概述
故障不可避免，但故障响应的质量决定了影响范围和持续时间。一个成熟的故障响应框架能够在混乱中建立秩序——让正确的人在做正确的事，让信息流向该去的地方，让恢复速度尽可能快。
很多团队在故障发生时面临的真实场景是：告警轰炸、群消息刷屏、不知道谁在负责、重复排查同一个问题、对外信息不一致、故障恢复后说不清楚做了什么。这些问题的根因不是技术能力不足，而是缺乏结构化的响应框架。
从故障分级、响应角色分工、escalation 路径设计、通信模板、时间线记录到恢复策略，详细梳理如何构建一个可执行的故障响应框架。
关于故障响应的系统方法论，可参考 Google SRE Book - Managing Incidents 和 Atlassian Incident Management Handbook。
一、故障分级标准
为什么需要分级
没有分级的故障管理等于没有管理。如果所有故障都按最高优先级处理，结果就是没有真正的最高优先级。故障分级的本质是资源调度优先级——在有限的人力下，让最严重的故障优先获得资源。
SEV 分级标准
采用业界通行的 SEV1-SEV4 四级分类：
| 级别 | 定义 | 影响范围 | 响应时效 | 升级条件 | 示例 |
|---|---|---|---|---|---|
| SEV1 | 生产服务完全不可用或核心功能失效 | 全量或大量用户受影响，营收直接损失 | 立即响应，<5min | 15min 无进展自动升级 | 支付服务宕机、数据库不可用、核心 API 全部 5xx |
| SEV2 | 核心功能严重降级 | 部分用户受影响，业务功能受损 | <15min | 30min 无进展自动升级 | 支付成功率下降 20%、P99 延迟劣化 5 倍 |
| SEV3 | 非核心功能降级或潜在风险 | 少量用户受影响或无直接影响 | <30min（工作时间） | 无需自动升级 | 某非核心服务异常、磁盘水位 80% |
| SEV4 | 优化建议或已知问题 | 无用户影响 | 下一工作日 | 无需升级 | 告警阈值优化、文档补充 |
分级判定要素
故障分级需要考虑多个维度，不是单一指标决定的：
# 故障分级判定矩阵
severity_matrix:
dimensions:
- user_impact: # 用户影响
none: 0
minimal: 1 # <1% 用户受影响
moderate: 2 # 1-10% 用户受影响
significant: 3 # 10-50% 用户受影响
severe: 4 # >50% 用户受影响
- business_impact: # 业务影响
none: 0
low: 1 # 非核心功能，无营收影响
medium: 2 # 核心功能降级，营收轻微影响
high: 3 # 核心功能失效，营收明显损失
critical: 4 # 全站不可用，营收严重损失
- duration: # 持续时间（已持续或预计）
unknown: 3 # 未知持续时间按高风险处理
brief: 1 # <5 分钟
short: 2 # 5-30 分钟
medium: 3 # 30 分钟 - 2 小时
long: 4 # >2 小时
# 最高维度决定 SEV 级别
rule: "max(user_impact, business_impact) + duration_bonus"
# duration_bonus: 如果持续时间 > 预期，SEV 上调一级
自动分级
理想状态下，故障级别应该能通过告警规则自动确定：
# Prometheus 告警自动分级
groups:
- name: incident-severity
rules:
# SEV1: 核心服务完全不可用
- alert: SEV1CriticalServiceDown
expr: |
up{job="payment-service",env="production"} == 0
for: 1m
labels:
severity: SEV1
page: true
escalation: true
auto_bridge: true # 自动创建电话会议
annotations:
summary: "支付服务完全不可用"
impact: "全量用户无法支付，营收直接损失"
runbook: "https://wiki/runbooks/payment-service-down"
ic_rotation: "primary-oncall"
# SEV2: 错误率超标
- alert: SEV2HighErrorRate
expr: |
sum(rate(http_requests_total{job="payment-service",status=~"5.."}[5m]))
/
sum(rate(http_requests_total{job="payment-service"}[5m])) > 0.05
for: 2m
labels:
severity: SEV2
page: true
escalation: false
annotations:
summary: "支付服务错误率超过 5%"
impact: "部分用户支付失败"
runbook: "https://wiki/runbooks/high-error-rate"
# SEV3: 资源水位告警
- alert: SEV3DiskUsageHigh
expr: |
(1 - node_filesystem_avail_bytes / node_filesystem_size_bytes) * 100 > 80
for: 5m
labels:
severity: SEV3
page: false
notify: "#alerts-warn"
annotations:
summary: "磁盘使用率超过 80%"
runbook: "https://wiki/runbooks/disk-cleanup"
分级调整
故障级别不是一成不变的。随着事态发展，需要动态调整：
场景：SEV3 磁盘告警
→ 排查发现磁盘即将满 → 服务可能崩溃
→ 升级为 SEV2
→ 磁盘满了，服务开始报错
→ 升级为 SEV1
调整规则：
- 任何参与响应的人都可以建议调整级别
- 最终决定权在 Incident Commander（IC）
- 级别调整需要广播通知所有响应者
- 升级比降级更安全——宁可过度响应也不要响应不足
二、响应角色分工
核心角色
故障响应中需要明确以下角色，每个角色有清晰的职责边界：
| 角色 | 缩写 | 职责 | 人选要求 |
|---|---|---|---|
| Incident Commander | IC | 统一指挥，做决策，协调资源 | 有经验的高级 SRE/技术负责人 |
| Operations Lead | Ops | 执行技术操作，排查和修复 | On-Call 工程师 |
| Communications Lead | Comms | 对内对外沟通，发布状态更新 | 技术背景的沟通人员/PM |
| Scribe | 记录员 | 记录时间线、决策、操作 | 任何可以打字快的人 |
| Subject Matter Expert | SME | 提供特定领域的技术判断 | 相关服务的负责人 |
角色之间的关系
┌──────────────┐
│ IC │ ← 统一指挥，不做具体操作
│ 指挥官 │
└──────┬───────┘
│
┌────────────┼────────────┐
│ │ │
┌──────▼──────┐ ┌──▼───┐ ┌──────▼──────┐
│ Ops │ │Scribe│ │ Comms │
│ 操作执行 │ │记录员│ │ 通信联络 │
└──────┬──────┘ └──────┘ └─────────────┘
│
┌──────▼──────┐
│ SME │ ← 按需介入，提供专业判断
│ 领域专家 │
└─────────────┘
关键原则：IC 不做具体操作。 IC 的注意力应该在全局——决策、协调、评估风险。如果 IC 在敲命令排查问题，就没有人在看全局。
各角色详细职责
Incident Commander（IC）
IC 是故障响应的灵魂角色。不一定是技术最强的人，但必须是最能做决策和协调的人。
IC 的核心职责：
- 确认故障并定级：收到告警后，快速评估影响并确定 SEV 级别
- 组建响应团队：召集需要的角色——Ops、Comms、SME
- 制定恢复策略：决定先做什么后做什么，权衡风险
- 协调资源：调用其他团队、申请额外资源
- 控制节奏：避免混乱，确保每个操作有明确指令和确认
- 决定升级：判断是否需要升级故障级别或请求更多支援
- 宣布恢复：确认故障已恢复，结束响应
IC 的行为规范：
ic_principles:
do:
- "保持全局视角，不陷入细节"
- "明确指令：谁在什么时间做什么"
- "定期同步进展：每 15 分钟更新一次状态"
- "鼓励信息共享：'如果你发现了什么，告诉我'"
- "做决策并承担后果：'我们先回滚，再看原因'"
dont:
- "不要亲自执行技术操作"
- "不要让多个人同时操作同一个系统"
- "不要在没有确认的情况下执行不可逆操作"
- "不要忽略任何人的信息——哪怕看起来不重要"
Operations Lead（Ops）
Ops 是执行者，负责具体的技术操作。
Ops 的核心职责：
- 执行排查：按照 IC 的指令或 Runbook 排查问题
- 执行修复：执行回滚、重启、扩容、限流等操作
- 反馈结果：每一步操作后立即向 IC 报告结果
- 建议方案：基于技术判断向 IC 建议恢复方案
Ops 的工作方式：
IC: "先检查最近的变更记录"
Ops: "10:00 有一位开发者提交了配置变更，修改了数据库连接超时时间"
IC: "回滚这个变更"
Ops: "正在回滚...回滚完成，错误率开始下降"
Ops: "错误率已恢复正常，P99 延迟回落到 180ms"
IC: "好，观察 10 分钟确认稳定"
Communications Lead（Comms）
Comms 负责所有对内对外的沟通。在大规模故障中，沟通本身就是一个全职工作。
Comms 的核心职责：
- 对内同步：定期向公司内部同步故障状态
- 对外公告：通过状态页、社交媒体向用户发布通知
- 管理层汇报：向技术管理层汇报故障进展
- 过滤信息：把技术细节翻译成业务语言
对内通信模板：
## [SEV1] 支付服务不可用 - 状态更新 #3
**时间**：2026-07-10 15:00
**级别**：SEV1
**状态**：排查中
### 当前情况
支付服务于 14:30 开始出现大量 5xx 错误，目前已影响约 15% 的支付请求。
SRE 团队已介入排查，初步判断与 14:00 的一次数据库配置变更有关。
### 正在执行
- 正在回滚数据库配置变更
- 预计 15 分钟内恢复
### 影响评估
- 受影响用户：约 15% 的支付请求失败
- 预计营收影响：约 XX 万元/小时
- 数据影响：无数据丢失
### 下次更新
15:15
对外状态页公告：
## 服务异常 - 支付功能
我们检测到部分用户在使用支付功能时遇到问题。我们的技术团队正在紧急处理中。
**影响范围**：部分用户的支付请求可能失败
**开始时间**：2026-07-10 14:30 UTC+8
**当前状态**：排查中
我们将每 15 分钟更新一次进展。感谢您的耐心等待。
---
2026-07-10 14:35 - 问题已确认，团队正在处理
2026-07-10 14:50 - 已定位问题，正在执行修复
2026-07-10 15:05 - 修复已执行，正在验证恢复
2026-07-10 15:15 - 服务已恢复正常
Scribe（记录员）
Scribe 的职责是记录故障期间的所有关键信息，为事后复盘提供原始素材。
Scribe 需要记录的内容：
# 故障时间线记录
## 基本信息
- 故障 ID：INC-2026-0710-001
- 级别：SEV1
- 开始时间：14:30
- 恢复时间：15:15
- 持续时间：45 分钟
- IC：张三
- Ops：李四
- Comms：王五
## 时间线
| 时间 | 事件 | 操作人 | 来源 |
|------|------|--------|------|
| 14:30 | Prometheus 告警：支付服务错误率 >5% | 自动告警 | AlertManager |
| 14:32 | 张三响应告警，确认为 SEV1 | 张三 | IM 群 |
| 14:33 | 张三组建响应团队：IC=张三, Ops=李四, Comms=王五 | 张三 | 电话会议 |
| 14:35 | 李四开始排查，检查 Grafana 监控 | 李四 | 操作记录 |
| 14:37 | 李四发现数据库连接数异常 | 李四 | Grafana |
| 14:40 | 李四检查变更记录，发现 14:00 的数据库配置变更 | 李四 | Git log |
| 14:42 | IC 决定回滚配置变更 | 张三 | 电话会议 |
| 14:45 | 李四执行回滚 | 李四 | kubectl |
| 14:48 | 错误率开始下降 | 李四 | Grafana |
| 14:52 | 错误率恢复正常，P99 延迟仍偏高 | 李四 | Grafana |
| 15:00 | 延迟恢复正常 | 李四 | Grafana |
| 15:05 | 观察 5 分钟，确认稳定 | 张三 | - |
| 15:15 | IC 宣布故障恢复 | 张三 | IM 群 |
角色轮换
长时间故障（>2 小时）需要轮换响应人员，避免疲劳导致判断失误：
故障持续 >2 小时：
→ IC 交接给备班 IC
→ Ops 交接给备班 Ops
→ 交接时做 5 分钟简报：当前状态、正在做什么、下一步计划
→ 交出方休息至少 4 小时后再回来
故障持续 >6 小时：
→ 全员轮换
→ 考虑请求跨团队支援
三、Escalation 路径设计
Escalation 的触发条件
Escalation（升级）不是"我搞不定了才找人帮忙"，而是在明确条件下自动触发的资源调度：
| 触发条件 | Escalation 目标 | 延迟 |
|---|---|---|
| SEV1 告警 | Primary On-Call | 立即 |
| Primary 5 分钟未响应 | Secondary On-Call | +5min |
| Secondary 5 分钟未响应 | SRE 负责人 | +10min |
| SEV1 15 分钟无进展 | 服务负责人 + 技术总监 | +15min |
| SEV1 30 分钟未恢复 | CTO | +30min |
| 影响超过 50% 用户 | 全管理层 | 立即 |
Escalation 矩阵
# Escalation 矩阵
escalation_matrix:
SEV1:
step_1:
delay: 0min
targets:
- role: "Primary On-Call"
contact: "phone + pagerduty"
timeout: 5min
step_2:
delay: 5min # Primary 未响应
targets:
- role: "Secondary On-Call"
contact: "phone + pagerduty"
timeout: 5min
step_3:
delay: 10min # Secondary 未响应
targets:
- role: "SRE Team Lead"
contact: "phone"
timeout: 5min
step_4:
delay: 15min # 仍无进展
targets:
- role: "Service Owner"
contact: "phone"
- role: "Engineering Director"
contact: "phone + im"
step_5:
delay: 30min # 仍未恢复
targets:
- role: "CTO"
contact: "phone"
step_6:
delay: 60min # 长时间未恢复
targets:
- role: "All Hands"
contact: "mass notification"
SEV2:
step_1:
delay: 0min
targets:
- role: "Primary On-Call"
contact: "pagerduty + im"
timeout: 15min
step_2:
delay: 15min
targets:
- role: "Secondary On-Call"
contact: "pagerduty + phone"
step_3:
delay: 30min # 无进展
targets:
- role: "SRE Team Lead"
contact: "im"
SEV3:
step_1:
delay: 0min
targets:
- role: "On-Call"
contact: "im only"
# 工作时间内处理，不电话呼叫
Escalation 的执行原则
- 自动优先：使用 PagerDuty/Opsgenie 等工具实现自动 escalation，不依赖人工判断
- 宁早勿晚：不确定是否该升级时，升级。延迟升级的代价通常远大于过度升级
- 信息完整：每次 escalation 都要携带完整的上下文——故障摘要、当前状态、已尝试的方案
- 不中断响应：升级是增加资源，不是换人——被升级的人加入响应，原响应者继续工作
Escalation 通知模板
# Escalation 通知模板
## SEV1 Escalation: 支付服务不可用
**故障摘要**：支付服务自 14:30 起出现大量 5xx 错误，约 15% 用户受影响
**当前状态**：已排查 15 分钟，定位到数据库配置变更，回滚中
**已尝试方案**：
1. 检查服务日志 - 发现数据库连接超时
2. 检查变更记录 - 14:00 有数据库配置变更
3. 正在回滚配置
**需要帮助**：需要 DBA 团队确认回滚方案是否安全
**IC**：张三
**电话会议**：https://meet.example.com/incident-001
**时间线文档**：https://wiki/incidents/INC-2026-0710-001
四、通信模板与规范
通信渠道设计
故障期间的通信需要分渠道、分受众：
| 渠道 | 受众 | 内容 | 频率 |
|---|---|---|---|
| 电话会议/War Room | 响应团队 | 技术讨论、决策、操作指令 | 持续在线 |
| IM 群（#incident-xxx） | 响应团队 + 相关方 | 技术细节、操作记录 | 实时 |
| IM 群（#company-status） | 全公司 | 非技术性的状态更新 | 每 15-30 分钟 |
| 状态页（status.example.com） | 外部用户 | 用户友好的故障通知 | 每 15-30 分钟 |
| 社交媒体 | 外部用户 | 简短故障通知 | 重大故障时 |
| 邮件 | 管理层 + 关键客户 | 详细影响评估 | 重大故障时 |
War Room 规范
War Room 是故障响应的指挥中心，可以是物理会议室或虚拟电话会议。
War Room 规则：
1. 只有响应角色进入 War Room（IC, Ops, Comms, Scribe, SME）
2. 其他人通过 IM 群获取信息，不进入 War Room
3. War Room 内只讨论当前故障，不讨论其他话题
4. 所有操作指令通过 IC 下达，不自行操作
5. 所有关键决策和操作由 Scribe 记录
状态更新模板
# 故障状态更新模板
## [SEV级别] 故障标题 - 更新 #N
**时间**：YYYY-MM-DD HH:MM
**级别**：SEVX
**状态**：[排查中/处理中/恢复中/已恢复]
**持续时间**：XX 分钟
### 当前情况
[一段话描述当前状态]
### 影响范围
- 受影响用户：[百分比/数量]
- 受影响功能：[列出]
- 业务影响：[量化]
### 正在执行
1. [当前操作 1]
2. [当前操作 2]
### 下一步计划
1. [计划操作 1]
2. [计划操作 2]
### 预计恢复时间
[预计时间或"无法预估"]
### 下次更新
[时间]
通信纪律
communication_discipline:
war_room:
- "只说与故障相关的事"
- "大声说出来——即使你认为不重要"
- "如果有疑问，直接问 IC"
- "操作前声明，操作后确认"
im_channel:
- "只有 Comms 角色发状态更新"
- "技术讨论用线程回复"
- "不要在群里刷屏——重要信息会被淹没"
- "截图要带时间戳"
examples:
good:
- "Ops: 我在 server-01 上执行了回滚，错误率从 15% 降到 2%"
- "IC: 收到。李四，继续观察 5 分钟。王五，发一次状态更新。"
bad:
- "Ops: 我觉得可能是数据库的问题" # ← 没有依据的猜测
- "某人: 天啊又挂了！！！" # ← 情绪化发言
- "某人: 这个问题上次也出现过" # ← 无助于当前恢复
五、时间线记录
为什么时间线很重要
时间线记录在故障响应中经常被忽视——因为大家都忙着解决问题，没人想停下来写记录。但时间线是事后复盘的基石，没有准确的时间线，复盘就变成了"各说各话"。
时间线的三个用途：
- 实时参考：帮助 IC 和响应者了解"我们做了什么、结果如何"
- 事后复盘：Postmortem 的核心素材
- 合规审计：某些行业要求保留故障记录用于审计
时间线记录工具
# 时间线记录工具选择
timeline_tools:
real_time:
- tool: "专用 Incident 管理工具（如 FireHydrant, Rootly）"
pros: "结构化，自动关联告警和变更"
cons: "需要预先部署和集成"
- tool: "Google Doc / 协作文档"
pros: "零部署成本，所有人可同时编辑"
cons: "非结构化，需要人工整理"
- tool: "IM 群消息 + Bot"
pros: "响应者已在用 IM，无额外操作"
cons: "信息分散，需要后期整理"
recommended: "IM 群 + Bot 自动记录，同时用协作文档做结构化整理"
自动化时间线收集
# 从多个数据源自动收集时间线事件
class TimelineCollector:
def __init__(self, incident_id):
self.incident_id = incident_id
self.events = []
def collect_from_alertmanager(self, start_time, end_time):
"""从 AlertManager 收集告警事件"""
alerts = query_alertmanager(start_time, end_time)
for alert in alerts:
self.events.append({
"time": alert["starts_at"],
"type": "alert",
"description": alert["annotations"]["summary"],
"source": "AlertManager"
})
def collect_from_git(self, start_time, end_time):
"""从 Git 收集变更事件"""
commits = query_git_log(start_time, end_time)
for commit in commits:
self.events.append({
"time": commit["timestamp"],
"type": "change",
"description": f"代码变更: {commit['message']} ({commit['author']})",
"source": "Git"
})
def collect_from_ci_cd(self, start_time, end_time):
"""从 CI/CD 收集部署事件"""
deploys = query_deployments(start_time, end_time)
for deploy in deploys:
self.events.append({
"time": deploy["timestamp"],
"type": "deploy",
"description": f"部署: {deploy['service']} {deploy['version']}",
"source": "CI/CD"
})
def collect_from_chat(self, incident_channel, start_time):
"""从 IM 群收集人工记录"""
messages = query_chat_history(incident_channel, start_time)
for msg in messages:
if msg.get("type") in ["action", "decision", "finding"]:
self.events.append({
"time": msg["timestamp"],
"type": msg["type"],
"description": msg["text"],
"source": msg["user"]
})
def generate_timeline(self):
"""生成排序后的时间线"""
return sorted(self.events, key=lambda x: x["time"])
时间线记录规范
好的时间线记录：
14:35 检查 Grafana 监控，发现数据库连接数从 50 飙升到 500 [李四]
14:37 确认连接数飙升与 14:00 的配置变更时间吻合 [李四]
14:42 IC 决定回滚配置变更 [张三]
14:45 执行 kubectl rollout undo deployment/payment-svc [李四]
14:48 错误率从 15% 降至 2% [李四]
不好的时间线记录：
14:35 看了一下监控 ← 看了什么？发现了什么？
14:42 决定回滚 ← 谁决定的？为什么？
14:45 操作了 ← 操作了什么？在哪个系统？
六、恢复策略
恢复优先级：先恢复，后修复
故障响应的第一原则是尽快恢复服务，而不是找到根因后再修复。
错误做法：
故障发生 → 找根因 → 找了 30 分钟 → 找到了 → 修复 → 恢复
总时间：45 分钟
正确做法：
故障发生 → 快速评估 → 回滚最近的变更 → 恢复 → 再找根因
总时间：10 分钟
恢复策略决策树
故障发生
│
├─ 最近 30 分钟内有变更？
│ ├─ 是 → 回滚变更 → 观察是否恢复
│ │ ├─ 恢复 → 故障结束，事后分析根因
│ │ └─ 未恢复 → 继续排查
│ │
│ └─ 否 → 检查监控指标
│ │
│ ├─ 资源耗尽（CPU/内存/磁盘/连接）？
│ │ → 扩容/清理/重启 → 观察是否恢复
│ │
│ ├─ 依赖服务异常？
│ │ → 切换备用依赖/降级功能 → 观察是否恢复
│ │
│ ├─ 流量异常（突发流量/攻击）？
│ │ → 限流/WAF 拦截 → 观察是否恢复
│ │
│ └─ 无明显线索
│ → 重启服务（最后手段）→ 观察是否恢复
│ → 如果仍未恢复，按 escalation 升级
常见恢复策略
| 策略 | 适用场景 | 操作 | 风险 |
|---|---|---|---|
| 回滚 | 变更导致的故障 | kubectl rollout undo | 低（如果变更前正常） |
| 扩容 | 容量不足 | HPA 扩容或手动加节点 | 低 |
| 降级 | 部分功能故障 | 关闭非核心功能，保核心 | 中（用户体验降低） |
| 限流 | 流量过大 | 调低限流阈值 | 中（部分用户被拒） |
| 重启 | 服务卡死 | kubectl delete pod | 中（短暂中断） |
| 切流 | 单机房故障 | 切换到备用机房 | 高（需要多活架构支持） |
| 回滚数据 | 数据损坏 | 恢复数据库备份 | 高（可能丢失数据） |
恢复验证
故障"看起来恢复了"不等于"真的恢复了"。需要系统性地验证：
# 恢复验证检查清单
recovery_verification:
technical_checks:
- "错误率已降至正常水平（<0.1%）"
- "延迟恢复到 SLO 以内（P99 < 200ms）"
- "所有 Pod 处于 Running 状态"
- "数据库连接数恢复正常"
- "队列积压已消化"
business_checks:
- "用户投诉量下降到正常水平"
- "核心业务指标恢复正常（如下单成功率 >99.9%）"
- "客服团队确认用户反馈正常"
monitoring_checks:
- "告警已自动清除"
- "监控仪表盘各项指标正常"
- "黑盒监控探测通过"
observation_period:
duration: "10-15 分钟"
purpose: "确认不是间歇性恢复"
action: "IC 宣布故障恢复后，继续观察 30 分钟"
故障后的收尾
故障恢复后的收尾步骤：
1. IC 宣布故障恢复（IM 群 + 电话会议）
2. Comms 发布恢复公告（状态页 + IM 群）
3. Scribe 完成时间线定稿
4. IC 确认所有响应人员可以休息
5. 创建 Postmortem 工单，设定复盘日期（3-5 个工作日内）
6. 如果是 SEV1/SEV2，24 小时内提交初步 Postmortem
7. 如果有临时修复措施（如降级某功能），记录待后续彻底修复
七、故障响应演练
演练的必要性
故障响应框架不能等到真故障时才第一次使用。定期演练能发现流程中的问题，让团队在真实故障时更从容。
演练类型
| 类型 | 方式 | 频率 | 目的 |
|---|---|---|---|
| 桌面推演 | 讨论式，模拟故障场景，口头走流程 | 每季度 | 验证流程和角色分工 |
| 功能演练 | 模拟单个环节（如 escalation 通知） | 每月 | 验证工具链和通知链路 |
| 红蓝对抗 | 红队注入故障，蓝队响应 | 每半年 | 验证端到端响应能力 |
| 混沌工程 | 自动注入故障，验证自愈 | 持续 | 验证系统弹性和监控覆盖 |
桌面推演示例
# 故障响应桌面推演
## 场景
周五下午 17:00，支付服务突然开始返回大量 5xx 错误。同时收到客服反馈，大量用户投诉支付失败。
## 推演流程
### T+0 分钟：告警触发
- 主持人："17:00，AlertManager 触发 SEV2 告警，支付服务错误率 8%。Primary On-Call 是谁？"
- 参与者（扮演 On-Call）："我是 Primary，我收到了告警。"
### T+2 分钟：响应启动
- 主持人："你会做什么？"
- 参与者："查看 Grafana 确认告警真实性，然后..."
- 主持人追问："然后你会在多少分钟内响应？如果 5 分钟没响应怎么办？"
### T+5 分钟：定级与组建团队
- 主持人："你确认错误率确实 8%，影响 8% 的用户。你怎么定级？"
- 参与者："SEV2。我需要组建响应团队..."
### T+15 分钟：排查
- 主持人："你查了监控，发现数据库连接数正常，但 Redis 延迟飙升。你会做什么？"
- 参与者："检查 Redis 状态..."
### T+30 分钟：Escalation
- 主持人："已经 30 分钟了，问题还没解决。此时应该做什么？"
- 参与者："按照 escalation 矩阵，30 分钟无进展需要升级到 SRE 负责人。"
### 演练复盘
- 哪些步骤执行顺利？
- 哪些步骤卡住了？原因是什么？
- 流程/工具/沟通有什么需要改进的？
总结
故障响应框架的核心价值在于：在混乱中建立秩序。一个好的框架能让团队在压力下依然高效协作，而不是各自为战。
关键要点：
- 分级是基础：清晰的 SEV 分级让资源调度有据可依，自动分级减少人为延迟
- 角色分工是核心：IC 统一指挥不做操作，Ops 执行操作，Comms 负责沟通，Scribe 记录时间线——各司其职，不越位
- Escalation 要自动化：不依赖人工判断，用工具实现自动升级，宁可过度升级也不延迟升级
- 通信要分渠道：War Room 讨论技术，IM 群同步状态，状态页面向用户——信息流向清晰
- 先恢复后修复：回滚 > 降级 > 重启 > 找根因。恢复服务永远是第一优先级
- 时间线是基石：实时记录所有关键事件，为复盘提供事实依据
- 演练是保障：框架不能只在真故障时才用，定期演练才能在关键时刻运转顺畅
记住：故障响应的质量不是由技术最强的人决定的，而是由流程最清晰的人决定的。 当每个人都知道自己该做什么、该跟谁沟通、该在什么时候升级时，故障恢复就变成了一个可预期的工程过程，而不是一场混乱的救火行动。
参考资料与致谢
本文在撰写过程中参考了以下资料，感谢原作者的贡献：
- Google SRE Book - Managing Incidents — Google SRE 团队，参考了Google SRE Book - Managing Incidents相关内容
- Atlassian Incident Management Handbook — Atlassian，参考了Atlassian Incident Management Handbook相关内容