2. 告警分类与等级定义
做告警处理这么多年，我最先想聊的就是分类和分级。你别小看这步，很多人一上来就看告警内容，直接动手修，结果修了半天发现根本不是自己的锅。说白了，分类和分级就像给告警报户口——先搞清楚它是什么类型、有多严重，后面的事才能安排明白。
2.1 为什么要分类？
我记得刚带团队那会，有个新同事盯着一条CPU使用率告警慌了神：“这个值95%了，是不是要宕机？” 我问他：“你确认过是突发峰值还是持续负载？是核心进程导致的还是恶意程序？” 他答不上来。这就是没做好分类的典型。
分类的意义在于：
- 快速定位根因：知道告警来自哪个层级（网络、系统、应用），就能缩小排查范围。
- 合理分配资源：网络告警派给网络组，应用告警派给开发组，避免交叉踢皮球。
- 积累处理经验：同类型告警可以沉淀为处置脚本或SOP。
我个人习惯：在告警平台里给每条告警打上“分类标签”，比如
CAT_NETWORK、CAT_SYSTEM_RESOURCE。这样后续统计分析就方便多了。
2.2 常见告警分类方式
实际生产中，我一般把告警分成三个维度来归类，你想想看是不是这样：
按来源分
- 基础设施告警：服务器、网络设备、存储、机房环境（温度、湿度）。
- 平台层告警：操作系统、中间件（Nginx、Tomcat）、数据库（MySQL、Redis）。
- 应用层告警：业务接口超时、错误率飙升、交易失败。
- 安全告警：入侵检测、异常登录、DDoS攻击。
按业务影响分
- 功能类：用户无法登录、支付失败——直接影响核心流程。
- 性能类：响应时间变长、吞吐量下降——用户体验变差但功能还可用。
- 资源类：磁盘空间不足、内存泄漏——可能逐渐恶化。
按检测方式分
- 阈值告警：超过预设门限（CPU>90%）。
- 变化率告警：指标在短时间内剧烈抖动，比如流量5分钟翻3倍。
- 日志模式告警：日志中出现“FATAL”“ORA-00600”等特定关键词。
- 预测告警：基于时间序列模型预判即将超出阈值。
避坑提醒：分类维度别搞太复杂。我曾经见过一个团队分了20几个类别，结果一线运维看到告警都不知道该选哪个，最后全是“其他”。建议控制在5~8个以内，最好能和团队现有工单系统一一对应。
2.3 严重级别划分标准
分级这事，说白了就是告诉所有人：“这个告警现在要不要扔下手里的活去处理？” 大部分场景我用四级体系，下面这张表是我在项目里常用的标准：
| 级别 | 名称 | 业务影响 | 响应要求 | 示例 |
|---|---|---|---|---|
| P0 | Critical（致命） | 核心业务完全中断 | 5分钟内响应，30分钟内恢复 | 支付网关宕机、主库不可用 |
| P1 | Major（严重） | 影响大量用户但可用 | 15分钟内响应，2小时内恢复 | 热门接口响应时间超过10秒、核心报表跑不出 |
| P2 | Minor（次要） | 少量用户受影响或无感知 | 1小时内响应，8小时内修复 | 个别后台服务重启、非核心页面图片加载失败 |
| P3 | Warning（警告） | 潜在风险，暂时无感知 | 当天确认，下一个迭代修复 | 磁盘使用率超过80%、证书还有30天过期 |
注意：同一类型的告警在不同业务场景下级别可能不同。比如“交易失败率超1%”在核心交易链路上是P1，但在非核心查询功能上可能只是P2。分级一定要结合业务上下文，不能一刀切。
2.4 实战中的分类分级联动
光有分类和分级还不够，关键是怎么把它们串起来用。我做过一个最简单的流转规则，分享给你：
- 告警产生 → 打上来源标签和应用标签。
- 自动判断级别 → 根据预设规则（比如涉及支付直接P0）。
- 分发责任人 → P0/P1同时触发电话+短信+群通知，P2发工单，P3进日报。
- 处置后降级 → 修复后升级为确认状态，并记录分类变更历史。
我曾经在电商大促期间遇到过一个场景：某个促销接口突然报P1警告，我一看分类是“应用层-性能”，按标准该发给开发组。但我又看了一眼业务影响评估——“该接口承载了全场优惠券核销”，果断手动升级到P0，后端开发主管直接电话拉群，7分钟定位到是缓存策略失效。如果按原规则走工单，至少耽误半个小时，那损失就大了。
2.5 知识体系总览
下面这张图帮你把刚才讲的内容理清楚，也是我自己培训新员工时必用的：
嗯，以上就是我对告警分类与等级定义的实战经验。你下次再看到告警，不妨先按这个框架过一遍——分类、分级、分派，三个动作做完，心里就有底了。