事故处理流程泳道图：发现-止血-恢复-复盘-改进的责任边界
线上出事故时，你需要的不是一张“描述发生了什么”的图，而是一张把人从混乱里拉回秩序的图：谁来指挥、先做哪一步、每一次交接要交什么、什么条件算“止血”、什么条件才能“恢复”、什么时候必须回滚、怎么对内对外同步。
一张能在事故现场用起来的事故处理流程泳道图，通常要解决四个问题：
- 责任边界：谁是指挥（Incident Commander），谁在执行（SRE/开发），谁在验证（QA/业务），谁在沟通（产品/客服）。
- 交接物：告警截图不算交接物；交接物应该是“可落地的记录”，例如事故工单、影响评估、缓解方案、变更记录、验证结果、对外通告文本。
- 升级条件：什么时候从 S3 升到 S2？什么时候必须拉更多人进来？什么时候需要停止所有发布？
- 退出条件：什么时候算止血？什么时候算恢复？什么时候才能结束事故并进入复盘？
如果你想把这些节点快速排成一张清晰的泳道图，并能导出高清图片给群里、文档里、复盘报告里直接用，可以用：泳道流程图在线制作。
一、先把“事故处理”定义清楚：不是修 bug，而是把服务拉回可用
很多团队把事故处理等同于“把问题找出来并修掉”。但事故现场的优先级顺序更像这样：
- 确认影响：到底影响了谁、影响多大、什么时候开始。
- 控制扩散：先止血，把系统从失控状态拉回可控。
- 恢复服务：恢复到可接受的可用性与数据一致性。
- 追根因与改进：在稳定后做复盘，把同类事故变成更难发生。
这也决定了泳道图上“主干节点”的顺序：发现 → 分级/升级 → 指挥建立 → 止血 → 恢复 → 结束 → 复盘 → 改进落地。
1.1 事故处理节点要写“可执行动作”，不要写抽象状态
更好用的节点命名方式：
- “确认告警是否为真实故障（排除误报）”
- “建立事故工单并指定指挥/记录员/沟通负责人”
- “发布冻结：暂停所有非紧急变更”
- “执行缓解措施：限流/降级/切换/回滚（选其一）”
- “验证恢复：关键指标回到阈值内并持续观察 30 分钟”
容易让人吵起来的节点命名：
- “处理中”“排查中”“修复中”（谁在做？做到哪一步？输出是什么？）
状态可以作为节点旁注，但节点本身要能被执行、能被验收。
二、泳道怎么分：建议 6 条泳道，别把“沟通”塞到备注里
事故处理时，技术动作和沟通动作是并行发生的。把沟通写在备注里，实际效果往往是：
- 群里有人一直问“影响范围？”“预计多久？”
- 工程师一边排查一边回消息，注意力被切碎
- 对外口径反复修改，错漏增多
更稳妥的做法是：把沟通放进泳道图里，明确负责人、频率、口径版本。
2.1 推荐泳道（通用可套用）
- 监控/平台（告警、日志、发布系统、工单）：告警触发、自动化隔离、变更记录、工单归档。
- 值班/一线响应（On-call）：首响、初步判断、拉群、初步缓解。
- 指挥/记录（IC + Scribe）：分级、角色分配、节奏控制、时间线记录、决策确认。
- 技术处置（SRE/运维 + 开发）：止血方案选择与执行、回滚/切换/降级、根因定位。
- 验证（QA/业务）：功能与数据验证、回归范围确认、恢复判定。
- 沟通（产品/客服/运营/PR）：对内播报、对外公告、客户解释、工单回复模板。
如果你们公司有安全合规要求，可以把“安全/风控”作为第 7 条泳道加入；否则建议先用“参与方旁注”表达，避免图变成一张巨大的地图。
2.2 每条泳道最少要有的“交接物”
- 值班/一线：事故群链接、初步影响评估（影响面 + 现象 + 时间范围）、下一次同步时间点。
- 指挥/记录：事故编号、严重级别、角色列表、决策记录、时间线。
- 技术处置：缓解方案与执行记录（变更单/回滚单/操作记录）、风险说明。
- 验证：验证项清单 + 结果（截图/指标/抽样数据），恢复结论。
- 沟通：对内播报模板、对外通告文本版本（V1/V2）、客户问答口径。
没有交接物，流程就会退化成“口头说了算”。
三、严重级别与升级条件：把“什么时候拉人、什么时候停发布”写进图里
事故处理最常见的拖延不是技术问题，而是决策迟疑：
- “要不要升级？”
- “要不要回滚？”
- “要不要暂停发布？”
建议在泳道图里专门画一个“分级/升级判断节点”，并把触发条件写得能落地。下面给一个可直接套用的例子（你可以按业务调整阈值）：
3.1 一个可执行的分级示例
- S1（严重）：核心交易不可用/大面积登录失败/数据错误扩散；需要管理层知会与对外公告。
- S2（高）：核心功能明显受损、影响范围可观；需要跨团队协同，可能需要回滚/切换。
- S3（中）：局部功能异常或性能退化；可由值班与相关开发处理，通常不对外公告。
- S4（低）：小范围问题或短暂抖动；记录并跟进即可。
3.2 升级条件写法（直接放到判断节点旁）
- 影响用户数/请求失败率持续超过阈值（例如 10 分钟）
- 影响核心链路（支付/下单/登录）
- 数据一致性风险（重复扣费、漏单、错账）
- 故障处置需要跨团队权限（数据库/网络/发布系统）
升级不是“更紧张”，升级意味着：更清晰的指挥链路、更快的决策、更完整的记录。
四、事故处理流程泳道图模板（主干 16 步）：照着画就能跑
下面这套流程适合大多数互联网/企业系统：既包含技术处置，也包含沟通与复盘入口。你可以在图上用“主干 + 分支”的方式呈现。
Step 1：告警触发与首响确认（判断误报）
- 平台泳道：告警触发（阈值/异常检测）
- 值班泳道：确认现象（可复现/监控验证/用户反馈）
- 输出（交接物）：事故工单草稿（现象、开始时间、初步范围）
- 判断分支：
- 误报/短暂抖动 → 记录原因与修正阈值，结束
- 真实故障 → 进入 Step 2
把“排除误报”画成显式分支，能减少很多“大家跑起来又发现没事”的成本。
Step 2：建立事故工单与事故群（把沟通与记录拉到台面）
- 值班/指挥泳道：创建事故编号（INC-xxxx）并拉群
- 指挥泳道：指定角色：IC（指挥）、Scribe（记录）、Comms（沟通）
- 输出：事故群、事故工单、第一次对内播报
对内播报不需要很长，建议包含四项：现象、影响、当前措施、下次更新时间。
Step 3：分级与升级（决定节奏）
- 指挥泳道：根据影响与风险定级 S1/S2/S3
- 判断分支：
- S1/S2：通知相关负责人；必要时“发布冻结”
- S3/S4：按值班节奏处置即可
- 输出：严重级别、升级名单、发布冻结决策（如有）
Step 4：收集关键信息（最少三类：时间、版本、变更）
- 平台泳道：拉取发布记录、变更单、配置变更审计
- 记录泳道：补全时间线（首次告警、首次响应、升级、采取措施）
- 输出：时间线初稿 + 最近变更清单
很多事故的突破口就是“最近改了什么”。把“变更清单”作为交接物，后面每一步都会用到。
Step 5：快速影响评估（别靠感觉）
- 技术处置泳道：从指标判断影响面（错误率、延迟、队列堆积、资源耗尽）
- 验证泳道：从业务侧确认影响（下单失败、回调异常、对账差异）
- 输出：影响评估（哪些功能、哪些地区/租户、影响规模、是否涉及数据风险）
Step 6：选择止血策略（四选一为主）
止血策略建议在泳道图上画成“决策节点”，并写出选择依据：
- 限流/熔断：流量暴涨或下游不可用，优先保护核心路径
- 降级：非核心功能拖垮整体时，先砍非核心
- 切换：主备/多活场景，切到健康单元
- 回滚：疑似由最近变更引起且回滚路径清晰
事故现场常见误区：一上来就“彻底修好”。更可取的是先止血，再修。
Step 7：执行止血（务必留下可追溯的操作记录）
- 技术处置泳道：执行限流/降级/切换/回滚
- 平台泳道：记录变更（变更单号、操作人、开始/结束时间）
- 输出：止血动作记录 + 风险说明
如果你们需要把止血动作快速画成“节点—连线—责任”并导出给复盘文档，直接用：泳道流程图在线制作。
Step 8：止血有效性验证（指标 + 业务双验证）
- 验证泳道：关键功能验证（下单/支付/登录/回调）
- 技术处置泳道：关键指标回落（错误率/延迟/资源/队列）
- 判断分支：
- 有效 → 进入 Step 9（恢复）
- 无效/反弹 → 回到 Step 6（重新选策略）并升级（如必要）
止血不是“感觉好了”，而是“指标与业务都回到阈值内，并持续一段观察期”。
Step 9：恢复策略（从“可用”走向“稳定”）
- 技术处置泳道：补齐临时修复（配置回调、重启、扩容、补偿任务）
- 验证泳道：抽样检查数据一致性（订单、库存、账务等）
- 输出：恢复动作清单 + 验证结果
这里特别建议在泳道图里增加一个“数据风险判断节点”：
- 若存在错账/重复扣费/漏单风险 → 进入“数据修复/补偿”分支
- 若不存在数据风险 → 进入 Step 10
Step 10：对内对外同步（固定频率，降低噪音）
- 沟通泳道：按节奏发布更新（例如每 15/30 分钟一次）
- 指挥泳道：确认口径版本与下一次更新时间
- 输出：对内播报记录 + 对外通告（如需）
对外通告写法建议只包含：现象、影响、当前状态、预计下一次更新时间、补偿方式（如有）。避免在未确认前把根因写死。
Step 11：恢复判定（明确“退出事故”的门槛）
- 指挥泳道：提出恢复判定
- 验证泳道：给出“通过/不通过”结论与证据
- 建议的恢复门槛：
- 关键指标连续稳定（例如 30–60 分钟）
- 客诉/工单新增量回落
- 关键业务链路验证通过
- 输出：恢复结论 + 观察期开始/结束时间
Step 12：解除发布冻结（或继续冻结并说明原因）
- 指挥泳道：决定解除/继续冻结
- 平台泳道：恢复发布流水线权限（如有）
- 输出：冻结解除记录 + 后续发布策略（如“当天只允许紧急变更”）
Step 13：结束事故（宣布进入复盘）
- 指挥/记录泳道：宣布事故结束，进入复盘窗口
- 输出：事故总结（1 页纸）：影响、止血措施、恢复时间点、待办列表
Step 14：复盘准备（时间线、证据、决策点）
- 记录泳道：整理时间线、关键截图、变更记录、决策点
- 沟通泳道：整理客户反馈与对外口径的演变
- 输出：复盘材料包
Step 15：复盘会议（把“怎么避免再发生”落到具体行动）
- 全体相关泳道：复盘会议
- 输出：根因链路（技术/流程/组织）、改进项列表（含负责人、截止时间、验收标准）
Step 16：改进落地与回收（没有回收就等于没做）
- 平台/技术处置泳道：落地改进（监控、演练、限流策略、发布门禁、自动化回滚、Runbook）
- 指挥泳道：回收改进项（到期验收/关闭）
- 输出：改进项关闭记录 + 防复发证据
事故处理真正的终点不是“恢复”，而是“下次同类问题更难再把你打趴”。
五、三个常见反例（以及怎么改成可执行的泳道图）
反例 1：图上只有技术节点，没有指挥与沟通
症状：流程图看起来很“工程化”，但事故现场还是一团乱：谁来拍板回滚？谁对外发公告？谁在记录时间线？
修正：增加两条泳道：
- 指挥/记录：分级、角色分配、决策确认、时间线
- 沟通：对内播报节奏、对外通告版本
并在关键决策点（升级、回滚、恢复判定）画出“谁确认、输出是什么”。
反例 2：回滚节点写成一句“必要时回滚”
症状：看上去留了后手，但真正需要回滚时发现：
- 回滚包不存在/不可用
- 数据迁移不可逆
- 回滚要停机，但没人提前知会
修正：把回滚拆成 4 个节点，并写出交接物：
- 回滚条件确认（触发阈值、时间窗口）
- 回滚方案与风险说明（含影响范围）
- 回滚执行（变更单/操作记录）
- 回滚验证（指标 + 业务）
反例 3：止血与恢复混成一段，节奏失控
症状：团队一边找根因一边改代码一边扩容，一小时后发现指标反弹，大家还在同一堆动作里打转。
修正：在图上明确两个阶段边界：
- 止血：目标是把系统拉回可控（先稳定）
- 恢复：目标是把服务拉回正常（再优化）
并要求止血完成必须经过“止血有效性验证”节点，验证不过就回到策略选择。
六、事故处理泳道图验收清单（发到群里就能对齐）
你画完图后，可以用下面这份清单做一次“能不能在事故现场用”的自检：
- 是否有明确的事故编号/工单入口？
- 是否有分级与升级判断节点？升级条件写清楚了吗？
- 是否指定了指挥（IC）、记录（Scribe）、沟通（Comms）？
- 是否明确了发布冻结/解除冻结的决策节点？
- 是否把止血策略画成决策节点（限流/降级/切换/回滚）？
- 是否要求止血动作有可追溯记录（变更单/操作记录）？
- 是否有“止血有效性验证”的门槛（指标 + 业务）？
- 是否有数据风险判断分支（是否需要补偿/修复）？
- 是否把对内/对外同步的节奏写进流程（频率、负责人、口径版本）？
- 是否定义了恢复判定门槛与观察期？
- 是否有复盘入口（材料包、会议、改进项回收）？
七、FAQ：事故处理流程里最容易问的 7 个问题
1）什么时候必须“发布冻结”？
当你满足下面任一条时，发布冻结通常是合理的：
- 故障影响核心链路，且根因未明
- 指标持续恶化或频繁反弹
- 处置需要频繁变更（每一次变更都可能扩大影响）
冻结不是“躺平”，冻结是为了把变量减少，让止血更快发生。
2）指挥一定要是技术负责人吗？
不一定。指挥的核心能力是：控制节奏、做决策、协调资源、把信息说清楚。
在一些团队里，SRE 做指挥更合适；在另一些团队里，值班负责人或某位资深工程师更合适。关键是：指挥只能有一个，而且角色要在流程图里明确。
3）止血策略选哪个最稳？
没有“最稳”，只有“最匹配当前风险”。
- 怀疑由最近变更引起、回滚路径清晰 → 回滚通常更快
- 下游不可用或流量异常 → 限流/熔断更合适
- 非核心功能拖垮整体 → 降级往往立竿见影
- 多活/主备条件成熟 → 切换可能最快
把选择依据写在决策节点旁，能显著减少争论时间。
4）为什么要同时做“指标验证”和“业务验证”？
指标好看不代表业务真的恢复；业务能下单也不代表系统指标健康。
事故里常见的“假恢复”包括：
- 指标回落，但队列堆积还在增长
- 下单成功，但支付回调延迟导致对账异常
- 主页打开了，但关键按钮点击失败
双验证能把这种坑提前踩掉。
5）对外通告什么时候发、发什么？
当影响明确、用户感知明显，且短时间无法恢复时，对外通告通常比沉默更好。
通告建议只写可确认的信息：现象、影响范围、当前状态、下一次更新时间。根因未确认前，不要把“猜测”写成结论。
6）事故结束后，复盘最重要的产出是什么？
最重要的不是“写得漂亮的复盘文档”，而是三件可验收的东西：
- 监控改进：同类问题更早被发现、更少误报
- 防扩散机制：限流/降级/隔离更可靠
- 发布与运行手册：关键操作路径更清晰、演练更频繁
7）流程图画好了，怎么保证真的会用？
把流程图和两件事绑定：
- 值班交接：每次交接必须过一遍“分级/升级/沟通节奏/回滚路径”
- 演练：每季度做一次桌面演练或故障演练，用流程图跑一遍
图只是一张纸；让它在真实场景里跑起来，才算真正完成。