一、告警概述：到底是什么，怎么分，怎么活

1.1 什么是告警？不只是“叮”一声

先说说我自己的理解。告警，说白了就是系统在喊救命。它告诉你：有个东西不正常了，你来管管。

但很多人把告警和日志、指标混为一谈。我见过不少团队，把“CPU用了80%”这种信息当告警发出去。结果呢？没人看。为啥？因为这不一定是需要人介入的“异常”。

我个人习惯把告警定义为：经过规则判断后，确认需要人为介入或自动处理的异常事件。它有三个要素：

• 可观测的信号 — 来自监控系统（Metrics、Logs、Traces）
• 明确的规则 — 什么情况下算异常（比如：错误率 > 5%）
• 触发后的动作 — 通知人的升级，还是机器人动手修

1.2 告警的分类：你别全往一个桶里扔

做了这么多年监控，我发现新手最容易犯的错：给所有告警同等对待。你想想看，线上挂了和磁盘快满了，处理优先级能一样吗？

我自己习惯从三个维度来划分告警。这能帮你决定谁能收到、要不要自动处理。

分类维度	类别	说明	处理建议
按严重程度	P0 - 灾难/宕机	核心服务不可用，数据丢失	分钟级响应，自动切换+紧急电话
	P1 - 严重	功能大面积受损，用户感知明显	需立即介入，自动降级或扩容
	P2 - 告警	单点故障、容量紧张、延迟升高	工作时间内处理，可自动修复
按来源	基础架构	CPU、内存、磁盘、网络	多数可直接自动恢复
	应用层	接口错误率、RTT、业务量	需要业务逻辑判断
	安全类	入侵检测、大量登录失败	联动安全响应，不能直接重启
按收敛方式	瞬时告警	突发尖峰、偶发超时	一般自动忽略，不直接触达人
	持续告警	资源耗尽、连接池占满	必须处理，否则引发雪崩

1.3 告警生命周期：一条告警的“生老病死”

一条告警不是简单地“来了 - 处理 - 关闭”。它有自己的生命周期。把生命周期搞清楚，你才能设计出靠谱的自动处置流程。

我通常把告警生命周期分成 6 个阶段：

1. 触发（Firing）：规则条件满足，告警正式诞生。但不要立刻通知人，我一般会加一段“评估期”，防止抖动。
2. 通知（Notifying）：确认告警有效，发送到钉钉/企微/PagerDuty。这个阶段注意限流，不然容易风暴。
3. 认领（Acknowledged）：有人接手了。这个状态很重要 — 没认领就要不断升级。
4. 处理中（In Progress）：人工或者自动脚本正在修复。
5. 恢复（Resolved）：触发条件已消失。但恢复不等于解决，有些恢复是暂时的。
6. 关闭（Closed）：根本原因查明，修复方案已上线，告警彻底结束。

嗯，这里要注意：很多系统把“恢复”当成终点，结果同样的根因不断触发新告警。我建议在“关闭”前加一步“根因确认”。

1.4 一张图讲清楚告警生命周期

下面这张 SVG 图，把整个生命周期的流转画出来了。你把它贴在监控大屏旁边，或者嵌入到告警 SOP 里，很直观。

1.5 生命周期管理：从“告警风暴”到“安静运维”

为什么要把生命周期搞得这么清楚？因为我吃过亏。有段时间我们一个集群的告警量飙到每小时 5000 条，全是同一波连接超时搞出来的。没有收敛、没有自动恢复、没有生命周期管理，所有人都被淹没了。

后来我引入了一套生命周期的状态流转规则，加上自动处置和抑制逻辑：

• 聚合：同一实体、同一规则、短期内只保留一条活跃告警，新触发作为“计数+1”
• 抑制：如果已有一个 P0 告警，低优先级关联告警自动静默
• 自动恢复：满足条件则转入“已恢复”，不需要人等半天