这些软件开发效率指标对平台工程和开发速度意味着什么。
译自 How to Do DORA Metrics Right 。
DevOps研究与评估(DevOps Research and Assessment， DORA)指标可以洞察软件开发和交付流程的效率。这些指标涵盖部署频率、变更前导时间（前导时间）、变更失败率和恢复平均时间等。
这些指标对任何管理工程团队的人都很重要，从团队负责人到CTO，因为它们可以数据化地了解团队交付软件的效率。我想解释这些指标是如何计算的，以及它们真正反映出我们的团队表现。
部署频率衡量团队成功将代码推送到生产环境的频率。
高部署频率通常意味着成熟的CI/CD流水线和开发、测试和运维之间的良好协作。它可以实现更快的反馈循环和对市场变化的更快适应。
注意四个DORA指标中，这是唯一一个数值越高越好的，因此为了便于绘制，可以计算 1/频率 或类似的反向指标，例如“两次部署间平均时间”，数值越高意味着发布节奏越慢。
本文指标从最简单到最困难排列。部署频率只需要知道一次部署发生的时间。然后可以用日周月等时间段计算直方图。在DORA指标项目的Four Keys中，为没有发生部署的时间段添加行是计算的唯一复杂之处。
很难反对更频繁的部署意味着产品团队更敏捷。绩效水平定义如下:
| 卓越者 | 高绩效者 | 中等绩效者 | 低绩效者 |
|---|---|---|---|
| 按需(每天多次) | 每天至每周之间 | 每周至每月之间 | 每月至每六月之间 |
来源:2019年谷歌DevOps状态报告
变更前导时间是提交被部署到生产的中值时间。计算提交时间和成功部署到生产之间的时间差。在特定时间内取这些时间的中值。
较短的前导时间常表示流水线化的开发和部署过程。它显示团队可以快速交付新功能、修复和更新。
计算变更前导时间的开始时间应该很清晰: 几乎可以确定是拉取请求(PR)创建或合并时间。要得到提交部署到生产的时间，我们需要部署频率的部署信息。我们还需要变更过程开始时有一个ID，这个ID会带到部署步骤。这可能是部署的标签包含PR ID。只要ID从PR带到部署即可。有了一组lead_times后，可以求这些前导时间的和，再除以时间窗口长度。
虽然像改进的评审流程可能会增加此值，但变更发生在提交后越快通常越好。
| 卓越者 | 高绩效者 | 中等绩效者 | 低绩效者 |
|---|---|---|---|
| 少于1天 | 1天到1周 | 1周到1月 | 1月到6月 |
来源:2019年谷歌DevOps状态报告
服务恢复时间是服务失败后恢复服务的中值时间。当相关错误或事件报告被关闭时，视为修复完成。
更短的服务恢复时间表示有效的事件管理和弹性系统。它最大限度减少停机时间和对终端用户的影响。
服务恢复时间是最难计算的指标。与其他三个指标不同，后者可以完全从源代码控制中计算，我们需要知道事件开始和结束时间，这个时间各方面未必达成一致。在一些组织中，为计算正常运行时间，事件时间被手动录入，这不是最佳方案。总体上，确定事件时间跨度有三种方法:
- 合成监控: 也称为“pinger”。如果我们定期向一组 URL 发送请求，可以准确定义事件时间跨度。明显缺点是假阴性，合成监控没发现服务宕机，因为尽管行为异常但返回了 200。近年来合成监控已日益复杂，可以进行更像端到端测试的监控。
- 日志错误、异常抛出或其他直接代码监控: 如果抛出内部错误，通常可以假定发生了事件。该系统会产生假阴性和假阳性: 有时函数的副作用可能抛错但对用户仍是正常响应。这需要改变对错误的定义。例如，可能有用户查询服务在未找到匹配记录时抛错。通过日志计算事件时，需要把非关键失败抛出的错误级别改为提示。
- 统计阈值监控(如响应时间): 可以通过性能统计推断出事件。如果响应时间大幅增加，即使服务仍在工作(虽然能力下降)，也可视为事件。这种方法很好地代表了用户的期望。即使代码从未报错，系统最终也始终返回“正确”响应，对用户来说加载超过15秒的网站就等同“宕机”。但是，这需要更深入的APM监控。
除非您目前已经非常详细地测量事件，否则建立服务恢复时间很可能需要通过可观察性工具测量新信息。对于刚刚开始测量开发速度的小团队，作为事后总结过程的一部分手动记录事件时间可能可行。
服务恢复时间统计最后计算为所有事件时间总和/{事件数}。
这个指标很可能已经是运维团队的核心竞争力，DORA给出的表现水平也很有说服力。
| 卓越者 | 高绩效者 | 中等绩效者 | 低绩效者 |
|---|---|---|---|
| 少于1小时 | 少于1天 | 1天到1周 | 1周到1月 |
来源:2019年谷歌DevOps状态报告
变更失败率是失败部署次数占总部署次数的比率。
较低的变更失败率表示系统更可靠、测试程序更有效。这意味着新变更不太可能引入问题。
在像Four Keys这样的项目中，默认情况下，变更失败率和服务恢复时间都依赖计算部署和事故的数量，并计算两者的比率。这有一些隐含假设: 它假定只有影响用户的失败才重要，并且所有失败部署都会持续足够长时间触发事故。另一个问题是事故数量才是关键指标，而不是事故长度。因此，如果同周有多次部署，24小时宕机看起来不错。但是20次5分钟宕机则看起来糟糕得多。我们如何获得更可靠的变更失败率？有三种可能的方法:
- 定义标准回滚流程。如果事件响应团队总是为失败的PR打标签或始终使用
git rewind，您可以直接测量何时变更失败。 - 采用像Argo Rollouts这样的金丝雀流程，并将回滚计为失败。
- 为何时判定事件“计入”失败定义一个标准。例如，根据部署频率设置判定为失败的最小事件长度。
在这些示例中，变更失败率总是一个感觉不如其他三个DORA指标那么量化。两项性能指标组合的高峰通常意味着可以被“解释为”环境问题。
统计的最终计算是{时间窗口内部署数量}/{时间窗口内失败次数}。
变更失败率可能包括高假阳性: 如果您正在使用部署的最后阶段做测试，如执行最后集成测试，变更失败时有时没必要担心。但是，DORA的标准是:
| 卓越者 | 高绩效者 | 中等绩效者 | 低绩效者 |
|---|---|---|---|
| 0-15% | 0-15% | 0-15% | 46-60% |
来源:2019年谷歌DevOps状态报告
对于所有四个指标，都可以想出指标增量实际是好事的场景。例如，如果我们提高部署代码的速度和便利性，变更失败率可能会增加。随着更好、更可靠的评审流程，部署时间可能会增加。但是，在所有这些场景下，流程改进应该明显改善其他三个指标。这些高层次指标可以帮助识别帕累托法则的益处，即小的变化带来大幅提升速度。
需要认识到，DORA指标旨在反映开发团队的整体效率。这些指标测量开发者平台实现开发速度的能力，也就是开发环境、部署系统和测试对轻松可靠地发布代码的效率。
您的开发团队可能非常努力并编写出色代码，但由于测试和部署流程容易出错、劳动密集且需要大量人工参与，他们的DORA指标仍可能非常糟糕。这种糟糕的开发者体验会损害整体开发速度，但解决方案不是让产品工程师更努力工作。DORA指标不佳的解决方案是认真检查内部平台的开发者体验，并使平台工程成为团队的首要任务。
如果代码易于测试和发布，开发环境与生产环境高度相似，您将有更少回滚和更快的上线流程。这种速度不仅显示技术卓越，也代表敏捷方法的典范，意味着您的团队正在变得更好地满足用户需求。
理解和实施DORA指标不仅是一个技术练习，也是平台工程师和开发团队负责人的战略需求。这些指标为开发流水线提供整体视图，从代码提交到部署和事故解决。它们是团队敏捷性、运营效率和整体开发速度的关键指标。
尽管专注于开发团队产出非常诱人，但DORA指标揭示开发者体验同样重要。笨拙容易出错的部署流程可能会严重阻碍最优秀的开发团队。投资平台工程和改进开发者体验是优化这些指标的关键步骤。
对于希望改善DORA指标的团队，Signadot提供定制解决方案，可以帮助实现更高效流畅的开发流水线。请记住，在软件开发的快速环境中，静止不前不是选项。把DORA指标作为重点，您将做好适应、创新和卓越的准备。