2009 年，受 John Allspaw 和 Paul Hammonds 在 Velocity 上演讲的启发，Patrick Debois 组织了一次名为“DevOps Days”的会议。早期，公众对 DevOps 持有褒贬不一的看法且大部分企业高层人员对其并不重视。DevOps 本应将技术人员们团结在一起，却难以定义，更难以衡量，因此很难提出令人信服的支持或反对理由。在这篇文章中，我将从 DORA 指标出发，探索 DevOps 实践与业务成果之间的预测联系。
2012 年，Alanna Brown 开始编写年度《DevOps 现状报告》。后来与 Gene Kim、Nicole Forsgren 和 Jez Humble 组成了一个强大的团队。Nicole Forsgren 是一位具有丰富研究资历的博士，她领导了 2013 年至 2017 年的研究工作。每年，该团队都会对全球数万名不同工作角色和行业领域的技术人员进行调查。他们检查结果、寻找结论、并公布数据和他们的研究成果。他们的研究结论常常受到很多人的关注。
为了了解为什么有些团队的表现比其他团队更好，首先需要一个衡量 IT 团队“绩效”的标准。DORA 小组讨论了各种传统指标（例如代码行数、故事点和利用率等）所面临的挑战，发现仅根据个人或团队投入的工作来定义他们的绩效是有问题的。
因此需要选择关注结果而不是产出。当他们这样做的时候，他们注意到了 4 个特定指标的独特之处，这 4 个指标涵盖了绩效和稳定性的平衡。这些指标被称为 "DORA 指标"。
部署频率（Deployment frequency）
变更交付时间（Lead time for changes）
平均恢复时间 (Mean Time to Recovery, MTTR)
更改失败率 (Change failure rate)
当团队表现更好时，特别是在这些指标方面，他们看到了独特的、统计上显著的、可预测的业务成果改善，包括：
盈利能力（profitability）
市场份额（market share）
生产力（productivity）
这种联系不仅存在于 "科技公司"（即以软件产品著称的公司），所有业务领域都是如此。到 2018 年，高绩效的技术团队为每个企业带来了竞争优势。更重要的是，DORA 继续讨论了其他 "非营利 "组织，在这些组织中，积极成果并不完全由银行存款余额决定。他们再次发现，DORA 指标是预测成功的可靠指标。
DORA 指标之所以有趣，是因为它们能促进各种正反馈循环，同时强化速度和质量方面的良好实践。花费更少的情况下，这种组合可以让团队更快地交付质量更好的软件。
正如 Chuck Rossi 在 Facebook 工作时所观察到的 "如果我们想要更多变化，就需要进行更多部署"。Chuck 面临着提高开发速度的压力。为了提供更多变更，Facebook 的部署变得越来越大、越来越复杂。然而，随着部署的增加，其可靠性也大大降低。一旦部署失败，就会造成严重后果。发现问题就像在数据中心大海捞针。Facebook 很难通过扩大部署规模来实现其生产率目标。
通过专注于从根本上提高部署频率而不是部署规模，Facebook 取得了更大的成功。他们能够交付更多更改，同时减少重大部署失败。当出现问题时，诊断起来更容易，修复速度也更快。他们了解到，生产力是部署频率的函数，而不是部署规模的函数。
为了从根本上提高部署频率，我们需要对组织层面的交付流程进行不同的思考。如果每次部署都需要两周的测试周期、过于形式的审查流程和 48 小时的停机时间窗口，我们就无法每周执行多次部署，更不用说每天执行 10 次部署了！
当目标设置为提高部署频率时，我们就需要了解交付时间。
在 Accelerate 中，交付时间被定义为开发人员开始某项工作与该工作在生产中交付（并验证）之间的时间。（他们明确不计算某些错误修复或功能请求在高优先级 Jira 工单的长尾积压中等待的时间。）
低绩效公司以月为单位衡量交付时间，而绩效较高的公司则以小时为单位衡量交付时间。对于表现不佳的企业来说，他们的大部分漫长的交付时间都投入在测试、批准和验证上，因此他们理所当然地认为，想要加快行动就需要在质量或安全方面做出牺牲。
然而，对于大多数以前没有认真考虑过交付时间的组织来说，通过寻找流程中最长的等待、延迟和错误发生在哪里，然后进行更改或自动化步骤来避免，能够有在交付时间上获得巨大改进。减少这些问题，通过将大批量的变更分解为更小范围的、可独立交付的批次，团队将会收获另一个巨大的提升。这样不仅可以更快、更安全地交付，同时也能更容易地进行调整，且不会影响当前的进度。
持续较短的交付时间并不意味着仓促开发工作或跳过测试阶段的结果，而是更智能的团队合作和优先考虑的自动化工作的结果，使代码得到及时审查、更快地发现错误、提高质量、更安全的部署和更好的敏捷性。
理解 MTTR 的最佳方法是将其与平均故障间隔时间（Mean Time Between Failure, MTBF）进行对比。对 MTTR 的关注意味着我们更关心减少故障所带来的影响，而不是完全避免故障的发生。相比避免故障，我们更注重故障时恢复的能力。我们还意识到显著降低部署频率和交付时间的安全举措也应当被避免，因为这些举措同样会产生系统性风险，即更长的交付时间或更高的部署风险等。
如果我们的故障可以在几分钟内修复，且这些故障只影响一小部分用户，同时所有数据都可以快速恢复，那出现故障就变得没那么可怕了。因此我们应当把更多精力放在恢复故障的能力上，而不是将一味捕捉每一个错误和故障。
当我们展示 MTTR（而非 MTBF）方面的持续改进时，就更容易省去不必要的形式流程。这可以有效缩短交付时间、提高部署频率、缩小部署规模，并带来更安全的部署和更好的 MTTR。
测试是 DevOps 中经常被遗忘的部分。在没有适当测试的情况下，持续部署是一种比以前更快地将错误部署到生产环境的方法。
虽然我们对 MTTR 而非 MTBF 的关注表明我们接受故障的发生，但这并不意味着我们会在故障发生时感到高兴。DevOps 是关于构建质量，通过小规模且频繁的部署，让部署过程保持平稳。
但在测试环节，我们需要快速进行检查，因此需要投资于自动化单元测试、集成测试、试运行部署和冒烟测试。在这个过程中，着重点在于频繁、快速、小规模的代码审查，而不是流于形式的缓慢、批量审查。需要注意的是，尽管我们总是试图减少部署失败的可能性，与试图减少部署失败的总数并不相同，总是担心部署失败的总数是否增加会分散注意力。
请参考以下信息，考虑哪家公司提供更高质量的产品：
B 公司的失败频率明显更高。然而，它可能被用户认为是更可靠的服务。A 公司的停机时间大约是原来的 3 倍，这将为用户带来巨大影响和损失。
通过将对 MTTR（减少故障影响）的关注与提高部署可靠性（由变更故障率定义）的共同努力相结合，即便部署失败的总数增加，仍然可以从根本上提高部署频率，同时提高质量。