站点挂掉的第一时间，通常不是你自己发现的，而是访客、客户或者搜索引擎的异常报告。等有人来问“你们网站是不是打不开”，损失已经发生了。可用性监控不需要多复杂，但至少要有一套自己能看懂、能叫醒人的机制。
先想清楚“正常”长什么样
很多站点的监控只做了一件事：请求首页，看返回码是不是 200。这只能覆盖最粗的一层。首页正常，不代表栏目页正常，也不代表搜索、下单、登录这些真正重要的路径正常。
建议先列出对站点最关键的 5 到 10 个地址，把它们当成观察窗口：
- 首页与主要栏目首页
- 近期流量最高的一批内容页
- 搜索页或带参数的筛选页，这类页面最容易因后端超时或参数异常出问题
- 登录、注册、表单提交等交互入口
- sitemap、robots.txt 等给蜘蛛读取的文件
判定条件不要只看状态码
返回 200 却不代表页面可用。常见的情况包括：数据库连接失败后输出一个空白页、模板报错只留一行提示、负载均衡把请求转发到尚未部署完成的节点。这些都可能顶着 200 返回。
补充两个辅助判定
- 页面特征串：在正常页面里挑一段稳定出现的文字或元素，监控时确认它存在。注意别选会随内容变化的标题或时间。
- 响应时间阈值：给关键地址设一个上限，比如超过 3 秒就算异常。很多故障不是打不开，而是慢到无法使用，这一点状态码看不出来。
检查频率与探测点怎么定
首页这类核心入口，1 到 5 分钟一次比较合适；普通栏目页和内容页 5 到 15 分钟一次即可。频率过高会给自己服务器增加压力，也容易产生大量误报。
如果条件允许，尽量从两个以上不同网络位置发起探测。单一探测点挂掉时，无法区分是自己网络的问题还是服务器的问题，排查方向会被带偏。国内与海外各放一个探测点，也能顺带发现线路层面的差异。
告警要叫得醒，也要停得下
全天候的短信轰炸只会让人麻木，最后演变成“看到告警先关掉”。几个实用做法：
- 连续失败再报：连续 2 到 3 次探测失败才触发告警，过滤掉网络抖动。
- 分级通知：长时间不可用或无响应，走电话或短信；响应变慢、单点异常，走群消息或邮件。
- 恢复也要通知：只报故障不报恢复，值班的人会一直不确定问题是否还在。
- 明确处理人：告警渠道里写清谁负责、联系方式是什么，避免消息在群里飘着没人接。
定期做一次人工复核
监控是自动的，但规则是人写的。配置可能在上线调整、域名更换、目录改版之后失效，而失效的监控不会报错，只会安静地什么都不报。建议每季度抽出十几分钟：打开监控列表，逐个访问被监控的地址，确认它们仍然是重要页面，确认特征串仍然存在，确认告警渠道仍然有效。
把告警记录留下来
每次故障处理完，简单记一句：什么时候开始、影响了什么、怎么恢复的。积累一段时间后，你会发现有些问题反复出现，比如某个时间段备份任务把磁盘写满、某个接口在高峰期超时。这些规律比单次修复更有价值。
监控的意义不在于图表好看，而在于问题发生时，你比访客更早知道。