很多站点的問题不是没人發現，而是發現得太晚：訪客打不開頁面，先在群里問一句；搜尋蜘蛛抓取失敗，等到下次翻日誌才知道。可用性监控的價值，就是在訪客和蜘蛛之前先發現問题，把“是不是又挂了”變成“什么时候挂的、挂了多久、影响了哪些地址”。
先想清楚监控什么
监控不是越多越好。指标堆得太杂，告警就會變成噪音，最後没人看。建议先围绕三類目标選点：入口可達、核心内容可達、關键鏈路可達。
入口與核心頁面
- 首頁、主要栏目頁、几個有代表性的内容頁。
- 登入、註冊、下單、留言等關键入口（如果站点有）。
- XML 站点地图地址，確認蜘蛛拿到的是正常响應而不是 500。
依赖項與外部條件
- 資料库、缓存、對象存储等内部依赖的响應情况。
- 證书有效期、域名解析是否正常。
- CDN 回源是否成功，邊缘节点是否返回異常狀態碼。
监控地址要選稳定的、不含随机參數的 URL。用带會话或带篩選參數的地址做监控，很容易把正常的參數差异誤判成故障。
监控方式與频率
常见做法有两层：外部探测（從机房或云节点請求頁面，看狀態碼和响應時間）與内部自检（應用端定时寫心跳、統計错誤日誌）。外部探测贴近真實訪客视角，内部自检更容易定位到具体模块，两者结合更實用。
- 频率：核心入口 1 分钟一次，普通頁面 5 到 10 分钟一次即可。
- 判定：不要只看狀態碼，配合响應体關键字、响應時間阈值一起判断。
- 多点：至少两個不同網絡位置的探测点，避免單点網絡抖動造成誤报。
自查清單
- 列出必须保證可用的地址清單，标注優先級。
- 確認监控地址在 robots.txt 允许范围内，且不會产生副作用（比如触發寫操作）。
- 检查探测請求是否带上了合适的 UA 與 Header，避免被安全策略当成異常流量拦下。
- 設定告警阈值和静默期，避免同一故障反复轰炸。
- 確認告警能真正到達负责人，別只發到一個没人看的信箱。
- 為每次故障记錄開始時間、恢复時間、影响范围。
- 定期回顾誤报，把無意义的告警規則删掉或調松。
和抓取、运营的關系
搜尋蜘蛛的抓取结果，可以当作一種“延迟的可用性反馈”：如果日誌里某些地址長期返回 5xx、超时或响應時間異常，往往說明监控存在盲区。反過来，监控發現短时宕机後，也可以對照日誌看看蜘蛛是否恰好在那段時間来過。這類交叉驗證比單獨看一份資料更有判断力。
對运营来说，稳定性直接影响更新节奏。栏目按計划更新，但如果發布时段频繁触發超时或寫入失敗，内容日歷就會變成一張空表。把监控告警和發布流程绑定，出問题时先暫停批量操作，比事後补稿省力得多。
常见誤区
- 只看首頁：首頁正常不代表栏目和詳情頁正常，缓存可能掩盖了後端問题。
- 只监控狀態碼：返回 200 但内容是一張错誤提示頁，同样属于故障。
- 告警太多：一天几十條通知，最後没人当回事。
- 只监控不记錄：没有歷史資料，就無法判断是偶發還是恶化趋势。
- 把监控当安全设备：可用性监控和攻击防護是两件事，別指望一套規則解决。
可用性监控不追求花哨，追求的是“出問题时有人知道，知道後能快速定位”。把關键地址、合理频率、清晰告警和简單记錄這四件事做扎實，就已经比大多數站点走得遠。