重大事件是什么
重大事件（Major Incident）是影响面或业务损失达到预设阈值的严重事件，需要跳出常规值班流程，启用独立的指挥与沟通机制。它的核心难点不是技术方案，而是协同：谁来指挥、谁对外沟通、多久更新一次。典型触发条件包括核心业务全量中断、大范围用户无法登录、数据错误或丢失、安全事件等。只有把触发条件写成可判定的规则，值班人员才能在压力下快速决策，而不是先开会讨论这算不算重大事件。
基本信息
| 触发 | 按影响面预定义（核心业务中断、大范围用户受影响等） |
|---|---|
| 角色 | 事件经理、沟通负责人、技术排查组、记录员 |
| 机制 | 指挥室或战情群 + 固定节奏更新 |
| 沟通节奏 | 建议 30 分钟一次，无进展也通报状态 |
| 结束条件 | 服务恢复并维持观察窗口稳定 |
| 收尾 | 无责复盘 + 行动项跟踪 |
典型使用场景
- 核心交易链路中断：支付、下单、登录入口不可用，业务损失按分钟计
- 大范围用户受影响：多地多用户同时报障，服务台来电激增
- 数据错误或丢失：批量写坏数据或口径错误，需要先止损再修数
- 安全事件：入侵、勒索、凭据泄露，技术与决策必须同步推进
- 依赖外部供应商：云厂商或专线故障，要对内解释、对外索赔
- 计划内高风险操作：大版本切换、机房迁移，按重大事件标准值守
重大事件时间线模板
重大事件时间线模板
T0 发现并确认影响范围，判定是否达到重大事件门槛
T0+10m 拉起指挥，指定事件经理与沟通负责人，首次对外通报
T+30m 更新处置进展与临时方案，明确下一个通报时间点
T+… 恢复服务，逐步降级观察，确认业务指标回到基线
事后 无责复盘 + 行动项跟踪，48 小时内出初稿
注意：全程记录时间线，通报模板必须预先准备角色与职责分工
| 角色 | 职责 | 关键动作 |
|---|---|---|
| 事件经理 | 统一指挥与决策 | 安排排查分工、决定临时方案与升级 |
| 沟通负责人 | 对外统一发声 | 按节奏发布通告、收集业务方反馈 |
| 技术排查组 | 定位与处置 | 并行验证假设，只上报结论不猜测 |
| 业务或产品代表 | 判断业务影响 | 反馈损失与优先级、确认恢复判定标准 |
| 记录员 | 维护时间线 | 记录关键动作与时间点，供复盘使用 |
沟通模板要预先准备：现场写通告会延误信息发布，也容易造成前后口径不一致。
通报节奏建议固定，例如每 30 分钟一次，没有进展也要说明当前状态与下一步计划；业务方的焦虑多来自信息空白。
宣布结束前先降级观察：业务指标回到基线并维持一个观察窗口，避免刚宣布恢复就二次中断。
重大事件的判定门槛要量化：例如核心功能不可用超过 10 分钟、受影响用户超过总数三成，写成数字后值班人员才敢直接启用。
平时要做的准备
- 预定义触发条件与第一判定人，避免现场讨论算不算重大事件
- 维护值班与呼叫链，覆盖夜间、周末与节假日
- 准备对外通告模板与口径审批方式，明确谁能对外发声
- 保留战情室入口与记录模板，并每半年做一次模拟演练