incident-command

事故指挥角色分工与响应流程

补充说明

事故指挥（Incident Commander，IC）不是“最会排障的人”，而是负责定级、分工、决策和升级的人。IC 不亲自查日志，否则没人统筹全局。事故一开始就应指定 IC、建立单一频道，并冻结相关变更。

响应顺序是：确认影响 → 定级 → 指定角色 → 止血 → 恢复 → 沟通 → 复盘。止血优先于根因。

常用示例

事故分级与响应时限：

级别	判据	首次响应	对外更新	升级对象
P0	核心链路全挂、资金损失、数据泄露	5 分钟	每 15 分钟	CTO / 安全负责人
P1	核心功能部分不可用、SLO 快速燃烧	10 分钟	每 30 分钟	部门负责人
P2	非核心功能降级、有绕过方案	30 分钟	每 2 小时	团队负责人
P3	无用户影响、容量或单点预警	下一工作日	日报	无需升级

角色分工：

角色	负责	不负责
IC	定级、分工、决策、升级	不直接排障
Ops Lead	回滚、切流、扩容、降级	不对外承诺
Comms Lead	状态页、客户、管理层同步	不猜根因
Scribe	时间线、决策、行动项	不参与操作

第一条事故消息模板：

[P1] 支付回调失败率升高
影响：约 12% 支付订单状态未更新
开始时间：2026-10-18 14:02 UTC
IC：@alice
频道：#inc-20261018-payment
当前动作：回滚 payment v2.3.1
下次更新：14:17 UTC

时间线记录（每条都带 UTC 时间）：

incident_log=/tmp/INC-20261018-payment.log
printf '%s | IC | 宣布 P1，建立频道\n' "$(date -u +%FT%TZ)" >> "$incident_log"
printf '%s | Ops | 开始回滚 v2.3.1\n' "$(date -u +%FT%TZ)" >> "$incident_log"
printf '%s | Ops | 错误率从 12%% 降到 0.3%%\n' "$(date -u +%FT%TZ)" >> "$incident_log"

交接模板：

IC 交接（14:40 UTC）
当前级别：P1
影响：支付回调失败率 0.3%，积压 240 条
已做：回滚 v2.3.1，扩容消费者到 6 副本
待验证：积压是否在 15 分钟内清空
风险：数据库连接池仍接近 80%
下次更新：15:00 UTC

决策规则：

影响面超过 5% 用户或涉及资金/数据安全，直接按 P1 起步，宁可升级后再降级。
15 分钟内没有止血，IC 必须升级并引入二线，不得继续单打独斗。
任何不可逆操作（删数据、改 schema、强制切主）需要第二人确认。
恢复后观察至少 30 分钟，确认指标回到基线再关闭事故。

易错点与排错

IC 自己钻进日志，没人分配任务和对外沟通，事故现场失序。
定级拖延：先查 20 分钟再宣布，错过沟通和升级窗口。
多个频道并行，信息不一致；必须只有一个事故频道。
先找根因再止血，用户影响持续扩大；回滚和切流应优先。
对外承诺“很快恢复”却不给下一次更新时间，客户反复追问。
变更未冻结，止血过程中又有新版本上线，造成二次故障。
没有 Scribe，复盘时间线靠回忆，关键决策无法还原。
交接只说“还在查”，没有级别、影响、已做动作和下一步。

读完自测

合上页面，先回答，再展开对照。

IC 的主要职责是什么？为什么 IC 不应亲自排障？
P0 和 P1 的首次响应时间与对外更新频率分别是多少？
事故止血和根因分析哪个优先？为什么？

答案

定级、分工、决策、升级和对外统筹。IC 一旦陷入具体排障，就没人协调角色、控制变更和同步信息。
P0 首次响应 5 分钟、每 15 分钟更新；P1 首次响应 10 分钟、每 30 分钟更新。
止血优先。先回滚、切流、扩容或降级，缩短用户受影响时间；根因可以在恢复后系统分析。

incident-command

补充说明

常用示例

易错点与排错

读完自测

相关条目