政策快报平台上线第一年，告警系统几乎不存在。
服务器挂了，等用户投诉才知道。爬虫停了，等用户说“怎么没有新政策”才发现。数据库慢了，等用户反馈“页面加载好慢”才去查。
那一年，有一个深夜，爬虫系统因某个网站改版卡死，停了6个小时，我们毫无察觉。第二天早上有用户发消息问“你们平台这两天更新是不是变慢了”，这才发现出问题了。
用户成了我们的“告警系统”。这种方式肯定不能再继续了。
后来我们用了一年多时间，逐步建起了一套完善的告警系统。现在任何异常，5分钟内就能收到通知。
告警系统的3个层次
第一层：基础设施告警（最早建立）
第一层，也是最早做的。监控服务器CPU、内存、磁盘、网络的基础指标，异常时发送告警。
这些指标可以解决大部分“系统挂了”的问题。只要服务器资源出了问题，能第一时间知道。
关键指标和阈值：
| 指标 | 告警阈值 | 说明 |
|---|---|---|
| CPU使用率 | 持续5分钟>80% | 可能被爬虫占满或代码死循环 |
| 内存使用率 | 持续5分钟>85% | 可能内存泄漏 |
| 磁盘使用率 | >85% | 日志太多或数据增长过快 |
| 磁盘IO等待 | >50ms | 可能磁盘性能瓶颈 |
| 网络带宽 | >80%峰值 | 可能被攻击或异常流量 |
这套方案非常基础，但很实用。大部分“系统不可用”的问题，都能从这几个指标里找到根源。
第二层：应用层告警（中期建立）
基础设施层面的告警能告诉你“系统出问题了”，但不一定能告诉你“具体是什么问题”。应用层告警就是来解决这个问题的。
关键监控点：
接口响应时间：P99超过3秒告警。接口慢，可能是数据库慢查询、依赖服务超时、或者代码效率问题。告警触发后可以快速定位到具体接口。
错误率：超过1%告警。错误率突增，通常意味着代码有bug或者某个依赖服务挂了。结合日志可以定位到具体报错。
爬虫采集量：单日采集量低于正常值50%告警。这个很关键——爬虫可能还在运行，但某个信源改版了，数据采不回来。
用户访问量：比昨日同时段下降30%告警。流量突然下降，可能是服务不可用、CDN出问题、或者某个入口失效了。
第三层：业务告警（近期建立）
这是最高层，关注的是“用户体感”层面的异常。
首页加载时间：超过2秒告警。用户第一印象最重要，首页慢用户会直接走。这个指标直接反映用户实际体验。
搜索成功率：低于95%告警。搜索失败率高，说明搜索服务可能出了故障或索引出问题。这是用户最常用的功能之一，需要重点保障。
用户反馈量：负面反馈突增告警。用户说“查不到政策”“页面打不开”这类反馈数量突然增加，往往意味着某个环节出了问题。
告警系统的3个设计原则
原则一：告警要“可操作”。每条告警都应该明确告诉接收人“该做什么”。如果收到告警不知道该怎么办，这条告警就没有意义。
原则二：告警要分级。P0级（立即处理）和P2级（工作时间处理）要分开。不要半夜把P2告警发给所有人，否则真正重要的P0告警会被淹没。
原则三：告警要“会收敛”。同一个问题不要发100条告警。一个故障发一条就够了，说清楚“什么服务、什么问题、什么时间开始”。后续的重复告警自动合并，不要反复打扰。
结尾
最好的告警，是用户还没发现问题，你已经修复了。告警系统建设需要持续投入，但每投入一分，都能减少一分“半夜被吵醒”的概率。