第1章 告警基础概念
1.1 什么是告警
告警，说白了就是系统抛给你的一个信号——「出问题了，快来处理」。这个信号可以是数字的、文本的，甚至是红灯闪烁的。我刚开始做运维时，觉得告警就是邮箱里那堆红色邮件，没什么稀奇的。后来踩过几次深夜被叫起来的坑，才明白告警远不止「通知」那么简单。
从技术角度说，告警是监控系统发现异常后，通过某种渠道（短信、电话、IM、邮件）触达人的消息。它的核心价值是：在故障变成灾难之前，给你一个反应窗口。你想想看，如果没有告警，你只能等用户投诉才知道系统挂了——那口碑就完了。
1.2 告警的分类
实际工作中，告警类型五花八门。我习惯按关注层次分三类：基础设施、应用、业务。这三类人的视角不同，处理方式也完全不同。
| 分类 | 关注什么 | 典型例子 | 谁在看 |
|---|---|---|---|
| 基础设施告警 | 硬件、网络、系统层 | CPU 100%、磁盘 IO 延迟高、交换机端口 down | 系统运维、IDC 运维 |
| 应用告警 | 服务进程、中间件、代码异常 | Java OOM、Nginx 502、数据库连接池耗尽 | 应用运维、开发工程师 |
| 业务告警 | 用户行为、交易指标、KPI | 支付成功率下降 10%、登录失败率暴增、订单超时率飙升 | 业务运维、产品经理 |
我第一次带团队时，把所有告警都塞一个群里，结果半夜全是「CPU 高了 1%」这种垃圾消息。真正重要的业务告警反而被淹没了。后来我逼着自己做了分类，每种告警定义清晰的负责人和响应时效。嗯，这个坑现在回想起来，犯得值。
基础设施告警
这类告警最直观，也最容易误报。比如物理机风扇转速异常，有时只是监控采样周期太短导致的瞬态。我建议给基础设施告警加「持续 N 分钟」的阈值，别一冒尖就报警。
应用告警
应用层告警往往是连锁反应的源头。举个例：数据库连接池满了 -> 应用线程阻塞 -> 接口超时 -> 前端白屏。如果你只看到应用告警，没追根溯源到数据库，那处理思路就偏了。
业务告警
这类告警最贴近管理层，但最难定义。你想想看，业务指标波动是常态，什么时候算告警？我通常靠历史基线 + 3σ 来算，比如支付成功率低于均值三个标准差才触发。曾经有个客户非要设成「成功率低于 99.99%」就报警，结果一天几百条，全是噪音。后来改成低于 99% 才报，清净多了。
1.3 告警的生命周期
每条告警从出生到死亡，都会经历几个阶段。我把它叫做告警的生命周期。理解了这个，你才知道什么时候该升级、什么时候可以关掉。
完整的生命周期一般包括：
- 产生 – 监控系统检测到异常，生成一条告警记录。
- 确认 – 有人认领了这条告警，表示「我知道它存在了」。
- 处理 – 开始排查根因、修复问题。
- 恢复 – 问题消失，监控指标回到正常区间。
- 关闭 – 运维人员手动或自动关闭告警。
- （可选）升级 – 如果超时无人处理，告警会自动升级到更高层级。
下面这张图把生命周期串起来了，你可以对照自己的流程看看有没有缺项。
关于生命周期，有两点我想重点强调：
- 不要跳过「确认」：哪怕只是点一下按钮，也证明你看到了。这能避免多人重复投入。
- 「关闭」不等于「根因消除」：有时你只是临时恢复了服务，根本原因还在。我习惯在告警关闭时加一个字段「是否已彻底修复」，选「否」则自动生成一个故障单去跟踪。
嗯，基础概念就这么多。记住一句话：告警是手段，不是目的。别为了发告警而发告警，要为了快速恢复而设计它。