生产环境一出问题，第一个崩掉的往往是协调。一个工程师默默开始排查，没人定严重程度，支持团队没有可对外同步的状态，三个人各自去呼叫同一个数据库负责人。技术上的修复也许很简单——真正把五分钟的小抖动拖成一小时停机的，是它周围的混乱。事故管理流程图把「响应」本身写明确来解决它，而不只是修复动作。
本文按 ITIL 的思路梳理一个完整的事故管理流程——从检测到复盘——加上那些决定你响应得多快、多大声的判断分支。格式基础参见什么是流程图？。
事故管理流程，一步步来
下面是一个标准的事故流程。每个编号步骤是图里的一个形状，判断处就是分支。这是协调视角——技术排查发生在第 7 步内部，它有自己的故障排查流程图。
1. 检测或上报事故。 入口——告警触发、监控跳闸，或用户报告出了问题。这是开始终止符。
2. 记录事故。 开一条事故记录，写上时间戳、上报人和症状。任何事故都该先记录再处理，否则你会丢掉复盘时需要的时间线。
3. 评估严重程度（判断）。 「这有多严重——P1、P2 还是 P3？」影响范围决定严重程度，而严重程度决定后续一切：谁被呼叫、多快、沟通多广。P1（重大停机）和 P3（轻微、单用户）走的路完全不同。
4. 需要立即响应吗？（判断） 对 P1，答案是「是」——立刻拉起作战室并呼叫值班。对较低级别，事故可以排到下一个工作时段。正是这个分支，让每条告警不至于把整个团队都吵醒。
5. 通知相关方 / 拉起作战室。 指定一名事故指挥官，拉进合适的响应人，开一个专用频道或会议桥。同时更新状态页，别让客户和支持团队干等着猜。
6. 同步状态。 定期发更新——发给作战室、发给管理层、通过状态页发给客户。沟通在这里是一等步骤，不是事后补的；它和下面的技术工作并行进行。
7. 诊断与缓解。 响应人处理技术问题：找出哪里坏了，施加一个缓解措施（回滚、故障转移、功能开关）。故障排查就发生在这里——见专门的流程。
8. 缓解了吗？（判断）
- 是 → 进入恢复。
- 否 → 升级：拉进更多响应人、提高严重程度，或叫上供应商，然后回到诊断。
9. 恢复服务。 确认服务健康、影响已消除。把状态页更新为「监控中」，再到「已解决」。
10. 关闭事故。 记录解决方案、时间线和影响，然后关闭记录。向相关方同步「警报解除」。
11. 复盘（回顾）。 事情平息后，开一次无责复盘：发生了什么、为什么、有哪些行动项能防止再次发生。这些反过来用于改进检测、加快下次响应。
两个判断处——严重程度评估，以及带升级环的「缓解了吗？」——正是把这变成一套事故「流程」而非一厢情愿的关键。打开流程图工具画出它，按你团队的分级改严重程度等级。
常见变体
不是每个团队都用同一套事故流程。几个常加的分支：
- On-call 轮值。 在「通知相关方」之前，很多流程会加一个「谁在值班？」的路由步骤，呼叫当前轮值而非固定某人。
- 按严重程度的 SLA。 每个严重程度有自己的响应和解决时钟。流程可以按严重程度分支到不同的通知和更新节奏。
- 对外状态页。 对面向客户的系统，加一个明确的「发布到状态页」步骤（及后续更新），让对外沟通在压力下不被遗忘。
- 无责复盘。 对 P1/P2，复盘是强制的并指派行动项；对低级别事故，可以跳过或并入每周回顾。
常见错误
没有严重程度分级。 如果每个事故都走同一条路，你要么对小抖动过度响应，要么对真停机响应不足。严重程度判断正是把响应「按需配置」的关键。
没有沟通分支。 只画技术修复的团队，会把客户和管理层晾在黑暗里。沟通和状态页值得有自己的步骤，与诊断并行。
跳过复盘。 关闭事故却不回顾，意味着同样的停机会再次发生。复盘步骤正是把一次事故变成永久改进的关键。
判断分支没标注。 每个菱形（「P1、P2 还是 P3？」「缓解了吗？」）都需要标注出路，否则响应人只能在压力下猜。
常见问题
什么是事故管理流程图？
事故管理流程图描绘一个组织如何协调对一次事故的响应——检测、记录、严重程度分级、通知、诊断与缓解、恢复、关闭和复盘——让整个团队一致地响应。
事故管理和故障排查有什么区别？
故障排查是工程层面找出并修复技术根因的工作。事故管理是围绕它的协调层——严重程度划分、谁被通知、状态如何对外沟通，以及事后的复盘。技术那一面见故障排查流程图。
想梳理自己的事故流程？打开流程图工具，从流程图模板开始——把严重程度等级、升级环和沟通步骤改成你团队的样子，无需注册。
