很多站点出问题，第一个知道的不是站长，而是搜索蜘蛛。日志里那串 5xx 是它留下的记录，等到自己发现，往往已经过去几个小时甚至几天。把可用性监控当成站点运营的固定动作，目的不是追求零故障，而是把故障的发现时间从「天」压缩到「分钟」。
监控别只盯着首页
首页能打开，不代表整站正常。常见的故障形态是：首页走了缓存或静态化，一直好好的，详情页却因为数据库连接池打满、附件目录挂载失败而整片报错。所以监控地址要有代表性。
- 首页：最基础的一层，但要留意是否被缓存掩盖了后端故障。
- 每个一级栏目：至少各取一个入口地址，确认栏目页能正常渲染。
- 详情页：随机取几条近期发布的内容，验证数据库和模板链路。
- 列表与分页：翻到第二页、第三页，不少分页逻辑的边界问题就藏在这里。
- 静态资源：CSS、JS、图片各取一个，确认 CDN 回源和对象存储正常。
- 对外接口：如果有 API 或站内搜索接口，单独加一条探针。
返回 200 不等于页面正常
比 5xx 更隐蔽的是软错误：服务器返回 200，正文里却是一段「系统维护中」或「内容不存在」的模板。监控工具只看状态码，会认为一切正常。
- 在响应正文里检查一个只应出现在正常页面上的标记，比如页脚版本号或某个固定模块。
- 设置正文长度下限，突然缩到几百字节通常意味着模板出错。
- 对关键地址校验标题或主要区块是否为空。
告警设置：宁可迟一点，也别天天误报
告警太吵，最后一定被忽略。几条经验：
- 用连续失败次数触发，而不是单次失败，例如连续 3 次、间隔 1 分钟。
- 按严重程度分层：全站不可用走即时消息或电话，单条地址异常走邮件。
- 区分探测节点与内容地区的差异，避免因探测机自身网络抖动而误报。
- 发布、重启等计划内动作，提前设置维护窗口静音。
从发现到恢复，按顺序来
- 确认范围：是单个地址、一个栏目，还是整站；是只影响外网，还是内网同样异常。
- 回看最近变更：代码发布、配置修改、证书更新、DNS 调整按时间线排一遍，多数故障都能对上号。
- 优先恢复：能回滚就先回滚，别在现场边查边改。
- 检查抓取影响：恢复后观察一段时间日志，确认错误响应停止、蜘蛛是否已经回来。
- 留下记录：时间、现象、原因、处理动作写进同一份文档，下次同类问题能省一半时间。
把监控结果变成月度习惯
每周或每月导出一次可用性报表，看一眼趋势：响应时间是缓慢上升还是平稳，错误有没有集中在某个时段、某个栏目。缓慢上升的响应时间通常比一次宕机更值得关注，因为它不会触发告警，却会持续影响抓取和访问体验。把这些数据和抓取日志对照着看，比单独盯一份报表有用得多。
监控的意义不是证明站点没问题，而是在出问题时，让你比蜘蛛先知道。