2. MTTR 基础概念
2.1 MTTR 定义
MTTR（Mean Time to Repair，平均修复时间） 是衡量系统从发生故障到完全恢复服务所消耗的平均时间。在 SRE 实践中，MTTR 是核心可靠性指标之一，直接反映团队对故障的响应与修复效率。
MTTR 公式：
MTTR = 总修复时间 ÷ 故障次数
示例： 某月发生 4 次故障，修复时间分别为 15min、20min、10min、15min，则 MTTR = (15+20+10+15) ÷ 4 = 15 分钟。
MTTR = 总修复时间 ÷ 故障次数
示例： 某月发生 4 次故障，修复时间分别为 15min、20min、10min、15min，则 MTTR = (15+20+10+15) ÷ 4 = 15 分钟。
MTTR 并非仅指“修好代码”的时间，而是从故障发生到服务完全恢复正常所经历的全部阶段。SRE 团队通常将 MTTR 拆解为四个核心构成要素，以便精准定位瓶颈。
2.2 MTTR 构成要素
| 阶段 | 定义 | 典型耗时占比 | 优化方向 |
|---|---|---|---|
| 检测（Detection） | 从故障发生到监控系统发出告警的时间 | 20% – 30% | 缩短监控粒度、提升告警准确率 |
| 诊断（Diagnosis） | 从收到告警到定位根因的时间 | 30% – 50% | 自动化诊断、可观测性建设 |
| 修复（Repair） | 从定位根因到执行修复操作的时间 | 15% – 25% | 自助修复脚本、服务降级/熔断 |
| 验证（Verification） | 从修复完成到确认服务完全恢复的时间 | 5% – 10% | 自动化验证、健康检查 |
关键洞察： 诊断阶段通常占据 MTTR 的最大比例。通过服务降级与熔断机制，可以在诊断未完成时先恢复核心功能，从而大幅压缩修复与验证时间。
2.3 MTTR 与系统可用性的关系
系统可用性（Availability）通常用 SLA（Service Level Agreement） 中的“几个九”来衡量。MTTR 与 MTBF（平均故障间隔时间）共同决定可用性：
可用性公式：
Availability = MTBF ÷ (MTBF + MTTR) × 100%
示例： 若 MTBF = 720 小时（30 天），MTTR = 1 小时，则可用性 = 720 ÷ 721 ≈ 99.86%（约两个九）。
Availability = MTBF ÷ (MTBF + MTTR) × 100%
示例： 若 MTBF = 720 小时（30 天），MTTR = 1 小时，则可用性 = 720 ÷ 721 ≈ 99.86%（约两个九）。
从公式可以看出，降低 MTTR 可以直接提升可用性，尤其在 MTBF 固定的情况下，MTTR 的微小改善就能带来可用性等级的跃升。
| 可用性等级 | 年停机时间 | MTTR 目标（MTBF=720h） | 典型场景 |
|---|---|---|---|
| 99.9%（三个九） | 8.76 小时 | ≤ 43 分钟 | 企业级应用 |
| 99.99%（四个九） | 52.56 分钟 | ≤ 4.3 分钟 | 金融交易系统 |
| 99.999%（五个九） | 5.26 分钟 | ≤ 26 秒 | 电信核心网 |
注意： 仅靠降低 MTTR 无法达到五个九可用性，还需要配合 MTBF 的提升（即减少故障发生频率）。服务降级与熔断主要作用于 MTTR 的修复与验证阶段，是快速止损的关键手段。
2.4 自助服务与 MTTR 优化的关联
自助服务能力（如自动化降级、一键熔断、预置修复脚本）直接作用于 MTTR 的 修复 与 验证 阶段：
- 自助降级： 非核心功能自动关闭，核心链路保持可用，避免全站宕机。
- 自助熔断： 检测到依赖服务异常时自动切断流量，防止级联故障。
- 自助验证： 修复后自动执行健康检查与回归测试，无需人工确认。
实战建议： 将服务降级与熔断操作封装为自助服务 API 或 ChatOps 命令，使 SRE 或开发人员可在 30 秒内完成修复操作，将 MTTR 从小时级压缩到分钟级。