如何监控供应商状态页以获取故障预警

2025 年 10 月 19 日太平洋时间午夜前夕，Amazon DynamoDB 底层 DNS 自动化系统中的竞态条件导致该服务在 us-east-1 的区域终端节点留下了一条空 DNS 记录。该区域中所有依赖 DynamoDB 的服务相继报错，故障迅速蔓延至其他依赖它的 AWS 服务。根据 AWS 自己的官方复盘报告，该事故持续了约 14 个半小时。

那天早晨，许多团队自身的服务器运行状态完全正常。当他们的身份认证服务商、支付网关或邮件平台深陷泥潭时，他们自己的正常运行时间监控却依然全线飘绿。不过，大多数停机事故并没有那么波澜壮阔：你的邮件供应商发送延迟了 40 分钟，客服团队收到成堆“密码重置邮件未收到”的工单，最终有人找到了供应商的状态页——那里赫然挂着已经出现半小时的“性能降级”提示。

我在 Page Deltas 工作，这是一款监控公开网页并在发生你关心的变更时发出通知的工具；因此在下文对比其他方案时，请知悉这一点。本文将带你了解如何将其对准你所依赖的供应商状态页：挑选哪个 URL、如何编写过滤杂音的监控指令（Brief）、将告警推送到何处，以及这种方案在哪些场景下存在局限。

为什么你的监控依然全线飘绿

你的存活监控（Uptime Monitor）检查的是你自己的网站是否响应，而在外部供应商发生故障期间，你的网站通常能够正常响应。你的 APM 工具会显示对该供应商的调用报错激增，但它无法告诉你问题出在你自己的代码还是对方的服务。这正是状态页所回答的问题，而这个答案将直接决定你的下一步行动：你无需慌忙回滚一小时前刚发布的新版本，而是可以告知客服这是一个已知的外部故障，并着手准备更新你自己的系统状态页。

那么，为什么不直接在供应商的状态页上订阅通知呢？如果它能完全满足需求，你确实应该直接订阅。许多状态页基于 Atlassian Statuspage 搭建，根据供应商开启的选项提供邮件、短信、Slack、Teams 或 Webhook 订阅。但当依赖的供应商增加到第 8 家时，麻烦就来了：每项订阅都是一套独立的配置，往往散落在某位员工的个人收件箱里；每家供应商的消息格式各不相同；而且往往无法仅针对你实际使用的组件进行精准过滤。有些供应商甚至使用自研页面，根本没有提供任何订阅按钮。

网页变更监控工具为所有供应商提供了统一的标准化工作流：粘贴状态页 URL，用一句话描述你关心的内容，所有告警便会以一致的格式汇入同一个指定频道。

应该监控哪个页面？

选择展示实时当前状态的页面，通常是 status.vendor.com。切勿选择供应商的官网主页或宣传性质的“信任（Trust）”页面。绝大多数 SaaS 状态页结构大同小异：包含组件列表及其状态标识、当前活跃事故横幅、即将到来的计划维护，以及带有完整历史链接的近期事故简表。

从故障发生时客户最先感知到的核心依赖项开始。对于大多数软件团队而言，这是一份简短而清晰的清单。

如果能监控的配额有限，请从最顶部开始。支付和登录故障会在几分钟内转化为客服工单，而 CDN 变慢初期可能只反映在后台指标图表中。免费方案提供的 10 个 URL 配额足以完整覆盖这 5 行核心依赖，并留有充裕空间添加下文推荐的补充页面。

还有两个页面值得纳入考量。一是历史记录页（通常是 /history），非常适合作为核心依赖供应商的第二监控源。短时事故可能在主页两次巡检的间隙发生并恢复，但它仍会保留在历史记录中，确保你事后仍能获知情况。二是当遇到持续较长时间的重大事故时，可以临时将该事故的独立详情页添加为监控项，以便实时跟踪每次进展通报；事故解决后及时将其删除，以免占用你的 URL 配额。

快速配置指南

整个配置大约仅需 5 分钟，操作流程与我们的更新日志监控指南完全一致，只需调整监控指令的内容。

1. 创建账号并配置通知渠道

注册免费账号，打开“Channels（通知渠道）”，添加接收告警的目标平台。建议创建诸如 #vendor-status 的专属频道，避免将通知直接发进杂乱的 #engineering 频道而被信息淹没。Slack、Discord 和 Microsoft Teams 均支持 Incoming Webhook URL。在 Teams 中，右键点击频道，选择“连接器”→“传入 Webhook”→“配置”，将生成的 URL 粘贴至 Page Deltas。邮件渠道则需要收件人先确认验证邮件。配置完成后，点击各渠道旁的“Send test”以确保消息能够畅通送达。

2. 添加监控项并填写监控指令（Brief）

点击“New monitor”并粘贴状态页 URL。建议每个供应商建立一个独立的监控项，这样可以在指令中准确列出该供应商对应的具体组件名称；如果不同团队分别负责不同供应商，还可以为每个监控项绑定不同的通知渠道。

即使在风平浪静的日子里，状态页的变化频率也往往超出你的想象。正常运行时间百分比在细微跳动，“最后更新”时间戳不断后移，近期事故列表每天都会翻过新的一页并刷出一条全新的“无报告事故”空行。计划维护甚至会提前数周发布。普通的纯文本或 DOM 差分比对工具会对这些无关紧要的变化无差别触发告警。

监控项中的“Description（描述）”就是我们的大语言模型（LLM）在判断页面变化是否值得通报时所依据的提示词（Prompt）。请将其视为写给一位帮你盯盘的同事的便签。对于邮件服务商，可以这样编写：

邮件服务商的状态页。我们仅使用了位于美区（US region）的 Email API 和 Webhooks 组件。
当出现影响这些组件或该区域的新事故、事故状态或严重级别发生变化，或事故恢复时，请提醒我。如果任一组件从 Operational（正常）变为其他状态，请提醒我。
忽略正常运行时间百分比、“最后更新”时间戳、每日轮转的“未报告事故”行，以及其他区域的事故。
仅在计划维护于 48 小时内即将开始时予以通报。
请简要概述受影响的组件、当前状态以及最新更新进展。

这段“忽略（Ignore）”指令承担了绝大部分降噪工作。如果遗漏了它，你会在第一周的每天午夜因为事故列表轮转而收到大量无用通知。

对于大型公有云厂商，指定区域和具体服务名称尤为关键。公有云控制台覆盖数十个区域中的数百项服务，在普通的工作周里，随时都有某些边角服务处于降级状态。务必指明自研业务实际跑在哪些区域与核心服务上，并要求 AI 仅在这些范围受影响时发出通知。

3. 首次抓取建立基线

创建监控项后，系统很快会执行首次检查。该次抓取将作为初始基准进行存档，因此在两次巡检之间页面未发生变化的前提下，你不会在第 1 分钟收到虚假告警。检查完成后，点开监控项并查看快照截图，确认其完整捕获了你所期望的组件列表。

4. 出现异常时立即手动检查

在 Page Deltas 中你无需手动固定巡检的时间间隔。系统采用自适应调度算法：变动频繁的页面会更频繁地被抓取，付费方案在队列拥堵时享有更高优先级。状态页绝大多数时间都处于静止状态，因此当你的业务错误率骤增且你怀疑供应商故障时，只需点击监控项上的“Check now”。这一操作也可以通过 API 触发，每个监控项上限为每分钟 1 次：

curl -X POST \
  -H "Authorization: Bearer $PAGEDELTAS_TOKEN" \
  https://api.pagedeltas.com/api/monitors/$MONITOR_ID/check-now

收到告警后的应对指南

当检测到符合监控指令的变更时，你将收到一条包含自然语言摘要以及变更前后对比截图的推送通知。如果你采用签名 Webhook，接收到的请求体示例如下（其中的字段值为演示数据）：

{
  "event": "change.detected",
  "monitor_id": "01HX7Q...",
  "monitor_url": "https://status.example-mail.com/",
  "monitor_name": "邮件供应商状态",
  "change_id": "...",
  "detected_at": "2026-10-14T07:21:00Z",
  "summary": "新事故：美区邮件投递延迟。Email API 由 Operational 变更为 Degraded Performance。状态：调查中。",
  "before_screenshot_url": "https://.../before.png",
  "after_screenshot_url": "https://.../after.png",
  "dashboard_url": "https://app.pagedeltas.com/monitors/..."
}

最先看到告警的团队成员应在讨论帖中回复该事件对自研系统的具体影响。客服团队可以在客诉激增之前置顶外部已知故障的自动回复话术。值班工程师无需再耗费数小时排查根本未引入 Bug 的最新代码发布；如果故障波及终端用户，团队可抢在舆论扩散前主动更新自家的状态页。

如果你的团队深度依赖 PagerDuty 或其他事故应急工具，签名 Webhook 可以通过轻量中继服务无缝接入。由于我们的数据格式与 PagerDuty 原生格式不同，只需在无服务器函数（Serverless Function）中编写几行代码来验证签名并转发事件：

import crypto from "node:crypto";

export async function handle(rawBody, signature) {
  const expected = "sha256=" + crypto
    .createHmac("sha256", process.env.PAGEDELTAS_WEBHOOK_SECRET)
    .update(rawBody).digest("hex");
  if (signature.length !== expected.length ||
      !crypto.timingSafeEqual(Buffer.from(signature), Buffer.from(expected))) {
    return 401;
  }
  const alert = JSON.parse(rawBody);
  await fetch("https://events.pagerduty.com/v2/enqueue", {
    method: "POST",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify({
      routing_key: process.env.PAGERDUTY_ROUTING_KEY,
      event_action: "trigger",
      dedup_key: alert.change_id,
      payload: { summary: alert.summary, source: alert.monitor_url, severity: "warning" },
      links: [{ href: alert.dashboard_url, text: "Open in Page Deltas" }],
    }),
  });
  return 200;
}

请务必在解析 JSON 之前先对原始请求体（rawBody）进行哈希运算，否则签名将无法匹配。通知渠道文档详细介绍了具体技术细节。每条告警针对每个渠道仅投递一次，不设自动重试机制；因此对于不可或缺的核心供应商，建议同时绑定不同类型的第二渠道（如 Slack 加邮件），以防单一转发链路或 Slack 临时波动出现遗漏。

这种方案的局限性

这种机制反映的是供应商“公开发布”的信息，在将其作为核心依赖之前，你应当明确其固有边界。

首先，供应商的事故通报往往存在滞后。自研系统的错误监控图表往往早于状态页承认故障前就已经告警，因此应将状态页告警视为事故原因的官方佐证，而非第一道防线。同时，它绝不能取代针对自身 API 的合成监测（Synthetic Checks）或存活监控。前者告诉你系统坏了，状态页则告诉你坏掉的原因。

其次，在两次巡检之间，变更需要等到下一次轮询抓取时才会被检出，无法承诺固定的秒级精度。对于分秒必争的一两家核心供应商，建议同时保留其自身的订阅推送，并使用 Page Deltas 统一接管其余供应商。此外，我们只能抓取公开网页，对于必须登录供应商后台控制台才能看到的私有状态目前无法覆盖。

再次，我们比对的是页面文本。如果某家供应商仅通过无文字变更的彩色状态灯显示健康度，我们无法检出。Visualping 支持框选页面的特定像素区域进行比对，在那类场景下更为合适。最后，如果状态页自身发生宕机，巡检会记录为失败而非告警；连续 10 次抓取失败后，监控项将自动暂停，管理员会收到通知邮件。

从最重要的 3 家供应商开始

挑选出一旦宕机对你业务冲击最大的 3 家供应商（通常是支付、登录和邮件），输入它们的状态页 URL，结合你实际使用的组件和区域调整上述监控指令，并向 #vendor-status 发送一条测试告警。免费方案涵盖 10 个 URL 配额、AI 智能过滤、全渠道告警及 API 访问，无需绑定信用卡。免费开始监控。

Julien，Page Deltas 产品经理