Salesfoce-DevOps-指南-全-

Salesfoce DevOps 指南（全）

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

译者：飞龙

协议：CC BY-NC-SA 4.0

前言

DevOps 和规模化敏捷框架®（SAFe®）都致力于将敏捷性扩展到团队之外。

DevOps 旨在将敏捷性从开发的“传统”边界扩展到包括开发到生产环境的部署和发布。这包括如果新开发的变更在生产环境中引发故障时应该怎么做，这些活动通常由运营团队执行。

SAFe®力图将敏捷思维扩展到需要多个团队开发和维护的产品。在这一框架下，协调一致性以及正确执行交付和发布的能力是成功的关键因素。DevOps 正是通过鼓励这两个因素来推动成功。因此，要实现 SAFe，必须确保 DevOps 也得到实施。

本书探讨了在 SAFe 框架下使用的 DevOps 方法。尽管有一些是特定于 SAFe 的实践，但我们为 DevOps 介绍的许多概念、实践和理论具有普遍适用性，并不限于 SAFe。

我们希望你享受这段学习旅程！

本书的读者对象

本书面向的 IT 专业人士包括 DevOps 和 DevSecOps 实践者、SRE 以及有意通过 SAFe 方法实施 DevOps 实践的管理者。了解 DevOps 和敏捷软件开发生命周期（SDLC）及其方法论的基础知识，将有助于你使用本书。

本书内容概述

第一章，介绍 SAFe®和 DevOps，简要回顾了 DevOps 和 SAFe 的发展历史。我们查看了推动敏捷开发的条件，敏捷开发到 DevOps 运动的演变，以及 SAFe 在推动 DevOps 实施中的作用。

第二章，共享责任文化，介绍了目前组织中存在的有益于 DevOps 的各种文化类型。我们还探讨了如何将组织文化转变为 DevOps 所需的文化。

第三章，为了效率和质量的自动化，探讨了组织为建立持续集成/持续部署（CI/CD）管道而使用的自动化和技术。我们还考察了用于监控和衡量预生产和生产环境的工具。最后，我们讨论了负责设置这些的团队。

第四章，利用精益流保持工作进展，描述了在 SAFe 框架下实现精益流的原则和方法。我们探讨了工作规模、积压工作长度、工作人员的繁忙程度以及工作项之间的差异，在完成工作所需时间中的作用。

第五章，衡量过程与解决方案，研究了确保产品开发过程中价值、安全性和可靠性所需的潜在测量指标。我们考察了帮助识别团队开发中是否有流动的测量指标。我们还探讨了监控和可观察性，以寻找确保解决方案安全可靠的度量指标。最后，我们着眼于收集评估产品最终用户价值的度量指标。

第六章，从生产故障中恢复，概述了一些方法，确保产品在面向客户的环境中可靠。我们探讨了著名生产故障的案例。我们还探索了站点可靠性工程（SRE）这一由 Google 开发的学科，旨在建立实践并确保可靠的环境。最后，我们通过考察混沌工程，结束了对这一主题的探索，混沌工程力求通过在生产环境中设立故障实验来为生产故障做好准备。

第七章，映射你的价值流，探讨了如何通过价值流识别工作坊来识别和建立价值流。我们将探索如何为工作坊做准备以及转向价值流所需的思维方式。接着，我们将探讨识别和绘制运营价值流所需的步骤。最后，我们将识别并绘制开发价值流。

第八章，衡量价值流绩效，深入探讨了用于提升价值流的度量指标。我们探索了由 DevOps 研究与评估组织（DORA）组织的度量指标。我们还探讨了 Flow Metrics，这是 Tasktop 创建的 Flow 框架的一部分。

第九章，通过持续学习迈向未来，考察了如何成为一个持续学习的组织。我们探讨了持续学习所需的学科，以及精益思想中的一些实践，如改进 Kata，它们鼓励持续学习。

第十章，持续探索与发现新特性，详细阐述了持续交付流水线的第一阶段——持续探索。我们探索了将史诗作为潜在客户价值假设的使用方式。我们通过确保架构能够支持这些新想法并保持产品的安全性和可靠性，来阐述这些假设。接着，我们将讨论如何将史诗拆解为特性，准备好供敏捷发布列车进行开发。

第十一章，解决方案开发的持续集成，讨论了持续交付流水线的第二阶段——持续集成，包括自动化过程的启动。我们探讨了测试的重要性，包括采用测试驱动开发和行为驱动开发。我们还讨论了在 CI/CD 流水线中引入自动化。

第十二章，持续部署到生产环境，提供了持续使用自动化和实践的深入分析，这是持续交付流水线的第三阶段——持续部署。我们继续探讨自动化如何通过 CI/CD 流水线将持续集成中创建的包部署到生产环境。同时，我们还探讨了如何在生产环境中继续进行测试。

第十三章，按需发布以实现价值，涵盖了持续交付流水线的最后阶段，在这一阶段，客户通过按需发布获取新功能。我们探讨了团队如何持续监控系统，以确保产品可靠且安全。接着，我们审视发布的内容是否真正满足了客户的需求。

第十四章，避免陷阱并深入未来，阐述了 DevOps 在流程和技术方面的新趋势，以及一些提示和技巧，帮助你开始这段旅程。我们从帮助你开启 DevOps 或 SAFe 之旅开始。

如何最大限度地利用本书

对于本书，了解 SDLC 的基础知识是有益的，但不要求掌握 SAFe 或 DevOps 知识。

下载彩色图片

我们还提供了一份 PDF 文件，包含了本书中使用的截图和图表的彩色图片。你可以在这里下载：packt.link/79pAN。

使用的约定

本书中使用了一些文本约定。

文本中的代码：表示文本中的代码词、数据库表名、文件夹名、文件名、文件扩展名、路径名、虚拟网址、用户输入和 Twitter 用户名。例如：“将下载的 WebStorm-10*.dmg 磁盘映像文件挂载为系统中的另一个磁盘。”

粗体：表示新术语、重要词汇或屏幕上看到的词。例如，菜单或对话框中的词汇通常以粗体显示。例如：“从管理面板中选择系统信息。”

提示或重要说明

以这种方式出现。

联系我们

我们始终欢迎读者的反馈。

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

勘误：尽管我们已经尽最大努力确保内容的准确性，但错误仍然可能发生。如果您在本书中发现错误，我们将非常感激您向我们报告。请访问 www.packtpub.com/support/errata 并填写表单。

盗版：如果您在互联网上遇到任何非法复制的我们作品，无论是以何种形式，我们都非常感激您能提供相关的网址或网站名称。请通过 copyright@packt.com 与我们联系，并附上链接。

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

分享您的想法

阅读完 SAFe® for DevOps Practitioners 后，我们非常希望听到您的想法！请点击这里直接访问该书的亚马逊评价页面并分享您的反馈。

您的评论对我们和技术社区非常重要，它将帮助我们确保提供高质量的内容。

下载本书的免费 PDF 版本

感谢您购买本书！

您喜欢随时随地阅读，却无法随身携带印刷版书籍吗？您的电子书购买无法与您选用的设备兼容吗？

别担心，现在每本 Packt 书籍都附带 DRM-free 的 PDF 版本，您无需额外支付费用。

在任何地方、任何设备上阅读。直接从您最喜欢的技术书籍中搜索、复制和粘贴代码到您的应用程序中。

福利不仅仅于此，您还可以获得独家折扣、新闻通讯以及每天送到您邮箱的精彩免费内容

按照以下简单步骤获取福利：

1. 扫描二维码或访问下面的链接

packt.link/free-ebook/9781803231426

1. 提交您的购买凭证

2. 就是这样！我们将直接把您的免费 PDF 和其他福利发送到您的电子邮件

第一章：引入 SAFe® 和 DevOps

许多组织，特别是那些从事基于软件的系统或涉及硬件和软件的复杂系统开发的组织，以及通过网络技术进一步增强的网络物理系统，过去 10 到 20 年中的产品开发方式发生了变化。诸如技术变革、向地理分布或远程开发的转变、推动更快的上市时间（TTM）、理解客户需求、以及减少生产失败的发生频率和严重性的压力，都是这些组织面临的机会、挑战，或者两者的混合。

为了解决这些挑战并利用机会，源自精益制造的思维方式开始出现并逐步发展。这些思维方式与新兴框架中的实践结合起来，开始帮助组织克服挑战并改善业务成果。

在本章中，我们将重点介绍历史上的挑战、流行的思维方式和方法，正是这些让许多组织克服了这些障碍。这些挑战、方法和框架在以下主题中有所描述：

• 组织在产品开发中面临的挑战

• 《敏捷概述》

• DevOps 简介

• 使用 SAFe® 扩展 DevOps

组织在产品开发中面临的挑战

当今的产品开发得益于技术与社会的结合。每个产品都是硬件和软件的组合，并通过与互联网的连接进一步增强。新的产品改进只需一次软件发布即可实现。我们真正生活在软件时代和数字时代。

正是在这样的背景下，我们审视产品开发中的挑战，发现这些挑战不仅没有改变，而且由于对技术和软件的依赖，这些挑战变得更加严峻。以下是一些经典挑战：

• TTM 压力

• 理解客户需求

• 安全性与合规性

• 确保质量

• 竞争

这些挑战并非孤立存在。有时会同时出现几个挑战，或者它们可能一并出现。让我们来看看这些挑战是如何单独或共同作用，妨碍产品开发的。

TTM 压力

TTM 是衡量从最初的构想到新产品或新产品特性发布所需时间长度的标准。它通常被视为衡量公司创新能力的指标。

一个日益增长的趋势是，近年来 TTM 的时间长度已经缩短。技术的进步加速了创新的步伐。这一创新步伐的加快迫使产品开发周期从年度周期缩短到 6 个月或季度周期。这个趋势将继续下去，并迫使组织考虑是否能够更频繁地交付新特性。

理解客户需求

亨利·福特曾说过：“如果我问人们他们想要什么，他们会说更快的马。”今天，这句话似乎依然适用。通常在开始时，客户并不知道他们想要产品的哪些功能。如果一个产品需要长时间的开发周期，客户的偏好可能会发生变化，通常变化到最终交付的产品并不是客户所需要或想要的。

通常，促使客户需求或要求发生变化的原因可能是竞争对手的类似产品提供的功能。来自竞争对手的压力提供了一个挑战：理解客户的需求，并在竞争对手之前发布能够满足这些需求的产品或功能。

安全与合规

组织面临的一个挑战并非来自市场。使用软件的产品面临着来自黑客和其他恶意行为者的日益增长的威胁，他们试图利用软件中的漏洞。如果他们能够利用这些漏洞，造成的损害可能从声誉受损到金钱损失，如勒索软件支付或诉讼费用。

此外，因应这些恶意行为者的威胁，已经颁布了旨在确保隐私和安全的法规。产品可能需要遵守地区性（例如通用数据保护条例（GDPR））或行业性（例如健康保险可携带性和责任法案（HIPAA））的监管标准，以确保客户的机密数据不被泄露。

确保质量

对于组织而言，保持质量在产品开发过程中至关重要。没有在确保产品具有内建质量方面严格执行的组织，很快会发现自己面临其他挑战。返工意味着更长的交付周期和产品上市的延迟。客户体验到有缺陷的软件或低质量的产品时，可能会转向竞争对手的产品。不充分关注质量还可能导致安全漏洞未被察觉，从而允许恶意攻击发生。

在产品开发过程中，保持质量的警觉性理想的做法是创建、设置并执行各级别的测试，贯穿整个开发过程。测试甚至可以在预生产和生产环境中进行，并尽可能地自动化。基于审批/检查的方法仅仅是将问题的发现推迟，直到可能太晚或者修复成本过高。

竞争

之前提到的一些挑战讨论了竞争所扮演的角色。事实是，你的竞争对手也面临着与你一样的挑战。如果你的竞争对手已经找到了应对这些挑战的方法，他们在市场上将具有明显的优势。

但需要记住的是，这场竞争并不是关于谁先到达终点。挑战在于能够率先推出产品或功能，并能够清晰传达其与客户需求的契合度。一个著名的例子来自苹果。苹果在发布 iPod 时，比其他竞争对手在数字音乐播放器市场上晚了几年。然而，正是这种营销方式让 iPod 成为一款现象级产品。苹果宣传其内存容量时，不以兆字节(MB)为单位，而是以可容纳的歌曲数量为单位。这一简单的信息深深打动了市场，不仅是技术爱好者和音乐发烧友，甚至是普通的音乐听众也能产生共鸣。

iPod 的极度成功推动了苹果走上了一条创新之路，使其迅速跃升为全球科技巨头之一。首个商业MPEG-1 音频层 3(MP3)播放器的制造商，如今已不再提供对其产品的支持。

面对挑战

这些挑战自人类历史早期就一直困扰着产品开发。然而，挑战的具体形式随着每一代人和每一次技术变革而变化。

TTM 周期将始终决定何时发布产品；然而，借助技术的帮助，这些周期正在缩短。客户的需求可能始终保持神秘，往往连客户自己都无法完全理解。竞争格局会随新型颠覆者的出现和落后者的消失而不断波动。

随着这些无处不在的挑战呈现出新的形式，那些已经掌握这些挑战的组织通过围绕三大领域的新思维和实践来应对：人员、流程和技术。

关注人员涉及考察人们共同持有的思维方式、价值观和原则，从而形成一种组织文化。这种文化是应对挑战的最重要对策，因为它为每个人提供了如何应对这些挑战的指引。

在确立文化之后，关注流程就实施了基于正确思维方式、价值观和原则的实践。成功应用这些实践能够促进反馈循环，进一步推动文化建设，并加强思维方式、价值观和原则。

最后，工具帮助了流程的实施。它们使得实践可重复且自动化，强化了流程的执行力，从而使得流程的应用能够取得成功。

本书的其余部分将重点介绍帮助组织应对现代产品开发中所面临挑战的人员、流程和工具的结合。这些结合构建成灵活的框架，旨在能够适应不同行业、不同组织的应用。这些结合最初源自软件开发，但鉴于软件的创造在当今每个组织中都广泛存在，因此值得关注。

我们从敏捷开发的探讨开始，或者说从大规模软件交付到短周期设计的增量交付的过渡。

敏捷简介

要理解这些挑战所处的背景，重要的是理解主流的产品开发过程，通常被称为瀑布模型。瀑布模型曾被用于许多年的大教堂和火箭飞船的开发，但当这一过程用于软件开发时，逐渐显露出其局限性，特别是在应对缩短的产品上市时间（TTM）和满足客户需求方面。必须采取一些措施。

接下来，让我们看看敏捷方法的兴起，从最初尝试将精益思维融入软件开发，到敏捷宣言的创建以及敏捷实践和框架的出现。

瀑布模型的兴起与衰退

被称为瀑布模型的方法源于传统的产品开发。工作人员将工作划分为特定的阶段，直到当前阶段完成才会进入下一阶段。

1970 年，温斯顿·W·罗伊斯（Winston W. Royce）首次提出了这一方法的图表和模型，当时产品开发已转向软件，如图所示：

图 1.1 – 瀑布模型图

尽管罗伊斯从未倡导这种方法，实际上他更倾向于采用增量开发的方法，但他的图表流行开来，行业内许多人称这种方法为瀑布模型，因为从一个阶段到另一个阶段的箭头形态像瀑布。

在软件开发中，这种方法开始显示出弊端。如果在后期阶段出现需求、问题或限制，额外的工作会将流程推回，导致大量返工。许多时候，最终客户在初期并不会有明确的需求，这就导致了返工或最终产品未能满足客户期望。

返工引入的延迟也对固定时间项目造成了压力。为了赶上截止日期，某些后期阶段（通常是测试）会被缩短或取消，以便交付产品。由于缺乏测试，错误或bug在产品发布前未被发现，从而导致低质量的软件和低客户价值。

产品开发周期中的 TTM 压力减少了开发新软件或更新现有软件的时间。这个模型开始崩溃，但还能做些什么不同的尝试呢？

敏捷方法的兴起

在 21 世纪初，其他方法如极限编程（XP）、Scrum 和 Crystal 开始涌现。这些方法倡导增量交付，即一小部分预期功能在小的设计周期中经过所有阶段（需求、设计、编码和测试），通常不超过一个月。在每个设计周期结束时，团队会征求客户反馈，并通常将这些反馈融入下一个设计周期。

以下图示展示了增量交付的表示，包含短周期的设计和有价值的包的交付：

图 1.2 – 增量式（敏捷）开发图

2001 年 2 月 11 日至 13 日，一群软件开发专家，其中一些人创建了agilemanifesto.org。

敏捷宣言包含一套价值观和一系列原则，但需要注意的是，宣言的作者们谈论这些价值时，将其视为一组偏好。敏捷团队可以有流程、工具、文档、合同和计划。只有当这些内容妨碍了每个价值声明左侧的项目时，团队才应重新评估流程、工具、合同和计划，并进行调整。

价值观设定展示了什么是重要的，说明如下：

通过实践和帮助他人实践，我们发现了更好的软件开发方式。通过这项工作，我们开始 重视：

• 个人和互动优于 流程和工具

• 工作的软件优于 详尽的文档

• 客户协作优于 合同谈判

• 响应变化优于 遵循计划

也就是说，尽管右边的内容也有价值，但我们更看重左边的内容。

敏捷宣言的 12 条原则详细阐述并提供了这些价值的背景，说明如下：

1. 我们的最高优先级是通过早期和持续交付有价值的软件来满足客户。

2. 欢迎变更需求，即使在开发后期。敏捷流程利用变化为客户创造竞争优势。

3. 经常交付工作的软件，从几周到几个月，优先考虑较短的时间尺度。

4. 商业人员和开发人员必须在整个项目过程中每天都共同工作。

5. 围绕有动力的个体构建项目。为他们提供所需的环境和支持，并信任他们完成工作。

6. 传递信息给开发团队及团队内信息传递的最有效方法是面对面的交流。

7. 工作的软件是进展的主要衡量标准。

8. 敏捷流程促进可持续发展。赞助人、开发人员和用户应该能够维持一个持续的节奏，无限期地进行下去。

9. 持续关注技术卓越和良好设计能够增强敏捷性。

10. 简单性——最大化未完成工作的艺术——至关重要。

11. 最好的架构、需求和设计源自自组织的团队。

12. 团队定期反思如何变得更加高效，然后调整和优化行为。

精益的加入

大约在同一时期，其他人也在寻找以更短的时间到市场（TTM）来开发软件的方法。他们开始研究如何将精益生产的原则应用到软件开发中。

精益生产旨在应用实践以减少浪费。这些方法由大野耐一（Taiichi Ohno）发明，用于创建丰田生产系统（TPS）。除了消除浪费，精益生产还力图构建质量并追求改善（Kaizen），即持续改进。

精益生产原则的应用被玛丽和汤姆·波本迪克（Mary and Tom Poppendieck）用于在他们的书籍《精益软件开发：敏捷工具包》中描述精益软件开发。这些原则总结如下：

• 消除浪费

• 强调反馈和学习

• 等到最后一刻再做决定

• 经常交付

• 确保团队有权决策

• 满足用户的感知和期望

• 运用系统思维

除了波本迪克夫妇的工作外，大卫·J·安德森（David J. Anderson）在微软改编了看板（Kanban），这是丰田生产系统中的另一个工具，专门用于软件开发。看板的这一改编被调整为适用于软件开发的实践框架。看板很快在开发中流行起来，不仅作为 Scrum 或 XP 的替代方案——许多实践都与 Scrum 或 XP 结合使用，以促进任务的执行。

软件开发团队确实发现，转向敏捷开发正在产生结果并克服产品开发中的挑战，但这些结果仅在开发中看到，而不是整个组织层面。显然，其他部门也需要进行变革。让我们来看看开发和运维如何在 DevOps 运动中共同进行改变。

DevOps 的介绍

随着开发团队开始采用敏捷方法并增量交付软件功能，他们面临着从外部交付价值的挑战。运维团队，即维护开发和生产平台（代码执行的地方）的团队，通常不会在新包出现时立即从开发团队发布它们。相反，运维团队坚持收集功能并在指定的发布窗口中部署它们，以最小化单个新变更可能导致生产环境崩溃的风险。但这种做法并没有最小化风险，反而通过压缩发布窗口的时间，导致开发与生产环境之间的配置不匹配，并且生产环境中存在无法追踪的手动干预，从而加剧了风险。将发布捆绑成发布包还将交付从小增量转向了较大的单体发布，这可能降低了客户价值。

在此时，必须从典型的运维团队的角度来看待问题。其工作是确保组织的生产环境——也就是可能产生收入的环境——尽可能地高效运行。任何对该环境的改动，甚至是为了新增功能的改动，都被视为对稳定性的风险。

2009 年，John Allspaw 和 Paul Hammond 在 O'Reilly Velocity 大会上做了一场题为 每天部署 10+ 次：Flickr 的开发与运维合作 的演讲。在这场演讲中，他们概述了实现前所未有的每天 10 次部署的方式。这些方法至今仍然是 开发-运维（DevOps）的基本支柱。我们将讨论以下内容的整合：

• 工具和技术

• 人员和流程

DevOps 工具和技术

在讲座中，Allspaw 和 Hammond 识别了各种技术，并介绍了他们如何利用这些技术来协调开发和运维团队。然而，值得注意的并不仅仅是这些工具——更重要的是团队们如何协作使用这些工具。

这些技术包括以下内容：

• 自动化基础设施

• 通用版本控制

• 一键构建/部署

• 功能标志

• 共享度量

• 即时通讯（IM）机器人在共享频道中

工具和技术的使用继续在 DevOps 中发挥着关键作用。我们将探讨这些工具如何使生产环境中的快速发布过程得以实现，并且在生产环境出现问题时能迅速解决。

自动化基础设施

随着软件变得更加复杂，执行这些软件的环境也变得更加复杂。运维团队面临的任务是配置不断增长的服务器，数量从几十台增加到几百台甚至几千台。这一任务需要自动化。配置管理（CM）工具，如 Chef 和 Puppet 开始出现。

配置管理使运维团队能够标准化环境配置，如操作系统版本、软件应用和代码库。它还帮助他们轻松找到那些没有标准配置的机器并进行修正。当服务器从物理硬件转移到 虚拟机（VMs）时，配置管理使得创建和维护按其在服务器环境中扮演的角色区分的标准镜像成为可能。

配置管理（CM）同样对开发者有帮助。自动化配置管理可以确保组织用于软件开发和发布的多个环境中的每台服务器配置一致。开发、测试和生产环境之间的一致性消除了一个问题，这个问题通常被称为“在我的机器上能运行”，即即便是开发、测试和生产环境之间的细微差别，也可能导致代码在开发环境中能运行，但在生产环境中失败。

通用版本控制

版本控制系统（VCS）如 Git 是软件开发中常用的工具，用于管理源代码。通过版本控制，开发者可以在一个称为分支的私有沙箱中修改源代码。当准备好共享源代码更改时，开发者可以将更改合并回源代码库的主分支，确保这些更改不会与其他开发者的更改产生冲突。VCS 会记录所有源代码的更改，包括来自其他分支的更改。因为版本控制包含了源代码演变的全面历史，所以可以根据特定时间点找到源代码的某个版本。

很快，版本控制不仅仅用于存储源代码，它也开始用于存储更多内容。测试工具需要版本控制的测试脚本和测试数据，随着测试的变化，版本控制也在其中。配置管理工具（CM 工具）使用文本文件来定义服务器和虚拟机的理想配置。运维还可以拥有执行自动配置任务的脚本。所有这些内容都可以通过版本控制来记录环境的演变。

确保开发和运维不仅使用版本控制，而且使用相同的版本控制工具变得十分重要。开发的所有工件（代码、测试、配置文件、脚本等）都要有版本，这样通过标签或标记可以轻松理解某个发布中使用的是哪个版本的哪个工件。使用统一的版本控制工具可以确保一方（开发或运维）在发生问题时不会被拒绝查看这一信息。

一键构建/部署

从源代码构建一个发布版本可能是一个耗时的任务。开发者需要从版本控制中拉取更改，添加必要的代码库，将更改编译成一个构建包，并将该构建包上传到环境中，以测试更改是否有效。一个聪明的开发者通常会通过设置构建脚本来自动化这些任务，但这个过程是否能变得更简单呢？

持续集成（CI）工具如 Hudson（后改名为 Jenkins）应运而生，它允许开发者通过按一个按钮完成构建过程的所有步骤并执行构建脚本。一个页面不仅可以显示构建是否成功，还能在构建失败时，显示失败发生在哪个步骤。通过 CI 自动化构建，也确保了开发者之间构建过程的一致性，保证所有步骤都被执行，并且没有遗漏任何步骤。

当运维团队部署发布时，是否可以应用相同的一致性？持续部署（CD）工具获取一个构建包并对其在当前级别环境中运行测试，如果测试通过，则将其应用于特定环境。这些工具还可以与CM工具连接，以在需要时创建带有新构建包的环境实例。任何新的部署都将被记录，显示谁按下按钮，何时按下按钮，以及部署到特定环境的哪些工件和工件变更。

用于 CI 的工具也能用于 CD 吗？这是实施可以由开发和运维双方使用的相同自动化的常见方式。

特性标志

Flickr，Allspaw 和 Hammond 所工作的公司，是一个照片分享和评分网站。其软件与传统的基于桌面的软件不同，因为它只关注支持其生产环境中的一个版本发布。公司不必担心支持发布软件的多个版本。这使得它将版本代码仓库的主分支作为它将支持并检查问题是否出现的特定版本。

为了处理由有缺陷的新功能引入的问题，它在代码中设置了称为特性标志的条件分支。根据变量的值，新功能的代码将可见或不可见。特性标志充当开关，指示发布的代码以及其可见性，如下图所示：

图 1.3 – 特性标志的插图

在代码中设置特性标志允许更灵活地部署到生产环境。新部署的代码可以存在于生产环境中，但在经过彻底测试之前不可见。这种情况可能导致“暗启动”，在此期间运维人员可以评估新功能在现有软件和生产数据负载下的性能。测试客户可以在启用这些特性标志的生产环境子集中评估新功能。最后，通过更改特性标志的值，通过 CI 和 CD 传播更改，并允许在生产中进行更改，可以快速改变环境的行为。这种恢复方法称为向前滚动或修复向前。

共享指标

为了确保稳定性，运维收集每个环境的性能，并审查这些数据收集产生的指标。这些指标可以显示为仪表板上的特定视图。仪表板视图不仅提供当前性能的指示，还允许运维识别趋势并采取纠正措施。

Flickr 不仅为运维人员制作了这些仪表板，还为开发人员提供了这些仪表板。开发人员可以在环境的上下文中看到应用程序的性能。让开发人员访问这些上下文数据，确保他们能够看到新功能的效果，以及这些功能是否提供了价值。

共享指标还允许在环境中发生适应性反馈回路。性能指标可以通过应用程序进行评估，评估结果可以生成通知，指示需要额外的资源。

在共享频道上的 IM 机器人

开发与运维之间的沟通至关重要。使用标准电子邮件被不鼓励，取而代之的是即时消息和聊天机制，这些机制允许开发与运维之间进行持续的实时通信。关于开发事件（如构建状态）和运维事件（例如，部署状态、系统警报和监控消息）的通知可以通过聊天机器人插入到频道中，提醒开发和运维人员发生的具体事件。聊天内容也可以被搜索，以便在出现问题时提供事件的时间线，帮助排查问题。

DevOps 人员和流程

值得注意的是，除了 Flickr 之外，其他组织也在使用相同的工具和技术。Flickr 的不同之处在于，来自不同小组的人们如何在共享流程中合作，利用这些工具和技术。这些人和流程形成了一种组织文化，使他们能够快速部署。

Allspaw 和 Hammond 在谈话中记录了具体的接触点。这些包括以下内容：

• 尊重

• 信任

• 从失败中学习

• 不“指责”

这些接触点的形成与组织文化一样重要，正如工具和技术的应用一样重要。

尊重

Flickr 内部不同小组的人们从尊重的角度运作至关重要。这种尊重意味着超越对开发人员或运维人员的刻板印象，关注共同的目标。

尊重他人的专业知识、观点和建议。基本的理解是，不同的人有着不同的背景和经验，这些背景和经验塑造了他们的观点和责任。解决问题的一个关键部分是倾听那些可能提供不同和更好的解决方案的不同观点。理解不同的责任可以帮助你理解另一个人的视角。

Allspaw 和 Hammond 强调的尊重的另一个重要延伸是，不仅仅是给出一个回答，而是要理解别人解决这些问题的原因和动机。仅仅回答一个问题是不够的——你还应该在回答之前理解这个问题被提出来的原因。让每个人都理解背景，可以帮助小组共同创造出独特的解决方案。

要表现出这种尊重，必须有透明度。小组之间隐藏信息会阻碍自由交换，从而无法创造出创新的解决方案。而且，最终无论你隐藏什么，都将被发现，从而引发冲突。

尊重的重要组成部分是同理心。在与运维人员讨论之前，了解代码变更对运维可能带来的影响是非常重要的。这为揭示任何潜在的假设并激发创造性解决方案提供了空间。

信任

拥有透明度和同理心来建立尊重后，一个小组的人需要信任其他小组。如果开发人员了解他们的功能对运维的影响，那么他们就有责任与运维人员进行沟通，确认这些影响，或者至少让他们意识到潜在的影响。

相反，运维人员需要让开发人员参与进来，共同讨论任何基础设施变更对当前或未来功能的影响。

最终，这意味着每个人都应该相信其他人都在尽最大努力为业务的利益而工作。

信任的体现不仅仅是通过版本控制、即时消息聊天机制、度量和仪表板共享数据，还体现在构建共享的运行手册和升级计划中，这些计划是在准备新版本时创建的。构建这些计划使得有关风险、影响和责任的讨论得以顺畅进行。

最后，包含允许另一组人员操作的机制，是利用信任的重要部分。对于开发人员来说，这意味着在软件中设置运维人员可以操作的控制功能。对于运维人员来说，这意味着允许适当的访问权限进入生产环境，以便开发人员能够直接看到新变更在生产环境中的影响。

从失败中学习

失败是不可避免的。一个组织如何应对失败，决定了它是一个成功的组织，还是一个很快无法继续运营的组织。成功的组织更加关注如何应对已知和未知的失败，而不是花力气去防止下一次失败的发生。

对失败的应对准备是每个人的责任。每个开发人员或运维团队成员必须知道在紧急情况下他们会如何反应。应急演练的方法包括让初级员工“跟随”高级员工，观察他们如何反应。在 Flickr，这些初级员工被置于与实际停机事件相同的“假设”场景中，看看他们能提出哪些解决方案。

无“指责”

在 Flickr，他们发现，当人们害怕因生产故障被指责时，第一反应往往是尝试单独修复问题、找出责任人或掩盖证据。这总是导致解决问题的延迟。因此，他们实施了无指责规则。

结果是显著的。解决问题的时间迅速减少。焦点从谁造成了问题转移到了什么是解决方案。

DevOps 运动的开始

对 Allspaw 和 Hammond 演讲的反应迅速且具有影响力。人们开始寻求更好地对齐开发和运维的方式。Patrick Debois 没有参加 O'Reilly Velocity 大会，那里 Allspaw 和 Hammond 发表了演讲，他在比利时根特组织了第一次 DevOpsDays 大会，继续推动这一对话。这一对话不断发展，并通过后续的 DevOpsDays 大会、在 Twitter 上以“#DevOps”标记的信息、博客和聚会，成为了一场运动。

这一响应推动了版本控制、变更管理、持续集成（CI）、持续交付（CD）、配置管理（CM）、自动化测试和工件管理等新工具的创造。技术从虚拟机（VM）发展到容器，旨在减少开发、测试、预生产和生产环境之间的差异。

DevOps 运动持续增长。与敏捷方法的采用类似，DevOps 是开放的、去中心化的。没有一种“做 DevOps”的方式。DevOps 可以应用于任何类型的环境，如遗留主机、物理硬件、云环境、容器和 Kubernetes 集群。DevOps 在任何行业中都能发挥作用，无论是金融、制造业还是航空航天。

自从 Allspaw 和 Hammond 的首次演讲以来，采纳 DevOps 原则和实践的组织在部署频率上取得了惊人的进展，同时还能够减少生产故障的概率，以及发生故障时的恢复时间。根据 2021 年的 DevOps 状态 报告，所谓的“精英”组织可以按需发布，这可能一天发生多次。这比那些被评为“低”的组织频繁 973 倍。精英组织发布故障的可能性也低了三分之一，且在发生故障时，恢复速度比其他组织快 6,570 倍。

一些组织是中型到大型的公司，所在行业包括金融、航空航天、制造业和保险等。他们所创建的产品可能是系统的系统的系统。他们可能不知道如何融入敏捷和 DevOps 方法。对于这些公司，可以考虑的一种框架是Scaled Agile Framework®（SAFe®）。

使用 SAFe®扩展 DevOps

SAFe®是根据最近的敏捷状态调查（每年进行）采用的较为流行的框架之一，用于融入敏捷思维模式和实践。如scaledagileframework.com所述，SAFe®的创建者和维护者 Scaled Agile Inc 表示，该框架是“一套经过验证的集成原理、实践和能力的知识库，用于通过精益、敏捷和 DevOps 实现业务敏捷性。”

组织可以选择在四种 SAFe®配置中运作。几乎所有组织都从一种称为Essential SAFe的基础配置开始。在 Essential SAFe 中，5 到 12 个团队——每个团队由一名 Scrum Master、产品负责人和 3 到 9 名额外成员组成——联合起来形成一个叫做敏捷发布列车（ART）的团队中的团队。ART 的工作是开发产品或解决方案。ART 的工作由以下三个特殊角色指导：

• 发布列车工程师（RTE）：这是 ART 的首席 Scrum Master。RTE 负责移除障碍、促进 ART 事件，并确保列车顺利运行。

• 产品管理（PM）：PM 负责通过创建和维护产品愿景来引导产品的演变，并引导创建优先级程序待办事项中的功能。

• 系统架构师（SA）：SA 通过创建称为“启用器”的架构工作来维护产品的架构。他们是 ART 中团队平衡团队的渐进设计与产品初期的有意架构之间的焦点。

以下图示展示了一个 ART 及其内部角色：

图 1.4 – 一个包含主要角色的 ART

就像故事一样，Scrum 团队的工作是有时间限制的，ART 的工作也是有时间限制的。功能应在程序增量（PI）内完成，PI 是一个持续 8 到 12 周的时间段。PI 是多个冲刺的组合，ART 中的团队通过将功能分解为故事并在 PI 中一个接一个地交付这些故事来进行工作。你可以在以下图示中看到这一点：

图 1.5 – 一个包含五次迭代（冲刺）的 10 周 PI

在 Essential SAFe 和 ART 的背景下，我们应用 DevOps。ARTs 着眼于采用 Allspaw 和 Hammond 在 2009 年演讲中提到的相同实践，以及自那时以来出现的新实践。本书将介绍 SAFe 中概述的 DevOps 方法，其中包括以下几个方面：

• 使用文化、自动化、精益流、度量和 恢复（CALMR）来建模 DevOps 方法

• 设置和维护价值流

• 将CD流水线应用于价值流

• 在流程中包括内建的质量和安全性

查看 CALMR

在 Allspaw 和 Hammond 的演讲之后，人们尝试组织所提到的实践，并创建一个模型来体现 DevOps 方法。在DevOpsDays 2010上，John Willis 和 Damon Edwards 提出了CAMS方法，其中每个字母代表 DevOps 的一个重要因素或支柱。这些字母及其代表的因素如下：

• (C)文化

• (A)自动化

• (M)度量

• (S)共享

后来，Jez Humble 在此基础上增加了一个L，代表精益流，以发展为CALMS方法。

在认识到所期望的文化中，共享是一个关键组成部分后，Scaled Agile 从其模型中移除了S，并用R替换，代表恢复。CALMR模型可以总结如下：

• 文化：在所有团队之间创建共同责任的文化（包括开发、运维、安全、业务等团队）。

• 自动化：在持续交付流水线中尽可能多地利用自动化。

• 精益流：使用小批量工作，视觉化所有工作，避免过多的进行中工作（WIP）。

• 度量：在所有环境中衡量你的流动、质量和性能，并评估是否达到了预期的价值。

• 恢复：创建低风险的发布版本。投入精力准备如何从失败中恢复。

第一部分：方法——通过 CALMR 观察 SAFe®和 DevOps将考察 CALMR 方法中的每个因素，了解团队和整个 ART 如何运用价值观、原则和实践来实现这些因素。

绘制你的价值流图

价值流是精益制造中的一个概念，它关注从产品的初始构想到交付的整体过程。在价值流中，你评估整个过程所需的步骤，以及每个步骤中涉及的人员和资源。每个过程步骤都有其前置时间（步骤开始前的等待时间）和周期时间（每个步骤的时间消耗）。

组织价值流的第一步是识别价值流的当前状态。每个步骤——以及相关的人员、资源、前置时间和周期时间——都需要被确定，以便识别和绘制整个价值流图。完成此识别后，会提出一系列问题，探讨可以采用的解决方案，以减少在价值流步骤中的时间。

在初步识别后，下一步是识别并放大每个步骤可能需要的反馈循环。度量在这里起着重要作用，可以帮助判断由 ART 实现的价值流是否在执行其过程，正在开发的解决方案在任何环境下是否存在问题，以及解决方案是否交付了承诺的价值。

在这个阶段，采取价值流识别和映射的第一步，以及为每个步骤寻找反馈的第二步，最终得出了第三步——价值流管理。在初步的价值流映射过程中，可能会识别出一个潜在的“未来状态”或优化后的价值流。由 ART 来进行增量式变更以实现这个最优的价值流。只有通过持续学习的态度，并不断朝着持续改进的方向努力，他们才能做到这一点。

第二部分：实施 – 向价值流迈进 详细介绍了三种价值流管理方法，这些方法借鉴了《凤凰项目》中的三种方法。我们将探讨识别价值流并绘制初步和潜在未来价值流的步骤。我们还将看到度量如何为价值流中的每个步骤形成反馈循环。最后，我们将评估来自精益思维的工具和技术，以便在持续改进的背景下改进价值流。

通过持续交付管道运行你的价值流

持续交付管道是 ART 实现价值流的方式。它将人及其职能与从初步构想到发布的产品交付过程相结合，并包括用于自动化任务的工具，通常以 CI/CD 管道的形式存在。在 SAFe 中，持续交付管道被分为四个方面。每个方面由 ART 成员在每个 PI 中并行执行，如下图所示：

图 1.6 – 持续交付管道

第一阶段是持续探索（CE）。在这个阶段，PM 与客户、利益相关者、UX、SA 以及合规性和安全等其他小组合作，基于对客户带来真实价值的假设来确定即将推出的功能。这些功能将被检查以确定可行性，以及是否需要对架构进行任何更改，以满足非功能性需求（NFRs），如安全性、可靠性、性能和合规性。在定义和完善后，该功能将被放入项目待办列表，并优先考虑纳入即将到来的 PI 中。

在执行 PI 的过程中，开发团队将纳入持续交付流水线的第二阶段：CI。一旦代码更改进入版本控制，CI/CD 流水线就会启动。流水线可能会进行多层测试，包括代码质量检查（linting）和功能单元测试。如果测试通过，代码更改可能会合并到更高层级的分支，并创建一个软件包。该软件包可能会经过额外的测试，以验证系统行为是否正确。通过测试后，包含更改的包可能会被部署——如果可能的话，自动部署——到一个类似生产环境的暂存环境中。

根据组织的不同，第三阶段 CD 可能会实现自动化并接管。CI 阶段创建的软件包可能会在生产环境中自动部署。功能标志可能会防止更改被发布，直到继续进行测试以确保这些更改与现有功能以及生产环境兼容。在生产环境中，持续监控会持续进行，以验证系统是否正常运行，并在出现问题时进行响应。

最后，在第四阶段，按需发布，新功能会被启用，允许客户利用这些更改。生产环境会继续监控是否有不良影响，ART 也会继续响应任何发生的部署失败。这里的衡量标准包括评估前瞻性指标，以评估新功能所带来的实际价值，并验证最初的假设是否成立。最后，ART 会反思并应用学到的经验教训，以改进持续交付流水线和价值流。

我们将在第三部分：优化——启用持续交付流水线中，深入探讨持续交付流水线的所有四个阶段。我们将研究与 CE 相关的人员和流程。我们将调查构成 CI 和 CD 的工具与技术。最后，我们将了解如何通过按需发布来闭环 ART，为客户提供价值。

在过程中包括安全性

人们越来越意识到，与组织中其他团队的合作和参与可以提高产品质量并加速产品开发。与开发和运维团队合作的一个团队就是安全团队。

DevSecOps 是 DevOps 领域中日益增长的趋势，信息安全实践在整个持续交付过程中得到融合。在 SAFe 中，我们包括了 DevSecOps 提倡的信息安全实践，以确保安全性不会成为事后的考虑。

在第 1 到第三部分中，你将看到安全在其中的积极参与，以及持续测试的执行，以确保解决方案符合开发结束时必须经过的任何批准。这些安全解决方案早已融入到产品设计、开发和部署中。

总结

在本章中，我们探讨了许多组织在今天开发产品时所面临的问题。我们看到了现代快速市场推出（TTM）、不断变化的需求和未知的客户需求、以及生产部署中的问题如何使开发和运维团队疲惫不堪。我们还讨论了开发和运维团队所提出的应对策略。

开发开始着眼于将敏捷思维融入其中，以实现快速、频繁发布小幅增量的价值，并通过客户反馈驱动下一个开发增量。这一思路要求审视价值和原则，改变思维方式，同时引入制造业中的精益思想。

随着开发开始收获敏捷思维转变的好处，并融入敏捷实践，发布新产品和新功能的瓶颈转向了运维——即那些维护现有生产环境的人。DevOps 运动作为一种新的协作方式，旨在通过工具和技术的应用、以及建立基于尊重、信任、同理心和透明度的文化，打破开发与运维之间的困惑壁垒。

一种将 DevOps 原则和实践融入开发的方式是 SAFe。使用 SAFe 的 DevOps 适用于团队中的团队或 ART。ART 通过采纳 CALMR 模型来拥抱 DevOps。团队识别其工作方式，并将其映射为价值流。最后，它使用持续交付流水线将工作交付到生产环境，衡量其价值，并改进价值流。

在下一章中，我们将开始审视 CALMR 方法，首先探讨最关键的因素：文化。

问题

通过回答这些问题来测试你对本章概念的理解。

1. CALMR 中的 M 代表什么？

   1. 监控

   2. 多任务处理

   3. 衡量

   4. 使命

2. 在持续交付流水线中，哪些是阶段？（选择两个）

   1. 持续改进

   2. 准时发布

   3. 持续探索

   4. 按需发布

   5. 持续交付

3. 在 CALMR 中，哪种文化很重要？

   1. 独立

   2. 共享责任

   3. 官僚主义

   4. 开放

4. 运维的传统关注点是什么？

   1. 收入

   2. 稳定性

   3. 速度

   4. 合规性

5. 哪个术语描述了将信息安全实践融入持续交付（CD）？

   1. 安全运维

   2. 开发安全

   3. DevSecOps

   4. 安全操作

深入阅读

欲了解更多信息，请参阅以下资源：

• leadinganswers.typepad.com/leading_answers/files/original_waterfall_paper_winston_royce.pdf—温斯顿·W·罗伊斯所写的原始论文，展示了后来被称为瀑布方法的流程图。需要注意的是，论文中他提倡采用替代路径，以便进行额外的测试和客户反馈。

• agilemanifesto.org—《敏捷软件开发宣言》，或简称为敏捷宣言。

• 《精益软件开发：敏捷工具包》 由玛丽·波彭迪克和汤姆·波彭迪克著。

• 《看板：为你的技术业务成功演变》 由大卫·J·安德森著。

• www.youtube.com/watch?v=LdOe18KhtT4—这是约翰·奥尔斯波和保罗·哈蒙德在 2009 年O'Reilly Velocity大会上所做的《每天部署 10+次：Flickr 上的开发与运维合作》讲座的录音，标志着 DevOps 运动的起步。

• cloud.google.com/blog/products/devops-sre/announcing-dora-2021-accelerate-state-of-devops-report—2021 Accelerate State of DevOps报告的研究结果。

第一部分 方法——通过 CALMR 视角审视 DevOps 与 SAFe®。

在 Flickr 讲座和初始的 DevOpsDays 大会后的第二年，约翰·威利斯和达蒙·爱德华兹在 2010 年 DevOpsDays 大会上尝试定义这个新兴运动 DevOps 的核心要素。他们最终确定了文化、自动化、度量和共享（CAMS）。

CAMS 一直是 DevOps 的核心方法，直到 Jez Humble 认为精益流同样是 DevOps 的关键，并需要被纳入模型。于是，CAMS 变成了 CALMS。

Scaled Agile 于 2018 年将 DevOps 纳入 Scaled Agile 框架®。在这样做时，他们评估了当前的 CALMS 模型并做出了一个重要的认识：共享是文化的重要组成部分。通过确立文化是共享责任的文化，它定义了 DevOps 所需的文化类型。这也使得“恢复”能够被纳入模型，最终模型变成了 CALMR。

在第一部分中，我们将审视 Scaled Agile 的 CALMR 方法在 DevOps 中的应用。我们将探讨哪些特征构成了共享责任的文化。接下来，我们将研究用于自动化的技术种类以及谁负责设置这些技术。我们将看看精益流如何帮助我们快速部署并保持高质量。然后，我们将探讨如何通过持续衡量开发中产品的进展、正确性和价值来确保质量和安全。最后，我们将关注如何防止生产故障，以及如果发生生产故障时我们可以采取哪些纠正措施。

本书的这一部分包含以下章节：

• 第二章, 共享责任文化

• 第三章, 提高效率和质量的自动化

• 第四章, 利用精益流动保持工作进展

• 第五章, 衡量过程和解决方案

• 第六章, 从生产故障中恢复

第二章：共同责任文化

“文化是战略的早餐。”

来自管理专家彼得·德鲁克的这句话强调了文化对组织目标实现的影响。在前一章中，我们看到文化（人们，他们的行为，以及在组织中鼓励这些行为的结构）为流程和工具提供了基础。所以，如果文化如此重要，那么最好的文化是什么，我们如何在发现当前文化不足时，达到那个理想的文化？

我们发现，结构和行为将决定文化。我们将首先基于经典的组织文化模型，检查不同的文化。这一组织文化的考察将包括特点和特征，以及每种文化如何处理信息流动。然后，我们将探讨如何通过改变行为来推动向更理想文化的文化变革。

凭借对理想组织文化以及如何实施变革的了解，我们将研究 SAFe®所推广的文化结构。第一部分是识别精益思维和敏捷宣言如何在培养正确心态方面发挥作用。

在这种思维模式下，我们将仔细研究 SAFe®中的原则，它们不仅为结构提供了背景，还为实施的实践提供了背景，旨在优化精益和敏捷开发。

最后，我们将初步了解价值流：那些能够促进理想文化的结构。我们将看到，价值流是如何基于精益-敏捷思维和 SAFe 原则构建的，从而实现有效的文化变革。

简而言之，我们将涵盖以下主题：

• 组织变革文化

• 精益敏捷思维

• SAFe 原则

• 价值流

组织变革文化

每个社区，从最小的团队到最大的国家，都会有一种文化——它是社区身份的象征。一个社区通过其文化来识别其规范，并表明使该社区与其他社区不同的特点。

组织有责任判断其文化是否满足组织需求，并允许其成长和繁荣。这第一步是自我检查，看看文化是否对组织有利。在这一分析后，组织可以决定采取什么措施来改变文化。

什么样的文化？

1988 年，Ron Westrum 在研究如何提高医疗团队的安全性时，提出了考察团队文化的想法。他研究了这些组织如何处理信息，并提出了一个包含三种文化类型的分类法。这些文化类型如下：

• 病态文化

• 官僚文化

• 创生文化

根据 Westrum 的说法，病态文化的特征是专注于个人权力和组织领导者的荣耀。信息被作为政治权力的杠杆。领导者通常以恐惧和威胁作为激励手段来实现（领导者的）目标。

在官僚文化中，组织将规则、职位和部门界限视为其主要特征。信息可以通过规定的渠道和程序进行共享，但仅限于本地边界内。

拥有生成文化的组织专注于与组织使命的一致性。信息自由流动，传递给任何能够帮助实现使命的人。

Westrum 提出了不同文化处理不同类型信息的特点的例子，以下展示了这些特点：

	病态文化	官僚文化	生成文化
焦点	以权力为导向	以规则为导向	以绩效为导向
合作	低	中等	高
如何处理坏消息的传递者	被责备	被忽视	受培训
处理责任/风险	推卸	狭窄	共享
组织间的沟通	不鼓励	容忍	鼓励
失败的处理方式	甩锅	寻求公正	调查与学习
新信息的应用方式	被压制	由于可能导致问题而被不鼓励	被实施

表 2.1 – 组织如何根据文化处理信息

Westrum 模型的一个关键部分是处理不同文化如何应对异常或发现问题的方式。组织如何应对负面发现？Westrum 确定了六种反应方式，如下：

• 压制：阻止传播发现的人继续传播消息

• 封锁：忽视发现坏消息的人

• 公关：最小化发现的影响

• 局部修复：仅解决眼前的问题，而不调查相关问题

• 全球修复：无论问题发生在哪里，均予以修复

• 调查：彻底调查根本原因

异常反应的范围及通常产生这些反应的文化如下图所示：

图 2.1 – 各文化对异常反应的范围

根据 Westrum 的说法，生成文化中信息的自由流动促进了三件事：一致性、意识和赋权。这三个因素在设定使命和朝着目标努力时至关重要。

由于信息在生成文化中自由流动，意识很容易形成。组织的目标对所有人都透明且可见。组织内部和外部其他成员的行动被传递，以便有效地管理各项工作的依赖关系。因此，这种意识不仅仅是局部的，还展现了更广泛的视角。

这种认知带来的对齐感来自于在整个组织内传播的明确目标。这让在生成性文化中的所有人——无论层级如何——都能认同文化目标。

在一个生成性文化中，每个人都清楚组织的使命，并且所有成员都朝着实现组织目标的方向一致努力，每个人都被鼓励发言，跳出自身角色与责任的框架，积极参与持续的探讨与思考。

最终，西斯特鲁姆总结道，具有生成性文化、信息流动自由且信息处理高效的组织，能够实现系统的根本性、持久性改进，而不是依赖于快速解决方案。他指出，文化是可以变化的，组织可以从一种文化类型转变为另一种。

西斯特鲁姆（Westrum）所识别的具有生成性特点的文化，与开发-运维（DevOps）方法有着密切关系。在《加速：构建与扩展高效能技术组织》（Accelerate: Building and Scaling High Performing Technology Organizations）一书中，作者发现，具有生成性文化的组织在软件交付表现和组织表现方面更为出色。此外，具有生成性文化的组织还体验到更高的工作满意度。

我们如何改变文化？

文化遵循一个组织的结构和行为。要改变一个组织的文化，显然需要在组织的结构和组织所展示的行为规范上同时进行改变。

尽管认识到决定实践的价值观和原则很重要，但真正的行为改变只能通过应用新的实践，并允许持续重复，直到它们成为习惯。当这些习惯得到奖励并持续下去时，它们就会变成一种行为。

一种推动行为变化并推动文化变革的模型来源于约翰·科特尔（John Kotter）的《领导变革》（Leading Change）。在书中，科特尔提出了一种推动文化转型的八步法。接下来将详细介绍这种方法。

创造紧迫感

改变一种文化从来都不是一件容易的事。人们可能已经习惯了某些行为，并且不愿意采纳新的行为。通常，改变需要一个足够紧迫的理由，足以克服所有的障碍。这些紧迫的理由可能包括以下几点：

• 燃烧的平台：意识到当前的方法已经不起作用，必须做出改变

• 主动领导：具有前瞻性思维的新领导，正在推动变革以实现更好的未来

2006 年，福特汽车公司面临诸多问题，不仅由于日本和韩国进口车导致市场份额下降，还因为内部纷争。那一年，他们亏损了美国****美元（USD）170 亿美元，债务被评为垃圾级别。创始人亨利·福特的曾曾孙比尔·福特召集了波音公司现任首席执行官（CEO）艾伦·穆拉利，看看他能否扭转公司的局面。

穆拉利开始了他的工作。他创建了一个每周的商业计划评审（BPR），领导们会分享他们在前五个业务优先事项上的状态，标记为绿色、黄色或红色。所有领导都表示他们是绿色的，直到穆拉利说：“我们今年将亏损 170 亿美元，而你们却说一切正常？我们计划今年亏损 170 亿美元吗？”他对透明度的推动震撼了福特的领导层，促使他们采取进一步的变革措施。

引领一个强大的联盟

人们无法单独进行变革。他们需要找到或创建看到相同问题并愿意就解决这些问题所需变革达成一致的盟友。这些人可能已经得出相同的结论，或者愿意成为早期采纳者。

当艾伦·穆拉利开始担任福特首席执行官时，他决心不清洗现有的福特高管团队。他的执行团队中的一些成员是福特的长期员工，他们的想法与穆拉利试图推动的变革相契合。值得注意的加入者包括德里克·库扎克，他将成为全球产品开发副总裁（VP），以及贝尼·福勒，他将成为最终的全球质量副总裁。

创建一个愿景

未来的状态是什么样的？在那个未来状态中，哪些事情是重要的？这个想法不仅是理解为什么需要变革，还要明确你要变革的方向。科特尔指出，确立变革的愿景是领导层的责任。创建愿景有三个目的，如下所述：

• 使命：这明确了为什么，并为每个人提供了清晰的方向

• 动机：这推动人们朝着正确的方向前进

• 对齐：人们的行动与目标协调一致

艾伦·穆拉利详细阐述的第一个行动是他希望福特汽车公司成为怎样的公司。他最终称这个计划为One Ford。One Ford计划的目标是实现以下几个方面：

• 从根本上重组福特的制造能力，以将产能与需求相匹配

• 快速设计出满足消费者需求的新车型

• 确保计划有足够资金并确保经济可行性

• 作为一个全球统一的福特汽车公司运营，而不是当时的地区性孤岛

传达这个愿景

一旦你拥有了愿景，确保组织内的每个人都得到相同的信息非常重要。这个信息应该是清晰的，避免行话。使用富有表现力的图像和隐喻来激发想象力。持续的重复可以设定基调并赋予持久性。准备好接受反馈。领导者也将对在面对这一愿景时可能显得虚伪的行为负责。

福特有多个受众，艾伦·穆拉利必须向他们传达他的One Ford愿景。他需要广泛地向员工、福特经销商网络、供应商和股东（包括亨利·福特的后代）传达信息。穆拉利通过多种方式实现了这一目标，从演讲和新闻发布会到确保每位员工都能收到一张写有愿景要点的One Ford钱包卡。

授权他人执行愿景

一旦愿景公之于众，组织内的成员就要决定如何实现这一愿景。领导者赋予他们自主权来做出这些行为改变并采取与愿景相符的新实践。领导者还可以提供支持这些变革的措施，包括培训。领导者还应消除任何可能鼓励抗拒或阻碍变革的结构性障碍。

即便穆拉利在准备他的One Ford愿景时，所需的行动已经开始实施。当时美洲区总裁马克·菲尔兹执行了前进之路计划，该计划在穆拉利成为 CEO 后得到了加速。此计划通过关闭工厂来重新调整福特，不仅剥离了低效和无利可图的汽车模型，还重新排列了生产线。德里克·库扎克设立了一个新的设计流程——全球产品开发系统（GPDS），这使得福特能够利用全球平台创建新车模型。

产生短期的胜利

这些变革将结出成果。领导层必须识别并庆祝所有出现的胜利，无论它们多么微小。根据科特尔的观点，认可短期胜利有以下效果：

• 提供努力的证据

• 奖励那些对变革负责的人

• 允许策略的调整

• 压制愤世嫉俗者和反对者

• 保持领导层的支持

• 建立动力

巩固胜利以推动更多的变革

此时，要小心不要滑入自满。工作仍需继续进行；否则，长期的努力会停滞不前。科特尔指出，此时持续长期变革所需的标志性特征包括：

• 更多的变革，而非减少

• 引入额外的帮助

• 来自高级管理层的更多领导力

• 来自更低层级的领导力

• 消除不必要的相互依赖

当穆拉利的福特振兴计划开始实施并产生效果时，由于按揭危机引发的全球经济衰退威胁了整个汽车行业。福特继续执行其生存计划，成为唯一没有接受政府救助的美国汽车制造商。

将新变革根植于文化中

随着变革的到来和成功的产生，新的文化逐步建立。每一次新的认可是将变革转化为习惯，并把习惯培养为期望行为，直到它成为文化的一部分。

阿兰·穆拉利引入的变革已经深深影响了福特，即使穆拉利在 2014 年退休后，这些变革依然存在。One Ford的心态至今仍在福特内部回响。开发过程是一个全球统一的视角，而不是各个业务单元（BUs）的区域化视角。穆拉利引入的其中一项实践——BPR，从高层管理人员到团队逐步推广，并且仍在使用。

现在我们已经看到了改变为生成性文化的成功方式，让我们更详细地了解敏捷发布列车（ART）所展示的文化部分。

精益-敏捷心态

SAFe 文化中的一个重要部分是实践所试图培养的，是将精益思维与敏捷开发相结合。这种结合被称为精益-敏捷心态。

这种心态的两部分之一关注如何让组织消除浪费，专注于必要的事项。这个部分侧重于运用精益思维来实现这一点。

这种心态的第二部分关注确保增量交付的发生。为此，我们参考《敏捷软件开发宣言》来获得指导。在 SAFe 中，满足组织需求需要对敏捷宣言进行细致的审视和调整。我们将很快查看这些调整。

在这种心态下，我们需要检查在 SAFe 中哪些是最重要的。为此，我们将审视 SAFe 的核心价值观。

SAFe 精益之屋

精益思维源于丰田生产方式（TPS），由大野耐一创立，部分受 W·爱德华兹·戴明的启发。在 TPS 中，重要的实践和优先事项像房屋一样排列，以强调作为基础和支撑的概念与实践。TPS 的目标作为屋顶：

“最佳质量-最低成本-最短交付时间-最佳安全性-高士气”

SAFe 通过类似“精益之屋”模型的范式总结了其精益思维方法。此模型如下所示：

图 2.2 – SAFe 精益之屋（©Scaled Agile, Inc. 保留所有权利）

让我们来看看这个房屋的各个部分，具体如下：

• 屋顶（价值）：我们试图实现的目标是价值。这个价值通过最短的交付时间和最高的质量来实现。这给客户带来愉悦，甚至可能使社会变得更好。员工从一个有着高士气和对安全关怀的环境中获益。

• 支柱：

  • 尊重人员和文化：我们期望与他人合作，在一个生成性的文化中共同工作。

  • 流动：我们致力于建立连续的工作流，以便不断交付价值。

  • 创新：我们需要时间和空间来发挥创造力，让我们的想象力飞翔，探索与解决方案相关的假设场景。如果没有这些时间和空间，我们的思维就会因为担忧下一个紧急情况而受限。这通常被称为紧急事务的暴政。

  • 持续改进：我们力求进步。我们明白，来自竞争的潜在危险不仅已经存在，而且还表现为随着新技术的到来，下一位颠覆者的出现。

• 基础（领导力）：我们无法在没有有效领导的情况下建立我们的事业，这种领导能够创造一种具有创造性的文化，使每个人都能发声，鼓励流动，设定创新的时间和场所，并寻找不断改进的机会。

我们已经了解了精益-敏捷心态中的精益方面。接下来，让我们看看另一半，看看是否需要对《敏捷宣言》做出任何调整。

调整《敏捷宣言》

在 第一章，介绍 SAFe®与 DevOps 中，我们初步了解了《敏捷宣言》。考虑到宣言的原始背景最初是针对小型开发团队的，因此在团队合作的背景下，价值观和原则可能需要重新审视，并在必要时进行调整。

在审视价值声明时，我们发现其中的真理在不同的背景下并未改变。我们仍然更重视左侧的项目，而不是右侧的项目。无论是小型团队还是大型 ART，这一点始终成立。

一些原则可能需要进一步的考虑。特别是，SAFe 要求你考虑《敏捷宣言》中第 2、第 4、第 6 和第 11 条原则的适用性。

《敏捷宣言》第2 条原则指出：“欢迎变化的需求，即使是在开发的后期。敏捷过程利用变化来为客户带来竞争优势。”然而，结合硬件和软件的产品可能需要在接受开发后期的变化需求时进行平衡。可定制的软件可能允许需求变化，但需要新硬件的需求变化在部署后可能难以实现且成本高昂。

《敏捷宣言》第4 条原则指出：“商业人员和开发人员必须在整个项目期间每天共同工作。”除了与敏捷团队的其他成员合作的产品负责人角色外，SAFe 还包括来自商业方面的其他角色。产品管理 (PM)与每个团队的产品负责人合作，定义 ART 的解决方案。商业负责人作为 ART 的关键利益相关者。

《敏捷宣言》第 6 条原则指出：“将信息传递给开发团队并在团队内部传递的最有效和高效的方法是面对面的交流。” ART 举办的许多活动，如 项目增量（PI）规划和检查与适应，最初主要是以面对面形式举行的。随着全球分布式开发的普及，以及历史性全球疫情的爆发，利用网络和视频会议的技术替代方案开始出现。随着生活逐渐恢复正常，混合型会议和协作方式可能会出现。

最后，《敏捷宣言》第 11 条原则指出：“最好的架构、需求和设计来自自组织的团队。” 在这里，当我们开发复杂的系统集成时，其中 ART 有 5 到 12 个团队，需要在 5 到 12 个涌现的架构与一个统一的意图架构声音之间找到平衡。这个平衡由系统架构师提供，系统架构师负责产品的架构以及指导所有团队正在处理的启用者。

确定了正确的心态后，我们现在来看看对 ART 重要的核心价值观。

SAFe 核心价值观

SAFe 有四个重要的核心价值观，这些价值观由具备精益敏捷心态的 ART 从业人员所推动。它们列举如下：

• 对齐：在具有使命感的生成性文化中，所有参与者共同努力实现这个使命。具有生成性文化的 ART 将会有与其他团队对齐的团队。

• 透明性：生成性文化通过默认方式创造透明性。这种透明性是确保对齐并促进生成性文化的关键部分。

• 项目执行：生成性文化专注于使命。整个透明且对齐的 ART 将共同致力于实现 ART 的愿景，并交付正确的解决方案。

• 内建质量：缺陷和失败会削弱 ART 可靠交付解决方案并保持 ART 愿景的能力。为了保持 ART 正常发展，需要保持警觉的态度，检测并消除开发过程中的缺陷。

我们现在知道了 ART 需要的重要素质。让我们来研究如何根据这些原则应用这些价值观。

SAFe 原则

SAFe 可以应用于各种行业中的不同组织。组织和行业之间的差异可能很大，这可能使得朝着生成性文化发展变得困难。我们可能需要一个指南来调整我们的实践，以便发展并保持核心价值观。

10 条 SAFe 原则是为了使实践与核心价值观保持一致。让我们看看它们如何应用于 DevOps。

采取经济视角

在我们的 SAFe 精益房屋中，我们关注的是价值目标，因此我们希望确保增量和一致性地获得价值增长。为此，我们需要确保我们的决策来源于经济背景。

唐纳德·赖内特森在他的书《产品开发流程的原则：第二代精益产品开发》中指出了增量价值交付所需的经济框架。SAFe 采用的主要组成部分包括以下内容：

• 在精益预算和护栏内运作：决策应该由最接近信息的人来做，但有关决策的边界可以在更高层次进行制定，以确保仍然应用必要的治理和监督。

• 理解经济权衡：由于 ART 需要做出决策，它应当意识到这些决策带来的各种考虑因素。这些因素包括开发费用、交付时间、产品成本、价值和风险。

• 利用供应商：常常会遇到自建还是购买的决策。一个组织可能会因其劳动力不足而寻求供应商，或者该供应商可能拥有专业技能，或是某个特定组件的唯一供应商。

• 为最大收益安排工作顺序：ARTs（敏捷发布列车）不能同时做所有事情。它们需要优先考虑那些最快带来最大价值的任务。赖内特森建议使用延迟成本（CoD），即如果组织未能在正确时间交付价值所产生的成本，而不是使用投资回报率（ROI）或高层管理人员的决策，后者通常被讽刺为最高薪酬者的意见（HiPPO）。SAFe 进一步通过将延迟成本除以任务的大小或持续时间，提出了一种称为加权最短任务优先（WSJF）的物有所值度量方法。

运用系统思维

当我们开发包括系统集成的复杂产品，例如赛博物理解决方案时，我们需要采用整体视角来看待产品。但这并不是唯一需要关注的系统。

常常被忽视的是系统本身——组织。在 1967 年，梅尔文·康威提出了一个观点，现在被称为康威定律：

“设计系统的组织（广义定义）将会产生一个其结构是组织通讯结构副本的设计。”

换句话说，组织如何开发产品，将在成品的架构中得到体现。

由于康威定律的适用性，为了优化最终的架构，我们需要找到一种更好的开发产品的方式。这使我们能够审视并优化我们的价值流。

假设变动性并保持选择性

我们希望确保在开发过程中，始终保持接受需求的精神，这一点在《敏捷宣言》的原则 2中有所体现。那么，问题就来了：我们如何才能保持这一原则的精神不变呢？

我们希望了解需求通常是如何变化的。通常，在开发初期，存在很多未知数。随着开发的进展，学习发生，未知数变成已知数。

学习还帮助识别哪些设计选项能够满足需求，哪些无法实现。需求、设计选项和时间的组合形成了一个不确定性锥，如图所示：

图 2.3 – 不确定性锥

为了应对不确定性锥形，最好保持需求的灵活性，并在早期阶段提供多个设计选项（通常称为基于集合的设计（SBD））。随着时间的推移，组织会不断学习，找出哪些需求不适用，哪些设计选项是不可行的。

通过快速、集成的学习周期逐步构建

增量交付最终是关于学习的。产生一个增量的价值使客户能够提供反馈，从而帮助组织沿着正确的轨道前进，交付更多价值。这种增量的学习循环还使组织能够根据环境中的新发现，找出哪些设计选项是不可行的。

每个 ART 团队都通过其开发周期进行学习。为了统一这种学习，它需要频繁地整合其工作，测试整合效果，并寻求整个系统的反馈。这种整合应该至少与其学习周期一样频繁。

基于对工作系统的客观评估设定里程碑

许多使用瀑布方法的组织设置了阶段门里程碑，以确保下一阶段的工作准备就绪并减少风险。要进入下一阶段，里程碑用来判断该阶段的交付物是否已准备好并完成。

阶段门里程碑无法处理风险，因为阶段门会强调尽可能多地使用单一设计方案。急于通过里程碑的做法不允许学习发生，以确保解决方案仍在不确定性锥形内。直到为时已晚，你可能才意识到某个解决方案是不可行的。

SAFe 建议设置定期的里程碑。这些里程碑基于每个增量价值和当时集成解决方案的反馈与学习。

可视化和限制 WIP，减少批量大小，管理队列长度

在我们使用价值流来安排开发时，我们希望确保价值流上能够顺畅流动，以确保持续交付价值。确保流动依赖于三个关键行动，如下所述：

• 可视化和限制工作中的 进展/过程（WIP）

• 确保我们有小批量

• 管理我们的队列长度

我们将在第四章中更详细地研究这些因素，并探讨如何通过精益流动来保持工作持续推进。

应用节奏——与跨领域规划同步

我们之前识别出的 SAFe 核心价值之一是对齐。这个价值非常重要，因为我们的 ART 中有多个团队，我们希望确保每个团队的每个成员都在同步朝着 ART 的愿景努力。

为此，ART（敏捷发布火车）中的团队应用了节奏和同步。两者都是必需的，以确保开发中的固有不确定性与 ART 当前计划之间保持平衡，从而允许必要的调整。

在 ART 中的节奏意味着团队拥有相同长度的学习/开发周期。这种固定的周期长度就像是开发的鼓点。有了固定的周期，事情可以以常规且可预测的节奏进行。

在 ART 中的同步意味着团队在相同时间开始和结束他们的学习/开发周期。这使得整个系统的整合能够在团队之间发生。

节奏和同步的应用在以下图示中有所体现：

图 2.4 – 多团队的节奏和同步

应用节奏和同步的另一个关键部分是跨领域规划，在 ART 中，它发生在每个 PI（程序增量）的开始。在这里，所有团队与业务利益相关者、共享服务、架构师、PM 和发布火车工程师（RTE）一起，围绕 PI 的 ART 使命进行对齐。让这种规划按节奏进行，允许所有团队检查现实与原计划的偏差，并进行调整。这将变异性限制在一个学习周期内，从而减少返工和其他浪费。

激发知识工作者的内在动机

生成性文化欢迎组织中每个人的意见和主动性。赋能的个人共同朝着一个使命努力，从而建立这种生成性文化。那么，赋能的个人是什么样的？生成性文化对他们有益吗？

彼得·德鲁克将知识工作者定义为“比他们的上司更了解自己所从事工作的个人。”他们通常是最接近信息的人，能够判断一个解决方案是否能为客户创造价值。这正是我们生成性文化所需要的人才。我们如何确保他们能留下来并积极参与呢？

丹尼尔·平克在他的书《驱动力：激励我们真正动机的惊人真相》中推翻了人们的预期，他发现金钱奖励有效，但仅限于某个程度。在金钱之后，真正激励人们的是以下这些因素：

• 自主性：人们希望有自由去探索最佳解决方案，并自我指导他们希望做的工作

• 精通：人们希望提高自己的技能并建立专业知识

• 使命：人们希望得到确认，他们所做的工作是有意义的

通过关注我们组织中的人以及真正激励他们的因素，我们可以确保我们朝着生成性文化的方向发展。

去中心化决策

在优化交付时间时，组织会意识到可能导致延迟的因素。其中一个延迟源可能是问题的升级和等待决策。

通过赋能的个人组成生成性文化，大部分决策可能由团队来做出。有些具有战略性质的决策确实需要在组织的更高层级做出。SAFe 建议这些决策应当像这样被上报：

• 不频繁：这些决策不经常做出

• 持久：决策的影响将持续很长时间

• 整合显著的规模经济：该决策可能会影响整个组织

接下来是那些更具战术性质、团队能够做出决策的事项，而不应由领导层不断做出，因为领导层的责任是做出战略性决策。简而言之，去中心化决策就是这样的：

• 频繁：这些是需要经常做出的常见决策

• 时间关键：这些决策具有高 CoD（决策成本）

• 需要本地信息：这些决策所需的信息可以轻松从团队所在环境中获得

围绕价值组织

在经历了前九条 SAFe 原则后，我们希望设立一个结构，使得所有原则得到体现，从而促进生成性文化的形成。

我们已经看到，在交付价值时需要考虑经济因素。我们还看到，对于我们的系统，我们必须意识到那些反映我们架构的通信链接。我们希望激励我们的知识工作者，让他们能够做出必要的战术决策，以加速价值的交付。

我们希望的结构应该与开发过程相吻合，同时确保交接时延迟最小化。结构还应适应小规模学习周期，并确保价值流的持续发生。

简而言之，我们希望实现价值流而非传统的层级孤岛。在大型组织中，可能有不同的部门被组织起来，以创造稳定性。这种稳定性仍然是必要的，以应对大规模的效率。那么，如何保持这种悖论呢？

在 SAFe 中，价值流被视为一个网络，将所需人员聚集在一起，以便他们能够合作，以最快的方式交付价值。组织的层级结构依然存在，作为第二操作系统。这两种结构，模仿了约翰·科特在其著作《加速（XLR8）：为更快变化的世界建立战略敏捷性》中讨论的双操作系统，在组织中并列存在，各有其不同的必要性。

我们将在本书的其余部分探讨这个网络——价值流。我们将看到如何识别和绘制我们的价值流，如何将其转化为 ART，以及如何使用 持续交付（CD）管道来辅助价值流。让我们从仔细看看什么是价值流开始。

价值流

我们看到 SAFe 原则 #10 讲到了围绕价值进行组织。为了实现这一点，我们的组织必须建立和使用价值流，以确保我们持续为客户创造价值。那么，什么是价值流呢？

价值流的经典定义来源于精益思想，它描述了步骤、执行这些步骤的人以及每个步骤相关的时间。它随后成为优化的平台，使得组织能够减少交付周期。

SAFe 将这个经典定义应用于两个背景中。第一个背景是操作价值流，描述了客户或最终用户与组织的互动，以及在这种互动中使用的产品。第二个背景是开发价值流，描述了产品或解决方案的开发过程。

我们将首先审视经典定义，然后探讨它们如何演变为操作和开发价值流。

经典价值流

如果我们追溯精益思想的起源，它源于制造业，那么价值流就是在工厂中一系列的装配步骤，用来生产将离开工厂并出售给客户的产品。

将价值流应用于产品开发时，我们将起点改为对新功能的初始请求或新产品的初步构想。然后我们概述主要步骤及执行者。价值流的终点是当新功能或产品发布给客户时。一个典型的例子如下所示：

图 2.5 – 价值流

价值流是精益方法论的关键部分。James P. Womack 和 Daniel Jones 在他们的著作《精益思想》中提出了一个五步过程，涉及价值流。这个过程总结如下：

1. 与客户合作，识别价值。

2. 确定详细描述从请求到交付活动的价值流。

3. 确保在创建的价值流上实现流动。

4. 当正常流动发生时，确保客户能够通过价值流拉取所需的更改。

5. 持续改进和优化价值流。

操作价值流和开发价值流

前一节介绍的经典价值流无疑为从初始概念到客户发布的开发过程提供了模型。在 SAFe 中，这样的价值流被定义为开发价值流。

SAFe 还关注客户如何使用组织的产品和服务来实现价值。从客户的角度来看，这一视角被定义为运营价值流。运营价值流涉及的产品和服务是由开发价值流来开发和维护的。

让我们看看运营价值流和开发价值流是如何协同工作，以通过一个包含虚构媒体流服务的例子，为客户创造价值的。

新的客户希望在流媒体服务上查看节目。他们将通过网站门户（由门户 ART 开发）设置帐户，包括必要的账单。可能还希望通过移动界面（由移动 ART 开发）在智能电视上设置流媒体服务。最后，他们可能希望观看流媒体服务独有的原创节目（由内容 ART 开发）。

这个客户场景展示了作为一个运营价值流与交叉的开发价值流的方式：

图 2.6 – 具有开发价值流的组织价值流

价值流代表了一种关键的精益实践。采用价值流并围绕价值流组织工作，使 ART 能够培养出肯定精益敏捷心态、核心价值和 SAFe 原则的行为。随着这些行为的稳定，文化向生成性文化转变，使每个人都与使命保持一致。

摘要

在本章中，我们通过研究文化、自动化、精益流、衡量和恢复（CALMR）方法中的第一个也是最重要的因素：文化，开始了我们的探讨。我们研究了 Ron Westrum 的工作，该工作讨论了三种类型的组织文化：病态、官僚和生成性。通过分析每种文化的特点，我们发现真正赋能我们团队的是生成性文化。

一旦我们确定了理想的组织文化，我们就开始研究如何向这一理想文化过渡。为了帮助这一过程，我们研究了约翰·科特尔（John Kotter）提出的变革模型的八个步骤。我们还通过福特汽车公司在艾伦·穆拉利（Alan Mulally）领导下的例子，看到这些步骤是如何实际运作的。

我们识别出了推动我们在生成性文化中展现的行为的心态。这一心态的来源既来自精益思维和敏捷宣言的知识体系，也来自 SAFe 的核心价值观。我们还识别了敏捷宣言中的一些原则，这些原则在与一个由多个团队组成的规模化环境合作时可能需要特别关注。

另外，推动我们行为并提供额外视角的是 SAFe 的 10 个原则。我们看到这些原则如何在核心价值观、心态和实践之间起到指导作用。

最后，由于文化既建立在结构又建立在行为的基础上，我们深入探讨了创建生成性文化的理想结构。我们还看到了价值流如何从精益起步，SAFe 如何将经典的价值流定义发展为操作和开发价值流。

在本章中，我们了解了文化的重要性以及如何通过行为改变来实现这种文化。技术可以帮助推动这种向生成性文化的转变。在下一章中，我们将探讨形成 CALMR 自动化方面的技术，它促进了这种转变。

问题

通过回答以下问题来测试你对本章概念的理解。

1. 在生成性文化中，信息传递者是：

   1. 归咎。

   2. 经过培训的。

   3. 被忽视。

   4. 被庆祝。

2. 在 SAFe 精益之屋中，作为屋顶的是？

   1. 时间

   2. 价值

   3. 领导力

   4. 创新

3. 对于 ART 中的团队来说，要实现对齐，他们需要同时练习节奏和 _______。

   1. 流动

   2. 文化

   3. 协同

   4. 独立性

4. 识别两个 SAFe 核心价值观。

   1. 内建质量

   2. 适应

   3. 授权

   4. 流动

   5. 透明性

5. 价值流识别 _________、参与者及从最初想法到向客户交付有价值事物所需的时间。

   1. 工具

   2. 文化

   3. 步骤

   4. 产品

6. 在科特变革模型中，生成 短期胜利 后会发生什么？

   1. 庆祝并认可胜利

   2. 授权他人实施愿景

   3. 巩固胜利以推动更多变革

   4. 将胜利与愿景联系起来

进一步阅读

如需更多信息，请参考以下资源：

• www.ncbi.nlm.nih.gov/pmc/articles/PMC1765804/—Ron Westrum 发表的“组织文化的类型学”文章，识别三种组织文化类型、它们的特征及影响。

• 《加速：构建和扩展高绩效技术组织》 作者 妮可·福斯格伦博士、杰兹·汉布尔 和 基因·金—这本书是基于研究的方法，探讨 DevOps 原则和实践的有效性。

• 《领导变革》 作者 约翰·科特尔—这本书描述了改变组织文化的八步模型。

• 《美国偶像：艾伦·穆拉利与拯救福特汽车公司之战》 作者 布莱斯·G·霍夫曼—透视艾伦·穆拉利及其他人所推动的变革，挽救了福特汽车公司。

• www.scaledagileframework.com/lean-agile-mindset/—在 SAFe 中对精益敏捷思维的介绍，包括 SAFe 精益之屋和敏捷宣言。

• 《产品开发流的原则：第二代精益产品开发》 作者 唐纳德·赖因特森—这本书是 SAFe 十大原则的基础，是了解流动的有趣读物。

• 《驱动力：激励我们的惊人真相》 作者 丹尼尔·平克—揭示了是什么激励知识工作者。

• 加速 (XLR8): 为更快变化的世界构建战略敏捷性 由约翰·科特尔编著——科特尔关于通过建立“双重操作系统”来改变组织的又一力作。

• 精益思想 由詹姆斯·P·沃马克和丹尼尔·琼斯编著——通过价值流来探讨精益原则。本书的大部分内容基于对 TPS 的分析。

第三章：提高效率和质量的自动化

在 CALMR（文化、自动化、精益流、度量、恢复）方法中的因素中，自动化是最与 DevOps 方法相关的。DevOps 从业人员投入了大量精力来跟踪技术趋势，尤其是在环境和工具方面。这些具有不同功能的工具被联系在一起，形成了工具链或管道。

我们通过首先看看每个管道所需的基础工具类型，开始对我们管道中不同类型的工具进行探讨。这些工具包括敏捷项目管理、版本控制系统和审查/文档工具。

持续集成（CI）工具来源于构建管理工具。我们将考察创建构建的工具，以及在构建执行时运行的其他工具。这些包括自动化测试工具、打包工具和工件仓库。

持续集成的扩展是将构建包部署到预发布和生产环境中。我们将考察在持续部署（CD）中使用的工具类型，包括配置管理、基础设施即代码（IaC）和漏洞扫描工具。

自动化仍然依赖于人力。我们将探讨开发团队和运维团队如何对齐，以使用 DevOps 拓扑结构创建必要的自动化和环境。

最后，我们将看到人们如何在 SAFe®中为持续交付管道创建自动化，通过检查系统团队在敏捷发布 列车（ART）中的工作来实现这一点。

简而言之，本章将涵盖以下主题：

• 管道和工具链

• 持续集成

• 持续部署

• DevOps 拓扑结构

• 系统团队

管道和工具链

工具链是产品开发生命周期中 DevOps 实践所使用的一组工具。在 DevOps 中，工具链的经典表示是一个无限循环，分解成多个功能。每个功能或阶段都通过自动化得到了增强。由 Kharnagy 创建并依据创作共用署名-相同方式分享（Creative Commons Attribution ShareAlike）许可的此无限循环表示如图所示：

图 3.1 – DevOps 工具链

如果我们将这个无限循环的两端分开，我们就能看到管道的基础。管道协调着所有阶段的操作，唯一例外是监控阶段。这标志着我们对每个管道阶段的探讨开始，如下图所示：

图 3.2 – DevOps 管道

我们通过查看那些其产物启动管道的活动：计划和创建，开始检查管道。这些基础步骤在图 3.3中进行了说明：

图 3.3 – 管道基础

我们通过了解基础工具来开始对 CI/CD 管道的检查。我们将探讨能够帮助我们规划价值流并监控整个开发过程进展的工具。同时，我们还将检查作为代码、测试、配置脚本和文档存储库的工具。

使用敏捷项目管理工具进行规划

要查看从请求到发布的进展，我们需要找到一种方式来理解我们必须做什么，以及这些步骤的进展如何。实现这一目标的方法有很多，从物理看板到 Excel 表格。随着团队在远程和地理分布的工作方式下展开合作，敏捷项目管理工具成为了流行的选择。

敏捷项目管理工具允许创建和更新工作项。工作项的进展可以通过看板或问题列表进行显示。记录工作项及其进展有助于轻松收集进度指标，例如交付周期。

此外，工作项可以与版本控制中的分支和 CI/CD 管道工具中的执行进行关联。这允许在整个管道中跟踪更改何时发布。

领先的敏捷项目管理工具包括 Atlassian 的 Jira 和 Trello，微软的 Azure DevOps，Digital.ai Agility（前身为 VersionOne），IBM 工程工作管理（前身为 IBM Team Concert）以及 Broadcom Rally。此外，许多版本控制工具，如 GitHub 和 GitLab，也包括敏捷项目管理功能。

创建代码和文档

版本控制自 1990 年代以来就是软件开发的重要组成部分。通过版本控制，多个开发人员可以在同一代码库上工作，而不必担心删除彼此的更改。为此，开发人员会创建一个包含其更改的分支。当需要共享这些更改时，他们会将更改合并回共享分支，并解决任何差异。合并也是其他开发人员审查即将合并到共享分支中的代码更改的有效时机。

如今，代码不再是唯一保存在版本控制中的工件。用于自动化测试的测试脚本也可以保存在版本控制中。用于配置暂存和生产环境的文本文件同样会保存在版本控制中。简而言之，任何涉及更改或发布的文本都会保存在版本控制中。正如我们在 第一章 中看到的，介绍 SAFe® 和 DevOps，在观察 Flickr 时，开发与运维之间的常见版本控制系统是最理想的。

最流行的代码版本控制系统是 Git，它由 Linus Torvalds 发明，曾作为 Linux 操作系统的仓库。Git 是一个分布式版本控制系统，允许整个仓库的副本轻松复制，甚至可以复制到开发人员那里。尽管复制非常简便，但仍然有 Git 托管解决方案，允许组织将仓库集中到一个源。最受欢迎的 Git 托管产品包括 Atlassian 的 Bitbucket、GitHub、GitLab 和 Azure DevOps。

文档是产品开发中另一个重要的制品。非功能性需求（NFRs）可以在规格中详细说明，架构可以通过模型和图表来指定，用户界面/用户体验（UI/UX）指南可以通过线框图和草图来展示。这些初步设计可能从规划开始，并在迭代学习周期中继续发展。

文档仓库和 Wiki 软件用于存储需求规格、架构模型、UI 线框图以及产品和用户文档。常见的仓库包括 Atlassian 的 Confluence 和 GitLab Pages。

一旦代码更改已添加到版本控制中的仓库，CI/CD 流水线的工作就可以开始。我们来看看构成持续集成的活动。

持续集成

当代码更改准备好时，自动化可以开始构建用于预发布和生产环境的必要包。作为构建过程的一部分，可以运行测试以确定功能是否正确以及是否安全。当测试表明功能正确且安全时，将创建一个包，并根据使用的技术存储在制品仓库中。

该流水线部分在下图中进行了说明：

图 3.4 – 流水线：持续集成

让我们看看流水线中的 CI 部分如何管理构建、执行初步测试并打包构建。我们将从定义持续集成、持续交付和持续部署开始。

持续集成与持续交付与持续部署

我们将看到，持续集成捕获了在更改提交到版本控制系统后可以自动运行的活动。包括任何更改的代码，可以被编译或打包成计算机可以使用的形式。构建步骤之后会运行测试，以确保没有引入任何漏洞或安全隐患。在成功或失败时，可以生成通知。成功后，代码更改可以与现有代码库合并。我们将在第十一章中详细探讨这些步骤，解决方案开发的持续集成。

持续交付通过允许将新合并的变更打包并交付到暂存环境、尽可能与生产环境相似的测试环境或生产环境，进一步推动了持续集成的步骤。一旦交付到环境中，就可以运行进一步的测试，以验证新特性的正确性或执行更深层的安全扫描。这些测试的成功使得组织可以在变更准备好时发布它们。有关持续交付的详细步骤（标为持续部署），将列在第十二章，持续部署 到生产中。

持续部署是在持续交付的基础上再进一步的步骤：当生产环境中的测试完成时，新特性会自动发布，让客户立即使用。

无论你最终的自动化目标是持续集成、持续交付，还是通过持续部署完全自动化发布，你通常会使用相同的工具来建立你的流水线。现在我们来看看这类工具。

编排变更

流水线编排工具（通常称为 CI/CD 工具）最初是作为构建管理工具的。这些工具在手动触发或在版本控制系统中发生提交时，执行构建脚本并执行其他操作。

早期的 CI/CD 工具将要执行的任务作为 UI 的一部分来维护。而如今的 CI/CD 工具允许通过文本文件使用 YAML 或其他格式来定义任务。

CI/CD 工具的强大之处在于它们的灵活性。通过与其他工具的轻松集成来执行其他功能，如自动化测试和部署，使得 DevOps 运动取得了整体成功。通过在工作节点中加入代理软件，实现执行的可扩展性也是一个重要因素，允许在任何环境中创建任务。

CI/CD 工具可以在本地环境、私有云中，或作为软件即服务（SaaS）产品进行设置。最受欢迎的本地或私有云环境中的 CI/CD 工具仍然是 Jenkins，这是一个开源项目，最初作为 Hudson 开发。其他受欢迎的工具包括 CircleCI 和 Atlassian 的 Bamboo。许多 Git 托管产品已经将 CI/CD 流水线扩展作为其系统的一部分推出，包括 GitLab、GitHub 上的 GitHub Actions、Azure DevOps 以及 Bitbucket Cloud 上的 Bitbucket Pipelines。

验证质量

到目前为止，流水线能做的最重要的功能之一就是设置并执行自动化测试。由于左移理念的兴起，自动化测试越来越受到关注，人们意识到越早进行测试、测试越频繁，最终产品的质量就越好。DevSecOps 运动倡导尽早并频繁地进行自动化测试，作为建立持续安全的一种方式。早期测试可以通过模拟输入并评估输出，或通过检查代码，在不要求在环境中执行代码的情况下进行。

这些第一层测试称为单元测试和静态分析。我们现在来详细了解它们。

单元测试（测试驱动开发）

单元测试是编写的脚本，用来验证代码中的函数在给定模拟输入时是否能产生预期输出。单元测试框架，如 JUnit 和 NUnit，专门针对用于创建代码的编程语言。单元测试可以作为一个定义的阶段直接从流水线中运行。

测试管理软件也可以用于执行单元测试。每个单元测试都会作为测试用例保存在测试管理软件中，结果也会被记录。测试管理软件还可以设置与敏捷项目管理工具的集成，当测试失败时记录缺陷。

流行的测试管理软件包括 IBM 的工程测试管理、XBlend 的 XRay 和 SmartBear 的 Zephyr。

静态分析

静态分析是指在不执行代码的情况下对代码进行检查。通常，使用工具来分析和审计代码。静态分析有其他名称，具体取决于预期的输出：

• Linting 是一种使用特定工具（lint）进行的静态分析。Linting 检查代码，寻找可能的代码错误，并可用于强制执行编码标准。

• 静态应用安全测试（SAST）是应用于寻找代码中可能存在的安全漏洞的静态分析。

• 依赖扫描查看代码调用的库的依赖关系，以检查是否存在已知的安全漏洞。

• 许可证扫描查看代码调用的依赖项，审查这些库所使用的开源许可证类型。这有助于确保组织遵守所使用的开源许可证类型，并判断是否需要归属和分发更改。

能执行上述分析（包括 SAST）的工具有：SonarSource 的 SonarQube，Snyk，Synopsys 的 Coverity，mend.io（前身为 WhiteSource），Perforce 提供的 Klocwork，以及 GitLab。

部署打包

在第一阶段测试通过后，流水线可以准备代码更改。打包这些更改取决于多个因素，包括所使用的语言和部署技术。

构件库工具可以实现对大规模包镜像的版本控制。这些可能会在前面提到的版本控制软件中造成存储问题，因为这些构件是大型二进制文件。这些二进制镜像可能包括标准包，如 Java 中的 WAR 文件或 Node.js 中的 NPM 镜像，甚至是虚拟机（VM）镜像。Docker 作为一种部署技术的流行促使了对私有库中 Docker 镜像的识别和版本控制的需求，导致构件库工具增加了额外的功能。

常见的构件库工具包括 JFrog 的 Artifactory 和 Sonatype 的 Nexus。此外，GitLab 和 Azure DevOps 也可以充当二进制镜像的构件库。

持续部署

在流水线的持续集成阶段，我们看到最后一步是将变更打包成二进制镜像。持续部署从这一步骤继续，将该镜像应用于测试和生产环境。

自动化可能在这些环境中添加或更新资源时发挥作用。IaC 工具可以配置这些资源。

现在代码变更已进入环境，可以进行更详细的测试，以发现质量和安全方面的问题。在这里，测试可能还会检查这些变更如何影响性能和所需变更的验证。

随着变更添加到环境中，我们需要意识到这些变更的影响。因此，我们将测量整体环境的性能，包括存储和分析日志。

持续部署阶段在下图中展示：

图 3.5 – 流水线：持续部署

让我们来看看在这些环境中执行的活动。我们可能需要配置环境来设置新特性。接下来是将变更实际部署到环境中。最后，可以在环境中进行更多更深层次的测试，以确保功能、 安全性和价值的正确性。

使用 IaC 配置环境

通常，变更可能涉及在环境中创建新资源。配置管理工具中的部分配置可能会调用其他工具，允许自动创建资源。这些资源的创建由脚本引导，通常是 YAML 格式。由于依赖这些脚本，这些工具被称为 IaC。

公有云环境的兴起，如亚马逊网络服务（AWS）、微软的 Azure 和谷歌云平台，带来了与每个云环境相关的工具。其中最著名的是与 AWS 配合使用的 CloudFormation。

其他供应商提供的 IaC 工具更加灵活，能够在多种物理服务器、私有云和公有云环境中工作。其中最著名的是 Hashicorp 的 Terraform。

使用配置管理和功能标志进行发布

配置管理工具负责识别和设置开发与生产环境的配置。流水线可以调用配置管理工具，引入已经通过持续集成阶段的构建包。

最初，配置管理工具用于指定物理（裸金属）服务器或虚拟机镜像的配置。它们已经扩展到包括 Docker 容器和 Kubernetes 集群。

配置的描述通常以期望的配置状态为标准，但不详细说明达到该状态的必要步骤。这有助于在系统中实现幂等性。

流行的配置管理工具包括 Progress Chef 提供的 Chef、Puppet 以及 Red Hat 提供的 Ansible。Ansible 相较于 Chef 和 Puppet 有一个优势，它通过 安全外壳（SSH）连接环境资源，这避免了在资源上安装代理软件。

使用功能标志发布可见性

即使代码更改进入生产环境，这些更改可能对最终用户不可见，或者不会影响现有的功能。这可能是由于代码切换或功能标志，它们阻止了代码更改的可见性。这允许逐步推出更改，比如金丝雀发布。它还允许通过停用相关的功能标志，快速回滚到先前的状态。

流行的功能标志工具包括 LaunchDarkly、Flagsmith 和 CloudBees Feature Management。

通过在环境中进行高级测试，进行额外的验证。

现在，变更已经构建、打包并放置到环境中，测试可以在更深层次进行。测试输入可以放入环境中，以确定代码是否按预期工作，是否引入了任何漏洞，以及系统是否按预期运行。

这些测试类型衡量正确的功能性、安全性和接受度，其描述如下。

功能和用户界面测试

功能测试最关心的是代码的正确性。它的存在主要是为了检查代码是否有效并满足基本要求。通常，功能测试超越了单个代码功能的范围，这些功能已经在单元测试中进行过验证。以下场景使用了特定类型的功能测试：

• 健全性测试是运行一小组功能测试，用于验证代码功能。

• 冒烟测试通常涉及运行简短的高层次功能测试，以增强对新构建或新部署的信心。

• 回归测试是一种更广泛的功能测试执行，用于验证新代码功能与现有系统功能是否兼容。

自动化功能测试工具依赖于编码特性所在的语言、代码将部署的环境以及技术平台（如 Web、移动端等）。常见的工具包括 Micro Focus 的 UFT、Worksoft Certify 和 Tricentis Tosca。

UI 测试是对图形用户界面的功能性测试。它确保页面上的元素（如按钮和字段）能够正确连接到底层代码功能，并确保这些代码功能的正确性。

许多流行的 UI 测试工具基于 Selenium，这是一个可以捕捉在网页上执行的操作，并生成可以被自动化重复执行的脚本的平台。此类工具包括 SmartBear 的 TestComplete、CrossBrowserTesting 和 Sauce Labs。

负载/性能测试

性能测试，如负载测试，并非用于衡量功能的正确性。性能测试的目标是验证任何非功能性需求（NFR），如可靠性和可扩展性。我们希望看到系统（包括任何新的代码更改）如何通过大量系统请求（如登录和表单评估）来承受资源需求的增加。

性能测试的常用工具包括 Micro Focus 的 LoadRunner 和 JMeter 用于传统应用程序，以及 Sauce Labs 的 Sauce Performance 用于 Web 和移动应用程序的性能测试。

动态应用安全测试

动态应用安全测试（DAST）继续强调 DevSecOps 中的安全性。通过 DAST，自动化测试通过对 Web 应用环境进行模拟攻击来进行安全扫描，寻找漏洞。

领先的 DAST 扫描器是 OWASP Zed Attack Proxy，它被 GitLab 用来在其流水线中提供 DAST 扫描功能。

IaC 扫描

针对 DevSecOps 的附加测试继续提供扫描 IaC 文件的能力，以发现是否存在配置错误或安全漏洞。

领先的工具，如 Snyk 和 GitLab，可以扫描多个 IaC 工具，包括 Ansible、Terraform、Dockerfiles 以及公共云的配置服务，如 CloudFormation、Google Deployment Manager 和Azure 资源 管理器（ARM）。

容器扫描

容器是一种技术，将应用程序及其所需的库封装为虚拟镜像。该虚拟镜像可以是操作系统提供的功能所代表的基础资源的扩展。

Docker 是实现容器的技术。开发者在 Docker 镜像中定义应用程序和库。镜像可以放入一个仓库中，通过 Docker Engine 在任何环境中拉取并执行。

容器扫描允许扫描 Docker 镜像及其依赖的镜像，以寻找安全漏洞。可以执行容器扫描的工具包括 GitLab 和 Snyk。

验收测试（行为驱动开发）

验收测试是用一种称为 Gherkin 的业务可读语言编写的测试脚本。每个测试由三条主要的条款组成，每条条款以一个关键字开始：

• 给定：本条款描述了初始条件

• 当：本条款描述了测试的输入

• 然后：本条款描述了期望的行为

Cucumber 是执行 Gherkin 测试的工具。Cucumber 提供开源版本，并且付费版本可以通过 CucumberStudio 和 Cucumber for Jira 获得。所有版本都由 SmartBear 支持。

监控环境

我们现在离开那些作为管道一部分的工具，转向那些持续运行的工具。对预生产和生产环境的持续评估由独立于管道的工具完成。这些工具执行以下功能：

性能监控/报告

稳定性是运维的关键目标。为此，他们将通过收集能够指示关键组件健康状况的指标来监控环境的健康状况。以下是可能包括的指标：

• CPU 利用率

• 内存利用率

• 存储利用率

• 进程数量

• 网络统计

• 应用状态

流行的监控工具包括 Prometheus 用于收集指标，Grafana 用于在仪表板上显示这些指标。如果环境在公共云中，AWS 上有 CloudWatch，Azure 上有 Azure Monitor。基于云的监控即服务（MaaS）产品可以整合来自多个环境和来源的监控。这类产品包括 Datadog 和 New Relic。

日志收集

监控的另一个方面来自于收集由系统和应用程序生成的日志消息。当环境中出现问题时，这些消息可能为问题提供上下文。

来自不同系统、不同系统组件和不同应用程序的日志通过日志聚合工具被收集到一个源中。这些工具包括搜索功能，在必要时可以根据重要的关键词进行过滤。

日志聚合工具可以是驻留在本地或私有云中的软件应用程序，也可以是公共云提供的一个功能，或者是一个SaaS产品。流行的日志聚合工具包括 Elasticsearch、Logstash 和 Kibana（ELK 堆栈）组合，用于本地/私有云环境中的数据收集和分析。日志收集是 AWS CloudWatch 服务的一部分。Splunk 和 Datadog 是流行的基于 SaaS 的产品，执行日志聚合。

警报

当问题发生时，及时通知关键人员非常重要。警报工具可以提供多种通知渠道，包括电子邮件、短信和即时消息。这些工具还可能提供容忍机制，以防止向运维人员发送过多的警报信息，从而避免出现警报疲劳。这些工具还可以为事件管理创造问题，以便遵循IT 服务管理（ITSM）流程。

领先的告警工具包括 PagerDuty 和 Atlassian 的 Opsgenie。

到目前为止，我们已经讨论了创建 DevOps 自动化中涉及的技术。现在让我们把注意力集中到人员方面，具体来说，谁可以负责安装和配置像 CI/CD 管道这样的自动化。

DevOps 拓扑结构

随着越来越多的工具和技术可供开发与运维使用，可能很难弄清楚在向 DevOps 方法转型过程中，哪些责任归属谁。谁负责创建 CI/CD 管道？我们如何定义数据库？我们如何部署到生产环境？

2013 年，Matthew Skelton 最初描述了三种需要避免的团队反类型以及五种可能的团队结构。后来，随着更多的贡献，反类型数量增加到了八个，团队结构的有益类型增加到了九个。以下是这些反类型的列表，详细内容可以在web.devopstopologies.com查看：

• 开发与运维孤岛

• 永久性的 DevOps 团队孤岛

• 开发不需要运维

• DevOps 作为开发工具团队

• 重新命名的系统管理员

• 运维嵌入开发团队

• 开发与 DBA 孤岛

• 假的 SRE

以下是该网站提供的 9 种 DevOps 拓扑结构。

开发与运维协作

这种结构被视为理想的 DevOps 方法，开发与运维在一起工作，并有着顺畅的协作。实现这一结构可能需要进行大规模的组织文化变革，朝着创造性文化的方向发展。

图 3.6 – 开发与运维协作（基于 devopstopologies.com 的工作图示 – 依据 CC BY-SA 许可）

完全共享的运维职责

一些拥有单一基于网络的产品的组织，如 Netflix 或 Facebook，可能能够采用前面提到的开发与运维协作模型，并更加全面地集成运维。在这种模型中，开发与运维之间几乎没有隔阂。因此，每个人都专注于使命。

图 3.7 – 完全共享的运维职责（基于 devopstopologies.com 的工作图示 – 依据 CC BY-SA 许可）

运维作为基础设施即服务

可能有一些组织仍然保留传统的运维部门。此外，一些组织可能会将应用部署到公共云环境中，例如 AWS 或 Azure。在这两种情况下，开发部门中的一小部分人员可能会将运维视为服务，并为这些资源的部署、指标、配置和监控设置工具。在这种模式下，没有与运维的直接协作。

图 3.8 – 运维作为基础设施即服务（图表基于 devopstopologies.com 的工作 – 采用 CC BY-SA 许可）

DevOps 作为外部服务

一些较小的团队和组织可能没有足够的人员或经验来推进 DevOps 方法。在这种情况下，他们可能会外包给外部供应商来创建测试环境、自动化和配置监控。DevOps 供应商也可能会培训开发和运维团队，以便转向不同的模型，例如开发和运维协作。

图 3.9 – DevOps 作为外部服务（图表基于 devopstopologies.com 的工作 – 采用 CC BY-SA 许可）

DevOps 团队（有使用期限）

可能存在某些情况下，拥有一个专门的 DevOps 团队是有效的。其思想是，DevOps 团队可以充当开发和运维团队之间的桥梁。DevOps 团队可以指导开发人员如何与基础设施合作，也可以指导运维人员如何进行敏捷开发。在某些时刻，DevOps 团队将解散，允许开发和运维在 Dev 和 Ops 协作模型中进行合作。

当 DevOps 团队没有解散，而是形成了一个独立的“孤岛”时，就存在危险。这实际上是 DevOps 拓扑网站中提到的反面类型之一（DevOps 团队孤岛）。

图 3.10 – 有使用期限的 DevOps 团队（图表基于 devopstopologies.com 的工作 – 采用 CC BY-SA 许可）

DevOps 倡导团队

如果开发（Dev）和运维（Ops）两个部门逐渐脱节，DevOps 倡导团队会充当两者之间的协调者。与有使用期限的 DevOps 团队不同，这个 DevOps 团队是持续存在的，确保开发和运维都遵循当前的 DevOps 实践。

与有使用期限的 DevOps 团队一样，DevOps 倡导团队也有转变为 DevOps 团队孤岛的风险。

图 3.11 – DevOps 倡导团队（图表基于 devopstopologies.com 的工作 – 采用 CC BY-SA 许可）

SRE 团队

早在 2004 年，Google 就已经将其软件工程师作为运维人员使用。这些站点可靠性工程师（SREs）负责生产环境的支持，主要通过开发软件来保持资源和服务的运行。SREs 接受开发提供的应用，但前提是开发提供了足够的日志和度量数据，证明它符合质量标准。如果代码不符合标准，SREs 可以拒绝部署。

图 3.12 – SRE 团队（基于 devopstopologies.com 网站的工作图示 – 按照 CC BY-SA 许可）

容器驱动的协作

由于容器抽象了许多基础设施细节，因此大部分开发与运维之间的协作是无需的。在这种情况下，如果有良好的工程文化，运维大多数时候可以接受基于容器的部署。如果没有得到密切监控，就有可能转变为一种反模式，期望运维毫无疑问地部署来自开发的任何内容。

图 3.13 – 容器驱动的协作（基于 devopstopologies.com 网站的工作图示 – 按照 CC BY-SA 许可）

开发与 DBA 的协作

如果一个组织开发的应用程序依赖于一个或多个中央数据库，那么开发人员与数据库管理员（DBA）之间的协作可能至关重要。为了实现这种协作，开发中的数据库开发人员与运维中的 DBA 密切合作。

图 3.14 – 开发与 DBA 的协作（基于 devopstopologies.com 网站的工作图示 – 按照 CC BY-SA 许可）

现在我们已经看到组织负责 CI/CD 流水线的团队的可能配置，让我们更详细地看看 ART 中的这个团队：系统团队。

系统团队

系统团队是 ART 中的一个团队，负责持续交付流水线的工具和自动化工作。他们与 ART 中的其他团队合作，帮助交付有价值的解决方案。

系统团队可能会遵循几种 DevOps 拓扑之一。系统团队可以作为一个有到期日期的 DevOps 团队来设立。他们将建立持续交付流水线，并在解散之前指导开发和运维人员如何使用它。系统团队的另一种模型可能是作为一个 DevOps 倡导团队来设立。

作为自动化和开发过程的管理者，他们对 ART 中的其他团队负有深厚的责任。这些责任如下所述。

解决方案开发的基础设施建设

系统团队通常负责设置 CI/CD 流水线的预构建、持续集成和持续部署部分，并将技术整合，使其成为持续交付流水线的无缝一部分。他们努力尽可能应用自动化。这也可能涉及与其他团队的紧密合作，因此他们可能会参加其他团队的活动。

解决方案集成的先锋

作为维护 CI 阶段的一部分，系统团队可能会参与在代码更改提交到版本控制后，确定构建过程。他们会维护正确的构建脚本和 CI 配置文件。如果尚未实现构建自动化，他们可能是执行构建和集成活动的团队。

设置端到端测试

为了支持其他团队，系统团队可能会协助测试人员创建和优化自动化测试。他们还可能与其他团队合作，将不同的测试整合成定义明确的测试套件，用于不同类型的测试，如冒烟测试。

协助演示

ART 集成所有团队的工作，并在某一时刻演示解决方案的工作状态。这种集成和演示称为 系统演示，并以固定的节奏进行。

作为持续交付流水线的维护者，系统团队确保所有团队的技术环境正常工作，以便系统演示能够顺利进行。

促进发布

因为系统团队对整个过程有全面的了解，所以可能会被要求验证部署到生产环境和最终发布的有效性。

系统团队可以被视为 ART 的 DevOps 团队。它可能会遵循 DevOps 拓扑中的一种模式，以便与其他敏捷团队进行协作。它的主要职责是配置自动化，但它也可能以其他方式协助敏捷团队，整个 ART 一起努力交付价值。

总结

自动化在 DevOps 中起着关键作用。我们查看了构成 DevOps 工具链的重要工具，尤其是那些从构建、测试到部署进行编排的部分，这些部分构成了 CI/CD 流水线或 流水线。

CI 通常包括在代码更改提交到版本控制后发生的活动。这可能包括初步测试，并在通过后，它们可能会一起构建并打包成一个基于语言和技术的产物。

CD 从 CI 结束的地方继续，利用构建产物将其应用到测试或生产环境中。在这里，环境将重新配置，可能会引入新的资源。还会进行额外的测试，以确保安全性、正确性和预期价值的验证。

DevOps 拓扑描述了开发和运维团队之间可能的协作模型，并可能包括专门从事 DevOps 的人员。一些拓扑不是长期存在的，以免它们变成 反类型，从而扼杀协作。

在 SAFe 中，系统团队充当 ART 上的 DevOps 团队。该团队负责为 ART 上的其他团队构建和维护持续交付流水线。

自动化确实使 ART 或任何 DevOps 团队能够更快地交付，但如果开发过程未优化以实现精益流程，则无济于事。在下一章中，我们将探讨来自精益思维运动的实践，以促进流程。

问题

通过回答这些问题来测试您对本章概念的理解。

1. 什么测试是静态分析的示例（选择两个）？

   1. 单元测试

   2. Linting

   3. DAST

   4. 依赖扫描

   5. 验收测试

2. 什么允许代码更改在生产环境中隐藏，直到启用？

   1. 版本控制

   2. 持续集成

   3. 特性标志

   4. 持续部署

3. 监控包括性能监控、警报等活动，以及什么？

   1. 负载测试

   2. 版本控制

   3. 日志收集

   4. 单元测试

进一步阅读

• DevOps 拓扑结构的原始公式，包括三种反类型和五种类型：blog.matthewskelton.net/2013/10/22/what-team-structure-is-right-for-devops-to-flourish/

）

• DevOps 拓扑结构的更新公式：web.devopstopologies.com

）

• 团队拓扑：为快速流程组织商业和技术团队，作者马修·斯克尔顿和曼努埃尔·佩斯 – DevOps 拓扑结构的演变，探索各种团队的拓扑结构。

第四章：利用精益流程保持工作的推进

在 第一章，介绍 SAFe® 和 DevOps 中，我们看到将精益思维方法（如精益软件开发和看板）纳入敏捷运动。Jez Humble 认为这非常重要，足以将其纳入 CAMS 模型，并从中创建了 CALMS 模型，基于此我们得到了 SAFe® CALMR 模型。Scaled Agile 讨论了这种精益敏捷心态，强调精益思维和源自《敏捷宣言》的敏捷心态。精益思维如何在 DevOps 和 SAFe 中体现出来呢？

在本章中，我们将看到，保持产品开发以可预测的速度进行需要建立精益流程。适当的流程使自动化能够成功。为此，我们将探讨以下实践来建立精益流程：

• 确保所有工作和工作进展都是可视化的

• 限制我们的 进行中的工作/过程 (WIP)

• 保持每个工作批次的适当小规模

• 监控我们的工作队列

• 运用系统思维改变传统的项目和团队定义

使工作可视化

工作可以被定义为团队或 敏捷发布列车 (ART)（作为团队的团队）可能为开发产品或解决方案所付出的努力。但并非所有这些工作都专注于客户价值。

Gene Kim、Kevin Behr 和 George Spafford 合著的《凤凰项目：关于 IT、DevOps 以及如何帮助你的业务成功》识别了四种工作类型，概括如下：

• 业务项目：旨在为客户带来价值的新特性请求

• 内部项目：有助于组织持续高效开发产品的工作

• 维护：维护现有产品所需的工作

• 未计划工作：偶尔发生的错误、缺陷和紧急情况

SAFe 将这些工作类别中的一些放入 使能器。这里的想法是使能器帮助创造未来的业务价值。SAFe 定义的四种使能器如下：

• 基础设施：这个使能器旨在增强产品开发和交付的方式。示例包括需要纳入 持续交付 (CD) 流水线的新自动化测试。

• 架构：这个使能器旨在增强业务功能和用户故事所依赖的架构。SAFe 定义了架构使能器的顺序，作为推动未来业务价值的架构跑道。示例包括为预发布和生产环境创建新的数据库服务器 虚拟机 (VM)。

• 合规性：这个使能器描述了在某些受监管行业中可能需要的额外工作。示例包括 验证和确认 (V&V)、审批和文档。

• 探索：有时，为了理解最佳方法、学习新技术或完善客户需求，需要额外的研究。探索启用器被创建来识别研究所需的工作。一个例子是敏捷团队用来研究新技术或评估开发选项的 Spike，例如确定适合网络流媒体的技术。

考虑到不同的工作类别，展示团队或 ART 的所有工作有一个统一的方式是非常重要的。传统上，具有技术背景的企业家常常依赖电子表格，因为它们的排列灵活，可以允许添加诸如工作类别或状态等信息。此外，在团队成员之间共享电子表格变得困难，因为可能需要同步的更改。

多米尼卡·德·格兰迪斯（Dominica DeGrandis）在她的书《让工作可视化：揭示时间盗窃以优化工作和流程》中指出，大多数人是视觉-空间学习者，也就是说他们能够理解并响应以视觉方式呈现的信息。这是设立看板的原因之一。

看板是一个分为多个列的空间。每一列代表工作项在工作流中的一个状态。工作项通过便签卡表示，并用颜色编码来代表适当的工作类别。

图 4.1 展示了一个简单的看板。请注意三个列，分别代表待办工作（Backlog）、进行中工作（Doing）和已完成工作（Done）：

图 4.1 – 简单看板

看板上的额外功能可以帮助团队管理他们的工作。让我们来看看看板上的其他功能。

通过额外列指定工作流

通常，单一的进行中列无法提供团队或 ART 正在做的所有工作的可视化，尤其是当整体流程中存在瓶颈时。将进行中列拆分成多个步骤来突出开发过程中的主要环节，这样瓶颈就容易被识别。

虽然通常会将离散的过程步骤分隔到不同的进行中列中，但需要记住，团队不应将所有问题都从一列移动到另一列，否则就会让流程退化为瀑布模型。问题的移动应该是持续进行的。

图 4.2 展示了将我们的进行中列划分为分析、实施和审查阶段的示意图：

图 4.2 – 将进行中列扩展为多个阶段

标记阻碍因素和紧急问题

有时候，工作问题可能因为某些外部事件或依赖关系被阻塞。当这些阻碍或阻塞发生时，可以在工作问题上附加一个图标，作为提醒，告诉团队在解决阻塞之前需要继续关注该问题。

同样，任何紧急问题可能需要整个团队的注意。团队可能需要集中力量解决紧急问题，直到其得到解决。紧急问题可以通过特殊指示器标记，或通过它在加速泳道中的位置来识别，该泳道横跨看板的所有列。在下面的截图中，展示了一个在加速通道中通过特殊指示器标记的紧急问题：

图 4.3 – 在加速通道中具有紧急指示器的工作问题

指定退出标准的政策

在流程的每个阶段，团队需要对退出标准达成明确一致的协议。明确的退出标准可以避免混淆，确保在该阶段问题是否真正完成。这种每个列的协议被称为政策。

列政策应当在团队章程或工作协议中明确列出，以确保这些政策是明确的并且已经达成一致。例如，就绪定义（DoR）是指所有问题都已解答，且需求足够详细，开发可以开始。另一个例子是完成定义（DoD），即团队达成的协议，明确何时一个故事算完成，开发工作可以停止。这些政策避免了工作是否真正完成与完成完成之间的混淆。

我们将在接下来的部分中讨论更多看板的补充内容，确保精益流动的发生。在接下来的部分中，我们将探讨 WIP 过多的问题以及看板如何通过提供可视化和执行团队行为的约束来帮助解决这一问题。

限制在制品（WIP）

WIP 是指团队或 ART 正在进行中的工作。它已经开始，但尚未完成。如果我们在看板上查看 WIP，它看起来像下面的截图：

图 4.4 – 强调 WIP 的看板

重要的是确保这些列中的工作得到监控，以防止其压垮团队或 ART。根据 Dominica DeGrandis 的说法，过多的 WIP 可能带来以下影响：

• 太多的多任务处理，会导致团队花费过多时间进行上下文切换，无法完成工作

• 在现有工作完成之前，新的工作项就开始了

• 工作完成时间过长（长交付周期/周期时间）

确保团队不让 WIP 失控的一个关键方法是，在每个列之间设置 WIP 限制或约束，从待办事项列（工作尚未接受）到完成列（已完成的工作）。以下截图展示了一个 Kanban 看板上 WIP 限制的示例：

图 4.5 – 列上的 WIP 限制

为了理解 WIP 限制如何帮助团队实现精益流动，考虑以下团队行为的比较。

首先，想象一下没有 WIP 限制的 Kanban 看板。团队中的一名开发人员刚刚完成了一个用户故事的开发。它符合该列的政策标准，可以被拉到下一个列。如果开发人员将该故事移到下一个列，并拉取一个新的故事来工作，那么这个开发人员做了什么来减少正在进行的工作量吗？如果已经有流动存在，这可能是可以接受的，但如果团队的过程中存在瓶颈，这个行为可能会加剧瓶颈，阻碍整个团队的交付。这种情况在我们的 Kanban 看板上可以看到，截图如下：

图 4.6 – 没有 WIP 限制的场景，导致 WIP 没有减少

现在，让我们想象在 Kanban 看板上设置了 WIP 限制。那个已经完成用户故事的开发人员无法将任何内容移入实施/测试列。此外，任何人都不能将任何内容从实施/测试列移入审查列。为了帮助解决瓶颈问题，开发人员采取行动，协助其他团队成员将一个故事从审查列移至完成列。这一做法引入了吞吐量并建立了流动。我们可以在以下截图中看到这一场景：

图 4.7 – 具有 WIP 限制的场景，导致流动

团队可以在开始工作时选择初始的 WIP 限制。经过一段时间后，如果仍然看到瓶颈，他们可以降低 WIP 限制，直到瓶颈消失，这时流动得以实现。即使瓶颈消失，其他瓶颈仍会出现。由 Eliyahu M. Goldratt 在他的书《目标》中提出的约束理论指出，应该逐步解决随后的瓶颈，一次移除一个瓶颈，以优化整个过程的流动。

根据 David J. Anderson 在他的书《Kanban: Successful Evolutionary Change for Your Technology Business》中的描述，WIP 限制是必要的机制。WIP 限制为团队创造了紧张感，鼓励团队采取行动以推进工作并促使流动，就像我们之前的场景中所看到的那样。这种紧张感还可能凸显出组织中的约束和系统性障碍。公开讨论这些约束和障碍，寻找解决方案，从而推动持续改进。

我们已经看到，通过施加列约束或工作项限制来限制 WIP（在制品）可能帮助我们解决开发过程中的瓶颈。我们过程中的另一个瓶颈来源是工作项的大小。让我们看看如何保持工作项的适当大小，以实现和维持流动。

保持小批量

批量大小通常指的是标准工作单元的大小。敏捷运动的一个成就就是成功地将交付集中在较小的增量上。这迫使我们重新审视可以交付的批量大小。减少批量大小以及限制 WIP 是实现精益流动的重要组成部分。唐纳德·莱因特森在他的书《产品开发流原则：第二代精益产品开发》中指出了批量大小的影响。让我们来探讨一下小批量在其中的作用。

小批量减少周期时间

敏捷开发的一个关键收获是以短周期交付价值。这一做法缩短了团队交付增量价值的周期时间，使得团队可以在周期结束前仅交付他们能够完成的工作。这使得我们可以说批量大小与周期时间直接相关。

保持大批量工作会产生几个不利影响。工作可能无法在周期结束时交付。交付的工作可能存在缺陷，需要修复或返工，从而增加周期时间。这些缺陷的出现也增加了批量大小，形成了滚雪球效应。批量大小和周期时间的增长会导致成本超支和进度延误。

小批量减少风险

正如我们在前一个小节中看到的，大批量工作可能带有需要修复的缺陷，这会影响整体批量大小和周期时间。尽管在小批量中工作无法消除缺陷的可能性，但它将保持可能缺陷的数量较小，从而便于管理。

小批量的一个副作用是它们导致较短的周期时间。较短的周期时间为客户反馈提供了机会。反馈的机会消除了团队在交付价值时可能走错方向的任何风险。

小批量限制 WIP

批量大小和 WIP 是直接相关的。直接改变其中之一会以相关的方式改变另一个。让我们看几个这个相关性在实际中的例子。

大批量意味着有大量的 WIP 项。如前所述，大量的 WIP 会增加多任务处理，因上下文切换增加而阻碍工作的完成。这种效应是另一个增加周期时间的因素。

大批量也会在系统中创建瓶颈。这种流动的不稳定性妨碍了工作有效推进，从而增加了周期时间。

Reinertsen 在他的书《产品开发流程的原则：第二代精益产品开发》中也提到，当在批量大小与通过解决瓶颈来限制在制品（WIP）之间进行优化时，应首先从减少批量大小开始。这通常是一个更容易实施的步骤。减少瓶颈以允许适当的流动可能涉及到更深层次的流程和技术变革。

小批量大小提高了性能

尽管看起来违背直觉，但大批量并不会在管理费用上创造效率。与小批量相比，大批量的时间处理管理活动实际上更大。大批量的管理费用会积累。而小批量的管理费用可以由于较短的周期时间而轻松减少。

小批量大小提高了效率。这看起来可能有些违反直觉，但由于小批量可以迅速获得反馈，随后的工作批次能够利用这些反馈，从而减少返工。而大批量的工作一次性暴露所有问题，导致更多的工作量，并且失去了隐含的效率。

我们已经看到使用小批量的优势以及使用大批量时发生的情况。那么接下来的问题是，“我如何确保自己不在使用大批量？”让我们来看看如何找到最优的批量大小。

寻找理想的批量大小

我们已经识别出使用小批量大小的好处。那么接下来的问题是，“什么样的批量大小足够合适？”

Reinertsen 提出了从经济学的角度来看待批量大小。当评估开发成本并确定理想的工作大小时，你需要考虑两个成本：

• 持有成本：保持（而非发布）已开发内容的成本

• 事务成本：开发工作的成本

这方面的一个例子来自于将工作发布到生产环境中的过程。下图展示了如果我们考虑发布更改的成本与在最佳时机收集更改的成本时，事务成本和持有成本曲线之间的关系：

图 4.8 – 事务成本与持有成本曲线

在我们之前的图示中，一个小变更的例子——例如发布一行软件代码——被表示为A点。在A点，我们可以承担非常低的持有成本来立即发布，但在A点的高成本来自于事务成本。我们花费了大量时间在一行简单的代码上进行测试和部署。

这是否意味着我们应该始终考虑合并更改以减少成本？让我们看一下前面图示中的B点，这个点收集了我们在更长时间周期内的更改——例如，一个月。现在，成本发生了变化。由于我们在执行测试并发布大量更改时，交易成本较低，但现在我们的持有成本很高。也许在延迟发布更改时，我们错过了一个重要的市场窗口，因而失去了销售机会，因为我们的竞争对手先发布了类似的更改。

如果我们想找出实际发布一组更改的盈亏平衡点，我们将进行U 型曲线优化。我们会将持有成本和交易成本的总和绘制在同一图表上，如前面的图示所示。在总成本曲线（持有成本和交易成本之和）的图表上，找到曲线的最低点。这就是批量中理想的项目数量。

我们如何改进这个理想的批量数量？如果我们引入新的工作方式或新技术，这可能会影响交易成本，给我们带来新的总成本曲线，并进行 U 型曲线优化。以发布更改到生产环境为例，使用自动化测试和部署工具可以实现更快、更可靠的部署，并在 CD 流水线中进行更频繁的测试，从而降低交易成本，并增强我们在一个迭代内更频繁发布故事的信心。新的成本曲线可能会类似于以下图示：

图 4.9 – 优化后的新成本曲线

我们可以从前面的图示中看到，在A点，持有成本保持不变，但交易成本已降低。同时，我们可以看到，总成本曲线的最低点已向左移动，理想点也向“小”批量规模移动。

那么，我们的团队和 ARTs 能做些什么，以便实现更低的交易成本曲线呢？采用自动化测试和自动化部署等实践和技术就是一个符合条件的例子。这些技术允许更小的批量通过，并鼓励流动。

在本节和上一节中，我们探讨了 WIP 和批量大小作为实现精益流动的因素。在下一节中，我们将看到这些因素如何与其他因素共同作用，决定你的系统是否具备精益流动。

监控队列

为了实现精益流动，你需要仔细研究排队理论，这是一门数学领域，研究排队和排队等待的行为（想象一下星巴克或你当地超市的结账区域！）。一些数学公式将有助于我们确保理解如何确保精益流动。它们包括：

• 利特尔定律

• 金曼公式

让我们看看如何利用这些排队理论的元素来实现精益流动。

我们的队列在哪里？

产品开发队列与产品制造队列之间的一个主要区别在于，产品开发（尤其是软件开发）的工件是非物理的，直到完成时很难察觉进度，而在制造过程中，你可以在车间里直观地判断产品的完成度。这种不可见性因素使得人们容易忽视这些队列，往往会自食其果。

长队列如果不受 WIP 限制或小批次大小的约束，会产生一系列问题，如 Reinertsen 所总结的。这些问题包括：

• 更长的周期时间

• 更大的风险

• 更多的开销

• 更多的变动

• 更低的质量

• 更低的积极性

我们在讨论大批量问题时，曾提到过与开销、风险和质量相关的问题。如果我们把工作的大小视为系统的队列，那么我们接下来将讨论的数学公式是适用的，并能够模拟我们精益流程的状态。

长队列如何降低工作场所的积极性？假设你正在准备工作，且下一步的流程每当你完成当前任务后就会立即准备好。这样你会有一种紧迫感，想要尽快完成自己的任务。但如果你交付完工作后，它排在其他任务后面，需要等待几周才能被处理，这种紧迫感就不存在了。

现在我们已经确定了批次大小和 WIP 作为队列，是时候看看数学公式如何展示队列、周期时间和变动之间的关系。

小法则与周期时间

我们已经看到 WIP 和批次大小如何与周期时间相关，周期时间是指我们接受工作后交付完成的时间。数学上，周期时间、WIP 和批次大小通过小法则相互关联。

小法则是一个将周期时间、WIP 或批次大小与吞吐量联系起来的表达式。小法则的公式如下：

L 代表队列的长度。这可以理解为在制品（WIP）或批次大小。L 是团队或 ART 处理的工作吞吐量。W 给出了周期时间或客户的等待时间。

此时，如果我们关心的是如何计算周期时间，那就是简单的数学问题。以以下方式书写，你可以看到周期时间（W）与队列大小（L）是直接相关的：

这是一个简单的例子，假设 Scrum 团队的积压工作。如果他们的积压工作中有 9 个用户故事，每个故事估计为 5 个故事点，而他们的速度（衡量每个迭代周期交付的故事点数量）是每个迭代 15 个故事点，我们可以用小法则来预测完成这些积压故事所需的迭代次数，具体如下图所示：

图 4.10 – 小法则的示意图

金曼公式

金曼公式是一个数学模型，用于描述等待时间如何与周期时间、可变性和利用率相关联。公式如下所示：

公式中的每一项代表一个独立的量。第一项 代表执行工作的人员的利用率。第二项 () 代表系统的可变性。第三项 (t) 代表服务时间或周期时间。

我们希望研究等待时间、利用率、可变性和周期时间之间的关系。如果我们为每个术语代入一个字母，我们将得到以下（更简单的）公式，通常称为VUT 公式：

所以，这个公式向我们展示了客户的总等待时间与利用率、可变性和周期时间是直接成正比的。

我们之前讨论过队列大小、批量大小和限制在制品（WIP）如何影响周期时间。现在让我们看看金曼公式的其他变量，了解利用率和可变性如何影响等待时间。

利用率及其影响

我们从利用率开始。当我们提到利用率时，我们是指系统整体容量的百分比。管理层可能希望达到较高的利用率——毕竟，我们不希望工人浪费时间。但是通过金曼公式，我们看到随着利用率的增加，等待时间也会增加。我们可以通过绘制利用率与队列大小的关系图来看到这一效果。结果曲线是一条非线性图形，利用率在 60%左右时开始上升，在 100%时趋近于无穷大。以下是该图示：

图 4.11 – 利用率与队列大小的比较

另一种观察这一百分比利用率的方式是将其视为负载/容量。如果负载关注的是新工作进入的速率，那么容量则关注的是工作流出并交付给客户的速率。这确保了适当的利用率，以避免我们接收超过处理能力的工作。

为了实现精益流动，必须引入调度松弛或空闲时间，以保持利用率在合理水平（例如，不能达到 100%）。这一思想源于丰田生产系统。Muri 或过度负担被视为精益中需要消除的三大浪费之一。接下来我们将讨论另一种浪费：Mura，即不均衡。我们也将其称为可变性。

可变性、其影响与行动

让我们来解释一下什么是变异性。到目前为止，我们一直假设，像在工厂车间制造产品一样，所有工作都涉及相同的努力。但事实上，情况往往并非如此。每一项工作可能涉及不同程度的努力，甚至是不同的努力。有些工作可能包含未知因素，需要更详细的调查。有些工作可能存在缺陷。变异性是描述每一项工作的个性的特性。

根据金曼公式（Kingman’s Formula），我们可以看到变异性的影响会对等待时间产生复合效应。下图中曲线显示了高变异性与低变异性对利用率的影响：

图 4.12 – 变异性对利用率和队列大小的影响

从前面的图中我们可以看到，这种影响是线性的，但组合起来会产生不希望的结果。对于高变异性，稍微降低利用率并不会遏制队列的增长。为了保持队列的控制，你必须以更低的利用率进行工作。那么该怎么办呢？

重要的是要理解，并非所有的变异性都是不好的。有些变异性可能是学习新事物所必需的。因此，关键是管理变异性，使其不会影响队列大小，从而影响等待时间。管理变异性的方法包括以下几点：

• 限制 WIP

• 使用较小批量进行工作

• 在系统中设置缓冲区

• 建立标准化流程

我们之前已经讨论过限制 WIP 和使用较小批量工作的方法，因此接下来让我们探讨一些管理变异性的其他方式。

设置过程缓冲区

精益生产通过建立缓冲区来限制变异性。这些缓冲区用于限制以下因素：

• 库存

• 产能

• 时间

在产品开发中，WIP 限制和小批量工作分别充当了库存和产能缓冲区。为了设置时间缓冲区，可以在看板中那些存在变异性的 WIP 列上建立缓冲区状态。我们看板上的一个示例如以下截图所示：

图 4.13 – 看板中实施/测试列的缓冲区状态

请注意，在每个缓冲区状态下都会设立 WIP（在制品）限制，以确保保持产出。

建立标准化流程

在上一节中，我们讨论了使用几种类型的缓冲区，以确保在多个阶段管理变异性。缓冲区管理的变异性通常是那种可以容忍，甚至由工作性质所鼓励的类型。

然而，由于开发过程中存在低效，可能会出现一定的变动。例如，鼓励某种类型的测试自动化——例如，代码的单元测试——而不是努力自动化行为驱动开发（BDD）测试以确保正确性。这样做的效果是保持较长的周期时间。

建立标准化流程可以确保减少周期时间中不必要的变动。标准化流程包括建立标准、检测任何可能的问题，并持续发现这些问题的根本原因。

我们已经看到了一些可以用来建模开发过程的实践，以确保工作按进度完成。这些实践需要有能够从头到尾审视整个过程的人来支撑。在下一节中，我们将更深入地探讨建立这种视角以及所需的系统性变革。

从基于项目的工作转向基于产品的工作

在采用价值流思维时，重要的是要改变开发的视角和思维方式，从基于项目的管理转变为基于产品的管理。

在《从项目到产品：如何在数字化颠覆时代通过流框架生存与发展》一书中，Mik Kersten 对比了德国莱比锡 BMW 工厂在组装 BMW 车型时，IT 与软件整合的成功，和诺基亚未能在智能手机行业继续主导地位的失败，后者是在 iPhone 和安卓手机推出之后发生的。他指出，尽管诺基亚成功采纳了敏捷实践，但它似乎没有促进整个产品开发过程的变化，也未能影响整个组织。他认为，在这个软件时代，基于价值流的产品导向开发能够创造和维护成功的产品。

Mik Kersten 强调了七个关键领域，其中项目管理和产品管理之间的差异十分明显。这些差异如下所示：

• 预算

• 时间框架

• 成功

• 风险

• 团队分配

• 优先级

• 可见性

现在让我们分别看看这些差异。

项目预算与价值流资金

在项目管理中，铁三角是一个广为人知的结构。在管理中，你需要查看三个因素或方面，看是否可以修正其中一个或多个因素，以完成一个项目或产品。这三个因素如下：

• 资源（人员、设备、设施等）

• 范围

• 时间

项目预算通常是一种赌注。项目能否在预计的时间框架（时间）内并且用预期的资源完成所有必要的任务（范围）？由于这个预算是批准所必需的，它通常是对三角形其他部分资源最大数量的猜测。有时这些猜测不足，导致成本超支，并可能导致另一个项目（及另一个预算）。

对价值流的资金支持更为简便。在预算期间，资源和时间保持恒定。在预算期结束时（通常是季度而非年度），开发结果和客户反馈将决定是否需要继续投入努力和能力，以满足交付功能的需求。如果需要，将为新的时间段创建一个增加分配的新预算。

确定的结束点与产品生命周期

项目的一个决定性特征是其生命周期。项目有一个开始，伴随大量活动组织团队并启动工作。接着进入开发阶段，直到项目结束：产品交付为止。此时，项目完成，项目和资金结束，开发产品的团队被解散。产品交给一个专门的维护团队，该团队可能未参与产品的开发，结果导致组织无法从中吸取全面的经验教训。

价值流从整个产品的生命周期进行时间线管理。从产品初始功能的开发和发布开始的相同团队和 ARTs，负责产品的维护和持续健康。维护的一部分包括识别并清除技术债务，确保产品的可行性。这一直持续到产品的生命周期结束。

成本中心与业务成果

基于项目的开发进度衡量往往与组成团队的成本中心的表现一致。这种脱节的进度视角集中于各个部门的表现，而非整体系统。

采用成本中心方式的另一个后果是，由于预算通常较大，项目利益相关者往往倾向于创建大型项目，而不是在交付后评估努力的价值。

价值流使用不同的成功指标。它们关注通过努力交付所产生的成果。通过允许增量交付并从客户反馈中学习，价值流可以调整以交付更好的业务成果。

前期风险识别与分散风险

在基于项目的开发中，交付风险尽早被识别，以便创建应急预案。但通常，仍有风险未被识别，因为在开发进行时，还有未知的风险需要发现。

在基于产品的开发中，随着学习的深入，风险会被逐步识别。增量交付允许在定期检查点进行调整。虽然这些调整可能会涉及一些开销，但这部分开销会分摊到产品生命周期中，随着时间的推移，它所占的比例变得非常小。

将人力调配到工作中与将工作调配到人力中

基于项目的开发从成本中心资源池中创建团队。这种通过创建团队来处理项目的方法假设资源池中的个体拥有相同的才能和技能。然而，这种假设从未成立。

这种人员重新分配的另一个后果是干扰了团队的福祉和生产力。1965 年，心理学家布鲁斯·塔克曼创建了形成、风暴、规范、表现和告别（FSNPA）团队创建模型，阐明了团队在成为高效团队过程中所经历的各个阶段。持续的重新分配和团队调整妨碍了团队达成高效表现的能力，团队未能作为一个整体协同工作。

基于产品的开发强调团队的长周期。这使得团队能够专注于获取产品知识，并作为一个整体一起成长。这提升了团队的交付能力和士气。

执行计划与学习

在基于项目的开发中，遵守项目计划是至关重要的。对计划的调整会导致成本超支，并因执行任何变更所需的额外开销而重新分配资源。

基于产品的开发通过设置逐步交付特性来欢迎变化，并为学习和假设验证创造了空间。在每次交付价值增量后，收集反馈和结果，并进行必要的调整。

不一致性与透明的商业目标

在基于项目的开发中，业务利益相关者与开发产品的 IT 部门之间往往存在脱节。这种脱节源于 IT 专注于产品，而业务方则专注于通过一系列步骤完成项目，且没有调整的余地。

在基于产品的开发中，业务和 IT 开发方面的目标是相同的：实现业务目标。这种目标的透明性促使了目标的一致性，并便于进度和反馈的共享。

总结

在本章中，我们研究了作为 CALMR 模型一部分的精益流。我们知道，达成一个精益流工作流程，其中工作进展稳定，团队既不被过度负担也不处于轻松状态，这有助于模型中其他部分的成功。为此，我们仔细分析了可以帮助团队实现精益流的精益实践。

我们研究的第一个实践是确保团队承诺的所有工作及其进展都是可见的。为了确保这种可见性，我们查看了团队可以做的工作类型。然后，我们将这些工作映射到看板上，突出了看板的功能，使我们能够看到任何一项工作进展的情况以及紧急工作的去向。我们了解了如何在看板上可视化工作进行中的状态，并通过设置工作进行中（WIP）限制来保持 WIP 在可控范围内。

从那里，我们开始查看工作或批量大小。我们努力理解确保批量大小尽可能小的重要性。我们查看了批量大小与周期时间、WIP 和性能之间的关系。牢记这一点，我们还研究了批量大小的经济学，以及如何通过 U 型曲线优化确定理想的批量大小。

然后我们通过仔细研究排队理论来看其他因素的作用。我们看到 Little’s Law 描述了周期时间与 WIP 或批量大小之间的关系。通过考察 Kingman 的公式，我们看到了其他因素及其与周期时间的关系。在接触其中一个因素——利用率时，我们看到高利用率会导致周期时间增加。我们还进一步了解了另一个因素——变异性，以及如何管理它。

最后，为了让价值流能够通过精益流传递工作，我们比较了基于项目的开发与基于产品的开发之间的差异。这些差异在更短的周期时间内创造了更强的团队和更强的产品。

为了确保工作在精益流中进展顺利，我们需要定期进行测量。我们还希望确保交付的工作不会对临时环境和生产环境产生不良影响。为此，我们将在下一章中检查测量，这是我们 CALMR 模型的下一个元素。

问题

通过回答这些问题来测试你对本章概念的理解。

1. 以下哪些是 SAFe 中的启用因素？（选择两个）

   1. 探索

   2. 测量

   3. 可视化

   4. 合规性

   5. 实际

2. Kanban 板的哪个功能可以用来可视化紧急工作的情况？

   1. WIP 限制

   2. 快速通道

   3. 列策略

   4. 扩展的工作流列

3. 过多的 WIP 会导致什么后果？

   1. 过多的多任务处理

   2. 减少的周期时间

   3. 新的工作在旧的工作完成后开始

   4. 短队列

4. 大批量大小会导致什么结果？

   1. 低 WIP

   2. 降低风险

   3. 高周期时间

   4. 高性能

5. 根据 Reinertsen 的说法，长队列会导致哪些问题？（选择两个）

   1. 更短的周期时间

   2. 更高的开销

   3. 较小的风险

   4. 更高的质量

   5. 更多的变异性

6. 哪种方法是管理变异性的方法？

   1. 更大的批量大小

   2. 建立缓冲区

   3. “一次性”流程

   4. 增加在制品（WIP）

7. 根据 Mik Kersten 的说法，哪些因素在基于产品的开发中存在？

   1. 将人力移至工作地点

   2. 一开始识别所有风险

   3. 专注于业务成果

   4. 项目规划

进一步阅读

这里有一些资源供你进一步探索这一主题：

• 《让工作可视化：揭示时间盗窃以优化工作和流动》（Dominica DeGrandis著）：探讨五种时间盗贼以及精益实践如何消除它们。过多的 WIP 被认为是其中一种时间盗贼。

• 《目标》（Eliyahu M. Goldratt著）：探讨约束理论以及如何消除流程中的瓶颈。

• 看板：为你的技术业务成功演变的变革 由 David J. Anderson 著作：关于看板的权威资料。有关看板板和限制 WIP 的进一步探索请见此处。

• 产品开发流的原则：第二代精益产品开发 由 Donald Reinertsen 著作：深入探讨精益实践背后的经济学，无论是限制在制品（WIP）、识别理想批量大小，还是利用率和变异性的影响。

• 项目到产品：如何在数字化破坏的时代，通过流动框架生存和发展 由 Mik Kersten 著作：探讨价值流及其绩效的衡量。

• 探讨团队合作模型，包括布鲁斯·塔克曼（Bruce Tuckman）的 FSNPA 模型：www.atlassian.com/blog/teamwork/what-strong-teamwork-looks-like

第五章：测量过程和解决方案

我们通过测量来查看我们的努力进展了多少。这些测量具有多个维度。我们会检查是否达成了精益流动并正确交付工作。之后，我们部署工作，看看变化是否在环境中有效，以及环境是否安全。最后，我们评估这些变化是否创造了价值，是否值得继续开发。

本章中，我们将研究用于回答上述问题的测量指标。我们将研究以下度量标准：

• 我们是否按计划交付解决方案

• 我们解决方案交付前后环境的健康状况

• 我们的解决方案是否实现了假设的价值

测量解决方案交付

在第四章，利用精益流动保持工作持续推进中，我们研究了建立和维持精益流动的实践。我们需要通过指标来评估是否实现了精益流动，以及是否能够在我们的承诺中保持可预测性。

用于评估精益流动的常见指标如下所示：

• 周期时间

• WIP

• 吞吐量

• 过程中的阻塞点或瓶颈

获取这些指标的一个有用工具是累积流图。我们将仔细查看累积流图，以便找到这些指标。

周期时间

对于一个价值流来说，周期时间是指工作被接受并经过整个开发过程后交付所需的时间。

我们在第四章，利用精益流动保持工作持续推进中看到，许多因素可能影响周期时间。这些因素包括过多的 WIP、大批量大小、高利用率和波动性。

另一个可能影响周期时间的因素是开发过程中是否存在浪费。这种浪费可能表现为延迟或等待时间，当工作从一个阶段移交到下一个阶段时。

定期测量周期时间可以帮助我们看到价值流交付工作的时间。周期时间的增加可以帮助我们确定根本原因是否是上述因素之一。一旦确定，可以采取纠正措施，将周期时间恢复到之前的时间长度。

交付时间

交付时间和周期时间常常互相混淆。它们之间的主要区别在于视角：交付时间是从客户的角度看，而周期时间是从价值流的角度看，是一个内部度量指标。

交付时间是指客户在请求工作后等待交付工作项的时间长度。如以下图所示，交付时间由周期时间和任何等待时间组成，等待时间是指价值流接受并开始工作的时间。

图 5.1 – 周期时间和交付时间的示意图

从前面的示意图中，我们可以通过两次改进来缩短交付时间。我们可以改善等待时间，或者我们可以改善周期时间。大多数组织都力求改善周期时间，并在此过程中改善交付时间。

WIP

到目前为止，我们应该已经熟悉 WIP 或 在制品/过程中的工作 这一概念，它指的是价值流已经开始但尚未完成的工作。我们已经看到了过多 WIP 的不良影响和后果。

WIP（在制品）在下图所示的看板上是可见的。

图 5.2 – 突出显示 WIP 的看板

在前面的示例中，我们可以数出项目并确定我们的 WIP 是六。

吞吐量

到目前为止，我们看到了单位（无论是时间还是数量）的度量。吞吐量是我们唯一关注的度量，它本质上是一个速率。换句话说，就是在给定时间单位内完成的工作量。

吞吐量基本上是指在一段固定时间内完成的工作单元数量。Scrum 实践者知道这个指标为速度（velocity）：在一个迭代周期（固定时间，一般为两周）内完成的故事点的总和。其他敏捷方法论会以其他工作单元（如故事、特性等）作为标准时间单位（如周、月）内交付的度量。

我们可以看到，周期时间与价值流的吞吐量之间存在反向关系。吞吐量越大，周期时间越短。

阻塞点和瓶颈

为了确保精益流动，我们需要找出并解决那些阻碍流动的障碍。这些障碍可能是临时的，或者是系统性的，阻止一项或多项工作在流程中继续推进。

对这些阻塞点的关注可能需要每天检查，看阻塞是否仍在发生，并在几天内没有解决阻塞时进行升级处理。

使用累积流图进行测量

累积流图是检查周期时间、交付时间、吞吐量和 WIP 的一种简便方法。你还可以通过它检查和发现过程中的瓶颈。

累积流图是展示价值流在一段时间内所处理过工作的历史图表。累积流图的 x 轴表示时间，y 轴表示工作的数量。累积流图中的每一条带状区域代表工作流中的一个步骤，这些步骤来自看板上的列。下面是一个累积流图的示例。

图 5.3 – 累积流图

通常，我们应该看到带状区域从左到右上升并扩展。代表工作流中某一过程步骤的带状区域的入口和出口线应该大致平行，表明流动正在发生。如果入口和出口线分开，形成一个大的扩展区域，那就表明该过程部分存在瓶颈。在下图中，我们可以看到这样的瓶颈。

图 5.4 – 累计流图中的瓶颈注释

让我们来看一下如何使用累计流图来衡量周期时间、在制品（WIP）和吞吐量。

使用累计流图衡量在制品（WIP）

要衡量某个价值流在某一时刻的在制品（WIP），请执行以下操作：

1. 从对应于待办事项或待做（To Do）列的带状区域与第一个进行中（In Progress）列的带状区域之间的边界开始。在我们的示例中，这是待做（To Do）带和进行中（In Progress）带之间的边界。我们只关注已经开始的工作，因此，这些工作已经超过了待做（To Do）状态。

2. 标注下这是多少工作单位。

3. 画一条垂直线穿过其他带状区域，直到你到达表示进行中（In Progress）列和表示完成（Done）列之间的边界。在我们的示例中，我们通过了进行中（In Progress）带和审查中（IN REVIEW）带。标注下这是多少工作单位。

4. 将第二个数字从第一个数字中减去。

下图展示了所描述方法的示意。

图 5.5 – 在制品（WIP）计算

请注意，您可以使用相同的方法在较小的范围内，通过观察形成目标列带状区域的两条线，来找到某一时刻进行中（In Progress）列中问题的数量。

使用累计流图衡量周期时间

要衡量周期时间，请执行以下操作：

1. 找到并标记当一个问题从表示待做（To Do）或待办事项（Backlog）列的带状区域移动时，并标记其日期。

2. 画一条水平线，直到它触及表示完成（Done）列的带状区域。标注第二个日期。

3. 将第二个日期减去第一个日期，你将得到一个问题的周期时间度量。

图 5.6 – 周期时间计算

步骤在上面的图示中有说明。

使用累计流图衡量吞吐量

累计流图中的吞吐量通过找出一条线并确定其斜率来完成：

1. 标记线上的一个点，并标注日期和问题的数量。

2. 在线上较高的位置，标注日期和问题的数量。

3. 分子将是第二个点的问题数量减去第一个点的问题数量。

4. 分母将是两个时间点之间的时间段。

以下是该计算的示例。

图 5.7 – 吞吐量计算

请注意，没有吞吐量的区域将显示为水平线。

所以，对于我们的示例，我们已经找到以下测量数据：

• 1 月 22 日，我们的待处理事项有六个问题

• 我们处理一个问题的周期时间为一个月

• 我们将问题从正在审查到已完成的吞吐量为 0.06/天

在评估了确保精益流程和及时交付解决方案的测量后，我们需要更仔细地关注确保在部署和发布前质量的存在。为此，让我们看看从预发布和生产环境中捕获的重要测量数据。

查看完整堆栈遥测数据

现在，我们将注意力从产品开发过程转移到产品本身。在整个开发过程中，我们在 CI/CD 管道中进行了测试。这些测试通过是产品按预期工作的指示。现在，随着产品在多个环境中的部署，我们希望确保其正常运行。为此，我们在这些环境中监控性能。

监控是衡量我们环境的行为。我们测量或捕获以下三种关键类型的数据：

• 日志：日志是标志着一个重要事件发生的指示。这些事件可能会被分类以确定其严重性。

• 追踪：追踪展示了应用程序内部的路径和应用程序在给定业务事务中发送的消息。也可能包括时间信息。追踪信息有助于在故障排除时确定正确的功能和性能。

• 指标：指标是系统及其组件当前状态的指示器。定期测量有助于确定长期的良好或不良趋势。

我们通过监控收集这些类型的数据文档，以回答以下关于包含系统及其组件的环境的问题：

• 安全性：是否存在安全漏洞？系统是否已被黑客攻击？

• 性能：系统是否正常运行？事务是否按预期路径进行？

• 可靠性：系统是否正常运行并且表现良好？

为了回答这些问题，监控从多个角度进行测量。以下是几个关键角度：

• 应用性能监控

• 基础设施监控

• 日志管理

• 网络监控

• 可观测性

让我们更仔细地看看这些完整堆栈遥测数据的元素。

应用性能监控

在查看应用程序是否在某个环境中正常运行时，通常会考虑两个角度：

• 用户如何感知应用程序的性能？这通常表现为用户负载或响应时间。

• 我们的资源（例如，分配的内存）被应用程序使用了多少？这通常通过与之前的状态或配置相比的容量变化来衡量。

2010 年，Gartner 开始将这些度量标准扩展为五个维度，称为 APM 概念框架。这些维度如下：

• 最终用户体验（例如，响应时间）

• 运行时应用架构（例如，垃圾回收事件）

• 商业交易

• 中间件组件（例如，数据库读取和写入）

• 应用分析

许多通过应用性能监控来衡量其性能的应用程序是基于 Web 的应用程序，具有 Web 浏览器或移动应用用户界面。之所以如此，是因为它能轻松收集跨越五个维度的度量标准。

许多监控工具，尤其是《第三章》中详细描述的工具，自动化以提高效率和质量，具有涵盖这五个维度的功能。

随着容器和微服务的日益流行，应用性能监控不得不创建准确的性能测量，以衡量容器或微服务中的表现。因此，应用性能监控与基础设施监控之间存在一些重叠。

基础设施监控

基础设施监控用于衡量整个系统或环境的资源。通常会根据以下利用率来进行识别：

• CPU 利用率

• 内存（RAM）利用率

• 存储可用性

从历史上看，基础设施监控对本地设备（如裸金属服务器）至关重要。随着云环境的发展，基础设施监控工具需要衡量动态分配的资源，这些资源将根据需求即时创建和销毁。

网络监控

网络监控衡量组织网络的性能，以发现性能下降或故障情况。通常，网络监控系统会跟踪以下领域：

• 网络资源的可用性（例如，连接正常运行时间，连接速度）

• 网络硬件状态

• 网络接口状态

网络监控的一个日益重要的领域是确保网络在完整性、可访问性和隐私方面的安全性。确保安全的网络防御措施包括以下内容：

• 网络访问 控制（NAC）

• 防火墙

• 防病毒/反恶意软件软件

• 虚拟专用 网络（VPNs）

• 邮件安全

• 应用安全

• 云安全

日志管理

所有执行监控的工具将创建所有活动和测量的日志，从关键警报到信息通知。日志管理收集这些事件并执行以下活动：

• 聚合到中央位置

• 存储

• 日志轮换与处置

• 分析

• 搜索与报告

在开发过程中以及之后，适当管理的日志对于多种目的都是必需的。这些目的包括：

• 确定测试是否通过

• 排查应用程序和环境故障

• 评估客户反馈

在收集日志、跟踪和指标数据时，这些数据很重要，但在出现问题时能够快速筛选这些数据也同样重要。为此，我们转向了可观察性。让我们讨论一下如何使用这些监控信息。

可观察性

通过监控收集日志、跟踪和指标所产生的数据海洋，现在引出了以下新的问题：

• 当出现问题时，我能否迅速在日志、跟踪和指标中找到数据，以了解根本原因并找到解决方案？

• 我是否可以使用在日志、跟踪和指标中收集的数据来预测问题何时可能发生，并尝试防止它们发生？

可观察性通过从收集数据转向理解数据本身，帮助回答这些问题，以识别其当前状态。这样做不仅仅是监控，还包括以下活动：

• 日志、跟踪和指标的分析

• 寻找日志、跟踪、指标与特定事件（如故障）之间的关联

• 通过仪表盘进行数据的可视化和探索

• 当问题发生时，发出警报和通知

可观察性通过让团队了解变更对环境产生的因果关系，帮助加强更高层次的系统思维。通过理解哪些变更对环境有益，团队可以融入正确的变更以获得更好的结果。

在确保解决方案具有足够的质量后，我们面临更大的考验：开发的解决方案是否能为客户提供足够的价值，足以让他们喜欢它？为了评估这一点，我们需要对基于结果的度量标准进行衡量。这是下一节的主题。

测量价值主张

将客观的度量应用于像价值这样的主观质量是困难的。我们能做的是通过测量客户采取的行动或客户在特定事件（如评审）期间所提供的调查反馈或想法来进行评估。

在查看价值的度量时，一些指标可能收集得太晚，导致价值流无法及时知道何时调整方向。比如损益表（Profit & Loss，P&L）或投资回报率（Return on Investment，RoI）。因此，需要其他能够作为领先指标的度量。这种收集领先指标以便做出调整或继续发展的做法，Eric Ries 在他的《精益创业》一书中称之为创新会计。

创新会计框架

Ries 将假设和学习的方法描述为创新会计框架。在这个框架中，团队会设定客户需求的假设，发展这些假设，然后进行衡量并决定后续行动。这是在三个阶段的循环中完成的，具体包括：

1. 查看当前情况，并通过最小可行产品（MVP）或开发足够的产品或功能来向客户展示并获得反馈，以验证假设。

2. 根据指标，针对 MVP 进行小范围调整。

3. 如果指标表明成功，继续优化 MVP。如果指标显示其他结果，则转向新的方向。

在创新会计框架中，收集的指标必须小心挑选，以避免成为虚荣指标。虚荣指标讲述了一个美好的故事，但没有提供有意义的见解。为了避免指标沦为虚荣指标，Ries 建议它们具备以下三个特征：

• 可操作性：这个指标是否显示出明确的因果关系？换句话说，你是否能够通过执行相同的操作来复制这个结果？

• 可访问性：价值流中的每个人是否都能访问相同的数据，且这些数据是否被所有人理解？

• 可审计性：报告是否具有可信度？

与创新会计相关的指标将依赖于价值流所开发的最终产品及其与客户的互动。我们将看看一些主要的指标集合，这些集合用于衡量价值。

海盗指标

对于许多面向最终用户客户的产品，如软件即服务（SaaS）或基于网络的产品，海盗指标提供了最佳的指导，帮助判断开发和营销努力是否取得了成果。

海盗指标由 Dave McClure 在 2007 年提出。这个名称来自于五个阶段的首字母缩写（AARRR），发音类似于海盗的叫声。这些阶段如下：

• 获取

• 激活

• 保留

• 推荐

• 收入

让我们仔细看看每个阶段。

获取

在这个阶段，指标用于确定新访客的数量。这里的指标用于捕捉以下方法吸引新用户的效果。

• 搜索引擎 优化（SEO）

• 社交媒体

• 广告

• 营销活动

激活

在激活阶段，我们查看多少新用户在首次接触产品或网站后愿意更加投入。这里的指标关注以下用户行为，作为新用户已经越过获取阶段，进入激活阶段的指示：

• 在登录页面后访问额外页面

• 查看或尝试额外的产品特性

• 在网站上花费更多时间

• 注册新闻通讯/邮件列表

• 注册免费试用

通过记录用户行为的测试结果，如 A/B 测试，来创建这些类型的指标。

留存

在这一阶段，我们希望了解能在用户首次接触后，保持他们多久。我们想要衡量以下事项是否发生：

• 返回访问网站

• 打开电子邮件新闻通讯

• 在一段时间内的重复使用产品情况（通常是第一个月）

通常，这些指标用于衡量营销邮件和活动的效果。

推荐

这一阶段看的是已建立的客户是否将消息传递给朋友或同事。确定进入此阶段的指标包括：

• 进入获取阶段的推荐人数

• 进入激活阶段的推荐人数

收入

最后，这一阶段关注那些已达到更高层次并购买了增强产品功能或网站内容的客户。我们查看以下客户是否做到了：

• 支付最低收入

• 为了使营销工作在各个阶段都能收支平衡，需要支付足够的收入。

Google HEART 框架

HEART 框架由 Kerry Rodden、Hilary Hutchinson 和 Xin Fu 在 Google 提出。它旨在衡量 Google 提供的大型 Web 应用的用户体验（UX）设计的有效性。

该框架要求团队成员评估以下维度：

• 快乐感：这些通常是主观的衡量标准，例如用户满意度、感知的易用性和推荐可能性。

• 参与度：这跟踪用户与产品及其功能的互动程度。

• 采用：这跟踪在某一时间段内的新用户数量。

• 留存：这跟踪在某一时间段内，多少用户在后续时间段仍然保持活跃。

• 任务成功：这衡量的是产品或某个特定功能的整体可用性。用户能否使用产品或功能完成预期目标？

对于每个维度，团队会设定三个特征。以下是这些特征的列表：

• 目标或任务：产品或功能的目标是什么？

• 信号：我们如何知道自己是否达成了目标？

• 指标：我们可以收集哪些指标来获取我们想要的信号？

团队通常会将各维度和特征整理成表格。以下示意图展示了一个例子。

	目标	信号	指标
快乐感
参与度
采用
留存
任务成功

表格 5.1 – Google HEART 框架

下一个指标框架旨在寻找客户需求与组织努力之间的一致性。我们现在来看看这个框架。

适用性指标

在《Fit for Purpose: How Modern Businesses Find, Satisfy, & Keep Customers》一书中，作者 David J. Anderson 和 Alexei Zheglov 描述了Fit for Purpose（F4P）框架，这是一种将客户需求（目的）与组织可能提供的产品和解决方案（适配）对齐的方法。

Anderson 和 Zheglov 识别了四种组织通常收集的指标分类，并展示了它们在框架中的位置。这些分类如下：

• 适配度标准

• 一般健康指标

• 改进驱动因素

• 虚荣指标

现在让我们来看看每个类别。

适配度标准

适配度标准描述了客户用来判断您的产品或解决方案是否符合他们需求或目的的度量标准。这些适配度标准将基于以下几个维度：

• 设计

• 实施

• 服务交付

客户将使用阈值来评估适配度标准。第一个是最低接受水平，低于该水平他们会认为产品或服务未能满足他们的需求。第二个阈值是卓越服务或在所有三个维度上超出预期的情况。

许多组织从这些指标作为适配度标准开始，直到他们对客户或市场细分有更多了解：

• 交付时间及其可预测性。

• 质量及其可预测性。

• 安全，包括符合相关法律和标准（如果处于受监管行业）。

• 价格。需要注意的是，价格通常不是一个独立变量。换句话说，价格可能会为了其他适配度标准的更高期望而被牺牲。

客户对其适配度标准的反馈通常通过 F4P 调查获取，调查问客户他们寻求的三个目的是什么，产品或服务在多大程度上满足了这些目的，以及其他备注。

一般健康指标

一般健康指标是组织内部的度量标准。它们可用于判断是否适合改进客户用来评估组织是否符合其目标的一个或多个维度（设计、实施、服务旅程）。虽然这些是重要的指标，应该收集并分析，但在判断是否创造了足够的价值以至于客户会选择该产品时，它们是次要的，重要性低于适配度标准。

一般健康指标的例子包括价值流的周期时间、Scrum 团队的速度、运营团队的恢复/恢复平均时间。

改进驱动因素

改进驱动因素是组织用于改进目的的度量标准。它们是组织采用特定行为的衡量标准。通常与之相关联的是目标，当目标实现时，这个指标应该转化为一般健康指标。

一个改进驱动因素的例子可能是自动化测试的数量。这个指标旨在鼓励注重测试自动化。

虚荣指标

我们之前在谈论创新会计时讨论过虚荣度量。许多组织确实会收集虚荣度量，这些度量能够提供情感上的提升。但就像含有空洞热量的糖果或垃圾食品一样，这些度量并没有真正揭示组织的行动是否为客户带来了他们想要的真实价值。

一个例子是一个组织的网站产生的总访问量。在没有深入了解细节的情况下，这是一个始终会增长的数字，且与组织在市场营销或搜索引擎优化方面的任何努力无关。

净推荐值

净推荐值是客户支持中常用的一个度量。通常以一个单一调查问题的形式出现：你有多大可能推荐这个产品或服务给朋友或同事？这个问题后面会有 1-10 的响应范围。然后，用户根据回答将受访者分为以下几类：

• 推动者（9-10）

• 中立者（7-8）

• 反对者（1-6）

然后通过查看推动者和反对者的百分比，计算得出分数，并将反对者的百分比从推动者的百分比中减去。然后将这个百分比表示为一个整数。

我们现在已经完成了对用于衡量我们为客户提供的价值的流行度量框架的探讨。这些大多涉及与客户的直接接触，如果这种接触能够频繁进行，会更有益。

总结

在本章中，我们查看了在开发过程和之后进行的度量。我们发现必须在三个领域进行度量，以确定我们的价值流是否得到优化，并朝着价值方向运作。

第一个衡量领域检查了团队和价值流，看看它们是否朝着优化流程的方向努力。定义并使用累积流图来确定周期时间、交付时间、WIP 和产出等度量。

第二个衡量领域检查了应用程序所在的环境。可用工具确保应用程序及其环境资源的正常运行，例如基础设施，包括存储和网络。

第三个衡量领域是解决方案所提供的价值。度量框架，例如海盗指标（AARRR）、谷歌 HEART 框架和 F4P 指标，关注客户的行为和想法，以确定所开发的解决方案是否符合客户期望，提供价值。

在下一章中，我们将通过查看恢复来完成对 CALMR 的检查。我们将探讨价值流如何使用方法来减少生产中失败的风险，并且如果发生问题，如何快速解决生产中的问题。

问题

通过回答这些问题来测试你对本章概念的理解。

1. 交付时间衡量等待时间和 ______________？

   1. 产出

   2. 阻碍因素

   3. 周期时间

   4. 进行中

2. 在衡量吞吐量和周期时间时，如果周期时间减少，吞吐量会发生什么变化？

   1. 吞吐量上升

   2. 吞吐量下降

   3. 吞吐量保持不变

   4. 吞吐量先上升，再下降

3. WIP 在累积流图中是如何表现的？

   1. 水平线

   2. 垂直线

   3. 上升坡度

   4. 下降坡度

4. 基础设施监控需要哪些度量（选择 2 个）？

   1. 垃圾回收率

   2. CPU 利用率

   3. 响应率

   4. 存储可用性

   5. 网络可用性

5. 在适用框架中，客户看重哪种类型的度量？

   1. 适用标准

   2. 一般健康指标

   3. 改进驱动因素

   4. 虚荣指标

进一步阅读

• www.gartner.com/DisplayDocument?id=1436734&ref=g_sitelink – 一份 Gartner 报告，描述了 APM 概念框架。

• 500hats.typepad.com/500blogs/2007/09/startup-metrics.html – Dave McClure 的博客页面，描述了海盗指标（AARRR）。

• research.google/pubs/pub36299/ – Kerry Rodden、Hilary Hutchinson 和 Xin Fu 提交的论文，概述了 Google 的 HEART 框架。

• 《精益创业》 由 Eric Ries 编著 - 精益创业周期的探讨。周期的一部分包括对创新会计的讨论，以及哪些度量是真正有益的，而不是虚荣指标。

• 《Fit for Purpose: How Modern Businesses Find, Satisfy, & Keep Customers》 由 David J. Anderson 和 Alexei Zheglov 编著 - 适用度度量的探讨。

第六章：从生产失败中恢复

我们生活在一个不完美的世界。我们首先看到漏洞逃入我们的生产环境。然后，我们可能会发现，当我们开始向 DevOps 实践过渡时，我们在理解上的一些空白会影响我们在生产环境中的交付方式。随着这些问题得到解决，我们可能会遇到其他超出我们控制范围的问题。我们能做些什么呢？

在本章中，我们将探讨如何减轻和处理生产环境中发生的故障。我们将研究以下主题：

• 生产环境中的错误成本

• 尽可能防止错误的发生

• 通过混沌工程进行故障演练

• 使用事件管理流程解决生产中的问题

• 通过回滚或前移修复来解决生产失败

从失败中学习

生产失败可能在产品开发过程中的任何阶段发生，从首次部署到支持成熟的产品。当这些生产失败发生时，根据其影响，可能会对客户所看到的价值产生不利影响，并有可能毁掉企业的声誉。

通常，我们不会在生产失败发生之前看到这些失败带来的教训，直到失败发生后，或者通过阅读其他组织（甚至竞争对手！）发生类似失败的情况。

我们将研究一些著名的生产失败案例，希望通过事后回顾来汲取经验教训。以下是一些示例：

• healthcare.gov 在 2013 年的上线

• 2022 年 Atlassian 云服务中断

其他的教训将来自本章的其他部分。

healthcare.gov（2013 年）

2010 年，美国通过了《患者保护与平价医疗法案》。该法案的关键部分，通称为奥巴马医保，是通过一个名为healthcare.gov的网站平台，让个人通过多个市场找到并注册负担得起的健康保险计划。该平台要求在 2013 年 10 月 1 日上线。

healthcare.gov在那一天上线后立刻遇到了问题。上线初期，网站需求为 250,000 次，是预期的五倍，导致网站在前两小时内崩溃。到第一天结束时，只有六个用户成功提交了健康保险计划的申请。

一场大规模的故障排除工作随之展开，最终使得网站能够承载 35,000 个并发用户，并在 2013 年 12 月注册期结束前为 120 万用户登记了健康保险计划。

关于healthcare.gov灾难的几份报告之一由 Dr. Gwanhoo Lee 和 Justin Brumer 编写。在报告中（见www.businessofgovernment.org/sites/default/files/Viewpoints%20Dr%20Gwanhoo%20Lee.pdf），他们具体指出了这样一个庞大工程的挑战，包括以下几点：

• 在有限时间内开发复杂的 IT 系统

• 政策问题导致实施过程中的不确定性

• 高风险的合同，且时间有限

• 缺乏领导力

Lee 和 Brumer 还指出了从门户网站设计和开发的早期阶段开始的一系列失误，这些失误最终导致了项目的失败。包括以下几点：

• 政府政策与门户网站技术实施之间缺乏对齐

• 不充分的需求分析

• 未能识别和减轻风险

• 缺乏领导力

• 对坏消息的漠视

• 僵化的组织文化

• 对项目管理基础知识的忽视

修复 healthcare.gov

在healthcare.gov的首次灾难性发布后，其中一项举措就是 Tech Surge，即由硅谷软件开发人员接管，重构了healthcare.gov网站的主要部分。Tech Surge 中的团队作为小型团队以初创公司心态运作，习惯于使用敏捷方法，进行紧密合作，使用 DevOps 工具如 New Relic，并利用云基础设施。

Tech Surge 的一个分支是由 Loren Yu 和 Kalvin Wange 领导的一小组程序员，他们被称为Marketplace Lite(MPL)。他们最初是作为 Tech Surge 的一部分，和医疗保险和医疗补助服务中心(CMS)的现有团队一起工作，向他们展示新的工作方法，例如通过聊天而非电子邮件进行协作，同时重写网站的登录和注册新计划部分。

MPL 继续在healthcare.gov上工作，因为许多其他开发者的合同到期了，Tech Surge 的其他开发者也在继续合作。它继续与 CMS 一起改进系统测试，并逐步推出修复措施，正如当时政府问责局(GAO)报告中所示。这些努力开始取得了显著成果。MPL 重新编写的其中一部分，即用于注册新医疗保险的工具App 2.0，仅限呼叫中心进行软启动，但它取得了极大的成功，成为了注册新申请的主要工具，适用于那些有简单病史的人群。

MPL 和技术冲击小组的工作，以及随后在进一步的注册期间healthcare.gov的成功推出，为敏捷和 DevOps 思维及实践提供了一个试验场。18F 等机构和美国数字服务局接过接力棒，开始指导其他联邦机构将敏捷和 DevOps 应用于技术项目。

Atlassian 云故障（2022）

2022 年 4 月 5 日，Atlassian 超过 200,000 个客户组织中的 775 个失去了对 Atlassian 云站点的访问，这些站点服务了如 Jira 服务管理、Confluence、Statuspage 和 Opsgenie 等应用程序。许多客户在服务恢复之前，已经无法访问其站点长达 14 天，直到 4 月 18 日剩余的站点恢复服务。

站点故障的根本原因追溯到 Atlassian 用来删除旧版 Insight 实例的脚本，Insight 是 Jira 的一个流行独立插件，Atlassian 在 2021 年收购了该插件。Insight 最终被捆绑进 Jira 服务管理中，但遗留的应用痕迹仍然存在，需要被删除。

出现了沟通错误，负责运行脚本的团队接收到的是站点 ID 列表作为脚本的输入，而不是 Insight 实例 ID 列表。结果是站点被立即删除。

Atlassian 的云架构由多个租户服务组成，这些服务处理多个客户的应用程序。全面恢复服务将会影响那些站点未被删除的客户。Atlassian 知道如何恢复单个站点，但从未预料到需要恢复当前面对的大量站点。Atlassian 开始恢复客户站点。恢复大量站点需要 48 小时。手动恢复所有缺失的站点将需要数周时间；显然，Atlassian 需要实现自动化。

自动化工作是为了帮助 Atlassian 找到一种方法，以便一次性恢复多个站点。自动化从 4 月 9 日开始运行，成功地在 12 小时内恢复了一个站点。到 4 月 18 日最后一个站点恢复时，大约 47%的站点已经通过自动化得到了恢复。

更大的问题是与受影响客户的沟通。Atlassian 最初是通过一个客户支持票得知这一事件的，但当时并没有立即意识到受影响的客户总数。这是因为删除站点时，也删除了包含客户信息的元数据，而这些信息通常会被客户用于创建支持票。恢复丢失的客户元数据对于客户通知非常重要。

Atlassian 无法直接联系受影响客户，导致了一个重大沟通问题的加剧。那些未被 Atlassian 联系的客户开始在社交媒体平台（如 Twitter 和 Reddit）上寻求有关事件的消息。Atlassian 于 4 月 7 日发布了一条通用推文。Atlassian 的首席技术官 Sri Viswanath 于 4 月 12 日发布了更详细的博文。在事件解决后，事后复盘报告于 4 月 29 日公开发布。

来自 Atlassian 停机事件的教训

Atlassian 的停机事件在技术和客户服务方面都带来了挑战。事后复盘总结了四个主要的学习点，Atlassian 必须改进这些方面，以防止类似的停机事件发生。这些教训包括：

• 将删除生产数据的过程更改为软删除，这样更容易恢复，并且数据只有在经过一定时间后才会被删除。

• 针对多个站点、多个产品的数据，针对更大范围受影响客户的具体流程。

• 考虑大规模事件的事故管理。Atlassian 为某个客户的网站制定了流程。现在，它需要考虑影响大量客户的大规模事故。

• 在事故发生期间改善客户沟通。Atlassian 在掌握事故原因和纠正措施后才开始沟通。这种延迟沟通让事故在社交媒体上扩展开来。

但我们也能从中汲取更广泛的教训。生产中的故障可以发生在从第一次部署到产品生命周期的任何阶段。无论是刚开始使用 Agile 和 DevOps 的公司，还是像 Atlassian 这样的公司，在使用 Agile 和 DevOps 取得成功之后，都有可能发生故障。对于这些公司来说，处理生产故障的关键在于确保流程能尽可能根除故障，进行故障演练以确定最佳流程，并在发生故障时建立合适的处理流程。

为了帮助我们应对这一挑战，我们转向了一个不断发展的学科，称为站点可靠性工程（SRE）。这一学科由 Google 的 Ben Treynor Sloss 创建，最初目的是将软件开发方法应用于系统管理。SRE 最初被视为一种混合方法，利用开发团队用于传统系统管理操作的方法，它已经发展成 DevOps 中的一个独立分支，确保在自动化部署之后，系统操作的持续可靠性。

第一步是规划和预防。我们从查看 SRE 用于防止生产故障的保障措施开始。

预防——拉动安灯（Andon）绳。

安灯绳在精益思想中占有特殊的地位。作为丰田生产系统的一部分，如果你怀疑生产线上有问题，你可以拉动围绕生产线的安灯绳，这会停止生产线。人们会赶到安灯绳拉动的地方，查看缺陷并确定首先如何修复缺陷，然后采取哪些步骤防止未来再次发生类似问题。

丰田生产系统的创始人大野耐一通过安灯绳实践自働化，赋予每个人停止工作来检查和实施持续改进的权力。

对于站点可靠性工程师，以下的理念和原则被用作实施安灯绳并确保持续改进的方法：

• 通过查看服务级别指标（SLI）、服务级别目标（SLO）和误差预算来规划风险容忍度

• 通过发布工程执行发布标准

• 与发布协调工程合作进行产品发布

让我们更详细地探讨这些理念。

SLI、SLO 和误差预算

许多人熟悉服务级别协议（SLA）的概念，即如果服务未达到可用性或响应性的门槛，供应商将需要支付约定的性能水平，通常以信用额度的形式进行补偿。

如果我们查看 SLA 期望实现或维持的目标或阈值，这称为 SLO。一般来说，SLO 有三个部分：

1. 要测量的质量/组件

2. 测量周期

3. 质量必须达到的要求阈值，通常以期望值或范围的形式写出

要测量的质量或组件被称为 SLI。常见的 SLI 包括以下几种：

• 延迟

• 吞吐量

• 可用性

• 错误率

对于每个 SLO，在测量周期内未达到阈值的时间称为误差预算。通过密切监控误差预算，SRE 可以评估风险是否可接受，以便推出新版本。如果误差预算几乎耗尽，SRE 可能会决定将焦点从功能开发转向更多的技术工作，例如增强可恢复性和可靠性的支持工具。

团队通常希望了解误差预算，以可允许的时间为单位。以下表格可能会提供有关每月和每年最大可允许误差的指导：

SLO 百分比	每月允许 误差预算	每年允许 误差预算
99%（1%误差范围）	7 小时 18 分钟	87 小时 39 分钟
99.5%（0.5%误差范围）	3 小时 39 分钟	43 小时 49 分钟 45 秒
99.9%（0.1%误差范围）	43 分钟 50 秒	8 小时 45 分钟 57 秒
99.95%（0.05%误差范围）	21 分钟 54 秒	4 小时 22 分钟 48 秒
99.99%（0.01% 误差范围）	4 分 23 秒	52 分 35 秒

表 6.1 – 按允许的每月和每年时间划分的误差预算

实施 SLOs 的过程通常从评估产品或服务开始。从那里，查看构成产品的组件或微服务：哪些部分如果不可用，会导致客户的不满？

在发现对客户满意度至关重要的组件后，选择那些用于捕获和设定目标（SLOs）的测量指标（SLIs），确保这些测量指标能真实反映潜在问题，并且目标是现实可达的（任何测量指标的 100% 都是无法实现的）。从一小组 SLOs 开始，将这些 SLOs 告诉客户，让他们理解 SLOs 在提升产品质量和期望方面的作用。

SLIs、SLOs 和误差预算应作为政策文档，但该政策是可以调整和改变的。经过一段时间后，重新评估 SLIs、SLOs 和误差预算，检查这些测量指标是否有效，并根据需要修订 SLIs 和 SLOs。

发布工程

为了确保 SLOs 得以保持，站点可靠性工程师需要确保发布给客户的任何内容都是可靠的，且不会导致服务中断。为此，他们与软件工程师合作，确保发布的内容风险较低。

Google 将这种协作称为发布工程。SRE 的这一方面遵循以下原则：

• 自助服务

• 高速度

• 封闭构建

• 政策/程序执行

现在让我们来看一下发布工程哲学的这四个部分。

通过自助服务模型实现发布自主权

为了实现敏捷，参与的团队必须是独立且自我管理的。发布工程过程允许团队自行决定发布节奏和实际发布的时间。自动化有助于团队在需要时按需发布。

追求高速度

如果团队选择更频繁地发布，通常是以更小批次的高测试覆盖率代码进行发布。更频繁的小批量发布降低了中断的风险。如果你有较大的误差预算，这尤其有帮助。

确保封闭构建

我们希望在构建和发布过程中保持一致性和可重复性。构建输出应与创建者无关，确保输出相同。这意味着，从测试到生产的依赖项和工具（如库和编译器）的版本应保持标准化。

当然，如果生产环境中出现问题，一种有用的故障排除策略是所谓的 cherry-picking（挑拣），团队从最后一个已知的 良好 生产版本开始，从版本控制中获取并逐个插入每个更改，直到发现问题。强有力的版本控制流程确保构建是封闭的，并且支持挑拣操作。

严格执行政策和程序

需要访问控制标准的自动发布过程，以确保在正确的构建机器上使用正确的源创建构建。关键是避免添加本地编辑或依赖项，只使用存储在版本控制中的经过验证的代码。

我们讨论的这四个原则实际上在处理发布过程中的以下部分时得到了应用：

• 持续集成/持续 部署 (CI/CD)

• 配置管理

我们第一次看到这些部分作为 CI/CD 管道的自动化实现出现在 第三章， 提升效率与质量的自动化。现在，让我们看看如何将这些过程与自动化联系起来。

CI/CD

发布过程从提交版本控制开始。这会启动构建过程，自动执行不同的测试，具体取决于分支。发布分支会运行单元测试以及适用的系统和功能测试。

测试通过后，构建会被标记，以便跟踪构建日期、依赖项、目标环境和修订号。

配置管理

配置管理工具使用的文件存储在版本控制中。配置文件的版本与发布版本一起记录，作为审计轨迹的一部分，以便我们知道哪个版本的配置文件与哪个版本的发布相关联。

发布协调工程

向客户发布新产品或功能时，可能会比现有产品的迭代发布面临更高的期望。为了促进新服务的发布，谷歌在 SRE 内创建了一个特殊的咨询职能，称为 发布协调工程 (LCE)。

LCE 的工程师执行多个职能，旨在确保发布过程顺利进行。这些职能包括以下内容：

• 审核产品或服务以确保可靠性

• 协调多个参与发布的团队

• 确保完成与发布相关的技术任务

• 确认发布是 安全的

• 培训开发人员与新服务的集成

为了帮助发布协调工程师确保发布顺利进行，创建了一个发布检查清单。根据产品的不同，工程师会定制该检查清单，添加或删除以下检查项：

• 共享架构和依赖

• 集成

• 容量规划

• 可能的故障模式

• 客户行为

• 流程/自动化

• 开发过程

• 外部依赖

• 发布规划

我们已经看到 SRE 使用的技术和流程，以确保产品发布或代码发布已准备就绪。我们已通过 SLIs、SLOs 和错误预算看到了容错能力。但我们是否知道当发生故障时，SRE 是否已做好准备？

判断的一种方式是模拟故障并观察反应。这是 SRE 使用的另一个工具，称为混沌工程。让我们看看其中涉及的内容。

准备工作 – 混沌工程

2015 年 9 月 20 日，亚马逊网络服务（AWS）在美国东部 1 区（US-EAST-1）发生了停机事故，超过 20 个服务出现故障。这些服务影响了许多大公司如 Tinder、Airbnb、IMDb 的应用，以及亚马逊自己的服务，如 Alexa。

在 AWS 发生故障期间，能够避免问题并保持完全运行的客户之一是 Netflix，这家流媒体服务公司。它能够做到这一点，因为它创建了一系列名为猩猩军团的工具，相关内容可以在netflixtechblog.com/the-netflix-simian-army-16e57fbab116的博客文章中找到，这些工具模拟了 AWS 可能出现的问题，使得 Netflix 的工程师能够设计出增强系统弹性的解决方案。

在多次 AWS 故障中，猩猩军团证明了它的价值，使 Netflix 能够继续提供服务。很快，像 Google 这样的其他公司也开始希望应用相同的技术。这股支持浪潮最终促成了混沌工程学科的诞生。

让我们更深入地了解混沌工程的以下几个方面：

• 原则

• 实验

混沌工程原则

混沌工程的关键是进行生产环境中的实验。尽管在生产环境中进行可靠性实验似乎充满风险，但这种风险通过对系统弹性的信心得到了缓解。

为了引导信心，混沌工程从以下原则开始：

• 基于生产环境稳态行为构建假设

• 创建模拟现实世界事件的变量

• 在生产环境中运行实验

• 自动化实验

• 最小化实验的后果

让我们详细讨论这些原则。

基于稳态行为进行实验

在设计实验时，我们真正想要关注的是系统的输出，而不是系统中各个组件的表现。这些输出形成了环境在稳态下行为的基础。混沌工程的重点在于验证行为，而不是验证单个组件的功能。

那些将混沌工程视为 SRE（站点可靠性工程）关键部分的成熟组织知道，这种稳态行为通常构成了 SLO（服务水平目标）的基础。

创建模拟现实世界事件的变量

基于已知的稳态行为，我们考虑现实世界中可能发生的假设场景。你考虑的每个事件都成为一个变量。

Netflix 的“猩猩军团”中的一个著名工具，Chaos Monkey，基于 AWS 中虚拟服务器节点不可用的事件。因此，它只测试这一条件。

在生产环境中运行实验

在预备环境或类似生产环境中运行实验是有益的，但最终，你需要在生产环境中运行实验，以查看它对实际流量处理的影响。

在 Netflix，Chaos Monkey 每天在生产环境中运行。它会查看每个正在运行的集群，并随机停用其中一个节点。

自动化实验

从混沌工程实验中学习的好处，只有当实验持续且频繁地运行时，才能显现出来。为了实现这一点，自动化实验是必要的。

Chaos Monkey 在初次推出时并未受到 Netflix 工程师的欢迎。每天，这个程序会故意在生产环境中制造错误，这让他们感到不太舒服，但它确实不断暴露出实例可能消失的问题。有了这个问题，工程师们就有了找到解决方案并增强系统弹性的任务。

最小化后果

因为你是在生产环境中进行实验，所以也有可能影响到同样使用该环境的客户。你的任务是确保实验带来的后果得到最小化。

Chaos Monkey 每天运行一次，但仅限于工作时间。这是为了确保如果发现对生产环境的任何负面影响，能够在大多数工程师在场时发生，而不是在凌晨 3 点等非工作时间，这时只有少数工作人员值班。

在这些原则的基础上，接下来让我们应用它们并探讨创建实验。

在混沌工程中运行实验

在生产环境中进行实验需要规划和开发流程。实验的目标是找出那些可以增强弹性的薄弱环节，以确保 SLO（服务水平目标）得到保持。目标不是破坏 系统。

在《混沌工程：实践中的系统弹性》一书中，理查德·克劳利写了一个章节，讲述了为 Slack 创建灾难剧院流程的内容。他概述了以下步骤：

1. 确保有一个安全网到位。

2. 准备演练。

3. 执行演练。

4. 对演练结果进行总结。

现在让我们详细检查每个步骤。

确保环境已准备好应对混沌

混沌工程的目标是找出系统弹性中的弱点，而不是关闭环境。如果现有环境没有容错能力，那么进行实验是没有意义的。

确保服务有备用容量。这个备用容量应该容易上线。

一旦备用容量和资源被识别并分配好，制定一个计划，允许移除故障资源并自动用备用容量进行替换。

准备演练

对于克劳利来说，一个演练从一个问题开始：哪个关键组件或服务会失败，从而影响系统的弹性？这成为演练的基础。

Crowley 然后以此为基础，展开工作，扩展为在开发、预生产和生产环境中运行的演习。他制定了一个检查清单，确保以下每个项目都在演习中得到满足：

• 描述将要故障的服务器或服务，包括故障模式，以及如何模拟故障。

• 确定开发和生产环境中的服务器或服务，并确认在开发环境中模拟的方法是否可行。

• 确定如何检测故障。是否会生成警报并显示在仪表板上？是否会生成日志？如果无法想象如何检测它，仍然值得执行演习以确定检测故障的方法。

• 确定冗余和缓解措施，这些措施应当能够消除或减少故障的影响。同时，确定在故障发生时应运行的操作手册。

• 确定应该邀请哪些相关人员为演习提供他们的知识。这些人员也可能是演习发生时的第一响应者。

准备工作最终在与相关人员的会议中完成，讨论演习所需的后勤工作。当所有准备工作就绪时，便是时候开始演习了。

运行演习

演习应当在执行前广泛告知所有参与人员。毕竟，他们将参与这次演习，目标是创建一个更具弹性的环境。

Crowley 执行演习时使用以下检查清单：

1. 确保每个人都知道演习正在被录音。如果每个人都同意，可以进行录音。

2. 审查在准备阶段创建的计划，并根据需要进行调整。

3. 在开发环境中宣布演习开始。

4. 在开发环境中制造故障。记录时间戳。

5. 查看是否为故障生成了警报和日志。记录时间戳。

6. 如果有自动恢复步骤，给它们一些时间来执行。

7. 如果使用了操作手册，按照操作手册的指引解决开发环境中的故障。记录时间戳以及是否有任何偏离操作手册的情况。

8. 确定是否有“开始/不开始”决策，以便在生产环境中复制此故障。

9. 在生产环境中宣布演习开始。

10. 在生产环境中制造故障。记录时间戳。

11. 查看是否为故障生成了警报和日志。记录时间戳。

12. 如果有自动恢复步骤，给它们一些时间来执行。

13. 如果使用了操作手册，按照操作手册的指引解决生产环境中的故障。记录时间戳以及是否有任何偏离操作手册的情况。

14. 宣布演习结束并宣布“全清”。

15. 进行总结。

16. 如果有录音，将其分发。

演习完成后，演习的关键部分是进行总结，这一过程从宣布演习结束开始。我们来看看如何创建一个学习总结。

事后总结以便学习

Crowley 建议在练习体验仍然新鲜时进行事后总结。在总结过程中，只呈现事实，并总结系统表现得如何（或未能表现）。

Crowley 提出了以下启动问题，以帮助展示学到的内容。这些问题可以作为模板使用：

• 事件检测和恢复的时间是多少？

• 当我们在生产环境中运行练习时，最终用户注意到了吗？我们如何知道？有没有解决方案可以让答案是没有？

• 哪些恢复步骤可以自动化？

• 我们的盲点在哪里？

• 我们需要对仪表板和运行手册做哪些更改？

• 我们需要在哪些方面进行更多练习？

• 如果这种情况意外发生，我们的值班工程师该怎么做？

练习的结果和总结中的回答可以形成接下来增强系统韧性的建议。可以重复进行练习，以确保系统能正确识别并解决故障。

灾难剧场可以作为执行混乱工程练习的有效框架。该练习的灵活性取决于你的系统已经有多强的韧性。

即使定期进行混乱工程练习，生产环境中仍然可能发生不良事件，影响到客户。让我们看看如何通过事件管理来解决这些生产问题。

问题解决 – 促成恢复

对于 SRE 来说，健全的事件管理流程在生产环境出现问题时非常重要。一个好的事件管理流程能够帮助你达成这些必要的目标，通常被称为三大 C：

• 协调响应

• 沟通事件参与者、组织中的其他人员以及外部感兴趣方之间的互动

• 控制事件响应

Google 在 Andrew Stribblehill 所写的《站点可靠性工程：Google 如何运营生产系统》的管理事件章节中，识别了他们的事件指挥系统所需的元素。这些元素包括以下内容：

• 明确的事件管理角色

• 一个（虚拟或物理的）指挥所

• 一个实时更新的事件状态文档

• 清晰的交接给他人

让我们详细看看这些元素。

事件管理角色

一旦确认你所面对的确实是一起事件，就应该组建一个团队来处理问题，并共享信息，直到事件解决。团队会有明确的角色，以便正确协调。让我们详细了解这些角色。

事件指挥官

事件指挥官可能最初是报告事件的人。事件指挥官通过将必要的角色委派给其他人来体现三大 C。任何未被委派的角色都假定属于事件指挥官。

事件指挥官将与其他响应人员合作以解决事件。如果有任何障碍，事件指挥官将促使其去除。

运营负责人

运营负责人将与事件指挥官一起工作。他们将运行解决事件所需的工具。只有运营负责人可以对系统进行更改。

通讯负责人

通讯负责人是事件及其响应的对外代表。他们负责与外部团体和利益相关者的沟通。他们还可能确保事件文档保持更新。

事件规划/后勤

规划和后勤将与运营人员一起解决事件的长期问题，如安排角色间的交接、订餐和在缺陷跟踪系统中输入票证。他们还将跟踪系统如何偏离常态，以便在事件解决时恢复正常。

事件指挥中心

一个战情室是所有事件响应团队成员集中合作解决方案的地方。这里应该是外部人员可以与事件指挥官和其他事件响应团队成员会面的地方。

由于分布式开发，这些指挥中心通常是虚拟的，而不是一个实体房间。互联网中继聊天（IRC）聊天室或 Slack 渠道可以作为集中在一个地方的媒介。

事件状态文档

事件指挥官的主要责任是记录与事件相关的所有活动和信息在事件状态文档中。这是一个动态文档，旨在频繁更新。一个 Wiki 页面可能足够，但通常它一次只能由一个人编辑。

适当的替代方案可能是 Confluence 页面或一个共享在公共 Google Drive 或 Microsoft SharePoint 文件夹中的文档。

Google 维护了一个事件状态文档模板，可以作为起点使用。

设置清晰的交接

正如我们在本章中看到的 Atlassian 事件，事件可能持续几天甚至几周。因此，角色的交接至关重要，特别是事件指挥官。必须确保每个人都清楚交接已发生，以最小化任何混淆。

在事件处理中，可能有一些有助于解决问题的行动，包括回滚或前进修复。如果根本原因被诊断为最近做出的新更改，这些方法可能有效。我们将在下一部分中详细介绍这些替代方案。

坚持不懈 – 回滚或前进修复

如果生产故障的原因是一个新更改，快速解决方案可能包括恢复到更改之前的系统状态，或者如果找到了修复方法，立即通过 CI/CD 流水线运行并立即部署。

一些回滚或修复推进的方法包括以下几种。让我们详细了解它们。

使用蓝绿部署回滚

蓝绿部署利用两个生产环境：一个是在线环境，另一个是备用环境。在线环境是客户使用的环境，而备用环境则作为备份。更改在备用环境中进行，然后将备用环境切换为在线环境。你可以看到这种部署方式的示意图：

图 6.1 – 蓝绿部署：环境切换

正如前面的图示所示，两个环境仍然存在，但只有一个环境能接收客户流量。这个安排将持续，直到更改部署到备用环境中，或者需要回滚，如下图所示：

图 6.2 – 蓝绿部署：回滚

蓝绿部署在环境是无状态时效果最佳——也就是说，不需要考虑数据的状态。当数据的状态需要在数据库或易失性存储等工件中考虑时，就会出现复杂情况。

使用特性标志回滚

我们在第三章，《为了效率和质量的自动化》中看到，特性标志允许变更传播到部署中，但在标志被开启之前，变更是不可见的。以同样的方式，如果新特性是生产故障的根本原因，可以将标志关闭，直到新特性被修复，如下图所示：

图 6.3 – 使用特性标志回滚

使用特性标志回滚可以快速恢复到以前的行为，而不需要对源代码或配置做出广泛的修改。

使用 CI/CD 流水线推进

向前推进或修复推进是通过开发错误修复来解决事件的方法，允许其通过 CI/CD 流水线，从而能够部署到生产环境中。这是一种有效的解决事件的方法，特别是当更改较小的时候。

修复推进应被视为最后的手段。如果修复推进是唯一可行的选择，可能是因为你的产品架构与依赖组件耦合过于紧密。例如，如果新版本依赖于数据库架构的更改，并且在发现生产故障之前，客户数据已经存储在新的表中，那么在不丢失客户数据的情况下可能无法回滚。

打算通过滚动更新发布的变更应遵循与常规发布相同的流程。快速修复可能不遵循完整流程，也可能没有同样的审查和测试覆盖，可能会通过在系统其他部分引入错误，增加技术债务。

总结

本章我们探讨了生产环境出现问题时的应对。我们通过两个事件开始了本章内容：2013 年healthcare.gov的初始发布和 2022 年 Atlassian 云宕机。我们从这两个事件中学到预防和规划未来事件的重要性。

接下来，我们通过查看 SRE 学科的重要部分，探索了准备工作的方式。SRE 通过设定 SLI 和 SLO 来开始这一过程，从而让我们通过错误预算了解风险的容忍度。SRE 还关注发布新变更和推出新产品的过程。

我们通过混沌工程学科练习灾难应对。我们理解了这一学科背后的原则，并学会了如何通过灾难剧场（Disasterpiece Theater）过程来设计实验。

最终，即使有充分的准备，生产故障仍然会发生。我们分析了 Google 事件管理过程中关键部分，并研究了处理事件的技术，如回滚或前向修复。

至此，我们已完成第一部分：方法论 – 通过 CALMR 看 SAFe**®和 DevOps。接下来，我们将在第二部分：实施 – 向价值流迈进*中，探讨 DevOps 的一个关键活动——价值流管理。

问题

通过回答这些问题，测试你对本章概念的理解。

1. 什么是 SLI 的例子？

   1. 速度

   2. 可用性

   3. 周期时间

   4. 可扩展性

2. 如果你的组织设置了 99%可用性的 SLO，并且每月的可接受停机时间是 7.2 小时，那么你的错误预算是多少？

   1. 0.072 小时/月

   2. 0.72 小时/月

   3. 7.2 小时/月

   4. 72 小时/月

3. 以下哪个不是发布工程的原则？

   1. 自服务模型

   2. 高速

   3. 依赖构建

   4. 政策/程序的执行

4. 是哪个公司创造了混沌猴和类人猿军团？

   1. Netflix

   2. Google

   3. 亚马逊

   4. 苹果

5. 以下哪些是混沌工程的原则（选择两个）？

   1. 去中心化决策

   2. 围绕价值组织

   3. 最小化实验的后果

   4. 在生产环境中运行实验

   5. 应用系统思维

6. 在 Google 的事件指挥系统中，哪个角色是事件状态文档的主要作者？

   1. 运维负责人

   2. 事件指挥官

   3. 通讯负责人

   4. 规划/物流

深度阅读

这里有一些资源，供您进一步探索这个话题：

• www.businessofgovernment.org/sites/default/files/Viewpoints%20Dr%20Gwanhoo%20Lee.pdf——管理关键任务政府软件项目：来自 Healthcare.gov 项目的经验教训，作者为 Dr. Gwanhoo Lee 和 Justin Brumer。深入探讨了 Healthcare.gov 灾难的根本原因。

• www.theatlantic.com/technology/archive/2015/07/the-secret-startup-saved-healthcare-gov-the-worst-website-in-america/397784/——关于 Tech Surge 和 MPL 特别努力的报道。

• www.gao.gov/assets/gao-15-238.pdf——GAO 报告，描述了 healthcare.gov 启动初期存在的问题以及朝着所需修复的进展。

• oig.hhs.gov/oei/reports/oei-06-14-00350.pdf——关于 healthcare.gov 初始启动的案例研究，以及 Tech Surge 带来的变革，这些变革促成了后续版本的成功发布。由 卫生与公共服务部（HHS）监察长办公室（OIG）创建。

• www.atlassian.com/engineering/post-incident-review-april-2022-outage——由现任 CTO Sri Viswanath 撰写的 Atlassian 云服务中断后的事后回顾。

• 站点可靠性工程：谷歌如何运行生产系统，编辑 Betsy Beyer、Chris Jones、Jennifer Petoff 和 Niall Richard Murphy——关于 SRE 的参考书，详细介绍了 SRE 主题的原则和论文。

• medium.com/kudos-engineering/managing-reliability-with-slos-and-error-budgets-37346665abf6——描述 SLI、SLO 和错误预算之间关系的文章。

• www.techrepublic.com/article/aws-outage-how-netflix-weathered-the-storm-by-preparing-for-the-worst/——描述 Netflix 如何通过为最坏情况做准备来避免 2015 年 9 月 AWS 中断影响的文章。

• netflixtechblog.com/the-netflix-simian-army-16e57fbab116——Netflix 博客文章，解释了 Simian Army。

• principlesofchaos.org——混沌工程原则的资源库。

• 混沌工程：实践中的系统韧性，作者 Casey Rosenthal 和 Nora Jones——混沌工程的参考书，描述了混沌实验的原则和论文。

• 《网站可靠性工作簿：实施 SRE 的实用方法》由Betsy Beyer、Niall Richard Murphy、David K. Rensin、Kent Kawahara和Stephen Thorne编辑—实现 SRE 实践的参考书。

• www.linkedin.com/pulse/service-recovery-rolling-back-vs-forward-fixing-mohamed-el-geish/—Mohamed El-Geish 撰写的博客文章，讨论了恢复策略、回滚与前向修复。

第二部分：实现—迈向价值流

在 Gene Kim、Kevin Behr 和 George Spafford 合著的《凤凰项目：IT、DevOps 与帮助你的业务获胜的小说》一书中，我们介绍了三种方法。这些方法概述了我们如何向 DevOps 和 CALMR 转变。

第一种方法强调朝着流动的方向努力。为此，我们将围绕价值流进行组织和结构化，目的是可视化执行步骤和参与这些步骤的人。作为一个价值流工作将帮助我们优化流动。在[第七章]中，我们将看到如何建立我们的价值流。

在第一种方法之后，我们来到了第二种方法，重点强调反馈循环的放大。为了找到我们的反馈，我们会查看可以用来评估价值流的指标，在第八章中有详细介绍。

最后，我们来到了第三种方法。第三种方法强调向持续实验和学习转变。第九章将讨论如何打造一个持续学习的组织，并介绍通过持续学习改进价值流的方法。

本部分旨在建立一种简单的方法来实现价值流管理，这是 DevOps 中的关键实践。

本书的这部分包含以下章节：

• 第七章，映射你的价值流

• 第八章，衡量价值流绩效

• 第九章，通过持续学习迈向未来

第七章：绘制你的价值流图

价值流是 SAFe® 的重要组成部分。在我们回顾 第二章 时，曾在“共享责任文化”部分看到过这一点，我们探讨了 SAFe 精益敏捷原则，并得出了原则 #10：围绕价值进行组织。同样地，价值流在 DevOps 中也扮演着关键角色。在《凤凰项目：IT、DevOps 和帮助你的企业成功的小说》中，作者 Gene Kim、George Spafford 和 Kevin Behr 提出了“三种方式”这一概念。第一种方式是利用价值流来建立流程，这正是我们在本章中要探讨的内容。

我们将探讨如何发现组织的价值流并寻找未来的优化空间。总的来说，我们将关注以下活动：

• 使组织的思维模式与价值流保持一致

• 为开发价值流设定背景

• 绘制开发价值流图

• 寻找改进领域

让我们来看看如何让组织从价值流的角度去思考运营。

使组织的思维模式保持一致

关注价值流将要求组织进行重大变革，这可能最终导致文化的改变。这些变革努力通常是持续改进旅程的开始。

我们将首先评估一个此类转型的例子：通过实施路线图采用 SAFe。在审视这个路线图时，我们将看到识别价值流在其中发挥了关键作用。

另一个转型指南的例子是由 Cecil “Gary” Rupp 在《通过价值流管理推动 DevOps：使用成熟的 VSM 方法改善 IT 价值流交付，以便在数字经济中竞争》一书中提出的，涉及八个步骤，构成了价值流管理（VSM）计划。正如本书中所描述的，VSM 计划是 VSM 联盟的参考方法，VSM 联盟是一个致力于推进方法来改善 VSM 的个人和组织群体。

我们将看到，这两种变革指南之间有显著的重叠。因此，可以在 SAFe 转型中实施 VSM（价值流管理）计划，两者互为补充。考虑到这一点，让我们从 SAFe 的实施路线图开始，来审视价值流。

向 SAFe 过渡

实施路线图是组织采用 SAFe 的主要模式。该路线图从建立变革代理联盟开始，培训他们适应新的工作方式，然后通过价值流来实施这一过程。路线图可以进行定制，以适应组织的需求。

实施路线图的步骤如下：

1. 达到转折点以采用 SAFe。

2. 培训倡导者和变革代理。

3. 培训高管和领导者适应新的工作方式。

4. 为变革代理创建一个精益敏捷卓越中心。

5. 识别价值流。

6. 制定实施计划。

7. 准备启动第一个 敏捷发布 列车 (ART）。

8. 培训 ART 并启动。

9. 指导 ART 执行。

10. 启动额外的价值流和 ART。

11. 将 ART 指导扩展到投资组合。

12. 通过检查和适应加速并继续前进。

我们可以看到，这个路线图与之前讨论过的科特变革模型（第二章，《共享责任文化》）一致，特别是在以下表格中所示。

科特变革 模型步骤	适用的实施 路线图步骤
创建紧迫感	达到采纳 SAFe 的临界点
引导强大的联盟	培训倡导者和变革代理人，培训高层和领导者新的工作方式，创建精益敏捷卓越中心
创建愿景	识别价值流，创建实施计划
传播愿景	创建实施计划，准备启动第一个 ART
授权他人执行愿景	准备启动第一个 ART，培训 ART 并启动
庆祝短期胜利	指导 ART 执行
整合胜利来创造更多变化	启动额外的价值流和 ART，将 ART 指导扩展到投资组合
将新变化扎根于文化中	启动额外的价值流和 ART，将 ART 指导扩展到投资组合，加速并继续通过检查和适应

表 7.1 — 科特变革模型与 SAFe 实施路线图的映射

我们可以看到，识别价值流是启动第一个 ART 和随后的 ART 的重要部分。考虑到这一点，我们可以看看启动 VSM（价值流管理）计划的步骤，以帮助识别价值流。

转向价值流

VSM 方法论在《推动 DevOps 与价值流管理：通过经过验证的 VSM 方法提高 IT 价值流交付，以在数字经济中竞争》一书中由 Cecil “Gary” Rupp 提出。在这本书中，作者将精益思维中的改进 Kata 模型应用于创建和维持一个或多个价值流。

VSM 方法论概述如下步骤：

1. 承诺精益

2. 选择价值流

3. 学习精益

4. 映射当前状态的价值流

5. 映射价值流的理想未来状态

6. 制定改进（Kaizen）计划，以达到未来状态

7. 实施改进计划

8. 重复这个过程

现在我们理解了映射价值流的整体战略，接下来让我们仔细看看在下一部分中识别价值流的过程。

为开发价值流设定背景

开发价值流所做的工作应用于解决方案，而这个解决方案在客户与组织之间获取价值的更大背景中起着作用。这一更大的背景通过组织可能拥有的运营价值流来体现。

我们初步了解了操作价值流和开发价值流之间的差异，操作价值流详细描述了客户的需求以及公司的解决方案如何满足这些需求，而开发价值流则展示了开发和维护解决方案所需的步骤，在第二章，共享责任文化中有提到。在本节中，我们将展示如何利用有用的工具（如 Gemba 走动）来创建一个操作价值流。最后一步是找到操作价值流所使用的解决方案，这些解决方案将成为开发价值流的基础。

为价值流识别做好准备

绘制操作和开发价值流可能是一个庞大的工作量，面对组织的复杂性时，这可能会令人沮丧。在进行这项工作之前，一些准备工作是必要的。

价值流绘制通常通过组织内部的不同成员参加的工作坊进行。在举办这样的工作坊之前，您可能想确保组织已经确定以下事项：

• 价值流的范围

• 将会面以识别价值流的团队成员

• 通过 Gemba 走动了解客户的观点

让我们更详细地审视这些内容。

确定范围

组织的规模可以是小型的，也可以是庞大的，这取决于组织的历史或设计、生产和维护的产品或解决方案的数量。在发现组织和开发价值流之前，组织应该为发现设定适当的范围。

卡伦·马丁和迈克·奥斯特林在他们的书籍《价值流图绘制：如何可视化工作并与领导对齐进行组织转型》中将范围列出为价值流章程。在书中，他们为价值流章程收集了以下内容：

• 价值流。

• 特定条件：限制允许的场景数量可能会有帮助。如果是这种情况，您可能需要设置仅带来期望场景的小范围条件。

• 触发事件：启动价值流活动的事件。

• 需求率：这是触发事件发生的频率。

• 流程中的第一步和最后一步。

• 边界/限制。

• 改进时间框架：这有助于确定应该首先进行的可能的未来状态改进。

• 当前状态的问题和需求。

• 可衡量的目标条件。

• 对客户和业务的价值。

• 负责的团队成员。

让我们在下一节中看看绘制价值流图所需的成员和角色。

创建团队

一次价值流图绘制活动可能需要几天时间。在这期间，许多人将被召集提供他们的专业知识，并填写操作和开发价值流所需的价值流章程项目。

在《价值流映射：如何可视化工作并为组织变革提供领导力对齐》中详细列出以下角色：

• 执行赞助人：这可能是最终对结果负责的 C 级领导者。他们将监督整个过程，并跟踪价值流朝未来状态的进展。

• 价值流冠军：这是一个负责价值流绩效的人。他们在价值流映射中将扮演关键角色。

• 促进者：这是确保价值流映射顺利进行的人。

• 物流协调员：此人负责为价值流映射做好所有必要的安排。这可能包括为面对面映射会议预订房间或准备虚拟会议所需的网络协作会议配置。

• 会议参与者：映射团队的成员将组成其余的团队。这将是一个多样化的团队，他们了解价值流战略要素，并直接经历开发价值流将采取的战术步骤。

应向这些人展示宪章，以便他们为映射研讨会做好准备。可能会出现关于可能情况的问题。他们应被带到研讨会上，以便向所有人传达。

通过 Gemba 漫步理解客户的视角

因为操作价值流直接涉及客户，理解客户的视角非常重要，以便解决方案更有价值。通过 Gemba（也称为现场考察）漫步是实现这一点的一种方式。

通过 Gemba 漫步，VSM 团队成员将前往客户现场，从客户的视角查看价值流的工作方式，并确定是否需要任何改进。

在进行 Gemba 漫步时，通常有利于从价值流的最后一步开始向前工作。这有助于保持客户视角的关注，重视向客户交付的价值。

Gemba 漫步应该经常发生，以理解不仅客户的心态和价值流从客户角度的影响，还有价值流改进是否达到了预期效果的情况。

通过价值流管理推动 DevOps：使用经过验证的 VSM 方法论提高 IT 价值流交付，以在数字经济中竞争 概述了以下步骤作为 Gemba 漫步策略：

1. 确定目标和目标。

2. 提前通知客户 Gemba 漫步访问及其原因。

3. VSM 团队成员应该以小组形式访问。

4. 追踪价值流的流程。

5. 发现过程及其相关活动中的任何问题。不要归咎于个人。

6. 记录您发现的内容。

7. 识别根本原因。五个为什么技术，即反复问为什么？五次，是一种有效的追溯根本原因的方法。

8. 倾听。

9. 跟进推荐意见。

10. 重复走一遍以确认推荐的变更已经实施。

11. 重复走一遍，以发现其他 Kaizen（持续改进）机会。

剩余的价值流识别将在专门的研讨会上与团队成员一起进行。让我们仔细看看在研讨会中如何识别一个运营价值流。

创建运营价值流

在价值流研讨会的初期活动中，你需要识别运营价值流以及作为开发价值流最终产品的解决方案。

运营价值流通常根据其如何为客户提供价值，分为以下四类：

• 数字化支持的产品或服务：该运营价值流处理客户对产品或服务的在线请求。电子商务销售就是一个很好的例子。

• 制造：该运营价值流负责创建客户购买的实体产品。

• 软件产品：该运营价值流负责交付给客户的软件产品。

• 支持：该运营价值流关注支持客户的活动工作流，通常是内部客户。

下面的图表展示了这四类运营价值流的示例：

图 7.1 – 运营价值流示例

识别运营价值流的类别可以让绘图团队查看客户的旅程，并识别所需的可能解决方案。然后，他们可以概述客户为寻找价值所采取的步骤，并为每个步骤创建一个注释。

然后，团队会制定一系列步骤，形成他们的组织价值流，如下图所示，这是我们在第二章中首次呈现的运营价值流，共享责任的文化。

图 7.2 – 运营价值流示例

确定价值流步骤可能需要在绘图团队之间进行反复讨论，尤其是当存在多种条件时。评估最常见的条件可能更有意义。如果在运营价值流的候选数量上没有达成共识，可以考虑将所有候选方案提出，并观察它如何影响开发价值流。

当我们能够识别以下特征时，我们就能很好地定义一个运营价值流：

• 运营价值流的类型

• 名称

• 价值流描述

• 客户（们）

• 触发因素

• 客户所获得的价值

• 组织所获得的价值

当操作价值流的步骤确定后，接下来的任务是找出操作价值流依赖的解决方案。

寻找解决方案

一旦操作价值流的步骤被识别，下一步是查看每个步骤并确定该步骤是否通过解决方案来实现。SAFe 将解决方案定义为产品、系统或服务。解决方案可以是客户直接接触的内容，也可以仅限于内部使用。

解决方案与操作价值流步骤的映射不是一对一的。有些步骤可能需要相同的解决方案，而有些步骤可能不需要解决方案。

也有可能一个解决方案支持多个操作价值流。这样的解决方案及其相应的开发价值流可能在组织中是集中管理的。

我们为示例操作价值流识别了以下解决方案：

图 7.3 – 解决方案和操作价值流示例

一旦我们找到了解决方案，就离找到创造和维持这些解决方案的开发价值流更近了。我们将在下一节探讨如何确定这些开发价值流。

映射开发价值流

在 SAFe 中，发现开发价值流让我们更接近将这些价值流建模为 ART 或甚至更大的解决方案列车。

在映射解决方案如何作为开发价值流进行开发时，我们将集中于以下几个方面：

• 过程和工作流

• 参与该过程的人，如供应商和客户

让我们通过考虑用于开发解决方案的过程来开始我们的映射之旅。

寻找过程和工作流

在查看开发价值流时，我们可以首先将开发价值流视为一个黑盒，只有输入和输出可见。从那里开始，我们可以拼凑出中间的步骤。

开发价值流的初步“黑盒”通过识别以下特征形成：

• 开发价值流的触发点

• 开发价值流的第一步

• 开发价值流的最后一步

• 解决方案的需求率

黑盒的映射可以从确定解决方案开始，如下图所示：

图 7.4 – 开发流黑盒的初步映射

当价值流映射团队的成员就触发点、第一步、最后一步和需求率达成一致时，便可以开始填写第一步和最后一步之间发生的所有步骤。

连接各个环节

目前，映射团队开始填充开发价值流的第一步和最后一步之间的各个步骤。《价值流映射：如何可视化工作并对组织转型进行领导对齐》的作者建议步骤数应在 5 到 15 步之间，或者过程模块。

需要记住的是，在映射过程中，我们需要查看这些开发价值流的当前状态，确保不会遗漏过程中存在的瓶颈和弱点。如果不了解当前开发价值流的工作方式，很难想象出我们开发价值流的理想未来状态。

以下图表详细说明了我们示例开发价值流的各个步骤：

图 7.5 - 包含步骤的开发价值流

一旦确定了各个步骤，团队现在的任务是详细描述每个步骤。让我们看看这部分过程涉及的内容。

详细阐述每个步骤

现在步骤已经确定，我们应该看看每个步骤内部发生了什么。以下特征对于理解单个步骤中的内容非常重要：

• 批量大小（如果已定义）

• 缺陷

• 现有队列形式的在制品（WIP）

• 必要的批准

• 步骤指标，如前置时间、周期时间和等待时间

• 资源

请注意，前面的列表代表了步骤之间信息和材料自由流动的障碍。记录当前状态对于确定未来状态非常重要。我们将在寻找改进机会部分讨论这些问题。

在全面评估每个过程步骤后，下一步是确定谁负责执行每个过程步骤，以及谁将接收完成的产品。让我们来看看这个部分。

找到过程背后的人

确定涉及的人有助于查看潜在的未来状态开发价值流，以确定是否涉及了正确的团队或人员，以及现有团队是否能够承载工作量。

我们将专注于价值流中每个步骤内的以下两个角色：

• 执行过程步骤中工作的人。

• 过程步骤中工作完成后的接收人。他们可能是内部客户，因为他们接收来自过程步骤末端的信息和材料，继续下一步的工作，或者他们可能是外部客户。

通过我们收集的信息，我们对当前开发价值流的现状有了很好的了解。接下来，我们将看看是否存在改进的机会。

寻找改进的机会

一旦确定了开发价值流的当前状态，映射团队可以寻找改进的领域，并创建一个未来状态的开发价值流。他们还将创建一项改进计划，朝着这个未来状态迈进。

为了达到未来状态，映射团队需要对当前状态的开发价值流应用度量。这些度量将在每个步骤中收集，然后整合到评估整个开发价值流的度量中。

当前状态的开发价值流和未来状态的开发价值流的完整图景被保存在一个 DevOps 转型画布中。这个画布将整个研讨会的工作集中在一个地方，让我们能够看到当前的状态和目标的方向。

让我们通过检查当前状态度量来开始审视未来的状态，看看我们的开发价值流步骤。

流程步骤度量

在研讨会中，我们在每个步骤中识别度量，以确定该步骤是否为阻碍流动的瓶颈。通过进行这些测量，我们旨在找出瓶颈，并在未来状态的开发价值流中获得最佳结果。

我们为当前状态的开发价值流中的每个步骤衡量以下度量：

• 交付时间

• 流程时间

• 完成百分比和 准确性（%C&A）

现在让我们仔细看看这些度量。

流程时间和交付时间

在查看单个流程步骤时，我们想知道从它离开前一个步骤或触发点，到它离开当前步骤的时间总和。这个总时间被称为交付时间。

在交付时间内，可能会有等待时间，团队在执行流程步骤时可能在等待批准或审查。或者，也可能有价值添加工作的时间。这些流程步骤中的活动期间被称为流程时间。

我们之前在第四章，利用精益流保持工作流畅中讨论过周期时间，在那里我们看到周期时间与批次大小和团队已经处理的队列大小有关。如果团队在处理一批项目，周期时间将通过以下公式与流程时间相关：

使用这个公式，如果团队一次只处理一项工作，它的周期时间和流程时间将是相等的。

让我们看一个来自我们开发价值流的例子，重点关注价值流中的两个步骤：构建和集成测试。如果构建和测试是手动进行的，没有自动化，那么在构建步骤完成后，可能会有延迟，直到有人接手完成的构建并开始集成测试。集成测试需要 3 小时才能完成。构建到集成测试的典型交接延迟是 5 小时。这使得集成测试的流程时间等于 3 小时。因此，集成测试的交付时间是流程时间（3 小时）加上交接延迟时间（5 小时），即总共为 8 小时。

需要注意的是，提前时间和过程时间之间可能涉及不同的时间尺度。过程时间涉及工作日历（每周 5 个工作日），每个工作日包含 8 小时。提前时间通常使用标准的 7 天一周日历，每天包含 24 小时。在过程时间中可能会有例外，特别是在地理分布的开发环境下，允许跟随太阳的工作方式。团队还应明确区分工作周与日历周之间的不同。

%C&A

另一个过程步骤指标并不是由执行过程步骤的人员决定的，而是由过程步骤的信息或材料的接收者决定的，以便他们能够执行下一个过程步骤。

这些客户或接收者将被询问他们收到的交付物中有多少比例是无缺陷的，并且可以直接使用。这一比例被称为%C&A。

了解%C&A 很重要，因为它有助于识别改进的机会。低%C&A 得分的过程步骤将有更长的提前时间，因为需要进行返工。

让我们看一下开发价值流中的两个步骤：构建和集成测试。如果构建步骤产生的构建失败率是 20%，那么当它进入集成测试步骤时，%C&A 将是100% - 20% = 80%。

一旦确定了所有过程步骤的单个过程步骤指标，就可以计算整个开发价值流的复合价值流指标。

价值流指标

在发现单个过程步骤指标后，映射团队成员可以计算整个当前状态开发价值流的指标。这些指标是复合指标；也就是说，它们是通过将单个过程步骤指标相加或相乘得出的。

以下一组指标用于确定开发价值流的整体表现：

• 总过程时间

• 总提前时间

• 活动比率

• 滚动的%C&A

让我们看看如何计算这些指标。

总过程时间和总提前时间

我们希望评估开发价值流从最初的触发到功能发布所需的时间。这可以通过将每个过程步骤的提前时间相加来计算。这个总和称为总提前时间：

另一个需要关注的复合指标是开发价值流中有多少时间是活跃的开发时间。为此，我们可以将每个过程步骤的过程时间加在一起。这个总和称为总过程时间：

总过程时间和总提前时间用于计算下一个我们要看到的指标。

活动比率

一旦我们知道了总流程时间和总交付时间，我们可能想要查看开发价值流的生产力。为此，我们将查看总流程时间与总交付时间的比例。这个比例被称为 活动比率：

我们现在有了衡量开发价值流生产力的标准。接下来我们将查看的度量标准显示了质量是否嵌入到价值流中。

滚动 %C&A

记住，%C&A 是负责下一个流程步骤的人员根据交付物是否可用于后续处理而给出的每个流程步骤的测量标准。为了确定整个价值流的 %C&A，我们需要查看滚动的 %C&A。

为了确定滚动的 %C&A，我们将所有流程步骤的 %C&A 相乘。然后我们将该值乘以 100 得到一个百分比：

诸如流程时间、交付时间和 %C&A 等度量标准提供了重要数据，帮助我们确定瓶颈出现的位置。为了改善我们的开发价值流，我们需要看到理想的未来开发价值流是什么样子的。现在，让我们来探索如何做到这一点。

识别未来的开发价值流

在识别开发价值流的过程中，可能会有很多关于价值流步骤应是什么样子与实际是什么样子的讨论。这种不同的看法有助于理解“理想的”开发价值流，并且可能为开发价值流的演变提供输入。

映射未来状态价值流可能会在当前价值流映射完成并开始运行以收集数据后进行。这些数据对于突出流程中的瓶颈和其他薄弱环节非常有价值。

Karen Martin 和 Mike Osterling 在 Value Stream Mapping: How to Visualize Work and Align Leadership for Organizational Transformation 中建议，在接近未来价值流时，应该考虑以下视角：

• 确定价值流中的正确步骤

• 寻找流程流动

• 寻找持续改进

让我们详细查看这些视角。

修复流程和步骤

精益思维的一个关键点是消除浪费。我们可以通过寻找那些不增值的流程和步骤并将其移除，来将这一点应用到我们的未来状态价值流映射中。我们首先将步骤分为增值、必要的非增值和不必要的非增值工作。我们尝试优先去除不必要的非增值工作。接下来，我们重新评估必要的非增值工作，看看它是否可以减少，或者是否可以重新分类为不必要的非增值工作并予以消除。

在去除这些步骤时，重要的是考虑这些步骤最初的目的，并确保即使去除步骤后，这个目的仍然可以成立。一个例子是价值流末端的检查步骤。这个步骤的目的是确保质量。如果价值流中包含了各个层级的自动化测试步骤，那么检查步骤就可以被去除，而不会影响质量。

修复价值流的另一种方法可能是增加额外的流程和步骤。如果重点是消除浪费，增加步骤可能看起来有悖常理，但即使是暂时性地增加步骤，也能让团队在价值流中建立新的工作方式，以便以后去除不必要的非增值工作。如果我们关注提高质量，我们可能希望在价值流中增加测试步骤，同时保留检查步骤，这样当我们对测试结果有信心时，就可以去除检查步骤。

寻求流程

仅仅确保价值流中有正确的步骤可能还不够。我们还希望确保工作在价值流中的各个步骤之间流动，没有问题或延迟。因此，我们会确保价值流中正在发生流动。

我们为每个价值流步骤收集的指标（处理时间、交付时间和%C&A）对于修复流程非常重要。它们有助于确定哪些步骤是价值流中的瓶颈。我们寻找那些交付时间包含长时间等待的步骤。我们还关注那些%C&A 百分比较低的步骤，因为这些步骤表明可能正在进行返工。

一旦我们找到了瓶颈步骤，就可以应用 Eliyahu M. Goldratt 在其著作《目标》中提出的约束理论。约束理论详细阐述了处理瓶颈并实现流动的以下步骤：

1. 确定瓶颈。

2. 决定如何克服瓶颈。

3. 聚焦于克服瓶颈，服从所有其他的关注点。

4. 克服瓶颈。

5. 一旦瓶颈被克服，可能会出现其他瓶颈。返回到第一步来处理它们。

在特定步骤中消除瓶颈可能会在其他步骤中引入新的瓶颈，但总体的指标（总处理时间、总交付时间和滚动%C&A）将显示出改进。

寻求持续改进

优化步骤和消除瓶颈的结合可能为我们提供更好的价值流，但现在我们还需要确保有方法确保绩效在改善。因此，我们将建立两个到五个关键绩效指标（KPI），并定期跟踪它们的测量值。这些 KPI 可能涉及成本、质量、安全和士气等方面的测量。

在收集并计算当前和未来状态开发价值流的信息后，将这些信息放置在一个地方进行参考可能会有所帮助，特别是在我们寻求改善我们的价值流时。我们将看一个这样的地方——DevOps 转型画布。

DevOps 转型画布

DevOps 转型画布可以作为绘制开发价值流的背景，也可以用于识别未来状态和实施步骤，以带我们走向那里。

DevOps 转型画布包含当前状态价值流的区域，并且具有以下特征：

• 触发器

• 第一步

• 最后一步

• 需求率

• 价值流指标（总流程时间，总交付时间，活动比例，以及滚动 %C&A）

为了识别理想的未来状态，DevOps 转型画布包括以下领域，供工作坊期间填写：

• 目标价值流指标（总流程时间，总交付时间，活动比例，以及滚动 %C&A）

• 边界/限制

• 改进项

一个示例的 DevOps 转型画布如下所示。

图 7.6 – DevOps 转型画布

在工作坊完成后，工作开始于改善我们的开发价值流，并衡量改进的效果。这是我们将在下一章深入探讨的主题。

总结

在本章中，我们对价值流进行了全面的探讨。我们看到，将我们的活动与价值流对齐是 DevOps 中采用的一项关键方法，并且是通过实施路线图转型 SAFe 的重要组成部分。

我们首先审视了我们组织的现状。我们准备好让团队着手绘制我们的价值流，并通过 Gemba 走访了解我们是如何接收工作的。从这个检查中，我们看到了我们的流程以及其中的任何不足。

然后，我们着手发现并绘制我们的价值流。我们首先绘制了连接我们与客户之间的操作价值流。从那里开始，我们着手研究操作价值流如何通过解决方案为客户创造价值。有了这些解决方案，我们继续研究创建和维护这些解决方案的开发价值流。最后，我们查看了指标，以了解开发价值流的现状，并在努力迈向未来状态开发价值流时衡量我们的改进。

现在我们已经确定了我们的开发价值流，我们将寻找反馈，以查看我们的改进是否产生了预期的效果。下一章将向我们展示如何收集这些反馈。

问题

1. 以下哪项在进行价值流绘制时没有被识别？

   1. 触发器

   2. 需求率

   3. 位置

   4. 第一步

2. 以下哪项标识完成一个过程步骤所需的时间，从前一个过程步骤移交开始计算？

   1. 需求率

   2. 交付时间

   3. 流程时间

   4. 周期时间

3. 谁决定过程步骤的%C&A？

   1. 客户

   2. 在过程步骤中工作的人

   3. 在下一个过程步骤中工作的人

   4. 在前一个过程步骤中工作的人

对于剩余问题，使用以下示意的价值流：

图 7.7 – 价值流示意图

1. 总过程时间是多少？

   1. 0.5 小时

   2. 2 小时

   3. 1 小时

   4. 5 小时

2. 总交付时间是多少？

   1. 5 小时

   2. 3 小时

   3. 1 小时

   4. 10 小时

3. 活动比率是多少？

   1. 1.0

   2. 0.66

   3. 0.25

   4. 0.5

4. 滚动的%C&A 是什么？

   1. 100%

   2. 490%

   3. 90%

   4. 400%

进一步阅读

• 《凤凰项目：关于 IT、DevOps 和帮助你的企业赢得胜利的小说》，作者：Gene Kim, George Spafford, 和 Kevin Behr – 一本关于 DevOps 的“必读”入门书籍。书中介绍了我们用来审视 VSM 的三种方法。

• www.scaledagileframework.com/implementation-roadmap/ – SAFe 上的一篇文章，讨论了实施路线图。

• www.scaledagileframework.com/development-value-streams/ – SAFe 上的一篇文章，讨论了开发价值流及其与运营价值流的关系。

• 《通过价值流管理推动 DevOps：使用经过验证的 VSM 方法改善 IT 价值流交付，竞争数字经济》，作者：Cecil “Gary” Rupp – 这是一本关于 VSM 的参考书，包含了价值流映射的指导。VSM 联盟使用的资源。

• 《价值流映射：如何可视化工作并为组织变革对齐领导力》，作者：Karen Martin 和 Mike Osterling – 关于如何进行价值流映射的参考书。

• 《目标》，作者：Eliyahu M. Goldratt – 本书介绍了约束理论。

第八章：测量价值流表现

在上一章中，我们通过参考《凤凰项目：关于 IT、DevOps 以及帮助企业成功的小说》中的三种方法，开始了对价值流的探索。第一种方法是通过建立价值流来实现流动。

本章超越了价值流的建立，转向验证它们的表现。对于本章，我们关注第二种方法：增强反馈回路。要遵循第二种方法，我们需要寻找并关注来自价值流的反馈。

我们可以使用度量标准作为反馈机制。出现了几种度量框架，如DevOps 研究与评估（DORA）指标和 Flow 框架®，它们可以作为反馈回路。

本章将涵盖以下主题：

• 创建良好的度量标准

• 查看 DORA 指标

• 查看 Flow 框架®和 Flow 指标

• 在 SAFe®中的度量标准理解

让我们首先了解如何获得有效的反馈。

创建良好的度量标准

我们最初在第五章《测量流程与解决方案》中看到过可以应用的不同类型的度量标准，我们在该章中查看了以下三个领域的度量：

• 开发过程

• 环境

• 提供的客户价值

可以充分覆盖这三个测量领域的度量标准集称为关键绩效指标（KPI）。

KPI 是用来衡量个人、团队、价值流或在我们案例中的敏捷发布列车（ART）是否实现其目标的度量标准。KPI 在特定时间点以及在给定时间段内进行评估，以突出趋势和目标的偏移或接近。

KPI 应该是客观的度量标准，而非受意见或解释影响。

在审视这些度量时，我们提醒大家避免使用虚荣指标，这些指标提供了不错的信息，但实际上并没有提供有意义的数据。比如网站的点击次数或某个服务的累计订阅者数量。

要设置 KPI，让我们看看下面的图示步骤，正如kpi.org所建议的那样。

图 8.1 — KPI 建立过程

让我们详细看看每一步。

描述目标或预期结果

在审视预期目标时，理解它是战略性目标还是更具战术性的结果非常重要。理想的目标应该是一个简洁、具体的结果，而不是一个广泛的目标。

这样，KPI 与目标和关键结果（OKR）是不同的。OKR 通常描述广泛的战略目标，预期的结果作为衡量该战略目标是否实现的标准。以下表格显示了一个 OKR 的示例：

目标	关键结果
我们通过卓越的可用性和服务在每个机会中让客户满意	到第三季度，我们的可用性得分从 6 提高到 9
到第三季度，我们的客户满意度得分从 7 提高到 10
每月活跃用户的比例从 56%提高到 65%

表格 8.1 — OKR 示例

KPI 指示是否达成了具体目标。一个 KPI 的例子是测量净推荐值（NPS）调查结果，通常来自忠实客户。

如果你已按照上一章节所示进行价值流映射，第七章，映射你的价值流，那么你期望的价值流未来状态就是你的 ART 或价值流可以努力实现的有效战术目标。

了解衡量目标的方法

为了实现你的目标，你需要了解衡量标准是如何工作的。是否有直接的衡量标准与目标相对应？如果有，这些应当是你使用的指标。

然而，如果你无法直接衡量目标，会发生什么呢？在这种情况下，你可能需要考虑提出假设，并通过实验来衡量假设的结果。

为每个目标选择衡量标准

既然目标已经设定，并且为每个目标定义了可能的衡量标准，是时候缩小选择范围，选取最重要的测量标准了。在大多数情况下，五到七个 KPI 就足以充分反映价值流的情况。集中精力关注几个关键的衡量标准，比沉浸在大量数据中要更有效。

我们希望我们的 KPI 具备以下特征：

• 回答有关我们表现的问题，以符合我们的目标

• 提供制定策略所需的清晰信息

• 有效且可以验证

• 鼓励员工表现出期望的行为

• 不难获取

现在我们有了衡量标准，接下来需要确定我们的价值流的理想值是什么。

如有必要，定义复合指标

可能有些衡量标准单独无法提供所有的信息来达成预期结果。这在目标是无形的情况下尤其重要，比如客户满意度。

如果是这种情况，你可能需要将单个衡量标准汇总成一个复合指标，以便于分析。

定义目标或阈值

我们希望看到自己在 KPI 上的表现。为了评估我们的表现，我们需要为每个 KPI 设定一个目标值。这个目标值应处于最佳表现的阈值范围内。阈值还应定义为表现不佳的标准。

定义并记录已选的衡量标准

现在我们已经定义了 KPI，并为良好、满意和差的表现设定了目标值和阈值。接下来是扩展和详细说明有关 KPI 的其他信息。

以下附加信息在收集和分析 KPI 时可能有帮助：

• 其预期目标

• KPI

• KPI 的描述

• 衡量标准的类型

• 计算该度量标准的公式

• 计量单位

• 测量数据的存储位置

• 谁负责测量并对其负责

• 数据来源

• 收集和报告的频率

• 负责验证的人员

• 负责验证的人员

• KPI 展示的方法

对于开发价值流，可能可以从一套标准的 KPI 开始。这种标准由 DORA 制定，并在年度调查中进行考察。让我们来看一下这些指标，并看看它们在新的开发价值流中的适用性。

DORA 指标

自 2014 年以来，DORA 的 Nicole Forsgren、Gene Kim、Jez Humble，以及 Puppet 的 Alanna Brown 每年都会发布一份详细说明 DevOps 采纳状态的报告。每年，他们都会详细介绍 DevOps 采纳的总体情况以及受访者在采纳 DevOps 实践方面的成熟度。

2016 年，他们概述了一些旨在衡量不同组织中 DevOps 实践吞吐量和稳定性的指标。这些指标被称为 DORA 指标。

年度报告作为 DevOps 实践融入程度及其效果的晴雨表。每年，报告都会指出 DevOps 运动的以下几个方面：

• 关键 KPI

• 基于 KPI 的组织绩效水平

• 即将到来的趋势

现在让我们逐一查看这些方面。

DORA KPI 指标

《加速：DevOps 状态报告》通过以下四个指标来确定参与组织的绩效水平：

• 交付时间

• 部署频率

• 变更失败率

• 平均修复时间

前两个指标衡量组织的速度，或组织将变更交付到生产环境的速度。第三和第四个指标则衡量组织的稳定性，或者说组织在保持生产环境运行方面的能力。

让我们更详细地了解这些指标。

交付时间

我们在前一章节中讨论过交付时间，第七章，映射您的价值流。在这一章节中，我们看到每个过程步骤都有一个交付时间。总交付时间是所有过程步骤的交付时间之和。

DORA 指标关注的是变更的交付时间 —— 即从提交代码到版本控制库到将代码部署到生产环境的时间。这是总交付时间的一个子集。书籍《加速：构建与扩展高性能技术组织》的作者，Nicole Forsgren、Jez Humble 和 Gene Kim（所有人都是 DORA 指标定义的关键贡献者）指出，交付时间应该排除与设计相关的任何交付时间。这主要是因为设计交付时间何时开始计时存在不确定性。交付时间更容易测量且抗干扰性强。

让我们来看一下下面这个示例价值流的插图：

图 8.1 — DORA 前置时间的示例价值流

在上图中，我们看到通过持续集成，自动化在非生产环境中执行测试。如果没有发现错误，则该过程需要 4 小时，之后变更会被部署到暂存环境中。

在暂存环境中，可能没有进行自动化测试。这或许可以解释为什么从暂存环境到生产环境的迁移时间需要 40 小时。

所以，对于这个价值流，我们将每个阶段的时间加总（4 小时 + 40 小时），得出总前置时间为 44 小时。

部署频率

DORA 指标考察的是组织成功将代码部署到生产环境的频率。

如果我们继续使用我们的价值流示例，其前置时间为 44 小时，或 1.83 天（因为前置时间是按照 24/7 日历进行度量的），我们可以看到他们每月大约部署 16 次。

变更失败率

该指标是对部署过程质量的考察。它衡量发布到生产环境时，服务是否会出现降级或失败的情况，需要通过回滚、修补或实施热修复来进行修复。

确定变更失败率来源于检查部署记录，并查看是否有任何部署直接导致了生产环境的失败。

假设在我们的价值流中，我们查看了过去 12 次部署。在这 12 次部署中，生产环境遇到了三次问题。

我们的变更失败率将通过以下计算得出：

= 3/12 = 25%

恢复时间

该指标考察的是在生产环境中发生的服务故障。在这些故障中，恢复服务需要多长时间？

通常，当发生多个故障时，恢复时间指标以平均恢复时间（MTTR）表示，即恢复的平均时间。

在我们的价值流中，对于过去 12 次部署中的三次失败，如果每次失败的修复时间分别是 3 小时、2 小时和 7 小时，那么平均修复时间将是以下计算结果：

= 4 小时

对于前述的四个指标，DORA 进行了响应的聚类分析，并确定了四个绩效水平。我们来看看这些级别。

DORA 指标绩效水平

每年在《加速：DevOps 状态》报告中，DORA 会分析反馈，查看受访者的表现水平。从四个 DORA 指标的 KPI 出发，他们创建了以下四个绩效水平：

• 精英

• 高

• 中等

• 低

每年的调查报告都会改变各个层级的标准。这是由于不仅每个组织的实践有了整体改善，行业整体的实践也在提升。2021 年的报告显示，Elite 或 High performer 层级的受访者人数相比往年有所增加，这表明持续改进在采用 DevOps 实践中的重要作用。

2022 年《DevOps 状态报告》在这些绩效水平上发生了重大变化。首次移除了 Elite 层级。调查结果表明，表现最好的群体的表现不再达到去年 Elite 层级的标准。需要更多的数据来寻找可能的原因。

《DevOps 状态报告》中的新兴趋势

为了适应变化的时代，调查还包括了一些关于组织环境的辅助问题，以便观察新兴的方面。最近的两份报告（2021 年和 2022 年）包含了以下附加内容：

• 自 2018 年以来，DORA 增加了另一个指标：可靠性。这个指标不仅衡量软件交付的表现，还衡量组织维护其环境或运营表现的能力。

• DORA 自 2019 年以来一直在研究云基础设施的采用，指出云技术的采用是一项促进技术，能够提高所有四个 DORA 指标的 KPI。

• 2021 年的报告开始调查 SRE 实践的采用情况，作为寻找与可靠性相关性的一个途径。

• 除了调查技术 DevOps 实践外，DORA 还扩大了调查范围，涵盖了集成到开发过程中的文档和安全实践。

• 由于 COVID-19 大流行对既定工作模式的冲击，调查中增加了衡量组织在避免员工倦怠的同时，能够继续交付的复原力的问题。

• 作为安全实践调查的一部分，2022 年《DevOps 状态报告》调查了公司是否采取措施确保其软件供应链的安全。这些措施属于两个标准化框架之一：软件工件供应链等级（SLSA）和 安全软件开发 框架（SSDF）。

DORA 指标提供了一个很好的初步视角来衡量 KPI，但通常并非所有价值流所做的工作都直接与提供客户价值相关。为了衡量这些 KPI，采用 Flow Framework® 并衡量 Flow Metrics® 可能是一个不错的选择。接下来，我们来看看 Flow Framework® 模型。

Flow Framework® 和 Flow Metrics®

Flow Framework® 模型在 Mik Kersten 的书籍 Project to Product: How to Survive and Thrive in the Age of Digital Disruption with the Flow Framework 中有详细描述。在这本书中，Kersten 解释了如何从基于项目的设计转向使用长期价值流进行产品开发。

为了衡量价值流的表现，Kersten 提出了流程框架®，这是一种流程文档结构，并使用流程度量®来衡量这些文档。

Kersten 最初制定了流程框架®，以衡量他所在公司 Tasktop 的软件交付流。通过审视 Tasktop 的价值流，Kersten 确定了他希望监控的以下四个结果：

• 价值

• 成本

• 质量

• 幸福感

他将这些项目与四个流程项相关联，这些流程项是 Tasktop 的价值流所做的工作类型。为了跟踪这些流程项的进展，Kersten 找到了四个这些流程项所表现出的流程度量®。

让我们通过检查四个流程项来开始了解流程框架®。

流程项

Kersten 确定了价值流所做的以下四种类型的工作：

• 待交付功能

• 缺陷修复

• 风险规避

• 技术债务减少

每个项目在利益相关者和这些项目的价值方面都有独特的差异。

功能

功能是带来直接商业价值的项目。客户从价值流中拉取功能，以提供他们想要或需要的解决方案。这项工作被认为是价值流将交付的主要类型的工作。

在 SAFe® 中，流程框架®的功能可以映射到功能，即将工作项分解为用户故事和启用故事，这些故事的时间框定为一个 程序增量 (PI)。

缺陷修复

价值流可能还会致力于修复发现的任何缺陷。这些修复可能是开发过程中发现的缺陷，也可能是已进入生产环境的缺陷。无论缺陷何时被发现，客户都会作为解决方案的一部分来拉取修复。

SAFe 没有直接识别修复缺陷的单独工作，但这类工作通常作为价值流使用的工作跟踪系统的一部分进行追踪。例如，当使用 Jira 的价值流识别出一个单独的问题类型（缺陷），以追踪修复缺陷的工作量。

风险规避

价值流可能会在合规、安全、治理和隐私等重要 非功能需求 (NFRs) 的组织中工作。这些非功能需求可能与它们所在的行业相关，这些行业可能有重要的合同要求或需要遵守的法规。旨在降低风险的项目由价值流交付给不同的利益相关者。这些利益相关者通常是组织内部的人员，如安全或治理团队。

在 SAFe 中，旨在满足非功能需求并减轻或消除风险的项目被称为合规启用项。时间框定为 PI 的合规启用项被识别为 ART 在一个 PI 内完成的功能，而以故事大小为单位的合规启用项则由 ART 内的个别团队进行处理。

技术债务减少

降低技术债务是价值流进行的重要工作。如果技术债务未能管理到可控水平，其他流动框架®项（特性、缺陷修复和风险规避）的交付将会受到架构不足的影响。

SAFe 将流动框架®的债务项归类为使能项。在讨论流动框架®的风险时，我们已经看到过合规使能项。其他类型的使能项有助于维持产品或解决方案的架构。

基础设施使能项由 ART 和团队使用，以增强开发过程。这类工作包括自动化测试和部署的集成与维护。

架构使能项直接改善 ART 产品或解决方案的架构。为了使这些改进能为未来特性所利用，一系列架构使能项被创建，这些被称为架构跑道。

探索使能项允许 ART 团队成员研究未知技术或确定最佳的功能实现方法。尖峰（Spikes）是探索使能项的常见例子。

使用流动框架®进行测量的价值流将其工作划分为这四个流动项。现在，我们将看看应用于这些项的度量。

流动度量

在流动框架®中，我们希望看到我们的价值流在所有工作类型中的表现。为此，我们将对每个流动项应用以下度量：

• 流动速度®

• 流动时间®

• 流动负荷®

• 流动效率®

此外，我们还有一个指标——流动分布®，这样我们可以看到价值流在哪些流动项上投入最多。

现在，让我们深入了解每个指标。

流动速度®

流动速度®查看在标准时间单位内完成的流动项数量，无论其类型如何。以下图表说明了一个价值流的流动速度®：

图 8.3 — 流动速度®的插图（版权 © 2018 Tasktop Technologies, Incorporated. 保留所有权利。经许可发布）

这类似于在 Scrum 中测量速度。一个稳定且运行良好的价值流将保持在多个时间周期内流动速度®的一致性。

流动时间®

流动时间®是完成单个流动项所需的时间，从它被接受到价值流中，到它从价值流中发布为止。流动时间®包括活跃时间和等待时间。以下图表说明了流动时间®：

图 8.4 – Flow Time® 插图（版权 © 2018 Tasktop Technologies Incorporated。保留所有权利。经许可发布）

Flow Time® 和交付时间的区别在于后者是一个客户指标。使用 Flow Time® 时，我们旨在确定开发我们的产品或解决方案所需的时间长度。

Flow Load®

我们在 第四章中讨论了大量 WIP 带来的问题，利用精益流动保持工作进行。Flow Load® 是 WIP 的一种衡量标准。如以下示意图所示，我们可以看到正在进行的 Flow Items 数量与 Flow Load® 的关系：

图 8.5 – Flow Load® 插图（版权© 2018 Tasktop Technologies Incorporated。保留所有权利。经许可发布）

记住，正如大量 WIP 会导致更长的交付时间和较低的性能，高 Flow Load® 值是性能降低的标志，这将导致更长的 Flow Times® 和降低的 Flow Velocity®。

Flow Efficiency®

我们之前看过 Flow Time®，并看到它包括了价值流在积极工作时和在某个过程步骤上等待时的时间。你可以通过观察积极时间与 Flow Time® 的比率来计算效率。

以下示意图通过计算 Flow Efficiency® 来完成我们之前关于 Flow Time® 的示例：

图 8.6 – Flow Efficiency® 插图（版权 © 2018 Tasktop Technologies Incorporated。保留所有权利。经许可发布）

Flow Efficiency® 类似于在 第七章中介绍的活动比率，绘制你的价值流。不同之处在于 Flow Efficiency® 关注的是价值流的开发视角。

Flow Distribution®

在查看到目前为止的 Flow Metrics® 时，我们还没有考虑正在测量的 Flow Item 类型。接下来我们将通过 Flow Distribution® 来指导我们判断价值流的工作是否平衡。

Flow Distribution® 查看某个价值流完成的 Flow Items 数量，并衡量每种类型的 Flow Item 占总 Flow Items 数量的百分比。Flow Distribution® 的计算通过以下示意图演示：

图 8.7 – Flow Distribution® 插图（版权 © 2018 Tasktop Technologies Incorporated。保留所有权利。经许可发布）

在 SAFe 中，通过查看 Flow Distribution®，ART 可以确定特性和使能器的适当分配比例，从而在交付客户价值和确保所需改进之间保持适当平衡。

在 SAFe 中的度量

在查看组织的价值流（作为 ART 实现时）时，Scaled Agile 建议从以下三个方面评估其表现：

• 成果

• Flow

• 能力

让我们看看在 SAFe 中如何衡量这三个方面。

在 SAFe 中衡量成果

衡量成果的主要机制来源于建立和衡量价值流的 KPI。

我们在 第五章，衡量过程和解决方案 中看到了一些衡量客户成果的 KPI 框架，如 海盗（ARRRR）指标和适用性指标。为团队或 ART 确定 KPI 集合在本章前面已讨论过。

验证来自 Epic 的效益假设可能会导致理想的结果。Epic 开发通过创建 最小可行产品 (MVP) 并使用前导指标来衡量假设的价值，从而进行实验性地完成。密切监控前导指标会产生证据，验证或否定 Epic 假设，允许我们在进一步的 Epic 开发中进行 转向或坚持。

ART 上的敏捷团队还希望衡量他们在每个迭代中创建的迭代目标，以及他们为每个 PI 创建的 PI 目标。这些目标帮助团队集中精力，不是完成每个特性和故事，而是确保交付客户价值。

在 SAFe 中衡量 Flow

团队或 ART 决定采用的一些价值流 KPI 将与确保交付价值的表现相关。Scaled Agile 推荐使用 Flow Framework® 中的 Flow Metrics® 来确保 Flow 成功地实现产品交付。前面部分已经讨论了这些 Flow 项目和对应的 Flow Metrics®。

此外，Scaled Agile 还推荐一种额外的 Flow 指标：Flow 可预测性。该指标衡量团队和 ART 规划 PI 并实现 PI 目标的能力。

为了衡量 Flow 可预测性，团队和 ART 使用 SAFe 程序可预测性度量 (**PPM*)。计算 PPM 时，团队查看 PI 规划期间确定的 PI 目标的原始业务价值。然后，他们将这些值的总和与在 PI 结束时的检查与适应研讨会上确定的已承诺和未承诺 PI 目标的实际业务价值进行比较。该度量通过以下公式确定：

以下表格显示了团队 PPM 计算的一个示例：

	PI 目标	计划（原始） 业务价值	实际 业务价值
承诺目标	将索引速度提高 50%	9	4
构建并发布电子商务功能	10	10
构建并发布智能搜索功能	8	4
未承诺目标	向数据库中添加 2,000 个新产品并对其进行索引	7	7
使用比特币支持购买	5	0

表 8.2 — 团队 PPM 计算示例

在前表中，承诺和未承诺 PI 目标的实际业务价值总和为 25。计划的业务价值总和为 27。然后，团队的 PPM 为 25/27：

图 8.8 — 团队预测性汇总示例到 PPM（© Scaled Agile, Inc. 版权所有）

上图显示了创建 PPM 的汇总过程。ART 通过对组成 ART 的各个团队的 PPM 值取平均来获得 PPM。

在 SAFe 中衡量能力

从更宏观的角度来看，采用 SAFe 的企业致力于实现业务敏捷性，在这里，战略与执行相结合，通过频繁交付客户价值来实现业务成果。

在 SAFe 中，业务敏捷性通过自我评估组织不同部门所实践的以下七项核心能力来衡量：

• 团队和技术敏捷性

• 敏捷产品交付

• 企业解决方案交付

• 精益组合管理

• 组织敏捷性

• 持续学习文化

• 精益敏捷领导力

团队和 ART 使用 DevOps 健康雷达评估他们在采纳 DevOps 原则和实践方面的能力。让我们来看看如何使用 DevOps 健康雷达。

DevOps 健康雷达

DevOps 健康雷达是一个工具，列出了与持续交付管道的四个方面相关的所有活动。DevOps 健康雷达的示意图如下：

图 8.9 — DevOps 健康雷达（©Scaled Agile, Inc. 版权所有）

对于持续交付管道的每个 16 项活动，团队和 ART 根据其在执行活动方面的成熟度进行自我评分。评分范围从 Sit（1 到 2），Crawl（3 到 4），Walk（5 到 6），Run（7 到 8）到 Fly（9 到 10），即顶峰。

团队和 ART 应定期使用 DevOps 健康雷达自我评估，以跟踪其 DevOps 性能的成熟度。此评估可在 Scaled Agile Framework 网站上免费获取，网址为 www.scaledagileframework.com/?ddownload=38794。我们将在第三部分中探讨持续交付管道及其活动。

摘要

在本章中，我们希望通过通过扩大反馈回路来采用第二种方法，确保我们走在正确的道路上。我们将为价值流使用的关键反馈回路通常是度量指标。

在选择指标时，我们希望将其视为 KPI。我们了解了如何从期望的目标开始，查看与这些目标相符的指标，精炼要收集的指标集合，并将它们收集为 KPI。

我们首先查看了作为 KPI 集合的一部分可以使用的一个标准指标：DORA 指标，它构成了年度《加速 DevOps 状态报告》的基础。通过收集这些指标并持续改进，可以通过与其他组织的比较，识别一个具有基准绩效水平的价值流，这些数据来自年度报告。

如果要查看除了提供客户价值之外的其他类型工作，可以查看 Tasktop 创建的 Flow Framework®。通过 Flow Framework®，我们概述了定义价值流所做工作的四个流动项，并为每个流动项设置了四个流动指标®，同时将流动分布®应用于一组流动项。

现在我们已经了解了如何查看反馈的测量指标，我们将进入第三种方式，应用持续实验和学习。在下一章中，我们将探索如何实现这一点的方法。

问题

1. 一个价值流应拥有的最佳 KPI 数量是多少？

   1. 2 到 4

   2. 5 到 7

   3. 6 到 9

   4. 10 到 12

2. 哪一项不是 KPI 的特征？

   1. 是有效的并且可以验证

   2. 鼓励员工做出期望的行为

   3. 回答关于向目标进展的问题

   4. 很难收集

3. 哪一项不是 DORA 指标 KPI？

   1. 周期时间

   2. 部署频率

   3. 变更失败率

   4. 平均修复时间

4. DORA 指标的哪些 KPI 衡量稳定性？（选择两个）

   1. 交付时间

   2. 周期时间

   3. 部署频率

   4. 变更失败率

   5. 平均修复时间

5. 哪一项不是 Flow Framework® 中的流动项？

   1. 特性

   2. 项目

   3. 风险规避

   4. 技术债务减少

6. 哪一项不是 Flow Framework® 中的流动指标®？

   1. 流程速度®

   2. 流程负载®

   3. 流程可预测性®

   4. 流程时间®

进一步阅读

要了解更多关于本章中讨论的主题，请查看以下资源：

• 《凤凰项目：IT、DevOps 和助力业务成功的小说》 由 Gene Kim、George Spafford 和 Kevin Behr 编写

• f.hubspotusercontent00.net/hubfs/8944057/The%20State%20of%20Value%20Stream%20Management%20Report%202021.pdf – 来自价值流管理联盟的 2021 年《价值流管理状态报告》

• kpi.org/KPI-Basics – 介绍如何定义 KPI 以及如何制定你的 KPI 集合

• www.devops-research.com/research.html#reports – DORA 和 Puppet Labs 发布的《加速 DevOps 状态报告》的所有版本的登陆页面

• cloud.google.com/blog/products/devops-sre/the-2019-accelerate-state-of-devops-elite-performance-productivity-and-scaling – DORA 发布的 2019 年《加速 DevOps 现状报告》的发现

• cloud.google.com/blog/products/devops-sre/announcing-dora-2021-accelerate-state-of-devops-report – 2021 年《加速 DevOps 现状报告》的发现

• 《从项目到产品：如何在数字化颠覆的时代中生存与发展，运用 Flow Framework》 由 Mik Kersten 撰写 – 这是 Flow Framework®各个方面的参考书，包括 Flow 项目和 Flow 指标

• flowframework.org/flow-metrics/ – 来自 Flow Framework® Institute 的 Flow 指标分析

• www.scaledagileframework.com/devops/ – 这是scaledagileframework.com网站上的一篇文章，其中提供了 DevOps 健康雷达的描述等内容。

• www.scaledagileframework.com/metrics/ – 这篇来自scaledagileframework.com网站的文章阐述了 KPI、Flow 指标和其他评估形式之间的相互作用

第九章：9

带着持续学习迈向未来

到目前为止，我们已经通过《凤凰项目：关于 IT、DevOps 与帮助你的企业成功的小说》中提到的三种方式来研究价值流管理。通过第一种方式——建立流动性，我们探讨了如何确定并绘制我们的开发价值流。在第二种方式中，我们通过采用有意义的 KPI 来加强我们价值流中的反馈回路。

现在我们来看第三种方式：持续学习和实验。DevOps 的一个关键部分是认识到转型之旅没有终点。也就是说，你的组织将不断改进并设定进一步的目标，以创造更强大的价值流。随着你不断发现和优化，未来的价值流将会更加完善且没有尽头。

在本章中，我们将通过讨论以下主题来研究如何为你的价值流寻找未来状态：

• 采用持续学习文化

• 利用改进 Kata 来识别未来状态的价值流

• 将精益改进周期的所有部分作为改进 Kata 的一部分来实施

让我们从深入探讨持续学习开始我们的探索。

理解持续学习

1990 年，彼得·先锋（Peter Senge）出版了《第五项修炼：学习型组织的艺术与实践》。在书中，他描述了公司要成为学习型组织所需具备的特质或学科。

学习型组织允许员工通过自己的努力促进学习。这种学习推动组织的持续转型，使其不断追求改进。在今天的商业环境中，学习速度比竞争对手更快的组织具有显著的优势。

先锋（Senge）识别了学习型组织必须具备的以下五个特点或学科：

• 个人精通

• 心智模型

• 共同愿景

• 团队学习

• 系统思维

当组织在前四个学科上取得进展时，第五个学科——系统思维，将帮助组织进入下一阶段，成为学习型组织。

让我们仔细看看每个学科，看看如何在该学科上变得精通，并朝着成为学习型组织的目标前进。

个人精通

组织无法学习，除非组织内部的个体学习。组织内部的个体寻求成长并持续学习。先锋称这种动力为个人精通，它是传播到整个组织的种子。

建立个人精通的个体将发现两个在其发展中起作用的工具：

• 愿景：个体学习他们对自己重要的东西

• 视角变化：将当前现实视为有助于或阻碍愿景的因素

随着个人发展愿景并通过个人精通看到当前现实，他们会遇到愿景与当前现实之间的张力。这些张力是自然存在的，包括创造性张力，即愿景与当前现实之间的差距，以及情感张力，即个人在面对创造性张力时所感受到的情绪。

除了创造性张力和情感张力，个人还可能意识到结构性冲突。这些结构性冲突是当无法应对创造性和情感张力时，感到无力或不配的压倒性情绪。

在遇到前述的张力和结构性冲突时，以下反应可能会作为应对机制出现：

• 让我们的视野逐渐消退，以实现一个更简单的目标

• 冲突操控，即我们专注于避免我们不想要的东西

• 采用意志力策略，即个人通过压倒性的力量克服张力、冲突及其他阻力，以实现愿景

为了确保我们通过意志力策略来发展个人精通，个人必须诚实并拥抱真理。这使得能够从多个角度看待创造性的张力，并允许从多个角度出击以实现愿景。另一种有效的策略是学习不仅仅发生在意识层面。擅长个人精通的人允许潜意识发挥作用。一个例子就是不断重复一项新技能，直到它成为肌肉记忆。

随着个人发展个人精通并朝着愿景前进，以下一些变化会逐渐显现：

• 理性和直觉开始融合。这使得能够从多个角度看待问题。

• 个人开始看到自己与世界之间更多的联系。

• 同情心开始建立。

• 个人看到整体，并开始致力于那个整体。

这些特质是组织从个人身上所需要的。因此，组织必须朝着允许并鼓励员工走向个人精通的方向努力。它们需要创造一种鼓励愿景创造的氛围。它们必须赋予个人自由去探究并寻求真理。有时，这可能涉及质疑现状。这些自由会造就更好的个人，进而促进组织的成长。

随着个人在个人精通方面的成长，他们可能会改变他们的愿景和对当前现实的认知。这种变化会影响他们已经创造并使用的心智模型。接下来，我们将探讨这些心智模型的意义。

心智模型

我们之前看到，当个人发展个人精通时，他们会遇到创造性的张力，或者他们会看到他们的愿景与当前现实之间的差距。这种创造性的张力可能源自他们对世界运作方式的认知。这些认知，简单来说，就是作为学习型组织的心智模型。

思维模型塑造了学习者的感知，并服务于以下两个主要目的：

• 它帮助个人理解周围的世界

• 它告知个人如何采取行动

思维模型为个人和组织提供有关当前情况下某个特定问题有效的解决方案。因此，学习型组织通过在面对新信息时改变其思维模型而受益。

以下是个人和学习型组织在增加或改变思维模型时所需要的内容：

• 促进个人意识和反思技能的工具

• 试图制度化实践并将其与思维模型联系起来的基础设施

• 促进探究并允许对现有思维进行挑战的文化

森吉（Senge）确定了几个工具，帮助轻松改变思维模型。让我们仔细看看这些工具。

反思性实践

反思性实践是学习过程中进行反思的行为，以判断新信息是否符合现有的思维模型，或者是否需要创建新的思维模型。

反思是调整思维模型的关键工具。那些允许反思的人在这个领域做得很好。

宣称的理论与实际使用的理论

培养反思性实践技能使得进行比较变得容易。一个这样的比较是，宣称的理论与该理论应用之间是否存在差距。

以下是典型的比较方法，用以判断现有思维模型是否有效：

• 质疑抽象跃迁：看看你所看到的是否基于事实，还是仅仅是一个泛化的观点。

• 左栏分析：将某人所思考的内容（写在左栏）与他们所说的内容（写在右栏）进行比较。这个由克里斯·阿吉里斯（Chris Argyris）创造的练习使我们能够看到思想与实际说法之间的差异，揭示我们的先入之见和偏见。

左栏分析可以帮助人们了解他们真正的想法和感受，并以更透明的方式传达这些想法。正确使用时，这种方式可以让对话更具生产力，因为它带来了透明度。

为了进行左栏分析，找一张纸将其分为两栏。选取一次最近的对话，将对话中说的话写在右栏。回忆你对所说内容的想法和感受，并将它们记录在左栏，将想法与所说的内容对齐。

以下表格展示了一个左栏分析的例子。

我 在想什么	说了什么
他难道不知道我已经够忙了吗？我不确定还能应付更多。	老板：你能帮我个忙吗？我：我想可以。什么忙？
真的吗？三个月前我就已经失败了！他真想让我在纽约的更大人群面前再失败一次吗？	上司：由于你三个月前在会议上表现出色，我和市场团队想知道你是否愿意下个月在纽约的会议上发言。 我：那确实很吸引人。
我怎么才能逃避这个任务？	上司：太好了！让我给你发关于会议的详细信息。 我：好的，谢谢！

表格 9.1 – 左列分析，展示了思考与言语之间的区别

定期检查和调整思维模型的能力是第五项学科——系统思维的一个重要推动力。在面对新信息时不调整思维模型，会阻止组织看到整体，从而无法以整个系统的视角进行思考。

一个发展思维模型的例子来自 Scrum。Scrum 团队通常会用故事点来估算故事的工作量。Scrum 团队通常通过计划扑克来估算故事点。在计划扑克中，团队成员聚集在一起，协作发展1 点故事的概念，这个概念指的是完成一个故事所需的最小努力量，并作为相对比较其他故事的基准。

在计划扑克中，团队成员聚集在一起，并被分发一套卡片，上面标有故事点数。产品负责人朗读故事，团队成员分别选择一张卡片，上面显示他们认为该故事所需的故事点数。Scrum Master 作为协调员，随后倒数计时，所有成员同时揭示他们的选择。那些选择不同值的成员被邀请解释他们选择的原因。这个全体成员的讨论帮助团队构建一个关于如何看待整个团队工作的模型。

随着组织中对思维模型的认同逐步建立，它就成为了共享愿景的基础。让我们看看这个共享愿景有多重要。

共享愿景

在第二章《共享责任的文化》中，我们探讨了生成型文化。请记住，生成型文化的成员专注于共同的使命。共享的使命激励成员，团结团队成员，赋予他们专注力，去做任何必要的事情。

这个共享的使命可以被看作是共享愿景，这是 Senge 所说的学习型组织的一项学科。共享愿景简单来说，就是对“我们到底在建设什么？”这个问题的回答。

许多组织从外部导向或注重外部的愿景开始，比如超越其他竞争者。这种类型的愿景存在问题，它们往往是短暂的；一旦实现了目标，接下来怎么办？最好的愿景是内在的，或者说是专注于内部的，这些愿景会让学习型组织在不同情况下不断前进。

另一种可能无法作为共享愿景延续的愿景是消极愿景。消极愿景描述的是组织想要避免的事情，而不是它想要成为的样子。这种思维方式分散了组织所需的能量，剥夺了组织实现长期愿景的机会。回避策略也意味着组织无法改变其命运。这类愿景仅在短期内有效，无法为组织提供任何长期愿景。

共享愿景来自个人愿景。由个人掌控力产生的个人愿景来源并不一定来自领导者或预定的过程。组织中的任何人，只要保持清晰的愿景，并积极质疑当前现实，都能分享他们所发现的东西并邀请他人跟随。

随着愿景的传播，分享愿景并邀请他人跟随时可能会出现多种反应。以下是可以预见的几种反应：

• 招募

• 认同

• 承诺

• 合规性

• 不合规

• 冷漠

在上述列表中，前三项（招募、认同和承诺）是有利的反应，能够帮助将个人的愿景转化为共享愿景。列表中的其他反应（合规、不合规、冷漠）则是达成广泛共识的挑战，而这种共识是愿景成为组织共享的必要条件。

将一个愿景从个人转变为组织的过程确实包含了几个挑战。大量不同的观点可能削弱专注力，并在组织内引发冲突。共享愿景和当前现实之间的差距可能让组织中的人感到沮丧。人们可能会忘记自己是集体的一部分，从而失去彼此之间的联系。

分享愿景可能需要创新的合作方式。在《哈佛商业评论》的一篇文章中（hbr.org/2011/07/are-you-a-collaborative-leader），Salesforce 公司的 CEO 马克·贝尼奥夫邀请了 5000 名员工参加一场虚拟的离线管理会议。结果立竿见影：公司全员参与的对话迅速展开。对话持续了数周，并促成了一个更具赋能感和使命感的公司。

共享愿景的其他建议来自 Empuls 的 Veena Amin 撰写的博客文章（blog.empuls.io/organizational-vision/）。在文章中，她给出了以下建议：

• 统一组织：领导者的任务是找到并汇聚组织的各个部分，传达愿景。

• 让每个人都参与进来：一旦大家都聚集在一起，领导者应与每个人沟通，即使他们的角色在组织中看似不重要或不核心。

• 设定上下文：优秀的领导者会找到一种方式，将愿景与组织当前的状态联系起来。

• 转变控制：愿景的完善需要一种合作方式，这通常意味着要牺牲控制权。为了实现这一点，可能需要在组织层面移除一些控制。

在共同愿景的创建过程中，组织通过应对这些挑战，改进了其他领域的能力。通过个人掌握，愿景将朝着理想现实迈进。个人掌握的过程改变了组织的心智模式。我们会看到，通过团队学习，启动个人掌握并实现心智模式的改变，以达成共同愿景的过程。让我们来探讨团队学习的内容。

团队学习

当从当前现实到共同愿景的个人掌握之旅时，个人需要通过学习来完成这段旅程。一开始，这种学习是个体进行的。有效的团队最终会汇聚在一起，作为一个集体进行学习。这种汇聚就是团队学习。

实现团队学习不是通过团体培训来完成的。团队学习的主要机制来自于组织之间频繁的对话机会。这种对话可以采取以下形式：

• 对话：这种对话形式允许组织达成共同理解

• 讨论：这种对话形式通常是不同观点的交换，随后进行审视，通常是为了看哪种观点占上风

在这两种形式中，组织试图超越个人的理解，达到共同的理解。通常会交换多个观点。对话与讨论的关键区别在于：对话允许不同的选择出现，而讨论则只有一个观点：获胜。

赛基谈到了实现团队学习的对话所需的三项必备条件：

• 能够提出假设，审视它们，并超越这些假设

• 所有参与者都能够把彼此看作同事和平等的人

• 拥有一个专门的引导者，可以为团队保持对话的上下文。

通过前述组件，领导者可以通过对话保持团队的学习。他们帮助团队保持对目标的所有权。

团队学习的另一种机制是意识到防御性惯例。随着团队意识到当前现实与共同愿景之间的差距，防御性惯例可能会出现。一位优秀的引导者可以识别防御性惯例并以以下方式处理它们：

• 直接向组织询问问题的原因

• 将防御性惯例视为团队学习未发生的信号

团队学习的一个例子是“群体编程”。这一实践由 Woody Zuill 开发，是“结对编程”实践的延伸。在群体编程中，团队的一名成员担任“驾驶员”角色，而其他成员则担任“导航员”。“驾驶员”执行主要任务，通常是编写代码，并从“导航员”那里获得反馈。在一段时间后，“驾驶员”角色会轮换给其他团队成员。

群体编程作为一种团队学习方法非常有效，因为团队在合作的过程中，他们同时学习并分享新的见解。

随着团队一起学习并获得对共同愿景的共识，改变思维模型，第五种学科——系统思维出现了。让我们来看一下这个最终的学科，它使学习型组织能够真正繁荣。

系统思维

系统思维是学习型组织通过其他四个学科的适当实践和技能发展所获得的视角转变。学习型组织可以看待自己，看到组成部分和相互联系。

系统思维源自于在开始和改进其他四个学科（个人修炼、思维模型、共享愿景和团队学习）的努力积累。在某些时刻，组织达到了某个学科的成熟水平，能够扩展到系统思维。

当个人调适到个人修炼的状态时，他们开始看到整体以及自己在集体中的角色。这种意识是系统思维的必要部分。

集体整体的意识会影响个人已建立的思维模型。个人的思维模型转变为学习型组织中共享的集体思维模型，并且定义了角色。

对集体思维模型的改变为组织的共享愿景铺平了道路。组织成员对这一共享愿景产生了承诺。他们与团队领导一起合作，通过对话学习如何将共享愿景传递到整个组织，并扩展这一愿景，使其包括学习型组织中的每个人。

可视化系统思维的一种方式是冰山模型。正如 ecochallenge.org 网站上的这篇文章所详细介绍的那样（ecochallenge.org/iceberg-model/），系统思维类似于冰山，只有 10%暴露在水面上，而 90%在水面下，这部分影响着可见部分。

冰山模型详细描述了以下四个层次：

• 事件层次：这是系统思维中唯一可见的层次。这代表了我们对外部世界的感知。

• 模式层次：这个层次试图解释我们在事件层次的感知。

• 结构层次：这个层次解释了我们观察到的模式背后的原因。

• 思维模型：这代表了创造结构的态度、信念和假设。

作为一个采用五大领域的学习型组织，成员们在不断发现的过程中，更多地了解自己以及如何改进。组织定期纳入新的学习，持续改进。让我们通过改进 Kata来看一下这一过程的样貌。

应用改进 Kata

改进 Kata 是源自丰田生产系统的模式之一，并在 Mike Rother 的书籍《丰田 Kata：为改进、适应性和卓越结果管理人员》中有详细描述。在改进 Kata 中，我们通过以下四个步骤朝着改进的方向前进：

1. 我们设想我们的理想未来状态。

2. 我们审视当前的状态或状况。

3. 我们确定下一个目标，使我们更接近理想的未来状态。

4. 我们进行实验，在计划-执行-检查-调整（PDCA）或精益改进循环中评估和学习，看看结果是否将我们更接近理想的未来状态。

改进 Kata 四个步骤的示意图如下：

图 9.1 – 改进 Kata

使用改进 Kata 的一个例子是敏捷回顾会。回顾会是团队定期举行的会议，在会议中，团队会考虑以下问题：

• 做得好的方面是什么？

• 做得不好的方面是什么？

• 我们应采取哪些行动（包括保持有效的做法）来实现改进？

前两个问题让我们探索当前状态和未来状态。第三个问题则启动了向理想未来状态前进的行动。在 Scrum 中，这些行动被添加到团队的工作待办事项中，团队可以在这些事项上工作。通过这种方式，团队利用 PDCA 学习循环朝着理想状态前进。

通过目标逐步实现理想的未来状态，需要不断的实验。这些实验是在遵循 PDCA 格式的学习循环中进行的。让我们看看在每个精益 改进循环中会发生什么。

关闭精益改进循环

持续改进是精益思维的核心。改进应融入到未来的工作中，并通过有效性进行衡量。

为了使我们的价值流采用这种方法，必须将其工作视为一个学习循环。这个循环最流行的模型是精益改进循环或PDCA循环。

这个循环与 W. Edwards Deming 相关，他称之为谢瓦特循环（Shewhart cycle），以纪念 Walter Shewhart。这一循环在下图中有所说明：

图 9.2 – PDCA 循环

如前面的图所示，该循环有四个活动阶段：

1. 计划：确定采取什么迭代步骤。这可能是一个在待办事项列表中优先级较高的步骤。制定实施该步骤后可能发生的结果假设。

2. 执行：将该步骤添加到你的价值流工作流程中。

3. 检查：检查（或持续检查）你为价值流测量的指标。

4. 行动（或调整）：执行这一步骤是否达到了假设？如果达到了，就保留该步骤。如果没有，可能需要通过制定另一个假设来进行调整。

这个周期可以在短期和长期内执行。在 SAFe®中，实践 Scrum 的 ART 团队将每个冲刺进行这个周期的操作，并与其他 ART 团队一起，在每个程序增量（PI）中执行这个周期。

总结

本章中，我们探讨了价值流如何通过采纳持续学习和实验来遵循第三种方法。我们看到，这一切始于组织成为学习型组织的旅程。它们通过个人精通、心理模型、共享愿景、团队学习和最终的系统思维五大学科来磨练自己的学习。

学习型组织朝着共同愿景迈进的一种方法是遵循改进卡塔。在改进卡塔中，在确定了理想的未来状态之后，识别当前状态。然后，价值流识别一个目标并进行实验。实验在 PDCA 周期中进行，学习成果用于判断价值流是否更接近或远离理想的未来状态。

精益改进周期或 PDCA 周期被用作改进卡塔的实验框架。价值流规划实验，执行实验，并检查结果是否验证了实验的假设。根据结果，价值流会做出调整。

这完成了本书的第二部分，我们讨论了如何在价值流中对齐工作，如何衡量价值流交付价值的效果，以及如何根据价值流的指标，走上持续学习的道路以改进价值流。在第三部分，我们将探讨在 SAFe 中，作为 ART 的价值流如何通过流程和技术的结合（称为持续交付管道）来执行交付价值的任务。

问题

通过回答这些问题来测试你对本章概念的理解。

1. 在个人精通中，是什么与愿景产生了冲突？

   1. 虚拟现实

   2. 当前现实

   3. 渴望的现实

   4. 过去的现实

2. 哪些类型的讨论有助于团队学习？（选择两个）

   1. 冲突

   2. 对话

   3. 讲座

   4. 讨论

   5. 独白

3. 改进卡塔的第一步是什么？

   1. 确定理想的未来状态

   2. 确定当前状态

   3. 确定一个目标

   4. 执行 PDCA 周期，以迭代达到目标

4. PDCA 周期中的C代表什么？

   1. 结论

   2. 停止

   3. 检查

   4. 资本

进一步阅读

• 《凤凰项目：关于 IT、DevOps 和帮助你的业务成功的小说》 by Gene Kim, George Spafford, and Kevin Behr – 我们使用这本书及其三种方法讨论价值流的创建和维护。

• 《第五项修炼：学习型组织的艺术与实践》 by Peter M. Senge – 在学习如何成为学习型组织时的参考书。

• valshebnik.com/blog/left-hand-column/：本文优秀地描述了左手列分析，包括定义、示例和危险。

• hbr.org/2011/07/are-you-a-collaborative-leader：本文探讨了领导者如何与公司合作和分享。

• blog.empuls.io/organizational-vision/：本文探讨了分享组织愿景的益处、技巧和窍门。

• ecochallenge.org/iceberg-model/：描述冰山模型的文章，展示系统思维。

• 《丰田方式：管理人员的改进、适应性和优异成果》 by Mike Rother – 关于改进方式的详细方法。

第三部分：优化 – 启用持续交付管道

在 SAFe®中，持续交付管道是过程和自动化的结合，允许价值流（作为敏捷发布列车（ARTs）实施）按节奏开发和部署，但在适合组织时按需发布。

我们将从持续探索开始探索持续交付管道。通过持续探索，我们将把新解决方案或增强的想法设置为实验，以便详细阐述、研究和为 PI 计划设置优先级。

在持续集成阶段的持续交付管道中，我们将开发我们的实验。在编码后，我们将开始自动化过程，以允许测试和打包（如果测试成功）。

在持续部署期间，我们将努力将我们的解决方案部署到生产环境。我们将努力在不干扰生产环境和客户的情况下部署这些变更，同时允许在生产环境中进行测试。我们将讨论如何在第十二章中执行部署和发布分离的方法。

最后，我们将按需发布。这使我们能够向客户交付价值。我们将监控发布，确保验证我们实验的假设，并且在安全性或可用性方面不会对生产环境造成不良影响。

本书的这一部分包括以下章节：

• 第十章，持续探索与发现新功能

• 第十一章，解决方案开发的持续集成

• 第十二章，持续部署到生产环境

• 第十三章，按需发布以实现价值

第十章：持续探索与发现新特性

在持续探索阶段，产品管理团队与敏捷发布列车（ART）内外的人一起工作，寻找能够为客户提供价值的特性，探索客户的需求与愿望，验证新特性在当前架构中的可行性，并为 ART 准备待开发的新特性。

正如我们在以下插图中看到的，持续探索是持续交付管道的第一阶段，它为后续的开发建立了触发点：

图 10.1 – 持续交付管道（© Scaled Agile，版权所有）

简而言之，本章将讨论以下活动：

• 假设客户价值

• 协作与研究

• 关于架构的讨论

• 综合工作

产品管理在持续探索阶段所做的工作对 ART 来说非常重要，因为它有助于为 ART 执行共享任务或愿景设定背景。让我们来看一下产品管理为即将到来的项目增量（PI）所做的准备工作。

假设客户价值

“如果我问人们他们想要什么，他们会说更快的马。” 这句常被（可能错误地）归于亨利·福特的话，突出了产品经理在寻找新特性或新产品时遇到的问题。客户可能根本不知道自己想要什么，或者无法想象那些来自不同思路或创新方法的产品和特性。

通过解决产品开发中的未知问题的一种方法，是采用埃里克·里斯（Eric Ries）在《精益创业：当今企业家如何利用持续创新创造极为成功的企业》一书中强调的方法。在这本书中，里斯展示了一种与客户协作进行迭代式产品开发的方法，其中一些方法体现在他提出的学习循环中，即构建-衡量-学习循环。

构建-衡量-学习循环是一个迭代式的产品开发循环，在这个过程中，精益创业公司通过实验发现与客户产生共鸣的产品和特性。该循环的以下部分是在客户参与下完成的：

• 构建：通常，第一次迭代中出现的最小可行产品（MVP）是启动与客户学习过程的关键。

• 衡量：与客户的对话或度量指标的应用，帮助确定什么有效，什么无效

• 学习：凭借从先前收集到的度量数据中获得的知识，做出是否调整方向或坚持下去的选择

构建-衡量-学习循环在以下图示中得以说明：

图 10.2 – 构建-衡量-学习循环

构建-衡量-学习循环与精益改进或 PDCA 循环的周期相同，后者在《第九章》中讨论过，通过持续学习迈向未来。构建发生在 PDCA 循环的计划和执行阶段。衡量则是我们在 PDCA 循环中的检查步骤。一旦完成衡量步骤，我们通过转型或坚持来学习（或调整）。

在明确了构建-衡量-学习循环的三个部分后，让我们来审视第一个循环以及它如何使用 MVP。

使用 MVP 进行构建

创建 MVP 是精益创业公司学习之旅的第一步。它为这些初创公司提供了一种检查手段，用来判断他们是否走在正确的道路上。虽然不同的人对 MVP 的定义有不同的看法，包括我们稍后会探讨的 SAFe®，但我们先来看看 Eric Ries 在《精益创业：今天的企业家如何运用持续创新创建极具成功的企业》中提出的定义。

根据 Ries 的说法，MVP 不一定非得是一个实际的产品，或者是最终形式的产品。唯一的必要条件是它能向顾客传达产品或服务的某种信息。

以下是 Ries 引用的作为 MVP 示例的几个例子：

• Dropbox 制作了一个视频，帮助顾客理解基于云的文件存储和同步的概念，并解释其相对于竞争对手的优势。

• Groupon 最初是一个 WordPress 博客，顾客通过电子邮件请求提供作为新博客文章发布的 PDF 优惠券。

• 总部位于奥斯丁的初创公司 Food on the Table 开始提供服务，通过与第一位顾客紧密合作，聚合顾客购物清单和食谱中的食材，并在当地杂货店完成采购，从而定义服务内容和工作方式。

这些例子表明，MVP 是为了回答以下问题而构建的：

• 我们的产品或服务应该是什么样子？

• 我们的产品或服务能与顾客产生共鸣吗？

• 我们能提供这个产品或服务吗？

初创公司通过与顾客对话，并将创新会计应用到对他们来说重要的指标中，来回答这些问题。让我们来看一下创新会计中使用的衡量标准。

使用创新会计进行衡量

创建 MVP 的目的是验证或推翻 Ries 所说的“信念假设”。在看“构建-衡量-学习”循环时，MVP 经历三个里程碑。这些里程碑有助于评估 MVP 的进展，并说明学习中的关键检查点：

1. 确立基准：创建 MVP 是一个基准，用于验证“信念假设”是否有效。这个假设也可以被视为一个假设，实验（MVP）可以验证它。

2. 调整引擎：根据客观数据，我们应该着眼于做出调整，帮助我们更接近目标。

3. 转型或坚持：根据我们收集的数据，可能促使我们继续当前的路径并进行进一步的优化，或者进行转型。转型可能会让我们为产品或服务选择不同的道路。

对于客观数据，我们要避免虚荣指标。我们之前在第五章中讨论过 Ries 最初对指标的标准，即衡量过程和解决方案。以下品质在此重复：

• 可操作性：这个指标是否显示了清晰的因果关系？换句话说，通过执行相同的操作，你能否复制出相同的结果？

• 可访问性：价值链中的每个人是否都能访问相同的数据，并且这些数据是否能被所有人理解？

• 可审计性：报告是否有可信度？

当然，最好的数据来源是直接的消费者反馈。在许多情况下，如果你无法理解指标所传达的信息，你可能需要通过采访客户来获得进一步的洞察。

通过从真实的指标或客户反馈中收集到的客观数据，接下来需要做出决策，以确保初创企业的持续性。我们是否需要为我们的 MVP（转型）走不同的方向，还是继续当前的方向并增加更多的改进（坚持）？让我们来分析决定中涉及的因素。

学会转型或坚持

根据客户反馈或客观数据，精益创业法有一个问题需要回答：我们当前产品或服务的方向是否能让我们实现目标，并为客户提供价值？如果可以，那我们就继续沿着这条道路走，增加更多的功能。如果不行，我们则需要毫不犹豫地转向另一个方向，或者进行转型。

转型可能是对产品或服务的一个或多个方面进行改变。Ries 列举了以下几种转型，旨在帮助产品或服务提供更好的价值：

• 缩小范围转型：产品或服务的某一功能比其他任何功能都更能引起客户的共鸣。你将专注于这个功能，并使其成为产品或服务的核心。

• 放大范围转型：产品或服务本身并未提供足够的客户价值，但如果作为另一个产品或服务的功能捆绑在一起，可能会证明其价值。

• 客户细分转型：产品或服务不仅满足了最初目标客户的需求，还能满足其他客户的需求。

• 客户需求转型：在与客户合作时，你可能会发现通过不同的产品或服务可以提供更大的价值。例如，Potbelly 三明治店最初是一家提供食物的古董店。

对于大多数类型的转型，产品或服务会发生变化，通常会发生到完全不同于原始产品或服务的程度，但也有一些转型，MVP、产品或服务会被放弃。

面对任何类型的转型前景时，保持客观判断是否转型或坚持非常重要。许多初创公司失败的原因是他们没有及时转型，或者转型过晚。

现在我们已经了解了如何创建我们的 MVP 并通过构建-测量-学习循环验证我们的假设，让我们来看一下 SAFe®如何将构建-测量-学习和创新会计纳入 SAFe 精益创业循环，这一循环将实验应用于史诗的执行。

SAFe®精益创业循环

在 SAFe 中，史诗是一项重要的产品开发工作，不限定在特定的时间框架内。史诗描述了一个组织可能希望对产品进行的长期变更。ART 团队将史诗作为实验，用以指导可能的产品开发。

请注意，虽然史诗和项目可能有相似的定义，但史诗的范围是灵活的。项目有明确的开始和结束日期，以及固定的范围，所有需求必须通过完成构建交付物的任务来满足。而史诗实际上为实验奠定了基础，实验可能会也可能不会完成。

史诗由精益商业案例描述，精益商业案例是一个简短的文档，概述了史诗的需求、可能的解决方案选择以及实验提案。实验以史诗假设声明的形式编写，描述了提议的价值、业务成果的假设、通过领先指标衡量实验的结果以及可能作为约束的任何非功能需求（NFRs）。MVP 被包含在精益商业案例中，作为实验的实施内容。

史诗的假设声明通过概述提案、其潜在收益、拟议的衡量标准和约束条件，为实验设定了基调。以下是一个史诗假设声明的示例，详细描述了一个提议的披萨无人机配送服务：

史诗描述

• 针对居住在城市地区的客户…

• 希望快速便捷披萨配送的客户，

• PizzaBot 2022…

• 是基于无人机的自动化披萨配送系统…

• 那些能快速、轻松地从餐厅配送披萨的客户。

• 与当前基于汽车的披萨配送（标准配送方式）不同，

• 我们的解决方案通过使用更便宜的电力而非汽油来降低开销成本。

|

商业成果

• 更好的客户体验，配送时间更快（披萨更热）

• 通过减少送货司机并节省燃料来降低开销成本

|

领先指标

• 平均配送时间减少

• 开销成本减少

• 更高的 NPS 调查分数

|

非功能需求	必须遵守有关商业空中无人机使用的当地条例

表格 10.1 – 史诗假设声明示例

史诗中的 MVP 与 Ries 的定义有所不同。在这里，MVP 指的是一套最小的功能特性，用于构建一个初步产品，供客户使用。这些特性将由 ART 开发。

领先指标度量用于验证我们实验的假设。它们可以告诉我们是否走在正确的道路上。我们希望我们的度量是可操作的、可访问的和可审计的，这样它们就不是虚荣指标。我们还希望它们是真正的领先指标，即在最早的时刻就能可靠地预测潜在价值，而无需等待趋势的出现。

SAFe 精益创业周期确实以 Eric Ries 提出的构建-测量-学习循环为模型。在 SAFe 精益创业周期中，ART 与史诗按以下方式合作：

• 构建：开发并发布 MVP 给客户

• 测量：史诗的精益商业案例中定义的领先指标度量决定了客户的反馈

• 学习：根据领先指标度量，必须做出决策，决定是坚持继续开发 MVP 之外的功能；还是转变方向，按照现有状态完成史诗，并创建一个包含新假设的新史诗；或者停止该史诗，不再开发 MVP 之外的内容。

以下图表展示了 SAFe 精益创业周期，概述了史诗的路径以及根据假设验证可能发生的路径：

图 10.3 – SAFe 精益创业周期（©Scaled Agile，保留所有权利）

这一活动的结果是史诗的待办事项列表。每个史诗都概述了一个实验，其中包含潜在价值的假设陈述和一个 MVP，使我们能够执行该实验。

基于构建-测量-学习循环的 SAFe 精益创业周期，产品管理建立价值假设和 MVP 作为验证假设的实验，但产品管理并非单独进行此操作。他们与他人合作，在周期的构建部分共同完善假设和实验。我们将在下一节探讨这种协作。

协作与研究

产品管理需要来自不同人员的输入，每个人对解决方案的需求都有独特的看法。优秀的产品经理知道，他们必须与这些人合作，发现能够构成利益假设基础的特性，或者 MVP 必须具备的功能。

在这里，我们将看看良好的产品管理需要形成 MVP 的两个方面。以下方面构成了产品管理开展 MVP 相关活动的基础：

• 与客户和利益相关者的合作

• 研究以引出产品特性和非功能需求（NFRs）

让我们从产品管理协调的主要协作开始。

与客户和利益相关者的合作

最好的产品是团队共同创造的。从早期阶段到设计、实施和测试阶段——最终导致发布，这一过程都是如此。

产品开发与以下人员合作，定义产品的特性：

• 客户

• 系统架构师或工程师

• 业务负责人

• 产品负责人或团队

让我们来审视产品管理与这些团队合作所创造的关系。

客户

客户是价值的最终裁定者。毕竟，他们是你为之构建产品的人。他们的反馈是评估产品是否满足需求的最直接来源。

除了那些可能不知道自己需要什么解决方案的客户，产品管理团队还必须关注那些只专注于做增量改进的客户，因为这种做法可能不会有助于产品的长期战略。

系统架构师

系统架构师从架构角度最了解产品。他们理解由启用工具确定的能力，以及由非功能需求（NFRs）识别的约束。

产品管理团队与系统架构师合作，了解新特性的平衡、使用启用工具进行长期开发、以及维护和减少技术债务的重要性，这一点至关重要。同时，系统架构师也需要了解客户的需求和关注点。因此，产品管理、系统架构师与客户之间的密切合作至关重要。

业务负责人

业务负责人是从组织角度来看最关键的利益相关者。他们需要确保 ART 开发的解决方案与组织的使命和整体战略保持一致。

产品管理与业务负责人合作，了解 ART 可能处理的特性优先级。

产品负责人和敏捷团队

ART 上的敏捷团队负责开发、部署、发布和维护解决方案。每个敏捷团队中的关键人物是产品负责人，他们作为内容权威，帮助团队详细描述故事和验收标准，并接受完成的故事。

因为团队最接近实际工作和实施，他们对产品和用户关注点的洞察不容忽视。优秀的产品经理会采纳敏捷团队的反馈。

现在我们已经了解了产品管理与哪些角色进行合作并接受反馈。接下来，我们应该审视这些反馈将以什么形式呈现。

研究活动

产品管理通过以下几种研究活动与客户、业务负责人和产品负责人合作，获取客户需求的洞察，并了解产品如何创造价值：

这些类型的活动可以分为以下几类：

• 与客户的主要市场调研

• 通过前往现场（Gemba walks）和客户拜访，了解客户体验

• 次级市场调研，以进一步深入了解客户的思维方式

• 精益用户体验（Lean UX）来建立实验

让我们来逐一审视这些活动。

主要市场调研

初级市场调研特点是产品管理和客户之间的直接合作。此类直接合作可能包括以下方法：

• 焦点小组

• 用户调查或问卷

• 创新游戏

焦点小组、调查和问卷直接询问产品或服务的问题。它们可能会涉及潜在的未来需求，但有时客户无法超越短期产品使用的想象。

这就是创新游戏的作用所在。创新游戏是《创新游戏：通过协作游戏创造突破性产品》（作者：卢克·霍曼）中描述的几项活动。在书中，游戏有助于发现未被言明的需求、客户如何看待成功以及你的产品如何与客户需求契合。

初级市场调研通常在组织内部进行，但也可以在其他地方收集到更多的见解。此时，Gemba 走访和客户现场访问就显得尤为重要。我们现在来了解一下它们。

Gemba 走访

Genchi genbutsu在日语中意为“亲自去看并理解”。Gemba 走访是一项体验genchi genbutsu的活动。它最早应用于丰田生产系统，是精益思维的核心内容。在 Gemba 走访中，人们会亲自到产品使用的地方，了解实际环境。

《精益创业：今天的企业家如何利用持续创新创造极其成功的企业》（作者：埃里克·里斯）中的一个 Gemba 走访的例子。2004 年丰田赛那迷你货车的设计由横谷裕司主导。他在北美市场的经验较少，而赛那的目标市场正是北美。因此，他提出了一项计划：在一辆现有的赛那迷你货车中，进行一次覆盖加拿大各省、美国五十个州及部分墨西哥的公路旅行，同时采访客户。

横谷发现，北美客户比日本客户进行更多的长途汽车旅行。另一个发现是，迷你货车需要更好地服务于通常占据车内三分之二空间的乘客：孩子们。根据这些数据，横谷添加了更多具有儿童吸引力的功能，以便更好地适应长途旅行。

这些功能的选择产生了深远的影响。2004 年款赛那车型的销量比前一年增长了 60%。

二级市场调研

二级市场调研是指不涉及与客户直接合作的活动。这些活动有助于了解客户和市场。

一些让你了解客户需求和愿望的活动包括以下内容：

• 创建人物角色，虚构的客户代表

• 使用同理心图了解客户的想法和情感

• 通过旅程地图检查客户的旅程，包括情感

这些文档在与客户会面时可以进行完善和修改。

精益用户体验（Lean UX）

在开发功能时，我们希望使用类似于 Build-Measure-Learn 的 PDCA 学习循环。这种增量学习循环帮助我们将史诗细化为功能。

这种类型的一个循环来源于 Jeff Gothelf 和 Josh Seiden 所著的《Lean UX: Designing Great Products with Agile Teams》一书。书中提到的 精益用户体验（Lean UX）是一种心态和过程，通过逐步发现产品功能并验证客户价值。

Scaled Agile 已将这一过程模型调整为适用于 用户界面（UI）和 用户体验（UX）团队以外的领域。以下来自 Scaled Agile 的图表展示了这一过程：

图 10.4 – 精益 UX 过程图（© Scaled Agile, Inc. 保留所有权利）

让我们逐步分析过程的每个步骤。

构建效益假设

在开发初期，无法知道哪些功能能够让客户感到满意，因为环境中的不确定因素和风险尚未明确。增量设计周期的第一部分旨在建立一个假设，假设该功能被开发并发布后，能够实现预期的可衡量的业务结果。如果该功能是史诗的 MVP 一部分或是史诗进一步开发的一部分，那么这个效益假设可能与史诗的假设相关。

协作设计

有了效益假设，ART（产品管理、系统架构师、业务负责人、产品负责人和敏捷团队）成员与客户需要共同合作，生成作为产品设计元素的工件。

构建最小可市场化功能

最小可市场化功能（MMF）是指功能包含的最少量功能，以验证或推翻某个效益假设。ART 可以通过迭代方式实现这一点，以便了解他们在效益假设上的进展情况。

有时，MMF 可能是一个轻量级的工件，没有功能，目的是生成客户反馈，如原型或线框图。其他时候，MMF 可能会被开发并发布，以便客户可以评估并提供反馈。

评估

MMF 发布后，我们等待看看客户的反应。我们可以通过观察和 A/B 测试收集客观数据，也可以通过调查问卷向客户询问反馈。

根据数据，我们可以决定效益假设是否得到了验证。这可能会让我们继续开发、重构，甚至调整方向放弃该功能。

合作和研究活动的结果让我们理解客户的需求，并根据这些需求设计功能。以下工件可能是这一活动生成的：

• 了解客户需求

• 风格指南

• 标志

• UI 资产

• 原型

• 模型或线框图

• 角色画像

• 客户旅程地图

当产品管理团队努力理解产品特性时，系统架构师需要了解产品的架构，并知道哪些使能者是维持产品功能流动所必需的。我们来看看系统架构师在持续探索中的角色。

架构解决方案

作为产品架构的维护者，系统架构师需要跟踪产品的功能，并通过创建使能者来增强这些功能，同时理解由非功能需求（NFRs）所识别的系统限制。

与 ART 团队或组织中的其他成员合作，系统架构师将探索产品的以下方面，以确保满足非功能需求（NFRs）：

• 可发布性

• 安全性

• 可测试性

• 操作需求

让我们更详细地审视这些方面。

架构可发布性

通常，按照组织的决策，将新功能发布给客户是可取的。我们仍然希望将生产环境部署作为开发节奏的一部分，但实际发布则变成了一项商业决策。因此，我们希望将部署和发布分离。

架构可能在实现部署与发布的分离中发挥关键作用。部署与发布的分离依赖于诸如功能标志（Feature Flags）等技术，而架构必须能够支持这些技术。这些功能标志可以轻松实现新功能的持续部署，而在关闭时不会干扰当前的功能。当功能标志被开启时，新功能被认为已经发布。功能标志的应用包括金丝雀发布和暗发布（Dark Launches）。具有松耦合组件的架构允许每个组件拥有独立的发布计划，这使得需要不同发布策略的组件能够各自独立实施。

最终，发布策略通常与组织的战略或商业目标相关。发布可能需要响应市场需求或超越竞争对手。能够灵活发布是一个竞争优势。我们将在第十三章中看到这一远见的好处，按需发布以实现价值。

设计安全性

尽管 DevSecOps 强调将安全性测试“左移”，即在开发过程中提前测试安全漏洞和问题，但 DevSecOps 方法在此开始，架构师会在绘制新功能时将安全性考虑在内。这使得安全性从一开始就被纳入设计，而不是事后补充的思考。

为确保在初步设计中包括安全性问题，必须执行以下实践：

• 威胁建模：审视当前产品的基础设施、架构、应用程序以及拟发布的功能，以识别可能的安全漏洞、攻击者和攻击路径。

• 合规管理：确保产品符合已知的行业安全法规标准，如 HIPAA、FedRAMP 和 PCI。这些标准中的要求主要涉及安全性和隐私保护。

这些实践的输出通常作为 NFRs 维护并向 ART 传达。NFRs 是 ART 开发的特性的工作约束。这些约束应该作为开发继续进行的持续测试套件的一部分。

确保可测试性

测试是确保功能正确、质量高、安全性好并且准备部署的主要方式。如果一个解决方案不能进行测试，ART 无法了解其进展或者是否可以实现价值。

正如我们之前所看到的，松耦合架构允许通过在不同时间表上发布组件来提高灵活性。这种灵活性延伸到设计允许更多测试发生的系统。具有定义良好接口的组件的系统，允许通过使用尚未准备好与其他组件集成的组件，替换为返回有效输出的虚拟代码或逻辑，来进行更频繁的系统级测试。

使用Strangler 模式，现有的遗留架构可以演变为基于现代松耦合应用程序编程接口（API）的架构。由 Martin Fowler 创造的 Strangler 模式将遗留的单体系统建立了一个面向这些实体的接口。新的代码逐步替换接口的各个部分。最终，所有遗留系统的功能都被新代码所取代。

另一个考虑测试性的设计方面是能够在各个层次上执行自动化测试，从单个代码函数到用户故事，最终到功能。自动化测试允许更频繁地执行测试。频繁的测试可以增加对系统质量和安全性的信心。

可测试的架构对于实施工作的敏捷团队有益。测试驱动开发（TDD）试图首先创建测试，形成对系统行为的初始理解。行为驱动开发（BDD）继续在更高层次上理解系统的行为。

维护操作

一旦特性通过了所有测试，架构设计的考虑因素不应该改变。系统架构师必须确保该架构在非生产或者暂存环境以及最终的生产环境中轻松运行。

这其中的第一个方面是可测量性。架构应允许在不同环境（如分阶段和生产环境）中监控其资源，以判断当前系统是否存在不良性能。当阈值被违反时，应设计警报。这种从低到高资源使用的测量能力通常被称为全栈遥测（full-stack telemetry）。

另一个方面是能够将所有度量记录到日志中，以便在发生事件时便于检索。架构师应该理解架构中哪些方面能够提供可作为日志捕获的洞见，以便运营人员可以将这些度量添加到日志工具中，该工具包括时间戳和搜索功能。

可发布性在确保架构易于操作方面起着作用。特性标记（Feature Flags），作为将生产环境的部署与客户发布分离的常见工具，可以作为回滚机制，在发生事件时通过停用受影响的特性来实现回滚。另一个需要考虑的回滚机制是在生产环境中建立蓝绿部署。CI/CD 管道中的可靠自动化，包括强大的自动化测试，可以支持 修复前进（fix-forward）的情况，其中事件修复可以尽快推送到生产环境。

架构师工作的输出包括解决方案意图，证明史诗（epic）效益假设所需的最小架构概念，以及 NFRs（非功能性需求），它们作为所有从史诗中派生的特性和故事的约束条件。

此时，产品管理和系统架构师已经完成了对特性在价值和架构影响方面的初步思考。其他人需要发挥他们的作用，从进一步细化和优先级排序，到为 PI 规划做好特性准备。让我们现在来看这些步骤。

综合工作

产品管理已收集了关于客户需求的知识和额外的研究，这些内容可能有助于预期的价值。系统架构师已着手确保当前已有或即将提供支持的架构功能。产品管理与业务所有者、产品所有者、敏捷团队及其他相关方合作，完成以下活动：

• 完成特性的定义

• 使用 BDD 来概述验收标准

• 使用 加权最短作业优先法 (WSJF) 对程序待办事项中的特性进行优先级排序

• 为 PI 规划做准备

综合的目标是为即将到来的 PI 做好 ART 的准备。为此，我们将创建以下工件：

• 对 ART 将要开发的内容有清晰的愿景

• 一份路线图，详细说明产品的演进，通过展示可能的解决方案何时交付

• 已定义特性的待办事项列表

让我们详细审视一下在综合阶段完成的这些活动。

完成特性

记住，我们一开始是从作为实验进行的重大产品工作（epics）开始的。我们通过开发 MVP（最小可行产品）来开始我们的实验。MVP 将是一个功能集，用于验证史诗的利益假设。使用精益 UX 方法，我们进一步将 MVP 细分为 MMFs（最小市场功能），这些最初是基于在了解客户需求和期望后产生的假设。产品管理和系统架构师的研究为此添加了更多细节。现在是时候完成完善工作，以便其他 ART 团队可以接手。

一个好的功能将包含以下三个部分：受益人、利益假设和验收标准。让我们更详细地讨论这些部分。

受益人

当我们考虑组织或客户的价值时，现在必须考虑我们产品或服务的最终用户。有时，最终用户不是购买该产品或服务的人。在这些情况下，我们可能需要挑战客户对于最终用户需求和期望的假设。

利益假设

我们希望在开发和发布该功能时，能够说明其对客户或组织的好处。因此，我们可以使用以下格式来创建我们的利益假设：

如果{proposition}，{**则利益}

我们的命题是对功能的描述。利益是预期的价值输出。

我们可能希望包括一些我们认为能够证明或反驳我们利益假设的指标。如果是这样，我们可以使用以下格式来包含我们的衡量标准：

我们相信{proposition}将导致{benefit}，并且当{metric}时，这将得到证明。

例如，假设我们之前在本章中定义的空中披萨无人机的史诗。一个可能的功能是增加一个内置加热单元，在送披萨的过程中保持披萨的温度。以下陈述可以作为该功能的利益假设：

我们相信，内置加热单元的无人机将通过确保披萨送达时不会变冷来提高客户满意度，并且当我们查看 NPS 调查结果时，这将得到证明。

在这里记住要避免使用虚荣指标——这些指标可能会产生正面反应，但通常无法表明是否真正实现了预期的价值。

验收标准

验收标准是确认实现已完成并且利益得以交付的衡量标准。它们是包含该功能后的系统行为描述。

通常，要评估一个利益假设是否已被验证，可以将多个验收标准映射到一个单一的利益假设声明上。

由于验收标准描述了系统的行为，我们将在下一部分中讨论如何使用 BDD（行为驱动开发）技术编写验收标准。

使用 BDD 编写验收标准

在上一节中，我们探讨了接受标准的作用。接受标准的一个关键作用是，它们描述了功能包含时系统的行为。这种描述会转化为组件的期望行为，以用户故事或代码功能的形式呈现。

我们在 Gherkin 格式中指定期望的行为。Gherkin 格式采用以下结构：

GIVEN (the initial conditions)
WHEN (an input that triggers the specific scenario occurs)
THEN (the desired behavior happens)

WHEN 和 THEN 可能包含一个或多个条款，描述相应的条件和行为。

延续我们关于为披萨无人机配置内置加热单元功能的示例，我们可能希望以下语句作为接受标准：

假设加热单元已安装并 加热完毕…

…当披萨在配送过程中被放入加热单元时…

…那么，当披萨送达时，它将是热的。

采用这种格式的接受标准可以作为自动化验收测试的基础。这些自动化验收测试使用 Cucumber 进行执行，Cucumber 是一种运行 BDD 测试的测试工具。

使用 WSJF 优先排序

一旦产品管理根据受益方、效益假设和接受标准指定了功能，就会将其放入项目待办事项中。

项目待办事项是 ART 可以处理的功能列表。由于 ART 在一次性处理的功能数量上有限，因此产品管理需要对功能进行优先排序，使工作更具聚焦性。

有多种标准可以用来确定在项目待办事项中功能的优先级。SAFe 提倡参考原则 1：采取经济视角，我们最初在第二章中看到过这一点，共享责任文化，在对功能进行排序时需要关注这一点。

我们从关注功能的延迟成本（CoD）开始经济视角的分析。延迟成本是指如果我们推迟发布功能，价值将会减少多少。延迟成本可以由以下几个因素构成，且这些因素可以相对估算：

• 用户业务价值：与项目待办事项中的其他功能相比，预计该功能将产生多少价值？

• 时间紧迫性：如果一个功能未能及时实现，是否会导致价值下降？我们是否错过了一个重要的市场机会？

• 风险减少或机会启用（RR/OE）：是否有其他重要方式能使某个功能降低风险，或者让组织接触到新市场？

SAFe 关注的另一个因素是工作的大小。我们希望优先处理最短的工作。处理时间较短的工作并快速获取价值比从较大的工作开始更容易。

SAFe 将对延迟成本和工作大小的关注结合成一个公式，称为 WSJF。这个公式可以具体如下所示：

如果我们查看前面的公式并代入我们的 CoD 因素，可以将公式改写如下：

产品管理可以与业务负责人、系统架构师以及其他相关方在精炼会议中合作，确定每个特性的 WSJF 值。参与者根据四个组成部分（用户商业价值、时间紧迫性、RR/OE 和工作量）的相对价值进行判断，通常使用修改过的斐波那契数列（1，2，3，5，8，13，20，40，100）来评估。

让我们看看产品管理如何与其他方合作，计算不同特性的 WSJF 值。

小组将召开会议，审查所有特性。然后他们会决定哪个特性的用户商业价值最小 – 该特性的用户商业价值将标记为1。接着他们会查看其他特性，并决定它们的用户商业价值与参考特性相比如何。如果它们被认为相同，它们也会获得1。如果其他特性更大，他们将在斐波那契数列上标出一个数字，表示它比参考特性大多少。

下表展示了在进程中确定用户商业价值的协作过程：

特性名称	用户商业 价值	时间紧迫性	RR|OE	延迟 成本	工作量	WSJF
内置加热单元	8
无人机防御系统	1
反推力推进器	5

表 10.2 – WSJF 协作示例 – 用户商业价值定义

该过程会重复进行时间紧迫性、RR/OE 和工作量的计算。对于上表，表示用户商业价值、时间紧迫性、RR/OE 和工作量的列，必须至少有一个1。下表继续展示我们的示例，其中时间紧迫性、RR/OE 和工作量也已定义：

特性名称	用户 商业价值	时间 紧迫性	RR|OE	延迟 成本	工作量	WSJF
内置加热单元	8	8	1		1
无人机防御系统	1	13	3		2
反推力推进器	5	1	1		5

表 10.3 – WSJF 示例继续 – 时间紧迫性、RR|OE 和工作量定义

CoD 通过将用户商业价值、时间紧迫性和 RR/OE 相加来计算。WSJF 通过将 CoD 除以工作量来计算。下表完成了我们特性 WSJF 的确定：

特性名称	用户商业 价值（UBV）	时间紧迫性（TC）	RR|OE	延迟成本（CoD） = UBV+TC+RR|OE	工作量（JS）	WSJF（CoD/JS）
内置加热单元	8	8	1	17	1	17（第一）
无人机防御系统	1	13	3	17	2	8.5（第二）
反推力推进器	5	1	1	7	5	1.4（第三）

表 10.4 – WSJF 确定示例 – 完整

在项目待办事项中的新功能定期进行优化会议，使产品管理能够了解需要优先完成的功能。这将影响项目愿景和产品管理将在 PI 规划中与 ART 沟通的路线图。

准备 PI 规划

有了优先级排序的项目待办事项，产品管理和 ART 的其余成员可以了解即将到来的 PI 的初步工作范围。理想情况下，这些活动应该至少在实际 PI 规划事件前一个月完成，以便及早发现任何意外情况。

业务负责人将准备一份演示文稿，帮助 ART 了解业务背景，并说明所选功能的开发如何与整体业务战略对接。

系统架构师还将准备一份演示文稿，概述重要的架构说明和变更。这可能还包括 ART 为发布开发的任何重要使能器。

剩下的就是综合结果的输出。产品管理将在 PI 规划之前努力组装以下文档：

• ART 能够交付的解决方案的愿景

• 功能的路线图及其在产品演进中的定位

• ART 承诺在下一个 PI 中开发的优先级功能列表

产品管理概述了项目愿景，旨在将 ART 的重点放在共同的使命上。这个愿景将在业务负责人演示之后，通过演示文稿传达给整个 ART。

计划在下一个 PI 中处理的功能集将传达给 ART 上的敏捷团队。团队可以选择他们希望参与的功能，并开始仔细查看这些功能。他们可能希望开始将这些功能分解为故事，就像我们在第十一章中看到的那样，持续集成解决方案开发，并且可能还会寻找任何风险或依赖关系。

摘要

在本章中，我们审视了触发持续交付管道的活动。通过持续探索，ART 检查市场和客户的需求与期望，生成新产品或新功能的创意。

这个过程始于认识到，开发实际上是一个系列的增量构建-测量-学习循环，开始时通过创建一个关于客户价值的假设来进行。

接下来，产品管理和系统架构师开始协作过程。产品管理与客户合作，更深入地了解客户和市场需求。系统架构师研究假设，以了解这些变更对架构的影响。

当研究完成后，ART 会将所学到的知识转化为特性，并对这些特性进行详细阐述，将其放入程序待办列表中并进行优先排序。一组最高优先级的特性将被选定用于即将到来的 PI。这些选定的特性将被传达给 ART，以便为下一个 PI 规划阶段做好准备。

在 PI 规划之后，ART 开始进行开发工作。这一开发工作将进入持续交付管道的下一个阶段——持续集成。我们将在下一章详细探讨持续集成的内容。

问题

1. 以下哪个不是持续探索的活动？

   1. 假设

   2. 协作与研究

   3. 开发

   4. 综合

2. 产品管理在持续探索阶段与谁合作（请选择三个）？

   1. 发布列车工程师

   2. 客户

   3. 产品负责人

   4. Scrum 主席

   5. 系统架构师

   6. 解决方案列车工程师

3. 创新会计被应用于“构建-测量-学习”周期的哪个阶段？

   1. 构建

   2. 测量

   3. 学习

   4. 所有阶段

4. 精益 UX 过程创建一个 __________ 来验证或证伪利益假设。

   1. 最具价值产品

   2. 可度量的特性

   3. 最小可行产品

   4. 最小市场化特性

5. 系统架构师在评估新特性架构变更时关注哪些领域（请选择三个）？

   1. 安全

   2. 成本

   3. 可测试性

   4. 重用

   5. 可发布性

进一步阅读

• 一系列来自 scaledagileframework.com 网站的文章，作为持续交付管道的参考：www.scaledagileframework.com/continuous-delivery-pipeline/

• 持续交付管道系列中的参考文章，讲述持续探索：www.scaledagileframework.com/continuous-exploration/

• 来自 scaledagileframework.com 的参考文章，详细介绍了史诗故事和 SAFe 精益创业周期：www.scaledagileframework.com/epic/

• 来自 scaledagileframework.com 的参考文章，详细介绍了如何在 SAFe 中使用创新会计和领先指标度量：www.scaledagileframework.com/guidance-applied-innovation-accounting-in-safe/

• 本文描述了 Scaled Agile 为 SAFe 适配的精益 UX 过程：www.scaledagileframework.com/lean-ux/

• 关于 Strangler 模式的解释，并举例说明如何实施：www.techtarget.com/searchapparchitecture/tip/A-detailed-intro-to-the-strangler-pattern

• 关于在 SAFe 中编写 Feature 的指南，并结合了 Feature 编写画布：medium.com/product-manager-tools/writing-effective-features-58a240e69222

• 精益创业：今天的创业者如何通过持续创新创造极具成功的企业 由 Eric Ries 著 – 这本书定义了 Build-Measure-Lean 循环、创新会计、商业转型（pivot）以及什么是最小可行产品（MVP）。

• 精益 UX：与敏捷团队设计伟大产品 由 Jeff Gothelf 和 Josh Seiden 著 – 这本书最初解释了精益 UX 流程，一种迭代的产品设计方法。

• 创新游戏：通过协作游戏创造突破性产品 由 Luke Hohmann 著 – 这本书解释了创新游戏，一系列由产品管理团队和客户共同进行的协作练习，用以挖掘客户需求和期望。

第十一章：解决方案开发的持续集成

在 PI 规划后，ART 上的团队开始工作。他们将查看持续探索的产出以及为 PI 选择的功能，并将其带入持续交付管道的下一个阶段，即持续 集成（CI）。

本章将介绍在持续交付管道的 CI 阶段中进行的以下活动：

• 开发解决方案

• 构建解决方案包

• 执行端到端测试

• 将包移到预发布环境

我们还将发现，持续交付管道中描述的过程将在 CI 阶段与自动化相结合，形成CI/持续部署（CD）管道。

现在，让我们加入 ART，随着他们根据持续探索阶段创建的功能开发解决方案。

开发解决方案

ART 团队的工作方式与使用瀑布方法的产品开发团队有很大不同。强调精益思维并聚焦于系统决定了新的工作方式。

我们将研究今天敏捷团队使用的以下工程实践：

• 将工作分解

• 协作开发

• 在构建质量

• 版本控制

• 面向系统的设计

这些实践旨在实现工作流的持续流动，为下一个构建状态做好准备。

将工作分解为故事

我们在第四章中学习到的精益流程的重要部分是保持批次规模小。一个功能，在 PI 规划之前呈现给我们，是一个大批次的工作，计划在 PI 结束时完成。为了确保工作流的顺畅，功能必须分解成更小的工作批次。

用户故事通常描述了在冲刺或迭代结束时需要交付的小块用户功能，通常为两周。它们通常以用户语气的形式表达，简要说明该故事是为谁准备的，以及所需的功能和预期的价值。以下是用户语气形式的示例：

作为客户，我想要每月收到一份详细的服务收据，以便我可以了解并整理我的开支。

故事的一个关键部分是其接受标准。接受标准概述了故事的正确行为，是团队判断故事是否完成的方式。

接受标准可以使用 Gherkin 格式编写。这有助于概述前置条件、输入、所需的行为和输出。这些在以 GIVEN-WHEN-THEN 开头的条款中进行描述。

以下是我们故事的接受标准示例，采用 Gherkin 格式编写。注意它是如何描述初始条件、输入和输出的：

初始条件	假设我已经配置了 通知日期…
输入	…当通知日期过去时…
输出或期望的行为	…然后我收到一封包含我项目清单的电子邮件通知。

表格 11.1：Gherkin 格式的验收标准

使能故事也可以来自功能。这些故事不直接为用户提供价值，但为未来用户故事的开发和架构能力提供便利，从而创造未来的业务价值。SAFe®列出了以下四种类型的使能者。

• 基础设施

• 架构

• 探索

• 合规性

将一个功能拆分成用户故事和使能故事可以通过多种方式完成。以下方法可以用来创建可以在短冲刺中完成的故事。

• 工作流步骤：首先设置故事来执行工作流的必要步骤。其他步骤可以在后续冲刺中发布。

• 业务规则的变异：根据不同的业务规则划分故事，例如不同的服务等级、不同的产品线等。

• 重大工作量：检查可以遵循的可能故事。首先选择看起来最难完成的故事。

• 简单与复杂：在评估功能时，是否有一个可以编写的故事来提供核心功能？那就是要先做的第一个故事。后续的故事将进一步详细说明核心功能。

• 数据中的变异：从一个适用于某种数据类型的故事开始，然后转到处理其他数据类型的不同故事。

• 不同的数据输入方法：首先创建一个手动输入数据的故事，然后逐步推进自动化数据输入的后续故事。

• 不同的系统特性：系统特性的一种示例可能是我们的应用程序将与不同的设备或接口配合使用，并为每个设备或接口建立一个故事。

• 按操作：将故事划分为处理不同操作的部分。常见的划分方法是创建、读取、更新和删除（CRUD）。

• 使用场景：为每个使用场景创建一个故事。

• 设置突发任务与后续工作：突发任务是用来安排开发时间，研究一种技术方法或解决未知问题。一旦研究完成，就继续进行实现该方法的故事。

请注意，可能需要进一步拆分大型故事，以便在短冲刺结束时完成并交付该故事。前述方法可以用来将较大的故事拆分成较小的故事。

协作开发

虽然团队可以选择如何开发他们的故事，但高效能团队发现，与其单独工作，不如团队成员一起合作，能够生产出更高质量的产品，并实现有效的知识共享，从而创造出更强大、更具协作性的团队。

在本节中，我们将讨论两种允许团队共同开发产品的实践，促进更好的质量和更强的团队凝聚力：配对编程和集体编程（或集群编程）。

配对编程

对偶编程是一种源自极限编程（XP）的实践。与其让两位开发者在两台电脑前分别工作，不如让他们在一台共享电脑前共同工作，相互交换想法，同时进行编码和审查工作。

当两位开发者一起工作时，以下模式是他们协作的体现。

• 驾驶员/导航员：在这种模式中，一位开发者掌控电脑（驾驶员），而另一位开发者通过评论屏幕上输入的内容来审查并提供指导（导航员）。在会议的某些时段，角色会进行交换。这是对偶编程中最常用的模式。通常，当一位开发者是专家级程序员，而另一位是新手时，这种模式尤其有效。

• 无结构模式：在这种临时的对偶编程风格中，开发者之间没有固定的角色。协作往往是没有明确指导和松散的。通常，在两位开发者都不确定哪种方法有效时会采用这种模式。这种模式适合技术水平相近的开发者，但对于两位初学者来说，可能会遇到一些问题。

• 乒乓编程：这种模式通常由一位开发者编写测试，另一位开发者则为通过测试而进行工作。两位开发者在编写测试和编写通过测试的代码之间频繁切换角色。这种风格适合两位经验丰富的开发者。

对偶编程已被证明是一种有效的协作方式。在对偶编程过程中编写的代码通常会进行审查和调试，从而产生高质量的代码。知识在开发者之间共享，加速了初学者或不熟悉代码库的开发者的学习。如果代码出现问题，通常不仅仅有一个开发者了解代码，可以帮助修复问题。

一个常见的误解是对偶编程需要双倍的努力或资源。然而，这一观点并没有得到对偶编程有效性研究的支持，包括犹他大学进行的一项研究（collaboration.csc.ncsu.edu/laurie/Papers/XPSardinia.PDF），该研究发现，虽然开发成本增加了 15%，但在后期阶段发现的缺陷减少了 15%，且代码功能实现时所用的代码行数更少，这表明设计质量更高。

团队编程或集体编程

集体编程可以看作是对偶编程的最高级形式。不同于只有一对开发者，整个团队都围坐在一台电脑前进行操作。团队成员们在相同的时间和空间里，在同一台电脑上共同工作。

这种典型的模式是一种驱动者/导航者模式的变体。团队中的一个人控制计算机，输入并创建代码或其他工作部分。团队的其他成员作为导航者审查并指导驱动者。经过一段时间（通常为 10 分钟），控制权会轮换到团队中的另一成员。轮换会持续进行，直到所有团队成员都有机会担任驱动者。

集体编程有利于整个团队。代码的知识共享适用于整个团队，而不仅仅是一对开发人员。整个团队都在场时，沟通变得更容易。决策基于最当前和相关的信息。

通过“向左转移”来构建质量

在此期间，不仅产品在开发中，同时确保产品质量的方法也在同时开发。这与传统开发方式有所不同，传统开发是在代码开发后才创建并运行测试。这一变化通常被称为向左转移，如下面的开发过程表示所示。这是 SAFe 中的一项重要实践，更多细节可参考 SAFe 文章《内建质量》(www.scaledagileframework.com/built-in-quality/):

图 11.1 – 与“向左转移”比较的测试（© Scaled Agile, Inc.，版权所有）

在前面的图示中，我们可以看到，传统的测试可能在故事和功能最初构思后很长一段时间才进行测试。这个延迟的反馈可能需要长达 3 到 6 个月的时间，这可能太晚了，无法知道我们是否朝着正确的方向前进。

从右侧的图示中，我们看到可以通过 TDD 和 BDD 测试加速反馈，以评估功能和故事的行为是否符合预期。理想情况下，这些测试应当自动化，以便能够反复快速运行。

我们还可以从前面的图示中看到，测试有多个层级，其中一些应通过自动化反复运行，而另一些可能需要一些时间或只能手动运行。我们如何知道哪些测试应该自动化，哪些测试应该频繁运行呢？

Mike Cohn 在他的书《成功的敏捷》中将测试层级描述为“测试金字塔”。他最初描述了以下三个从下到上的层级。

• 单元测试

• 服务测试

• UI 测试

其他类型的测试可以添加到测试金字塔中并加以应用。这使得我们可以如下图所示查看测试金字塔：

图 11.2 – 测试金字塔

请注意，在金字塔的底部，单元测试是执行速度最快且成本最低的。将它们的执行自动化并频繁运行是明智之举，理想情况下应该在每次提交版本控制时，尤其是在构建阶段执行。

随着你向金字塔的上方移动，测试的执行时间逐渐增加，成本也变得更高。这些测试可能不会像单元测试那样频繁运行。它们可能通过自动化执行，但只会在进入测试阶段时运行。这些测试的例子包括来自 BDD 的故事测试、集成测试、性能测试和安全测试。

金字塔顶部的测试需要最久的执行时间，且也是最昂贵的。这些大多是手动测试。这些测试可能会在发布前运行。此处的测试示例包括用户验收测试和由客户进行的探索性测试。

大多数测试旨在验证代码的正确性和功能性，以及验证故事和特性的行为。创建测试以衡量这些标准的主要方法包括：TDD 和 BDD。让我们来看看这些测试是如何开发的。

TDD

TDD 是源自 XP 的一种实践。在 TDD 中，你会遵循以下流程：

1. 创建测试。这是为了理解行为。

2. 观察测试失败（即使没有写任何代码）。这让我们对测试执行环境有信心，并展示了测试失败时系统的行为。

3. 编写通过测试所需的最简单代码。

4. 确保所有测试通过。这意味着任何新创建的代码都需要经过修订，直到测试通过为止。

5. 根据需要重构测试和代码。

随着新功能的开发，这个流程会重复进行。这个流程的图形表示如下：

图 11.3 – TDD（en.wikipedia.org/wiki/Test-driven_development#/media/File:TDD_Global_Lifecycle.png 根据 CC BY-SA 许可证授权）

通常使用 TDD 编写的测试是单元测试；小型、易于执行的测试，旨在验证代码模块的正确功能。更广泛的测试使用 BDD 来开发验证特性和故事的系统行为的测试。现在让我们来看看 BDD。

BDD

BDD 通常被视为 TDD 的扩展，但与 TDD 侧重于验证单个代码功能和组件的正确行为不同，BDD 力求验证系统作为可执行规格的正确行为，这些规格通过特性和故事来表达。在本章的早些时候，我们创建了故事的接受标准，这是 BDD 的一种应用。

查看正确的系统行为涉及三个互相协作的视角，这些视角帮助确定最终的规格、开发内容以及作为正确测试的内容。以下是这三种视角：

• 了解业务需求并寻找新功能的可取性和可行性的客户

• 了解可行技术方法的开发人员

• 查看系统行为的边界条件和边缘案例的测试人员

BDD 通过使用规范将这三种视角结合在一起。这些规范使用领域特定语言（DSL）编写，采用自然语言语法，使技术人员和非技术人员能够协同开发规范。这些 DSL 之一是 Gherkin，它将行为划分为以下三个部分：

• GIVEN 概述了场景中期望行为所需的初始条件

• WHEN 描述了触发场景的输入

• THEN 描述了场景的期望行为

可以使用AND将多个 GIVEN、WHEN 和 THEN 条款连接在一起，以表示多个条件、输入和行为。

使用 DSL 的规范可以变成多个工件。产品负责人和产品管理人员与开发团队的其他成员一起创建功能和故事的验收标准。验收标准的创建可以看作是对期望系统行为的发现。

创建规范的下一个阶段是制定。在此阶段，开发人员和测试人员共同合作，创建验收测试。他们可以根据写好的验收标准，详细阐述每个条款中的具体标准，包括允许的初始条件和测量输入与输出的值，从而使得某一特定场景的规范变成一项测试。理想情况下，验收测试应使用与验收标准相同的领域特定语言（DSL）编写。

我们可以通过采用故事的验收标准，并添加特定的前置条件、输入和期望的输出或行为，来创建自动化测试。让我们看看之前看到的验收标准如何转化为测试，见下表：

验收标准	测试
GIVEN 我已配置通知日期…	给定日期状态不是 x…
…WHEN 通知日期过去…	…当日期状态变为 x 之后一个工作日…
…THEN 我收到一封包含明细收据的电子邮件通知。	…然后向所有用户发送包含 xxx 内容的电子邮件通知。

表 11.2 – 将验收标准转换为测试

规范的最后一个阶段是自动化。用 DSL 编写的验收测试可以在支持自动化测试的工具中执行。用 Gherkin 编写的验收测试可以通过如 Cucumber、JBehave、Lettuce Behave 和 Behat 等工具执行。

版本控制

版本控制软件允许团队中的多个开发者在相同的代码库、测试脚本或其他文本上并行开发，而不受其他开发者更改的干扰。版本控制系统中的每个更改都会被记录。通过合并操作整合更改，解决工作内容中的变动。

使用版本控制的重要实践包括以下几个方面：

• 将所有内容都保存在版本控制中：许多设计决策作为工件被记录在版本控制中，超越了源代码的范畴。代码、测试脚本、配置文件以及任何其他基于文本的工件可以一起标记，表示它们是同一个发布版本的一部分。版本控制还允许检索先前的版本，回滚任何更改或查看设计决策的演变过程。

• 每个人都使用相同的版本控制系统：正如我们在第一章《引入 SAFe®与 DevOps》中看到的，照片分享网站 Flickr 的开发和运维人员之间使用的是相同的版本控制系统。这使得当生产故障发生时，任何人都可以轻松检索工件。

我们将在下一部分中介绍构建过程中进行的其他版本控制最佳实践。

面向系统的设计

特性和故事并不是团队在为其产品开发新能力时唯一需要考虑的标准。非功能需求（NFRs）是可能影响每个特性和故事的质量，它们作为一种约束或限制。这些 NFRs 可能涉及安全性、合规性、性能、可扩展性和可靠性等方面。

有两种实践可确保符合某些 NFRs：面向运维的设计和威胁建模。让我们来看看这些实践。

面向运维的设计

开发与运维之间的协作是 DevOps 运动的一个标志。确保运维可以轻松检查系统资源，是在开发初期容易纳入的内容，而不是事后才考虑的。

确保产品维护所需能力的关键部分是应用遥测。作为一个系统，产品必须允许轻松衡量系统资源，包括应用程序如何使用服务器内存和存储等资源。除了系统度量，应用遥测还应允许衡量商业数据，用作验证收益假设的领先指标。

其他考虑因素包括确保新特性带来的变化可以轻松回滚，或者修复可以通过持续交付管道向前推进。在进行这些操作时，需要注意可能代表系统状态的组件，例如数据库。这些组件可能无法轻松回滚。

威胁建模

向 DevSecOps 方法迈进需要一种向左转的安全思维方式。这种思维方式可以在持续交付流水线的设计和开发阶段考虑安全问题，从而对产品有一个更全面的视角。

我们首先在第十章《持续探索与发现新特性》中看到，威胁建模是架构系统的一部分。作为持续集成过程中威胁建模的一部分，我们可能会问以下问题：

• 我们在做什么？这有助于你了解工作的范围。

• 这可能会出什么问题？这让你可以通过头脑风暴或结构化的威胁建模过程（例如应用安全框架（ASF）或欺骗、篡改、拒绝、信息泄露、服务拒绝或特权提升（STRIDE））开始你的评估，后者识别可能的网络安全威胁类型。

• 我们能做些什么来解决出现的问题？根据评估，制定对策或缓解步骤。

• 到目前为止，我们为现有系统做得够好吗？持续评估评估、对策和缓解步骤。

向 DevSecOps 发展基于评估过程中识别的对策和缓解步骤。

随着开发更改的完成，它们必须与现有产品集成并进行测试。这可能会开始将自动化纳入 CI/CD 流水线。接下来，让我们看看如何通过构建过程开始进入 CI/CD 流水线。

构建解决方案包

CI/CD 流水线可以通过版本控制系统中的操作触发，例如将新更改保存为提交。在版本控制系统接受更改之前，它们应该经过测试过程，以确保不会对当前的代码库产生不良影响。这个测试和版本控制集成的过程是 CI 过程中的一个重要部分，其中实践分为版本控制视角和测试视角。

让我们来看看这些视角以及其中的实践。

版本控制实践

良好的版本控制实践确保在将更改引入版本控制之前，通过测试对其进行评估，然后再将其保存并与现有代码库合并。这确保了代码库的健壮性，不会出现阻止代码库正确构建或打包的更改。

版本控制实践可以进一步分为三种类型，帮助确保随着更改的引入，代码库保持健壮。让我们详细看看这些实践是什么。

代码的持续集成（CI）

CI 实践源于通过自动化构建脚本或 CI 工具优化构建过程。通过提交操作将更改保存到版本控制中，会触发以下一系列步骤：

1. 应用程序将被构建，并整合保存的变更。如果构建过程中出现错误，将发送关于该错误的通知。变更将无法与代码库合并。

2. 如果构建成功，测试将会在包含代码变更的构建上运行。这些测试通常是小型测试，测量功能的一个小部分，可以快速执行且不占用太多时间。如果检测到测试失败，将会发送通知，并且变更将无法与代码库合并。

3. 另一种可以执行的测试是对代码库的扫描。扫描可以查找代码风格标准的偏差、语法错误以及已知的安全漏洞。根据发现的严重性，变更将无法与代码库合并，并且会就所有发现的内容发送通知。

4. 在构建、测试和扫描步骤成功完成后，代码变更将被记录到版本控制系统中。代码变更将通过版本控制系统合并到主干，整合到代码库的其余部分。

上述步骤在下图中进行了概述：

图 11.4 – CI 自动化

在执行上述一系列步骤时，团队最终意识到，成功的代码集成依赖于以下因素：

• 频繁执行集成：许多团队最初通过每晚执行构建和测试过程，检查前一天保存的变更。随着变更越来越多，夜间构建通常会增长，直到无法在第二天或更晚之前完成。更频繁的构建，通常是每天多次执行，允许团队成员看到构建结果并迅速采取行动。

• 在较少变更上执行集成：一个包含多个开发者变更的夜间构建会在构建失败时产生问题。诊断哪个开发者的变更导致了构建失败变得更为复杂。基于较少变更执行构建，每次构建都基于保存的变更，可以在出现错误时更快速地进行故障排查。

无论成功与否，CI 都会产生以下输出：

• 快速反馈：CI 的结果应该在几分钟内产生。任何导致 CI 无法成功完成的错误都会在短时间内给出反馈，从而减少延迟。

• 成功时可部署的工件：通过成功构建，将生成一个可以部署到非生产环境中的构建包。

CI 工具，如 Jenkins、GitLab 管道和 GitHub Actions，构成了实现代码持续集成（CI）的自动化基础。

主干开发

一个团队中的多个开发人员，甚至多个团队（如 ART 中的团队）通常必须在同一个代码库上工作，该代码库保存在版本控制中。版本控制系统通过允许更改分支出来，支持同一代码库的并行开发。开发人员或团队可以在分支上工作，直到准备好合并并与其他开发人员或团队共享之前，他们的更改不会影响其他团队或 ART。

图 11.5 – 分支结构示例

在前面的示例中，团队 1和团队 2都有自己基于主分支不同版本的代码库分支（通常称为主干）。团队 1的开发人员创建了一个更改（D1）并将其作为更改T1-2合并回团队 1的分支。在独立的团队分支下，我们如何知道团队 2的必要更改是否可见，并且能被团队 1使用呢？

另一个问题出现在团队 1和团队 2在各自的分支上开发，但没有从主干接收更新，直到他们发布或冲刺结束时才合并。跟踪多个团队的多项更改，并解决大量合并冲突，带来了巨大的挑战。

为了保持简单并确保所有团队都能看到变化，我们希望避免出现长期存在的或永久性的分支。开发人员和团队可以创建分支以支持并行开发，但当准备好后，必须将其合并回主分支，并在此过程中销毁分支。这一过程被称为基于主干的开发。下图展示了基于主干的开发流程：

图 11.6 – 基于主干的开发分支结构

基于主干的开发使得合并操作更容易进行，因为每个验证过的更改都会合并到主分支，而不是一组更改。

有门控的提交

使用基于主干的开发，我们尽可能频繁地将更改合并到代码库的主分支中。这个主分支是 ART 上所有团队使用的。由于主分支的完整性对多个团队至关重要，我们如何确保任何错误的更改不会破坏当前的代码库呢？

为了确保代码库的健壮性，我们必须遵循一个有门控的提交过程，在允许更改合并到主分支之前，必须成功通过构建和测试过程。也可以采取额外的措施，比如对更改进行审查。

在基于 Git 的环境中，Bitbucket、GitLab 和 GitHub 等 Git 服务器将有门控的提交定义为拉取请求或合并请求，这些请求允许在请求合并操作时进行更严格的审查。

测试实践

我们看到，构建过程依赖于测试来确保对代码库的更改不会对产品的功能或安全性产生不利影响。执行的测试证明是非常重要的，因为理想情况下，构建过程应该在每次保存的更改后执行，如果成功，下一步将是将更改合并到主分支，对于 ART 来说，这个分支对团队或多个团队是可见的。

构建过程涉及两种类型的测试，这些测试会针对潜在的新版本代码库运行：自动化单元测试和静态应用安全分析。

让我们更深入地了解作为构建过程一部分的每种测试类型。

自动化单元测试

单元测试通常与代码同时编写，如果不是提前编写。这些单元测试可能由个人开发者在其工作站上运行，在代码开发过程中进行。如果是这种情况，为什么还要在构建过程中再次运行它们呢？

CI 的主要思想是确保一个标准、可靠的流程。通过 CI/CD 流水线实现自动化，确保所有开发者都遵循这一流程。在构建过程中增加单元测试，并在自动化的 CI/CD 流水线上运行，确保每个开发者的代码变更都会每次执行单元测试。

同时确保任何已更新的单元测试也是潜在代码变更的一部分，并且被纳入版本控制中的代码库。这可以确保代码更改能够通过正确的测试进行验证，防止因为不正确的测试导致 CI/CD 流水线停止。确保代码创建者和测试创建者之间的协作开发是必要的，以确保这种情况不发生。

应用安全的静态分析

静态分析是一种通过工具扫描代码库文本（包括正在检查的潜在代码更改）来查找特定文本模式的过程。这些文本模式可以用于识别以下问题：

• 编码错误

• 已知的安全漏洞

• 不遵守编码指南或编码标准

这种分析是在无需执行应用程序的情况下进行的。因此，静态分析是一种高效的检查构建过程中问题的手段。

正如我们在第三章《提高效率和质量的自动化》中所看到的，静态分析可以分为以下两类：

• 静态代码分析：查看代码中可能存在的编码错误。Linting 就是静态代码分析的一种示例。

• 静态安全分析：查看代码中可能存在的安全漏洞和攻击向量。执行静态安全分析的应用程序可能进行以下扫描：

  • 依赖扫描：扫描代码依赖和对第三方库的引用，以查找漏洞

  • 静态应用安全测试（SAST）：扫描代码以查找攻击向量和漏洞

  • 许可合规：扫描库以确定其开源许可模型

  • 容器扫描：扫描 Docker 容器以查找嵌入的漏洞

  • 秘密检测：扫描代码以查找嵌入的凭证、密钥和令牌

我们的应用程序已经通过了第一组测试，但它是否已经准备好应对生产环境中的严苛要求？为了回答这个问题，我们需要进行系统级测试。接下来的部分将探讨支持系统级测试的实践。

端到端测试

此时，我们已经对单独的代码片段进行了测试，并确保了功能的正确性，同时保持了安全性。在此，我们开始将新的代码变更与现有代码库集成，并通过端到端测试来评估整个系统。

允许对系统进行真实端到端测试的实践将在接下来的部分中讨论。让我们深入了解。

等效的测试环境

系统级测试应在尽可能接近生产环境的环境中进行。尽量在与生产环境相似的环境中测试解决方案，可以更有信心地确保解决方案在实际投入生产环境时能够正常工作。测试环境与生产环境的相似性越高，发现问题并开始排查根本原因时，涉及的变量就越少。

确保测试环境与生产环境等效的一个关键因素是使用配置管理。通过配置管理，操作系统版本、关键驱动程序版本和应用程序版本等关键资源会被记录在基于文本的配置文件中。理想情况下，配置文件会通过版本控制进行管理，并带有标签，标明解决方案的版本及其在测试环境和生产环境中的应用。

因为为生产环境分配完全相同的资源可能会非常昂贵，所以重要的视角是，资源的确切版本，而不是资源的确切数量，是保持等效性的关键。

测试自动化

系统级测试可以涵盖多个层次，其中大部分可以实现自动化。在不同层次的测试中，哪些测试可以被自动化？

除了前面提到的测试金字塔，我们可能还需要考虑需要理解测试结果的人员。第二个考虑因素是，测试是验证解决方案是否符合要求，还是让开发人员看到他们的设计方法是否正确。

敏捷测试矩阵查看各种类型的测试，并根据这些考虑因素对其进行组织。下图展示了在 SAFe 文章中看到的敏捷测试矩阵，关于敏捷测试 (www.scaledagileframework.com/agile-testing/)：

图 11.7 – 敏捷测试矩阵（© Scaled Agile, Inc.，保留所有权利）

从前面的图示可以看出，第一个考虑因素是从业务或技术的角度来看待的。开发人员从技术测试的角度，确保解决方案的正确功能和正常操作。最终用户从面向业务的测试角度，确保对解决方案的理解并验证其效益假设。

我们还可以看到第二个考虑因素：测试是否涉及完整的解决方案或实现。指导开发的测试有助于 TDD 和 BDD 方法，其中测试先于代码编写。批判产品的测试则关注解决方案是否符合用户需求。

在每个考虑因素的两个领域中，我们可以将测试分为以下四个象限：

• Q1：这些包含单元测试和组件测试。这些测试可能作为 TDD 方法的一部分创建。

• Q2：这些包含功能性测试以及故事和特性的测试。这些测试可以使用 BDD 方法创建，以实现自动化测试。否则，其中一些验证可能需要手动进行。

• Q3：这些是整个解决方案的验收测试。这些可能是发布前的最终验证。这些测试通常由 alpha 和 beta 用户手动执行。

• Q4：这些测试整体系统的质量，包括非功能性需求（NFRs）。这些测试验证生产环境中的系统。

我们将看到，第 3 象限的测试是在第十二章 持续部署到生产环境 中的 CD 阶段进行的。第 4 象限的测试是在第十三章 按需发布以实现价值 中提到的按需发布阶段进行的。

测试数据的管理

确保测试环境与生产环境之间相似的一个关键部分是用于测试解决方案的数据。使用在生产环境中可能找到的数据，可以提供更现实的测试结果，从而增加对解决方案的信心。

现实的测试数据可以来自合成测试数据或真实的生产数据。测试数据可能来自生产数据的备份，这些数据被恢复到测试环境中。测试数据应该删除任何被视为私密的信息。

合成测试数据是由数据生成工具（如 DATPROF Privacy 和 Gretel）创建的虚假数据。它的优点是无需进行匿名化步骤来删除私人信息。

无论数据是匿名化的生产数据还是合成数据，测试数据应该使用版本控制来维护，使用工件库软件来存储大规模的基于二进制的数据。

服务虚拟化

服务虚拟化使得即使测试环境缺少生产环境中可用的资源，测试环境也能像生产环境一样工作。生产环境可能依赖于一些关键组件，这些组件由于以下因素而无法复制：

• 该组件尚未完成

• 该组件由第三方供应商或合作伙伴开发

• 在测试环境中对组件的访问有限

• 该组件在测试环境中配置困难

• 需要访问该组件的多个团队具有不同的设置

• 该组件太昂贵，无法用于性能或负载测试

由组件组成的系统，如果它们通过公认的接口进行通信，可以利用服务虚拟化来模拟一个或多个组件的行为。如果虚拟化服务是一个数据库，它可以返回合成的测试数据。

在测试环境中模拟的组件称为虚拟资产。虚拟资产是通过以下方法由工具创建的，这些方法可以测量真实组件的行为：

• 记录一个组件在共享通道或总线上通信时的消息、响应和响应时间

• 检查组件的日志

• 查看服务接口规范

• 手动输入数据并测量行为

一旦虚拟资产创建完成，它就会在测试环境中占据一席之地。生产环境与测试环境之间使用虚拟资产的区别示例如下：

图 11.8 – 生产环境与测试环境

用于创建虚拟资产的流行工具包括 Smartbear 的 SoapUI 和 ReadyAPI、MockLab、Parasoft Virtualize 和 WireMock。

一个重要的区别需要考虑的是，尽管服务虚拟化看起来类似于模拟或桩化组件，但这两个概念并不相同。添加模拟组件或桩通常是在开发过程中进行的，当组件尚未准备好发布时。模拟对象的行为只返回一种类型的输出——成功信息——因此其他组件的开发不会受到阻碍。服务虚拟化允许在各种场景下提供正确的行为。

使用虚拟资产的环境应在配置管理工具中进行维护。虚拟资产的配置文件和接口定义文件应保存在版本控制中，紧密存放，并贴有标签以标识它们作为应用程序版本的测试资产。

测试非功能性需求

在进行端到端系统测试时，我们需要记住系统的约束条件，这些条件我们之前已经确定为非功能性需求（NFRs）。非功能性需求影响每个用户故事和功能，作为必须遵守的约束。诸如安全性、性能、可靠性和可扩展性等质量属性，应该通过测试进行检查，以验证这些约束没有被破坏。

非功能性需求的测试通常是自动化的，涉及专门的测试工具。ART 上的敏捷团队通常与系统团队合作，确保建立工具链，以便作为端到端测试的一部分执行非功能性需求的测试。

在对变更执行完所有测试组合后，我们可能还希望有一个机会来查看我们的变更是否准备好部署到生产环境。我们将变更放入阶段环境，这是生产环境的替代品，用于在将变更部署到生产之前进行最终检查。让我们来看看将变更部署到阶段环境的活动。

移动到阶段环境

我们可能希望验证能否将变更部署到类似生产的环境中，并验证我们的解决方案是否仍然有效。为了进行这最后的检查，我们采用了一些实践。

让我们深入了解这些实践。

阶段环境

阶段环境是生产环境的复制品，在 PI 过程中有多种用途。它是系统演示的地方，展示当前系统的状态。用户验收测试可以在这个环境中进行，它尽可能接近生产环境。

随着产品的变更开发，阶段环境展示了在部署到生产之前的变更状态。至少，每个迭代或冲刺期间，阶段环境都会进行变更。只要构建过程和端到端测试成功完成，更频繁的变更也是允许的。

阶段环境也可以作为生产环境的替代环境，采用蓝绿部署配置，这种配置可以在生产故障时轻松回滚。现在，让我们来看一下这种配置。

蓝绿部署

在蓝绿部署中，你有两个相同的环境。两个环境中，一个是生产环境并面对流量，另一个是空闲的，处于待命状态。

空闲环境接收最新的变更，并进行彻底的测试。适当时，变更将通过将空闲环境切换为上线状态，并使另一个环境处于空闲状态来发布。以下图示说明了这一过渡：

图 11.9 – 蓝绿部署发布新版本

如果发现问题，可以切换回滚变更。对于不追踪状态的系统来说，这种来回切换很容易。否则，蓝/绿部署必须精心设计，以确保能够存储状态的组件，如数据库，在过渡时不会被损坏。

系统演示

在每个 PI（程序增量）的每个冲刺或迭代结束时，在每个团队的迭代评审后，团队会聚集在一起整合他们的工作成果。与系统团队合作，他们展示目前在暂存环境中该 PI 中产品的当前状态。商业负责人、客户和 ART 的其他关键利益相关者会出席此演示活动，以查看进展并提供反馈。这个活动为 ART 目前的努力提供了快速反馈。

请注意，系统演示并不妨碍将变更部署到生产环境中。这可以继续作为 CD（我们将在下一章讨论）的一部分自动发生，但反馈可能会阻止变更发布给客户，直到基于反馈的变更进入生产并按需发布。

在暂存环境中的成功测试让我们有信心，变更具有正确的功能，并且在生产环境中足够稳定，但唯一真正证明这一点的方式是将我们的变更部署到实际的生产环境中。

总结

在本章中，我们继续探索持续交付管道，关注 CI（持续集成），它实现了在持续探索中创建的功能。功能被拆分成更易消化的故事。产品的开发不仅包括产品本身，还包括验证产品的测试。安全性和面向运维的设计也纳入了开发中。

构建阶段将自动化引入管道中。当版本控制发生提交时，单元测试会运行以确保功能的持续正确性。构建还会扫描代码错误并查找安全漏洞。如果一切正常，提交将被允许与版本控制仓库的主分支或干线合并。

成功的构建可以触发在类似生产环境的测试环境中进行进一步测试。在这里，会进行系统级的端到端测试，以防止任何生产故障。这里的测试尽可能自动化。准确的测试数据和服务虚拟化可能为生产环境提供合理的仿真进行测试。

当构建和测试完成后，变更可能会出现在一个暂存环境中，它是生产环境的副本，或者是蓝/绿部署的一部分。暂存环境也是在系统演示期间展示变更的地方，这是一个在每次冲刺或迭代结束时，ART（敏捷释放训练）团队获得系统开发反馈的活动。

在进入暂存环境后，我们必须将更改移入生产环境。这是在 CD 中发生的，我们将在下一章中探讨它。

问题

1. 协同开发的两个例子是什么？

   1. 独立编程

   2. 配对编程

   3. 挑战编程

   4. Mob 编程

   5. 跨团队编程

2. TDD 的第一步是什么？

   1. 编写测试

   2. 编写代码

   3. 重构测试

   4. 重构代码

3. 在进行基于主干的开发时，成功的构建和测试将使提交的更改与哪个分支合并？

   1. 发布分支

   2. 修复分支

   3. 主分支

   4. 完整测试分支

4. 根据测试金字塔，哪种类型的测试执行速度最快？

   1. 单元测试

   2. 安全测试

   3. 故事测试

   4. 用户验收测试

5. 应该存储在版本控制中的基于文本的文档是什么？

   1. 代码

   2. 测试

   3. 配置文件

   4. A 和 C

   5. 以上所有

6. 可以用什么方法让测试环境与生产环境相似？

   1. 使用旧的生产服务器

   2. 清理后的生产数据备份

   3. 服务虚拟化

   4. B 和 C

   5. 以上所有

7. 与生产环境完全相同的暂存环境可以用来做什么？

   1. 用户验收测试

   2. 用于蓝绿部署的空闲环境

   3. 系统演示

   4. 以上所有

进一步阅读

• Scaled Agile 指南，说明如何将功能分解为故事及良好故事的内容：www.scaledagileframework.com/story/

• 一份常用模式的指南，说明如何将功能分解为故事或将大故事拆分成小故事：www.humanizingwork.com/wp-content/uploads/2020/10/HW-Story-Splitting-Flowchart.pdf

• 一篇好文章，详细介绍了配对编程的实践：www.techtarget.com/searchsoftwarequality/definition/Pair-programming

• 犹他大学进行的研究，详细描述了配对编程的好处：collaboration.csc.ncsu.edu/laurie/Papers/XPSardinia.PDF

• Woody Zuill 的原文，详细描述了 mob 编程的工作原理及其好处：www.agilealliance.org/resources/experience-reports/mob-programming-agile2014/

• Scaled Agile 的一篇文章，关于“将测试向左移”和采用 TDD 和 BDD：www.scaledagileframework.com/built-in-quality/

• 来自 开放 Web 应用程序安全项目 (OWASP) 的文章，详细描述了威胁建模：owasp.org/www-community/Threat_Modeling

• 这篇来自 OWASP 的文章详细介绍了用于威胁建模的流程，包括 ASP 和 STRIDE：owasp.org/www-community/Threat_Modeling_Process

• 一篇扩展了 Mike Cohn 测试金字塔的文章：martinfowler.com/articles/practical-test-pyramid.html

• Scaled Agile 关于敏捷测试和敏捷测试矩阵的文章：www.scaledagileframework.com/agile-testing/

• Smartbear 公司（两款领先服务虚拟化工具的供应商）撰写的关于服务虚拟化的文章，内容包括什么是服务虚拟化，它的好处，以及它与存根的比较：smartbear.com/learn/software-testing/what-is-service-virtualization/

• Scaled Agile 关于系统演示的指导：www.scaledagileframework.com/system-demo/

第十二章：持续部署到生产环境

在我们继续沿着持续交付管道前进时，我们设计了特性来测试在持续探索过程中获得的效益假设。这些特性的实现发生在持续集成阶段，我们在这一阶段创建了故事、开发了变更和测试，并将变更通过构建和测试过程。最终，我们的变更被放置在一个预发布环境中。

在持续部署中，我们完成了变更到生产环境的整个过程。然而，活动并不在部署到生产环境后就结束。

在本章中，我们将探讨使得在持续部署中能够实现以下操作的实践：

• 将变更部署到生产环境

• 验证变更在生产环境中的正常运行

• 监控生产环境

• 响应和从生产故障中恢复

需要记住的是，我们将部署与发布分开。我们在第十章，持续探索与发现新特性中看到了使得新变更能够自动部署到生产环境的架构问题。虽然我们持续将变更部署到生产环境，但直到我们发布这些变更，客户才会看到它们。本章将讨论如何只允许特定人员查看生产环境中的这些变更。我们将在下一章，第十三章，按需发布以实现价值中讨论按需发布。

让我们从第一项活动开始，探索持续部署：将变更部署到生产环境。

部署到生产环境

部署的目标是将我们的解决方案（无论是新产品还是对现有产品的增强功能）投入生产环境。在持续部署中，我们希望尽可能频繁地推动这一解决方案，同时将对生产环境的风险降到最低。

以下实践使我们能够更频繁地部署并降低生产环境中的故障风险：

• 设置暗启动

• 使用特性标志

• 自动化部署

• 基础设施即代码

• 选择性部署

• 自助部署

• 版本控制

• 蓝绿部署

我们在前面的章节中，特别是第十一章，解决方案开发的持续集成中已经讨论过版本控制。我们也在同一章中讨论了蓝绿部署。

让我们来看看其余的实践，它们是如何在降低风险的同时增加部署频率的。

增加部署频率

我们在第一章，介绍 SAFe®和 DevOps中看到了一组实践，这些实践使得 Flickr 能够在 Velocity 大会上宣布他们可以一天进行 10 次部署。他们通过创建脚本，确保在所有测试通过后进行自动部署。

当今的自动化和实践是 Flickr 最初成功的自动化部署的演变。为此，我们将研究今天正在使用哪些实践以及如何使用。

让我们从今天的部署自动化开始探索。

部署自动化

允许 Flickr 自动化其部署的脚本将从代码提交到部署的时间从天缩短到了小时。随着这一脚本的现代演变，CI/CD 管道进一步将部署时间从小时缩短到分钟甚至秒钟。让我们来看看它是如何做到的。

在整体的持续交付管道中，我们看到在持续集成过程中引入了自动化。自动化可以尽可能地在不需要人工干预的情况下完成构建、测试、合并和打包操作，如下图所示。

图 12.1 – CI 和 CD 自动化

我们继续在持续部署过程中使用自动化，如前面的图所示。在持续部署中，我们将应用程序包从持续集成的尾部提取并部署到测试环境。在测试环境中执行系统级测试后，应用程序包将被部署到生产环境。这种自动化可以通过将持续集成和持续部署结合在一起的工具来完成，如 Jenkins 以及 GitLab 和 Bitbucket 的管道。持续部署自动化也可以在像 ArgoCD 这样的工具中与持续集成分开进行。多个技术和实践方面的支持有助于在持续部署中实现有效的自动化。

第一个重要的部分是版本控制。我们已经看到版本控制对文本工件的重要性，它是 CI/CD 管道的触发器，并且能够将所有工件连接起来，以便理解特定部署或发布过程中涉及的一切。

工件库可以充当大规模二进制工件的版本控制工具，这些工件无法存储在基于文本的版本控制系统中。它们存储中间构建、代码库、虚拟机镜像和可能作为构建过程的一部分创建的 Docker 容器。如果某个组件不需要重建和测试，其工件可以直接从工件库中获取，从而节省时间和精力。

更改的大小是另一个可以减少自动化部署到生产环境所需时间的因素。我们在第四章，利用 精益流程保持工作持续推进中看到，批量大小是促进流程流动的一个重要因素。一个小的独立更改会比一个大型更改处理得更快，因为后者可能会启动大量的重建和测试流程，影响 CI/CD 管道的效率。

自动化尽可能多的步骤，包括部署推送，将显著减少部署的前置时间。允许自动化继续进行构建和测试的后续步骤，贯穿整个持续集成和持续部署阶段，能够保持持续的工作进度，避免由于需要手动操作才能进行下一步而导致的延误。这可能将部署时间缩短到秒级，而非分钟级。

基础设施即代码

部署自动化的关键部分是创建和配置生产环境中的资源。基础设施即代码（IaC）使我们能够通过基于文本的描述来定义所需的基础设施及其资源配置。这些配置文件与配置管理工具一起使用，用于创建新资源、更新资源配置，或者在需要时销毁资源。如第三章中提到的，提高效率与质量的自动化，流行的 IaC 工具包括 Hashicorp 的 Terraform 和适用于 Amazon Web Services 环境的 AWS CloudFormation。

版本控制在建立顺畅的基础设施即代码（IaC）流程中扮演着关键角色，确保配置文件的演变得到记录和维护。如果产品的更改需要对生产环境中的配置进行更改，则配置文件的更改会在预发布环境中创建并进行测试。版本控制中的标签将用于将所有与更改相关的工件连接起来，从源代码到测试，再到配置文件的更改。

构建和测试配置文件的过程与开发产品或其测试没有区别。这有助于确保在生产环境中创建的资源是可靠的，并与任何产品更改保持同步。

选择性部署

在某些组织中，生产环境可能会被划分为多个生产环境。这种划分可能基于以下一些因素：

• 基础设施/资源

• 地理

• 客户

选择性部署利用了环境隔离，通过仅在生产环境的某一个实例上进行部署来实现。以下示例展示了一个面向单个客户的环境的选择性部署。

图 12.2 – 向客户 A 的生产环境进行选择性部署

我们前面的例子允许在有限的生产能力中与客户 A 进行测试，而其他生产环境中的客户看不到变化。在多个环境中的部署允许灵活的发布策略，例如金丝雀发布，其中变化首先发布到特定区域或客户，然后才发布到整个客户群。我们将在第十三章中更详细地讨论金丝雀发布，按需发布以实现价值。

一个现实世界中选择性部署的例子发生在 Facebook。随着 Facebook 的流行增长，发布工程团队通过开发一个从主分支推送系统来跟上开发活动，这使得发布更频繁。正如在engineering.fb.com/2017/08/31/web/rapid-release-at-massive-scale/中详细介绍的那样，部署开始时针对 50%的 Facebook 员工，然后是 0.1%的 Facebook 生产流量，最终推广到 10%的 Facebook 生产流量。

自助部署

可能有正当理由，导致你的组织无法允许自动化部署到生产环境中。通常，这是为了遵守合规政策。

如果是这种情况，自助部署（通常称为一键部署）允许任何人，通常是开发人员，将通过持续集成的更改部署到生产环境中。这种方法仍然使用自动化来执行实际部署，因此开发人员没有对生产环境的无限制访问权限。

使用自动化的部署仍然会被记录和审计，以便追踪完整的活动。每次自动化部署的可追溯性可能会让业务合规部门对自动化部署的推进充满信心。

降低风险

Jez Humble 在《持续交付：通过构建、测试和部署自动化实现可靠的软件发布》一书中著名地说过以下关于部署的话：“如果它让你痛苦，就更频繁地做它，并把痛苦提前。”我们已经看到了一些更频繁进行部署的关键方法。现在我们将看看一些可能帮助我们应对部署痛苦的实践。

以下实践可以帮助我们降低在生产环境中引入故障的风险：

• 黑暗启动

• 功能标志

• 蓝绿部署

• 版本控制

蓝绿部署和版本控制在前几章中已有讨论。在本章中，让我们将重点放在其他的风险缓解措施上。

功能标志

功能标志（或功能切换）是实现黑暗启动和金丝雀发布的主要机制。通过选择功能的可见性，即是否启用或禁用标志，你可以有效地将新功能的部署与功能的发布分离，后者使功能对所有用户可用。

功能标志还允许在生产中出现问题时迅速回滚。只需在发现问题的第一时间禁用功能标志。

设置功能标志时，重要的是要测试功能标志在两个状态下的行为：测试功能标志启用时的效果，然后是禁用时的效果。这个测试应该在预生产环境中完成，远在部署到生产环境之前。

功能标志的存在确实增加了整体解决方案的复杂性，因为它增加了更多的行为测试组合。使用过多的功能标志，尤其是对于那些已经发布很久的过时功能标志，会增加测试的复杂性并产生技术债务。过时的功能标志应该在第一时间被移除。

暗推出

暗推出允许在生产环境中仅对开发人员、测试人员以及通常是 beta 或特定客户可见新功能，而不是对所有客户群体可见。为了实现暗推出，组织通常使用功能标志，根据需要可见性的用户群体来允许或禁止功能的可见性。

以下插图详细展示了开发人员和测试人员如何使用功能标志进行暗推出的示例。

图 12.3 – 使用功能标志进行暗推出的示例

在我们之前的示例中，新功能在生产环境中对开发人员和测试人员可见。这种可见性使他们可以在不影响客户的情况下对该功能进行实验，而客户并不会看到该功能。

开发人员和测试人员可以通过以下方式使用暗推出：

• 测试新的应用基础设施

• 动态控制哪些早期客户可以看到新功能

• 新功能的实验

暗推出通常与金丝雀发布同义。暗推出和金丝雀发布之间的主要区别在于，功能标志允许选择一部分客户查看新功能，以了解他们对金丝雀发布中新功能的反应。

我们现在需要确认这些变更不会对我们当前的生产环境产生不良影响，即使这些部署的变更没有正式发布。为此，我们需要进行测试。让我们来看看我们在生产环境中的测试过程。

验证功能的正常运行

产品的变更，以新功能的形式，已经进入生产环境，但这并不意味着工作已经完成。实际上，工作才刚刚开始。我们需要确保我们的功能按预期运行。这不仅从功能角度来看是对的，还涉及到与非功能性需求（NFR）相关的其他方面。

以下做法帮助我们验证生产环境中的正确行为：

• 生产环境测试

• 在生产环境中的测试自动化

• 测试数据管理

• 测试非功能性需求（NFR）

有些做法在前一章已经介绍过，但现在我们看到生产环境，我们可以更仔细地检查这些做法。让我们看看所有这些做法及其在生产中的应用。

生产测试

在功能开关的配合下进行暗发布，测试可以继续在生产环境的资源上进行。尽管在生产环境中的测试并不完全模拟生产环境的条件，但测试人员仍然应谨慎进行生产环境中的测试。生产测试有以下优势：

• 允许在实时、真实的场景中监控应用程序性能

• 监控应用程序在实时流量下的性能

• 进一步检测漏洞和恶意攻击

• 有助于维护应用程序的质量

在生产中运行的测试应该是测试金字塔顶部的测试，并结合前一阶段的持续集成中运行的部分测试作为基本的 sanity check。我们真正关注的是确认我们即将发布的功能行为是否符合预期。测试金字塔中的其他所有方面应该已经在测试环境和预发布环境中进行了测试。生产中的测试是对早期测试的补充，而不是替代。

成功的生产测试需要详细理解以下因素：

• 在生产环境中使用真实浏览器和设备。测试环境中可能使用了仿真器或模拟器，但它们可能无法展现与“真实设备”相同的行为。

• 允许生产环境中的真实流量来衡量在负载下的应用程序性能。毕竟，这才是应用程序将面对的流量。

• 使用功能开关让少部分开发者、测试人员和测试客户体验新功能。功能开关还允许在出现问题时快速禁用所有用户的该功能。

• 在进行生产测试时，必须持续监控生产环境。这可以在问题出现的第一时间快速关闭任何测试。此外，可能还需要恢复测试操作。

• 使用专用的测试用户账户，以便日志能够区分测试交易和真实交易。

在生产中执行的关键测试之一是 A/B 测试。在 A/B 测试中，功能开关可能会将测试中的新功能（选项“A”）分配给测试用户，以此评估该新选项在行为上是否与当前应用程序（选项“B”）有所不同。

生产环境中的自动化测试

在生产环境中进行测试时，功能开关管理非常重要。功能开关不仅决定功能是否可见，还决定该功能对哪些用户可见。

功能标志管理的一个关键用例发生在 Facebook。在 www.facebook.com/notes/10158791573022200 的博客文章中，Meta（Facebook 母公司）的一名工程师描述了他们如何使用 Gatekeeper 为每个 UI 变更建立 A/B 测试，测试对象为真实的 Facebook 用户。Gatekeeper 确保真实用户参与单一 UI 元素的测试，并确保 A/B 测试之间不会发生冲突。

因为 Facebook 在评估小规模变化时知道一些用户可能会有不理想的用户体验，但 Facebook 仍然致力于提供更好的整体产品。为此，如果足够多的用户不使用该 UI 元素变化，就会视为测试失败，并且不会向所有 Facebook 用户推广。

测试数据管理

虽然 A/B 测试可以用来确定特定功能是否会被最终用户使用，但其他测试可能需要在生产环境中进行，以查看该功能的预期流程和信息是否得以实现。

合成交易使用自动化测试脚本验证应用程序在生产环境中的端到端性能。脚本模拟用户完成交易时的操作。这些合成交易及应用程序作出的响应会被合成监控工具记录。允许合成监控和使用合成交易进行测试，能够让位于功能标志后的测试人员验证应用程序的以下特征：

• 功能性：应用程序是否按正确的路径运行？

• 可用性：应用程序在生产环境中的性能是否足够？

• 响应时间：这是衡量应用程序在生产环境中性能的另一个指标。

合成监控使你能够了解应用程序的关键流程以及它们的表现如何。这些内容还可以提供发布时用监控工具检查的重要事项。

测试 NFRs

将新功能部署到生产环境，并通过功能标志让少数用户可见，允许在发布之前评估关键的 NFRs。

合成交易和监控允许在生产环境中进行性能测试。接收生产环境中真实流量的样本能够进行漏洞测试。

在生产环境中对 NFRs 的测试是发布前功能验证的重要最后一步。这是一个关键步骤，不能忽视。合成交易和功能标志可以使 NFRs 的低风险测试成为可能，从而确保生产环境的稳健性。

当我们在生产环境中执行测试时，我们发现验证过程的关键部分是持续监控。接下来我们将探索进行持续监控所需的内容。

监控生产环境

监控生产环境让我们了解环境的 NFR（非功能需求）是否仍然得到保持，以及部署的新功能是否按照 NFR 中识别的约束条件正常工作并执行。

有一些实践对提供持续监控至关重要。让我们看看这些实践是什么，以及如何确保它们在我们的生产环境中得到建立。

全栈遥测

我们需要在不同层级上监控我们解决方案的重要指标，原因有很多。在较低层级，我们希望确保我们的生产环境稳定，并且没有失败的风险。当我们提升到更高层次来审视我们的系统时，我们希望确保我们拥有可以判断最初启动开发的商业假设是否成立的衡量指标。最终，在商业层面，我们所做的衡量可以判断开发是否与我们的战略保持一致，或者是否需要做出战略上的调整。

为了满足我们所需的各个层级的度量标准，这些度量被称为全栈遥测。以下表格详细说明了各个层级和示例度量标准。

测量层级	示例度量标准
商业	价值流关键绩效指标（Cycle Time, Lead Time）和解决方案关键绩效指标（收入、NPS、转化率）。
IT 服务管理（ITSM）	服务级别目标和其他服务 KPI（服务器正常运行时间和网络可用性）。
产品或解决方案	垃圾回收指标、响应时间、可用性和应用日志。
基础设施	CPU 利用率、RAM 利用率、网络指标和事件日志。

表 12.1 – 解决方案层级的样本度量标准

所需的度量标准必须在持续交付管道的持续探索阶段设计，以确保它们能够在持续部署及之后的阶段轻松收集。计划中的度量标准应包括用于衡量利益假设的商业数据，以及能够告诉我们生产环境中系统状态的技术数据。

可视化显示

通过全栈遥测可以收集大量数据。使数据有用的是组织数据的方式，以便用户能够一目了然地了解环境状态，并及时识别何时需要采取快速行动。

仪表盘提供了一种可视化收集数据的关键方式。这种可视化有助于识别趋势，或理解某个重要指标是否已超出阈值，这可能表示生产中的故障。

以下是一个示例仪表盘。这是 Grafana 的云版本的公共仪表盘，Grafana 是一款用于创建仪表盘的产品。

图 12.4 – 来自 grafana.org 的示例仪表盘

仪表盘的重要性毋庸置疑，但同样重要的是这些仪表盘要对组织中的每个人都可见。透明度使得价值流中的每个人都能获取所有必要的信息，而无需等待批准或争论是否被允许查看单独的度量数据。

联邦监控

在复杂的组织中，显示数据可视化的透明度可能会很困难，尤其是当涉及多个业务线、业务单元和其他小组时。为了确保信息不被孤立，可能需要考虑如何确保信息是联邦化的，并且容易共享和交流。以下图是显示联邦信息的仪表盘示意图。

图 12.5 – 联邦仪表盘示例

在前面的图中，仪表盘显示了所选系统（系统 B）的测量数据。通过在控制面板中选择相应的系统，可以查看其他系统的信息。

在联邦结构中共享信息可以提供更多的透明度，同时鼓励各个业务单元的敏捷性。来自其他来源的数据应与本地业务单元的信息结合，提供对业务单元系统的更全面视图。仪表盘和其他信息展示机制可以显示系统数据，并允许深入查看数据及其来源。

通过仪表盘上共享和可见的各种数据，组织可以持续监控其生产环境。这可以为他们做好准备，应对在发布新功能时可能发生的生产故障。让我们来看看发生生产故障时他们可以采用的做法。

灾难发生时的响应和恢复

快速恢复的能力是 DevOps 方法的关键特性之一。DORA 的关键指标之一是恢复服务的时间，表现卓越的 DevOps 组织能够在几分钟内完成恢复。准备恢复是 CALMR 方法的一个重要部分。

为了促进恢复，我们需要了解以下做法：

• 主动检测

• 跨团队协作

• 混沌工程

• 会话回放

• 回滚并向前修复

• 不可变基础设施

在生产环境中，主动响应至关重要，因为这里是最终用户所在的环境。这里的问题是显而易见的，并且会影响我们的客户。没有及时处理的问题可能会影响到持续交付管道中其他部分的工作。

让我们来看看在生产环境中可以采取的主动做法。

主动检测

因为我们使用功能标志将部署与发布分离，所以可以主动测试并寻找问题，而不会干扰客户，或者更糟糕的是让客户发现问题。为测试人员启用功能标志，可以让他们在生产环境中检查新功能。

利用这个独特机会，在不干扰客户流量的前提下将新功能放入生产环境，测试人员可以进行额外的测试，执行“假设”场景，并最终计划灾难恢复程序，涉及到新功能的发布。

跨团队协作

对客户可见且初期信息较少的问题，可能会成为相互指责的温床。压力在一个非常显眼的问题上增加，伴随着愤怒客户的反馈。解决方案在早期可能并不明显。正是这种类型的压力，可能会考验跨团队协作的有效性，但它已被证明是解决此类问题最有效的方式。

拥有来自不同领域的开发和运维人员是我们在第一章，引入 SAFe®和 DevOps中最初讨论的 Flickr 成功的关键之一。跨部门的协作至今仍然是成功的关键。

要实现真正的协作，我们需要朝着我们在第二章，共同责任文化中识别的以任务为导向、心理安全的创造性文化迈进。随着这种文化的转变，集体拥有感就会产生，团队在不同领域之间协作，共同识别问题的根本原因，并迅速找到解决方案。这样，问题就会成为学习的机会。

混沌工程

在发布功能之前，你可以主动进行一个混沌工程练习，利用功能标志来确保影响不会被现有用户看到，这是一项值得做的练习。

最著名的混沌工程案例来自 Netflix。正如在netflixtechblog.com/the-netflix-simian-army-16e57fbab116的博客文章中所详细描述的那样，Netflix 运行了一套名为“Simian Army”的工具，模拟亚马逊 Web 服务云中的生产故障。其中最著名的工具是 Chaos Monkey，它模拟虚拟服务器宕机。实验通常在工作日进行，工程师们会实时监控并处理发现的问题。

你可以进行类似于 Chaos Monkey 执行的练习。通过模拟故障情况来测试新功能是否足够健壮。在实验结束后，通过复盘来确定下一步行动。

完整的方法详细介绍请参见第六章，从生产故障中恢复。如果在错误预算中有足够的时间，可以对已经发布的现有功能进行混沌工程练习。如果功能管理非常健全，可以对未发布的功能进行练习。

会话重放

一个有用的故障排除工具是会话回放。会话回放是记录单个用户交易并回放这些交易的能力。执行会话回放具有以下优点：

• 开发人员可以了解用户在网站的可用性方面可能遇到的问题，并且可以洞察用户如何真正使用某个功能。

• 开发人员可以查看用于在网站上执行欺诈性交易的操作，这有助于关闭潜在的漏洞。

• 对于生产故障，开发人员可以查看用户执行的具体操作序列，从而导致故障发生。

在客户端执行的会话回放展示了终端用户的操作视角。这些工具允许开发人员看到光标的位置、点击的内容以及输入的内容，像视频回放一样。Dynatrace 和 Datadog 是提供会话回放功能的工具示例。

基于服务器的会话回放捕获所有网站流量，包括键入内容和点击的内容，但不包括滚动和鼠标移动。

使用会话回放时，必须关注会话数据。此类数据通常包含私人信息，如密码，并且可能需要大量存储空间。

回滚和向前修复

当生产故障发生时，恢复稳定环境的两种快速方法包括回滚和向前修复。

回滚是将生产环境恢复到先前的版本，即不包含可能导致生产故障的最新更改的版本。正如我们在第六章《从生产故障中恢复》中看到的那样，回滚的两种常见方法是蓝绿部署和功能标志。

蓝绿部署是一种简便的方法，可以将生产环境回滚到空闲环境，并将原先空闲的环境恢复为活跃状态。在回滚过程中，必须特别注意表示状态的组件，如数据库或易变存储。这些组件在回滚时需要谨慎处理。

功能标志是一种简便的方法，用来在新功能发布导致生产环境故障时隐藏该功能的可见性。将功能标志切换回关闭状态不需要进行大量的代码或配置更改。

向前修复是解决生产环境稳定性的另一种方法。为了进行向前修复，你需要在持续交付流水线中开发并传播故障修复，以便将其部署并发布到生产环境。当执行向前修复时，建议你通过持续交付流水线使用标准部署流程，并且不要跳过任何测试。绕过测试进行“快速修复”可能会导致更大的技术负担。

不可变架构

自动化部署到测试、预发布环境，最终到生产环境的一个主要原因是为了使架构不可变。也就是说，环境中的任何变化都不能手动进行。

任何环境中的变化必须通过持续交付管道进行，并且每个变化所需的工件必须记录在版本控制中。与版本控制和持续交付管道的紧密耦合防止了配置漂移或不同环境之间的变化差异。

总结

在本章中，我们继续探索将持续交付管道引入生产环境的过程。在持续探索阶段完成设计后，我们的特性进入了持续集成阶段进行开发和测试，现在准备部署到生产环境。自动化在执行将变化引入生产环境的步骤中起着关键作用，可能使用基础设施即代码（IaC）来创建和配置新的生产资源。

即使在生产环境中引入了新变化，测试仍然会进行，以便在发布之前建立信心。功能标志允许工程师和选定的测试客户在生产环境中对新变化进行测试，同时对普通用户隐藏。以合成事务形式存在的测试数据允许进行功能测试和非功能性需求（NFRs）测试。

在生产环境中的监控让我们能够看到生产中测试的成功或失败。我们希望确保从系统资源到可能作为领先指标的那些度量数据都能反映出我们希望实现的收益假设。我们希望这些数据在仪表盘上可见，且对所有人透明。如果监控显示生产环境出现问题，我们将准备采取行动。整个价值流协同工作，找到根本原因。我们可以回滚到之前的版本，或修复问题，并通过持续交付管道传播修复。

我们的变化现在已经进入生产环境。接下来，我们等待最后一个事件：发布给我们的用户，以便他们能利用这些变化。为此，我们将在下一章中探讨我们的持续交付管道的最后阶段——按需发布。

问题

1. 什么有助于减少部署到生产环境的交付时间？（选择 3 项）

   1. 单元测试

   2. 小批量变化

   3. 版本控制

   4. 行为驱动开发

   5. 自动化部署

2. 哪种实践可以让你执行金丝雀发布？

   1. 基础设施即代码

   2. 蓝绿开发

   3. 选择性部署

   4. 自助部署

3. 功能标志允许……（选择 3 项）

   1. 测试人员在生产环境中查看未发布的特性

   2. 让你更快地运行单元测试

   3. 开发人员开始部署到生产环境

   4. 在生产环境故障发生时回滚新特性

   5. 进行 A/B 测试的精选客户群体

   6. CI/CD 管道的执行

4. 在生产环境中运行合成事务可以帮助衡量……（选择 3 项）

   1. 周期时间

   2. 功能性

   3. 可扩展性

   4. 可用性

   5. 响应时间

5. 全栈遥测应该衡量哪些操作级别？

   1. IT 服务管理

   2. 商业

   3. 解决方案

   4. 基础设施

   5. 上述所有

6. 服务器端会话重播中可以回放哪些信息？

   1. 向下滚动网页

   2. 网页表单上的输入字段

   3. 将鼠标光标从左向右移动

   4. 水平滚动到按钮

7. 在不可变架构中如何进行生产环境的更改？

   1. 管理员更改生产环境中的文件。

   2. 管理员更改配置文件并执行 IaC 工具来创建更改。

   3. 管理员更改配置文件，将更改提交到版本控制，并执行 CI/CD 管道。

   4. 管理员重新启动生产服务器。

8. 请列举两个有助于实现不可变架构的实践。

   1. 特性标志

   2. 版本控制

   3. CI/CD 管道

   4. 蓝绿部署

   5. 行为驱动开发

进一步阅读

• 来自 Scaled Agile 特性指导的总结，关于持续交付管道中的持续部署：www.scaledagileframework.com/continuous-deployment/

)

• 来自 Meta（Facebook 母公司）工程师的观点，描述了 Facebook 如何进行测试、部署和发布：engineering.fb.com/2017/08/31/web/rapid-release-at-massive-scale/

• 持续交付：通过构建、测试和部署自动化实现可靠的软件发布，作者 Jez Humble 和 David Farley——关于创建 CI/CD 管道的权威指南，详细讲解了集成、部署和发布。

• 来自 LaunchDarkly 的博客文章，LaunchDarkly 是特性标志管理的供应商，描述了特性标志的使用和好处：launchdarkly.com/blog/guide-to-dark-launching/

• 一篇文章描述了在生产环境中进行测试的优势：www.softwaretestingmaterial.com/testing-in-production/

• 一篇详细的博客文章，描述了在生产环境中进行测试的用途和优势：www.tothenew.com/blog/testing-in-production-environment-what-why-and-how/

• 一篇文章描述了 Facebook 如何使用 Gatekeeper 监控生产环境中的用户测试：www.facebook.com/notes/10158791573022200/

• 一篇博客文章，描述了在测试新特性时使用合成事务：www.netreo.com/blog/synthetic-transactions/

• 一篇来自 Netflix 工程师的博客文章，描述了他们如何使用一套称为“猴子军团”的工具进行混沌工程：netflixtechblog.com/the-netflix-simian-army-16e57fbab116

第十三章：按需发布以实现价值

我们现在已经完成了持续交付管道的旅程。我们从一个为客户提供价值的假设开始，并将其转化为在持续探索中开发的功能。在持续集成中，我们逐个故事地开发功能，并将这些变更应用到版本控制中，利用持续交付管道的自动化构建和测试这些变更，直到它们准备好进入生产环境。在持续部署中，我们将变更传播到生产环境，但始终将其隐藏，直到我们准备好发布。

现在我们准备将变更发布给客户。按需发布我们的变更包括以下四个活动：

• 将这些价值发布给客户

• 在运营中稳定我们的解决方案

• 衡量价值

• 学习结果

让我们从查看发布过程开始。

向客户发布价值

到目前为止，我们已将变更放入生产环境，并测试它们以确保功能、安全性和可靠性。现在我们准备发布。我们希望将变更发布给客户，原因如下：

• 我们认为现在是客户可以利用的时机，并且组织认为市场需求较高时

• 我们有信心这些变更不会对生产环境产生负面影响

即便有这些原因，我们也许不希望一次性发布所有内容。1985 年 4 月 23 日，可口可乐公司宣布对其旗舰软饮配方进行首次重大更改。新可乐在超过 200,000 次盲测中，成功击败了可口可乐的主要竞争对手百事可乐。然而，发布后，反应迅速且负面。对新配方的强烈反对迫使可口可乐在仅 79 天后重新推出原始配方，命名为可口可乐经典。从那时起，许多公司在向整个市场发布之前，采取了逐步发布的策略。

如果我们希望采用逐步发布的方式，我们将使用以下实践：

• 功能开关

• 黑暗发布

• 通过组件架构解耦发布

• 金丝雀发布

在前面的章节中，我们已经讨论了功能开关和黑暗发布，参考第十二章，持续部署到生产环境。让我们来看一下通过组件架构解耦发布和金丝雀发布的其他实践。

通过组件架构解耦发布

在第十章，持续探索与发现新特性中，我们讨论了如何将架构设计作为开发新特性时的关键活动之一。其一部分是确保可发布性，以符合组织的商业优先事项。

实现这种可发布性的一种方法是将你的产品或解决方案架构成主要的解耦组件。这些组件可以有各自独立的发布节奏。

在第二章，共享责任文化一章中，我们首次介绍了运营和开发价值流的概念。我们讨论了开发价值流是如何设计、开发、测试、发布并维护一个产品或解决方案的，并且我们识别出几个开发价值流，它们的解决方案是我们视频流服务的运营价值流所依赖的。

回到这个例子，我们来检查一下其中一个开发价值流，即维护移动应用程序的价值流。这个价值流有多个组成部分，每个部分的发布节奏不同，如下图所示。

图 13.1 – 移动应用程序价值流的解耦发布计划

在我们的移动应用程序价值流示例中，我们会在漏洞出现后，随着它们通过持续交付管道的流动，发布安全更新。

其中一个组成部分是移动设备上看到的界面和逻辑，也就是我们所说的前端。这里的开发可以以较快的节奏发布，实际上是在每个冲刺的结束时发布。

另一个组成部分是处理视频流服务数据中心或云端的逻辑和处理，称为后端。在这个例子中，该组件的发布周期是每月一次。

金丝雀发布

“金丝雀发布”这一术语来源于矿业中的做法——带一只金丝雀进入煤矿。金丝雀会作为有毒气体存在的警告。由于其体积较小，如果它在煤矿中死亡，说明矿井中存在有毒气体，矿工应该立即撤离。

就现代产品开发而言，金丝雀发布是将产品或新特性发布给一个小范围的用户群体，以便在全体用户之前获取他们的反馈。

要设置金丝雀发布，再次使用功能标志来决定谁可以在生产环境中看到变更。这一功能标志配置如以下图所示。

图 13.2 – 使用功能标志的金丝雀发布配置

另一种执行金丝雀发布的方式是在分布式生产环境中。如果生产环境位于不同的地理区域，变更会首先在一个生产环境中发布，供一部分用户使用，而其他生产环境则保持其版本不变。如果一切顺利，最终其他区域的生产环境将会被升级。

金丝雀发布的优势在于，它们允许进行 A/B 测试，在该测试中，接受变更的A组可以与未变更的B组或对照组进行比较，以查看新的变更是否对用户行为产生了预期的影响。将金丝雀发布作为实验进行时，确实需要能够测量用户和系统行为的能力，这是全栈遥测的一部分。

可能会有一些情况不适合进行金丝雀发布，以下是一些原因：

• 如果解决方案是关键任务、医疗或安全系统的一部分，且对故障的容忍度较低

• 如果最终用户对被当作小白鼠或测试版测试人员做出负面反应

• 如果变更需要对后端配置进行修改，如数据库架构，而这些修改与当前生产版本不兼容

随着我们将发布从最初的金丝雀用户扩展到整个用户群体，我们希望能够确保我们的生产环境保持弹性。这可能需要我们稳定解决方案并确保其正常运行。在接下来的部分中，我们将探讨实现这一目标的步骤。

稳定并运营解决方案

我们的目标是确保生产环境保持稳定，能够承受新的变更，并持续提供可持续的价值交付。为了维持这一活动，我们希望应用以下实践：

• 网站可靠性工程

• 故障转移和灾难恢复

• 持续安全监控

• 为运营架构设计

• 监控非功能性需求（NFRs）

我们之前在第十二章中探讨了如何测试和监控 NFRs，持续部署到生产环境。让我们来看看剩余的实践。

网站可靠性工程

我们首次在第六章中了解了网站可靠性工程（SRE），从生产故障中恢复。在这一章中，我们看到网站可靠性工程师使用以下四种实践来维护生产环境，特别是当大规模系统需要高可用性时：

• 使用服务级指标（SLI）和服务级目标（SLO）制定错误预算

• 通过发布工程创建发布标准

• 与发布协调工程团队合作进行产品发布

• 通过混沌工程和事件管理程序进行恢复演练

在第六章中，我们看到，如果可用性 SLO 为四个九（99.99%的可用性或更高），那么每月允许的停机时间为 4 分钟 23 秒。为了保持这一可用性，SRE 会使用前述的实践来确保系统的可靠性，并且会定义和排练标准的事件管理政策，以最小化问题发生时的停机时间。

谷歌采纳的其他原则和实践能帮助我们更好地理解 SRE 学科及其如何推动 DevOps 方法。为了理解这些额外的原则和实践，可能需要了解 SRE 在谷歌的起源。

SRE（站点可靠性工程）始于 2004 年，由 Ben Treynor Sloss 在谷歌发起。他的初衷是重新思考系统管理的操作方式。他希望从软件开发的角度来解决运营中发现的问题。从这个角度出发，除了之前提到的实践之外，还出现了以下原则：

• 消除繁重工作，即找到重复性的任务并查看是否能够消除这些任务

• 增加自动化使用，作为一种有效消除繁重工作的方式

• 监控生产环境的各个方面，这有助于实现可观察性

Sloss 为其初始 SRE 团队招募的人员将一半时间用于开发，另一半时间则用于操作，跟踪他们从头到尾开发的变化。这使他们能够培养必要的操作技能，并保持开发专长。

自 2004 年以来，随着技术的进步，许多实践被引入 SRE 学科。然而，许多站点可靠性工程师仍然坚持之前提出的原则。在可靠性作为关键非功能性需求的情况下，采纳这些原则和实践可能会带来实际的好处。

容错和灾难恢复

穆菲定律（Murphy’s Law）著名地指出：“任何可能出错的事情，都会出错。”从这个意义上讲，问题不在于系统是否会遭遇灾难，而在于何时遭遇灾难。我们已经探索了防止灾难的方法，并使用混沌工程来模拟灾难，但是否还有其他准备灾难的方式？

灾难恢复专注于确保在自然或人为灾难发生时，确保对业务重要的技术方面尽快恢复。灾难恢复包括以下要素，以为最坏的情况做好准备：

• 灾难恢复团队：一群负责创建、实施和管理灾难恢复计划的人员。灾难恢复计划概述了团队在紧急情况下需要遵循的职责，包括与其他员工和客户的沟通。

• 风险评估：灾难恢复团队应识别可能发生的场景，并为每种情况制定相应的响应措施。例如，如果发生网络攻击，灾难恢复计划中的步骤应该是什么？

• 资产识别与评估：灾难恢复团队应识别所有系统、应用程序、数据及其他资源。识别过程中需要评估它们对业务连续性的重要性，以及恢复它们的相关指引。

• 资源备份：灾难恢复计划应确定需要备份的资源、备份频率、备份存储位置以及备份保存的时间。

• 演练：灾难恢复计划的所有部分应定期进行演练。应尝试恢复备份，以发现备份过程中的缺陷，并确定备份是否有效。在演练过程中发现的任何缺陷应进行修复，以改进灾难恢复计划。演练应检查不断变化的威胁，看看是否需要在灾难恢复计划中加入新的措施。

灾难恢复计划将根据以下两个度量目标来确定整体策略：

• 恢复点目标（RPO）是指数据的状态，通常从上次备份的时间开始计算，当资源恢复时恢复点的状态。

• 恢复时间目标（RTO）是指灾难发生后可接受的停机时间。

让我们通过以下图示的示例来解释这些目标。

图 13.3 – RPO 和 RTO 的示意图

在前面的图示中，我们每四小时备份一次资源。我们已经练习了对资源进行灾难恢复，并且能够在 30 分钟内可靠地恢复操作。当灾难发生时，如果是熟悉的情况并且已经经过演练，我们的服务恢复时间将与我们的 RTO 目标相匹配，为 30 分钟。

对于 RPO，我们需要查看上次备份的时间点。在我们的示例中，上次备份与灾难之间的时间差可能高达四小时。备份频率越高，RPO 就越低。

灾难恢复机制可以采取多种形式。组织可以选择使用以下方法之一或多种组合：

• 备份：备份是最简单的灾难恢复形式。请注意，这确保了数据的安全，但对于基础设施没有任何帮助。

• 冷站点：冗余的第二生产环境。这可以确保业务连续性，但无法恢复数据。蓝绿部署就是一个冷站点的例子。

• 热站点：一个冗余的第二生产环境，其数据与活动生产环境定期同步。

• 灾难恢复即服务（DRaaS）：供应商将组织的处理能力从组织自身的基础设施转移到其自身的（通常是云基础设施）中。

• 备份即服务（BaaS）：备份由第三方供应商执行，并存储在异地或云基础设施中。

• 数据中心灾难恢复：这些是组织场所上的设备，用于应对如火灾或停电等灾难。这些设备的例子包括备用发电机或灭火设备。

持续安全监控

在我们持续交付流水线的前期阶段，我们对安全的关注重点是预防。我们希望确保我们设计和开发的变更不会引入安全漏洞。因此，我们在流水线中执行的自动化安全测试检查了代码变更。

随着代码发布，我们的关注点从预防转向检测来自恶意行为者的威胁。我们寻找利用当前未知漏洞的攻击或入侵。

国家标准与技术研究院（NIST）将持续安全监控（CSM）视为信息安全持续监控。在 2011 年 9 月发布的白皮书中（nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-137.pdf），他们将信息安全持续监控定义如下：

信息安全持续监控（ISCM）被定义为保持对信息安全、漏洞和威胁的持续意识，以支持组织的风险 管理决策。

白皮书进一步定义了通过以下步骤实施 CSM 的过程：

1. 通过查看风险容忍度来定义策略，包括资产的可见性、漏洞意识、当前威胁信息，以及对任务或业务的影响。

2. 建立一个程序，包括指标的定义、状态监控频率和技术架构。

3. 实施该程序并收集与安全相关的信息，用于度量、评估和报告。尽可能实现信息的收集、分析和报告自动化。

4. 分析发现并报告。

5. 响应发现的问题。

6. 审查并更新监控程序。

需要监控的资产不仅包括由组织直接维护的资产，还可能扩展到第三方和供应商。监控工具可能会查看以下资产：

• 已知资产：属于组织资产清单的一部分

• 未知资产：被遗忘的资产，包括开发网站或旧的营销网站

• 恶意资产：由恶意行为者创建的资产，可能伪装成组织的域名

• 供应商资产：第三方供应商拥有的资产

一旦识别出资产，应检查其可能的威胁和漏洞。以下是一些常见的威胁和漏洞：

• 不必要的开放 TCP/UDP 端口：任何开放的端口如果相关服务配置错误或未修补，可能会成为问题，从而可能暴露出漏洞。

• 中间人攻击：这是一种网络攻击，攻击者介于两方之间，双方认为它们有直接连接，但攻击者可能监听甚至修改信息，然后再传输给另一方。

• 邮件安全差：这可能会让你的组织暴露在邮件欺骗攻击中。

• 域名劫持：攻击者在未获得域名所有者许可的情况下，改变了一个组织的域名注册。

• 跨站脚本攻击（XSS）漏洞：攻击者可以在网页上注入客户端脚本，从而绕过访问控制。

• 泄露的凭证：通过数据泄露事件发现，它们允许攻击者访问组织系统。

• 数据泄露：私人或敏感数据的暴露。

• 域名拼写欺骗：这是一种网络域名抢注形式，攻击者注册与已知组织域名相似的域名，期望有人错误输入网址并进入攻击者的网站。

识别这些攻击可能是自动化监控后进行的评估的一部分。缓解步骤和行动将明确谁在组织内执行修复步骤并协调响应。

针对运维的架构设计

在持续交付管道的这个阶段执行的支持活动将对系统架构产生深远的影响，甚至可能推动产品或解决方案未来的方向。这些可能是系统架构师在持续探索阶段考虑新功能时所做的架构决策的一部分。

在这一阶段做出的决定可能会被纳入持续探索阶段，具体项目包括以下内容：

• 由站点可靠性工程师创建的修复和新自动化工具

• 因灾难恢复计划中发现的缺陷而导致的更改，这些缺陷影响了测试、预发布或生产环境的配置。

• CSM 发现的新漏洞，产品架构必须防止这些漏洞未来的发生。

因此，系统架构师成为了有意架构与突发设计的平衡点，监督着产品或解决方案的预期架构，同时也考虑环境等因素对架构变更的需求。

这个阶段的学习不仅限于架构方面。我们还必须从产品性能的角度评估我们的开发是否实现了收益假设。为此，我们需要衡量我们解决方案的价值。让我们在下一部分中探讨这个问题。

衡量价值

在持续交付管道的设计与开发过程中，我们已对我们的更改进行了一系列测试。现在我们将查看最终测试，以回答以下问题：我们的开发努力是否为客户带来了价值，达到了既能使客户受益，又能使组织受益的程度？

为了帮助我们回答这个问题，我们将查看以下活动：

• 创新会计

• 证明/反驳收益假设

我们将首先回顾创新会计及其来源：精益创业循环。基于这些知识，我们将看到领先指标和滞后指标如何验证或反驳我们在持续探索中创建的收益假设。

创新会计

我们首先在第五章中看到了创新会计，衡量过程和解决方案。在本章中，根据埃里克·里斯的《精益创业：当今企业家如何利用持续创新创造极为成功的企业》，我们了解到，衡量标准对于评估收益假设是否成立非常重要。

里斯在他后续的书《创业之道：现代公司如何利用企业家管理转变文化并推动长期增长》中进一步扩展了创新会计。在书中，他对创新会计给出了以下定义：

创新会计（IA）是一种评估进展的方法，当一个成熟公司通常使用的所有衡量标准（收入、客户、投资回报率、市场份额）都 几乎为零时，才适用此方法。*

他提出了三层创新会计，每一层都有不同的衡量标准。现在我们来看看这些层级。

第一层级：仪表盘衡量标准

这些衡量标准作为起点。里斯建议设置一个仪表盘。在这个初步的仪表盘上，显示的是开发团队认为重要的面向客户的衡量标准。这些衡量标准基于每位客户的投入。以下是用于学习的每位客户的衡量标准：

• 转化率（通常是指从免费版到付费版产品的客户百分比）

• 每位客户的收入

• 每位客户的生命周期价值

• 客户保持率

• 每位客户的成本

• 推荐率

• 渠道采用

像这样的衡量标准有助于强化开发可以在观察到其努力成果后影响这些标准的观点。这里可见的衡量标准有助于保持开发过程与反馈保持一致。

第二层级：商业案例衡量标准

在第二层级中，我们会使用一组不同的衡量标准深入探讨。在这里，我们尝试量化“信念飞跃假设”，正如里斯所说的那样。信念飞跃假设分为以下两类：

• 价值假设：这些描述了用户从产品或解决方案中获得的价值

• 增长假设：新用户如何找到产品？

这些类型的假设对于任何新开发都是必需的，否则就不会有新的开发。这些假设通过最小可行产品（MVP）及其他验证性实践得到检验。

以下衡量标准展示了假设和假设的分类：

• 客户保持率（价值假设）

• 推荐率（价值假设）

• 口碑推荐（增长假设）

价值假设关注客户行为。它们基于用户的积极行为来实现。增长假设则关注可持续增长。

第三层级：净现值

在这个层级，我们关注的是长时间段的表现。随着你获得新的数据，并重新评估或比较当前数据与预测数据的差异，变化会逐步显现。我们关注的是产品未来表现的长期驱动因素。

以下度量指标可能为长期提供指导：

• 网站用户数量

• 访客转化为用户的百分比

• 付费用户的百分比

• 用户支付的平均价格

这些度量指标通常涉及的不仅仅是开发团队。财务团队可能也会参与进来，目标是在此时将重点转向产品的财务表现。

证明/反驳收益假设

现在我们已经了解了创新会计中的步骤，接下来我们来看看它们如何与我们在持续探索中创建的收益假设对照。

在我们穿越持续交付管道的旅程中，我们在持续探索中创建了我们的收益假设。为了衡量假设的有效性，我们可能会在仪表板中加入第二级度量标准。我们的仪表板通过我们在测试、预发布和生产环境中设计的全栈遥测，自动获取这些度量数据。

我们可能会从持续部署阶段的测试中获得一些迹象，但真正的测量结果会来自按需发布，首先是在 A/B 测试或金丝雀发布中，随后是一般发布。我们希望看到表现与初始收益假设之间的所有关联。

我们现在在此步骤中收集和分析的数据，不仅仅是为了改进产品，也为了改进我们的价值流和开发流程。让我们探索下一个部分，看看这两者是如何实现的。

从结果中学习

根据我们的学习，我们现在需要找出最佳的下一步。无论是从产品角度，还是从价值流角度来看，这都是正确的。

对于我们的产品来说，关键在于确定最佳方向。这可能意味着是否该调整方向，改变我们的整体产品战略，或者坚持原有方向继续前进。

对于我们的价值流，这段时间用于反思如何改进。我们可以从中学到哪些经验，以便改进？

以下实践用于确定产品未来方向以及价值流的未来方向：

• 《精益创业》中的调整方向或坚持原有方向

• 不断改进

• 价值流映射会议

我们进行这种学习是为了能够在持续交付管道的起始阶段重新聚焦，设定执行的想法。我们通过改进价值流来提升持续交付管道的表现。

让我们来看一下这些可以帮助我们改进的实践。

调整方向或坚持原有方向

在 第十章 持续探索与寻找新功能 中，我们观察了 Eric Ries 的 Build-Measure-Learn 循环在 SAFe® 精益创业循环中的应用，在这里我们看到了 Epics 是如何通过效益假设来创建的。这些 Epics 通过最小可行产品（MVP）进行实施，MVP 作为实验来验证或反驳效益假设。MVP 通过创新会计和领先指标的追踪进行评估，这些指标将用于决定是转变方向还是坚持下去。

我们现在正处于作出这一决定的时刻。对于我们的 ART，MVP 可能是通过持续交付管道初期创建的一些功能。我们已经开发了这些功能，进行了测试，并通过管道中的持续集成和持续部署阶段将其部署到生产环境中。现在，在按需发布中，我们将 MVP 作为功能展示给用户群体，看看效益假设是否得以验证。根据我们通过完整堆栈遥测收集的创新会计指标，我们做出了以下两个决定：

• 转变方向：我们的功能未能达到预期效益假设。是时候朝着不同的方向前进了。这可能包括停止该产品方向的开发。

• 坚持下去：我们的效益假设已经得到验证。我们应该继续开发更多功能来增强我们的 MVP。

请注意，即使在我们为 MVP 作出坚持决策之后，我们的功能仍然会被评估，以确定它们是否证明是有价值的，并且产品方向仍然能与客户产生共鸣。

不懈改进

我们第一次看到不懈改进是在我们首次检查 SAFe 精益之屋时，在 第二章 共享责任文化 中提到。我们提到，在不懈改进中，我们寻求通过那种“潜在的危险感”来寻找变得更好的机会。

在整个开发过程中，团队和 ART 一直在寻找改进价值流动的机会。团队定期在每次迭代结束时举行回顾会议，以识别团队层面的问题，而 ART 在每个项目增量结束时举行检查与调整（I&A）活动，以便审视系统性问题。

其他改进可能会出现在持续交付管道本身。更新的工具、额外的测试以及持续的维护使 ART 能够保持或改进他们创建实验的方式，以验证效益假设。

额外的价值流映射会议

不懈改进的另一个重要部分来自于价值流管理和持续学习，这些理念最早在 第九章 通过持续学习走向未来 中进行了讨论。

我们最初在价值流映射中执行的一个活动，不仅是绘制当前的价值流图，还包括识别一个理想的未来状态价值流。改进行动可以通过向着理想价值流的小步迭代变化来实现。

另一个改进步骤是至少每年举行一次价值流映射会议，以评估当前迭代中的价值流。这使得 ART 能够查看目前阻碍价值流动的瓶颈。在这次价值流映射会议中，可以为新的改进确定一个新的未来状态价值流。

总结

在本章中，我们已达到持续交付管道的最后阶段：按需发布。在使用功能标志让测试人员查看开发环境中的新变化后，我们可以使用它们将这些变化逐步发布给少量用户进行金丝雀发布。我们可能还希望设置架构，使每个组件具有不同的发布节奏。发布后，我们希望确保这些变化不会破坏环境，并且我们的整体解决方案是稳定的。为此，我们遵循 SRE 的原则和主要实践，包括准备灾难恢复。

在稳定环境中发布变更后，是时候通过全栈遥测来衡量业务结果了。我们在持续探索过程中选择了我们的度量标准，依靠创新会计原则。通过查看每个人都可以看到的仪表板上的这些度量，我们可以尝试确定我们在持续探索中创建的利益假设是否有效。

基于利益假设是否有效，我们必须决定是转型、改变方向，还是坚持并继续在相同的产品方向上发展。在做出决定后，ART 通过回顾、I&A 以及定期绘制价值流图来查看其他改进机会。

这使我们接近第三部分的结尾。接下来，我们将在本书的最后一章中看看新兴趋势，以及在 DevOps 采纳过程中取得成功的一些技巧和窍门。

问题

1. 以下哪些是 SRE 的关键实践或原则？（选择 3 个）

   1. 使用功能标志进行 A/B 测试

   2. 通过自动化减少无谓劳动

   3. 在生产环境中运行单元测试

   4. 通过错误预算了解自己能承受多少风险

   5. 混沌工程

   6. 在生产环境中测试

2. 以下哪些应成为灾难恢复计划的一部分？（选择 3 个）

   1. 确定灾难恢复团队

   2. 资源识别

   3. 供应商联系信息

   4. 服务器原理图

   5. 备份计划

   6. 重要文件的纸质版本

3. 数据库每两小时进行一次备份。如果数据库服务器崩溃，预期的 RPO 是多少？

   1. 2 小时

   2. 4 小时

   3. 8 小时

   4. 16 小时

4. CSM 可以检测哪些问题？（选择 2 个）

   1. 中间人攻击

   2. 许可证违规

   3. 跨站脚本（XSS）漏洞

   4. 弱密码

5. 哪些做法不是持续改进的例子？（选择 2 项）

   1. 回顾会议

   2. 代码审查

   3. 检查与适应（I&A）

   4. 向持续交付管道添加测试

   5. 代码注释

进一步阅读

• 关于 New Coke 推出的描述：www.coca-colacompany.com/company/history/the-story-of-one-of-the-most-memorable-marketing-blunders-ever

)

• 另一篇关于 New Coke 推出的描述，增加了竞争格局的视角：www.vox.com/2015/4/23/8472539/new-coke-cola-wars

• blog.getambassador.io/cloud-native-patterns-canary-release-1cb8f82d371a – 介绍金丝雀发布并详细说明实现、好处和使用实例的博客文章

• 关于金丝雀发布的有趣参考资料：martinfowler.com/bliki/CanaryRelease.html

)

• 来自 LaunchDarkly 的博客文章，LaunchDarkly 是一个功能标志管理解决方案的供应商，介绍了如何使用功能标志进行金丝雀发布：launchdarkly.com/blog/what-is-a-canary-release/

)

• 来自 Google 的 YouTube 视频，详细介绍了站点可靠性工程的历史，包括 Ben Treynor Sloss 的视角：www.youtube.com/watch?v=1NF6N2RwVoc&t=6s

)

• VMWare 关于不同类型灾难恢复的详细资料：www.vmware.com/topics/glossary/content/disaster-recovery.html

)

• 来自 NIST 的白皮书，详细介绍了信息安全持续监控（Information Security Continuous Monitoring），这是在谈论 CSM 时常用的内容：nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-137.pdf

• 来自 Upgard 的博客文章，Upgard 是 CSM 工具的供应商，定义了主要的安全漏洞：www.upguard.com/blog/continuous-security-monitoring

• The Startup Way: How Modern Companies Use Entrepreneurial Management to Transform Culture and Drive Long-Term Growth by Eric Ries – 精益创业的续集；进一步定义了如创新会计等概念

• 一篇博客文章，概述了关于创新会计的更多思考：www.boldare.com/blog/lean-startup-innovation-accounting/

第十四章：避免陷阱并迈向未来

自 2009 年在 Velocity 大会上 Flickr 的演讲以来，DevOps 运动在许多方面发生了演变和变化。技术的最新进展，如容器和 Kubernetes，已经改变了许多核心实践。新方式的出现，如站点可靠性工程（SRE），也改变了人们扮演的角色。

在本章中，我们将讨论如何开始将全书讨论的原则和实践融入其中，从而成功地迈向 DevOps 转型或转向 SAFe®。

我们将探讨一些可能在 DevOps 演进中发挥重要作用的新兴趋势。我们将关注 XOps，它试图将更多组织部分融入 DevOps 和 DevSecOps 中所看到的协作方法中。我们还将看看与标准线性价值流不同的另一种视角。

我们还将探讨一些新兴技术，它们有望改变我们的工作方式。通过 IT 运维中的 AI，也称为 AIOps，我们将探讨人工智能（AI）和机器学习（ML）在预测问题和漏洞中日益增长的作用。我们还将考察版本控制与持续集成/持续部署（CI/CD）的融合，在此过程中我们将关注 GitOps。

最后，我们将看一些常见问题，并给出一些答案。

避免陷阱

在朝着 DevOps 方法前进的过程中，显然并非每个人都会走相同的路径。不同的组织处于不同的阶段，准备好接受所需的思维方式转变，以便实现成功的 DevOps 旅程。

话虽如此，我们将根据本书前几章所学，来看一组启动或重启 DevOps 方法的步骤。你会发现，从一个步骤到下一个步骤之间通常没有直接的路径。

让我们来看看 DevOps 旅程中的以下步骤：

• 了解系统

• 从小做起

• 开始自动化

• 衡量、学习并调整

现在让我们开始我们的旅程吧。

了解系统

无论我们是从头开始，还是在失败后重新开始，我们都需要从精益思维中的改进 Kata 步骤入手，评估我们当前的状况。这一评估应当是对现有流程、流程背后的人以及工具是否支持流程的全面审视。

观察所有这些方面的一种方式是进行价值流映射，正如在第七章中首次讨论的那样，映射你的价值流。正如我们在那一章中最初提到的，进行价值流映射工作坊可以帮助你发现以下几个方面：

• 从头到尾的工作流过程步骤

• 执行这些过程步骤的人

• 可能的改进领域

价值流映射工作坊还提供了一个从系统更广阔视角审视整个开发工作范围的视角。这个系统视角不仅仅是一个过程步骤和改进的系列，还包括工具在此过程中的作用，或者在尚未纳入时工具可以如何在过程里发挥作用。

价值流映射工作坊会生成两个价值流：当前价值流和一个包含增强和改进、降低周期时间和交付时间并提高完成度和准确度（%C&A）的理想价值流。记录这些增强项，以便价值流中的人员作为持续****学习（CL）的一部分来处理它们。

从小做起

在价值流映射工作坊后，查看来自理想价值流的改进和增强清单。从这些增强项中，价值流中的人员应选择他们认为最重要的改进来进行处理。

每次只允许一个改进的做法有助于集中精力。我们在第四章，利用 精益流动保持工作流动中看到，通过小批量工作避免了多任务处理可能带来的问题，从而防止了工作无法完成的情况。

一种可能的改进是通过提高流动性来减少开发产品的周期和交付时间。第四章中的实践——如小批量、监控队列和限制在制品——也能帮助实现这一目标。遵循这些实践可能会带来更高的敏捷性，随着 DevOps 方法的实施，这种敏捷性会不断提升。

价值流中的人员可以关注的另一个改进领域是工具的使用。需要考虑的第一个基础工具是版本控制。价值流中的团队应该评估是否将所有文件放入版本控制系统。如果他们已经在使用版本控制系统，他们应该确保使用的是统一的版本控制系统，并且每个人都拥有必要的访问权限。

除了选择版本控制系统外，价值流中的人员还应该选择一个分支模型，概述他们如何从主干分支并何时将变更合并回主分支或主干。

开始自动化

改善价值流的一个关键步骤是建立 CI/CD 管道。如果组织尚未建立 CI/CD 管道，可以建立一个，许多版本控制系统自带这样的管道。其他组织可能希望安装一个独立的 CI/CD 管道工具，以获得更多的灵活性。无论哪种方式都可以，因为最重要的是创建这样一个管道。

CI/CD 管道可以在版本控制中通过提交触发。当发生提交时，添加必要的后续操作，每次添加一个操作。这些操作可能从构建或编译提交中来的更改开始。完成的构建可以让合并进入更高级别的分支，并可能将构建产物保存到制品库中。

开始自动化测试

一旦定义了 CI/CD 管道的端点，你就可以用自动化测试填充管道中的其他中间步骤。你可以创建自动运行的测试，来发现功能和安全性方面的问题。

从创建以下类别的自动化测试开始，逐一进行：

• 单元测试

• 功能测试

• 系统测试

• 安全测试（静态应用安全测试（SAST）、动态应用安全测试（DAST）和其他扫描）

自动化测试的开发现在鼓励创建多个部署环境，例如测试环境、预发布环境和生产环境。单元测试通过后，可以为其他测试级别部署测试环境。

创建环境、部署和监控

测试的建立让我们能够建立不同的预生产环境，所有这些环境在实践允许的情况下都是等效的。

引入新的预生产环境还允许我们为这些预生产环境引入监控。监控可以先在测试环境上启动，直到我们对部署到预发布环境甚至最终生产环境的监控有足够的信心。

构建预生产环境让我们能够建立所需的工具进行构建。配置管理工具和基础设施即代码（IaC）可以被添加来定义和配置环境。建立标准配置允许像回滚这样的功能得以实现。

衡量、学习并调整方向

在每一步中，我们应该评估我们所增加的每个步骤是否有助于将我们带到理想的未来状态价值流。根据需要做出调整。这些微小的课程修正促使了 CL（持续学习）。

可能会有人质疑是否是时候进行调整。正当理由总是避免沉没成本谬误，在这种谬误中，人们会固守原有方案，尽管有压倒性的证据表明应该做出改变。

最后一点：有一个流传已久的故事称，约翰·F·肯尼迪曾指出，中文中的危机一词是由危险和机会这两个词组成的。虽然中文中危机一词的前半部分确实可以单独表示危险，但后半部分则单独翻译为变化的节点或转折点。

采用 SAFe 或采用 DevOps 很像观察组成危机的各个角色。观察危险和观察转折点能帮助我们远离危机。

在本书中，我们谈到了 DevOps 从 2009 年初期到今天的演变。现在，让我们来谈谈开始出现的趋势。

DevOps 中的新兴趋势

DevOps 运动成功的一个主题是组织内两个独立职能——开发和运维之间的协作，目的是频繁发布产品，同时保持生产环境的稳定。

随着运动的成长，它的成功鼓励了更多富有创意的协作努力，推动了除了增加部署频率和稳定性之外的其他方面的进展。我们将探讨的一些重新构想的努力包括以下内容：

• XOps

• 革命模型

• 平台工程

让我们开始探索 DevOps 的潜在未来。

XOps

DevOps 运动的成功鼓励了组织其他部分（除了开发和运维）加入，以便除了开发频率和稳定性外，还能提升其他方面的速度和质量。值得注意的运动包括以下几个：

• DevSecOps：在管道的各个阶段纳入安全性，以确保安全性不会被忽视。目前，许多人认为 DevSecOps 方法中执行的实践已经完全融入到 DevOps 运动中。

• BizDevOps：被誉为 DevOps 2.0，这一运动增加了商业团队、开发人员和运维人员之间的协作，目的是最大化商业收入。

此外，其他工程学科也通过采用 DevOps 中首次提出的相同实践获得了成功。这些面向相邻学科的 DevOps 基础运动包括DataOps和ModelOps。

让我们看看 DevOps 方法在这些工程学科中的运作方式。

DataOps

DataOps 是将敏捷开发原则、DevOps 实践和精益思维融入数据分析和数据分析领域的过程。

数据分析遵循类似于产品开发的流程。以下步骤是数据分析中典型流程的一部分：

1. 由指导分析的人或客户指定的数据需求

2. 数据收集

3. 使用统计软件或电子表格处理数据

4. 数据清理以去除重复或错误

5. 探索性数据分析（EDA）

6. 数据建模以发现关系

7. 通过使用数据产品应用程序创建输出

8. 报告

随着数据量的指数增长，新的方法被投入使用，以便快速获取洞察。以下使用的方法类似于 DevOps 在产品开发中看到的步骤：

• 建立一个数据管道，使得数据能够通过数据分析过程处理成报告和分析结果

• 通过统计过程 控制（SPC）验证数据流经数据管道的情况

• 在数据清理、数据分析和数据建模阶段，加入自动化测试以确保数据的正确性

• 测量数据流经数据管道的情况

• 将数据分离为开发、测试和生产环境，以确保数据管道自动化功能的正确运行

• 数据科学家、分析师、数据工程师、IT 和质量保证/治理之间的协作

基于大量数据轻松发现关系为企业提供了竞争优势。使用 DataOps 实践和原则，能够使从数据中创造洞察的人员实现更高的可靠和无误数据分析的部署率。

ModelOps

当前技术领域中最大的趋势之一是 AI。这一趋势促使机器学习（ML）和决策模型的建立，利用大量数据不断提升性能。这些 ML 模型的开发可以为任何想要了解更多客户信息及其产品如何提供帮助的组织带来竞争优势。

现在开发有效的模型经历一个类似于软件开发生命周期（SDLC）的开发周期。2018 年 12 月，IBM Research AI 的 Waldemar Hummer 和 Vinod Muthusamy 提出了 ModelOps 的初步概念，将 AI 工作流通过 DevOps 方法中的技术，使其变得更加可重用、平台无关且可组合。

模型生命周期涵盖了如何为企业创建、训练、部署、监控 AI 模型，并根据数据反馈对模型进行再训练。以下图表展示了模型生命周期的路径：

图 14.1 – ModelOps 生命周期（作者 Jforgo1 – 自创作品，CC BY-SA 4.0，https://commons.wikimedia.org/w/index.php?curid=99598780）

由于模型生命周期和 SDLC 之间的相似性，快速部署变更、监控其对环境的影响，并学习以改进的期望行为，使得使用 ModelOps 开发的 AI 模型可以与使用 DevOps 创建的 AI 应用对齐，并且两者都依赖于使用 DataOps 开发的数据分析。

革新模型

软件开发中的价值流概念以传统的 SDLC 过程为模型。这个过程源自瀑布开发模式，假设开发是按照从一个活动到下一个活动的逐步线性运动进行的。随着产品的复杂度增加，DevOps 扩展了责任范围，线性的一次性活动进程是否还合理呢？

亚马逊 Web 服务（AWS）社区参与主管 Emily Freeman，也是《DevOps for Dummies》的作者，提出了一种不同的开发流程视角。她并未采用直线式的方法，而是提出了一个模型，在该模型中，优先级随着活动的进行而向前和向后移动，沿着活动的圆圈变化。她将这个模型称为革新。让我们更深入地了解一下。

Freeman 提出了以下五个软件开发角色，作为同心圆向外辐射：

• 运营

• 部署

• 自动化

• 开发

• 架构设计

这些圆圈的交集是工程师在每个活动中必须考虑的六个特性。这些特性，如下所示，作为同心圆的辐条被绘制出来：

• 可测试性

• 安全性

• 可靠性

• 可观察性

• 灵活性

• 可扩展性

在各个部分就位后，让我们展示以下模型图：

图 14.2 – 革新模型

为确保这六个特性得到充分满足，工程师或团队成员会从外向内跳跃不同角色（或圆圈），逐一进行处理。角色是由工程师临时承担的，直到不再需要为止。在 Freeman 在主题演讲中所描述的一个事件管理场景中（www.youtube.com/watch?v=rNBXfgWcy5Q），团队成员需要在运营、开发和部署之间切换，以调查是否具备足够的可靠性、可观察性、灵活性、可扩展性和可测试性。

平台工程

近年来，云原生环境中涉及的大量工具和技术得到了快速发展。为了设置和维护产品所在的测试、预生产和生产环境所需的知识水平，已经让负责其运营的人力捉襟见肘。

从历史上看，DevOps 最初是将运营融入到敏捷开发过程中，以便在保持稳定性的同时，也能维持开发速度。随着时间的推移，运营部门已经开始采用敏捷开发思维，结合 SRE（站点可靠性工程）来解决大型系统的可靠性问题。Honeycomb.io 的首席技术官 Charity Majors（这家公司在开发监控和可观察性平台方面处于领先地位）在一篇博客文章中（www.honeycomb.io/blog/future-ops-platform-engineering）写道，下一步是将运营所负责的环境视为可以通过敏捷开发思维来开发的产品本身。

平台工程（由 Humanitec 的 Luca Galante 定义，参考 platformengineering.org/blog/what-is-platform-engineering）设计工具链和工作流，以使用这种敏捷开发思维模式提供自服务能力。通过平台工程开发的产品是 内部开发平台（IDP），它是开发者用于构建产品和解决方案的操作环境中所用技术的抽象。

开发者将使用以下五个组件的 IDP 来建立其产品或解决方案所需的能力：

• 应用配置管理 (ACM)：这包括自动创建清单文件，这些文件被配置管理工具用来部署应用程序更改。

• 基础设施编排：这建立了 CI 管道与部署环境之间的集成，包括可能的集群创建/更新、IAC 和镜像注册表。

• 环境管理：这将 IDP 的 ACM 与底层基础设施的环境集成，允许开发者根据需要创建完全配置好的环境。

• 部署管理：这设置了 CD 管道。

• 基于角色的访问控制（RBAC）：这允许对环境及其资源进行细粒度的访问控制。

我们已经看到随着人们开始应用变化于流程中，趋势开始显现，但 DevOps 将继续随着技术的进步而变化。让我们来看一下由技术进步驱动的 DevOps 趋势。

DevOps 中的新技术

如今的 DevOps 已经超出了 2009 年最初设想的范围，这在一定程度上是由于技术的进步，推动了云原生环境中的部署。今天的进步承诺将增添前所未有的新能力。

我们将要讨论的 DevOps 技术变化，源自于部署到云原生环境和新兴技术应用的改进。我们将着眼于这些基于技术的 DevOps 趋势：AIOps 和 GitOps。

让我们从展望未来的 AIOps 开始。

AIOps

我们在上一节讨论了利用 AI 创建能够从大量数据中学习的应用程序的兴起。一个可以从基于大量数据的深入洞察中受益的领域可能是采用 DevOps 方法的产品开发，该方法通过全栈遥测收集数据。这与我们之前讨论的 DataOps 或 ModelOps 不同，因为这次我们将机器学习和数据可视化应用到实际的开发过程当中。

IT 运维中的人工智能（或 AIOps）旨在增强我们之前在 CI、CD 和按需发布阶段所识别的传统实践，加入基于机器学习（ML）的工具，以处理来自我们全栈遥测的数据。AIOps 工具的引入可以帮助理解 IT 环境中的以下领域：

• 系统：测试、预发布和生产环境可能是云原生和本地资源的复杂组合。云资源可能来自一个或多个供应商。资源可能是物理计算服务器（“裸金属”）的组合，或者使用虚拟化形式，如虚拟机（VMs）或容器。如此多样化的资源组合确保了环境的稳定性和可靠性。

• 数据：全栈遥测产生大量数据。其中一些数据可能对做出关键决策至关重要，而一些则不然。我们如何判断数据量是否庞大？

• 工具：为了获取全栈遥测，可能会使用各种工具来收集数据并管理系统。这些工具可能无法互相协作，或者功能受限，从而形成数据孤岛。

为了应对这一挑战，采用机器学习的工具可能会采用以下类型的 AI 算法：

• 数据选择：分析数据以去除冗余和无关信息

• 模式发现：分析数据以确定关系

• 推理：查看见解以识别根本原因

• 协作：使自动化通知团队发现的问题

• 自动化：旨在自动响应重复出现的问题

这些工具在识别安全漏洞、查找生产故障的根本原因，甚至识别可能预测生产环境中即将发生的问题方面都有应用。随着技术的进步，AIOps 成为 DevOps 和 IT 运维的标准组成部分的前景也在不断增加。

GitOps

随着 CI/CD 管道的接受度逐渐提高，许多人开始思考如何建立这些管道，以便将功能部署到云原生的测试、预发布和生产环境中。2017 年，Weaveworks 提出了 GitOps 这一术语，建议一种基于 Git 提交触发的 CI/CD 方法，Git 是一种流行的版本控制程序。

GitOps 从版本控制开始。应用程序和环境配置各自有独立的代码库。应用程序代码库将包含产品的代码，包括如何在 Dockerfile 中构建该产品作为容器。环境代码库将包含 CI/CD 管道工具的配置文件和脚本，以及环境的部署记录。

GitOps 中的部署可以是推送式或拉取式。推送式部署使用常规的 CI/CD 流水线工具，从 CI 推向 CD。拉取式部署则使用操作员监控环境仓库的变化。当发生这些变化时，操作员根据环境仓库的变化将其部署到环境中。

下图展示了从 Git 仓库到 CI 流水线，再到操作员和部署流水线的进展：

图 14.3 – GitOps 拉取式部署

GitOps 在那些希望使用 Kubernetes 设置部署的群体中受到了极大的关注。Kubernetes 是一种打包 Docker 容器以设置微服务集群的技术。随着 Kubernetes 的流行，GitOps 已成为一种成熟的实践，用于将 Kubernetes 集群持续部署到基于云的环境中。

常见问题解答

现在我们来看一些可能会出现的问题，即使是在阅读了本书的早期部分之后。

什么是 DevOps？

DevOps 是一个用于开发和维护产品的技术运动。它结合了精益思维和敏捷开发原则与实践，扩展了关注点，不仅仅局限于开发，还包括新产品及其功能的部署、发布和维护。DevOps 推广使用自动化和工具来允许频繁测试功能和安全性，并允许一致的部署和发布。当产品进入发布阶段时，DevOps 模型呈现出由开发人员和运维人员执行的操作实践，这些实践可以在生产环境出现问题时快速恢复，体现了一种任务导向的生成性文化。

什么是规模化敏捷框架（Scaled Agile Framework®）？

规模化敏捷框架（SAFe）是一套由 Scaled Agile, Inc. 开发的价值观、原则和实践。SAFe 主要被中型和大型组织采纳，帮助其为“团队中的团队”和企业的投资组合引入精益和敏捷的工作方式。正如 Scaled Agile, Inc. 所定义的：

SAFe for Lean Enterprises 是全球领先的业务敏捷框架。SAFe 将精益、敏捷和 DevOps 的力量整合成一个全面的操作系统，帮助企业在数字时代通过更快、更可预测且更高质量地交付创新产品和服务而蓬勃发展。——© Scaled Agile, Inc.

我是否需要采纳 SAFe 才能转向 DevOps？

不。我们在谈论 DevOps 时会提到 SAFe，因为在 SAFe 中工作的一个关键视角是专注于为其“团队中的团队”创建和组织价值流，这些团队被称为敏捷发布火车（ART）。SAFe 还通过其 CD 流水线专注于流程和自动化。这两者与成功的 DevOps 方法一致。

采用 SAFe 最适合当你的价值流可以通过一个由 5 到 12 个常规大小团队组成的团队来完成，并且这个团队中的团队正在共同开发一个单一的产品或解决方案时。这被称为Essential SAFe配置。

DevOps 仅适用于那些为云环境开发的公司吗？

尽管 DevOps 在最近的许多技术进步中是为了帮助开发、测试、部署、发布和维护云环境上的产品而产生的，但作为一项技术运动，DevOps 对产品所基于的任何技术都是中立的。

DevOps 的原则和实践在那些开发和维护云环境、嵌入式硬件、主机和物理服务器环境产品的组织中取得了成功。诸如采纳精益思维、价值流管理和 SRE 等实践，并不依赖于最终产品所使用的技术。

做 ___________ 最好的工具是什么？

一个常见的问题是询问在执行特定功能（如 CI/CD、自动化测试、配置管理或安全测试）时，最受欢迎的工具是什么。我总是避免选择单一的工具，原因有很多。

主要原因是每个行业和组织都有所不同。一个适用于某个行业或组织的工具，可能在另一个行业或组织中并不适用。

另一个原因是技术不断发展，发布了可能现在被认为是“最佳”的新工具。

DevSecOps 如何融入 DevOps？

在本章前面，我们看到 DevSecOps 是 XOps 的首个模型之一，最终发生的事情是将安全思维和实践融入到 DevOps 的更广泛定义中。通过 DevSecOps，我们在传统 DevOps 中，除了开发速度和操作稳定性外，增加了安全作为重点。在本书中，我们列出了几个地方，在这些地方包括安全实践将我们从 DevOps 带向 DevSecOps。

在第六章《从生产故障中恢复》中，我们看到混沌工程可以用来模拟灾难，如安全漏洞，并评估应对这些安全故障的潜在反应。

在第十章《持续探索与发现新特性》中，我们发现安全性是在为产品创建新特性时的主要考虑因素之一。这一考虑通常由系统架构师处理，常常与组织的安全团队进行咨询。

我们在第十一章《解决方案开发的持续集成》和第十二章《持续部署到生产》中进一步扩展了安全性，在这两章中，我们探讨了在不同形式的安全测试中加入，以检测潜在的漏洞。在 CI 过程中，我们进行了威胁建模，以识别任何潜在的攻击向量。

最后，在 第十三章，《按需发布以实现价值》中，我们探讨了在生产环境中进行持续安全监控和持续安全实践，以保持警觉，并在漏洞被利用时修复环境。

摘要

在本章的最后，我们展望了未来。首先，我们看到了 DevOps 在产品开发方面的新兴趋势。结合 AI 和数据工程的新进展为正在开发的产品添加了新的组成部分。像 AI 模型和数据管道这样的工件的开发表明，在 DataOps 和 ModelOps 等新领域中，采用 DevOps 方法可以带来很大的好处。我们还审视了可能影响 DevOps 和价值流管理的软件开发与维护的新视角。

技术的变化也改变了 DevOps。我们考察了如何将 AIOps 产品纳入其中，这些产品包括 AI 用于分析在测试和维护中收集的数据，以发现漏洞和潜在的故障。我们探索了将版本控制与 CD 结合起来的 GitOps 运动。

然后，我们从 DevOps 的未来转向将 DevOps 融入到您组织的未来中。我们探讨了如何采用 DevOps 实践，包括绘制您的价值流并在开发过程的不同领域中逐步应用自动化。最后，我们回答了一些可能遇到的问题及其解答。

我们已经探讨了 DevOps 的不同方面，从了解人们的动机到理解正在进行的过程，并考察了可以帮助实现更高绩效水平的工具。SAFe 采纳了这三个方面，使得多个团队能够作为一个价值流共同工作，开发、部署和维护为客户创造价值的产品。我们希望这次探索能为您继续进行 DevOps 之旅提供指导。

进一步阅读

欲了解更多信息，请参考以下资源：

• 一篇关于 XOps 及其各种组成部分的博客文章：www.expressanalytics.com/blog/everything-you-need-to-know-about-xops/

• 关于 XOps 及其主要组成部分和受欢迎程度的描述：datakitchen.io/gartner-top-trends-in-data-and-analytics-for-2021-xops/

• 来自 Scaled Agile, Inc. 的指导文章，详细介绍了如何在您的价值流中使用 DataOps：www.scaledagileframework.com/an-agile-approach-to-big-data-in-safe/

• 来自 IBM Research AI 的 Waldemar Hummer 和 Vinod Muthusamy 撰写的初步白皮书，详细介绍了他们的 ModelOps 过程：s3.us.cloud-object-storage.appdomain.cloud/res-files/3842-plday18-hummer.pdf

• ModelOp.com 制作的 ModelOps 基础指南：www.modelop.com/wp-content/uploads/2020/05/ModelOps_Essential_Guide.pdf

• 来自 Scaled Agile, Inc.的指导文章，关于如何在价值流中使用 ModelOps：www.scaledagileframework.com/succeeding-with-ai-in-safe/

• Emily Freeman 的《革命模型》官方文档：github.com/revolution-model

• 主题演讲，Emily Freeman 讨论《革命模型》：www.youtube.com/watch?v=rNBXfgWcy5Q

• 来自 honeycomb.io 的 CTO Charity Majors 的博客文章，介绍了平台工程：www.honeycomb.io/blog/future-ops-platform-engineering

• 来自 Humanitec 的 Luca Galante 的文章，描述了平台工程：platformengineering.org/blog/what-is-platform-engineering

• IDP 及其组件的定义：internaldeveloperplatform.org

• 来自 Moogsoft 的博客文章，这是一家 DevOps 工具供应商，详细介绍了 AIOps 的应用：www.moogsoft.com/resources/aiops/guide/everything-aiops/

• GitOps 入门：www.gitops.tech

• 来自 Atlassian 的 Warren Marusiak 的博客文章，概述了采用 DevOps 的方法：community.atlassian.com/t5/DevOps-articles/How-to-do-DevOps/ba-p/2137695

• 来自 Scaled Agile, Inc.的文章，定义了 Scaled Agile 框架：www.scaledagileframework.com/safe-for-lean-enterprises/

评估答案

本节包含来自所有章节的问题答案。

第一章 – 介绍 SAFe®与 DevOps

1. C

2. C, D

3. B

4. B

5. C

第二章 – 共享责任文化

1. D

2. B

3. C

4. A, E

5. C

6. C

第三章 – 提高效率与质量的自动化

1. B, D

2. C

3. C

第四章 – 利用精益流动保持工作进展

1. A, D

2. B

3. A

4. C

5. B, E

6. B

7. C

第五章 – 测量过程与解决方案

1. C

2. A

3. B

4. B, D

5. A

第六章 – 从生产故障中恢复

1. B

2. C

3. C

4. A

5. C, D

6. B

第七章 – 绘制你的价值流

1. C

2. B

3. C

4. D

5. D

6. D

7. C

第八章 – 测量价值流表现

1. B

2. D

3. A

4. D, E

5. A

6. C

第九章 – 通过持续学习迈向未来

1. B

2. B, D

3. A

4. C

第十章 – 持续探索与发现新特性

1. C

2. B, C, E

3. B

4. D

5. A, C, E

第十一章 – 解决方案开发的持续集成

1. B, D

2. A

3. C

4. A

5. E

6. B, C

7. D

第十二章 – 持续部署到生产环境

1. B, C, E

2. B

3. A, D, E

4. B, D, E

5. E

6. B

7. C

8. B, C

第十三章 – 按需发布以实现价值

1. B, D, E

2. A, B, E

3. A

4. A, C

5. B, E