1. MTTR 基础概念
在 SRE 与运维体系中，MTTR（Mean Time to Repair，平均修复时间）是衡量故障响应与恢复效率的核心指标。它直接决定了故障对用户的影响时长，也是变更窗口、On-Call 流程优化的最终目标。
1.1 MTTR 定义
MTTR 指从系统发生故障到完全恢复服务所消耗的平均时间。它覆盖了从告警触发、故障确认、定位根因、执行修复到验证恢复的完整链路。
| 阶段 | 说明 | 典型耗时占比 |
|---|---|---|
| 检测（Detection） | 从故障发生到监控系统发出告警 | 10% – 20% |
| 响应（Response） | On-Call 工程师收到告警并开始介入 | 5% – 15% |
| 诊断（Diagnosis） | 定位故障根因、确定修复方案 | 40% – 60% |
| 修复（Repair） | 执行变更、回滚或重启等恢复操作 | 10% – 20% |
| 验证（Verification） | 确认服务指标恢复正常、用户无感知 | 5% – 10% |
关键认知：MTTR 不是单纯的“修机器时间”，而是从故障发生到服务完全恢复的端到端时长。诊断阶段通常占比最高，是降低 MTTR 的主要发力点。
1.2 MTTR 与 MTBF / MTTF 的关系
在可靠性工程中，MTTR 与 MTBF（Mean Time Between Failures，平均故障间隔时间）、MTTF（Mean Time to Failure，平均故障前时间）共同构成系统可用性计算的基础。
| 指标 | 定义 | 适用场景 | 与 MTTR 的关系 |
|---|---|---|---|
| MTBF | 两次故障之间的平均正常运行时间 | 可修复系统（如服务器、数据库集群） | MTBF 越大，系统越稳定；MTTR 越小，恢复越快 |
| MTTF | 系统首次发生故障前的平均运行时间 | 不可修复系统（如一次性传感器、SSD 寿命） | MTTF 决定寿命，MTTR 不适用（无法修复） |
| MTTR | 故障发生后恢复服务的平均时间 | 所有可修复系统 | 与 MTBF 共同决定可用性：A = MTBF / (MTBF + MTTR) |
可用性公式：A = MTBF / (MTBF + MTTR)。即使 MTBF 很高，如果 MTTR 过长，可用性依然会显著下降。例如 MTBF = 720h（30天），MTTR = 8h，可用性 = 720 / 728 ≈ 98.9%，仅达到“两个9”级别。
1.3 MTTR 对业务连续性的影响
MTTR 是业务连续性的“刹车距离”。在变更窗口驱动的 On-Call 场景中，每一次变更都可能引入故障，而 MTTR 决定了故障窗口的宽度。
- 用户感知时长：MTTR 每延长 1 分钟，受影响的用户就多承受 1 分钟的服务降级或中断。对于高并发在线业务，这直接转化为收入损失与用户流失。
- SLA/SLO 达标率：可用性公式 A = MTBF / (MTBF + MTTR) 中，MTTR 是分母的一部分。在 MTBF 固定的情况下，MTTR 翻倍，可用性从 99.9% 可能跌至 99.8%，触发 SLA 赔偿。
- 变更风险累积：高 MTTR 意味着每次故障恢复缓慢，工程师在压力下容易引入二次故障，形成“故障叠加”效应，进一步拉长恢复时间。
- 团队信任与疲劳：频繁的长耗时故障会消耗 On-Call 团队的精力与信心，导致响应延迟、判断失误，形成恶性循环。
常见误区：很多团队只关注 MTBF（系统稳定性），却忽视 MTTR（恢复效率）。实际上，在变更频繁的互联网系统中，MTTR 对可用性的影响往往比 MTBF 更显著——因为变更本身就是故障的主要诱因，而快速恢复才是保障连续性的关键。