DevOps 研究与 DORA 评估指标可帮助我们深入了解软件开发和交付流程的性能和效率。这些指标包括部署频率、变更交付时间、变更失败率和平均恢复时间 等方面。DORA 指标对于管理开发团队（从团队领导到 CTO）都很重要，因为这些指标提供了对团队交付软件情况的数据驱动的了解 。这篇文章将带您了解这些指标是如何计算出来的，以及它能告诉我们团队的表现如何。
部署频率
定义
部署频率衡量团队成功将代码发布到生产环境的频率 。
重要性
高部署频率通常是成熟的 CI/CD 流水线以及开发、QA 和运营之间有效协作的标志。它能加快反馈循环并更快地适应市场变化。
请注意，在 DORA 的四个指标中，这是唯一一个越高越好的指标 ，因此为了便于绘制图表，您可能需要计算 1/频率 或类似的反向指标"平均部署间隔时间"，数值越高意味着发布速度越慢。
衡量部署频率
本文中的度量指标按照难度从易到难的顺序排列。部署频率只要求我们知道部署发生在某个时间。在此基础上，我们就可以计算出以日、周或月为单位的柱状图。在 DORA 指标项目 "四个关键"中，计算中的唯一复杂之处是为没有部署的时间段创建行。
评估部署频率
更频繁的部署意味着更快、更敏捷的产品团队。性能级别定义参考以下：
| Elite | High | Medium | Low |
|---|---|---|---|
| 按需部署（每天多次部署） | 每周一次到每月一次部署 | 每周一次至每月一次部署 | 每月一次至每六个月一次部署 |
Source: 2019 Accelerate State of DevOps, Google
变更的交付时间
定义
变更的准备时间是指将提交部署到生产中所需的中位时间 。计算提交和成功部署到生产之间的时间差。取特定时间段内这些值的中位数。
重要性
更短的交付周期通常表明开发和部署流程得到了简化。这表明团队可以快速交付功能、修复或更新。
测量变更的交付时间
在测量变更的交付时间时，时间跨度的起点应该很简单：即拉取请求（PR）的创建或合并时间。要获得提交部署到生产中的时间，我们需要部署频率中的部署信息。同时还要求变更流程的开始包含一个 ID，该 ID 将贯穿部署步骤。这可能看起来像部署上的一个包含拉取请求 ID 的标签。只要 ID 从拉动请求一直延续到部署即可。当我们有了一个 Lead_times 数组，我们就可以将这些交付时间相加，然后除以 {length of time window}. 。
评估变更交付时间
虽然改进审核流程等措施可能会增加这一价值，但一般来说，变更最好还是在提交后不久发生。性能级别定义参考以下：
| Elite | High | Medium | Low |
|---|---|---|---|
| 不足一天 | 一天至一周 | 一周至一个月 | 一个月至六个月 |
Source: 2019 Accelerate State of DevOps, Google
恢复服务的时间
定义
恢复服务所需时间是指发生故障后恢复服务所需的中位时间 。当相关错误或事件报告关闭时，即认为修复工作完成。
重要性
恢复服务的时间越短，说明事故管理越有效，系统越有弹性。它能最大限度地减少停机时间和对终端用户的影响。
如何衡量恢复服务所需的时间
恢复服务的时间是最难衡量的指标。与其他三个完全可以通过源控制来衡量的指标不同，我们需要知道事件开始和结束的时间，因为每个人认定的时间点都会有所偏差。在一些企业中，事件发生时间最终会通过手动输入来计算正常运行时间，但这样的出的结果并不理想。一般来说，有三种方法可以确定事件的时间跨度：
-
综合监测：有时也称为 "pinger"。如果我们向一个设定的 URL 发送一致的请求，我们就能确定事件发生的确切时间范围。这样做的明显弊端是出现假阴性，即综合监控器认为服务没有宕机，因为尽管出现了意外行为，但返回的结果却是 200。在过去几年中，综合监控已经变得更加复杂，因此可以进行更像端到端的测试。
-
记录错误、引发异常或直接监控代码：如果出现内部错误，我们通常就可以认为发生了故障。这种系统既可能将真实的故障误判为无故障（假阴性），也可能在没有故障的时候误报故障（假阳性）。有时函数可能会引发错误，但用户仍能得到满意的响应。这可能需要改变对错误的定义。例如，我们可能有一个用户查询服务，当没有找到匹配记录时就会引发错误。因此在通过日志记录衡量事件时，我们需要改变非关键故障引发标志的级别。
-
通过统计阈值（如响应时间）进行测量 ：从统计性能推断事件是可行。如果响应时间急剧延长，尽管容量有所降低、服务仍在运行，也可将其视为事件。这种方法的最大优点是能密切反映用户的期望。一个网站的加载时间超过 15 秒，即使代码从未出错，或者系统最终总是发送 "良好 "的响应，用户也会认为该网站 "宕机 "了。
除非您目前正在非常密切地测量事件，否则确定恢复服务的时间很可能需要使用可观测性工具来测量新信息。对于刚刚探索测量开发人员速度的小型团队来说，手动记录事件发生时间作为事后分析流程的一部分也许是可行的。
恢复服务时间统计的最终计算结果为: sum([array of all incident lengths])/{number of incidents} .
评估恢复服务的时间
该指标可能已经成为运营团队的核心能力 。性能级别定义参考以下：
| Elite | High | Medium | Low |
|---|---|---|---|
| 1小时以内 | 1天以内 | 1天以内 | 1周至1个月之间 |
Source: 2019 Accelerate State of DevOps, Google
变更失败率
定义
变更失败率是指失败的部署数量与部署总数的比率 。
重要性
变更失败率越低，说明系统越可靠，测试程序越有效。它表明新的变更不太可能带来问题。
如何衡量变更失败率
在默认情况下，变更失败率（如恢复服务的时间）依赖于计算部署和事件，并计算两者之间的比率。这有一些隐含的假设：它假定唯一重要的故障是那些影响用户的故障，并且所有失败的部署都持续了足够长的时间，以至于引发事故。还有一个问题是，这里关键的衡量标准是事件的数量，而不是时间的长短。因此，如果一周内有多次部署，持续 24 小时的故障看起来没什么问题，但 20 次 5 分钟的中断看起来就非常可怕了。如何获得更可靠的变更故障率？有三种可能的途径：
-
定义标准回滚流程。如果您决定事件响应团队始终标记失败的 PR 或始终使用 git rewind，则您可以直接测量更改何时失败。
-
采用金丝雀流程，例如 Argo Rollouts，并将回滚计为失败。
-
定义事件何时算作失败的标准 。例如，根据部署频率设置算作故障的事件的最短长度。
在上述例子中，看起来变更失败率是一个比其他三个 DORA 指标更模糊的统计数据。不过根据 DORA 小组，变更失败率的最终计算方式是 {number of deployments in time window} / {number of failures in time window} 。
评估变更失败率
有时，变更的失败率可能包括较高的误报率。如果您将部署的最后阶段用作测试组件，比如进行最终集成测试，那么如果变更经常失败，可能也没什么好担心的。DORA 小组的标准是：
| Elite | High | Medium | Low |
|---|---|---|---|
| 0-15% | 0-15% | 0-15% | 46-60% |
Source: 2019 Accelerate State of DevOps, Google
特别情况
对于所有这四种指标，都有可能出现指标增量实际上情况并没有那么糟糕的时候。例如，如果我们通过实验提高代码部署的速度和便利性，那么变更失败率就有可能上升。有了更好、更可靠的审查流程，部署时间可能会增加。但是，在所有这些情况下，流程的改进应该会导致其他三个指标的显著改善。这些非常高层次的指标可以帮助更多好的改变，即小的变更会带来速度上的大改善。
DORA 指标能说明什么？
DORA 指标旨在提示开发团队的整体生产力。这些指标衡量的是您的开发人员平台提高开发人员速度的能力；换句话说，是开发人员环境、部署系统和测试在轻松可靠地发布代码方面的效率 。
开发团队可能非常努力地工作并编写出了优秀的代码，但他们的 DORA 指标可能仍然很糟糕，因为测试和部署过程容易出错、工作量大，而且需要大量的人工干预。这种困难的开发人员体验会影响开发人员的整体开发速度，但解决办法并不是让产品工程师更加努力地工作。解决 DORA 指标不佳问题的办法是认真审视内部平台的开发人员体验，并将平台工程作为团队的真正优先事项 。
DORA 关系到开发人员的生产力
如果代码易于测试和发布，并且您的开发环境与生产环境非常相似，那么开发团队就可以减少回滚，更快地将代码发布到生产环境。这种速度不仅仅是技术卓越性的指标，它意味着你的团队在满足用户需求方面做得更好。
了解和实施 DORA 指标不仅是一项技术工作，也是平台工程师和开发团队领导者的一项战略任务 。这些指标提供了从代码提交到部署和事件解决的开发流水线的整体视图。它们是衡量团队敏捷性、运营效率和整体开发速度的关键指标。
虽然只关注开发团队的产出很有诱惑力，但 DORA 指标显示，开发人员的体验同样至关重要 。繁琐、容易出错的部署流程甚至会严重阻碍最有能力的开发团队。投资平台工程和改善开发人员体验是优化这些指标的重要步骤 。请记住，在快节奏的软件开发领域，原地踏步是行不通的。将 DORA 指标作为优先考虑事项，企业将具备良好的适应能力、创新能力和卓越能力。
参考链接: