1. MTTR 基础概念
1.1 MTTR 定义
MTTR（Mean Time to Repair，平均修复时间） 是衡量系统从故障发生到完全恢复所消耗平均时间的核心指标。在 SRE 实践中，MTTR 覆盖从故障被检测到、诊断、修复、验证到服务恢复正常运行的完整时间窗口。
MTTR 计算公式：
MTTR = 总修复时间 / 故障次数其中“修复时间”指从故障确认到服务恢复之间的时长，不包括故障等待被发现的空闲时间。
MTTR 的典型构成阶段包括：
- 检测时间（Detection Time）：从故障发生到告警触发的时间。
- 响应时间（Response Time）：从告警触发到工程师开始排查的时间。
- 诊断时间（Diagnosis Time）：定位根因所花费的时间。
- 修复时间（Fix Time）：执行修复操作的时间。
- 验证时间（Verification Time）：确认服务恢复正常的时间。
💡 关键认知：MTTR 不是单纯的“修代码时间”，而是从故障被感知到服务完全恢复的端到端时长。Prometheus 指标驱动的复盘优化，核心目标就是压缩 MTTR 中的检测和诊断环节。
1.2 MTTR 在 SRE 中的重要性
在 SRE 体系中，MTTR 是衡量故障响应效率和服务可靠性的关键指标。Google SRE 经典著作中将 MTTR 列为最重要的可用性工程指标之一，原因如下：
| 维度 | MTTR 的影响 | 说明 |
|---|---|---|
| 可用性 | 直接决定 SLA/SLO 达成 | MTTR 越长，故障期间不可用时间越长，可用性越低 |
| 用户体验 | 影响用户流失与信任 | 每次故障都是对用户信任的消耗，MTTR 越短损失越小 |
| 工程效率 | 决定故障处理成本 | 长 MTTR 意味着更多工程师时间被占用，影响迭代速度 |
| 复盘质量 | 驱动持续改进 | MTTR 数据是复盘的核心输入，指导自动化与流程优化 |
| 团队压力 | 影响值班健康度 | 高 MTTR 导致频繁告警疲劳和值班 burnout |
⚠️ 常见误区：很多团队只关注“故障是否修复”，而忽略了“修复花了多久”。没有 MTTR 量化，复盘就变成了“凭感觉改进”，无法形成可度量的闭环。Prometheus 指标驱动的复盘，正是要解决这个“不可度量”的问题。
1.3 MTTR 与 MTBF / MTTF 的区别
在可靠性工程中，MTTR、MTBF、MTTF 是三个容易混淆但含义完全不同的指标。理解它们的区别是进行有效复盘的前提。
| 指标 | 全称 | 定义 | 关注点 | 典型用途 |
|---|---|---|---|---|
| MTTR | Mean Time to Repair | 平均修复时间 | 故障恢复速度 | 评估响应效率、复盘优化 |
| MTBF | Mean Time Between Failures | 平均故障间隔时间 | 系统稳定性 | 评估系统可靠性、预测故障频率 |
| MTTF | Mean Time to Failure | 平均无故障时间 | 组件寿命 | 评估不可修复组件的可靠性 |
核心区别总结：
- MTTR 衡量的是“坏了之后多久能修好”——关注恢复速度。
- MTBF 衡量的是“两次故障之间隔多久”——关注系统稳定性。
- MTTF 衡量的是“一个组件能用多久才坏”——关注组件寿命（适用于不可修复场景）。
可用性公式中的关系：
可用性 = MTBF / (MTBF + MTTR)从公式可以看出：降低 MTTR 和提升 MTBF 都能提升可用性。但在实际 SRE 工作中，MTTR 的优化见效更快——因为 MTBF 的提升通常需要架构重构，而 MTTR 可以通过更好的可观测性和自动化快速改善。
🎯 复盘视角建议：在 Prometheus 指标驱动的 MTTR 复盘优化中，我们主要关注 MTTR 的拆解和压缩。MTBF 和 MTTF 作为辅助指标，用于评估优化措施是否对系统稳定性产生了负面影响（例如：过度追求低 MTTR 可能导致频繁重启掩盖了根本问题，反而降低 MTBF）。