告警分级标准：影响范围与紧急程度
告警分级这件事，说简单也简单，说复杂也复杂。我见过不少团队把分级搞成一锅粥——P1、P2、P3堆在一起，谁先处理全靠吼。为什么会这样？因为大家只盯着"严重"两个字，没想过影响范围和紧急程度其实是两个不同的维度。
我个人习惯把这两个维度拆开看，再组合成一个矩阵。你想想看，一个告警影响了10000台服务器，但业务还能撑10分钟；另一个告警只影响了1台客户机，但数据正在被篡改。你说哪个先处理？这就是我们需要分级标准的原因。
两个核心维度
我们先定义清楚这两个维度，后面才好落地。
| 维度 | 定义 | 典型等级 |
|---|---|---|
| 影响范围 | 告警所影响的业务范围、用户人数、设备台数或数据条数 | 单点 / 局部 / 全局 |
| 紧急程度 | 若不处理，在多长时间内会造成不可逆损失 | 缓慢 / 紧迫 / 危殆 |
嗯，这里要注意：影响范围大不等于必须立刻动。我以前遇到过丢包率轻微波动，影响范围覆盖所有用户，但紧急程度极低——其实只是运营商在割接，等它自己恢复就行。反过来，一台核心数据库服务器上的单个磁盘告警，影响范围只是这一台机器，但如果5分钟内不处理，整个库就崩了，这时候谁还敢等？
五级分级标准
基于这两个维度，我梳理了一套五级标准。这套标准我在三家不同规模的公司都推行过，效果还不错。
核心原则：级别数字越小越紧急。P0 是火警，必须有人跳起来；P4 是风吹草动，记录在案即可。
- P0 – 关键：全局范围 + 危殆紧急。例如：全站宕机、核心数据库无法写入、大规模数据泄露。
- P1 – 严重：全局范围 + 紧迫紧急，或局部范围 + 危殆紧急。例如：某个核心业务模块不可用、支付链路超时超阈值。
- P2 – 一般：局部范围 + 紧迫，或全局范围 + 缓慢。例如：非核心页面加载慢、部分用户下单异常但可降级。
- P3 – 警告：单点范围 + 紧迫/危殆，或局部范围 + 缓慢。例如：单台 API 网关 CPU 飙高、某个微服务实例反复重启。
- P4 – 通知：单点范围 + 缓慢，或任何不影响业务的异常。例如：磁盘使用率超 80%、证书即将过期（但还有一周）、日志解析轻度延迟。
我曾经犯过一个错：把一块磁盘的 IO 延迟告警直接定成 P1，结果值班兄弟半夜爬起来，查了半天发现只是批量写日志的正常抖动。从那以后我规定，所有单点告警默认 P3 起步，除非你有自动化证据证明它在影响下游。
实操建议：在监控系统中配置分级时，先按「影响范围」打底，再按「紧急程度」修正。我一般会在告警规则里写一个回调函数，自动判断：如果影响范围是全局、紧急程度是危殆，直接打 P0；如果影响范围是单点、紧急程度是缓慢，一律降到 P4。
分级矩阵图
下面这张 SVG 图把两个维度的组合关系可视化出来了。你可以保存下来贴在告警值班大屏旁边，新同事一看就明白。
分级在实际落地中的常见坑
标准定了，但执行起来总会遇到一些问题。我挑几个高频的讲一讲。
- 告警升级机制缺失：P2 告警如果 30 分钟没认领，应该自动升为 P1 并抄送值班经理。我曾经在一个运维团队里发现，同一个磁盘告警挂了 8 小时都没人碰——因为定的是 P3，大家觉得不急，结果磁盘直接挂了。
- 分级颗粒度太细：有团队搞了 8 级，P0～P7。实际值班时根本分不清 P5 和 P6 的区别。我个人建议不超过 5 级，大脑的记忆上限就在这儿。
- 分级不跟 SLA 挂钩：分级如果不规定响应时间和处理时间，那就是一张废纸。下面这张表你得贴在规则里。
分级 SLA 参考（我团队正在用的版本）
| 级别 | 响应时间 | 处理时间 | 通报对象 |
|---|---|---|---|
| P0 | 5 分钟内 | 30 分钟内恢复 | CTO + 值班全体 |
| P1 | 15 分钟内 | 2 小时内恢复 | 部门负责人 + 值班小组 |
| P2 | 30 分钟内 | 8 小时内恢复 | 值班小组 + 相关开发 |
| P3 | 2 小时内 | 24 小时内处理 | 值班人员 |
| P4 | 下一个工作日 | 纳入迭代或自动修复 | 仅记录 |
注意：响应时间指的是从告警产生到有人确认"已看到"的时间，不是解决时间。很多团队把这两个混了，结果统计出来 SLA 总是不达标。我一般会在值班机器人里加一个确认按钮，点了才算响应开始计时。
特殊场景：跨团队的分级如何对齐
你要是只有一两个团队，分级好办。但一旦涉及多个业务线，每个团队对"严重"的理解可能不一样。我记得有一次，业务团队把用户头像上传失败定为 P1，运维团队说你这算哪门子 P1——最后闹到总监那去。
怎么对齐？我建议搞一个分级共识清单，把每个业务域最典型的告警列出来，大家坐在一起拍板。比如：
- 支付域：单笔交易失败 P2，批量超时 P1，全量不可用 P0。
- 登录域：SSO 全站不可用 P0，某区域登录慢 P2，单用户认证失败 P4。
- 存储域：任一数据节点磁盘写满 P2（熔断前），超过 3 个节点写满 P1，全部不可写 P0。
嗯，说白了，分级标准不是写死就完事的，你得隔一段时间复盘一次。我每季度会拉一个告警分级 Review 会议，把过去三个月误定级或者漏定级的告警翻出来，大家一起改规则。这样迭代上两轮，准确率就能提到 90% 以上。
小技巧：在告警规则里加上动态调整逻辑。比如某个指标连续 3 天在 P2 边界波动，但每次都自动恢复——我建议自动降一级到 P3，并打标签记录，减少无效骚扰。我写过一段简单的 Prometheus 告警规则，用 for: 5m 加阈值偏移来实现，效果不错。
分级标准这事，核心就一句话：别让值班的人猜。你把影响范围和紧急程度拆清楚，把矩阵画明白，把 SLA 写进系统，剩下的就是不断迭代。我见过最好的团队，他们让告警系统自己在运行时动态调整级别，结合历史命中率和误报率——这才是终极形态，但那是后面几章我们要聊的内容了。