站点挂掉的第一時間，通常不是你自己發現的，而是訪客、客戶或者搜尋引擎的異常报告。等有人来問“你們網站是不是打不開”，损失已经發生了。可用性监控不需要多复杂，但至少要有一套自己能看懂、能叫醒人的机制。
先想清楚“正常”長什么样
很多站点的监控只做了一件事：請求首頁，看返回碼是不是 200。這只能覆盖最粗的一层。首頁正常，不代表栏目頁正常，也不代表搜尋、下單、登入這些真正重要的路径正常。
建议先列出對站点最關键的 5 到 10 個地址，把它們当成观察窗口：
- 首頁與主要栏目首頁
- 近期流量最高的一批内容頁
- 搜尋頁或带參數的篩選頁，這類頁面最容易因後端超时或參數異常出問题
- 登入、註冊、表單提交等交互入口
- sitemap、robots.txt 等给蜘蛛讀取的文件
判定條件不要只看狀態碼
返回 200 却不代表頁面可用。常见的情况包括：資料库连接失敗後輸出一個空白頁、模板报错只留一行提示、负载均衡把請求轉發到尚未部署完成的节点。這些都可能顶着 200 返回。
补充两個辅助判定
- 頁面特征串：在正常頁面里挑一段稳定出現的文字或元素，监控时確認它存在。注意別選會随内容變化的标题或時間。
- 响應時間阈值：给關键地址设一個上限，比如超過 3 秒就算異常。很多故障不是打不開，而是慢到無法使用，這一点狀態碼看不出来。
检查频率與探测点怎么定
首頁這類核心入口，1 到 5 分钟一次比較合适；普通栏目頁和内容頁 5 到 15 分钟一次即可。频率過高會给自己服務器增加压力，也容易产生大量誤报。
如果條件允许，尽量從两個以上不同網絡位置發起探测。單一探测点挂掉时，無法区分是自己網絡的問题還是服務器的問题，排查方向會被带偏。國内與海外各放一個探测点，也能顺带發現线路层面的差异。
告警要叫得醒，也要停得下
全天候的短信轰炸只會让人麻木，最後演變成“看到告警先關掉”。几個實用做法：
- 连續失敗再报：连續 2 到 3 次探测失敗才触發告警，過滤掉網絡抖動。
- 分級通知：長時間不可用或無响應，走电话或短信；响應變慢、單点異常，走群消息或邮件。
- 恢复也要通知：只报故障不报恢复，值班的人會一直不确定問题是否還在。
- 明确處理人：告警渠道里寫清谁负责、联系方式是什么，避免消息在群里飘着没人接。
定期做一次人工复核
监控是自動的，但規則是人寫的。配置可能在上线調整、域名更換、目錄改版之後失效，而失效的监控不會报错，只會安静地什么都不报。建议每季度抽出十几分钟：打開监控列表，逐個訪問被监控的地址，確認它們仍然是重要頁面，確認特征串仍然存在，確認告警渠道仍然有效。
把告警记錄留下来
每次故障處理完，简單记一句：什么时候開始、影响了什么、怎么恢复的。积累一段時間後，你會發現有些問题反复出現，比如某個時間段备份任務把磁盘寫满、某個接口在高峰期超时。這些規律比單次修复更有價值。
监控的意义不在于图表好看，而在于問题發生时，你比訪客更早知道。