专业书籍精读 · Accelerate · 第 2 章
Accelerate: The Science of Lean Software and DevOps · Ch 2 · Forsgren, Humble & Kim · 2018
想知道一个厨房好不好，你可以去数它一天洗了多少个盘子——但这跟客人吃得满不满意几乎没关系。《Accelerate》（中译《加速》）第 2 章要解决的正是这件事：给一个软件团队打分，到底该数什么？上一章说「交付的本事能量出来」，这一章把话兑现：量什么、怎么量、为什么偏偏是那几个数。
公司里最常用的三把尺子——写了多少行代码、这个月干完多少活、人排得有多满——每一把用得越认真，团队反而变得越差。数代码行，代码就越写越臃肿；数干活量，估算就集体注水；把人排到满，交付反而更慢。
问题不在于「还没找到对的尺子」，而在于这三把尺子有个共同的毛病：它们量的是「你有多忙」，不是「东西有没有到用户手里」。
最反直觉的是「人排得有多满」那一把。把人排满听起来天经地义——闲着不就是浪费吗？可它和高速公路一个道理：车不多时来一辆走一辆；一旦车流填满路面，前面稍微一脚刹车，后面就堵成一片。日程排到一点缝都不剩，计划外的事没地方塞，只能排队——而排队的时间，往往比真正干活的时间长得多。
还有一层更隐蔽的毛病：这些尺子都只量一个格子。写代码那边考核「交了多少功能」，管线上那边考核「有没有出事」，两边的最优解正好相反。于是两边数字都达标，用户什么也没等到。
这一章立了两条挑尺子的规矩，比它最后挑了哪四个数更值钱：
第一，要量整条链的结果，不能只盯一个格子，否则团队之间必然互相拆台；第二，要量「东西到了没、好不好用」，不量「人忙不忙、写了多少」。按这两条筛出来的四个数，说白了就是四句家常话：多久发一次版、从代码写完到用户能用要多久、发出去的东西有多大比例把线上搞坏了、搞坏之后多久能恢复。前两个说「快」，后两个说「稳」。
妙处在于这四个数互相拽着。想让「发得勤」好看，就得靠自动化把每次改动做小，否则「搞坏的比例」立刻难看；反过来想让「不出事」好看，最省事的办法是干脆别发版，可那样「多久发一次」立刻见底。没有哪一侧能靠牺牲另一侧来刷分——这就是它防作弊的地方。
还有一处观念换挡：「多久能恢复」这个问法承认了故障是躲不掉的——该问的不是「多久不出事」，而是「出事了多久能好」。
诚实的代价只有一句：这四个数是体检报告，不是 KPI——一旦拿去排名或者折算奖金，人立刻会去刷它，而刷它比真改进它容易得多。
别数「干了多少」，去数「到了没、稳不稳」。四个数——多久发一次、从写完到能用要多久、发坏了多大比例、坏了多久修好——前两个管快、后两个管稳；四个一起看，谁也没法靠牺牲另一边给自己刷分。
想进到四个指标的操作定义、具体量级与防刷设计？ → 切到精读版
第 2 章把上一章的承诺兑现成一套具体的度量设计。它真正的贡献不是「四个指标」这份清单，而是清单背后的两条准则：量全局结果、不量局部产出；量结果（outcome）、不量产出（output）。你以为难点在「找到对的指标」，其实难点在大多数指标一旦被拿去考核就会反噬——本章先解剖三把公认有毒的旧尺子（代码行数、速率、利用率），再论证为什么这四个数彼此牵制、单独刷不动。
本章紧接 Ch1，位于 Part I「研究发现」开头。Ch1 主张「交付效能可测量、且预测组织绩效」，本章负责把「可测量」落成操作定义——全书唯一一章专门讲「怎么量」。分量在于：后面各章（Ch3 文化、Ch4 技术实践、Ch5 架构）得出的「某某能力能提升效能」，用的都是本章定义的那个因变量；这一章的定义如果站不住，全书结论一起塌。对应现实：任何一场「我们效能到底怎么样、下季度改哪」的评审会，以及今天各家云平台上那块「DORA 四指标」面板。
软件难量有个物理层面的原因：它没有可见的库存。制造业车间里，在制品堆在哪台机器前，瓶颈就一眼看得见；软件的在制品是没合并的分支、堆在评审队列里的 PR、做完但没上线的功能——瓶颈没有形状。所以「该量什么」不像流水线那样自明，只能靠设计。
而行业现成的三把尺子——代码行数、速率、利用率——全部有毒，且毒法一致。举个具体场景：一家电商，开发团队每个迭代的 velocity 从 40 点涨到 55 点，季度报表很好看；另一边，变更咨询委员会（CAB）每周只开一次会、一次放行 2 个变更窗口，功能做完后平均在待发布队列里躺 3 周才上线。两个团队的 KPI 都达标，从用户视角看，这个季度的交付速度改善为零。
不解决会怎样？管理层对着一屋子达标的数字做决策，却不知道自己交付得快不快；更糟的是这些数字不只是没用，它们主动地把团队推向局部最优——开发囤活以保住速率，运维卡窗口以保住稳定记录。指标本身成了拆台的动力来源。
代码行数（lines of code）。奖励多写，得到的是臃肿软件——维护与变更成本一起涨。奖励「少写」也不行：按这个逻辑，最优解是一行都不写。根子在于代码是成本，不是产出——同一个功能的两种实现能差出好几倍代码量，用户那边感知为零。
速率 / 故事点（velocity）。它本是个容量规划工具——外推「这堆活几个迭代能干完」。当成生产率考核有三个硬伤：它是相对的、团队自定义的（A 队的 5 点和 B 队的 5 点不是同一个单位，横向排名在数学上就不成立）；一旦考核立刻估点通胀（同一件活从 3 点报成 8 点，数字涨了 167%，交付一点没变）；团队开始囤活、拒绝协作（帮隔壁队解阻塞不进自己的账）。
利用率（utilization）。高利用率只在某个点之前是好事。排队论给的直觉是：利用率越逼近 100%，前置时间涨得越凶，直至趋于无穷——没有留白，计划外的事就只能排队，而排队时间以远快于线性的速度膨胀。所以「把人排满」这个看起来最负责任的管理动作，恰恰保证了交付变慢。
三把尺子的共同点值得单独记一句：前两把量的是产出而不是结果，第三把量的是局部忙碌而不是全局流动。记住这个诊断比记住这三个反例有用——它能直接用来判断你们公司下一个新指标是不是又一把毒尺子。
准则 ①：量全局结果，不量局部产出。目的是不让团队被摆到对立面。最经典的一对冤家是开发（求吞吐）与运维（求稳定）：只要指标分设在两个格子里，双方的理性选择就是互相拆台。全局指标的作用是取消这场对赌——四个数属于同一条交付链，任何一方牺牲另一方，账都记在同一张表上。
准则 ②：量结果，不量产出。不奖励「投入了多少」。产出（写了多少代码、开了多少会、关了多少工单）容易数，也因此容易刷；结果（东西到用户手里了吗、稳不稳）难刷得多。
这两条比那四个指标更耐用：指标会过时——DORA 自己 2021 年就加了第五个；准则不会。
（1）交付前置时间（delivery lead time）——只量后半段。精益里 lead time 指「从客户提出请求到请求被满足」。软件把这段天然切成两半：设计与验证（模糊的点子 → 想清楚、可实现的方案）和交付（代码提交 → 跑在生产上）。两半性质完全不同：前半段本质是探索，高变异、也不该硬压——压它只会逼出没想清楚的方案；后半段应当快且可预测，它才是工程能力的直接体现。所以本书只量后半段：从代码提交到成功跑在生产环境上，有多久。
为什么短前置时间要紧：反馈越快，纠错越便宜——等三周才发现一个技术决定错了，返工代价是等三小时的几十倍，因为这三周里别的代码已经长在它上面了。量级：高效能小于 1 小时，低效能一周到一个月（书中所引 2017 年 State of DevOps 数据）。最常见的坑是起点定义：很多公司从「需求进 backlog」开始算，那量的是产品排期和优先级会议，不是工程能力；两个口径能差一个数量级，混着用会让你以为在修流水线，其实该修的是产品决策。
（2）部署频率（deployment frequency）——它其实是「批量大小」的替身。作者真正想量的是批量大小：一次交付里塞了多少改动，精益几十年的经验是批量越小越顺。可软件没有可见的库存，「一次改动有多大」跨语言、跨团队没有统一单位——你没法把一个后端服务的 300 行改动和一个前端的 30 行改动放上同一把秤。于是他们退而求其次，用部署频率作为批量大小的代理指标：人人报得出、口径基本一致、变异小，方向也明确——发得越勤，每次装的东西就越少。
量级：高效能按需部署、一天多次；低效能每周一次到每月一次。两个坑：部署（deploy）≠ 发布（release）——用特性开关把「代码上线」与「功能对用户可见」解耦之后，它才是纯粹的工程节奏指标，否则会被产品排期污染；另一个是把一次发布硬拆成十次来刷频率——这正是它必须和另外三个数一起看的原因。
（3）恢复服务时间（time to restore service / MTTR）。背后是一次观念换挡。传统可靠性度量盯的是 MTBF（平均无故障时间），隐含假设是「故障可以被防住」；本书的假设是故障不可避免，于是该问的变成「多久能恢复」。下游影响很大：它直接决定了后面几章的实践重心是「让回滚变快变安全」，而不是「加更多审批把故障挡在门外」。量级：高效能小于 1 小时；低效能一天到一周。坑在口径：「恢复」指用户又能用了，还是根因彻底修完了？两者能差一个数量级——先把定义钉死，再谈这个数好不好看。
（4）变更失败率（change fail rate）。定义：投到生产的变更里（含软件发布与基础设施配置变更），有多大比例导致服务降级或中断、并需要补救——回滚、打补丁、hotfix、fix forward 都算。
为什么用比例而不是绝对次数？发得越勤，出事的绝对次数必然越多，只有比例才能跨节奏横向比较。这是四个指标里防刷设计最明显的一处：它天然堵死了「靠少发版来降低事故数」这条捷径——你少发一半，事故数掉一半，比例纹丝不动。量级：高效能 0–15%；低效能 31–45%（2017）。剩下的坑是谁定义「失败」：把失败收窄到只算 P0 级故障，这个数立刻好看一半。
把四个数交给聚类分析、让数据自己分堆，得到高 / 中 / 低三档。两个细节比「分了三档」本身更值得记：
其一，中档与低档在「快」的两项上落在同一区间（见表 2）。书里的解释是中档团队正卡在转型半路——已经在推自动化、提交也变频繁，却还背着遗留系统（legacy system）和重量级审批，「快」的收益还没兑现，风险却先涨了。转型最痛的地方常在半路，不在起点。
其二，2016 那届数据更刺眼：中档团队的变更失败率反而比低档更高。合理的解释是低档团队发得太少、发的又往往是不那么关键的系统——「不动就不出错」。但那不是稳定，那是没在交付。这恰好印证了本章的设计意图：四个指标必须一起读，单看任何一个都能读出反的结论。
表 1 · 四个指标：定义、量级、最容易被刷的地方、防刷办法
| 指标 | 操作定义（本书口径） | 高效能量级 | 最容易被刷的地方 → 防刷办法 |
|---|---|---|---|
| 交付前置时间 | 代码提交 → 成功跑在生产环境 | < 1 小时 | 偷偷把起点挪到「需求进 backlog」→ 钉死起点是 commit，产品排期另设指标 |
| 部署频率 | 成功部署到生产的频次（批量大小的代理） | 按需，一天多次 | 把一次发布拆成十次 → 与变更失败率同看；用特性开关把部署与发布解耦 |
| 恢复服务时间 | 出事到服务恢复正常的时长 | < 1 小时 | 「恢复」按用户可用算还是按根因修完算 → 团队内统一口径并写进复盘模板 |
| 变更失败率 | 生产变更中导致降级 / 中断并需补救的比例 | 0–15% | 把「失败」收窄到只算 P0 → 定义写死在事故分级里；用比例已堵死「少发版」这条路 |
表 2 · 高 / 中 / 低三档画像（书中所引 2017 年 State of DevOps 数据）
| 指标 | 高效能 | 中效能 | 低效能 |
|---|---|---|---|
| 部署频率 | 按需，一天多次 | 每周一次到每月一次 | 每周一次到每月一次 |
| 交付前置时间 | 小于 1 小时 | 一周到一个月 | 一周到一个月 |
| 恢复服务时间 | 小于 1 小时 | 小于 1 天 | 一天到一周 |
| 变更失败率 | 0–15% | 0–15% | 31–45% |
注意中档与低档在前两行完全重合——这正是上文说的「卡在转型半路」。三档之间的倍数差（书中所引：部署频率 46 倍、前置时间 440 倍、恢复速度 96 倍、失败率 5 倍）之所以吓人，是因为区间本身跨了数量级，不是因为高效能团队多加了几个班。
表 3 · 先想清楚你到底想量什么，再挑尺子
| 你想回答的问题 | 该用什么 | 不该用什么 |
|---|---|---|
| 我们交付得快不快、稳不稳 | 四指标，看自己的趋势 | 跨团队排名——口径不同，比不了 |
| 这堆活几个迭代能做完 | velocity（它的本职工作） | 四指标——它们不预测工期 |
| 这个人干得怎么样 | 同行评审与产出质量 | 四指标——团队级的，落到个人必被刷 |
| 我们做的东西有没有价值 | 产品指标：留存、转化、完成率 | 四指标——一天发 50 次废功能照样全绿 |
| 下一步该改哪 | 盯四指标里最差的那一项往上游找约束点 | 照抄别家的实践清单 |
今天你在 Google Cloud、GitHub、GitLab、Azure DevOps 的工程效能面板上看到的那四个数，操作定义就出自这一章；DORA 团队 2018 年并入 Google Cloud，把它做成了开源度量方案与年度报告。但工业界真正继承下来的是本章的度量设计手法：先想清楚要改进什么结果，再挑指标，最后确认这组指标互相牵制、单独刷不动。落到面试和架构评审——被问「你怎么衡量团队效能」，背出四个词是及格线；先讲两条准则、再讲四个数如何互相牵制、最后主动承认它们不测产品价值，才是把这一章读透了的答法。
① 本章把 Ch1 的「效能可测量」兑现成操作定义，是全书唯一一章讲「怎么量」；后面所有结论都建立在这里定义的因变量上。
② 软件难量的物理原因：没有可见的库存——在制品是没合的分支和待发布队列，瓶颈没有形状。
③ 三把有毒的旧尺子：代码行数（把成本当价值）、速率（容量规划工具被拿去考核，引发估点通胀与囤活）、利用率（排队论：越逼近 100%，前置时间越陡增）。
④ 两条准则比四个指标更耐用：量全局结果不量局部产出（取消开发与运维的对赌）、量结果不量产出（不奖励忙碌）。
⑤ 交付前置时间只量从 commit 到生产可用这半段（探索那半段本就该高变异，起点定义是最常见的坑）；部署频率是批量大小的代理指标（批量没法直接量，它好量、变异小、方向一致）。
⑥ 恢复服务时间背后是观念换挡：从 MTBF（多久不出事）换到故障不可避免，问多久恢复——这决定了后面几章重视回滚而非审批。
⑦ 变更失败率用比例不用次数，天然堵死「少发版降事故数」的捷径——全套设计里防刷最明显的一处。
⑧ 量级背下来（2017）：高效能 = 一天多次部署、前置时间与恢复时间均 < 1 小时、失败率 0–15%；中档与低档在「快」的两项上重合，说明转型最痛的地方在半路。
⑨ 最该警惕的两条：四指标测交付能力而非产品价值；它是团队级诊断工具，不是个人 KPI——DORA 官方自己都说，跟自己的去年比才有意义。