恢复时长是什么
恢复时长(MTTR,Time to Restore)统计服务中断到恢复所经历的时间,衡量系统的恢复能力;DORA 语境下强调从故障开始(或失败部署发生)到服务重新健康可用的完整过程,包含为修复而进行的部署本身。它由四段能力共同决定:检测(发现多快)、诊断(定位多准)、修复(回滚或修复路径多顺)、沟通(协作链路多通畅)。与 MTBF(故障间隔)不同,MTTR 不关心故障发生多频繁,而是问出了事多久能站起来——在故障无法杜绝的现实里,恢复能力是更可控的投资方向。
基本信息
| 口径 | 从事故开始到服务恢复的时长 |
|---|---|
| 影响因素 | 检测速度、诊断效率、回滚能力、沟通链路 |
| 改善 | 演练、可观测性建设、一键回滚 |
| 区分 | 与 MTBF 不同,关注恢复而非发生频率 |
| 记录 | 事故工单要有开始与恢复两个时间戳 |
典型使用场景
- 按等级统计:不同严重度分开看趋势,避免平均掩盖大事故。
- 复盘输入:恢复慢的环节在复盘里定位改进项并跟踪闭环。
- 演练:混沌与回滚演练直接压缩恢复时间,效果可测量。
- 观测投资:先降 MTTD(检测时间),MTTR 通常随之改善。
- 值班改进:诊断手册与操作手册让深夜恢复执行更快。
- 趋势守门:恢复时长恶化时检查部署流程与回滚通道是否退化。
按等级统计
按等级统计
SELECT severity,
AVG(recovered_at - started_at) AS avg_restore
FROM incidents
WHERE recovered_at IS NOT NULL
GROUP BY severity;相关指标区分
| 指标 | 度量对象 | 回答的问题 |
|---|---|---|
| MTTD | 发现时长 | 多久注意到故障 |
| MTTR | 恢复时长 | 多久恢复服务 |
| MTBF | 故障间隔 | 多久出一次故障 |
| 变更失败率 | 失败部署占比 | 变更质量如何 |
缩短恢复通常比杜绝全部故障更现实:故障难避免,快速恢复是可控能力。
检测是恢复的一半:靠用户报障才发现问题的团队,恢复时长天然偏高,先把告警接入。
恢复不等于根因修复:先回滚或切流把服务救回来,根因分析与长期修复放到事后复盘。