很多站点出问题，第一个知道的人不是运营，而是用户。等投诉来了再去看，故障可能已经持续了几个小时，蜘蛛也在这段时间里反复抓到 5xx，抓取节奏被打乱。可用性监测不是大厂才需要的东西，一个便宜的探测服务加上几个关键地址，就能把“事后救火”变成“事前知道”。
先想清楚：监测的目标不是绿点，而是可访问
监测工具给出的绿色打勾，只能说明探测节点拿到了响应。至于拿到的是正常页面、错误页还是登录墙，需要你自己定义。建议至少把这几个地址列进监测清单：首页、一个核心栏目页、一个内容详情页、站点搜索或表单入口（如果对外可访问）。如果你的站点有多个域名或子域，主站之外还要覆盖主要入口。
监测内容：状态码之外还要看什么
- HTTP 状态码：5xx、连续 404，以及被误配置成 200 的错误页。
- 响应时间：单次波动没意义，看趋势。响应从 200ms 涨到 3s，通常意味着数据库或后端出了问题。
- HTTPS 证书有效期：证书过期是全站不可访问，而且往往发生在周末。
- DNS 解析：解析异常会同时影响用户和蜘蛛，表现像“整个站消失”。
- 静态资源：CDN 回源失败或图片域名挂掉时，页面骨架还在，用户看到的是残缺页面。
探测节点与频率：别只从一个地方看
只用一个探测节点，等于用一个用户的视角代表所有人。运营者所在网络正常，不代表其他地区正常。选择监测服务时，留意它是否有多个地域节点，以及是否支持从不同运营商发起请求。频率上，1 分钟一次适合核心页面，栏目页 5 分钟一次就够了。频率太高既浪费资源，也容易把偶发抖动变成一堆无效告警。
告警：能叫醒人的规则才是好规则
告警太吵，人就会麻木，最后所有告警都被静音。建议做两件事：一是加“连续失败次数”条件，比如连续 3 次失败才通知，过滤掉瞬时抖动；二是分级，核心页面走电话或即时通讯，次要页面走邮件汇总。同时把告警发给多人，避免唯一的接收人刚好在飞机上。
收到告警后的处理顺序
- 先确认范围：只有自己访问不了，还是多个探测节点都失败。
- 看最近变更：是否刚发布代码、改过服务器配置、调整过 DNS 或 CDN。
- 检查依赖：数据库、缓存、对象存储、第三方接口，哪一环先断的。
- 先恢复再排查：回滚或切到备用节点让站点先能访问，根因分析放到之后做。
- 记录时间线：故障开始、发现、处置、恢复的时间点，方便后续复盘。
几个常被忽略的细节
- 监测地址用正式域名，不要用内网 IP 或带调试参数的地址，否则测的不是用户看到的页面。
- 错误页本身也要能正常返回，别让错误页再触发一次错误。
- 维护窗口提前在监测里设置，避免计划内操作触发一堆告警。
- 把监测结果和服务器日志对照，确认蜘蛛抓取失败是否也集中在同一时间段。
可用性监测解决的是“知不知道”，不解决“为什么”。它不能替代日志分析、性能优化和内容运营，但它是其他运营动作的前提——站点打不开，后面的事都无从谈起。
如果现在还没有任何监测，先从首页加一个探测开始，把告警发到自己能第一时间看到的渠道，跑一周看看误报多不多，再决定要不要扩到栏目页和证书到期提醒。这件事成本不高，但能省下很多“用户比你先发现问题”的尴尬。