站点运营里最让人难受的场景，不是頁面寫得不够好，而是蜘蛛来過、却撞上一堵墙。服務器重啟、證书過期、连接池打满、CDN 回源失敗，都會表現為一段時間内整站或部分栏目打不開。如果這段時間恰好落在蜘蛛的抓取窗口里，损失的不只是当次抓取，後續的抓取安排也可能受影响。可用性巡检和告警，就是把這類問题從「等用戶反馈」變成「自己先知道」。
先分清三類「打不開」
- 整站不可用：解析異常、源站宕机、负载過高，所有地址都超时或返回 5xx。
- 局部不可用：某台後端、某個栏目、某個接口挂了，首頁正常但列表頁打不開。
- 看似正常但不正常：返回 200，内容却是错誤提示頁、空白模板或登入跳轉，這一類最容易被忽略。
巡检清單怎么列
一、监控点要覆盖關键入口
不要只监控首頁。首頁往往是缓存最厚、最不容易出問题的那個頁面。至少把這几個地址加進去：
- 首頁與主要栏目列表頁；
- 最近更新的内容頁，用来驗證動態渲染是否正常；
- 站点地图與 robots.txt，確認能正常取出；
- 搜尋、篩選這類動態入口，確認没有返回内容不對的 200；
- 關键的静態资源，比如主样式表和主脚本。
二、判定标准要寫死
只看狀態碼不够。建议同时约定三件事：响應時間上限、頁面内容特征、连續失敗次數。比如「连續三次請求超過 5 秒」或「返回内容里找不到约定的标题字符串」都算異常。判定标准寫清楚，值班的人才知道什么情况下该打电话。
三、告警阈值與噪声控制
阈值太松，問题發現得晚；阈值太紧，一天几十條誤报，最後没人看。可以按下面的思路調：
- 核心頁面用較短的檢測間隔和較低的容忍次數；
- 次要頁面合並成一组，只报聚合结果；
- 同一故障在恢复前只提醒一次，避免重复轰炸；
- 把「维護窗口内」的告警單獨标记，不要和應用故障混在一起。
告警的價值在于被認真對待，一條總被忽略的告警，等于没有。
维護窗口與蜘蛛的關系
計划内的升級、迁移、換證书，尽量安排在站点訪問量較低的時間段，並且提前让相關同事知道。维護期間返回 503 比返回 200 的空頁面更清楚，也更不容易让頁面内容被誤判。维護結束後，顺手抽查几個關键地址，確認狀態碼和内容都恢复。
和抓取日誌對照着看
监控只能告诉你「此刻能不能打開」，日誌能告诉你「蜘蛛那會儿有没有撞上」。每隔一段時間，把监控的異常时段和日誌里蜘蛛的 5xx、超时记錄對一下：如果異常时段里恰好有密集的抓取失敗，就值得在复盘里多寫两句。反過来，如果日誌里出現的失敗時間点在监控里没有任何记錄，說明监控点還没覆盖到那個入口。
值班與复盘
- 明确谁先看、谁决策、谁回滚，別等出事了再找人；
- 恢复之後补一條记錄：時間、現象、處理動作、影响范围；
- 每月挑一次真實告警做回顾，看看阈值是否需要調整；
- 新增栏目或新上线功能时，同步更新监控清單。
可用性這件事没有一劳永逸的方案，它的稳定来自一套持續被执行的检查习惯。把监控点、判定标准和维護安排固定下来，蜘蛛再来的时候，至少不會撞上一扇打不開的门。