# 《Accelerate》把“部署太慢”变成四个可核对的数字

> 这本基于四年 DORA 研究的 2018 年著作，训练 FDE 驻场的第一项功课：先量客户的交付能力，再提方案。

原文: https://fdetimes.net/zh/books-courses/accelerate-dora-four-key-metrics/

很多客户会议都卡在同一句抱怨上：“我们团队部署太慢了。”跟谁比慢？慢多少？会议室里没人拿得出数字。《Accelerate》教的，就是把这句抱怨变成四个人人都能核对的数字。

本书作者是 Nicole Forsgren、Jez Humble 和 Gene Kim。副标题承诺用科学方法研究精益（Lean）与 DevOps，帮助组织建设并扩展高绩效技术团队。IT Revolution 于 2018 年 3 月 27 日出版此书，该书获得了 Shingo Publication Award。

对前线部署工程师（FDE）而言，这本书的价值不在于出版多久，而在于它培养的能力：在提出任何建议之前，先衡量一个组织的软件交付能力。到了客户现场，第一个问题永远是：对方团队现在处在什么水平？

## 这本书建立在什么数据之上？

据 IT Revolution 介绍，本书是四年研究的成果，数据来自为 State of DevOps 报告收集的资料。出版方承诺，读者将学会如何衡量团队表现，以及该投资哪些能力。

这些数字背后是 DORA（DevOps 研究与评估），一个按学术标准运作的多年期研究项目。早在 2015 年的报告中，DORA 就发现，高绩效 IT 组织在四项关键软件交付指标上远远领先竞争对手。《Accelerate》把这些发现写成了一本书。

## 四个数字，放到真实客户身上试一试

Google Cloud 在介绍 DORA 的“Four Keys”时，对这些指标的定义如下。部署频率（Deployment Frequency）指组织成功发布到生产环境的频率。变更前置时间（Lead Time for Changes）指一次提交进入生产环境所需的时间。

变更失败率（Change Failure Rate）指在生产环境引发故障的部署所占的百分比。服务恢复时间（Time to Restore Service），也称平均恢复时间（MTTR），指组织从生产故障中恢复所需的时间。

假设你刚到一家物流公司。30 天里，他们的团队成功完成了 20 次生产部署。部署频率就是每 30 天 20 次，平均每一天半发布一次。

这 20 次里有 3 次引发了事故，所以变更失败率是 3/20，即 15%。前置时间不要只看某一次提交，而要逐个变更计算，再取中位数。假设中位数约为四天，也就是说，周一上午写下的一次典型提交，要到周五下午才能到达客户手里。

恢复时间也是同样的算法。三次事故分别用了 30 分钟、1 小时和 6 小时。中位数是 1 小时，平均值是 2.5 小时；如果单拿 6 小时那次当作“恢复时间”，客户团队就会显得比实际更差。最坏的情况值得单独讲成一个故事，而不是当作指标上报。

有了这四个数字，会议的性质就变了。你不再说“部署很慢”，而是说“一次典型提交要四天才能到达客户，每 20 次部署就有 3 次引发事故”。这是一个可以界定范围的问题，而不是一种感觉。

## 带到客户现场的三个观点

第一条很简单：先衡量，再建议。本书承诺帮你判断该投资哪些能力，但前提是你手上有基线数据。到了现场，第一件事是拿到部署日志和事故历史，而不是开始争论用什么工具。

第二个观点来自 DORA 现在组织指标的方式：一组反映软件变更的吞吐量，另一组反映不稳定性。两组一起看，才能避开一个常见陷阱：部署次数上去了就宣布胜利，事故率却也跟着上升。

**要点:** 速度和稳定性要一起衡量，不要优化一个、掩盖另一个。

最后一个观点是与管理层的共同语言。IT Revolution 明确表示，这本书非常适合各级管理者。FDE 经常需要同时说服 CTO 和运维负责人，而这四项指标双方都能看懂，不需要先讲一遍架构。

## 为什么先打开 dora.dev，再打开这本书？

“四项指标”是 2018 年的说法。此后 DORA 已扩展到五项指标，新增了部署返工率（deployment rework rate）。如果你在客户会议上引用这本书却不知道这一点，细心的听众马上就会发现错误。

所以合理的顺序是：先读 dora.dev 上的“DORA metrics: the four keys”页面，掌握当前的定义；再读《Accelerate》，理解这些数字为什么可信；最后读 Google Cloud 的文章“Using the Four Keys to measure your DevOps performance”，看看实际中如何测量。

这本书适合有两到八年经验、熟悉 CI/CD，但从未需要向非技术人员解释流水线为何重要的开发者。如果你的目标是 FDE 岗位，这正是从“会部署”迈向“能衡量整个组织部署能力”的那一步。

## 真实日志从来不干净：一道练习

客户现场的部署日志很少像上面的例子那样整齐。下面是一周假设的日志，故意弄得很乱。先自己算出全部四项指标，再看后面的答案。

| 部署时间 | 环境 | 结果 | 最早提交 | 备注 |
|---|---|---|---|---|
| 周一 09:10 | production | 成功 | 周日 22:00 | — |
| 周一 09:12 | production | 成功 | 周日 22:00 | 任务重跑，重复构建 |
| 周二 14:00 | staging | 成功 | 周二 10:00 | — |
| 周三 16:30 | production | 流水线中失败 | 周三 11:00 | 从未到达生产环境 |
| 周三 17:45 | production | 成功 | 周三 11:00 | 引发事故，18:30 恢复 |
| 周五 10:00 | production | 成功 | 周四 15:00 | — |

## 答案：先清洗，再计算

清洗这一步决定一切。去掉重复的重跑，去掉 staging，再去掉那次流水线失败，因为它从未到达生产环境。剩下 3 次成功发布，部署频率就是每周 3 次。

三次中有一次引发事故，变更失败率为 1/3，约 33%。三次的前置时间分别是 11 小时 10 分钟、6 小时 45 分钟和 19 小时，中位数为 11 小时 10 分钟。

恢复时间是 45 分钟。如果误算成 6 次部署，频率会翻倍，失败率降到约 17%，客户团队看上去就比实际稳定一倍。

## 把它变成求职优势

阅读 FDE 或解决方案工程师的岗位描述时，留意“deployment”“time to production”或“衡量交付效能”之类的说法。它们说明雇主想要一个能用数字说话的人。

在简历上，“将从提交到生产环境的中位前置时间从四天缩短到一天以内”这样一行字，远比“具备 DevOps 经验”有分量。数字必须是你自己在真实项目里测出来的，被问到时还要能讲清楚你是怎么清洗日志的。

《Accelerate》不会教你写任何具体的流水线。它教你走进一个陌生组织，在第一周就弄清楚它处在什么位置，而这恰恰是客户花钱请 FDE 带来的东西。

**本周动手试试:**

- 拉取当前项目最近 30 天的部署日志，去掉重复记录、staging 和失败的流水线运行，然后在电子表格里算出全部四项指标
- 打开《Accelerate》之前，先读 dora.dev 上的“DORA metrics: the four keys”页面，了解指标有哪些变化
- 把简历中的一行改写成前后对比：你的工作让前置时间、部署频率或恢复时间发生了怎样的变化

## 信源

- [Accelerate (IT Revolution)](https://itrevolution.com/product/accelerate/)

- [Using the Four Keys to measure your DevOps performance](https://cloud.google.com/blog/products/devops-sre/using-the-four-keys-to-measure-your-devops-performance)

- [DORA | Research](https://dora.dev/research/)

- [DORA metrics: the four keys](https://dora.dev/guides/dora-metrics-four-keys/)