1.7 结论

现在你面临一个选择。是继续单枪匹马，手握舵柄，尽自己最大的能力，独自指挥这艘架构巨轮，还是选择通过团队协作充分发挥各自的优势。你可以把手从舵柄上移开，循序渐进地利用四个关键指标解锁对话和行动，慢慢地朝着团队的共同目标—实现更加可测试、解耦、容错、云原生、可运行和可观测的架构。

这就是将四个关键指标置于最有价值的架构指标之列的原因。我希望你使用它们，与你的合作伙伴一起，共同交付你所见过的最好的架构。

---

[1] 原版书名为Thinking in Systems：A Primer，由Chelsea Green Publishing于2008年出版。

[2] 这里不需要代码被修复。我们在这里考虑的是服务恢复，因此自动故障转移等完全可以作为计时的截止点。

[3] 事实上，这是微软希望你采用的模式。

[4] CAB代表“变革顾问委员会”（change-advisory board）。最著名的例子是Gene Kim、Kevin Behr和 George Spafford所著的经典著作《凤凰项目》（The Phoenix Project，IT Revolution Press，2018）中提及的定期开会批准代码和配置发布的小组。

[5] 特别是如果你有长期存在的分支或永远无法结束的拉取请求时，我打赌你是知道这些的，并且它们也不难单独量化。

[6] 查看文档（https://oreil.ly/L5cs0）了解所有你想知道的基于主干开发的一切。查看极限编程（https://oreil.ly/pGAfY）了解结对编程最初的定义。

[7] 如果这让你认为拥有多个独立的流水线（每个制品一个）是个好主意，恭喜你，你已经回想起了微服务的关键原则之一——独立可部署性。如果这让你想起单体，那么请记住微服务带来的其他好处，我们将在本章的最后介绍相关内容。

[8] 有时会出现这样的问题：“关于基础设施的构建该怎么办？”我看到它们已经被包含在“四个关键指标”的计算中了，但如果它们没有被包含在内，我也不会感到不安。至于因定时而非变更触发的流水线，不要统计它们。它们不会导致部署任务，因为任何变更都没发生。

[9] 还是那句话，可能有人会指出，开启故障单的时间和服务故障第一次出现的时间不一样。这没错。也许你想把监控系统和故障单创建操作关联起来，以解决这个问题。假如你有办法的话，恭喜你：你也许已经正处于采纳这四个关键指标的“微调”阶段了。大多数人只会憧憬这种精度（至少在刚开始的时候），所以考虑到这一点，只要从人工创建故障单开始就已经足够了。

[10] 确保对自己诚实：收集所有应该收集的构建活动，不要挑三拣四。数字要尽可能准确，如果存在猜测成分，对猜测的准确程度也要有所估算。

[11] 记住！对平均值再次计算平均值一定会引入问题，所以最好避免这种情况。由于我们每日都计算总数，因此在我们指标的背后，是一张漂亮的图表，我们稍后会讲到。

[12] 未解决的故障并不存在“已解决”时间戳。

[13] 如果存在计算错误，信息透明甚至可能会带来一些关于错误的上报—我对这四个关键指标的一些了解就是这样产生的。

[14] 感谢Matthew Skelton和Manuel Pais提出“最小可行平台”（minimal viable platform）的想法，它对MVD概念的形成有启发作用。

[15] 参见Accelerate中的图2-2和图2-3，以及最新DORA State of DevOps报告（https://oreil.ly/IetZp）中的表格。

[16] 根据2021 Accelerate State of DevOps报告（https://cloud.google.com/blog/products/devops-sre/an-nouncing-dora-2021-accelerate-state-of-devops-report）中的数据（参考2021年的报告是因为之后的报告中已删去了“精英”级别），少于一小时的前置时间应属于“精英”级别。

[17] 不难发现，这里存在一次被阻塞的构建。对于“平均”这个词，我们用了average，而不是mean（有刻薄之意），让它更平易近人。

[18] 有时我们会看到多次失败，但这种情况是非常少见的。

[19] 根据我的经验，这也是你们关注的重点。

[20] ADR一词最早是由Michael Nygard提出的。

[21] 这让QA和操作人员非常高兴。我经常看到QA 使用这四个关键指标来驱动变更，就像架构师一样。