第4章告警级别定义

告警级别定义：P0/P1/P2/P3分级标准

告警级别这事儿，说白了就是给故障分个三六九等。

我刚做运维那会儿，团队里所有告警都往一个群里扔。结果呢？半夜三点，磁盘空间用了80%的告警和核心数据库宕机的告警混在一起。值班兄弟直接麻了，分不清哪个该先处理。后来我们花了整整两个迭代，才把分级标准定下来。

我个人习惯，告警级别分四档：P0、P1、P2、P3。数字越小，优先级越高。

P0是什么？就是用户完全用不了你的系统了。

举个例子：支付网关全部超时、用户登录全面失败、核心数据库主库挂了且切换失败。这种级别的故障，影响的是所有用户，而且是持续性的。

我在项目中遇到过最典型的P0：双十一凌晨，订单创建接口全部502。那会儿我正睡觉呢，电话一响，看到是P0告警，直接从床上弹起来。嗯，那晚我们搞到凌晨四点才恢复。

  P0核心特征：
  核心功能完全不可用
影响所有用户或核心业务
需要立即响应，5分钟内必须有人处理
恢复时间目标（RTO）通常小于30分钟

P1比P0低一档，但同样紧急。

你想想看，用户能登录，但查不到历史订单；或者能下单，但支付一直转圈。这种就是P1。功能可用，但核心链路有严重问题。

我记得有一次，我们的推荐系统挂了。用户能正常浏览商品，但首页推荐全是空的。虽然不影响下单，但转化率直接掉了40%。这就是典型的P1——不是不能用，是体验极差。

我的经验：P1和P0的区别在于「是否完全不可用」。如果用户还能找到绕过去的方法，那就是P1；如果完全没辙，那就是P0。

P2级别的告警，说白了就是「有问题，但不着急」。比如某个非核心页面加载慢、某个报表生成延迟了10分钟、某个次要模块报错但自动恢复了。

这类告警通常不需要半夜处理。我一般建议：工作时间响应，24小时内解决。

举个例子：用户头像上传偶尔失败，重试就好了。这种就是P2。影响面小，有临时解决方案。

P3就是最低级别的告警。通常是些小毛病：某个接口响应时间从50ms涨到了80ms、某个日志里出现了少量警告、某个服务的内存使用率缓慢增长。

这类告警我一般攒着，每周统一看一次。说白了，就是「知道有问题，但不影响当前业务」。

注意：P3告警虽然优先级低，但不能忽视。我见过太多P3慢慢演变成P2、P1的案例。比如内存泄漏，一开始只是P3，三个月后直接OOM变成P0。所以P3也要有跟踪机制。

光有分级还不够。你得搞清楚：这个告警到底影响了谁？有多紧急？

我习惯用一个矩阵来辅助判断：

影响范围 \ 紧急程度	高紧急（立即处理）	中紧急（1小时内）	低紧急（24小时内）
全量用户	P0	P1	P2
部分用户	P1	P2	P2
内部/非核心	P2	P3	P3

这个矩阵怎么用？举个例子：

我在项目中遇到过最纠结的情况：某个功能影响了10%的用户，但恰好是VIP用户。按矩阵是P2，但业务方坚持要P0。后来我们加了一个「业务影响度」的权重因子，VIP用户的影响自动升一级。嗯，这个后面会细讲。

SLA（服务等级协议）和告警级别是绑定的。说白了，你承诺了99.9%的可用性，那告警响应时间就得跟上。

我一般这样关联：

告警级别	响应时间（SLA）	恢复时间（SLA）	通知方式
P0	5分钟	30分钟	电话 + 短信 + 群@所有人
P1	15分钟	2小时	电话 + 群@相关人员
P2	1小时	8小时（工作时间）	群消息 + 工单
P3	24小时	72小时	工单 + 日报

避坑指南：我曾经把P0的响应时间设成了1分钟，结果值班同学天天被电话轰炸。后来发现很多P0告警其实是误报。所以响应时间别设太短，5分钟是比较合理的。太短了容易狼来了，太长了业务受不了。

这里有个关键点：SLA不是拍脑袋定的。你得根据团队规模、值班人数、系统复杂度来调整。小团队搞P0 5分钟响应？不现实。我建议刚开始可以放宽一些，比如P0 15分钟响应，等团队成熟了再收紧。

另外，SLA要跟告警级别联动。比如某个服务承诺了99.99%的可用性，那它的告警级别天然就高。反过来，一个内部工具，SLA是99%，那P2级别的告警可能就够了。

  核心原则：
  告警级别决定响应速度
SLA决定告警级别的下限
影响范围决定紧急程度
三者结合，才能做出合理的告警策略

最后说一句：分级标准不是一成不变的。我每季度都会复盘一次告警数据，看看哪些P0其实可以降级，哪些P2其实应该升级。动态调整，才能让告警体系越来越精准。