KEEL · 龙骨 · A CURRICULUM FOR THE AI ERA
06 · 度量与改进：怎么证明你的流水线真的有用 — keel 龙骨
这一章回答：花在流水线上的钱到底买到了什么。答不上这个问题，流水线就永远只能被当成成本项。
这一章回答：花在流水线上的钱到底买到了什么。答不上这个问题，流水线就永远只能被当成成本项。
度量这件事有两个常见失败姿势：什么都不量（于是无法判断改动是好是坏），以及把指标当 KPI 考核（于是团队开始优化指标本身）。这一章给出一组用于改进而不是用于考核的指标，以及它们的正确读法。
一、先看结果侧：交付性能的五个指标
源自《Accelerate》并由 DORA 长期维护，2025 年演进为五个：
| 指标 | 定义 | 它衡量的本质 |
|---|---|---|
| 部署频率 | 单位时间成功部署到生产的次数 | 批量大小与流程自动化程度 |
| 变更前置时间 | 从提交到成功跑在生产的中位时间 | 整个交付链条的流动效率 |
| 变更失败率 | 导致降级/回滚/热修的部署占比 | 质量闸门的有效性 |
| 服务恢复时间（MTTR） | 从故障发生到恢复的中位时间 | 观测与回滚能力 |
| 可靠性 / 可用性 | 服务是否达到其承诺的可用水平（DORA 2025 新增为独立结果） | 上述四件事没有以牺牲稳定性为代价的前提 |
读法上的三个提醒：
- 这四个（五）个必须一起看。 只看部署频率会把团队推向"频繁上线一堆半成品"。吞吐与稳定性是一对张力，改进的目标是同时改善，不是此消彼长。
- 用中位数而不是均值。 长尾的单次耗时才是团队真实体感的来源。
- 分层（Elite / High / Medium / Low）是对照用的，不是考核用的。 拿别组织的基线压自己的团队，只会得到被优化的指标。
二、再看过程侧：流水线自己的健康度
结果指标变化慢，过程指标能让你今天就知道改动有没有效：
| 指标 | 怎么算 | 为什么重要 |
|---|---|---|
| 队列等待时间 | 从触发到作业开始运行的差值 | 大多数"CI 很慢"其实是排队慢，不是跑得慢 |
| 运行时长 P50 / P90 | 每次运行中某些作业/整条流水线的耗时分布 | P90 才是体感，P50 常常骗人 |
| 绿率 | 通过次数 / 总运行次数（主分支） | 主分支长期低于 90% 说明流水线不值得信任 |
| flake 率 | 同一 commit 多次运行结果不一致的比例 | 直接决定团队会不会习惯性点重跑 |
| 回滚/热修占比 | 结果侧的变更失败率在发布维度的展开 | 和 DORA 的变更失败率互为印证 |
| MTTR（流水线侧） | 红了之后多久被恢复 | 反映故障是否易于定位 |
建议的起步组合只有四个：队列等待、P90 时长、绿率、flake 率。 这四个能在一周内采集到，也解释得了绝大多数"流水线让人难受"的场景。
三、指标的三种误用（以及怎么避免）
| 误用 | 表现 | 对策 |
|---|---|---|
| 当作个人 KPI | 按人统计部署次数、修复时长 | 只做团队级、系统级；改动 KOH 指标会诱发充分暴露问题的反诱因 |
| 只看不放眼它是分布 | 平均值掩盖长尾 | 一律 P50 / P90 / 最大值一起看 |
| 指标上升就宣称成功 | "部署频率翻倍了"但失败率也翻倍了 | 吞吐与稳定性至少成对汇报 |
一句话原则：指标的目的口是"让我们下一次的判断更准"，而不是"证明我们这次做对了"。
四、怎么真正开始改（不是一次性重构）
第 1 步 采集四个起步指标，连续看两周，建立基线（不要还没量基线就动手"优化"）
第 2 步 找最大的那个瓶颈：通常是队列等待或 flaky 测试，而不是"流水线不够高级"
第 3 步 一次只改一件事，改动前后各看一周
第 4 步 把结论写进仓库（README 或 docs/delivery.md），让规范和流水线的距离保持为零
改的顺序也有讲究：先把"不可预测"修掉（flake、排队），再优化"平均速度"（缓存、并行）。 一个每次时间都差不多的慢流水线，比一个平均快但随机抽风的流水线好用得多——因为人可以围绕它做安排。
五、个人 / 小团队的现实版本
不是每个地方都有完整的 DevOps 平台。一个人、一个服务的落地清单可以是：
| 阶段 | 做到什么 | 标志 |
|---|---|---|
| Day 0 | 每次 push 自动跑测试 | 有人提交坏代码时被挡住一次 |
| Day 30 | 产物由流水线生成 + 冒烟 + 部署脚本幂等 | 敢在没有人的时候按发布按钮 |
| Day 60 | 发布后有健康检查 + 一条核心指标图 + 明确回滚命令 | 能用一句话说清"上线后十分钟我在盯什么" |
| Day 90 | 采集四个起步指标，每周固定时间回顾 | 能回答"这个月比上月好在哪" |
注意 Day 90 那条里"有人看"—没人看的指标等于没有指标，所以务必把指标放到每天会经过的地方（PR 检查列表、每日站会看板、发布后检查清单），而不是一个需要专门打开才看得到的仪表盘。
动手：可观察结果
| 动作 | 产出物 | 判断标准 |
|---|---|---|
| 算自己的四个起步指标 | 一张表：队列等待/ P90 / 绿率 / flake 率 | 每个数都有明确的取样窗口和算法说明 |
| 画一次 change failure rate | 近 30 次部署的失败/回滚次数 | 分子分母定义清晰，别人能复算 |
| 做一次 Pareto | 流水线耗时 Top5 环节 | 能指出"如果只优化一件事，应该优化哪个" |
| 写一份交付 README | 文档 + 流水线互相引用 | 新人照文档能独立完成一次发布 |
| 做一次回滚演练 | 计时记录 | 能在预定目标时间内完成，且所有人知道命令在哪 |
故障注入
| 注入方式 | 观察什么 | 说明的现象 |
|---|---|---|
| 让主分支连续红三次不修 | 团队行为 | 是否开始出现"先合并回头再修"——这是流水线失效的开端 |
| 制造一个 flaky 测试 | flake 率指标是否捕获 | 指标捕获不到就说明整套度量是假的 |
| 让队列等待突然变长 | 团队第一反应 | 若反应是"加并发"而非"找排队原因"，说明缺过程指标 |
| 把指标面板从常用入口挪走一次 | 两周内是否还有人看 | 无人问津 → 指标放错了地方 |
| 只汇报部署频率一个月 | 是否有人追问失败率 | 没人追问本身就是一种风险信号 |
自测题
- DORA 的五个指标里，哪两个构成一对必须同时看的张力？
- 为什么"CI 很慢"的第一嫌疑人通常是队列等待而不是运行耗时？
- flake 率是怎么算出来的？它为什么比"重跑一次就好了"更能反映真实健康度？
- 把交付指标当作个人 KPI 会发生什么？
- 只能优化一件事时，你依据什么排序？（提示：不可预测性优先于平均速度）