从“用户投诉才知道”到“出问题前自动告警”：告警系统演进之路

政策快报平台上线第一年，告警系统几乎不存在。

服务器挂了，等用户投诉才知道。爬虫停了，等用户说“怎么没有新政策”才发现。数据库慢了，等用户反馈“页面加载好慢”才去查。

那一年，有一个深夜，爬虫系统因某个网站改版卡死，停了6个小时，我们毫无察觉。第二天早上有用户发消息问“你们平台这两天更新是不是变慢了”，这才发现出问题了。

用户成了我们的“告警系统”。这种方式肯定不能再继续了。

后来我们用了一年多时间，逐步建起了一套完善的告警系统。现在任何异常，5分钟内就能收到通知。

告警系统的3个层次

第一层：基础设施告警（最早建立）

第一层，也是最早做的。监控服务器CPU、内存、磁盘、网络的基础指标，异常时发送告警。

这些指标可以解决大部分“系统挂了”的问题。只要服务器资源出了问题，能第一时间知道。

关键指标和阈值：

这套方案非常基础，但很实用。大部分“系统不可用”的问题，都能从这几个指标里找到根源。

第二层：应用层告警（中期建立）

基础设施层面的告警能告诉你“系统出问题了”，但不一定能告诉你“具体是什么问题”。应用层告警就是来解决这个问题的。

关键监控点：

• 接口响应时间：P99超过3秒告警。接口慢，可能是数据库慢查询、依赖服务超时、或者代码效率问题。告警触发后可以快速定位到具体接口。

• 错误率：超过1%告警。错误率突增，通常意味着代码有bug或者某个依赖服务挂了。结合日志可以定位到具体报错。

• 爬虫采集量：单日采集量低于正常值50%告警。这个很关键——爬虫可能还在运行，但某个信源改版了，数据采不回来。

• 用户访问量：比昨日同时段下降30%告警。流量突然下降，可能是服务不可用、CDN出问题、或者某个入口失效了。

第三层：业务告警（近期建立）

这是最高层，关注的是“用户体感”层面的异常。

• 首页加载时间：超过2秒告警。用户第一印象最重要，首页慢用户会直接走。这个指标直接反映用户实际体验。

• 搜索成功率：低于95%告警。搜索失败率高，说明搜索服务可能出了故障或索引出问题。这是用户最常用的功能之一，需要重点保障。

• 用户反馈量：负面反馈突增告警。用户说“查不到政策”“页面打不开”这类反馈数量突然增加，往往意味着某个环节出了问题。

告警系统的3个设计原则

原则一：告警要“可操作”。每条告警都应该明确告诉接收人“该做什么”。如果收到告警不知道该怎么办，这条告警就没有意义。

原则二：告警要分级。P0级（立即处理）和P2级（工作时间处理）要分开。不要半夜把P2告警发给所有人，否则真正重要的P0告警会被淹没。

原则三：告警要“会收敛”。同一个问题不要发100条告警。一个故障发一条就够了，说清楚“什么服务、什么问题、什么时间开始”。后续的重复告警自动合并，不要反复打扰。

结尾

最好的告警，是用户还没发现问题，你已经修复了。告警系统建设需要持续投入，但每投入一分，都能减少一分“半夜被吵醒”的概率。