事件严重级别是什么？SEV1 到 SEV3 一次讲清
事件严重级别（Severity Level）衡量事故对业务的影响程度：SEV1 是致命事故、SEV3 是轻微问题。本文讲清 SEV 分级标准、Severity 与 Priority 的区别、为什么"说人话"的分级更好用，并附分级定义模板。
不是所有事故都值得半夜把人叫醒。严重级别（Severity Level）就是给事故按业务影响分级的制度，让全公司在事故发生时瞬间对齐认知、启动对应流程，而不是现场临时讨论"这算不算大事"。
什么是严重级别
严重级别衡量事故对业务的影响程度。最常见的分级是 SEV1 到 SEV3：
| 级别 | 定义 | 典型例子 |
|---|---|---|
| SEV1（致命） | 对业务影响重大 | 全站宕机、所有用户不可用；重大安全漏洞；客户数据丢失 |
| SEV2（严重） | 有显著业务影响 | 核心功能的重要部分失效；部分用户无法使用服务 |
| SEV3（轻微） | 业务影响低 | 给用户带来轻微不便，但不影响任何主要功能 |
大组织会延伸到 SEV4、SEV5，但3 级对多数团队已经足够。级别越多，事故发生后花在"这算 SEV2 还是 SEV3"上的争论就越长——分级的意义是加速响应，不是制造新的会议议题。
为什么要分级
分级不是 DevOps 的黑话，它解决两个实际问题：
- 对齐认知：说一句"SEV1"，所有人立刻明白事态量级，不用解释；
- 绑定流程：每个级别挂接预设的响应动作，出事即触发，零即兴发挥。例如 SEV1 自动关联"立即更新状态页 + 电话通知高管"；SEV3 只关联"在工单系统里建个单子"。
Severity 和 Priority 有什么区别
多数情况下两者一致：越严重越优先。但存在两类错位：
- 高优先级 + 低严重度：首页改版导致 H1 标题排版错乱——功能毫无影响（不严重），但损害品牌形象、误导访客（很紧急，要先修）；
- 高严重度 + 低优先级：产品对 0.01% 的客户完全不可用——对这部分客户是致命的，但影响面太小，排期上可以往后放。
所以两者的准确定义是：
- Severity（严重度）：事故对业务的影响有多大——回答"后果是什么"；
- Priority（优先级）：事故的紧急程度——回答"先修哪个"。
因为优先级直接决定行动顺序，实操中围绕优先级工作往往更顺手。
简化方案：说人话的分级
分级制度的最大失败模式：半夜三点被叫醒的值班人想不起"SEV1 是最严重的还是最轻的"——数字编号在高压状态下容易错乱，非技术同事更可能把 SEV3 当成最高级。
解法：放弃代号，直接用人类语言。
| 数字代号 | 人话版本 |
|---|---|
| SEV1 / P1 | 致命事故（Critical） |
| SEV2 / P2 | 严重事故（Major） |
| SEV3 / P3 | 轻微事故（Minor） |
"致命事故"三个字不需要培训，全员秒懂。
更好用的定义方式：用自家业务举例
抽象定义容易扯皮，用你产品的真实场景写分级定义才落地。以一家民宿预订平台为例：
| 级别 | 我们产品的真实场景 |
|---|---|
| 致命 | 全站无法访问；支付资金错误；房东/房客数据泄露 |
| 严重 | 无法下单预订；搜索不可用；某城市房源全部打不开 |
| 轻微 | 图片加载慢；次要页面排版异常；单个房源信息错误 |
这样的表贴出来，技术和非技术人员对"我们现在面对什么"有完全一致的认知——这就是分级制度的终极目的。
最后提醒
无论用 SEV、P 还是人话分级，级别本身不产生价值，绑定在级别上的流程才产生价值。分级表写完，紧接着要做的是给每一级挂上：通知谁、多久内确认、是否更新状态页、是否启动复盘。
在观测云中，可以通过告警级别 + 告警策略把分级固化：不同级别绑定不同通知对象和升级规则，致命事故电话+短信直接叫人，轻微事故只发群内通知，让分级从文档变成系统行为。 1
常见问题（FAQ）
Q：SEV 和 P 两套编号要同时用吗？
不要。选一个体系用到底，混用必然混乱。纠结选哪个的话，直接用人话版（致命/严重/轻微）。
Q：谁来定级别？吵起来了怎么办？
第一响应人现场定级别，先定先干，事后校准。复盘中发现定错了，调整的是分级定义表，而不是追责定级人。现场纠结级别的代价远大于定错一级。
Q：级别定好后可以中途改吗？
可以且应该。事故处置中发现影响面比预想大，立即升级级别并触发对应流程；反之亦然。级别是动态评估，不是一锤定音。
Q：我们事故很少，需要分级吗？
需要，而且可以更简单——"致命/非致命"两级起步。分级的价值恰恰在事故来临时体现：没有预设流程，第一次大事故就是灾难现场。
