2. MTTR 核心概念：定义、四阶段与灰度特殊性
MTTR（Mean Time to Repair，平均修复时间）是衡量系统从故障发生到完全恢复所需平均时长的关键指标。在 Feature Flag 灰度发布场景下，MTTR 的统计口径与计算方式直接影响复盘结论的准确性。本节从标准定义出发，逐步拆解 MTTR 的四个阶段，并重点分析灰度环境带来的特殊性。
2.1 MTTR 定义：从故障发生到服务恢复
MTTR 的核心公式为：
MTTR = (总修复时间) / (修复次数)其中“修复时间”指从故障被确认到服务恢复正常状态之间的时间窗口。在灰度发布场景中，故障可能仅影响部分用户或流量，因此 MTTR 的统计粒度需要细化到“灰度批次”级别。
| 指标维度 | 标准定义 | 灰度场景调整 |
|---|---|---|
| 起始点 | 故障被监控系统检测到 | 灰度批次异常指标首次触发告警 |
| 结束点 | 服务完全恢复正常 | 灰度批次回滚或修复后指标回归基线 |
| 统计范围 | 全量服务实例 | 仅受影响的灰度分组（如 10% 流量） |
| 分母 | 修复事件总数 | 灰度发布次数或批次切换次数 |
复盘口径提示： 灰度场景下，MTTR 的“修复”不一定是代码回滚，也可能是 Feature Flag 开关关闭、流量切回基线版本或动态调整灰度比例。统计时需明确“修复动作”的定义，避免口径不一致导致复盘偏差。
2.2 MTTR 的四个阶段：检测、诊断、修复、验证
MTTR 并非单一时间点，而是由四个连续阶段组成的时间总和。每个阶段都有独立的优化目标和度量方式。
- 检测（Detection）：从故障发生到系统或人工发现异常的时间。依赖监控覆盖率、告警延迟、日志采集时效。
- 诊断（Diagnosis）：从确认异常到定位根因的时间。依赖可观测性数据（链路、指标、事件）的关联分析能力。
- 修复（Repair）：从定位根因到执行修复动作的时间。依赖自动化回滚、Feature Flag 开关、配置下发等工具链。
- 验证（Verification）：从修复完成到确认服务恢复正常的时间。依赖健康检查、灰度指标回归基线、用户反馈闭环。
关键公式： MTTR = T检测 + T诊断 + T修复 + T验证
下图展示了四个阶段在灰度发布故障场景下的串联关系：
2.3 灰度场景下的 MTTR 特殊性
灰度发布引入的流量切分、动态开关、渐进式放量等机制，使 MTTR 的每个阶段都产生显著变化。以下从四个阶段逐一分析灰度特殊性：
| 阶段 | 全量发布场景 | 灰度发布场景 | MTTR 影响 |
|---|---|---|---|
| 检测 | 全量告警，指标波动大 | 灰度分组指标对比，基线偏差更早发现 | 检测时间缩短 30%~60% |
| 诊断 | 需排查全量实例日志 | 仅需分析灰度分组链路，可对比基线组 | 诊断时间缩短 40%~70% |
| 修复 | 代码回滚 + 重新部署 | Feature Flag 关闭 / 流量切回基线 | 修复时间缩短 80%~95% |
| 验证 | 全量回归测试 | 灰度分组指标回归基线即可 | 验证时间缩短 50%~80% |
复盘口径陷阱： 灰度场景下，如果 MTTR 统计口径仍沿用全量发布的“代码回滚完成”作为修复终点，会严重高估实际恢复时间。正确的口径应以“灰度分组恢复正常”为准，且需区分“开关关闭”与“代码回滚”两种修复动作的耗时差异。
下图对比了全量发布与灰度发布在 MTTR 各阶段的时间分布差异：
2.4 灰度 MTTR 复盘口径建议
基于上述特殊性，在灰度发布复盘时建议采用以下口径：
- 检测时间：从灰度批次开始放量到首个灰度分组告警触发的时间。
- 诊断时间：从告警触发到确认根因（如 Feature Flag 配置错误、新版本代码缺陷）的时间。
- 修复时间：从确认根因到灰度分组恢复正常（开关关闭 / 流量切回 / 配置回滚）的时间。
- 验证时间：从修复动作完成到灰度分组所有核心指标回归基线的时间。
- 总 MTTR：上述四段时间之和，仅统计受影响的灰度分组，不包含未受影响的基线分组。
复盘示例： 某次灰度发布中，检测耗时 2 分钟，诊断耗时 5 分钟，修复（关闭 Feature Flag）耗时 1 分钟，验证耗时 3 分钟，则 MTTR = 2 + 5 + 1 + 3 = 11 分钟。若按全量发布口径（代码回滚 + 重新部署），修复阶段通常需要 15~30 分钟，MTTR 将高达 25~40 分钟。灰度场景下 MTTR 降低 60% 以上。