3. 告警标准化：告警字段定义、告警级别划分、告警类型分类、告警去重策略
告警标准化，说白了就是给告警立规矩。没有规矩，不成方圆。我见过太多团队，告警系统跑了一年，结果每天几千条告警，运维兄弟根本看不过来。为什么？因为告警字段不统一，级别乱分，类型混在一起，重复告警刷屏。嗯，今天我们就来聊聊怎么把这些事理顺。
核心观点：告警标准化的目标只有一个——让每一条告警都具备可操作性。运维人员看到告警，能立刻知道「这是什么问题？严重吗？该找谁？」
3.1 告警字段定义：统一语言，消除歧义
我个人习惯，先定义好告警的「身份证」。每条告警必须包含以下核心字段，缺一不可。
| 字段名 | 说明 | 示例 |
|---|---|---|
| 告警ID | 全局唯一标识，用于去重和追踪 | AL202503211432001 |
| 告警标题 | 一句话概括问题，不超过30字 | MySQL主库连接数超阈值 |
| 告警级别 | P0/P1/P2/P3，定义见下节 | P1 |
| 告警类型 | 基础设施/应用/业务/安全 | 基础设施 |
| 发生时间 | 精确到毫秒的时间戳 | 2025-03-21 14:32:00.123 |
| 告警源 | 产生告警的系统或组件 | Prometheus / Zabbix |
| 告警对象 | 具体的主机名、服务名或实例ID | db-master-01 |
| 当前值 | 触发告警时的指标数值 | 连接数: 850 |
| 阈值 | 配置的告警阈值 | 连接数 > 500 |
| 告警详情 | 补充信息，如日志片段、堆栈信息 | 详见附件 |
| 关联工单ID | 联动运维工单时填充 | WO20250321001 |
我在项目中遇到过，有些团队把告警标题写成「服务器异常」，这等于没写。你想想看，运维看到这条告警，还得点进去看详情才知道是哪台服务器、什么问题。所以，我建议标题必须包含「对象+问题+指标」，比如「db-master-01 MySQL连接数超过阈值(850/500)」。这样一眼就能定位。
小技巧：告警ID的生成规则建议用「AL + 日期 + 流水号」，方便按时间排序和检索。别用UUID，运维人员记不住，也不方便口头沟通。
3.2 告警级别划分：别让P0和P3混在一起
告警级别，我见过最乱的就是这个。有的团队把「磁盘使用率80%」定为P0，有的团队把「服务完全不可用」定为P2。这会导致什么？真正严重的告警被淹没在大量低级别告警里。
我个人习惯，采用四级划分法：
- P0（紧急）：核心业务完全不可用，需要立即响应。比如支付服务挂了、数据库主库宕机。响应时间：5分钟内。
- P1（严重）：核心功能受损，但还有降级方案。比如某个API接口超时率超过50%。响应时间：15分钟内。
- P2（警告）：非核心功能异常，或资源即将耗尽。比如磁盘使用率超过85%。响应时间：1小时内。
- P3（通知）：不影响业务，但需要关注。比如某个服务的内存使用率周期性波动。响应时间：24小时内。
这里有个坑，我曾经踩过。有一次，我把「某个非核心服务的CPU使用率超过90%」定为了P1，结果运维半夜被叫起来，一看是个测试环境的老服务。从那以后，我加了一条规则：告警级别必须结合「业务影响」和「环境」两个维度。生产环境的P0，在测试环境可能只是P2。
注意：别把告警级别定得太死。我建议每个季度复盘一次，看看哪些P0告警其实可以降级，哪些P3告警其实应该升级。动态调整，才能保持告警的有效性。
3.3 告警类型分类：分门别类，快速分流
告警类型，说白了就是给告警打标签。运维人员看到标签，就知道该找哪个团队、用什么工具处理。
我一般分成四大类：
- 基础设施告警：服务器、网络、存储、机房等。比如CPU高、磁盘满、网络延迟大。
- 应用告警：中间件、数据库、微服务等。比如MySQL慢查询、Redis连接失败、Nginx 5xx错误。
- 业务告警：直接与业务指标相关。比如订单失败率上升、支付成功率下降、用户登录超时。
- 安全告警：入侵检测、漏洞扫描、异常登录等。比如SSH暴力破解、Webshell上传。
你想想看，如果一条告警是「基础设施」类型，那直接转给基础设施团队处理。如果是「业务告警」，那需要业务研发介入。这样分类，告警的流转效率能提升一大截。
我记得有一次，一个团队把所有告警都归为「其他」类型，结果每次告警来了，都要人工判断该找谁。后来我帮他们重新分类，配合自动化路由，告警处理时间从平均30分钟降到了8分钟。
建议：每个大类下可以再细分二级分类。比如「基础设施」下分「计算」「存储」「网络」。但别超过三级，否则分类本身就成了负担。
3.4 告警去重策略：别让告警刷屏
告警去重，是运维最头疼的问题之一。我见过最夸张的案例：一台服务器磁盘满了，结果触发了1000多条告警——因为每个监控项都在报错。运维手机直接被打爆。
去重策略，我总结了几种常用方法：
- 时间窗口去重：同一个告警源、同一个告警类型，在5分钟内只发一条。后续的告警合并到这条里，更新「告警次数」字段。
- 相似度去重：基于告警标题或详情做文本相似度计算。比如「db-master-01 连接超时」和「db-master-01 连接失败」，相似度超过90%，合并为一条。
- 因果去重：如果A告警是B告警的根因，只保留A。比如「网络交换机宕机」导致「100台服务器不可达」，只发交换机告警。
- 聚合去重：把同一类告警聚合成一条。比如「10台服务器CPU超过90%」，聚合为一条「集群CPU高负载告警」。
我个人最推荐「时间窗口+因果去重」的组合。先通过时间窗口把短时间内的重复告警合并，再通过因果分析去掉衍生告警。这样既能减少告警量，又不丢失关键信息。
我曾经踩过一个坑：去重策略太激进，把P0告警也合并了。结果运维没看到单独的告警，以为没问题，导致故障处理延迟了20分钟。所以，P0告警不要做去重，必须逐条通知。
经验之谈：去重策略上线后，一定要观察一周。看看告警量是否真的降下来了，有没有误合并的情况。我一般会设置一个「去重日志」表，记录每次合并的原始告警，方便回溯。
3.5 知识体系总览
下面这张图，是我对告警标准化的整体理解。你可以把它当作一个检查清单，看看自己的团队做到了哪一步。
告警标准化不是一蹴而就的事。我建议先从字段定义和级别划分入手，这两步做扎实了，后面的分类和去重才能落地。别想着一步到位，先跑起来，再迭代优化。
最后说一句：告警标准化的最终目的，不是减少告警数量，而是提升告警质量。100条高质量的告警，比1000条垃圾告警更有价值。你想想看，是不是这个理？
公众号:蓝海资料掘金营，微信deep3321