2、告警级别定义：Critical、Major、Minor、Warning 的划分标准与业务影响
聊到告警级别，我见过太多团队在这个环节上栽跟头。
说白了，告警级别就是给故障定个“轻重缓急”。你想想看，如果所有告警都一个级别，那跟没有告警有什么区别？我早年带团队时，就吃过这个亏——半夜被一条“磁盘使用率 51%”的告警吵醒，结果发现真正要命的数据库连接池耗尽，反而被淹没了。
所以，今天咱们就把这四级告警掰开揉碎，讲清楚。
2.1 四级告警模型：从 Critical 到 Warning
RMC 里我习惯用四个级别：Critical（致命）、Major（严重）、Minor（一般）、Warning（警告）。这不是拍脑袋定的，背后是业务影响和响应时效的差异。
| 级别 | 颜色标识 | 业务影响 | 响应要求 | 典型场景 |
|---|---|---|---|---|
| Critical | 红色 | 核心业务完全中断 | 立即响应（≤5分钟） | 数据库宕机、支付接口不可用 |
| Major | 橙色 | 核心功能严重受损 | 紧急处理（≤15分钟） | 响应时间超过 5 秒、大量 5xx 错误 |
| Minor | 黄色 | 非核心功能受影响 | 计划内修复（≤2小时） | 某个次要模块报错、缓存命中率下降 |
| Warning | 蓝色 | 潜在风险，尚未影响业务 | 观察或下一迭代处理 | 磁盘使用率超过 80%、CPU 负载偏高 |
核心原则：告警级别不是技术指标，而是业务影响指标。一个 CPU 使用率 95% 的告警，在离线计算集群里可能只是 Warning，但在交易核心链路上，它就是 Major 甚至 Critical。
2.2 Critical：天塌下来的级别
Critical 意味着什么？用户用不了系统了，或者核心数据正在丢失。
我记得有一次，线上支付网关的 Redis 集群突然脑裂，所有支付请求全部超时。这就是典型的 Critical——每多等一秒，就是真金白银的损失。
划分标准其实就两条：
- 核心业务完全不可用：比如登录、下单、支付这些主流程断了
- 数据有丢失风险：比如数据库主从同步中断超过阈值，或者磁盘损坏
嗯，这里要注意：Critical 告警必须走电话或短信通道，不能只发邮件。我见过有人把 Critical 配成邮件通知，结果半夜出事了，第二天早上才看到——那场景，惨不忍睹。
避坑指南：我曾经见过一个团队，把“某个 Pod 重启”也设成 Critical。结果一天收到 200 条 Critical，真正的故障反而被淹没了。记住，Critical 是“天塌下来”的级别，别滥用。
2.3 Major：火烧眉毛的级别
Major 比 Critical 低一档，但同样需要快速响应。它的特点是：核心功能还在跑，但已经严重受损。
举个例子，你打开一个电商网站，能加载出商品列表，但点“加入购物车”要等 10 秒——这就是 Major。业务没断，但用户体验已经崩了。
我个人的划分经验是这样的：
- 核心接口的 P99 延迟超过 5 秒
- 错误率超过 5% 但未达到 100%
- 核心依赖（如数据库、消息队列）的连接池使用率超过 90%
说白了，Major 就是“再不处理就要变成 Critical”的级别。我建议 Major 告警也要走电话通知，但可以允许值班人员有 15 分钟的处理缓冲。
2.4 Minor：可以喘口气的级别
Minor 告警，我的定义是：业务还在正常跑，但某个非核心环节出了点问题。
比如，用户头像上传服务挂了。这会影响用户体验吗？会。但用户还能正常下单、付款吗？能。所以它不配叫 Major。
我在项目中遇到过这样的情况：某个报表生成模块每天凌晨跑批，偶尔会失败。这就是 Minor——不影响白天业务，第二天上班再排查完全来得及。
Minor 的典型场景：
- 非核心服务的错误率升高
- 某个次要功能的响应时间变慢
- 缓存命中率从 95% 掉到 80%
这类告警走邮件或 IM 通知就够了，别半夜打电话。你想想看，凌晨三点被叫起来修一个“用户头像加载慢”的问题，换谁都得骂娘。
2.5 Warning：预警信号
Warning 是最容易被忽视的级别，但恰恰是最有价值的。
它的定位是：还没出问题，但趋势不对。比如磁盘使用率 80%，现在没事，但按这个增长速度，三天后就会满。Warning 就是给你一个提前量。
我个人的习惯是：Warning 告警不要求立即处理，但必须记录到工单系统里，纳入下一迭代的计划。我曾经因为忽略了一个“连接数缓慢增长”的 Warning，结果两周后连接池爆了，直接导致了一次 Major 故障。从那以后，我再也不敢小看 Warning。
Warning 的划分标准：
- 资源使用率超过安全阈值但未到危险线（如 CPU 70%、内存 75%）
- 错误率出现上升趋势（比如从 0.1% 涨到 0.5%）
- 证书即将过期（比如还有 30 天）
小技巧：Warning 告警可以设置“静默期”。比如同一个 Warning 在 24 小时内只发一次通知，避免刷屏。我一般会配合“事件压缩”策略来用，效果很好。
2.6 级别划分的核心逻辑：一张图说清楚
说了这么多，咱们用一张图来总结一下这四级告警的划分逻辑。我习惯用“业务影响程度”和“响应紧急度”两个维度来画这个矩阵。
你看，这个矩阵很直观：
- 右上角（Critical）：业务影响高 + 响应紧急度高，必须秒级响应
- 左上角（Major）：业务影响高但紧急度稍低，可以喘口气但别太久
- 左下角（Minor）：业务影响低 + 不紧急，排期处理就行
- 右下角（Warning）：业务影响低但紧急度高？其实 Warning 的“紧急度”是趋势上的，不是当下的
2.7 实战中的级别调整
最后说一句，告警级别不是一成不变的。我建议每季度做一次告警复盘，看看哪些告警级别定高了或定低了。
举个例子，我去年把一个“日志收集服务不可用”的告警从 Major 降到了 Minor。为什么？因为日志丢了不影响核心交易，而且我们有本地缓存兜底。但反过来，如果某个告警连续触发且每次都造成了实际影响，那就该升级了。
嗯，记住一句话：告警级别是为业务服务的，别让运维同学在半夜被没意义的告警折磨。
总结一下：Critical 是“立刻起来修”，Major 是“赶紧处理”，Minor 是“有空看看”，Warning 是“留个心眼”。把这四级定义清楚了，你的告警体系才算真正立住了。