站点运营里最让人难受的场景，不是页面写得不够好，而是蜘蛛来过、却撞上一堵墙。服务器重启、证书过期、连接池打满、CDN 回源失败，都会表现为一段时间内整站或部分栏目打不开。如果这段时间恰好落在蜘蛛的抓取窗口里，损失的不只是当次抓取，后续的抓取安排也可能受影响。可用性巡检和告警，就是把这类问题从「等用户反馈」变成「自己先知道」。
先分清三类「打不开」
- 整站不可用：解析异常、源站宕机、负载过高，所有地址都超时或返回 5xx。
- 局部不可用：某台后端、某个栏目、某个接口挂了，首页正常但列表页打不开。
- 看似正常但不正常：返回 200，内容却是错误提示页、空白模板或登录跳转，这一类最容易被忽略。
巡检清单怎么列
一、监控点要覆盖关键入口
不要只监控首页。首页往往是缓存最厚、最不容易出问题的那个页面。至少把这几个地址加进去：
- 首页与主要栏目列表页；
- 最近更新的内容页，用来验证动态渲染是否正常；
- 站点地图与 robots.txt，确认能正常取出；
- 搜索、筛选这类动态入口，确认没有返回内容不对的 200；
- 关键的静态资源，比如主样式表和主脚本。
二、判定标准要写死
只看状态码不够。建议同时约定三件事：响应时间上限、页面内容特征、连续失败次数。比如「连续三次请求超过 5 秒」或「返回内容里找不到约定的标题字符串」都算异常。判定标准写清楚，值班的人才知道什么情况下该打电话。
三、告警阈值与噪声控制
阈值太松，问题发现得晚；阈值太紧，一天几十条误报，最后没人看。可以按下面的思路调：
- 核心页面用较短的检测间隔和较低的容忍次数；
- 次要页面合并成一组，只报聚合结果；
- 同一故障在恢复前只提醒一次，避免重复轰炸；
- 把「维护窗口内」的告警单独标记，不要和应用故障混在一起。
告警的价值在于被认真对待，一条总被忽略的告警，等于没有。
维护窗口与蜘蛛的关系
计划内的升级、迁移、换证书，尽量安排在站点访问量较低的时间段，并且提前让相关同事知道。维护期间返回 503 比返回 200 的空页面更清楚，也更不容易让页面内容被误判。维护结束后，顺手抽查几个关键地址，确认状态码和内容都恢复。
和抓取日志对照着看
监控只能告诉你「此刻能不能打开」，日志能告诉你「蜘蛛那会儿有没有撞上」。每隔一段时间，把监控的异常时段和日志里蜘蛛的 5xx、超时记录对一下：如果异常时段里恰好有密集的抓取失败，就值得在复盘里多写两句。反过来，如果日志里出现的失败时间点在监控里没有任何记录，说明监控点还没覆盖到那个入口。
值班与复盘
- 明确谁先看、谁决策、谁回滚，别等出事了再找人；
- 恢复之后补一条记录：时间、现象、处理动作、影响范围；
- 每月挑一次真实告警做回顾，看看阈值是否需要调整；
- 新增栏目或新上线功能时，同步更新监控清单。
可用性这件事没有一劳永逸的方案，它的稳定来自一套持续被执行的检查习惯。把监控点、判定标准和维护安排固定下来，蜘蛛再来的时候，至少不会撞上一扇打不开的门。