第4章 告警级别分类：P0/P1/P2/P3的定义与响应时效
告警级别这事儿，说白了就是给问题贴标签。你想想看，凌晨三点收到一条告警，是爬起来处理还是翻个身继续睡？这个决定权，就握在级别定义手上。
我刚开始带团队时，犯过一个典型错误——把所有告警都设成P2。结果呢？真正出大事的时候，大家反而麻木了。嗯，这就是“狼来了”的运维版。
4.1 四级告警模型
我们业内通用的分级标准，从重到轻依次是P0、P1、P2、P3。每个级别对应不同的业务影响范围和响应要求。记住一个原则：级别越高，动作越快。
核心思想：告警级别的本质，是对“用户感知”和“经济损失”的量化评估。
一个技巧：如果你不确定该定P几，先问自己“这个故障持续5分钟，公司会损失多少钱？” 0元？P3。几万？P1。几十万以上？P0。
下面这张图，是我梳理的告警分级处理流程，你先从全局上有个印象：
4.2 每级定义的详解
P0 —— 核心服务完全瘫痪
这是最高级别。我遇到过最典型的情况：线上数据库主库宕机，所有用户无法登录。这就是P0。
- 定义：核心业务完全不可用，影响全量用户或造成重大资损。
- 例子：支付接口挂死、核心数据库不可读写、CDN全站故障。
- 响应时效：5分钟内响应，30分钟内恢复或止血。
- 通知方式：电话 + 即时通讯 + 语音群呼，必须找到人。
避坑指南：我曾经在一次P0事件中，因为“再等一下看看会不会自动恢复”，耽误了宝贵的15分钟。P0不是赌运气的时候。直接执行应急预案，别犹豫。
P1 —— 核心服务严重降级
P1和P0的区别在哪？P0是“彻底不能用”，P1是“能用但非常难受”。举个例子：某功能响应时间从100ms飙升到10s，用户能操作，但体验极差。
- 定义：核心功能严重受损，影响大部分用户，但系统未完全宕机。
- 例子：订单查询慢如蜗牛、图片加载大面积超时、核心API批量500错误。
- 响应时效：15分钟内响应，2小时内恢复或止血。
- 通知方式：电话 + 即时通讯。
我自己有个习惯：P1事件介入后，每30分钟在群内同步一次进展。哪怕只是说“还在查”，也能避免恐慌。这个习惯救过我很多次。
P2 —— 非核心功能异常或局部故障
P2的特点是什么？说白了，不影响主营业务，但影响周边功能。比如个人中心的头像上传失败，就是典型的P2。
- 定义：非核心功能故障，或核心功能仅影响极小部分用户。
- 例子：用户头像无法编辑、某地区（非核心）访问延迟、控制台页面报错。
- 响应时效：2小时内响应，24小时内修复。
- 通知方式：即时通讯群。
一个建议：P2虽然不急，但往往藏着大隐患。我在排查一个P2的慢查询时，顺藤摸瓜发现了一个即将变成P0的索引丢失问题。所以，P2的工单我会在2小时内“看过一次”，确认根因，而不是真的等到24小时再管。
P3 —— 低优先级问题或体验优化
P3一般指向“不影响用户正常使用，但看着不爽”的问题。比如官网某个页面错别字、文档链接失效、非功能性建议。
- 定义：问题存在但不影响运行，或仅为优化建议。
- 例子：UI样式错乱、文案拼写错误、某日志级别设置过高。
- 响应时效：24小时内响应，下次迭代修复。
- 通知方式：工单系统或邮件。
4.3 响应时效管理要点
光知道级别定义还不够，关键看怎么“管住”时效。我给你列几个我踩过的坑和总结出的方法：
| 管理要点 | 说明 |
|---|---|
| 计时起点 | 从告警产生瞬间开始计时，不是从你看到的那一秒开始。我在项目里吃过“我以为”的亏。 |
| 响应 vs 解决 | 响应=有人接手；解决=问题恢复。P0要求5分钟内必须有人回复，不代表5分钟能修好，但必须要有人“认领”。 |
| 升级机制 | P0/P1超过响应时效未处理，系统自动升级到更高一级的运维经理甚至CTO。 |
| 值班覆盖 | P0/P1必须保证7×24小时有人响应。我的团队曾经因为只有一个人值班，结果他连夜宵都不敢去吃——不健康。 |
一个容易忽略的规则：告警级别可以“升级”但一般不“降级”。如果P2事件迟迟4小时没人处理，自动升级为P1。但反过来，不要轻易把一个P0降为P2去记工时——除非问题已经明确止血且影响消除。
好了，关于告警级别的定义和时效，核心就是这几个点。你可能会觉得P0离自己很远，但相信我，做好P3的管理，能有效减少P0的产生。毕竟，很多大火都是从一个小小的冒烟开始的。