2. 告警生命周期：全流程管理

大家好，我是老赵。这一章我们来聊聊告警的“一生”。很多团队只关心告警怎么发、发给谁，却忽略了告警从出生到消亡的完整路径。说白了，没有生命周期管理的告警系统，就是一个只会嗷嗷叫的“熊孩子”。

我见过不少团队，告警发出来没人管，最后变成“狼来了”，运维直接免疫。所以，管好告警的每个阶段，比设计规则本身更重要。

2.1 为什么需要生命周期？

告警不是孤立的事件。它是一连串的 状态迁移。一个告警从产生到最终归档，至少要经历六个阶段。每个阶段都有明确的责任人和动作。

我在项目中遇到过一套监控系统，一天发几万条告警，却没有“已确认”状态。结果所有人都在猜：“这个告警有人看了吗？” —— 这就是生命周期缺失的典型后果。

2.2 六个关键阶段

咱们一个一个来看。你可以把告警想象成一个工单，它有自己的“生涯规划”。

阶段	英文名称	核心动作	责任人
1. 产生	Generated	监控指标/日志匹配到规则	监控系统
2. 触发	Triggered	满足条件，生成告警实例	告警引擎
3. 通知	Notified	通过渠道送达目标人	通知路由
4. 确认	Acknowledged	值班人认领，避免重复处理	运维值班
5. 解决	Resolved	故障恢复或手动关闭	处理人
6. 归档	Archived	数据入库，不可再修改	系统自动

2.3 全流程详解

阶段一：告警产生 (Generated)

这是告警的“初生”。监控系统采集到一个异常数据点。比如，CPU 使用率超过了 90%。

但注意：告警不等于故障。它只是一个信号。我经常跟团队说：“告警是问你‘有没有问题？’，而不是告诉你‘出大事了’。”

• 关键点： 数据源要准确，避免“抖动”导致的无效告警。
• 避坑： 不要因为数据延迟一秒就放弃采样。我见过因为采样间隔太长，错过了瞬时的流量洪峰。

阶段二：告警触发 (Triggered)

满足规则阈值后，系统创建一个告警实例。这个实例有唯一的 ID、严重级别、开始时间。

说白了，这是告警的“身份认证”阶段。规则引擎会做两件事：

1. 去重： 同一时间、同一主机、同一指标，只生成一条。
2. 分派： 根据规则归属，决定丢给哪个 team 或哪个值班窗口。

阶段三：通知 (Notified)

告警必须“喊出来”才有价值。这一步涉及通道选择、升级策略和通知频率。

实际中，我把通知分为三个等级：

• P0/P1： 电话 + 短信 + 即时消息，通知值班人。
• P2/P3： 即时消息 + 邮件，通知群组。
• P4： 仅邮件或工单，甚至不主动通知。

我在项目中遇到过一个问题：某个 P0 告警 10 分钟没人响应。后来我加了“升级通知”——5 分钟没确认，自动转给第二责任人。

阶段四：确认 (Acknowledged)

这是整个生命周期里最容易被忽略的一环。确认不代表解决了问题，只代表“我看到了，正在处理”。

很多新手会问：“为什么要有确认？直接去修不就完了？” 其实不然。如果没有确认：

• 两个人可能同时处理同一个告警，造成资源浪费。
• 告警系统不知道“有人接手”，会持续轰炸所有人。

阶段五：解决 (Resolved)

通常有两种方式：

1. 自动解决： 监控指标恢复后，系统自动将告警标记为 Resolved。
2. 手动解决： 运维人员修复后，手动关闭。

我倾向于混合模式。对于能自动恢复的指标（如 CPU 突刺），让系统自动解决。对于复杂故障（如磁盘坏道），必须手动确认。

阶段六：归档 (Archived)

这是告警的“终局”。归档后的告警，不能再修改状态，也不参与任何路由计算。它变成了“历史记录”，供后期复盘使用。

说白了，归档就是给告警“盖棺定论”。归档的数据要保留至少 30 天（法规要求长的可能 180 天）。

2.4 生命周期流程图

下面这张图，我把整个流程串了起来。你可以把它当作告警管理的“行动地图”。

2.5 各阶段状态对照表

搞清楚每个阶段的状态变化，才能写好代码或配置。下面这张表，你拿去可以直接参照设计数据库字段。

阶段	状态值	可迁移至	触发条件
1. 产生	generated	triggered	规则匹配 & 去重通过
2. 触发	triggered	notified, acknowledged, resolved	实例化成功，进入通知队列
3. 通知	notified	acknowledged, triggered(重试)	消息递送完成
4. 确认	acknowledged	resolved	值班人点击确认
5. 解决	resolved	archived	指标恢复 / 手动关闭
6. 归档	archived	(终态)	解决后延时自动归档

2.6 实战避坑指南

最后，我结合自己踩过的坑，给你三个小提示：