通过6个简单步骤过渡到DevOps

一年前的高管们决定开始一个新项目——创建一款旗舰产品，作为解决方案组合的一部分。高管们对产品开发方式提出了挑战，并希望探索快速推出产品的新方法。经过内部讨论，决定尝试一种开发产品的新方法。决定与 DevOps 团队合作。在本文中的 SCRUM 大师 Peter Borg 解释了过渡到 DevOps 文化的必要步骤和要克服的挑战。

过渡到 DevOps 的步骤

从历史上看，该公司在传统的敏捷设置中遇到了一些问题，这导致了项目交付的延迟。如果 SCRUM 团队正在全速运行以实现目标，但基础设施尚未准备好，则交付会延迟。部门隔离可能会造成支持团队可能没有资源来支持 SCRUM 团队的情况。仅一个部门并不能交付软件产品，而这正是我们希望通过过渡到 DevOps 来改变的。

1. 创建自给自足的团队

为了启动新的 DevOps 文化变革，我们组建了一个新团队，其职位描述对公司来说是独一无二的。我们从全栈开发人员转向 DevOps 软件工程师，从系统管理员转向站点可靠性工程师 (SRE)。

通过这样做，我们能够组建一个自给自足的团队，其目标是交付手头的项目。除了在新技术堆栈的特定方面拥有专业知识外，雇用合适的人也至关重要，他们可以在不依赖团队外部人员的情况下交付产品。

SRE 的任务是对基础架构进行编码，软件工程师负责开发应用程序，QA 工程师负责建立自动化测试框架，软件和系统架构师负责设计解决方案。

尽管人们根据他们的知识领域被指定用于特定任务，但我们促进了知识的交叉授粉。SRE 为软件代码做出了贡献，软件工程师参与了我们的 基础设施即代码 (IaC)，QA 参与了我们的测试驱动开发 (TDD) 策略和持续集成 (CI) 管道，架构师帮助开发和故障排除。

2. 拥抱测试驱动开发

每个人都讨厌大爆炸式发布，这会导致发现后期集成问题、重构复杂解决方案以及可能的产品愿景分歧等问题。

为了不陷入这些陷阱，我们选择了 测试驱动开发 (TDD)。TDD 使我们能够分解、实施、测试、审查和扩展复杂的解决方案，同时在我们构建产品的过程中始终从产品负责人 (PO) 那里获得反馈。这种迭代方法和反馈循环使我们能够在建立坚实的基础后继续改进功能，这是敏捷宣言中的第一条原则（Kent Beck 等人，2001）。采用 DevOps 方法时要牢记的最重要的考虑因素是确保团队不会在情感上将自己与他们的实施联系在一起，因为它可能有一天会在那里，但第二天就会消失。

通过选择 TDD 方法，我们用非过度设计的解决方案实现了复杂的问题。TDD 是一种迭代方法来开发功能，使重构更容易实现，同时还增加了解决方案的质量。“从某个地方开始，从经验中学习”（John Shook。2008 年。管理学习：使用 A3 管理流程解决问题、获得共识、导师和领导）。

3. 推动 DevOps 文化变革

引入文化变革不仅很难。这令人筋疲力尽，令人沮丧和士气低落。在多结构组织中推动不同的思维方式比在初创公司中建立公司文化要困难得多。

这就是为什么我相信通过以同样的方式对待他们可以实现改变。如果您试图在一家已经建立的公司内构建不同的实施方法，那么只有创建一个小型组织生态系统才能实现。形成公司在实施新项目时将其视为初创公司的团队结构。

您将面临限制，例如“这不是我们做事的方式”或“我们已经为此提供了不同的工具”。如果你听到这些陈述，你就走在了正确的轨道上。提出文化变革时，首先需要做的就是质疑公司的流程和工具。考虑现有的工具和方法是否完全相关。

在我们的案例中，通过质疑，我们能够利用 云原生技术 ，而不是公司认为“标准”的系统。在推动 DevOps 变革时，您不会得到所有人的支持。然而，获得高层管理人员的支持至关重要。这将有助于激励公司内部不太愿意改变的人，因为愿景得到了更高管理层的支持。

4. 测试你的进步

在各个 DevOps 过渡阶段测试您的工作进度。从测试速度开始。您希望敏捷并快速实施解决方案。通过将“启动”项目与其他正在进行或历史的解决方案进行比较，您应该能够了解 DevOps 团队是否交付得更快。衡量团队适应变化的能力也很重要。如果反馈回路的变化结果是对系统的大修，那么在设计阶段就出现了问题。

其次，通过分析团队的士气来衡量成功。当引入新的实施适应时，人们应该感到兴奋和积极。你会意识到你已经通过无意中听到团队中的某个人与团队外部的某个人交谈，解释我们如何使用新的心态或技术解决问题，这对公司来说是新的。这将激发其他团队的兴趣，并且在这一点上，您会意识到文化变革正在整个组织中蔓延。考虑一下成功的真正衡量标准——新的 DevOps 方法受到关注。其他团队成员想尝试不同的事情，并就如何使用 DevOps 解决方案向您寻求建议。

5. 毫不妥协

当我担任 SCRUM Master 的角色时，我知道我必须尽快交付新产品和 DevOps 文化变革。必须在整个产品开发阶段保持这两个目标一致。面对此类挑战时，高管的认同和信任可以成就或破坏文化变革。有时，管理层可能不会关心项目是如何实现的，只要它已经交付——即使我们不得不使用过时的技术。

这让我想到了下一点，从一张空白画布开始。不要试图将当前的公司标准融入到 DevOps 开发软件的方式中。从头开始并保持精益解决方案。让团队研究解决问题的最佳工具。如果他们确定了公司已经在使用的解决方案，那就太好了。如果他们不这样做，那么将新工具展示给支持当前解决方案的任何人，以获得他们的支持来改变它。确保团队牢记没有什么是一成不变的，工具可以改变，有人可能有更好的想法，需求也可以改变；它是迭代的。

6. 将其他团队过渡到 DevOps

一旦这个微型组织内的 DevOps 文化变革开始结出硕果，您就需要考虑下一步—— 增长。如何让更多团队过渡到 DevOps？

丰田生产系统 (TPS) 理念（Toshiko Narusawa 和 John Shook. 2009. Kaizen Express）似乎符合 Spotify 的敏捷扩展模型。保持一个尽可能扁平和独立的组织结构是关键。这赋予了团队权力，使他们对自己的成功和失败更加负责。与其组建由相同技能人员组成的部门，不如设立“分会”，让这些成员组成 SCRUM 团队的一部分，并鼓励他们相互联系以帮助解决问题。促进持续的沟通保持团队内的项目优先级。

设置知识共享活动，以告知其他部门团队已做出的任何技术决策。知识共享将有助于推动整个公司向 DevOps 的过渡，并在整个组织中获得支持。在过去的一年里，我们学到了很多东西，并且我们一直在寻找通过不同迭代来改进我们的流程和结构的方法。保持精益和敏捷的心态并确保产品是成功的故事将是维持的最重要因素。

关于切换到 Devops 的最终建议

对于任何过渡到 DevOps 的人来说，最后也是最关键的一点是永远不要放弃。有时你会认为拥抱 DevOps 文化很难实现，但如果你有来自团队、管理层和高管的正确支持系统，你就会成功。有一天，来自另一个团队的人会要求开会，想知道你是如何实施某事的。那时你会意识到公司正走在接受 DevOps 文化的正确轨道上。分阶段将理念从一个团队传播到另一个团队，并花时间将整个组织转移到 DevOps。