很多站点运营的日常是这样的：出问题之前风平浪静，出问题之后靠访客在群里说一句“你们网站打不开了”才知道。从故障发生到被发现的这段时间，可能正好是蜘蛛来访的时段，也可能是访客下单的高峰。可用性监控听起来像大站才需要的东西，其实小站更需要，因为小站没有值班工程师，只能靠自动检查替自己盯着。
先想清楚要盯哪几个点
监控不是越多越好，而是要把有限的注意力放在“一旦坏掉就影响业务”的地方。首页能打开但登录接口挂了，对用户来说同样等于站点不可用。建议至少覆盖下面几类：
- 核心页面的 HTTP 状态码与响应时间：首页、主要栏目页、一个典型的详情页。
- 关键交互环节：登录、注册、提交表单、站内搜索，这些接口出错时页面往往还显示得很正常。
- HTTPS 证书的剩余有效期，提前三十天提醒比到期当天提醒有用得多。
- DNS 解析是否正常，域名是否被意外暂停解析。
- 服务器基础指标：CPU、内存、磁盘占用、带宽，磁盘写满会让整站跟着停摆。
监控点怎么选才合理
监控地址最好用固定 URL，不要带随机参数，也不要选那种本身依赖第三方接口的页面，否则第三方抖动会让你误判成自己的问题。检查频率按站点体量来，小站五分钟一次已经足够，频率太高既浪费资源也容易触发对方的风控。检查节点建议放在站外，机房内部互相能 ping 通，并不能说明外网访问正常。
告警设置的三个常见坑
告警太多，最后没人看
如果每隔几分钟就收到一条通知，用不了多久所有人都会把通知静音。可以给告警分级：连续两次失败才发初级提醒，持续十分钟以上再升级到电话或即时通讯工具。同时把已知的维护窗口排除掉，避免计划内重启也报警。
只看状态码，不看内容
有些故障页面依然返回 200，内容却变成了空白或者一段错误提示。对最重要的几个页面，可以加一条关键字检查，确认页面里确实包含预期的标题或正文片段。
忘了告警之外的“人”
告警发到没人负责的群里，等于没发。至少要指定一个第一响应人，并把处理步骤写清楚：先做什么、去哪里看日志、联系谁。
一份可以照着做的自查清单
- 列出三到五个必须保持可用的地址，写进监控配置。
- 给每个地址设定响应时间阈值，超出后触发告警。
- 配置至少两条告警通道，避免单一通道失效时无人知晓。
- 把证书到期、磁盘占用、域名到期加入定期检查项。
- 每季度做一次演练，手动停掉服务，看看告警多久到达、流程是否顺畅。
- 把每次故障的时间线记录下来，形成自己的经验库。
故障恢复之后别急着关页面
站点长时间不可用，恢复后的第一件事往往不是发公告，而是确认数据没有异常、页面返回正常。如果故障期间大量页面返回过 5xx，可以留意之后几天的抓取日志，看看蜘蛛是否重新回来访问，必要时通过站点地图再提醒一次。真正有价值的不是“这次修好了”，而是“下次能更快发现”。
监控解决的是发现问题的时间，不解决修复的速度。两者都要有人负责，站点才不会一直靠运气运行。