事件严重性

检测后 5 分钟内声明严重性以定响应紧急度和升级。

为什么

事件前 5 分钟定后 5 小时。若严重性未声明，响应者犹豫是否 page 经理、是否开始客户通讯、是否回滚 — 每犹豫加 10 分钟 MTTR。预定义严重性表（见 severity-mapping）把这变 30 秒查表："结账错误率 >1% = SEV1 = page 经理 + 开始通讯 + 回滚。"事件指挥官声明一次，每下游行动（作战室、通讯、复盘要求）从该声明流。5 分钟内声明严重性的团队 MTTR 比边走边想的团队快 3 倍，因声明立即对齐所有人而非经 20 分钟聊天。

何时使用

检测到任何事件后 5 分钟内。影响变化时重评估。

如何做

1. 5m 内检测并声明
   - 值班见告警 → 按严重性表评估影响 → 声明
   - 若不清，声明更高严重性（可后降；别低反应）

2. 声明定一切下游
   - SEV1 → page IC + 经理 + 通讯负责人；开作战室；开始客户通讯
   - SEV2 → page IC；开事件频道；除非升级否则无作战室
   - SEV3 → 工单；工作时间调查

3. 每影响变化重评估
   - 错误率从 5% 降到 0.1% → SEV1 降 SEV2
   - 扩到第二区域 → SEV2 升 SEV1
   - 在事件频道带理由说明变更

4. 指派事件指挥官（IC）
   - IC 不调试 — 协调：严重性、通讯、升级、时间线
   - 声明者成 IC 直到显式交接

5. 带严重性准确的后续关事件
   - SEV1/SEV2 → 5 工作日内需复盘
   - SEV3 → 复盘可选
   - 严重性驱动审查非反之

示例

# 事件声明（在 #incidents Slack）：
14:07  @oncall：SEV1 声明 — 结账错误率 100%（告警：CheckoutSLOBurnRateFast）
       影响：所有结账尝试失败，约 $500/分钟收入损
       IC：@oncall  |  通讯：@commslead  |  作战室：zoom-link
14:09  @oncall：回滚启动（runbook：rollback-checkout）
14:12  @oncall：回滚完成，错误率 0%
14:15  @oncall：SEV1 降 SEV2 — 监控复发 30m
14:45  @oncall：SEV2 解决 — 无复发。复盘排 2026-03-16。

# 严重性表（预定义，30s 查表）：
#   结账错误 >1% 持续 5m → SEV1（收入降）
#   结账错误 0.1-1%      → SEV2（退化）
#   搜索挂               → SEV2（浏览工作）
#   邮件延迟 >30m        → SEV3（无收入影响）

常见问题

⚠严重性 20+ 分钟未声明 — 响应者聊天辩论而宕机涨；声明更高严重性后降。
⚠IC 也在调试 — 无人协调通讯、升级或时间线，响应混乱且客户通讯被忘。
⚠严重性从不重评估 — 降到 0.1% 错误率的事件仍开作战室 2 小时浪费大家时间。
⚠无严重性表，声明成凌晨 3 点判断 — 不同工程师对同事件声明不同严重性。

最佳实践

✓5 分钟内用预定义表声明严重性；不清时声明高后降 — 低反应是贵错误。
✓指派专职 IC 协调（严重性、通讯、升级）但不调试 — 协调和调试争同一脑。
✓每影响变化重评估严重性并在事件频道说明 — 已解决事件开作战室浪费响应者时间。
✓严重性绑后续：SEV1/SEV2 需复盘，SEV3 不需 — 审查匹配影响非响应者愧疚。