2009 年，受 John Allspaw 和 Paul Hammonds 在 Velocity 上演讲的启发，Patrick Debois 组织了一次名为“DevOps Days”的会议。晚期，公众对 DevOps 持有褒贬不一的认识且大部分企业高层人员对其并不器重。DevOps 本应将技术人员们团结在一起，却难以定义，更难以掂量，因而很难提出令人信服的反对或拥护理由。在这篇文章中，我将从 DORA 指标登程，摸索 DevOps 实际与业务成绩之间的预测分割。
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 衡量标准为何无效？
DORA 指标之所以乏味，是因为它们能促成各种正反馈循环，同时强化速度和品质方面的良好实际。破费更少的状况下，这种组合能够让团队更快地交付品质更好的软件。
部署频率
正如 Chuck Rossi 在 Facebook 工作时所察看到的 “ 如果咱们想要更多变动，就须要进行更多部署 ”。Chuck 面临着进步开发速度的压力。为了提供更多变更，Facebook 的部署变得越来越大、越来越简单。然而，随着部署的减少，其可靠性也大大降低。一旦部署失败，就会造成严重后果。发现问题就像在数据中心海底捞针。Facebook 很难通过扩充部署规模来实现其生产率指标。
通过专一于 从根本上进步部署频率而不是部署规模，Facebook 获得了更大的胜利。他们可能交付更多更改，同时缩小重大部署失败。当呈现问题时，诊断起来更容易，修复速度也更快。他们理解到，生产力是部署频率的函数，而不是部署规模的函数。
为了从根本上进步部署频率，咱们须要对组织层面的交付流程进行不同的思考。如果每次部署都须要两周的测试周期、过于模式的审查流程和 48 小时的停机工夫窗口，咱们就无奈每周执行屡次部署，更不用说每天执行 10 次部署了！
当指标设置为进步部署频率时，咱们就须要理解交付工夫。
变更交付工夫
在 Accelerate 中，交付工夫被定义为开发人员开始某项工作与该工作在生产中交付（并验证）之间的工夫。（他们明确不计算某些谬误修复或性能申请在高优先级 Jira 工单的长尾积压中期待的工夫。）
低绩效公司以月为单位掂量交付工夫，而绩效较高的公司则以小时为单位掂量交付工夫。对于体现不佳的企业来说，他们的大部分漫长的交付工夫都投入在测试、批准和验证上，因而他们天经地义地认为，想要放慢口头就须要在品质或平安方面做出就义。
然而，对于大多数以前没有认真思考过交付工夫的组织来说，通过寻找流程中最长的期待、提早和谬误产生在哪里，而后进行更改或自动化步骤来防止，可能有在交付工夫上取得微小改良。缩小这些问题，通过将大批量的变更合成为更小范畴的、可独立交付的批次，团队将会播种另一个微小的晋升。这样不仅能够更快、更平安地交付，同时也能更容易地进行调整，且不会影响以后的进度。
继续较短的交付工夫 并不意味着仓促开发工作或跳过测试阶段的后果 ，而是 更智能的团队单干和优先思考的自动化工作的后果，使代码失去及时审查、更快地发现错误、提高质量、更平安的部署和更好的敏捷性。
均匀复原工夫 (MTTR)
了解 MTTR 的最佳办法是将其与均匀故障间隔时间（Mean Time Between Failure, MTBF）进行比照。对 MTTR 的关注意味着咱们 更关怀缩小故障所带来的影响，而不是完全避免故障的产生。相比防止故障，咱们更重视故障时复原的能力。咱们还意识到显著升高部署频率和交付工夫的平安动作也该当被防止，因为这些动作同样会产生系统性危险，即更长的交付工夫或更高的部署危险等。
如果咱们的故障能够在几分钟内修复，且这些故障只影响一小部分用户，同时所有数据都能够疾速复原，那呈现故障就变得没那么可怕了。因而咱们该当把更多精力放在复原故障的能力上，而不是将一味捕获每一个谬误和故障。
当咱们展现 MTTR（而非 MTBF）方面的继续改良时，就更容易省去不必要的模式流程。这能够无效缩短交付工夫、进步部署频率、放大部署规模，并带来更平安的部署和更好的 MTTR。
变更失败率
测试是 DevOps 中常常被忘记的局部。在没有适当测试的状况下，继续部署是一种比以前更快地将谬误部署到生产环境的办法。
尽管咱们对 MTTR 而非 MTBF 的关注表明咱们承受故障的产生，但这并不意味着咱们会在故障产生时感到高兴。DevOps 是对于构建品质，通过小规模且频繁的部署，让部署过程放弃安稳。
但在测试环节，咱们须要疾速进行查看，因而须要投资于自动化单元测试、集成测试、试运行部署和冒烟测试。在这个过程中，着重点在于频繁、疾速、小规模的代码审查，而不是流于形式的迟缓、批量审查。须要留神的是，只管咱们总是试图缩小部署失败的可能性，与试图缩小部署失败的总数并不相同，总是放心部署失败的总数是否减少会扩散注意力。
请参考以下信息，思考哪家公司提供更高质量的产品：
B 公司的失败频率显著更高。然而，它可能被用户认为是更牢靠的服务。A 公司的停机工夫大概是原来的 3 倍，这将为用户带来微小影响和损失。
通过将对 MTTR（缩小故障影响）的关注与进步部署可靠性（由变更故障率定义）的共同努力相结合，即使部署失败的总数减少，依然能够从根本上进步部署频率，同时提高质量。
参考链接：
https://www.devopsdigest.com/dora-metrics-the-predictive-link…