3. MTTR 测量与指标体系：从分解维度到 SLO/SLI/SLA 对齐
在平台工程视角下，MTTR（Mean Time to Repair）不是单一数字，而是一组可分解、可度量、可对齐的指标体系。只有将 MTTR 拆解为检测、诊断、修复三个子阶段，并定义对应的关键指标（MTA、MTTD、MTTR），才能与 SLO/SLI/SLA 形成闭环，驱动值班台持续调优。
3.1 MTTR 的三阶段分解模型
MTTR 的完整生命周期包含三个核心阶段：检测（Detect）、诊断（Diagnose）、修复（Repair）。每个阶段都有独立的耗时和优化空间。
核心公式： MTTR = MTA + MTTD + MTTRrepair
其中 MTA = Mean Time to Acknowledge（平均确认时间），MTTD = Mean Time to Diagnose（平均诊断时间），MTTRrepair = Mean Time to Repair（平均修复时间，狭义）。
其中 MTA = Mean Time to Acknowledge（平均确认时间），MTTD = Mean Time to Diagnose（平均诊断时间），MTTRrepair = Mean Time to Repair（平均修复时间，狭义）。
| 阶段 | 定义 | 典型耗时占比 | 平台工程优化方向 |
|---|---|---|---|
| 检测（Detect） | 从故障发生到值班人员确认告警的时间 | 15% - 25% | 告警收敛、智能降噪、多通道通知 |
| 诊断（Diagnose） | 从确认告警到定位根因的时间 | 40% - 60% | 可观测性数据关联、自动化诊断 Runbook |
| 修复（Repair） | 从定位根因到服务恢复正常的时间 | 20% - 35% | 自动化修复、自愈 Pipeline、变更回滚 |
实践要点： 诊断阶段通常占据 MTTR 的最大比例。平台工程应优先投资可观测性数据平台和自动化诊断能力，而非盲目追求修复速度。
3.2 关键指标定义与计算
在 MTTR 分解模型基础上，我们定义三个核心指标，每个指标都有明确的统计口径和计算方式。
3.2.1 MTA（Mean Time to Acknowledge）
从故障发生到值班人员确认告警的平均时间。反映告警通知的有效性和值班响应速度。
MTA = Σ(确认时间 - 故障发生时间) / 告警总数3.2.2 MTTD（Mean Time to Diagnose）
从确认告警到定位根因的平均时间。反映可观测性能力和诊断效率。
MTTD = Σ(定位时间 - 确认时间) / 故障总数3.2.3 MTTR（Mean Time to Repair，狭义）
从定位根因到服务恢复正常的平均时间。反映修复自动化程度和变更能力。
MTTR = Σ(恢复时间 - 定位时间) / 故障总数
常见误区： 很多团队将 MTTR 直接等同于修复时间，忽略了检测和诊断阶段。实际上，诊断阶段往往占据 MTTR 的 50% 以上。平台工程应建立三阶段独立度量，避免优化方向偏差。
3.3 SLO/SLI/SLA 与 MTTR 的对齐
MTTR 指标必须与 SLO（Service Level Objective）、SLI（Service Level Indicator）、SLA（Service Level Agreement）形成对齐关系，才能驱动业务价值。
| 概念 | 定义 | 与 MTTR 的关系 |
|---|---|---|
| SLI | 服务等级指标，如延迟、错误率、吞吐量 | MTTR 直接影响 SLI 的恢复时间，MTTR 越短，SLI 劣化窗口越小 |
| SLO | 服务等级目标，如 99.9% 可用性 | MTTR 是达成 SLO 的关键输入，MTTR 过长会导致 SLO 违约 |
| SLA | 服务等级协议，对外承诺的合同条款 | MTTR 必须满足 SLA 中定义的响应和修复时间要求 |
对齐公式： SLO 可用性 = (总时间 - MTTR × 故障次数) / 总时间 × 100%
例如：月度总时间 43200 分钟，MTTR 30 分钟，故障 5 次，则可用性 = (43200 - 150) / 43200 ≈ 99.65%
例如：月度总时间 43200 分钟，MTTR 30 分钟，故障 5 次，则可用性 = (43200 - 150) / 43200 ≈ 99.65%
3.4 指标体系落地实践
在平台工程中，MTTR 指标体系需要嵌入到值班台的日常运营中。以下是推荐的落地步骤：
- 定义 SLI 基线： 选择与用户体验最相关的指标（如 P99 延迟、错误率），建立基线值。
- 分解 MTTR 目标： 根据历史数据，将 SLO 目标分解为 MTA、MTTD、MTTRrepair 的子目标。
- 建立仪表盘： 在值班台展示实时 MTTR 分解指标，支持按服务、按团队、按故障等级下钻。
- 设置告警阈值： 当某个子阶段耗时超过预设阈值时，自动触发升级流程。
- 定期复盘： 每周/每月分析 MTTR 趋势，识别瓶颈阶段并制定改进计划。
平台工程建议： 在内部开发者平台（IDP）中内置 MTTR 仪表盘模板，让每个服务团队都能自助查看自己的 MTTR 分解数据，无需依赖 SRE 团队手动导出。
3.5 常见陷阱与避坑指南
| 陷阱 | 表现 | 解决方案 |
|---|---|---|
| 指标混用 | 将 MTTR 等同于修复时间，忽略检测和诊断 | 强制分解为 MTA、MTTD、MTTRrepair 三个独立指标 |
| 数据口径不一致 | 不同团队对“故障发生时间”定义不同 | 统一使用可观测性平台的时间戳，避免人工记录 |
| SLO 与 MTTR 脱钩 | SLO 目标未考虑 MTTR 影响 | 使用可用性公式将 MTTR 纳入 SLO 计算 |
| 过度优化单一阶段 | 只优化修复速度，忽略诊断瓶颈 | 建立三阶段平衡仪表盘，关注整体 MTTR |
通过以上分解维度和指标体系，平台工程团队能够将 MTTR 从黑盒数字转变为可观测、可分解、可优化的白盒指标，最终实现与 SLO/SLI/SLA 的精准对齐。