6.3 指标与度量

6.3 指标与度量

本节摘要：DevOps 度量的核心是四大关键指标——部署频率、变更前置时间、变更失败率、平均恢复时间，它们分别刻画交付的速度与稳定性，且全部度量"过程"而非"个人"。本节讲四个指标的定义、采集口径与解读陷阱，说明为什么代码行数、Bug 数、加班时长这类伪指标会毒害协作，并给出从零搭建度量看板的路径。

读完这节你能回答

1. 准确定义四大指标并说出各自的采集口径
2. 用速度与稳定性双维度定位团队所处的象限
3. 识别度量反模式（对个人考核、指标游戏化）
4. 从工具链数据源搭建一个团队度量看板

一、度量什么：四个指标的故事

为什么是这四个？因为它们恰好覆盖了发布之旅的两个根本问题、四个侧面。

问题一：交付有多快？ 由两个指标回答。部署频率：单位时间内部署到生产的次数——它衡量的是"发布的平常化程度"（1.1 节讲过：发布越频繁，每次发布越平凡）。变更前置时间：从代码提交（或合并到主干）到该变更运行在生产上的耗时——它衡量的是旅程的通过速度，包括了所有的排队与等待（上一节价值流图的总时长就是它）。

问题二：交付有多稳？ 也由两个指标回答。变更失败率：引发故障（回滚、紧急修复、降级）的部署占总部署的比例——它是质量闸门的有效性证明。平均恢复时间：从故障发生（或告警）到服务恢复的时长——它衡量的是韧性，即"出事之后多快能站起来"（第 4 章全部内容的服务对象）。

速度与稳定常被当成对立面——"快了就不稳"。四个指标的存在恰恰是为了拆穿这个迷思：多年跨行业的大型调研反复观察到，精英团队在四个指标上同时领先——又快又稳不是悖论，是同一个工程能力（小批量、自动化、快速反馈）的两面。慢而不稳的团队才是常态，因为大批量发布既慢又险。

四大指标参考分档（行业调研口径的简化表述）
────────────────────────────────────────────────
指标            精英        中等        落后
部署频率        按需多次     每周~每月    每月~半年
前置时间        不到一天     一周~一月    一月~半年
变更失败率      0~15%       16%~30%     超 45%
恢复时间        不到一小时   不到一天     超过一天
────────────────────────────────────────────────
注意: 分档用于自我定位, 不是攀比榜单
​

二、口径：度量成败在细节

四个指标看似简单，口径不严就会失真到不可用。

前置时间的起点。从"提交"起算还是从"合并入主干"起算，差出整个评审等待。建议两个都采：提交到合并（评审效率）、合并到生产（交付效率），加总即全程。部署的计数单位。一次部署推了 5 个服务算 5 次还是 1 次？按服务计更利于横向比较，但要在团队内统一。变更失败的定义。回滚算、紧急修复算、性能降级算不算？建议口径：部署后需要人工干预（回滚/热修/紧急配置回退）即计失败；纯监控告警但自愈的不计。恢复时间的终点。是服务恢复（用户可用）还是根因修复？两个都要，但"恢复时间"特指前者——止血优先原则（4.3 节）的度量体现。

口径必须写成文档、随看板公示。否则各团队汇报的数字不可比，度量会迅速沦为"各有各的算法、互相不服气"的政治问题。

三、解读：速度-稳定矩阵

把四个指标压成两个维度（速度=频率与前置时间，稳定=失败率与恢复时间），团队可以放进一个四象限。

又快又稳（右上）：目标象限，特征是小批量、全自动、强观测。快而不稳（右下）：典型的"自动化跑在了质量前面"——部署很勤但失败率高，需要回补测试金字塔与质量门禁（第 2.3 节）。稳而不快（左上）：典型于银行核心、医疗系统——用重流程换稳定，未必需要改（监管行业的合理选择），但如果业务在快速变化，就要用第 3 章的渐进发布手段（灰度、金丝雀）把"安全的快"建立起来。又慢又不稳（左下）：最常见也最痛苦——大批量、手工多、环境乱。好消息是这个象限改进空间最大，任何一条自动化（先从 CI 稳定性或部署脚本化入手）都会同时改善两个维度。

关键洞察是：四个指标是联动的，单点优化会被系统拉回。比如强行提高部署频率而不改测试，失败率上升会迫使团队回退到低频发布。有效的改进总是成组出现：频率提升必须伴随金丝雀（护失败率）与回滚演练（护恢复时间）。

四、伪指标与度量反模式

有三类常见指标会主动毒害协作，必须警惕。

产出量指标：代码行数、提交次数、关闭工单数。它们度量的是活动量不是价值——被这类指标考核的团队会学会拆分提交、多写样板代码、捡软柿子工单。对个人的度量：任何把上述指标落到个人头上（张三的失败率、李四的评审速度）的做法，都会摧毁无责复盘的心理安全（4.3 节），把系统性问题逼成隐瞒。DevOps 指标只对团队与服务计，永不对个人计。目标游戏化：给指标定硬性 KPI 后，优化行为会替换真目标——比如为拉高部署频率而做无意义的小部署。防御方法是古德哈特定律的常识版：指标只用于导航（看趋势、找瓶颈），不用于考核（排名、奖惩）。

⚠️ 常见坑：把"度量面板"做成"考核面板"。前者帮团队看清自己（趋势向好、瓶颈在哪），后者让团队隐藏真相。一旦团队开始问"这个数字会被谁看到"，度量已经死了。

五、从零搭建度量看板

好消息是：四大指标不需要新的采集系统——它们全部藏在已有工具链的数据里（5.1 节的"身份流转"在这里兑现）。

# 度量采集的简化配置：从既有系统抽取事件
metrics_pipeline:
  sources:
    - system: 版本仓库          # 提供: 提交与合并时间戳
    - system: CI 流水线         # 提供: 制品构建完成时间
    - system: 部署系统          # 提供: 每次生产部署的时间与制品号
    - system: 告警与工单系统    # 提供: 事故的开始、恢复时间与关联变更
  joins:
    key: 制品号                 # 4.1/5.1 节的身份: 一切事件按制品号串起
  outputs:
    - deploy_frequency: 按周计数生产部署
    - lead_time: 生产部署时间 减 对应合并时间 的分布
    - change_fail_rate: 关联了事故的部署 占比
    - mttr: 事故恢复时长的中位数
  display: 团队看板 · 只对内 · 展示趋势线而非排名
​

实施要点三条。先有身份链，再有指标：制品号贯穿仓库、CI、部署、告警四个系统（身份流转），是所有指标可计算的前提——身份断链处，指标就只能人工统计，而人工统计撑不过两个季度。展示分布而非平均值：前置时间报中位数与 p85，恢复时间报中位数——平均值会被极端值扭曲到失真（4.1 节同款陷阱）。月度回顾嵌入节奏：每月用 30 分钟看四个指标的趋势与异常，异常月份数一数当月发生了什么（大促封网？关键人员离职？）——把指标解读变成团队的例行学习，而不是数据工程师的独角戏。

本节要点回顾

• 四大指标：部署频率与前置时间度量快，变更失败率与恢复时间度量稳；精英团队四项同优——快与稳是同一能力的两面
• 口径先行：起点终点定义写成文档公示；口径不清的指标会变成政治问题
• 象限解读：四象限各有处方；指标联动，单点优化会被系统拉回，改进须成组
• 伪指标三害：产出量指标、个人度量、目标游戏化；导航用可以，考核用必死
• 落地三要点：身份链是前提、分布代替平均、月度回顾成节奏