2、报警分级理论基础：P0/P1/P2/P3分级标准、严重性(S)与紧急度(U)矩阵、分级决策树模型
说实话，报警分级这件事，我见过太多团队把它搞砸了。
要么是全员P0，半夜三点被叫起来处理一个磁盘空间还剩40%的"紧急"告警。要么是P3泛滥，真正出大事的时候，大家反而麻木了。
为什么会这样？说白了，就是分级标准没定清楚。
今天我就把我在多个千万级用户系统里沉淀下来的分级方法，掰开揉碎了讲给你听。
2.1 P0/P1/P2/P3 分级标准
先给个最直观的定义。我习惯用「用户能不能用」和「数据会不会丢」这两个维度来切。
| 级别 | 定义 | 典型场景 | 响应要求 |
|---|---|---|---|
| P0 | 核心业务完全不可用，或数据有丢失风险 | 数据库宕机、支付链路中断、核心服务雪崩 | 立即响应，5分钟内介入 |
| P1 | 核心功能严重受损，但非完全不可用 | 接口超时率>30%、关键缓存失效、主从延迟过大 | 15分钟内响应，1小时内恢复 |
| P2 | 非核心功能异常，或核心功能有轻微影响 | 某个非关键页面报错、报表生成延迟、部分用户头像加载失败 | 1小时内响应，当天内修复 |
| P3 | 不影响用户，但需要关注或优化 | 磁盘使用率超过70%、某个慢查询出现、日志告警 | 记录工单，排期处理 |
我的经验：P0和P1的边界最容易模糊。我见过有人把「某个接口报错率5%」定为P0，这其实不合理。5%的报错率，如果用户侧有重试机制，感知可能只有0.5%。我个人的判断标准是——用户是否明确感知到「用不了」。
2.2 严重性(S)与紧急度(U)矩阵
光靠P0/P1/P2/P3还不够。你想想看，同样是数据库连接池满了，白天和凌晨三点，处理方式能一样吗？
所以我把分级拆成了两个维度：严重性（Severity）和紧急度（Urgency）。
- 严重性（S）：故障本身造成的损害程度。比如数据丢失就是S1，页面样式错乱就是S3。
- 紧急度（U）：需要多快处理。比如凌晨的磁盘告警，如果还有20%空间，U可以低一些；但如果是白天高峰期，同样的告警U就要拉满。
我习惯用这个矩阵来定级：
| U1（极紧急） | U2（紧急） | U3（一般） | |
|---|---|---|---|
| S1（极严重） | P0 | P0 | P1 |
| S2（严重） | P0 | P1 | P2 |
| S3（一般） | P1 | P2 | P3 |
| S4（轻微） | P2 | P3 | P3 |
一个小技巧：我每次做告警规则配置时，都会先问自己两个问题：「这个故障如果发生，用户会骂娘吗？」（严重性）「现在不修，半小时后会死人吗？」（紧急度）。两个答案一交叉，级别就出来了。
2.3 分级决策树模型
理论讲完了，但实际落地的时候，很多人还是会犹豫。所以我画了一棵决策树，你照着走一遍，基本不会出错。
这棵树怎么用？我举个例子。
有一次凌晨两点，告警说「订单服务响应超时」。我按决策树走了一遍：
- 用户是否完全不可用？—— 是，订单页面打不开。
- 数据是否安全？—— 检查了数据库，数据没丢，只是服务进程挂了。
- 定级：P0。虽然是凌晨，但核心业务全挂，必须立刻起来处理。
我曾经踩过的坑：有一次我把一个「非核心服务CPU飙高」的告警定成了P2，结果这个服务是核心服务的依赖链路之一，最终引发了级联故障。从那以后，我定级时一定会问自己：「这个故障会不会引发连锁反应？」如果答案是「有可能」，那就往上升一级。
2.4 分级后的行动指南
级别定好了，接下来就是「谁来处理」和「怎么处理」。我习惯这样分配：
- P0：全员响应，值班SRE直接拉起紧急会议，必要时通知研发负责人。每15分钟同步一次进展。
- P1：值班SRE主导，通知相关模块负责人。每30分钟同步一次。
- P2：记录工单，分配给对应团队。当天内给出修复计划。
- P3：进入待办池，排期处理。不需要额外通知。
嗯，这里要注意一点：P0和P1的响应流程里，一定要有「止损」环节。我见过太多人一上来就查根因，结果故障持续了半小时。正确的做法是——先恢复服务，再查原因。
说白了，报警分级不是为了给故障贴标签，而是为了让你在最短时间内做出正确的决策。你想想看，如果每个告警都按P0处理，那跟没有分级有什么区别？
这套方法我在多个团队里推行过，效果都不错。刚开始大家会觉得「走决策树太麻烦」，但用习惯了就会发现——它帮你省掉了「这个告警到底要不要管」的纠结时间。
公众号:蓝海资料掘金营，微信deep3321