营销站群健康检查落地：5步设置探测项与故障分级

营销网站集群的自动健康检查与故障分级规则，重点不是让每个页面都频繁请求，而是尽早发现访客真正会遇到的故障，并让告警对应到明确的处理动作。以下五步适用于由多个域名、落地页或应用组成的站点集群，阈值应根据业务时段和实际基线调整。

第一步：列清站点和关键路径

先建立一份站点清单，至少记录域名、负责人、主要用途、重要页面和依赖服务。将站点分成核心入口、活动页面、普通内容页等类别；不要把所有页面都设成同一优先级。

每个站点挑出少量有代表性的检查对象：主页或主要落地页、一个重要表单、必要时再加一个登录或查询流程。对活动页面，可在发布前加入清单，结束后及时移除，避免旧页面持续触发无效告警。

第二步：设置能代表用户体验的探测项

1. 可达性：请求 HTTPS 页面，检查连接是否成功、返回状态码是否符合预期，以及最终页面是否包含稳定的标题或关键文字。仅检查服务器能否响应，可能漏掉空白页或错误内容。
2. 证书与跳转：检查证书是否有效、到期时间是否接近，并确认 HTTP 到 HTTPS、旧路径到新路径的跳转符合预期。证书提醒可先设为到期前约14天和7天，团队应根据续期流程调整。
3. 关键交互：用合成交易模拟填写表单并到达成功确认页。使用专门的测试数据；若流程会产生真实订单、短信或费用，应改在测试环境验证，或仅检查不会造成实际提交的环节。
4. 性能表现：记录页面响应时间和失败率，先观察正常时段的基线，再为超时设置门槛。页面复杂度、探测地点和网络状况都会影响结果，不宜直接套用一个适合所有站点的固定毫秒数。

探针监控可采用 Prometheus Blackbox Exporter 配合 Prometheus，或使用 Uptime Kuma 做较轻量的状态检查；前者便于与指标和告警规则整合，后者设置相对直观。无论选哪种，都要确认探测频率、重试次数和维护时段可配置。

第三步：用基线设阈值，避免一跳就报警

初始阶段可每1至5分钟检查一次公开页面，具体间隔取决于故障影响、探测成本和告警响应能力。关键流程可采用较短间隔，普通页面则不必过密。连续失败两次再告警，通常比单次失败更能过滤短暂网络波动；紧急业务也可设置单次失败通知值班人，但要保留后续复核。

性能阈值建议从一至两周的正常数据起步，分别观察高峰与低谷。可把持续高于自身常态的响应时间、连续错误率上升作为告警条件，而不是把偶发慢请求当作故障。使用 Prometheus 时，可按站点标签汇总失败率；配合 Grafana 查看趋势，再由 Alertmanager 控制通知和重复提醒。

第四步：按影响范围划分故障等级

等级应结合影响面、持续时间和功能重要性，不只看故障数量。例如，单个高价值入口失效可能比多个普通页面变慢更紧急。营销网站集群的自动健康检查与故障分级规则应写明升级条件；像“连续失败两轮”或“核心站点同时异常”这样的门槛，应由团队按实际规模校准。

第五步：接好通知，并定期验证

1. 为每个站点绑定维护负责人和备用联系人，P1、P2通知进入值班渠道，低等级提醒进入工单或日常看板。
2. 设置告警恢复通知和重复提醒间隔；发布维护期间使用明确的静默窗口，结束后确认探测已恢复。
3. 每月抽查探针是否仍覆盖有效页面，并通过受控方式模拟超时或错误状态，验证通知能否到达负责人。
4. 故障结束后记录发现时间、影响对象、原因和改进项；若同类误报反复发生，调整探测目标或阈值，而非简单关闭告警。

落地时先覆盖少数核心站点，再逐步扩展到其余页面。把站点清单、探测配置、值班人和等级标准放在同一处维护，营销网站集群的自动健康检查与故障分级规则才会在故障发生时真正可用。

常见问题

健康检查应该多久执行一次？

公开页面可从每1至5分钟一次开始评估；核心流程可更频繁，前提是探测负载和告警处理能力能够承受。

只检查首页够不够？

不够。首页正常不代表表单、登录或关键跳转正常。至少为核心站点增加一项能代表主要用户任务的检查。

测试表单会不会产生真实业务数据？

可能会。使用测试环境或专用测试数据，并确认流程不会触发实际订单、费用或对外通知；无法安全提交时，只检查提交前的关键步骤。

什么时候应该升级故障等级？

当影响范围扩大、核心流程持续失败，或原定恢复时间无法满足时，应按团队约定升级，并同步已确认的影响与处置进度。