10 事件管理（Incident Management）

概述#

告警响了、值班人 ack 了，然后呢？90% 的团队没有结构化的响应流程——群聊里 30 个人问"谁能看一下"，5 个人在查、8 个人在聊天、业务方没人通报。本章建立规范化的事故响应流程，核心是角色分工和响应节奏。

事件管理的本质是把"混乱的群聊救火"变成"有指挥、有节奏、有沟通"的结构化响应。这不是官僚主义，是工程方法——人在高压下的判断力会下降，结构化流程能保证即使在压力下也能做出合理决策。

一、事故分级：SEV-1 到 SEV-4#

没有分级就没有响应节奏。每个事故首先定义它的严重性级别：

分级的关键原则#

1. 宁可高估不要低估。升级容易降级难。发现问题的第一时间按最严重预估，确认没问题再降。
2. 分级决定流程，不决定责任。SEV-1 不等于"谁写错了代码"，只意味着需要加倍资源响应。
3. 有上升风险就升级。看起来像 SEV-2 但有可能变成 SEV-1 → 直接按 SEV-1 处理。
4. 影响范围动态评估。事故刚开始看起来是 SEV-3，但扩散到更多用户后要升级为 SEV-2。

分级的常见误区#

• 只看技术严重度不看业务影响：DB 主库挂了是技术大事，但如果是凌晨 3 点无流量，影响有限，可能是 SEV-2 而不是 SEV-1
• 忽略数据丢失：数据丢失即使影响范围小也应该是 SEV-1——数据是组织资产
• 忽略安全事件：安全事件即使没影响用户也应该是 SEV-1——潜在损失巨大
• 不敢升级：怕"小题大做"而拖延升级，最终导致事故扩大

二、角色定义：IC / Ops Lead / CL / IMOC#

结构化响应的核心是：每次事故都有明确的指挥结构。这套结构借鉴自应急响应领域的 ICS（Incident Command System），经过简化适用于软件团队。

Incident Commander（IC）——唯一指挥#

事故响应的指挥官。职责：

• 组织响应节奏
• 做重大决策（rollback / 切流 / 封锁发布）
• 分配任务
• 主持定期通报（每 15 分钟）
• 不写代码，不直接操作，只指挥

IC 最重要的技能是"冷静"和"信息整合"。一个合格的 IC 能在 10 分钟内把群里 30 条消息凝练成 5 行状态摘要。技术深度其次。

IC 不下场是硬规则——IC 一旦开始查代码、敲命令，群龙无首，响应节奏立即崩溃。即使 IC 是团队技术最强的人，事故时也要克制动手冲动，专注指挥。

Ops Lead（运维负责人）——真正动手的人#

负责：

• 执行 IC 分配的技术任务
• 汇报技术状态
• 复现和定位问题
• 回滚/重启/切流等实际操作

Ops Lead 是 IC 的"手脚"。Ops Lead 必须向 IC 实时汇报动作——"我在做 X，预计 Y 分钟，结果会是 Z"。IC 据此决策下一步。

Communications Lead（CL）——对外沟通#

负责：

• 每 15-30 分钟向业务/客服/管理层发状态更新
• 统一对外口径（避免一百个人问一百遍）
• 撰写事故沟通邮件/内部公告
• 维护对外状态页（status page）

这个角色必须存在——缺少 CL 的典型症状：业务方在群里问"什么时候好"没人回。CL 不是"打杂的"，是事故中信息流的守门人。没有 CL，IC 会被"什么时候好"这类问题淹没，无法专注指挥。

Incident Manager on-Call（IMOC）——跨事故管理者#

负责：

• 监督 IC 是否履职
• IC 疲惫时接手
• 跨事故协调资源
• 决定事故升级和降级
• 跨团队协调（如需要其他团队配合）

IMOC 是"IC 的 IC"。当事故持续时间长（>2 小时）或 IC 经验不足时，IMOC 介入。

角色任命时机#

任命方式：在事故频道置顶一条消息：

【角色任命】
IC: @张三
Ops Lead: @李四
CL: @王五
IMOC: @赵六

后来加入的人一看置顶就知道谁在指挥。

团队规模与角色建议#

小团队不需要全套角色——4 个人的团队搞 IC/CL 是过度工程。但即使 1 个人值班，也要有"角色意识"——"现在我是 IC，不写代码"。

三、响应时序：从告警到 Resolve#

一次规范的事故响应按时间顺序：

T+0：告警触发#

• 告警响起（PagerDuty/钉钉）
• 值班人员 acknowledge

T+2min：初步判断#

• 打开 Dashboard 看影响面
• 决定 severity
• SEV-3 以下自己处理，SEV-2 以上拉事故群

T+5min：拉群、任命角色#

群命名规范：#incident-YYYYMMDD-HHmm-<短描述>

IC 贴第一条状态摘要：

【事故摘要 v1】
症状：order-api p99 从 150ms 涨到 8s
影响：下单流程 30% 失败
时间：15:02 开始
初步判断：疑似 MySQL 慢 SQL
当前动作：Ops Lead 正在查 MySQL 进程
下次更新：15:17

T+10min：根因调查#

• Ops Lead 主导调查
• 其他参与者按 IC 分配工作
• 群里禁止发"什么情况"等无效信息
• IC 整合信息，准备下一次通报

T+15min：第一次 Mitigation 尝试#

核心原则：先止损，后找根因。

• 有明确回滚路径 → 优先回滚而非修复
• 任何操作前 IC 确认格式：

  "执行 X 操作，预期 Y，风险 Z，2 分钟后我们看结果"

• 操作后必须验证效果

T+30min：状态复盘#

• 是否有效？
• 需要升级 severity 吗？
• IC 还撑得住吗，需要换人吗？
• 通知范围要扩大吗？
• 需要更多资源吗？

T+Mitigation：确认恢复#

• 业务指标回落到基线
• IC 宣布 mitigation 成功
• 但事故不关闭，进入 monitoring 阶段（至少观察 30 分钟）
• monitoring 期间 CL 持续通报

T + 30min 稳定后：事故关闭#

• IC 宣布事故 Resolved
• 排定复盘会议（48 小时内）
• CL 发送事故总结通报

完整时序示例#

14:31 告警：PaymentAPI_error_rate > 5%
14:31 值班 A ack，dashboard 看错误率 12%
14:32 A 判断 SEV-2，拉事故频道，@IC
14:33 IC B 上线，任命 Ops Lead C，CL D
14:33 B 发第一条摘要：「payment-api 错误率 12%，疑似下游异常」
14:34 C 查 trace，发现 signal-api 返回 500
14:35 C 查 signal-api 日志，发现 redis connection refused
14:36 C 查 redis，发现一个 redis master pod 被 evict
14:37 B 决策：先手动切换 redis 到 replica
14:38 C 执行 sentinel failover
14:39 指标恢复
14:40 B 宣布 mitigation 成功，进入 monitoring
14:55 D 发送第一次对外状态更新
15:10 B 宣布 resolve，安排 48h 内复盘

9 分钟从告警到恢复。这种"教科书式"响应不是一天练成的，是团队跑过 20+ 次事故、打磨过多次流程之后形成的肌肉记忆。

四、事故沟通模板#

人在事故中最容易做不好的是沟通。模板固化下来，压力下也能输出。

事故群置顶#

状态：ongoing / mitigated / resolved
Severity: SEV-2
IC: @张三
CL: @王五
开始时间: 15:02
影响: 下单成功率降低
最新摘要: [链接]

状态摘要（每 15 分钟）#

【事故摘要 v<N>】<时间>
现状: <一句话>
新发现:
- ...
已执行:
- ...
下一步:
- ...
ETA: <估计恢复时间，未知写 "unknown">

ETA 写 "unknown" 比编一个时间好——编的时间被业务方记住后会变成承诺，没兑现就是二次事故。

对外状态页#

[查清中] 我们正在调查订单提交失败的报告
- 15:05 问题被发现
- 15:15 我们已定位到下游服务异常
- 15:30 初步修复已部署，正在验证
- 15:45 服务已恢复，正在监控

关键：用户看不到技术细节，只看到"知道了 → 在查 → 修了 → 恢复了"四个状态。不要写"MySQL 慢 SQL 导致 etcd 写放大"这种话——用户看不懂，且暴露内部架构。

内部通报邮件（SEV-1/2 需要）#

主题: [Incident Report] SEV-2 Order API Degradation (2026-07-01 15:02 - 15:58)

摘要: order-api 在 15:02 到 15:58 期间 p99 显著升高，下单成功率降至 67%。
初步原因为 MySQL 主库慢 SQL 堆积。已通过 kill 慢查询 + rollback 上一次发布恢复。

受影响: 所有 web / mobile 下单用户约 30%
持续: 56 分钟
根因: 初步判断（详细见 postmortem）
恢复方式: rollback + kill query
下一步: 48h 内产出 postmortem 和 action items

SEV-2 以上的邮件一定要有。即使收件人不看，发的这个动作本身就强制你把事情想清楚。

沟通的三个层次#

三层信息不能混用——事故群的技术细节发给用户会引发恐慌，给用户的简单状态发给响应团队不够用。

五、决策框架#

事故中需要做很多决策，IC 必须有清晰的决策框架。

回滚 vs 修复#

是否是发布引起的？
  ├─ 是 → 有明确回滚路径吗？
  │       ├─ 有 → 立即回滚（止损优先）
  │       └─ 无 → 尝试修复（同时准备回滚）
  └─ 否 → 排查根因，尝试修复

回滚永远是首选——回滚是已知操作，风险可控；修复是未知操作，可能引入新问题。

切流 vs 就地修复#

影响范围是否可控？
  ├─ 是 → 就地修复
  └─ 否 → 切流到备用集群/降级服务

切流的代价大（DNS 切换、缓存失效、会话丢失），但比让全站挂掉好。

升级 vs 自己处理#

事故严重度 vs 自己能力
  ├─ SEV-1 → 立即升级，拉更多资源
  ├─ SEV-2 → 评估能力，必要时升级
  ├─ SEV-3 → 自己处理
  └─ SEV-4 → 工单处理

升级不是失败，是流程。早点升级比晚点升级好——晚升级意味着前期处置可能错误，要重新开始。

六、工具栈#

事故管理需要工具支持：

告警与排班#

• PagerDuty / OpsGenie / Grafana OnCall
• Alertmanager（开源）

事件管理#

• incident.io / FireHydrant / Rootly（商业）
• 自研 bot（500 行 Python）

沟通#

• Slack / 钉钉 / 飞书（事故频道）
• Statuspage / Cachet（对外状态页）

文档#

• Confluence / Notion / Markdown 仓库（postmortem）

关键经验#

不要一开始就上专业工具。先用 Confluence + 钉钉频道跑通流程，跑半年再决定是否买专业工具。专业工具主要省 20% 的操作，但 80% 的价值在你的流程和模板。

七、常见反模式#

八、不同规模团队的简化#

事件管理流程要根据团队规模简化：

< 10 人团队#

• 不需要 IC/CL 这套
• 一个值班人处理所有事
• 事故后写简短 postmortem（不追求完整模板）
• 用钉钉群代替事故频道

10-50 人团队#

• 引入 IC 角色，SEV-1/2 规范化
• CL 角色可选（值班人兼任）
• 事故频道用钉钉/Slack
• Postmortem 用标准模板

50-200 人团队#

• 四角色齐全
• 事故管理工具（incident.io 等）
• 对外状态页
• Postmortem 进 wiki

200+ 人团队#

• 专职 IMOC 轮值
• 事故平台工具化
• 自动化事故时间线记录
• 季度事故回顾会

实战要点#

1. IC 不下场操作——IC 写代码查日志的那一刻，群龙无首了。
2. 先止损永远是第一优先级。修好系统再写 root cause analysis。
3. 模板比"灵机一动"靠谱。事故压力下，格式化的模板比临场发挥好十倍。
4. 48 小时内完成复盘（Postmortem），72 小时内开复盘会——下一章展开。
5. SEV-2 以上必须有书面通报——即使收件人不看，发的动作本身强制你把事情想清楚。
6. 事故频道要纯净——无关的人踢出，只留响应人员。50 个人的事故群等于没有指挥。
7. ETA 不会就写 unknown——编造的 ETA 会变成承诺，没兑现就是二次事故。
8. monitoring 期不能省——mitigation 后至少 30 分钟观察，避免回滚后又出问题。
9. 每次事故后 review 流程——这次响应哪里做得好、哪里可以改进，流程本身要迭代。
10. IC 培养是长期投资——IC 不是天生的，需要多次事故演练才能培养出来。平时做"模拟事故"练习。

小结#

结构化事故响应的核心 = CIC：Command（IC 统一指挥）+ Investigation（Ops Lead 主导调查）+ Communication（CL 对外通报）。配合 SEV 分级，把"群聊救火"变成"规范化事故响应"。

判断一个团队的事故响应是否成熟，看三件事：SEV-2 以上事故有标准时序（拉群→任命→mitigation→通报→复盘）、每条事故有完整时间线记录、事故后 48 小时内有 postmortem。三件事都做到是成熟团队；只做到一两件是"在建立中"；一件都没做，事故响应就是"群聊救火"。

下一章讲事故之后最重要的环节——故障复盘，把每次事故变成组织资产。