4. 告警级别定义：P0/P1/P2/P3/P4 分级标准，业务影响与紧急程度矩阵
先问大家一个问题：一个系统的告警分级，到底分给谁看？
很多人上来就抄互联网大厂的 P0～P4，结果运维收到一堆“P0”却全是磁盘快满、日志报错……说白了，分级脱离了业务影响，就是数字游戏。
我在项目中遇到过：某电商大促期间，一个 P0 告警打给值班主管，他爬起来发现只是单台机器 CPU 毛刺——这种“狼来了”反而让真故障被忽略。
4.1 核心原则：故障不等于告警，影响才决定级别
我始终强调一个观点：告警级别不是由技术指标定的，而是由业务损失定的。
举个例子：数据库连接池耗尽，对非核心报表查询可能是 P2，但对支付链路就是 P0。
所以分级前，必须先定义“业务影响域”和“紧急程度”。
4.2 P0～P4 定义标准
这里给出我在多个生产环境中用过的一套标准，适用于大部分互联网及企业级系统。
| 级别 | 业务影响 | 紧急程度 | 响应时效 | 修复时效 |
|---|---|---|---|---|
| P0 | 核心业务完全不可用，或产生资损/安全事件 | 极高 | 5 min | 30 min |
| P1 | 核心业务部分受阻，或大范围用户感知异常 | 高 | 15 min | 1 h |
| P2 | 非核心功能受损，或核心功能有降级但可绕行 | 中 | 30 min | 4 h |
| P3 | 单点异常、慢查询、资源预警，无用户影响 | 低 | 1 h | 24 h |
| P4 | 信息类告警，如磁盘使用量趋势、定期巡检 | 最低 | 日报 / 周报 | 下个迭代 |
注意：P0 和 P1 的差异在于“是否完全不可用”。我在某支付公司遇到过：支付接口超时 5% 算 P1，超时超过 30% 才升 P0——因为 5% 用户仍可通过重试成功。
4.3 业务影响 × 紧急程度矩阵
只有表格还不够，我们还需要一个二维矩阵来辅助判断。我把常见组合列出来：
| 业务影响 \ 紧急程度 | 低 | 中 | 高 |
|---|---|---|---|
| 无用户影响 | P4 | P3 | P3（如已影响趋势） |
| 单用户 / 少量 | P3 | P2 | P1（如用户是 VIP） |
| 部分用户 | P2 | P1 | P0（核心链路） |
| 全部用户 | P1 | P0 | P0 |
实战小技巧：如果你不确定某个告警该定 P1 还是 P2，先问自己一个问题：“我敢不敢让这个告警在凌晨 2 点把我叫醒？” 敢就是 P1 以上，不敢就是 P2 或更低。
4.4 一个决策流程图，帮你看懂分级逻辑
下面这张图是我自己常用的“告警级别快速判定流程”。我把影响范围和紧急程度分开判断，最后收敛到级别。
4.5 我踩过的一些坑
- P0 泛滥：某团队把所有“服务不可用”都标为 P0，结果一个前端页面报 503 连带后端 10 个 P0——全是重复的。我对每个 P0 都加了“去重窗口”和“确认是否真影响业务”。
- 紧急程度误判：有一次数据库主从延迟 30 秒，值班同学按 P2 处理。实际上那个库支撑着秒杀页面——用户看到的全是脏数据。后来我强制在分级标准里写清楚“用户能否通过刷新恢复”。
- 响应时效形同虚设：P0 要求 5 分钟响应，但通知系统本身延迟 3 分钟。我在项目中遇到过这种尴尬：等值班看到告警已经过了 8 分钟。所以分级标准必须配套 通知链路优化——P0 要走电话+即时通讯双通道。
4.6 落地建议
- 先定矩阵，再定代码。不要一上来就写告警规则表达式。把业务影响域（支付、登录、推荐……）和紧急程度（秒/分/时）画成矩阵，每个交叉点确认级别。
- P0～P4 必须跟 SLO 挂钩。比如 P0 对应 99.99% 可用性违约，P1 对应 99.9% 违约——这样级别不再是拍脑袋。
- 动态降级。我在生产环境做了“自动升降级”：如果某个 P2 告警半小时内未修复，自动升为 P1 并通知主管——因为你低估了影响。
⚠️ 警告：分级标准一旦发布，就是运维团队的契约。不要随意调整响应时效，除非经过全组评审。我在某公司见过 P1 响应时效从 15 分钟改成 30 分钟，结果导致核心链路挂了 40 分钟才有人介入——因为阈值放得太松了。