上线翻车怎么收：按 Google SRE「事故管理」拆指挥与复盘

生产事故一旦蔓延，常见翻车姿势是：值班的人埋头改配置，老板追 ETA，有人半夜「顺手」推了一版自以为的优化——结果雪上加霜。Google SRE 手册第 14 章 Managing Incidents 把对策写得很具体：先定角色，再抢修；先止血，再根因。下面把可执行部分抽成清单，原文公开可核对。[1]

准备工作

• 团队先书面约定：什么情况要正式宣布 Incident（见下文三条阈值）。

• 准备好「事故状态文档」模板（可多人同时编辑的文档即可）、固定通知频道（邮件列表 / IRC / 等价即时通道）、指挥交接话术。

• 原则性框架，不是你们公司的制度或法律意见；落地时改成自己的 on-call 手册。

操作步骤

1、尽早宣布事故，而不是熬到崩盘

原文建议：宁可早宣布、很快关闭，也不要问题烧了几小时才搭指挥架。可参考阈值（满足任一条就宣布）：

1. 修复需要拉第二个团队进来；

2. 故障已对用户可见；

3. 集中分析一小时仍没有头绪。

为什么： 晚宣布时，技术债和沟通债会叠在一起。
如何确认成功： 邮件/频道里出现明确的「Incident 已开启」记录，并指定临时指挥官。

2、按职责拆角色，禁止「所有人一起改系统」

手册强调 Recursive Separation of Responsibilities，至少分清：

为什么： 技术高手若同时搞定沟通和改配置，很容易「视野变窄」；旁人未经协调的 freelancing 会直接把剩余容量打穿。
如何确认成功： 频道里能指出谁是指挥、谁可以动生产；其他人只做被指派的任务并回传结果。

3、维持「指挥所 + 活文档 + 清楚交接」

• 指挥所： 实体 War Room，或全员在同一 IRC/聊天频道盯更新；Google 提到 IRC 便于留日志、挂 bot 记告警。

• Live incident document： 指挥最重要的活计之一——顶部放影响面、当前假设、已尝试动作、下一步；事故结束后留作复盘材料。

• 交接： 换班时电话/视频同步后，离任者必须明确说「You’re now the incident commander」并得到对方确认，再通知全员指挥已更换。

如何确认成功： 任意中途加入的人只靠文档 + 频道就能接上，而不必私聊五个人。

4、止血优先级写进口头禅

章末 Best Practices 可直接当检查单：

1. Prioritize： 先停血、恢复服务，同时保全根因证据；

2. Prepare： 流程事前写好并和参与者对齐；

3. Trust： 角色内给足自主权；

4. Introspect： 慌了就加人，别硬撑；

5. Consider alternatives： 定期停下来问「还要不要继续当前战术」；

6. Practice： 日常变更、异地协作、灾备演练里就用这套，别等真炸才第一次摸；

7. Change it around： 轮换指挥/沟通/Ops，避免只有一个人会当指挥。

注意事项

• Ops 以外的人即使「有把握」，也不要擅自改生产。

• 事故文档可以乱，但不能缺关键时间线；依赖正在抢救的同一套 SaaS 当唯一文档平台，有风险。

• 复盘（postmortem）是下一章主题，本章要求先把证据和动作留下。

以上为 Google SRE Book 公开章节的实践摘要，用于工程复盘框架；具体升级、处罚与对外口径以所在组织制度为准。

来源

[1] Google SRE Book：Managing Incidents，Andrew Stribblehill / Kavita Guliani。

#SRE #事故响应 #IncidentManagement #上线 #复盘