告警分类与优先级
告警系统每天能吃掉几千条事件，但真正需要立刻动手的，可能就那么几条。如何不让自己被垃圾告警报摊，又不错过致命问题？
我个人习惯先把告警按维度拆开——严重程度、影响范围、业务层级、是否紧急。分清楚后，优先级自然就出来了。
为什么要分类？
说白了，就是解决两个痛点：告警风暴和优先级混淆。我经历过一次线上故障，同一个磁盘 IO 抖动推送了 2000 条告警，结果真正关键的连接池打满的消息被淹掉了。后来我们重构了分类体系，把“同因合并”和“降噪”写进了规则里。
另一个问题是，P0 和 P4 混在一起，值班的人根本分不清先后。我曾经见过运维组把一条“单节点 CPU 超 90%”的告警提了 P1，但那个节点其实是离线降级节点，用户无感知。这就是分类没做准。
分类维度
我一般用四个维度切分告警，每个维度给一个权重，最后算总分定优先级。
| 维度 | 等级/取值 | 说明 |
|---|---|---|
| 严重程度 | Critical / Major / Minor / Warning | 技术层面，看服务是否中断、数据是否丢失 |
| 影响范围 | 全局 / 部分 / 单点 / 无影响 | 影响多少个用户或业务模块 |
| 业务层级 | 核心链路 / 重要功能 / 附属功能 / 非关键 | 按业务价值排序，交易链路 > 配置管理 |
| 紧急程度 | 分钟级 / 小时级 / 天级 / 计划处理 | 匹配 SLA 要求，看是否需要立刻响应 |
优先级矩阵
光有维度不够，还得把维度组合成优先级等级。下面是我常用的一套五级分级（P0~P4），跟多数工单系统兼容。
| 优先级 | 定义 | 响应时间 | 例子 |
|---|---|---|---|
| P0 | 核心服务完全不可用，或数据丢失 | 立即响应，5 分钟内确认 | 支付接口返回率 0%、主库宕机 |
| P1 | 核心功能严重退化，但未中断 | 15 分钟内响应 | API 延迟 > 2s、连接池耗尽 80% |
| P2 | 重要功能受影响，有工作替代 | 1 小时内响应 | 缓存集群降级、非核心页面报错 |
| P3 | 非关键问题，不影响用户 | 4 小时内处理 | 备份失败、磁盘用量超 85% |
| P4 | 优化类、信息类告警 | 下一个迭代处理 | 日志告警、过期的证书提醒 |
关键规则：P0 和 P1 必须带自动通知（电话+微信+短信），P2 以下只走工单。别把 P3 都推成即时消息，不然值班手机震到没电。
优先级计算的自动化
手动定级太慢，而且容易出错。我推荐用决策树或者打分表，把四个维度的值映射成一个数字。
# 伪代码示例：告警优先级计算
def get_priority(severity, scope, biz_level, urgency):
score = 0
if severity == 'Critical': score += 40
elif severity == 'Major': score += 25
elif severity == 'Minor': score += 10
if scope == 'Global': score += 30
elif scope == 'Partial': score += 15
if biz_level == 'Core': score += 20
elif biz_level == 'Important': score += 10
if urgency == 'Minute': score += 30
elif urgency == 'Hour': score += 15
if score >= 90: return 'P0'
if score >= 70: return 'P1'
if score >= 40: return 'P2'
if score >= 20: return 'P3'
return 'P4'
分类后的收敛与降噪
优先级定出来后，还有个常见问题——同一条告警反复推送怎么办？
我的做法是三步：合并（相同根因在窗口期内只推一条）、抑制（比如主库挂后，从库只读告警和连接池告警都应该被主库告警抑制）、聚合（同一个服务节点的不同指标告警，聚合成一条服务健康告警）。
举个例子：某个微服务有 10 个实例，3 个实例返回 5xx。如果不聚合，你收到 3 条独立告警；聚合并抑制相同实例的后续告警后，只产生一条“服务 A 健康度下降”的 P1 告警，附带上故障实例列表。
整体流程框架
下面这张图展示了从告警产生到进入不同处理队列的完整路径。我建议在工单系统初始化时就把这些规则配置好，后面减少人工干预。
实践中要注意的坑
- 不要给告警打固定等级：比如把“磁盘使用率 > 95%”永远定为 P3。它在凌晨可能只是报告，但大促时磁盘 IO 吃紧就可能变成 P1。我建议把阈值关联到当前业务水位，动态调整优先级。
- 避免 P0 过多：如果每天有 30 条 P0，那 P0 就失去了意义。我建议把 P0 的门槛抬高——必须是“核心服务完全中断”或“用户数据不可恢复性丢失”。其他只能打 P1 或更低。
- 工单衰减策略：告警连续重复推送 3 次以上且没有人工确认，自动降级一级。我曾经被一个告警每 5 分钟推送一次，持续半小时，最后大家直接忽略了那条告警——后来真出问题了才发现。