很多站点出問题，第一個知道的人不是运营，而是用戶。等投诉来了再去看，故障可能已经持續了几個小时，蜘蛛也在這段時間里反复抓到 5xx，抓取节奏被打乱。可用性监测不是大厂才需要的東西，一個便宜的探测服務加上几個關键地址，就能把“事後救火”變成“事前知道”。
先想清楚：监测的目标不是绿点，而是可訪問
监测工具给出的绿色打勾，只能說明探测节点拿到了响應。至于拿到的是正常頁面、错誤頁還是登入墙，需要你自己定义。建议至少把這几個地址列進监测清單：首頁、一個核心栏目頁、一個内容詳情頁、站点搜尋或表單入口（如果對外可訪問）。如果你的站点有多個域名或子域，主站之外還要覆盖主要入口。
监测内容：狀態碼之外還要看什么
- HTTP 狀態碼：5xx、连續 404，以及被誤配置成 200 的错誤頁。
- 响應時間：單次波動没意义，看趋势。响應從 200ms 涨到 3s，通常意味着資料库或後端出了問题。
- HTTPS 證书有效期：證书過期是全站不可訪問，而且往往發生在周末。
- DNS 解析：解析異常會同时影响用戶和蜘蛛，表現像“整個站消失”。
- 静態资源：CDN 回源失敗或图片域名挂掉时，頁面骨架還在，用戶看到的是残缺頁面。
探测节点與频率：別只從一個地方看
只用一個探测节点，等于用一個用戶的视角代表所有人。运营者所在網絡正常，不代表其他地区正常。選擇监测服務时，留意它是否有多個地域节点，以及是否支持從不同运营商發起請求。频率上，1 分钟一次适合核心頁面，栏目頁 5 分钟一次就够了。频率太高既浪費资源，也容易把偶發抖動變成一堆無效告警。
告警：能叫醒人的規則才是好規則
告警太吵，人就會麻木，最後所有告警都被静音。建议做两件事：一是加“连續失敗次數”條件，比如连續 3 次失敗才通知，過滤掉瞬时抖動；二是分級，核心頁面走电话或即时通讯，次要頁面走邮件匯總。同时把告警發给多人，避免唯一的接收人刚好在飞机上。
收到告警後的處理顺序
- 先確認范围：只有自己訪問不了，還是多個探测节点都失敗。
- 看最近變更：是否刚發布代碼、改過服務器配置、調整過 DNS 或 CDN。
- 检查依赖：資料库、缓存、對象存储、第三方接口，哪一环先断的。
- 先恢复再排查：回滚或切到备用节点让站点先能訪問，根因分析放到之後做。
- 记錄時間线：故障開始、發現、處置、恢复的時間点，方便後續复盘。
几個常被忽略的细节
- 监测地址用正式域名，不要用内網 IP 或带調试參數的地址，否則测的不是用戶看到的頁面。
- 错誤頁本身也要能正常返回，別让错誤頁再触發一次错誤。
- 维護窗口提前在监测里設定，避免計划内操作触發一堆告警。
- 把监测结果和服務器日誌對照，確認蜘蛛抓取失敗是否也集中在同一時間段。
可用性监测解决的是“知不知道”，不解决“為什么”。它不能替代日誌分析、性能優化和内容运营，但它是其他运营動作的前提——站点打不開，後面的事都無從谈起。
如果現在還没有任何监测，先從首頁加一個探测開始，把告警發到自己能第一時間看到的渠道，跑一周看看誤报多不多，再决定要不要扩到栏目頁和證书到期提醒。這件事成本不高，但能省下很多“用戶比你先發現問题”的尴尬。