4. MTTR 复盘口径设计原则：可量化、可追溯、可对比、可改进

MTTR（Mean Time to Repair）是衡量蓝绿发布故障恢复效率的核心指标。然而，若复盘口径设计不严谨，MTTR 极易沦为“数字游戏”——不同团队对“开始时间”与“结束时间”的定义各异，导致数据失真、决策偏差。本章定义 MTTR 复盘口径的四大设计原则，并给出可落地的量化模型与追溯机制。

4.1 四大原则定义与对比

4.2 避免主观偏差与幸存者偏差

在复盘过程中，两种常见偏差会严重扭曲 MTTR 的真实分布：

• 主观偏差： 操作者倾向于低估自己的恢复时间，或高估自己在故障中的决策正确性。例如：“我几乎立刻就发现了问题”——实际从告警到确认耗时 3 分钟。
• 幸存者偏差： 只复盘“最终成功恢复”的案例，忽略了那些因回滚失败、数据损坏导致长时间故障的“沉默数据”。例如：只统计了 10 次快速回滚，却漏掉了 1 次耗时 2 小时的数据库修复。

4.3 MTTR 复盘口径的量化模型

为了满足“可量化”与“可追溯”，我们定义标准化的 MTTR 阶段分解模型。每个阶段都有明确的触发事件与结束事件。

MTTR 阶段分解（单位：秒）
----------------------------------------
T0  = 故障触发时间（监控告警产生）
T1  = 故障确认时间（值班人员 Acknowledge）
T2  = 决策开始时间（回滚/切换指令下达）
T3  = 操作完成时间（流量 100% 切回旧版本）
T4  = 业务恢复确认时间（健康检查通过）

阶段耗时：
- 发现耗时  = T1 - T0
- 决策耗时  = T2 - T1
- 执行耗时  = T3 - T2
- 验证耗时  = T4 - T3
- 总 MTTR   = T4 - T0

4.4 渐进式验证与口径校准

MTTR 口径并非一成不变。随着蓝绿发布成熟度提升，口径需要渐进式校准：

1. 阶段一（初始期）： 仅统计“从告警到回滚完成”的粗粒度 MTTR，用于建立基线。
2. 阶段二（优化期）： 拆分为发现、决策、执行、验证四个子阶段，定位瓶颈。
3. 阶段三（自动化期）： 引入“自动回滚触发率”与“人工干预次数”作为辅助指标，修正 MTTR 的幸存者偏差。

以下 SVG 展示了 MTTR 复盘口径的完整数据流与阶段分解：

4.5 可追溯性落地：事件链与审计日志

为了实现“可追溯”，每个 MTTR 阶段必须关联以下信息：

• 事件 ID： 全局唯一标识，关联到具体的发布批次。
• 操作人/系统： 人工操作记录工号，自动化操作记录触发器名称。
• 上下文快照： 故障时刻的流量比例、错误率、延迟数据。
• 变更记录： 回滚前后的版本号、配置 diff。

4.6 可改进性：从复盘到自动化闭环

MTTR 复盘的根本目的是驱动改进。我们建议将复盘结论转化为具体的 Action：