站点上线之后，最怕的不是出故障，而是故障发生了自己却不知道。很多运营者第一次得知站点打不开，是收到用户截图，或者搜索流量突然下滑。可用性监控和告警看起来是运维的活，但真正决定它有没有用的，是运营侧对哪些异常值得被通知的判断。
先明确要监控哪些指标
监控不是装个探针就完事。先列出对站点有实际影响的检查项，再决定用什么工具覆盖。
- HTTP 状态与响应时间：首页、主要栏目页、关键详情页是否返回 200，首字节时间是否突然变长。
- 证书与域名：HTTPS 证书剩余有效期、域名到期时间、解析记录是否被改动。
- 服务器资源：磁盘占用、内存、连接数，尤其是日志和缓存目录把磁盘写满的情况。
- 核心依赖：数据库、缓存服务、对象存储、CDN 回源是否正常。
- 业务可用性：搜索框能不能出结果、表单能不能提交、登录是否正常。
只监控首页返回 200 意义有限。如果详情页因为数据库连接问题全部报错，首页可能依然正常。
告警配置里最容易踩的坑
阈值拍脑袋，稍有抖动就报警
响应时间设成 500 毫秒，稍微有点波动就触发，几天下来就没人看了。更稳的做法是结合一段时间的基线，比如连续三次检测超过平时峰值的 1.5 倍再通知，并且把请求失败和单纯变慢区分成两类告警。
通知只发到一个容易被淹没的地方
邮件很容易被淹没，群消息又容易被划过。至少保证有一条会真正响的通道，同时避免把同一个故障同时推到五个渠道，制造重复打扰。
没有明确谁处理
告警发到群里，所有人都看到了，但没有人认领。值班表不必复杂，但要知道工作时间和非工作时间分别找谁，以及哪些情况可以先重启服务、哪些必须上报。
把蜘蛛抓取情况一起纳入观察
对依赖搜索流量的站点来说，蜘蛛能不能正常访问，本身就是一项可用性指标。
- 观察服务器日志或站长平台数据里，抓取请求是否在某天突然归零。
- 检查是否返回大量 5xx 或 403，尤其是防爬策略调整之后。
- 留意返回给蜘蛛的页面是否被错误地缓存成验证页、跳转页。
抓取量下跌的原因可能是自身故障，也可能是对方策略调整，需要结合日志和状态码一起看，而不是看到数字下降就急着改 robots.txt。
定期做一次故障演练
监控是否真的有效，只有在故障发生时才验证得了。平时可以低成本地模拟一次。
- 临时断开某台服务器的对外服务，观察告警多久触发、内容是否准确。
- 确认收到告警的人是否真的看得懂，里面是否包含出问题的地址和时间。
- 记录从告警到恢复的耗时，看看瓶颈在检测、通知还是处理环节。
- 演练结束后恢复配置，并检查是否残留临时规则。
监控之外还要补的几件小事
监控工具会有额度限制，也会有误报，别把它当成唯一依据。定期手动打开几个重要页面，尤其是在改版、迁移、更换服务器之后；把域名、证书、第三方服务的到期时间记在同一个日历里；告警历史留档，方便回头查某个时间点到底发生了什么。
能收到告警不代表监控做对了，能在一分钟内判断这是什么问题、该找谁、要不要马上处理，才算真正可用。