什么是DevOps？如何使用DevOps？

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

毕竟，这个术语已经出现了 15 年，其采用率也呈指数级增长。然而，这并不意味着它的定义、定位和应用已经普及。它导致了许多语义上的混乱，如 BizDevOps、DevSecOps、AIOps、NoOps、FinOps 等。这一切都加剧了人们对 DevOps 及其与数字生态系统中任何人的相关性的困惑。因此，让我们花点时间来揭开 DevOps 背后的基本原理、原则和不为人知的真相。

一切是如何开始的？

首先，让我们从什么是 DevOps 的通用定义开始。仅仅这个简单的问题就能引发数小时的争论、争吵甚至宗教战争。因此，无论如何，让我们回到源头，寻找一个可靠的答案。帕特里克-德布瓦（Patrick Debois）于 2009 年在比利时根特组织了第一届 "DevOps 日 "活动，首次创造了这个术语。作为一名系统管理员，Debois 饱受技术交付链缺乏协作之苦，他的挫败感成为全球 DevOps 运动的火种。困惑之墙 "是一个痛苦的隐喻，指的是开发和运营之间缺乏共鸣、共享和有效协作。

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

对 DevOps 的这种广义理解说明了 DevOps 及其基本理念的整体观和适用性。虽然这个术语本身暗示着仅针对开发人员（dev）和操作人员（ops）的狭窄范围，但启动这一切的主要驱动力是改善所有相关孤岛之间的协作和流程，包括业务、安全、质量或支持。因此，理解为什么这种潜在的愿望会导致 DevOps 最终被采纳为组织、文化和技术变革的主要载体，远比寻找一个更好、更易理解的 "DevOps "更有意义。

DevOps 不是目标

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

在过去的十年中，许多 DevOps 应用都未能带来预期的价值。实践表明，DevOps 转型失败的主要原因之一是我们将其称为 DevOps 转型。这种给新举措贴标签的行为让我们不再关注根本（业务）目标，如更快乐的客户或高质量的交付等。

DevOps 的承诺建立在 "三种方法 "之上： 流程、反馈和持续学习与实验。

1. 第一种方法： 流程
侧重于优化从创意到生产、从开发到运营的工作流程。这意味着要打破团队之间的孤岛，创建协作文化，实现流程自动化以消除瓶颈。目标是确保工作尽可能顺利、快速地完成。优化端到端流程的策略包括批量大小：通过系统的工作批量较小。大型发布等结构会严重阻碍优化流程。
工作进度：限制团队同时处理的项目数量。
确定优先次序：以价值或经济为导向的决策支持将重点放在最相关的流程上。

2.第二种方法：反馈
强调在开发和运营内部之间和周围建立快速可靠的反馈回路。这意味着要实施持续的测试、监控和客户或用户反馈机制。还意味着要让团队能够轻松地分享知识并相互学习。这可以让团队尽早获得反馈，了解他们的价值假设是否有效。此外，这还包括从客户、用户、开发人员、供应商或生态系统中的任何其他利益相关者那里收集经验数据。毕竟，我们对所提供的产品或服务的潜在价值的假设，只能通过测量最终交付后的体验来验证。将情感和运营数据反馈到系统中可以促进持续改进和学习。

3.第三种方法：不断学习和实验
强调持续学习和实验的重要性。这意味着要培养一种实验文化，将失败作为学习的机会，在流程、技术和团队中建立复原力，并利用数据和指标来推动持续改进。通过不断学习和实验，团队可以长期改进流程和成果。

通过了解和实施 “三种方法”，组织可以改进协作、反馈和持续改进，从而取得更好的成果和更高效的流程。换句话说，它们有助于为团队带来真正的所有权和端到端的责任。或者，正如亚马逊首席技术官维尔纳-沃格尔斯（Werner Vogels）所说，“建造它，运行它”。团队在创造价值时遇到的依赖越少，我们在实践中看到的结果就越好。

保留 CALMS，构建 DevOps 实践
CALMS 是 DevOps 中广为接受的缩写，代表文化（Culture）、自动化（Automation）、精益（Lean）、测量（Measurement）和共享（Sharing）。当以适当的平衡方式一起应用时，CALMS 支柱提供了一个坚实的框架，指导组织采用 “三种方法”，并在其生态系统中集成相应的 DevOps 实践：

文化指的是在组织内部创建一种协作、同理心、信任和持续学习的文化。
自动化是指坚持不懈地将流程和工作流自动化，以提高效率并降低人为错误的风险。
精益是指精益（和敏捷）工作方式的方法论基础，如消除浪费、关注客户价值和流程。
衡量是指使用数据（证据）和指标来衡量产品、服务、流程和实践的有效性，并确定需要改进的领域。
共享是指促进组织内团队和个人之间的知识共享与协作。

文化： 培养同理心、协作精神和共同责任感CALMS 以文化为起点是有原因的。文化是 DevOps 理念的基础，它强调向协作、分担责任和打破组织孤岛转变。这种文化转变不仅限于开发和运营团队，还延伸到业务利益相关者、用户、安全专家和供应商。它包括一种重视沟通、换位思考和共同致力于为最终用户提供价值的思维方式。

鼓励 DevOps 文化包括在不同团队和部门之间培养透明度和开放的沟通渠道。业务部门融入开发流程，确保 IT 计划与组织目标保持一致。DevOps 文化的精髓在于通过打破团队之间的孤岛，促进责任共担文化，从而提高产品和服务交付的速度、质量和可靠性。

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

自动化：最大限度地减少手工作业，简化工作流程，提高效率自动化是为 DevOps 机器提供动力的引擎，使企业能够简化工作流程、减少人工错误并加快交付时间。从代码开发到部署和监控，自动化工具在实现持续发现、集成、交付和部署方面发挥着举足轻重的作用。

自动化测试可确保对代码变更进行全面评估，从而降低将缺陷引入生产环境的可能性。持续集成管道实现了构建和集成流程的自动化，为部署提供了一致、可靠的基础。自动部署工具有助于无缝、可重复地部署应用程序，最大限度地减少停机时间，提高整体效率。

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

精益：关注价值、消除浪费、优化流程

精益和敏捷是 DevOps 工作方式的核心。数字组织在很大程度上依赖于敏捷和精益原则与实践，以应对多变、不可预测的环境。无论团队使用 Scrum、看板还是其他工具来管理他们的工作（流程），DevOps 的主要工作特征都包含对价值、流程和弹性的执着关注。

如果您是 Scrum 团队的一员，正在为企业开发一种新产品，但却很难从已投入生产的产品增量中获得反馈。在这种情况下，您可以考虑使用结对工作、可观察性或经验测量来收集所需的反馈。在此过程中，可视化管理、价值流图和 Kaizen 等精益实践可以有效地应用这些实践，消除瓶颈或减少收集所需反馈的人工工作量。同样，如果您是一名每天与客户打交道的服务台人员，肯定会为处理复杂事件的解决小组之间的高效协作和工作流程而兴奋不已，也会为用于创造快乐客户和用户的体验数据的持续反馈回路而兴奋不已。

在应用精益和/或敏捷工作方法时，必须认识到并不是所有的环境都是平等的。如果您的团队是在一个以标准工作程序为主的可预测环境中运作，那么您对应用敏捷方法的需求将与处理高度不确定性和波动性的产品开发团队截然不同。因此，后者更有可能从增量开发、时间盒或 Scrum 等敏捷原则和框架中受益。同样，在可预测和稳定的环境下，精益改进将更有助于支持重复性任务和工作流程的标准化和自动化。

精益思想还鼓励使用指标（证据）来确定需要改进的领域。通过分析客户满意度、准备时间和恢复时间等指标，组织可以找出效率低下的地方，并优先考虑流程改进。

衡量： 数据驱动决策和持续改进
衡量是 DevOps 的基石，可为知情决策和持续改进提供所需的数据。DevOps 衡量标准有助于组织评估其数字产品、服务和流程的有效性，确定需要改进的领域，并跟踪随时间推移取得的进展。对相关数据和指标的持续收集、解释和应用有助于在整个价值生命周期（从构思到运营，从领导到团队）更好地开展协作。

大多数高绩效组织和团队已经卓有成效地应用了 DevOps 的典型 DORA 指标：变更提前期、部署频率、失败率和恢复时间。此外，企业还开始探索成果或价值指标，如客户保留率、用户满意度和员工幸福感。通过引入对成果、体验和影响的严格衡量，重点正在转向真正的端到端交付、优化和协作，而不是部分或团队成果。

与 DevOps 的 "第三种方法 "相一致，衡量也是持续学习文化的重要组成部分，以支持不断发展的生态系统。将零重复作为创新指标之一，激发安全的学习环境（“犯错没关系”），同时强调从以前的错误中学习的重要性（“同样的错误不要犯两次”）。

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

共享还延伸到文档和知识转移。DevOps 鼓励创建必要的（精益求精/恰到好处）文档，记录整个开发生命周期。这些文档是新团队成员入职、排除故障和确保人员变动时连续性的宝贵资源。

按照 "谁建设，谁管理 "的理念，企业努力将尽可能多的自主权和责任赋予实际团队。团队执行任务的自主性越强，其流程就越可靠，反馈回路就越短，为客户提供的价值就越大。一个常见的误区是期望产品生命周期和交付链中的所有任务都汇聚到一个团队中。认知负荷的概念告诉我们，人的局限性决定了不可能在一个由 5-9 名工程师组成的团队中汇集所有相关知识和能力，从简单到复杂。

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

将 DevOps 付诸实践

这一切都引发了人们对 DevOps 工程师是否存在的讨论。从根本上说，DevOps 是一场运动、一种思维方式、一套实践方法。声称我们有一个 DevOps 工程师，在一个角色中囊括了所有这一切，就好比说我们指派了一个人去协作。更实际的观点是，我们可以让工程师在任何现代组织中执行 DevOps 相关活动，并接受典型的 DevOps 原则和实践。无论他们是产品团队或平台团队的一员，还是担任辅助角色，我们都可以使用 DevOps 工程师这一总称来准确定位所需的能力和行为。

DevOps 就是通过应用 "三种方法 "和平衡各自的 CALMS 支柱来消除孤岛之间的摩擦。如果我们真正理解了这一点，就能为自己的组织发挥其潜力。这将使生态系统表现出更多的同理心、更好的协作、优化的流程，并最终为我们的客户创造更多价值。