网站可用性监控的不同之处

去年双十一凌晨，某电商平台的可用控运维团队盯着监控大屏——所有服务器指标正常，CPU、性监内存、不同带宽全绿。网站但订单量突然断崖式下跌。可用控排查了四十分钟才发现，性监第三方支付网关的不同HTTPS证书过期了，浏览器直接拦截了跳转。网站服务器没问题，可用控用户却根本付不了款。性监这件事暴露了一个老问题：可用性监控和“服务器监控”压根不是不同一回事。

大多数团队用的网站Zabbix、Prometheus，可用控本质是性监资源监控。它们关心CPU有没有跑满、磁盘I/O是否异常、进程还活着没。这类工具擅长回答“机器累不累”，但回答不了“用户能不能用”。我见过一个内部系统，后端API响应时间稳定在200ms，可用性报表100%。可前端页面加载了一个来自CDN的JS文件，那个CDN节点在某个省份被污染了，当地用户打开页面就是白屏。后端监控毫无感知。

这就是可用性监控的第一个分水岭：模拟用户视角，还是观测系统内部。Pingdom、UptimeRobot这类工具，从全球多个节点发起真实HTTP请求，检查状态码、响应内容、加载时间。它们模拟的是“一个普通用户点击链接后会发生什么”。而Zabbix们站在服务器里往外看。两者互补，但绝不等价。

第二个不同在于监控的粒度。资源监控通常按分钟级采集，因为CPU飙高持续30秒可能只是正常波动。但可用性监控必须更细。一个电商详情页，如果图片加载超过3秒，40%的用户会直接关掉。这种“慢”在服务器指标上完全看不出来——CPU才20%，带宽也没跑满。可用性监控得盯着首字节时间、DOM就绪时间、完整加载时间。差几百毫秒，转化率就掉一截。

有个做SaaS的朋友跟我吐槽，他们用某知名监控服务，每5分钟发一次请求。结果一次持续4分50秒的数据库连接池耗尽，被完美漏掉。用户投诉了才知道。后来他们把关键路径的检查频率调到15秒一次。频率本身就是成本，但漏报的代价更高。

第三个容易被忽略的差异是监控点的位置。你在阿里云北京区部署监控，只能看到北京区用户的情况。但你的用户可能在成都用电信、在广州用移动、在纽约用Comcast。不同运营商、不同地域的DNS解析、路由跳转、CDN回源策略都不一样。我见过一个案例：网站主站可用性99.99%，但电信用户访问时，某个中间节点对特定User-Agent做了限速，导致电信用户加载时间暴涨到8秒。只有多节点分布式监控才能抓到这种问题。

还有内容校验。很多基础监控只检查HTTP 200。但200不代表正确。一个返回“系统维护中”的页面也是200。一个登录接口返回了“用户名或密码错误”的JSON，状态码也是200。可用性监控得能匹配响应体里的关键字，或者校验JSON字段。否则你监控了个寂寞。

最后说个反直觉的点：可用性监控不是越灵敏越好。有个团队把超时阈值设成1秒，结果每天收到几百条告警——全是CDN边缘节点的正常抖动。工程师开始忽略告警，直到真正的大故障被淹没。后来他们改成：连续3次失败才告警，且不同地域节点分别判断。误报率降了90%，真正的故障反而抓得更准。

（写完这段我去查了下自己博客的监控记录：过去30天，可用性99.87%，但有一次持续2分钟的502，发生在凌晨3点。监控报了，我在睡觉。所以可用性监控的最后一公里，其实是告警路由和值班机制。工具再好，没人看也是白搭。）

所以下次有人跟你说“我们监控很全”，先问一句：你监控的是服务器，还是用户眼里的网站？这两件事，隔着一整个互联网。