什么是 DORA 指标？

DORA 指标由 Google 的 DevOps 研究与评估 (DORA) 团队开发，为软件交付和 DevOps 成熟度提供了行业标准基准。

其核心，DORA 指标关注两个维度：

1. 吞吐量：DevOps 团队交付软件的速度。
   
   
2. 稳定性：DevOps 团队交付软件的可靠性和安全性。

面向吞吐量的指标揭示代码变更在软件开发生命周期中（从构思到生产）流转的速度，而面向稳定性的指标则显示部署发生故障的频率以及团队恢复的速度。两者结合，为企业领导者和 DevOps 团队提供了基于证据的、可复现的 DevOps 绩效洞见。企业不必依赖主观的绩效衡量标准或虚荣指标，例如“编写的代码行数”或“工作时长”。

跟踪 DORA 指标使 DevOps 团队能够了解自己与行业公认的绩效等级（低、中、高和精英级）相比处于什么水平，以及是否与整个企业的目标保持一致。它帮助企业客观地识别持续集成/持续交付 (CI/CD) 管道、软件测试和事件管理中的瓶颈。  

DORA 指标还使领导层更容易向业务利益相关者传达工程部门的健康状况，并证明对有助于优化 DevOps 实践的高级自动化、可观测性和站点可靠性工程 (SRE) 工具的投资是合理的。

在 DevOps 中，DORA 指的是 DevOps 研究与评估团队，该团队普及了适用于软件开发团队的组织绩效指标。

DORA 现在隶属于 Google Cloud，最初是一个独立的研究项目，研究软件交付流程如何影响业务成果。DORA 团队致力于回答一个关键问题：是什么让高绩效的软件团队与低绩效者不同？

他们从数千个团队收集调查和遥测数据，发现一小部分与交付和运维相关的指标可以强有力地预测整体绩效。这些指标即部署频率、变更前置时间、变更失败率和故障部署恢复时间。结果还证明，发布速度和软件稳定性可以齐头并进，因此团队不必优先考虑其中一个而牺牲另一个。

最终，这四个指标成为了标准的 DORA 指标，为软件交付绩效提供了行业标准基准。2024 年，DORA 研究团队在该框架中增加了第五个指标——部署返工率。  

五大 DORA 指标可分为两个总体类别：“吞吐量”和“稳定性”。

吞吐量指标包括部署频率、变更前置时间和故障部署恢复时间，它们共同描述了一个应用程序能够处理多少变更以及变更流入生产环境的速度。

稳定性指标包括变更失败率和部署返工率，它们衡量导致故障的部署比例，以及非计划或由生产事件驱动的部署所占的比例。

部署频率衡量一个团队在一段时间内（每天、每周、每月）成功将代码部署到生产环境的频率。

部署频率是软件团队交付流程敏捷性和信心的最明显信号之一。当一个团队每天多次将代码部署到生产环境时，通常意味着自动化的构建、测试和部署流程运行顺畅，并且有完善的可观测性机制到位。这些条件使开发团队能够无需担心破坏系统而发布软件。

相反，每月只部署一次（甚至更少）的团队通常依赖于长期存在的代码分支、手动测试、复杂的审批协议和大型发布日。所有这些因素都会拖慢用户反馈周期，并增加修复缺陷的成本。

值得注意的是，如果高部署频率伴随着频繁的停机或回滚，那么它并不是健康的标志。高绩效团队将高部署频率与强大的质量保障实践（多层次的自动化测试、分阶段部署、功能标志和实时监控实践）结合起来，这些实践有助于团队频繁交付，同时最大限度地降低用户风险。

从领导层的角度来看，跟踪部署频率随时间的变化可以揭示软件交付管道中的瓶颈。例如，在引入新的审批委员会后部署频率下降，可能表明该流程过于严苛。相反，部署频率稳步提高，同时可靠性指标改善，则有力地表明对 CI/CD 管道和 DevOps 实践的投资正在取得回报。

变更前置时间（也称更改前置时间）衡量代码变更在提交到版本控制系统的主代码分支后，到达部署并在生产环境中成功运行所需的时间。

该端到端的时间窗口包含了所有环节，包括构建时间、测试执行、代码审查、审批、流水线阶段和实际部署。它揭示了一个系统将决策转化为对最终用户有形的变更的速度。

当前置时间很短（不到一小时）时，组织可以近乎实时地响应事件。例如，如果安全团队标记了一个漏洞，工程团队可以实施修复，通过自动化检查进行验证，并在极短的时间内将其上线。这种快速的反馈循环将开发工作直接与业务成果联系起来，因为团队可以快速衡量变更的影响并相应地进行调整。

缩短变更前置时间几乎总是需要 DevOps 团队自动化并简化交付管道。该过程通常包括投资于持续集成 (CI) 工具，以便每次提交都能快速构建和测试，并简化审批流程，使审批与开发工作流相集成。  

故障部署恢复时间，也称为平均恢复时间 (MTTR) 或平均服务恢复时间，衡量在发生与部署相关的故障后，将服务恢复到正常所需的时间。

服务修复可能需要开发人员回滚有问题的变更、部署热修复（在正常发布周期之外发布的紧急小代码变更），或以其他方式减轻问题的影响，以便用户能够再次正常使用系统。

当恢复时间很短（几分钟之内）时，通常意味着多个 DevOps 组件正在良好地协同工作。

可观测性强。实时的遥测数据——指标、日志和追踪——被充分聚合，并集中呈现在仪表板中。事件能被快速（通常是自动）检测到，无需等待用户投诉。

告警经过适当调整，确保工程师能及时收到通知，但不会被噪音淹没。

DevOps 团队依赖运行手册（执行技术任务的逐步战术指南）、应急预案（描述团队应如何响应某种情况的高层次战略指南）和文档化的回滚程序。这些框架消除了在中断期间决定该做什么的猜测工作。

较长的恢复时间（数小时甚至数天）通常表明运维实践薄弱。检测可能很差，导致生产故障一直持续到客户报告为止。诊断过程缓慢，因为数据收集分散、错误消息不清晰，或者团队对系统在故障模式下的行为缺乏共同理解。在这样的环境中，每个事件都变成了高压力、高风险的事件，而不是一个有明确解决规程的直接解决问题的过程。

当与其他 DORA 指标结合使用时，较低的故障部署恢复时间有助于确保即使部署偶尔失败，故障也能被控制住，且响应时间很短。

变更失败率 (CFR) 是一项“交付质量”指标，它告诉 DevOps 团队部署在生产环境中失败的频率。任何有问题的生产部署，只要迫使团队立即介入（而不是等待下一个计划发布来解决问题），都被视为“失败”的部署。

跟踪 CFR 随时间的变化有助于团队了解他们交付变更的可靠性，并作为对优先考虑速度的吞吐量指标（部署频率、变更前置时间）的平衡。

CFR 通常以百分比表示，计算方法是将失败部署的次数除以同期总部署次数，然后乘以 100。

低变更失败率表明团队正在交付的变更在生产环境中通常能按预期运行。当 CFR 低且稳定时，团队可以安全地增加部署频率并缩短变更前置时间，而不会损害用户体验。

然而，高变更失败率表明有太多变更正在破坏系统的稳定性。原因可能包括不完整或不稳定的测试、与生产环境存在差异的预发布和测试环境、部署规模过大，或者监控和告警缓慢。高 CFR 表明组织应优先考虑更小、更增量的变更和更安全的部署实践（例如金丝雀发布，即新应用程序或功能在向更广泛用户发布之前，先推送给一小部分用户），以减少演变成生产事件的变更。

部署返工率是一项稳定性指标，衡量团队部署中有多大比例是返工。“返工”指因生产环境中用户可见的缺陷或事件而触发的任何部署，并且这些部署不属于原计划的发布序列。

部署返工率通过让被动性工作变得可见，对原有的四个 DORA 指标形成了补充。它揭示了团队有多少开发精力花在了清理过去的错误上，而不是推动产品前进。

低返工率通常表明 DevOps 团队在大多数问题到达最终用户之前就将其捕获，并将大部分时间花在创造价值的工作上（计划内的优化和重构）。高返工率意味着团队花费了太多时间在救火任务上。

当与其他关键指标结合使用时，返工率尤其有价值。例如，如果一个团队部署频率高且返工率低，这表明该团队在快速交付新的软件迭代的同时没有牺牲质量。但如果团队的部署频率高，同时返工率也高，则表明他们虽然交付了大量代码，但也花费了大量时间来修复这些代码。

重要的是，非零的返工率是正常的（通常也是健康的）。即使最好的开发团队也会犯错，构建良好的软件应用程序随着时间的推移仍然需要改进和功能更新。目标不是达到 0% 的返工率，而是将返工率控制在所有部署中一个小且可预测的比例内。

对于每个 DORA 指标，团队会被划入四个绩效等级之一——精英、高、中或低——每个等级都基于该指标的既定阈值。阈值如下：

由于部署返工率是一项较新的指标，它还没有既定的阈值或绩效等级。然而，许多企业和 DevOps 团队会追踪自己的返工基线，并致力于使其随时间推移呈下降趋势。将返工率数据与变更失败率和其他可靠性指标结合使用，有助于团队改善部署返工率，而不会仅凭单一数字就过度纠正。 

DORA 指标支持更广泛的 DevOps 软件开发方法，该方法优先考虑应用程序开发和运维职能中多学科团队之间的持续协作。DevOps 环境的成功程度，取决于构成这些环境的团队。

DORA 指标使企业能够根据与更广泛的价值流和业务成果紧密相连的标准，量化团队绩效。例如，高绩效者和精英绩效者更有可能达成盈利、上市时间和客户满意度目标。

DevOps 文化的另一个特点是，软件交付相关方承诺自由沟通并共担责任，所有各方齐心协力构建高质量软件并加速产品创新。因此，许多组织利用 DORA 指标来建立持续改进的反馈循环。指标衡量每个团队的绩效，团队可以基于衡量结果讨论改进机会，尝试新方法，然后重新衡量绩效，以了解哪些改变真正改善了交付实践。

重要的是，DORA 指标是诊断性的，而非惩罚性的。它们有助于揭示开发流程中的系统模式，而不是聚焦于单个开发人员的工作。