严重性映射

把每个事件按用户和业务影响（非技术原因）映射到严重性（SEV1-SEV4）。

为什么

严重性驱动一切下游 — 谁 page、响应多快、是否通知客户、复盘多严。若按技术原因定（"DB 崩了，SEV1"），你凌晨 3 点为打只读副本零用户影响的崩 page DBA。若按用户和业务影响定（"0.1% 结账失败 = SEV2，收入降 = SEV1"），对的人以对紧急度响应。映射须事件前写下，因为凌晨 3 点没人能冷静评估"这影响收入吗"；预定义表把判断变查表，既快又跨值班工程师一致。

何时使用

在第一个事件之前。业务模型、用户群或服务架构变到移影响阈值时 revisit。

如何做

1. 按影响非原因定义 4 严重性
   - SEV1：收入降 或 >10% 用户失败 或 数据丢/安全破
   - SEV2：1-10% 用户退化 或 关键功能坏有变通
   - SEV3：次要功能坏、变通易、<1% 用户
   - SEV4：外观或仅内部、无用户影响

2. 为你业务预算影响阈值
   - "收入降" = 结账错误率 >1% 持续 5m（你知你每分钟收入）
   - "10% 用户" = 一个服务 10% 流量的区域挂
   - 写成具体数字，非形容词

3. 每告警映射默认严重性
   - 告警规则含基于其隐含影响的严重性标签
   - 事件中 IC 可带理由升/降级

4. 严重性绑响应期望
   - SEV1：page、确认 <5m、作战室、客户通讯、需复盘
   - SEV2：page、确认 <30m、需复盘
   - SEV3：工单、下一工作日、复盘可选
   - SEV4：工单、方便时修、无复盘

5. 复盘中审查严重性判定
   - "这是 SEV2 还是 SEV3？" — 从真实事件校准表
   - 漂向过严重（一切 SEV1）破坏紧急信号

示例

# severity-table.md — 预定义、事件中查表
| 影响                                      | 严重性 | 响应              |
|-------------------------------------------|--------|-------------------|
| 结账错误率 >1% 持续 5m                     | SEV1   | page、确认 <5m、作战室、客户通讯 |
| 任一区域 100% 挂                           | SEV1   | page、确认 <5m     |
| 认证挂（无人能登录）                       | SEV1   | page、确认 <5m     |
| 结账错误率 0.1-1%                          | SEV2   | page、确认 <30m    |
| 搜索挂（浏览仍工作）                       | SEV2   | page、确认 <30m    |
| 邮件通知延迟 >30m                          | SEV3   | 工单、工作日       |
| 静态页错别字                               | SEV4   | 工单、方便时       |

# 告警规则带默认严重性：
- alert: CheckoutErrorRateHigh
  expr: checkout_error_rate > 0.01
  for: 5m
  labels: { severity: SEV1, team: payments }
# IC 可降为 SEV2 若调查显示是已知抖动上游且有变通激活
# — 但须在事件频道说明理由。

常见问题

⚠按技术原因（"DB 崩 = SEV1"）非用户影响定严重性 — 打零用户影响的只读副本崩凌晨 3 点 page DBA。
⚠一切 SEV1 — 紧急度统一则无信息，工程师对 SEV1 不比对 SEV2 响应更快。
⚠无预定义表，严重性成凌晨 3 点判断 — 不同值班工程师对同事件定不同严重性，破一致性。
⚠严重性不改响应行为 — SEV3 和 SEV4 都 page，破坏区分目的；每级绑具体响应期望。

最佳实践

✓按用户和业务影响（收入、受影响用户 %、数据丢）非技术原因定严重性 — 写具体数字非形容词。
✓预发布带影响阈值和每级响应期望的严重性表；值班查表而非凌晨 3 点判断。
✓每严重性绑具体响应行为（确认时间、作战室、客户通讯、需复盘）使级别改行为非仅标签。
✓复盘中从真实事件校准表；监控漂向过严重并在一切变 SEV1 时重基。