在这篇文章中，我们将介绍 DevOps 四个关键指标——DORA 指标是什么，其度量难点，以及如何基于开源工具快速实现 DORA 指标的持续追踪。如果你熟悉 DORA 指标，可以直接跳到本文第二部分。

什么是 DORA 指标？

DORA 的全称是 DevOps Research and Assessment，是一个致力于 DevOps 调研与研究的组织，2018 年加入 Google Cloud。自 2014 年起，DORA 每年会发布一份行业报告，基于对数千名从业者的调研，分析高效能团队与低效能团队在 DevOps 实践上的差异。

高效能团队如何定义？可能每个人、每个组织都有不同见解。DORA 的做法是将研发团队表现分为三个方面：软件交付表现、运行稳定性表现和组织业绩表现。在软件交付表现方面，提炼出四个关键的结果性指标进行概括，这就是著名的 DORA 指标。DORA 指标包括

• 部署频率（Deployment Frequency）：一段时间内应用程序部署到生产中的次数，代表研发团队交付价值的频率
• 变更交付周期（Lead Time for Changes）：从代码提交到将代码部署到生产中的时长，代表团队进行代码评审、测试和部署的速度，也部分反映了团队响应用户需求的速度
• 变更失败率（Change Failure Rate）：变更部署到生产后发生故障、导致服务降级的比例，代表团队交付稳定服务的能力
• 服务恢复时间（Time to Restore Service）：生产环境中发生故障到服务恢复的时间，代表团队快速监测、定位、诊断故障，并从故障中快速恢复的能力

在以上四个指标中，部署频率和变更交付周期指标主要度量的是 DevOps 交付表现中的产能维度（Throughput），而变更失败率和服务恢复时间指标主要度量的是稳定性维度（Stablity）。

同时度量产能与稳定性，一方面能使二者相互制衡，避免大量低质量变更损害用户体验，或避免严守质量拖累交付效率；另一方面，验证优秀的实践能够同时改善产能与稳定性，而不需要研发团队做出取舍，例如小批次的发布策略不仅直接提高部署频率，一旦故障发生也能快速定位，有利于缩短服务恢复时间。

DORA 指标如何指导具体的实践改进？DORA 调研报告贴心地提供了一系列基准值，分为精英团队（Elite）、高效能团队（High）、中等效能团队（Medium）和低效能团队（Low）。研发团队可以参考业界水平对号入座，从而找到最关键的改进项。在改进的同时，团队可以持续度量 DORA 指标，验证改进措施的有效性。

2021年DORA报告中的各级别团队表现

度量 DORA 指标，难在哪？

DORA 指标并不是什么新鲜事物，指标只有四个，公式也非常简单明了。但对于许多研发团队来说，要在日常工作中持续自动化地度量 DORA 指标，依然难度不小。

困难在于，DORA 指标度量依赖于变更、部署、故障等研发数据，而许多研发团队并没有获取研发数据的可靠基础设施。原因在于：

首先，研发过程本身是复杂的，通常涉及多个流程、活动和工具，研发过程数据也常常散落在复杂的工具链中（包括代码托管、事务管理、CI/CD 工具等），导致数据难以提取，耗时费力。如果研发团队同时使用同类型的多个研发工具，可能还需要处理不一致的数据概念，比如同时使用 GitHub 和 GitLab 的团队，就需要统一 Pull Request 和 Merge Request 两个概念。

其次，不同的组织和项目的研发和交付过程不同，可能会采用不同的数据定义和计算方法。比如，有的团队使用 Git Tag 或某特定分支的合并来识别一次部署，有的团队使用 CI/CD 工具中的事件来识别一次部署。这样非标准化的定义与计算方法，也使得研发数据难以治理，进而给数据的可靠性打了一个问号。

市面上 DORA 指标工具之多，也从侧面印证了这仅仅四个指标的度量并非易事。如果某个团队考虑度量 DORA ，他们可能需要对比市面上的数十个工具，眼花缭乱中找到恰好能接入当前研发工具链，恰好变更、部署、故障的定义均符合团队实践的那一个。

数据源和指标计算方式各有差异，导致市面上的DORA度量工具多而分散

这也正是我们建设并开源了研发数据平台 Apache DevLake 的原因。我们认为，无论是研发工具链的接入以及研发数据的定义，都应当保留一定程度的开放和灵活性。团队根据实际需求收集并治理研发数据，保障数据可靠，在此基础上度量 DORA 指标，并获得有价值的改进洞见。

开源的模式降低了研发数据的治理成本，同时也吸引更多团队参与建设，不断丰富可接入的数据源和数据计算方法，让平台越用越好用。

基于 Apache DevLake 快速度量 DORA 指标

正如上文所说，度量 DORA 指标前，你需要先拿到三个研发数据：

• 变更：大多数团队是通过 Pull Requet 来识别一次变更，因此变更的数据将来自代码托管工具，DevLake目前已支持 GitHub、GitLab 和 BitBucket
• 部署：部署的数据来自 CI/CD工具。DevLake 目前已支持 Jenkins、GitHub Actions 和 GitLab CI，CircleCI 正在开发中
• 故障：故障的数据可以来自事务管理工具中的某类型事务，例如 Crash或 Incident；也可以直接来自监控工具，DevLake 将很快支持 PagerDuty 和 Sentry

除了手动触发数据收集，DevLake 也支持自动定时拉取研发数据，方便研发团队低门槛地使用 DORA 指标，持续追踪效能表现。

如果 DevLake 尚未支持你的研发工具，你依然可以使用 webhook 将事件数据推送到 DevLake。

接下来，只需四步，就可以在 DevLake 中看到 DORA 指标和数据看板：

1. 配置 DevLake：使用 Docker Compose、Kubernetes、Helm 或 Temporal
2. 收集数据：借助 DevLake 插件接入研发工具链，不需要复杂的集成与适配，就可以把需求、开发、测试、交付各个环节研发数据归于一处
3. 数据看板开箱即用：DevLake 预置了许多指标和数据看板并通过 Grafana 来呈现，其中包括 DORA 指标和相应看板
4. 自定义：如果你还需要进一步分析，例如探查某个 DORA 指标异常的原因，只需要几行 SQL 查询就可以创建新的指标或数据看板