為什么可用性监控属于站点运营的日常
站点出問题的时候，最先發現的往往不是站長，而是用戶和搜尋蜘蛛。用戶看到的是空白頁或 502，蜘蛛拿到的可能是一串超时。等到自己打開浏览器点一下才發現，中間可能已经過去几個小时。可用性监控的價值就在這個時間差里：它替你不間断地訪問几個關键地址，一旦结果不符合预期就發出提醒，让你有机會在影响扩大之前處理。
需要說明的是，监控只能告诉你“站点現在能不能正常响應”，不能替代抓取诊断、日誌分析這些工作，也不會因為装了监控就带来收錄上的變化。它解决的問题很朴素——別让自己最後一個知道站点挂了。
先确定监控哪些東西
核心頁面與接口
- 首頁：最基础的可用性信号。
- 主要栏目頁：通常承担分發入口，出問题时影响面較大。
- 關键功能頁：登入、搜尋、列表接口等，尤其是依赖後端和資料库的頁面。
- 静態资源：挑一两個 CSS、JS 或图片地址，用来判断 CDN 和對象存储是否正常。
监控点不宜過多，覆盖主要鏈路即可。几十個地址一起告警，最後很容易變成没人细看。
域名、解析與證书
- 检查 DNS 解析是否正常，解析结果是否指向预期地址。
- 记錄域名和證书的到期時間，提前留出續期和替換的時間。
- 如果站点有跳轉鏈路，至少监控跳轉後的最终地址，避免只看第一跳。
把蜘蛛的訪問也纳入观察
如果手里有訪問日誌或爬虫統計，可以顺带看一個指标：單位時間内来自搜尋蜘蛛的請求是否骤降。訪問量下降的原因很多，但当它和站点错誤同时出現时，往往說明抓取确實受到了影响。這個指标适合作為辅助參考，不适合單獨用来判断站点健康。
阈值和告警級別的設定
监控工具一般允许設定狀態碼、响應時間、连續失敗次數等條件。比較實用的做法是分层：
- 紧急：首頁或核心接口连續多次返回 5xx、超时，或者 DNS 解析失敗，這類問题需要立刻處理。
- 提醒：响應時間明顯變長、單次偶發失敗、個別静態资源 404，可以攒一攒再看，避免被噪声打断。
- 记錄：證书剩余天數、磁盘空間、备份任務结果，按天或按周匯總一次即可。
连續失敗次數是一個容易被忽略的參數。設定成一次失敗就告警，網絡抖動會带来大量誤报；設定得太宽松，又可能延迟發現真實故障。可以先按“连續 2 到 3 次失敗”起步，再根據實际誤报情况調整。
通知渠道與值班习惯
告警發到哪里，比告警本身更影响执行效果。邮件适合留档，即时通讯适合即时提醒，电话或短信适合紧急級別。建议至少准备两個渠道，並且定期確認渠道本身是通的——曾经出現過告警發到了已经没人维護的群里的情况。
另外，把處理動作寫下来會省很多事：收到告警先看什么、在哪里看、联系谁。站点故障时人容易慌，一份简短的清單能让排查更有顺序。
监控的意义不是把每一條異常都消灭掉，而是让真正影响用戶和抓取的問题尽快浮出水面，让不重要的噪声安静下来。
出現故障後的處理顺序
- 確認影响范围：只有某個頁面，還是整站；只有部分地区，還是全部。
- 從外层往里查：DNS、網關、负载均衡、Web 服務、資料库，逐层排除。
- 查看最近變更：配置、發布、證书、CDN 規則，出問题前動過什么。
- 恢复可用優先：先让站点能正常响應，再慢慢定位根因。
- 记錄與复盘：把時間、現象、處理動作记下来，下次同類問题會快很多。
几点提醒
监控只是运营中的一环。它不能保證蜘蛛一定来抓，也不能保證頁面被收錄，但能减少“站点明明打不開，自己却毫不知情”這種低級损耗。把监控点控制在自己看得過来的范围内，把告警阈值調到能行動的粒度，坚持下去比一開始配得复杂更有用。