禾光知寒

主题

架构中级阅读约 1 分钟

事故管理与无指责复盘 ​

本篇定位

系统挂了别慌：把「谁该上、谁说了算、怎么沟通、事后怎么复盘不甩锅」这套流程固定下来。读完你能拿到一份事故分级、On-call 轮值、应急指挥分工、响应流程图和一份可直接复制的无指责 Postmortem 模板。 本篇版本：方法体系基于 Google SRE Book / 业界通用实践，配套工具 Alertmanager 0.34.1、Grafana OnCall（开源）。本文为流程与模板，不绑定特定版本。

一、为什么需要事故管理流程 ​

1.1 小白类比：「火灾来了谁指挥」 ​

饭店着火，若大家各喊各的——有人泼水、有人抢东西、有人乱跑——火只会越烧越大。专业消防队有固定章法：谁报警、谁是现场指挥、谁灭火、谁对外面喊话、谁记录，各司其职，不乱。

线上事故也一样。没有流程时，常见的混乱是：十几个人同时改配置、群里 99+ 条消息没人看、不知道现在谁在操作、对外不知道该说什么。事故管理就是给「救火」定一套流程，让大家在高压下还能有序。

1.2 事故严重性等级 ​

等级定义例子响应要求
SEV-1 致命核心业务全站不可用/数据泄露，影响全部用户支付全挂、数据库主库宕机立刻电话叫醒，全员投入，30 分钟内响应
SEV-2 严重核心功能受损但有降级/部分用户受影响下单慢但能下、部分区域故障5~15 分钟响应，值班立即处理
SEV-3 一般非核心功能问题、有 workaround后台报表慢、某个边缘接口报错工作时间处理，不叫醒
SEV-4 轻微体验问题、不影响业务页面文案错、偶发慢一次排期修复即可

二、On-call 值班与升级路径 ​

2.1 轮值设计 ​

  • 主值班（Primary）：第一个接电话的人，负责初步判断和拉起事故。
  • 副值班（Secondary）：主值班 15 分钟没响应/搞不定时升级到他。
  • 后备（Manager/TL）：两人都搞不定时升级，负责协调资源和对外决策。

2.2 升级路径要点 ​

  • 升级要有明确时间阈值（如主值班 15 分钟不响应自动转副值班），不能靠「觉得差不多了」。
  • 告警要分级：SEV-1/2 走电话+短信，SEV-3 只走群消息，SEV-4 开工单。这正是上一篇 SLO 多燃烧率告警 做的分层。

三、应急指挥（IC）与角色分工 ​

事故一旦拉起战情室（语音会议/群），第一件事是指定一个 IC（Incident Commander，事件指挥官）。IC 自己不动手修，他只管调度。

角色职责小白类比
IC 事件指挥官统一指挥、做决策、宣布升降级/恢复火场总指挥，不自己拿灭火器
OLP 操作负责人真正执行命令、改配置、回滚冲上去灭火的消防员
Comms 通信官对内同步进度、对外发公告对媒体喊话的发言人
Scribe 记录员记录时间线：几点发生了什么现场书记员

关键原则：IC 和操作的人必须分开。一个人又当指挥又改命令，忙起来就会忘了同步，别人不知道现在进行到哪一步。

四、事故响应流程 ​

第一原则：先止血，后查因。 用户正在受损时，不要钻进去深挖根因——先回滚、先切流、先降级把影响止住，根因留到恢复后慢慢查。

五、对内对外沟通与时间线 ​

  • 对内：在战情群固定频率（如每 30 分钟）发一条进展：现在现象、已尝试的动作、下一步、预计时间。别让大家追着问。
  • 对外：面向用户/客户的公告要谨慎——说事实、说影响范围、说正在处理，不要甩锅、不要猜根因。
  • 时间线：记录员按「时间戳 + 事件」记录，例如 14:02 告警触发 / 14:08 IC 张三拉起会议 / 14:20 回滚 v1.4.2 / 14:35 流量恢复。这份时间线是复盘的原料。

5.1 沟通话术模板（直接套用） ​

拉起事故时的对内通知（发到战情群）：

text
【SEV-2 事故通报】
现象：下单接口 P99 飙升，错误率约 30%，影响华东区用户。
IC：张三（电话 xxx）
OLP：李四
Comms：王五
Scribe：赵六
下一步：正在回滚 v1.4.2，预计 15 分钟内反馈。

进展同步（每 30 分钟一条，别让人追着问）：

text
【14:30 进展】
已回滚 v1.4.2 → v1.4.1，错误率从 30% 降到 2%，正在观察。
下一步：继续观察 30 分钟，若稳定则宣布解除。

对外公告（只说事实，不猜根因）：

text
尊敬的用户：我们监测到部分用户在 14:02~14:35 期间下单遇到超时，
目前服务已恢复正常，正在进一步排查原因，给您带来不便深表歉意。

5.2 值班工具选型 ​

工具用途说明
Alertmanager告警分发按 severity 路由到电话/群/工单，见 SLO 告警
Grafana OnCall值班轮班、升级开源，支持轮班表、自动升级、电话通知
战情语音会议事故时实时沟通拉起后所有人进同一个语音频道
共享文档记录时间线多人同时编辑，Scribe 主笔

六、无指责复盘（Blameless Postmortem） ​

6.1 文化核心 ​

无指责不是「不找人负责」，而是「在当时的信息和条件下，做决策的人是合理的」。

出事故后最忌讳的是骂「谁谁谁怎么会犯这种低级错误」。因为人在高压、信息不全下的判断，事后看是错的，当时往往是合理的。复盘要对着系统找漏洞，而不是对着个人发脾气——否则下次出事没人敢上报，问题被藏起来，更危险。

6.2 可直接复制的复盘模板 ​

markdown
# 事故复盘：<一句话标题，如「9.28 下单接口大面积超时」>

## 摘要
- 等级：SEV-2
- 时间：2026-09-28 14:02 ~ 14:55（约 53 分钟）
- 影响：约 12% 用户下单失败，订单损失估算 X 笔
- 一句话结论：发布 v1.4.2 引入连接池配置错误，导致数据库连接耗尽

## 影响面
- 受影响服务：order-service
- 受影响用户：华东区约 12% 请求
- 数据影响：无数据丢失，无资损

## 时间线（UTC+8）
| 时间 | 事件 | 操作人 |
|---|---|---|
| 14:02 | 告警触发：订单 P99 飙升、错误率 30% | 监控 |
| 14:08 | 主值班李四拉起战情室，指定 IC | 李四 |
| 14:20 | 决定回滚 v1.4.2 → v1.4.1 | IC/OLP |
| 14:35 | 流量恢复正常 | OLP |
| 14:55 | 观察期结束，宣布解除 | IC |

## 根因分析
- 直接原因：v1.4.2 把数据库连接池 maxOpenConns 从 200 改成了 10，高峰连接被打满。
- 促成因素：该配置变更没有走评审；压测没覆盖高峰并发；告警到发现有 6 分钟延迟。

## 做得好的
- 值班 6 分钟内响应，回滚果断。
- 时间线记录完整，沟通及时。

## 做得不好的
- 配置变更未评审就上线。
- 缺少连接池饱和度告警。

## 行动项（必须有 owner + 截止时间）
| 行动项 | Owner | 截止时间 | 状态 |
|---|---|---|---|
| 连接池配置纳入变更评审清单 | 王五 | 2026-10-10 | 待办 |
| 增加 DB 连接池使用率告警 | 赵六 | 2026-10-08 | 待办 |
| 压测补充高峰并发用例 | 孙七 | 2026-10-15 | 待办 |

6.3 行动项闭环 ​

  • 每个行动项必须有 owner 和截止时间，否则等于没写。
  • 行动项要进跟踪系统（Jira/飞书任务），定期 review 完成情况。
  • 复盘结论要分享给全团队，让别人也从你的事故里学到东西。

七、常见反模式 ​

反模式为什么不好正确做法
复盘会变成批斗会下次没人敢报事故无指责，对着系统
没有 IC，一群人同时操作互相覆盖、越改越乱先指定指挥，操作统一由 OLP
只顾深挖根因不先止血用户一直在受损先回滚/降级，根因事后查
行动项没人跟同样事故再犯一次owner+截止时间+闭环跟踪
对外公告瞎猜原因说错了更被动只说事实和进展，根因复盘后再补
事故一解除就散会没观察期，问题反复恢复后至少观察 30 分钟再解除
复盘报告写完就归档行动项没人跟进任务系统定期 review 闭环

经验：SEV-1 事故的复盘要在恢复后 48 小时内开掉，趁大家记忆还新鲜；行动项跟踪到全部关闭才算结束。

复盘会控制在 60~90 分钟，主持要引导大家「对事不对人」，把精力放在「系统怎么改下次不再犯」而不是「谁的锅」。

生产红线

  • SEV-1/2 事故必须先指定 IC 再动手，禁止多人同时改生产配置。
  • 所有生产变更保留一键回滚能力（见 CI/CD 进阶与渐进式交付）。
  • 复盘模板里不许出现「某某某不小心」这类人身归因，只写系统与流程缺陷。
  • 对外公告走 Comms 统一出口，别让工程师在群里随口评论。

相关速查 ​

官方文档 ​

基于 VitePress 构建Copyright © 2026 sresec.com 黑ICP备2026011822号