一、告警体系概述

聊告警之前，我先问个问题：你每天会收到多少条告警？

我在一家中型互联网公司做运维那会儿，早上一打开钉钉，好家伙，500多条未读告警。说实话，当时我第一反应不是去处理，而是把群消息屏蔽了。这其实是个很危险的信号——告警太多，等于没有告警。

1.1 什么是告警

告警，说白了就是系统在喊「救命」。它不是一个简单的通知，而是系统状态异常时主动发出的信号。我个人习惯把告警分成两类：

• 指标告警：CPU超过90%、内存不足、磁盘快满了
• 事件告警：服务挂了、数据库连接失败、证书过期

嗯，这里要注意：不是所有异常都需要告警。我在项目中遇到过开发同学把「用户登录失败」也配成告警，结果一天告警量直接破万。你想想看，用户输错密码是正常业务逻辑，跟系统故障有啥关系？

1.2 告警的生命周期

一个告警从出生到死亡，大概经历这么几个阶段。我画了张图，你一看就明白：

这张图我解释一下：

1. 触发：监控系统发现指标异常，生成告警。我记得有一次半夜三点，磁盘告警触发了，结果是因为日志没做轮转。
2. 确认：值班人员看到告警，点一下「我收到了」。这一步很关键，不确认就等于没人管。
3. 处理中：开始排查问题。我建议这个阶段要更新处理状态，不然别人不知道你在搞。
4. 升级：如果超时没人处理，或者处理不了，自动升级给更高级的工程师。我曾经被升级过，那感觉，嗯，不太好。
5. 关闭：问题解决，告警关闭。注意，关闭不等于完事，后面还要复盘。

1.3 告警的等级划分

告警等级怎么分？说白了就是看「这问题不解决，公司会损失多少钱」。我见过很多团队把等级分得特别细，P0到P5六个级别，结果没人记得住区别。我个人习惯只分四级：

你可能会问：P0和P1到底怎么区分？我举个例子：

• 如果线上所有用户都下不了单，这是P0
• 如果只有某个地区的用户下单慢，这是P1
• 如果下单功能正常，但后台报表生成慢了，这是P2

1.4 告警处理的核心目标

说了这么多，告警处理到底为了啥？我总结了三句话：

• 减少MTTR（平均修复时间）：从告警触发到问题解决，时间越短越好。我见过最快的记录是30秒——自动恢复脚本直接搞定了。
• 降低误报率：告警太多，人会疲劳。我建议把误报率控制在5%以下，超过这个数就得优化规则了。
• 防止重复告警：同一个问题，发一次就够了。我曾经遇到过一台机器磁盘满了，结果每5分钟发一次告警，一晚上发了200多条。

说白了，告警处理的终极目标就一个：让该响应的告警被及时响应，让不该响应的告警压根别出现。

嗯，这一章的内容就这些。告警体系是运维自动化的基石，搞不明白这个，后面谈什么自动化处理都是空中楼阁。下一章我们聊聊告警源的接入和标准化，到时候我会分享一些我在对接Prometheus和Zabbix时踩过的坑。