1. 课程导论：MTTR复盘痛点、Metric Design核心思想、数据结构重构目标
1.1 为什么MTTR复盘总是“算不清”？
在SRE日常故障管理中，MTTR（Mean Time to Repair，平均修复时间）是最核心的可用性指标之一。然而，绝大多数团队在复盘时都会遇到同一个困境：数据口径不一致，导致复盘结论无法对齐。
以下是我们在多个大型互联网企业故障复盘现场总结的典型痛点：
| 痛点 | 具体表现 | 后果 |
|---|---|---|
| 时间起点不统一 | 有的团队从“告警触发”开始计时，有的从“值班人员确认”开始，有的从“故障定级”开始 | 同一故障，不同团队算出的MTTR相差30%~50% |
| 修复动作定义模糊 | “修复完成”是指代码回滚完成？流量切换完成？还是监控指标恢复？ | 复盘时反复争论“到底算不算修好” |
| 人工记录偏差 | 值班人员手工填写故障时间线，存在记忆偏差、漏填、补填 | 数据可信度低，无法用于自动化分析 |
| 跨系统数据孤岛 | 监控系统、变更平台、工单系统、CMDB各自记录不同时间戳 | 复盘需要手动拉取多份数据，耗时且易出错 |
| 聚合粒度混乱 | 按周聚合还是按月聚合？按服务聚合还是按团队聚合？ | 趋势分析失真，无法有效驱动改进 |
核心矛盾：MTTR本身是一个数学公式（总修复时间 / 故障次数），但如果没有统一、可追溯、可自动计算的数据结构，这个公式在不同场景下会得出完全不同的结果。MTTR复盘不是“算不出来”，而是“算出来没人信”。
1.2 Metric Design：从“事后统计”到“事前定义”
要解决上述痛点，不能只靠流程规范或人工对齐。我们需要引入Metric Design（指标设计）的方法论——在数据产生之前，就定义好指标的结构、来源、计算规则和约束条件。
Metric Design的核心思想可以概括为三个层次：
- 语义层（Semantic Layer）：明确指标的业务含义，消除歧义。例如“MTTR”必须拆解为“检测时间（TTD）”、“响应时间（TTR）”、“修复时间（TTF）”三个子阶段。
- 结构层（Structural Layer）：定义指标的数据模型，包括时间戳、维度标签、度量值、关联ID等字段，确保数据可被机器解析和聚合。
- 约束层（Constraint Layer）：设定指标的采集频率、精度、缺失值处理策略、异常值过滤规则，保证数据质量。
关键认知：Metric Design不是“设计一个好看的仪表盘”，而是“设计一套可编程、可验证、可演进的指标数据契约”。它让MTTR从“复盘时的争论话题”变成“系统自动产出的可信数据”。
以下是一个典型的MTTR指标设计对比：
| 维度 | 传统做法（无设计） | Metric Design做法 |
|---|---|---|
| 时间起点 | 人工定义，口头约定 | 固定为“监控系统首次产生P0告警的时间戳” |
| 时间终点 | “业务恢复”模糊描述 | 固定为“核心成功率指标连续5分钟恢复至基线99.9%” |
| 数据来源 | 值班日志 + 事后回忆 | 监控系统 + 变更系统 + 工单系统自动采集 |
| 聚合方式 | 简单平均 | 按故障等级加权，支持P50/P90/P99分位计算 |
| 校验机制 | 无 | 自动校验时间线连续性，缺失数据标记为“无效” |
1.3 数据结构重构目标：让MTTR可计算、可追溯、可改进
基于Metric Design思想，本课程的核心目标是重构MTTR复盘背后的数据结构。这不是一次简单的数据库表结构调整，而是一次从数据模型到计算引擎的体系化升级。
具体目标分为以下四个维度：
- 目标一：统一时间线模型
- 定义故障时间线的标准字段：
fault_id、detect_time、respond_time、repair_time、recover_time - 所有系统统一使用UTC时间戳，精度到毫秒
- 定义故障时间线的标准字段：
- 目标二：建立维度标签体系
- 每个故障记录必须携带：
service_name、team_name、severity、root_cause_type - 支持按任意维度组合进行下钻分析
- 每个故障记录必须携带：
- 目标三：实现自动化数据管道
- 从告警系统、变更系统、CMDB自动拉取数据，生成标准化的故障事件表
- 数据延迟不超过1分钟，满足实时复盘需求
- 目标四：构建可复用的计算引擎
- 支持MTTR、MTTD、MTTF等指标的预计算与实时计算
- 输出结果直接对接BI报表和告警平台
下图展示了本次数据结构重构的整体架构：
1.4 课程收益与适用人群
通过本课程的学习，你将获得以下核心能力：
| 角色 | 核心收益 |
|---|---|
| SRE工程师 | 掌握从监控数据到MTTR指标的全链路设计方法，提升故障复盘效率 |
| 数据架构师 | 学会构建可扩展、可校验的故障数据模型，支撑大规模SLA/SLO体系 |
| 技术管理者 | 获得统一团队MTTR口径的实操方案，让数据驱动改进成为可能 |
| 平台开发工程师 | 理解如何设计故障时间线采集SDK和计算引擎，提升平台数据质量 |
课程前置要求：建议具备基础的SRE故障管理经验，了解MTTR、MTTD等基本概念，熟悉至少一种关系型数据库或时序数据库的基本操作。不需要精通数据建模，但需要具备一定的系统架构思维。