网站报警

凌晨三点，网站报手机突然响了。网站报不是网站报来电，是网站报短信——阿里云发来的：“您的服务器CPU使用率持续超过95%，请及时处理。网站报”我翻了个身，网站报心想又是网站报哪个爬虫在作妖。打开电脑一看，网站报监控图表红得发紫，网站报流量曲线像心电图一样往上窜。网站报这不是网站报爬虫，这是网站报有人在刷接口。

很多人以为网站报警就是网站报服务器挂了才响。错。网站报真正有用的网站报报警，是在用户还没感觉到卡之前就响。我见过太多团队，报警阈值设得跟闹钟似的——非得等到网站打不开、数据库连接池爆了才发通知。那会儿用户早跑光了，再修也是马后炮。

我自己的做法是分三层。第一层是硬件层，CPU、内存、磁盘IO，这些指标超过基线值20%就触发。第二层是应用层，接口响应时间超过500毫秒、错误率超过1%，马上告警。第三层最容易被忽略——业务层。比如支付成功率突然掉两个百分点，或者新用户注册量半小时内归零。这类报警不依赖技术指标，但往往比服务器宕机更致命。

去年有个做电商的朋友找我。他的网站平时好好的，就是每天下午四点左右会卡几分钟。报警从来没响过，因为那几分钟里CPU和内存都正常。我让他加了一个业务报警：监控“加入购物车”这个动作的失败率。结果第二天就抓到了——每天四点，有个定时任务在跑全表扫描，把数据库连接占满了。购物车请求排队超时，用户点一次没反应，点两次就烦了，直接关页面走人。技术指标看不出来的问题，业务指标一抓一个准。

报警发到哪里也很关键。别什么都往微信群里扔。我见过一个团队，报警群一天几百条消息，最后所有人都把群静音了。真出事的时候，没人看。我的做法是分级：P0级别的直接打电话，P1发短信加钉钉，P2只发邮件。P0的定义很简单——核心功能不可用，或者钱收不进来。其他的一律降级。

还有一点，报警要带上下文。光说“CPU 95%”没用，得告诉值班的人：哪台机器、哪个进程、最近五分钟有没有发过版、有没有定时任务在跑。我习惯在报警消息里附一条命令，值班的人复制粘贴就能看到现场快照。别让人半夜爬起来还要先登录跳板机查半天，那会儿脑子都是糊的。

最容易被忽视的是报警的“噪音治理”。每加一条报警，都要问自己：这条报警响了，我会做什么？如果答案是“什么都不做，等它自己好”，那就别加。我每个月会花半小时翻一遍报警记录，把那些连续三个月都没触发过的、或者触发了但没人处理的规则删掉。报警系统跟衣柜一样，不清理就会越来越乱，最后你想找那件真正重要的衣服，翻半天翻不到。

说到底，网站报警不是技术问题，是判断力问题。你得知道什么算“不正常”，什么算“正常但可以忍”。阈值设太松，出事了你不知道；设太紧，天天被吵醒，最后麻木了。这个平衡点没有标准答案，得靠对自己业务的熟悉程度去调。我调了三年，现在半夜被叫醒的次数，一只手数得过来。每次响，都是真有事。