3、告警级别定义：Critical、Warning、Info 的划分标准与业务影响评估
聊到告警级别，我见过太多团队把这事儿搞砸了。
要么全是 Critical，半夜三点把运维大哥叫起来看一个磁盘用了 81%——其实还能撑两天。要么全是 Info，真正出大事的时候，告警被淹没了，没人看。
说白了，级别定不好，监控系统就是个摆设。今天咱们就聊聊，Critical、Warning、Info 这三个级别到底该怎么划，以及背后的业务影响怎么评估。
3.1 三个级别的核心定义
我个人习惯，先把级别和「人的反应」绑定起来。别光看技术指标，要看这个告警来了，人需要做什么。
| 级别 | 定义 | 人的反应 | 响应时间 |
|---|---|---|---|
| Critical（严重） | 服务已中断或即将中断，用户已受影响 | 立即响应，无论几点 | ≤ 5 分钟 |
| Warning（警告） | 服务还在跑，但指标正在恶化 | 上班后处理，或值班人员关注 | ≤ 30 分钟（工作时间） |
| Info（信息） | 发生了某件事，但不需要人介入 | 看看就行，或者不看也行 | 无要求 |
嗯，这个表格看起来简单，但实际落地的时候，坑特别多。我一个个说。
3.2 Critical：什么才算「天塌了」？
Critical 级别的告警，应该满足一个条件：用户正在报障，或者 5 分钟内一定会报障。
我在项目中遇到过，有人把「CPU 使用率 > 90%」设成 Critical。结果呢？一台编译节点 CPU 跑满，但线上服务完全正常。运维半夜爬起来，看了一眼，骂了一句，又睡回去了。
真正的 Critical 应该是这样的：
- 服务完全不可用：比如 Nginx 502、数据库连接池耗尽、核心 API 超时率 > 50%
- 数据丢失或损坏：比如消息队列积压超过阈值、主从同步延迟超过 10 分钟
- 安全事件：比如被入侵、敏感数据泄露、证书过期（这个我吃过亏，后面细说）
- 资源即将耗尽且无法自动恢复：比如磁盘使用率 > 95%，且没有自动清理机制
我曾经把「单台机器内存使用率 > 95%」设成 Critical，结果集群里 100 台机器，每次滚动发布都会触发几十条 Critical。后来改成「集群内超过 30% 的机器内存 > 95%」才合理。记住：Critical 要看整体影响，不是单点指标。
3.3 Warning：预警信号，别让它变成 Critical
Warning 级别的意义在于：给运维留出处理时间。说白了，就是「现在还没事，但你再不管就要出事了」。
我建议 Warning 的阈值设置，要留出至少 30 分钟的缓冲。举个例子：
- 磁盘使用率：Critical 设 95%，Warning 设 80%
- 内存使用率：Critical 设 95%，Warning 设 85%
- API 响应时间：Critical 设 5 秒，Warning 设 2 秒
为什么是 30 分钟？你想想看，从告警触发，到值班人员看到，再到登录机器排查，最后决定怎么处理——这一套流程下来，20 分钟算快的。如果 Warning 和 Critical 只差 5%，那 Warning 基本等于没用。
Warning 的告警频率可以降低。Critical 我建议 1 分钟一次，Warning 可以 5-10 分钟一次。不然 Warning 刷屏，反而把真正重要的信息淹没了。
3.4 Info：记录就好，别打扰人
Info 级别的告警，说白了就是「日志的升级版」。它不需要任何人处理，只是告诉你：系统发生了某件事。
常见的 Info 告警：
- 服务正常启动/停止
- 配置变更已生效
- 定时任务执行完成
- 自动扩缩容触发
Info 告警最大的问题是——太多。我曾经见过一个团队，每天产生 10 万条 Info 告警，结果没人看，连 Critical 都被淹没了。
我的建议是：Info 告警不要发到企业微信或钉钉群。写到日志文件里，或者用一个单独的「事件中心」去展示。人只有在排查问题的时候才去看它。
3.5 业务影响评估：级别不是拍脑袋定的
很多团队定级别，就是拍脑袋：「嗯，这个挺重要的，设成 Warning 吧。」——这是大忌。
我习惯用一个简单的评估矩阵，把技术指标和业务影响挂钩：
| 业务影响 | 技术指标示例 | 建议级别 |
|---|---|---|
| 用户无法下单 | 订单接口超时率 > 80% | Critical |
| 用户下单变慢 | 订单接口响应时间 > 3s | Warning |
| 用户无感知 | 后台报表生成延迟 5 分钟 | Info |
| 部分用户受影响 | 非核心功能（如历史记录）不可用 | Warning |
| 全部用户受影响 | 登录服务完全不可用 | Critical |
你看，同样是「接口超时」，如果影响的是核心交易，那就是 Critical；如果影响的是非核心功能，Warning 就够了。级别不是由技术指标本身决定的，而是由它对业务的影响程度决定的。
3.6 一张图看懂告警级别体系
下面这张图，是我自己总结的告警级别判定流程。每次新加告警规则，我都会走一遍这个流程：
这个流程我用了好几年，核心就一句话：先问业务影响，再定技术级别。别上来就看 CPU 多少、内存多少，先问一句：「这个指标出问题了，用户会怎么样？」
3.7 实战建议：从「拍脑袋」到「有依据」
最后，给几个落地建议：
- 每个告警规则都要写「业务影响描述」。比如「磁盘使用率 > 95% → 可能导致日志无法写入，用户操作无记录」。写清楚，后面的人才知道为什么这么定。
- 定期复盘告警级别。我建议每季度做一次。看看哪些 Critical 其实没出事，降级；哪些 Warning 经常变成 Critical，升级。
- 新规则先设 Warning，观察一周再定。这是最稳妥的做法。我见过太多人一上来就设 Critical，结果把自己搞得精疲力尽。
- 级别要和值班表挂钩。Critical 必须有人 7×24 响应，Warning 可以只覆盖工作时间。如果团队小，可以考虑把 Warning 也纳入值班，但响应时间放宽。
Critical 是「天塌了」，Warning 是「天快塌了」，Info 是「天没塌，记录一下」。
级别不是由技术指标决定的，是由业务影响决定的。
定级别之前，先问一句：「用户知道吗？」
公众号:蓝海资料掘金营，微信deep3321