4. MTTR 拆解：四个阶段与计算口径
MTTR（Mean Time to Repair）在可观测性与异常检测场景下并非单一指标，而是由四个独立阶段串联而成的端到端恢复时长。只有将 MTTR 拆解为 MTTI、MTTK、MTTF、MTTR 四个子阶段，才能精准定位异常检测流程中的瓶颈环节，制定针对性的复盘口径。
4.1 MTTR 四阶段定义与边界
| 阶段 | 英文全称 | 定义 | 起止边界 |
|---|---|---|---|
| MTTI | Mean Time to Identify | 从异常发生到被检测系统识别并发出告警的平均时间 | 异常注入时刻 → 告警触发时刻 |
| MTTK | Mean Time to Know | 从告警触发到运维人员确认异常根因的平均时间 | 告警触发时刻 → 根因确认时刻 |
| MTTF | Mean Time to Fix | 从根因确认到修复方案部署完成的平均时间 | 根因确认时刻 → 修复完成时刻 |
| MTTR | Mean Time to Recover | 从修复完成到业务指标恢复至基线的平均时间 | 修复完成时刻 → 业务恢复时刻 |
口径注意点： 四阶段中的最后一个阶段与总指标同名（均为 MTTR），在复盘文档中建议使用
MTTR_recover 或 MTTR_恢复 加以区分，避免与总 MTTR 混淆。
4.2 四阶段串联流程
下图展示了从异常发生到业务完全恢复的完整时间线，四个阶段首尾相接，构成端到端 MTTR 总时长。
4.3 各阶段计算方式
每个阶段的计算均基于历史事件样本的均值。以下给出标准计算公式与典型数据来源。
4.3.1 MTTI（异常识别时长）
MTTI = (1 / N) * Σ (告警触发时间戳_i - 异常发生时间戳_i)
数据来源：
- 异常发生时间戳：由混沌工程注入记录或业务日志中的异常起始标记提供
- 告警触发时间戳：由监控系统告警事件表记录
复盘关注点： MTTI 过长通常意味着检测规则灵敏度不足、采集周期过长或告警抑制策略过于激进。目标值建议控制在 1-5 分钟以内。
4.3.2 MTTK（根因确认时长）
MTTK = (1 / N) * Σ (根因确认时间戳_i - 告警触发时间戳_i)
数据来源：
- 根因确认时间戳：由事件管理平台中“根因标记”或“确认人操作”时间记录
- 告警触发时间戳：同上
常见陷阱： 如果团队在告警触发后直接跳过根因分析就开始修复，MTTK 会被错误地记为 0。复盘时必须区分“猜测修复”与“确认根因后修复”，否则 MTTK 数据失真。
4.3.3 MTTF（修复部署时长）
MTTF = (1 / N) * Σ (修复完成时间戳_i - 根因确认时间戳_i)
数据来源：
- 修复完成时间戳：由 CI/CD 流水线部署完成事件或变更单关闭时间记录
- 根因确认时间戳：同上4.3.4 MTTR_recover（业务恢复时长）
MTTR_recover = (1 / N) * Σ (业务恢复时间戳_i - 修复完成时间戳_i)
数据来源：
- 业务恢复时间戳：由 SLI/SLO 监控中业务指标恢复至告警阈值以下的时间点记录
- 修复完成时间戳：同上4.4 四阶段对比与复盘优先级
| 阶段 | 典型时长范围 | 主要影响因素 | 复盘优先级 |
|---|---|---|---|
| MTTI | 30s ~ 5min | 检测规则、采集频率、告警延迟 | 高 |
| MTTK | 2min ~ 30min | 可观测性数据完备性、根因分析工具 | 最高 |
| MTTF | 1min ~ 60min | 自动化修复能力、变更流程 | 中 |
| MTTR_recover | 30s ~ 10min | 业务恢复策略、缓存预热、流量切换 | 中 |
复盘建议： 在异常检测场景中，MTTK 通常是四阶段中耗时最长且优化空间最大的环节。建议优先建立根因分析仪表盘，将 MTTK 作为核心复盘指标。
4.5 四阶段数据采集架构
下图为支撑四阶段计算所需的数据采集与时间戳打点架构，各系统间通过统一事件总线传递时间标记。
4.6 复盘口径设计要点
- 时间戳对齐： 所有阶段的时间戳必须使用同一时钟源（如 NTP 同步），避免跨系统时间偏差导致计算错误。
- 样本过滤： 计算均值前应剔除人工演练、计划内变更等非异常事件，仅保留真实异常检测场景的样本。
- 分位值补充： 除均值外，建议同时输出 P50、P90、P99 分位值，避免极端值掩盖整体趋势。
- 阶段占比分析： 计算各阶段时长占总 MTTR 的百分比，快速识别占比最高的瓶颈阶段。
最佳实践： 在可观测性平台中为每个阶段创建独立的仪表盘面板，配置 SLO 目标（如 MTTI < 3min、MTTK < 10min），当阶段时长超出阈值时自动触发复盘流程。