4. MTTR复盘口径定义：从故障发现、故障定位、故障恢复三个阶段拆解MTTR
在微服务架构中，故障排查的时效性直接决定业务损失。MTTR（Mean Time to Repair，平均修复时间）是衡量故障处理效率的核心指标。然而，若不对MTTR进行阶段拆解，复盘将流于形式。本章定义MTTR的三阶段拆解口径，明确每个阶段的起始与结束标志，为后续的分布式追踪数据对齐提供精确的时间锚点。
4.1 MTTR三阶段拆解模型
我们将MTTR拆解为故障发现、故障定位、故障恢复三个阶段。每个阶段对应不同的SRE动作和可观测性数据源。下图展示了三阶段的串联关系及关键时间点。
4.2 阶段一：故障发现（T0 → T1）
定义：从故障实际发生（T0）到系统产生明确告警并被SRE值班人员确认（T1）的时间间隔。该阶段反映监控覆盖率和告警时效性。
| 标志类型 | 起始标志（T0） | 结束标志（T1） |
|---|---|---|
| 定义 | 故障首次对业务产生可观测影响的时间点 | 监控系统发出告警，且值班人员确认收到 |
| 可观测性证据 | 错误率突增、延迟飙升、流量归零、业务日志报错 | Prometheus Alertmanager 通知、PagerDuty 事件、钉钉/飞书告警 |
| 分布式追踪锚点 | 首个异常 Span 的时间戳 | 告警事件中关联的 Trace ID 时间戳 |
| 常见延迟原因 | 监控采样周期过长、无黄金指标 | 告警静默期、值班轮换交接、告警风暴淹没 |
复盘要点：若 T0 无法精确获取，可使用“首个用户报障时间”作为近似值，但需在复盘报告中标注误差。分布式追踪的 Trace 开始时间是最接近真实 T0 的数据源。
4.3 阶段二：故障定位（T1 → T2）
定义：从告警确认（T1）到SRE团队明确故障根因（T2）的时间间隔。该阶段是MTTR中最具优化潜力的部分，直接依赖分布式追踪的链路分析能力。
| 标志类型 | 起始标志（T1） | 结束标志（T2） |
|---|---|---|
| 定义 | 值班人员确认告警并开始排查 | 定位到具体故障服务、接口或代码行 |
| 可观测性证据 | 告警事件状态变更为“Acknowledged” | 根因分析报告、Trace 中标记的异常 Span |
| 分布式追踪锚点 | 告警关联的 Trace 开始查询时间 | 识别出错误 Span 的 Service Name + Operation Name |
| 常见延迟原因 | 缺乏端到端 Trace、日志与指标割裂 | 依赖人工逐级排查、调用链深度过大 |
关键指标：定位阶段应追求“5分钟内根因识别”。若 T2 - T1 > 15 分钟，复盘时必须分析分布式追踪的查询链路是否完整，是否存在“Trace 断裂”或“采样率不足”问题。
4.4 阶段三：故障恢复（T2 → T3）
定义：从根因确认（T2）到业务指标恢复正常（T3）的时间间隔。该阶段包含修复决策、变更执行和验证确认。
| 标志类型 | 起始标志（T2） | 结束标志（T3） |
|---|---|---|
| 定义 | 根因已确认，开始执行修复动作 | 业务黄金指标（错误率、延迟、吞吐量）恢复至基线 |
| 可观测性证据 | 变更工单创建、回滚指令发出 | 监控面板指标连续5分钟处于正常范围 |
| 分布式追踪锚点 | 修复操作开始时间 | 最新正常 Trace 的结束时间 |
| 常见延迟原因 | 修复方案评审、变更审批流程 | 灰度发布等待、缓存预热、依赖服务恢复慢 |
注意：恢复阶段结束标志（T3）不是“服务重启完成”，而是“业务指标恢复”。分布式追踪应验证恢复后的 Trace 是否全部正常，避免“假恢复”导致二次故障。
4.5 三阶段口径汇总与复盘公式
将三个阶段的口径统一为可计算的复盘公式，便于在分布式追踪平台中自动提取时间戳。
MTTR = T3 - T0
其中：
T0 = 首个异常 Trace 的开始时间（或首个错误 Span 的时间戳）
T1 = 告警事件被确认的时间（从告警系统 API 获取）
T2 = 根因 Span 被标记为“Root Cause”的时间（人工或自动标注）
T3 = 最后一个异常 Trace 结束时间 + 5分钟稳定窗口
阶段分解：
MTTD（平均发现时间）= T1 - T0
MTTI（平均定位时间）= T2 - T1
MTTR（平均恢复时间）= T3 - T24.6 口径落地检查清单
在微服务故障复盘会议前，SRE团队应使用以下清单验证MTTR口径的准确性：
- 时间源一致性：所有阶段时间戳必须来自同一时钟源（推荐使用NTP同步的分布式追踪时间戳）。
- Trace完整性：确保故障期间的Trace采样率不低于100%，避免因采样导致T0丢失。
- 告警关联：每个告警事件必须携带关联的Trace ID，否则T1无法与T0对齐。
- 根因标注：在分布式追踪平台中强制标注“Root Cause Span”，否则T2依赖人工回忆。
- 恢复验证：T3必须基于业务指标，而非基础设施指标。例如，错误率恢复至1%以下，而非CPU使用率下降。
最佳实践：在Jaeger或Zipkin中创建“MTTR复盘Dashboard”，自动计算每次故障的T0、T1、T2、T3，并生成阶段耗时柱状图。这能将复盘从“手动翻日志”升级为“数据驱动”。