DevData Talks | 对谈谷歌云 DORA 布道师，像谷歌一样度量 DevOps 表现

本期 DevData Talks 我们请到来自 Google Cloud 谷歌云的 DORA 研究团队的嘉宾 Nathen Harvey 与 Apache DevLake、CNCF DevStream 的海外社区负责人 Maxim 进行对谈。如果您关注 DevOps 的话，也许对这个团队有所耳闻。

DORA 的全称是 DevOps Research and Assessment，是一个致力于 DevOps 调研与研究的独立组织，2018 年加入谷歌云。自 2014 年起，DORA 每年会发布一份 DevOps 行业现状报告，基于对几千位从业者的调研和数据分析，来研究并推广最佳实践，这些最佳实践涵盖了软件开发、部署、交付、安全性、文化和组织变革等多个方面。

Nathen 在 DevOps 领域有丰富的经验，他曾以受访者的身份参与 DORA 发布第一份行业报告。Nathen 加入谷歌云后不久，谷歌云就收购了 DORA 团队，从 2018 年起，Nathen 以布道师的身份，与全球各地的研发团队协作，帮助他们更好地理解并应用 DORA 团队的研究成果。借此，研发团队可以自行评估 DevOps 健康状况，识别问题并优化实践。最终的目的是实现更高效、更快速、更安全的软件交付和运维。

希望本期直播分享，能为你带来关于 DORA 指标的新观点。

什么是 DORA 指标？

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

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

1

部署频率（Deployment Frequency）

一段时间内应用程序部署到生产中的次数，代表研发团队交付价值的频率

2

变更交付周期（Lead Time for Changes）

从代码提交到将代码部署到生产中的时长，代表团队进行代码评审、测试和部署的速度，也部分反映了团队响应用户需求的速度

3

变更失败率（Change Failure Rate）

变更部署到生产后发生故障、导致服务降级的比例，代表团队交付稳定服务的能力

4

服务恢复时间（Time to Restore Service）

生产环境中发生故障到服务恢复的时间，代表团队快速监测、定位、诊断故障，并从故障中快速恢复的能力

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

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

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

完整视频

🎙️关于 DevData Talks

DevData Talks 是专注于研发效能实践经验与方法论的系列分享活动。

我们会每月邀请行业专家分享研发效能提升、数字化管理等相关先进实践与深入思考，持续沉淀优质干货内容。与伙伴们共同探讨研发效能领域的实践与思考，一起交流、学习、成长。

独行者速，众行者远。期待在 DevData Talks 活动中见到你，一起交流、学习、成长。