MTTR 是什么
MTTR 有两种展开：Mean Time To Repair（平均修复时间）与 Mean Time To Recovery（平均恢复时间）。运维语境里更常用恢复口径：从故障发生到服务恢复可用、告警解除的平均时长，覆盖发现、响应、定位、修复、验证全链路。它衡量故障处置能力，前提是起始与结束时间点的定义全组织统一，否则报表没有意义。
基本信息
| 起点定义 | 故障发生时间、首次告警时间或开始影响用户的时间，须明确其一 |
|---|---|
| 终点定义 | 服务恢复可用、监控恢复正常、用户侧确认，口径要统一 |
| 相关指标 | MTBF 平均无故障间隔；MTTF 平均失效前时间；可用性 = MTBF ÷（MTBF + MTTR） |
| 分层统计 | 按严重度分级，P1 与 P3 的恢复时长不可混算出平均 |
| 缩短手段 | 值班与升级机制、告警质量、预案演练、快速回滚、可观测性 |
| 记录载体 | 故障工单或事件时间线，保留各阶段时间戳 |
典型使用场景
- 故障复盘：把 MTTR 拆成发现、响应、修复、验证四段，找最长瓶颈段。
- 值班改进：响应时长超标时，排查告警触达渠道与值班覆盖问题。
- 预案建设：恢复慢源于缺少回滚与降级手段时，优先补预案。
- 目标设定：按严重度设定恢复目标并与服务等级承诺对齐。
- 工具评估：对比引入新监控后，发现与定位阶段时长的变化。
阶段拆分与观察点
| 阶段 | 从到 | 瓶颈信号 |
|---|---|---|
| 发现 | 故障发生到告警触发 | 靠用户报障才知道 |
| 响应 | 告警触发到有人投入 | 值班电话没人接 |
| 定位 | 开始处理到锁定原因 | 靠猜和试错 |
| 修复 | 锁定原因到变更完成 | 依赖手工发版 |
| 验证 | 变更完成到确认恢复 | 缺少验证清单 |
均值会被极端故障拉偏：同时看中位数与最长的那几次事件。
缩短 MTTR 不能靠改统计：把恢复点定义挪到告警解除而不是用户恢复，数字好看但没用。
预案要真演练：演练能显著压降真实故障时的慌乱成本，文档存放不等于能力。