站点运营里有個常见的错觉：只要没人来反馈，網站就是正常的。實际上用戶很少會专门告诉你“首頁白屏”“某個栏目 502”，他們直接關掉頁面就走了。监控與告警的意义，就是把這類沉默的故障變成你能主動看到的信息。
先确定要盯哪几類信号
不需要一開始就搭很复杂的体系，先覆盖下面几類，就能解决大部分“事後才知道”的問题。
可用性
- 首頁、主要栏目頁、核心落地頁各挑一两個，做多地域拨测。
- 關注的不只是“能不能打開”，還包括返回的狀態碼和首字节時間。
- 登入、下單、提交表單這類關键路径，單獨设一條检查。
错誤率與响應時間
- 5xx 比例比绝對值更有參考價值，短時間突增通常意味着發布或依赖出了問题。
- 慢請求占比、连接數、上游接口超时，都值得留一條趋势线。
證书、域名與基础配置
- HTTPS 證书到期、域名到期、CDN 配置變更，都設定提前提醒。
- 提醒時間至少留出一個月，別设成“到期前 3 天”。
抓取侧的異常
- 同一时段的蜘蛛抓取量骤降、狀態碼里 5xx 變多，往往和线上故障同源。
- 把抓取資料的日环比放進每周巡检，異常时先確認站点本身是不是不可用。
告警设得太吵，等于没有告警
不少团队的监控最後被静音，不是因為没出故障，而是噪音太多。几條经驗：
- 分等級：致命級走电话或即时通讯，提醒級只進日报。
- 给阈值加持續時間：连續两到三次失敗再报，避開網絡抖動造成的誤报。
- 设静默窗口：發布和备份期間允许短暂报错，但要有明确的結束時間。
- 明确谁来看：每條告警有對應责任人，別只發到一個没人認领的群里。
另外，每次誤报之後花两分钟調一下規則。监控規則和内容排期一样，都是需要長期维護的東西。
收到告警之後的處理顺序
- 先確認影响范围：只有某個地域、某個机房，還是全站。
- 回忆最近的變更：發布、配置、依赖升級、DNS 調整。
- 能回滚先回滚，不能回滚就降級，比如關掉非核心功能、先切静態頁。
- 恢复後补一條记錄：現象、原因、處理動作、後續待办。
每周一次的轻量巡检
- 看一眼可用性和错誤率的周趋势，有没有缓慢恶化。
- 核對證书、域名、服務續費的時間点。
- 抽查两三個核心頁面的狀態碼和内容是否正常。
- 確認告警通道本身是通的——静默的监控也可能已经坏掉。
监控不能承诺問题不發生，它只保證問题發生时你比用戶先知道。
先把最核心的几個頁面和一條错誤率告警接上，跑两周再慢慢加。比起一次搭一套“看起来完整”的系統，能持續看、持續改的小配置更管用。