告警标准化：统一是效率的基石

告警标准化这事儿，我最早其实是抗拒的。总觉得“反正我能看懂不就行了？”直到有一次，线上一个核心服务挂了，告警消息里写的却是 Connection pool exhausted - db1，值班同学看不懂是哪个库、什么影响、优先级多少——他愣是点了十分钟“忽略”。等真正的责任人看到时，业务已经停了五分钟。那次复盘会上，所有人盯着我：“为什么你们团队出的告警连个固定格式都没有？”

从那以后我才明白，告警标准化不是写文档给领导看，而是让你在凌晨三点被电话叫醒时，扫一眼就能知道：什么东西坏了、有多严重、我要找谁。今天就跟你聊聊我这些年踩坑后沉淀下来的四件事：格式规范、字段定义、严重级别、分类编码。

格式规范：别再让告警“长”得乱七八糟

你想想看，一个运维团队每天少说几百条告警。如果每条格式都不同——有的用JSON，有的用纯文本，有的甚至把时间戳写成2023-8-1 14:32这种不指定时区的格式——那自动化处理根本跑不起来。

我建议统一成结构化的键值对。最简单的做法是用key=value，或者干脆用JSON。但不管选哪种，顺序很重要：把最关键的字段放在前面。

一个反例：alarm: high cpu at 14:32 on server1——时间缺时区、服务器名不完整、没有级别。这种告警进了告警平台，没法自动分派、没法统计、没法关联。

字段定义：每个字段都有它的使命

格式定好了，字段也得统一。我记得有一次和基础设施团队合作，他们用的host字段，我们用的server字段，结果自动化脚本匹配不上。说白了，字段命名和定义必须有一本“字典”。

我列几个我认为最少要有的字段：

• alarm_id：全局唯一ID，方便去重和关联。可以是md5(source+time+type)。
• alarm_name：短的描述，如高CPU使用率，供告警规则名称使用。
• alarm_source：具体实例或进程名，必须能从CMDB查到。
• alarm_time：触发时间，精度到秒、带时区。
• severity：级别，用P1-P4或Critical-Warning-Info。
• status：当前状态，如firing、resolved、acknowledged。
• owner_team：负责团队，方便自动分派。
• description：详细原因，包含关键指标值。

严重级别：分清轻重缓急

级别定义得不好，整个告警流程就从“效率工具”变成“垃圾邮件”。我见过某个团队把磁盘使用率超过60%就打P1，结果全团队都被警报炸麻了，真正的P1来了反而没人看。

我习惯用四阶模型：

这里有个关键：级别必须和业务影响挂钩。不能用单纯的CPU 80%来定级，而要看“CPU 80%是否导致请求超时”。我个人建议每条告警规则都加上一个 impact 字段描述影响范围，否则级别就成了摆设。

分类编码：给告警报“户口”

分类编码的价值在于：当你需要统计“这周数据库相关告警有多少”时，不用翻几百条告警描述去猜。一个好的编码能直接告诉你是哪个模块、什么故障。

我推荐的结构是：[业务域]-[子系统]-[故障类型]-[序号]，例如：

分类编码还能和自动化脚本绑定：比如收到DB-POOL-001，自动触发连接数采集和阈值调整。不过要注意，编码不要超过三段，太长没人能记住。

总结一下：格式规范让你能解析，字段定义让你能理解，严重级别让你能判断，分类编码让你能分析。这四个东西搭起来，你的告警系统才算有了“语言”。

如果你现在的告警平台还是一片混乱，别急着上AI分析、上自动修复。先从标准化开始——你想想看，基础不牢，再高级的工具也白搭。