指标一：分段恢复时长
记录从告警触发到业务确认恢复的总时长，再拆成发现、决策、执行、验证四段。为什么要拆：总时长只能说明慢，分段才能说明慢在哪，是监控不灵敏、签字流程太长，还是执行人手不够，对应的改进动作完全不同。
指标二：回滚成功率
统计计划内回滚中一次成功的比例，以及失败后走了哪条兜底路径。怎么做：把每次回滚的事件单标注结果类型，例如一次成功、重试成功、快照恢复、降级替代，按季度汇总看趋势，比单次结论更有意义。
指标三：演练发现项
演练的价值在于暴露问题，因此要统计发现项数量与关闭率，而不是统计演练次数。为什么：只考核次数会得到走过场的演练，考核发现项才会有人认真设计故障场景，这个口径直接决定演练质量。
指标四：误触发比例
有些回滚是由误报告警或口径不一致触发的，这类空回滚同样消耗窗口与信任。怎么区分：复盘时区分该回未回与不该回却回，前者补阈值，后者修监控与判定规则，两类问题的负责人往往不是同一批人。
指标怎么用才不跑偏
度量容易滑向对内问责，一旦如此，团队倾向于少报事件或延后登记，数据反而失真。建议把指标用于改进流程与资源投入，复盘聚焦机制缺项；对外汇报只讲趋势与已完成的改进行动，不拿单一数字给个人排名，也不承诺未经验证的时长。
适用与不适用
适合谁
- 需要向上汇报上线稳定性的技术负责人
- 正在建设运维与恢复度量体系的团队
- 多项目并行、要比较不同系统恢复能力的集团 IT
不适合谁
- 尚无生产流量、没有事件记录的项目
- 只关心单次事故结论、不做长期度量的组织
典型场景
某能源集团的信息部把三个 AI 应用的恢复时长、回滚成功率与演练发现项按月汇总。两个月后看出问题集中在决策段而非执行段，于是调整授权规则；下一季度同类事件的平均恢复时长明显收敛，误触发比例也同步下降。
可执行步骤
- 在事件单模板中固定记录四段耗时、结果类型与所用的兜底路径名称。
- 每季度汇总成功率与兜底路径的使用次数，观察趋势变化并与上期对比。
- 演练后逐项登记发现项、责任人与关闭状态，考核关闭率而非次数。
- 复盘时区分该回未回与不该回却回，分别制定改进动作、责任人与时限。
- 连续记录形成自身基线后，再据此设定下一阶段的改进目标与复盘节点。
常见坑
- 只统计事故数量，不记录恢复过程，无法判断方案是否真的改善了响应能力，汇报时也说不清依据。
- 把演练次数当成绩，场景年年雷同，真正的风险点从未被覆盖到，出事时才发现方案没写过。
- 指标口径随负责人变动，同比数据失去意义，汇报时被质疑统计可信度，跨期比较只能作废。
- 只考核时长不考核业务影响，团队倾向选择快但不彻底的处理方式，问题被延后到下一轮爆发。
自检与验收清单
- 事件单是否固定记录四段耗时、结果类型与兜底路径
- 回滚结果是否按一次成功、重试、兜底等类型登记
- 演练发现项是否登记责任人与关闭状态及期限
- 指标定义与统计口径是否书面固定并跨期一致
- 是否已积累足够历史数据形成自身的基线区间
常见问题
没有历史数据怎么定目标？
先做基线采集，不急着定目标值。连续记录若干次真实事件与演练后，取中位数作为起点，再设定改进方向，例如缩短决策段。对外承诺前应使用实测值，而不是行业传闻的数字。
演练没发现问题算好事吗？
通常要警惕。没有发现往往说明场景设计过于温和或检查项太粗。可以刻意设计依赖失败、数据错乱、人员缺席等组合场景，逼出真实薄弱点；连续多轮零发现时，应重新审查演练设计。
回滚指标要不要进考核？
可以进，但要避免只考时长。建议同时看业务影响范围与兜底路径使用比例，否则容易诱导团队掩盖问题、延迟上报。指标的目的是改进流程，而不是排名，这一条要在制度里写明。