第3章 告警级别定义：P0~P4 多级告警的核心原则
告警级别这事儿，说简单也简单，不就是分个轻重缓急嘛。但我在很多团队都见过一个通病：把P0当成万能标签，出了啥事都往上贴。结果呢？真正的P0来了，大家反而麻木了。
这一章，咱们就把P0到P4的定义原则、影响范围和响应时效掰开揉碎讲清楚。你想想看，如果没有一套靠谱的分级标准，告警响应流程就是空中楼阁。
3.1 为什么需要多级告警？
很多刚入行的朋友会问：为啥不干脆搞成“有问题”和“没问题”两类？我以前也这么想过。但现实情况是，一个大型系统每天能产生上万条告警，如果不分级，运维人员根本没法判断该先处理哪个。
多级告警的核心价值就三点：
- 帮人做决策：级别直接告诉你“现在停下手里的活，先看这个”。
- 资源对等投入：P0 需要拉总监级别拍板，P4 可能实习生就能跟进。
- 事后复盘有依据：哪类告警经常漏掉？哪类总是超时？一查便知。
我个人习惯：每个新系统上线前，先把告警级别定义贴在团队公告栏。大家达成共识比啥都重要。
3.2 P0 ~ P4 定义原则
分级的底层逻辑就两条：影响范围和用户感知。说白了，一个告警的级别，取决于它让多少用户用不了、让用户的体验差了多少。
P0 —— 核心业务完全瘫痪
全站宕机、支付链路断了、数据库主库挂了。这种级别的事故，每多一秒钟都是钱。
- 影响范围：所有用户或核心业务完全不可用。
- 响应时效：≤5 分钟（有人可能觉得太严，但我跟你说，真出了事 5 分钟都嫌长）。
- 处置要求：必须立即中断所有其他工作，全员投入。
⚠ 我记得有一次电商大促：凌晨两点订单服务突然全挂，原因是机房光纤被施工挖断了。按我们的 P0 定义，3 分钟内就拉起了备份集群，5 分钟内业务恢复。如果不提前定义好级别，光确认“这算不算紧急”就得吵半天。
P1 —— 部分核心功能不可用
比如搜索首页打不开、某个核心 API 超时率飙升到 50%、登录模块间歇性失败。部分用户受到影响，但还有降级方案可用。
- 影响范围：核心功能严重受损，但尚未完全瘫痪。
- 响应时效：≤15 分钟。
- 处置要求：立刻响应，优先恢复，事后根因分析可放宽。
P2 —— 非核心功能受损或核心功能轻微异常
比如后台报表系统不可用、历史数据查询变慢、某些非关键页面加载超时。用户还能用，但体验打了折扣。
- 影响范围：部分用户，或非核心功能完全不可用。
- 响应时效：≤30 分钟。
- 处置要求：值班人员优先处理，可排在 P0/P1 之后。
P3 —— 低优先级功能或非功能性告警
磁盘使用率超过 80%、某个次要接口耗时偶发偏高、日志收集模块重启。这些告警通常是渐进式的，短时间不会酿成大祸。
- 影响范围：少数用户或内部运维问题。
- 响应时效：≤120 分钟。
- 处置要求：记录工单，日间处理即可。
P4 —— 建议性或告警性事件
比如某个服务版本有安全漏洞但尚未被利用、监控项阈值接近但未触发、合规性提醒。说白了，就是“提醒你注意一下”。
- 影响范围：基本无直接影响。
- 响应时效：≤1 个工作日。
- 处置要求：纳入后续迭代或定期巡检。
| 级别 | 影响范围 | 典型场景 | 响应时效 |
|---|---|---|---|
| P0 | 全站/核心业务瘫痪 | 支付不可用、数据库主从全挂 | ≤5 分钟 |
| P1 | 核心功能严重受损 | 登录失败、API 超时率 > 50% | ≤15 分钟 |
| P2 | 非核心功能不可用(或核心功能轻度异常) | 后台报表不可用、页面加载慢 | ≤30 分钟 |
| P3 | 低优先级功能/内部问题 | 磁盘超过 80%、次要接口偶发慢 | ≤120 分钟 |
| P4 | 建议/告警性事件 | 版本安全漏洞、阈值接近临界值 | ≤1 个工作日 |
3.3 避坑指南：这些坑我都踩过
我曾经在金融项目中遇到一个典型问题：把“支付链路错误率达到 1%”定义为 P2，结果后来发现那是个 P0 级别的事故前兆。为啥？因为那 1% 的用户恰好是 VIP 客户，他们无法交易，直接导致投诉爆炸。
教训：定级不能只看指标数字，还要看“谁”被影响了。核心用户的 1% 可能比普通用户的 50% 更严重。
还有一个常见错误：把运维操作的便利性混进定级标准。比如“这个告警半夜处理太麻烦，干脆降到 P3 明天再看。”这就完全偏离了分级的目的——级别应该只反映用户和业务的真实影响。
我的建议是：
- 每次定级后反问自己：“如果这是凌晨三点，我愿意被叫起来处理吗？” 如果愿意，说明级别够高。
- 定期（比如每季度）回顾告警数据，看看哪些 P3 累积变成了 P0。别等到砸手里才后悔。
3.4 如何判定具体场景的级别？
实际工作中，很多时候边界是模糊的。比如一个微服务的 CPU 冲到 99%，但上游有降级缓存——这算 P1 还是 P2？
我个人习惯用一个小表格快速对齐：
| 判定维度 | P0 | P1 | P2 | P3 |
|---|---|---|---|---|
| 影响用户比例 | ≥80% | 30% ~ 79% | 5% ~ 29% | < 5% |
| 功能重要性 | 核心交易链 | 核心特征 | 辅助功能 | 管理/日志类 |
| 是否可降级 | 无降级方案 | 仅部分降级 | 完全可降级 | 自动恢复/降级 |
| 恢复影响 | 需立即回滚 | 需手动干预 | 可自动重试/调度 | 可观察后处理 |
嗯，这里要注意：上面的表格不是的。每个团队的业务特点不一样，有些 P2 场景在另一个系统可能就算 P1。关键是把判定逻辑明确下来，让大家有据可依。
3.5 响应时效是“承诺”不是“理想”
我见过很多团队把响应时效定得很漂亮，比如 P0 3 分钟响应、P1 10 分钟响应。结果呢？真出了事，人凑不齐，电话打不通，最后超时了也没人追责。这样的响应时效就是一纸空文。
定响应时效时，你得考虑团队的实际排班、跨时区协作、告警渠道的可达性。比如：
- P0 要求 5 分钟内响应，那意味着对应的值班人员必须 7×24 小时在线，且能立即中断当前任务。
- 不要定一个经常达不成的目标，否则大家会失去敬畏心。宁可宽松一点、严格执行，也别定一个好看的“假目标”。
响应时效的落地，靠的是制度、工具和反复演练，不是嘴巴说“我们要重视”。