告警分类与分级
搞告警处置，第一件事就是把告警分清楚。别急着搭平台、写规则，先问自己三个问题：谁该响应？多快响应？怎么响应？答案都在分类分级里。
我记得刚做SRE那会儿，团队把Prometheus所有告警都往一个群里怼。结果呢？半夜告警刷屏，大家先瞪眼“这是啥？”，然后挨个查，最后干脆集体开静音。说白了，没有分类分级，告警就是噪音。
我习惯先按类型划分，再定级别。为什么？因为类型决定处理团队，级别决定响应速度，两个维度一交叉，处置路径就清晰了。
告警类型：基础设施、应用、安全、业务
告警按来源可以分为四大类。我在项目中踩过一个坑：把数据库连接池告警归到“应用层”，结果数据库团队没收到，应用团队又没权限看DB日志，硬生生拖了15分钟才发现是连接泄露。从那以后，我坚持类型归属必须明确。
| 类型 | 典型场景 | 响应方 | 特点 |
|---|---|---|---|
| 基础设施 | CPU ≥ 90%、磁盘满、网络丢包、节点宕机 | 基础设施/SRE | 规模效应明显，一个告警可能代表一批机器 |
| 应用 | 接口延迟、错误率突增、进程OOM、慢SQL | 应用开发/业务SRE | 和代码强相关，通常需要看日志和调用链 |
| 安全 | 暴力破解、异常登录、SQL注入、WAF拦截 | 安全团队 | 涉及攻击溯源，需要保留现场证据 |
| 业务 | 下单失败率、支付超时、转化率下降 | 业务运营/产品 | 直接关联收入，指标往往需要自定义 |
实际生产中还会有网络、存储、中间件等细分，但大类上跑不出这四块。你想想看，如果一个告警同时涉及多个类型，比如“应用部署后CPU飙高”，那就得靠标签（tags）来区分侧重点——别怕标签多，后期告警聚合全靠它。
告警级别：P0～P4，响应行为驱动
级别不是拍脑袋定的。我见过最糟的做法：把所有告警等级设成“紧急”。结果呢？真出大故障时，大家都麻木了。分级的核心原则是：级别越高，对人的打扰越深，越需要自动化兜底。
一个实用的分级参考（P0-P4）：
| 级别 | 含义 | 响应要求 | 示例 |
|---|---|---|---|
| P0 | 核心服务不可用，资损、大规模故障 | 立即响应（≤5分钟），需要拉起War Room | 全站502、数据库主库宕机 |
| P1 | 重要功能受损，影响大量用户 | 10分钟内响应，需指定责任人 | 订单列表接口超时、支付成功率下降20% |
| P2 | 非核心功能异常，或部分用户受影响 | 30分钟内响应，工作时间优先 | 某地域节点网络抖动、后台报表延迟 |
| P3 | 低风险问题，不影响用户 | 工作日8小时内响应，可放入工单 | 磁盘使用率80%、证书即将到期 |
| P4 | 信息提示，无需立即处理 | 不强制响应，记录归档即可 | 业务指标日报、版本发布通知 |
个人小技巧：给每个级别配一个响应超时自动升级的机制。比如P1级别15分钟无人认领，自动升级为P0并通知Duty Manager。我曾经在凌晨三点被P0叫醒，结果是P2没认领自动升级的猫腻——后来我们加了一条“认领后自动降级”，才解决问题。
类型 + 级别 = 处置矩阵
把类型和级别组合起来，就是一个清晰的分诊表。我习惯用一个二维矩阵来分配响应流程：
# 伪代码示例：根据类型+级别选择处理器
def dispatch_alert(alert):
if alert.level == 'P0':
if alert.type == '安全':
trigger_security_war_room()
elif alert.type == '基础设施':
call_infra_oncall()
# ...
elif alert.level == 'P2':
if alert.type == '业务':
create_biz_ticket(alert)
# ...实际工程中，我会把这些规则直接写死到告警引擎（比如Alertmanager的路由配置）。别让On-Call人员自己去想“这个告警应该找谁”——系统替他决定。
一段避坑指南
我曾经把P0定成“服务不可用”，结果线上实例内存泄露，一部分客户端超时、一部分正常。仲裁失败了？告警引擎判定为“部分可用”，只发了P2。等大量用户投诉时，已经过去1小时。后来我改了定义：带影响范围的量化标准（比如“错误率＞5%且持续3分钟”才算P0），而不是纯逻辑判断。
千万不要死守标准。告警级别的阈值得随着系统演变定期调整。我见过一个团队，数据库连接数P0阈值设为80%，结果版本上线后连接池增加，80%变成常态——P0告警天天响，大家直接忽略，直到真的挂掉。所以每次大版本发布后，重新审视一次告警阈值，很有必要。
下面这张图总结了我常用的分类分级体系。嗯，你照着这个结构去搭建自己的告警模型，基本不会出大错。
快速上手建议：先用你线上最高频的20条告警做一次分类分级，然后对照上面的矩阵看看有没有漏掉的组合。跑通一条完整链路再扩量，没必要一开始就追求完美。
记住：分类分级的最终目的是让正确的人，在正确的时间，用正确的方式去响应告警。别让工具定义流程，而是流程驱动工具。下一轮我们聊聊告警收敛和通知路由，但先把这个根基打牢——后面所有自动化都是建立在这个分类分级之上的。