4. MTTR 测量与数据采集
MTTR（Mean Time to Repair，平均修复时间）是值班台最核心的效能指标。准确测量 MTTR 的前提是建立可靠的数据采集管道，并对原始数据进行清洗与标准化处理。本节将系统讲解数据来源、采集方法、异常值处理逻辑及标准计算公式。
4.1 数据采集来源与方法
MTTR 数据通常来自三个主要系统：事件管理系统、监控告警平台和工单系统。每个系统记录的时间戳维度不同，需要对齐后才能计算。
| 数据来源 | 关键时间字段 | 采集方式 | 常见问题 |
|---|---|---|---|
| 事件管理系统 （如 PagerDuty、Opsgenie） |
事件创建时间、确认时间、解决时间 | API 拉取 / Webhook 推送 | 手动确认延迟、自动关闭规则干扰 |
| 监控告警平台 （如 Prometheus + Alertmanager） |
告警触发时间、告警恢复时间 | PromQL 查询 / 告警事件导出 | 告警聚合导致时间偏移、静默期未过滤 |
| 工单系统 （如 Jira、ServiceNow） |
工单创建时间、首次响应时间、关闭时间 | REST API / 数据库直连 | 人工填写误差、非工作时间暂停计时 |
最佳实践：建议以事件管理系统的时间戳作为 MTTR 计算的主数据源，监控告警平台作为辅助校验，工单系统用于补充人工操作环节的细分耗时。三个系统的时间戳应统一转换为 UTC 时间，避免时区偏差。
4.2 数据清洗与异常值处理
原始数据中常包含噪声和异常记录，直接计算会导致 MTTR 失真。标准清洗流程包含以下步骤：
- 时间戳完整性校验：剔除缺少开始时间或结束时间的记录。
- 逻辑一致性检查：解决时间必须晚于创建时间，差值小于 0 的记录直接丢弃。
- 异常值过滤：使用 IQR（四分位距）方法识别离群点，通常将超出 [Q1 - 1.5×IQR, Q3 + 1.5×IQR] 范围的记录标记为异常。
- 业务规则过滤：排除测试事件、重复告警、已预知的变更窗口事件。
- 缺失值处理：对于缺少确认时间的记录，使用创建时间 + 中位确认延迟进行估算，并在报告中标注。
清洗前后对比示例：某团队原始数据包含 1200 条事件记录，清洗后保留 1082 条有效记录。清洗前 MTTR 为 47 分钟，清洗后为 32 分钟，差异主要来自 3 条长达 12 小时的僵尸事件和 15 条测试告警。
4.3 MTTR 计算示例与公式
MTTR 的标准计算公式为：
MTTR = Σ(解决时间_i - 创建时间_i) / N
其中：
- 解决时间_i：第 i 个事件的最终关闭时间
- 创建时间_i：第 i 个事件的首次触发时间
- N：有效事件总数在实际值班台场景中，通常将 MTTR 拆分为三个子阶段，以便定位瓶颈：
| 子阶段 | 计算公式 | 典型目标 |
|---|---|---|
| MTTA（平均确认时间） | Σ(确认时间 - 创建时间) / N | < 5 分钟 |
| MTTD（平均诊断时间） | Σ(诊断完成时间 - 确认时间) / N | < 15 分钟 |
| MTTR（平均修复时间） | Σ(解决时间 - 诊断完成时间) / N | < 20 分钟 |
计算示例：某值班台一周内处理了 5 个事件，时间记录如下（单位：分钟）：
事件A：创建 09:00 → 确认 09:03 → 诊断完成 09:12 → 解决 09:28
事件B：创建 10:15 → 确认 10:18 → 诊断完成 10:35 → 解决 10:50
事件C：创建 11:00 → 确认 11:02 → 诊断完成 11:20 → 解决 11:45
事件D：创建 13:30 → 确认 13:35 → 诊断完成 13:50 → 解决 14:10
事件E：创建 15:00 → 确认 15:04 → 诊断完成 15:25 → 解决 15:40
MTTA = (3+3+2+5+4) / 5 = 3.4 分钟
MTTD = (9+17+18+15+21) / 5 = 16.0 分钟
MTTR = (16+15+25+20+15) / 5 = 18.2 分钟
整体 MTTR = (28+35+45+40+40) / 5 = 37.6 分钟
注意：整体 MTTR（37.6 分钟）不等于 MTTA + MTTD + MTTR 子阶段之和（3.4+16.0+18.2=37.6 分钟），两者在数学上等价。但拆分子阶段能帮助团队识别是响应慢、诊断慢还是修复慢，从而制定针对性优化措施。
4.4 数据采集自动化建议
- 定时任务采集：每 5 分钟从事件管理系统拉取增量事件，写入时序数据库（如 InfluxDB、VictoriaMetrics）。
- 实时流处理：通过 Kafka 接收 Webhook 事件，使用 Flink 或 Stream Processing 框架实时计算滚动 MTTR。
- 数据质量监控：对采集管道设置告警，当数据缺失率超过 5% 或时间戳异常比例超过 2% 时触发值班通知。
- 历史数据回填：首次部署时，从各系统导出过去 90 天的事件数据，建立基线 MTTR 用于后续对比。
关键指标：数据采集的完整性应达到 99.5% 以上，时间戳精度控制在秒级。建议每周生成一次数据质量报告，包含采集覆盖率、异常值比例、缺失值分布等维度。