1.1 MTTR 基本概念
1.1.1 MTTR 定义
MTTR（Mean Time To Repair，平均修复时间）是衡量系统从故障发生到完全恢复服务所需平均时间的核心指标。在发布工程语境下，MTTR 特指从发布异常被检测到到服务恢复正常所经历的全部时间窗口。
发布工程中的 MTTR 公式：
MTTR = (故障检测时间 + 故障定位时间 + 故障修复时间 + 验证恢复时间) / 故障次数
MTTR = (故障检测时间 + 故障定位时间 + 故障修复时间 + 验证恢复时间) / 故障次数
MTTR 的四个关键阶段：
- 检测时间（Detection Time）：从故障发生到监控告警触发的时间差。
- 定位时间（Diagnosis Time）：从告警触发到确定根因的时间。
- 修复时间（Resolution Time）：从确定根因到执行修复操作（如回滚、热修复）的时间。
- 验证时间（Verification Time）：从修复完成到确认服务恢复正常的时间。
实践要点：在发布复盘时，MTTR 应拆解为上述四个子阶段分别统计，才能精准定位瓶颈环节。质量门禁和人工审批流程直接影响的是"修复时间"和"验证时间"两个阶段。
1.1.2 MTTR 在发布工程中的重要性
在持续交付和 DevOps 实践中，MTTR 是衡量发布成熟度的关键指标之一。低 MTTR 意味着团队能够快速从故障中恢复，从而降低发布风险对用户的影响。
| 维度 | 高 MTTR 的影响 | 低 MTTR 的价值 |
|---|---|---|
| 用户体验 | 故障持续时间长，用户流失风险高 | 快速恢复，用户感知最小化 |
| 业务损失 | 停机时间越长，收入损失越大 | 缩短停机窗口，降低经济损失 |
| 团队信心 | 频繁长故障导致发布恐惧 | 快速恢复能力增强发布信心 |
| 合规审计 | 故障响应超时可能违反 SLA | 满足 SLA 要求，通过审计 |
在发布工程中，MTTR 直接关联到质量门禁和人工审批流程的设计：
- 质量门禁：自动化检测环节（如自动化测试、健康检查）越完善，检测时间和定位时间越短。
- 人工审批流程：审批环节过多或响应过慢，会显著拉长修复时间和验证时间。
常见误区：很多团队只关注 MTBF（平均无故障时间），却忽视了 MTTR。实际上，在发布频率较高的场景下，MTTR 对系统可用性的影响往往大于 MTBF。可用性公式为：Availability = MTBF / (MTBF + MTTR)。
1.1.3 MTTR 与 MTBF / MTTF 的区别
这三个指标共同构成了系统可靠性的核心度量体系，但各自关注不同的维度：
| 指标 | 全称 | 定义 | 发布工程中的含义 |
|---|---|---|---|
| MTTR | Mean Time To Repair | 平均修复时间 | 从发布故障发生到恢复的平均时长 |
| MTBF | Mean Time Between Failures | 平均故障间隔时间 | 两次发布故障之间的平均正常运行时长 |
| MTTF | Mean Time To Failure | 平均失效时间 | 系统从启动到首次故障的平均时长（不可修复系统） |
三者的核心区别：
- MTTR 关注恢复速度：衡量的是"出问题后多久能好"，是发布工程复盘的核心指标。
- MTBF 关注稳定性：衡量的是"两次故障之间能稳定运行多久"，反映系统健壮性。
- MTTF 关注首次失效：适用于一次性组件或不可修复场景，在发布工程中较少直接使用。
发布工程复盘口诀：
MTTR 看恢复快不快，MTBF 看系统稳不稳，MTTF 看组件牢不牢。
质量门禁主要降低 MTTR 中的检测和定位时间，人工审批流程则影响修复和验证时间。
MTTR 看恢复快不快，MTBF 看系统稳不稳，MTTF 看组件牢不牢。
质量门禁主要降低 MTTR 中的检测和定位时间，人工审批流程则影响修复和验证时间。
复盘口径提示：在发布工程复盘时，建议同时记录 MTTR 和 MTBF 两个指标。如果 MTBF 很长但 MTTR 也很长，说明系统稳定但恢复能力弱；如果 MTBF 很短但 MTTR 很短，说明系统频繁出问题但恢复快。质量门禁和人工审批流程优化的目标是在不显著增加 MTBF 的前提下，持续降低 MTTR。