1. MTTR 复盘口径总览
在 Prometheus 存储瓶颈场景下，MTTR（Mean Time to Repair）是衡量故障恢复效率的核心指标。然而，不同团队对“修复完成”的定义差异巨大——有人以查询恢复为基准，有人以数据完整写入为准。本章建立一套标准化的复盘口径，确保每次存储瓶颈复盘都能对齐同一把尺子。
1.1 MTTR 在存储瓶颈场景下的核心指标
我们将 MTTR 拆解为三个可独立度量的阶段，每个阶段对应一个子指标：
| 子指标 | 英文全称 | 定义 | Prometheus 存储瓶颈典型场景 |
|---|---|---|---|
| 检测时间 | Time to Detect (TTD) | 从故障发生到监控系统发出明确告警的时间间隔 | WAL 写入延迟突增 → 告警触发；或 TSDB 块压缩失败累积至阈值 |
| 响应时间 | Time to Respond (TTR) | 从告警触发到 SRE 开始执行修复操作的时间间隔 | 值班人员确认告警、登录机器、定位到存储目录或查询超时根因 |
| 修复时间 | Time to Fix (TTF) | 从开始修复到存储瓶颈完全解除、查询恢复正常的时间间隔 | 清理 WAL 积压、扩容磁盘、重建 TSDB 块、调整 retention 策略 |
复盘口径公式：
MTTR = TTD + TTR + TTF每个子指标必须独立记录时间戳，避免将“告警延迟”与“修复延迟”混为一谈。
1.2 复盘口径的标准化框架
标准化框架围绕“时间线对齐 + 阶段锚点 + 数据源”三个维度构建，确保每次复盘可复现、可对比。
1.3 复盘口径的标准化步骤
- 锚点对齐：在每次存储瓶颈事件中，强制记录 T0～T3 四个时间戳，精确到秒。
- 子指标计算：TTD = T1 - T0；TTR = T2 - T1；TTF = T3 - T2。
- 异常标记：若某个子指标超过历史 P95 基线，标记为“异常阶段”，在复盘中重点分析。
- 数据源校验：告警时间戳以 Alertmanager 的
startsAt为准；修复操作时间以堡垒机或 kubectl 日志为准。
最佳实践：在 Prometheus 的告警规则中增加
summary 和 description 字段，携带故障首次出现的时间戳（通过 time() 函数计算），避免 T0 丢失。
1.4 复盘口径的常见误区
| 误区 | 错误做法 | 正确做法 |
|---|---|---|
| TTD 与 TTR 混淆 | 将告警触发时间当作故障发生时间 | 通过 PromQL 反查故障首次出现的时间点 |
| 修复完成标准不统一 | 以磁盘清理完成为修复终点 | 以查询延迟恢复至 P99 基线以下为修复终点 |
| 忽略数据源时差 | 直接使用告警系统与操作系统的本地时间 | 统一使用 NTP 同步后的 UTC 时间戳 |
| 复盘口径未固化 | 每次复盘临时定义指标 | 使用标准化框架，每次复盘输出相同维度的报告 |
注意：在 Prometheus 存储瓶颈场景中，WAL 积压导致的查询超时往往在故障发生 5～15 分钟后才被告警捕获。如果复盘时不区分 TTD 和 TTR，会掩盖“告警延迟”这个关键短板。
1.5 复盘口径的落地检查清单
- ✅ 是否已定义 T0～T3 四个时间锚点？
- ✅ 是否在告警规则中嵌入了故障首次出现的时间戳？
- ✅ 是否统一了所有时间源为 NTP 同步的 UTC？
- ✅ 是否将修复完成标准与查询延迟 P99 基线绑定？
- ✅ 是否在每次存储瓶颈事件后自动生成 MTTR 子指标报告？
标准化复盘口径是后续查询优化的基础——只有知道“时间花在了哪里”，才能精准优化 Prometheus 的存储配置与查询模式。