告警系统基础：告警概念、告警级别、告警生命周期
好，咱们直接进入正题。这一章要把告警系统的基础打牢。你想想看，没有扎实的地基，后面设计告警规则就像在沙子上建房子。我个人习惯先把概念理清楚，再谈实践。
什么是告警？
告警，说白了就是系统告诉你——「出事了，你来看看」。它不是一个日志条目，也不是一封群发邮件。告警的核心是主动通知，而且带有明确的行动意图。
我在项目中遇到过一件有意思的事：有个同事把所有的 error 日志都配成了告警，结果一天收几万条，最后直接屏蔽了告警通道。这其实不是告警，是日志洪水。告警必须满足三个要素：
- 检测到异常 —— 比如审计日志中出现「连续5次登录失败」
- 有明确的告警对象 —— 哪个用户、哪个系统、哪个 IP
- 需要人工响应 —— 要么确认，要么处理，要么忽略（但要留痕）
我的经验： 一个合格的告警，应该让人在 30 秒内看懂「发生了什么」「严重程度」「谁来处理」。写不清楚的告警标题，等同于没告警。
告警级别：别把小事和灾难混在一起
告警级别不是拍脑袋定的。我记得刚入行时，总想着把所有异常都标成「严重」，结果真正出大事的时候反而没人重视了。这叫「告警疲劳」。
我建议采用四个级别，够用且清晰：
| 级别 | 标签 | 典型场景（审计日志类） | 响应时间要求 |
|---|---|---|---|
| P0 | 紧急 | 管理员账号被暴力破解成功、核心数据被导出 | 15 分钟内 |
| P1 | 严重 | 连续 10 次登录失败来自陌生 IP、敏感权限异常提升 | 30 分钟内 |
| P2 | 警告 | 单用户多次尝试访问未授权资源、非工作时间登录 | 2 小时内 |
| P3 | 提示 | 审计日志记录异常格式、配置变更未复核 | 下一个工作日 |
你可能会问：为什么 P0 和 P1 要用那么短的时间？因为审计日志告警往往涉及合规与安全，晚一分钟都可能造成实际损失。我在一家金融科技公司时，就是因为 P0 告警响应延迟，导致入侵者多拿了 6 分钟的数据库权限。嗯，后来我们连夜改了规则。
注意： 不要为了「显得重要」把 P2 升级成 P1。我曾经见过一个团队，把「磁盘使用率 80%」标为 P1，结果真正的安全告警被淹没了。级别要和影响挂钩，不是和运维人员的焦虑挂钩。
告警生命周期：从出生到死亡
每一个告警都不是孤立的事件。它从产生、通知、确认、处理到关闭，有一条完整的生命线。理解这个生命周期，比背概念重要得多。
我解释一下这张图里的关键节点：
- 触发（Trigger） —— 告警规则引擎检测到审计日志中的异常。比如一条「root 用户凌晨 3 点登录」的记录命中了规则。
- 通知（Notify） —— 系统将告警推送到值班人员。这里要注意：通知不等于确认。很多人收到告警就以为是处理了，其实只是第一步。
- 确认（Acknowledge） —— 值班人员阅读告警内容，判断是否需要介入。如果明显是误报（比如测试流量触发的），可以直接跳到「关闭」，避免浪费精力。
- 处理（Handle） —— 实际调查、修复、临时止血。对审计告警来说，可能是禁用被破解的账号、回滚异常权限等。
- 关闭（Close） —— 解决问题后关闭告警。保留处理记录，形成闭环。不能只关不记，否则审计回溯时就找不到原因了。
关键点： 告警生命周期里最容易出问题的是「确认」阶段。我在一家电商公司看到，告警产生后无人确认，一直超时自动升级，最后变成了 P0 告警轰炸。最好的做法是：每个告警设置确认超时时间（比如 10 分钟），超时自动升级或通知备用联系人。
实践中你还需要知道的
嗯，这里补充几个我踩过的坑：
- 不要用「确认」代替「处理」 —— 有些人收到告警点一下「已确认」就当结束了。实际上确认只是认领，处理才是真干活。
- 告警关闭前要留处理说明 —— 我曾经因为没写说明，三个月后追溯一个安全事件时，根本不知道当时为什么关了告警。后来我们强制要求关闭前必须填写处理结论，哪怕只是「误报，已忽略」。
- 生命周期状态要可回溯 —— 把每个告警的触发时间、确认人、处理人、关闭时间处理到数据库里。审计日志告警本身也需要被审计。