指标的分歧不在定义，在计算

了解 DORA 四项指标的名称还不够。即使数据相同，窗口（window）、分母与代表值的选择也可能让结果相差数倍，因此必须把指标定义和计算方式固化在代码中，而不是只写在文档里。

概念图: 窗口（window）、分母与代表值 · 如何计算指标 · 台账（ledger） · 失败部署次数

两个团队曾针对同一份部署记录，分别报告“交付周期 40 分钟”和“交付周期 4 小时”。数据完全相同，一方使用中位数，另一方使用平均数；一方只统计成功部署，另一方统计全部部署。这样就无法用数字沟通。指标越多、会议越长的组织，通常就卡在这里。

因此，平台团队引入指标时，最先决定的不应是查看哪些指标，而是如何计算指标。

指标来自台账（ledger），而不是仪表板。每次部署都记录一行：服务名称、提交与部署时间、成功或失败，以及失败后的恢复耗时。有了这张表就能计算全部四项指标；没有它，购买任何工具都只能估算。

指标	常见错误
部署频率	只看组织总数时，一个高频服务会掩盖其余服务，因此还要逐服务查看
变更交付周期	平均数会被少数极慢事件拉高，应使用中位数
变更失败率	分母是部署次数，不是服务数或事故数
平均恢复时间	分母是失败部署次数，除以全部部署会让结果缩小数倍

中位数还有一个陷阱：**各服务中位数的平均值，不等于整体中位数。**每个服务的部署次数不同，两者通常不相等。混用会让同一台账产生不同报告。

DORA 将四项指标划分为 Elite、High、Medium、Low。比具体阈值更重要的是，必须预先写下组织采用的阈值并原样执行。每次判定时微调标准，等级就失去意义。

四项指标应一起阅读。速度好而稳定性差，不代表组织快，而可能是跳过验证。反之，稳定性好但很少部署，可能是为规避风险而停止改进。

平台采用率争论总围绕两点：分母是全部服务还是已入驻服务，以及什么才算“正在使用”。把完成入驻算作采用会让数字漂亮，却可能掩盖无人真正使用的状态。更诚实的方式，是统计最近一段时间内实际部署过的服务，并同时记录这段时间的长度，才能日后比较。

若 SLO 为 99.5%，窗口为 28 天，那么 28 天等于 40320 分钟，其中 0.5% 即 201.6 分钟，是本窗口允许的坏时间。减去实际消耗时间，就是剩余预算。有了这个数字，才能根据余额而不是情绪讨论“现在继续发布功能，还是投入稳定性”。

一旦把指标用作团队排行榜，台账就会被污染。人们不再把失败记录为失败，还会把部署拆细以增加次数。数字变好，真实情况却变差，指标从此变成遮蔽现实的装置。

因此，平台团队应把指标指向自己。某条规则合规率低时，不应先责问团队，而应让规则更容易遵守；某个服务交付周期特别长时，应检查流水线在等待什么。指标的价值不在排名，而在决定下一步修复什么。

开始衡量平台指标后，很快会发现：**一旦开始测量，数字就会成为目标，人们会朝着美化数字的方向行动。**因此，测量什么，就会发生什么。

只测部署频率，会增加无意义部署。无变更重部署和拆碎提交都会提高数字。因此必须一起看四项指标。部署频率提高且变更失败率不变，才是真正改善；只改善一项，往往是牺牲了另一项。

不定义变更失败率的分母，就能得到任何结果。“失败”究竟指回滚、故障还是达到某个事故等级，会让数值成倍变化。应记录定义，并在定义改变时重新计算历史值，否则定义变更当月的图表会看起来像改善。

**恢复时间应同时看中位数与最坏值。**大多数情况十分钟恢复，但每季度有一次耗时八小时，平均数说明不了任何问题；人们记住的是那八小时。

不要用于团队横向比较。服务性质不同，数字自然不同。把支付系统和内部工具放进同一张表，会驱使支付团队选择不承担风险。指标应用于观察同一团队随时间的变化。

采用率不应定义为“使用过”，而应是“用它工作”。创建账号的人数毫无意义。应采用统计过去 30 天内真实完成部署的团队数等行为定义，才能判断平台是否提供帮助。

错误预算是协商工具。必须预先约定：预算有余时可以进行高风险变更，预算耗尽后专注稳定性。没有这种约定，数字只会成为故障后争论的材料。

我们会使用 28 天部署台账亲自计算四项指标，手工确认中位数与平均数的差异，以及失败率和恢复时间的分母；再按预定阈值判定等级。随后根据服务名册，按活跃使用定义计算采用率，最后计算错误预算与消耗率。