📚 课程目录第3章告警分级标准

告警分级标准：严重、主要、次要、警告

告警分级这事儿，说白了就是给告警贴个“重要性”的标签。我刚开始做运维那会儿，收到的告警基本全是一个级别，结果就是狼来了喊多了，真正出了事反而没人当回事。后来我慢慢摸索出这套四级的分类体系，用了好多年，算是比较成熟了。

为什么要分四级？你想想看，一个系统日常产生的告警可能有上千条，如果每一条都按最高级别处理，团队早就崩溃了。分级之后，大家可以快速识别哪些需要立即响应，哪些可以白天再说。

严重，就是系统的“心脏骤停”。我在项目中遇到过好几次这种情况，半夜三点被电话叫醒，那种感觉，真的不好受。

核心定义：直接导致核心业务中断或数据丢失的异常。必须立即响应，没有商量余地。

  判定标准：
  核心业务完全不可用（比如支付系统挂了、登录认证失效）
数据持久性损坏或丢失（数据库损坏、存储链路断裂）
安全合规风险（疑似数据泄漏、异常提权）

注意：我曾经踩过一个坑，把某个只有 VIP 用户能访问的功能故障也定成严重。结果导致团队误判了真正的核心业务中断。后来我学乖了，严重必须同时满足“核心”和“不可用”两个条件。

响应要求：我个人习惯的做法是，严重告警必须在 15 分钟内由一线值班人员确认，30 分钟内拉起应急小组。超过 1 小时未处理，自动升级到部门负责人。

主要告警，老运维常叫它“功能骨折”。系统还在跑，但某个重要功能已经瘸了。

核心定义：核心业务功能受损，但业务流没有被完全打断。用户可能会遇到超时、部分功能不可用，但主流程还在。

  典型场景：
  非核心模块不可用（比如用户中心能登录，但个人头像上传坏了）
核心功能性能大幅下降（单次请求延迟从 50ms 飙升到 5s）
部分服务集群故障，但其他节点还能扛住

处理技巧：我建议团队对 P1 告警采用“两班倒”抢修策略——主值班立即介入，同时通知备班人员就绪。这样即使处理时间较长，也不至于把人耗到精疲力尽。

响应要求：30 分钟内一线确认并开始排查，2 小时内必须给出修复计划或临时解决方案。如果 4 小时内找不到根因，则需要升级到研发经理。

次要告警，说白了就是“皮外伤”。系统功能正常，用户体验也没明显影响，但有个地方不对劲。

核心定义：非核心功能异常或资源使用异常，不直接影响用户主流程。这类告警通常可以等到日常维护窗口再处理。

  我的经验清单：
  磁盘使用率超过 85%（还能用，但需要关注增长趋势）
单台服务器负载偏高（还没到集群整体告警阈值）
某项内部监控指标短暂异常（比如某个非关键接口偶发超时）

避坑提示：我曾经见过一个团队积压了上千条 P2 告警没处理，最后发现是某个缓慢的磁盘泄漏导致全集群宕机。所以我建议对 P2 也必须设定最长挂起时间——超过 72 小时没处理，自动升级为 P1 重新告警。

响应要求：可安排到下一个备份窗口或日常维护计划中处理。但要注意，必须每周审核一次 P2 告警列表，避免堆积成问题。

警告告警，你可以把它理解成系统在说“我有点累，帮我看看”。不会出大事，但积累多了可能会变成慢性的系统压力。

核心定义：已知的、不影响业务的异常。通常是基础环境层面的提示性信息，或者业务上的已知边缘情况触发的日志。

  常见示例：
  临时缓存命中率略低（可能由于刚刚扩容导致）
某个旧版客户端 API 调用频次下降（不影响新版用户）
基础设施巡检发现可用内存还剩 20%（还能撑一段时间）

自动化处理：我个人习惯的做法是，把 P3 告警直接接入自动化脚本。比如磁盘用量达到 85% 只是 P2，但如果增长速率超过某个阈值，自动把级别提成 P1。这样既减少了人工负担，又不漏掉真实风险。

响应要求：不需要立即处理。建议每月汇总一次 P3 告警，分析是否存在趋势性问题。如果发现某个 P3 告警连续出现超过一个周期（比如每天产生 50+），就应该考虑把它提级或做自动化修复。

这张表我用了好几年，团队新人来了直接对着这个看，基本不会出错。

做得久了，我发现新手团队最容易犯这几个错误。嗯，我自己也踩过其中的大多数。

误区一：级别模糊——有时候觉得“这个告警好像有点严重但又不是特别严重”，就定了个 P0.5。别这么干，要么 P0 要么 P1，中间状态只会让大家困惑。
误区二：所有告警都要有人确认——P3 告警如果也需要人工确认，你想想看，值班的人得多忙。建议 P3 自动调低优先级，P2 自动派单，P0/P1 才需要人工确认。
误区三：级别固定不变——有一次我发现某个 P2 告警每天半夜都会触发，一开始没当回事，后来才知道是定时任务导致 I/O 抖动。这种就应该及时升为 P1 或调整监控规则。

一个小建议：每个季度复盘一次全站告警分级标准，看看有没有需要调整的地方。业务在变，监控规则也得跟着变。