这四个指标共用同一套发布记录作为统计基础，先统一时间窗、变更粒度、失败判定和恢复标准，数值才可比较。变更失败率是失败变更数除以同期已完成变更总数；回滚率是执行回滚的变更数除以同期已完成变更总数；回滚耗时从回滚决策确认算到服务恢复正常，用分钟呈现中位数与P90；恢复验证通过率是首次恢复验证即通过的变更数除以执行了回滚的变更数。本文给出可直接复算的口径、字段与算例。
要点总览（TL;DR）
- 四个指标共用同一套发布记录作为统计基础，先统一时间窗、变更粒度、失败判定和恢复标准，数值才可比较。
- 变更失败率 = 失败变更数 ÷ 同期已完成变更总数；回滚率 = 执行回滚的变更数 ÷ 同期已完成变更总数。
- 回滚耗时从回滚决策确认算到服务恢复正常，用分钟呈现中位数与P90，避免均值被极端值拉偏。
- 恢复验证通过率 = 首次恢复验证即通过的变更数 ÷ 执行了回滚的变更数，验证标准需在回滚前写入预案。
- 指标不设通用达标线，回滚率高不等于处置差，需结合失败率与耗时一起看，跨团队比较需谨慎。
这套指标要回答什么评估问题
这组指标评估的是发布风险暴露程度与回滚处置能力：一次发布中有多少变更以失败收场，失败后有多少需要回滚，回滚要花多久把服务拉回正常，恢复后的验证是否一次通过。四个数值合起来，构成对“发布风险是否被有效处置”的可核验判断，而不是对某个团队或个人的绩效评分。
指标主要服务于三类决策。第一类是发布准入：当某类变更的失败率与回滚率持续偏高时，可以收紧该类变更的上线条件，例如增加灰度批次或延长观察期。第二类是回滚预案评审：回滚耗时中位数与P90偏长，说明预案中的决策路径、执行脚本或数据回退方案需要重新演练。第三类是流程改进：恢复验证通过率偏低，往往指向验证清单不完整或监控基线不清晰，可以据此补齐验证项。
需要与一般服务事件指标划清边界。服务事件指标统计的是故障对用户的影响，分母通常是时间或请求量；本文四个指标的分母是变更，统计对象是发布行为本身。一次变更失败可能没有形成对外可见的服务事件，一次服务事件也可能由多个变更叠加引起。因此这组指标回答“发布做得稳不稳、回滚处置快不快”，服务事件与问题管理指标回答“故障影响多大、根因是什么”，两者互补，不能互相替代。
四个指标的范围、公式与分母
四个指标共用“同期已完成的变更总数”作为主要分母基础，回滚耗时是时长类指标，恢复验证通过率的分母收窄到执行了回滚的变更。下表给出完整口径，可直接用于复算。
| 指标 | 定义 | 公式 | 分子 | 分母 | 时间窗 | 单位 |
|---|---|---|---|---|---|---|
| 变更失败率 | 统计窗口内以失败收场的变更占比 | 失败变更数 ÷ 已完成变更总数 | 判定为失败的变更数 | 同期已完成的变更总数 | 与统计窗口一致，按变更完成时间归集 | 百分比 |
| 回滚率 | 统计窗口内执行了回滚的变更占比 | 执行回滚的变更数 ÷ 已完成变更总数 | 回滚决策确认并实际执行的变更数，同一变更多次回滚按一次计 | 同期已完成的变更总数 | 同上 | 百分比 |
| 回滚耗时 | 从回滚决策确认到服务恢复正常的时长 | 逐条计算时长后取中位数与P90 | 每条回滚变更的时长样本 | 不适用，按样本分布呈现 | 回滚决策时间落在统计窗口内的变更 | 分钟 |
| 恢复验证通过率 | 回滚后首次恢复验证即通过的变更占比 | 首次验证通过数 ÷ 执行回滚的变更数 | 首次恢复验证即通过的变更数 | 同期执行了回滚的变更数 | 同上 | 百分比 |
失败判定需要事先写明条件，常见依据包括：发布后验证不通过、关键监控指标越过阈值并触发告警、上线后需紧急修复才能维持业务、变更被主动撤销。判定以发布单结论和验证记录为准，避免事后凭印象归类。回滚事件的认定以“回滚决策确认并实际执行”为标志，仅讨论未执行的不计入；同一变更在一个窗口内多次回滚，按变更去重计一次，耗时取首次回滚的完整时长。
回滚耗时的起点是回滚决策确认的时间点，终点是服务恢复正常的确认时间点，两端都要有记录支撑。呈现时同时给中位数与P90：中位数反映典型处置速度，P90反映长尾，均值容易被个别超长回滚拉偏，不建议单独使用。恢复验证的通过标准按系统约定，例如核心交易链路验证通过、关键监控指标回到基线、数据一致性校验通过；标准要在回滚前就写进预案，不能事后调整。
数据从哪里取、字段怎么记
四个指标能否复算，取决于发布记录是否记全了关键时间点和结论。建议每条变更至少包含以下字段：变更标识、变更类型与所属系统、变更开始时间、变更结束时间、结果判定（成功或失败）、失败原因分类、是否回滚、回滚决策确认时间、服务恢复正常时间、恢复验证结论、验证完成时间。
失败与回滚判定要有证据支撑。发布单记录变更内容与审批结论；监控告警记录提供指标越界的时间点；验证记录写明验证项、执行人与结论。回滚决策确认时间以决策会议记录、值班群确认消息或工单状态变更时间为准，服务恢复正常时间以监控指标回到基线或验证人确认时间为准。这两类时间点如果只靠事后回忆补录，回滚耗时就会失真。
缺失值与未闭环记录要单独处理，不能默认按成功计入。变更结束时间缺失的记录不进入分母；结果判定缺失的记录标记为待补，补齐后再纳入统计；回滚已决策但恢复时间未记录的回滚，计入回滚率但不计入耗时样本，并在报告中注明样本缺口。统计前对同一变更的多条记录按变更标识去重，保留最终结论。
这些字段本质上要求发布、回滚决策与验证结论在同一处留痕并可追溯。在 ONES 中，可以把一次发布建为工作项，将变更标识、起止时间、结果判定、是否回滚、回滚决策时间、恢复时间与验证结论作为字段记录，回滚决策与恢复验证作为流程节点留下状态与时间戳，统计时按字段导出即可复算，减少从多个系统手工拼接记录的工作。
计算与评估步骤
按以下顺序操作，可以保证四个指标在同一口径下产出。
- 确定统计窗口与变更粒度。窗口可以是自然月或一个发布周期；变更粒度明确到“一次发布单对应一个变更”还是“一个需求合并对应一个变更”，全篇保持一致。
- 按窗口取数并去重。以变更完成时间落在窗口内为纳入条件，按变更标识去重，剔除结束时间缺失的记录，形成基础数据集。
- 计算变更失败率与回滚率。分别统计失败变更数与回滚变更数，除以基础数据集条数，保留一位小数。
- 计算回滚耗时。对每条回滚变更计算“恢复时间减回滚决策时间”，换算为分钟，剔除负值与明显异常值后，取中位数与P90。
- 计算恢复验证通过率。统计首次验证即通过的变更数，除以执行回滚的变更数。
- 分组对比。按发布类型（常规发布、紧急修复、配置变更）或系统分组重复上述计算，观察差异来源。
- 复核。抽取若干条记录回溯原始发布单与监控记录，核对失败判定、回滚认定与时间点是否一致。
分母为零时不要写成0%，应标注“窗口内无已完成变更”，暂不下结论。样本过少时同时给出样本量，例如回滚样本不足10条时，P90参考价值有限，宜与中位数一起看并注明样本数。分组对比时保持各组的失败判定与验证标准一致，否则组间差异可能来自口径而非实际表现。
一个算例：把四个指标算出来
假设某月统计窗口内已完成变更100条，其中判定为失败12条，执行了回滚8条，回滚后首次恢复验证即通过6条。以下为演示数据，用于说明计算过程。
| 指标 | 计算过程 | 结果 |
|---|---|---|
| 变更失败率 | 12 ÷ 100 | 12.0% |
| 回滚率 | 8 ÷ 100 | 8.0% |
| 恢复验证通过率 | 6 ÷ 8 | 75.0% |
回滚耗时取8条回滚变更的时长样本（分钟）：18、22、25、30、35、42、58、95。排序后中位数为第4与第5个值的平均，即(30+35)÷2=32.5分钟。P90按最近秩法计算，位置为0.9×(8−1)+1=7.3，取第7与第8个值插值：58+(95−58)×0.3≈69.1分钟。结果呈现为“回滚耗时中位数32.5分钟，P90约69.1分钟”。
这组结果可以这样读：该月每100次变更约有12次失败、8次触发回滚，回滚后四分之三的变更一次验证通过，典型回滚约半小时恢复，长尾接近70分钟。若下月失败率降到8%但回滚耗时P90升到100分钟，说明失败变少了、单次处置却变慢了，应检查预案执行环节而非只盯失败率。
怎么解读，以及口径上的限制
四个指标要合起来看。回滚率高本身不说明风险处置差：如果失败率低、回滚耗时短、验证通过率高，较高的回滚率可能反映团队对失败变更果断止损、快速恢复。反过来，回滚率低也可能是变更失败后选择带病运行而不回滚，此时要结合失败率与验证记录判断。
回滚耗时受系统规模、依赖数量与预案成熟度影响，跨团队直接比较意义有限。一个依赖数十个下游服务的系统，回滚与验证本身就更耗时；比较宜在同一系统的时间序列上进行，观察改进趋势。恢复验证通过率的分母选择同样影响结果：以执行回滚的变更为分母，衡量的是回滚后的恢复质量；若改用全部失败变更作分母，数值会被未回滚的失败变更稀释，两种口径不能混用，报告里要写明用的是哪一种。
这组指标不设通用达标线。不同业务对可用性与发布频率的要求不同，合理的阈值应结合自身历史数据与发布准入要求确定，并在口径稳定后逐步校准。指标反映的是发布与回滚过程的统计特征，不构成因果保证：失败率下降可能来自变更范围缩小，也可能来自判定标准放宽，解读时需要回到具体记录核对。把单次窗口的数值直接用于绩效结论，容易忽略样本量与口径变化，建议至少观察连续三个窗口再判断趋势。
常见问题
统计窗口内没有发生回滚，回滚率和回滚耗时该怎么呈现？
回滚率的分母是同期已完成变更总数，分子为零时结果为0%，可以正常呈现。回滚耗时没有样本，不应写成0分钟，建议标注“窗口内无回滚样本”，暂不计算中位数与P90。如果连续多个窗口回滚样本都很少，可以把统计窗口拉长到季度，或按发布类型合并样本后再看分布，同时注明样本量。
同一个变更在一个月内回滚了两次，回滚率和回滚耗时分别怎么算？
回滚率按变更去重，同一变更在一个窗口内多次回滚只计一次，分子加一。回滚耗时取首次回滚的完整时长，即从第一次回滚决策确认到服务恢复正常的分钟数，后续回滚不重复计入耗时样本。这样处理可以避免同一变更因反复回滚而放大回滚率，也能让耗时反映首次处置的实际速度。
恢复验证通过率的分母用执行回滚的变更数，还是用全部失败变更数？
两种口径回答的问题不同。以执行回滚的变更数为分母，衡量的是回滚后的恢复质量，适合评估回滚预案和验证清单的有效性。以全部失败变更数为分母，会把未回滚的失败变更也纳入，数值被稀释，适合观察失败变更的整体恢复情况。报告里要写明用的是哪一种，同一份报告内不要混用，否则趋势对比会失真。
回滚决策确认时间和服务恢复正常时间以什么记录为准？
回滚决策确认时间以决策会议记录、值班群确认消息或工单状态变更时间为准；服务恢复正常时间以监控指标回到基线或验证人确认时间为准。两端都需要有可追溯的记录，事后回忆补录会让回滚耗时失真。建议在发布流程中把回滚决策和恢复验证设为固定节点，留下状态与时间戳，统计时直接取用。
四个指标算出来之后，怎么判断发布风险处置是否有效？
把四个指标放在同一时间窗内合起来看：失败率和回滚率反映风险暴露程度，回滚耗时反映处置速度，恢复验证通过率反映恢复质量。建议观察连续三个窗口的趋势，而不是单点数值。如果失败率下降但回滚耗时P90上升，说明失败变少、单次处置变慢，应检查预案执行环节；如果回滚率高但耗时短、验证通过率高，可能反映团队对失败变更果断止损。指标不构成因果保证，解读时需回到具体发布记录核对。
