MTTR 定义与拆解：MTTR = MTTD + MTTF + MTTR修复
在可观测性工程与 SRE 实践中，MTTR（Mean Time to Repair，平均修复时间）是衡量故障恢复效率的核心指标。然而，许多团队将 MTTR 简化为“从故障发生到恢复的总时长”，这种粗粒度的定义掩盖了故障处理各阶段的瓶颈。为了通过 Metric 设计驱动复盘与基线优化，必须将 MTTR 拆解为三个可测量、可追溯的子阶段：
核心公式： MTTR = MTTD + MTTF + MTTR修复
其中：
- MTTD（Mean Time to Detect）：平均发现时间，从故障发生到被监控系统或人工识别的时间窗口。
- MTTF（Mean Time to Triage）：平均定位/定界时间，从故障被识别到确定根因或影响范围的时间窗口。
- MTTR修复（Mean Time to Repair - Fix）：平均修复时间，从确定根因到服务完全恢复正常的时间窗口。
这种拆解方式将“黑盒”的 MTTR 转化为“白盒”的三段式流水线，每一段都可以独立设计 Metric、设定 SLO 基线，并驱动复盘改进。
1. MTTD：平均发现时间
MTTD 衡量的是从故障实际发生到系统或人感知到故障的时间差。这是故障处理流程的“第一道防线”，直接决定了故障影响扩散的程度。
| 维度 | 说明 | 典型 Metric 示例 |
|---|---|---|
| 定义起点 | 故障首次发生（用户可感知或系统内部异常） | 错误率突增、延迟 P99 超阈值、健康检查失败 |
| 定义终点 | 监控系统发出告警 / On-Call 工程师确认 | 告警触发时间戳、PagerDuty 确认时间 |
| 常见瓶颈 | 监控覆盖率不足、告警阈值过松、告警路由错误 | MTTD 中位数 > 5min 需复盘 |
基线建议： 对于核心服务（如支付、登录），MTTD 基线应设定在 ≤ 2 分钟；对于非核心服务，可放宽至 5-10 分钟。通过 Metric 持续追踪 MTTD 的 P50/P90/P99，识别“发现延迟”的异常模式。
2. MTTF：平均定位/定界时间
MTTF 是故障处理中最“烧脑”的阶段，从告警确认到确定根因或至少确定影响范围（定界）。此阶段的长短高度依赖可观测性数据的关联能力和团队的排障经验。
| 维度 | 说明 | 典型 Metric 示例 |
|---|---|---|
| 定义起点 | 告警确认 / 故障工单创建 | 告警 Ack 时间、Jira 创建时间 |
| 定义终点 | 根因定位完成 / 确定回滚或修复方案 | Root Cause 标签添加时间、回滚决策时间 |
| 常见瓶颈 | 缺乏分布式追踪、日志/指标/事件割裂、知识库陈旧 | MTTF 中位数 > 15min 需优化 |
避坑提示： 不要将 MTTF 与 MTTR修复 混为一谈。许多团队在复盘时把“定位+修复”合并统计，导致无法区分是“找不到原因”还是“修得慢”。必须通过时间戳精确切分。
3. MTTR修复：平均修复时间
MTTR修复 是从确定修复方案到服务完全恢复正常的时间。此阶段强调执行效率，包括变更操作、回滚、扩容、配置修改等动作。
| 维度 | 说明 | 典型 Metric 示例 |
|---|---|---|
| 定义起点 | 根因定位完成 / 修复决策下达 | 变更审批通过时间、回滚脚本执行开始时间 |
| 定义终点 | 服务恢复正常（SLO 达标 / 错误率归零） | 错误率恢复至基线、延迟 P99 回落到阈值内 |
| 常见瓶颈 | 变更审批流程过长、回滚自动化缺失、依赖人工编译部署 | MTTR修复 中位数 > 10min 需自动化 |
4. 三阶段拆解的复盘价值
将 MTTR 拆解为 MTTD + MTTF + MTTR修复 后，复盘会议不再笼统地问“为什么恢复这么慢”，而是可以精准定位到具体阶段：
- 如果 MTTD 占比过高（例如占总 MTTR 的 40% 以上）：说明监控体系存在盲区或告警延迟，需要优先优化告警规则、增加指标覆盖、引入异常检测。
- 如果 MTTF 占比过高：说明排障效率低下，需要建设分布式追踪、统一可观测性数据面、维护排障 Runbook。
- 如果 MTTR修复 占比过高：说明变更/回滚流程存在摩擦，需要推进基础设施即代码（IaC）、自动化回滚、灰度发布。
Metric 设计驱动复盘： 每个阶段都应设计独立的 SLO 和错误预算。例如：
• MTTD SLO：99% 的故障在 3 分钟内被检测到。
• MTTF SLO：95% 的故障在 15 分钟内完成定位。
• MTTR修复 SLO：99% 的修复操作在 10 分钟内完成。
当某个阶段的 SLO 持续违反时，对应的 Metric 基线就需要调整，并触发专项改进。
• MTTD SLO：99% 的故障在 3 分钟内被检测到。
• MTTF SLO：95% 的故障在 15 分钟内完成定位。
• MTTR修复 SLO：99% 的修复操作在 10 分钟内完成。
当某个阶段的 SLO 持续违反时，对应的 Metric 基线就需要调整，并触发专项改进。
5. 时间戳对齐：确保拆解可测量
拆解的前提是每个阶段都有精确的时间戳。推荐在故障管理平台（如 PagerDuty、Opsgenie）和可观测性平台中记录以下关键事件：
| 事件 | 对应阶段 | 记录方式 |
|---|---|---|
fault_occurred_at |
MTTD 起点 | 由异常检测算法或用户反馈标记 |
alert_fired_at |
MTTD 终点 / MTTF 起点 | 监控系统自动记录 |
root_cause_identified_at |
MTTF 终点 / MTTR修复 起点 | 工程师手动标记或自动化分析完成 |
service_recovered_at |
MTTR修复 终点 | SLO 指标恢复至阈值内 |
实践建议： 在故障复盘文档中，强制要求填写上述四个时间戳。通过脚本自动计算 MTTD、MTTF、MTTR修复，并生成趋势图。当某个阶段的 P90 持续恶化时，自动触发告警到 SRE 团队。