Salesforce DevOps 指南及相关方法介绍
原文：
annas-archive.org/md5/ec167da03c90d6a18edd50835461d337译者：飞龙
前言
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 版本，您无需额外支付费用。
在任何地方、任何设备上阅读。直接从您最喜欢的技术书籍中搜索、复制和粘贴代码到您的应用程序中。
福利不仅仅于此，您还可以获得独家折扣、新闻通讯以及每天送到您邮箱的精彩免费内容
按照以下简单步骤获取福利：
- 扫描二维码或访问下面的链接
packt.link/free-ebook/9781803231426
-
提交您的购买凭证
-
就是这样！我们将直接把您的免费 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 条原则详细阐述并提供了这些价值的背景，说明如下：
-
我们的最高优先级是通过早期和持续交付有价值的软件来满足客户。
-
欢迎变更需求，即使在开发后期。敏捷流程利用变化为客户创造竞争优势。
-
经常交付工作的软件，从几周到几个月，优先考虑较短的时间尺度。
-
商业人员和开发人员必须在整个项目过程中每天都共同工作。
-
围绕有动力的个体构建项目。为他们提供所需的环境和支持，并信任他们完成工作。
-
传递信息给开发团队及团队内信息传递的最有效方法是面对面的交流。
-
工作的软件是进展的主要衡量标准。
-
敏捷流程促进可持续发展。赞助人、开发人员和用户应该能够维持一个持续的节奏，无限期地进行下去。
-
持续关注技术卓越和良好设计能够增强敏捷性。
-
简单性——最大化未完成工作的艺术——至关重要。
-
最好的架构、需求和设计源自自组织的团队。
-
团队定期反思如何变得更加高效，然后调整和优化行为。
精益的加入
大约在同一时期，其他人也在寻找以更短的时间到市场（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 方法，首先探讨最关键的因素：文化。
问题
通过回答这些问题来测试你对本章概念的理解。
-
CALMR 中的 M 代表什么？
-
监控
-
多任务处理
-
衡量
-
使命
-
-
在持续交付流水线中，哪些是阶段？（选择两个）
-
持续改进
-
准时发布
-
持续探索
-
按需发布
-
持续交付
-
-
在 CALMR 中，哪种文化很重要？
-
独立
-
共享责任
-
官僚主义
-
开放
-
-
运维的传统关注点是什么？
-
收入
-
稳定性
-
速度
-
合规性
-
-
哪个术语描述了将信息安全实践融入持续交付（CD）？
-
安全运维
-
开发安全
-
DevSecOps
-
安全操作
-
深入阅读
欲了解更多信息，请参阅以下资源：
-
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 在他们的著作《精益思想》中提出了一个五步过程，涉及价值流。这个过程总结如下：
-
与客户合作，识别价值。
-
确定详细描述从请求到交付活动的价值流。
-
确保在创建的价值流上实现流动。
-
当正常流动发生时，确保客户能够通过价值流拉取所需的更改。
-
持续改进和优化价值流。
操作价值流和开发价值流
前一节介绍的经典价值流无疑为从初始概念到客户发布的开发过程提供了模型。在 SAFe 中，这样的价值流被定义为开发价值流。
SAFe 还关注客户如何使用组织的产品和服务来实现价值。从客户的角度来看，这一视角被定义为运营价值流。运营价值流涉及的产品和服务是由开发价值流来开发和维护的。
让我们看看运营价值流和开发价值流是如何协同工作，以通过一个包含虚构媒体流服务的例子，为客户创造价值的。
新的客户希望在流媒体服务上查看节目。他们将通过网站门户（由门户 ART 开发）设置帐户，包括必要的账单。可能还希望通过移动界面（由移动 ART 开发）在智能电视上设置流媒体服务。最后，他们可能希望观看流媒体服务独有的原创节目（由内容 ART 开发）。
这个客户场景展示了作为一个运营价值流与交叉的开发价值流的方式：
图 2.6 – 具有开发价值流的组织价值流
价值流代表了一种关键的精益实践。采用价值流并围绕价值流组织工作，使 ART 能够培养出肯定精益敏捷心态、核心价值和 SAFe 原则的行为。随着这些行为的稳定，文化向生成性文化转变，使每个人都与使命保持一致。
摘要
在本章中，我们通过研究文化、自动化、精益流、衡量和恢复（CALMR）方法中的第一个也是最重要的因素：文化，开始了我们的探讨。我们研究了 Ron Westrum 的工作，该工作讨论了三种类型的组织文化：病态、官僚和生成性。通过分析每种文化的特点，我们发现真正赋能我们团队的是生成性文化。
一旦我们确定了理想的组织文化，我们就开始研究如何向这一理想文化过渡。为了帮助这一过程，我们研究了约翰·科特尔（John Kotter）提出的变革模型的八个步骤。我们还通过福特汽车公司在艾伦·穆拉利（Alan Mulally）领导下的例子，看到这些步骤是如何实际运作的。
我们识别出了推动我们在生成性文化中展现的行为的心态。这一心态的来源既来自精益思维和敏捷宣言的知识体系，也来自 SAFe 的核心价值观。我们还识别了敏捷宣言中的一些原则，这些原则在与一个由多个团队组成的规模化环境合作时可能需要特别关注。
另外，推动我们行为并提供额外视角的是 SAFe 的 10 个原则。我们看到这些原则如何在核心价值观、心态和实践之间起到指导作用。
最后，由于文化既建立在结构又建立在行为的基础上，我们深入探讨了创建生成性文化的理想结构。我们还看到了价值流如何从精益起步，SAFe 如何将经典的价值流定义发展为操作和开发价值流。
在本章中，我们了解了文化的重要性以及如何通过行为改变来实现这种文化。技术可以帮助推动这种向生成性文化的转变。在下一章中，我们将探讨形成 CALMR 自动化方面的技术，它促进了这种转变。
问题
通过回答以下问题来测试你对本章概念的理解。
-
在生成性文化中，信息传递者是：
-
归咎。
-
经过培训的。
-
被忽视。
-
被庆祝。
-
-
在 SAFe 精益之屋中，作为屋顶的是？
-
时间
-
价值
-
领导力
-
创新
-
-
对于 ART 中的团队来说，要实现对齐，他们需要同时练习节奏和 _______。
-
流动
-
文化
-
协同
-
独立性
-
-
识别两个 SAFe 核心价值观。
-
内建质量
-
适应
-
授权
-
流动
-
透明性
-
-
价值流识别 _________、参与者及从最初想法到向客户交付有价值事物所需的时间。
-
工具
-
文化
-
步骤
-
产品
-
-
在科特变革模型中，生成 短期胜利 后会发生什么？
-
庆祝并认可胜利
-
授权他人实施愿景
-
巩固胜利以推动更多变革
-
将胜利与愿景联系起来
-
进一步阅读
如需更多信息，请参考以下资源：
-
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 团队能够更快地交付，但如果开发过程未优化以实现精益流程，则无济于事。在下一章中，我们将探讨来自精益思维运动的实践，以促进流程。
问题
通过回答这些问题来测试您对本章概念的理解。
-
什么测试是静态分析的示例（选择两个）？
-
单元测试
-
Linting
-
DAST
-
依赖扫描
-
验收测试
-
-
什么允许代码更改在生产环境中隐藏，直到启用？
-
版本控制
-
持续集成
-
特性标志
-
持续部署
-
-
监控包括性能监控、警报等活动，以及什么？
-
负载测试
-
版本控制
-
日志收集
-
单元测试
-
进一步阅读
- 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 – 小法则的示意图
金曼公式
金曼公式是一个数学模型，用于描述等待时间如何与周期时间、可变性和利用率相关联。公式如下所示：
公式中的每一项代表一个独立的量。第一项 https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/safe-dop-prac/img/Formula_04_003_-Part_11.png 代表执行工作的人员的利用率。第二项 (https://github.com/OpenDocCN/freelearn-devops-pt3-zh/raw/master/docs/safe-dop-prac/img/Formula_04_003_-Part_2.png) 代表系统的可变性。第三项 (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 模型的下一个元素。
问题
通过回答这些问题来测试你对本章概念的理解。
-
以下哪些是 SAFe 中的启用因素？（选择两个）
-
探索
-
测量
-
可视化
-
合规性
-
实际
-
-
Kanban 板的哪个功能可以用来可视化紧急工作的情况？
-
WIP 限制
-
快速通道
-
列策略
-
扩展的工作流列
-
-
过多的 WIP 会导致什么后果？
-
过多的多任务处理
-
减少的周期时间
-
新的工作在旧的工作完成后开始
-
短队列
-
-
大批量大小会导致什么结果？
-
低 WIP
-
降低风险
-
高周期时间
-
高性能
-
-
根据 Reinertsen 的说法，长队列会导致哪些问题？（选择两个）
-
更短的周期时间
-
更高的开销
-
较小的风险
-
更高的质量
-
更多的变异性
-
-
哪种方法是管理变异性的方法？
-
更大的批量大小
-
建立缓冲区
-
“一次性”流程
-
增加在制品（WIP）
-
-
根据 Mik Kersten 的说法，哪些因素在基于产品的开发中存在？
-
将人力移至工作地点
-
一开始识别所有风险
-
专注于业务成果
-
项目规划
-
进一步阅读
这里有一些资源供你进一步探索这一主题：
-
《让工作可视化：揭示时间盗窃以优化工作和流动》（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），请执行以下操作：
-
从对应于待办事项或待做（To Do）列的带状区域与第一个进行中（In Progress）列的带状区域之间的边界开始。在我们的示例中，这是待做（To Do）带和进行中（In Progress）带之间的边界。我们只关注已经开始的工作，因此，这些工作已经超过了待做（To Do）状态。
-
标注下这是多少工作单位。
-
画一条垂直线穿过其他带状区域，直到你到达表示进行中（In Progress）列和表示完成（Done）列之间的边界。在我们的示例中，我们通过了进行中（In Progress）带和审查中（IN REVIEW）带。标注下这是多少工作单位。
-
将第二个数字从第一个数字中减去。
下图展示了所描述方法的示意。
图 5.5 – 在制品（WIP）计算
请注意，您可以使用相同的方法在较小的范围内，通过观察形成目标列带状区域的两条线，来找到某一时刻进行中（In Progress）列中问题的数量。
使用累计流图衡量周期时间
要衡量周期时间，请执行以下操作：
-
找到并标记当一个问题从表示待做（To Do）或待办事项（Backlog）列的带状区域移动时，并标记其日期。
-
画一条水平线，直到它触及表示完成（Done）列的带状区域。标注第二个日期。
-
将第二个日期减去第一个日期，你将得到一个问题的周期时间度量。
图 5.6 – 周期时间计算
步骤在上面的图示中有说明。
使用累计流图衡量吞吐量
累计流图中的吞吐量通过找出一条线并确定其斜率来完成：
-
标记线上的一个点，并标注日期和问题的数量。
-
在线上较高的位置，标注日期和问题的数量。
-
分子将是第二个点的问题数量减去第一个点的问题数量。
-
分母将是两个时间点之间的时间段。
以下是该计算的示例。
图 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 将假设和学习的方法描述为创新会计框架。在这个框架中，团队会设定客户需求的假设，发展这些假设，然后进行衡量并决定后续行动。这是在三个阶段的循环中完成的，具体包括：
-
查看当前情况，并通过最小可行产品（MVP）或开发足够的产品或功能来向客户展示并获得反馈，以验证假设。
-
根据指标，针对 MVP 进行小范围调整。
-
如果指标表明成功，继续优化 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 的检查。我们将探讨价值流如何使用方法来减少生产中失败的风险，并且如果发生问题，如何快速解决生产中的问题。
问题
通过回答这些问题来测试你对本章概念的理解。
-
交付时间衡量等待时间和 ______________？
-
产出
-
阻碍因素
-
周期时间
-
进行中
-
-
在衡量吞吐量和周期时间时，如果周期时间减少，吞吐量会发生什么变化？
-
吞吐量上升
-
吞吐量下降
-
吞吐量保持不变
-
吞吐量先上升，再下降
-
-
WIP 在累积流图中是如何表现的？
-
水平线
-
垂直线
-
上升坡度
-
下降坡度
-
-
基础设施监控需要哪些度量（选择 2 个）？
-
垃圾回收率
-
CPU 利用率
-
响应率
-
存储可用性
-
网络可用性
-
-
在适用框架中，客户看重哪种类型的度量？
-
适用标准
-
一般健康指标
-
改进驱动因素
-
虚荣指标
-
进一步阅读
-
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 编著 - 适用度度量的探讨。
扫一扫
935
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
