2、报警级别与分类：紧急程度分级（P0-P4）、报警类型（阈值、波动、预测）、报警分类标准
报警管理这件事，说白了就是给系统装上一套「红绿灯」。
没有分级，所有报警都往你手机上轰炸。结果呢？真正出大事的时候，你反而麻木了。我在项目里见过太多这样的场景——凌晨三点，P0 和 P3 的告警混在一起，运维同学直接静音了手机。嗯，这很危险。
所以这一章，我们来聊聊怎么给报警「排座次」。
2.1 紧急程度分级：P0 - P4
我个人习惯把报警分成五个等级。从 P0 到 P4，紧急程度依次递减。这个分级标准，业内基本是通用的。
| 级别 | 定义 | 响应要求 | 典型场景 |
|---|---|---|---|
| P0 | 核心业务完全不可用 | 立即响应，5分钟内介入 | 支付链路中断、数据库主库宕机 |
| P1 | 核心功能严重受损 | 15分钟内响应 | 订单超时率飙升、API 错误率 > 5% |
| P2 | 非核心功能异常 | 1小时内响应 | 后台报表延迟、部分用户头像加载失败 |
| P3 | 系统异常但不影响用户 | 24小时内处理 | 日志堆积、磁盘使用率超过 80% |
| P4 | 信息提示或建议 | 下一个迭代处理 | 版本升级提醒、证书即将过期（30天后） |
我曾经踩过一个坑：把 P3 和 P4 的报警直接发到了同一个群里。结果大家天天被「磁盘使用率 81%」这种告警刷屏，真正 P0 的「数据库连接池耗尽」反而被淹没了。后来我强制要求：P0/P1 走电话+短信，P2 走即时消息，P3/P4 只进工单系统。
2.2 报警类型：阈值、波动、预测
分级是「有多严重」，类型是「怎么发现的」。我一般把报警类型分成三大类。
2.2.1 阈值报警
最传统的方式。设定一个固定值，超过了就报警。
- 优点：简单、直观、容易配置
- 缺点：容易误报。比如双十一流量暴涨，CPU 冲到 90% 是正常的，但阈值报警会疯狂触发
# 一个典型的阈值报警规则（PromQL 示例）
# 当 CPU 使用率超过 90% 持续 5 分钟时报警
avg by(instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) < 0.12.2.2 波动报警
不看值，看变化率。说白了就是「跟平时不一样了」。
- 优点：能发现缓慢恶化的问题，比如内存泄漏
- 缺点：需要历史数据做基线，配置稍复杂
我建议：波动报警的窗口期至少设为 3 个周期。比如你的业务高峰是 10 分钟一个周期，那就用过去 30 分钟的数据做对比。太短了容易误报，太长了反应太慢。
2.2.3 预测报警
这是比较高级的玩法。用历史数据预测未来趋势，提前干预。
- 优点：在故障发生前就处理，用户体验最好
- 缺点：模型需要训练，初期准确率不高
举个例子。磁盘使用率如果按当前增长速度，预计 2 小时后会满。预测报警会在 1 小时前就提醒你扩容。你想想看，这比等到磁盘满了再报警，是不是从容多了？
2.3 报警分类标准
分级和类型都定了，接下来就是分类。我习惯把报警分成四个维度。
- 基础设施层：服务器、网络、机房。比如「交换机端口 down」
- 平台层：中间件、数据库、容器平台。比如「Redis 主从同步延迟」
- 应用层：业务代码、API 接口。比如「下单接口 500 错误率飙升」
- 安全层：入侵检测、漏洞扫描。比如「SSH 暴力破解尝试」
为什么要分这么细？
因为不同层级的报警，处理人不一样。基础设施的报警，网络工程师去修；应用层的报警，开发同学去看。分清楚了，才不会出现「报警转了一圈没人认领」的尴尬局面。
核心原则：一个报警，必须能明确找到「谁负责」。如果一条报警需要三个人开会讨论才知道该谁处理，那这个分类就是失败的。
2.4 知识结构图：报警分级与分类体系
下面这张图，把上面讲的内容串起来了。你可以把它贴在工位上，或者作为团队培训的参考。
2.5 实战中的避坑指南
最后，分享几个我踩过的坑，希望能帮你少走弯路。
我曾经犯过一个错误：把所有 P0 报警都发给了所有人。结果运维、开发、DBA 全被拉进一个群，半夜三点大家一起被吵醒。后来我改了规则：P0 只发给当值 SRE 和对应的业务负责人，其他人第二天看复盘报告就行。
一个小技巧：给每个报警级别配一个「冷却时间」。比如 P0 报警 1 分钟内不重复发送，P3 报警 30 分钟内不重复。不然一个抖动，你的手机能响到没电。
嗯，分级和分类这块，其实没有的标准。关键是要适合你的团队规模和业务特点。小团队可以只分三级，大团队可能需要更细。但不管怎么分，记住一个原则：让正确的人，在正确的时间，收到正确的报警。