MTTR 基础概念：平均修复时间
1. MTTR 的定义
平均修复时间（Mean Time To Repair，MTTR）是衡量故障从发生到完全恢复所消耗平均时间的核心指标。它反映了组织在故障响应与修复环节的整体效率，是 SRE 实践中最重要的可用性度量之一。
MTTR 的计算公式为：
MTTR = 故障修复总耗时 / 故障次数其中“修复总耗时”指从故障被确认（或首次告警触发）到服务完全恢复正常所经过的时间。MTTR 越低，说明团队的故障处理能力越强，对用户的影响越小。
关键认知： MTTR 并非仅指“动手修”的时间，而是覆盖从故障感知到最终恢复的完整时间窗口。缩短 MTTR 需要系统性优化整个故障处理链路。
2. MTTR 的三大组成部分
MTTR 可拆解为三个核心阶段，每个阶段都有独立的优化空间。下表列出了各阶段的定义、典型活动及常见瓶颈：
| 阶段 | 定义 | 典型活动 | 常见瓶颈 |
|---|---|---|---|
| 检测时间 | 从故障发生到被监控系统或人工发现的时间 | 告警触发、日志分析、用户反馈收集 | 监控盲区、告警延迟、阈值设置不合理 |
| 响应时间 | 从故障确认到第一响应人开始处理的时间 | 告警分派、On-Call 人员确认、故障定级 | 响应人未及时接听、定级流程冗长、信息传递断层 |
| 修复时间 | 从开始处理到服务完全恢复正常的时间 | 根因定位、代码回滚、配置变更、重启服务 | 缺乏 Runbook、依赖人工排查、变更审批慢 |
实践建议： 在复盘时，应将每次故障的 MTTR 按上述三阶段拆解记录，以便精准定位耗时最长的环节，制定针对性改进措施。
3. MTTR 在故障管理中的重要性
MTTR 是衡量故障管理成熟度的关键标尺，其重要性体现在以下四个方面：
- 直接影响可用性： 在 SLO 框架下，MTTR 越长，故障期间消耗的错误预算越多，可用性越容易超标。
- 反映团队协作效率： 低 MTTR 通常意味着清晰的响应流程、完善的自动化工具和高效的跨团队协作。
- 驱动持续改进： 通过追踪 MTTR 趋势，团队可以量化改进效果，例如引入自动化告警压缩后检测时间是否缩短。
- 关联用户体验： 故障恢复越快，用户感知到的负面影响越小，对业务连续性的保障越强。
常见误区： 不要只关注“修复时间”而忽略“检测时间”和“响应时间”。在很多故障案例中，检测和响应阶段占据了 MTTR 的 60% 以上，是最大的优化空间。
4. MTTR 组成部分的流程关系
下图展示了 MTTR 三阶段在故障时间轴上的串联关系，以及各阶段之间的衔接点：
5. MTTR 与 SLO 的关联
在 SRE 实践中，MTTR 直接影响 SLO 的达成。故障持续时间越长，消耗的错误预算越多。下表展示了不同 MTTR 水平对月度 99.9% SLO 的影响：
| MTTR | 单次故障消耗错误预算 | 月度允许故障次数（近似） | 风险等级 |
|---|---|---|---|
| 5 分钟 | 0.01% | 约 86 次 | 低风险 |
| 30 分钟 | 0.06% | 约 14 次 | 中风险 |
| 2 小时 | 0.27% | 约 3 次 | 高风险 |
| 4 小时 | 0.55% | 约 1 次 | 极高风险 |
复盘启示： 将 MTTR 拆解为检测、响应、修复三部分后，可以针对每个阶段设定独立的 SLO（例如“检测时间 SLO ≤ 5 分钟”），并在复盘中评估各阶段是否达标，从而驱动精准改进。