原文：
annas-archive.org/md5/ba124a17e6265749b6cd2d08ea640996译者：飞龙
第七章：重要的衡量指标
在前几章中，我们探讨了你应该考虑哪些工具和技术，如何认识到变革会以不同的方式影响人们，为什么文化、行为和环境如此重要，哪些潜在障碍需要克服，以及这些内容如何帮助你成功地采纳 CD 和 DevOps。如果你已经考虑到这些，并为此制定了计划来应对和/或解决这些问题，那么你应该已经为迈出更大步伐做好了准备。
我们现在要关注的是一个重要但有时被忽视——或干脆被忽略——的领域：监控和衡量进展。我们之前曾涉及过这个话题，但当时我们只是看到了其中一小部分。现在我们要探讨的是与持续交付（CD）和开发运维（DevOps）对日常工作方式和整个业务的影响相关的指标的收集、汇总和共享。
从表面上看，这可能被认为只对管理层有用，对那些每天处理 CD 和 DevOps 采纳的人没有价值。从某种程度上来说，这是对的，但能够分析、理解和分享可证明的进展，肯定会为你和所有在 CD 和 DevOps 旅程中的人带来价值。我们这里说的不是简单的项目管理图表、图形和 PowerPoint 材料；我们要看的是真正衡量整个流程尽可能多的方面。这样，每个人都能清晰地看到并理解你们集体已经取得的进展，并且了解距离最终目标还有多远。
为了有效地进行这项工作，你需要确保在 CD 和 DevOps 采纳的初期就开始收集这些数据，因为如果没有代表当时的数据，你将很难进行现在与当时的对比。你需要保持警惕和一致性，确保持续收集这些衡量指标，这样你才能在不同时间点比较进展的状态。有些人可能认为这是过于苛刻，但整个 CD 和 DevOps 的旅程正是因为在象限曝光中捕捉到的数据指向了浪费的领域——或者至少是低效的流程——而开始的。
在本章中，你将学习以下内容：
-
如何衡量你的工程流程的有效性
-
如何衡量你使用和依赖的各种环境的稳定性
-
如何衡量你采纳 CD 和 DevOps 所带来的影响
我们从头开始，首先关注工程度量。
衡量有效的工程最佳实践
这是一个相当难以理解的概念：如何衡量有效的工程实践，甚至更进一步，如何衡量最佳实践？还有一个常被提问的问题是：这和 DevOps 或 CD 有什么关系？我们稍后会讨论前者，但现在我们先专注于后者。
我们来看两个场景：
-
你当前的软件工程过程非常瀑布式，并且你有大量的手动测试来验证代码，直到代码准备发布——这一过程通常在 3 到 6 个月之间——并且会预留时间来修复 BUG。
-
你当前的软件工程过程相当灵活，并且大体遵循行业最佳实践。然而，由于发布之间有相当长的时间间隔，你有时可能会忽视技术债务（包括自动化测试），因为你可以在下一次发布前有时间回头去修复——而下一次发布通常是在 3 到 6 个月后。
好的，虽然这个很简化，但请耐心听我说。随着持续交付（CD）和开发运维（DevOps）的推广，发布间隔时间将会缩短。因此，我们可以稍后做的窗口也会越来越小。这可能会导致工程师们为了赶时间而不得不开始“偷工减料”，因为他们已经没有时间去清理发布前的技术债务任务。CD 和 DevOps 的采用最终能够让你快速交付解决方案——并没有什么明确的规定表示工程师会有更多时间来编写和测试这些解决方案。
让我们来看看一个大型季度发布的时间线和工作量，如下所示：
现在，让我们与 CD 类型的发布进行比较，如下所示：
这些都是非常简化的例子，但它们突出了减少发布间隔时间对关键角色产生的影响。我们可以稍后做的窗口从几天/几周缩短到几小时。
在第五章*，* 方法、工具和技术中，我们探讨了更广泛的业务如何看待功能和发布之间的关系。随着你的 CD 和 DevOps 采用的成熟，发布间隔时间将缩短，这意味着工程师将有更少的时间来完成功能。如果更广泛的业务已经习惯了在给定的发布中交付功能，他们会继续期待这一点，直到新方式稳定下来。
让我们回到“偷工减料”的话题。这些通常与非修改代码相关，但仍是耗时的活动——例如跳过某些单元测试、在集成测试中留下一些空白、不做文档、减少重构旧代码的倾向等等。简单来说，工程师们会面临交付压力，他们将不再有时间处理之前完成的所有任务。这因此变成了技术债务——这是每个软件工程团队都尽力避免的，因为它最终会在未来反噬他们。
回到衡量有效工程最佳实践的主题，这其实并不像你想象的那样陌生或罕见。全球有大量的软件公司定期使用工具来捕捉数据和测量一些内容，例如：
-
整体代码质量
-
遵循编码规则和标准
-
代码文档
-
代码复杂度
-
代码重复
-
冗余代码
-
单元测试覆盖率
-
技术债务
-
平均故障间隔时间
-
平均解决时间
-
缺陷逃逸距离
-
修复反弹率
单独衡量这些指标可能不会带来太多价值；然而，当它们汇总在一起时，你可以获得一个非常详细的整体情况。此外，如果你能够在一段时间内持续捕获这些详细信息，你就可以开始衡量和报告进展。这对持续交付（CD）和 DevOps 的采用至关重要，原因很简单：如果由于软件发布速度加快而导致质量下降，落后的人员将有机会借此反击。如果这些落后人员处于有影响力和/或决策岗位，整个采用过程可能会被拖延。
如前所述，如果你能在问题开始发生时就发现它，你就有机会去制止它。还有另一面：如果你当前的质量很差，而你能证明持续交付（CD）和 DevOps 的采用有助于提高质量，那么这就是一个巨大的好消息——我们可以更快发布，而质量大幅提高。给那些落后者看看！
听起来很简单，实际上，确实可以做到，但你需要注意，你需要投入一些时间、精力和严格性，确保能够获得最大的价值。过程中也会有一定的试错和调整，以确保能够以可靠和可重复的方式捕获数据——更多的检查和适应——因此你需要确保考虑到这一点。这些衡量标准不仅会帮助你的工程团队，也会有助于在更广泛的业务中建立信任。例如，你将能够提供开放、诚实、真实的软件质量指标，这反过来会增强他们对开发和维护平台的团队的信任。
在你开始衡量诸如软件代码指标等事物之前，有一点需要认真考虑：工程师自己对此的感受。Devina 的想法可能是典型反应之一：
对这种方法的典型反应
一些工程师可能会变得防备或防守，认为这在质疑他们在创建高质量代码方面的技能和工艺。你需要小心，避免在你与工程团队之间建立障碍，也要避免让他们回到落后者阵营。你应该将这些工具作为工程师的积极利益来推销。例如，他们可以明确证明自己的代码有多好；他们可以利用这些工具检查过于复杂的区域或可能包含漏洞的代码区域；他们可以突出冗余代码并从代码库中移除；他们还可以直观地看到硬依赖关系，这在进行组件化时有很大帮助。
如果你有一些发声的拖后腿者，让他们积极参与工具的设置和配置（例如，他们可以负责定义可接受的代码覆盖率的门槛，或者选择要实施的工具）。
如果没有别的，你需要确保工程社区中的创新者和追随者都能参与其中。为了更清晰地说明这一点，我们来看一下前面列表中的几个项目——顺便说一下，这个列表并不完整——并更详细地探讨它们为什么对你的持续交付（CD）和开发运维（DevOps）采用可能至关重要。我们从代码复杂度开始。
代码复杂度
拥有复杂代码有时是必要的，特别是在面对极其优化的代码时，尤其是在资源有限和/或需要实时 UI 的情况下——基本上是每毫秒都很重要的场景。当你拥有像在线商店、登录页面或财务模块这样的功能时，过于复杂的代码反而可能弊大于利。一些工程师认为他们很特别，因为他们能写复杂的代码；然而，单纯为了复杂而复杂其实就是在炫耀。
过于复杂的代码可能会导致许多普遍性的问题——特别是在调试时，或者在你试图扩展代码以满足更多使用案例时——这直接影响到你实施哪怕是最小改动的速度。持续交付的前提是交付小而渐进的高质量改动。如果你的代码过于复杂，以至于无法实现这一点，那么你将在未来遇到问题——通常这被称为代码的可维护性、可测试性和可读性。
我建议你在开始实施任何过程或工具之前，先花些时间更深入地研究这个复杂的（带有双关意味）主题。你真的需要理解其背后的基本原则和科学原理；否则，这将变得混乱不堪。某些科学原理在附录 A，一些有用的信息中做了详细解释。
一个建议是，选择一些现有的代码分析工具，进行试用，分析你的代码库，帮助你找出一些现有的痛点。通过这些，你可以开始制定一个计划。
你接下来可以考虑的一个方面是代码覆盖率。
单元测试覆盖率
在软件开发过程中引入单元测试被广泛认为是最佳实践——第六章，避免障碍。这个主题有大量的信息可供参考，因此我不会在这里花太多时间讨论，但我建议你投入一些时间和精力，研究一下这个主题以及如何在你的软件开发生命周期（SDLC）中采用这种方法。
为了不让你觉得我在敷衍你，我将提供一些关于这个主题的见解和背景，特别是与 CD 和 DevOps 相关的部分。
从简单的角度看，单元测试允许软件工程团队在开发过程中对代码路径和逻辑进行粒度化的验证，这反过来可以帮助尽早发现并消除软件缺陷。将这些测试纳入持续集成（见第六章，避免障碍，了解持续集成的相关信息）并让它们在构建过程中阻止错误，可以帮助防止缺陷进入持续交付管道的下游阶段。这也可以作为回归的早期警告；例如，如果一个先前正常的单元测试开始失败，很可能是引入了回归问题。
持续交付的前提是能够频繁发布变更。如果你的代码库中有良好的单元测试覆盖率，你将对频繁发布该代码并降低风险充满信心。
分析覆盖率是一个很好的指标，能够表明你在多大程度上可以依赖单元测试来发现问题。你还可以利用这些数据绘制出在快速发布代码时的风险领域（例如，如果你的登录页面经常被修改并且覆盖率较高，那么频繁发布该页面的风险会较低）。
有一件事是你需要考虑的，关于覆盖率的衡量——即旧代码与新代码的混合。你通常会发现，旧代码，尤其是基于旧技术的代码，可能几乎没有单元测试覆盖。如果这类代码占据了你代码库的大部分，覆盖率的衡量结果会非常低。如果更广泛的业务团队过于关注这一指标，他们可能会将低分数视为一个重大风险。虽然从技术角度讲这是正确的，但你不能指望从第一天开始就对旧代码进行全面覆盖。因此，你需要确保为数据设定一个上下文，并制定一个随着时间推移提高覆盖率的计划。一种方法是设定一个规则，要求所有新代码或重构代码应该有较高的覆盖率（理想情况下是 100%，前提是在不进入收益递减领域的情况下可以实现），并且随着旧代码重构的增加，总体覆盖率应当增长。
现在让我们来看一下提交频率的衡量效果。
提交和合并率
定期提交源代码到版本控制系统是应该广泛鼓励并深度嵌入工作方式的一部分。将源代码长时间存放在个人的工作站或笔记本电脑上是非常危险的，有时会导致重复劳动，甚至更糟的情况是，可能会阻碍其他工程师的进展。
可能有人担心，如果工程师提交代码太频繁，创建缺陷的机会会增加，特别是当你认为未完成的代码可能会被合并到主代码分支时。这种担心是个谬论。没有任何一位称职的工程师会认真考虑做这种事——为什么要这么做？如果你有像定期代码审查或拉取请求审批流程这样的检查和制衡，合并有缺陷的代码的风险将大大减少。再加上单元测试和代码分析，你几乎可以消除风险。
与此相反的是，提交和代码合并之间存在非常真实的延迟风险。需要合并的代码越多，风险就越大，引入代码冲突、缺陷和不完整功能的潜力也就越高。持续交付（CD）方法的核心是经常交付可工作的软件。这不仅限于软件二进制文件；经常交付小的增量源代码也是一种良好的实践。
大多数源代码控制系统会提供可以通过第三方工具分析的工具和日志。你需要分析的数据包括每天每位工程师的提交和合并次数、合并之间的时间间隔，以及代码库中哪些区域被更改的最频繁。
从这些数据中，你可以开始看到一些模式，例如谁在积极合作，谁没有，以及代码库中哪些区域承载着最大的风险。提醒一下：不要使用这些数据来奖励或惩罚工程师，因为这可能会促使错误的行为，甚至可能像忽视工程最佳实践一样具有破坏性。
接下来，我们将讨论代码违规和遵循规则的棘手问题。
遵循编码规则和标准
你可能已经在软件开发团队中制定了编码标准和/或试图遵循外部文档化和公认的最佳实践。能够分析你的代码库，查看哪些部分符合标准，哪些不符合，是非常有用的，因为它有助于突出潜在的风险区域。如果你随着时间的推移持续捕获这些数据，你将能开始发现趋势——尤其是当这些数字开始下降时。
有很多工具可以帮助你做到这一点，其中一些列在附录 A 中，一些有用的信息。
这种类型的分析需要一些设置，因为它通常基于一组预定义的规则和阈值（例如，信息、次要、主要、关键和阻塞），你需要与工程团队合作，商定并在工具中设置这些内容。
衡量遵循编码规则和标准有助于防止代码中的缺陷泄露，但软件就是软件，缺陷总会悄悄出现。因此，你需要做的是分析缺陷出现后的情况。
质量指标
质量是所有参与编写和交付软件的人应该希望维护并融入其解决方案的东西。前面的部分包含了一些质量度量的元素，但你还应该考虑一些专门针对时间的具体度量。
与 CD 和 DevOps 相关的关键指标是平均故障间隔时间（MTBF）、平均修复时间（MTTR）和缺陷逃逸距离，具体解释如下：
-
MTBF：这将帮助你衡量最终用户发现问题（或故障）的频率——故障之间的时间越长，整体平台的稳定性和质量越高。
-
MTTR：这将帮助你衡量从发现问题到修复问题所花费的时间
-
缺陷逃逸距离：这将帮助你衡量问题发现的时间和发现者——例如，工程团队发现的缺陷离缺陷源较近（例如，团队中的某个成员），而 UAT 发现的缺陷则离源头更远。
前两者为 CD 和 DevOps 的采用情况提供了一些良好的指示，尤其是它们与交付速度的关系。例如，预计如果 CD 和 DevOps 的采用运作良好，MTBF 会逐渐增加，而 MTTR 则会逐渐减少。如果没有发生这种变化，那就意味着存在某些问题需要调查。
三者中的第三个——缺陷逃逸距离——是工程最佳实践和持续集成（CD）管道是否能够及早发现问题的良好指示。如果工程团队在流程早期就能发现缺陷——例如，由于单元测试失败，CI 步骤失败——那么距离和影响就很小。如果缺陷逃逸到下游流程——例如，用户验收测试（UAT）团队——那么距离和影响就会更大。如果缺陷最终进入生产环境，那么……我想你应该明白了。
一种表示方法是根据缺陷所在的环境以及发现它所需的时间，为每个缺陷添加一个美元价值。例如，假设我们有四个环境，作为 CD 管道的一部分：开发、QA、UAT 和生产。然后根据每个环境距离源头的远近，应用一个滑动成本比例：
| 环境 | 成本 |
|---|---|
| 开发 | 1 |
| QA | 2 |
| UAT | 8 |
| 生产 | 16 |
现在，让我们考虑每个缺陷的成本，使用一个乘数，基于缺陷创建和发现之间的交付时间。你将得到如下结果：
| 缺陷# | 环境 | 环境成本 | 交付时间（天） | 缺陷成本 |
|---|---|---|---|---|
| DE1 | 开发 | 1 | 2 | 2 |
| DE2 | 开发 | 1 | 5 | 5 |
| DE3 | QA | 2 | 10 | 20 |
| DE4 | 开发 | 1 | 0.5 | 0.5 |
| DE5 | 生产 | 16 | 20 | 320 |
| DE6 | 生产 | 16 | 50 | 800 |
| DE7 | UAT | 8 | 5 | 40 |
| DE8 | QA | 2 | 7 | 14 |
| DE9 | 开发 | 1 | 15 | 15 |
| DE10 | UAT | 8 | 12 | 96 |
这是一个时间快照，给你一个关于缺陷成本的指示。这并不意味着你应该完全消除缺陷——做到这一点的唯一方法是停止编写软件——但你应该专注于消除高成本的缺陷。毕竟，客户在实际环境中发现的缺陷成本远高于在 SDLC 阶段发现的缺陷成本。
现在我们来看看交付时间（和循环时间）的含义。
循环时间和交付时间
这些是更基于时间的指标，对于衡量你在 CD 和 DevOps 采纳过程中的变化进展和效果非常有用。这两个指标相对简单易懂：
-
交付时间：从需求被识别到交付给客户之间的时间测量
-
循环时间：从某人开始处理某个工作项/故事/缺陷到交付给客户之间的时间
以下图表应该能让你更清楚地了解这是什么意思：
你们中的敏锐观察者可能会注意到，对于缺陷来说，交付时间与 MTTR 几乎是相同的，这意味着一个简单的数据点可以用于两个度量标准。以一换二，物有所值。
定期拍摄交付时间和循环时间的快照，可以很好地指示事情是否在顺利进行（或者，情况可能并非如此）。需要注意的是，交付时间可能会受到业务优先级和时间承诺变化的影响——例如，当更紧急的任务进入待办事项列表时，某个功能可能会被降级优先级——因此，数值可能会随着时间的推移而波动。你应该争取的是交付时间的总体减少。另一方面，循环时间更多地受工程团队控制，因此减少循环时间掌握在他们手中。随着 CD 和 DevOps 采纳的推进，交付过程应该变得更加简单，因此平均循环时间应该减少。如果没有减少，你应该检查是什么原因导致了瓶颈。有些原因可能与质量问题相关。
质量门控
捕获数据不仅有助于随着时间的推移建立一个清晰的全貌并发现趋势，还可以帮助你防止质量问题的泄露。我的意思是，一旦你收集并分析了关于代码覆盖率、编码标准遵循情况、代码复杂度或代码文档化水平等方面的数据，你可以在 CD 流水线中设置一些阈值，如果超过这些阈值，流水线会立刻停止。你还可以根据自动化测试的结果实施质量门控——同样地，如果测试失败，CD 流水线也会停止。
例如，假设你已经决定，任何新的软件都必须拥有 100%的单元测试代码覆盖率，并且不能包含任何已记录的安全漏洞；那么，你可以在 CD 流水线中实现一个代码分析/代码检查工具，用于检查每次提交或合并。如果工具报告所检查的代码未通过检查，CD 流水线将停止并通知团队。
在提到 CD 流水线时，我会将 CI 解决方案作为整个流水线的一部分——以防你认为它们是分开的。
实施这些工具不仅能确保你的代码达标，还可以帮助减少诸如缺陷外泄等问题，确保代码通过 CD 流水线时的最小干扰。捕捉这些数据还会为你提供一些历史洞察，关于质量门是否通过/失败的时间点，这可能与其他事件相关——例如，在一个重大发布前的紧张时期，失败可能会增加。
你们中的一些人可能会认为这一切听起来像是额外的繁重工作——在所有其他繁重工作的基础上——那么，真的值得吗？是的，值得！
从哪里开始，为什么要费心？
如前所述，有许多事情你可以并且应该衡量、分析，并为此生成指标，同时也有许多工具可以帮助你做到这一点。你只需要弄清楚最重要的是什么，然后从那里开始。设置所需工具所需的工作和努力，应该被视为一个很好的机会，可以带入你想要嵌入的良好行为：协作、公开和诚实的对话、信任。
我建议在 CD 和 DevOps 的采用过程中尽早实施这些工具，这样你可以从一开始就开始跟踪进展。无需多说，刚开始时它不会是一个漂亮的景象，而且毫无疑问，当这些工作没有直接推动采用时，围绕其有效性的疑问会不断出现——事实上，尤其是在早期，情况可能会非常糟糕。
这可能不会直接影响采用情况，但它提供了一些值得的补充，下面将对此进行解释：
-
拥有额外的数据来证明软件质量，将反过来建立信任，使得代码能够快速、安全地交付。
-
很有可能，对整体代码库有一个非常简洁的视角将有助于对平台进行重新设计以实现组件化。
-
如果工程师对代码库有更多的信心，他们就可以专注于新功能的开发，而无需担心每次更改时都可能引发一系列问题。
现在我们将焦点从衡量软件创建的过程转向衡量软件构建后的重要性。
衡量现实世界
分析和衡量你的代码和工程技术是其中的一部分；然而，为了让 CD 和 DevOps 真正有效，你还需要密切关注整体环境、平台、运行中的软件以及 CD 和 DevOps 的效果进展。让我们从环境开始。
衡量环境的稳定性
在产品交付过程中，你可能会有多个不同的环境用于不同的目的：开发环境、CI、QA、UAT、性能/负载测试等。随着发布周期的加快，你对这些不同环境的依赖将会增加——如果你的发布周期是 2 到 3 个月，那么某个环境中出现半天左右的问题对你的发布影响不大；而如果你每天发布 10 次，那么半天的停机时间就会造成重大影响。
在 IT 行业中，似乎有一种普遍的词汇与此相关，“环境问题”这个术语一次又一次地出现，正如我们在这里看到的：
普遍的环境问题讨论
我们都听过这些话，有些人也可能自己说过这些话。总的来说，这些说法远非有帮助，反而可能在长远来看适得其反，尤其是在建立 Dev 和 Ops 之间良好工作关系的情况下，因为这些说法暗示基础设施（由运营方负责）有问题，尽管没有确凿的证据。
为了克服这种态度并培养一些良好的行为，我们需要做两件事中的一件：
-
毋庸置疑地证明软件平台按预期工作，因此，任何遇到的问题必须是由基础设施中的问题引起的
-
毋庸置疑地证明基础设施按预期工作，因此，任何遇到的问题必须是由软件中的问题引起的
当我说“相当简单”时，其实我意思并不完全是“非常简单”。让我们来看一下我们有哪些选择。
融入自动化测试
我们已经探讨了使用自动化测试来帮助证明每个软件组件在发布时的质量的优点，但如果你将这些测试集中起来，并在给定的环境中持续运行它们呢？通过这种方式，你将不断地对平台的大部分内容进行重复测试——实际上是持续进行的。
如果你捕捉到这些测试的结果，你可以快速而轻松地看到环境的健康状况，或者更准确地说，你可以看到软件是否按预期运行。如果测试开始失败，我们可以查看自上次成功运行以来发生了什么变化，并尝试确定根本原因。
当然，关于这一点有很多注意事项：
-
你需要有充分的测试覆盖，以建立高度的信心
-
你可能会有不同的测试，这些测试以不同的方式编写，使用不同的技术，而这些技术之间并不兼容。
-
一些测试可能会互相冲突，特别是当它们依赖于某些预定的测试数据集时。
-
测试本身可能并非万无一失，尤其是在包含模拟或桩的情况下，它们可能无法显示问题。
-
你的部分测试可能会出现波动，也就是说，它们不稳定，因某些原因偶尔会失败。
-
如果你是顺序执行这些测试的话，可能需要很多小时才能完成所有测试的端到端执行。
假设你愿意接受这些警告，或者你有足够的资源来加强测试，以便它们能够作为一个整体持续、一致地运行，你将得到一个能够提供更高信心的软件平台解决方案。
我建议你集中注意力于频繁波动的测试和/或执行后结果不一致的测试，因为这些会影响信任度。一个经验法则是，如果你无法信任某个测试，要么重构它，要么将其从测试套件中移除。
如果你拓展这种思维，你还可以使用相同的方法来增强对环境的信心。例如，如果你多次在相同环境中运行相同的测试套件，而在软件、配置或环境方面没有任何变化，那么每次都应该得到相同的结果。因此，你应该能够相对轻松地发现给定环境中的不稳定性问题——某种程度上。
结合自动化测试和系统监控
实际上，仅仅运行测试只会给你提供部分信息。为了获得更真实的情况，你可以将自动化测试结果与监控解决方案的输出结合起来（如第五章《方法、工具与技术》中所述，方法、工具和技术）。将二者结合起来可以让你更全面地了解整个环境的稳定性——或者说，环境是否稳定。更重要的是，如果发生问题，你将更容易定位根本原因。
好吧，虽然我把这个问题说得很简单，但说实话，整体目标是简单的；实现起来可能会有些困难。一如既往，有很多工具可以帮助你完成这些工作，但同样，需要时间和精力来正确地实现和设置它们。你应该将其视为另一个 DevOps 协作的机会。
然而，我们应该在前面提到的列表中添加另一个警告：你可能会在生产环境中遇到无法运行某些自动化测试的重大问题。
除非你的运维团队愿意接受在生产数据库中每小时/每天生成和销毁测试数据，并且他们也能接受因此带来的额外负载和可能的安全隐患，否则这种方法可能仅适用于非生产环境。
这可能足够让你开始，但如果你想要更全面的视图，你需要查看另一种互补的方法，以获取更深入的实时度量指标。
对软件本身的实时监控
将自动化测试和系统监控结合起来，可以提供有用的数据，但实际上只能证明两件事：平台正常运行，且测试通过。这并不能让你深入了解你的软件平台如何运行，或者更重要的是，它在被成百万的真实用户使用的生产环境中如何表现。要实现这一点，你需要迈向下一个层级。
想想看一辆一级方程式赛车是如何开发的。我们有一位试车手坐在驾驶舱内，输入指令让汽车执行某些动作；他们的脚踩在油门上，让汽车向前行驶，同时他们在转动方向盘，让汽车绕过弯道。你有一支技术员和工程师队伍，观察汽车的行驶速度，并能观察到汽车的运行情况（也就是说，当踩下油门时，汽车加速，转动方向盘时，汽车绕过弯道）。这些都很好，但对技术员和工程师而言，更有价值的是由汽车内部成千上万的传感器和电子设备生成的深入数据和度量指标。
这种方法同样可以应用于软件平台。你需要从平台内部深处获取数据和度量指标，才能完全理解发生了什么；单单通过测试和观察结果是无法获得这些的。这并不是一个新概念；它已经存在了很多年。只要看看任何一个操作系统，你就会发现有很多方法可以深入挖掘并提取有用且有意义的指标和数据。为什么不把这个概念直接应用到软件组件上呢？在某些方面，这已经是内建的；看看你的软件平台生成的各种日志文件（例如，HTTP 日志和错误日志），这就给你一个先机；如果你能够收集这些数据并加以利用，就更好了。
有很多工具可以帮助你浏览这些输出，并将其汇总成有用且有意义的报告和图表。不过这里有一个问题：在实时生成这些报告时非常困难，尤其是在产生大量数据的情况下，因为这些数据需要时间来获取和处理。
一种更简洁的方法是将某些功能直接构建进软件本身，使其能够以一种简洁、一致且对你有用的格式提供这种低级别数据——说实话，你的平均 HTTP 日志包含了大量对你毫无价值的数据。我将在附录 A 中讲解一些示例，一些有用的信息，但简单来说，这种方法可以分为两类：
-
在你的软件 API 中集成健康检查功能；这样，当中央数据收集解决方案周期性地调用时，它将提供低级别的度量数据
-
定期将低级别的度量数据推送到中央数据收集解决方案，以扩展你的软件平台
当然，你需要一些东西作为中央数据收集解决方案，但如果你在 DevOps 方法下选购并实施最适合你的工具，市场上是有这些工具的。
监控的理想状态
无论你采用何种方法（或方法组合），最终你都应该能够获得非常丰富且深入的信息。实质上，你将拥有与普通一级方程式技术人员一样的数据（那是大量大量的数据）。你只需要将所有数据整理成一个连贯且易于理解的形式。这一挑战也是鼓励 DevOps 行为的另一个因素，因为你想要捕获/展示的数据最好是双方工程师共同商讨并达成一致的。
如果你不确定是否应该测量平台或基础设施的特定部分，但感觉它可能有用，还是测量一下吧。你永远不知道这些数据是否会在以后派上用场。经验法则是：如果它在变化，监控它；如果它不变化，也要监控，以防万一。
最终，你想做的是确保整个环境（基础设施、配置和软件平台）是健康的。这样，如果有人说一定是环境问题，他们可能确实是对的。
如果我们把这一切整合起来，我们现在可以扩展之前的列表：
-
毋庸置疑地证明软件平台按预期工作，因此，遇到的任何问题必须是基础设施中的问题
-
毋庸置疑地证明基础设施按预期工作，因此，遇到的任何问题必须是软件中的问题
-
同意问题可能因任何原因发生，并且根本原因应该在协作的 DevOps 方式中被识别和解决
现在我们将从测量的技术方面转向业务导向的视角。
CD 和 DevOps 的有效性
实施 CD 和 DevOps 并不便宜。它需要付出相当多的努力，这直接转化为成本。每个企业都希望看到投资回报，所以没有理由不提供这类信息和数据。在本章的大部分内容中，我们一直在关注衡量进展和成功的更深入技术方面。这对技术导向的人员非常有价值，但普通的中层经理可能不会理解这些细微差别，坦白说，你也不能怪他们。看到大量的数据和图表，包含像每秒事务数（TPS）计数、某个软件组件的响应时间，或提交了多少次代码，对普通的管理者来说并不会感到震撼。他们更喜欢的是顶层的总结信息和数据，这代表着进展和成功。
就 CD 和 DevOps 而言，主要的关键因素是提高效率和吞吐量，因为这些因素直接决定了产品能够多快地交付到市场，以及企业能多快开始实现价值。这就是最重要的目标。CD 和 DevOps 是实现这一目标的催化剂，那么为什么不展示这些呢？
如果幸运的话，你将拥有（或计划拥有）一些工具来促进和协调 CD 过程。你还应该在这些工具中内置度量标准；你应该捕捉的度量标准包括：
-
完成的部署次数统计
-
将发布候选版本投入生产所需的时间
-
从提交到工作软件投入生产所需的时间
-
已构建的发布候选版本数量统计
-
已发布的软件组件排行榜
-
正在通过 CD 管道的独特软件组件列表
然后你可以将这些数据汇总出来，供所有人查看——它必须简单，必须易于理解。你可以在办公室的屏幕上显示类似下面截图所示的信息：
总结 CD 过程有效性的示例页面
这种信息非常有效，如果它是可见且易于获取的，它还可以引发关于进展如何以及哪些领域仍然需要一些工作和优化的讨论。
对于管理层来说，尤其有价值的是财务数据和信息，比如每次发布所消耗的资源成本。如果你有这些数据，包含它们不仅对管理层有用，还能帮助工程团队集中精力，因为他们会开始了解这些事情的成本。
访问这些数据和信息不应受到限制，且应该高度可见，以便每个人都能看到进展，并且更重要的是，看到自己距离最初目标还有多远。
我们已经看过效果了；现在让我们来看看实际的影响。
CD 和 DevOps 的影响
实施 CD 和 DevOps 将对你的工作方式和整个业务产生影响。这是事实。更好的做法是理解这种影响到底是什么。你可能已经在捕捉和报告一些像是业务关键绩效指标（KPI）（活跃用户数、收入、页面访问量等），那为什么不把这些也加入到更广泛的指标和衡量标准中呢？如果 CD 和 DevOps 对客户保持率有积极影响，大家看到这一点岂不是很好吗？
在基本层面上，你需要确保自己朝着正确的方向前进。
在我们离开衡量和监控之前，让我们看一个表面上看起来确实有些奇怪的事情：衡量你的 DevOps 文化。
衡量你的文化
我知道你在想什么：衡量软件、环境和流程已经够困难的了，那怎么衡量像文化这样无形的东西呢？说实话，没什么简单的答案，这真的取决于你认为什么最有价值。例如，你可能觉得开发人员有 20%的时间与系统运维人员一起工作，这表明 DevOps 在正常运行且健康，或者说是开发人员和运维团队一起解决现场问题，这也是一个很好的标志。
捕捉这些信息也可能很棘手，但它不需要过于复杂。你真正需要知道的是人们觉得事情是否在进展，以及他们是否认为事情是在正确的方向上进展。
捕捉这一点的最简单方法是尽可能多地询问人们。当然，你还需要捕捉一些有意义的数据点——仅仅拥有一个写着“进展顺利”的图表并不能给你太多信息。你可以考虑使用定期访谈或问卷调查来收集以下数据：
-
你是否觉得工程师（开发和运维）之间的协作有效？
-
工程师（开发和运维）愿意合作解决生产问题的程度如何？
-
当出现问题时，你是否觉得责任仍然是主要的因素？
-
你是否觉得运维工程师在功能开发的早期就参与其中？
-
是否有足够的机会让工程师（开发和运维）改善他们的工作方式？
-
你是否觉得自己拥有有效完成工作的工具、技能和环境？
-
你是否觉得 CD 和 DevOps 对我们的业务产生了积极影响？
你可能还能想出其他的示例问题；然而，不要过度，不要让人们感到轰炸——KISS（参见第三章，文化和行为是成功的基石）。如果你能使用允许用尺度形式回答的问题（例如，1 表示强烈同意，2 表示同意，3 表示不同意，4 表示强烈不同意），你将能获得更清晰的画面，然后可以随着时间进行比较。
再次强调，如果你将这些数据与技术数据结合起来，这可能会提供一些你未曾预料的洞察。例如，也许你实施了一项新流程，成功减少了 10%的逃逸缺陷，但每日发布的次数减少了 5%，而且大部分工程团队成员都不满意。在这种情况下，你可能在流程本身或在基层接受度方面存在问题。
总结
在本章中，你学到捕捉数据和衡量标准的重要性，因为这能清晰地指示出事情是否按照你计划和期望的方式进行和进展。不论你是对软件质量随时间的提升、缺陷的减少、软件平台的性能，还是过去一个季度的环境问题数量感兴趣，你都需要数据。大量的数据。将这些数据与以业务为重点和现实世界的数据相结合，只会增加价值，并为你提供更多关于事情进展的洞察。
你正在努力在整个组织中促进开放和诚实（参见第四章，文化和行为）；因此，在你的 CD 和 DevOps 实施过程中分享你收集的所有指标和数据，将提供高度的透明度。归根结底，任何业务的各个部分都会转化为数据、指标和图表（如财务数字、员工人数、产品的公众评价等等），那么，为什么产品交付过程应该有所不同呢？
越早开始收集这些数据，你就能越早进行检查和调整。你需要将你的口号从“监控、监控，再监控”，扩展为“持续且一致地监控和衡量”。
现在让我们从衡量所有可以和应该衡量的事物转向，看看一旦你的 CD 和 DevOps 采纳成熟后，情况会是怎样。在第八章，《你还没有完成》，我们将讨论一些在 CD 和 DevOps 成为常态时，你应该考虑的事项。
第八章：你还没有完全结束
直到这一点为止，我们一直在进行一段旅程，从揭示导致业务痛点的问题，到定义去除这些问题的目标和愿景，再到解决文化、环境和技术障碍，采用急需的工具和技术，克服障碍，再到衡量成功。
让我们把时间往前推，假设到这个时刻为止，前面章节和页面中的所有建议都已帮助你——加上更多的专业建议、补充出版物，甚至一些协助——并且你已经实施了必要的工具和流程变更。我们还假设 CD 和 DevOps 的采用在你们的组织中已经全面展开。
如果你在旅程的开始阅读这些内容，那么我建议你继续阅读，并运用你的想象力，设想在实施了 CD 和 DevOps 后，事情将会是怎样的。
如果一切按计划进行，业务部门已经开始看到收益，并且能够更快地向市场交付优质功能，远比之前快。从表面上看，你几乎完成了你的目标，实现了你的愿景，但——这非常重要——这并不是终点。
你们所经历的旅程是漫长的，就像那个坐在车后座、长时间开车去奶奶家的五岁孩子一样，你们组织中的人们现在会反复问一些问题，比如“我们到了吗？还要多久？什么时候可以停止花钱在这个 DevOps 事情上？”以及“我需要上厕所！”好吧，也许不是那么多关于上厕所的事，但我想你明白我的意思。现在是暂停片刻、盘点一下你们所处位置的好时机。
反思你们现在所处的位置
是的，你已经走了很长一段路；是的，事情进展顺利得多；是的，组织内部的协作更加紧密；是的，开发和运维之间的鸿沟变得不再是深渊，而更像是地面上的一道小裂缝；是的，你几乎完成了你最初的目标。你所做的是将软件交付的过程从复杂、痛苦和繁琐的状态，简化成了如下的简单过程：
你最初打算解决的问题围绕着软件交付过程中的浪费，包括冗长且无意义的流程、政治姿态，更具体地说，是来自大规模、少量发布的浪费。采用 CD 和 DevOps 帮助你克服了（大部分）这些问题。
因此，你现在会开始听到类似的评论，比如“我们可以快速部署，所以我们一定实施了 CD”或者“我们的开发人员和运维人员密切合作，所以我们一定实施了 DevOps”。
有人会建议，一旦你开始听到这些，那就意味着你确实完成了你最初设定的目标。从某些方面来说，这是对的；然而，实际上，情况远非如此。
这些评论所说明的事实是，旅程开始时突出的问题现在已经开始变得模糊和遥远。公司已经开始接受 CD 和 DevOps 作为我们在这里的工作方式，并且终于开始理解它们的意义，这是好事。然而，仍然有很多工作要做，问题也需要解决；尽管这些工作和问题已变得不同。就像你在旅程开始时做的那样，现在是时候检查并确认哪些问题现在重要，并适应解决它们。为了说明这一点，我们需要稍微偏离一下主题。
流动
让我们将你的软件发布过程比作一条流动的河流（我确实说过这有点偏题）：
- 在最开始时，许多小溪流汇入一个大河，这条河流向前流淌，但却被一系列的水坝和人工大坝所阻碍：
-
然后，河流开始倒流，形成了一个水库。
-
每隔几个月，闸门被打开，水流自由畅通，但这通常是短暂且匆忙的冲刺。
-
随着你识别并开始移除这些人工障碍，流量变得更加均匀，但仍然受到下游一些巨大巨石的阻碍：
-
于是你开始系统地一一移除这些巨石，这样又增加了流量；这反过来使得流量变得更加一致、可预测和可管理。
-
由于移除了障碍以增加流量，水位开始下降，小石子开始出现并形成涡流，这限制了流量，虽然不是完全停止，但还是稍微影响了流动：
- 流量继续增加，水位不断下降，很快就会明显看出，这些小石子其实是隐藏在河流深处的更多巨石的顶部。
那么，这和你采用 CD 和 DevOps 有什么关系呢？如果你停下来思考，答案其实很明显：
-
在你开始之前，你有许多工作流，最终汇集成一个复杂的发布——这些就是流入河流的溪流，最终堆积到水库中。
-
在旅程的开始，你对主要问题和挑战有相当清晰的了解。这些问题对所有人来说都很明显，并且是造成最大痛苦的原因——这些就像是锁和水坝。
-
你移除了这些障碍，流量开始变得更加一致，但它依然受到巨石的阻碍——这些障碍包括缺乏工程最佳实践、不良的文化和行为、缺乏开放和诚实的环境等等。
-
你系统性地解决并去除了每一块巨石，开始获得一个稳定、持续的流程，但新的不可预见的问题开始浮现，阻碍了你的进展——这些就是那些水面下实际上是巨石的小石子。
如果你回顾一下，你最初的目标和愿景集中在大象曝光检查阶段（人造水闸和大坝）中突出的问题——那些你知道在开始时就存在的问题。随着你系统地解决这些问题，你交付的软件流开始更加顺畅，你和更广泛的业务也开始看到一些积极和有趣的成果。随着时间的推移，那些不太显眼或重要的障碍（巨石）变得更加明显，成为了令人担忧的原因。于是，你改变了焦点，去除这些障碍，从而再次改善了整体流动性。
由于改进的本质，越是让一个流程变得高效和有效，越是会有那些小小的烦恼（小石子）变成障碍（巨石）。这并非 CD、DevOps 或 IT 特有的问题；这只是一个普遍现象。
这绝非全是悲观和沮丧，也不需要过于担心。你和业务已经面临过更大的挑战，现在你们具备了足够的组织成熟度，可以轻松应对这些新出现的障碍。这是成功的标志。
成为自己成功的牺牲品
人类是非常善变的生物。由于大多数业务由人类构成，它们也同样善变。短暂的成功很快过去，逐渐淡入集体记忆中，而几周或几个月前并不算问题的事情开始成为大家热议的话题——无论是在镇上的街头巷尾，还是在董事会、茶水间或洗手间。成功的另一个问题是，这会成为新的基准，意味着即便是最小的问题也可能迅速演变为重大问题。这些问题可能是一些相对简单的事情，例如：
随着采纳的成熟，相对较小的问题可能变成新的挑战
在几个月的时间里，最初在大规模发布周期约束下工作的团队成员——这些发布周期需要几周或几个月来整理、测试和推送到生产环境——几乎已经忘记了那些黑暗的旧日子，现在却开始找寻新的担忧和抱怨。这并不罕见；它发生在每一个项目中，不论是重大的业务变革项目，还是相对简单的软件交付项目。这并不奇怪，但如果你仔细思考，它其实是一个积极的问题。
直到最近，工程团队由于大规模发布过程中的官僚主义、复杂性和约束，受到严重限制，无法真正创新、实验或展示他们的工程能力。他们现在不再需要担心软件发布的过程，因为这已经成为一种日常的背景噪音，反复进行，不需要太多的努力——这主要得益于你们所做的出色工作。
现在提出的这些看似小问题，在黑暗的日子里，可能只是一些简单的麻烦，会被当作低优先级的问题被忽视或忽略。它们曾是水下的鹅卵石。现在，它们变得真实而庞大，像巨石一样，必须被解决；否则，可能会出现事情停滞不前的风险，日子也可能重新变得暗淡。
此时，你和更广泛的业务团队可能会开始问以下类型的问题（如果能帮到你，我也提供了我的回答）：
| 问题 | 答案 |
|---|---|
| 新问题的出现是否意味着你原本的目标没有实现，你已经失败了？ | 不是的！这只是意味着形势发生了变化。 |
| 这全都是浪费时间吗？我们似乎有和最初一样多的问题。 | 不是的。你之前遇到的那些问题——比如很久以前的“大象问题”——要大得多，影响范围也更广，而且从各方面看都被忽视了，或者至少是被接受了。而这些新出现的问题在直接比较下显得微不足道——尤其是对业务的成本来说——并且现在已经公之于众，所有人都能看到。 |
| 我们还需要花多少钱？ | 这取决于新问题的规模和相对优先级。然而，既然 CD 和 DevOps 现在已是标准 SDLC 的一部分，你应该像投资业务流程和工具中的任何其他部分一样进行投资。 |
| 我们错过了什么吗？ | 不，大多数新问题是在旅程开始时无法预见的，或者仅仅是些小麻烦。 |
| 这是否意味着你需要改变目标，制定新的计划，重新开始？ | 不一定。你现在需要的是一些 PDCA。 |
那么，究竟什么是 PDCA 呢？让我们来了解一下。
[P]lan, [D]o, [C]heck, [A]djust
这个缩写有多种变体；然而，最广泛使用的是计划、执行、检查和调整。你也可能听到 PDCA 被称为戴明循环或谢瓦特循环。无论你偏向哪种定义，PDCA 方法背后的理念都非常简单；它是一个框架和方法，帮助你进行持续的迭代改进。以下这个简单的图表应该能帮助解释这一点：
PDCA 的迭代过程
简单来说，这种方法是对之前多次提到的检查和调整方法的扩展——虽然实话说，它存在已久。这个概念非常容易理解和遵循，并且几乎可以应用于你 CD 和 DevOps 采纳的每一个方面。让我们看一个例子：
-
计划：你意识到当前的软件交付流程有问题，并决定通过运行研讨会来找出原因，绘制整个流程地图
-
执行：你运行研讨会，并从整个业务中收集输入和数据
-
检查：你分析输出，确定所提供的数据是否能让你了解流程中的痛点在哪里
-
调整：你突出显示一些浪费的领域，并商定纠正措施
-
计划：你设定一个目标，并制定一项攻击计划来解决主要痛点
-
执行：你按照这个计划执行
-
检查：你审查进展与目标之间的关系
-
调整：当发现更多信息和未预见的障碍时，你对方法进行微调
-
计划：你重新调整计划，确保在获取新信息后仍然可以实现目标
-
执行：我觉得你可以自己填写剩下的部分
就像本书涵盖的大多数工具和技术一样，与其他方法相比，选择 PDCA 方法是你的决定；然而，这是一个经过充分验证和广泛认可的框架——特别是当你考虑实施像 CD 和 DevOps 这样广泛影响和改变业务的东西时——因此，我建议你不要简单地忽视它。
如果你注意到收集数据和度量的重要性，正如第七章《重要的测量指标》所述，你现在应该有足够的数据来在 PDCA 的检查阶段使用，这将使调整阶段更容易定义。你甚至可能会发现一些不那么明显的问题。例如，如果你发现周期时间经常波动（检查），而这也与 QA 环境的计划外停机时间相对应，而后者又是由于存储空间填满所致，那么有人应该调查为什么会发生这种情况并阻止它发生（调整）——这可能只是（计划）增加更多存储空间。
PDCA 的一个主要优势是它在业务各个层面都易于理解，同时也非常适应性强——例如，本书就是使用了同样的方法开发的：
-
我规划了整本书的结构和内容
-
我随后把这些记录为一个提案
-
我将这份材料交给出版商审核并提供反馈
-
我评估了反馈并对整体计划进行了调整
-
我开始规划第一章
-
我写了第一章
-
我的编辑审阅了它并提供了反馈
-
我调整了第一章
-
我规划了第二章——我想你已经颇费心思地理解了这一点
如果 PDCA 不是你首选的框架或方法，我建议你在采取任何行动之前做一些研究。我特别说“采取任何行动”而不是“你行动”，因为你现在应该退后一步，审视一下自己所处的现状，了解自己接下来需要做什么。
退出，舞台左侧
经过许多个长时间的工作时段、日子和几个月，业务已经习惯了你和你身边的人一起花费大量时间、日子和几个月实施的变化。这个善变的业务现在正在经历并报告他们认为重要的新问题。问题是，谁来解决这些新出现的挑战？答案很简单——不是你，也不是那些与你一起推动 CD 和 DevOps 采纳的人。
你已经帮助嵌入了新的协作工作方式，帮助弥合了开发与运维之间的差距，帮助实施了新的工具并优化了流程，喝了很多咖啡，睡得很少。你已经做了你的部分，现在是时候让你帮助过的人摘掉训练轮，挺身而出，接过缰绳（来混合一些比喻）。
不再需要训练轮
很久以前，在第二章《理解你当前的痛点》中，我们探讨了如何识别业务面临的问题和挑战。我们称之为“房间里的大象”。你帮助整个业务理解并学习如何运用回顾和其他工具回顾过去并规划未来，同时教会他们如何通过开放、诚实和勇敢的对话，找到正确的路径。正如几次所提到的，新的问题和挑战就是这样：新的。
这些新的问题和挑战确实需要解决，但如果你把业务在旅程开始时的状态与现在在组织成熟度方面的位置进行对比，你会发现一个重大且非常重要的区别：现在，业务已经具备了快速识别新的“大象”般的难题的工具和能力，而且现在他们有足够的工具、知识、信心、经验和专业知识，能够迅速且无痛苦地解决这些问题。如果你不相信我，可以重新做一遍第一章《软件交付的演变》中的 CD 和 DevOps 进化量表测验，看看现在业务的得分与几个月前相比如何。
如前所述，你几乎已经达到了最初的目标（或者说差不多达到了，真是的），所以你的告别演出就是帮助他人帮助自己。在这段旅程中很有趣，但所有美好的事物都必须结束，现在正是考虑退出策略的好时机。这并不是说你应该逃避、躲藏，完全不参与；而是意味着，为了充分鼓励新兴的工作方式，你需要扮演负责任的父母角色，让孩子们独立成长，自己学习。
你现在的重点应该从推动采纳（做）转变为辅导和引导其延续（领导）。那些曾是 CD 和 DevOps 采纳的创新者——包括你自己——现在应该开始鼓励那些从采纳中受益的创新者和追随者走到前台，承担起他们自己的责任。这不会一蹴而就，但你需要非常清楚你的意图，让人们理解你正在交接接力棒。像将定期的 CD 和 DevOps 会议的组织工作交给他人，或在下次重大工具升级的时间安排时预留时间休息这样的简单举动，就足够了。当你需要时，“眼不见心不烦”的格言可以派上用场。
就像一个好的父母一样，你为成长和自我发现设定了一个安全的环境，因此，你只需要轻微的引导，偶尔的建议，以及在正确的方向上适时地推动。
作为这种新发现的父母式领导角色的一个重要部分，你需要重新审视 CD 和 DevOps 中更广泛且不易捉摸的领域，以确保自满情绪不会滋生。
不要安于现状
因此，你已经做了很多并取得了更大的进展，企业和其中的员工也因此受益。这是一件好事——你和所有参与其中的人都应该为所取得的成就感到非常自豪。然而，这并不意味着企业可以安于现状；虽然可能很有诱惑力，但仍然有许多需要控制的事情。
之前，我提到过会有新的问题和挑战从水面以下浮现出来，继续让新一代的创新者和追随者忙碌。通过你和前一代人的辅导和引导，他们会没问题并解决这些新的挑战。与此并行的是，当新事物变得常态化时，自满情绪也会随之而来。你帮助了企业发展，但你必须非常注意这样一个事实：如果企业中出现真空，自满情绪渗透进去，它就会像进化一样迅速地退化。
恐惧真空（更常见的说法是“自然厌恶真空”）——亚里士多德
就像任何深远的项目或企业变革一样，如果急剧的变化速度开始放缓或看似停止，事情就会开始停滞，陈旧的固有习惯会重新浮现。在这种环境中，落后者可能会再次变得高调，而追随者们也可能开始听从他们的意见。你将积极而显著地从执行者转变为推动者和影响者；因此，你的角色将是确保事情顺利进行，保持警觉，留心新的威胁。你已经建立了一个良好的网络，因此应该开始利用这个网络来获取早期警报。
与你所取得的成就相比，这看起来可能简单，但有时却更加困难；你习惯了积极参与并推动他人，亲自做事情，而现在你必须保持距离，看着别人做你依然充满热情的事情。虽然有时更难，但同样充满回报。把它当作个人进化的下一步。因此，你现在处于一个良好的位置，可以超越最初的目标，看看是否有机会在更广泛的领域提供帮助。
总结
采用持续交付（CD）和 DevOps 是一个漫长而艰难的过程。如果你认为这不难，那你就是被误导了。随着你接近旅程的终点，你将遇到满是大象的河流和其他不可预见的挑战。在此过程中，需要父母般的指导来引领企业走向正确的方向，同时你也需要规划如何走出聚光灯，腾出空间给那些从你们共同取得的成就中受益的人。新的问题会出现并威胁到采纳的进度；然而，企业现在更加成熟，应该具备应对这些问题所需的工具、经验和智慧。保持警觉是值得赞赏的，但也有更重要、更值得关注的事。在第九章，拓展你的机会视野，我们将探讨一些来自成熟的 CD 和 DevOps 文化中更大、更好的机会示例。
第九章：拓宽你的机会视野
如你所猜到的，我们的关注点主要集中在传统企业中的传统软件交付上，这些公司提供的是传统的 Web/服务器软件解决方案和产品，而非那些年轻、时髦且富有创新精神的初创科技公司。原因在于，初创企业通常具备内在的敏捷性和创新机会，能够灵活交付软件。大多数科技初创企业——尤其是近几年成立的——通常会将 CD 和 DevOps 融入到他们的日常工作方式中。
也许你目前就在这样一家时尚企业工作，但 CD 和 DevOps 并未从一开始就融入其工作方式中。这不应成为问题，因为本书应能为你提供一些解决这一差距的好点子和指导。
绝大多数日常交付软件的公司并没有那么幸运——尽管有意图，但可能缺乏行动的意愿。因此，关注点依然停留在传统模式上。很有可能你自己也在其中一家传统公司工作。
如果你已经遵循了本书中提供的建议，并成功采用了 CD 和 DevOps，那么你很可能已经赶上了那些年轻的天才，你的业务在交付软件的方式上能够同样具有敏捷性和创造力，甚至可能更具优势。
在第八章的尾声部分，你还没有完成，我们将焦点转向了你，以及你如何将新获得的知识、技能和经验继续推进，超越最初将 CD 和 DevOps 工作方式嵌入组织的目标。让我们来看一下这实际上意味着什么。
那我呢？
假设在这个故事的叙述中，你在 CD 和 DevOps 的成功采纳中发挥了重要作用，并达成了你最初设定的目标。事情进展顺利，甚至比你预想的还要好。业务已经成熟，能够独立解决问题，不再需要你牵着手走——嗯，差不多吧。
如第八章《你还没有完成》中所提到的，你还没有结束，你应该花一两分钟考虑一下，在这段旅程的开始时，大多数企业中的个人处于什么位置，现在他们又处于什么位置。考虑一下工作方式、沟通、协作和行为上的变化。想一想在发展初期创新者、跟随者和滞后者的比例，现在又是什么样子。考虑到所有这些，你很可能会发现，现实中，大多数人现在处于你开始时的同一个位置——他们只是刚刚意识到，事情有另一种做法，而且那是一种更好的做法。没错，依然有工作要做，目标是使一切尽可能有效和高效，还有一些小问题需要解决，但总的来说，事情是好的。
现在，看看你个人走了多远；就大多数你曾经合作、指导和教授 CD 与 DevOps 方法的人来说，你就像远处的一个身影：
他人对你的看法
无论你在旅程开始时的角色是什么，开发人员、系统管理员、经理，还是其他什么角色，现在你的角色已经发生了变化。无论你是否喜欢，你已经成为了知识、专业技能和经验的拥有者。你是 CD 和 DevOps 的主题专家。你了解你的专业。
你可能觉得你早期采用的创新者同伴们也都和你肩并肩站在一起，但为了简单起见，今天阅读这些内容的是你，因此你就是那个站在远处的人。
你已经走得很远，景象与你最初开始时大不相同，你还有新的高峰需要攀登——这些是现在企业已经准备好要看的新机会。也许这些曾经是企业无法克服的挑战；也许他们根本不知道这些机会的存在，但凭借新获得的知识，他们渴望尝试新的事物。也许你的首席技术官（CTO）和他年轻时尚的同行在高尔夫球场上聊得很投机。无论是什么原因，现在是时候将你的东西应用于这些新的挑战和机会了。接下来是一些示例，说明你如何在传统软件交付之外，运用你的技能、专业知识和经验。
接下来是一些在成功采用 CD 和 DevOps 后可以开启的机会示例。有些可能在没有 CD 和/或 DevOps 的情况下也能实现，但根据经验，没有这些工具，结果不会那么理想。这些是你——如果你愿意接受——可以投入精力、关注和时间去解决的新挑战和机会。
性能和负载测试
你们中更为细心的人可能已经注意到，本书中几乎没有提到性能或负载测试。这是故意为之，因为在我看来，如果没有持续交付（CD）和开发运维（DevOps）所带来的紧密协作、工具和技术，进行这些活动就是一项徒劳的任务。是的，确实有许多传统的方法，但这些方法通常会在你准备发布代码之前将某些东西强行塞进流程中——这可能会导致由于最后一分钟发现性能问题而导致代码无法发布。你可能已经通过实施一种周期性地获取软件版本并在受控且高度监控的环境中进行密集自动化测试的过程来解决这个问题。这有一定帮助，但除非你已经设置了完全模拟实际使用场景的自动化测试，否则你基本上是在给大家带来虚假的希望，认为代码上线后不会出现性能问题。
我还敢猜测，在暴露问题的检查阶段，性能/负载测试被视为一种负担，甚至是浪费资源的行为。实际上，这种看法既不必要，也不应该是如此。
一旦你采用了持续交付（CD）和开发运维（DevOps），性能/负载测试的过程可以变得相对简单直接。你只需要改变思考和处理问题的方式。
有一种非常简单且易于理解的方法来考虑负载和性能测试；迄今为止，最好的方法是在生产环境中检查软件在实际负载和使用下的表现。你可能正在阅读这段话并想，作者是不是疯了？这可能是真的，但我请求你耐心听我说下去，并自行做出判断。
假设你已经实施了对整体生产环境以及其中运行的软件进行广泛监控（正如在第七章中提到的，关键指标），通过这些监控，你可以详细观察硬件、基础设施和软件在背后发生的情况。通过这些数据，你能够清晰地了解正常日常操作时的表现应当是怎样的。
通过这些数据，你应该能够安全地进行受控实验，并观察平台整体性能的结果。例如，你可以进行一项实验，逐步施加额外的负载到正在使用的平台上，方法可以是将更多的用户活动路由到特定的节点或服务器，或者通过运行一些非侵入性的自动化测试，以受控的方式生成负载。当你增加负载并提高负载时，你将开始看到痛点——一种近乎实时的热图。由于开发和运维团队密切合作，共同观察平台，他们应该能够通过将正常的日常统计数据与负载下生成的统计数据进行对比，找出问题所在。
如果在某个时候问题被定位，它们可以通过使用 CD 工具实时应用补丁来轻松克服，而负载仍然存在——提供即时反馈。或者，他们可能会看到平台的整体慢下来，但监控解决方案没有突出显示任何具体问题。这可能意味着整体监控覆盖存在一个漏洞，这同样可以通过协作方式定位并解决。无论如何，简单地将负载调回正常日常负载即可恢复正常状态。
你们中的一些人可能正在阅读这篇文章，并认为生产环境是神圣不可侵犯的，不应当用于此类活动，因为这可能会影响到同时使用平台的客户。我的看法是，除非你故意限制可以访问生产环境的人数，否则这种负载增加将会在你不知情的情况下以不受控制的方式发生——特别是当你的 CD 和 DevOps 采用直接导致客户满意度和增长提升时。为什么不在增长发生之前，确保你的生产环境已为此做好准备呢？
总而言之，如果没有充分的监控和/或开发与运维团队之间高度的协作，尝试进行性能或负载测试将无法提供预期或所需的结果。在生产环境之外进行测试将得到混合结果。这并不是采用 CD 和 DevOps 的明显好处，但它是一个非常强大且令人信服的好处，就像减少复杂性一样。
减少功能标志的复杂性
有许多已建立的方法可以在实时中切换不同的使用案例或用户流程，但大多数方法都围绕着某种功能标志或平台中的配置设置展开。尽管这是一个可行的方法，但它确实会在代码库中增加一些内容，随着时间的推移，这可能会成为一个巨大的麻烦。这个“东西”就是复杂性。
这不仅增加了代码库的复杂性，还增加了相关活动的复杂性，如测试和整体平台的设置/支持，尤其是当你开始将特性标志链式连接时。例如，假设你有一个新的报告功能（我们称之为特性 C），如果报告菜单功能（我们称之为特性 B）被手动启用并且遗留报告功能（我们称之为特性 A）被手动禁用，那么特性 C 会自动启用。如果特性 A和B 被手动启用，那么特性 C 会自动禁用。然而，如果特性 A 和 B 都被手动禁用，那么第三方报告功能（特性 D）将自动启用。
以下可能会使这个例子更容易理解：
这一切看起来足够简单，基于简单的逻辑门，但想一想，当你拥有一个平台，其中有特性标志控制着数十个或数百个特性时，会发生什么——其中一些是相互独立的，而另一些则形成了一个奇怪、复杂的链式特性树。测试所有这些组合并尝试支持一个可以设置成数百种（有时是数千种）不同状态的生产系统将是一场噩梦，更不用说当问题出现时，试图调试特定问题是多么徒劳无功了。
我曾经参与过一个产品的开发，其中有超过 50,000 个特性标志——大多数特性标志的来源和控制的功能早已被时间的迷雾掩盖，因此，新的特性标志不断被添加，用来控制新添加的功能。复杂性完全失控！
成功采用了持续交付（CD）和 DevOps 后，你将能够定期且持续地轻松地发布代码，并且开发和运维团队将紧密协作。因此，使用 CD 方法来启用和禁用功能将变得更加简单。换句话说，要启用某个功能，你只需要发布包含该功能的代码——不需要使用标志、设置或复杂的链式操作。你当然会先进行测试，确保没有出现意外的负面影响，但有一个非常简单的回退方法：发布不包含新功能的先前版本（如果你遵循第五章中的“永远不破坏你的消费者”建议，方法、工具与技巧，回滚应该不会引起任何问题）。我相信你会同意，这种方式既简单易懂，又便于开发和支持。
好吧，这可能是一个过于简单化的观点，但通过 CD 和 DevOps，你可以开始以新的和创新的方式看待这些问题。其优势可能不会立即显现出来，但至少减少复杂性将为你节省时间、金钱和精力，同时减少过程中的浪费。
在软件中使用功能标记的原因之一是为了实现 A/B 测试。现在我们来看看 A/B 测试到底是什么，以及 CD 和 DevOps 如何帮助改善这种方法。
A/B 测试
A/B 测试已经存在一段时间，它是一种非常有效的方式，用来尝试对用户旅程和/或软件解决方案中的逻辑流程进行更改。其简单的前提是，通过配置、功能标记或巧妙的流量路由，你可以将一定数量的用户（或通过使用软件本身产生的交易）引导到不同的路径。这有助于在通常是在生产环境中以受控条件下尝试新功能和/或功能，以验证或反驳某些假设。
我不会深入探讨这个话题——有很多书籍和在线资源专注于这个话题，我鼓励你去阅读。
举个例子，假设你的业务想要看看如果引入一个新的设计或微妙的网页布局变化会产生什么影响。如果你能够以某种方式将特定的用户或用户群体引导到路径 A，而将其余的用户引导到路径 B，那么你就可以通过分析和度量来监控并比较用户行为，看看哪种效果最好。
下图提供了这种方法的简化概览：
一个简单的 A/B 测试示例
另一种有用的方法是偷偷进行 A/B 实验。例如，如果你有一个新的推荐服务想要试用，你可以将一些用户流量和交易引导到这个新服务上，看看它与现有服务的表现如何。你甚至可以使用相同的机制，将数据路由到特定服务作为负载测试的一部分。可能性是无穷的。
你不一定需要 CD 或 DevOps 来实现 A/B 测试；然而，两者确实能为你带来一些重大好处：
-
能够极其快速地发布代码——例如，你希望在几分钟内在所有服务器上实施代码，将流量分配到 A 或 B，从而确保所有用户同时使用相同的代码。
-
你有开发和运维团队紧密合作，监控正在发生的一切。如果在用于分析结果的数据中发现有缺口，你能够相对容易地解决这一问题。
-
如果事情发生意外变化或你已完成实验，你有选择相对快速回滚所有内容的选项，并且几乎没有或完全没有影响。
如果没有 CD 和 DevOps，你需要提前非常紧密地规划此类活动，并且希望在实施时没有遗漏或错误。除非你有能力进行小规模的补丁发布，否则你无疑需要在完整的发布周期内包含任何变更——无论多小——以便启动正常的、规避风险的流程。完成后，回滚这些变更时也将适用同样的流程。
A/B 测试的另一种变体（或至少是一个紧密相关的形式）是 Alpha 测试和 Beta 测试（有时称为封闭测试或预发布测试）。这使我们能够在现有解决方案的基础上尝试广泛的 UI、UX 和功能性变更。通常，这种测试会限定在特定的用户群体中，或仅通过邀请进行。与 A/B 测试传统上针对小范围、具体的变化不同，这种测试通常更为广泛。基本前提仍然适用：以受控的方式尝试新功能和特性。同样，虽然可以在没有 CD 和 DevOps 的情况下实现这一点，但这样做将更加复杂、风险更高，并且容易失败，因为旧式的流程会妨碍进展，拖慢速度，并且——根据经验——最终会被归咎于测试失败的原因。试想一下，如果没有及时响应问题的机制，如何同时维护两个版本的整个 UI 并使其并行运行。
如前所述，A/B 测试基本上是为了验证或反驳某些假设，无论是由于市场条件变化，还是作为战略方向改变的一部分。无论背后的原因是什么，进行 A/B 测试通常是时间敏感的。如果没有 CD 和 DevOps 帮助你频繁交付高质量软件，成功运行 A/B 测试的能力将受到阻碍，因为在你努力计划和执行发布的同时，世界可能已经发生变化，而你最初想要测试的用例可能不再相关。正如人们所说，时间不等人，也不等女人和 A/B 测试。
接下来我们将从测试转向颜色——实际上是蓝色和绿色。
蓝绿部署
一些熟悉 CD 的人无疑听说过蓝绿部署，它是原始 CD 方法的基石之一。对于那些不了解的人，蓝绿部署允许你在现有版本/服务器运行的同时（如其名所示）部署软件的新版本（或具有更新操作系统的新服务器，或新的配置或数据库引擎等），然后无缝地将新版本切换为旧版本。这是对这种方法的一个非常简化的概述，但可以说这是一个相对容易理解的概念。
这种方法大大提高了你不仅减少/消除停机时间的能力（见 第五章，方法、工具与技术），还可以尝试并行版本控制（例如，在同一环境中运行两个不同版本的相同内容）——这同样能帮助 A/B 测试：
尽管这种方法与持续交付（CD）紧密相关，但采用 DevOps 也会使得管理、规划和协调变得更加容易。如果开发和运维团队之间没有密切的合作与信任，就有可能导致问题严重—尤其是在处理生产环境时。例如，如果一名开发者不小心将破坏性变更部署到 API 中，并且这个 API 与现有的 API 一起存在，但消费者服务（见第五章，方法、工具和技术）开始同时与两者进行交互，这将导致非常不一致的结果，甚至让人摸不着头脑。有了 DevOps，找到根本原因相对容易，并且可以通过协作来修复潜在的数据问题。
我不打算深入细节，但我强烈建议你进行一些 CD 的研究和阅读—在附录 A，一些有用的信息中有相关参考资料—不过，可以简单地说，蓝绿部署是一种非常强大的工具。
我强烈推荐的另一件事是利用 CD 和 DevOps 来减轻安全补丁的负担。
安全补丁与“拯救培根”
看起来每天新闻中都充斥着关于最新遭到黑客攻击的企业，或是遭受分布式拒绝服务（DDOS）攻击的报道。当然，这些只是我们知道的—研究表明，很多企业并未公开承认大规模的 IT 安全问题（又为什么要承认呢？）。近年来，这使得企业，尤其是高层管理人员，对变革变得异常谨慎，并非常关注确保他们的 IT 系统在安全补丁方面保持完全（或至少大部分）最新。大多数时候，这通常是以软件交付为代价的。
当企业采用了 CD 和 DevOps 时，安全补丁的实施和验证就变成了另一个需要交付的变更。如果补丁是在操作系统（O/S）级别，那么第五章，方法、工具和技术中讨论的配置即代码方法将会适用。对于网络、基础设施和运行时框架（例如 JAVA、.NET 等）也是如此。如果补丁是在软件层面（例如，某些使用的开源软件中发现的补丁），那么通过 CD 管道交付软件变更的方式已经经过了充分的验证。
为了简化叙述，假设某个企业遭到黑客攻击，客户数据由于网络中的安全漏洞和未打补丁的操作系统而被盗。
现在让我们将这个场景应用于一个没有采用 CD 或 DevOps 的传统上市公司。考虑以下问题并思考可能的答案：
-
你认为他们会多快修补漏洞以解决问题？
-
你认为他们的运营团队在 CEO、公关副总裁和运营高级副总裁都在盯着他们想知道 IT 系统何时修补时，心情会有多冷静？
-
你认为运维团队对匆忙应用本应几个月前就该应用的操作系统和网络补丁不会影响软件平台有多自信？
-
当工程高级副总裁告诉开发团队他们在解决由于匆忙应用操作系统补丁引发的问题之前不能回家时，你认为他们会有多高兴？
-
当新闻曝光他们被黑客攻击，客户数据被窃取时，你认为一家上市公司会失去多少市值？
-
会有多少人被辞退？
猜测这些问题的答案并不需要博士学位。像这样的情况并不像以前那样孤立或罕见，近年来的后果已经非常广泛，代价高昂，并且让那些卷入其中的人们的职业生涯受到了限制。
现在，想象一下一个已经采用 CD 和 DevOps 的公司的相同情况。对前面问题的回答大致会是这样的：
-
他们能像平时一样迅速发布——最多几分钟或几小时。
-
完全冷静，坦白说，高层管理人员直到通过常规监控发现问题并被告知正在处理时才会知道。
-
非常自信，因为他们可以与开发团队合作，确保不会产生影响和/或并行工作以制定应对影响的计划。
-
他们不会有这种问题。
-
如果传达的信息是：“我们发现了一个问题并已经应用了修复。影响非常小，我们可以向客户保证他们的数据是完全安全的，”那么这条新闻不太具有新闻价值，市场甚至可能不在乎。事实上，他们可能会将此视为好消息，并希望加大对该业务的投资。（好吧，我无法量化这个，但它是有可能的。）
-
没有人。
如果你的 CD 和 DevOps 采用已经成熟，因安全补丁过时而导致黑客攻击的概率会非常小，因为定期安全补丁的监控和实施将被纳入日常工作流程中，无论是通过配置即代码（configuration-as-code）还是作为软件交付流水线的一部分。然而，始终会有不可预见的安全漏洞，所以了解当这些情况发生时有一种快速的解决方式是很重要的。
如你所见，采用持续交付（CD）和 DevOps 可以带来一些非常重要的拯救局面的好处。这并不是说没有 CD 和 DevOps 你不能取得相同的结果，但能够快速交付，并且开发和运维团队之间有非常紧密的合作关系，将使得在问题发生之前更容易发现并修复实时问题——而不是让你的公司成为晚间新闻的头条。
如前所述，总会有无法预见的事件影响生产系统的正常运行，保持领先应对这些事件可能是困难的。然而，确实有一种方法可以帮助在这些问题显现之前发现它们。这就是主动去尝试破坏实时平台。故意的。
混沌猴子中的秩序
无论你多么细心地照顾和关注你的平台，总会有不可预见的事情发生，尤其是在你最不期望的时候。例如，服务器可能会崩溃，进程可能会开始循环，网络交换机会决定不再作为网络交换机工作，SAN 会决定自己喜欢在单用户模式下运行，最新的安全补丁可能会导致软件平台出现问题，或者有人会因为你是一个大目标而决定黑你。正如那句老话所说的，你应该时刻准备好应对意外。
大多数企业都会有某种业务应急计划来应对突发情况，但很有可能他们并不会刻意去强迫问题的发生，至少不会让它发展到实际发生坏事的程度——他们只是希望坏事永远不会发生，如果发生了，他们希望并祈祷能够做好准备，计划能够发挥作用。
如果你有一套工具，能够在受控的方式下安全地启动故障，以观察发生了什么， 更重要的是，观察平台中的薄弱环节在哪里，这样的工具是否有用呢？这正是几年前某个聪明人所做的事情，而这也被广泛采用为混沌猴子方法。虽然有一些变种，但其核心内容就是：一套工具，能在你高度监控的环境中运行，其存在的理由就是尽力去破坏它。
如果你对这个话题进行一些研究，你会发现目前大多数工具都集中在基于云的安装环境中。这并不意味着这些工具不能在本地环境中使用，但它们的效果可能较低，且风险较高，所以你需要考虑到这一点。
如果在没有强大嵌入式持续交付（CD）和开发运维（DevOps）文化的情况下尝试这种方法，结果会是一团糟——说实话，我怀疑你是否能在一开始就被允许尝试，因为你需要让组织中非常高层的人理解为什么必须这样做，并愿意承担风险。通过紧密合作、深入监控和依赖信任的关系，依赖 CD 和 DevOps 的做法使得尝试去破坏平台并观察发生的事情相对（但不是完全）没有风险。
这种方法有一个前提：你需要确信你的平台在设计和构建时已经考虑到优雅地处理失败的机制。你应该避免在公开场合犯平台自杀（platformicide），让核心转储和 HTTP 500 错误信息暴露在所有人面前。同样，这可以通过 DevOps 的方式来解决，确保环境和运行其中的软件能优雅地失败。
混乱猴子方法的另一个优势是，它也是一个很好的方式，能让 Dev 和 Ops 团队共享平台如何运作的知识。如任何具有创造性和技术思维的人所说，理解某个事物如何运作的最佳方式就是将其推到极限，看看它的运作机制。回到我们在第七章中提到的 F1 赛车类比——关键测量，工程师和驾驶员会在测试和练习圈中定期将赛车和组件推向极限，确保赛车在需要时按设计工作。通过这种活动获得的信息，可能意味着能否站上领奖台与被超越之间的差距。
现在我们将暂时不讨论持续交付（CD）和 DevOps 的潜在破坏性力量，而是考虑 CD 和 DevOps 如何使你的客户和组织内其他团队的工作变得更加轻松。
终端用户自助服务
在本书的过程中，我们一直关注将软件推送到指定环境（包括生产环境）的单向流程。其本质上是一个软件工程团队对自己的变更充满信心，因此触发将其发布的过程，或是一个 Ops 团队有信心将配置作为代码的变更发布。
如果你把这个情况颠倒过来，允许你软件平台的用户随时主动“拉取”你的软件呢？这听起来可能有些奇怪，但在某些合法的场景下，这种做法可能是必要的。
我们来看几个场景：
-
你有一个实施团队，负责新客户的引导，他们希望测试不同的场景和用例，以确保他们的手动测试脚本、常见问题解答和培训文档是最新的。
-
SecOps 团队需要在他们封闭的测试实验室中，针对平台的副本运行一系列深度安全扫描和一些 DDoS 场景。
-
公关和市场营销团队需要为新闻稿拍摄当前 beta 平台的屏幕截图。
-
销售团队即将向一个重要的新客户展示，并希望在他们的 Mac 上的虚拟机中运行软件平台的本地副本，因为会议中心内没有可靠的 Wi-Fi。
-
一名内部审计员正在调查六个月前的数据泄露事件，并希望获取当时平台的精确副本。
使用传统的技术和方法，前述每种场景都会涉及大量琐碎的工作（我这是在轻描淡写）来设置一个专用环境，并让所有需要的软件安装并正常工作——更不用说基础设施的设置了。这些琐碎的工作必须根据各个团队已有的工作负载来进行优先级排序，因此可能需要很长时间——很可能远远超出环境需要的时间。我敢肯定，你自己一定也经历过这种沮丧——我知道我经历过很多次。
现在考虑一下，如果这些团队/用户能够按下一个按钮，自动为他们设置一个完整的环境，这将会减少多少琐碎的额外工作？如果他们还可以通过自助服务门户指定他们想要的精确版本（例如，生产版本、测试版本、当前进行中的工作、时间快照等等），那该多好？
随着 CD 和 DevOps 融入你的工作方式，没有明显的理由不能做到这一点。虽然这需要一些设置工作，但你已经拥有可靠的工具来配置环境、部署软件资产，并提供深入的监控。如果自动化出现了偏差，或者没有涵盖某些场景，你有一个习惯于协作的 DevOps 团队，他们也乐于帮助解决问题。
将用户自助服务的范围扩展到你的组织边界之外，也是 CD 和 DevOps 可以帮助你实现的目标。
作为服务的物品
随着软件解决方案的成熟，投资于这些解决方案的企业不断寻求新的、有趣的方式来利用已作出的投资。通俗来说，他们希望从已支付的软件中赚取更多的利润。
有很多成熟的方法可以实现这一点，但PaaS（平台即服务）或SaaS（软件即服务）是最受欢迎的，并且在通过现有软件平台赚取更多收入的全新且有趣的方式中非常流行。你可能还记得我们在第三章，文化与行为——成功的基石中简要提到过这些内容，涉及第三方工具。其基本前提非常简单；你通过应用程序编程接口（API）将某些功能暴露给第一方或第三方，他们使用这些 API 扩展他们的软件平台，以包括你所提供的功能。例如，如果你的软件平台专注于汽车租赁预订，你可以将 API 暴露给一个价格比较网站，让他们的用户能够通过你的软件平台无缝地预订汽车。
这种方法已经存在多年，有时被称为 B2B 或类似的东西，但它一直被视为一种实施、维护、安全、变现和支持起来都非常痛苦的东西——尤其是对以传统方式交付软件的公司来说。在涉及对可能影响 API 的任何更改时，也存在复杂性，这可能导致技术债务的积累和/或使使用这些 API 的客户/客户端不满（参见 第五章中的“永远不要破坏你的消费者”，“方法、工具与技术”）。与此相对的是，任何所需的 API 更改交付速度较慢——当第一方或第三方已经采用了 CD 和 DevOps 并能比你更快地行动时，这成为了一个问题。这有时会导致他们开始寻找下一个合作伙伴。
我不会说 CD 和 DevOps 的采用可以在没有任何努力和投资的情况下实现这种方法，但它确实能大大简化使其启动和运行的过程，并保持其持续运行。这反过来应该消除“SaaS/PaaS 实施起来过于痛苦”的看法，并应被视为一种利用软件平台的新颖且有趣的方法。此外，你还会发现，已经采用 CD 和 DevOps 的组织更有可能与那些以类似方式运作的供应商合作，因为他们知道新的需求可以快速且可靠地实现，且合作是自然而然发生的事情。
总结
在本章中，我们专注于你在推动 CD 和 DevOps 采用之后的演变，以及你如何帮助业务发展超越仅仅是频繁交付高质量软件的阶段。我们回顾了一些例子，说明 CD 和 DevOps 如何进一步改善所有参与产品交付的人的工作方式，以及它们如何为业务打开新的机会。
你或许能想到一些与自己情况、组织或业务更相关的场景和有趣问题，但重点是，一旦 CD 和 DevOps 融入你的工作方式，你就能够减轻 Ops 和 Dev 团队的负担，帮助他们解决新问题，并提高你内部和外部客户的满意度。
到目前为止，我们一直在讲述 CD 和 DevOps 运动的创始人力求优化、简化并减少痛苦的网络/服务器软件交付方式。在我们的最后一章中，我们将探讨 CD 和 DevOps 如何在它们的舒适区外使用，以及你如何为你的组织和业务带来更多的价值。
第十章：超越传统软件交付的 CD 和 DevOps
CD 和 DevOps 通常与交付基于 Web 服务器的解决方案相关——这并不意味着它仅限于此，然而，这是常态。正如你所学到的，CD 和 DevOps 并不特别与工具或技术相关。CD 和 DevOps 的真正采纳是基于文化、行为和工作方式的提升，以顺畅变更流程，从而实现持续交付价值。这意味着它们不必局限于传统的软件交付方式。一旦你的业务采用了 CD 和 DevOps 作为我们这里的工作方式，你就可以、应该，并且能够将相同的方法应用到解决其他业务问题上。
最显而易见的做法是将 CD 和 DevOps 方法应用到大多数交付软件解决方案的企业通常认为困难的事情上：移动应用。
CD、DevOps 与移动世界
CD 和 DevOps 基于文化、行为和工作方式，因此，将这些方法应用于交付移动应用程序——这是一个庞大且不断增长的行业——是可行的。这并不是说它是一个千篇一律的采纳；在交付移动应用软件与 Web 基于服务器的软件交付方式之间，确实存在一些不同之处，当前的主要差异如下：
-
每天无缝地将软件交付到 Web 平台 10 次而不影响最终用户是可以实现的——你完全控制着基础设施和发布机制。而同样的操作如果应用到移动应用程序上，会对最终用户产生重大影响——你能想象如果每天向最终用户的智能手机发送移动应用 10 次会发生什么吗？
-
终端用户的智能手机/平板电脑、音响、冰箱、灯具、门锁、宠物监控摄像头等设备中没有 Ops 团队，因此，DevOps 合作中的 Ops 部分并不严格存在。
-
你无法保证你将要部署的设备的规格、尺寸、网络能力等。
-
严格来说，你并不完全控制软件的最终分发。
那么，你如何解决这个难题呢？让我们依次来看看。
关于第一个要点，实际上你不会希望比每几周一次的频率更频繁地发布——即便你具备这样的能力——因为这样只会骚扰终端用户。因此，你应该采用发布列车的方法。实质上，这意味着逐步积累变更（这些变更都是独立构建、测试和通过你的 CD 管道发布的），直到你觉得足够的时间已经过去，可以进行发布。有一个例外：你可以（并且应该）频繁地向内部 Beta 测试/自用用户发布，以便他们随时体验最新版本。
关于第二点，除非你能将运维团队缩小并克隆成数百万倍，否则你能做的也不多。不过，如果你按照第五章《方法、工具和技术》和第七章《关键指标》的建议，你会在软件中嵌入分析和度量，并且已经实施了深入的监控，因此，你将能够像在服务器上运行软件一样，发现应用程序在运行中可能出现的问题。如果发现了问题，开发和运维团队可以协作，找出问题所在并加以修复。
关于第三点，你可以尝试在测试中考虑这一点，但说实话，这是一项非常没有回报的工作。我建议集中精力关注畅销应用，并根据捕获的分析数据和指标，确定用户更喜欢哪些尺寸、规格和设备类型——如果你看到某个设备类型的使用趋势上升，那么你应该考虑将其加入到支持的设备列表中，并将其包含在自动化测试套件中。否则，你可以考虑使用专门从事移动设备测试的外部解决方案/提供商——许多这样的解决方案可以通过 API 驱动，这意味着你的测试解决方案可以协调并控制测试的执行。
关于最后一点，你能做的并不多。目前，领先的应用商店已经非常成熟且可靠，且在全球范围内具有良好的覆盖。持续交付（CD）给你带来的优势是，应用商店实际上是一个二进制仓库，而这正是你的 CD 流水线已经习惯发布到的地方，因此发布可发布的应用程序的机制与服务器端软件的发布机制非常相似。此外，大多数应用商店都支持自动更新，这意味着当你发布新版本的应用程序时，最终用户应该很快就能收到更新。然而，也没有绝对的保证，因此你需要考虑到，仍然会有一些版本在外面运行，需要支持。
这实际上只是表面上的探讨，但它在某种程度上突出了传统基于服务器的应用程序和移动应用程序在软件开发生命周期（SDLC）过程中的相似性。
现在，你可能在阅读这段文字时会想，许多科技公司正在构建并发布移动应用程序，而并没有正式遵循我们在本书中讨论的持续交付（CD）和 DevOps 方法，那么为什么你还需要去在意呢？因为你可以，而且它会带来价值。将协作、信任和诚实融入到组织中的工作，可以轻松地应用到你的移动应用程序上。你已经实现了工具和技术来自动化构建、测试、发布和监控服务器平台的过程，因此将这些扩展到你的移动应用程序上应该是（相对）简单的。
另外，现在可以使用与服务器端网站相同的技术编写移动应用，并将其构建为本地移动应用程序。这意味着同一代码库可能被部署到服务器和移动端，因此使用相同的技术、工具和方法将使流程无缝，并节省大量时间、精力和金钱。
另一个非传统领域可以应用 CD 和 DevOps 工作方式的领域完全超出了软件交付的世界范围。
拓展至软件交付之外
迄今为止，本书一直倡导采用持续交付（CD）和 DevOps 来显著改进软件无缝、快速和持续交付的能力。CD 和 DevOps 并不仅限于软件/产品交付。
这种工作方式带来的工具、流程和最佳实践可以扩展到业务的其他领域。当然，某些工具和技术可能需要进行一些调整和更改，但总体而言，重要的是行为、文化和环境因素。
让我们来看看一些超出软件交付范围的领域，可以从 CD 和 DevOps 工作方式中受益，首先是 UX 和设计。
UX 和设计
大多数交付软件的企业——尤其是包含用户界面的软件（网站、桌面应用等）——通常都会有 UX 和/或设计团队参与 UI 和用户体验资产（线框图等）的工作。即使是最敏捷的组织，在处理 UX 和设计时也通常会采用瀑布式的方式。例如，大多数 UX 和设计团队通常独立于软件工程之外。通常的做法是在开发开始之前预先创建资产，这些资产会输入产品积压列表。敏捷软件开发方法在某种程度上解决了这个问题，但大多数方法并未关注密切的协作需求以及文化、行为方式和持续交付的重要性。
您可以（也应该）利用您新获得的经验和技能，改善设计和 UX 资产的构建和交付方式。如果与 UX/设计团队合作，并让他们考虑如何将这些资产拆分为更小的逻辑块（就像您的软件平台一样），并逐步交付，您可能会发现流程变得更加顺畅、高效，减少浪费。在工具方面，有许多成熟的设计/UX 软件解决方案提供协作功能和敏捷交付。
业务流程改进
假设你已经按照本书中的建议，识别并移除了产品交付过程中浪费的部分，现在通过采用 CD 和 DevOps，流程已变得最优和高效，但在实际的产品交付过程之前和/或之后的业务职能和流程开始拖慢了进度。
例如，你可能有一个团队在管理销售线索和业务组合/需求收集，这些信息最终流入产品交付或交付后的实施/支持团队，这两个团队中的一个或两个正在努力跟上快速变化的步伐。
没有理由不能使用本书前面提到的相同技术来解决更广泛的商业问题。作为一个组织，你现在拥有了足够的经验、信心和尊重，能够将那些笨重和复杂的事务简化并高效运作，那么为什么不将这一经验应用到更广泛的领域呢？
回到之前的例子，你应该能够隔离出在产品交付流程之前和之后的业务流程，并进行类似的检查（找出问题所在），解决行为、文化和环境问题，并定义和实施工具、技术和方法，以简化流程并衡量结果。
这样做可以带来更大的商业价值，并使更多业务部门意识到 CD 和 DevOps 工作方式的巨大好处。你的整体业务流程越无缝，整体影响力就越大。如果你能以一种高效的方式捕捉客户需求，你就能够交付他们想要的，并提供他们期望的服务水平。
业务增长
之前，我们讨论了 PaaS 和 SaaS 作为向客户交付软件解决方案的模式，但那我们应该如何看待新的商业机会呢？如果你已经成功实现了自动化配置，或许你应该考虑扩展业务，为客户提供 IaaS——毕竟，你们已经具备了为自己提供这一服务的专业能力，为什么不为客户提供呢？
业务增长的其他领域可能来自于利用目前已在组织内部嵌入的技能和经验。回想一下当初你需要 CD 和 DevOps 领域专家的帮助时。如果你曾经得到过一些帮助，我敢打赌那并不便宜。那么，如果你的客户自己交付软件，但需要帮助开始采用 CD 和 DevOps 呢？你或许能提供这种帮助作为附加价值——也许你应该建议他们购买几本这本书？别怪我试图这么做。
优化的反馈循环
这个短语在敏捷软件交付方法中已经讨论了一段时间。对于那些不熟悉的人，这与减少从用户那里获得反馈的时间有关，反馈的内容是你提供的软件如何运作、如何执行。反馈可以有多种形式——如 NPS（净推荐值）功能、反馈表单、评分——但最重要的是尽早获取这些反馈。如果你已经采用了 CD 和 DevOps，并能够快速交付变化，那么你确实需要及时获取反馈，以确保交付的内容符合预期（和质量标准）。如果等到特性构建完成两三个月后才得到反馈，那就没多大意义了，因为此时世界可能已经发生变化，反馈也就失去了价值。
最简单的优化反馈循环方式是利用组织内已经植入的文化、行为和协作方式，向内部团队成员（或组织中的任何其他人）获取公开、诚实的看法，随着功能和特性的逐步交付。你可以利用在第九章中提到的自助功能，拓展你的机会视野。然而，更大的价值来自于及时从目标终端用户那里获取反馈。
随着 CD 和 DevOps 的采用，使你能够快速、可重复和可靠地交付软件，你应该能够整合工具来收集终端用户的反馈（如之前提到的），如果结合你所嵌入的度量和分析（见第七章，关键指标），将为你提供非常丰富的反馈和相关数据。传统上，这些反馈会由软件工程以外的团队收集和/或整理，而采用 CD 和 DevOps 工作方式后，软件工程团队将习惯于处理这些数据，从而能够更快速地作出反应。
正如我所说，CD 和 DevOps 不仅仅是交付软件；完成工作的方式、协作、公开诚实的环境、基于信任的关系，甚至是使用的语言，都可以并且将有助于振兴和增强任何业务流程。
那我呢？
上述内容只是一些示例，但如果没有人为业务提供帮助并引导其走向正确方向，它们都无法成为现实。无论你喜不喜欢，你将会拥有经验、技能和声誉，成为与 CD 和 DevOps 相关事务的首选人。
现在，你有机会开始一段新的旅程，通过推动只有在成熟且强大的 CD 和 DevOps 文化下才能实现的变化，帮助业务自我发展。
如果这不符合你的兴趣，或许跟上不断变化和扩展的 CD 与 DevOps 领域才是你感兴趣的事情。仅仅追赶新的做事方式、新的工具、新的想法和新的见解就可能占据你大部分的时间和注意力。越来越多的企业意识到，拥有倡导者对他们至关重要——尤其是在软件和产品交付方面。
你可能已经将自己融入了全球 CD 和 DevOps 社区，这将为你提供与他人分享或展示自己经验的机会，更重要的是，将他人的经验和知识带回到你的业务中。也许你甚至可以将这些经验记录下来，发布到公共博客和论坛，甚至出版成书。奇怪的事情时有发生。
无论你选择做什么，你都不会感到无聊，也无法回到以前的状态。你已经学到了一课：有更好的方法，而 CD 和 DevOps 正是其中之一。
你学到了什么？
我一直在提到你的经验、知识和专业技能，但直到你真正经历过采用和实施 CD 与 DevOps 的过程，这些都只是你读到的内容。让我们最后再总结一下我们所讨论的内容：
-
CD 和 DevOps 不仅仅是关于技术选择和工具的，它们的成功很大程度上取决于行为、文化和环境。
-
实施和采用 CD 与 DevOps 是一个过程，刚开始可能看起来漫长而令人生畏，但一旦你迈出了第一步，接着一步步前进，你几乎不会注意到时光的流逝。
-
那些成功采纳了 CD 和 DevOps 的团队很少后悔，或者想要回到以前那个发布版本意味着加班和熬夜的时代——熬夜和周末加班应该和创新以及创造一款杀手级应用或下一个改变世界的技术突破紧密相连。
-
你不必同时采用 CD 和 DevOps，但它们是相互补充的。你不一定要同时做，但你应该认真考虑一下。
-
在需要做出技术选择时，确保你所实施的内容能够增强并补充你当前的工作方式——永远不要为了工具而改变你的工作方式。
-
这可能很庞大且令人害怕，但如果你睁大眼睛开始，你应该能够走下去。CD 和 DevOps 现在已经非常成熟，并且有一个全球社区可以提供帮助和建议，所以不要害怕去寻求支持。
-
不要仅仅因为 CD 或 DevOps 是下一个大家都在做的大趋势，就开始实施它们。你需要有充分的理由来采用这些方法，否则你将无法收获它们的好处，也不会真正相信你所做的事情。
-
虽然我们已经讨论了大量内容，但你不必实施你所阅读的所有内容；选择最适合你和你当前情况的部分，从那里开始——就像你会对待任何一种良好的敏捷方法一样。
-
仅仅因为你能交付软件，并不意味着你就完成了。CD 和 DevOps 是一种工作方式，其中的方法可以应用到其他业务领域和问题上。
-
分享失败和成功，这样你可以从中学习，别人也有机会从你身上学习。
总结
这本书，和所有美好的事物一样，已经结束了。如同多次指出的，我们在这些页面中讨论了相当多的内容。 本书绝不是采用 CD 和 DevOps 的权威著作；它只是基于真实世界的经验和战斗故事，按逻辑顺序整理出的一系列建议。我建议你花些时间通过其他阅读材料和书籍来扩展自己的知识，甚至参加一两场会议。
即使你只是看看需要什么来实施和采纳 CD 与 DevOps 的工作方式，现在你应该对自己和组织将要面临的情况有了更清晰的了解。正如人们所说，“有准备就是有优势”。这不是一段轻松的旅程，但它值得。
所以，去拿一杯热饮，一本笔记本和一支笔；跳回到第二章，理解你当前的痛点，开始绘制出为什么你需要采用 CD 和 DevOps，以及你打算如何去做。
那就去吧。别再读了，赶紧去做！
祝你好运！
第十一章：一些有用的信息
尽管本书提供了一些（希望）有用的信息，但毕竟篇幅有限。因此，我编制了一个额外信息来源的列表，以补充本书内容。我还列出了许多领域专家，他们可能能在你前行的过程中提供进一步的帮助和指导。额外的资源可以在我的网站上找到：www.swartout.co.uk。
接下来列出的并非详尽无遗，但它是一个不错的开始。
工具
以下一些工具在本书中提到过，一些被认为是 CD 和 DevOps 领域的最佳工具：
| 工具 | 描述 | 更多信息在哪里可以找到 |
|---|---|---|
| Jenkins | jenkins.io/ | |
| GIT | 一个免费的开源分布式版本控制系统 | git-scm.com/ |
| GitHub | 一个基于 GIT 的在线托管社区解决方案 | github.com/ |
| Graphite | 一个高度可扩展的实时图表系统，允许你从应用程序内部发布度量数据 | graphiteapp.org/ |
| Tasseo | 一个易于使用的 Graphite 仪表盘 | github.com/obfuscurity/tasseo |
| SonarQube | 一个开源平台，用于管理代码质量 | www.sonarqube.org/ |
| Ganglia | 一个可扩展的分布式监控系统，用于高性能计算系统 | ganglia.sourceforge.net/ |
| Nagios | 一个强大的监控系统，使组织能够在 IT 基础设施问题影响关键业务流程之前识别并解决这些问题 | www.nagios.org/ |
| Puppet Labs | 一个自动化创建和维护 IT 基础设施的工具 | puppet.com/ |
| Chef | 另一个自动化创建和维护 IT 基础设施的工具 | www.chef.io/chef/ |
| Vagrant | 一个使用自动化构建完整开发环境的工具 | www.vagrantup.com/ |
| Docker | 一个开源平台，用于分布式应用程序 | www.docker.com/ |
Kubernetes (kubernetes.io/docs/concepts/overview/what-is-kubernetes/) | 一个开源系统，用于自动化部署、扩展和管理容器化应用程序 | kubernetes.io/ |
| Octopus deploy | 一个非常好的工具，可以用作 CD 管道 | octopus.com/ |
| Yammer | 一种企业私人社交网络（可以把它看作是公司的 Facebook） | www.yammer.com |
| Slack | 一款成熟且广泛使用的协作工具和平台 | slack.com/ |
| IRC | 协作和聊天工具的“祖父” | www.irc.org/ |
| Hubot | 一种可以在大多数聊天室系统中设置的自动化机器人 | hubot.github.com/ |
| Trello | 一种在线 Scrum/Kanban 看板解决方案 | trello.com/ |
人物
以下是一些积极参与敏捷、持续交付和 DevOps 社区的人员：
-
帕特里克·德布瓦（Patrick Debois）被许多 DevOps 社区成员视为 DevOps 的奠基人和 DevOpsDays 运动的创始人（
devopsdays.org/）。这个由志同道合的人组成的小型聚会在 2009 年开始，已经发展成为全球性的聚会。 -
约翰·博查卡卢佩·威利斯（John Botchagalupe Willis）是 DevOps 社区的常驻和著名贡献者，他通过自己真诚的分享智慧方式，激励了许多人。
-
杰兹·汉布尔（Jez Humble）是《持续交付》一书的合著者，许多人在调查或实施持续交付时，将其作为权威参考资料。他还积极为
continuousdelivery.com/上的持续交付博客贡献内容。 -
约翰·奥尔斯帕（John Allspaw）是
www.etsy.com/的运营高级副总裁，他似乎非常理解 DevOps 的价值——尽管他是高级管理层中的一员。 -
加雷斯·拉什格罗夫（Gareth Rushgrove）是自称的网页极客，他似乎总能找到时间制作《DevOps 每周通讯》（http:// devopsweekly.com/），其中充满了有用且富有洞察力的信息。
-
吉恩·金（Gene Kim）是《凤凰计划》的合著者，Tripwire 的创始人及前 CTO。他对 IT 运维、安全性和合规性充满热情，并关注 IT 组织如何从优秀转变为卓越。
-
米切尔·哈希莫托（Mitchell Hashimoto）是自称的 DevOps 工具狂热分子，也是 Vagrant、Packer、Serf、Consul 和 Terraform 的创始人。
-
雷切尔·戴维斯（Rachel Davies）是国际公认的专家，专注于指导团队有效使用敏捷方法，并且在回顾技术和游戏方面拥有丰富的知识。
-
肯·施瓦布尔（Ken Schwaber）和迈克·科恩（Mike Cohn）是 Scrum 和敏捷的“教父”。
-
约翰·克拉普哈姆（John Clapham）是一个全能的好人，也是敏捷/DevOps 的传道者。
-
卡尔·斯科特兰（Karl Scotland）是著名的敏捷教练，专注于精益和敏捷技术。
-
基思·沃森（Keith Watson）在英国的 DevOps 社区中非常有名，我有幸与他紧密合作。
推荐阅读
以下书籍值得一读，即使你出于某种奇怪的原因不打算采用持续交付和/或 DevOps：
| 资源 | 描述 | 链接 |
|---|---|---|
| 敏捷教练 | 如何成为优秀敏捷教练的简介 | pragprog.com/book/sdcoach/agile-coaching |
| 敏捷回顾：让优秀团队更上一层楼 | 一本优秀的书籍，涵盖了运行有效回顾所需的大部分知识 | pragprog.com/book/dlret/agile-retrospectives |
| 持续交付：通过构建、测试和部署自动化实现可靠软件发布 | CD 圣经 | www.amazon.com/dp/0321601912?tag=contindelive-20 |
| 凤凰项目 | 以虚构形式独特呈现的 DevOps 采纳方法，值得一读 | itrevolution.com/books/phoenix-project-devops-book/ |
| 使用 Scrum 进行敏捷产品管理 | 从产品经理的角度看 Scrum 和敏捷 | www.amazon.com/exec/obidos/ASIN/0321605780/mountaingoats-20 |
| 企业与 Scrum | 本书提供了关于采用敏捷方法和工作方式面临的挑战以及解决方法的额外见解 | www.amazon.com/exec/obidos/ASIN/0735623376/mountaingoats-20 |
| 精益创业 | 实际经验和见解，如何转变您的业务、文化和工作方式 | amzn.com/0307887898 |
| 从敏捷回顾中获取价值 | 提供了回顾的良好简介，并列出了一系列游戏/练习 | leanpub.com/gettingvalueoutofagileretrospectives |
回顾游戏
回顾通常是敏捷检视和适应的一部分。如果你了解或正在使用 Scrum 或其他敏捷方法，那么进行回顾不应该是什么新鲜事。如果你以前从未进行过回顾，那么你将有一些有趣的事情要学习。
回顾的目的是回顾一个特定的时间段、项目、发布或者简单的业务变更，并突出表现良好的地方、表现不佳的地方以及需要改进的地方。这个过程传统上可能有些枯燥，因此回顾往往基于游戏（有些人称之为练习，但我更喜欢称其为“游戏”），这鼓励协作、参与，并增添一些乐趣。
就像任何游戏一样，总会有一些需要遵守的规则。这里有一些示例规则：
-
每个会议都应该严格按时限进行
-
每个人都应该有发言的机会和能力积极贡献
-
每个人都应该能够表达自己的观点，但不应该损害他人的权益
-
会议的主持人负责并控制会议的进行
-
本次会议应当产生一些可以作为改进措施推进的具体和实际行动。
就像在第二章中提到的价值流图技术，理解你当前的痛点，你真正需要的工具只有笔、纸、白板（或只是墙面）、一些空间和便签。
我已经向你介绍了时间轴和价值流图。现在让我介绍一下我最喜欢的游戏之一——StoStaKee。
StoStaKee
这个缩写代表停止（stop）、开始（start）和保持（keep）。同样，这是一项以过去事件为重点的互动时间盒练习。这一次，你要求每个人填写便签，记录他们希望停止、开始或继续做的事情，并将其添加到三个栏目（停止、开始和保持）中的一个。然后，你让每个人投票——再次使用便签上的小圆点，标记他们最强烈的看法。同样，你应该鼓励大家进行大量开放且建设性的讨论，确保每个人都理解每个便签的意义。最终目标是确定一系列可以推进的行动。以下图示展示了一个典型的 StoStaKee 板：
一个典型的 StoStaKee 板
之前的示例仅仅是可用资源的一部分，但它们已经一再证明，在调查和，更重要的是，理解一个失败的流程中的问题时，最为有效。
扩展的关键度量
第七章，关键度量，向你介绍了测量你流程中某些方面的多种方法。现在我们将扩展一些这些方法，并更详细地探讨你可以/应该测量的内容。我们将从重新审视代码复杂性及其背后的科学开始。
代码复杂性——一些科学原理
如第七章中提到的，关键度量，在某些情况下，复杂的代码是可以接受的，甚至是必要的；然而，过于复杂的代码可能会给你带来很多问题，特别是在调试时或在你尝试扩展代码以适应更多使用案例时。因此，能够分析一段代码的复杂性应该是有帮助的。
有几种已被记录并认可的源代码复杂性度量方法，但最常被提及的是由 Thomas McCabe 在 1970 年代提出的圈复杂度度量（有时被称为 MCC 或 McCabe 圈复杂度）。这个度量背后有一些现实世界的科学原理，使用正确的工具时，可以基于你的源代码提供量化的度量值。MCC 公式的计算方法如下：
M = E - N + X
在前面的公式中，M是 MCC 度量，E是边数（决策执行后的代码），N是节点数或决策点数（条件语句），X是方法图中的退出数（返回语句）。
代码与注释
在源代码中包含注释会使其更加易读，尤其是在未来，当原作者以外的人需要重构或修复代码时。一些工具可以帮助你衡量和分析代码与注释的比例。
话虽如此，一些软件工程师认为注释没有价值，并认为如果另一个工程师无法读懂代码，那么这个工程师就不称职。这是一种观点；然而，作为一种良好的工程实践和礼貌，应该鼓励在代码中加入注释。
如果你实现了代码与注释的分析功能，那么需要注意的是，一些人可能通过简单地添加以下代码片段等方式规避规则：
/**
* This is a comment because I've been told to include comments in my
* code
* Some sort of code analysis has been implemented and I need to
* include comments to ensure that my code is not highlighted as poor
* quality.
*
* I'm not too sure what the percentage of comments vs code is
* required but if I include lots of this kind of thing the tool will
* ignore my code and I can get on with my day job
*
* In fact this is pretty much a waste of time as whoever is reading
* this should be looking at the code rather than reading comments.
* If you don't understand the code then maybe you shouldn't be trying
* to change it?!?
*/
这可能有些极端，但我相信如果你仔细查看你的代码库，你可能会发现类似的东西隐藏其中。
根据我的经验，另一个添加注释的好理由是，当你需要处理一些非常老旧的代码时（按今天的标准，可能只是几年前的代码），例如调查可能的 bug 或仅仅想了解代码的功能。如果代码是基于过时的设计模式，甚至是基于旧的语言标准（例如旧版本的 Java 或 C#），那么在没有注释的情况下，理解代码的功能可能会非常耗时。
将监控嵌入到软件中
如第七章《关键度量》中所述，重要度量，有几种方法可以在软件本身中嵌入和生成度量。
假设你的软件组件包含用于组件间通信的 API。如果你能扩展这些 API，加入某种健康检查功能，你就可以构建一个工具，简单地调用每个组件并询问它的状态。然后，组件可以返回各种数据，表明其健康状况。虽然这看起来有些复杂，但实际上并不难。
下图概述了这种实现的可能方式：
一个健康检查解决方案，用于从软件组件收集健康状态数据
在这个示例中，我们有一个健康检查工具，它通过 API 调用每个组件并获取数据，这些数据随后可以存储、报告或显示在仪表板上。返回的数据可以根据需要简单或复杂。你所要做的，就是判断每个组件是否正常运行。假设，例如，返回的数据中有一个元素指示软件组件是否能连接到数据库。如果这个值返回为 false，并且你注意到查看数据库服务器上剩余磁盘空间的系统监控显示几乎为零，你就能非常快速地确定问题所在并加以解决。
这种监控方法很好，但依赖于你事先设置一些工具来逐个调用每个组件，收集数据，并以某种可读/可用的形式展示给你。它也受限于 API 的返回结果，或者更准确地说，受限于它们的设计和实现。例如，如果你想扩展数据收集内容，加入像数据库连接数这样的指标，你需要修改 API，重新部署所有组件，然后更新工具来接受这一新的数据元素。这并不是什么大问题，但毕竟是一个问题。然而，真正可能成为大问题的是单点故障——就是工具本身。如果它因为某些原因停止工作，你就会再次陷入盲区，因为你没有数据可查看，更重要的是，你也无法收集数据。
有一种替代方法可以克服这些问题。在这种方法中，组件本身生成你需要的指标，并将数据推送到你的工具中。像 Graphite 这样的工具就能很好地做到这一点。与其扩展 API，你只需实现少量代码；这使得你可以在软件组件内部填充指标数据的“桶”，并将这些桶推送到 Graphite 平台。一旦数据进入 Graphite，你就可以查询数据并生成一些非常有趣的实时图表。Graphite 的另一个优点是，现在有大量工具可以基于 Graphite 数据生成和创建非常有效的图表、图形和仪表板。
扫一扫
895
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
