告警分类：故障、性能、安全

告警一多，人就懵了。我见过不少运维新手，每天面对几百条告警，每条都当成大事处理，结果真正出问题时反而被淹没了。

其实分类就是给告警“贴标签”。把相似的放一起，你才能快速判断该不该重视。

为什么非要分类？

我个人习惯，新接手的系统第一件事就是理清告警类型。不分类，你根本没法做后续的预案和自动化处理。

举个例子，上次我处理一个电商平台事故，凌晨三点告警哗啦啦涌进来。如果没分类，我得一条条人工看——网络闪断、磁盘IO高、登录失败混在一起。但有了分类，一眼就能锁定是“性能类”的数据库响应超时，直接跑预设的应急脚本，十分钟搞定。

分类带来几个好处：

• 快速聚焦：同类问题处理逻辑相似，不用每次都重新分析
• 自动化前提：按类型写自动化规则，比如“安全类告警”自动隔离IP
• 趋势分析：统计某类告警数量变化，能提前发现系统隐患

三大核心分类

告警分类可以很细，但最基础也最常用的是三类：故障类、性能类、安全类。我习惯把它们称为告警的“三原色”。

故障类告警

说白了就是“系统罢工了”。服务挂了、进程退出、硬件损坏、网络不通——这些都属于故障类。特征很明显：非0即1，要么全好要么全坏。

性能类告警

系统还在跑，但“跑得慢”了。CPU使用率超90%、内存不足、磁盘IO等待长、接口响应延迟大——这些都是性能告警。它们通常有阈值，超过警戒线就触发。

性能告警比故障告警更考验经验。为什么呢？因为阈值设得太低，告警刷屏；设得太高，又可能错过真正的瓶颈。

安全类告警

这类告警关乎“你是谁、你在干什么”。比如登录失败次数过多、敏感文件被修改、防火墙拦截异常流量、Web应用检测到SQL注入尝试。安全告警的特点是：可能没有明显的性能或故障表现，但危害极大。

你想想看，一个服务器被攻击者控制，CPU内存都正常，但数据被你悄悄拖走了。所以安全类告警的研判逻辑往往更复杂，需要结合上下文。

告警类别	典型场景	响应优先级	典型处理方式
故障类	服务不可用、磁盘损坏、进程崩溃	P0/P1（最高）	自动重启、切换备份、立即上人
性能类	CPU过高、内存不足、延迟增大	P2/P3	自动扩容、限流、分析慢查询
安全类	暴力破解、恶意文件、异常登录	P1/P2	封禁IP、隔离主机、取证分析

其他分类维度

除了按“现象本质”分类，我还喜欢再切一个维度——按影响范围。同一个告警，影响1%用户还是100%用户，响应策略完全不同。

我个人习惯加上“影响范围”标签：

• 局部：单个实例、单台机器
• 区域：某个机房、某个可用区
• 全局：全站、所有用户

这样组合后，告警的“级别”就清楚多了。比如一个性能告警如果是“局部且非核心”，可以降级为P3，放在日常清单里观察。

分类方法：一个简单实用的框架

以下是我做新系统时常用的分类脚本（伪代码），你直接套用就行：

rule classify_alarm(event):
    if is_service_down(event):        return "fault"
    if is_hardware_fail(event):       return "fault"
    if is_timeout_or_high_latency():  return "performance"
    if is_resource_exhaustion():      return "performance"
    if is_unauthorized_access():      return "security"
    if is_attack_pattern():           return "security"
    else:                             return "other"

嗯，这里要注意：不要把所有“other”都忽略。我建议对“other”类也要设置一个人工审核队列，免得漏掉新出现的异常。

知识结构图

实践中的避坑指南

分类看起来简单，但做不好反而添乱。我总结几个常见问题：

• 分类太粗：只分“系统”和“业务”，结果系统告警还是几百条，等于没分。
• 分类太细：搞了二三十个类型，运维人员根本记不住，导致告警归属混乱。
• 缺少“其他”兜底：没有未分类的包容区，新出现的异常直接被丢弃。