一、告警分级概述：为什么需要告警分级？
各位同学好，我是老赵。今天咱们开始聊告警分级。
先问大家一个问题：你经历过告警风暴吗？
我记得刚做运维那会儿，公司监控系统刚上线，一天能收到上万条告警。半夜被电话吵醒，一看手机——全是磁盘使用率超过80%的提醒。说实话，80%的磁盘占用，在大多数业务场景下根本不算紧急。但因为没有分级，所有告警都发给了所有人。结果呢？真正重要的服务宕机告警，反而被淹没了。
这就是为什么我们需要告警分级。
1.1 没有分级的代价
我见过太多团队踩过这个坑。说白了，没有告警分级，你会面临三个问题：
- 告警疲劳：每天几百条不痛不痒的提醒，团队很快就麻木了。我有个朋友，他们团队后来干脆把手机静音了——因为实在受不了。
- 关键事件被淹没：真正需要立即处理的P0级故障，混在一堆P3、P4的告警里。等发现的时候，用户已经投诉了。
- 响应效率低下：所有人收到所有告警，没人知道该谁处理。我曾经在一个项目里，一个数据库连接池耗尽的问题，因为没分级，三个团队互相推了半小时。
避坑指南：我曾经接手过一个客户的监控系统，他们把所有告警都设成了“严重”级别。结果一个月后，连CTO都开始忽略告警了。记住：如果所有告警都是严重的，那就没有告警是严重的。
1.2 告警分级的目标
告警分级到底想解决什么问题？我个人理解，核心目标就三个：
- 区分轻重缓急：让团队知道哪些事必须马上处理，哪些可以等上班再说。
- 匹配响应资源：P0级故障需要全团队投入，P3级可能一个人就能搞定。分级能帮你合理分配人力。
- 减少噪音：把真正有价值的信息从海量数据里捞出来。说白了，就是让告警系统学会“闭嘴”。
核心观点：告警分级的本质，不是给告警贴标签，而是建立一套“事件-响应”的匹配机制。你想想看，消防队的火警也分等级，医院急诊也分颜色。运维告警，道理是一样的。
1.3 告警分级的原则
做告警分级，不能拍脑袋。我总结了几条原则，都是实战里踩过坑换来的：
| 原则 | 说明 | 我的经验 |
|---|---|---|
| 业务影响优先 | 以对用户和收入的影响为核心 | 别只看技术指标。一个非核心服务的CPU飙到99%，可能不如核心API的5%延迟增加严重 |
| 可量化 | 每个级别要有明确的判断标准 | “严重”这种词太模糊。改成“用户完全不可用”或“订单成功率低于95%” |
| 动态调整 | 分级标准要随业务变化 | 大促期间和平时，同一个指标的分级可能完全不同 |
| 可执行 | 每个级别对应明确的响应动作 | P0要拉群、打电话、启动应急流程；P4可能只需要记个工单 |
小技巧：我习惯在制定分级标准时，拉上业务方一起讨论。因为运维觉得“数据库连接数过高”是P1，但业务方可能觉得只要还能用，就是P3。这种认知差异，必须在分级阶段对齐。
1.4 告警分级的整体框架
下面这张图，是我在多个项目中沉淀下来的告警分级框架。它把整个流程串起来了：
嗯，这张图其实已经说得很清楚了。从数据源到分级引擎，再到最终的分级输出和响应动作，每个环节都环环相扣。我见过不少团队，只做了分级输出，但没定义响应动作——结果就是分了级也没人知道该干嘛。
1.5 常见分级模型对比
目前业界主流的告警分级模型，主要有这么几种。我列个表给大家对比一下：
| 模型 | 级别数 | 典型场景 | 优点 | 缺点 |
|---|---|---|---|---|
| P0-P3四级模型 | 4级 | 互联网公司、SaaS服务 | 简单清晰，容易落地 | 粒度较粗，复杂场景不够用 |
| SEV1-SEV5五级模型 | 5级 | 大型云厂商、金融行业 | 粒度细，适合大规模团队 | 级别太多，容易混淆 |
| 红橙黄蓝四色模型 | 4级 | 传统企业、IT运维 | 直观，非技术人员也能看懂 | 缺乏量化标准 |
| 自定义模型 | 按需 | 特定业务场景 | 灵活，贴合业务 | 维护成本高 |
我个人比较推荐P0-P3四级模型。为什么？因为简单。你想想看，告警分级本身是为了降低复杂度，如果分级模型太复杂，反而增加了认知负担。我见过一个团队搞了7个级别，结果运维同学每次收到告警都要先查表——这就不对了。
我的建议：刚开始做告警分级，先用P0-P3四级模型跑起来。等团队成熟了，再考虑细化。记住：先有，再优。
1.6 本章小结
好了，这一章的内容就这些。咱们回顾一下重点：
- 告警分级是为了解决告警疲劳、关键事件被淹没、响应效率低下这三个问题
- 核心目标是区分轻重缓急、匹配响应资源、减少噪音
- 四条原则：业务影响优先、可量化、动态调整、可执行
- 推荐从P0-P3四级模型开始落地