网站可用性监控电话

凌晨三点十七分，网站我的可用控电手机突然响了。屏幕上显示的性监是一个陌生号码，归属地是网站杭州。接起来，可用控电对面是性监值班工程师小周的声音：“王总，电商平台在杭州节点的网站响应时间已经超过8秒了，持续了大概五分钟。可用控电监控系统自动拨了你的性监电话。”

我一边穿衣服一边问：“支付接口呢？网站数据库连接池呢？”小周说都查了，不是可用控电内部问题。等我打开电脑连上VPN，性监才发现是网站CDN服务商在凌晨做了一次路由变更，导致华东地区的可用控电用户访问全部绕到了北京节点。如果那天晚上没有那通电话，性监等到早上八点上班才发现，损失的不只是几百万的GMV，还有用户对平台的信任。

做网站可用性监控的人，最怕的就是“静默故障”。服务器没宕机，进程还活着，但用户就是打不开页面。这种故障最阴险，它不会触发常规的告警，只会体现在用户的流失曲线上。我见过太多团队，白天一切正常，晚上悄悄挂掉，第二天上班才从客服那边听说“昨晚好像打不开”。

所以电话告警这件事，看起来简单，其实讲究很多。短信通知容易被手机系统拦截，邮件更是经常被扔进垃圾箱。只有电话，能真正把人从睡梦里拽起来。但电话也不能乱打——要是每次抖动都响铃，运维人员一周就得神经衰弱。

我认识一个做独立站的朋友，他用的监控工具是开源的，自己写了套告警逻辑。规则很粗暴：连续三次探测失败才打电话，每次电话间隔十五分钟。结果有一次，机房真的断电了，他老婆接的电话，迷迷糊糊说了句“他在洗澡”，然后挂了。等他从浴室出来看到未接来电，网站已经躺了四十分钟。后来他把规则改成：第一次电话响三声就挂，若没回拨，五分钟后再打——直到有人接为止。

另一个细节是，电话告警的内容不能太啰嗦。人半夜被吵醒，大脑是混沌的，你让他听一段六十秒的语音播报，他根本记不住。好的电话告警应该像对讲机一样简短：“XX网站，HTTP 503，持续五分钟，IP是1.2.3.4，重复三次。”说完就挂。清醒的人能记下，没醒透的人至少知道出了事。

还有一点常被忽略——监控电话的号码要固定。我见过有公司用随机号码外呼，结果被运维人员当成骚扰电话拉黑了。等到真出大事，电话打不进去，值班的人还在睡梦里。固定号码还有个好处，可以存进手机通讯录，备注成“网站告警”，这样半夜看到来电，心跳不会先漏一拍。

说到底，电话监控是最后一道防线。前面有邮件、短信、IM推送，层层过滤，能走到电话这一步的，一定是必须立刻处理的事故。别把它当成日常通知工具，那是狼来了的故事。我自己的习惯是，每次电话告警响完，处理完故障，一定会在第二天复盘：这条告警值不值得半夜打电话？如果只是短暂抖动，就把阈值调高；如果确实是严重故障，就想想为什么前面的预警没拦住。

现在很多云厂商都提供智能告警，能自动合并事件、抑制重复通知。但工具再聪明，也代替不了人判断“这个时间点，哪个故障需要立刻被叫醒”。凌晨的机房，风扇声嗡嗡的，监控大屏上的曲线在跳。那通电话响起来的时候，你知道，真正的问题出现了。接，还是不接，不取决于你困不困，而取决于你之前把告警规则设计得多合理。