2、告警分级与分类：告警等级定义（P0-P4）、告警分类方法（基础设施、应用、安全、业务）、分级响应策略
告警分级与分类，说白了就是给告警「定个位」。
我见过太多团队，半夜被P4的告警吵醒，结果发现只是磁盘用了80%。而真正P0的「数据库挂了」，反而因为告警太多被淹没了。嗯，这就是分级没做好的典型症状。
2.1 告警等级定义：P0到P4
我个人习惯用P0到P4五级体系。为什么是五级？因为三级太粗，七级又太细。五级刚刚好，一线运维能记住，值班同学也能快速判断。
| 等级 | 定义 | 响应时间 | 典型场景 |
|---|---|---|---|
| P0 | 核心业务完全不可用 | 立即响应（≤5分钟） | 支付链路中断、数据库主库宕机 |
| P1 | 核心功能严重受损 | 15分钟内响应 | API超时率>50%、缓存集群降级 |
| P2 | 非核心功能异常 | 30分钟内响应 | 报表系统延迟、部分用户登录失败 |
| P3 | 潜在风险或轻微异常 | 4小时内响应 | 磁盘使用率>85%、单节点CPU飙高 |
| P4 | 信息通知类 | 下一个工作日 | 证书即将过期、版本升级提醒 |
⚠️ 避坑指南： 我曾经见过一个团队，把所有告警都设成P2。结果呢？真正的P0来了，大家还在想「是不是又跟上次一样虚惊一场？」。记住：告警等级不是拍脑袋定的，是跟SLA绑定的。
2.2 告警分类方法
告警分类，我习惯分成四类：基础设施、应用、安全、业务。你想想看，这四类其实对应了运维的四个视角：
- 基础设施告警：服务器、网络、存储这些「硬家伙」。比如CPU、内存、磁盘、网络延迟。这类告警的特点是「物理性」强，通常有明确的阈值。
- 应用告警：中间件、数据库、微服务。比如MySQL慢查询、Redis内存碎片率、Nginx 5xx比例。这类告警需要结合业务流量来判断。
- 安全告警：入侵检测、DDoS攻击、异常登录。这类告警的特点是「时效性极强」，晚一分钟可能就出大事。
- 业务告警：订单量骤降、支付成功率下跌、用户注册失败。这类告警最「敏感」，也最容易误报。
💡 我的经验： 业务告警最好跟「同比/环比」结合。比如「订单量下降50%」比「订单量低于1000」更有意义。因为凌晨3点订单量本来就低，你设个固定阈值，那不得天天半夜被叫起来？
2.3 分级响应策略
分级响应，说白了就是「什么人、在什么时间、用什么方式、处理什么告警」。
我建议这样设计：
- P0响应：全员拉群，电话通知。值班SRE必须在5分钟内确认，10分钟内启动应急预案。我记得有一次线上P0，我们直接启用了「熔断+降级」策略，5分钟恢复核心链路。
- P1响应：值班SRE处理，15分钟内响应。如果30分钟解决不了，自动升级为P0。这个「升级机制」很重要，防止有人「死扛」。
- P2响应：日间处理，30分钟内响应。可以走工单流程，但要有明确的「处理人」和「截止时间」。
- P3响应：记录到运维看板，4小时内处理。这类告警通常是「慢性病」，比如磁盘慢慢涨、内存慢慢泄漏。
- P4响应：走变更流程，下一个工作日处理。比如证书更新、版本升级。
🔑 核心原则： 告警分级不是「定死」的，而是「动态」的。比如一个P3的「磁盘使用率85%」，如果连续3次告警都没处理，系统应该自动升级为P2。这叫「告警疲劳度检测」——我自己的项目里就踩过这个坑，磁盘从85%涨到95%用了两周，没人管，最后直接宕机。
2.4 知识体系总览
下面这张图，是我梳理的告警分级与分类的核心逻辑。你可以把它贴在工位上，或者放到运维手册里。
💡 一个小技巧： 告警分级不是「一劳永逸」的。我建议每季度做一次「告警分级复盘」，看看哪些告警被降级了、哪些被升级了。你会发现，有些P3告警其实比P1还危险——比如「证书过期」这种慢性病，一旦爆发就是P0。
好了，告警分级与分类就聊到这儿。记住：好的分级，能让你的团队睡个好觉；差的分级，能让你的团队天天「狼来了」。
公众号:蓝海资料掘金营，微信deep3321