站点上线之後，最怕的不是出故障，而是故障發生了自己却不知道。很多运营者第一次得知站点打不開，是收到用戶截图，或者搜尋流量突然下滑。可用性监控和告警看起来是运维的活，但真正决定它有没有用的，是运营侧對哪些異常值得被通知的判断。
先明确要监控哪些指标
监控不是装個探针就完事。先列出對站点有實际影响的检查項，再决定用什么工具覆盖。
- HTTP 狀態與响應時間：首頁、主要栏目頁、關键詳情頁是否返回 200，首字节時間是否突然變長。
- 證书與域名：HTTPS 證书剩余有效期、域名到期時間、解析记錄是否被改動。
- 服務器资源：磁盘占用、内存、连接數，尤其是日誌和缓存目錄把磁盘寫满的情况。
- 核心依赖：資料库、缓存服務、對象存储、CDN 回源是否正常。
- 业務可用性：搜尋框能不能出结果、表單能不能提交、登入是否正常。
只监控首頁返回 200 意义有限。如果詳情頁因為資料库连接問题全部报错，首頁可能依然正常。
告警配置里最容易踩的坑
阈值拍脑袋，稍有抖動就报警
响應時間设成 500 毫秒，稍微有点波動就触發，几天下来就没人看了。更稳的做法是结合一段時間的基线，比如连續三次檢測超過平时峰值的 1.5 倍再通知，並且把請求失敗和單纯變慢区分成两類告警。
通知只發到一個容易被淹没的地方
邮件很容易被淹没，群消息又容易被划過。至少保證有一條會真正响的通道，同时避免把同一個故障同时推到五個渠道，制造重复打扰。
没有明确谁處理
告警發到群里，所有人都看到了，但没有人認领。值班表不必复杂，但要知道工作時間和非工作時間分別找谁，以及哪些情况可以先重啟服務、哪些必须上报。
把蜘蛛抓取情况一起纳入观察
對依赖搜尋流量的站点来说，蜘蛛能不能正常訪問，本身就是一項可用性指标。
- 观察服務器日誌或站長平台資料里，抓取請求是否在某天突然归零。
- 检查是否返回大量 5xx 或 403，尤其是防爬策略調整之後。
- 留意返回给蜘蛛的頁面是否被错誤地缓存成驗證頁、跳轉頁。
抓取量下跌的原因可能是自身故障，也可能是對方策略調整，需要结合日誌和狀態碼一起看，而不是看到數字下降就急着改 robots.txt。
定期做一次故障演练
监控是否真的有效，只有在故障發生时才驗證得了。平时可以低成本地模拟一次。
- 临时断開某台服務器的對外服務，观察告警多久触發、内容是否准确。
- 確認收到告警的人是否真的看得懂，里面是否包含出問题的地址和時間。
- 记錄從告警到恢复的耗时，看看瓶颈在檢測、通知還是處理环节。
- 演练結束後恢复配置，並检查是否残留临时規則。
监控之外還要补的几件小事
监控工具會有額度限制，也會有誤报，別把它当成唯一依據。定期手動打開几個重要頁面，尤其是在改版、迁移、更換服務器之後；把域名、證书、第三方服務的到期時間记在同一個日歷里；告警歷史留档，方便回头查某個時間点到底發生了什么。
能收到告警不代表监控做對了，能在一分钟内判断這是什么問题、该找谁、要不要马上處理，才算真正可用。