告警体系设计：从P0到P4的实战落地
告警体系设计，说白了就是回答三个问题：什么时候该叫醒你？用什么方式叫？叫不醒怎么办？我在多个风控系统里摸爬滚打过后，发现很多团队把告警做成了「狼来了」——要么半夜被无关紧要的告警吵醒，要么真出事了反而没收到通知。今天咱们就聊聊怎么把这事做扎实。
一、告警级别定义：P0到P4的分级逻辑
我个人习惯把告警分成5个级别，从P0到P4。这个分级不是拍脑袋定的，而是根据业务影响面和响应时效两个维度来划分的。
| 级别 | 定义 | 响应时间 | 典型场景 |
|---|---|---|---|
| P0 | 核心功能完全不可用 | ≤5分钟 | 风控决策引擎宕机、数据库主库挂掉 |
| P1 | 核心功能严重受损 | ≤15分钟 | 规则引擎响应超时、关键数据延迟超过阈值 |
| P2 | 非核心功能异常 | ≤1小时 | 报表系统不可用、部分辅助模型失效 |
| P3 | 潜在风险或轻微异常 | ≤24小时 | CPU使用率超过80%、磁盘空间不足 |
| P4 | 信息通知类 | 不强制 | 版本发布成功、日常巡检报告 |
核心原则：P0和P1必须能直接打到人身上，P2和P3走工单或IM群，P4看看就行。
我在项目中遇到过一个问题：刚开始把「某个模型分数异常」定成了P1，结果一天告警上百次，值班同学直接崩溃。后来调整成P3，配合上下文分析，反而更有效。你想想看，告警级别不是越严重越好，而是越精准越好。
二、告警通知方式：选对渠道比喊破嗓子重要
不同的告警级别，通知方式完全不同。我见过最离谱的配置——P4告警也发短信，结果一个月短信费比服务器还贵。
我的建议是这样的：
- P0：电话 + 短信 + IM — 三重保险，确保有人接。电话打不通自动转给第二责任人。
- P1：短信 + IM — 短信保证能收到，IM方便查看详情。
- P2：IM群消息 — 发到值班群，@对应负责人。
- P3：邮件 + IM — 邮件留底，IM提醒。
- P4：邮件 — 或者干脆不通知，写到日报里。
避坑指南：我曾经把电话告警的轮询间隔设成了1分钟，结果P0故障时，5分钟内打了5个电话，值班同学接了第一个后正在处理，后面4个全是干扰。后来改成「首次电话后，5分钟内不再重复拨打」，体验好多了。
三、告警收敛与降噪：别让告警变成噪音
告警收敛，说白了就是把100条告警合并成1条。降噪则是把没用的告警过滤掉。这两件事做不好，告警体系就是摆设。
我常用的几种收敛策略：
- 时间窗口聚合 — 同一类告警在5分钟内只发一次，后面的计数累加。
- 根源告警识别 — 比如数据库挂了，上游所有服务都会报错，这时候只发数据库的告警，其他的自动抑制。
- 告警去重 — 同样的错误重复出现，只发一次，后面标记「已重复N次」。
- 动态阈值 — 根据历史数据自动调整阈值，避免白天晚上一个标准。
注意：收敛不是一刀切。我曾经把P0告警也做了5分钟聚合，结果核心服务挂了，5分钟后才收到通知。P0级别的告警，收敛策略要单独配置，甚至不做收敛。
降噪方面，我有个经验：告警规则每季度至少review一次。很多规则是半年前加的，现在业务变了，阈值早就不合适了。我见过一个团队，告警规则300多条，实际有效的不到100条，剩下的全是噪音。
四、告警升级机制：从值班到总监的阶梯
告警升级，就是当前级别的人搞不定，自动往上找。这个机制在P0和P1场景下特别重要。
我设计的升级流程一般是这样的：
P0告警触发
↓
值班工程师（5分钟内未确认）
↓ 自动升级
值班组长（10分钟内未解决）
↓ 自动升级
技术负责人（15分钟内未解决）
↓ 自动升级
CTO/VP（20分钟）
这里有个关键点：升级不是惩罚，是兜底。我曾经遇到一个情况，值班同学正在处理，但因为太忙忘了点「确认」，结果告警直接升级到了CTO那里。后来我们加了个「处理中」状态，只要有人点击处理，升级计时就暂停。
升级策略的核心参数：
- 确认超时时间：P0设3分钟，P1设10分钟
- 处理超时时间：P0设15分钟，P1设30分钟
- 升级轮次：最多3轮，再往上就是管理层了
- 节假日模式：非工作时间升级时间缩短一半
五、整体架构图：告警体系的全貌
下面这张图是我自己梳理的告警体系架构，涵盖了从数据采集到最终通知的完整链路：
这张图里，我特别想强调告警处理层。很多团队把精力都花在采集和通知上，中间的处理层反而最薄弱。其实告警分级、收敛、降噪这些逻辑，才是决定告警体系好不好的关键。
六、实战中的几个坑
最后分享几个我踩过的坑，希望能帮你少走弯路：
坑1：告警规则写得太死
我曾经把「接口响应时间超过500ms」设成P2告警，结果双11大促期间，所有接口都超500ms，告警刷屏了。后来改成「超过基线值的2倍」才解决问题。
坑2：升级机制没有熔断
有一次半夜数据库主从切换，P0告警触发，值班同学正在处理，结果升级机制每5分钟升一级，15分钟就升到了CTO那里。CTO打电话过来时，问题已经快解决了，白白浪费了管理层的时间。
我的建议：告警体系上线后，先跑一个月「观察模式」——只记录不通知。看看每天会产生多少告警，哪些是有效的，哪些是噪音。调整好了再正式启用。这个习惯我一直保留着，每次新系统上线都这么干。
告警体系设计，说到底是个平衡的艺术。太敏感了全是噪音，太迟钝了又容易漏报。找到那个平衡点，需要不断迭代和优化。嗯，今天就聊到这里，希望对你有帮助。
公众号:蓝海资料掘金营，微信deep3321