MTTR 基础概念：定义、重要性及四个阶段
在 SRE 与可观测性体系中，MTTR（Mean Time to Repair，平均修复时间）是衡量系统从故障发生到完全恢复的关键指标。对于 Feature Flag 开关延迟场景，MTTR 直接决定了开关变更对用户体验的影响时长。理解 MTTR 的定义、其在 SRE 中的核心地位以及构成 MTTR 的四个阶段，是优化复盘口径的前提。
2.1 MTTR 定义
MTTR 是指系统从故障被确认到完全恢复正常服务所花费的平均时间。在 Feature Flag 场景中，MTTR 特指从开关延迟被检测到、经过响应、修复到最终恢复至预期状态的总时长。
| 维度 | 传统 IT 定义 | Feature Flag 场景定义 |
|---|---|---|
| 起始点 | 故障告警触发 | 开关延迟首次被可观测系统捕获 |
| 结束点 | 服务恢复正常 | 开关状态与预期一致，延迟消除 |
| 核心度量 | 修复时长 | 检测 + 响应 + 修复 + 恢复 |
| 常见单位 | 分钟 / 小时 | 秒 / 分钟（高精度要求） |
关键公式： MTTR = (总修复时间之和) / (修复事件总数)。在复盘时，需按四个阶段分别统计，避免笼统计算。
2.2 MTTR 在 SRE 中的重要性
在 SRE 实践中，MTTR 是服务等级目标（SLO）的核心支撑指标。低 MTTR 意味着更短的故障窗口、更小的用户影响和更高的系统韧性。具体体现在以下四个方面：
- 用户感知直接关联： Feature Flag 延迟每增加 1 秒，用户体验下降一个量级。MTTR 越短，用户无感知恢复越快。
- 故障成本控制： 延迟导致的流量损失、计算资源浪费、数据不一致风险，均与 MTTR 正相关。
- 复盘效率提升： 将 MTTR 拆解为四个阶段后，团队能精准定位瓶颈（如检测慢还是修复慢），避免无效复盘。
- 自动化投资回报率（ROI）衡量： 通过对比优化前后的 MTTR 各阶段时长，量化自动化检测、自动回滚等能力的价值。
SRE 最佳实践： 将 MTTR 目标纳入服务等级指标（SLI）体系，例如设定“P99 MTTR ≤ 30 秒”作为 Feature Flag 开关延迟的硬性要求。
2.3 MTTR 的四个阶段
MTTR 并非单一数值，而是由四个连续阶段组成。每个阶段都有独立的优化空间和复盘口径。下图展示了四个阶段的完整链路：
2.4 各阶段详细拆解
为了在复盘时精确归因，必须将 MTTR 按四个阶段分别度量。下表列出了每个阶段的定义、典型场景及复盘口径：
| 阶段 | 定义 | Feature Flag 延迟典型场景 | 复盘口径（度量项） |
|---|---|---|---|
| 检测 | 从延迟发生到系统产生告警 | 开关状态与预期不符，但监控未及时触发 | 告警延迟、检测覆盖率、误报率 |
| 响应 | 从告警到工程师开始处理 | 值班人员未及时响应或事件分派错误 | 响应时间、分派准确率、升级次数 |
| 修复 | 从开始处理到执行完修复操作 | 手动回滚开关、修改配置、重启服务 | 修复操作耗时、回滚成功率 |
| 恢复 | 从修复完成到服务完全正常 | 缓存刷新、流量切换、数据一致性校验 | 恢复验证时长、残余错误率 |
常见误区： 很多团队将“修复”和“恢复”混为一谈，导致 MTTR 统计失真。例如，回滚操作只用了 5 秒（修复完成），但缓存刷新和流量切换用了 2 分钟（恢复阶段），若合并计算则无法定位真实瓶颈。
2.5 四阶段在复盘中的实际应用
在 Feature Flag 开关延迟的复盘会议中，建议按以下步骤拆解 MTTR：
- 提取时间戳： 从可观测平台导出延迟开始时间、告警时间、响应时间、修复完成时间、恢复确认时间。
- 计算各阶段时长： 分别计算 T1（检测）、T2（响应）、T3（修复）、T4（恢复）。
- 对比基线： 与历史 MTTR 各阶段均值对比，识别异常阶段。
- 归因分析： 针对异常阶段深入分析根因（如检测阶段告警阈值过高、响应阶段值班漏接等）。
- 制定优化措施： 针对每个阶段提出可量化的改进项，并设定下一周期的目标值。
下图展示了复盘过程中各阶段数据的流转关系：
复盘口径优化提示： 在 Feature Flag 延迟复盘时，建议将 MTTR 的四个阶段分别记录到事件管理系统中，并自动计算各阶段占比。例如，若 T1（检测）占比超过 50%，则优先优化可观测告警策略；若 T3（修复）占比高，则需考虑自动化回滚能力。