凌晨三点，网站我的健康检测手机突然震个不停。监控告警推送像弹幕一样刷屏——某客户官网挂了，网站整站返回502。健康检测我揉着眼睛爬起来，网站先ping网关，健康检测通；再curl首页，网站卡在TLS握手。健康检测折腾二十分钟才发现，网站是健康检测CDN回源超时。这破事不是网站第一次了。

网站健康检测这词听着高大上，健康检测本质就一句话：确认用户能不能正常打开你的网站页面。别扯什么全链路监控、健康检测拨测节点、网站APM探针，那些都是工具。核心问题永远是——你的网站在真实网络环境下，到底能不能用。

我见过最离谱的案例，某电商平台技术团队盯着Grafana看了一下午，所有指标绿油油，CPU、内存、带宽全正常。结果用户疯狂投诉下单失败。最后查出来是前端代码里有个bug，只在特定机型特定浏览器下触发，白屏但页面状态码还是200。你说这算健康还是病危？按服务器指标看，活蹦乱跳；按用户体验看，已经进ICU了。

所以后来我给自己定了个规矩：检测必须分三层。第一层探活，就是看进程在不在、端口通不通，这层只解决“服务器没宕机”的问题。第二层要模拟真实请求，拿curl带完整header去抓页面，检查返回内容里有没有关键关键词——比如购物网站的“加入购物车”按钮文本。第三层才轮到性能，首屏时间、交互延迟这些。很多团队把三层顺序搞反了，天天盯第三层，第一层反而靠人工巡检，纯属本末倒置。

有次帮朋友排查他的博客站，他说检测脚本显示100%正常，可他自己打开就是慢。我看了下脚本，好家伙，检测的是`/healthz`端点，那是个返回空字符串的静态接口，当然快。真实用户访问的是首页，首页要查三次数据库、加载十七张图片、还有两个第三方统计脚本。检测入口跟用户入口不一致，这检测就是自欺欺人。

搞检测还得学会“制造故障”。定期杀一下Web服务器的进程，看监控能不能发现；手动改个数据库连接池配置，看会不会告警。我管这叫“主动混沌”，比等出事了再复盘强得多。去年双十一前，我故意往预发环境注入五分钟延迟，结果告警倒是触发了，但值班同学按预案操作时发现，重启脚本有bug——这要是真出事，够喝一壶的。

最后说个扎心的事实：再完善的检测也防不住所有故障。检测做的是概率管理，把“出大事”变成“出小事”，把“半夜惊醒”变成“白天从容处理”。我电脑桌面长期开着三个终端窗口，一个跑ping，一个跑curl循环，一个看错误日志。丑是丑了点，但比任何商业监控都直观——至少它不会在我最需要的时候，因为监控平台自己宕机而失明。

网站健康检测，说到底就是跟不确定性较劲。你多较一分劲，用户就少骂一句娘。就这么简单。