事故响应生命周期：从告警触发到故障恢复的完整流程概述

事故响应生命周期是 SRE 运维体系中最核心的闭环流程。它定义了从监控系统发出告警，到工程师介入排查、执行变更、最终恢复服务并完成复盘的全过程。理解这个生命周期，是编写高质量 Runbook 和设计自动化变更窗口的前提。

一个标准的事故响应生命周期通常包含以下 6 个阶段：

生命周期全景流程图

下图展示了事故响应生命周期的完整流向，以及各阶段之间的关键决策点：

各阶段详细拆解

阶段 1：告警触发

监控系统通过预定义的阈值规则（如 P99 延迟 > 500ms、错误率 > 1%）产生告警。告警通过 PagerDuty、钉钉、飞书或自研平台发送给值班工程师。

• 输入： 监控指标数据流
• 输出： 告警通知（含告警级别、指标值、影响范围）
• 常见问题： 告警风暴、重复告警、缺乏上下文

阶段 2：告警确认

值班工程师收到告警后，需要在 5 分钟内 完成确认。确认动作包括：查看 Grafana 仪表盘、检查服务健康状态、判断是否为已知问题。

• 关键决策： 真实故障 vs 误报
• 误报处理： 标记为误报，更新告警规则，返回阶段 1
• 真实故障： 进入阶段 3，同时启动事故响应计时

阶段 3：故障定界

这是整个生命周期中技术难度最高的阶段。工程师需要快速缩小故障范围，定位根因。常用手段包括：

• 查看服务依赖拓扑图，确认故障传播路径
• 分析应用日志（ELK/Loki），查找异常堆栈
• 检查基础设施指标（CPU、内存、网络、磁盘）
• 确认最近变更记录（发布、配置修改、扩缩容）

阶段 4：变更执行（变更窗口）

一旦定位到根因，立即进入变更窗口。Runbook 在此阶段提供标准化的恢复步骤。变更类型通常包括：

• 回滚： 回退到上一个稳定版本（最常用）
• 热修复： 修改配置、重启服务、扩容实例
• 降级： 关闭非核心功能，保障核心链路
• 切换： 切换到备用集群或灾备环境

# 示例：Runbook 中的回滚变更步骤
# 步骤 1：确认当前版本
kubectl get deployment my-service -o jsonpath='{.spec.template.spec.containers[0].image}'

# 步骤 2：执行回滚到上一个版本
kubectl rollout undo deployment/my-service

# 步骤 3：验证 Pod 状态
kubectl rollout status deployment/my-service --timeout=120s

# 步骤 4：检查服务健康
curl -s http://my-service:8080/health | jq .status

阶段 5：持续观测

变更执行完成后，不能立即关闭告警。需要持续观测 5-15 分钟，确认以下指标回归正常：

• 错误率恢复到基线以下
• 延迟 P99 回到正常范围
• 服务可用性达到 SLA 要求
• 无新的告警产生

阶段 6：复盘改进

故障恢复后，需要在 24-48 小时内完成事故复盘。复盘的核心产出包括：

• 事故报告： 记录时间线、根因、影响范围、恢复措施
• Runbook 更新： 补充本次故障的排查步骤和变更脚本
• 监控优化： 增加或调整告警规则，避免漏报/误报
• 自动化改进： 将手动操作转化为自动化 Runbook 步骤

生命周期中的关键指标

生命周期与 Runbook 的映射关系

Runbook 不是孤立存在的文档，它贯穿整个事故响应生命周期。下表展示了 Runbook 在各阶段的具体作用：