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

很多客户会议都卡在同一句抱怨上：“我们团队部署太慢了。”跟谁比慢？慢多少？会议室里没人拿得出数字。《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 带来的东西。