SEV 分类
严重性是一种排班决策，而不是感觉量表。分配任何单一信号所能证明的最高 SEV，然后仅在获得证据时才降级。
严重性定义
- SEV1 - 影响收入或完全服务丧失。超过 5% 的用户无法完成关键流程。可能发生数据丢失或破坏。立即呼叫事件指挥官 + 技术主管 + 执行值班人员。
- SEV2 - 显著降级。核心功能对部分用户损坏，错误率超过 SLO 违规阈值，或存在临时解决方案但长期不可接受。在 5 分钟内呼叫事件指挥官 + 团队值班人员。
- SEV3 - 部分或轻微降级。非关键功能受影响，SLO 仍在预算内，尚无客户升级。创建工单，团队异步通知，下一个工作日之前修复。
- SEV4 - 外观问题或边界情况。无用户影响，主动发现。仅创建工单。
信号检查清单
回答以下问题以确定 SEV。第一个匹配的“是”胜出。
- 任何用户的支付、认证或数据完整性流程是否中断？ -> SEV1 候选。
- 过去 10 分钟内错误率是否超过 SLO 阈值？ -> 至少 SEV2。
- 是否影响多个区域或可用区？ -> 升级一级。
- 是否存在活跃的数据泄漏或破坏风险？ -> 无论用户数量多少，均视为 SEV1。
- 是否单个非关键端点变慢而其余正常？ -> SEV3。
范围乘数
- 影响半径：估计受影响用户的百分比。低于 1% 很少能证明 SEV1 的合理性，除非这 1% 是付费客户或存在严重的数据风险。
- 增长速度：影响是否在扩大？每 10 分钟翻倍的 SEV3 就是 SEV2。
- 检测延迟：如果问题未被发现已超过 30 分钟，假设影响半径比当前信号显示的要大。
呼叫谁
- SEV1：事件指挥官、服务负责人、值班 SRE 和技术主管。立即打开战斗室。
- SEV2：事件指挥官和值班服务负责人。根据需要邀请其他人。
- SEV3：服务团队异步值班。不打开战斗室。
- SEV4：工单，不呼叫。
工作示例：做出决策
错误做法：“结账似乎对某些用户中断了。感觉像是 SEV3——我会先调查原因，如果问题严重再呼叫某人。”
正确做法：“结账错误率在过去 15 分钟为 12%（SLO 阈值：1%）。支付流程中断 -> 信号 1 -> SEV1。已呼叫事件指挥官、服务负责人和值班 SRE（14:32）；战斗室已打开。影响半径估计：约 12% 的结账尝试，增长情况不明。原因未知——与 SEV 无关。重新分类时间定于 15:00。”
错误做法颠倒了顺序（原因在严重性之前），对已中断的支付流程犹豫不决，并延迟了呼叫。正确做法引用了设定级别的信号，立即呼叫，记录影响半径，并安排了重新分类时间——所有这些都在任何人知道问题原因之前完成。
交付物
生成一条分类记录——发布到事件频道或工单中——包括：分配的 SEV、一行说明引用设定级别的检查清单信号、影响半径估计（用户或请求的百分比）、被呼叫的人及时间，以及计划的重新分类时间。该记录让后续响应者可以信任当前级别，而无需重新推导。
质量标准
- 在开始任何根因调查之前，应根据影响信号分配 SEV。
- 说明应引用具体的检查清单信号，而不是直觉。
- 呼叫应在分配时发生，而不是在确认之后——潜在的 SEV1 应基于一个数据点立即呼叫。
- 设置重新分类时间（每 30 分钟），且级别应随证据上下移动。
应该做 / 不要做
- 应该做：在调查根因之前分配 SEV。严重性关乎当前影响，而非原因。
- 应该做：每 30 分钟重新分类。已解决的 SEV2 变成 SEV4；正在扩散的 SEV3 变成 SEV1。
- 不要做：为了避免吵醒人而低估 SEV。虚假的 SEV1 比遗漏的 SEV1 代价更低。
- 不要做：在潜在的 SEV1 上等待第二个数据点后再呼叫。