2. 事故响应生命周期：事故发现、事故分类与定级、事故响应启动、事故排查、事故修复、事故复盘
事故响应不是一次性的“救火”行动，而是一个结构化的闭环流程。SRE 团队通过标准化的生命周期管理，确保每个环节都有明确的输入、输出、角色和时限，从而系统性地降低 MTTR。本章将拆解事故响应的六个核心阶段，并给出每个阶段的关键实践与量化指标。
2.1 生命周期全景图
下图展示了事故响应从“发现”到“复盘”的完整闭环。每个阶段都依赖前序阶段的输出，并产生后续阶段所需的输入。跳过或压缩任何阶段，都会导致响应混乱或问题复发。
2.2 阶段一：事故发现
事故发现是生命周期的起点。发现的速度直接决定了 MTTR 的下限。SRE 团队需要建立多层次的发现渠道，避免单一依赖用户投诉。
| 发现渠道 | 典型来源 | MTTD 目标 | 可靠性等级 |
|---|---|---|---|
| 主动监控告警 | Prometheus / Grafana / 自定义探针 | < 1 分钟 | 高（首选） |
| 日志异常检测 | ELK / Loki / 机器学习异常检测 | < 3 分钟 | 中高 |
| 用户反馈工单 | 客服系统 / 社交媒体 / 内部反馈 | < 5 分钟 | 低（被动） |
| 混沌工程实验 | 主动注入故障，验证告警有效性 | N/A（验证手段） | 辅助 |
实践建议： 为每个服务定义“黄金信号”告警（延迟、流量、错误、饱和度），并设置多级告警阈值。避免告警风暴，使用告警聚合和抑制规则。
2.3 阶段二：事故分类与定级
收到告警后，值班人员需要在 5 分钟内完成初步分类和定级。定级标准必须事先定义，避免主观判断导致响应延迟或资源浪费。
2.3.1 通用定级矩阵
| 等级 | 定义 | 影响范围 | 响应要求 | 示例 |
|---|---|---|---|---|
| P0 | 核心服务完全不可用 | 全站 / 所有用户 | 立即响应，5 分钟内启动 | 数据库主库宕机、支付链路中断 |
| P1 | 核心服务严重降级 | 大部分用户 / 核心功能 | 15 分钟内启动 | API 延迟 > 5s、大量 5xx 错误 |
| P2 | 非核心服务不可用或部分用户受影响 | 部分用户 / 次要功能 | 1 小时内启动 | 单个可用区故障、报表服务不可用 |
| P3 | 轻微问题，无用户影响 | 内部 / 运维层面 | 下一个工作日处理 | 告警阈值误报、日志格式错误 |
常见陷阱： 不要将 P0/P1 事故降级为 P2 来逃避紧急响应流程。定级错误会导致资源投入不足，MTTR 急剧上升。建议每季度复盘定级准确性，校准标准。
2.4 阶段三：事故响应启动
定级完成后，立即启动响应流程。这个阶段的核心目标是“快速建立指挥体系”，而不是立即开始排查。
- 建立事故群： 在即时通讯工具中创建专用事故响应群，包含值班人员、相关团队负责人、SRE 经理。
- 指定事故指挥官（IC）： 由经验最丰富的 SRE 担任，负责协调资源、决策优先级、对外沟通。IC 不应亲自排查代码。
- 发布事故通告： 在内部状态页或广播频道发布初步通告，格式为：“[P0] 支付服务不可用，影响范围：全量用户，当前状态：排查中，预计更新时间：5 分钟。”
- 启动计时： 记录事故开始时间、响应启动时间，作为 MTTR 计算的基准。
关键指标： 响应启动时间（Time to Acknowledge, TTA）应控制在 5 分钟以内。超过 10 分钟未启动，自动升级到二级 On-Call。
2.5 阶段四：事故排查
排查阶段是 MTTR 中最不可控的部分。SRE 需要遵循系统化的排查路径，避免“乱枪打鸟”。
2.5.1 排查路径与工具
| 排查步骤 | 目标 | 常用工具 |
|---|---|---|
| 1. 确认影响范围 | 判断是局部还是全局问题 | Grafana 全局视图、告警聚合 |
| 2. 检查变更历史 | 最近 1 小时内是否有代码/配置/基础设施变更 | Git 提交记录、CI/CD 流水线、变更窗口日志 |
| 3. 查看关键指标 | CPU/内存/网络/磁盘/错误率/延迟 | Prometheus / Datadog / CloudWatch |
| 4. 分析日志 | 查找异常堆栈、错误模式 | ELK / Loki / 日志聚类工具 |
| 5. 回滚或隔离 | 如果定位到变更，立即回滚；否则隔离故障单元 | K8s 回滚、流量切换、功能开关 |
排查心法： 遵循“先止血，后找根因”原则。如果 15 分钟内无法定位根因，优先执行已知的恢复操作（如重启、回滚、切流），而不是继续深挖。
2.6 阶段五：事故修复
修复阶段的目标是“恢复服务至正常水平”，不要求完美修复。临时止血措施（如切流到备用集群）也是有效的修复手段。
- 执行恢复操作： 根据排查结果执行回滚、重启、扩容、切流等操作。操作前必须经过 IC 确认，避免多人同时操作导致混乱。
- 验证恢复效果： 观察监控指标是否回归基线，执行冒烟测试确认核心功能正常。
- 发布恢复通告： 在状态页更新：“[P0] 支付服务已恢复，影响时长 23 分钟，根因待复盘确认。”
- 持续监控： 恢复后保持 30 分钟观察期，确认无复发或次生故障。
关键指标： 修复时间（Time to Resolve, TTR）是 MTTR 的核心组成部分。P0 事故的 TTR 目标应控制在 30 分钟以内。
2.7 阶段六：事故复盘
复盘是生命周期的最后一环，也是持续改进的起点。复盘不是追责，而是通过系统化分析，找到流程、工具或架构上的薄弱点。
2.7.1 复盘报告结构
| 章节 | 内容要求 | 负责人 |
|---|---|---|
| 事故概述 | 时间、等级、影响范围、持续时间 | IC |
| 时间线 | 精确到分钟的关键事件时间戳 | 值班 SRE |
| 根因分析（RCA） | 使用 5 Whys 或因果图，找到直接原因和根本原因 | 相关团队 |
| 改进项清单 | 每个改进项需指定负责人和截止日期 | SRE 经理 |
| 行动跟踪 | 在后续周会中跟踪改进项完成情况 | 项目管理 |
2.8 生命周期各阶段 MTTR 分解
理解 MTTR 的构成，有助于针对性优化。下表将 MTTR 拆解为四个子指标，并给出 SRE 团队的参考目标。
| 指标 | 全称 | 定义 | P0 目标 | 优化重点 |
|---|---|---|---|---|
| MTTD | Mean Time to Detect | 从事故开始到被发现的平均时间 | < 2 分钟 | 告警覆盖率、告警延迟 |
| MTTA | Mean Time to Acknowledge | 从发现到响应启动的平均时间 | < 5 分钟 | On-Call 响应机制、升级策略 |
| MTTK | Mean Time to Know | 从响应启动到定位根因的平均时间 | < 15 分钟 | 排查路径、可观测性、Runbook |
| MTTR | Mean Time to Resolve | 从发现到服务恢复的平均时间 | < 30 分钟 | 回滚速度、切流能力、止血手段 |
注意： 不要只关注最终的 MTTR 数值。如果 MTTD 很长，即使修复很快，整体 MTTR 仍然很高。建议在事故报告中同时记录四个子指标，找到真正的瓶颈环节。