事故响应流程图：从第一次告警到事后复盘

凌晨三点，没有人会去读一份十页的事故处理制度。值班工程师需要尽快弄清四件事：这是真的吗？这是事故吗？还有谁需要知道？首先该做什么？一页纸的流程图会按问题出现的顺序回答它们，而这也是整套制度中人们真正会遵循的部分。

本文为一个运行生产服务的工程团队绘制一张事故响应流程图：分诊、宣布事故的标准、严重级别与角色、缓解，以及闭合整个闭环的事后复盘。最后还会给出一些绘图建议，让流程图在压力之下依然好用。

流程图需要做出哪些判断

事故处理流程是一连串判断，中间穿插着几项耗时较长的工作。判断应该画在图上，写成带有标注答案的问题：

• 告警是真实且可处理的吗？ 如果不是，问题出在告警本身。
• 这是事故吗？ 如果不是，就作为普通工作，开一个工单处理。
• 有多严重？ 严重级别决定呼叫谁、通知谁。
• 服务恢复了吗？ 如果没有，尝试下一个缓解措施或升级。

其他所有内容，例如如何回滚部署、如何对数据库进行故障切换，都应放在流程图所链接的运行手册中。

何时宣布事故

宣布事故是团队最容易犹豫的一步，而这种犹豫代价高昂。Google SRE 一书中事故管理一章主张尽早宣布：与其在问题不断扩大数小时后才启动流程，不如先宣布，找到简单的修复办法，然后关闭事故。该章中的团队在满足以下任一条件时宣布事故：

1. 需要第二个团队参与才能解决问题。
2. 故障对客户可见。
3. 经过一小时的集中分析，问题仍未解决。

把你们自己的标准写在图上，放在对应判断的旁边。明确的标准能消除宣布事故的社交成本。

角色

同一章描述了一种基于 Incident Command System（事故指挥系统）的组织方式。即使是小团队，给角色命名也有好处，因为最常见的失败就是一个人包揽所有角色：

事故指挥官还要维护一份实时更新的事故文档，并在班次结束时明确交接：交班的指挥官宣布交接，并等待对方确认。

事故管理技能不用就会生疏。同一章建议把这套框架也用于跨团队或跨时区的运维变更，并对过去的事故进行角色扮演演练，这样在下一次真实事故到来之前，大家已经熟悉流程。带着新加入值班的工程师，用一次旧事故把流程图走一遍，是一种低成本的起步方式。

严重级别

各公司对严重级别的定义各不相同，所以请把下面的内容当作示例，并把你们自己的定义写在图上：

逐步解读流程图

1. 确认并分诊。 告警触发后先确认它，让呼叫停止升级，然后查看影响范围和影响程度。
2. 真实且可处理吗？ 误报或无法处理的告警要调整或删除，然后关闭。
3. 这是事故吗？ 对照标准判断。如果不是，就作为普通工作开工单处理。
4. 宣布。 指定事故指挥官，开设沟通频道并创建事故文档。
5. 严重级别。 对于 SEV-1 和 SEV-2，由沟通负责人在状态页发布信息并定期发送更新。
6. 先缓解。 回滚、故障切换、关闭功能开关或削减负载。SRE 一书把止血、恢复服务和保全证据列为第一优先级；根因分析可以稍后再做。
7. 恢复了吗？ 如果没有，尝试下一个缓解措施或升级，并继续循环。
8. 解决。 用指标确认恢复，继续观察，并把系统交还给正常运维。
9. 事后复盘和行动项。 撰写不追责的事后复盘并进行评审，待行动项都被跟踪后再关闭事故。

这张图的读法如下：

• Yes 向右，No 向下。 每个判断都遵循同一约定，因此主路径一路向右推进，提前退出的分支向下落。
• 左侧，初步响应。 告警被确认并分诊。不真实或无法处理的告警，以及不属于事故的事件，都在 Done 处结束。
• 第三列，事故本身。 宣布事故，判断严重级别，然后缓解。SEV-1 和 SEV-2 会在右侧增加一名沟通负责人。
• 循环。 “Service restored?”会把你送回缓解步骤，直到答案为 Yes。
• 右列，收尾。 解决问题，撰写不追责的事后复盘，在行动项被跟踪后关闭。
• 便签写有宣布事故的标准和严重级别，这样谁都不必再打开另一份文档。

事后复盘闭合闭环

SRE 一书中事后复盘文化一章列出了常见的触发条件，例如超过阈值的用户可见停机或性能下降，以及任何形式的数据丢失。不追责的事后复盘在系统和流程中寻找促成因素，而不归咎于个人；否则，人们就不再愿意报告问题。在图上把事后复盘画成一份有负责人和截止日期的文档，并且在其行动项被跟踪之前，不要把事故标记为已关闭。

安全事件需要的不止这张图：证据保全、法律和监管步骤，往往还需要一个独立的团队。2025 年 4 月发布的 NIST SP 800-61 Rev. 3 是常用的参考标准。请把安全分支连接到那套流程，而不是临时拼凑一个。

压力下使用的流程图绘制建议

• 一个起点，明确的终点。 每条路径都应该在某处结束，哪怕终点只是“Done”。
• 把判断写成是非题， 两个出口都要标注，并且 Yes 和 No 每次都从相同的边引出。
• 把循环画明确。 “尝试下一个缓解措施”是一个循环，而不是脚注。
• 图形不超过十五个。 细节放进各步骤所链接的运行手册。
• 标出职责转移的位置。 如果需要按角色分泳道的版本，可以从跨职能流程图模板开始。
• 放在值班人员会看的地方。 在运行手册里放链接或嵌入实时图表，而不是粘贴截图。

如果你的流程涉及多个团队和正式交接，BPMN 图可以更精确地建模；但对值班场景来说，流程图更容易跟着走。

在 Archboard 中构建

1. 使用 Google 或 GitHub 登录，并新建一张图。
2. 添加流程图节点包中的 开始 / 结束 表示起点和每个终点，用 处理 表示每个步骤，用 判断 表示每个问题。
3. 添加一个 文档 表示事后复盘。
4. 连接各个图形。判断图形在右侧角上标有 Y，在底部角上标有 N，因此把 Yes 画向右侧、No 画向下方，两者都加上标注，并把“未恢复”的出口连回缓解步骤。
5. 添加基础节点包中的 便签 节点，写上你们宣布事故的标准和严重级别。

这个示例共用 15 个图表节点，在 Free 套餐的限制之内。流程图制作页面介绍了其他图形和泳道布局。

常见问题

事故响应流程图应该由谁负责？ 由负责值班轮换的团队负责。每当有人在事故中不知道下一步该做什么，都要在事后重新审视这张图。

每条告警都应该算作事故吗？ 不应该。大多数告警都应作为普通工作处理。满足标准时宣布事故，拿不准时尽早宣布。

小事故也需要事故指挥官吗？ 总得有人掌握全局。在小事故中，值班工程师就是指挥官；把这一点明确说出来，可以避免两个人用不同的方式修同一个问题。

事后复盘应该什么时候写？ 尽快，趁细节还清晰的时候。设定一个团队能遵守的截止日期，写在图上，并跟踪行动项。

流程图应该包含安全事件吗？ 添加一个把安全事件转交给安全事件处理流程的分支。那套流程有不同的步骤，例如证据保全和法律审查。

免费开始 — 1 个席位，无需信用卡。