理解 DevOps

无论您是在维护公司基础设施的正常运行，支持客户解决 IT 问题，构建、测试或修复软件，还是保护同事免受安全威胁，您很可能都遇到过 DevOps。

毕竟，这个术语已经存在了 15 年，其采用率呈指数增长。然而，这并不意味着其定义、定位和应用是统一的。这导致了许多语义上的混淆，如 BizDevOps、DevSecOps、AIOps、NoOps、FinOps 等。这些都增加了关于 什么是 DevOps 及其对数字生态系统中任何人的相关性的混乱。因此，让我们花些时间揭示 DevOps 背后的基础、原则和隐藏真相，好吗？

一切的起点

首先，让我们从一个关于 DevOps 的通用定义开始。仅仅这个简单的问题就可能引发无数小时的辩论、争吵，甚至宗教战争。所以，务必回到源头，寻找一个坚实可靠的答案。这让我们想到了 Patrick Debois，他于 2009 年在比利时根特组织了首届 DevOps Days，首次提出了这个术语。作为一名系统管理员，Debois 对技术交付链中缺乏协作的挫败感成为了全球 DevOps 运动的火种。混乱之墙成为了缺乏同理心、共享和有效协作的痛苦隐喻，这种情况主要体现在开发与运维之间。

他关于 DevOps 定义的最佳名言之一是，“DevOps 是你为克服孤岛之间的摩擦所做的一切。其他的都是普通工程学”。

这种对 DevOps 较为宽泛的看法体现了 DevOps 的整体视角及其适用性和底层哲学。尽管该术语本身暗示了仅针对开发者（dev）和运维人员（ops）的狭义范围，但其启动的主要驱动力是改善所有相关孤岛之间的协作和流程，包括业务、安全、质量或支持。因此，理解这一底层愿望为何最终促成了 DevOps 作为组织、文化和技术变革的主要载体，比寻找一个更好、更全面的名称更为重要。

DevOps 不是目标

既然我们知道如何定义 DevOps，也必须明白 DevOps 本身不是目标。无论我们将 DevOps 视为一套实践、原则，还是一种社会技术构造，它仅仅是实现底层目标的手段。活跃的 BVSSH 社区为我们提供了一套逻辑的主要目标：更好价值、更快、更安全、更快乐。换句话说，DevOps 的实践和原则可以帮助我们实现最佳价值、更高质量、更安全的交付、更快的反馈以及更快乐的客户和员工。如果你认为自己在做 DevOps，但没有实现这些底层目标，那么你做得不对。

过去十年中，许多 DevOps 采用未能带来预期价值。实践表明，DevOps 转型失败的主要原因之一是我们称其为 DevOps 转型。这种给新举措贴标签的冲动使我们忽视了底层（业务）目标，如更快乐的客户或高质量交付。

DevOps 的三条路径

该概念最早在上个十年初的《The Phoenix Project》一书中提出，DevOps 的承诺建立在三条路径上：流程（Flow）、反馈（Feedback）以及持续学习与实验（Continuous Learning and Experimentation）。

1. 第一条路径：流程

第一条路径关注优化从构想到生产、从开发到运维的工作流程。这意味着打破团队之间的孤岛，营造协作文化，并自动化流程以消除瓶颈。目标是确保工作尽可能顺畅快速地完成。优化端到端流程的策略包括：

• 批量大小：通过系统的小批量工作。诸如大规模发布等结构严重阻碍了最佳流程。
• 正在进行的工作：限制团队同时处理的项目数量。
• 队列：减少队列数量及其相应的吞吐时间。
• 优先级：基于价值驱动或经济决策，支持关注流程中最相关的事项。

2. 第二条路径：反馈

第二条路径强调在开发和运维内部、之间及周围创建快速且可靠的反馈循环。这意味着实施持续测试、监控以及客户或用户反馈机制。同时，也意味着让团队轻松共享知识并相互学习。这使团队能够及早获得其价值假设是否有效的反馈。此外，还包括收集来自客户、用户、开发者、供应商或生态系统中任何其他利益相关者的经验数据。毕竟，我们对所交付产品或服务潜在价值的假设，只有通过衡量交付后的最终体验才能得到验证。将情感和运营数据反馈回系统，促进持续改进和学习。

3. 第三条路径：持续学习与实验

第三条路径强调持续学习与实验的重要性。这意味着培养实验文化，将失败视为学习机会，在流程、技术和团队中建立韧性，并利用数据和指标推动持续改进。通过持续学习和实验，团队可以随着时间推移改进其流程和成果。

通过理解和实施这三条路径，组织可以改善协作、反馈和持续改进，从而带来更好的成果和更高效的流程。换句话说，它们有助于赋予团队真正的所有权和端到端责任。正如亚马逊 CTO Werner Vogels 所说：“你构建它，你运行它。”团队在创造价值时遇到的依赖越少，实践中看到的成果就越好。

保持 CALMS，构建你的 DevOps 实践

CALMS 是 DevOps 中广泛接受的缩写，代表 Culture、Automation、Lean、Measurement 和 Sharing。当这些支柱以正确的平衡应用时，CALMS 提供了一个坚实的框架，指导组织采用三条路径并将相应的 DevOps 实践整合到其生态系统中：

• Culture 指在组织内营造协作、同理心、信任和持续学习的文化。
• Automation 指不断自动化流程和工作流，以提高效率并减少人为错误的风险。
• Lean 指 Lean（及 Agile）工作方式的方法论基础，如消除浪费，关注客户价值和流程。
• Measurement 指利用数据（证据）和指标衡量产品、服务、流程和实践的有效性，并识别改进领域。
• Sharing 指促进组织内团队和个人之间的知识共享与协作。

Culture：培养同理心、协作和共同责任

CALMS 以 Culture 开头是有原因的。文化是 DevOps 哲学的基础，强调向协作、共同责任和打破组织孤岛的转变。这种文化转型不仅限于开发和运维团队，还扩展到业务利益相关者、用户、安全专家和供应商。它包含一种重视沟通、同理心和共同致力于为最终用户交付价值的心态。

鼓励 DevOps 文化包括促进不同团队和部门之间的透明度和开放沟通渠道。业务部门被整合到开发过程中，确保 IT 计划与组织目标保持一致。DevOps 文化的核心是通过打破团队间的孤岛，促进共同责任文化，从而提升产品和服务交付的速度、质量和可靠性。

关注这些文化方面将实现更快的价值交付、更高的质量和可靠性、更灵活地响应不断变化的业务需求，以及增强团队协作和团队精神。此外，DevOps 文化还可以通过自动化重复任务和简化流程，帮助组织降低成本并提高效率。

Automation：最小化手动工作，简化工作流以提升效率

Automation 是驱动 DevOps 机器的引擎，使组织能够简化工作流、减少人为错误并加快交付周期。从代码开发到部署和监控，自动化工具在实现持续发现、集成、交付和部署中发挥着关键作用。

自动化测试确保代码变更得到彻底评估，减少将缺陷引入生产环境的可能性。持续集成管道自动化构建和集成流程，为部署提供一致且可靠的基础。自动化部署工具促进应用的无缝且可重复部署，最大限度减少停机时间，提高整体效率。

除此之外，无数其他技术解决方案也解决相关任务，如版本控制、发布管理、容器编排、基础设施配置、知识管理、体验测量、监控和可观测性。

精益：聚焦价值，消除浪费，优化流程

精益和敏捷是DevOps工作方式的核心。数字化组织高度依赖敏捷和精益的原则与实践，以应对其多变且不可预测的环境。无论团队使用Scrum、Kanban还是其他工具来管理其工作（流程），关键的DevOps工作特征都包括对价值、流程和韧性的执着关注。

如果您是参与为组织开发新产品的Scrum团队成员，并且难以从已投入生产的产品增量中获得反馈，那么您可以考虑使用配对工作、可观测性或体验测量来收集所需反馈。通过这样做，精益实践如可视化管理、价值流映射和Kaizen可以有效应用这些方法，消除瓶颈或减少收集反馈时的人工工作。同样，如果您是每天与客户打交道的服务台代理，您肯定会对解决团队之间高效的协作和工作流程感到兴奋，这些团队处理复杂事件或利用持续反馈循环的体验数据来创造满意的客户和用户。

应用精益和/或敏捷工作方式的关键在于认识和理解并非所有环境都是相同的。如果您的团队在一个以标准工作程序为主的可预测环境中运作，您应用敏捷方法的需求将与处理高度不确定性和多变性的产品开发团队大不相同。因此，后者团队更可能从增量开发、时间盒或Scrum等敏捷原则和框架中受益。同样，处于可预测且稳定环境的团队更适合通过精益改进来支持其重复任务和工作流程的标准化与自动化。

精益思维还鼓励使用指标（证据）来识别改进领域。通过分析客户满意度、交付周期和恢复时间等指标，组织可以定位低效环节并优先进行流程优化。

测量：数据驱动的决策制定与持续改进

测量是DevOps的基石，提供了做出明智决策和持续改进所需的数据。DevOps指标帮助组织评估其数字产品、服务和流程的有效性，识别改进空间，并跟踪进展。持续收集、解读和应用相关数据与指标支持从创意到运营、从领导层到团队的整个价值生命周期中的更好协作。

大多数高绩效组织和团队已成功应用典型的DORA指标：变更交付周期、部署频率、失败率和恢复时间。此外，组织开始探索结果或价值指标，如客户留存率、用户满意度和员工幸福感。通过引入对结果、体验和影响的严格测量，关注点正从部分或团队成果转向真正的端到端交付、优化和协作。

与DevOps的第三条路径一致，测量也是支持不断学习文化、促进生态系统持续演进的重要组成部分。以零重复为创新指标之一，激励安全学习环境（“犯错没关系”），同时强调从过去错误中学习的重要性（“就是不要犯同样的错误两次”）。

共享：分担认知负荷与知识共享

CALMS中的共享强调团队内外沟通、协作和知识共享的重要性。在DevOps文化中，信息在开发、运维及其他利益相关者之间无缝流动，促进对目标和优先事项的共同理解。

共享还延伸至文档和知识传递。DevOps鼓励创建必要的（我们是精益的：恰到好处的）文档，涵盖整个开发生命周期。这些文档是新成员入职、问题排查及人员变动时确保连续性的宝贵资源。

遵循“你构建，你运行”的理念，组织努力将尽可能多的所有权和责任赋予实际团队。团队自主完成任务的能力越强，其流程越可靠，反馈循环越短，交付给客户的价值也越大。一个常见的误区是期望产品生命周期和交付链中的所有任务都集中在一个团队中。认知负荷的概念告诉我们，人类的能力有限，不可能将所有相关知识和能力——从简单到复杂——都集中在一个由5-9名工程师组成的团队中。

这就是为什么组织采用区分产品和平台的组织结构，使团队能够将产品交付与平台工程及专业支持分开。这使得产品团队能够专注于理解、创建和交付面向客户的数字产品，同时利用平台团队提供的标准化服务，并由支持团队中的安全或测试自动化专家提供支持。

实践DevOps

这也引发了关于是否存在所谓DevOps工程师的讨论。从根本上讲，DevOps是一种运动、一种思维方式、一套实践。声称有一个DevOps工程师能在一个角色中涵盖所有这些，就像说我们指派一个人来完成协作一样。更实际的观点是，现代组织中各处的工程师都可以执行与DevOps相关的活动，拥抱典型的DevOps原则和实践。无论他们是产品团队、平台团队的一部分，还是担任支持角色，我们都可以使用总括性的“DevOps工程师”一词来指代所需的能力和行为。

DevOps通过应用三条路径并平衡相应的CALMS支柱，消除孤岛之间的摩擦。如果我们真正理解这一点，就能发挥其对我们组织的潜力。这将带来更具同理心、更好协作、优化流程的生态系统，最终为客户创造更多价值。