内容摘要：网站挂了，用户不会发邮件告诉你。他们直接关掉页面，去用别人的产品了。你甚至不知道刚才有37个人尝试访问、全部失败。这就是为什么可用性监控不是“锦上添花”，而是底线。 我见过一个电商团队，大促前反复测试

网站挂了，网站用户不会发邮件告诉你。可用控他们直接关掉页面，性监去用别人的网站产品了。你甚至不知道刚才有37个人尝试访问、可用控全部失败。性监这就是网站为什么可用性监控不是“锦上添花”，而是可用控底线。

我见过一个电商团队，性监大促前反复测试了支付流程，网站信心满满。可用控结果活动开始12分钟，性监订单量断崖式下跌。网站排查一圈，可用控发现是性监商品详情页调用的一个第三方推荐接口超时，页面白屏。监控系统只盯着首页和支付页，没人想到这个“边缘”接口会拖垮整条链路。可用性监控最怕的就是这种盲区——你监控了什么，不代表用户只用了什么。

好的监控得从用户视角出发。不是服务器CPU降到10%就万事大吉，而是“北京联通用户打开商品页要几秒”“上海电信用户能不能提交订单”。我习惯用真实浏览器去跑核心路径，从首页到搜索、到详情、到加购、到支付，每一步都计时。有时候curl返回200，但页面里图片全裂了，或者CSS加载失败，用户看到的就是一坨乱码。这种“假活”状态，只有渲染层面的监控才能抓到。

频率也很关键。一分钟一次不算多。有人觉得五分钟一次够了，可故障往往在90秒内就能赶走一半用户。你五分钟才发现，损失已经造成。当然，高频监控会带来成本，但比起一次宕机烧掉的广告费和口碑，这点投入不值一提。我见过一个SaaS产品，监控间隔从5分钟调到30秒后，平均故障恢复时间从22分钟压到4分钟。区别就是用户还没来得及截图发推特。

告警要精准，别搞狼来了。半夜三点打电话说“磁盘使用率80%”，这种告警除了让人关掉手机，没有任何意义。好的告警应该绑定业务指标：连续三次检测失败、错误率超过5%、关键页面加载超过5秒。而且告警信息里要带上下文——哪个地区、哪个运营商、哪个接口、最近一次成功是什么时候。值班的人扫一眼就知道该干什么，而不是先花十分钟翻日志。

还有一点常被忽略：监控系统本身也得被监控。你依赖的那个监控服务如果挂了，你可能比用户还晚知道。我习惯至少用两个独立的监控节点，一个在云上，一个在办公室的树莓派上。它们互相检查，谁失联了另一个就报警。听起来有点偏执，但吃过亏的人都懂。

最后说个反直觉的观察。很多团队花大钱买APM工具，却没人看仪表盘。监控的价值不在于数据多漂亮，而在于有人真的在响应。我见过最有效的做法是：每天早会花三分钟过一遍昨天的可用性报告，谁负责的模块出问题谁解释。不是批斗，就是让数字变成习惯。三个月后，故障率自然下降——因为每个人写代码时都会想“明天早上别被点名”。

监控不是装个软件就完事。它是一套习惯：从用户角度定义正常，用高频检测缩短发现时间，让告警只说人话，并且确保有人真的在听。做到这几点，你至少不会在用户流失之后才收到那封永远迟到的邮件。