很多站点出問题，第一個知道的不是站長，而是搜尋蜘蛛。日誌里那串 5xx 是它留下的记錄，等到自己發現，往往已经過去几個小时甚至几天。把可用性监控当成站点运营的固定動作，目的不是追求零故障，而是把故障的發現時間從「天」压缩到「分钟」。
监控別只盯着首頁
首頁能打開，不代表整站正常。常见的故障形態是：首頁走了缓存或静態化，一直好好的，詳情頁却因為資料库连接池打满、附件目錄挂载失敗而整片报错。所以监控地址要有代表性。
- 首頁：最基础的一层，但要留意是否被缓存掩盖了後端故障。
- 每個一級栏目：至少各取一個入口地址，確認栏目頁能正常渲染。
- 詳情頁：随机取几條近期發布的内容，驗證資料库和模板鏈路。
- 列表與分頁：翻到第二頁、第三頁，不少分頁逻辑的邊界問题就藏在這里。
- 静態资源：CSS、JS、图片各取一個，確認 CDN 回源和對象存储正常。
- 對外接口：如果有 API 或站内搜尋接口，單獨加一條探针。
返回 200 不等于頁面正常
比 5xx 更隐蔽的是软错誤：服務器返回 200，正文里却是一段「系統维護中」或「内容不存在」的模板。监控工具只看狀態碼，會認為一切正常。
- 在响應正文里检查一個只應出現在正常頁面上的标记，比如頁脚版本号或某個固定模块。
- 設定正文長度下限，突然缩到几百字节通常意味着模板出错。
- 對關键地址校驗标题或主要区块是否為空。
告警設定：宁可迟一点，也別天天誤报
告警太吵，最後一定被忽略。几條经驗：
- 用连續失敗次數触發，而不是單次失敗，例如连續 3 次、間隔 1 分钟。
- 按嚴重程度分层：全站不可用走即时消息或电话，單條地址異常走邮件。
- 区分探测节点與内容地区的差异，避免因探测机自身網絡抖動而誤报。
- 發布、重啟等計划内動作，提前設定维護窗口静音。
從發現到恢复，按顺序来
- 確認范围：是單個地址、一個栏目，還是整站；是只影响外網，還是内網同样異常。
- 回看最近變更：代碼發布、配置修改、證书更新、DNS 調整按時間线排一遍，多數故障都能對上号。
- 優先恢复：能回滚就先回滚，別在現场邊查邊改。
- 检查抓取影响：恢复後观察一段時間日誌，確認错誤响應停止、蜘蛛是否已经回来。
- 留下记錄：時間、現象、原因、處理動作寫進同一份文档，下次同類問题能省一半時間。
把监控结果變成月度习惯
每周或每月導出一次可用性报表，看一眼趋势：响應時間是缓慢上升還是平稳，错誤有没有集中在某個时段、某個栏目。缓慢上升的响應時間通常比一次宕机更值得關注，因為它不會触發告警，却會持續影响抓取和訪問体驗。把這些資料和抓取日誌對照着看，比單獨盯一份报表有用得多。
监控的意义不是證明站点没問题，而是在出問题时，让你比蜘蛛先知道。