MTTR 跟踪

把平均解决时间作事件响应质量的先导指标跟踪，连同 MTTA 和 MTTF。

为什么

MTTR（平均解决时间）是告诉你事件响应是否在改的指标 — 若在降，runbook、工具和 IC 训练有效；若在升，某物在退（runbook 腐、新复杂、值班疲劳）。但 MTTR 单独是滞后复合：MTTA（确认时间）告诉你 paging 系统和升级是否工作；MTTF（找根因时间）告诉你 runbook 和可观测是否工作；MTTR - MTTF（修复时间）告诉你回滚/修工具是否工作。跟踪三者让你诊断响应何处慢：MTTA 高则修 paging；MTTF 高则修 runbook；修复时间高则修工具。单 MTTR 数告诉你某物错；分解告诉你什么。

何时使用

每事件。月度按严重性审查趋势（MTTA、MTTF、MTTR）。

如何做

1. 给事件时间线插桩
   - T0 = 告警触发；T1 = 值班确认；T2 = 根因找到；T3 = 事件解决
   - MTTA = T1 - T0；MTTF = T2 - T1；MTTR = T3 - T0；修复时间 = T3 - T2
   - 多 paging 系统记 T0 和 T1；你须记 T2（IC 宣"根因找到"）

2. 按严重性和团队跟踪
   - SEV1 MTTR 目标：<30m；SEV2：<2h；SEV3：<1 工作日
   - 按团队：MTTR 2x 组织均值的团队有工具或 runbook 缺口

3. 月度审查趋势，非仅均值
   - 绘 MTTA、MTTF、修复时间、MTTR 随时间；找退非仅均值
   - MTTF 3 月升 → runbook 在腐或复杂在涨

4. 用分解诊断慢响应
   - MTTA 高 → paging 系统、升级或值班排班问题
   - MTTF 高 → 可观测、runbook 或 SME 可用性问题
   - 修复时间高 → 回滚工具、部署管道或权限问题

5. 按组件设改目标
   - "Q3 前 MTTA 从 8m 降到 5m" → 修升级策略
   - "Q3 前 MTTF 从 20m 降到 10m" → 为 top 5 告警类型加 runbook
   - 别仅目标 MTTR；目标最慢的组件

示例

# 事件指标仪表盘（过去 30 天，SEV1）
incidents: 4
MTTA: 6.2m  (目标 <5m)  ⚠ 略高
MTTF: 18m   (目标 <10m) ⚠ runbook 或可观测缺口
修复时间: 4m (好 — 回滚工具工作)
MTTR: 28m   (目标 <30m) ✅ 但仅因修复时间快

# 趋势（过去 6 月）：
#   MTTA:  4m → 5m → 6m → 7m → 6m → 6.2m  (缓升 — 升级策略？）
#   MTTF:  10m → 12m → 15m → 20m → 19m → 18m  (升 — runbook 腐）
#   修复:  3m → 4m → 4m → 5m → 4m → 4m  (稳）

# 行动：MTTF 是退。top 5 SEV1 告警类型：
#   1. DbPrimaryDown（8 事件，均 MTTF 22m）→ runbook 过期，重写
#   2. CheckoutSLOBurn（5 事件，均 MTTF 15m）→ runbook 好，无行动
#   3. ... → 聚焦 runbook 工作于 DbPrimaryDown，最大 MTTF 贡献者

常见问题

⚠仅跟踪 MTTR 非分解 — 你知响应慢但不知修 paging、runbook 还是工具。
⚠均值藏退 — MTTR 均 30m 但 6 月从 20m 涨到 40m；绘趋势非仅均值。
⚠无 T2（根因找到）时间戳 — MTTF 无法算，故 runbook/可观测缺口不可见。
⚠MTTR 目标无按组件目标 — "MTTR 降到 20m"模糊；"重写 top 3 runbook 把 MTTF 降到 10m"可行动。

最佳实践

✓每事件插桩 T0、T1、T2、T3 并跟踪 MTTA、MTTF、修复时间和 MTTR — 分解告诉你修什么非仅某物慢。
✓绘 6 月趋势非仅月均；缓升 MTTF 是 runbook 腐或复杂涨的早期警告。
✓按最慢段设按组件改目标（MTTA、MTTF、修复时间）非单 MTTR 目标。
✓按团队和严重性审查；MTTR 2x 组织均值的团队有特定工具或 runbook 缺口可投资。