3. MTTR（Mean Time to Repair）基础
MTTR（平均修复时间）是衡量系统从故障发生到完全恢复所消耗平均时间的核心指标。在 Feature Flag 配置错误的场景中，MTTR 直接决定了错误配置对用户的影响窗口长度，是 SRE 团队最关注的恢复能力指标之一。
3.1 MTTR 的定义与计算
MTTR 衡量的是“修复”效率，而非“发现”效率。其标准计算公式为：
MTTR = 总修复时间 / 修复次数在 Feature Flag 配置错误场景下，“修复时间”通常包含以下阶段：
| 阶段 | 定义 | Feature Flag 场景示例 |
|---|---|---|
| 检测（Detection） | 从错误配置生效到被监控或用户反馈发现的时间 | 灰度比例误设为 100%，5 分钟后告警触发 |
| 诊断（Diagnosis） | 从发现到定位根因的时间 | 确认是 Flag 配置值错误而非代码缺陷 |
| 修复（Fix） | 从定位到执行修复操作的时间 | 通过控制台回滚 Flag 配置或关闭 Flag |
| 验证（Verification） | 从修复执行到确认系统恢复正常的时间 | 验证目标用户群已切回正确配置 |
实践要点：在 Feature Flag 平台中，MTTR 的“修复”通常指配置回滚或 Flag 关闭操作，而非代码部署。这意味着 MTTR 可以压缩到秒级，前提是平台具备一键回滚能力。
3.2 MTTR 在 SRE 体系中的位置
在 Google SRE 体系中，MTTR 是 可靠性方程 的关键组成部分。SRE 的核心目标是最大化系统可用性，而可用性公式为：
可用性 = Uptime / (Uptime + Downtime)其中 Downtime 直接受 MTTR 影响。MTTR 越短，每次故障造成的停机时间越短，可用性越高。
下图展示了 MTTR 在 SRE 故障生命周期中的位置：
SRE 关键认知：MTTR 是 SRE 团队可以直接控制的指标。通过自动化检测、标准化诊断流程、一键修复能力，MTTR 可以从小时级压缩到分钟级甚至秒级。在 Feature Flag 场景中，MTTR 的优化空间远大于 MTBF。
3.3 MTTR 与 MTBF / MTTF 的关系
MTTR、MTBF（平均故障间隔时间）和 MTTF（平均故障时间）共同构成了 SRE 的可靠性三角。三者定义如下：
| 指标 | 全称 | 定义 | Feature Flag 场景 |
|---|---|---|---|
| MTBF | Mean Time Between Failures | 两次故障之间的平均正常运行时间 | 两次配置错误之间的平均间隔 |
| MTTF | Mean Time To Failure | 系统开始运行到首次故障的平均时间 | 新 Flag 上线到首次配置错误的时间 |
| MTTR | Mean Time To Repair | 从故障发生到完全恢复的平均时间 | 从错误配置生效到回滚完成的时间 |
三者之间的数学关系直接影响系统可用性：
可用性 = MTBF / (MTBF + MTTR)
当 MTBF >> MTTR 时，可用性趋近于 100%下图展示了 MTBF、MTTF 和 MTTR 在时间轴上的关系：
3.4 Feature Flag 场景下的关键洞察
- MTTR 是可控变量：在 Feature Flag 配置错误场景中，MTBF 受代码质量、配置审核流程影响，优化周期长；而 MTTR 可以通过平台能力（一键回滚、自动检测、灰度验证）快速优化。
- MTTR 对可用性的影响权重更高：当 MTBF 较大时，MTTR 的微小改善就能显著提升可用性。例如 MTBF=1000h，MTTR 从 1h 降到 0.5h，可用性从 99.90% 提升到 99.95%。
- MTTF 在首次部署场景中更敏感：新 Feature Flag 首次上线时，MTTF 决定了“首次故障”的时间窗口，需要配合灰度发布和渐进式暴露来延长 MTTF。
常见误区：不要将 MTTR 与“修复时间”等同。MTTR 包含检测、诊断、修复、验证四个阶段。在 Feature Flag 场景中，检测和诊断往往占据 MTTR 的 70% 以上时间。优化 MTTR 应优先缩短检测和诊断时间，而非仅关注“回滚操作”本身。