2. MTTR 基础概念：定义、计算与业务影响
MTTR（Mean Time To Repair，平均修复时间）是衡量系统从故障发生到完全恢复所需时间的核心指标。在 SRE 实践中，MTTR 直接决定了故障对用户的影响时长，是服务等级目标（SLO）达成与否的关键变量。本章将系统阐述 MTTR 的定义、计算公式、与 MTBF/MTTF 的关系，以及它对业务连续性的实际影响。
2.1 MTTR 定义与计算公式
MTTR 定义为从系统发生故障（或告警触发）到服务恢复正常运行所经历的平均时间。它涵盖了故障发现、定位、修复、验证的全过程，而不仅仅是“修复”这一步。
| 阶段 | 说明 | 典型耗时占比 |
|---|---|---|
| 故障发现（TTD） | 从故障发生到监控告警或用户反馈触发响应 | 10% – 20% |
| 故障定位（TTI） | 从响应开始到确定根因 | 40% – 60% |
| 故障修复（TTF） | 执行修复操作（回滚、重启、扩容、切流等） | 15% – 25% |
| 验证恢复（TTV） | 确认服务恢复正常、流量恢复、告警消除 | 5% – 10% |
MTTR 计算公式
MTTR = (总修复时间) / (故障次数)
其中：
总修复时间 = Σ(每次故障从发现到恢复的时长)
故障次数 = 统计周期内发生的故障总数示例计算：某月发生 4 次故障，修复时长分别为 12 min、8 min、15 min、5 min，则：
MTTR = (12 + 8 + 15 + 5) / 4 = 40 / 4 = 10 分钟
实践要点：MTTR 统计应包含所有“用户可感知的故障”，不包括计划内维护或灰度发布中的短暂抖动。建议按严重等级（P0/P1/P2）分别统计 MTTR，避免高优故障被低优故障稀释。
2.2 MTTR 与 MTBF / MTTF 的关系
MTBF（Mean Time Between Failures，平均故障间隔时间）和 MTTF（Mean Time To Failure，平均失效时间）是与 MTTR 紧密关联的可靠性指标。三者共同构成系统可用性计算的基础。
| 指标 | 定义 | 适用场景 | 与 MTTR 的关系 |
|---|---|---|---|
| MTBF | 两次故障之间的平均正常运行时间 | 可修复系统（如在线服务、数据库集群） | MTBF 越大越好，MTTR 越小越好 |
| MTTF | 系统首次失效前的平均运行时间 | 不可修复系统（如一次性设备、无冗余组件） | MTTF 替代 MTBF 用于不可修复场景 |
| MTTR | 平均修复时间 | 所有可修复系统 | 与 MTBF 共同决定可用性 |
可用性计算公式：
可用性（A） = MTBF / (MTBF + MTTR) × 100%从公式可以看出：降低 MTTR 与提升 MTBF 对可用性的贡献是等效的。例如，MTBF = 100h、MTTR = 1h 时可用性为 99.01%；若 MTTR 降至 0.5h，可用性提升至 99.50%。
关键认知：在系统架构设计中，MTBF 的提升通常需要架构重构、冗余设计、代码质量改进等长期投入；而 MTTR 的优化可以通过自动化、标准化、可观测性建设等中短期手段快速见效。因此，MTTR 优化是 SRE 团队投入产出比最高的领域之一。
2.3 MTTR 对业务连续性的影响
业务连续性（Business Continuity）指在故障发生时，组织能够维持关键业务功能的能力。MTTR 是衡量这一能力最直接的量化指标。
MTTR 对业务连续性的三个核心影响维度：
- 用户感知时长：MTTR 越长，用户无法使用服务的时间越长，直接导致用户体验下降、用户流失、品牌声誉受损。
- 经济损失：对于电商、支付、广告等在线业务，每多一分钟故障都意味着真金白银的损失。MTTR 每降低 1 分钟，可能挽回数十万甚至数百万的营收。
- 合规与 SLA 风险：多数业务 SLA 对可用性有明确要求（如 99.99%），MTTR 过高将直接导致 SLA 违约，面临赔偿或监管处罚。
| 业务场景 | 典型 MTTR 目标 | MTTR 超标后果 |
|---|---|---|
| 金融交易系统 | < 5 分钟 | 交易中断、监管处罚、客户索赔 |
| 电商核心链路 | < 10 分钟 | 订单流失、大促活动失败、品牌信任下降 |
| 社交媒体/内容平台 | < 15 分钟 | 用户活跃度骤降、广告收入损失 |
| 企业内部系统 | < 30 分钟 | 员工工作效率受阻、业务流程中断 |
常见误区：部分团队只关注“修复时间”而忽略“发现+定位”时间。实际上，故障定位（TTI）通常占 MTTR 的 50% 以上。如果只优化修复步骤而不改善可观测性和告警质量，MTTR 的改善幅度将非常有限。
MTTR 优化对业务连续性的杠杆效应：
- 自动化恢复：通过自愈脚本、自动回滚、限流降级等手段，将 MTTR 从分钟级压缩到秒级，业务几乎无感知。
- 标准化流程：建立故障响应 SOP（标准操作流程），减少人为决策延迟，将 MTTR 降低 30% – 50%。
- 混沌工程验证：定期注入故障，检验 MTTR 实际表现，持续改进薄弱环节。