3. 告警生命周期：从产生到关闭的五个关键阶段

告警从产生到关闭，就像一趟完整的旅程。每个环节处理不好，都可能让你半夜爬起来白忙一场。我刚开始做SRE那会儿，收到告警就急着操作，跳过确认直接处理，结果好几次都是误报，白白折腾一两个小时。后来才明白，老老实实走完这五个阶段，才是靠谱的。说白了，这是个闭环——少一步都不行。

3.1 产生阶段：源头决定后续一切

告警不会凭空冒出来。它背后一定有规则、阈值、聚合逻辑在起作用。比如CPU使用率超过90%持续5分钟，或者错误日志出现某个关键字，就会触发一条告警。这个阶段最关键的是：规则要准、粒度要对。

举个实际例子——我曾经遇到过一个大流量入口集群，日志量突然翻了100倍，结果告警规则是按「单位时间内错误日志条数」设的固定阈值，直接触发了告警风暴，一晚上收到了8000多条。后来发现是上游的一个配置写错了，根本不是真实故障。从那以后，我们给所有产生阶段加了流量基线的动态阈值，才消停下来。

3.2 通知阶段：让正确的人及时收到

告警产生之后，下一步就是通知到人。通知渠道有很多种：邮件、短信、电话、IM（飞书、钉钉、Slack）。但你不能一股脑全发出去，得考虑优先级和责任人。

• P0/P1 告警——必须电话+短信+IM三管齐下，并且要找到值班人。
• P2/P3 告警——发到IM群聊就行，白天处理。
• 通知去重——同一条告警在短时间内重复触发，只发送一次提醒，防轰炸。

3.3 确认阶段：告别“已读不回”

告警发出去，人收到了，然后呢？很多人觉得「我看到了，知道了」就算完了。但在正式流程里，确认（Ack）是一个独立的动作。它的目的是：告诉系统「这条告警我接手了，其他人不用再管」。

常见做法是值班人员在告警管理平台上点一个「确认」按钮，系统自动带上处理人的姓名和时间。如果没有确认机制，很可能出现多人同时处理同一条告警，浪费资源，甚至踩到别人的操作。

嗯，这里要注意：确认不等于处理完毕。你只是告诉系统「我看到了，正在处理中」。很多平台还会设置自动确认——比如人工15分钟内没手动确认，系统自动把告警指派给下一级值班。我个人的习惯是：手动确认 + 自动兜底结合起来用，避免漏掉。

3.4 处理阶段：从响应到修复

确认之后，真正的活来了。处理阶段通常包含几步：

1. 诊断定位——查看指标、日志、链路追踪，找到根本原因。
2. 制定方案——回滚、重启、扩容、修改配置……选一条最快恢复的路。
3. 执行修复——按方案操作，注意验证每一步的效果。
4. 验证恢复——确认告警不再触发，业务恢复正常。

一个铁律：处理过程中，每一步都要记录。无论是用JIRA工单、Wiki还是评论区，都写清楚「什么时间、谁、做了什么、结果如何」。这不只是给别人看，也是给你自己以后复盘用的。我记得有一次处理一个内存泄漏的告警，临时加了个JVM参数顶住了。当时没记录参数值，三个月后同样的故障发生，大家都忘了上次怎么修的……那次之后，我们强制要求处理阶段必须有操作日志。

3.5 关闭阶段：闭环的最后一公里

告警处理完了，业务恢复了，屏幕不红了，你以为就结束了？不，还差最后一步——关闭（Close）。

关闭告警需要满足两个条件：

• 告警的触发条件已经消失（比如CPU降回正常值）。
• 系统确认真正修复了，不会很快再次触发。

我有一次犯过错误：看到告警不再弹了，就直接点击关闭。结果半小时后同一台机器又告警了——因为我之前的操作只是临时重启了进程，根因（配置错误）没修。所以现在我建议：关闭之前，一定要看一眼告警的持续时间和恢复趋势。如果恢复后指标一直平稳，再关闭。

关闭后，还可以自动触发一条「事后分析」任务，生成这起告警的完整时间线。方便团队做故障复盘。

一张图看懂告警生命周期

下面这个SVG把五个阶段串起来了。你可以看到每个阶段的输入、输出和流程方向。建议保存下来，贴在值班手册里。

各阶段对照清单