首页/开发/CI/CD 与发布速查/恢复时长(MTTR / Time to Restore)
质量门禁与回滚51 条

恢复时长(MTTR / Time to Restore)

服务中断到恢复所需的平均时间,衡量系统恢复能力;DORA 口径强调从故障开始到修复完成,包含为修复而进行的发布。

CI/CD 与发布速查开发更新于 2026-10-13

恢复时长是什么

恢复时长(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故障间隔多久出一次故障
变更失败率失败部署占比变更质量如何
缩短恢复通常比杜绝全部故障更现实:故障难避免,快速恢复是可控能力。
检测是恢复的一半:靠用户报障才发现问题的团队,恢复时长天然偏高,先把告警接入。
恢复不等于根因修复:先回滚或切流把服务救回来,根因分析与长期修复放到事后复盘。

易错点

  • 等级混算:小故障与大宕机一起平均,指标失去指导性;分开统计。
  • 只记发现时间不记故障开始时间:检测环节的短板被掩盖;两个时间戳都采集。
  • 缺失数据直接排除:只剩快恢复的样本,数字失真;缺失的记录补录。
  • 把回滚排除在修复之外:回滚也是恢复手段,统计应包含。
  • 指标用于问责:团队会瞒报或降级上报;保持无指责文化才能拿到真数据。

数据来源与参考

  • DORA《Accelerate State of DevOps Report》
  • Google SRE Book《Managing Incidents》
​‌‌​​‌​​​‌‌​‌‌‌‌​‌‌​​​‌‌​‌‌‌​​‌‌​​‌​‌‌‌​​‌‌‌​​​‌​‌‌​‌​​‌​‌‌‌​​​‌​‌‌​‌​​‌​‌‌​​​‌‌​‌‌‌​‌​​​‌‌​‌‌‌‌​​‌​‌‌‌​​‌‌​​​‌‌​‌‌​‌‌‌‌​‌‌​‌‌​‌