持续交付与-DevOps-第三版-全-

持续交付与 DevOps 第三版（全）

原文：annas-archive.org/md5/ba124a17e6265749b6cd2d08ea640996

译者：飞龙

协议：CC BY-NC-SA 4.0

前言

持续交付（CD）和 DevOps 在过去十年左右一直是聚光灯下的焦点。关于 CD 和 DevOps 的技术方面和工具已写了大量内容，然而，许多所谓的 IT 专家实际上并不真正理解它们到底是什么。更令人担忧的是，他们似乎也不知道它们绝对不是些什么。在本书的章节中，我将逐步解析 CD 和 DevOps，让您了解它们是什么、它们是如何产生的，以及它们如何为您的业务带来真正的商业价值。严格来说，我们应将 CD 和 DevOps 视为两种互为补充但独立的方式：

• 如书名所示，持续交付是一种工作方式，在这种方式下，质量产品，通常是软件资产，可以快速构建、测试和交付，从而比传统方法更快地交付价值。

• DevOps 是一种工作方式，开发人员与 IT 系统运维人员紧密合作、协作并和谐共事，朝着共同目标努力，彼此之间几乎没有或完全没有组织障碍和界限。

本书将为您提供一些洞见，帮助您优化、简化和改进工作方式，并最终帮助您交付高质量的软件。本书中包括了一些基于现实世界经验和观察的窍门和技巧；它们可以帮助您减少实施和采用 CD 与 DevOps 所需的时间和精力，从而帮助您减少一致交付高质量软件所需的时间和努力。

在本修订版中，您将接触到有助于成功采用 CD 和 DevOps 的工具、技术和方法。本书中包括了真实世界的示例，帮助您理解 CD 和 DevOps 的采用过程，从准备阶段到实施和扩展，再到超越传统应用领域，同时还包含一些现实世界的示例、窍门和技巧，帮助推动采用。您将获得清晰简明的见解，了解 CD 和 DevOps 到底是什么，以及它们能为您的业务和每一位员工带来什么量化的价值。

本书适合谁阅读

参与传统软件交付的每个人，无论是 IT 专业人员、高层管理人员、产品负责人、开发人员、测试人员、项目经理，还是那些总是充满好奇的技术媒体，都会在某个时刻意识到一个共同的问题；交付高质量的软件可能非常困难、非常痛苦且成本高昂。但这并非必然，也不应如此。本书是为所有希望了解如何克服这些困难，以及如何通过采用 CD（持续交付）和 DevOps 来减轻这些痛苦的人编写的。

本书内容概述

第一章，软件交付的演变，介绍了一个典型的基于软件的企业，并详细描述了它们从一个初创公司、通过收购后的成长痛苦，到实现两者优势的演变过程。

第二章，理解当前的痛点，介绍了可以用来确定当前软件交付过程中的痛点以及它们来源的工具和技巧。

第三章，文化与行为是成功的基石，强调了如果你想让 CD 和 DevOps 成功，必须考虑到“人”因素的重要性。

第四章，为成功规划，提供了如何定义 CD 和 DevOps 成功采用的指引，以及如何衡量这种成功。

第五章，方法、工具与技巧，介绍了可以帮助 CD 和 DevOps 采纳的各种工具和技巧（有些是技术性的，有些则不完全是）。

第六章，避免障碍，为你提供有用的见解、技巧和窍门，帮助你克服或避免在采用 CD 和 DevOps 过程中遇到的路障。

第七章，关键指标，集中讨论了可以用来监控和传达 CD 和 DevOps 采用相对成功程度的各种度量标准和指标。

第八章，你还没有完成，涵盖了如果你想将 CD 和 DevOps 固化到日常工作中，必须完成的那些不那么显而易见的重要任务。

第九章，扩展你的机会视野，探讨了在采用 CD 和 DevOps 之后，如何进行演变。

第十章，超越传统软件交付的 CD 和 DevOps，提供了如何将 CD 和 DevOps 工具、技巧和方法应用到软件交付以外领域的见解。

如何最大化利用本书

本书并非专注于某一特定人群或特定类型的读者。如果你从未听说过 CD 或 DevOps，本书将为你提供关于这些话题为何如此引起关注的见解。如果你已经开始采用 CD 和/或 DevOps，本书则可以通过提供一些有用的技巧和窍门来帮助你。如果你对这两个主题都了如指掌，那么本书将帮助你确认你的选择，并可能为你提供一些额外的思考。总的来说，目标读者范围非常广泛：任何想了解如何无痛且定期交付优质软件的人。

之前了解 DevOps 实践、CD 或使用 DevOps 工具的知识并非必需。

下载彩色图片

我们还提供一个包含本书中所有截图/图表彩色图像的 PDF 文件。您可以在此下载：www.packtpub.com/sites/default/files/downloads/9781788995474_ColorImages.pdf。

使用的约定

本书中使用了多种文本约定。

警告或重要提示如下所示。

提示和技巧如下所示。

联系我们

我们欢迎读者的反馈。

一般反馈：如果您对本书的任何部分有疑问，请在邮件主题中注明书名，并通过 customercare@packtpub.com 邮件联系我们。

勘误表：虽然我们已经尽力确保内容的准确性，但错误仍然可能发生。如果您在本书中发现任何错误，我们将不胜感激，如果您能向我们报告。请访问 www.packt.com/submit-errata，选择您的书籍，点击“勘误提交表格”链接，并输入相关细节。

盗版：如果您在互联网上发现我们作品的任何非法复制品，我们将不胜感激，如果您能提供其位置或网站名称。请通过 copyright@packt.com 邮件联系我们，并附上该材料的链接。

如果您有兴趣成为作者：如果您在某个领域有专业知识，并且有兴趣撰写或为书籍贡献内容，请访问 authors.packtpub.com。

评价

请留下您的评价。阅读并使用本书后，为什么不在您购买书籍的网站上留下评价呢？潜在读者可以通过您的公正意见做出购买决策，我们在 Packt 可以了解您对我们产品的看法，作者们也能看到您对其书籍的反馈。谢谢！

有关 Packt 的更多信息，请访问 packt.com。

第一章：软件交付的演变

如前言所述，持续交付（CD）和 DevOps 是互补的工作方式。前者使任何通过软件交付客户价值的人能够迅速、一致地，并且—正如名字所示—持续地完成交付。后者则有助于协调交付和支持该软件的团队。两者都能帮助你优化、精简并改进工作方式，最终提高通过交付高质量软件来传递价值的能力。

需要指出的是，过去十年中，这些方法的真正意义已经被模糊化—无论是技术媒体的误解，还是招聘公司为了提高薪资而夸大其词，或者软件供应商和咨询公司希望通过跟风来赚取财富。

我已经总结了 CD 和 DevOps 的定义，但在继续之前，可能有助于我强调它们并非什么：

• 持续交付和持续部署并不相同——前者关注的是商业价值，而后者是交付软件的机制。

• DevOps 工程师不是魔法师。软件工程师和 DevOps 工程师本质上是一样的——前者创建用于生成软件资产的文本文件，后者创建用于生成运行该软件所需环境和配置的文本文件。

• DevOps 并未取代传统的系统运维活动和方法——它扩展、补充并增强了这些活动。

• DevOps 并不消除确保软件及其运行环境高度安全的需求——尽管它可以促进 SecOps 的采纳和实施。

• CD 和 DevOps 并不是解决所有流程和业务问题的灵丹妙药，尽管它们能帮助减少整体问题的数量。

你需要考虑的一点是，几乎所有成功的软件公司都会经历多个演变阶段。它们通常从一个小而专注的团队开始，拥有很好的创意、雄心壮志和一些投资。随着市场份额、覆盖范围和收入的增长，通常会出现一个快速增长的阶段，体现在员工和支出的增加上。随着公司成熟并且站稳脚跟，它们会进入下一阶段，要么继续大规模增长以保持竞争优势，要么成为并购的目标——这通常取决于投资者希望多快看到回报。

同时，也不可避免地，随着业务的演变，日常的业务流程会变得更加复杂，这反过来会导致软件交付的复杂性和困难。

CD（持续交付）和 DevOps 的采用可以帮助减少这种复杂性和痛苦；然而，企业可以获得的效果和好处在很大程度上取决于企业在进化阶梯上的位置。如果你偏离了目标，采用这些方法可能反而会带来更多麻烦，甚至可能使整体业务变得更糟。不仅如此，企业是奇特且独特的存在——尤其是那些以提供软件解决方案为生的企业——没有两家企业是相同的；因此，采用这些方法需要量身定制，才能切合实际。

本章我们将涵盖的主题如下：

• 对软件交付进化各个阶段的更详细解释

• 每个阶段的优点和缺点

• 如何确定你处于哪个阶段

• CD 和 DevOps 工作方式可能带来的未曾预见的优势

为了更容易理解这些实际意义，我们现在将通过追踪一个典型的软件公司——ACME 系统的进化过程，深入探讨这些阶段。

ACME 系统——进化阶段 1.0

ACME 起步时与全球成千上万的小型软件公司有一些共同点：它有一些不错的创意，并且看到了市场中的一个可以利用的空白，从而可以借此发财。它的资金相对较少，因此需要快速行动才能生存下去，并且必须不惜一切代价迅速吸引、招募和留住客户。它通过在客户需要之前交付他们想要的产品来实现这一目标。如果交付过早，可能会浪费资金构建客户最终决定不再需要的解决方案；如果交付过晚，别人可能已经抢走了公司的市场份额——以及收入。这里的关键词是交付。

作为一家小型初创公司，在初期，进展缓慢，工作艰难：大量的研发，拼命构建的预售原型，快速且粗糙的交付，以及不切实际的截止日期。在经历了许多漫长的日子、夜晚、周末和几个月之后，事情终于开始有了起色。客户群体开始增长，订单和收入也开始滚滚而来。过了一段时间，员工人数达到了两位数，创始人也变成了董事。

那么，这与 CD 或 DevOps 有什么关系呢？实际上，关系非常大。一个小型软件公司的文化、默认行为和工程实践，在 CD 和 DevOps 方面被视为相当不错。例如：

• 开发人员与运维团队之间几乎没有任何障碍——事实上，他们通常是同一个团队

• 开发人员可以完全访问生产环境，并能够密切监控他们的软件

• 业务的所有领域都专注于同一目标，即尽可能快速地将软件投入生产环境，从而让客户满意。

• 交付速度至关重要

• 如果出现故障，每个人都会聚集起来帮助修复问题——即使是非工作时间

• 软件快速演进，特性以增量方式添加

• 工作方式通常是非常敏捷的

• 跨业务部门的沟通和协作高效且大多数情况下有效

提出小型软件公司文化、默认行为和工程实践属于“相当好”而非“理想”的原因是，小型软件公司通常必须以某种方式运作以生存，这其中有很多缺陷：

• 为了赶上截止日期，常常会削减角落，导致软件设计、质量和优雅性受到妥协

• 应用安全最佳实践常常被忽视或根本不予考虑

• 为了赶上截止日期，工程最佳实践常常被妥协

• 技术债务的概念几乎被忽视

• 测试不会是开发人员的首要任务（即使它是，也可能没有足够的时间以测试驱动的方式进行工作）

• 源代码和版本控制系统没有严格遵守使用规则

• 由于可以无限制地访问生产环境，因此可以随意且不受控制地调整基础设施和环境设置

• 软件发布将主要是手动操作，并且大多数时候是整体系统设计后的附加考虑

• 有时，粗糙且即用的原型可能会直接成为生产代码，且没有机会进行重构

• 文档稀缺或不存在——现有的文档很可能是过时的

• 在小型软件公司工作的工程师的工作与生活平衡是不可持续的，倦怠确实会发生

让我们看看 ACME 系统的软件交付流程 1.0 版本，老实说，这不应该花太多时间。

软件交付流程版本 1.0

以下图表展示了 ACME 系统用于交付软件的简单流程。它简单、优雅（以一种粗犷的方式），且易于沟通和理解：

ACME 1.0 版本的软件交付流程概览

这个非常简单的流程是许多小型软件企业和初创公司会认同的。从 CD 和 DevOps 的角度来看，构建和交付软件的人员与支持它的人员之间几乎没有障碍（我们将在本章后面详细讲解这一点）。

让我们往前看几年，看看 ACME 系统的现状，并从中获得一些关于成为行业领导者的好处和陷阱的见解。

ACME 系统进化阶段 2.0

企业的规模和营业额都在增长。客户基础已扩展到全球，ACME 软件平台每天为数百万客户提供服务。ACME 系统作为一家公司已经建立了稳固的基础，声誉良好，并被认为是该领域的前沿者。然而，增长和投资的水平已经对利润产生了影响——利润几乎是不存在的。

ACME 系统的董事会接到了一个来自更大竞争对手的收购提议。董事会和投资者认为这一提议具有良好的商业意义，且将有助于未来业务的稳定，因此同意出售。总体而言，大家都对这笔交易感到满意，大多数人视此为他们终于迎来成功的标志。

一开始，一切都很顺利——事实上，一切都非常好。ACME 系统团队现在获得了所需的支持，可以投资于业务并实现扩展，进而获得真正的全球影响力。它还可以专注于重要事项，例如构建高质量的软件、扩展软件平台、投资于新技术、工具和研发。企业中较为枯燥的一面——行政管理、项目与程序管理、销售、市场营销等等——可以交给已经拥有这些体系的新母公司来处理。

ACME 工程团队满怀期待地向前推进。投资的规模之大，以至于软件工程团队在几个月内翻了一番。现在称为研发团队的团队引入了新的开发工具和流程，以加速高质量软件的交付。敏捷方法在研发团队中得到了广泛采用，充分利用工程最佳实践的机会也得以实现。原先的 ACME 平台开始出现老化的迹象，逐渐显得力不从心，因此又获得了进一步投资，以重新设计并重写软件平台，采用最新的架构方法和技术。简而言之，研发团队觉得一切开始走向正轨，且有机会做对的事情。

与此同时，负责生产环境的 ACME 工程团队成员被吸收到母公司的全球运营组织中。从表面上看，这似乎是个非常好的主意；数据中心里充满了尖端设备，云能力、全球网络能力和可扩展的基础设施一应俱全。所有托管和运行 ACME 平台所需的资源都在这里。和研发团队一样，运营团队拥有比他们曾经梦想的更多资源。除了硬件和基本的设施，运营团队还有可用于维护质量、控制平台变更的资源，并确保平台能够稳定运行并提供 24 小时不间断的服务。

在这一切之上，母公司也拥有成熟的治理结构，以及程序和项目管理职能，用以控制和协调整体的端到端产品交付时间表和流程。

表面上看，一切似乎都很美好，团队们比以往任何时候都更加高效地工作。最初，这的确是事实，但很快，情况开始发生下滑。在表面之下，情况并非那么美好：

• 交付软件变得越来越困难——原本只需几天的工作，现在可能需要几周甚至几个月。

• 随着新的 ACME 平台快速增长，更多的功能被添加，变更不断进行，发布变得过于复杂且越来越大。

• 尽管在重新架构 ACME 平台方面取得了一些进展，但系统深处仍然存在大量有缺陷的遗留代码，它们顽固不化，拒绝消失。

• 研发团队成员现在距离生产环境如此遥远，以至于他们对自己编写的软件如何运作或表现一无所知，直到软件最终上线。

• 运维团队成员现在距离开发流程如此遥远，以至于他们对交付的内容以及其开发方式一无所知。

• 在软件变更能够接近生产服务器之前，必须通过许多公司流程和解决各种过程障碍。

• 质量开始受到影响，因为最后一分钟的更改和匆忙的错误修复被应用于适应发布周期。

• 在快速而松散的开发阶段积累的技术债务开始引发重大问题。

• 越来越多的研发资源被投入到协助发布的工作中，这影响了新功能的开发。

• 部署导致了生产停机时间的延长——包括计划内和计划外的停机。

• 截止日期被错过，利益相关者受到失望，信任正在被侵蚀。

• 曾经光辉的声誉正在被玷污。

然而，主要问题在于，这种渐进性的损耗已经缓慢发生了数月，并非每个人都注意到——他们都太忙于试图完成交付。

现在让我们重新审视软件交付的流程，看看自上次查看以来发生了什么变化——这不是一幅美丽的画面。

软件交付流程版本 2.0

如下图所示，ACME 团队的情况变得非常复杂。曾经简单优雅的流程变得复杂、曲折且高度低效。步骤和障碍的数量增加了，使得软件交付变得极为困难。事实上，几乎什么都做不成了。以下图表概述了 ACME 版本 2.0 的软件交付流程：

ACME 版本 2.0 软件交付流程概述。

这一远非简单的流程是许多大型软件公司都会认识到的。从持续交付和 DevOps 的角度来看，这个流程远非理想，因为现在交付软件的团队与支持它的团队之间存在许多障碍。

坦率地说，所描绘的流程实际上缺少一些关于变更管理环节的附加细节，这些细节可能会增加更多的复杂性、工作量和痛苦。让我们补充这些细节，再次审视一下：

ACME 版本 2.0 软件交付流程的更现实概述。

正如你所看到的，情况远非理想。曾经高效有效的流程现在已经变成了完全的反面。更重要的是，所有参与变更交付的人之间的对话、沟通质量和信任，充其量是支离破碎的，最糟糕的是几乎完全不存在。曾经的五分钟咖啡聊天现在变成了 20 页的邮件线程、会议和 Skype 聊天。前 ACME 工程团队成员不再像同事，更像是深陷战斗的对手。

这个过程不仅冗长，而且一个变更在没有问题地完成整个流程的机会非常渺小——大多数情况下，变更必须在循环中绕一圈又一圈，才能算作可以发布的版本；例如，过程中任何环节发现的缺陷可能会将变更推回到流程的开始。

我提到对话、沟通质量和信任是有非常特定的原因的——你在 CD 和 DevOps 相关的许多文章和讨论中会看到，它们似乎暗示一些新的工具和最佳架构方法会提供你所需要的东西。虽然这些可能有所帮助，但也可能会带来巨大的阻碍——特别是在公司经历组织变革和/或增长的同时引入这些变更时。在 ACME 的例子中，变化来得太快，大家都没能理解发生了什么，旅程将会走向何方。这不可避免地导致了人性发挥作用，人们在混乱中建立起了屏障和孤岛，以保持一些稳定。

如果你把这一切都考虑进去，从外部的角度看，ACME 系统用来交付软件的过程，现在在实际意义上已经完全失败了。

好吧，这可能有点夸张，但它突出了一个问题，那就是在那些参与变更交付的人之间——尤其是研发团队成员（负责交付急需的变更和功能）与运维团队成员（负责支持将要应用变更的生产环境）之间，存在着相对的巨大隔阂，这完全可能导致事情脱轨。

从内部看外部的视角

正如之前所说，并非每个人都注意到了组织中的人员流失——幸运的是，还是有一些细心的人察觉到了。少数 ACME 团队成员意识到情况并不理想，决定从外部的视角回顾问题。然后，他们开始清楚地看到了整体流程中的问题，并决心让所有人都看到这些问题。此外，他们决定解决这些问题——只是有一个小问题，如何在每个人都全力以赴地在自己的孤岛内以解决自己的问题、以任何代价交付软件的情况下做到这一点。

起初，他们投入了大量个人时间来研究和构建简单粗糙的工具，包括构建和测试自动化、持续集成（CI）、持续部署流水线和系统监控解决方案。其目的是尽可能自动化断裂流程中的各个部分，以减少痛苦。他们还在技术驱动的同侪群体中积极宣传这些想法。尽管大多数人欢迎他们的想法和建议，但没有足够的动力去采纳这些新式工具——每个人都忙于在断裂的流程中交付软件，他们需要另一种方法。

他们决定需要一些帮助，于是寻求了一位在更广泛业务中具有影响力、志同道合的经理，帮助他们获得急需的支持。在经过多次劝说、讨论和恳求后，这位经理同意帮助他们获得预算，组建一个专注于推进 CD 和 DevOps 工具的小团队。新成立的团队成员花了几个月的时间识别并拆解最紧迫和最痛苦的问题，构建、安装并实施了能够缓解一些痛苦的工具——为了便于采用，许多工具是量身定制的，以适应现有的流程。

这在一定程度上解决了断裂的流程，但现实是，这些工具并没有产生他们预期的影响。实际上，为了使工具适应现有流程，它们本身需要做出如此多的修改，以至于它们开始变得不可靠和过于复杂，甚至最初支持这种方法的人开始质疑自己决策的有效性。

最终，存在一个更大的问题是工具无法解决的——那就是组织本身的文化、其中人员的行为，以及多年来在分裂的业务孤岛之间形成的各种脱节的沟通方式。很明显，所有的工具和中国的茶都无法缓解痛苦；需要更为彻底的变革。

团队成员重新聚焦，并很快意识到，真正需要改变的不是工具去适应流程，而是流程和工作方式本身需要改变。如果这个问题得到解决，工具可以直接从货架上取下来——可以这么说——并且无需大量修改就能使用。团队成员必须大幅改变方向，减少对技术的关注，更像是业务变革的推动者。他们随后将这一显而易见的事实传递给尽可能多的组织内外人员，同时这位有影响力的经理努力争取高层领导的支持，以实施深远的业务变革。幸运的是，他们在组织内的声誉和地位使得获得支持变得容易。

我们现在进入了演变的第三阶段，事情开始重新聚集在一起，ACME 团队重新获得了在需要时交付高质量软件的能力。

ACME 系统演进阶段 3.0

现在，CD 和 DevOps 团队得到了高层的正式支持，成员们开始解决破碎的文化和行为，制定克服和/或消除障碍的方法。他们不再仅仅是一个技术团队；他们是业务变革的催化剂。

任务明确——采取一切必要措施简化软件交付流程，并使其无缝且可重复。实质上，实施我们现在通常称之为 CD 和 DevOps 的内容。

他们首先做的就是与尽可能多的业务人员进行交谈，确保他们也意识到破碎的流程及其根本原因。简单来说，如果有人积极参与将软件从构想到消费者的决策过程，或参与支持软件上线后的工作，他们就是交谈对象。这不仅收集了有用的信息，还为团队提供了传播理念和建立志同道合网络的机会。

团队有一个愿景，一个目标，其成员热情地相信需要做的事情，并且他们有能量和动力去实现它。

在接下来的几个月里，他们将开始（包括其他事项）：

• 举办各种深入的会议，以理解并绘制端到端的产品交付流程

• 根据使用者的持续反馈，精炼和简化工具——在适用的情况下，将内部开发的解决方案替换为现成的产品

• 解决管理依赖关系和部署顺序的复杂性

• 邀请 CD 和 DevOps 领域的专家独立评估所取得的进展（或者没有进展，根据具体情况）

• 安排离线的 CD 和 DevOps 培训，并鼓励研发和运维团队成员共同参加培训（真是令人惊讶，很多 DevOps 合作都是从酒店酒吧的一次聊天开始的）

• 减少整个软件发布过程中众多的交接和决策点

• 消除障碍，使开发人员能够安全地将自己的软件部署到生产平台

• 与其他业务职能部门合作，赢得信任，并帮助他们完善和简化他们的流程

• 消除“我们和他们”态度与行为，强化基于信任的关系

• 与研发和运维团队合作，尝试不同的敏捷方法论，如看板、Scrum 和精益方法

• 公开透明地分享关于交付和进展的数据和信息，涵盖所有业务领域

• 用开发人员能够密切监控其在生产环境中运行的软件来取代复杂的性能测试需求

• 消除需要停机以发布更改的需求

• 在整个业务范围内推广，分享并推销 CD 和 DevOps 的整体愿景和价值

这绝非轻松之事，它需要决心、坚定的专注、耐心，最重要的是，需要时间来产生可量化的积极结果。然而，几个月之后，愿景和好处开始显现。如今，构建和交付软件的流程已经发生了转变，以至于代码更改可以在几分钟内构建、完全测试并部署到生产平台——而且是一天中多次进行的操作——这一切只需按下一个按钮，由进行更改的开发人员启动并监控，且完全没有停机时间，对客户几乎没有或没有影响。利益相关者拥有了一种可信赖且可靠的方式来向客户交付价值，研发团队拥有必要的工具和授权，可以按需交付价值，运维团队则拥有一个可以支持和优化的稳定可靠平台。

让我们再次回顾一下软件交付流程，看看已实现了哪些成果。

软件交付流程版本 3.0

从图表中可以看出，整个过程看起来更加健康。它不像版本 1.0 那样简单，但它高效、可靠且可重复。一些在版本 2.0 中非常必要的制衡机制被保留下来，并经过优化，以增强而非阻碍整体流程：

ACME 3.0 软件交付流程概览

这个更加优雅和顺畅的流程是一个成熟而现代的软件企业所能认同的。那些负责交付软件和支持软件的人之间的隔阂，旨在确保一定程度的控制和质量保证，但双方都能从中受益并且接受它们。

这个高效的流程解放了宝贵的研发和运维资源，让他们可以专注于自己最擅长的事情——开发和交付新的高质量功能，确保生产平台健康，令客户满意。

ACME 系统团队找回了自己的动力，正朝着更加自信和有动力的方向前进。现在，它拥有了两全其美的优势，前方没有任何阻碍。

ACME 系统版本 3.0 及之后

ACME 系统团队的成员在经历了挑战后变得更加坚韧和精简，但他们的故事并未就此结束。和任何成功的企业一样，他们不会自满，而是决定扩展到新的市场和机会——即构建并交付移动优化客户端，以便与其核心的基于 Web 的产品互补并协同工作。

在整个进化过程中，他们学到了很多，他们知道已经有了一种最佳的工作方式，可以让他们在客户需要时交付客户想要的优质产品，并且知道如何快速、可靠、渐进地交付。然而，将功能交付到托管的基于 Web 的平台的复杂性与将功能交付到终端消费者的移动设备的复杂性是不同的——它们是可比的，但并不完全相同。例如，每天多次将代码交付到生产服务器的过程由 ACME 团队控制，而他们几乎无法控制如何将移动客户端交付给最终客户，也无法控制最终客户是否会在各种应用商店发布移动客户端的情况下，何时安装最新的版本。此外，移动客户端将要安装的生产平台在规格、性能和存储方面几乎是未知的。

不过，一切并未失去——远非如此。ACME 系统团队的成员们在进化过程中学到了大量的知识，并决定像以前一样应对这一新挑战。他们知道自己可以以一致的质量构建、测试和交付软件。他们知道如何以渐进的方式交付变更，且几乎不会带来任何影响。他们知道如何支持客户，并迅速响应变化。他们知道自己的文化已经成熟，整个组织能够团结一致，克服共同的挑战。

随着新业务的进展，他们还发现了另一个副作用：他们重新点燃的成功带来了流量和交易量的快速增长。因此，他们需要扩展平台，并且必须尽快完成。与其依赖自己的数据中心，他们决定将整个平台迁移到一个全球分布的云解决方案。这带来了新的挑战：基础设施完全不同，资源配置工具是新的，用于构建和交付软件的工具与现有的 ACME 工具不兼容。同样，ACME 系统团队迎难而上，凭借高度协作的工作方式、技术和方法，继续自信地前进，这些方式、技术和方法现在已经成为他们文化的一部分。

那么，ACME 系统 1.0 版的业务能否应对这些新挑战并取得成功呢？这有可能，但结果可能会是好坏参半，风险会大得多，质量也会更低。很明显，ACME 系统 2.0 版的业务将面临重大困难，到产品进入市场时，它们可能已经过时，并且与更迅速、更精简的竞争对手争夺市场份额。

让我们从一个整体的角度来看，这一切意味着什么。

进化简述

在本章中，我们一直在跟踪 ACME 系统的演变：它们的起步，成功带来的成长烦恼，如何发现快速增长既带来负面影响也带来正面影响，如何通过采纳 CD 和 DevOps 克服差点灭绝的困境，以及如何恢复活力和信心继续前进。所有这一切可以通过以下简单的图表来表示：

ACME 系统演变概述

他们还学到了一些东西——虽然是在进化的后期——那就是 CD 和 DevOps 的采纳与技术工具无关，完全取决于人们如何协作。如果没有对参与端到端交付过程的每个人的文化和行为进行改变，几乎不可能实现并最大化成功采纳 CD 和 DevOps 所带来的好处。可以说，如果他们从一开始就知道这一简单但常常被忽视的事实，采纳就会更早发生，企业也会更早变得更强大。希望这为你在阅读本书的剩余部分时提供一些思考。

我在进化阶梯上的位置在哪里？

在本章开头，我提到采用 CD 和 DevOps 的有效性在很大程度上取决于一个企业在进化阶梯上的位置。我们已经经历了 ACME 的演变及其所经历的各个阶段。请注意，ACME 是虚构的，它的故事非常简单。现实中的企业并非如此——远非简单——要确定一个企业在 CD 和 DevOps 进化阶梯上的位置是相当困难的。如果没有这些信息，很难理解企业的接受程度、反应能力以及对采纳的开放性。

话虽如此，有一些简单的方法可以让你更清楚地了解情况。例如，以下问题列表可以帮助你大致了解。看一下你的企业，问问自己以下问题：

	选项 #1	选项 #2	选项 #3
你的业务是否更注重流程而非人员？	流程	人员	我们没有任何值得一提的流程。
项目计划中的不可移动的截止日期是否优先于逐步交付高质量解决方案？	是的，按时完成任务是唯一重要的。	我们在至少一个领域具有灵活性，可以进行小范围调整，并重新规划以确保质量不受影响。	我们会做任何必要的事情来保持客户满意。
你的项目是按照固定的时间表、固定资源和固定范围来执行，还是具有灵活性？	是的，所有这些都事先商定、签署并精心规划。	不，我们在至少一个方面具有灵活性。	我们会做任何必要的事情来保持客户满意。
	选项 #1	选项 #2	选项 #3
开发人员是否可以访问生产环境？	不，为什么我们要信任开发人员不会搞砸事情？	所有开发人员都有对实时环境的安全只读访问权限，并可以通过特定工具访问所有配置。	是的，他们可以完全访问，并做任何需要做的事情。
失败是被鄙视还是作为学习的机会？	失败就是失败，没有借口——责任人会被开除。	我们确保失败的影响最小，并从错误中学习。	失败意味着公司倒闭，我们都得失业。
谁负责处理超时的生产问题？	T1 帮助台，T2 运营支持和 T3 应用支持团队为其提供后备支持。	通常有一个联系人随时待命，可以联系任何他们需要的人。	软件工程团队中的每个成员都需要处理。
当代码准备好时，你能立即部署吗，还是需要等待预定的发布？	发布团队根据已达成的程序计划，通过 CAB 和过渡团队安排并同意将代码交付到生产环境。	我们信任工程师在确定代码准备就绪且不影响整体质量时使用我们的部署工具进行发布。	我们的工程师通常在代码编译完成后，直接通过 FTP 将代码上传到生产服务器。
高层领导是否理解交付软件的复杂性和挑战？	他们不清楚具体细节，但项目管理办公室（PMO）会编制并生成许多报告，这些报告会在项目审查会议中定期审查。	他们都有访问工具，可以看到各个项目及其进展的相关指标。	他们没有时间或兴趣去理解这些——他们只是期望事情能按时完成。
工程团队是否了解公司在商业方面的表现？	所有顶级财务信息由首席财务官编制并每 6-12 个月在公司内网发布。	他们都有访问工具，能够看到当前的 KPI 和衡量进展的指标。	他们不了解，但只要工资照发就足够了。
工程团队是否能访问客户反馈？	通常由客户服务团队收集并审核，作为缺陷或增强请求提出。	客户反馈通过专门的工具收集并对所有人开放。	是的，这通常与需要修复的缺陷和错误相关。

如果你将这些应用于 ACME 公司在其发展过程中的某些阶段，你会发现，1.0 版本的公司大多会回答第 3 个问题，2.0 版本的公司大多会回答第 1 个问题，而高度进化的版本的公司则大多会回答第 2 个问题。

上述内容仅仅是一个示例，旨在让你从一个非常宏观的角度了解如何评估企业的成熟度以及它在持续交付（CD）和 DevOps 发展过程中所处的位置。你无疑会有一些额外的、互补的或更相关的问题可以使用。然而，如果你遵循类似的格式，你将能够感知当前的情况，更重要的是，能够识别出哪些领域最需要关注。你应该尽可能多地扩大视野，从企业的各个部分获取反馈，这样，当你决定深入实践时，就不会遇到惊讶的情况。

摘要

ACME 系统的发展故事并非今天许多软件企业的典型代表。无疑，你会认出并与 ACME 旅程中描述的一些特点和挑战产生共鸣，你现在应该能够绘制出你的企业（或你客户/合作伙伴的企业）在持续交付（CD）和 DevOps 发展过程中的位置。你还全面了解了什么是 CD 和 DevOps，以及它们不是些什么。

我们现在将从讲故事的模式转变，开始更详细地探讨采纳 CD 和 DevOps 的一些实际方面，首先从如何识别那些可能（并且确实）会阻碍高质量软件交付的潜在问题开始。

在第二章《了解当前的痛点》中，我们将探讨如何识别软件交付生命周期（SDLC）中的问题和挑战，并突出一些工具、技术和方法，以便发现这些问题并加以解决。

第二章：理解你当前的痛点

在第一章《软件交付的演变》中，你被介绍了 ACME 系统，并了解了它是如何意识到软件交付过程中存在问题（严重影响了它满足客户期望并为客户创造价值的能力），以及它是如何识别并解决这些问题，进化并在经过一番努力、决心和时间后，采用了 CD 和 DevOps 的工作方式来克服这些问题的。

这个基于虚构商业的故事相当简化和线性，以便让你作为读者更容易理解。现实生活从来不会那么简单，但在讲述过程中提出了一些关键点，实际上是适用于现实企业的。对于任何考虑—或积极推进—采用 CD 和/或 DevOps 的企业来说，最重要的一点是，必须有一个明确的理由去进行这种采纳。CD 和 DevOps，像任何解决方案一样，可以帮助你解决一个问题—或一系列问题—但你需要真正理解并量化这些问题；否则，你永远无法确定这个解决方案是否有帮助。

就像 ACME 系统所做的那样，你需要花时间并付出努力，正如那个广泛使用的敏捷术语所说，在适应之前必须先进行检查。

你对这个问题的第一反应可能是，你没有任何问题，一切都运作良好，参与你软件交付过程的每个人都非常高效、积极投入，并且富有动力。如果这确实是事实，那么以下其中一项已经发生：

• 你已经达到了软件交付的理想状态，因此此时无需再继续阅读。

• 你在自我否认

• 你还没有完全理解高效且精简的软件交付应当是什么样的

更可能的是，你有一个可行的软件交付过程，但在整个过程中某些环节—可能是某些团队或个人—让事情进展缓慢。这通常不是故意的；也许有一些必须遵守的规则和规定，也许需要一些质量门槛，也许没人曾经质疑为什么某些事情必须以特定方式进行，大家都在照常做，或者也许没有人强调发布软件究竟有多重要。

需要考虑的另一点是，组织内的不同人员对同一问题的看法可能会有所不同（或根本看不到）。让我们暂时回到 ACME，看看三个人物（经理 Stan、开发者 Devina、运维人员 Oscar）在软件发布完全由运维团队控制的情况下各自的看法：

正如你所看到的，不同的人根据他们在整体流程中扮演的角色，会有截然不同的看法。为了便于理解，本示例只列出了三种角色——实际上，会有更多的人，他们各自会有稍微不同的观点；想象一下项目经理、发布经理、技术写作人员、安全运营人员，甚至是 CEO 会如何看待这一特定场景。

假设我们确实在软件发布过程中遇到了一些问题，并且想要弄清楚问题的根本原因——或者更可能是多个根本原因——以便让整个流程更加高效、有效并简化。正如之前所说，在你能够进行适应之前，你需要进行检查——这是大多数敏捷方法的基本前提。接下来的章节将展示一些有助于解决这些问题的方法和技巧。

本章中，我们将探讨以下主题：

• 如何识别软件交付流程中的潜在问题和挑战。

• 如何在不陷入指责游戏的情况下揭示问题。

• 有时候，保持诚实和开放是很困难的，但这样做能带来最好的结果。

• 你组织中的不同人将以不同的方式看待相同的问题。

在我们开始探讨如何检查之前，我想稍微偏离一下话题，聊聊一只通常是灰色的大型哺乳动物。

房间里的大象

我们其中一些人有一个非常真实且令人担忧的困扰，这个困扰影响着我们的工作生活，那就是“房间里的大象盲症”——或者用它的医学名称来讲，叫做“巨兽在位视觉障碍”。那些受到影响的人意识到有一个巨大的问题或障碍挡在他们面前，妨碍了他们的进展、效率和参与的意愿，甚至削弱了他们的士气。这些可怜的灵魂通常会怎么做呢？他们通常选择要么接受这个问题，要么更糟的是忽视它——取决于问题的大小。那些不选择视而不见的人，通常会找到巧妙的方式来绕过、规避或避免这个问题，通过对自己的工作方式进行局部的改变来应对。有时候，这会以牺牲他人为代价。事实上，他们通常会投入大量的精力、时间和金钱来建立这些巧妙的解决方案，然后说服自己和他们的领导，这样做是最好的选择。

请允许我再进一步延伸这个比喻——请耐心听我讲，这有一个重点——我想转向艺术世界。艺术家班克斯（Banksy）在他 2006 年在洛杉矶举办的“几乎合法”展览中展出了一件生动的艺术品。这件生动的艺术品是一只成年印度象，站在一个临时搭建的客厅里，墙上有花卉图案。这只大象从头到脚都被涂上了同样的花卉图案。这件作品被命名为——运气好的话——“房间里的大象”。起初这似乎荒谬，你可以清楚地看到一个重达 12,000 磅的大象站在那里；虽然它被涂成与周围环境融为一体，但它仍然是一只大象明目张胆地站在那里。这带我来谈我的观点，软件交付过程中的问题和挑战就像是这头大象，我们简直荒谬地忽视或者不加质疑地接受它们的存在。

就像现实生活中一样，软件交付过程中房间里的大象不难发现。它通常就坐/站/潜伏在每个人都能看到的地方。你只需要愿意去看，知道如何去看，以及要寻找什么。一旦掌握了这些，揭示它的存在就会更容易。

在本章的剩余部分，我们将介绍一些方法来帮助突显房间里的大象的存在，更重要的是，如何确保尽可能多的人也能看到它，并意识到它不是可以避开、绕过或忽视的东西。

在你开始从比喻性的大象身上去掉比喻性的花卉图案之前，你还需要做一些功课。

定义规则

任何检查、暴露、调查或审查都会在某种程度上需要挖掘出一些“污垢”—比喻而言。这是不可避免的，不应该轻视或对待得轻浮。将会问到的问题包括以下几个：

• 为什么事情以某种方式进行？

• 最初是谁提出了这个流程？

• 是谁做出了优先决策来做一件事而不是另一件事，他们有什么权利做出这个决定？

• 决策是何时做出的？

• 谁拥有整个产品交付过程？

• 谁拥有流程中的各个步骤？

• 之前有人质疑过这个流程吗？如果有，发生了什么？

• 是否有人真正知道这个流程是如何从头到尾运作的？

• 为什么管理层看不到显而易见的问题，为什么他们不听我们的意见？

这些问题可能会让一些人感到非常不舒服，并可能揭露出一些事实，激发情绪反应或情感反应——尤其是那些曾经参与设计和/或实施你正在审视的流程的人。即使他们能够看清并理解他们曾经培育的流程是有问题的，他们可能仍然对其有情感依赖——尤其是如果他们已经参与了很长时间。你需要意识到，这些人可能是帮助替换和/或完善流程的关键人物，所以要小心行事。

为了保持纯粹的职业水平，你应该制定一些基本规则，明确调查的目的和目标。这些规则需要简洁明了，所有参与者都能理解，并且用积极的语言表述。你需要关注以下几个方面：

• 我们试图理解现有的端到端流程是如何形成的。

• 我们需要了解有哪些商业、立法或法律上的约束。

• 我们需要了解多个不同的流程是如何相互连接，形成端到端的流程的。

• 我们需要验证我们的流程是否真正有效，是否能为我们和更广泛的业务带来好处。

• 我们希望能把问题和障碍暴露出来，让每个人都能看到，并帮助解决它们。

• 我们希望改善现状。

为了进一步确保尽量减少情绪反应，你应该制定一些规则，以便让所有参与者明白什么行为是可以接受的，什么行为可能会越过界限。再次强调，保持这些规则简单明了，并用积极的语言表述，会帮助大家理解并记住它们。好的例子可能包括以下内容：

• 不进行公开指责和羞辱。

• 不进行人身攻击或“猎巫”式的行为。

• 这不是一场死后剖析。

• 没有绝对正确或错误的答案。

• 任何细节都不应被忽视。

• 坚持事实，不凭空想象。

• 摆脱自负情绪。

回顾分析可以是一个强有力的工具，帮助你更好地理解哪些方面可以改进，但如果使用不当，它可能带来比好处更多的麻烦——如果没有远见，你可能会多次“自伤其足”。在开始这类活动之前，你需要确保自己明白将面临什么。

现在让我们考虑一下你需要与哪些人合作，以及谁能提供最大价值。希望这两者是重合的，但事情往往没有那么简单或显而易见。

包容（几乎）所有人。

你需要的是来自那些能够积极贡献、参与其中、理想情况下愿意接受变革（或者至少希望看到事情朝更好的方向发展）并理解和同意前面提到的规则的人的信息和洞察。这些积极参与者应该来自业务的各个部门——如果他们参与产品的创建和交付，他们就应该被考虑在内。你需要广泛的信息和数据来推动工作，因此，你需要让更多的参与者参与其中。

为了确保你能识别尽可能多的人，你需要在组织中建立一个良好的网络，或者至少要有访问那些已经拥有良好网络的人的途径——尤其是当你的组织规模较大时，因为不可能识别并与每个人保持联系。你通常会发现，那些在公司工作较长时间的人，往往拥有一个成熟的、良好的内部网络，你可以利用这个网络。

从事产品支持、业务分析、产品管理、销售和市场营销，或者项目管理的人员是值得寻找的对象，因为他们大部分时间都在与组织内各方建立关系和网络。

你应该主动与这些人互动，并解释你想要做的事情——记住前面提到的积极措辞的目标和互动规则——并请求他们帮助建立你的名单。如果你还能将他们添加到参与者名单中，那么事情会更快推进，因为他们可以为你做一些宣传工作和实地调研。

正如本节标题所示，尽管你有最好的意图，希望让所有参与或受软件交付过程影响的人都参与，但这在大组织中既不现实也不实用——所以如果你能让几乎所有人参与，那就足够了。

当你开始编制参与者名单时——对于一个大组织来说，这可能是相当令人畏惧、需求巨大的，并且不是没有付出努力——你无疑会发现，随着你开始邀请人们参与，会有一定程度的自然选择；一些人可能会说他们太忙，一些人可能出于不愿透露的原因不想参与，还有一些人可能根本不关心。

识别关键人物

在编制参与者名单的同时，你还应该识别出流程中的关键人物。这些关键人物一开始可能并不显而易见；然而，在你建立网络时，向不同部门的不同人询问同样的简单问题，会让你更清楚这些人有多么重要。以下是一些简单问题的例子：

• 你认为我应该邀请谁来参加？

• 如果出现问题，你通常会找谁来沟通？

• 谁知道这一切是怎么运作的？

• 通常是谁会对流程进行修改？

还有一个很大的可能性是，许多关键人物会是那些说自己太忙的人。他们忙的原因可能直接与他们所在的工作流程出问题有关，但他们没有时间停下来意识到这一点。我强烈建议你花更多时间确保那些符合这一类的关键人物能够被鼓励、哄劝并说服参与进来。例如，你需要在协调他们的空闲时间方面非常灵活——这可能意味着需要在短时间内改变计划，仅仅为了能和他们挤出 15 分钟的时间；不过，我鼓励你这样做，因为那些不投入的参与者很可能会在未来成为活跃的反对者。

如果某些人是关键人物，有时让他们知道这一点会有所帮助，因为适当的满足他们的虚荣心有时能够帮助赢得他们的支持。同时，有时也可以打出“如果你不趁这个机会把事情处理好，别人可能会接手，结果可能更糟”的牌。

你无疑也会遇到一些人，他们非常（有时过于）急于参与，仅仅因为他们有私利要图，或者需要一个讲台来宣扬个人观点。这些人并不容易被直接发现，但通过几个恰当的问题，他们的意图就会变得更加明显——尤其是当他们的回答似乎带有偏见，并且包含诸如“指责”、“责任”、“他们”或“与我无关”之类的词语和/或短语时。如果这些人希望参与，那也没问题，但你需要意识到，这类人可能会使整个过程偏离轨道——这也可能正是他们想要参与的原因之一。有一点警告：不要简单地将这些人一笔勾销，因为他们可能会提出有价值的意见，忽视他们可能会导致更多的负面情绪，并使他们成为非常活跃的反对者。然而，你应该确保这些人同意成为积极的参与者，并理解你设定的基本规则。在接下来的阶段中，你无疑需要留意他们——就像班级里的调皮孩子——以确保避免干扰和负面情绪蔓延。话虽如此，你可能会对他们为过程带来的价值感到惊讶。

太多人指挥

当你建立起参与者名单时，你可能会遇到一个积极的问题——你有太多人想要参与。从某种程度上说，这是件好事——过度报名是一个不错的问题，因为你将能够收集到更多有价值的数据——然而这也会引发一些问题——如果你不加以管理，事情可能会迅速变得混乱和嘈杂。

如果你有过多报名者，而不是从名单中删除人，你应该考虑运行多个会话。稍后我们将更详细地介绍会话的格式，但可以说它们可以非常互动，并且有很高的积极参与度。因此，我建议你尽量保持每个会话的参与人数在可控范围内，否则你将会有太多声音和意见，造成过多噪音和讨论偏离主题。你还应确保每个会话的参与者来自业务的不同部门（例如，不要连续进行开发人员会议、运营会议和项目经理会议——要进行混合），因为你需要来自广泛领域的输入。

规则经验是，每次会议参与者应该是 20-30 人——除非你是非常有经验的促进者，否则你将难以保持秩序和集中注意力。

你也将面临一个身体上的挑战，你需要同时出现在两三个地方——除非你掌握了克隆或星体投射的艺术，否则根本不可能。因此，你应该依次运行会话，而不是同时运行，这样可以给自己一个休息和整理捕获数据的间隙。如果这不可能，那么你应考虑邀请一个或多个共同促进者，他们在揭示大象方面与你拥有相同的目标、动力和激情。在此提醒一句：你们所有人在方法上必须非常一致，否则可能会使数据偏倚。

如果你最终运行了多个会话，请确保每位参与者只参加其中一个会话——尤其是那些怀有怨恨之情的人。你希望确保每个人都有平等的发言权。

实质上，前述的等同于这样：你需要吸引并包括尽可能多参与到定义、构建、测试、交付和支持组织内软件的过程中的各种人。网越广，捕获的信息和数据就越相关，可以这么说。

调查的进行方式和参与者都非常重要，确保环境设置正确以使参与者能够开放、透明，尤其是诚实是至关重要的——这也将鼓励适当的行为表现出来。稍后我们将更详细地研究行为，但现在让我们专注于前述的三个关键领域。

开放性、透明性和诚实

要真正搞清楚一个问题的根本原因，你需要尽可能多地收集与此相关的信息和数据，这样你才能集体分析并达成共识，找到最好的解决方法——你需要知道大象到底有多大，才能暴露它并将其清除。大多数高级管理人员，尤其是那些受过高等 MBA 教育的高层管理人员，通常的反应是，随即聘请一家昂贵的商业变革咨询机构，进行一场封闭式的高层调查，邀请少数从中层管理中挑选出来的人参与，最终形成一份管理报告。

尽管这种老生常谈的方法可能会提供一些信息和数据，但我认为它并不能为你或公司提供所需的答案。此外，在这些类型的调查中，环境通常是这样的，参与者会感到自己受到监视和威胁，因此他们不会感到自由去诚实地披露相关信息——以防这给他们的记录和/或职业生涯带来污点。因为这个原因，基本的人类本能会开始发挥作用，重要的细节可能被遗漏，或者更糟的是，一些信息可能会被误解，甚至被断章取义。总的来说，封闭式调查是缺乏信任、不披露、不参与、眼光狭隘和秘密的温床。

隐藏真相的秘密

如前所述，要实际获得所需的信息和参与度，你需要创建一个开放和透明的环境，让积极的行为得以蓬勃发展。在这样的环境中，信任、诚实、披露和建设性对话是被鼓励并且司空见惯的。这并不意味着你必须在一个玻璃房里工作，所有对话都在公共场合进行，每个决策都由委员会作出。所需的是完全没有秘密。

让我通过一个例子来澄清我的意思：Bernie 是一家小型但成功的软件公司的 CEO。在过去的几个月里，越来越多的客户开始抱怨破坏承诺，明显匆忙发布的且充满漏洞的版本。她还听说员工们不满意，生产力下降。她考虑了以下几点：

• 勉强承认可能有一些需要解决的问题，并指示工程副总裁挑选一支他信任的团队，列出解决方案，并在一周内向董事会呈报。副总裁将被指示不得向封闭小组以外的人透露或讨论此事。

• 委托一家外部咨询公司进行高层封闭式调查。

• 邀请每位员工参加全天的研讨会，要求大家提供开放和诚实的反馈，讲述他们每天面临的问题。然后，她将召集领导团队，一起花几周时间公开讨论所有反馈。接着将安排一次后续研讨会，诚实地讨论和辩论各种提出的问题及可行的解决方案。

我认为很容易看出两者的区别，以及哪些方法会取得成果，哪些则会失败。

这一切听起来可能过于简单，但如果没有开放、诚实和透明，大家会保持戒备，你也无法获得所需的所有事实——"事实"这个词是故意使用的。你需要一个让每个人都能畅所欲言、贡献意见的环境。你还需要考虑的一点是协作。

地点，地点，还是地点

理想情况下，你应该计划让调查（或其他活动）在同一地点进行（让每个人都在同一个物理位置），因为这有助于更多的人际互动、建立融洽关系——这对建立信任至关重要——以及在高互动性的活动中，话题的自然而流畅。

你可能需要考虑在中立的地点举行这些会议（例如，某个本地酒店的会议室或共享办公空间），这不仅能让人放松，还能让参与者从办公室和日常的干扰中集中精力。

实际上，你可能会有需要远程参与的团队或个体。他们可能在家工作，或在其他办公室，甚至在其他国家。如果是这种情况，你需要更加创造性地处理事务，确保一切尽可能无缝对接。如前所述，理想的情况是让所有需要的人都聚集在同一个地方。根据参与人数以及他们通常的物理位置，决定采取哪种最佳方法——例如，以下所示：

• 如果大部分参与者都在同一个办公室内，那么考虑将远程团队或个别成员带到他们所在地——预算允许的情况下。

• 如果大部分参与者都在远程地点，那么考虑将本地团队或个别成员带到他们那里——同样，预算允许的情况下。

• 如果以上两种方式都不可行，那么考虑使用一个可靠且高质量的视频会议解决方案（语音会议不足以支持你们的需求），并辅以实时协作软件。

如果你被迫在两个或更多地点举行会议，那么你还需要考虑时区差异带来的挑战，并提出可行的方案（即，不要指望你的波士顿团队会在东部时间 5:00 远程参加一个研讨会，仅仅因为对英国团队来说这样更方便）。这需要一些创造性的规划。

正如你所见，在你开始面对“房间里的大象”这一挑战之前，你需要做一些前期准备工作。

在本章中，你已经接触到了一些术语，比如“调查”、“揭示大象”和“回顾”。这些术语在与你的软件交付流程相关时，几乎意味着同一件事：收集关于流程从头到尾运作的数据和信息，这样你就可以找出问题，进而解决它们。接下来，我们将讨论一些收集这些信息和数据的方法，但在此之前，我们先澄清一些事情。

这全是些过于乐观的管理空话——对吧？

一些技术背景的人可能在读这一章时会想，这本书的目标读者是谁，并可能会想：“这肯定是关于软技能、人际管理的自我帮助书，不太适合我。” 在某些方面，这是非常真实的；任何一位合格的经理或领导者，至少应该知道如何应对这种活动，但你必须考虑到一个非常现实的事实——一个无效的流程对其中的人产生的影响，比那些被认为是在管理它的人更大。简单来说，如果作为一名工程师，你的工作效率、士气和工作乐趣受到一个你认为存在问题并需要改变的流程的影响，那么你有同样的权利和责任去帮助改进它，正如其他任何人一样。在我的经验中，最优秀的工程师是那些能够分析、理解并解决复杂问题的人——不管这些问题是否技术性。除此之外，在尝试找出流程中的问题时，谁比那些直接参与并受其影响的人更适合加入呢？

如果你是软件工程师、运维工程师、项目经理、构建与发布工程师、QA 工程师或任何其他参与软件交付的人，并且你被困在一个拖慢你工作效率并影响你有效完成工作的流程中，那么我强烈鼓励你参与调查并帮助揭示问题（会有很多问题，有些问题可能不像你最初想的那样显而易见）。是的，这可能让人感到害怕，是的，如果你被雇佣来分析需求、设计系统、编写代码或照看基础设施，你可能会问自己，为什么要参与这类相当于商业分析的工作。其实很简单；如果你什么都不做，可能会有人替你做，而情况可能会变得更糟。

如果你是经理或领导者，我鼓励你以身作则并参与其中。更重要的是，你应积极鼓励你团队中的所有成员参与其中——即使这意味着暂时将他们从日常工作中抽离。正如前面所提到的，他们是每天都在流程中工作的人，换句话说，他们对流程非常了解——我敢说，他们比你了解得更透彻。作为领导者，有些团队成员可能需要你的帮助，有些可能需要鼓励，有些可能需要培训或辅导，有些可能需要授权，还有些可能需要所有这些。长远来看，这一切都会是值得的。

不仅要鼓励团队成员积极参与，你还应该利用你的影响力，鼓励你的同行小组也这么做。从表面上看，这似乎很容易实现，但实际上可能会是一个挑战，特别是当其他管理者开始在你面前设置障碍时。你会面临的挑战包括以下几种：

• 说服他们这是一件值得做的好事

• 让他们同意允许许多团队成员停止日常工作几个小时，以便他们可以参与

• 让他们同意倾听并且不主导议程

• 让他们在更广泛的同行小组中开放和诚实

• 确保他们允许下属在没有报复恐惧的情况下开放和诚实地表达

• 让他们信任你

如你所想，你可能需要与公司内许多人、不同角色以及各种自尊心进行许多细腻的对话。正如我之前提到的，关于说服关键人物参与其中，你应该再次考虑利用一些简单的人类心理学来吸引他们的善良本性。尽管这不会容易，但坚持下来从长远来看是值得的。

现在这个问题已经解决了，我们可以进入有趣的部分——揭露“象”。

伟大的“象”披露

假设此时你已经克服了将人们聚集在同一地点（无论是实体还是虚拟）的所有挑战，你已获得各个管理团队的支持，商定了休息时间，并在一个中立场所设置了安全的环境。你已经几乎准备好开始“象”披露——几乎。接下来你需要做的是将所有人聚集在一起并运行工作坊，以捕捉你所需的数据。

为了让事情不那么令人生畏，可以将整个端到端的过程视为四个不同的阶段：

一个典型端到端软件交付过程的四个不同阶段

将整个过程拆分成这些较小的阶段有助于规划出你将主持的研讨会的流程和结构。例如，如果你决定进行全天的研讨会，你可以将其分解为多个阶段，每个阶段专注于一个特定的部分，最后将所有内容整合在一起。一个示例研讨会议程可能是这样的：

从这一点可以看出，这些类型的研讨会可能变成非常漫长的一天，尤其是当参与者人数较多时。因此，确保你非常有组织，并在整个过程中保持进度是至关重要的。仅仅凭借直觉是无法得到你需要的结果的。有些人可能会考虑通过取消各种休息时间来压缩总体时间，但这些休息时间非常宝贵，因为它们能帮助建立融洽的关系、放松心情，还能让参与者的大脑消化正在披露和讨论的信息。

在多个地点和/或时区安排这样的研讨会可能会非常复杂和具有挑战性，这也是为什么倾向于进行同地研讨会更为可取的原因。

这些类型的研讨会可以分两天进行，然而我建议你不要在它们之间留出太大的间隙，否则注意力会丧失，参与者，尤其是你确定的关键人物，可能会被拖入日常问题中。如果你需要将研讨会分开，我建议你安排第一天的研讨会在当天晚些时候结束，并在第二天一大早开始第二天的部分。

为了确保事情尽可能顺利进行——考虑到你将面临让每个人保持专注并按轨道推进的挑战——我建议你保持尽可能简单和显而易见的方式，不仅是为了你自己，也为了参与者。为此，你需要准备两件事情：

• 你需要任何敏捷从业者/主持人必备的工具：一些大白纸覆盖的空白墙面、大型白板、挂图、便签纸、各种颜色的笔和贴纸、一些空间、足够的零食，以及一点耐心。

• 你需要选择一种经过验证的敏捷技巧，它为研讨会本身提供了格式。

关于第二点，这是我非常希望能够提供详细说明的地方，涉及许多经过验证的技巧和练习，它们有着美妙的名字，比如 StoStaKee、海星法和帆船法，但这会形成一本完整的书籍。

在发送研讨会邀请之前，你应该确保所有相关人员了解研讨会的格式——因为你将要求他们回忆过去的经验，他们可能希望带一些事先准备的笔记，因此提前通知将有助于加快进程。

让我们从规划阶段转到执行阶段。

曝露显而易见的工具和技巧

如前所述，你可以使用许多敏捷工具和技术，然而为了节省篇幅，我将在附录 A 中提到这些有用的信息，我们将特别关注两种多年来被证明非常有效的工具；它们是时间线和价值流图。

时间线

时间线回顾技术是一种敏捷工具，用于回顾特定时间段，捕捉关键数据点和信息，帮助推动积极的变革。这些数据点通常与特定的事件/挑战相关（例如项目启动、季度评审后的预算削减，或者停电导致所有生产服务器下线），也可以揭示出常见的行为模式、沟通障碍、糟糕的规划和低效的流程。

由于你将回顾一段时间，揭示发生的事件（或者没有发生的事件，视情况而定），因此最好先缩小你将要审视的范围。根据经验，你应该考虑一个特定的大型复杂项目，或者一个商业计划，或者一个具体的发布——我相信你也会有其他的一些想法。因为你试图揭示交付过程中的问题和挑战，我建议不要选择那些已经进行得非常顺利的事情作为本阶段的回顾对象，因为你可能不会学到太多东西——这可以在以后进行回顾，以确保所做的任何改变都产生了积极的影响。不论你选择什么内容，它都应该成为工作坊的重点。

时间线回顾的格式非常简单：

• 你需要定义并达成共识确定时间线（即开始日期——结束日期），并将其水平画在一面宽墙上（或者更确切地说，画在覆盖墙面的纸上）。

• 然后，你将这一过程分解成更小的时间段（即月份或周），并在时间线上标出这些关键点。

• 接下来，要求所有参与者写下他们在这一期间内记得的重要事件，并把这些便签贴到墙上的时间线上（如果有远程成员参与，要求在场的某人作为他们的代理）。便签的数量没有限制——鼓励参与者尽可能多地添加。

• 随着时间的推移，你将开始看到类似的事件便签成群出现——你应该鼓励参与者将这些便签进行归类。这些具体的事件便签可能在时间线上出现多次，表明存在普遍性问题。

• 如果没有更多的事件便签需要添加，你应该指示小组用颜色标记这些便签（可以使用贴纸或马克笔），以表示他们对该事件的感受——绿色代表高兴，蓝色代表悲伤，红色代表愤怒。

在这些过程中，你应该积极鼓励与会者进行公开且诚实的讨论——可能会挑出具体的事件记录，提出类似“是否有更多细节需要补充？”、“还有其他人注意到这个吗？”或者“这个问题发生过不止一次吗？”这样的问题。

现在，你将看到一个高度可视化的时间线，展示了在这个时间段内发生了哪些事件，以及这些事件让人们的情感如何变化。然后，你可以引导大家进行公开且诚实的讨论，集中探讨那些引发最大情绪波动的事件。在讨论过程中，可能会提出一些解决方案来缓解这些痛点——这些方案应该记录下来以便后续使用，但此时暂时不要急于制定行动计划。

以下展示的是来自一个时间线工作坊的输出示例，代表了一个相当痛苦的项目，并且应该给你一些关于你最终应该得到什么的启示：

一个示例时间线看板

另一个经过验证并且文献丰富的技巧是价值流图绘制。

价值流图

这种精益技巧来源于——正如许多敏捷方法和工具一样——制造业，已经存在多年了。和任何精益方法论/工具/技巧一样，价值流图围绕价值与浪费的模型展开。其实，价值流图是一种将产品交付过程拆解为一系列步骤和交接点的方式；如果需要，还可以用来帮助计算效率率。整体图可以绘制出来并进行分析，以查看在流程中哪里出现了瓶颈或延误；换句话说，就是哪些步骤没有增加价值。价值流图中使用的关键指标是前置时间（例如，从原始想法开始到为业务带来实际收入的时间）。

有很多资源和参考资料可以详细说明如何绘制价值流图，如果你需要帮助，领域内也有很多专家可以提供协助。

为了有效地创建价值流图，你需要邀请来自各个业务领域的多位人员，这些人应该清楚并且最好有实践经验，了解产品交付过程中的每个阶段——通常被称为产品生命周期。如果你做了充分的准备，应该会有这些人参加工作坊。理想情况下，价值流图应该代表一个业务流程；然而，刚开始时这可能会显得过于庞大和复杂。为了简化流程，可能更有益的是选择一个最近的项目和/或发布版本，并将其拆解。

举个例子，下面我们来讲解一下 ACME 系统 2.0 版本业务提出的一个单一功能需求的流程（在他们看到曙光之前）：

每个框表示整体过程中的一个步骤。每个框内的持续时间值代表工作时间（即完成每个步骤所需的时间）。每个箭头中的持续时间值代表每个步骤之间的等待时间（即每个步骤之间的时间差）。

这只是一个非常简化的概述，但它突显了即便是最简单的需求也需要花费多少时间才能交付。这也强调了过程中的浪费有多少。每一步都有成本，每一次延迟都有成本，每一个错误都有成本。唯一真正的价值是在客户实际使用软件时才会体现。

从表面上看，生成这种类型的地图似乎非常简单，但它也可能是一个相当大的挑战。这个简化的图表是在实时的基础上，结合了来自多个不同领域的输入。过程中会有大量开放和诚实的对话与辩论，验证事实、回忆被唤起、日期和时间被核实、例子被澄清，并在各方之间达成一致，明确实际发生的事情。

如果您更倾向于使用标准的价值流映射术语和图标，您可以将便签版本转换为如下所示的形式，这同样代表了特性请求在业务中的流动：

该图表还包括了效率（其基于在流动过程中，增值时间与死时间的比例）

这一技术的最有价值输出是，您可以发现明显的浪费区域。这些是整体过程中拖慢进度并妨碍您整体交付能力的部分。有了这些信息，您现在可以集中精力解决这些问题区域，并开始寻找使其更有效率、更有价值的选项。

如前所述，您可以使用许多其他技术来提供类似的数据，其中一些将包括在附录 A 中，一些有用的信息。

摘要

在本章中，您已了解以下方面的内容：如何揭示产品交付过程中的问题（我们称之为“屋子里的大象”）、使用协作和参与式方法识别这些问题的挑战与益处，以及一些有效的工具和技巧，帮助您将问题分解为容易识别的工作块。

现在，你已经知道如何获取关于你的问题的宝贵信息和数据，并且有了一些急需采取的行动。你现在也知道如何进行检查。假设这些问题与长时间发布周期和组织之间的孤岛效应有关。既然如此，你已经有了一个非常明确的目标，这几乎可以肯定解决问题并满足整个业务的需求。现在你需要做的就是制定一个实施计划。换句话说，你现在需要适应。而这正是我们接下来很快要讨论的内容。

在我们开始之前，我想深入探讨一下 CD 和 DevOps 的人性化方面，并强调两个对采用成功或失败至关重要的领域：文化和行为。在下一章中，我们将深入探讨文化和行为如何影响 CD 和 DevOps 的采纳——无论是正面还是负面，以及为什么忽视这一点并不是一个好主意。

第三章：文化与行为是成功的基石

在第二章《理解当前的痛点》中，我们了解到，要求人们开放和诚实并不容易，除非你花时间创造一个能够支持这种行为的环境。环境必须能够让诚实披露的文化得以发生。此外，你还必须确保每个参与者都同意根据既定的灵活规则和流程行事。

我们现在将基于这段经验进行扩展，确保组织内部的环境、文化和行为设置得当，以支持—可能是—巨大的变革。我们将在本章中涵盖以下内容：

• 为什么文化如此重要

• 你的工作环境如何影响你的文化

• 文化和行为如何影响你的进步与成功

• 在草根层面鼓励创新

• 在整个组织中培养责任感

• 从工作环境中去除责怪

• 接受并从失败中学习

• 建立信任

• 以正确的方式奖励成功

• 培养“变革是好的”这一观念

• 好的公关如何帮助

在本章中，我们还将探讨这对之前介绍的三种角色意味着什么：

此外，我们还将加入一个从 IT 角度掌控全局的新角色：

• 副总裁维多利亚

需要注意的是，我绝不是人文学科的专家，也没有心理学博士学位。接下来的内容是我通过观察、经验以及与该领域专家的合作所获得的学习成果。

让我们从澄清为什么文化对成功采用持续交付（CD）和 DevOps 如此重要开始。

所有的道路通向文化

在科技行业中，有许多人—其中一些非常有影响力—认为，采用持续交付（CD）和/或 DevOps 不过是实施一些技术工具，然后对现有的繁重流程做些微调，从而可能使软件每几周/几个月发布一次。

更糟糕的是，一些人将此视为一个正当理由，以在现有组织中设立一个新的 DevOps 团队—考虑到所有因素—他们花费时间建立和实施工具和流程，这些工具和流程对成功交付高质量软件几乎没有或根本没有任何影响。

如果你认为这些观点是正确的，那么你顶多是错的，最坏的情况下可能是自欺欺人。再强调一遍，持续交付（CD）和 DevOps—简而言之—是敏捷的工作方式。DevOps 工具仅仅是工具而已。当我们说“工作方式”时，我们不仅仅是在谈论标准操作程序或人力资源政策，而是在谈论人们工作、思考和行为的默认方式。

就像任何其他高效、有效的工作方式一样，CD 和 DevOps 的效果也取决于人们所处的文化和环境，以及他们所表现出来的行为。这些都在任何变革的成功或失败中扮演着至关重要的角色：

众多道路的汇聚

当我们谈论文化时，主要指的是企业文化和组织文化，而非地理、地缘政治或社会群体文化。话虽如此，这些因素也可能对人们的行为产生一定影响，因此你应当对此保持意识。例如，如果你考虑到某种文化更加重视并尊重社会等级而非个人观点和意见，那么这些个体可能会将开放和诚实视为不自然或陌生的概念——或者至少，他们可能会对这种方式感到不舒服。这也可能导致个体仅仅因为上级要求（或指示）他们这样做而口头上接受变化——而不是因为他们个人相信这种变化。

尽管你应当关注人们的文化价值观和动机，但你不应让这些决定或定义你的方法——你应该只是顺应这些因素，在过程中加以适应。

不利于成功采用持续交付（CD）或 DevOps 的文化和环境因素包括以下几点：

• 团队之间的障碍或权力斗争

• 组织内部的孤岛现象

• 沟通不畅

• 僵化、老式的等级制度

• 深深扎根的信念，认为一贯做事的方式是最好的

• 功能失调的领导力

• 企业对变革的抗拒

• 避免从失败中学习

• 命令与控制

在这些问题普遍存在的环境中尝试实施 CD 或 DevOps，如果不解决支撑这些问题的根本文化问题，最终将导致失败。

你可能在阅读这些内容时会想到，你曾经在（或正在）一个已采用 CD 或 DevOps 的企业工作，并认为上述一些/所有点的确适用，但总体上事情似乎进展顺利。这里的关键短语是seem to be，如果你把它应用到其他日常场景中，你可能不会那么容易接受：

• 我检查了你车上的刹车，目前看起来没问题

• 我制定了一个修复方案，解决了 DDOS 缺陷，这个缺陷可能暴露 300 万活跃用户的个人信息，目前看起来效果不错。

• 我调查了报告中的薪资系统问题，目前看起来问题已得到解决

• 在过去三个季度中，我们不断失去 10%的客户群，但自从最近的组织变动和裁员以来，事情似乎有所好转

如你所见，感知可以是一种极具误导性的力量，并可能造成一种虚假的安全感。如果你将前面的例子中的seem to be替换成are，你会注意到你对这些陈述的感知方式会有很大不同。

如果你把这一规则应用到你对组织 CD 和 DevOps 采纳的思考中，你可能会发现很难像之前那样自由地应用看似（are）这个词，因为相关人员的文化和行为还没有到位。为了有效地将看似（seem to be）改为是（are），你需要一个积极和进步的文化作为工作环境。

定义文化

文化是一个非常模糊的概念，难以可视化、理解和定义。当它应用于积极和进步的文化时，这一点尤其困难；然而，下面的图表或许能帮助可视化这一概念在 CD 和 DevOps 采纳中的意义——我们将在本章的后续部分更详细地探讨这些内容：

CD 和 DevOps 所有事物的文化相互联系

在之前的图表中，你会看到文化是促进、鼓励、影响、强化和维持积极行为的核心。为了确保你的采纳成功，这些积极行为需要成为常态。有些人可能认为情况相反；然而，现实是，文化是如此核心，以至于所有为建立和维持积极行为所付出的努力、工作和良好意图，几乎可以在一夜之间被一个功能失调和有毒的文化所破坏。这并不是说你不能通过足够持续和一致的努力从外部开始工作；然而，从经验来看，我知道这可能是非常漫长、困难且脆弱的——只需要一个错误的决定或事件就能毁掉几个月的工作。最终，你需要关注文化。

换句话说，试着想象你的组织是一棵苹果树，它需要强壮健康的根来使芽和花开花——如果根（或文化）不健康，树看似存活，但永远不会结果（或产生积极行为）：

文化的树

这与 CD 和 DevOps 的采纳有什么关系呢？要真正从采纳 CD 和 DevOps 中获益，你需要让积极的行为广泛存在、得到鼓励并嵌入其中，使其成为常态。为了使这一切真正发生，你需要文化是积极的和进步的。你可能在揭示“房间里的大象”时目睹过一些积极行为的展现，因此这不应是一个陌生的概念。

那么，环境呢？再次回到园艺类比，要让健康的根（文化）生长并保持健康，你需要肥沃且富含养分的土壤（环境）。

下图展示了环境、文化和行为之间的关系——这些因素都需要对齐并保持健康，才能让 CD 和 DevOps 的采纳真正起作用：

DevOps 采纳的俄罗斯套娃

如果这听起来很熟悉，那是有原因的。在“大象暴露”过程中，你已经通过设定环境（尽管是在安全的温室条件下）播下了种子，以便让积极的行为浮现出来。即使这种文化持续的时间很短，它通常也是积极和进步的。正因如此，你成功地暴露了组织中的问题，从而证明了只要付出努力并采取一致的方法，你就能取得本来无法实现的成果。你需要做的就是培养这颗幼苗，并鼓励它成长，这可能比你想象的要困难。

就所有实际目的而言，持续交付（CD）和 DevOps 的真正成功采纳可能会带来相当大的变化，对于一些组织来说，这可能是一次革命性的变革。纵观历史，当谈到文化革命时，采纳和接受通常与普通大众或车间一线员工的共鸣更为强烈，而不是高层。在技术行业中，通常是工程师、测试人员和其他团队成员最先理解并接受 CD 和 DevOps 的理念和好处，并且最终在其采纳后受益最大。

这些都很好；然而，现实是，作出决定性改变的权力通常掌握在公司/社会阶层更高层次的那些人手中。因此，你的领导层必须清楚地理解并欣赏持续交付（CD）和 DevOps 所带来的好处，更重要的是，理解环境、文化和行为如何极大地帮助或阻碍成功的采纳。我们将在本章后面更详细地讨论这个问题。

如前所述，行为会受到环境和文化的影响，反之亦然。还有一些其他因素与此形成共生关系。关键因素是流程、沟通、工具和技术，如下图所示：

更多的 DevOps 采用“俄罗斯套娃”

让我们简要地看看每一个。

流程

正如你在“大象暴露”过程中注意到的，大多数企业遭遇的众多问题之一就是它们内部的流程——其中许多流程复杂、繁琐且根深蒂固。现在，假设在采用持续交付（CD）和 DevOps 的同时还要保留这些流程——正如你能想象的那样，这显然不是理想的做法。

为了使采用成功，你需要有精简、高效且有效的流程。它们还需要与积极的文化、环境和行为相辅相成并加以强化。例如，考虑一下一个典型的、繁重的流程，用于将单行代码的变更推送到生产环境：

一个典型的繁重流程

好吧，这可能有些夸张；然而，这并不罕见——尤其是在一些大型组织和/或严格遵循像 ITIL 这样的框架的公司中。如果你再考虑到这是代表了过程中的“理想路径”，那么可以想象，如果在各个步骤中发现了任何问题或缺陷，你将不得不经历的循环和障碍（通常意味着从头开始）。总的来说，这种过程不仅不利于 CD 和 DevOps 的采纳，也与积极的文化、环境和行为不太匹配。

现在让我们将其与典型的 CD 和 DevOps 流程进行比较，看看如何进行一次单行代码变更的交付：

简单的 CD 等效过程

再次说明，这只是一个过于简化的表示；然而，与之前的示例相比，你可以看到需要实施的过程变化。与前者相比，后者的过程不仅更加精简和优化，而且还帮助鼓励积极的行为，例如合作和责任感。

如你所想象的那样，进行这种激烈且具有影响力的变化，几乎是不可能的，除非你有一种文化和环境来支持它。

沟通

沟通是成功采纳 CD 和 DevOps 的另一个关键因素。我们将在本书后续部分更详细地讨论沟通；但是，让我们先看看它为何如此关键。

与任何变革一样，要让 CD 和 DevOps 被接受和采纳，需要大量的公关、对话、宣传、讨论以及信息和知识的分享。这将涉及大量的沟通（我所说的大量，是指非常非常多）。就像在大象暴露案例中一样，文化和环境需要确保所有参与者之间的沟通是畅通无阻的，并且应当鼓励公开交流，最重要的是要保持一致性。

就 CD 和 DevOps 采纳的传播而言，必须针对受众进行，以确保他们能理解。因此，你需要确保沟通方式能够确保所有相关人员清楚地了解 CD 和 DevOps 的含义，并以他们能够理解和关联的方式进行表达。

如前所述，可能会有一些人的社会和文化信仰并不完全符合成功采用 CD 和 DevOps 所需的开放和诚实文化及行为。因此，你需要花时间确保沟通方式能够适应这些人的需求。

工具和技术

当我们谈论工具和技术时，我们并不仅仅指技术工具，所指的其实是有助于持续交付（CD）和 DevOps 采纳的敏捷工具和技术——有时被称为工程最佳实践。如前所述，在过去十年里，许多专注于 CD 和 DevOps 的专业企业，专门提供针对 CD 和 DevOps 的技术工具（说实话，主要是 DevOps）；然而，除传统的（开发）运维领域外，外界对于这些工具的采纳并不广泛。这可能归因于掌握这些工具所需的专业知识——这是开发人员通常没有时间或兴趣去理解的。而对于开发团队偏好的工具和技术，但在运维同事中并不普遍的情况也是如此，比如采用 Scrum、严格的版本控制和先行测试开发。

一些开发工具供应商已经意识到这一点，并构建了技术工具，使得开发人员能够与所谓的 DevOps 工具无缝互动，而运维人员则能无缝使用传统上针对开发人员的工程最佳实践。必须提到的是，截止目前，这还远未成为常态。

回到环境和文化这一点，考虑这一点：即使开发人员确实有机会使用所谓的 DevOps 工具，除非环境和文化支持他们可以自由地使用这些工具（例如，他们能够通过 DevOps 管道自由地将代码变更自动推送到某个环境），否则即使拥有这些工具，他们也无法真正发挥其价值。

为了让持续交付（CD）和 DevOps 的推广取得成功，开发和运维的工作文化和环境应该支持无缝协作与互动。同时，交付软件变更所使用的工具和技术应由两方（开发和运维）共同选择并使用（例如，开发人员应知道如何使用像 Octopus Deploy 这样的工具，而运维人员应了解如何使用像 Visual Studio 这样的工具）。

在技术方面，持续交付和 DevOps 的一项巨大胜利是“配置即代码”（configuration-as-code）的方法。我们稍后会详细讨论这一点，但可以简单说，没有一个支持协作的环境和文化，这样一种具有变革性的技术很可能不会落地生根。

让我们看看我们的角色们能做些什么来帮助：

好的方法	不太好的方法
Victoria（副总裁）及她的同事们可以通过榜样带头；即使是一些简单的行为，比如展现出对环境和文化的关注，以及展示积极的行为，也会有所帮助。如果需要改变，她们可以作为执行赞助人来确保每个人都重视这些变革。	Victoria（副总裁）忽视她下属的情况（或不感兴趣），忽略寻求帮助的请求，继续展现命令与控制的文化。
Stan（经理）应被视为展示积极行为并鼓励同行群体也这样做。他可以研究一些最佳实践方法，并指导团队采纳相关的实践，抽出时间来完善他们的工作方式。	Stan（经理）既不帮助改善和强化积极行为，也没有表现出任何采纳或接受现代敏捷技术的倾向。
Devina（开发者）和 Oscar（运维人员）能够共同合作，展示积极的行为，并鼓励同事们也这样做。他们还可以鼓励同事们与经理合作，突出环境和文化方面的改进之处。	Devina（开发者）和 Oscar（运维人员）坚持分开工作，仅在需要时沟通，并尽量避免合作。

到目前为止，我们一直在看你需要的各种要素，以实现成功的 CD 和 DevOps 采纳。现在，让我们开始深入挖掘具体细节，从环境开始。

一个开放、诚实和安全的环境

除了听起来像是直接摘自管理培训手册的内容，开放、诚实和安全的环境实际上意味着什么？在 CD 和 DevOps 采纳过程中，这意味着任何参与你产品交付过程的人都愿意、被鼓励并能够公开评论和讨论想法、问题、关切和困难，而无需担心受到嘲笑或报复——尤其是来自领导层的压力。

正如你在“大象曝光”阶段所发现的，允许开放讨论和诚实评价组织内的做事方式和产品交付过程，会让那些本可能被忽视或隐藏的细节和事实浮出水面。你需要坚持营造一种文化和行为中没有秘密的环境，并保持这种环境的持续存在。

如果在“大象曝光”和采纳之间存在时间延迟，那么你将需要做更多工作来重新激发最初的热情，因为大多数人可能已经回到了他们的日常工作和工作方式。因此，你应该认真考虑将时间延迟保持到最小。

表面上看，这一切听起来像常识，但不幸的是，这种工作方式在某些工作环境中并不被鼓励，甚至在一些情况下是被积极阻止的——特别是在企业环境中。如果你发现自己处于这种情况，那么你需要克服一些额外的挑战，因为这些规定通常是通过人力资源和管理指南定义和执行的，而这些指南又定义了企业运作的政策。因此，你不能随意破坏或弯曲这些规则。我们将在本书的后续部分详细讨论这一点，但可以简单说，你需要非常小心，并确保以身作则，展示积极的行为。

让我们更详细地分析这些概念。

开放性和诚实

开放性和诚实是确保持续交付（CD）和 DevOps 实施成功的关键因素。如果没有这些行为，要打破障碍并在组织内实施亟需的变革将变得非常困难。在“象征性披露”阶段，你已经让大多数业务部门参与进来，收集了关于当前情况的真实反馈。现在，你需要确保继续与所有相关方保持对话。所有参与产品交付过程的人，从开发人员和测试人员，到变更和发布管理者，再到产品负责人和高级经理，都必须有一个可以分享他们的想法、建议、观察、担忧和新闻的论坛。

实现这一点的最有效方法，正如之前所述，是通过面对面的互动，无论是亲自面对面还是通过视频会议系统进行虚拟交流（记住，视频优于语音，因为视频可以提供更多的人际互动）。这种方法有一个潜在的缺点——让每个人在同一时间出现在同一个地方可能会很困难。稍后我们会看看一些克服物理环境挑战的方法；如果面对面交流大多数时候不可行，可以考虑使用丰富且成熟的协作工具市场，如 Slack、Flowdock、Yammer 或 MsTeams（仅列举其中几个），这些工具可以为你提供实时的人际互动。

在考虑这类协作工具时——因为大多数工具是基于公共互联网托管的平台即服务（PaaS）或软件即服务（SaaS）——需要注意的是它们的使用是否符合你公司内部的 IT 安全政策。你应该与安全运营团队（SecOps）合作，如果可能，争取他们参与实施，从而扩展持续交付（CD）和 DevOps 的方式及社区。

尽管长期以来有一种看法认为电子邮件是一个有效的协作工具，但它并不应该被视为如此。

无论你选择哪种方法，建议你设置某种形式的礼仪或指导方针，以便每个人都知道什么是可接受的，什么是不可接受的。通常情况下，常识会占主导地位；然而，开放性和诚实也伴随着责任和成熟——有些人可能会忘记这一点，因此温和的提醒总是有帮助的。相反，应该避免的是对内容进行过度的监管或审查，因为这会积极地阻碍开放性和诚实，最终使解决方案失去意义。你应该审查现有的政策，并与人力资源团队合作，看看他们是否能提供帮助。

回到开放性和诚实的主题，我们来看看这在之前提到的角色中意味着什么：

良好的方法	不太好的方法
Victoria（副总裁）应该在合理范围内与她的部门开放分享计划和信息（最好是面对面或通过网络研讨会），并公开征求反馈。	Victoria（副总裁）不愿与部门沟通，所有计划和信息都保持隐藏，直到最后一刻才通过匿名邮件发送。
Stan（经理）应该定期并开放地与团队分享计划和信息（在合理范围内），并征求反馈。如果实施了协作工具，Stan 和他的同行应该积极使用这些工具，并鼓励他们的团队也这样做。	Stan（经理）模仿 Victoria 的行为，保持计划和信息的保密，直到最后一刻才通过匿名邮件发送。
Devina（开发者）和 Oscar（运维人员）尽可能主动进行面对面的沟通——无论是面对面还是通过视频会议——而不是仅仅在出现问题时沟通。使用协作工具而非电子邮件应该是常态，他们也应该鼓励他们的同行采取同样的做法。	Devina（开发者）和 Oscar（运维人员）继续各自为政，仅在出现问题时进行沟通——通常通过电子邮件。信息的共享仅限于需要知道的人。

如你所见，容易陷入并不那么理想的方法；然而，保持在理想路径上所需要的额外努力将带来更多好处，因为这将鼓励开放和诚实的对话。

要求并鼓励他人保持开放和诚实是非常好的，但你也应该以身作则。在实施持续交付（CD）和 DevOps 的过程中，定期获得各方关于实施中有效的部分以及更重要的无效部分的开放、诚实和真实的反馈极为重要。同样，最简单且最有效的方式是面对面的交流；只需走到人群中询问。如果这完全不可行，你可以考虑一些轻量级的调查解决方案（例如 Survey Monkey 或类似工具）来收集反馈。这里的“轻量级”很重要，因为如果调查每几周就要求填写 10 页的问卷，没有人会定期提供反馈。

如果你采用或使用敏捷方法论并定期进行回顾会议，请要求主持这些会议的人转发与你的实施相关的任何反馈，或者更好的是，亲自参加会议并进行观察。

希望你已经对什么是开放和诚实的对话有了初步的了解，但还有另一件非常重要的事情需要你关注：勇敢的对话。接下来让我们回顾一下它是什么，为什么它很重要，以及它如何融入到整个过程当中。

勇敢的对话

有时候，处于较低职位的人会对上级如何帮助或阻碍产品交付过程有看法或观点。

您可能还会遇到那些观点与企业某些部分，甚至是某些团队或个人相冲突的人。要在这种情况下发声，需要勇气和胆量，尤其是在企业环境中。如果我们诚实地说，大多数人都会因为害怕某种形式的报复而回避这种做法。

为了让这些人敢于发声，他们需要确信自己所说的内容（当然在合理范围内）不会被视为个人记录上的污点，也不会以其他方式对他们产生负面影响。为此，您可以考虑建立一个对话非军事化区（简称 DDMZ），在这个区域内，他们可以自由地分享自己的想法、观点和意见——也就是说，能够指出“皇帝的新装”。

您应该与领导团队和人力资源部门合作，确保有一个平台供这种非常重要且有价值的对话存在。内容可能不会很有启发性，但如果有不少人都在说同样的话，那么很可能有一些问题需要解决。

如果建立 DDMZ 不可行，至少您应该考虑实施某种形式的宽恕政策，或者收集匿名反馈的途径——像是一个简单的意见箱或在线调查就足够了。需要注意的是，随着文化和环境的成熟，这类措施的需求应当逐渐减少。

在勇敢对话的过程中，另一个重要的考虑因素是那些安静的人。让我详细说明一下：一般来说，个性特征大致分为两种类型：内向型和外向型。

这只是一个非常笼统且过于简化的说法——实际上，有许多不同的个性特征——不过，为了简化，我们就按照这两种类型来讨论。

外向型的人不怕与人互动、交谈并公开讨论自己的观点和感受。对于外向型的人来说，开放、诚实且勇敢的对话通常不是他们会回避的事情。而内向型的人，在面对冲突（无论是潜在的还是实际的）时，往往会选择闭口不言，或者随波逐流。因此，您需要特别留意这一点，确保每个人都有机会参与并表达自己的观点。虽然这看起来是额外的工作，但从经验来看，内向型人的贡献通常都经过深思熟虑并且富有启发性，值得投入。

如果您难以区分这两种类型，以下是一个简单的小贴士：外向型的人通过交谈来激活大脑，而内向型的人则是通过大脑来激活嘴巴。

让我们非常坦诚、开放且勇敢地谈论将这些行为融入正常工作方式的难易程度：这并不容易。它将充满挑战、复杂、耗时，并且有时非常令人沮丧。然而，如果你坚持下去，并且事情开始奏效（它们会奏效的），你会发现这是一种非常有效的工作方式。一旦开放和诚实被嵌入到正常的工作方式中，事情就会真正开始步入正轨。

让我们总结一下到目前为止我们所讨论的内容：

做	不做

|

• 允许自由表达

• 鼓励任何人发表意见（在合理范围内）

• 对于安静的人要有耐心，因为他们可能需要更长时间才能敞开心扉

• 确保管理层和人力资源理解为什么开放和诚实至关重要

• 让管理层积极参与并以身作则

• 没有秘密

|

• 拥有封闭和保密的环境与文化

• 忽视或轻视他人的意见和看法

• 以负面或不正当的方式使用开放和诚实的反馈

• 不耐烦

• 忽视“做我说的，而不是我做的”态度

|

让我们看看我们的角色可以做些什么来帮助：

好方法	不太好的方法
Victoria（副总裁）正式支持创建 DDMZ，并鼓励她的部门在对他们来说重要的领域内进行开放（在合理范围内）沟通。她还与人力资源同事合作，确保根据反馈采取行动。	Victoria（副总裁）将开放和诚实的沟通视为发现并针对应从组织中移除的麻烦制造者的一种方式。
Stan（经理）应该强化 Victoria 的讯息和行动，并以身作则。当他从团队中收到保密的反馈时，应该确保其保密性。	Stan（经理）只是口头上回应任何反馈，并继续采取有利于自己职业发展的行为。
Devina（开发者）和 Oscar（运维人员）抓住机会与彼此、同事以及经理进行开放和诚实的沟通。当调查问卷发出以便获取开放和诚实的反馈时，他们会花时间填写并提供真实的信息。	Devina（开发者）和 Oscar（运维人员）害怕表达真实想法，担心会对职业发展产生负面影响。

可能不那么明显的是，物理环境是一个因素，它可能会在鼓励开放和诚实的对话及行为时引发更多问题。我们现在来看一看这个问题。

物理环境

你们中的一些人可能很幸运，能够在宽敞、通风的开放式办公室中工作，那里有很多机会可以四处走动、聊天，并且能直接看到与你合作的人的身影。现实情况是，大多数人并不那么幸运，团队被办公墙、楼梯、可怕的隔间，甚至时区所隔开。在这种情况下，我们假设办公室空间并非开放式，且存在一些物理障碍。

你可以考虑以下几种方法来消除这些障碍：

• 保持办公室的门敞开，或者如果可能的话，完全移除它们。

• 为集体聚会预留一个区域（通常靠近咖啡机），提供舒适的座椅，如沙发或豆袋椅，供大家放松聊天。

• 定期举行聚会（至少每周一次），让大家聚在一起（通常会在咖啡和免费的甜甜圈、蛋糕、饼干、糕点或任何能吸引大家离开工作桌的美食附近），聊聊天，放松一下。

• 配备一台桌上足球或乒乓球桌；你会惊讶于办公室里通过友好的竞争能够打破多少隔阂。

• 如果你使用的是敏捷（scrum）方法论，且各个团队被隔离在不同的办公室内，每个团队私下举行日常站立会议，那就举行一个“全体站立会议”（scrum of scrums），让每个团队派一人参加。更好的方法是，打破常规，安排各个 scrum 团队的成员参加其他团队的站立会议。

• 让团队在常规工作区域之外举行日常站立会议。

• 查看是否可以移除一些隔断墙。

• 如果你有隔间，那就把它们全部移除。我个人认为这些隔间是魔鬼的产物，它们比实体墙分隔团队更容易制造负面氛围。

• 查看是否可以调整办公室布局，让团队之间更紧密地合作，或者至少做一些调整，增加混合。

• 在可能的情况下，用笔记本电脑替换台式电脑——如果你可以携带工作站而不需要推车移动，那么你就能更容易地坐在与之合作的人旁边。

• 不要再依赖电子邮件进行沟通，鼓励大家面对面交流——进行讨论、达成共识，并在需要时通过电子邮件跟进。

这些当然仅仅是根据我在不同组织中的经验，以及对你们工作环境的广泛假设提出的建议。你们无疑会有更好的想法。最终目标是消除这些可能会抑制持续集成（CD）和开发运维（DevOps）成功采用的障碍，无论这些障碍是虚拟的还是物理的。

让我们看看我们的角色能做些什么来帮助：

好的方法	不太好的方法
Victoria（副总裁）倾听下属的意见，并与她的同级高层领导合作，帮助推动对物理环境所需的任何变更——如有需要，确保预算到位。	Victoria（副总裁）从她那间奢华的办公室望出去，建议大家停止抱怨，专心工作，同时为她所计划增加的开发人员订购新的隔间。
Stan（经理）在同事群体中工作，努力说服上级改变物理环境。他单独尝试此事时，尤其是在需要花费资金的情况下，可能会面临挑战，因此，拥有多个管理者的声音支持同一观点会增加说服力。他还考虑花时间与他的团队一起在办公室空间中工作——每周几小时可能就足够了。	Stan（经理）从他那间略逊一筹的办公室望出去，订购了一些百叶窗，这样他就不必再看着那些挤在办公室里的团队了。
Devina（开发人员）和 Oscar（运维人员）一起合作进行小范围的变更并进行实验，例如，通过面对面讨论而不是通过电子邮件进行沟通，或是接管办公室的某个区域，大家一起坐在一起。	Devina（开发人员）和 Oscar（运维人员）坚持继续在办公室的不同区域工作，通过电子邮件沟通，并且不向他们的领导团队提及工作环境的情况。

接下来，我们将从看似简单的开放性和诚实话题转向看似简单的协作领域。

鼓励并拥抱协作

当你开始采用 CD 和 DevOps 的旅程时，你无疑会假设所有参与者都希望合作并共同努力。

业务中有很大一部分积极参与了“大象暴露”练习，旨在捕捉并突出现有业务流程和工作方式的不足，并以一种非常协作的方式进行。肯定他们会希望继续沿着这条路前进吧？

起初，这可能是真的——前提是没有发生前述的延迟；然而，随着时间的推移，人们会开始回到他们自然的孤立位置。这一点在 CD 和 DevOps 采用活动停滞时尤其明显——你可能忙于构建/实施技术工具，或将注意力集中在现有流程中最痛苦的某些领域。无论如何，如果你不小心，旧习惯将悄悄回归。

因此，重要的是你要让协作工作方式始终处于人们的心中，并鼓励每个人将这些方式作为默认的工作模式。挑战在于让所有相关人员做出一个简单的决定。本质上，你需要让人们相信并感受到，协作工作比不协作工作更容易。当人们相信并感受到这一点时，它就会变得习惯化并成为常态。

幸运的是，有许多经过验证的方法可以促进协作，但无论你选择哪一种，你需要保持简单轻便，确保你鼓励的人不会觉得这种工作方式是强加给他们的；一些反向心理学的方法，让他们觉得这是他们自己的主意，会有帮助。以下是一些简单的例子：

• 鼓励每个人在无法面对面交流时，优先使用你的在线协作论坛/消息/聊天工具，而不是电子邮件——一开始甚至可以通过排行榜和奖励来激励大家的使用。

• 如果通常问题是在每周的部门会议上讨论，而不是在某人桌前进行五分钟的讨论，那么取消部门会议，鼓励大家站起来走动并交流（或者使用上述协作工具）。

• 如果办公室里的常态是大家戴着耳机低头工作（这会鼓励孤立并压制传统的人际沟通），寻找方法改变这一行为，使其不再成为常态。如果人们喜欢在工作时听音乐，可以考虑一些极端的做法，比如设置点唱机或者联网的扬声器。你也可以考虑设定耳机和低头工作的使用时间（例如，仅限于下午）。此外，如果人们需要安静的时间/空间，看看你是否可以改变物理环境以适应这一需求。

• 即使你没有采用 Scrum 方法论，也可以在团队中普遍使用每日站会的形式——你甚至可以在不同团队之间切换站会地点，鼓励大家参加并倾听。

• 在办公室空间内安装一些磁性白板，鼓励大家站起来、混合交流，展现创意，无论是解决问题、展示进展，还是仅仅为了乐趣或涂鸦。如果你已经设置了一个共享的休息区，也可以在那安装一个白板——这将鼓励更多的合作。

• 确保你与所有团队保持交流并开展开放式讨论——你永远不知道，你可能会听到别人也在讨论的内容，而你可以充当 CD 和 DevOps 之间的媒人。

一旦协作开始落实，你必须继续保持敏锐的观察力和倾听力，确保能提前发现事情回退的迹象。如果你已经建立了一个志同道合的网络，确保利用它来了解现场的情况，并在听到孤岛式工作重新抬头时，及时采取行动。

你还应该注意到，协作也可能会受到物理环境的影响——无论是正面还是负面。例如，如果团队分布在不同的建筑物或同一建筑的不同楼层，协作可能会受到严重阻碍。某些前面提到的技巧可能无法完全实现/可行——尤其是当需要紧密的物理接近时——然而，鼓励创意使用技术协作工具来填补这些空白是必要的。

让我们再次看看我们的角色可以做些什么来帮助：

• 协作并非工程师的专属领域。经理和高级领导也可以并且应该进行协作——更重要的是，应该让大家看到他们在协作。斯坦（经理）可以使用一些前面提到的技巧和技术协作工具。

• 说实话，大多数高级领导通常不会在日常工作中考虑使用上述的协作技巧和工具；然而，维多利亚（副总裁）至少应该理解它们，并在她的同龄人中积极推广。为技术工具的费用做预算也会有所帮助。

• 德维娜（开发人员）和奥斯卡（运维人员）应该身体力行，进行推广，并在协作时保持高度可见（理想情况下是在团队/办公室区域内，而不是躲在会议室里）。即使是一些简单的事情，比如鼓励开发人员和运维工程师在周五午餐时间一起去同一家酒吧，也能产生影响。

随着协作逐渐嵌入组织，你会看到许多变化开始发生。起初，这些变化可能很微妙，但如果你仔细观察，很快就会发现：人们在桌前的日常对话增多了，在线聊天室里出现更多类似“我正在尝试解决一个问题，但不确定最佳解决方案，有人愿意一起喝咖啡讨论一下吗？”的内容，背景噪音也增多了，大家分享当天的笑话。

一些微妙的（或有时不那么微妙的）公关手段可能会有所帮助，例如，办公室周围的海报、咖啡杯，甚至是奖励最具协作精神的团队；任何能够让协作始终保持在视野中的方式。

现在我们先不讨论协作，转而关注创新和问责制。

在基层层面促进创新和问责制

如果你幸运地在一个以现代技术为基础的企业工作（或曾经工作过），你应该已经习惯于将创新作为产品待办事项和整体路线图中的一个重要且被重视的输入。创新在实施持续交付（CD）和 DevOps 时非常强大，尤其当这种创新来自基层时。

许多世界上最成功和最常用的产品都源于创新，因此你应该帮助在整个业务中建立一种文化，使创新被视为一种积极且值得的事情，而不是推动产品的冒险方式。大多数工程师在创新中茁壮成长，或者至少享受创新，说实话，这很可能是他们选择成为工程师的主要驱动力之一——这和美酒、跑车以及国际化的快节奏生活方式（好吧，这可能有点夸张）有关。

这并不是说他们可以随心所欲地做任何事；仍然需要交付和支持产品。你需要做的是留出一些空间进行调查和实验——重新点燃研发中的“R”。创新不仅仅存在于软件领域；可能会出现不同的工作方式或产品交付方法，你可以并且应该考虑这些方法。

创新不仅仅局限于产品和工具；敏捷技术，如测试驱动开发（TDD）、Scrum、XP 和看板，最初都作为创新的想法出现，随后得到了更广泛的采用。

尽管通常的惯例是，创新不是解决方案和系统架构师的专有权；每个人都应该有机会进行创新并贡献新的想法和概念。鼓励这种活动的方法有很多（比如比赛、研讨会等），但你需要保持简单，以确保在业务范围内得到广泛的覆盖。一个简单的想法是定期举办创新论坛或聚会，允许每个人提出并在可能的情况下，原型化某个想法或概念。

创新可能增加风险，新的事物总是这样；因此，工程团队必须理解，他们在做决策和选择时所获得的自由，伴随着责任、所有权和对新事物的问责，无论是他们提出的、生产的还是实现的。他们不能仅仅实现一些闪亮的新玩具、工具、流程和软件，然后把这些交给其他人去支持。别人的问题（SEP）或“甩锅”式的方法将不再奏效。

一个好的例子是 ACME 系统计划允许开发者直接将代码部署到生产环境。从表面看，这正是持续交付（CD）和 DevOps 的核心内容，但一个简单的问题使得这个计划未能实现。这个问题是，谁来负责接听寻呼机？或者，用 21 世纪的语言来说，开发者在非工作时间出现问题时是否需要随时待命？最终，你需要确保所有参与交付和支持软件的人员都拥有相同的强烈责任感，这样就不必再提出这个问题。

那么，如何在你的组织中灌输这些价值观和行为呢？让我们看看我们的角色能做些什么来帮助：

好的方法	不太好的方法
Victoria（副总裁）应该花时间调查和审查创新如何改变成功企业的运作方式，并增加收入和利润。	Victoria（副总裁）忽视了创新在现代企业中的重要性，坚持按照旧的方式执行，仅仅满足于交付规范，别无他求。
Stan（经理）应该积极为团队成员留出时间进行尝试或实验，不论是通过预留一些象征性的 10%时间，还是简单地鼓励他们提出自己的想法和建议，以推动产品或生产力的进步。	Stan（经理）忽视了创新的重要性，强迫他的团队把产品功能的交付放在一切之上。
Devina（开发人员）和 Oscar（运维人员）应该积极推动这一议程，作为与经理进行一对一或团队会议讨论的一部分。为了推动进展，利用一些空闲时间思考一个创意并呈现出来，可能是一个不错的做法，因为这表明了承诺并且证明你是认真的。合作工作也会增加其可信度。	Devina（开发人员）和 Oscar（运维人员）应该低调行事，按要求去做，哪怕这与现代工程最佳实践背道而驰。

随着你们对持续交付（CD）和 DevOps 的采用逐渐成熟，你会发现创新和问责将成为常态，因为工程团队（包括软件和运维团队）将有更多的精力去专注于以新的方式做事，并改善他们为企业提供的解决方案。这不仅仅与新鲜和闪亮的东西有关；你会发现，团队会重新投入精力去解决旧的技术债务，以完善和推动整体平台的发展。

不管你信不信，有时候事情会出错。我们现在来看看那些不顺利的事情应该如何处理，以及为什么责备文化不是一种好的文化。

责备游戏

鼓励快速失败的工作方式是良好敏捷工程实践的关键元素；说起来容易，但这必须成为你们公司工作方式的一部分——正如他们所说，行动胜于言辞。例如，如果我们有一位经理认为在事情出错时指责和孤立个别人是一个好的激励技巧，那么要创造一个员工愿意主动尝试新事物的环境就会非常困难。责备文化很快就会破坏所有的努力，摧毁那些培养开放、诚实、合作、创新和问责文化的工作。

理想情况下，你应该拥有一个这样的工作环境：当错误发生时（我们毕竟是人，错误是难免的），与其让个人遭受来自上级的猛烈指责，不如鼓励他们从错误中学习，采取措施确保错误不再发生，并继续前进。不需要大张旗鼓的演出。更重要的是，他们应该积极被鼓励与他人分享自己的经验和发现，从而加强我们到目前为止提到的其他积极的工作方式。

缓慢责备，快速学习

在商业环境中，这可能听起来很奇怪，甚至被视为传达错误的信息（例如，可能看起来你在忽视或鼓励失败），但如果能够从错误中学习，而且问题能够迅速在公开场合得到解决，那么勤奋和质量的文化将会得到鼓励。指责那些迅速修正问题的个人并不利于良好的工作方式。虽然有人可能认为表扬他们发现并解决问题是错误的，但这确实加强了良好的行为。

以下插图展示了缓慢责备、快速学习文化的潜在影响：

随着责备的减少，学习将得到增长，因为人们不再觉得必须时刻回顾过去，而只能局限于他们知道的或被告知要做的事情。

如果管理者不再过于关注琐碎问题，他们可以专注于那些制造问题但不解决问题或不承担责任的个人。

正如你所理解的，这种文化变化对一些人来说并不容易，尤其是那些已经建立起“怒吼大王”形象的管理者。有时候他们会适应，其他时候他们可能只是站到进步的旁边——因为浪潮正在获得动力。他们别无选择，只能做出适应或放手的决定。

让我们再总结一下：

应做的	不应做的
接受意外会发生	指责他人
鼓励快速失败、快速学习的文化	批评个人的失败
鼓励责任感	在了解所有事实之前指责他人
鼓励公开诚实地分享所学的经验教训	阻碍进展
不把问题看得太严重
聚焦于没有表现出良好行为的个人

去除工程师工作生活中的威胁和责备文化意味着他们将更加投入，更愿意对错误保持开放和诚实的态度，也更可能迅速修复出现的问题。

让我们看看我们的角色如何帮助：

良好做法	不太好的做法
Victoria（副总裁）积极推动无责备文化，将错误视为单纯的错误，只要人们能够主动从中学习。她的语言和沟通风格也反映了这一点。	Victoria（副总裁）将错误视为一种纪律处分，给她的部门灌输一种恐惧感，认为每当出现问题时，责任人一定会被找出。
Stan（经理）确保在发生因知识/技能差距导致的错误时，团队有时间进行学习和培训。他的语言和处理问题的方式开放，并避免使用责备这一词汇。	Stan（经理）与 Victoria 的做法相一致并表示赞同。为了强调这一点，他会指出问题并确保责任人被识别并被点名。
Devina（开发人员）和 Oscar（运营人员）不怕承认他们在共同的知识/技能上存在差距，并将这一点向他们的经理们指出。当发生错误时，他们会坦诚自己在其中的责任，并积极参与学习如何避免再次发生。	Devina（开发人员）和 Oscar（运营人员）努力与发现的问题保持距离，按指示行事，而不是利用他们的技能和经验寻找创造性解决问题的方法——这可能会带来风险。

当然，要让这一切有效运作，所有方面都需要有大量的信任。

在组织边界之间建立基于信任的关系

现在，我必须坦诚地承认，这听起来确实像是直接取自人力资源或管理培训手册的内容；然而，信任是一种非常强大的东西。我们都明白它是什么以及它能为我们带来什么好处。我们也明白，当完全缺乏信任时，事情会变得多么困难。如果你与某人有个人关系，并且信任他们，那么这段关系往往会是开放、诚实的，并且是长久且富有成果的。建立信任是非常困难的；你不能仅仅因为被告知要信任某个同事就去信任他——生活不是这样的。信任是通过人们的行为逐渐积累的。在工作环境中建立信任也是一件非常难的事。造成这种困难的原因有很多（不安全感、野心、声誉、性格等），所以你需要小心行事。同时，你也需要有耐心，因为这不会一蹴而就。

在传统的开发和运营团队之间建立信任可能更加困难。这两个部门之间通常存在一定程度的、潜在的不信任：

• 开发人员不相信运营团队了解平台的实际运作方式，也不相信他们能够有效地调查出现的问题

• 运营团队不相信开发人员不会因为实施不合格的代码而导致整个平台崩溃

这种程度的不信任可能根深蒂固，并且在双方的业务中表现得非常明显。这些态度、行为及其所创造的文化都过于消极。要在不玩弄谁做什么、谁不做什么的愚蠢游戏的情况下，开发、交付并稳定软件已经够难了。如果你处于这样的环境中，业务需要成熟起来，按其应有的方式行事。没有什么灵丹妙药能够在两个或更多阵营之间建立良好的基于信任的关系；然而，以下技术已经证明是有效的：

• 如果你安排了某些外部的 CD 或 DevOps 培训，确保邀请到软件和运营工程师参加，并确保他们住在同一家酒店。你会惊讶地发现，有多少合作关系是从酒店酒吧开始的。

• 如果有你正在考虑参加的研讨会或会议（例如，DevOpsDays），确保有 Dev 和 Ops 的混合人员参加，并安排住在同一家酒店。

• 如果你是经理，要非常注意自己做出的承诺和/或保证，并确保要么履行承诺，要么非常公开、诚实地说明为什么没有做到/做不到。如果你是工程师，也要采取完全相同的做法。

• 如果你已经建立了一个创新论坛（如前所述），鼓励各方参与并贡献意见。

• 避免讨论“我们”和“他们”之间的分歧及其相关行为。

• 如果可行，尝试组织软件和运营工程团队之间的工作交换或借调（例如，安排一名软件工程师在运营部门工作一个月，反之亦然）。这也可以包括管理岗位。

让我们看看我们的角色可以做些什么来帮助：

好的方法	不太好的方法
Victoria（副总裁）鼓励她的管理团队（Stan 和他在 Ops 团队中的对口人员）紧密合作，更重要的是，要让大家看到他们在紧密合作。她还批准了跨团队活动、培训和团队建设活动的预算。	Victoria（副总裁）忽视了 Dev 团队和 Ops 团队（及其管理层）之间的裂痕，维持了 Dev 和 Ops 在工作方式和优先级上的严格分离。她还拒绝为联合活动、培训和团队建设活动提供资金，并鼓励公开冲突。
Stan（经理）被认为与 Ops 团队的对口人员进行合作，并鼓励他的团队忽略组织边界来完成工作。他还鼓励团队在社交场合中与 Ops 团队混合。	Stan（经理）主动忽视或避免与 Ops 团队的对口人员进行合作，并坚持要求他的团队留在组织边界内。与 Ops 团队的交往被视为不可接受，敌意成为常态。
Devina（开发人员）和 Oscar（运维人员）忽视工作中的组织和层级界限，简单地合作解决问题，模仿他们领导层的行动。	Devina（开发人员）和 Oscar（运维人员）模仿他们领导层的行动，并避免任何跨团队协作的机会。

接下来我们将从信任谈到奖励与激励。

奖励良好的行为和成功

我们中有多少人曾经参与过或在一家企业中工作过，企业会在发布后举办一场盛大的庆祝派对，庆祝你们战胜重重困难，成功地将产品发布出去？表面上看，这似乎是良好的商业实践和管理 101 课程的内容；毕竟，大多数项目经理都经过培训，会在项目计划中安排一个项目结束派对的任务和预算。如果一切按时交付并且质量最高，这并不是什么坏事。我们来尝试重新表述一下这个问题。

我们中有多少人曾经参与过或在一家企业中工作过，企业会在发布后举办一场盛大的庆祝派对，庆祝你们战胜重重困难，成功地交付了大部分需求，而且在他们试图解决测试中未发现的 bug 时，只将生产平台下线了三小时？

如果问题的答案是很多人，但这确实是一次艰难的努力，我们也确实为此付出了努力，那么你就是在愚弄自己。奖励这种行为是 100%错误的。那些快速交付客户所需的企业，才是成功的企业。

如果你想成为一家成功的企业，你需要停止传递错误的信息。我们确实说过，只要你能迅速从失败中学习，失败是可以接受的；然而，我们并没有提到应该奖励那些未能按时交付的失败。你应该奖励那些按时（或提前）交付所需工作的每一个人。这里的每个人非常重要，因为奖励不应该针对某一个个人，因为这可能带来更多麻烦。你希望培养一种协作精神和 DevOps 的工作方式，因此奖励应该是团队奖励，例如举办一个聚会或组织一次集体出游。

那些少数几个人

好吧，也许会有少数人在困难时刻投入更多努力，奖励这些个人并不是坏事；然而，这不应成为常态。如果工程团队（无论是软件团队还是运维团队）不断被要求加班加点、熬夜工作，甚至周末也不休息，那么工作优先级肯定存在问题。然而，如果他们决定付出额外努力，解决一些长期积压的技术债务，或者实施一些节省劳力的工具来加快进度，那么这完全不同，你应该针对这些具体的优秀行为进行特别奖励。

最终，你希望奖励那些做出超出职责范围、表现出色的个人或团队，而不是仅仅因为成功发布了软件。随着 CD 和 DevOps 工作方式的深入，你会发现你不再拥有以前所谓的“发布”（因为它们发生得太快，难以察觉每一次），因此，你需要寻找其他方式来给予奖励。例如，你可以在达成业务里程碑时举行庆祝派对（例如，当你迎来下一个百万客户时），当新产品成功上线时，或者仅仅因为外面阳光明媚，老板们想表达感谢之情。

CD 和 DevOps 将改变业务运作方式，所有领域都需要认识到这一事实。因此，你奖励员工的方式也需要发生变化，以培养之前提到的良好行为（开放和诚实、创新、责任等）。这对一些企业来说可能是一个巨大的转变，有些甚至可能需要实施新的奖励系统、解决方案或流程来适应这种变化。

一种标准的奖励员工的方式是通过某种奖金或激励机制。这也需要改变，但首先你需要认识到现有的系统可能助长了错误的行为，并可能抑制你实施 CD 和 DevOps 的进程。

认识到 Dev 和 Ops 团队的激励机制如何影响决策，可以产生深远的影响

有一个简单而显而易见的事实，某些人可能没有立即意识到，但它在整个 IT 行业中非常真实且普遍存在。这个事实是，开发团队的激励措施是为了交付变更，而运维团队的激励措施是为了确保稳定性和系统正常运行，从而阻碍了变更。以下图表强调了这一点：

没有简单的答案，但你可以参考一些示例来缓解这一痛点：

激励措施	优点	缺点
在 Dev 和 Ops 之间设定相同的激励措施。	如果你在激励措施中支持持续变革，将增加 CD 和 DevOps 成为常态的可能性，因为所有相关人员都将关注同一个目标。	这可能带来更多的风险，因为人们可能认为快速改变比质量和系统正常运行更重要。
将 DevOps 合作伙伴双方的激励措施纳入彼此的考量中。	如果软件工程团队的部分奖金与实时平台的稳定性挂钩，他们会在冒险之前三思。如果运维工程团队的部分奖金与推动 CD 相关，他们会在无必要的情况下阻止变更。	如果这种交换比例较小，可能会被忽视，因为焦点仍然会放在获得大部分奖金上，这仍然会鼓励旧的行为模式。
用一种专注于良好行为并鼓励 DevOps 文化的新激励机制替代当前的激励方案。	这种方法有可能消除工程团队（开发与运维）之间的冲突，并鼓励他们关注真正重要的事情：交付客户所需的产品。	现实是，想要达成完全一致并迅速实施这一方案是相当困难的，特别是在公司环境中。这并不意味着这不是值得追求的目标。

无论你在激励和奖励员工方面做什么，你都需要在变革中培养一种积极的心态，同时确保风险得到降低。

拥抱变革并减少风险

与在基层层面上培养创新和问责制相似，你需要跨越更广泛的组织工作，确保他们接受变革是好事，而不是应当害怕的事情。

的确可以说，任何在生产平台上的更改——无论是引入一项新技术、修复一个 15 年历史的代码库、升级操作系统，还是更换存储阵列——都可能增加平台或其部分组件失败的风险。要真正消除这种风险，唯一的办法就是什么都不改，或者直接关闭一切并锁起来，但这既不现实也不切实际。所需要的是一种管理、减少并接受风险的方式。

实施持续交付（CD）和 DevOps 正是能够做到这一点。你将进行小范围的渐进性变更，保持透明度，变更的开发团队与支持团队密切合作，代码编写者（个人）拥有责任感和问责制，并且全力以赴地追求成功。

这里的主要挑战是让公司内的每个人都理解并接受这作为日常工作方式。最有效的方式就是通过实际证明这一点。

用成果改变人们的看法

与其他天生规避风险的公司部分相比，让基层人员理解这个概念应该相对简单。

我这里指的是 QA 团队、高级管理人员、项目经理和程序经理等。说服他们风险已经被控制有几种方式，但最好的方法是使用“成果验证”的方法：

1. 选择一个小的变更，并确保它在整个公司内得到广泛宣传

2. 吸引更广泛的业务团队，专注于风险规避，并确保他们了解相关信息；同时邀请他们参与观察和贡献（团队站立会议、计划会议等）

3. 确保参与变革的工程师也意识到变革需要被特别关注

4. 随着变革的推进，邀请工程团队参与并定期发布博客，详细说明他们正在做什么，包括统计数据和指标（代码覆盖率、测试通过率等）

5. 在发布过程经过各个环境到达生产环境时，尽可能多地捕获统计数据和度量指标，并将其发布。

6. 当所有工作完成后，将这些内容整合成一篇博客文章和发布后报告，然后进行呈现。

你可能会觉得这是一项庞大的工作，坦白说，如果你按照前述步骤逐一处理每一个改动，确实会很繁琐。但这项工作是有意义的：它向业务证明了变化是好的，风险是可以被控制和管理的。我建议你多执行几次这些步骤，以建立信任和信心——你始终可以在后续优化。你会发现另一个积极的效果是，它会在基层培养一种勤奋的文化；如果他们非常清楚业务在关注事情的进展，尤其是在事情出错时，他们就会在做出愚蠢决定之前三思而后行。

应该注意的是，尽管这些步骤会产生额外的工作量，但与一些组织目前的运作方式相比，这算不了什么；改动会被充分记录，风险会被评估，进度会议会召开，项目进展会公示，每个细节都会被记录和归档。难怪交付软件可能如此痛苦。

与生活中的任何事情一样，如果你做出一些小的改变，风险会大大降低。如果你多次重复这个过程，风险几乎会被消除，习惯也会形成。沿着这个思路，如果不频繁发布且每次改动较大，风险就会很大。将其变小并且频繁发布，风险就会消失。从这个角度看，事情其实很简单。

作为验证成果的例子，进行了大量的宣传和博客发布。这不应被视为负担，而是 CD 和 DevOps 采用的必要组成部分。保持高度可见性是打破障碍并确保每个人都意识到发生了什么的关键。

保持透明

正如我们之前所讨论的，对你所做的事情及其方式保密并不利于建立开放、诚实且基于信任的工作环境或文化。如果每个人都能看到正在发生的事情，那么就不会有意外发生。我们所追求的是一种文化，一种工作方式，在这种方式下，变化是好的且频繁的，个人在共同目标上协作，业务部门信任产品交付团队按时交付所需的内容，运维团队了解即将发生的事情。如果整个过程高度可见，任何人都能看到这一切，而且更重要的是，看到它有多么有效。

你可以考虑在办公室周围安装大屏幕，展示统计数据、事实和数字。你可能已经设置了类似的显示系统，但我猜这些屏幕显示的是非常技术性的系统统计信息、CPU 图表、警报等。我还猜大多数这样的屏幕位于技术团队的区域（开发、运维等）。这并不是坏事，只是非常专业化，非技术性人员可能会忽略它们，或者更可能根本不知道它们的存在。看看你能否将部分屏幕移动到办公室的公共区域，或者尝试找到预算购买新的屏幕。

你还应该用非常简单、易于阅读和理解的与 CD 和 DevOps 过程相关的数据来补充这些高度技术性的内容。你应该考虑展示以下几种信息：

• 本日、本周、本月和本年发布次数，与昨天、上周、上月和去年相比

• 当前发布队列和发布进度，以及谁发起了该过程

• 生产系统的可用性（当前和历史）

• 如果你使用在线 scrum/Kanban 看板（如 Jira、Rally 或 Trello），可以考虑展示这些数据，以展示你的积压任务、进行中的工作和已完成的工作，以及相关的统计数据，如速度和燃尽图

• 最新的商业信息，例如股价、活跃用户数和未解决的客户服务单数

最后一条非常重要。你应该发布、展示和宣传与业务相关的互补信息和数据，而不仅仅是关注技术性的事实和数字。这将有助于提高技术团队以外的员工的参与度和意识。随着你在实施 CD 和 DevOps 的过程中推进，公开这些信息也将证明事情正在改善。

总结

本章中我们讨论了实施 CD 和 DevOps 过程中与人相关的诸多内容。希望你已经意识到，运作的文化决定了 CD 和 DevOps 的成功。在协作方面，你会发现信任、诚实和开放是强有力的工具，它们使得个人能够为自己的行为负责。奖励良好行为并去除责备也将有助于推动采纳。

到这一点，你应该已经有了一个计划，并对在实施 CD 和 DevOps 时文化和行为的重要性有所了解。在第四章，成功规划中，我们将探讨一些有助于推动前进的实际事项。

第四章：成功的规划

在第二章《理解你当前的痛点》中，你已经接触到了一些工具和技巧，帮助你识别可能在整体产品交付过程中存在的问题。我们将此称为“房间里的大象”，因为它是显而易见的，但却非常容易被忽视。

然后我们在第三章《文化与行为是成功的基石》中进一步探讨，强调（并在某些方面强化）一个事实：团队在进行和交付变更的文化和环境对行为有巨大影响，进而影响他们的工作方式和交付质量。

我们现在将运用这些学习，专注于各种方法、策略、技巧和工具，你可以利用这些来将其转化为一个可以实施的计划，帮助你克服挑战——可以说是一个实施 CD 和 DevOps 的进攻计划。

在本章节中，你将接触到以下内容：

• 为什么为你的 CD 和 DevOps 采纳定义目标和愿景非常重要

• 为什么确保每个人都理解其内容并且熟悉所使用的语言和术语非常重要

• 如何通过使用在线协作解决方案来提高参与度和沟通

• 确保业务方理解持续交付（CD）和 DevOps 实施的广度

• 为什么有效的公关、宣传、勇气和决心对项目的成功至关重要

• 在开始你的冒险之前，必须考虑的成本，有些是显而易见的，有些则不太明显

这个进攻计划不容小觑；就像“大象曝光阶段”一样，你需要进行相当多的基础工作，以确保实施范围得到理解、接受和传达。

在我们深入规划之前，让我们先看看你无疑会遇到的各种问题。

一些常见的问题

在“大象曝光”过程中，你将暴露出一些当前软件交付中的问题。你也将开始考虑文化、环境中的问题，以及表现出来的行为问题。

这里的假设是，所识别的问题是与全球大多数企业中的软件交付过程相关的常见问题。这些问题包括以下一些：

• 由于过程中的交接点和决策点过多而浪费

• 因步骤之间不必要的等待时间而浪费

• 许多软件变更被打包成大型、复杂的一次性发布

• 大规模且不频繁的发布容易导致缺陷和漏洞的流失，以及交付变更的人与支持变更的人之间的不信任

• 发布被视为一种令人畏惧的事情，而不是变革的积极机会

• 大部分团队成员处于脱离状态，或者士气低落（或者两者兼有）。

• 关键团队之间的沟通存在碎片化、停滞不前，有时甚至完全没有沟通。

• 软件变更在没有经过多次测试之前是无法被信任的。即便如此，正式上线也不意味着没有问题。

• 软件设计中存在过于复杂的依赖关系，这使得测试和发布变得非常具有挑战性。

• 整个过程中的任务和活动存在重复。

说仅仅制定一个计划就能解决所有问题和难题是荒谬的——毕竟，有些问题和难题实际上可能是由于计划不一致造成的——然而，没有计划的话，至少要有所进展将变得非常困难。成功实施持续交付（CD）和开发运维（DevOps）本身就已经足够艰难，因此拥有一个统一且被理解的方法将大大提高成功的机会。

和任何计划或项目一样，必须有一个最终目标，并且有一个清晰的路线图来实现它。

设定和传达目标与愿景。

对任何项目来说，设定目标和愿景非常重要，因为它能确保所有相关人员知道预期的结果，并且参与项目的人员清楚地知道项目以及他们自己的方向。这听起来可能很简单，但并不总是显而易见的。除了设定目标和愿景之外，沟通的内容和方式同样重要。如果两者有任何不当，你将面临失去业务支持、参与和认同的风险。正如在第三章中指出的，文化与行为是成功的基石，组织内的环境、文化以及默认行为会在 CD 和 DevOps 的实施过程中产生助力或阻碍作用，因此在制定目标、愿景和沟通方法时，必须保持警觉。

在与高级管理层沟通时，这些挑战可能会变得非常极端。例如，他们可能认为，只要解决在“象曝光”过程中揭示的一些问题，就足以克服企业所付出时间和精力展现的所有问题——一旦你开始听到像“低垂的果实”这样的术语，你就应该开始担心了。多年来帮助许多商业变革的一个简单经验法则是，你必须清楚自己要达成的目标，以及清楚自己要向谁传达这个目标。

在采用 CD 和 DevOps 时，这可能会是一个相当具有挑战性的任务，因为交付物和收益并不总是对外行人来说容易理解或显而易见。它也可能很难完全量化，因为你从采用中获得的一些好处并不是完全有形的——提高团队协作和幸福感的增加是很难衡量的。一些领导者可能会将他们的决策与投资回报率（ROI）模型对齐，并只考虑在回报非常明显且可量化的情况下才为这些事情分配预算。同样的，这很难将采用 CD 和 DevOps 所带来的优势直接转化为纯粹的货币价值。

最好的建议是遵循保持简单，傻瓜（KISS）的方法。你有一个问题列表，这是更广泛的业务为你提供的，他们想要的是一些（任何东西）能够让他们的生活更轻松，帮助他们做他们被雇佣和支付报酬做的工作。我还建议，大多数人也希望有机会为企业、客户以及自己的价值感增添价值。至于问题列表，说实话，你的列表上很可能有比你能有效交付的更多的事情。这应该被视为一件好事，因为在优先级排序时，你会有一定的灵活性。

你的挑战是汇集一个目标和愿景，这将引起所有利益相关者、员工和更广泛的业务的共鸣，并确保它能够增加业务价值。更重要的是，你需要确保这个目标和愿景能够实现。这将需要相当多的努力、思考和规划，但这是可以做到的。为了给你一些启发，我们可以回到 ACME 系统，看看他们是如何处理这个问题的。

当 ACME 系统计划采用 CD 和 DevOps 时，他们将自己的想法汇集在一起，并为项目设定了一个目标。这非常简单且不言自明；即每天能将工作代码发布到生产环境 10 次。他们进一步简化为每天交付 10 次价值，这形成了一个简单易懂的口号（几乎每个人都能理解，但稍后我们会详细说明），并为其愿景和沟通策略奠定了基础。

是的，这是一个雄心勃勃的目标，但公司知道，只要有一些艰苦的工作、勇气、决心和合适的人参与，这个目标是可以实现的。

设定目标可能同样简单。你对需要解决的业务问题有清晰的了解，知道哪些团队参与其中，也对哪些问题能引起利益相关者共鸣有清晰的概念。这听起来可能很简单，但可以说，凭借一块空白的白板和一支笔，你就能填满大部分空间，列出许多目标示例。征询你信任的人的意见；如果他们认为你提议的目标不靠谱，那可能就是真的不靠谱。如果你幸运地有公关或营销人员可供咨询，向他们征求意见；毕竟，这正是他们擅长的。制定一个高层次的沟通计划也可能有助于聚焦信息传递给目标受众。

让我们再回到 ACME 系统，看看他们是如何处理沟通的。他们有一个目标（每天交付 10 次价值），并需要设定愿景。这个愿景包括了多种交付物，他们相信这些交付物能够解决在“揭示大象”过程中强调的大多数问题。这些交付物既有技术性内容，也有非技术性内容，但最重要的是，它们易于理解、解释，并且可以清晰地传达。这些交付物被列出、细分并按优先级排序，以指明将以什么顺序解决哪些问题。熟悉敏捷工作方式的你们一定能认出这是一个优先级排序的功能待办事项列表。

为了进一步加强这一点，他们随后着手处理能够引起利益相关者和业务领导层共鸣的商业论证。他们通过回顾问题清单，找出那些直接与成本相关——或者更重要的是浪费相关的问题。他们重点关注的例子包括过度重复的手动测试、由（昂贵的）高级领导出席的重复会议，以及发布的停机成本。为此，他们还汇总了与缺陷逃逸和需要修复的热修复数量相关的事实和数据。

下一步是将目标和愿景记录并呈现给业务决策者以及有影响力的利益相关者，以获得一致意见，确认所提议的方案能够解决在“揭示大象”过程中捕捉到的问题和难题。这次演示面向尽可能广泛的受众——不仅仅是领导层——为此安排了多次会议，持续了许多天，以便尽可能多的人能参与其中。首选的结果是获得最初参与“揭示大象”过程的人员的同意，全面理解、支持并接受所提议的方法。

经过多次讨论、展示、劝说和一些时间后，组织内达成了共识，目标和愿景得到了确认。随着愿景的确定，接下来开始将愿景中的最高优先事项（即最高优先级的功能）分解为需求（即用户故事），这些可以付诸实践并更重要的是交付。

下一步是汇聚一群志同道合的人来协助项目的交付——无论是从技术工具的角度，还是从教育、辅导和咨询的角度，帮助更广泛的团队实现其目标。

为确保目标和愿景的透明度和易获取性，ACME 系统团队的成员需要确保所有数据、信息和计划都能供大家查看。为此，他们充分利用了所有可用的内部沟通和项目存储及报告工具：内部 Wiki、博客、网站、内网和论坛。

如果你没有类似的工具可用，使用开源解决方案设置一个工具并不会耗费太多精力。甚至有一些在线解决方案足够安全，能够保护公司机密。拥有这种透明度和开放性将帮助你在执行计划时向前推进。尤其是像社交解决方案这样的工具，比如博客和论坛，能够提供反馈，并开展虚拟讨论。

让我们看看我们的角色能做些什么来提供帮助：

好的方法	不太好的方法
Victoria（副总裁）可以继续积极参与项目，帮助她的团队量化业务案例，在同行之间推广目标、愿景和业务利益。理想情况下，成为项目赞助人将为活动增添分量。	Victoria（副总裁）逐渐与活动保持距离，因为她已经投入了足够的时间和精力。她还开始公开质疑目标、愿景和项目的有效性，因为没有明显的投资回报。
Stan（经理）继续积极参与，确保目标和愿景是现实可行的，并且传达准确。他还可以呼叫市场营销部门的同事帮助定位信息。正如 Victoria 所做的那样，他可以帮助在同行之间推广目标和愿景。如果他有敏捷教练或 Scrum Master 可用，他应该让他们参与协助制定待办事项列表。	Stan（经理）效仿他的上司（Victoria）的行为，公开质疑目标和/或愿景的必要性。他还鼓励他的团队忽略这些，直接执行。
Devina（开发人员）和 Oscar（运营人员）可以并且应该继续积极参与项目，尽可能地收集背景数据。	Devina（开发人员）和 Oscar（运营人员）低调行事，按指示执行。

当这些内容用几段文字表达出来时，听起来都相当简单，坦白说，如果有合适的环境和合适的人参与，确实是如此。这只是确保你和他们都能很好地理解业务和利益相关者的需求，并将其总结成一个人们能理解且能够支持的目标的问题。关键在于将愿景对齐，以推动事物朝着正确的方向发展。这里的关键是“易于理解”，这有时会是一个挑战，尤其是当你考虑到在许多业务领域之间（可能还涉及多个时区和文化）沟通时，每个领域可能对所使用的术语和词汇有不同的理解时。这样，我们就可以顺利过渡到如何沟通并确保所有相关人员都能理解正在发生的事情。

词汇和语言的标准化

一个小小的、完全可以避免的事情可能会毁掉任何一个项目，那就是对交付物的误解或混淆。听起来可能有些令人担忧，但项目失败往往仅仅因为一个人期望的是某个东西，而另一个人误解或误读了这个需求，交付了完全不同的东西。这通常并非因为无知，通常是因为双方对同一个事情的理解方式不同。

例如，让我们来看一个相对无害的词语：发布（release）。对项目经理或发布经理来说，这可能代表一系列软件更改，需要在计划或工作程序内进行测试并上线。这通常涉及详细的项目计划、与产品交付职能内外的各个部门的紧密协调，以及大量的会议、文书工作和加班。对一个以敏捷方式工作的开发人员来说，发布 可能只是一次简单的代码更改，可能在他们完成编码并运行自动化测试后不久就会上线。如你所见，同一个简单的词在产品交付团队的一个成员眼里可能代表着需要大量工作的内容，而在另一个人眼中却是每天都会发生的简单事情。这些不同的理解会导致许多无法预见的浪费问题。

当你开始审视我们在产品交付和 IT 整体过程中使用的各种不同的词汇、术语和 TLAs（三个字母的缩略语）时，可能也会遇到一些问题。因此，我们需要注意我们沟通的目标受众，并确保他们能轻松理解所传达的信息。同样，KISS（简化）方法在这里也非常有效。你不一定要将内容降到最低的共识水平；那可能非常困难（你可能最终会写一本书），并且可能会适得其反。尽量找到一个平衡。如果一些目标受众没有轻松理解的能力，那么让一个理解的人去和他们沟通并解释；这将有助于弥合差距，同时也能建立良好的工作关系。

另一个有助于弥合差距的建议是汇总一个术语表，供大家参考。以下是一个简单的示例：

术语	定义	非定义
持续交付	一种将完全工作且经过测试的软件以小的增量方式交付到生产平台的方法，从而快速为客户提供价值	一种非常复杂的方法，每几周或几个月交付大量代码
DevOps	一种工作方式，鼓励开发和运维团队高度协作，共同朝着相同目标努力	让开发人员承担运维任务，反之亦然
CD	见持续交付
持续集成	在开发周期内尽早发现软件问题，并确保平台各部分正确对接	被忽视或绕过的任务，因为它需要努力
CI	见持续集成
定义完成	平台的变更（如软件、硬件、基础设施等）已上线并被客户使用	一项名义上已签署的、最终会在上线时生效的变更
DOD	见定义完成
发布	将代码一次性部署到指定环境（如测试、预发布、生产等）	一大堆变更交给他人整理
部署	将发布版本推送到指定环境中的操作	运维团队执行的任务

如果你有内部沟通/协作工具，如维基、内联网、博客或论坛，那么这些地方就是分享这些内容的好地方，因为其他人可以随着更多流行词和缩略语的引入不断更新它。

这里的经验法则是，无论你标准化了什么词汇、语言或术语，都必须坚持使用并保持一致——随意变化应当避免。例如，如果你选择使用 CD 和 DevOps 这个术语，就应该在所有形式的交流中保持一致，包括书面和口头表达。这样它会变得深入人心，其他人也会在日常中使用，这意味着对话会更加一致，误解和混淆的风险会大大降低——未能做到这一点可能会导致错误决策的产生。

还需要考虑的一点是行业标准术语与企业惯用术语的区别。例如，如果你们公司每个人在提到发布这个词时都会感到一阵恐惧，那么就不要试图改变它的含义以符合行业标准，因为有些人仍然会联想到负面含义。相反，可以尝试使用替代术语——如交付——这种词汇没有历史负担。总的来说，谨慎选择你的词汇，因为它们将伴随你一段时间。

让我们看看我们的角色可以做些什么来提供帮助：

良好方法	不太好的方法
Victoria（副总裁）积极参与组织内部使用的语言和词汇，并在所有沟通中（书面和口头）使用已达成一致的术语。她还会纠正同事和更广泛组织中的成员，当他们重新使用曾经用过的术语和语言时。	Victoria（副总裁）忽视了组织内部语言和词汇的重要性，任由不正确的术语和语言不加挑战地流传。事实上，她自己也仍然使用不正确的术语、语言和词汇。
Stan（经理）模仿老板（Victoria）的行为，有时会纠正她的失误。Stan 也应积极鼓励团队编制、完善并在所有沟通中使用标准的符号。	Stan（经理）模仿老板（Victoria）的行为。
Devina（开发人员）和 Oscar（运维人员）也会模仿他们老板的行为，并鼓励同事们也这样做。	Devina（开发人员）和 Oscar（运维人员）只是忽略周围发生的事情，继续使用他们一直以来使用的术语、语言和词汇。

假设你现在已经有了目标、愿景、高层次的待办事项清单、标准的沟通方式，并准备好开始实施。几乎可以开始了。愿景的执行不是一项轻松的任务。无论你是一个小型软件公司还是一个大型企业，都应像对待任何其他项目一样，认真对待 CD 和 DevOps 的采用与实施，因为它们涉及并影响到业务的许多方面。例如，你不会像处理一个小型的“skunkworks”项目那样，将新的财务和薪资系统引入到公司。任何影响到整个业务的变动都需要协作、紧密协调和规划。CD 和 DevOps 的采纳并非琐事，因此应该被看作是一项同样重要的任务。

一项真正的业务变革项目

将 CD 和 DevOps 的实施和采纳归类为一项业务变革项目，可能听起来有些枯燥，但这正是它的本质；你是在改变业务的运作方式，使之变得更好。这绝不是一件轻松的事情。如果你曾参与过业务变革项目，你会明白它们可能带来的深远影响。

很可能更广泛的业务部门没有像你一样充分理解这一点。他们参与了调查并验证了发现，看到你打算采取的措施来解决提出的问题。但他们可能并没有完全理解实施和采纳 CD 与 DevOps 的深远影响——从业务角度来看，这可能是一次改变人生的事件。本书稍后会讨论在实施过程中你可能遇到的一些障碍，但如果你从一开始就有所准备，你会更容易越过这些障碍。

可以肯定地说，你应该确保让企业认识到这个项目将会影响到许多人，尽管是以积极的方式。当前业务运作的方式、现有的流程、工作方式以及所需的技能将需要改变。我们谈论的并不仅仅是产品开发；采用 CD 和 DevOps 将改变业务的思维方式、计划方式、决策方式以及运营速度。

例如，假设销售、营销、产品和项目管理团队目前正在进行一个三到六个月的周期，将特性推向市场。如果 CD 和 DevOps 的采用按计划进行，那么这个周期将大大缩短，特性可能会在几天或几周内就能交付：

一个典型的多月软件交付周期：

一个典型的敏捷软件交付周期

上述团队将需要以不同的节奏工作，并且必须加快和精简他们的流程、规划和沟通。他们还需要优化市场推广策略，以确保客户不会因特性过早交付而感到惊讶。

根据经验，CD 和 DevOps 的采用以及交付速度的一贯提高，也带来了一些意想不到且非常积极的好处——即业务中重新建立的信任感。当产品交付和运营团队承诺交付某个功能时，他们确实能按时交付——一遍又一遍。从表面上看，这是一件好事，但如果下游团队如销售和营销已经习惯了特性交付的持续延迟，他们可能会将延迟因素考虑到计划中，因此按时交付特性可能会让他们感到意外。

这也意味着整个端到端的过程可以得到简化，因为传统的计划 B、C 和 D——通常在事情出错时（当事情出错时）启动——已经不再需要了。交付特性的方式将发生巨大变化，其他业务部门需要接受这一变化，并为之做好准备。

当你开始考虑 CD 和 DevOps 采纳对更广泛业务可能带来的（积极）影响时，你会开始意识到需要多么小心谨慎地对待这一过程。如果你能够接触到专门从事业务变革的项目管理团队，那么你应当明智地邀请他们参与，以帮助提供整体计划。

需要注意的是，变化不会一蹴而就，但历史表明，真正采用 CD 和 DevOps 的企业通常在几个月内会发生转变（当然，这取决于组织的规模），所以最好有一个计划，以便在事物迅速发展时抢先一步。

回到秘密项目（skunkworks）示例，你应该注意到，CD 和 DevOps 的采用最初会被更广泛的业务视为一个类似的项目——一个开发和运维团队需要实施的项目，目的是克服他们的低效。企业需要认识到的是，CD 和 DevOps 的采用远远不止于此。越早意识到这一点越好。现在我们将集中讨论这个话题。

Dev + Ops + Org

在采用的早期阶段，更广泛的业务很可能会认为 CD 和 DevOps 的影响——正如其名称所示——仅限于开发和运维团队。以下这个相对标准的图示展示了更广泛的业务将如何看待这一气泡的大小：

企业在初期阶段所看到的

起初，这可能离事实不远，你无疑会从小做起，以便能够掌握其中的细微差别，找到你的立足点。这样做是可以的；然而，一旦你获得了一些动力——这不会花太长时间——事情将开始迅速变化，如果人们没有准备好，或至少没有意识到，你可能会遇到一些障碍、困难和痛点，这可能会拖慢进度，甚至将采用过程停滞不前。

如前所述，CD 和 DevOps 的采用是一个业务变革项目——正如名称所暗示的那样——它将影响整个业务，而不仅仅是技术人员。因此，企业必须接受这一影响将是深远的，如这个更广泛且更现实的气泡所示：

企业应该看到的代表性领域，哪些会受到影响并参与其中

如果你回想一下在第二章中“理解你当前的痛点”时，提到过的“房间里的大象”，你会记得，在这个活动中，更多的业务职能部门参与了对端到端业务流程中问题的调查、理解和突出展示。因此，他们不应简单地放弃这项艰难的任务，而应保持参与，积极参与解决问题并改变工作方式，从而实现效益并消除暴露出来的问题。

我不想听起来像是唱片卡住了，但 CD 和 DevOps 的采用不仅仅与产品交付团队相关——其影响和变革将是广泛的，因此你需要确保更广泛的业务继续参与其中。

我想我已经充分说明了这一点，所以我们可以假设企业已经就实施的广泛性质达成一致，且（几乎）每个人都完全支持这个项目。接下来的挑战是决定组建一个专门的团队来推动目标和愿景的实施，以及最终的 CD 和 DevOps 采用。

专门团队的利弊

关于是否需要专门且全力投入的团队来监督 CD 和 DevOps 的采纳，存在几种不同的观点。一种观点认为这是必要且合乎逻辑的举措，因为只有那些对 CD 和 DevOps 感兴趣或具备相关经验/知识的人，才能真正理解这两者的价值，并且知道（或者至少有比较清晰的想法）应该如何进行采纳。这一点是非常正确的，但也存在缺点——我们稍后会讨论。另一种观点则认为这是一个不好的主意，因为这与其他业务变革项目并没有太大的区别，因此可以通过紧密合作和协调来管理，而不需要专业知识。事实上，这两种观点都是对的，同时也都是错的。

归根结底，问题是这样的：如果一个专门的团队能够快速、高效、有效地推动采纳进程，那就去做吧，只要他们不会把所有事情都自己做，孤立地工作，并因此被视为仅仅执行技术任务的 CD 和 DevOps 团队，而不需要与其他人合作。正如我之前所说，仅仅拥有一个 CD 和/或 DevOps 团队并不意味着你已经采纳了 CD 和 DevOps，情况比这要复杂得多。像任何成功的业务变革项目一样，专门的团队应该帮助引导、指导、辅导并支持那些志同道合的人（不仅仅是开发和运维），使他们能够合作和贡献，同时自己也要积极参与，专注于推动采纳的进程。这里常常被过度使用的商业术语是“赋能者”或“变革推动者”。

如果你更倾向于不组建专门的团队，而是将采纳过程作为一个业务变革项目来推进，在需要时引入技能和个人，那么至少应该有一些人深度参与，他们必须了解和/或具备 CD 和 DevOps 采纳的实际含义，并能够确保目标和愿景的实现——没有这一点，事情可能会有些偏离轨道。另一个需要考虑的问题是，偶尔合作的个人团队是否能像一个拥有共同目标和愿景的专门团队那样，保持相同的责任感和紧密的合作。

这确实是你的决定，不过我的建议是加入一个专门的 CD 和 DevOps 采纳团队学校。你需要确保团队的成员不仅仅是技术背景/经验的人员，他们还应该愿意、有能力并且能够跨业务部门工作，更重要的是，最终的目标是让他们自己变得不再必要。我并不是说他们会失去工作，而是指专门的团队应该是过渡性的，一旦 CD 和 DevOps 的采纳已经稳固，团队可以顺利解散，毫不费力地回到他们的日常工作中。

根据以往的经验，决定方法的最简单方式是回归基础，列出对你和你的业务适用的利弊。为了便于阅读和节省页面篇幅，我们假设到目前为止你已经决定组建一个专门的团队——接下来该做什么？

与任何高度协作的项目一样，团队成员的同地工作总是最优先的，然而并非总是可能的。如果你的团队分布在不同的地理位置，那么你需要确保在每个地点都有来自专门的 CD 和 DevOps 采纳团队的成员，因为他们需要与被指导、引导、辅导和指导的人员处于相同的时区并且近在咫尺。他们还需要在日常工作中紧密合作——我建议你参考第三章中的建议，文化与行为是成功的基石，这与团队合作和物理环境有关。

当我们说“专门团队”时，指的就是这个意思。团队成员的主要日常职责是专注于做任何必要的事情，以成功实现之前商定的目标。现在，招募或从外部购买一个专门团队并不罕见，但这并不总是明智之举，因为这些人通常没有业务领域知识，也没有与公司其他部门的联系。尽管如此，招募外部专家和/或有 CD 和 DevOps 采纳经验的人员是有帮助的，只要他们能够与核心专门团队互补。再次强调，这真的是你需要根据业务需求、资源限制和预算来考虑的事情。

无论你决定做什么，都需要注意，你将会把一些关键人物从业务中抽出来，让他们脱离日常工作，投入大量时间专注于 CD 和 DevOps 的实施与采纳。

一旦这一点被明确，我几乎可以保证，业务的某些领域在参与度方面会有大幅度退缩——特别是那些管理你希望派遣到专门团队的人员的领域。这是可以理解的，因为他们很可能是自己领域的专家，因此对于现有团队/职能区至关重要。

这就需要你去劝说、恳求、谈判、交换，来获得你所需要的人选。坦率来说，这不应该太难，因为你手头有相当多的“武器”可用——这些信息和数据是你辛苦汇总的，且公司本身也认同这些信息所揭示的问题。如果你使用了价值流映射练习，你应该也能够准确地找到痛点。我们以你和测试与质量保障负责人之间的典型对话为例——我们叫他 Chucky：

我承认，这可能不会完全按照这些步骤进行，但希望你能理解这个要点。你已经清楚地了解了企业面临的痛点，并被要求消除这些痛点。企业需要意识到，这一过程并非没有成本，他们需要提供你完成工作所需的资源。

关于专门的 CD 和 DevOps 采用团队的设置，这实际上取决于你的企业是如何构建的。一个典型的企业通常会有类似于开发、质量保证、运维和变更管理团队参与软件发布流程；因此，你应该从每个领域中挑选一个人。为了使事情尽可能敏捷，加入一名 Scrum Master 和一位产品负责人，并且加上一个高级经理（能够充当项目赞助人并代表团队参与高层事务的人），这样，你将得到如下图所示的团队配置：

一个典型的团队设置示例

现在，这一切看起来不错，但这不就是一个典型的 IT 项目团队吗？一句话，是的。然而，这主要是因为这一领域的技能和经验。持续交付（CD）和 DevOps 历来源于 IT 人员，因此，你不会看到很多销售高管或会计人员对 CD 和/或 DevOps 有工作理解（除非他们读过这本书，当然）。

如前所述，你应该积极与那些会受到影响的业务领域进行接触，然而，你需要决定谁应该积极参与，谁应该被归类为利益相关者。这里的经验法则应该是：如果某人每天都在积极参与和贡献，他们应该被纳入专门的团队。如果他们有兴趣或需要定期咨询，他们应该是利益相关者。

这里有一个非常有用的工具是 RACI，它可以帮助你定义谁是负责（Responsible）、谁是主管（Accountable）、谁是被咨询的（Consulted）、谁是被告知的（Informed）——关于 RACI 有很多信息，所以我建议你做一些功课。

再次强调，如果要在更广泛的业务中获得信誉，专门的团队必须不仅仅由开发和运维人员组成。

现在你已经掌握了说服和积极影响的技巧，你和你新组建的团队需要学习传道的艺术。

传道的重要性

在整个企业中随时进行传道将需要一些努力和决心。这还将需要一定的精力。事实上，这个说法不准确；它需要大量的精力。你的目标受众范围广泛，涵盖从高层管理到车间的人员，因此你和你的团队需要花费相当多的时间才能传达信息。在我们深入探讨应该对谁、何时以及如何说些什么之前，让我们先确定一些基本规则：

• 如果你想要在推广 CD 和 DevOps 采纳的过程中具有说服力，你和你新组建的团队必须真正相信这一点——如果你自己不信，那么怎么指望别人相信呢？

• 你、团队以及所有参与项目的人，必须践行自己所宣传的理念，为他人树立良好的榜样。例如，如果你在项目中构建/实施了一些工具，确保你使用的技术和工具与所宣传的完全一致。

• 很多人（大多数人）一开始可能不理解，所以你和团队需要非常非常耐心。你可能需要一次又一次地向同一个人解释相同的内容。把这些人当作一个标尺；如果他们开始理解什么是 CD 和 DevOps 的采纳，那么你的信息就很可能成功传达了。

• 记住你的目标受众，并根据其特点调整你的信息。开发人员想听的是技术性内容，新的、闪亮的东西；系统运维人员更关心的是稳定性和可预测性；管理层则想听关于效率、优化流程和风险降低的内容。不要对所有人使用相同的信息。

• 在推广和赞美 CD 和 DevOps 采用时，确保你在衡量信息的影响力——经验法则是，如果你看到他们的眼神变得呆滞，说明你的信息没有传达好，那么就需要做出改变。

• 有些人可能根本不想了解或倾听，也许你不值得花费精力去让他们接受（我们将在第三章中讨论一些这个问题，文化和行为是成功的基石）。如果你能让他们转变过来，那对你和团队来说是个好成绩，但不要因少数滞后者而灰心丧气。

• 保持相关性和一致性。你有标准化的语言、目标和愿景，所以要加以使用。

• 不要随便编造内容。只要专注于可以实现的目标和愿景，其他的可以先放一放。如果有新的想法和建议，把它们加入待办事项列表，等待优先级排序。

• 任何情况下都不要放弃。

归根结底，你和团队必须既要言行一致，又要身体力行。会有很多社交活动，所以要准备好进行大量讨论。随着你的网络不断扩大，推广的机会也会越来越多。不要回避这些机会，确保利用这些机会与业务中的各方建立良好的工作关系，因为你以后会需要这些关系。推广是有回报的，如果你真的相信 CD 和 DevOps 是自从面包切片以来最棒的事情，你会发现与他人讨论它的机会就像是度假一样轻松愉快。

宣传本质上是公关工作，因此如果你有公关人员可用（或者更好的是作为团队的一部分），你还应该考虑准备一些简单的物品，比如徽标或一些免费赠品（例如徽章、杯子、鼠标垫等）来分发。尽管这看起来有些多余，但就像任何公关活动一样，你希望确保将信息传达出去，并将其深深嵌入到环境和人们的心理中。

到此为止，我可能将事情描绘得有些过于美好。采用 CD 和 DevOps 绝不是轻松的事情。所有相关人员面临的挑战非常大。只要所有人都意识到这一点，并且拥有成功的勇气和决心，事情应该会顺利进行。

在整个组织过程中所需的勇气和决心

勇气和决心可能看起来是强烈的词汇，但它们是正确的词汇。过程中会有很多挑战，有些是你意识到的，有些是你没有意识到的，这些挑战会试图阻碍进展，因此需要决心确保一切朝着正确的方向推进。勇气也是必不可少的，因为这些挑战中的一些将要求你、团队和更广泛的业务部门做出艰难的决定，这可能会导致采取一些无法回头的行动。我会以 ACME 系统版本 2.0 为例，说明这一点。

在他们初次采用 CD 和 DevOps 时，他们从平台的一小部分开始，选择了使用新部署工具和工作方式进行发布的候选项。不幸的是，同时由于另一项发布（使用旧的将所有内容打包并作为一个巨大的部署推送出去的方法）进展不顺，业务部门产生了大量噪音。业务部门要求大家集中精力不惜一切代价将发布完成，甚至包括暂停 CD 试验。这让团队并不太满意。然而，在 ACME CD 和 DevOps 采用团队的高级经理与同僚进行了一次相当大胆的讨论后，大家达成一致，如果能确保这是最后一次大爆炸式发布，并且今后的所有发布都将使用新的 CD 流水线流程，资源便可以得到分配。协议最终达成，随之而来的是大爆炸式发布的时代终结，以及 CD 和 DevOps 新时代的曙光。最后一次大爆炸发布完成后，整个开发和运维团队决心尽快启动 CD。

他们已经经历了足够的痛苦，迫切需要另一种方法，或者说一种更好的方法。他们坚持了几个月，直到第一次使用新工具和工作方式的发布顺利进入生产环境，接着是下一个，依此类推。此时，已经无法回头，因为已经改变了太多。

正如你无疑能够理解的，这一决策需要业务各方面的勇气。没有备用计划，如果这个方案没有成功，他们将没有办法发布软件。了解这一点后，业务决心将新的 CD 和 DevOps 工作方式深入植入并确立下来。

这可以算作极端案例，但它仍然表明，有时勇气和决心是非常必要的；有志者事竟成。

在我们脱离规划阶段之前，还有几件事你应该注意，在准备开始新的冒险时：寻求帮助的渠道，以及确保你和更广泛的业务团队了解实施和采用 CD 与 DevOps 的成本。我们首先讨论成本。

理解成本

实施 CD 和 DevOps 最终将为企业节省大量资金；这是一个非常简单且明显的事实。发布软件所需的努力将大大减少，与大型大爆炸发布相比，所需资源将微乎其微，市场推出时间将大幅缩短，质量将大大提高，做生意的成本（即所需修复的错误数量、系统停机支持、未达到 SLA 的罚款等）将几乎可以忽略不计。也就是说，实施 CD 和 DevOps 并非没有成本。确实需要成本，企业需要意识到这一点。

让我们来逐一分析：

• 专门的团队被指派到 CD 和 DevOps 项目

• 业务流程文档和/或业务流程图的变更

• 标准操作程序的变更

• 主机托管的变更（假设会迁移到虚拟/云基础设施）

• 调整变更管理系统，以便进行更快速、更轻量级的操作

• 内部公关和营销材料

• 寻求外部专家的帮助

• 在新的工作方式成为常态时，起初可能会有所放慢

这些成本不应是过高的；然而，它们是需要考虑并计划的成本。像任何项目一样——尤其是像 CD 和 DevOps 推广这样影响深远的项目——总会有一些成本。如果从一开始，业务就已经意识到这一点，那么以后项目失败的可能性就可以最小化。

可能会有一些间接由项目引起的成本。你可能会有一些人无法接受这些变化，最终选择离开；这时需要承担替换他们的成本（或者可能不需要，视情况而定）。正如在“大爆炸”发布转型初期所说，你可能会为了更快的速度而放慢进度。如果在此期间有合同截止日期需要遵守，或许需要重新谈判这些截止日期。

那些积极参与 CD 和 DevOps 推广的人，比任何人都更了解你的业务——尤其是在经历了“大象曝光”之后——因此你可能会有更好的成本相关想法。只要确保不要忽视他们的意见。

现在让我们集中讨论一下，如果你需要帮助和建议，可以去哪里寻求。

寻求他人建议

在你决定彻底改变企业运作方式之前，做一些研究和/或联系符合以下描述的人可能是个不错的主意：

• 已经经历过几次这种转型，并拥有可以证明这一点的“战斗伤疤”

• 和你处于相同境地的人

• 专注于广泛的敏捷商业变革

• 在 CD 和 DevOps 领域被公认为专家

全球范围内有越来越多的人拥有实施（甚至定义）CD 和 DevOps 的经验。有人是该领域的专家，并专注于此作为他们的全职工作；也有人仅仅是日益壮大的社区成员，他们看到了光明，并无私地希望帮助他人实现他们亲身见证和体验的好处。

再次强调，实施 CD 和 DevOps 绝非易事，有时身处前沿的确是一个孤独的地方。不要觉得自己应该孤军奋战。实际上，有一些有价值的参考资料可供利用（我希望这本书是其中之一），更重要的是，还有许多社区—无论是在线的还是面对面的聚会—你可以加入其中以获得帮助。你永远也不知道，也许你的故事和意见会成为他人的启发，所以，秉持 CD 和 DevOps 的精神，打破障碍，享受开放和诚实的对话。我将在附录 A 中列出一些参考资料和联系方式，一些有用的信息。

总结

那么，我们在本章中讲了什么？我们了解到，如果没有定义目标和愿景，就很难澄清和沟通 CD 和 DevOps 的采用意味着什么，以及它们将带来什么商业价值。继续沟通的话题，我们了解到，如果没有在术语、语言和词汇方面达成共识，跨组织协作将变得非常困难。至于谁会受到 CD 和 DevOps 的影响，我们已经提到这是一项广泛的商业变革，而不仅限于传统的 IT 组织。就像任何商业变革一样，CD 和 DevOps 的采用不会是免费的；它将会有成本（有些是显而易见的，有些则不那么明显），你需要考虑到这一点。最后，你并不孤单；全球有大量的人、团队和企业已经经历了这一过程，并且从中获得了显著的进步。

假设此时你已经遵循了这些建议，现在你拥有了一个团队、一份计划、执行支持和赞助、明确的沟通方式、一些预算以及来自经验丰富专家的支持。你现在准备好进入下一个阶段——实现目标和愿景，这也是我们将在接下来的几章中讨论的内容。我们将从一些经过验证的方法、工具和技术开始，这些将帮助你向前推进。

第五章：方法、工具和技术

上一章专注于为 CD 和 DevOps 的实施和推广组建目标、愿景和专门的团队（或根据实际情况不组建）。在接下来的几章中，我们将通过执行计划的步骤，最终实现你所定义的目标。

在第三章中，文化和行为是成功的基石，我们专注于 CD 和 DevOps 采用中需要落实的人文方面。第四章，成功的规划，则探讨了如何制定计划以及为确保采纳成功需要构建的一些基本要素。接下来，我们将重点关注执行中的技术层面——你和团队应该在计划中实施和/或完善的工具、技术、方法和流程。

本章将涵盖很多内容，其中一些是你需要的，一些你可能已经具备，另一些则可能是你以后想要考虑实施的。我建议你阅读全部内容，以防其中有些小的智慧或信息，你能够调整或采用，以更好地满足你的需求。

本章有相当一部分内容集中在软件工程（即 DevOps 合作中的 Dev 端），更偏向 CD 而非 DevOps，但请耐心阅读，因为其中的一些要点对系统运维和软件工程同样相关——毕竟，这正是 DevOps 的核心所在。

值得指出的是，所提到的工具和流程并不是相互排斥的——并非“全有或全无”；你只需选择适合你的方法。话虽如此，接下来一两章中所涉及的一些内容确实有一定的逻辑顺序和依赖关系，但最终决定什么是可行的，还是取决于你。

另一个非常重要的考虑因素是，除了我将要提到的内容外，还有大量的书籍、网站、博客等，它们提供了比我更为详细的信息。我会努力提供一个概览，帮助你理解推动 CD 和 DevOps 采用的关键内容。深入了解的部分就交给你和团队去探索吧。

在本章中，我将提到一些工具和/或软件解决方案，您应考虑使用它们来减轻负担并促进 CD 和 DevOps 的采用。像任何投资一样，我建议您不要仅仅选择出现在您最喜欢的搜索引擎中的第一个工具，或选择一个现有供应商强推的工具。CD 和 DevOps 工具市场竞争激烈；因此，您应该有多个选择。根据您的具体需求，了解您需要解决的问题，并在选择时进行充分的尽职调查。如果需要尝试几种不同的工具，您应该这样做。CD 和 DevOps 的采纳效果可能依赖于这些工具，因此请选择谨慎。

既然这些问题已经解决了，让我们开始一些工程最佳实践吧。

工程最佳实践

对于那些不是软件工程师，或者没有软件工程背景的人来说，您对软件如何开发的知识和/或兴趣可能非常有限。你可能会问，为什么我需要了解开发人员是如何工作的？难道开发人员比我更懂这些吗？反正我都不理解其中 10%！

在某种程度上，这是非常真实的；开发人员确实（并且应该）懂得自己的业务，把你放进来可能并不受欢迎。然而，如果你至少对软件是如何创建的有所了解或理解，会有帮助，因为这有助于识别潜在的问题所在。

换个方式说：我理解并且欣赏内燃机是如何组装的以及它是如何运作的，但我不是机械师——事实上，远非如此。然而，我知道足够的知识，能够质疑当我带车去修理时，为什么一个机械师会把我的整个排气系统和后轴都换了，尽管我只是带车来解决一个燃油喷射器的问题——事实上，我肯定会激烈地质疑为什么。

软件开发和它周围的过程也是如此。如果你一点技术背景都没有，且没有做过功课来理解软件应该如何编写，你就会让自己暴露在那些喜欢用技术术语来转移话题而不是开诚布公、愿意并能够与你合作的人做决定的风险中。在“象的曝光”过程中，你无疑会遇到过这样的人，我敢打赌，他们肯定避免参与到这个快速交付软件而不让一切乱套的空想之中——至少他们是这么认为的。你和团队将需要与他们在同一水平上合作，所以如果你对你所说的内容有一些了解，将有助于这些讨论。

让我们从基础开始：CD（持续交付）基于一个前提，即优质软件可以在短时间内多次开发、构建、测试和发布（这就是“持续”的部分）——理想情况下，我们说的是几小时或几天最多。当你把这个列表应用到传统的瀑布式开发项目时，你无疑会发现每个步骤都需要时间和精力，并且充满浪费。你也无疑会发现，最痛苦、最昂贵、最有风险的部分就是发布（或交付）。而当应用到现代敏捷开发项目时，你通常会发现列表中的前三项更为精炼、高效和有效（尽管仍然存在一些浪费和时间滞后——这取决于团队的成熟度），但发布部分仍然是痛苦的，且需要大量的时间和精力。稍后我们将重点讨论发布（更准确地说，是交付）部分。

从这一点开始，我假设你已经知道瀑布式开发和敏捷开发之间的区别（如果不知道，我建议你停下来做点功课），然后迅速进入下一部分。

让我们回归基础，讲解一些现代敏捷软件工程的基本概念：

• 所有代码、配置和相关元数据都存储在现代的源代码/版本控制解决方案中

• 小的且完整的代码更改应频繁提交到源代码管理仓库

• 单元测试默认包含并与源代码仓库一起存放

• 代码重构会定期进行

• 代码不应过于复杂，并且应该有文档化说明

• 分支生命周期短，合并频繁

• 自动化测试与代码一起存放在源代码仓库中，并且会非常频繁地运行

• 一直使用结对编程、代码审查或拉取请求

• 构建和自动化测试由持续集成（CI）解决方案进行协调和控制

• 测试失败并不意味着世界末日；让别人指出你代码中的缺陷也不是终结

可能有些人已经失去兴趣，但在跳过本章之前，请再稍微阅读下去，因为我很快会深入讲解其中的一些概念。

上述列表相当简单，正如之前所说，大多数从事现代敏捷软件开发项目的工程师会把这些视为常识和常规做法。

提到现代敏捷软件开发是有目的的，因为仍然有一些（在某些行业中，应该说是很多）老派的程序员认为，他们由于多年来在没有这些新潮的“hipster”技术的情况下成功交付代码，因此可以免除这一切。也许这是事实；然而，如果不改变软件的编写和交付方式，几乎不可能成功地采用 CD 和 DevOps。这些人无疑会在“参与度低”的贡献者组中。

更令人担忧的是，当这些人积极阻止那些希望遵循现代敏捷软件工程最佳实践的软件工程师时。无论情况如何，这些“老狗”都得学会新把戏。

最终，现代敏捷软件工程的基础是尽早发现软件问题。没有这种方法，这些软件问题必定会在后期被发现，它们必定会拖慢进度，并且必定会对最佳实践的采用和其成功的认知产生负面影响。

换句话说，如果你持续开发小的增量变化，并且这些变化正在构建、集成和测试，那么持续交付的便利性将大大提高。

让我们看看我们的角色可以做些什么来帮助：

良好方法	不太好的方法
Victoria（副总裁）不应仅仅将此视为“开发人员的工作”，应确保她意识到在工程团队中成功实施最佳实践所需的努力，并愿意提供预算和高层支持。	Victoria（副总裁）将其视为更多的开支，这可能会拖慢进程和/或成为偏离主要产品交付流程的低优先级秘密项目
Stan（经理）应确保相对重要性在领导层、同伴群体和团队之间得到充分重视，并确保正确的资源在组织中分配和对齐。	Stan（经理）忽视工程最佳实践带来的好处，认为其采用会增加额外的工作量，从而分散团队的注意力。
Devina（开发人员）和 Oscar（运维人员）应该花时间理解并完全接受工程最佳实践，并在同伴中以身作则。	Devina（开发人员）和 Oscar（运维人员）低调行事，把领导角色交给他人，继续在执行工程最佳实践时遇到困难。

对于那些眼神开始涣散的朋友，或者那些需要复习的朋友，让我们从源代码管理开始，进一步解释这些概念。

源代码管理

有很多不同版本、种类和解决方案可供选择用于源代码管理（有时称为 SCM 或版本控制系统），包括商业（收费）和开源（免费的）。这些工具大多可以自托管（如果需要的话），或者作为PaaS模式提供（虽然不是免费的，但仍然相对便宜）。考虑到这一点，不使用源代码管理没有任何借口。绝对没有！

如果所有代码都存储在源代码管理中，并且进行了版本控制（即，每一个变更都有历史记录，从最早的版本开始），它对任何拥有源代码管理访问权限的人都是可用的，是安全的，并且应该有备份，以防丢失任何代码。

一些更现代的解决方案实际上可以帮助你通过内置的工具、工作流程和触发器来控制软件交付的整个生命周期。这可以为你节省大量的时间、复杂度和成本。然而，你不应过分被此类功能所左右。你需要的是一个最适合你组织和工作方式（现在以及未来）的解决方案，帮助你持续交付高质量的软件。

你们中的一些人可能听说过一个城市传说，认为源代码管理解决方案仅对软件源代码有用。像所有的城市传说一样，这种说法在很久以前是有一定道理的，但现在已经不成立了。源代码管理不应该仅限于软件源代码。任何可以、能够并且将会被更改的东西都应该进行版本管理，并存储在源代码管理系统中。我已经提到了一些例子，下面我们来详细扩展一下：

• 单元测试

• 测试用例

• 自动化测试脚本

• 软件配置/元数据

• SQL 脚本/SPROCS

• 文档

• 环境配置

• 服务器配置

• 任何可以被更改、编辑或保存的东西

一般来说，争议的焦点是环境/服务器配置以及其他一些工件集合，比如启动脚本和网络路由配置，有些人可能认为这些应该排除在源代码管理之外，因为它们属于运维领域，而不是开发领域。然而，随着你们逐步过渡到 DevOps，这种说法就不再有任何意义，且不再适用。经验法则应该是：如果它可以被更改，它就应该在源代码管理中进行版本控制。

DevOps 社区提到的一种方法是通过配置文件来表示给定的环境，并且这些配置文件可以（也应该）存储在源代码管理中，作为“配置即代码”。需要指出的是，这种方法源自开源社区，因此这种方法的一些方面最初可能并不完全适用——例如，管理 Windows 服务器更多是通过点击操作，而不是使用一组配置文件来管理 Linux 集群。然而，你也可以通过 PowerShell 脚本来管理 Windows 服务器，所以这也是一种选择。总的来说，你应该努力让给定环境/服务器/交换机/路由器/防火墙的每个元素都以配置文件的形式表示，并可以（并且应该）存储和版本控制在你的源代码管理系统中。这样，你就可以相对轻松地在某一时刻创建给定环境的精确克隆（稍后我们会讲到这个问题）。

一个可能成为阻碍的因素是安全性以及对源代码管理系统中文件内容的访问权限。例如，如果你将环境配置作为代码存储，理想情况下你不希望开发团队访问生产数据库连接字符串或 API 令牌。已经有了经过验证且文档化的方式来做到这一点（如掩码、加密、限制访问某些仓库等），所以如果你提前做好规划，这不应该成为障碍。

关于源代码管理的书籍和参考资料很多，它们在这个主题上有更深入的讨论，因此我在这里就不多赘述。只需说，如果你没有源代码管理解决方案，请立即实施一个。

如你所见，源代码管理解决方案对于持续交付（CD）和 DevOps 的采用是非常有价值的工具。除了拥有一个中央位置来安全存储源代码之外，将同样的方法应用于你的二进制对象和工件也是非常重要的。

二进制仓库

顾名思义，二进制仓库就是用来存储二进制对象和工件的地方。在软件工程术语中，二进制对象/工件是指源代码成功编译后生成的可执行软件。

二进制仓库的功能与源代码管理解决方案非常相似，但正如你所预期的那样，它们更适合存储二进制文件。一些解决方案还提供版本管理机制，甚至将二进制文件打包以便以后在目标环境中安装。

我们将在本章稍后讨论二进制仓库的重要性。现在，让我们继续讨论保持小而频繁变更的有价值实践。

小而频繁、简单的变更

保持小的变更意味着变更的影响——有时称为爆炸半径——也应该很小，风险减少，变更的机会增加。听起来过于简单，但这也是非常正确的。如果你考虑一个典型的软件工程团队每天做的变更次数，然后将其推广到你有的所有团队的变更次数，你很快就会发现这些变更会积累起来。如果你再将这个数字乘以版本发布之间的天数，你会发现变更量并不微不足道——这些变更的风险也同样不可忽视。

就风险而言，假设我们有一个由五个软件工程师组成的团队，每个工程师每天平均做 10 次代码变更——这就是 50 次变更。假设我们有 10 个团队都在做同样的事情——这就是每天 500 次代码变更。现在假设我们每 12 周发布一次版本（或 60 个工作日）；我们现在谈论的是 30,000 次需要上线的变更。即使我们有行业领先的测试覆盖率——假设是 99.9%的覆盖率——仍然有可能会漏掉一些问题。在这种情况下，就是 30 个未被覆盖的变更。简单来说，每 12 周可能会产生 30 个缺陷的风险。好吧，这是一种非常简化的方式，但希望它能说明一个问题——将大量代码变更聚集在一起远不是理想的做法。

一件可能不太显而易见的事情是，如果在发布后的第二天发现了一个可以通过单行代码修改来修复的简单缺陷会发生什么。如果我们按照前面的例子，那这个缺陷将在生产环境中再停留 11 周 6 天（假设我们无法进行紧急补丁发布）。发布周期的第一天所做的任何变更——包括客户功能请求——也会发生同样的情况。

如果我们将其拆解成更小且更频繁的发布——例如，每两周一次——并应用相同的数据，我们可能会看到类似以下的情况：

500 次变更 * 10 天 = 5,000 次变更发布，可能存在五个缺陷未被发现。

现在，假设如果在发布后的第二天发现并修复了一个缺陷，那么这个变更将在九天内上线。再次假设，如果在发布周期的第一天做了一个客户功能请求变更，它将在 10 天内上线。我想你会同意，这听起来比第一个例子要好一些。

以下图示可以某种程度上说明这可能会是什么样子：

大变更与小的增量变更

现在，我必须承认前面的例子非常简化，可能与现实不符，且由于外部因素，你可能目前没有频繁发布代码的奢侈（也许你的客户不希望——或者不能接受——频繁的发布，或者你现有的运维流程需要时间来支持这一点）；然而，这并不能成为你现在不采用这些理念的借口。如果你的软件工程团队习惯于以小且可发布的模块进行发布，他们就会养成持续交付的习惯。

另一种表达方式是，一旦你完全采用了持续交付（CD）和 DevOps，它们将必须在这种模式下工作，那么为什么不从现在开始适应它呢？

持续地进行小范围且频繁的变更也有助于其他方面；即减少复杂性、提高代码的可维护性并提升质量。如果工程师只需要更改少量代码，那么他们就有更大的机会重构周围的代码，减少复杂性并提高代码库的整体可维护性，包括增加额外的单元测试。另一个不太明显的好处是减少代码审查、拉取请求和合并的开销，这些过程可以更加频繁地发生，成为一种日常的事情，而不是繁琐的任务。

这种做法不仅限于软件工程，它同样适用于系统运维领域的变更。例如，对服务器配置进行小范围、孤立的调整（如虚拟服务器的内存分配）比一次性进行大范围变更要安全得多，且更容易控制和监控。如果你进行小规模的更改，你将有更大的机会看到这些变更是否对平台的整体运行产生了影响（无论是正面的还是负面的）。

进行小规模、渐进性的变更是一个非常有益的实践。然而，除非你有一些工具来帮助自动化构建软件，否则这将非常难以管理。

自动化构建

CD（持续交付）和 DevOps 采用的一个常见主题是如何使用自动化。如前所述，如果没有某种自动化工具或解决方案，将非常难以频繁地交付。你可能会读到这里并想，“嗯，这显然是显而易见的。”然而，即使在这个现代科技时代，仍然有一些软件工程团队在手动完成所有工作，使用手动步骤和/或手工编写的脚本——其中一些脚本的历史甚至比正在运行它们的工程师还要久远。幸运的是，这种情况如今已经非常少见，尽管我还是会介绍一些自动化的相关内容以及它为何对于 CD 和 DevOps 的采用至关重要，以防你正处于少数派。

每个进行更改的工程师——无论是软件工程师还是运维工程师——都需要反馈，以了解他们所做的更改是否有效（或者是否失败）。他们越早收到反馈，就能越早解决问题或继续进行下一个更改。从软件工程的角度来看，了解自己编写的代码是否能够顺利构建和/或编译，并且保持一致性，也是非常有帮助的，以便可以进行测试。

这种验证可以通过手动过程（或过程或脚本）来完成，但这可能会繁琐、不一致、容易出错、缓慢，且并不总是能够完全重复。缺乏一致性和可重复性，会增加额外的风险。

实施自动化将有助于加快进程，保持一致性、可靠性和可重复性，并且最重要的是提供信心。如果你反复执行相同的步骤并获得相同的结果，那么可以合理地推测该过程是有效的，且可以信任它。因此，如果你在软件、配置或环境中更改了某个部分，并且之前正常工作的过程失败了，那么很有可能是这个变更破坏了某些东西。

有很多工具可供用来构建/编译代码——这取决于你使用的开发语言——它们的功能基本相同：确保代码书写正确、语言语法符合预期、确保所有外部引用可用，并且——如果一切正常——创建可以运行的二进制文件。这是一个过于简单的描述，但希望能传达出要点。触发这个过程的方法有多种：可以通过命令行手动触发、通过脚本手动触发，或通过开发者的 IDE 来触发。无论使用哪种方式，你都应该认真考虑自动化该过程，以确保一致性和可重复性。

另一个需要考虑加入自动化脚本/流程的工具是代码检查（linting）。代码检查工具帮助扫描并检查源代码中的语法问题。这是一个非常有用的补充，因为如果在构建/编译代码之前使用它，能大大减少查找问题的时间——尤其是在代码库非常复杂时，这意味着构建时间可能是几分钟而不是几秒钟。同样，依据你使用的编程语言，有许多选项可供选择。

希望你现在已经对为什么自动化构建软件组件很重要有所了解。现在让我们集中讨论测试自动化。

测试自动化

传统的软件交付过程通常会包含一定的测试环节。然而，根据组织的不同以及软件的使用年限，测试用例的执行通常是一个手动过程。尽管如此，测试自动化已经存在了一段时间——与敏捷软件开发同时发展。然而，测试自动化并不像人们希望的那样普遍。我要指出的是，测试方法及其自动化是一个庞大的话题，我不会在这里涵盖所有内容。如果你需要更多的信息，我建议你做一些研究并阅读一些关于这个主题的好书。我们在这里讨论的内容相当基础，但应该足够让你理解测试自动化如何融入 CD 和 DevOps 的应用中。

测试主要有三种类型：

• 单元测试通常用软件的编程语言编写，用来测试代码库中的代码和逻辑路径。它们通常不会与任何特定的用例或功能区域对齐。

• 集成测试通常测试软件系统/平台中一个部分与另一个部分之间的交互方式（例如，确保登录页面正确调用身份验证服务）。

• 端到端测试通常集中于最终用户会启动的实际用例（例如，当成功登录后，欢迎页面会显示，且显示的文本语言正确）。

这是一种过于简化的视角，但希望能阐明不同类型的测试。

就工具和技术而言，用于创建、维护和运行自动化测试的选择有很多，不同的解决方案各有特点，选择最适合你需求的工具可能会很困难。从基本层面来看，这些工具基本上做的事情相同：它们协调测试脚本的运行并捕获结果。选择测试自动化工具是一个不应仓促做出的决定，我的建议是，像选择开发语言一样，给予这方面足够的思考。

你有时会听到“框架”这个词，特别是在研究如何加入单元测试时。它们基本上是预定义的（大多数是）行业标准方法。这意味着工具本身可能不同，但它们所遵循的标准是相似的。

在选择工具时，尽量考虑未来可持续性，特别是用于创建和维护测试的测试语言。像 Cucumber 这样的标准化工具是一个不错的起点，而且这是许多工具都采用的方式。如果你希望采用TDD和/或BDD方法进行集成和端到端测试，这会非常有帮助。

最终，你需要朝着广泛被称为“倒置测试三角形”的方向努力。本质上，传统的测试方法大多依赖于手动执行的测试，自动化和单元测试则较为少见。为了使 CD 和 DevOps 的采用成功，你需要改变这种比例，显著减少对手动测试的依赖，并增加自动化。关于这一点有很多文献支持，特别是在 CD 和 DevOps 方面，主要的优势是速度、可靠性、可重复性和一致性：

倒置的测试三角形

你可能会注意到，与传统三角形相比，敏捷三角形中单元测试层的相对大小。这是理想的情况，因为你拥有的单元测试越多，能够检查代码和代码中的逻辑流程，你对底层代码的信心就会越大。反过来，这也应当能增强你对更高级别测试的信心。一个不那么显而易见的优势是成本——编写单元测试比编写集成和/或完整的端到端测试便宜得多。

像 TDD 和极限编程（XP）这样的敏捷软件工程方法，遵循的前提是单元测试必须始终编写并通过，才能进入下一个测试阶段。

继续讨论自动化测试，有一件事确实会增加困惑，并且让人望而却步：采用测试自动化可能会让人感到非常令人畏惧——这还算轻描淡写。走这条路时有很多事情需要考虑：你需要覆盖多少代码库？如何在现实世界中模拟实际用户及其使用情况？你从哪里开始？

不幸的是，没有简单或通用的答案。当你开始查看关于这个话题的大量在线资料、书籍和信息时，这变得更加具有挑战性。更糟糕的是，其中的一些信息可能与其他的内容相互矛盾。我唯一能给出的建议是遵循简单至上的（KISS）方法。例如，你可以从绘制出一些主要且最常执行的用例开始（例如，登录/身份验证、用户从列表导航到购物车中的商品详情，或用户进行购买），并通过创建自动化测试来尝试一些工具以覆盖这些用例。只要你能够运行这些测试，并且结果是稳定、可靠和可重复的，那么你就应该走在正确的道路上。

使用 KISS 方法，即使只有一个自动化测试验证了代码库的一小部分，也总比什么都没有要好。

一旦你对整体的自动化测试过程建立了一定的信心和信任，就可以进入下一个用例——或者尝试另一种工具，直到你感到满意为止。

我还建议在覆盖率方面使用 KISS 方法——如果你可以覆盖 100% 的代码库和用例，那就选择这个数字。如果不能，那么找到一个可行的数字，并随着时间的推移增加它。我的意思是，当新增代码和功能时，不要让覆盖率百分比下降。设定一个里程碑日期和现实的百分比目标可能有助于保持紧迫感和专注力，避免在过程中丧失动力。

还有一组工具可以通过检查/分析你的代码库和源代码仓库（当然，这也包括你所有的自动化测试）来帮助你确定测试覆盖率，并提供有用的信息和仪表板供你查看。这些工具还可以为你提供历史视图，帮助你衡量覆盖率的增加（或减少）。

另一个可以应用 KISS 方法的地方是自动化测试中通常会让人头痛的测试数据问题。测试数据可能是一个巨大的问题，且可能带来更多问题而不是解决问题——并且还可能引发相当多的争论。一个好的经验法则是，将运行测试所需的测试数据作为自动化流程的一部分来创建——更重要的是——在最后一步将其移除。我见过太多没有遵循这一 KISS 方法的例子，这意味着你最终可能会得到过时的数据，这些数据很可能会很快变得不再适用。这些过时的数据可能导致以前运行正常的测试开始失败，或者更糟的是，其他人拿这些数据作为基础来编写他们的测试（这意味着即使你想清除它，也做不到）。它还会影响你确保测试一致性和可重复性的能力。

让我们看看我们的角色可以做些什么来提供帮助：

好方法	不太好的方法
Victoria（副总裁）应该积极关注测试自动化如何大大降低整体成本并提高质量保证的效果，并愿意提供预算和高层支持。	Victoria（副总裁）将此视为一种裁员/降低成本的解决方案，并削减预算以获得最优惠的交易，而非团队所需的最佳解决方案。
Stan（经理）应该确保在领导层、同级团队及团队内部清楚地传达相对重要性。他还应该确保最相关的资源在组织内得到分配和协调。	Stan（经理）不愿了解测试自动化带来的好处——他把这看作是开发后的质量保证工作，对此不感兴趣。
Devina（开发人员）和 Oscar（运维人员）应该花时间理解、调查并接纳测试自动化，作为与软件开发并行的日常活动。	Devina（开发人员）和 Oscar（运维人员）忽视测试自动化，因为已经有团队在软件构建完成后进行测试，那这样做有什么意义呢？

到目前为止，我们尚未讨论的是可以运行、管理和控制这些自动化的工具。这正是持续集成解决方案发挥作用的地方。

持续集成

持续集成，或更常见的 CI，是一种经过验证的方法，用来确保正在开发的软件资产能够正确构建并与代码库中的其他部分良好协作。这里的关键词是持续，顾名思义，它是尽可能频繁的（理想情况下是在每次提交和/或合并到源代码控制系统时）。最简单的理解 CI 解决方案的方法是将其视为一个工具，用于协调构建和测试自动化工具——我们刚刚讨论的这两项内容。

如你所猜测的那样，市面上有大量成熟的 CI 解决方案，既有商业版也有开源版，因此没有理由不选择一个并使用 CI。

如前所述，CI 解决方案是一个非常基础的、协调构建和测试自动化执行的软件解决方案。执行是由许多人所称的CI 任务控制的，当某些事件发生时，这些任务会被调用；例如，当代码提交并/或合并到源代码控制库时，或按定时计划执行，或当另一个自动化工具触发 CI 时，等等。这些任务包含一个活动列表（通常被称为步骤），需要快速连续地执行；例如，从源代码控制中获取最新的源代码，编译为可执行文件，将二进制文件部署到测试环境，获取源代码中的自动化测试，并运行它们。

如果一切顺利，CI 任务会完成并报告成功。如果失败，它会报告失败并提供详细的反馈，解释失败的原因。大多数工具还允许你深入查看失败的步骤，了解哪里出了问题。每次运行给定的 CI 任务时，都会为你写入完整的审计日志，你可以回顾并比较结果和/或随时间变化的趋势，如下所示：

一个典型的 CI 流程

CI 工具非常强大，你可以构建简单的逻辑来控制流程。例如，如果所有自动化测试都通过，你可以自动将可执行文件（可能已嵌入构建版本号）移至二进制仓库，或者如果某个环节失败，你可以将结果通过邮件发送给工程团队。你甚至可以构建仪表板或信息显示器，以便提供即时、易于理解的可视化表示，展示当前的情况和结果。

CI 解决方案是 CD 的必备工具。如果你频繁地构建和测试软件变更，你就能频繁发布。

CI 对传统系统操作变更的优势并不那么显而易见，但它们在尝试更改而不影响生产平台方面可以提供很大帮助。例如，假设你有一个 CI 解决方案，正在对一个隔离的测试环境运行多个自动化夜间测试。这些测试已经成功通过（通常称为绿色）好几天了，所以你有信心一切正常。然后，你对服务器配置进行了更改并重新运行 CI 套件，结果失败了。唯一的变化是服务器配置，因此它一定产生了不利影响。这是 DevOps 方法应用的一个很好的例子。

实施 CI 并非易事——尤其是当你没有任何自动化工具可用时。然而，CI 是一个非常强大的工具，能大大减少使用手动方法进行系统更改构建和测试的开销与风险。就实际情况而言，如果没有 CI，尝试实现 CD 将是一个非常艰难的过程，因此我的建议是咬紧牙关，实施 CI。

在本节中，我们一直在讨论如何自动化构建和测试，以确保软件可以被验证和交付。我们还提到了一些结果，整体来说应该是积极的——自动化构建必须完成，自动化测试需要通过，才能进入下一阶段。换句话说，如果测试失败，那就不好了。总体上，这是正确的。然而，失败也可以是好事，只要这些失败是在流程的早期发现的。

快速失败并频繁失败

快速且频繁地失败可能看起来反直觉，但这是一个非常好的工作理念。如果一个缺陷被引入，但直到它已经上线后才被发现，修复这个缺陷的成本是很高的（可能需要完全新的发布版本），更不用说它可能对您的客户、声誉和可能的收入产生的影响了。尽早发现缺陷是必须的。

敏捷工程方法如TDD或BDD基于在软件开发过程的早期阶段找到和解决软件中的故障的原则，其简单前提是在编码开始之前编写测试来覆盖软件需要满足的某些/所有用例——这个比例通常称为覆盖率。随着代码的编写，这些测试可以作为持续集成过程的一部分反复运行，以发现漏洞。如果在此时测试用例失败，这是件好事，因为唯一受到影响的是编写代码的软件工程师，而不是您的客户。

这听起来可能有些奇怪，特别是对于管理者来说，但如果早期发现缺陷，您不应大惊小怪，也不应责备人员。回想一下我们对责备与学习行为的理解。您想要的是找到问题，弄清原因，修复它，从中学习，然后继续前进。

有时会妨碍实施 TDD 等工程实践的事情之一是软件平台本身的规模和复杂性。为不围绕这些原则构建的软件系统回顾性地实施测试套件可能是一项非常艰巨的任务。如果是这种情况，从小处着手逐步构建可能是明智的选择。

我们现在将远离软件构建和测试自动化，转向在采用持续交付（CD）和 DevOps 时可能遇到的挑战，特别是与软件系统/平台的设计和架构相关的挑战。

架构方法

尽管科技界媒体和穿着牛仔裤 T 恤的会议演讲者让您相信大多数企业都在运行现代软件架构，但事实并非如此。实际情况是，世界上大量的软件平台和系统经过多年发展，其中一些（多数）相当复杂和笨重，难以维护或推进。即使是年轻和时尚的科技公司也在运行和维护被视为遗留解决方案和平台的少量大型可执行文件，这些文件都是在构建和测试后一起交付的。这并不意味着不能使用或采用 CD 和 DevOps 原则，只是意味着需要更多的工作。

立即反应可能是花费大量时间、精力和金钱将整个软件平台转型为一个新的参考架构模型，以实现 CD 和 DevOps 的无缝接入。如果你足够幸运，拥有深谙此道的高层领导并且他们有充足的资金，那么祝你好运。大多数人并不这么幸运，因此我们需要在方法上更加富有创造性。

如果你要研究最佳的参考架构种类，这可能会让人感到有些望而生畏，因为你会发现关于什么是最佳方法存在许多不同的看法（往往各不相同）。更不用说，采用和实施该架构的方式有很多且各异。如果你足够幸运，拥有一位高瞻远瞩的愿景者，他能凭直觉知道该怎么做，那么你就已经有了一个好的开端。实际上，最终你得到的将是一个目标架构，以及通过所谓的遗留系统“勒索”来实现这一目标的计划——这是一种系统性地用更现代的方法设计和构建的软件组件替换遗留平台部分的方式，重点是特定的功能（以及非功能）领域。

尽管遗留解决方案是个痛点，但在 CD 和 DevOps 的采用过程中，它们并不是世界末日。需要考虑的限制因素包括每次进行更改时，必须构建、测试和部署整个平台的需求，以及完成这一过程的整体时间，这可能需要几分钟（有时是几个小时），具体取决于平台本身的规模和复杂性。

这时创造力就派上用场了。假设你的遗留平台构建需要 30 分钟，而自动化测试套件的完成需要 90 分钟。每进行一次更改并希望测试，就需要等待两小时。将这一时间扩展到所有做更改的工程师身上，这简直无法承受。大多数人会通过只在特定时间触发 CI 作业来克服这个问题——例如在工作日结束时——这样时间就不会延续到工作日中。这确实在某些方面有所帮助，但也增加了一个风险，那就是整个构建可能由于一个简单的错误、缺陷或拼写错误而失败，从而阻碍其他所有更改和工程师继续下一个任务。

你可以通过对流程进行一些小的调整来克服这一问题，使其变得（稍微更）可行。例如：

• 将测试套件拆分成更小、更独立的测试包；例如，在构建完成时使用一部分测试（有时称为烟雾测试），并且在晚上进行完整的测试。

• 为你的构建和/或自动化测试服务器增加更多的计算能力。

• 实现一个集群化的 CI 解决方案。

• 将 CI 作业并行化（你需要更多的计算能力/集群化）。

• 改变软件构建方式，使得只有自上次构建以来有变化的部分才会重新构建（也就是说，每次只构建增量，而不是整个平台）

最终，你希望减少构建、测试和发布遗留软件所花费的时间。你在这方面取得的进展越多，就能为自己争取更多时间，去将遗留平台拆解成更小的、可以独立构建、测试和发布的软件组件。即使是最集成、最紧密耦合的软件平台，也由许多小组件组成，它们之间相互通信。

如果你退后一步，回顾一下你的遗留平台，你可能会发现实际上你可以将它（或至少大部分部分）拆分成小而易于管理的模块（共享库、不同技术层、打包解决方案等），这些模块可以独立并快速地构建和测试，更重要的是，它们可以频繁地发布。

基于组件的架构

如前所述，如果你有幸能够重新设计你的遗留平台——就像 ACME 系统那样——那么你应该花时间考虑最适合你需求的方法。理想情况下，你应该选择一种技术或架构方法，允许将平台拆解成小而独立的模块或组件，并且这些组件之间是松耦合的。我的意思是，每个组件都可以独立开发、构建、测试和发布，而不依赖其他组件。

这种方法多年来有许多名称——如 Web 服务架构、面向服务架构（SOA）或微服务架构——但从基本层面来看，它们几乎是相同的：一种架构方法，允许松耦合的、自包含的软件组件共同工作，提供通常会作为完整单体平台交付的功能，示例如下：

一个典型的架构比较

采用这种方法，你将拥有小而独立的软件组件，它们可以被开发、测试，且更重要的是，可以独立发布。这大大有助于实现持续交付（CD）的好处。

这种方法的另一个优势是节省成本，这与持续交付（CD）或 DevOps 并没有直接关系。基于组件的架构不仅允许频繁的小规模变更发布，还可以减少对大型昂贵 IT 基础设施的需求。例如，如果你现在有一两块庞大的代码，你就需要一两台巨大的服务器来运行它们。然后你还需要一两台庞大的数据库服务器——为了实现灾难恢复，你还得有另一套服务器在等待。想一下，要获得并维持这些服务器运行的成本有多高。使用许多小组件，你可以考虑更具成本效益的托管方式——我们稍后将讨论这个问题。

有大量的选项和信息可以帮助确定最适合您当前和未来需求的方法。可以这么说，如果您能够朝着基于组件的架构迈进，发布时的痛苦和开销将成为过去。

在这里需要注意的一点是，如果您采用基于组件的架构（顺便说一下，您应该这么做，万一不够清楚的话），如何发布这些组件。可能会有诱惑使用与遗留平台相同的将所有内容合并为一个大版本的方法，但这将只会导致一堆痛苦，并且根本不会给您带来任何优势。稍后我们会讨论持续交付工具，因此请继续阅读。

让我们看一下另一个可能的解决方案，它可以帮助解决遗留系统的限制问题，并使您更容易向基于组件的架构理想迈进。

抽象层

如果您的平台中有复杂的依赖关系，尝试通过使用某种形式的抽象来分离软件资产可能会有所帮助。这个技术应该有助于去除，或者至少减少平台内的硬依赖，并帮助您朝着基于组件的架构迈进，进而为您提供采用持续交付（CD）的机会。

举个例子，假设您有两个必须一起部署的软件组件，因为它们被硬性耦合在一起，无法单独部署，否则会导致平台停机。那么您将很难遵循小幅增量变更的方法，更不用说您将很难做到在不出现停机的情况下发布了。

有许多成熟且经过验证的设计模式可以为实现这一目标提供一些不错的方法，但至少，移除尽可能多的紧密依赖是一个好的实践，这样您就不会最终拥有一堆需要一起部署的资产。

一个常见的紧耦合领域是软件和数据库之间。这意味着对其中一个的更改可能意味着两者都需要进行测试和发布。在这里添加抽象可能和在两者之间添加数据访问层代理一样复杂，或者像使用 SQL 视图一样简单。另一个问题区域是 UI 和业务逻辑代码捆绑在一起，这同样可以通过遵循标准设计模式来分离。无论采用何种方法，目标都是一样的：能够独立构建、测试和发布软件组件。

作为额外的作业，您应该花些时间查看并分析现有平台中的区域，找出那些紧密耦合的组件，然后看看如何添加抽象层，使得每个组件都可以独立工作而不影响其他组件。您还可以查看快速变化和缓慢变化的区域（例如，哪些软件组件是定期更新的，哪些非常少更新），因为这可能帮助您找出哪些组件需要首先分离。

永远不要破坏您的消费者

你的软件平台可能会很复杂，并且有相当多的依赖关系——这并不丢人，实际上这是非常正常的。这些依赖关系可以被分类为消费者和提供者之间的关系。提供者可以是任何东西，从共享库或核心代码模块到数据库。消费者将根据某些预定义的接口规范（有时称为服务合同）以特定方式调用/执行/发送请求给提供者。

一个简单的例子是，网页利用共享库返回内容来渲染和显示用户的地址信息。在这种情况下，网页是消费者，共享库是提供者。如果共享库最初返回了四个数据项，但被更改为只提供三个，消费者可能不知道如何处理这种情况，可能会抛出错误，甚至更糟糕的是，直接崩溃。当然，你可以添加一些防御性代码，但实际上，这只是由于懒惰的变更管理而增加了更多复杂性。

大多数软件平台都有许多依赖关系，这意味着有时很难发现是哪个提供者发生了变化，导致众多消费者中的一个失败——特别是当你考虑到一个消费者也可能是另一个位于堆栈上游的消费者的提供者时（也就是说，一个共享库，它从数据库中获取数据，然后提供这些数据给网页，网页再消费这些数据，并将其提供给 JavaScript 客户端，等等）。

要了解这种情况有多普遍，你需要进行一些影响分析，帮助你将其映射出来。提前提醒，除非你能够将整个平台映射成一个易于理解且始终保持最新的格式，否则这将是一项艰巨的任务。幸运的是，有许多成熟且已建立的模式可以解决这些问题，还有一些工具可以帮助进行分析。

另外，有助于做的是建立一些规则，来规范如何处理未来的更改。简单来说，如果你正在更改软件、配置或数据库，而这些更改将被平台的其他部分消费，那么做出更改的人有责任验证该更改没有破坏任何上游或下游的内容。如果你已经建立了 CI 和自动化测试，那有助于尽早发现问题。然而，简单地在代码审查/拉取请求过程中增加一些谨慎态度既便宜又容易，而且有助于巩固良好的行为。

在系统操作领域，“永远不要破坏你的消费者”规则也应该适用。例如，软件平台可以被视为服务器操作系统（提供者）的消费者；因此，如果你更改或升级操作系统，必须确保没有任何破坏性更改会导致消费者失败。

有时候，破坏性更改是无法避免的（例如，组件之间的服务契约必须发生变化，以容纳新的功能）。然而，这应该是例外而非常规，并且你应该提前规划好应对这种情况的策略。一个示例策略是支持并行版本管理，这将允许你同时运行多个版本的软件资产——这一点我们稍后会讲到。

消费者/提供者关系可能会失败，原因是负责提供者的一方人员或团队没有意识到这种关系。对于系统运维领域中的提供者来说，这一点尤为真实。为了克服这个问题，或者至少尽量减少风险，使用开放和诚实的同行合作实践。

开放和诚实的同行合作实践

今天有许多不同的敏捷软件交付方法论，但它们都围绕着某种形式的高度协作的工作方式和自由流动的沟通展开。像XP、配对编程或简单的代码审查过程等敏捷方法，都依赖于工程师们紧密合作。

我不能过分强调与他人分享你工作的必要性。即使是地球上最优秀的软件工程师（或系统管理员）也是人，他们会犯错。如果你认为自己的代码是珍贵的，不想与其他人分享，那么你会制造缺陷，并且会花费更长的时间来解决小错误，这可能会导致几个小时的困惑，或者更糟糕的是，对你的客户产生不利影响。

如果你对自己的代码质量非常自信，并且能经得起推敲，那么就不要把它藏起来——说到做到，分享你的工作。如果你没有那么有信心，与同行分享将帮助你建立这种信心。有一点需要指出——就软件工程师而言——同行小组不应该仅仅由其他软件工程师组成；运维团队也可以（并且应该）参与到这个过程中来。看起来可能有些奇怪，因为他们可能无法真正阅读你的代码（虽然你可能会惊讶于有多少系统管理员能够读懂代码），但是他们了解在线平台是如何运行的，可能会提供一些有价值的意见和/或提出一些相关问题（例如，代码在网络中断时会做什么，长期运行的线程会如何，或者为什么不使用连接轮询）。这也有助于推动 DevOps 的思维模式和方法。对于运维团队所做的更改，同样的规则也应该适用。

综合考虑，世界上大多数高质量的软件都是通过高度协作的方式构建的，因此你没有理由不采取相同的方法。尽管一些极端主义者可能会嘲笑这种做法，但请考虑这一点：这些人很可能会称赞基于 Linux 的操作系统，而如果他们仔细想一想，实际上，像大多数开源软件一样，它们也是通过高度协作的方式开发的，从一开始，协作就已是开发过程的一部分。

在运营团队中，与开发团队一样，拥有一个开放、诚实、透明的同行评审过程同样重要。对平台的任何部分进行更改都伴随着风险，而让不止一双眼睛来进行审查有助于降低这种风险。就像软件代码一样，系统配置更改也没有理由不进行共享。

一种通常被忽视的好处是，如果你的代码（或配置更改）未能通过同行评审，对生产系统的影响就会被消除。关键在于快速失败，而不是等到发布到生产环境才发现它失败。

假设你已经意识到这一点，并决定转向一个松耦合的基于组件的架构，该架构是采用最佳实践编写的，现在你准备迈向软件工程演进的下一阶段。

现在大家都在一起合作愉快，我们将进入下一个挑战：如何重新调整更广泛业务方面的期望，特别是在发布和功能交付方面。

功能的增量交付

之前我们讨论了将工作分解成小的增量块，以便能够快速交付和发布。你还需要考虑如何处理功能。这里我指的是那些以商业驱动的交付物，它们最终转化为收入。通常，你会有一个为期一年的商业计划，这个计划由若干个关键举措组成，需要在这一年内完成，而这些举措又进一步细化为一些功能，这些功能最终将被营销并卖给客户。从业务流程的角度来看，这是非常正常的。

请注意，你们公司内部使用的术语可能会有所不同，可能会使用如史诗（epics）、主题（themes）、目标（goals）或最小可行产品（MVP）等术语。实质上，我们将重点讨论的是：将一个能够为企业带来收益的东西交付给客户的时机。为了简化起见，我将这个东西称作“功能”，而交付给客户的时机称作“发布”。

持续交付（CD）和 DevOps 的采用如何影响这一点，确实取决于当前的发布节奏，但我敢猜测，你会看到一个以月或季度为单位的节奏。一旦 CD 和 DevOps 嵌入到流程中，你将会看到每次发布之间的间隔从几周、几天甚至几小时。这无疑是好事，但我们还是花点时间考虑一下更广泛的影响：

• 更广泛的业务部门目前可能期望在每个发布周期内完整交付一个功能

• 销售、营销、法律和支持等业务职能将会有相应的流程来应对这一情况

• 你将大幅度缩短发布周期，并逐步交付变更

更广泛的业务部门该如何应对这一变化？功能什么时候可以准备好？他们应该何时开始行动？他们该如何告诉客户？

你需要与这些业务领域合作，并就如何在多个发布周期中逐步交付功能达成一致。你应该考虑并讨论以下几种方法：

• 分阶段交付端到端体验，并在多个发布周期中逐步丰富功能，直到功能完成

• 专注于某一功能领域直到完成，然后再转向下一个，依此类推，直到功能完成

• 在多个发布周期中逐步构建功能，但在完成之前保持其隐藏

值得考虑的是，像第一种和第二种方法可能会开启像 alpha/beta 版本发布这样的途径，这意味着你可以提前获得客户反馈；而像最后一种方法则意味着你无法提前获取反馈，但上线过程相对简单（因为你已经发布了代码，上线实际上就是“打开”）。无论你选择哪种方法——你必须选择一种——你都需要确保那些期望“发布等于功能交付”的人得到教育，并调整他们的期望。

现在我们将回到一个更技术性的领域：确保在所有环境中部署相同的软件

在所有环境中使用相同的二进制文件

在软件资产可以在给定环境中使用之前，它必须已经被构建/编译成可执行文件或二进制文件。这个二进制文件很重要，因为它是将在你的环境中运行时执行的软件版本。可以将其看作是一个时间快照。有些人会说源代码比二进制文件本身更重要，因为二进制文件只是副产品，可以一次次重建，尽管这并不完全准确。

你不会对源代码进行功能性、回归、性能或负载测试，而是对二进制文件进行测试。因此，重要的是要像对待源代码一样对待生成的二进制文件。如果你采用并行版本控制和/或在 CI 过程中嵌入版本信息，这一点就显得尤为重要。例如，如果你的 CI 解决方案生成了版本 1.2.0.1 的二进制文件，那么你应该使用并测试的是版本 1.2.0.1。

理想的、推荐的做法是，二进制文件仅在某个特定版本/部署时构建一次，并且在所有环境中使用完全相同、未经修改的二进制文件，包括生产环境。这听起来像是常识，但有时由于软件设计和/或工具的原因，这一点会被忽视，或者干脆做不到，或者更让人担心的是，它没有被视为重要。

工具/软件设计的一个限制例子可能出现在与环境相关的软件令牌或配置（有时称为机密）上。以数据库服务器的凭据为例。有些人会说，因为这些数据非常敏感——特别是在像生产环境这样的高权限环境中——它应该只对少数几个人可见。一种解决方法是在编译时将这些信息嵌入到二进制文件中，这样就可以确保它的安全。这种方式确实不错，但我们只想构建一次，因此你必须在所有环境中设置相同的凭据，包括完全开放的开发环境——你肯定会同意，这远不是安全的。这个方法的另一个缺点是，有人可能通过逆向工程获得二进制文件，并获取凭据，而你却毫不知情。而且，如果这些凭据泄露并需要更改，你该怎么做呢？

你始终可以为每个环境构建多个二进制副本（每个环境一个）；然而，这样你又得测试不同版本的软件。

解决这个问题的行业标准方法有很多，但简单的方法（似乎对大多数企业来说都很有效）是将这些数据保存在启动脚本或系统配置文件中（当然，这些文件是版本控制下的），并在运行时由软件加载它。如果你限制对这些配置文件/脚本的访问，就有很大的机会保持它们的机密性。无论你选择哪种方法，都应该确保它允许你使用相同的二进制文件。

如前所述，使用二进制仓库也能让你存储某个二进制文件的多个版本，这意味着回滚到先前版本会变得相对简单。

现在我们已经了解了如何将软件交付到每个环境，接下来看看你需要多少个环境。

多少个环境才算足够？

这个问题从软件开发诞生以来就存在。不幸的是，无法给出一个简单的答案，尽管有一些常识性的、经过实践检验并得到信任的方法多年来一直有效。当我谈论环境时，我不仅仅指服务器；我指的是服务器、基础设施、网络、防火墙、第一方和第三方集成等。实际上，就是你运行软件平台所需的一切。

回到我们讨论的问题，（相当平淡的）答案是：你需要的环境数量取决于你的工作方式、工程设置以及平台架构。当然，还有一个因素需要考虑：管理和维护多个环境的开销，以及保持它们运行和健康的成本。可以肯定地说，你不应该做得过头；尽量采用少即是多的方法。

也可能会有一种诱惑，想要为不同的场景设置不同的环境：开发、功能测试、回归测试、用户验收测试、性能测试和负载测试。如果你能确保所有环境都能够保持最新（包括至关重要的测试数据），并且能够轻松部署到这些环境中，更重要的是，需要所有这些环境，那么这种做法是可行的。现实情况是，环境过多实际上可能适得其反，造成太多的噪声和负担。

理想的环境数量是两个：

• 一个用于开发

• 一个用于生产

听起来这可能像是一个意外即将发生，但如果你仔细想想，很多小型企业和初创公司在这样的设置下都能顺利运作。你会发现，随着企业的成长，对风险规避的需求也随之增加，因此可能会需要多个环境。

当 ACME 系统刚开始时，两个环境就足够了。随着公司的发展，环境的需求也在增加，最终他们有了多个开发环境（每个工程团队一个），一个集成环境，一个性能测试环境，一个负载测试环境，一个预上线部署环境，当然还有生产环境。最终，他们还成立了一个专门的团队，负责维持这些环境的运行——实际上，他们成立了两个团队：一个负责工程和测试环境，另一个负责生产环境。远非理想或高效。

你可能会认为，现在虚拟化技术（包括基于云的虚拟化）已经高度成熟，并且被广泛应用，设置和运行数百台服务器不再像以前那样是一个巨大的负担。这个想法是有道理的，但真正的挑战在于如何保持一切井然有序——软件版本、操作系统补丁级别、网络配置、防火墙配置等等。因此，虚拟化在某些方面确实有帮助，但“需要多少个环境”这个问题仍然存在。

无论你做出什么决定，可能都会有一个麻烦：如果你的生产环境被锁定在一个高度安全的数据中心，你几乎无法访问，或者更糟糕的是，由第三方完全管理，这可能会对你的少即是多方法产生巨大影响。如果是这种情况，那么你真的需要让那些管理这些环境的人紧密配合你正在做的事情——如果不这样做，可能会破坏你的 DevOps 采纳。

让我们继续看一个现实世界的例子，看看 ACME 系统是如何处理这个问题的。当他们回顾为持续交付（CD）和 DevOps 所需要的环境时，他们认为以下环境足以满足他们的需求：

• 开发环境：平台的精简版本，只包含本地测试所需的少数平台组件

• CI 环境：软件构建和所有自动化测试定期运行的地方

• 预生产环境：用于偶尔的抽查/用户验收测试（偶尔是关键字）

• 生产环境：这是所有操作发生的地方

下图展示了所使用的环境：

ACME 系统 3.0 环境设置

如你所见，这遵循了少即是多的方法，并允许足够的质量门控，以确保给定的更改是充分的。当与所有前述的工程最佳实践（高水平的测试覆盖率、构建自动化、CI 工具等）结合使用时，给定更改的交付速度可能只需几分钟。

好吧，这有点理想化，现在你可能离这个目标还有一段距离，但希望你能看到它有多简单，并且希望你能稍微接近回答需要多少环境的问题。

现在让我们看看另一种可能的环境相关解决方案，它可以帮助加速您的交付能力。

在类似生产环境中进行开发

有很多方法可以确保一个版本的软件二进制文件能够正常工作或与平台的其他部分进行集成，但迄今为止，最简单的方法是实际上在一个包含平台实时版本的环境中进行开发。

从理论上讲，这可能看起来像是一个奇怪的说法，但如果你仔细想想，你正在更改整体平台的一部分——就像持续交付（CD）的方法那样——你希望尽快验证并交付这个更改。这样做的好处是，您可以确保您期望在生产环境中可用的依赖项确实存在并按预期运行，同时还包括配置和基础设施。

当与基于组件的架构结合使用时，这种方法将产生最大价值，但一些方面也适用于传统平台。

最简单的方法是直接在生产环境中进行开发，但这种做法风险极高，你可能会无意中导致服务中断。还有安全/访问问题。因此，最好的做法是设置一个类似于生产环境的环境，包含在生产环境中运行的代码版本。

你可能会觉得在类似生产环境中进行开发有些过度，或许你会疑惑为什么不直接在 CI 环境中的软件版本上进行开发。答案很简单：你无法确定 CI 环境中哪些更改后的二进制文件会在你之前被推向生产环境。例如，如果你正在开发和测试身份验证组件的版本 1.2.0.3（随便挑选一个版本），而当你的二进制文件进入生产并开始与版本 1.2.0.1 进行交互时，你可能会遇到开发/测试阶段没有发现的问题。

如果有人正在测试一个重大变更，需要确保在将其发布到生产环境之前，已经涵盖了所有场景，这一点尤其重要，在发布到生产之前。

这个类似生产环境的设置仅需要在软件（和基础设施）版本上与生产环境相似。如果你能用实际数据填充它，那将更好，但实际上，你需要一个和生产环境一样大的存储空间，这会很昂贵。更不用说暴露机密数据并违反数据保护法规（如 GDPR）的风险——除非你有办法对机密数据进行脱敏处理（这又是一个完全不同的挑战）。

为了让你了解这一过程如何运作，以下图表概述了 ACME 系统如何实现这种设置：

ACME 系统 3.0 使用的类似生产环境

正如你所看到的，类似生产环境被添加到部署流水线的末端。它之所以放在末端，是因为你只想在成功部署到生产环境后才进行部署到这个环境。

需要注意的是，当我们谈论类似生产环境时，这不一定是一个物理服务器集群。你可以考虑虚拟化（云端或桌面虚拟化），通过这种方式，你几乎可以在开发者的工作站上创建一个生产环境的副本（前提是有足够的计算能力和存储空间）。

既然你已经开始搭建实现采用持续交付（CD）和 DevOps 目标的所有基础组件，我们还有一些额外的组件你需要了解，那就是如何将完全构建和测试通过的软件组件以一种受控、可靠且可重复的方式穿越各个环境。这正是 CD 工具发挥作用的地方。

CD 和 DevOps 工具

还有另一组工具，可能不像上述工具（自动构建和测试、CI 等）那样随处可得。这些是您将用来控制和编排整个软件交付生命周期的工具，从构建二进制文件（通过 CI）、将这些二进制文件部署到各种测试环境，以及如果一切顺利，推送相同的二进制文件到生产环境。在非常简单的层面上，这些工具充当工作流引擎，其中每个步骤被定义为执行特定操作，然后流程继续移动到下一个任务。它们还内置了基本逻辑来捕获流程中的异常（例如，如果测试失败，则不要继续并发送通知）。这种工作流程类比通常称为 CD 管道、交付管道或仅管道。

在过去几年中，持续交付和 DevOps 工具市场从几乎无到成为一个价值数百万美元的全球行业。现在有大量工具和供应商想要向您销售工具，选择一个或两个符合您需求的工具已变得非常困难。就像您软件开发生命周期内使用的任何工具或技术一样，您需要可靠的持续交付和 DevOps 工具，它们能帮助而不是阻碍，并且随着您的采用成熟而成长。我还敢猜测，您可能已经有一些管理软件交付/部署的工具，因此您可能需要考虑一些能够与现有工具集成或完全替换它的东西。

选择的工具将被日复一日地使用，并且将被严重依赖，因此最好确保它符合您的需求，并且在需要时可靠。为了帮助您，您可以使用类似以下的内容，这将在选择工具/供应商以及尽职调查期间提供帮助。

以下是您应该询问 CD 和 DevOps 工具/供应商的一些示例问题：

• 它能够将相同的二进制部署到多个环境中吗？

• 它能够访问我们正在使用的二进制和源代码仓库吗？

  它能够远程调用和控制安装过程在其部署到的服务器上吗？

• 它有功能来允许它编排我的当前工具集吗？

• 它能够部署数据库变更吗？

• 它有功能允许排队发布吗？

• 它能够并行运行管道吗？

• 它包含已部署内容的审计，包括何时部署和由谁部署的吗？

• 它是否安全？

• 它是如何托管的（SaaS、PaaS、本地等等）？

• 它是否能与基础架构互动，以允许无停机部署？

• 它能够/可以编排自动化基础设施提供吗？

• 它能够与其他系统和解决方案进行交互，例如电子邮件、协作工具、变更管理、问题管理和项目管理解决方案吗？

• 它是否有简单易懂的仪表板，可以在办公室周围的大屏幕上显示？

• 它能与 CI 解决方案互动并/或协调工作吗（我们的当前解决方案和其他行业领导者）？

• 它会随着我们的需求增长而扩展吗？

• 我们需要什么技能/经验来运行它？

• 它是否足够简单，人人都能使用？

• 我们获得什么支持/SLA？

• 我们在价格中包括了哪些设置/实施支持？

• 那么高可用性/故障转移呢？

• 升级工具本身的过程是怎样的？

此时，如果我列出大部分市场领先工具并告诉你它们的优缺点，那将非常有帮助。然而，根据你阅读本文的时间，这些信息可能已经过时了。无论如何，这本该是你自己做的事——你比我更了解自己的需求、要解决的问题和预算。当然，这不言而喻，但我还是要提一提：工具的选择应该按照真正的 DevOps 风格进行，开发和运维都应该深度且平等地参与其中。

在选择 CD 和 DevOps 工具时，有几件事需要考虑：不要在预算上吝啬，因为工具将成为你交付流水线的核心；不要仅仅依赖市场上的大牌工具，因为它们从长远来看可能会过于局限；如果有可以通过定制解决方案填补的空白，你应该认真考虑，而不是创造出另一个需要维护的遗留问题。

你可能已经注意到，自动化配置是这里提到的一个考虑因素。现在，让我们深入了解一下这意味着什么。

自动化配置

过去几年中的常态是从传统的金属和电缆物理服务器以及基础设施转向虚拟化的等效解决方案，无论是在本地、数据中心托管，还是基于云的。我不会过多讨论某一类比另一类更具优势——再说一次，如果你有兴趣深入了解，这里有很多丰富的信息——但是我会重点关注一个在规划迁移到虚拟化环境解决方案时并不总是显而易见的因素：将自动化配置作为 CD 和 DevOps 流水线的一部分。

配置并不是什么新鲜事；只要云服务商存在，他们就一直在为客户提供可以按需配置的云基础虚拟化服务器。你还可以自由定义服务器的配置和设置，包括计算能力、存储、网络、操作系统以及位置/区域。除此之外，当这些服务器不再需要时，它们可以被删除（有时称为销毁）。

现在，考虑一下如果将自动化供应作为 CD 管道中的一个步骤会有多有用。你不仅能够控制和协调软件交付生命周期，还可以即时创建环境，安装软件，运行测试，然后销毁它们。这带来的巨大优势是可预测性和可重复性。如果你能保证每次启动 CD 管道时，都会从零开始创建完全相同的标准环境，那么你几乎可以消除某些人喜欢称之为环境问题的情况——这也是我们稍后会讨论的内容——这些问题不断地在测试步骤中产生噪声和虚假阴性（或阳性）。

正如你所预料的那样，围绕这种活动存在许多行业术语，它们往往使事情变得复杂——最常见的术语是基础设施即服务（IaaS）和 PaaS——但归根结底，这就是能够通过编程与供应系统接口，告诉它你想要的规格、配置等，最终让它输出相应的结果。当你完成时，再通过编程接口来删除环境。

传递给供应系统的需求清单，定义了服务器的规格、CPU、GPU、RAM、存储等，通常被称为配方——根据工具的不同，可能有一些变体，但它们基本上是相同的。

在自动化供应过程中需要考虑的一个问题是你可能在 CD 管道中遇到的时间延迟。例如，如果你将一个二进制文件部署到一个预建的服务器上，那么所花的时间就是部署的时间。将自动化供应加入其中，CD 管道必须等到新的虚拟服务器被供应出来，才能部署你的二进制文件。你需要权衡的是质量、可重复性和可预测性与速度和便利性之间的重要性。仅仅因为某件事更快并不意味着它更好。为了解决这个问题，你可以提前制作一些标准的虚拟服务器镜像，这些镜像可以通过自动化供应工具作为 CD 管道的一部分加入到环境中。这样，你就可以在更短的时间内获得一个全新的虚拟服务器。事实上，这正是许多领先的云服务提供商的操作方式。这种方法有一定的开销；需要有人保持这些标准虚拟服务器镜像的更新和新鲜，操作系统的补丁问题尤其麻烦。同样，你需要权衡利弊。

自动化配置的一个巨大优势是蓝绿部署。严格来说，这种方法在自动化配置成为主流之前就已经存在，但自动化配置使得实现这一方法变得更容易。我不会过多详细介绍——这留给你自己去学习。不过，简单来说，蓝绿部署允许你在环境中离线配置一台新服务器，安装最新版本的软件或配置更改或数据库更新，然后通过小的网络/路由调整来切换旧服务器与新服务器。实质上，你提前完成了所有的艰苦工作和准备，发布过程只是一个切换操作。这种方法非常有效且快速，并且在发现问题时（例如，切换回旧版本）可以几乎即时回滚。我强烈建议你将这项内容加入你的阅读清单。

你可能会认为自动化配置方法只适用于开发和测试环境，但这种方法实际上也可以（而且应该）应用于生产环境。毕竟，如果你已经建立了 CD 流水线，那为什么还要止步不前呢？我不建议你在第一天就尝试这样做；你需要建立对工具的信心，并在跳入实际操作前解决任何问题。根据经验，我可以保证，一旦你将自动化配置落实到位，你将不再回头。

自动化配置的另一个巨大的但鲜少被提及的好处是能够克服全球大多数 IT 部门和软件公司面临的头疼问题：必须将生产系统下线进行升级。

无停机部署

大规模发布软件（无论是遗留系统还是其他）时，一件不可饶恕的事情就是必须将生产平台下线进行升级。是的，我确实说了“不可饶恕”，因为这正是它的真实情况。而且完全可以避免。这就像是电梯上挂着“故障”标志的 IT 等价物：

将生产系统下线进行升级有两个简单的原因：有太多尚未发布的更改被捆绑在一起，或者你不信任交付的软件质量。这两种情况都可以通过采用 CD 和 DevOps 来克服。

假设你正在运营一个实时在线服务，并且你通知你的客户你需要将系统下线进行升级。你可以打赌，客户一定不会高兴，因为为了升级系统中的某些部分，你将让他们无法访问系统（更重要的是，无法访问他们的数据）几个小时。为了将影响降到最低，你无疑会安排在非工作时间进行升级，这意味着你需要有人员待命以支持升级——但是因为是在非工作时间，我怀疑你无法联系到所有参与过更改的工程师，所以你已经面临一定的风险。

关于非工作时间的一个重要事项是：除非你运营的是 B2B 解决方案并且客户都在同一时区，否则你可能会很难找到合适的非工作时间窗口。例如，如果你的解决方案和业务是 B2C 的，你几乎是在提供一个全天候的服务，因此除非你确切知道你的消费者何时睡觉，否则找到合适的时间窗口会非常困难。如果你的客户是全球性的，那么找到合适的窗口会更加困难。你无疑已经在你的服务条款和/或合同中包含了为了将在线平台下线而做出的相关规定，但这实际上是在向客户承认你的业务流程存在不足。

如果你还考虑到每当进行大规模停机 IT 升级时，关于重大问题的新闻报道通常会频繁出现，那么也有很大的可能性，客户会对这种“大爆炸”式的做法产生不信任感，因为他们很清楚一旦服务重新上线，就很可能会出问题。如果超出了预定的时间窗口，这种不信任感会加剧。根据经验，我可以自信地说，总会出问题，根据问题的严重性，你可能需要迅速进入限损模式来让客户满意，撇开服务条款和合同不谈。甚至可能会发展到客户开始寻找不需要计划停机的竞争对手。

好吧，这听起来有点悲观，但这就是残酷的现实。客户和消费者并不关心你的流程问题或软件开发生命周期（SDLC）中的复杂性；他们已经习惯了每天使用的 IT 服务在需要时都能随时使用。试着回想一下，什么时候某个主要搜索引擎或社交媒体平台曾经出现过离线问题。当发布问题发生时，现在很难控制坏消息的传播，尤其是在社交媒体、24 小时新闻等的普及下。你必须记住，坏消息的传播速度比其他任何事情都快，因此你最不需要的就是因为发布问题而产生的坏消息。

CD 和 DevOps 的最终目标是尽可能快速、一致和可靠地反复交付价值。完全消除停机部署的需求对你来说是一个巨大的好处。

需要指出的一点，可能并不显而易见，那就是不仅仅是生产环境应该最大限度地保证正常运行。任何你依赖的开发、测试和 CD 环境也应该同样对待。如果类似生产环境的环境发生故障，你怎么进行开发？如果你的 CI 环境出现故障，你怎么进行集成和测试？这些规则应该在所有环境中通用——没有例外。

在之前的讨论中，我们涵盖了工程最佳实践中的开放和诚实工作方式。开放和诚实在 CD 方面同样至关重要。提供这种透明度的一个好方法就是对一切进行监控，并让所有人都能访问这些数据。

监控，监控，再监控

确保 CD 和 DevOps 是否有效的最重要方式之一就是监控、监控，再监控。如果在 CD 过程中使用的所有环境都在持续被观察，那么任何变化的影响（无论大小）都容易看到——换句话说，应该没有意外的情况。这里有一个简单的经验法则：如果它在动，就监控它。

如果你的监控覆盖范围足够广泛，你就能在各个方面获得更多的透明度。没有理由将监控仅限于运维团队；业务中的每个人都应该能够查看并理解任何环境——特别是生产平台——的表现以及它在做什么。

市面上有很多成熟且符合行业标准的监控工具，但要获得一个一致且有意义的统一视图可能会非常困难。例如，一些工具专注于监控基础设施和服务器，而另一些则专注于收集应用程序的指标，还有一些则专门用于测量应用程序和/或数据库的性能。除非你能将这些数据整合成一个连贯的视图，否则它们看起来会支离破碎。理想情况下，你应该尝试将这些工具的数据汇总在一起——或者至少尽量将它们集成——并呈现一个统一的视图，展示任何特定环境以及其中运行的软件/服务的运行状态和表现。

你会惊讶于你能获得的非常有价值的数据，以及它如何引导你的工程工作，因为工程师可以实时看到他们的软件或基础设施在真实用户环境中的表现。

如果它在动，就监控它。如果它不动，还是监控一下以防万一

监控是 CD 和 DevOps 正常运行的必要条件，因为事物（软件、服务、基础设施等）会不断变化，而 Dev 和 Ops 的双方都需要查看正在发生的情况，并在问题出现时提供帮助。

监控能带来的另一个不太显眼的好处是证明 CD 对生产平台没有产生不利影响。如果你使用的是某种图表随时间变化的解决方案，你可以让你的 CD 工具在部署时向图表添加一个尖峰或标记。这样你就可以直观地看到变化的影响（或者没有影响）。

到目前为止，我们主要关注的是技术解决方案和工具，这些解决方案和工具有助于实现 CD 和 DevOps 的采用。这些解决方案和工具可能会为你提供许多你工具箱所需的内容。然而，简单的手动过程依然有它的空间。

当一个简单的手动过程也是一个有效的工具时

即使你拥有足够的工具，也无疑会遇到一些无法仅通过工具和自动化解决的小问题。说实话，工具和自动化在某些方面可能是过度的，甚至可能在你努力将组织的不同部分整合时制造障碍——这里指的是形成 DevOps 的开发与运维之间的合作关系。

如果工具和自动化完全消除了对人类互动和讨论的需求，你可能会发现最终又回到了最初的状态。你可能还会发现，几乎不可能通过自动化来解决一个简单的问题。

以依赖管理这个棘手问题为例。随着软件平台的发展，许多相互依赖关系会逐渐形成。如果你使用持续交付（CD）流程进行代码部署，这些众多的相互依赖关系就变成了不断变化的目标，其中各个组件的开发和部署速度各不相同。你可以尝试在持续集成（CI）流程中捕捉这些变化，但某些地方可能会被遗漏，最终可能会因为组件 B 在组件 A 之前部署而不经意地导致整个平台崩溃。

你可以尝试绘制出这个过程，并将其构建到工具规则中，以限制或至少最小化这些不断变化的目标，但这些规则可能会比最初的依赖关系更复杂。或者你可以简单地约定一个过程，即在任何给定的时间只能进行一次更改。为了支持这一点，你可以实现一个简单的队列机制，写在白板上，并由所有工程和运维团队定期审查。

这种方法对 ACME 系统非常有效。以下是他们所做的事情：

• 他们获得了每个人的统一同意，即在任何时候，只有一个变更可以进入生产环境。他们将此称为部署事务。

• 为了突出某人正在对生产环境进行更改（无论是部署还是操作更改），这个人持有生产环境令牌，令牌的形式是一个毛绒玩具动物，并被命名为“构建獾”。如果你持有构建獾，意味着你正在更改生产环境。

• 他们使用白板和笔实现了一个简单的优先级队列系统。每天早上，任何想要进行部署的人都会来到部署站会，并与在场的每个人商定当天部署（或更改）顺序。

• 屏幕被安装在整个办公室（不仅仅是开发和运维区域），显示实时仪表板，展示当前正在进行的工作。

这些都非常简单，但这给 ACME 系统带来了克服依赖地狱的方法（例如，如果他们一次只能更改一项内容，那么就隐含了一个逻辑顺序，表示某个更改应该在另一个更改之前进行），并且在所有参与的团队中建立了协作的意识。

以下图示应能帮助你理解部署事务在部署过程中的作用：

部署事务

最终，ACME 成功地解决了早期困扰他们的依赖问题，从而使得这个手动过程可以被停用，尽管这个过程曾帮助他们推进 CD 和 DevOps 的采纳。

其他你可以使用的非常简单的手动解决方案包括以下几种：

• 使用协作工具进行团队间的实时沟通，并将其集成到你的 CD 工具中，这样部署时可以宣布并供所有人跟踪。

• 如果你的管理层对于开发人员在不涉及运维团队的情况下直接部署到生产环境感到不安，确保有一个 DevOps 团队负责发布。

• 如果部署失败需要即时回滚，可以考虑一些简单的回滚方式，例如使用 CD 工具将先前版本的组件重新部署。

• 通过定期回顾持续检查和适应，以了解哪些有效，哪些无效。

正如你所看到的，这不仅仅是技术解决方案的问题。如果简单的手动流程或工作方式的调整足够，那为什么要费力去自动化它们呢？

这就是今天的课程——暂时结束了。让我们回顾一下我们所涵盖的内容。

总结

正如本章开头所说，内容非常丰富，需要消化的东西很多。其中一些内容对你现在有帮助，有些则是在未来才会相关。

到这个时候，你应该更清楚并且更能欣赏敏捷工程最佳实践（包括使用源代码控制、CI、增量交付、测试自动化、快速失败）以及现代架构方法、交付方式和深入的监控如何简化你的 CD 和 DevOps 采纳过程。最重要的是，你应该已经明白，问题不仅仅关乎技术工具和技巧，有时简单的流程也能解决问题。

接下来，我们将从如何推进 CD 和 DevOps 采纳的方式，转向你在此过程中可能遇到的难题，如何识别这些问题以及如何克服它们。

第六章：避免障碍

到目前为止，本书主要集中在你在工具箱中需要掌握的核心工具、技术和方法，以确保你对 CD 和 DevOps 的采用能够顺利启动并持续推进。我们也讨论了一些你可能会遇到的潜在障碍，你需要设法克服这些障碍。

我们现在将更加关注这些障碍，并探讨如何克服它们，或者至少尽量减少它们对推动目标和愿景的实现产生的影响。在本章中，我们将重点关注：

• 你可能会遇到的常见障碍

• 你应该把精力集中在哪些方面，以及谁应当得到最多关注。

• 变革令人害怕，员工如何反应和看待变革不容小觑。

• 地理问题

• 事情会出错，因此你应该为此做好准备。

请注意，以下内容绝非详尽无遗的清单，但你很可能会遇到相当多这些障碍。

与任何重大变革一样，你在旅程中会遇到一些风暴，因此你需要了解如何绕开这些风暴，或者如何处理它们，以确保它们不会让采纳过程搁浅、阻碍进展或完全让变革失败——不知为何，使用航海类比来描述。

你需要注意的潜在问题有哪些？

你需要关注的问题确实取决于你的文化、环境、工作方式和业务成熟度。我知道这听起来有点敷衍，但不幸的是，它确实是事实。我们已经讨论了一些相关内容，但需要指出的是，如果你的文化、环境或行为不健康，可能会遇到比你预想的更多障碍。这就是为什么处理这些领域至关重要的原因。

希望这种情况不会发生，你能够顺利采纳新的方法，但万一我过于乐观，让我们来看看一些更明显的潜在障碍。你可能会遇到的情况包括以下几种：

• 一些个人根本不理解为什么事情必须改变，或者根本不想改变现有的做法。

• 一些希望事情能够更快进行并且急于变革的个人。

• 人们在情感层面对变革的反应可能会帮助你，也可能会妨碍你的进展。

• 如果你对自己试图达成的目标缺乏理解或可见性，商业优先级的变化可能会给进程带来阻碍。

• 官僚主义和繁重的公司流程可能会让进程陷入停滞。

• 地理上分散的团队以及团队之间的隔阂/孤岛问题。

• 工具使用过程中出现的意外问题（技术性和非技术性问题）。

• 技能差距和资源限制。

• 由于领导层变动而导致的政治动荡。

这个列表可以（并且确实可以）更长，但本书篇幅有限，所以我们将重点关注一些更明显的潜在问题，正如前面所提到的，这些问题可能会导致 CD 和 DevOps 采用陷入浅滩，甚至更糟，触礁。我们将首先关注个体，了解他们如何对你的愿景和目标产生负面或积极的影响。

阵营中的异见者

虽然“异见者”这个词似乎有些强烈，但它相当能代表那些决定反对你所提议或正在做的事情，且这些事情与他们的世界观不符的情况。

正如任何新概念、想法或变化一样，都会有一些人感到不舒服。大多数人希望能够理性思考，试图理解并接受事物的变化。然而，也会有一些个体，毫无明显理性理由地决定反对你正在做的事情。其背后的原因可以被分析到极致，但你需要意识到的是，这种情况是会发生的。还要明白，如果相对少数的个体声音足够大且具有干扰性，他们可以制造大量不必要的噪音，分散你对愿景和目标的关注。这正是他们所希望的，因此，重要的是不要让他们得逞。

正如我所说，你可能会投入大量精力和时间，深入挖掘其心理学原因，但仅仅知道并预料到这种情况会发生，已经是一个不错的准备。事先有准备，才能从容应对。

我需要提到的是，这种现象并不新鲜，也不完全是 CD 和/或 DevOps 采用所特有的。如果回顾敏捷方法刚开始被采纳的初期阶段，你会发现很多类似的例子。参与组织内敏捷采用的个体大致可以分为三类：少数创新者，开辟道路；更多的跟随者，他们对这种新的工作方式感兴趣，或者看到了其益处，并决定跟随创新者的步伐；以及落后者，他们尚未做出决定，或没有确信这条路是正确的。下图展示了这三类人群：

敏捷采用初期识别出的三类个体

一般共识是，应该将精力和注意力集中在创新者和追随者身上，因为他们代表了大多数参与者，并且积极推动采纳进程。那些正在上升曲线的追随者可能需要一些帮助才能跨越高峰，因此应该给予更多的关注。过多关注落后者可能会让注意力过度分散，令大多数人受到影响，因此痛苦的事实是，他们要么有所改进，要么就得离开——即使他们是高级经理或领导。这听起来可能有点残酷，但这种方法已经行之有效多年，肯定是有其道理的。

让我们从 CD 和 DevOps 采用的角度来考虑我们的异见者或落后者：你应该怎么做？正如之前所指出的，如果他们足够喧嚣和具有破坏性，他们可以制造足够的噪音来破坏事情，但不会持续太久。如果大多数组织成员已经认同你正在做的事情——不要忘了你是根据他们的反馈和建议执行计划——他们不会轻易分心，因此你也不应该分心。如果你已经在整个业务中建立了良好的网络，利用这个网络来减少噪音，并尽可能将落后者转化为追随者。

如果这些落后者处于管理或领导职位，可能会使问题变得更为复杂——尤其是当他们擅长玩弄任何企业中都存在的政治游戏时。然而，正如前面所说，他们最终会输掉这场战斗，因为大多数人都会支持目标和愿景。如果你有一位执行赞助人或一位在领导层中有影响力的人，且他们站在创新者或追随者阵营，请让他们参与其中。你只需要忽视这些政治游戏，保持专注，坚守你需要做的事。

你需要做的一件事是保持警觉，随时了解周围的动态，这样你就能在麻烦发生之前察觉到它。当这种情况发生时，我建议你转移一些精力，及时扼杀问题的苗头，避免它成为大问题。及时扼杀可以通过简单、非对抗性的面对面讨论来进行，你可以和潜在的麻烦制造者坐下来喝咖啡谈谈——这样，异见者会觉得他们被倾听了，而你也能了解噪音的真正来源。作为最后的手段，和他们的上司进行面对面的讨论也许能奏效。不要通过电子邮件来往，这种方式不起作用！

总的来说，你应该尽可能像对待课堂上的顽皮孩子一样处理异见者；不要让他们破坏大家的事情，不要把所有注意力都给他们，并采取冷静、审慎的方式。过一段时间后，人们会停止听他们的意见，或者不再对他们说的内容感兴趣（尤其是当这些内容不太具有建设性时）。

没有消息就是没有消息

一些可能增加异见者破坏局面的风险因素，是在 CD 和 DevOps 采纳方面缺乏明显或可证明的进展，或者更简洁地说，是缺乏被认知的明显或可证明的进展。也许你正在忙于一些复杂的流程变更，或者在实施工具，或专注于虚拟化遗留解决方案，因此看起来有一段可见活动的低谷期。

如果你们组织中有一些非常有动力并且注重交付的个人，他们可能会将这种低谷视为采用过程停滞的迹象，或者甚至认为你们已经完成了。如前所述，即使进展不大，高度可见性仍然非常重要。如果人们能看到进展在不断取得，他们会继续跟随。如果有一段被认为是没有行动的时期，那么追随者可能不知道你们的方向，甚至开始注意到异议的声音。

任何形式的沟通和/或进展更新都能帮助避免这种情况发生——即使没有太多内容可以报告，沟通的行为也能表明你仍然在场，并且仍在朝着目标前进。“没有消息就是好消息”这种说法是错的；没有消息就是没有消息。

让我们看看我们的角色可以做些什么来帮助：

好方法	不太好的方法
Victoria（副总裁）应当公开表现为创新者（或追随者），并公开鼓励她的部门在没有报复恐惧的情况下决定自己的立场	Victoria（副总裁）毫无疑问地接受滞后者的声音，并/或宣布她是其中之一
Stan（经理）应该支持 Victoria 的观点，并确保他了解在同级别和团队中谁是滞后者，并确保他们的声音不会变得太过响亮	Stan（经理）忽略滞后者产生的噪音及其对创新者和追随者的影响
Devina（开发者）和 Oscar（运维人员）也应该了解他们的立场，并注意滞后者的噪音，这些噪音可能会轻易影响同组的创新者和追随者	Devina（开发者）和 Oscar（运维人员）简单地沉浸在自我陶醉的无知中，将问题留给领导去解决

我们简要提到过一些人会对变化感到不适，并可能会以意想不到的方式做出反应。接下来我们将探讨变化如何以不同的方式影响个人，以及你需要注意的事项。

变革曲线

让我们公开说清楚一点，这很重要：你需要认识到并接受，识别问题并随之解决问题可能是一次很大的变化。你们已经与业务方一起识别出问题，现在你们正在致力于解决它。这就是变化，纯粹而简单。

在本书前面，我们提到过，ACME 系统公司那些帮助企业采纳 DevOps 和 CD 工作方式的勇敢男女们，是变更的催化剂。这个表述是故意为之的，因为变更确实发生在 ACME 系统团队中——而且事实证明这是一次非常大的变革。采用 CD 和 DevOps 不容小觑，且对个人的影响也不容忽视；即使他们最初认为这就像是切片面包发明以来最好的事情。

那些曾经担任过或正在担任管理或领导职务的朋友们，可能会理解变更既可以被视为积极的，也可以被视为消极的，有时候，尤其是当变更直接影响到个人及其当前角色时，它可能会被视为一种非常个人化的事情。人们如何看待变更，通常是从情感层面而非逻辑、理性层面来感知的。

让我们来看看一些关于人类如何应对变更的基本要点。

任何变更，不论大小、是否与工作相关，都可能以不同的方式影响个人，并且，如前所述，影响的层次也各不相同。有些人欢迎并接受变更，有些人对此不以为意，将其视为生活中发生的事情；有些人对此感到担忧和焦虑，但也愿意看看会发生什么；而有些人则对变更抱有敌意，认为变更是针对个人的。更重要的是，有些人是上述所有反应的结合体——当然并不一定是同时发生。如果在实施变更之前能意识到这些事实，那么在实施过程中就能更清楚地了解需要克服哪些挑战，以确保变更的成功。

有很多关于人们如何应对变更的研究，许多学者在这些年里发表了相关论文。我并不是说我对这个话题了解所有内容，但在涉及变更时，或者有时称之为过渡时，确实需要一些常识，且有一些非常明显且可以理解的特点需要考虑。

我个人偏好的一种可视化和理解变更影响的方式叫做变更或过渡曲线。这种曲线描绘了个人在变更/过渡实施过程中所经历的各个阶段。

以下图示是一个非常好的变更/过渡曲线示例：

约翰·费舍尔（John Fisher）的个人过渡曲线图，感谢 John Fisher 提供

你可以清楚地看到，在变更被规划、讨论或实施时，个人会经历几个阶段。我们不会逐一详细讲解每个阶段（你可以在www.c2d.co.uk/techniques/process-of-transition/上慢慢阅读）；不过，关于 CD 和 DevOps 的采纳，有一些非常重要的信息值得关注：

• 一个个体可能会多次经历这个曲线，甚至在变化的初期阶段

• 每个人都不同，他们经历变化曲线的速度也各有不同

• 你和那些身边少数开明的人也将经历这一曲线

• 那些不能/无法走出低谷的个体可能需要更多的帮助、指导和领导

• 即使某人沉默，不显得受影响，他们也不可避免地处于某个变化曲线的阶段，所以他们不应该被忽视——不仅仅是那些发声的人需要关注

总而言之，个体就是个体，他们会是落后者、跟随者或创新者，他们也会处于变化曲线的某个阶段。你组织中的领导者和经理需要特别关注这一点，确保员工得到照顾。你也需要意识到这一点，尤其是因为这同样适用于你自己。

你还应该考虑到，最初作为跟随者甚至创新者开始项目的个体，可能会多次经历变化曲线，因为最初的兴奋感会被现实所取代，意识到事情真的在发生变化。这也能解释为什么有些人在开始时表现出一种方式，但随着你们执行计划和愿景的过程中，他们的方式和态度发生了变化。

从个人和情感层面来看，变化既是好的也是坏的，既令人兴奋也是令人害怕的，既具有挑战性也是令人生畏的，既被欢迎也是被回避的。这一切取决于个体在任何时刻的感受。CD 和 DevOps 可能是一次非常大的变化；因此，情绪会在其中扮演重要角色。如果你能意识到这一点，并确保注意到这些迹象并做出相应反应，你会有一个更好的体验。忽视这一点，你将面临一场艰难的战斗。

让我们看看我们的角色能够做些什么来帮助：

良好的方法	不太好的方法
Victoria（副总裁）应该非常清楚变化对她组织的影响，并确保公开承认这一点。她还应该考虑与人力资源团队合作，在需要时提供帮助	Victoria（副总裁）仅仅把 CD 和 DevOps 的采纳看作是另一个项目，认为它不需要特别关注
Stan（经理）应该支持 Victoria 的意见，并确保他有时间去帮助、支持和协助他的团队	Stan（经理）反映 Victoria 的看法，忽视 CD 和 DevOps 对他团队的影响
Devina（开发人员）和 Oscar（运维人员）应该接受事情将会发生变化，并意识到他们的同事可能会对此感到困难，并可能需要支持	Devina（开发人员）和 Oscar（运维人员）则安坐在他们幸福的无知泡沫中，把事情交给领导去解决

说到这一点，我们将讨论如何应对那些在你组织内没有参与你们变化过程的人，或者甚至可能不知道它正在进行中的人。我们将他们称为外部人员。

外部人员

与持续交付（CD）和 DevOps 采纳相关的人员比例将很大程度上取决于你所在组织的整体规模。如果你是一个初创公司，那么几乎组织中的每个人都有可能参与其中。如果你是一个中小企业（SME），那么并不是组织中的每个人都会参与其中。如果你在一个企业环境中工作，那么积极参与的人员比例将远远小于不参与的人员比例。

以下图表展示了与核心团队的距离如何直接影响对实际情况的了解程度：

靠近核心团队的个人会对发生的事情有更深入的了解。

那些距离日常工作更远的人往往对发生的事情一无所知。这可能（并且会）导致这些外围人员由于缺乏知识，往往不自觉地在进展道路上设置障碍。需要指出的是，这并不是什么新鲜事，且并不仅仅适用于 CD 和 DevOps 的采纳；这对于任何大规模的业务变革项目来说都是现实。如果个人，特别是那些决策者，不了解正在发生的事情，那么 CD 和 DevOps 不会是他们首先考虑的事项之一。

举个例子，让我们看看 ACME 系统，看看这种情况如何影响了他们的实施。

在他们进化的 2.0 阶段，ACME 系统成为了一个大公司的组成部分。他们最终成为了一个卫星办公室，总部设在海外，并且在整体上被放任自流。他们努力工作了一段时间，开始审视和实施 CD 和 DevOps。在全球企业层面来看，他们是在孤立的情况下进行这些工作的。是的，他们确实对 ACME 系统组织进行了广泛而深刻的变革，但他们只是在一个非常大机器中的小齿轮而已。ACME 系统办公室之外的人几乎没有什么可见性或对发生的事情的深入了解。因此，当一个关于全球运营组织裁员的战略计划被宣布时，几乎没有人考虑到 ACME 系统的进展，实话说，做出决策的人根本不知道发生了什么。因此，CD 和 DevOps 的实施进展很快就停滞了。幸运的是，一旦尘埃落定，对 DevOps 的需求变得比最初更大，导致了采纳的焦点和速度加快。

在 ACME 系统的案例中，CD 和 DevOps 的采纳带来了积极的影响，实际上还提供了额外的推动力。如果在你的过程中发生了广泛的变化，而人们对你正在做的事情一无所知，那么你的故事可能不会有一个好的结局。记住这一点。

这个故事的寓意是：你不仅应该关注公司内部的情况，还应该关注整个组织的动态。我们已经探讨了沟通你正在做的事情并保持高度可见性的重要性。这种沟通和可见性不应该仅限于那些直接参与 CD 和 DevOps 采纳的人；你应该尽量让尽可能多的人了解。如果你在一个公司环境中工作，毫无疑问你会有一个内部通讯团队，他们定期发布新闻文章到公司内网或通讯刊物上。联系这些人，让他们报道你正在做的事情。适当的公关活动会帮助你的事业，扩大知识的传播范围。

这看起来可能是付出很多努力却收获不多，但你可能会惊讶于它能带来的好处。例如，假设你撰写并发布了文章，结果被 CEO 或一位高级副总裁看到，他们决定亲自访问，看看到底是什么让大家如此关注。这无疑是一次重大的士气提升，也是很好的公关。更重要的是，它可能有助于解决你与管理层之间的分歧——如果他们看到高层认可你所做的事情是积极的，他们可能会重新考虑自己的立场。

我们主要考虑的是外部人士，即那些不在你直接影响范围内、不了解你所做的事情和发展方向的人。你可能也有一些人非常清楚，但他们被公司繁文缛节或官僚主义所限制或掩盖。让我们花一些时间深入探讨这个潜在障碍，以及如何克服它。

公司指南、繁文缛节和标准

这一潜在障碍的大小和规模取决于你所在组织的大小以及你所在行业的市场环境。如果你在服务行业工作，并且有商业责任需要满足某些服务水平协议（SLA），或者你在金融机构工作并且需要遵守监管指南，那么你在实施和采纳 CD 和 DevOps 时会在某些方面受到制约。这正如人们所说，这是行业的常态。

你需要做的是与那些制定和/或监管规则的人合作，看看是否有调整的空间。你可能会发现，某些为公司制定的规则和指南实际上是过度的，它们之所以被实施，仅仅是因为坚持书面规定比根据业务需求进行调整更容易。

这种规则、指南和政策的需求主要涉及变更管理和可审计性。简单来说，它们提供了一个安全网，并能在发生问题时帮助确认最近的变化。你可能会发现，那些管理或监管这些规则、指南和政策的人认为 CD 和 DevOps 与他们的工作方式不兼容。虽然这可能是真的，但并不意味着它是正确的。

在调查阶段，他们的组织/部门可能已被指出是产品交付过程中浪费的一个环节（我敢打赌是这样），所以他们可能对变革持防御态度。甚至可能他们根本不知道在不违反规则或公司政策的情况下，能改变什么。与这些人合作，帮助他们理解 CD 和 DevOps 的含义，帮助他们研究他们的哪些流程可以改变以适应这一点。不要只是忽视他们并违反规则，因为这会在未来影响到你，甚至可能完全扰乱流程。开放、诚实和勇敢的对话是关键。

也就是说，开放和诚实的对话可能会受到地理位置的影响，我们来看看如何解决这个问题。

地理分布广泛的团队

我们之前提到过建立一个开放和诚实的物理环境，以帮助加强开放、诚实和协作的工作方式。如果团队是共址的，这一切都很顺利。然而，尝试在地理分布广泛的团队中重现这一点可能是一个棘手的问题。它完全取决于时区差异，以及在某种程度上，文化差异。

我在这里再次使用“文化”这个词是故意的。如前所述，文化对持续交付（CD）和 DevOps 的成功采用非常重要，我们曾关注过公司和组织文化。当涉及到可能会影响你的因素时，地理、政治或社会群体文化差异通常排在前列。当团队或团队成员的观点或价值观与您（或大多数组织成员）不完全一致时，他们可能会轻易变成反对者，或者至少成为创新者或追随者，他们确实认为自己在贡献，但可能会以他们自己的方式解读你的意图，甚至可能最终成为障碍。因此，你需要关注并确保他们感受到与物理在场的团队成员同等的对待。

这自然地引出了“物理在场”这一话题。没有物理在场总是一个障碍。关于远程团队与共址团队的对比，已经有许多研究，毫无疑问，还会有更多的研究，但似乎没有哪种方法能显示哪种方法能够产生最佳结果。这些研究有时忽略了外部因素对远程团队和共址团队的影响：组织的成熟度、文化协同作用、共享的经验和知识、共同语言等。如果这些因素对共址团队的协作有负面影响，那么当你加入远程团队时，这些负面影响很可能会被放大。

需要注意的是，大多数研究都集中在 DevOps 合作关系中的开发（Dev）方面。有时人们接受开发和运维（Ops）团队分离的现象，认为这是一种常态。然而，如果你考虑到 DevOps 在开发和运维紧密合作时最为有效，那么你就应该将这种地理分散的团队模式应用于两者。

根据经验，最有效率的团队通常是同地工作的团队，因为人类是社交性动物，因此通常倾向于喜欢与其他人一起工作、交谈、争论或分享笑话。除非你的预算允许每个人都在同一个物理位置工作，否则你需要考虑为那些不在同一地点的团队和团队成员复制这种体验。以下是一些你可以考虑的方案，以帮助消除这种障碍：

• 尝试将所有团队成员视为仅仅是——同一个团队中的成员，应该平等对待。

• 确保本地团队和远程团队都定期（最好是每天）进行电话会议（理想情况下是视频会议）。

• 如果你正在使用敏捷开发（scrum）或类似的方法论，并决定进行每日的 scrum 汇报，那么让远程团队也参与进来——即使你需要用手机给他们打电话并将其放在免提上。

• 在两个办公室之间安装一个 Skype（或类似软件）PC，作为虚拟墙/窗。这些设备应该在正常办公时间内保持开启，这样虚拟墙/窗两边的团队成员就可以随时走过去进行面对面的交流，就像他们在同一个房间里一样。

• 如果预算允许，尽量通过借调、外派等方式让团队成员在短时间内互相交换办公地点。

• 不要依赖电子邮件作为协作/沟通的工具，而是应该投资于协作工具（我们之前已经提到过）。

另一个需要注意的潜在障碍是时区问题。这可能会对团队会议和每日站会等事项造成混乱（根据经验，这些会议通常安排在早晨，这可能会成为问题，特别是当团队位于地球两端时）。通过一些创造性的思考，你可以克服这些小问题，例如选择一个位于团队时区中间的“早晨时段”作为会议时间。

再次回到文化问题，还有另一点需要考虑。在一些地区，文化可能不是那种快速而随意的西方文化，在那里每个人都有发言权并且不怕表达自己的看法。对一些人来说，培养开放性、诚实和透明可能会更困难，你应该对此保持敏感。我建议你与当地的人力资源或管理团队合作，向他们解释你正在尝试做什么，看看他们如何提供帮助。

现在我们来看看如果在执行目标和愿景时遇到失败应该怎么做。

在发展过程中遇到的失败

在你前进的过程中，事情偶尔会出错，这是不可避免的，也没有什么可怕或可耻的地方。可能会有你未曾预见到的情况，或者在现有流程中的某些步骤没有在“大象曝光”过程中被注意到。问题可能仅仅是选定工具集中的一个问题，它没有达到你预期的效果，或者只是存在一些漏洞。

你的自然反应可能是隐瞒这种失败，或者至少不公开失败的事实。这并不是明智之举。你和你的团队正在努力培养开放和诚实的意识，因此你能做的最糟糕的事情就是完全相反的行为。回想一下我们之前提到的关于快速失败以发现缺陷的内容；同样的方式在这里也适用。

承认失败、蜷缩成胎儿姿势，躺在角落里呜咽也不是一个选择。像任何变革一样，事情会出错，因此需要审视情况，评估你的选项，并向前推进。一旦你找到了绕过或解决问题的方法，就要进行沟通。确保你坦诚地表达问题所在，以及正在采取哪些措施来克服它。这将向他人展示如何应对和处理变革——一种通过示范来领导的方式。

你可能会担心，承认失败可能会给落后者提供更多的武器来破坏采用进程；然而，一旦创新者和追随者找到了解决方案，他们的胜利将是短暂的。坚持住，站稳脚跟，并保持信心。

如果你正在使用敏捷技术，例如 Scrum 或 Kanban，推动持续交付（CD）和 DevOps 的采用，你应该能够相对快速地改变方向，而不会阻碍进展。

好的，这一切都是非常积极的心态（PMA），可能会被一些比其他人更具怀疑精神的人视为管理上的空谈和陈词滥调，那么让我们看看另一个例子。

ACME 系统实施了一个部署事务模型（在前一章中已提到），用于管理依赖关系，确保在任何时刻只有一个更改被提交到生产系统。这一方案有效运行了一段时间，但随着时间的推移，事情开始变得缓慢。以前正常工作的自动集成测试开始间歇性失败，曾经被认为是万无一失的功能区域开始出现缺陷。这种减缓开始影响到更广泛的研发团队交付能力，尤其是来自一些慢节奏人员的抱怨声日益增多。相关方之间进行了公开且诚实的讨论，经过多次辩论，最终发现问题的主要根源是一个非常简单的依赖关系，且变更管理跟不上交付速度。从本质上讲，没有可靠的方法来确定哪个软件资产的更改会在另一个软件资产的更改之前完成，也没有简单的方法来尝试不同的集成场景。最终的核心问题是：如果资产 A 中的更改依赖于资产 B 中的更改，那么资产 B 必须首先上线，以便进行完整的集成测试。然而，如果资产 A 先准备好，就必须等待——有时可能等待数天或数周。部署事务开始妨碍持续交付（CD）。

这里是 ACME 系统所称的部署事务的简单流程的提醒：

你会记得，大家一致认为部署事务运作良好，并提供了一个有效的替代方案，解决了依赖地狱的问题。然而，当系统在实际使用中投入工作时，它暴露了一个缺陷，开始导致真正的痛苦问题。即使可以通过功能开关关闭某些特性，也无法在没有将所有内容部署到生产环境等真实环境中时，进行完整的集成测试。此前并没有出现这个问题，因为发布的速度非常慢，而且资产都是捆绑在一起的。现在，ACME 系统能够非常快速地部署到生产环境，但也遇到了一个新问题：应该按什么顺序进行部署？经过许多讨论和复杂选项的考虑，最终解决方案相当简单：移动部署事务的边界，并允许在资产进入生产环境之前进行完整的集成测试。接下来，便是各个研发团队手动确定应该按什么顺序进行部署。

以下图示展示了修订后的部署事务边界：

所以，ACME 曾面临一个可能成为“致命杀手”的问题，这本可以彻底破坏他们的 CD 和 DevOps 采纳。问题变得非常明显，许多人开始提出问题。追随者开始怀疑创新者，滞后的员工变得 vocal。通过一些老式的合作，开诚布公的讨论，这个问题很快而且相对轻松地被解决了。

再次强调，开放和诚实的沟通以及勇敢的对话是关键。如果你持续地审视并倾听他人的意见，你就有更大的机会提前发现潜在的障碍，避免它们完全阻碍你的进展。

让我们看看我们的角色能做些什么来帮助：

好的方法	不太好的方法
Victoria（副总裁）公开承认在采纳过程中可能会出现问题，并且鼓励她的部门在没有报复恐惧的情况下，共同合作解决任何问题	Victoria（副总裁）无法容忍任何形式的失败，并且公开批评出现的问题
Stan（经理）应该支持 Victoria 的消息，并确保他腾出时间帮助、支持和协助他的团队（们）在需要时	Stan（经理）将失败视为无能的表现，并在每个机会中加以打压。任何提出问题或困难的人都会被告知保持沉默
Devina（开发人员）和 Oscar（运维人员）在尝试新事物或冒险时不应害怕失败。当问题出现时，他们应该共同合作解决，并确保领导层完全知晓	Devina（开发人员）和 Oscar（运维人员）仅仅在他们的无知泡沫中待着，留下给领导层去处理

另一个可能破坏你实施并侵蚀信任的因素是不一致的结果。

不可重复的流程

技术性人员有一个倾向，就是自动化他们所接触的一切，例如自动构建工程师的工作站、自动构建软件、以及当办公室灯光打开时自动开启咖啡机。这并不新鲜，且这种方法没有错，只要过程是可重复的并且提供一致的结果。如果结果不一致，其他人会不愿意使用你花费数小时、数天或数周时间整理出的自动化工具。

在涉及 CD 和 DevOps 时，应采取相同的方法，尤其是当你在看工具时。你需要信任你一次又一次得到的结果。

有些人认为，内部工具和节省劳动力的解决方案或流程，既然不在敌对的客户环境中使用，就不需要达到生产质量，因为它们主要供公司内部的技术人员使用。这是百分之百错误的。

让我们看一个非常简单的例子：如果你是一个软件工程师，你会使用 IDE 编写代码，并且会使用编译器生成二进制文件来部署。如果你是一个数据库管理员（DBA），你会使用 SQL 管理程序来管理数据库并编写 SQL。你会期望这些工具始终如一地工作，并且能够产生一致和可重复的结果；你打开一个源文件，IDE 会打开它以供编辑，你执行一些 SQL，SQL 管理工具会在服务器上运行它。如果你的工具不断崩溃或产生意外的结果，你可能会感到有些沮丧（委婉地说），并无疑会避免再次使用这些工具。它可能让你抓狂。

疯狂：一遍又一遍做相同的事情，却期待不同的结果。

-阿尔伯特·爱因斯坦

同样的道理也适用于你为 CD 和 DevOps 采纳所构建和/或实施的工具（技术和非技术）。这些工具必须与（如果不是更好）你的团队正在创建的软件一样好。实施的工具/流程的用户需要确信，当他们一遍又一遍地执行相同的操作时，能够得到相同的结果。随着这种信心的增长，工具/流程的信任度也会随之增加。最终，工具/流程将被视为理所当然，人们会在没有第二次考虑的情况下使用它。

因此，人们也会信任，如果结果与上一次不同，那么某些坏东西已经被引入（例如，软件错误被创建），需要立即关注。

想象一下，如果工具/流程不断失败或提供不同的和/或意外的结果，会削弱多少信心和信任。因此，你需要非常确信这些工具/流程是适合目的的。

我们已经讨论了你在企业指南、繁琐的流程和标准方面可能遇到的潜在障碍。想想看，当你无法为可重复的任务提供一致的结果时，如何说服门卫们，CD 和 DevOps 并不危险，这将是多么有趣。好吧，也许“有趣”这个词不太合适，也许“痛苦”是更合适的词。

一致和可重复的结果的另一个优势，在查看指标时显现出来。如果你能够信任每次部署相同的资源到同一台服务器所花费的时间是一样的，那么你就可以开始发现问题（例如，如果部署时间变长了，可能是基础设施出现了问题，或者配置中的某些根本性变化）。

总的来说，这可能听起来很无聊，也不太具创新性，但凭借一致和可重复的结果，你可以不再为琐碎的事务担忧，将注意力转向需要解决的问题，比如非常现实的需求——为正在转型或已经转型的企业招募新员工。

弥合技能差距

这看起来可能不是一个大问题，但随着组织的产出增加，效率提高，组织开始被认可为能够快速交付高质量产品的公司（而且它会的），那么增长和扩展可能会成为一个高优先级问题——我想你会同意，这是一个好问题。现在，你需要找到那些能够以新的方式工作并表现出大家努力灌输并在整个组织中扎根的行为的人。这并不像你想的那么容易，找到那些不仅具备技能、经验和潜力，而且具备你所需心态的人将需要一些时间。仅仅在职位要求中加入CD 和 DevOps 经验是无法达到你想要的结果的；即使 CD 和 DevOps 已经存在一段时间，真正符合你所要求的经验的人并不多。

你将面临的另一个大问题是，在招聘和人才获取领域，对于 CD 和 DevOps 的真正理解水平。他们可能根据科技媒体和一些会议有一个粗略的了解，但他们并不会准确知道你在寻找什么。因此，与你招聘过程中相关的人员开展更多的知识共享非常重要，以确保他们理解你在寻找什么（或者至少理解你不在寻找什么）。你可能需要多做几次这种知识共享，直到他们理解为止。

在筛选候选人时，你可以做一些事情来区分那些理解 CD 和 DevOps 的人和那些不理解的人。例如，如果你有一个候选人的主要经验是在运营领域，可以向他们提出一些传统开发方向的问题；或者如果是开发人员，可以问一些传统上针对运营候选人的问题。将这些问题混合起来能帮助你更全面地了解他们的掌握情况。我的一个最喜欢的面试问题非常简单：

作为一名软件工程师，如果你的代码在提交到源代码控制后 10 分钟内就运行在生产环境中，并被数百万客户使用，你会有什么感受？

这个问题的表述是特别为了引发一个诚实的情感反应；这里的关键词是“feel”（感受）。你会对这个问题的回答感到惊讶；对于一些人来说，这个问题会让他们一下子停下来，有些人会对这种问题感到震惊，认为你提出这种问题是疯了，而有些人则会思考这个问题，并意识到虽然他们从未考虑过这个问题，但他们非常喜欢这个想法。如果，然而，答案是“10 分钟”？那就太慢了，你可能已经找到了一个赢家。

慢慢来，确保你选择了合适的人选。你需要创新者和追随者，而不是滞后者。

我们将以一个大多数人不会视为问题的事情结束这一部分，但它可能会让 CD 和 DevOps 的采用停滞不前，那就是领导层的变化。

领导层变动

我们每个人在某个时刻都曾在经历过领导层变动的地方工作过。通常，变动越高层，可能带来的影响就越大。例如，一个新的 CEO 在几个月内会通过招聘、解雇或通过组织调整（通过“搬动椅子”来解雇人）来改变领导层的报告结构。他们还会有一些新的愿景和商业驱动因素，以提高某些业务指标，这也是他们获得这份工作的原因。

大多数时候，位于较低层级的人不会看到任何影响，至少一开始不会，但影响终究会到来。你可以肯定这一点。

当你面临一些可能相当激进的事情时，比如采用 CD 和 DevOps，董事会的一次决策可能会完全搞砸一切，尤其是在采用的初期。正如之前所说，CD 和 DevOps 更侧重于工作方式、行为和文化，而不是单纯的填表和商业指标。话虽如此，采纳 CD 和 DevOps 是有原因的——提升快速且反复交付高质量软件解决方案的能力。这一点不会因为组织架构的更新而消失。

你最好的做法是继续保持现状，保持开放、诚实和透明。如果你仍然有一位在职的高管赞助人，鼓励他们重新展开魅力攻势。不要害怕重复旧话题，重申决策背后的原因和历史。此外，确保分享好消息，并确保新领导人被包括在你的定期沟通中。实质上，做任何必要的事情以保持工作进展，确保持续向前。

摘要

在这一章中，我们学到了哪些新东西？主要的信息是：变革并不可怕，它是会发生且已经发生的，而且在过程中会遇到障碍。只要你为此做好准备，意识到这一事实，并能够帮助和引导那些受到变革影响的人们度过难关，你就会处于相对有利的位置。当隐形的障碍显现出来时，无论是沟通问题、繁文缛节、官僚主义、招聘还是地理位置方面，你都会有一些应对的思路。你还学到的另一件事是，无论是处于核心圈子内还是外部的人，都是你成功的关键。

没有疑问，在这过程中会有其他的障碍、危险和潜在的阻碍因素，这些内容并未在本书中涵盖，但只要你做好准备，你就会成功。说到成功，我们现在来谈谈成功的衡量标准以及它为何如此重要——这些内容将在下一章中讨论。

第七章：重要的衡量指标

在前几章中，我们探讨了你应该考虑哪些工具和技术，如何认识到变革会以不同的方式影响人们，为什么文化、行为和环境如此重要，哪些潜在障碍需要克服，以及这些内容如何帮助你成功地采纳 CD 和 DevOps。如果你已经考虑到这些，并为此制定了计划来应对和/或解决这些问题，那么你应该已经为迈出更大步伐做好了准备。

我们现在要关注的是一个重要但有时被忽视——或干脆被忽略——的领域：监控和衡量进展。我们之前曾涉及过这个话题，但当时我们只是看到了其中一小部分。现在我们要探讨的是与持续交付（CD）和开发运维（DevOps）对日常工作方式和整个业务的影响相关的指标的收集、汇总和共享。

从表面上看，这可能被认为只对管理层有用，对那些每天处理 CD 和 DevOps 采纳的人没有价值。从某种程度上来说，这是对的，但能够分析、理解和分享可证明的进展，肯定会为你和所有在 CD 和 DevOps 旅程中的人带来价值。我们这里说的不是简单的项目管理图表、图形和 PowerPoint 材料；我们要看的是真正衡量整个流程尽可能多的方面。这样，每个人都能清晰地看到并理解你们集体已经取得的进展，并且了解距离最终目标还有多远。

为了有效地进行这项工作，你需要确保在 CD 和 DevOps 采纳的初期就开始收集这些数据，因为如果没有代表当时的数据，你将很难进行现在与当时的对比。你需要保持警惕和一致性，确保持续收集这些衡量指标，这样你才能在不同时间点比较进展的状态。有些人可能认为这是过于苛刻，但整个 CD 和 DevOps 的旅程正是因为在象限曝光中捕捉到的数据指向了浪费的领域——或者至少是低效的流程——而开始的。

在本章中，你将学习以下内容：

• 如何衡量你的工程流程的有效性

• 如何衡量你使用和依赖的各种环境的稳定性

• 如何衡量你采纳 CD 和 DevOps 所带来的影响

我们从头开始，首先关注工程度量。

衡量有效的工程最佳实践

这是一个相当难以理解的概念：如何衡量有效的工程实践，甚至更进一步，如何衡量最佳实践？还有一个常被提问的问题是：这和 DevOps 或 CD 有什么关系？我们稍后会讨论前者，但现在我们先专注于后者。

我们来看两个场景：

• 你当前的软件工程过程非常瀑布式，并且你有大量的手动测试来验证代码，直到代码准备发布——这一过程通常在 3 到 6 个月之间——并且会预留时间来修复 BUG。

• 你当前的软件工程过程相当灵活，并且大体遵循行业最佳实践。然而，由于发布之间有相当长的时间间隔，你有时可能会忽视技术债务（包括自动化测试），因为你可以在下一次发布前有时间回头去修复——而下一次发布通常是在 3 到 6 个月后。

好的，虽然这个很简化，但请耐心听我说。随着持续交付（CD）和开发运维（DevOps）的推广，发布间隔时间将会缩短。因此，我们可以稍后做的窗口也会越来越小。这可能会导致工程师们为了赶时间而不得不开始“偷工减料”，因为他们已经没有时间去清理发布前的技术债务任务。CD 和 DevOps 的采用最终能够让你快速交付解决方案——并没有什么明确的规定表示工程师会有更多时间来编写和测试这些解决方案。

让我们来看看一个大型季度发布的时间线和工作量，如下所示：

现在，让我们与 CD 类型的发布进行比较，如下所示：

这些都是非常简化的例子，但它们突出了减少发布间隔时间对关键角色产生的影响。我们可以稍后做的窗口从几天/几周缩短到几小时。

在第五章， 方法、工具和技术中，我们探讨了更广泛的业务如何看待功能和发布之间的关系。随着你的 CD 和 DevOps 采用的成熟，发布间隔时间将缩短，这意味着工程师将有更少的时间来完成功能。如果更广泛的业务已经习惯了在给定的发布中交付功能，他们会继续期待这一点，直到新方式稳定下来。

让我们回到“偷工减料”的话题。这些通常与非修改代码相关，但仍是耗时的活动——例如跳过某些单元测试、在集成测试中留下一些空白、不做文档、减少重构旧代码的倾向等等。简单来说，工程师们会面临交付压力，他们将不再有时间处理之前完成的所有任务。这因此变成了技术债务——这是每个软件工程团队都尽力避免的，因为它最终会在未来反噬他们。

回到衡量有效工程最佳实践的主题，这其实并不像你想象的那样陌生或罕见。全球有大量的软件公司定期使用工具来捕捉数据和测量一些内容，例如：

• 整体代码质量

• 遵循编码规则和标准

• 代码文档

• 代码复杂度

• 代码重复

• 冗余代码

• 单元测试覆盖率

• 技术债务

• 平均故障间隔时间

• 平均解决时间

• 缺陷逃逸距离

• 修复反弹率

单独衡量这些指标可能不会带来太多价值；然而，当它们汇总在一起时，你可以获得一个非常详细的整体情况。此外，如果你能够在一段时间内持续捕获这些详细信息，你就可以开始衡量和报告进展。这对持续交付（CD）和 DevOps 的采用至关重要，原因很简单：如果由于软件发布速度加快而导致质量下降，落后的人员将有机会借此反击。如果这些落后人员处于有影响力和/或决策岗位，整个采用过程可能会被拖延。

如前所述，如果你能在问题开始发生时就发现它，你就有机会去制止它。还有另一面：如果你当前的质量很差，而你能证明持续交付（CD）和 DevOps 的采用有助于提高质量，那么这就是一个巨大的好消息——我们可以更快发布，而质量大幅提高。给那些落后者看看！

听起来很简单，实际上，确实可以做到，但你需要注意，你需要投入一些时间、精力和严格性，确保能够获得最大的价值。过程中也会有一定的试错和调整，以确保能够以可靠和可重复的方式捕获数据——更多的检查和适应——因此你需要确保考虑到这一点。这些衡量标准不仅会帮助你的工程团队，也会有助于在更广泛的业务中建立信任。例如，你将能够提供开放、诚实、真实的软件质量指标，这反过来会增强他们对开发和维护平台的团队的信任。

在你开始衡量诸如软件代码指标等事物之前，有一点需要认真考虑：工程师自己对此的感受。Devina 的想法可能是典型反应之一：

对这种方法的典型反应

一些工程师可能会变得防备或防守，认为这在质疑他们在创建高质量代码方面的技能和工艺。你需要小心，避免在你与工程团队之间建立障碍，也要避免让他们回到落后者阵营。你应该将这些工具作为工程师的积极利益来推销。例如，他们可以明确证明自己的代码有多好；他们可以利用这些工具检查过于复杂的区域或可能包含漏洞的代码区域；他们可以突出冗余代码并从代码库中移除；他们还可以直观地看到硬依赖关系，这在进行组件化时有很大帮助。

如果你有一些发声的拖后腿者，让他们积极参与工具的设置和配置（例如，他们可以负责定义可接受的代码覆盖率的门槛，或者选择要实施的工具）。

如果没有别的，你需要确保工程社区中的创新者和追随者都能参与其中。为了更清晰地说明这一点，我们来看一下前面列表中的几个项目——顺便说一下，这个列表并不完整——并更详细地探讨它们为什么对你的持续交付（CD）和开发运维（DevOps）采用可能至关重要。我们从代码复杂度开始。

代码复杂度

拥有复杂代码有时是必要的，特别是在面对极其优化的代码时，尤其是在资源有限和/或需要实时 UI 的情况下——基本上是每毫秒都很重要的场景。当你拥有像在线商店、登录页面或财务模块这样的功能时，过于复杂的代码反而可能弊大于利。一些工程师认为他们很特别，因为他们能写复杂的代码；然而，单纯为了复杂而复杂其实就是在炫耀。

过于复杂的代码可能会导致许多普遍性的问题——特别是在调试时，或者在你试图扩展代码以满足更多使用案例时——这直接影响到你实施哪怕是最小改动的速度。持续交付的前提是交付小而渐进的高质量改动。如果你的代码过于复杂，以至于无法实现这一点，那么你将在未来遇到问题——通常这被称为代码的可维护性、可测试性和可读性。

我建议你在开始实施任何过程或工具之前，先花些时间更深入地研究这个复杂的（带有双关意味）主题。你真的需要理解其背后的基本原则和科学原理；否则，这将变得混乱不堪。某些科学原理在附录 A，一些有用的信息中做了详细解释。

一个建议是，选择一些现有的代码分析工具，进行试用，分析你的代码库，帮助你找出一些现有的痛点。通过这些，你可以开始制定一个计划。

你接下来可以考虑的一个方面是代码覆盖率。

单元测试覆盖率

在软件开发过程中引入单元测试被广泛认为是最佳实践——第六章，避免障碍。这个主题有大量的信息可供参考，因此我不会在这里花太多时间讨论，但我建议你投入一些时间和精力，研究一下这个主题以及如何在你的软件开发生命周期（SDLC）中采用这种方法。

为了不让你觉得我在敷衍你，我将提供一些关于这个主题的见解和背景，特别是与 CD 和 DevOps 相关的部分。

从简单的角度看，单元测试允许软件工程团队在开发过程中对代码路径和逻辑进行粒度化的验证，这反过来可以帮助尽早发现并消除软件缺陷。将这些测试纳入持续集成（见第六章，避免障碍，了解持续集成的相关信息）并让它们在构建过程中阻止错误，可以帮助防止缺陷进入持续交付管道的下游阶段。这也可以作为回归的早期警告；例如，如果一个先前正常的单元测试开始失败，很可能是引入了回归问题。

持续交付的前提是能够频繁发布变更。如果你的代码库中有良好的单元测试覆盖率，你将对频繁发布该代码并降低风险充满信心。

分析覆盖率是一个很好的指标，能够表明你在多大程度上可以依赖单元测试来发现问题。你还可以利用这些数据绘制出在快速发布代码时的风险领域（例如，如果你的登录页面经常被修改并且覆盖率较高，那么频繁发布该页面的风险会较低）。

有一件事是你需要考虑的，关于覆盖率的衡量——即旧代码与新代码的混合。你通常会发现，旧代码，尤其是基于旧技术的代码，可能几乎没有单元测试覆盖。如果这类代码占据了你代码库的大部分，覆盖率的衡量结果会非常低。如果更广泛的业务团队过于关注这一指标，他们可能会将低分数视为一个重大风险。虽然从技术角度讲这是正确的，但你不能指望从第一天开始就对旧代码进行全面覆盖。因此，你需要确保为数据设定一个上下文，并制定一个随着时间推移提高覆盖率的计划。一种方法是设定一个规则，要求所有新代码或重构代码应该有较高的覆盖率（理想情况下是 100%，前提是在不进入收益递减领域的情况下可以实现），并且随着旧代码重构的增加，总体覆盖率应当增长。

现在让我们来看一下提交频率的衡量效果。

提交和合并率

定期提交源代码到版本控制系统是应该广泛鼓励并深度嵌入工作方式的一部分。将源代码长时间存放在个人的工作站或笔记本电脑上是非常危险的，有时会导致重复劳动，甚至更糟的情况是，可能会阻碍其他工程师的进展。

可能有人担心，如果工程师提交代码太频繁，创建缺陷的机会会增加，特别是当你认为未完成的代码可能会被合并到主代码分支时。这种担心是个谬论。没有任何一位称职的工程师会认真考虑做这种事——为什么要这么做？如果你有像定期代码审查或拉取请求审批流程这样的检查和制衡，合并有缺陷的代码的风险将大大减少。再加上单元测试和代码分析，你几乎可以消除风险。

与此相反的是，提交和代码合并之间存在非常真实的延迟风险。需要合并的代码越多，风险就越大，引入代码冲突、缺陷和不完整功能的潜力也就越高。持续交付（CD）方法的核心是经常交付可工作的软件。这不仅限于软件二进制文件；经常交付小的增量源代码也是一种良好的实践。

大多数源代码控制系统会提供可以通过第三方工具分析的工具和日志。你需要分析的数据包括每天每位工程师的提交和合并次数、合并之间的时间间隔，以及代码库中哪些区域被更改的最频繁。

从这些数据中，你可以开始看到一些模式，例如谁在积极合作，谁没有，以及代码库中哪些区域承载着最大的风险。提醒一下：不要使用这些数据来奖励或惩罚工程师，因为这可能会促使错误的行为，甚至可能像忽视工程最佳实践一样具有破坏性。

接下来，我们将讨论代码违规和遵循规则的棘手问题。

遵循编码规则和标准

你可能已经在软件开发团队中制定了编码标准和/或试图遵循外部文档化和公认的最佳实践。能够分析你的代码库，查看哪些部分符合标准，哪些不符合，是非常有用的，因为它有助于突出潜在的风险区域。如果你随着时间的推移持续捕获这些数据，你将能开始发现趋势——尤其是当这些数字开始下降时。

有很多工具可以帮助你做到这一点，其中一些列在附录 A 中，一些有用的信息。

这种类型的分析需要一些设置，因为它通常基于一组预定义的规则和阈值（例如，信息、次要、主要、关键和阻塞），你需要与工程团队合作，商定并在工具中设置这些内容。

衡量遵循编码规则和标准有助于防止代码中的缺陷泄露，但软件就是软件，缺陷总会悄悄出现。因此，你需要做的是分析缺陷出现后的情况。

质量指标

质量是所有参与编写和交付软件的人应该希望维护并融入其解决方案的东西。前面的部分包含了一些质量度量的元素，但你还应该考虑一些专门针对时间的具体度量。

与 CD 和 DevOps 相关的关键指标是平均故障间隔时间（MTBF）、平均修复时间（MTTR）和缺陷逃逸距离，具体解释如下：

• MTBF：这将帮助你衡量最终用户发现问题（或故障）的频率——故障之间的时间越长，整体平台的稳定性和质量越高。

• MTTR：这将帮助你衡量从发现问题到修复问题所花费的时间

• 缺陷逃逸距离：这将帮助你衡量问题发现的时间和发现者——例如，工程团队发现的缺陷离缺陷源较近（例如，团队中的某个成员），而 UAT 发现的缺陷则离源头更远。

前两者为 CD 和 DevOps 的采用情况提供了一些良好的指示，尤其是它们与交付速度的关系。例如，预计如果 CD 和 DevOps 的采用运作良好，MTBF 会逐渐增加，而 MTTR 则会逐渐减少。如果没有发生这种变化，那就意味着存在某些问题需要调查。

三者中的第三个——缺陷逃逸距离——是工程最佳实践和持续集成（CD）管道是否能够及早发现问题的良好指示。如果工程团队在流程早期就能发现缺陷——例如，由于单元测试失败，CI 步骤失败——那么距离和影响就很小。如果缺陷逃逸到下游流程——例如，用户验收测试（UAT）团队——那么距离和影响就会更大。如果缺陷最终进入生产环境，那么……我想你应该明白了。

一种表示方法是根据缺陷所在的环境以及发现它所需的时间，为每个缺陷添加一个美元价值。例如，假设我们有四个环境，作为 CD 管道的一部分：开发、QA、UAT 和生产。然后根据每个环境距离源头的远近，应用一个滑动成本比例：

环境	成本
开发	1
QA	2
UAT	8
生产	16

现在，让我们考虑每个缺陷的成本，使用一个乘数，基于缺陷创建和发现之间的交付时间。你将得到如下结果：

缺陷#	环境	环境成本	交付时间（天）	缺陷成本
DE1	开发	1	2	2
DE2	开发	1	5	5
DE3	QA	2	10	20
DE4	开发	1	0.5	0.5
DE5	生产	16	20	320
DE6	生产	16	50	800
DE7	UAT	8	5	40
DE8	QA	2	7	14
DE9	开发	1	15	15
DE10	UAT	8	12	96

这是一个时间快照，给你一个关于缺陷成本的指示。这并不意味着你应该完全消除缺陷——做到这一点的唯一方法是停止编写软件——但你应该专注于消除高成本的缺陷。毕竟，客户在实际环境中发现的缺陷成本远高于在 SDLC 阶段发现的缺陷成本。

现在我们来看看交付时间（和循环时间）的含义。

循环时间和交付时间

这些是更基于时间的指标，对于衡量你在 CD 和 DevOps 采纳过程中的变化进展和效果非常有用。这两个指标相对简单易懂：

• 交付时间：从需求被识别到交付给客户之间的时间测量

• 循环时间：从某人开始处理某个工作项/故事/缺陷到交付给客户之间的时间

以下图表应该能让你更清楚地了解这是什么意思：

你们中的敏锐观察者可能会注意到，对于缺陷来说，交付时间与 MTTR 几乎是相同的，这意味着一个简单的数据点可以用于两个度量标准。以一换二，物有所值。

定期拍摄交付时间和循环时间的快照，可以很好地指示事情是否在顺利进行（或者，情况可能并非如此）。需要注意的是，交付时间可能会受到业务优先级和时间承诺变化的影响——例如，当更紧急的任务进入待办事项列表时，某个功能可能会被降级优先级——因此，数值可能会随着时间的推移而波动。你应该争取的是交付时间的总体减少。另一方面，循环时间更多地受工程团队控制，因此减少循环时间掌握在他们手中。随着 CD 和 DevOps 采纳的推进，交付过程应该变得更加简单，因此平均循环时间应该减少。如果没有减少，你应该检查是什么原因导致了瓶颈。有些原因可能与质量问题相关。

质量门控

捕获数据不仅有助于随着时间的推移建立一个清晰的全貌并发现趋势，还可以帮助你防止质量问题的泄露。我的意思是，一旦你收集并分析了关于代码覆盖率、编码标准遵循情况、代码复杂度或代码文档化水平等方面的数据，你可以在 CD 流水线中设置一些阈值，如果超过这些阈值，流水线会立刻停止。你还可以根据自动化测试的结果实施质量门控——同样地，如果测试失败，CD 流水线也会停止。

例如，假设你已经决定，任何新的软件都必须拥有 100%的单元测试代码覆盖率，并且不能包含任何已记录的安全漏洞；那么，你可以在 CD 流水线中实现一个代码分析/代码检查工具，用于检查每次提交或合并。如果工具报告所检查的代码未通过检查，CD 流水线将停止并通知团队。

在提到 CD 流水线时，我会将 CI 解决方案作为整个流水线的一部分——以防你认为它们是分开的。

实施这些工具不仅能确保你的代码达标，还可以帮助减少诸如缺陷外泄等问题，确保代码通过 CD 流水线时的最小干扰。捕捉这些数据还会为你提供一些历史洞察，关于质量门是否通过/失败的时间点，这可能与其他事件相关——例如，在一个重大发布前的紧张时期，失败可能会增加。

你们中的一些人可能会认为这一切听起来像是额外的繁重工作——在所有其他繁重工作的基础上——那么，真的值得吗？是的，值得！

从哪里开始，为什么要费心？

如前所述，有许多事情你可以并且应该衡量、分析，并为此生成指标，同时也有许多工具可以帮助你做到这一点。你只需要弄清楚最重要的是什么，然后从那里开始。设置所需工具所需的工作和努力，应该被视为一个很好的机会，可以带入你想要嵌入的良好行为：协作、公开和诚实的对话、信任。

我建议在 CD 和 DevOps 的采用过程中尽早实施这些工具，这样你可以从一开始就开始跟踪进展。无需多说，刚开始时它不会是一个漂亮的景象，而且毫无疑问，当这些工作没有直接推动采用时，围绕其有效性的疑问会不断出现——事实上，尤其是在早期，情况可能会非常糟糕。

这可能不会直接影响采用情况，但它提供了一些值得的补充，下面将对此进行解释：

• 拥有额外的数据来证明软件质量，将反过来建立信任，使得代码能够快速、安全地交付。

• 很有可能，对整体代码库有一个非常简洁的视角将有助于对平台进行重新设计以实现组件化。

• 如果工程师对代码库有更多的信心，他们就可以专注于新功能的开发，而无需担心每次更改时都可能引发一系列问题。

现在我们将焦点从衡量软件创建的过程转向衡量软件构建后的重要性。

衡量现实世界

分析和衡量你的代码和工程技术是其中的一部分；然而，为了让 CD 和 DevOps 真正有效，你还需要密切关注整体环境、平台、运行中的软件以及 CD 和 DevOps 的效果进展。让我们从环境开始。

衡量环境的稳定性

在产品交付过程中，你可能会有多个不同的环境用于不同的目的：开发环境、CI、QA、UAT、性能/负载测试等。随着发布周期的加快，你对这些不同环境的依赖将会增加——如果你的发布周期是 2 到 3 个月，那么某个环境中出现半天左右的问题对你的发布影响不大；而如果你每天发布 10 次，那么半天的停机时间就会造成重大影响。

在 IT 行业中，似乎有一种普遍的词汇与此相关，“环境问题”这个术语一次又一次地出现，正如我们在这里看到的：

普遍的环境问题讨论

我们都听过这些话，有些人也可能自己说过这些话。总的来说，这些说法远非有帮助，反而可能在长远来看适得其反，尤其是在建立 Dev 和 Ops 之间良好工作关系的情况下，因为这些说法暗示基础设施（由运营方负责）有问题，尽管没有确凿的证据。

为了克服这种态度并培养一些良好的行为，我们需要做两件事中的一件：

• 毋庸置疑地证明软件平台按预期工作，因此，任何遇到的问题必须是由基础设施中的问题引起的

• 毋庸置疑地证明基础设施按预期工作，因此，任何遇到的问题必须是由软件中的问题引起的

当我说“相当简单”时，其实我意思并不完全是“非常简单”。让我们来看一下我们有哪些选择。

融入自动化测试

我们已经探讨了使用自动化测试来帮助证明每个软件组件在发布时的质量的优点，但如果你将这些测试集中起来，并在给定的环境中持续运行它们呢？通过这种方式，你将不断地对平台的大部分内容进行重复测试——实际上是持续进行的。

如果你捕捉到这些测试的结果，你可以快速而轻松地看到环境的健康状况，或者更准确地说，你可以看到软件是否按预期运行。如果测试开始失败，我们可以查看自上次成功运行以来发生了什么变化，并尝试确定根本原因。

当然，关于这一点有很多注意事项：

• 你需要有充分的测试覆盖，以建立高度的信心

• 你可能会有不同的测试，这些测试以不同的方式编写，使用不同的技术，而这些技术之间并不兼容。

• 一些测试可能会互相冲突，特别是当它们依赖于某些预定的测试数据集时。

• 测试本身可能并非万无一失，尤其是在包含模拟或桩的情况下，它们可能无法显示问题。

• 你的部分测试可能会出现波动，也就是说，它们不稳定，因某些原因偶尔会失败。

• 如果你是顺序执行这些测试的话，可能需要很多小时才能完成所有测试的端到端执行。

假设你愿意接受这些警告，或者你有足够的资源来加强测试，以便它们能够作为一个整体持续、一致地运行，你将得到一个能够提供更高信心的软件平台解决方案。

我建议你集中注意力于频繁波动的测试和/或执行后结果不一致的测试，因为这些会影响信任度。一个经验法则是，如果你无法信任某个测试，要么重构它，要么将其从测试套件中移除。

如果你拓展这种思维，你还可以使用相同的方法来增强对环境的信心。例如，如果你多次在相同环境中运行相同的测试套件，而在软件、配置或环境方面没有任何变化，那么每次都应该得到相同的结果。因此，你应该能够相对轻松地发现给定环境中的不稳定性问题——某种程度上。

结合自动化测试和系统监控

实际上，仅仅运行测试只会给你提供部分信息。为了获得更真实的情况，你可以将自动化测试结果与监控解决方案的输出结合起来（如第五章《方法、工具与技术》中所述，方法、工具和技术）。将二者结合起来可以让你更全面地了解整个环境的稳定性——或者说，环境是否稳定。更重要的是，如果发生问题，你将更容易定位根本原因。

好吧，虽然我把这个问题说得很简单，但说实话，整体目标是简单的；实现起来可能会有些困难。一如既往，有很多工具可以帮助你完成这些工作，但同样，需要时间和精力来正确地实现和设置它们。你应该将其视为另一个 DevOps 协作的机会。

然而，我们应该在前面提到的列表中添加另一个警告：你可能会在生产环境中遇到无法运行某些自动化测试的重大问题。

除非你的运维团队愿意接受在生产数据库中每小时/每天生成和销毁测试数据，并且他们也能接受因此带来的额外负载和可能的安全隐患，否则这种方法可能仅适用于非生产环境。

这可能足够让你开始，但如果你想要更全面的视图，你需要查看另一种互补的方法，以获取更深入的实时度量指标。

对软件本身的实时监控

将自动化测试和系统监控结合起来，可以提供有用的数据，但实际上只能证明两件事：平台正常运行，且测试通过。这并不能让你深入了解你的软件平台如何运行，或者更重要的是，它在被成百万的真实用户使用的生产环境中如何表现。要实现这一点，你需要迈向下一个层级。

想想看一辆一级方程式赛车是如何开发的。我们有一位试车手坐在驾驶舱内，输入指令让汽车执行某些动作；他们的脚踩在油门上，让汽车向前行驶，同时他们在转动方向盘，让汽车绕过弯道。你有一支技术员和工程师队伍，观察汽车的行驶速度，并能观察到汽车的运行情况（也就是说，当踩下油门时，汽车加速，转动方向盘时，汽车绕过弯道）。这些都很好，但对技术员和工程师而言，更有价值的是由汽车内部成千上万的传感器和电子设备生成的深入数据和度量指标。

这种方法同样可以应用于软件平台。你需要从平台内部深处获取数据和度量指标，才能完全理解发生了什么；单单通过测试和观察结果是无法获得这些的。这并不是一个新概念；它已经存在了很多年。只要看看任何一个操作系统，你就会发现有很多方法可以深入挖掘并提取有用且有意义的指标和数据。为什么不把这个概念直接应用到软件组件上呢？在某些方面，这已经是内建的；看看你的软件平台生成的各种日志文件（例如，HTTP 日志和错误日志），这就给你一个先机；如果你能够收集这些数据并加以利用，就更好了。

有很多工具可以帮助你浏览这些输出，并将其汇总成有用且有意义的报告和图表。不过这里有一个问题：在实时生成这些报告时非常困难，尤其是在产生大量数据的情况下，因为这些数据需要时间来获取和处理。

一种更简洁的方法是将某些功能直接构建进软件本身，使其能够以一种简洁、一致且对你有用的格式提供这种低级别数据——说实话，你的平均 HTTP 日志包含了大量对你毫无价值的数据。我将在附录 A 中讲解一些示例，一些有用的信息，但简单来说，这种方法可以分为两类：

• 在你的软件 API 中集成健康检查功能；这样，当中央数据收集解决方案周期性地调用时，它将提供低级别的度量数据

• 定期将低级别的度量数据推送到中央数据收集解决方案，以扩展你的软件平台

当然，你需要一些东西作为中央数据收集解决方案，但如果你在 DevOps 方法下选购并实施最适合你的工具，市场上是有这些工具的。

监控的理想状态

无论你采用何种方法（或方法组合），最终你都应该能够获得非常丰富且深入的信息。实质上，你将拥有与普通一级方程式技术人员一样的数据（那是大量大量的数据）。你只需要将所有数据整理成一个连贯且易于理解的形式。这一挑战也是鼓励 DevOps 行为的另一个因素，因为你想要捕获/展示的数据最好是双方工程师共同商讨并达成一致的。

如果你不确定是否应该测量平台或基础设施的特定部分，但感觉它可能有用，还是测量一下吧。你永远不知道这些数据是否会在以后派上用场。经验法则是：如果它在变化，监控它；如果它不变化，也要监控，以防万一。

最终，你想做的是确保整个环境（基础设施、配置和软件平台）是健康的。这样，如果有人说一定是环境问题，他们可能确实是对的。

如果我们把这一切整合起来，我们现在可以扩展之前的列表：

• 毋庸置疑地证明软件平台按预期工作，因此，遇到的任何问题必须是基础设施中的问题

• 毋庸置疑地证明基础设施按预期工作，因此，遇到的任何问题必须是软件中的问题

• 同意问题可能因任何原因发生，并且根本原因应该在协作的 DevOps 方式中被识别和解决

现在我们将从测量的技术方面转向业务导向的视角。

CD 和 DevOps 的有效性

实施 CD 和 DevOps 并不便宜。它需要付出相当多的努力，这直接转化为成本。每个企业都希望看到投资回报，所以没有理由不提供这类信息和数据。在本章的大部分内容中，我们一直在关注衡量进展和成功的更深入技术方面。这对技术导向的人员非常有价值，但普通的中层经理可能不会理解这些细微差别，坦白说，你也不能怪他们。看到大量的数据和图表，包含像每秒事务数（TPS）计数、某个软件组件的响应时间，或提交了多少次代码，对普通的管理者来说并不会感到震撼。他们更喜欢的是顶层的总结信息和数据，这代表着进展和成功。

就 CD 和 DevOps 而言，主要的关键因素是提高效率和吞吐量，因为这些因素直接决定了产品能够多快地交付到市场，以及企业能多快开始实现价值。这就是最重要的目标。CD 和 DevOps 是实现这一目标的催化剂，那么为什么不展示这些呢？

如果幸运的话，你将拥有（或计划拥有）一些工具来促进和协调 CD 过程。你还应该在这些工具中内置度量标准；你应该捕捉的度量标准包括：

• 完成的部署次数统计

• 将发布候选版本投入生产所需的时间

• 从提交到工作软件投入生产所需的时间

• 已构建的发布候选版本数量统计

• 已发布的软件组件排行榜

• 正在通过 CD 管道的独特软件组件列表

然后你可以将这些数据汇总出来，供所有人查看——它必须简单，必须易于理解。你可以在办公室的屏幕上显示类似下面截图所示的信息：

总结 CD 过程有效性的示例页面

这种信息非常有效，如果它是可见且易于获取的，它还可以引发关于进展如何以及哪些领域仍然需要一些工作和优化的讨论。

对于管理层来说，尤其有价值的是财务数据和信息，比如每次发布所消耗的资源成本。如果你有这些数据，包含它们不仅对管理层有用，还能帮助工程团队集中精力，因为他们会开始了解这些事情的成本。

访问这些数据和信息不应受到限制，且应该高度可见，以便每个人都能看到进展，并且更重要的是，看到自己距离最初目标还有多远。

我们已经看过效果了；现在让我们来看看实际的影响。

CD 和 DevOps 的影响

实施 CD 和 DevOps 将对你的工作方式和整个业务产生影响。这是事实。更好的做法是理解这种影响到底是什么。你可能已经在捕捉和报告一些像是业务关键绩效指标（KPI）（活跃用户数、收入、页面访问量等），那为什么不把这些也加入到更广泛的指标和衡量标准中呢？如果 CD 和 DevOps 对客户保持率有积极影响，大家看到这一点岂不是很好吗？

在基本层面上，你需要确保自己朝着正确的方向前进。

在我们离开衡量和监控之前，让我们看一个表面上看起来确实有些奇怪的事情：衡量你的 DevOps 文化。

衡量你的文化

我知道你在想什么：衡量软件、环境和流程已经够困难的了，那怎么衡量像文化这样无形的东西呢？说实话，没什么简单的答案，这真的取决于你认为什么最有价值。例如，你可能觉得开发人员有 20%的时间与系统运维人员一起工作，这表明 DevOps 在正常运行且健康，或者说是开发人员和运维团队一起解决现场问题，这也是一个很好的标志。

捕捉这些信息也可能很棘手，但它不需要过于复杂。你真正需要知道的是人们觉得事情是否在进展，以及他们是否认为事情是在正确的方向上进展。

捕捉这一点的最简单方法是尽可能多地询问人们。当然，你还需要捕捉一些有意义的数据点——仅仅拥有一个写着“进展顺利”的图表并不能给你太多信息。你可以考虑使用定期访谈或问卷调查来收集以下数据：

• 你是否觉得工程师（开发和运维）之间的协作有效？

• 工程师（开发和运维）愿意合作解决生产问题的程度如何？

• 当出现问题时，你是否觉得责任仍然是主要的因素？

• 你是否觉得运维工程师在功能开发的早期就参与其中？

• 是否有足够的机会让工程师（开发和运维）改善他们的工作方式？

• 你是否觉得自己拥有有效完成工作的工具、技能和环境？

• 你是否觉得 CD 和 DevOps 对我们的业务产生了积极影响？

你可能还能想出其他的示例问题；然而，不要过度，不要让人们感到轰炸——KISS（参见第三章，文化和行为是成功的基石）。如果你能使用允许用尺度形式回答的问题（例如，1 表示强烈同意，2 表示同意，3 表示不同意，4 表示强烈不同意），你将能获得更清晰的画面，然后可以随着时间进行比较。

再次强调，如果你将这些数据与技术数据结合起来，这可能会提供一些你未曾预料的洞察。例如，也许你实施了一项新流程，成功减少了 10%的逃逸缺陷，但每日发布的次数减少了 5%，而且大部分工程团队成员都不满意。在这种情况下，你可能在流程本身或在基层接受度方面存在问题。

总结

在本章中，你学到捕捉数据和衡量标准的重要性，因为这能清晰地指示出事情是否按照你计划和期望的方式进行和进展。不论你是对软件质量随时间的提升、缺陷的减少、软件平台的性能，还是过去一个季度的环境问题数量感兴趣，你都需要数据。大量的数据。将这些数据与以业务为重点和现实世界的数据相结合，只会增加价值，并为你提供更多关于事情进展的洞察。

你正在努力在整个组织中促进开放和诚实（参见第四章，文化和行为）；因此，在你的 CD 和 DevOps 实施过程中分享你收集的所有指标和数据，将提供高度的透明度。归根结底，任何业务的各个部分都会转化为数据、指标和图表（如财务数字、员工人数、产品的公众评价等等），那么，为什么产品交付过程应该有所不同呢？

越早开始收集这些数据，你就能越早进行检查和调整。你需要将你的口号从“监控、监控，再监控”，扩展为“持续且一致地监控和衡量”。

现在让我们从衡量所有可以和应该衡量的事物转向，看看一旦你的 CD 和 DevOps 采纳成熟后，情况会是怎样。在第八章，《你还没有完成》，我们将讨论一些在 CD 和 DevOps 成为常态时，你应该考虑的事项。

第八章：你还没有完全结束

直到这一点为止，我们一直在进行一段旅程，从揭示导致业务痛点的问题，到定义去除这些问题的目标和愿景，再到解决文化、环境和技术障碍，采用急需的工具和技术，克服障碍，再到衡量成功。

让我们把时间往前推，假设到这个时刻为止，前面章节和页面中的所有建议都已帮助你——加上更多的专业建议、补充出版物，甚至一些协助——并且你已经实施了必要的工具和流程变更。我们还假设 CD 和 DevOps 的采用在你们的组织中已经全面展开。

如果你在旅程的开始阅读这些内容，那么我建议你继续阅读，并运用你的想象力，设想在实施了 CD 和 DevOps 后，事情将会是怎样的。

如果一切按计划进行，业务部门已经开始看到收益，并且能够更快地向市场交付优质功能，远比之前快。从表面上看，你几乎完成了你的目标，实现了你的愿景，但——这非常重要——这并不是终点。

你们所经历的旅程是漫长的，就像那个坐在车后座、长时间开车去奶奶家的五岁孩子一样，你们组织中的人们现在会反复问一些问题，比如“我们到了吗？还要多久？什么时候可以停止花钱在这个 DevOps 事情上？”以及“我需要上厕所！”好吧，也许不是那么多关于上厕所的事，但我想你明白我的意思。现在是暂停片刻、盘点一下你们所处位置的好时机。

反思你们现在所处的位置

是的，你已经走了很长一段路；是的，事情进展顺利得多；是的，组织内部的协作更加紧密；是的，开发和运维之间的鸿沟变得不再是深渊，而更像是地面上的一道小裂缝；是的，你几乎完成了你最初的目标。你所做的是将软件交付的过程从复杂、痛苦和繁琐的状态，简化成了如下的简单过程：

你最初打算解决的问题围绕着软件交付过程中的浪费，包括冗长且无意义的流程、政治姿态，更具体地说，是来自大规模、少量发布的浪费。采用 CD 和 DevOps 帮助你克服了（大部分）这些问题。

因此，你现在会开始听到类似的评论，比如“我们可以快速部署，所以我们一定实施了 CD”或者“我们的开发人员和运维人员密切合作，所以我们一定实施了 DevOps”。

有人会建议，一旦你开始听到这些，那就意味着你确实完成了你最初设定的目标。从某些方面来说，这是对的；然而，实际上，情况远非如此。

这些评论所说明的事实是，旅程开始时突出的问题现在已经开始变得模糊和遥远。公司已经开始接受 CD 和 DevOps 作为我们在这里的工作方式，并且终于开始理解它们的意义，这是好事。然而，仍然有很多工作要做，问题也需要解决；尽管这些工作和问题已变得不同。就像你在旅程开始时做的那样，现在是时候检查并确认哪些问题现在重要，并适应解决它们。为了说明这一点，我们需要稍微偏离一下主题。

流动

让我们将你的软件发布过程比作一条流动的河流（我确实说过这有点偏题）：

• 在最开始时，许多小溪流汇入一个大河，这条河流向前流淌，但却被一系列的水坝和人工大坝所阻碍：

• 然后，河流开始倒流，形成了一个水库。

• 每隔几个月，闸门被打开，水流自由畅通，但这通常是短暂且匆忙的冲刺。

• 随着你识别并开始移除这些人工障碍，流量变得更加均匀，但仍然受到下游一些巨大巨石的阻碍：

• 于是你开始系统地一一移除这些巨石，这样又增加了流量；这反过来使得流量变得更加一致、可预测和可管理。

• 由于移除了障碍以增加流量，水位开始下降，小石子开始出现并形成涡流，这限制了流量，虽然不是完全停止，但还是稍微影响了流动：

• 流量继续增加，水位不断下降，很快就会明显看出，这些小石子其实是隐藏在河流深处的更多巨石的顶部。

那么，这和你采用 CD 和 DevOps 有什么关系呢？如果你停下来思考，答案其实很明显：

• 在你开始之前，你有许多工作流，最终汇集成一个复杂的发布——这些就是流入河流的溪流，最终堆积到水库中。

• 在旅程的开始，你对主要问题和挑战有相当清晰的了解。这些问题对所有人来说都很明显，并且是造成最大痛苦的原因——这些就像是锁和水坝。

• 你移除了这些障碍，流量开始变得更加一致，但它依然受到巨石的阻碍——这些障碍包括缺乏工程最佳实践、不良的文化和行为、缺乏开放和诚实的环境等等。

• 你系统性地解决并去除了每一块巨石，开始获得一个稳定、持续的流程，但新的不可预见的问题开始浮现，阻碍了你的进展——这些就是那些水面下实际上是巨石的小石子。

如果你回顾一下，你最初的目标和愿景集中在大象曝光检查阶段（人造水闸和大坝）中突出的问题——那些你知道在开始时就存在的问题。随着你系统地解决这些问题，你交付的软件流开始更加顺畅，你和更广泛的业务也开始看到一些积极和有趣的成果。随着时间的推移，那些不太显眼或重要的障碍（巨石）变得更加明显，成为了令人担忧的原因。于是，你改变了焦点，去除这些障碍，从而再次改善了整体流动性。

由于改进的本质，越是让一个流程变得高效和有效，越是会有那些小小的烦恼（小石子）变成障碍（巨石）。这并非 CD、DevOps 或 IT 特有的问题；这只是一个普遍现象。

这绝非全是悲观和沮丧，也不需要过于担心。你和业务已经面临过更大的挑战，现在你们具备了足够的组织成熟度，可以轻松应对这些新出现的障碍。这是成功的标志。

成为自己成功的牺牲品

人类是非常善变的生物。由于大多数业务由人类构成，它们也同样善变。短暂的成功很快过去，逐渐淡入集体记忆中，而几周或几个月前并不算问题的事情开始成为大家热议的话题——无论是在镇上的街头巷尾，还是在董事会、茶水间或洗手间。成功的另一个问题是，这会成为新的基准，意味着即便是最小的问题也可能迅速演变为重大问题。这些问题可能是一些相对简单的事情，例如：

随着采纳的成熟，相对较小的问题可能变成新的挑战

在几个月的时间里，最初在大规模发布周期约束下工作的团队成员——这些发布周期需要几周或几个月来整理、测试和推送到生产环境——几乎已经忘记了那些黑暗的旧日子，现在却开始找寻新的担忧和抱怨。这并不罕见；它发生在每一个项目中，不论是重大的业务变革项目，还是相对简单的软件交付项目。这并不奇怪，但如果你仔细思考，它其实是一个积极的问题。

直到最近，工程团队由于大规模发布过程中的官僚主义、复杂性和约束，受到严重限制，无法真正创新、实验或展示他们的工程能力。他们现在不再需要担心软件发布的过程，因为这已经成为一种日常的背景噪音，反复进行，不需要太多的努力——这主要得益于你们所做的出色工作。

现在提出的这些看似小问题，在黑暗的日子里，可能只是一些简单的麻烦，会被当作低优先级的问题被忽视或忽略。它们曾是水下的鹅卵石。现在，它们变得真实而庞大，像巨石一样，必须被解决；否则，可能会出现事情停滞不前的风险，日子也可能重新变得暗淡。

此时，你和更广泛的业务团队可能会开始问以下类型的问题（如果能帮到你，我也提供了我的回答）：

问题	答案
新问题的出现是否意味着你原本的目标没有实现，你已经失败了？	不是的！这只是意味着形势发生了变化。
这全都是浪费时间吗？我们似乎有和最初一样多的问题。	不是的。你之前遇到的那些问题——比如很久以前的“大象问题”——要大得多，影响范围也更广，而且从各方面看都被忽视了，或者至少是被接受了。而这些新出现的问题在直接比较下显得微不足道——尤其是对业务的成本来说——并且现在已经公之于众，所有人都能看到。
我们还需要花多少钱？	这取决于新问题的规模和相对优先级。然而，既然 CD 和 DevOps 现在已是标准 SDLC 的一部分，你应该像投资业务流程和工具中的任何其他部分一样进行投资。
我们错过了什么吗？	不，大多数新问题是在旅程开始时无法预见的，或者仅仅是些小麻烦。
这是否意味着你需要改变目标，制定新的计划，重新开始？	不一定。你现在需要的是一些 PDCA。

那么，究竟什么是 PDCA 呢？让我们来了解一下。

[P]lan, [D]o, [C]heck, [A]djust

这个缩写有多种变体；然而，最广泛使用的是计划、执行、检查和调整。你也可能听到 PDCA 被称为戴明循环或谢瓦特循环。无论你偏向哪种定义，PDCA 方法背后的理念都非常简单；它是一个框架和方法，帮助你进行持续的迭代改进。以下这个简单的图表应该能帮助解释这一点：

PDCA 的迭代过程

简单来说，这种方法是对之前多次提到的检查和调整方法的扩展——虽然实话说，它存在已久。这个概念非常容易理解和遵循，并且几乎可以应用于你 CD 和 DevOps 采纳的每一个方面。让我们看一个例子：

• 计划：你意识到当前的软件交付流程有问题，并决定通过运行研讨会来找出原因，绘制整个流程地图

• 执行：你运行研讨会，并从整个业务中收集输入和数据

• 检查：你分析输出，确定所提供的数据是否能让你了解流程中的痛点在哪里

• 调整：你突出显示一些浪费的领域，并商定纠正措施

• 计划：你设定一个目标，并制定一项攻击计划来解决主要痛点

• 执行：你按照这个计划执行

• 检查：你审查进展与目标之间的关系

• 调整：当发现更多信息和未预见的障碍时，你对方法进行微调

• 计划：你重新调整计划，确保在获取新信息后仍然可以实现目标

• 执行：我觉得你可以自己填写剩下的部分

就像本书涵盖的大多数工具和技术一样，与其他方法相比，选择 PDCA 方法是你的决定；然而，这是一个经过充分验证和广泛认可的框架——特别是当你考虑实施像 CD 和 DevOps 这样广泛影响和改变业务的东西时——因此，我建议你不要简单地忽视它。

如果你注意到收集数据和度量的重要性，正如第七章《重要的测量指标》所述，你现在应该有足够的数据来在 PDCA 的检查阶段使用，这将使调整阶段更容易定义。你甚至可能会发现一些不那么明显的问题。例如，如果你发现周期时间经常波动（检查），而这也与 QA 环境的计划外停机时间相对应，而后者又是由于存储空间填满所致，那么有人应该调查为什么会发生这种情况并阻止它发生（调整）——这可能只是（计划）增加更多存储空间。

PDCA 的一个主要优势是它在业务各个层面都易于理解，同时也非常适应性强——例如，本书就是使用了同样的方法开发的：

• 我规划了整本书的结构和内容

• 我随后把这些记录为一个提案

• 我将这份材料交给出版商审核并提供反馈

• 我评估了反馈并对整体计划进行了调整

• 我开始规划第一章

• 我写了第一章

• 我的编辑审阅了它并提供了反馈

• 我调整了第一章

• 我规划了第二章——我想你已经颇费心思地理解了这一点

如果 PDCA 不是你首选的框架或方法，我建议你在采取任何行动之前做一些研究。我特别说“采取任何行动”而不是“你行动”，因为你现在应该退后一步，审视一下自己所处的现状，了解自己接下来需要做什么。

退出，舞台左侧

经过许多个长时间的工作时段、日子和几个月，业务已经习惯了你和你身边的人一起花费大量时间、日子和几个月实施的变化。这个善变的业务现在正在经历并报告他们认为重要的新问题。问题是，谁来解决这些新出现的挑战？答案很简单——不是你，也不是那些与你一起推动 CD 和 DevOps 采纳的人。

你已经帮助嵌入了新的协作工作方式，帮助弥合了开发与运维之间的差距，帮助实施了新的工具并优化了流程，喝了很多咖啡，睡得很少。你已经做了你的部分，现在是时候让你帮助过的人摘掉训练轮，挺身而出，接过缰绳（来混合一些比喻）。

不再需要训练轮

很久以前，在第二章《理解你当前的痛点》中，我们探讨了如何识别业务面临的问题和挑战。我们称之为“房间里的大象”。你帮助整个业务理解并学习如何运用回顾和其他工具回顾过去并规划未来，同时教会他们如何通过开放、诚实和勇敢的对话，找到正确的路径。正如几次所提到的，新的问题和挑战就是这样：新的。

这些新的问题和挑战确实需要解决，但如果你把业务在旅程开始时的状态与现在在组织成熟度方面的位置进行对比，你会发现一个重大且非常重要的区别：现在，业务已经具备了快速识别新的“大象”般的难题的工具和能力，而且现在他们有足够的工具、知识、信心、经验和专业知识，能够迅速且无痛苦地解决这些问题。如果你不相信我，可以重新做一遍第一章《软件交付的演变》中的 CD 和 DevOps 进化量表测验，看看现在业务的得分与几个月前相比如何。

如前所述，你几乎已经达到了最初的目标（或者说差不多达到了，真是的），所以你的告别演出就是帮助他人帮助自己。在这段旅程中很有趣，但所有美好的事物都必须结束，现在正是考虑退出策略的好时机。这并不是说你应该逃避、躲藏，完全不参与；而是意味着，为了充分鼓励新兴的工作方式，你需要扮演负责任的父母角色，让孩子们独立成长，自己学习。

你现在的重点应该从推动采纳（做）转变为辅导和引导其延续（领导）。那些曾是 CD 和 DevOps 采纳的创新者——包括你自己——现在应该开始鼓励那些从采纳中受益的创新者和追随者走到前台，承担起他们自己的责任。这不会一蹴而就，但你需要非常清楚你的意图，让人们理解你正在交接接力棒。像将定期的 CD 和 DevOps 会议的组织工作交给他人，或在下次重大工具升级的时间安排时预留时间休息这样的简单举动，就足够了。当你需要时，“眼不见心不烦”的格言可以派上用场。

就像一个好的父母一样，你为成长和自我发现设定了一个安全的环境，因此，你只需要轻微的引导，偶尔的建议，以及在正确的方向上适时地推动。

作为这种新发现的父母式领导角色的一个重要部分，你需要重新审视 CD 和 DevOps 中更广泛且不易捉摸的领域，以确保自满情绪不会滋生。

不要安于现状

因此，你已经做了很多并取得了更大的进展，企业和其中的员工也因此受益。这是一件好事——你和所有参与其中的人都应该为所取得的成就感到非常自豪。然而，这并不意味着企业可以安于现状；虽然可能很有诱惑力，但仍然有许多需要控制的事情。

之前，我提到过会有新的问题和挑战从水面以下浮现出来，继续让新一代的创新者和追随者忙碌。通过你和前一代人的辅导和引导，他们会没问题并解决这些新的挑战。与此并行的是，当新事物变得常态化时，自满情绪也会随之而来。你帮助了企业发展，但你必须非常注意这样一个事实：如果企业中出现真空，自满情绪渗透进去，它就会像进化一样迅速地退化。

恐惧真空（更常见的说法是“自然厌恶真空”）——亚里士多德

就像任何深远的项目或企业变革一样，如果急剧的变化速度开始放缓或看似停止，事情就会开始停滞，陈旧的固有习惯会重新浮现。在这种环境中，落后者可能会再次变得高调，而追随者们也可能开始听从他们的意见。你将积极而显著地从执行者转变为推动者和影响者；因此，你的角色将是确保事情顺利进行，保持警觉，留心新的威胁。你已经建立了一个良好的网络，因此应该开始利用这个网络来获取早期警报。

与你所取得的成就相比，这看起来可能简单，但有时却更加困难；你习惯了积极参与并推动他人，亲自做事情，而现在你必须保持距离，看着别人做你依然充满热情的事情。虽然有时更难，但同样充满回报。把它当作个人进化的下一步。因此，你现在处于一个良好的位置，可以超越最初的目标，看看是否有机会在更广泛的领域提供帮助。

总结

采用持续交付（CD）和 DevOps 是一个漫长而艰难的过程。如果你认为这不难，那你就是被误导了。随着你接近旅程的终点，你将遇到满是大象的河流和其他不可预见的挑战。在此过程中，需要父母般的指导来引领企业走向正确的方向，同时你也需要规划如何走出聚光灯，腾出空间给那些从你们共同取得的成就中受益的人。新的问题会出现并威胁到采纳的进度；然而，企业现在更加成熟，应该具备应对这些问题所需的工具、经验和智慧。保持警觉是值得赞赏的，但也有更重要、更值得关注的事。在第九章，拓展你的机会视野，我们将探讨一些来自成熟的 CD 和 DevOps 文化中更大、更好的机会示例。

第九章：拓宽你的机会视野

如你所猜到的，我们的关注点主要集中在传统企业中的传统软件交付上，这些公司提供的是传统的 Web/服务器软件解决方案和产品，而非那些年轻、时髦且富有创新精神的初创科技公司。原因在于，初创企业通常具备内在的敏捷性和创新机会，能够灵活交付软件。大多数科技初创企业——尤其是近几年成立的——通常会将 CD 和 DevOps 融入到他们的日常工作方式中。

也许你目前就在这样一家时尚企业工作，但 CD 和 DevOps 并未从一开始就融入其工作方式中。这不应成为问题，因为本书应能为你提供一些解决这一差距的好点子和指导。

绝大多数日常交付软件的公司并没有那么幸运——尽管有意图，但可能缺乏行动的意愿。因此，关注点依然停留在传统模式上。很有可能你自己也在其中一家传统公司工作。

如果你已经遵循了本书中提供的建议，并成功采用了 CD 和 DevOps，那么你很可能已经赶上了那些年轻的天才，你的业务在交付软件的方式上能够同样具有敏捷性和创造力，甚至可能更具优势。

在第八章的尾声部分，你还没有完成，我们将焦点转向了你，以及你如何将新获得的知识、技能和经验继续推进，超越最初将 CD 和 DevOps 工作方式嵌入组织的目标。让我们来看一下这实际上意味着什么。

那我呢？

假设在这个故事的叙述中，你在 CD 和 DevOps 的成功采纳中发挥了重要作用，并达成了你最初设定的目标。事情进展顺利，甚至比你预想的还要好。业务已经成熟，能够独立解决问题，不再需要你牵着手走——嗯，差不多吧。

如第八章《你还没有完成》中所提到的，你还没有结束，你应该花一两分钟考虑一下，在这段旅程的开始时，大多数企业中的个人处于什么位置，现在他们又处于什么位置。考虑一下工作方式、沟通、协作和行为上的变化。想一想在发展初期创新者、跟随者和滞后者的比例，现在又是什么样子。考虑到所有这些，你很可能会发现，现实中，大多数人现在处于你开始时的同一个位置——他们只是刚刚意识到，事情有另一种做法，而且那是一种更好的做法。没错，依然有工作要做，目标是使一切尽可能有效和高效，还有一些小问题需要解决，但总的来说，事情是好的。

现在，看看你个人走了多远；就大多数你曾经合作、指导和教授 CD 与 DevOps 方法的人来说，你就像远处的一个身影：

他人对你的看法

无论你在旅程开始时的角色是什么，开发人员、系统管理员、经理，还是其他什么角色，现在你的角色已经发生了变化。无论你是否喜欢，你已经成为了知识、专业技能和经验的拥有者。你是 CD 和 DevOps 的主题专家。你了解你的专业。

你可能觉得你早期采用的创新者同伴们也都和你肩并肩站在一起，但为了简单起见，今天阅读这些内容的是你，因此你就是那个站在远处的人。

你已经走得很远，景象与你最初开始时大不相同，你还有新的高峰需要攀登——这些是现在企业已经准备好要看的新机会。也许这些曾经是企业无法克服的挑战；也许他们根本不知道这些机会的存在，但凭借新获得的知识，他们渴望尝试新的事物。也许你的首席技术官（CTO）和他年轻时尚的同行在高尔夫球场上聊得很投机。无论是什么原因，现在是时候将你的东西应用于这些新的挑战和机会了。接下来是一些示例，说明你如何在传统软件交付之外，运用你的技能、专业知识和经验。

接下来是一些在成功采用 CD 和 DevOps 后可以开启的机会示例。有些可能在没有 CD 和/或 DevOps 的情况下也能实现，但根据经验，没有这些工具，结果不会那么理想。这些是你——如果你愿意接受——可以投入精力、关注和时间去解决的新挑战和机会。

性能和负载测试

你们中更为细心的人可能已经注意到，本书中几乎没有提到性能或负载测试。这是故意为之，因为在我看来，如果没有持续交付（CD）和开发运维（DevOps）所带来的紧密协作、工具和技术，进行这些活动就是一项徒劳的任务。是的，确实有许多传统的方法，但这些方法通常会在你准备发布代码之前将某些东西强行塞进流程中——这可能会导致由于最后一分钟发现性能问题而导致代码无法发布。你可能已经通过实施一种周期性地获取软件版本并在受控且高度监控的环境中进行密集自动化测试的过程来解决这个问题。这有一定帮助，但除非你已经设置了完全模拟实际使用场景的自动化测试，否则你基本上是在给大家带来虚假的希望，认为代码上线后不会出现性能问题。

我还敢猜测，在暴露问题的检查阶段，性能/负载测试被视为一种负担，甚至是浪费资源的行为。实际上，这种看法既不必要，也不应该是如此。

一旦你采用了持续交付（CD）和开发运维（DevOps），性能/负载测试的过程可以变得相对简单直接。你只需要改变思考和处理问题的方式。

有一种非常简单且易于理解的方法来考虑负载和性能测试；迄今为止，最好的方法是在生产环境中检查软件在实际负载和使用下的表现。你可能正在阅读这段话并想，作者是不是疯了？这可能是真的，但我请求你耐心听我说下去，并自行做出判断。

假设你已经实施了对整体生产环境以及其中运行的软件进行广泛监控（正如在第七章中提到的，关键指标），通过这些监控，你可以详细观察硬件、基础设施和软件在背后发生的情况。通过这些数据，你能够清晰地了解正常日常操作时的表现应当是怎样的。

通过这些数据，你应该能够安全地进行受控实验，并观察平台整体性能的结果。例如，你可以进行一项实验，逐步施加额外的负载到正在使用的平台上，方法可以是将更多的用户活动路由到特定的节点或服务器，或者通过运行一些非侵入性的自动化测试，以受控的方式生成负载。当你增加负载并提高负载时，你将开始看到痛点——一种近乎实时的热图。由于开发和运维团队密切合作，共同观察平台，他们应该能够通过将正常的日常统计数据与负载下生成的统计数据进行对比，找出问题所在。

如果在某个时候问题被定位，它们可以通过使用 CD 工具实时应用补丁来轻松克服，而负载仍然存在——提供即时反馈。或者，他们可能会看到平台的整体慢下来，但监控解决方案没有突出显示任何具体问题。这可能意味着整体监控覆盖存在一个漏洞，这同样可以通过协作方式定位并解决。无论如何，简单地将负载调回正常日常负载即可恢复正常状态。

你们中的一些人可能正在阅读这篇文章，并认为生产环境是神圣不可侵犯的，不应当用于此类活动，因为这可能会影响到同时使用平台的客户。我的看法是，除非你故意限制可以访问生产环境的人数，否则这种负载增加将会在你不知情的情况下以不受控制的方式发生——特别是当你的 CD 和 DevOps 采用直接导致客户满意度和增长提升时。为什么不在增长发生之前，确保你的生产环境已为此做好准备呢？

总而言之，如果没有充分的监控和/或开发与运维团队之间高度的协作，尝试进行性能或负载测试将无法提供预期或所需的结果。在生产环境之外进行测试将得到混合结果。这并不是采用 CD 和 DevOps 的明显好处，但它是一个非常强大且令人信服的好处，就像减少复杂性一样。

减少功能标志的复杂性

有许多已建立的方法可以在实时中切换不同的使用案例或用户流程，但大多数方法都围绕着某种功能标志或平台中的配置设置展开。尽管这是一个可行的方法，但它确实会在代码库中增加一些内容，随着时间的推移，这可能会成为一个巨大的麻烦。这个“东西”就是复杂性。

这不仅增加了代码库的复杂性，还增加了相关活动的复杂性，如测试和整体平台的设置/支持，尤其是当你开始将特性标志链式连接时。例如，假设你有一个新的报告功能（我们称之为特性 C），如果报告菜单功能（我们称之为特性 B）被手动启用并且遗留报告功能（我们称之为特性 A）被手动禁用，那么特性 C 会自动启用。如果特性 A和B 被手动启用，那么特性 C 会自动禁用。然而，如果特性 A 和 B 都被手动禁用，那么第三方报告功能（特性 D）将自动启用。

以下可能会使这个例子更容易理解：

这一切看起来足够简单，基于简单的逻辑门，但想一想，当你拥有一个平台，其中有特性标志控制着数十个或数百个特性时，会发生什么——其中一些是相互独立的，而另一些则形成了一个奇怪、复杂的链式特性树。测试所有这些组合并尝试支持一个可以设置成数百种（有时是数千种）不同状态的生产系统将是一场噩梦，更不用说当问题出现时，试图调试特定问题是多么徒劳无功了。

我曾经参与过一个产品的开发，其中有超过 50,000 个特性标志——大多数特性标志的来源和控制的功能早已被时间的迷雾掩盖，因此，新的特性标志不断被添加，用来控制新添加的功能。复杂性完全失控！

成功采用了持续交付（CD）和 DevOps 后，你将能够定期且持续地轻松地发布代码，并且开发和运维团队将紧密协作。因此，使用 CD 方法来启用和禁用功能将变得更加简单。换句话说，要启用某个功能，你只需要发布包含该功能的代码——不需要使用标志、设置或复杂的链式操作。你当然会先进行测试，确保没有出现意外的负面影响，但有一个非常简单的回退方法：发布不包含新功能的先前版本（如果你遵循第五章中的“永远不破坏你的消费者”建议，方法、工具与技巧，回滚应该不会引起任何问题）。我相信你会同意，这种方式既简单易懂，又便于开发和支持。

好吧，这可能是一个过于简单化的观点，但通过 CD 和 DevOps，你可以开始以新的和创新的方式看待这些问题。其优势可能不会立即显现出来，但至少减少复杂性将为你节省时间、金钱和精力，同时减少过程中的浪费。

在软件中使用功能标记的原因之一是为了实现 A/B 测试。现在我们来看看 A/B 测试到底是什么，以及 CD 和 DevOps 如何帮助改善这种方法。

A/B 测试

A/B 测试已经存在一段时间，它是一种非常有效的方式，用来尝试对用户旅程和/或软件解决方案中的逻辑流程进行更改。其简单的前提是，通过配置、功能标记或巧妙的流量路由，你可以将一定数量的用户（或通过使用软件本身产生的交易）引导到不同的路径。这有助于在通常是在生产环境中以受控条件下尝试新功能和/或功能，以验证或反驳某些假设。

我不会深入探讨这个话题——有很多书籍和在线资源专注于这个话题，我鼓励你去阅读。

举个例子，假设你的业务想要看看如果引入一个新的设计或微妙的网页布局变化会产生什么影响。如果你能够以某种方式将特定的用户或用户群体引导到路径 A，而将其余的用户引导到路径 B，那么你就可以通过分析和度量来监控并比较用户行为，看看哪种效果最好。

下图提供了这种方法的简化概览：

一个简单的 A/B 测试示例

另一种有用的方法是偷偷进行 A/B 实验。例如，如果你有一个新的推荐服务想要试用，你可以将一些用户流量和交易引导到这个新服务上，看看它与现有服务的表现如何。你甚至可以使用相同的机制，将数据路由到特定服务作为负载测试的一部分。可能性是无穷的。

你不一定需要 CD 或 DevOps 来实现 A/B 测试；然而，两者确实能为你带来一些重大好处：

• 能够极其快速地发布代码——例如，你希望在几分钟内在所有服务器上实施代码，将流量分配到 A 或 B，从而确保所有用户同时使用相同的代码。

• 你有开发和运维团队紧密合作，监控正在发生的一切。如果在用于分析结果的数据中发现有缺口，你能够相对容易地解决这一问题。

• 如果事情发生意外变化或你已完成实验，你有选择相对快速回滚所有内容的选项，并且几乎没有或完全没有影响。

如果没有 CD 和 DevOps，你需要提前非常紧密地规划此类活动，并且希望在实施时没有遗漏或错误。除非你有能力进行小规模的补丁发布，否则你无疑需要在完整的发布周期内包含任何变更——无论多小——以便启动正常的、规避风险的流程。完成后，回滚这些变更时也将适用同样的流程。

A/B 测试的另一种变体（或至少是一个紧密相关的形式）是 Alpha 测试和 Beta 测试（有时称为封闭测试或预发布测试）。这使我们能够在现有解决方案的基础上尝试广泛的 UI、UX 和功能性变更。通常，这种测试会限定在特定的用户群体中，或仅通过邀请进行。与 A/B 测试传统上针对小范围、具体的变化不同，这种测试通常更为广泛。基本前提仍然适用：以受控的方式尝试新功能和特性。同样，虽然可以在没有 CD 和 DevOps 的情况下实现这一点，但这样做将更加复杂、风险更高，并且容易失败，因为旧式的流程会妨碍进展，拖慢速度，并且——根据经验——最终会被归咎于测试失败的原因。试想一下，如果没有及时响应问题的机制，如何同时维护两个版本的整个 UI 并使其并行运行。

如前所述，A/B 测试基本上是为了验证或反驳某些假设，无论是由于市场条件变化，还是作为战略方向改变的一部分。无论背后的原因是什么，进行 A/B 测试通常是时间敏感的。如果没有 CD 和 DevOps 帮助你频繁交付高质量软件，成功运行 A/B 测试的能力将受到阻碍，因为在你努力计划和执行发布的同时，世界可能已经发生变化，而你最初想要测试的用例可能不再相关。正如人们所说，时间不等人，也不等女人和 A/B 测试。

接下来我们将从测试转向颜色——实际上是蓝色和绿色。

蓝绿部署

一些熟悉 CD 的人无疑听说过蓝绿部署，它是原始 CD 方法的基石之一。对于那些不了解的人，蓝绿部署允许你在现有版本/服务器运行的同时（如其名所示）部署软件的新版本（或具有更新操作系统的新服务器，或新的配置或数据库引擎等），然后无缝地将新版本切换为旧版本。这是对这种方法的一个非常简化的概述，但可以说这是一个相对容易理解的概念。

这种方法大大提高了你不仅减少/消除停机时间的能力（见 第五章，方法、工具与技术），还可以尝试并行版本控制（例如，在同一环境中运行两个不同版本的相同内容）——这同样能帮助 A/B 测试：

尽管这种方法与持续交付（CD）紧密相关，但采用 DevOps 也会使得管理、规划和协调变得更加容易。如果开发和运维团队之间没有密切的合作与信任，就有可能导致问题严重—尤其是在处理生产环境时。例如，如果一名开发者不小心将破坏性变更部署到 API 中，并且这个 API 与现有的 API 一起存在，但消费者服务（见第五章，方法、工具和技术）开始同时与两者进行交互，这将导致非常不一致的结果，甚至让人摸不着头脑。有了 DevOps，找到根本原因相对容易，并且可以通过协作来修复潜在的数据问题。

我不打算深入细节，但我强烈建议你进行一些 CD 的研究和阅读—在附录 A，一些有用的信息中有相关参考资料—不过，可以简单地说，蓝绿部署是一种非常强大的工具。

我强烈推荐的另一件事是利用 CD 和 DevOps 来减轻安全补丁的负担。

安全补丁与“拯救培根”

看起来每天新闻中都充斥着关于最新遭到黑客攻击的企业，或是遭受分布式拒绝服务（DDOS）攻击的报道。当然，这些只是我们知道的—研究表明，很多企业并未公开承认大规模的 IT 安全问题（又为什么要承认呢？）。近年来，这使得企业，尤其是高层管理人员，对变革变得异常谨慎，并非常关注确保他们的 IT 系统在安全补丁方面保持完全（或至少大部分）最新。大多数时候，这通常是以软件交付为代价的。

当企业采用了 CD 和 DevOps 时，安全补丁的实施和验证就变成了另一个需要交付的变更。如果补丁是在操作系统（O/S）级别，那么第五章，方法、工具和技术中讨论的配置即代码方法将会适用。对于网络、基础设施和运行时框架（例如 JAVA、.NET 等）也是如此。如果补丁是在软件层面（例如，某些使用的开源软件中发现的补丁），那么通过 CD 管道交付软件变更的方式已经经过了充分的验证。

为了简化叙述，假设某个企业遭到黑客攻击，客户数据由于网络中的安全漏洞和未打补丁的操作系统而被盗。

现在让我们将这个场景应用于一个没有采用 CD 或 DevOps 的传统上市公司。考虑以下问题并思考可能的答案：

1. 你认为他们会多快修补漏洞以解决问题？

2. 你认为他们的运营团队在 CEO、公关副总裁和运营高级副总裁都在盯着他们想知道 IT 系统何时修补时，心情会有多冷静？

3. 你认为运维团队对匆忙应用本应几个月前就该应用的操作系统和网络补丁不会影响软件平台有多自信？

4. 当工程高级副总裁告诉开发团队他们在解决由于匆忙应用操作系统补丁引发的问题之前不能回家时，你认为他们会有多高兴？

5. 当新闻曝光他们被黑客攻击，客户数据被窃取时，你认为一家上市公司会失去多少市值？

6. 会有多少人被辞退？

猜测这些问题的答案并不需要博士学位。像这样的情况并不像以前那样孤立或罕见，近年来的后果已经非常广泛，代价高昂，并且让那些卷入其中的人们的职业生涯受到了限制。

现在，想象一下一个已经采用 CD 和 DevOps 的公司的相同情况。对前面问题的回答大致会是这样的：

1. 他们能像平时一样迅速发布——最多几分钟或几小时。

2. 完全冷静，坦白说，高层管理人员直到通过常规监控发现问题并被告知正在处理时才会知道。

3. 非常自信，因为他们可以与开发团队合作，确保不会产生影响和/或并行工作以制定应对影响的计划。

4. 他们不会有这种问题。

5. 如果传达的信息是：“我们发现了一个问题并已经应用了修复。影响非常小，我们可以向客户保证他们的数据是完全安全的，”那么这条新闻不太具有新闻价值，市场甚至可能不在乎。事实上，他们可能会将此视为好消息，并希望加大对该业务的投资。（好吧，我无法量化这个，但它是有可能的。）

6. 没有人。

如果你的 CD 和 DevOps 采用已经成熟，因安全补丁过时而导致黑客攻击的概率会非常小，因为定期安全补丁的监控和实施将被纳入日常工作流程中，无论是通过配置即代码（configuration-as-code）还是作为软件交付流水线的一部分。然而，始终会有不可预见的安全漏洞，所以了解当这些情况发生时有一种快速的解决方式是很重要的。

如你所见，采用持续交付（CD）和 DevOps 可以带来一些非常重要的拯救局面的好处。这并不是说没有 CD 和 DevOps 你不能取得相同的结果，但能够快速交付，并且开发和运维团队之间有非常紧密的合作关系，将使得在问题发生之前更容易发现并修复实时问题——而不是让你的公司成为晚间新闻的头条。

如前所述，总会有无法预见的事件影响生产系统的正常运行，保持领先应对这些事件可能是困难的。然而，确实有一种方法可以帮助在这些问题显现之前发现它们。这就是主动去尝试破坏实时平台。故意的。

混沌猴子中的秩序

无论你多么细心地照顾和关注你的平台，总会有不可预见的事情发生，尤其是在你最不期望的时候。例如，服务器可能会崩溃，进程可能会开始循环，网络交换机会决定不再作为网络交换机工作，SAN 会决定自己喜欢在单用户模式下运行，最新的安全补丁可能会导致软件平台出现问题，或者有人会因为你是一个大目标而决定黑你。正如那句老话所说的，你应该时刻准备好应对意外。

大多数企业都会有某种业务应急计划来应对突发情况，但很有可能他们并不会刻意去强迫问题的发生，至少不会让它发展到实际发生坏事的程度——他们只是希望坏事永远不会发生，如果发生了，他们希望并祈祷能够做好准备，计划能够发挥作用。

如果你有一套工具，能够在受控的方式下安全地启动故障，以观察发生了什么， 更重要的是，观察平台中的薄弱环节在哪里，这样的工具是否有用呢？这正是几年前某个聪明人所做的事情，而这也被广泛采用为混沌猴子方法。虽然有一些变种，但其核心内容就是：一套工具，能在你高度监控的环境中运行，其存在的理由就是尽力去破坏它。

如果你对这个话题进行一些研究，你会发现目前大多数工具都集中在基于云的安装环境中。这并不意味着这些工具不能在本地环境中使用，但它们的效果可能较低，且风险较高，所以你需要考虑到这一点。

如果在没有强大嵌入式持续交付（CD）和开发运维（DevOps）文化的情况下尝试这种方法，结果会是一团糟——说实话，我怀疑你是否能在一开始就被允许尝试，因为你需要让组织中非常高层的人理解为什么必须这样做，并愿意承担风险。通过紧密合作、深入监控和依赖信任的关系，依赖 CD 和 DevOps 的做法使得尝试去破坏平台并观察发生的事情相对（但不是完全）没有风险。

这种方法有一个前提：你需要确信你的平台在设计和构建时已经考虑到优雅地处理失败的机制。你应该避免在公开场合犯平台自杀（platformicide），让核心转储和 HTTP 500 错误信息暴露在所有人面前。同样，这可以通过 DevOps 的方式来解决，确保环境和运行其中的软件能优雅地失败。

混乱猴子方法的另一个优势是，它也是一个很好的方式，能让 Dev 和 Ops 团队共享平台如何运作的知识。如任何具有创造性和技术思维的人所说，理解某个事物如何运作的最佳方式就是将其推到极限，看看它的运作机制。回到我们在第七章中提到的 F1 赛车类比——关键测量，工程师和驾驶员会在测试和练习圈中定期将赛车和组件推向极限，确保赛车在需要时按设计工作。通过这种活动获得的信息，可能意味着能否站上领奖台与被超越之间的差距。

现在我们将暂时不讨论持续交付（CD）和 DevOps 的潜在破坏性力量，而是考虑 CD 和 DevOps 如何使你的客户和组织内其他团队的工作变得更加轻松。

终端用户自助服务

在本书的过程中，我们一直关注将软件推送到指定环境（包括生产环境）的单向流程。其本质上是一个软件工程团队对自己的变更充满信心，因此触发将其发布的过程，或是一个 Ops 团队有信心将配置作为代码的变更发布。

如果你把这个情况颠倒过来，允许你软件平台的用户随时主动“拉取”你的软件呢？这听起来可能有些奇怪，但在某些合法的场景下，这种做法可能是必要的。

我们来看几个场景：

• 你有一个实施团队，负责新客户的引导，他们希望测试不同的场景和用例，以确保他们的手动测试脚本、常见问题解答和培训文档是最新的。

• SecOps 团队需要在他们封闭的测试实验室中，针对平台的副本运行一系列深度安全扫描和一些 DDoS 场景。

• 公关和市场营销团队需要为新闻稿拍摄当前 beta 平台的屏幕截图。

• 销售团队即将向一个重要的新客户展示，并希望在他们的 Mac 上的虚拟机中运行软件平台的本地副本，因为会议中心内没有可靠的 Wi-Fi。

• 一名内部审计员正在调查六个月前的数据泄露事件，并希望获取当时平台的精确副本。

使用传统的技术和方法，前述每种场景都会涉及大量琐碎的工作（我这是在轻描淡写）来设置一个专用环境，并让所有需要的软件安装并正常工作——更不用说基础设施的设置了。这些琐碎的工作必须根据各个团队已有的工作负载来进行优先级排序，因此可能需要很长时间——很可能远远超出环境需要的时间。我敢肯定，你自己一定也经历过这种沮丧——我知道我经历过很多次。

现在考虑一下，如果这些团队/用户能够按下一个按钮，自动为他们设置一个完整的环境，这将会减少多少琐碎的额外工作？如果他们还可以通过自助服务门户指定他们想要的精确版本（例如，生产版本、测试版本、当前进行中的工作、时间快照等等），那该多好？

随着 CD 和 DevOps 融入你的工作方式，没有明显的理由不能做到这一点。虽然这需要一些设置工作，但你已经拥有可靠的工具来配置环境、部署软件资产，并提供深入的监控。如果自动化出现了偏差，或者没有涵盖某些场景，你有一个习惯于协作的 DevOps 团队，他们也乐于帮助解决问题。

将用户自助服务的范围扩展到你的组织边界之外，也是 CD 和 DevOps 可以帮助你实现的目标。

作为服务的物品

随着软件解决方案的成熟，投资于这些解决方案的企业不断寻求新的、有趣的方式来利用已作出的投资。通俗来说，他们希望从已支付的软件中赚取更多的利润。

有很多成熟的方法可以实现这一点，但PaaS（平台即服务）或SaaS（软件即服务）是最受欢迎的，并且在通过现有软件平台赚取更多收入的全新且有趣的方式中非常流行。你可能还记得我们在第三章，文化与行为——成功的基石中简要提到过这些内容，涉及第三方工具。其基本前提非常简单；你通过应用程序编程接口（API）将某些功能暴露给第一方或第三方，他们使用这些 API 扩展他们的软件平台，以包括你所提供的功能。例如，如果你的软件平台专注于汽车租赁预订，你可以将 API 暴露给一个价格比较网站，让他们的用户能够通过你的软件平台无缝地预订汽车。

这种方法已经存在多年，有时被称为 B2B 或类似的东西，但它一直被视为一种实施、维护、安全、变现和支持起来都非常痛苦的东西——尤其是对以传统方式交付软件的公司来说。在涉及对可能影响 API 的任何更改时，也存在复杂性，这可能导致技术债务的积累和/或使使用这些 API 的客户/客户端不满（参见 第五章中的“永远不要破坏你的消费者”，“方法、工具与技术”）。与此相对的是，任何所需的 API 更改交付速度较慢——当第一方或第三方已经采用了 CD 和 DevOps 并能比你更快地行动时，这成为了一个问题。这有时会导致他们开始寻找下一个合作伙伴。

我不会说 CD 和 DevOps 的采用可以在没有任何努力和投资的情况下实现这种方法，但它确实能大大简化使其启动和运行的过程，并保持其持续运行。这反过来应该消除“SaaS/PaaS 实施起来过于痛苦”的看法，并应被视为一种利用软件平台的新颖且有趣的方法。此外，你还会发现，已经采用 CD 和 DevOps 的组织更有可能与那些以类似方式运作的供应商合作，因为他们知道新的需求可以快速且可靠地实现，且合作是自然而然发生的事情。

总结

在本章中，我们专注于你在推动 CD 和 DevOps 采用之后的演变，以及你如何帮助业务发展超越仅仅是频繁交付高质量软件的阶段。我们回顾了一些例子，说明 CD 和 DevOps 如何进一步改善所有参与产品交付的人的工作方式，以及它们如何为业务打开新的机会。

你或许能想到一些与自己情况、组织或业务更相关的场景和有趣问题，但重点是，一旦 CD 和 DevOps 融入你的工作方式，你就能够减轻 Ops 和 Dev 团队的负担，帮助他们解决新问题，并提高你内部和外部客户的满意度。

到目前为止，我们一直在讲述 CD 和 DevOps 运动的创始人力求优化、简化并减少痛苦的网络/服务器软件交付方式。在我们的最后一章中，我们将探讨 CD 和 DevOps 如何在它们的舒适区外使用，以及你如何为你的组织和业务带来更多的价值。

第十章：超越传统软件交付的 CD 和 DevOps

CD 和 DevOps 通常与交付基于 Web 服务器的解决方案相关——这并不意味着它仅限于此，然而，这是常态。正如你所学到的，CD 和 DevOps 并不特别与工具或技术相关。CD 和 DevOps 的真正采纳是基于文化、行为和工作方式的提升，以顺畅变更流程，从而实现持续交付价值。这意味着它们不必局限于传统的软件交付方式。一旦你的业务采用了 CD 和 DevOps 作为我们这里的工作方式，你就可以、应该，并且能够将相同的方法应用到解决其他业务问题上。

最显而易见的做法是将 CD 和 DevOps 方法应用到大多数交付软件解决方案的企业通常认为困难的事情上：移动应用。

CD、DevOps 与移动世界

CD 和 DevOps 基于文化、行为和工作方式，因此，将这些方法应用于交付移动应用程序——这是一个庞大且不断增长的行业——是可行的。这并不是说它是一个千篇一律的采纳；在交付移动应用软件与 Web 基于服务器的软件交付方式之间，确实存在一些不同之处，当前的主要差异如下：

1. 每天无缝地将软件交付到 Web 平台 10 次而不影响最终用户是可以实现的——你完全控制着基础设施和发布机制。而同样的操作如果应用到移动应用程序上，会对最终用户产生重大影响——你能想象如果每天向最终用户的智能手机发送移动应用 10 次会发生什么吗？

2. 终端用户的智能手机/平板电脑、音响、冰箱、灯具、门锁、宠物监控摄像头等设备中没有 Ops 团队，因此，DevOps 合作中的 Ops 部分并不严格存在。

3. 你无法保证你将要部署的设备的规格、尺寸、网络能力等。

4. 严格来说，你并不完全控制软件的最终分发。

那么，你如何解决这个难题呢？让我们依次来看看。

关于第一个要点，实际上你不会希望比每几周一次的频率更频繁地发布——即便你具备这样的能力——因为这样只会骚扰终端用户。因此，你应该采用发布列车的方法。实质上，这意味着逐步积累变更（这些变更都是独立构建、测试和通过你的 CD 管道发布的），直到你觉得足够的时间已经过去，可以进行发布。有一个例外：你可以（并且应该）频繁地向内部 Beta 测试/自用用户发布，以便他们随时体验最新版本。

关于第二点，除非你能将运维团队缩小并克隆成数百万倍，否则你能做的也不多。不过，如果你按照第五章《方法、工具和技术》和第七章《关键指标》的建议，你会在软件中嵌入分析和度量，并且已经实施了深入的监控，因此，你将能够像在服务器上运行软件一样，发现应用程序在运行中可能出现的问题。如果发现了问题，开发和运维团队可以协作，找出问题所在并加以修复。

关于第三点，你可以尝试在测试中考虑这一点，但说实话，这是一项非常没有回报的工作。我建议集中精力关注畅销应用，并根据捕获的分析数据和指标，确定用户更喜欢哪些尺寸、规格和设备类型——如果你看到某个设备类型的使用趋势上升，那么你应该考虑将其加入到支持的设备列表中，并将其包含在自动化测试套件中。否则，你可以考虑使用专门从事移动设备测试的外部解决方案/提供商——许多这样的解决方案可以通过 API 驱动，这意味着你的测试解决方案可以协调并控制测试的执行。

关于最后一点，你能做的并不多。目前，领先的应用商店已经非常成熟且可靠，且在全球范围内具有良好的覆盖。持续交付（CD）给你带来的优势是，应用商店实际上是一个二进制仓库，而这正是你的 CD 流水线已经习惯发布到的地方，因此发布可发布的应用程序的机制与服务器端软件的发布机制非常相似。此外，大多数应用商店都支持自动更新，这意味着当你发布新版本的应用程序时，最终用户应该很快就能收到更新。然而，也没有绝对的保证，因此你需要考虑到，仍然会有一些版本在外面运行，需要支持。

这实际上只是表面上的探讨，但它在某种程度上突出了传统基于服务器的应用程序和移动应用程序在软件开发生命周期（SDLC）过程中的相似性。

现在，你可能在阅读这段文字时会想，许多科技公司正在构建并发布移动应用程序，而并没有正式遵循我们在本书中讨论的持续交付（CD）和 DevOps 方法，那么为什么你还需要去在意呢？因为你可以，而且它会带来价值。将协作、信任和诚实融入到组织中的工作，可以轻松地应用到你的移动应用程序上。你已经实现了工具和技术来自动化构建、测试、发布和监控服务器平台的过程，因此将这些扩展到你的移动应用程序上应该是（相对）简单的。

另外，现在可以使用与服务器端网站相同的技术编写移动应用，并将其构建为本地移动应用程序。这意味着同一代码库可能被部署到服务器和移动端，因此使用相同的技术、工具和方法将使流程无缝，并节省大量时间、精力和金钱。

另一个非传统领域可以应用 CD 和 DevOps 工作方式的领域完全超出了软件交付的世界范围。

拓展至软件交付之外

迄今为止，本书一直倡导采用持续交付（CD）和 DevOps 来显著改进软件无缝、快速和持续交付的能力。CD 和 DevOps 并不仅限于软件/产品交付。

这种工作方式带来的工具、流程和最佳实践可以扩展到业务的其他领域。当然，某些工具和技术可能需要进行一些调整和更改，但总体而言，重要的是行为、文化和环境因素。

让我们来看看一些超出软件交付范围的领域，可以从 CD 和 DevOps 工作方式中受益，首先是 UX 和设计。

UX 和设计

大多数交付软件的企业——尤其是包含用户界面的软件（网站、桌面应用等）——通常都会有 UX 和/或设计团队参与 UI 和用户体验资产（线框图等）的工作。即使是最敏捷的组织，在处理 UX 和设计时也通常会采用瀑布式的方式。例如，大多数 UX 和设计团队通常独立于软件工程之外。通常的做法是在开发开始之前预先创建资产，这些资产会输入产品积压列表。敏捷软件开发方法在某种程度上解决了这个问题，但大多数方法并未关注密切的协作需求以及文化、行为方式和持续交付的重要性。

您可以（也应该）利用您新获得的经验和技能，改善设计和 UX 资产的构建和交付方式。如果与 UX/设计团队合作，并让他们考虑如何将这些资产拆分为更小的逻辑块（就像您的软件平台一样），并逐步交付，您可能会发现流程变得更加顺畅、高效，减少浪费。在工具方面，有许多成熟的设计/UX 软件解决方案提供协作功能和敏捷交付。

业务流程改进

假设你已经按照本书中的建议，识别并移除了产品交付过程中浪费的部分，现在通过采用 CD 和 DevOps，流程已变得最优和高效，但在实际的产品交付过程之前和/或之后的业务职能和流程开始拖慢了进度。

例如，你可能有一个团队在管理销售线索和业务组合/需求收集，这些信息最终流入产品交付或交付后的实施/支持团队，这两个团队中的一个或两个正在努力跟上快速变化的步伐。

没有理由不能使用本书前面提到的相同技术来解决更广泛的商业问题。作为一个组织，你现在拥有了足够的经验、信心和尊重，能够将那些笨重和复杂的事务简化并高效运作，那么为什么不将这一经验应用到更广泛的领域呢？

回到之前的例子，你应该能够隔离出在产品交付流程之前和之后的业务流程，并进行类似的检查（找出问题所在），解决行为、文化和环境问题，并定义和实施工具、技术和方法，以简化流程并衡量结果。

这样做可以带来更大的商业价值，并使更多业务部门意识到 CD 和 DevOps 工作方式的巨大好处。你的整体业务流程越无缝，整体影响力就越大。如果你能以一种高效的方式捕捉客户需求，你就能够交付他们想要的，并提供他们期望的服务水平。

业务增长

之前，我们讨论了 PaaS 和 SaaS 作为向客户交付软件解决方案的模式，但那我们应该如何看待新的商业机会呢？如果你已经成功实现了自动化配置，或许你应该考虑扩展业务，为客户提供 IaaS——毕竟，你们已经具备了为自己提供这一服务的专业能力，为什么不为客户提供呢？

业务增长的其他领域可能来自于利用目前已在组织内部嵌入的技能和经验。回想一下当初你需要 CD 和 DevOps 领域专家的帮助时。如果你曾经得到过一些帮助，我敢打赌那并不便宜。那么，如果你的客户自己交付软件，但需要帮助开始采用 CD 和 DevOps 呢？你或许能提供这种帮助作为附加价值——也许你应该建议他们购买几本这本书？别怪我试图这么做。

优化的反馈循环

这个短语在敏捷软件交付方法中已经讨论了一段时间。对于那些不熟悉的人，这与减少从用户那里获得反馈的时间有关，反馈的内容是你提供的软件如何运作、如何执行。反馈可以有多种形式——如 NPS（净推荐值）功能、反馈表单、评分——但最重要的是尽早获取这些反馈。如果你已经采用了 CD 和 DevOps，并能够快速交付变化，那么你确实需要及时获取反馈，以确保交付的内容符合预期（和质量标准）。如果等到特性构建完成两三个月后才得到反馈，那就没多大意义了，因为此时世界可能已经发生变化，反馈也就失去了价值。

最简单的优化反馈循环方式是利用组织内已经植入的文化、行为和协作方式，向内部团队成员（或组织中的任何其他人）获取公开、诚实的看法，随着功能和特性的逐步交付。你可以利用在第九章中提到的自助功能，拓展你的机会视野。然而，更大的价值来自于及时从目标终端用户那里获取反馈。

随着 CD 和 DevOps 的采用，使你能够快速、可重复和可靠地交付软件，你应该能够整合工具来收集终端用户的反馈（如之前提到的），如果结合你所嵌入的度量和分析（见第七章，关键指标），将为你提供非常丰富的反馈和相关数据。传统上，这些反馈会由软件工程以外的团队收集和/或整理，而采用 CD 和 DevOps 工作方式后，软件工程团队将习惯于处理这些数据，从而能够更快速地作出反应。

正如我所说，CD 和 DevOps 不仅仅是交付软件；完成工作的方式、协作、公开诚实的环境、基于信任的关系，甚至是使用的语言，都可以并且将有助于振兴和增强任何业务流程。

那我呢？

上述内容只是一些示例，但如果没有人为业务提供帮助并引导其走向正确方向，它们都无法成为现实。无论你喜不喜欢，你将会拥有经验、技能和声誉，成为与 CD 和 DevOps 相关事务的首选人。

现在，你有机会开始一段新的旅程，通过推动只有在成熟且强大的 CD 和 DevOps 文化下才能实现的变化，帮助业务自我发展。

如果这不符合你的兴趣，或许跟上不断变化和扩展的 CD 与 DevOps 领域才是你感兴趣的事情。仅仅追赶新的做事方式、新的工具、新的想法和新的见解就可能占据你大部分的时间和注意力。越来越多的企业意识到，拥有倡导者对他们至关重要——尤其是在软件和产品交付方面。

你可能已经将自己融入了全球 CD 和 DevOps 社区，这将为你提供与他人分享或展示自己经验的机会，更重要的是，将他人的经验和知识带回到你的业务中。也许你甚至可以将这些经验记录下来，发布到公共博客和论坛，甚至出版成书。奇怪的事情时有发生。

无论你选择做什么，你都不会感到无聊，也无法回到以前的状态。你已经学到了一课：有更好的方法，而 CD 和 DevOps 正是其中之一。

你学到了什么？

我一直在提到你的经验、知识和专业技能，但直到你真正经历过采用和实施 CD 与 DevOps 的过程，这些都只是你读到的内容。让我们最后再总结一下我们所讨论的内容：

• CD 和 DevOps 不仅仅是关于技术选择和工具的，它们的成功很大程度上取决于行为、文化和环境。

• 实施和采用 CD 与 DevOps 是一个过程，刚开始可能看起来漫长而令人生畏，但一旦你迈出了第一步，接着一步步前进，你几乎不会注意到时光的流逝。

• 那些成功采纳了 CD 和 DevOps 的团队很少后悔，或者想要回到以前那个发布版本意味着加班和熬夜的时代——熬夜和周末加班应该和创新以及创造一款杀手级应用或下一个改变世界的技术突破紧密相连。

• 你不必同时采用 CD 和 DevOps，但它们是相互补充的。你不一定要同时做，但你应该认真考虑一下。

• 在需要做出技术选择时，确保你所实施的内容能够增强并补充你当前的工作方式——永远不要为了工具而改变你的工作方式。

• 这可能很庞大且令人害怕，但如果你睁大眼睛开始，你应该能够走下去。CD 和 DevOps 现在已经非常成熟，并且有一个全球社区可以提供帮助和建议，所以不要害怕去寻求支持。

• 不要仅仅因为 CD 或 DevOps 是下一个大家都在做的大趋势，就开始实施它们。你需要有充分的理由来采用这些方法，否则你将无法收获它们的好处，也不会真正相信你所做的事情。

• 虽然我们已经讨论了大量内容，但你不必实施你所阅读的所有内容；选择最适合你和你当前情况的部分，从那里开始——就像你会对待任何一种良好的敏捷方法一样。

• 仅仅因为你能交付软件，并不意味着你就完成了。CD 和 DevOps 是一种工作方式，其中的方法可以应用到其他业务领域和问题上。

• 分享失败和成功，这样你可以从中学习，别人也有机会从你身上学习。

总结

这本书，和所有美好的事物一样，已经结束了。如同多次指出的，我们在这些页面中讨论了相当多的内容。 本书绝不是采用 CD 和 DevOps 的权威著作；它只是基于真实世界的经验和战斗故事，按逻辑顺序整理出的一系列建议。我建议你花些时间通过其他阅读材料和书籍来扩展自己的知识，甚至参加一两场会议。

即使你只是看看需要什么来实施和采纳 CD 与 DevOps 的工作方式，现在你应该对自己和组织将要面临的情况有了更清晰的了解。正如人们所说，“有准备就是有优势”。这不是一段轻松的旅程，但它值得。

所以，去拿一杯热饮，一本笔记本和一支笔；跳回到第二章，理解你当前的痛点，开始绘制出为什么你需要采用 CD 和 DevOps，以及你打算如何去做。

那就去吧。别再读了，赶紧去做！

祝你好运！

第十一章：一些有用的信息

尽管本书提供了一些（希望）有用的信息，但毕竟篇幅有限。因此，我编制了一个额外信息来源的列表，以补充本书内容。我还列出了许多领域专家，他们可能能在你前行的过程中提供进一步的帮助和指导。额外的资源可以在我的网站上找到：www.swartout.co.uk。

接下来列出的并非详尽无遗，但它是一个不错的开始。

工具

以下一些工具在本书中提到过，一些被认为是 CD 和 DevOps 领域的最佳工具：

工具	描述	更多信息在哪里可以找到
Jenkins		jenkins.io/
GIT	一个免费的开源分布式版本控制系统	git-scm.com/
GitHub	一个基于 GIT 的在线托管社区解决方案	github.com/
Graphite	一个高度可扩展的实时图表系统，允许你从应用程序内部发布度量数据	graphiteapp.org/
Tasseo	一个易于使用的 Graphite 仪表盘	github.com/obfuscurity/tasseo
SonarQube	一个开源平台，用于管理代码质量	www.sonarqube.org/
Ganglia	一个可扩展的分布式监控系统，用于高性能计算系统	ganglia.sourceforge.net/
Nagios	一个强大的监控系统，使组织能够在 IT 基础设施问题影响关键业务流程之前识别并解决这些问题	www.nagios.org/
Puppet Labs	一个自动化创建和维护 IT 基础设施的工具	puppet.com/
Chef	另一个自动化创建和维护 IT 基础设施的工具	www.chef.io/chef/
Vagrant	一个使用自动化构建完整开发环境的工具	www.vagrantup.com/
Docker	一个开源平台，用于分布式应用程序	www.docker.com/
Kubernetes (kubernetes.io/docs/concepts/overview/what-is-kubernetes/)	一个开源系统，用于自动化部署、扩展和管理容器化应用程序	kubernetes.io/
Octopus deploy	一个非常好的工具，可以用作 CD 管道	octopus.com/
Yammer	一种企业私人社交网络（可以把它看作是公司的 Facebook）	www.yammer.com
Slack	一款成熟且广泛使用的协作工具和平台	slack.com/
IRC	协作和聊天工具的“祖父”	www.irc.org/
Hubot	一种可以在大多数聊天室系统中设置的自动化机器人	hubot.github.com/
Trello	一种在线 Scrum/Kanban 看板解决方案	trello.com/

人物

以下是一些积极参与敏捷、持续交付和 DevOps 社区的人员：

• 帕特里克·德布瓦（Patrick Debois）被许多 DevOps 社区成员视为 DevOps 的奠基人和 DevOpsDays 运动的创始人（devopsdays.org/）。这个由志同道合的人组成的小型聚会在 2009 年开始，已经发展成为全球性的聚会。

• 约翰·博查卡卢佩·威利斯（John Botchagalupe Willis）是 DevOps 社区的常驻和著名贡献者，他通过自己真诚的分享智慧方式，激励了许多人。

• 杰兹·汉布尔（Jez Humble）是《持续交付》一书的合著者，许多人在调查或实施持续交付时，将其作为权威参考资料。他还积极为 continuousdelivery.com/ 上的持续交付博客贡献内容。

• 约翰·奥尔斯帕（John Allspaw）是 www.etsy.com/ 的运营高级副总裁，他似乎非常理解 DevOps 的价值——尽管他是高级管理层中的一员。

• 加雷斯·拉什格罗夫（Gareth Rushgrove）是自称的网页极客，他似乎总能找到时间制作《DevOps 每周通讯》（http:// devopsweekly.com/），其中充满了有用且富有洞察力的信息。

• 吉恩·金（Gene Kim）是《凤凰计划》的合著者，Tripwire 的创始人及前 CTO。他对 IT 运维、安全性和合规性充满热情，并关注 IT 组织如何从优秀转变为卓越。

• 米切尔·哈希莫托（Mitchell Hashimoto）是自称的 DevOps 工具狂热分子，也是 Vagrant、Packer、Serf、Consul 和 Terraform 的创始人。

• 雷切尔·戴维斯（Rachel Davies）是国际公认的专家，专注于指导团队有效使用敏捷方法，并且在回顾技术和游戏方面拥有丰富的知识。

• 肯·施瓦布尔（Ken Schwaber）和迈克·科恩（Mike Cohn）是 Scrum 和敏捷的“教父”。

• 约翰·克拉普哈姆（John Clapham）是一个全能的好人，也是敏捷/DevOps 的传道者。

• 卡尔·斯科特兰（Karl Scotland）是著名的敏捷教练，专注于精益和敏捷技术。

• 基思·沃森（Keith Watson）在英国的 DevOps 社区中非常有名，我有幸与他紧密合作。

推荐阅读

以下书籍值得一读，即使你出于某种奇怪的原因不打算采用持续交付和/或 DevOps：

资源	描述	链接
敏捷教练	如何成为优秀敏捷教练的简介	pragprog.com/book/sdcoach/agile-coaching
敏捷回顾：让优秀团队更上一层楼	一本优秀的书籍，涵盖了运行有效回顾所需的大部分知识	pragprog.com/book/dlret/agile-retrospectives
持续交付：通过构建、测试和部署自动化实现可靠软件发布	CD 圣经	www.amazon.com/dp/0321601912?tag=contindelive-20
凤凰项目	以虚构形式独特呈现的 DevOps 采纳方法，值得一读	itrevolution.com/books/phoenix-project-devops-book/
使用 Scrum 进行敏捷产品管理	从产品经理的角度看 Scrum 和敏捷	www.amazon.com/exec/obidos/ASIN/0321605780/mountaingoats-20
企业与 Scrum	本书提供了关于采用敏捷方法和工作方式面临的挑战以及解决方法的额外见解	www.amazon.com/exec/obidos/ASIN/0735623376/mountaingoats-20
精益创业	实际经验和见解，如何转变您的业务、文化和工作方式	amzn.com/0307887898
从敏捷回顾中获取价值	提供了回顾的良好简介，并列出了一系列游戏/练习	leanpub.com/gettingvalueoutofagileretrospectives

回顾游戏

回顾通常是敏捷检视和适应的一部分。如果你了解或正在使用 Scrum 或其他敏捷方法，那么进行回顾不应该是什么新鲜事。如果你以前从未进行过回顾，那么你将有一些有趣的事情要学习。

回顾的目的是回顾一个特定的时间段、项目、发布或者简单的业务变更，并突出表现良好的地方、表现不佳的地方以及需要改进的地方。这个过程传统上可能有些枯燥，因此回顾往往基于游戏（有些人称之为练习，但我更喜欢称其为“游戏”），这鼓励协作、参与，并增添一些乐趣。

就像任何游戏一样，总会有一些需要遵守的规则。这里有一些示例规则：

• 每个会议都应该严格按时限进行

• 每个人都应该有发言的机会和能力积极贡献

• 每个人都应该能够表达自己的观点，但不应该损害他人的权益

• 会议的主持人负责并控制会议的进行

• 本次会议应当产生一些可以作为改进措施推进的具体和实际行动。

就像在第二章中提到的价值流图技术，理解你当前的痛点，你真正需要的工具只有笔、纸、白板（或只是墙面）、一些空间和便签。

我已经向你介绍了时间轴和价值流图。现在让我介绍一下我最喜欢的游戏之一——StoStaKee。

StoStaKee

这个缩写代表停止（stop）、开始（start）和保持（keep）。同样，这是一项以过去事件为重点的互动时间盒练习。这一次，你要求每个人填写便签，记录他们希望停止、开始或继续做的事情，并将其添加到三个栏目（停止、开始和保持）中的一个。然后，你让每个人投票——再次使用便签上的小圆点，标记他们最强烈的看法。同样，你应该鼓励大家进行大量开放且建设性的讨论，确保每个人都理解每个便签的意义。最终目标是确定一系列可以推进的行动。以下图示展示了一个典型的 StoStaKee 板：

一个典型的 StoStaKee 板

之前的示例仅仅是可用资源的一部分，但它们已经一再证明，在调查和，更重要的是，理解一个失败的流程中的问题时，最为有效。

扩展的关键度量

第七章，关键度量，向你介绍了测量你流程中某些方面的多种方法。现在我们将扩展一些这些方法，并更详细地探讨你可以/应该测量的内容。我们将从重新审视代码复杂性及其背后的科学开始。

代码复杂性——一些科学原理

如第七章中提到的，关键度量，在某些情况下，复杂的代码是可以接受的，甚至是必要的；然而，过于复杂的代码可能会给你带来很多问题，特别是在调试时或在你尝试扩展代码以适应更多使用案例时。因此，能够分析一段代码的复杂性应该是有帮助的。

有几种已被记录并认可的源代码复杂性度量方法，但最常被提及的是由 Thomas McCabe 在 1970 年代提出的圈复杂度度量（有时被称为 MCC 或 McCabe 圈复杂度）。这个度量背后有一些现实世界的科学原理，使用正确的工具时，可以基于你的源代码提供量化的度量值。MCC 公式的计算方法如下：

M = E - N + X

在前面的公式中，M是 MCC 度量，E是边数（决策执行后的代码），N是节点数或决策点数（条件语句），X是方法图中的退出数（返回语句）。

代码与注释

在源代码中包含注释会使其更加易读，尤其是在未来，当原作者以外的人需要重构或修复代码时。一些工具可以帮助你衡量和分析代码与注释的比例。

话虽如此，一些软件工程师认为注释没有价值，并认为如果另一个工程师无法读懂代码，那么这个工程师就不称职。这是一种观点；然而，作为一种良好的工程实践和礼貌，应该鼓励在代码中加入注释。

如果你实现了代码与注释的分析功能，那么需要注意的是，一些人可能通过简单地添加以下代码片段等方式规避规则：

/**
* This is a comment because I've been told to include comments in my
* code
* Some sort of code analysis has been implemented and I need to
* include comments to ensure that my code is not highlighted as poor
* quality.
*
* I'm not too sure what the percentage of comments vs code is
* required but if I include lots of this kind of thing the tool will
* ignore my code and I can get on with my day job
*
* In fact this is pretty much a waste of time as whoever is reading
* this should be looking at the code rather than reading comments.
* If you don't understand the code then maybe you shouldn't be trying
* to change it?!?
*/

这可能有些极端，但我相信如果你仔细查看你的代码库，你可能会发现类似的东西隐藏其中。

根据我的经验，另一个添加注释的好理由是，当你需要处理一些非常老旧的代码时（按今天的标准，可能只是几年前的代码），例如调查可能的 bug 或仅仅想了解代码的功能。如果代码是基于过时的设计模式，甚至是基于旧的语言标准（例如旧版本的 Java 或 C#），那么在没有注释的情况下，理解代码的功能可能会非常耗时。

将监控嵌入到软件中

如第七章《关键度量》中所述，重要度量，有几种方法可以在软件本身中嵌入和生成度量。

假设你的软件组件包含用于组件间通信的 API。如果你能扩展这些 API，加入某种健康检查功能，你就可以构建一个工具，简单地调用每个组件并询问它的状态。然后，组件可以返回各种数据，表明其健康状况。虽然这看起来有些复杂，但实际上并不难。

下图概述了这种实现的可能方式：

一个健康检查解决方案，用于从软件组件收集健康状态数据

在这个示例中，我们有一个健康检查工具，它通过 API 调用每个组件并获取数据，这些数据随后可以存储、报告或显示在仪表板上。返回的数据可以根据需要简单或复杂。你所要做的，就是判断每个组件是否正常运行。假设，例如，返回的数据中有一个元素指示软件组件是否能连接到数据库。如果这个值返回为 false，并且你注意到查看数据库服务器上剩余磁盘空间的系统监控显示几乎为零，你就能非常快速地确定问题所在并加以解决。

这种监控方法很好，但依赖于你事先设置一些工具来逐个调用每个组件，收集数据，并以某种可读/可用的形式展示给你。它也受限于 API 的返回结果，或者更准确地说，受限于它们的设计和实现。例如，如果你想扩展数据收集内容，加入像数据库连接数这样的指标，你需要修改 API，重新部署所有组件，然后更新工具来接受这一新的数据元素。这并不是什么大问题，但毕竟是一个问题。然而，真正可能成为大问题的是单点故障——就是工具本身。如果它因为某些原因停止工作，你就会再次陷入盲区，因为你没有数据可查看，更重要的是，你也无法收集数据。

有一种替代方法可以克服这些问题。在这种方法中，组件本身生成你需要的指标，并将数据推送到你的工具中。像 Graphite 这样的工具就能很好地做到这一点。与其扩展 API，你只需实现少量代码；这使得你可以在软件组件内部填充指标数据的“桶”，并将这些桶推送到 Graphite 平台。一旦数据进入 Graphite，你就可以查询数据并生成一些非常有趣的实时图表。Graphite 的另一个优点是，现在有大量工具可以基于 Graphite 数据生成和创建非常有效的图表、图形和仪表板。