1. MTTR 基础概念
1.1 MTTR 定义
MTTR（Mean Time To Repair，平均修复时间） 是衡量系统从发生故障到恢复正常服务所花费平均时间的核心指标。在 SRE 实践中，MTTR 通常涵盖从故障被检测到、诊断定位、执行修复操作，到最终验证服务恢复的完整周期。
| 阶段 | 说明 | 典型耗时占比 |
|---|---|---|
| 检测（Detection） | 监控告警触发，确认故障发生 | 10% – 20% |
| 诊断（Diagnosis） | 定位根因，分析影响范围 | 40% – 60% |
| 修复（Repair） | 执行恢复操作，如回滚、扩容、重启 | 20% – 30% |
| 验证（Verification） | 确认服务指标恢复正常 | 5% – 10% |
关键认知：MTTR 不是单纯的“修机器时间”，而是从故障发生到服务完全恢复的端到端时长。缩短 MTTR 的核心在于压缩诊断阶段，这也是 Runbook 联动方案的主要发力点。
1.2 MTTR 在 SRE 中的重要性
SRE 以 服务可用性 为最终目标，而 MTTR 直接影响可用性计算公式中的分母——总故障时长。在相同的故障频率下，MTTR 越低，全年累计不可用时间越短，SLO 达成率越高。
- 直接影响可用性： 可用性 = Uptime / (Uptime + Downtime)，MTTR 直接决定单次故障的 Downtime 长度。
- 降低故障影响面： 快速恢复意味着更少的用户请求失败、更少的数据不一致窗口。
- 提升团队响应效率： 标准化的修复流程（Runbook）减少人为决策延迟，降低“救火”压力。
- 支撑自动化能力建设： MTTR 是衡量自动化修复效果的关键指标，驱动持续改进。
SRE 黄金信号关联： MTTR 与“延迟（Latency）”和“错误率（Error Rate）”直接耦合——故障期间延迟飙升、错误率上升，MTTR 越长，对用户体验的损害越大。
1.3 MTTR 与 MTBF / MTTF 的关系
在可靠性工程中，MTTR 通常与 MTBF（Mean Time Between Failures，平均故障间隔时间） 和 MTTF（Mean Time To Failure，平均故障前时间） 共同使用，构成系统可靠性的完整评估框架。
| 指标 | 全称 | 定义 | 关注点 |
|---|---|---|---|
| MTBF | Mean Time Between Failures | 两次相邻故障之间的平均时间 | 系统稳定性、故障频率 |
| MTTF | Mean Time To Failure | 系统从开始运行到首次故障的平均时间 | 不可修复系统的寿命 |
| MTTR | Mean Time To Repair | 从故障发生到恢复的平均时间 | 恢复速度、运维效率 |
对于可修复系统，稳态可用性 的经典计算公式为：
Availability = MTBF / (MTBF + MTTR)该公式揭示了两个优化方向：
- 提升 MTBF： 通过架构优化、代码质量、混沌工程减少故障发生频率。
- 降低 MTTR： 通过自动化诊断、Runbook 联动、快速回滚缩短恢复时间。
常见误区： 只关注 MTBF 而忽视 MTTR，会导致“故障少但每次故障恢复极慢”的局面，可用性依然无法达标。SRE 实践要求两者并重，尤其在故障不可避免的分布式系统中，降低 MTTR 往往比提升 MTBF 更具短期可操作性。
1.4 三者协同优化策略
在实际 SRE 工作中，MTTR、MTBF、MTTF 并非孤立指标，而是构成一个完整的可靠性评估体系。下表总结了针对不同场景的优化重点：
| 场景 | 优先优化指标 | 典型手段 |
|---|---|---|
| 频繁出现短时故障 | MTBF ↑ | 代码审查、单元测试、混沌工程、限流降级 |
| 故障次数少但恢复极慢 | MTTR ↓ | 自动化 Runbook、GitLab CI 联动、一键回滚、诊断脚本 |
| 不可替换硬件/组件 | MTTF ↑ | 冗余设计、降级运行、预测性维护 |
| 追求高可用性（99.99%+） | MTBF ↑ + MTTR ↓ | 全链路可观测性 + 自动化故障自愈 |
课程定位： 本课程《MTTR 优化：GitLab CI 管道 Runbook 联动方案》专注于 降低 MTTR，通过将 Runbook 自动化嵌入 CI/CD 管道，实现故障诊断与修复的标准化、可重复、可审计，从而显著压缩从故障检测到服务恢复的时间窗口。