站点出問题，最尴尬的情况往往不是“修不好”，而是“没人知道”。訪客打不開頁面只會默默關掉标簽，搜尋引擎蜘蛛抓取失敗也只在日誌里留一行记錄。等到有人来反馈，可能已经過去几個小时甚至几天。把可用性监控和告警纳入日常运营，能把發現故障的時間從“天”压到“分钟”。
先想清楚：哪些故障必须第一時間知道
不是所有異常都值得半夜叫你起来。先把優先級排出来，通常這几類属于必须立刻感知的：
- 首頁以及几個核心栏目頁無法訪問；
- 服務器返回 5xx 的比例明顯升高；
- 响應時間從几百毫秒涨到几秒；
- HTTPS 證书即將到期或已经失效；
- 域名解析異常，訪問被指向错誤地址；
- 磁盘寫满導致日誌或資料無法寫入；
- 資料库连接失敗，頁面只輸出报错信息。
把這几点寫下来，後面的监控配置才有依據，不然很容易買一堆服務却没人看。
從最小可用集合開始，而不是先搞大屏
很多团队一開始就想做可视化大屏，结果监控項配了一堆，告警渠道却没接通。更務實的做法是先跑通一條鏈路：一台便宜的探针或第三方监控服務，定时請求几個關键 URL，记錄 HTTP 狀態碼、响應時間，並做一次内容校驗。這條鏈路跑顺了，再逐步加項。
狀態碼监控要看什么
- 连續两次失敗再告警，避免偶發網絡抖動触發誤报；
- 4xx 和 5xx 分開統計，前者多半是連結問题，後者才是服務問题；
- 關注趋势而不只是單点，比如 5xx 從每天几條變成每小时几條。
内容校驗比狀態碼更接近真實体驗
有些故障頁面會返回 200，但正文区域變成了“系統维護中”，或者干脆把資料库报错信息輸出到頁面上。只监控狀態碼會完全看不到這類問题。做法很简單：在监控請求里检查頁面是否包含某個固定關鍵詞，比如站点名稱或主标题，找不到就告警。
告警要送到人真正會看的地方
邮件是最容易漏的渠道。比較稳妥的组合是：聊天工具机器人负责日常通知，重要故障再通過短信或电话触達。可以按影响面分三級：
- P1：核心頁面不可訪問、大面积 5xx，立即用电话或短信叫人；
- P2：單一路径異常、响應時間明顯劣化，走聊天工具；
- P3：證书临期、磁盘使用率偏高，匯總成日报或周报。
別让告警變成“狼来了”
告警最大的敌人是噪音。几個常见做法：設定合理的重试次數和静默期，同一個故障在恢复前只提醒一次；計划内的维護、迁移、压测提前挂上维護窗口；定期回看那些“告警了但没事”的记錄，把誤报規則調掉。一個長期被忽略的告警群，等于没有监控。
告警之外，還需要一份定期巡检清單
监控只能覆盖你想到的路径，定期巡检是兜底。下面這份清單可以按自己的节奏执行：
- 每周看一眼可用率與平均响應時間的趋势，別只看当天；
- 每月確認一遍證书到期時間，尤其是自動續期是否真的生效；
- 每月確認备份任務在跑，並抽一次實际恢复；
- 每季度模拟一次故障，驗證告警能否送達、多久送達；
- 每次故障记錄時間、影响范围、原因和處理動作，方便复盘。
這些動作單獨看都很小，但坚持下来，站点出問题时你手里就有歷史資料可對比，而不是凭感觉猜。
日誌留多久，也影响你能查多深
服務器訪問日誌和错誤日誌建议做轮轉，保留一段時間用于复盘。留得太短，故障過後查不到證據；留得太長，又容易把磁盘寫满。這里可以结合站点規模定一個折中值，比如訪問日誌保留两周到一個月，错誤日誌保留更久一些，並监控磁盘使用率。
监控和告警不會让站点不出故障，它的價值在于把“被動挨骂”變成“主動處理”。先保證核心頁面有人盯着，再慢慢补齐其它监控項，比一次性堆满配置更現實。