凌晨三点，网站手机突然响了。可用控可靠监控告警：主站返回502。性监我从床上爬起来，网站打开电脑，可用控可靠发现是性监后端某个服务挂了。但奇怪的网站是，用户端没有任何反馈——因为那会儿根本没人访问。可用控可靠这次告警除了吵醒我，性监没有任何实际意义。网站

这就是可用控可靠网站可用性监控的日常。它可靠吗？性监答案是：它可靠，但不可全信。网站

监控工具能告诉你“挂了”，可用控可靠但说不清“怎么挂的性监”

我用过不少监控服务，从UptimeRobot到Pingdom，再到自建的Prometheus加Blackbox Exporter。它们的核心逻辑都差不多：每隔一段时间向你的网站发一个HTTP请求，看返回码和响应时间。返回200就算正常，返回500或者超时就算故障。

问题在于，这种判断太粗糙了。

有一次，我们的登录接口返回200，但响应体里其实是一个错误提示：“系统繁忙，请稍后再试”。监控没告警，因为HTTP状态码是200。用户却炸了。后来我加了一条规则：检查响应体里是否包含特定关键词。但这又带来新问题——关键词匹配太死，稍微改个文案就误报。

还有一次，CDN节点出问题，北京用户访问正常，广州用户全部超时。而我的监控节点在杭州，完全没感知。监控的视角是单一的，它只能代表那个节点、那个时刻、那条网络路径的状况。你看到的“可用”，可能只是你运气好。

告警疲劳比漏报更可怕

我见过一个团队，监控配了上百条规则，邮箱里每天塞满告警。结果呢？所有人把告警邮件自动归档到某个文件夹，根本没人看。真正出故障那次，告警邮件混在一堆“磁盘使用率超过80%”和“CPU瞬时飙到90%”的通知里，被彻底淹没。

监控的可靠性不取决于它多灵敏，而取决于它多克制。一个每天误报十次的系统，和一个从不报警的系统，在关键时刻的表现可能一样糟——因为没人信它了。

我现在习惯把告警分成两级：P0是“用户已经受影响”，比如首页返回503；P1是“可能即将受影响”，比如数据库连接池快满了。P0直接打电话，P1只发邮件。这样至少保证半夜被吵醒时，是真的有事。

合成监控和真实用户监控，差距比想象中大

合成监控就是模拟请求，像机器人一样定时访问。真实用户监控（RUM）则是收集真实用户的浏览器数据。两者经常打架。

合成监控说：首页加载1.2秒，正常。RUM说：50%的用户加载超过5秒。为什么？因为合成监控的服务器在机房，网络质量极好；而真实用户可能在用3G网络，或者手机内存快满了。

我现在的做法是：合成监控用来做故障发现，RUM用来做性能优化。前者保证“网站活着”，后者保证“用户用得爽”。两者缺一不可，但别指望其中一个能替代另一个。

监控本身也会挂

最讽刺的是，监控系统自己也会出问题。有一次我们的监控服务器磁盘满了，导致所有检查任务静默失败。我们以为一切正常，直到用户打电话来问：“你们网站是不是挂了？”

从那以后，我给监控系统加了一个“心跳”机制：如果监控超过5分钟没有上报任何数据，就触发另一个独立通道的告警。监控自己也需要被监控。

所以回到标题的问题：网站可用性监控可靠吗？

它可靠，但前提是你知道它的边界。它擅长发现“完全不可用”，不擅长判断“部分用户不可用”。它能告诉你“出事了”，但说不清“出什么事”。它需要和日志、链路追踪、真实用户数据配合，才能拼出完整画面。

别把它当神。把它当一个有点笨但很勤奋的哨兵。你还需要自己偶尔去站岗。