怎么看网站可用性监控

半夜两点十七分，看网我的用性手机震了。不是监控闹钟，是看网监控告警——电商网站下单接口响应时间飙到四千毫秒。爬起来开电脑，用性登录后台一看，监控CPU没爆、看网带宽没满、用性数据库连接数正常。监控但页面就是看网卡成PPT。最后查出来是用性第三方物流查询API超时，拖垮了整个下单流程。监控那个晚上我抽了半包烟，看网也记住了一个道理：网站可用性监控，用性监控的监控不是网站，是用户的耐心。

很多人以为可用性监控就是拿个工具ping一下，通就绿，不通就红。太天真了。真正的可用性是个复合指标——DNS解析要快、TCP握手要顺、SSL证书别过期、首字节别磨蹭、DOM解析别卡壳、资源加载别掉链子。任何一个环节出问题，用户看到的都是白屏。你ping通了又怎样？页面渲染不出来，用户照样骂娘。我见过最离谱的案例，某个网站监控显示200状态码，但页面内容是空的——后端服务返回了空壳HTML，前端JavaScript全部加载失败。监控面板上一片绿，用户那边全在摔手机。

监控工具倒是不少。商业的有听云、博睿，开源的Prometheus加Grafana也能凑合。但工具只是拐杖，关键看你怎么设计监控点。别傻乎乎只盯着首页——首页通常有CDN加速、有缓存策略，是最不容易挂的。真正要监控的是核心业务链路：登录流程、加购动作、结算接口、支付回调。这些环节出问题才是致命的。我有个做跨境电商的朋友，首页监控天天绿得发亮，结果某天海外用户结算时全部报500，整整四个小时没人发现。为啥？因为他们的监控只覆盖了首页和商品详情页，结算接口压根没纳入监控范围。那天的损失够买十年监控服务。

监控频率也是个学问。太频繁了，对服务器是负担，还可能被误判为攻击流量。太稀疏了，出现问题无法及时发现。一般建议核心接口每三十秒探测一次，非核心的可以五分钟一次。但别死板——大促期间要加密探测频率，平时可以适当放宽。还有告警阈值，设得太灵敏会变成狼来了，半夜三更被无关紧要的抖动吵醒，第二天顶着黑眼圈上班；设得太迟钝又形同虚设。我的经验是，响应时间超过三倍基线值才告警，错误率超过百分之一持续五分钟才拉响。这套规则帮我过滤掉了百分之八十的无效告警。

监控数据本身不会说话，得靠人解读。我习惯把可用性数据跟发布记录放在一起看——每次上线新版本，就盯着错误率曲线。如果发布后十分钟内错误率平稳，基本没问题；要是出现锯齿状波动，赶紧回滚。还有一类隐蔽问题：地域差异。国内访问快得飞起，海外用户慢如蜗牛。所以监控节点要分布在不同区域，别只盯着自家机房附近的节点看。我吃过这个亏——某个客户抱怨网站打不开，我这边监控一切正常，最后发现是他们的海外用户被某个国际出口的DNS污染了，国内节点根本探测不到。

说到底，可用性监控不是装个工具就完事，得持续迭代。今天监控了结算接口，明天是不是该看看优惠券核销流程？后天是不是要加上移动端H5页面的渲染性能？互联网产品改版频繁，监控范围也得跟着业务走。每次上线新功能，顺手把新接口纳入监控，这应该成为开发流程的固定动作，而不是事后补救。监控不是为了给领导看报表，是为了让用户在下单那一刻，不因为一个超时而放弃购物车里的东西。凌晨两点的警报声虽然烦人，但总比第二天早上看到一堆用户投诉强。毕竟，用户的耐心就那么几秒，你慢一毫秒，他就去隔壁平台了。