事故指挥与应急响应体系全景图
回答“重大故障发生时，谁判断、谁指挥、谁沟通、谁止血，怎样让应急从混乱变成协同系统”
阅读边界: 事故指挥不是值班群里谁声音大谁指挥，也不是事故后写复盘。它要定义分级、拉群、角色、指挥权、时间线、外部沟通、止血优先级、升级路径和复盘闭环。
一句话判断: 如果事故中大家同时排查、同时决策、同时对外解释，却没人维护全局时间线和优先级，应急体系就还没有成形。
识别事故
分级升级
建立指挥
止血恢复
同步沟通
复盘闭环
| 事故混乱 | 根因 | 治理判断 |
|---|
| 没人知道是不是事故 | 缺少事故分级和触发标准 | 定义影响范围、用户影响、收入风险和数据风险的分级规则 |
| 群里多人同时拍板 | 没有 incident commander 角色 | 事故中必须有一个人维护优先级、决策和时间线 |
| 排查很多，止血很慢 | 团队把找根因放在恢复用户前面 | 应急优先级通常是止血、恢复、保全证据，再深入根因 |
| 对外口径反复变化 | 技术处置和业务沟通没有分工 | 设沟通角色，固定同步节奏和事实口径 |
事故分级
按用户影响、业务损失、数据风险、合规风险和持续时间定义 P0/P1/P2 等级。
指挥角色
Incident commander 负责节奏、决策、任务分配和升级，不必亲自排查细节。
应急角色
区分技术排查、操作执行、业务沟通、客户支持、记录员和安全合规接口人。
时间线
记录发现、升级、假设、动作、指标变化、决策理由和恢复时间，支撑复盘。
Runbook
常见故障要有可执行手册、权限入口、回滚步骤、验证方式和联系人。
复盘闭环
复盘项要进入工程 backlog，并追踪到自动化、护栏、演练或组织机制改进。
| 手册机制 | 最低要求 | 为什么属于事故响应 |
|---|
| 告警到手册映射 | P0 / P1 告警能直接指向影响范围、判断步骤、止血动作和升级联系人 | 事故现场最需要的是可执行路径，而不是临时问人 |
| 操作分级 | 区分只读排查、低风险操作、高危变更和不可逆动作，并绑定权限与审批 | 事故中错误操作会放大损失，手册要明确边界 |
| 回滚与验证 | 每个动作写清可撤销性、回滚条件、数据副作用和验证指标 | 止血动作必须能证明有效，也要知道什么时候撤销 |
| 演练更新 | 发布、架构变化、事故复盘和演练失败都要触发手册更新 | 过期 runbook 会在关键时刻制造二次事故 |
| 角色 | 主要责任 | 不应该做什么 |
|---|
| Incident Commander | 维护优先级、分派任务、确认止血动作、决定升级和恢复标准。 | 不要陷入具体排查细节，导致全局节奏无人维护。 |
| 技术排查负责人 | 组织假设、证据、指标和修复方案，向指挥角色汇报可选动作。 | 不要在未说明风险和可逆性的情况下直接操作生产。 |
| 操作执行人 | 执行回滚、开关、扩容、降级、修复脚本等动作，并反馈结果。 | 不要口头执行高危动作，必须保留命令、参数和结果。 |
| 记录员 | 记录时间线、决策、指标变化、操作结果和未验证假设。 | 不要等事故后凭记忆补时间线。 |
| 业务 / 客户沟通人 | 维护对业务、客服、管理层或客户的同步口径和节奏。 | 不要让排查群里的不确定猜测直接变成对外口径。 |
| 等级 | 触发信号 | 响应要求 |
|---|
| P0 | 核心交易、资金、登录、数据正确性、合规或大面积用户路径受损。 | 立即指定指挥角色，拉齐技术、业务、客服和管理层同步；优先止血恢复，固定 15-30 分钟同步节奏。 |
| P1 | 重要业务受影响但有绕行或影响范围可控。 | 指定 owner 和记录员，明确升级条件、恢复标准和业务同步频率。 |
| P2 | 局部功能、内部系统或低影响链路异常。 | 由服务 owner 处理，保留时间线和修复记录；若扩大影响则升级。 |
| Near Miss | 已触发高风险信号但未造成明显用户影响。 | 纳入轻量复盘，修 runbook、告警、权限或降级预案，避免下次变成事故。 |
| 误区 | 为什么危险 | 修正方式 |
|---|
| 最懂技术的人应该指挥 | 他会被细节吸走，没人维护全局节奏 | 技术专家排查，指挥角色管理决策和协同 |
| 先找到根因再行动 | 用户影响会持续扩大 | 先评估可逆止血动作，再保留证据做根因分析 |
| 复盘就是写事故报告 | 报告如果不进入改进闭环，同类事故还会发生 | 复盘必须有 owner、截止时间、验证方式和复查 |
| 检查项 | 最低要求 |
|---|
| 分级标准 | P0/P1/P2 触发条件、升级路径和通知范围明确 |
| 角色分工 | 指挥、排查、执行、沟通、记录、业务接口角色可快速指定 |
| 应急入口 | 告警、Dashboard、日志、Runbook、回滚、开关和权限入口集中可达 |
| 沟通节奏 | 内部同步、业务同步、客户同步和管理层同步频率明确 |
| 复盘闭环 | 复盘项有 owner、期限、优先级、验收方式和二次复查 |
| 战情板字段 | 事故中要持续更新什么 | 为什么重要 |
|---|
| 当前等级与影响 | P0/P1/P2、受影响用户、核心路径、收入或数据风险、已知绕行方案 | 让所有人先对“严重到什么程度”形成同一张图 |
| 指挥与角色 | Incident commander、技术排查、操作执行、记录员、业务沟通、升级联系人 | 避免多人同时拍板，或关键任务没人真正负责 |
| 时间线 | 发现、升级、假设、操作、指标变化、决策、对外同步和恢复确认时间 | 支撑现场决策，也让复盘不靠事故后回忆 |
| 当前假设与证据 | 最可能原因、支持证据、反证、下一步验证动作和负责人 | 让排查从聊天流变成可收敛的假设列表 |
| 止血动作 | 已执行和待执行的回滚、降级、限流、开关、扩容、隔离、数据保护动作 | 把注意力从“谁猜得对”拉回“如何先恢复用户” |
| 交接项 | 交接时必须说清楚 | 失败信号 |
|---|
| 当前状态 | 事故等级、用户影响、恢复程度、剩余风险、是否仍需业务或客户同步 | 接手人只知道“还在查”，不知道是否已经止血 |
| 已做动作 | 执行过的命令、开关、回滚、扩容、降级、配置变更和验证结果 | 重复执行或撤销了前一班次的关键操作 |
| 未验证假设 | 还没排除的原因、下一步验证计划、需要等待的指标或日志 | 新班次从头猜，排查上下文断裂 |
| 外部沟通 | 已同步对象、承诺时间、下一次同步点、对外口径和不确定信息边界 | 客户、客服、业务方收到互相矛盾的信息 |
| 后续复盘素材 | 关键截图、日志链接、变更单、告警链接、相关 PR、操作审计和时间线链接 | 事故恢复后找不到证据，复盘只能靠印象 |