1. MTTR 基础概念
1.1 MTTR 定义
MTTR（Mean Time to Repair，平均修复时间） 是 SRE 领域衡量故障响应效率的核心指标，代表从系统发生故障到完全恢复服务所消耗的平均时长。MTTR 越低，说明团队发现故障越快、定位根因越准、恢复操作越高效。
在事故管理中，MTTR 并非单一数值，而是由多个子阶段串联而成的端到端时间窗口。每个子阶段都有独立的优化空间，只有拆解到子指标才能精准驱动改进。
核心公式： MTTR = MTTI + MTTK + MTTF
1.2 MTTR 的组成
MTTR 可拆解为三个关键子指标，分别对应故障响应链路上的不同阶段：
| 子指标 | 全称 | 定义 | 优化方向 |
|---|---|---|---|
| MTTI | Mean Time to Identify | 从故障发生到被监控系统或人工发现的时间 | 监控覆盖率、告警延迟、告警噪声过滤 |
| MTTK | Mean Time to Know | 从发现故障到定位根因的时间 | 可观测性、日志分析、链路追踪、知识库 |
| MTTF | Mean Time to Fix | 从定位根因到服务完全恢复的时间 | 自动化恢复、变更回滚、应急预案、权限就绪 |
实践提示： 多数团队在 MTTI 和 MTTK 上浪费了 60% 以上的故障响应时间。优先优化这两个阶段，通常能以较低成本获得显著的 MTTR 缩减。
1.3 MTTR 在 SRE 中的重要性
MTTR 是 SRE 四大黄金信号（延迟、流量、错误、饱和度）之外最关键的效率指标。它直接反映团队对故障的掌控能力，并影响以下三个维度：
- 用户信任： 每次故障都是一次信任危机。MTTR 越短，用户感知到的不可用窗口越小，信任恢复越快。
- 业务成本： 故障每分钟都在产生直接经济损失（交易中断、SLA 罚款、客户流失）。MTTR 每缩短 1 分钟，都可能挽回数十万甚至更高的损失。
- 团队疲劳度： 长 MTTR 意味着长时间的高压响应，容易导致 on-call 疲劳、判断力下降、二次故障风险上升。缩短 MTTR 就是保护团队健康。
常见误区： 不要只盯着 MTTR 的最终数值。如果团队为了降低 MTTR 而跳过根因分析、采用临时重启或扩容等治标不治本的手段，长期来看会积累技术债，导致故障复发率上升。
1.4 MTTR 组成流程图
下图展示了 MTTR 的完整时间线拆解，帮助理解每个子阶段在故障响应链路中的位置：
1.5 子指标对比速查表
下表从优化难度、常见瓶颈、典型工具三个维度对比三个子指标，便于团队制定优先级：
| 维度 | MTTI | MTTK | MTTF |
|---|---|---|---|
| 优化难度 | 低（增加监控即可见效） | 中（依赖可观测性基建） | 高（需要自动化与流程沉淀） |
| 常见瓶颈 | 告警延迟、告警风暴、非工作时间无人值守 | 日志分散、缺乏链路追踪、知识库缺失 | 手动操作、变更审批慢、回滚脚本不完善 |
| 典型工具 | Prometheus + Alertmanager、PagerDuty | Grafana、Jaeger、ELK Stack | Ansible、Spinnaker、Kubernetes Rollback |
| 对 MTTR 贡献 | 约 25% | 约 35% | 约 40% |