在承诺客户 SLA 积分之前构建 AI API 中断证据分类账

当上游模型提供商发生事件时，您的客户不仅会询问该提供商是否已停机。他们会询问他们的请求是否失败、哪些密钥和模型受到影响、中断是否会影响您的 SLA，以及他们应该获得什么信用。提供商状态页面会有所帮助，但它本身无法回答这些特定于租户的问题。

AI API 网关应将中断证据视为一流分类账：提供商信号、综合探测结果、请求级症状、租户影响窗口、归因决策和信用调整。我们的目标不是创建一个更漂亮的事件时间表。目标是使面向客户的中断决策可解释、可重复，并防止过度信用和信用不足。

提供商状态页可以证明什么、不能证明什么

事实： Atlassian Statuspage 公开公共 API 端点，用于摘要、状态、组件、未解决的事件、事件和计划维护。 OpenAI 和 Anthropic 发布包含组件和事件数据的 Statuspage-style JSON 端点。 Google Cloud 记录服务运行状况 API 和仪表板，并通过 Feed 公开公共健康信息。云提供商还会发布某些事件的事后评论。

这些 Feed 是有用的输入。他们可以告诉您提供商承认了一个事件，哪个广泛的组件受到了影响，以及事件何时经历调查、识别、监控、解决或事后分析等状态。它们不足以决定 AI API 经销商运营 计划的客户信用。

状态页面通常滞后于真正的客户影响。它们可能描述广泛的组件，例如聊天、响应、嵌入、图像或文件，而没有清晰地映射到模型别名、提供商帐户、区域、部署、服务层或租户白名单。他们也无法告诉您特定客户的请求是否因上游降级、网关限制、预算耗尽、输入无效、客户端超时行为或本地网络问题而失败。

建议：将提供商状态用作一个证据流，而不是信用触发器。积分应取决于租户影响证据以及请求日志、使用结算和提供商事件更新可用后的对账结果。

您需要的账本记录

从持久的中断记录开始，该记录可以代表提供商范围内的事件和特定于租户的影响。该记录应仅附加或版本化，以便以后的分类更改不会删除原始检测跟踪。

{
  "incident_id": "inc_2026_05_29_openai_azure_eastus_latency",
  "provider": "azure_openai",
  "provider_account_id": "acct_prod_shared_01",
  "surface": "chat_completions",
  "model_or_deployment": "gpt-4o-prod-eastus",
  "region": "eastus",
  "source_signals": ["provider_status", "synthetic_canary", "request_symptoms"],
  "confidence": "confirmed",
  "provider_started_at": "2026-05-29T11:42:00Z",
  "provider_acknowledged_at": "2026-05-29T12:05:00Z",
  "detected_at": "2026-05-29T11:45:11Z",
  "mitigated_at": "2026-05-29T12:31:44Z",
  "recovered_at": "2026-05-29T12:48:00Z",
  "affected_tenant_ids": ["ten_123", "ten_456"],
  "linked_request_ids": ["req_a", "req_b", "req_c"],
  "credit_policy_version": "sla_2026_04",
  "credit_status": "pending_reconciliation"
}

提供商事件时间和租户影响时间是不同的字段。提供商可能会在 11:30 到 13:00 之间报告广泛的事件，但一个租户可能不会受到影响，因为其允许的模型使用了另一家提供商。另一个租户可能仅在 11:47 到 12:18 期间出现故障，因为路由将其转移到后备模型。第三个可能经历了高延迟，但没有失败的请求。当积分变成金钱时，这些差异就很重要。

提取三个证据流

1.提供商状态 API

在事件发生期间按计划和按需收集提供商状态数据。存储原始有效负载哈希、检索时间、提供程序组件标识符、事件状态、事件 URL 或提供程序引用以及任何文本摘要。不要覆盖旧状态。如果事件从调查到识别再到监控，请保留每个转变。

将提供商组件标准化为您自己的网关维度：

• 提供商：OpenAI、Anthropic、Azure OpenAI、Google 或其他上游
• 表面：聊天、响应、嵌入、图像、批量、音频、实时、文件、审核
• 模型或部署：上游模型、内部别名或云部署名称
• 区域：如果适用
• 帐户或凭据池：共享帐户、租户绑定帐户或 BYOK 凭据
• 服务层：标准、优先级、配置、批量或内部层名称

权衡：提供者状态获取成本低廉且对于确认而言具有权威性，但可能会延迟、范围广泛或不完整。它应该引起怀疑并有助于客户沟通，但不应自动产生积分。

2.合成金丝雀

合成金丝雀是通过与生产流量相同的网关路径发送的小型受控请求。它们应该涵盖您销售的组合，而不是所有可能的提供商功能。例如，经销商可以为付费计划使用的每个提供商、表面、模型层和区域运行金丝雀。

每个金丝雀结果应包括：

• canary_id和计划版本
• 提供商、表面、模型、区域、凭据池和路线配置文件
• 开始时间、第一个字节时间、完成时间和超时阈值
• HTTP 状态、提供商错误代码、网关错误代码和重试次数
• 延迟百分位数桶，不仅仅是通过或失败
• 请求相关 ID 和经过编辑的响应元数据

Canary 应避免原始的客户提示。使用固定的、不敏感的提示并保持响应验证简单。金丝雀可以验证端点是否接受请求、流是否完成以及延迟是否保持在阈值内。它不需要判断中断信用决策的模型质量。

权衡：金丝雀在客户报告问题之前提供独立证据。它们还会增加成本，并可能在提供商压力期间消耗配额。在活动事件期间限制金丝雀并避免导致上游负载的激进重试行为。

3.真实请求症状

请求级证据是租户影响的最强来源。每个网关请求都应该已经具有租户、密钥、用户或最终用户标识符、模型别名、提供商路由、区域、状态、延迟、令牌使用情况和计费状态。对于中断报告，添加分类字段，将上游症状与客户和网关原因分开。

有用的症状类别包括：

• provider_5xx：上游HTTP 5XX 或同等提供商服务器错误
• provider_timeout：网关超时之前提供商没有响应
• provider_429_spike：上行速率限制高于正常基线
• stream_abort_upstream：提供程序流意外结束
• latency_degraded：已完成的请求超出了政策阈值
• gateway_throttle：网关由于租户限制或公平政策而拒绝请求
• customer_error：请求无效、模型不受支持、身份验证错误或负载格式错误
• budget_exhausted：租户支出或信用额度阻止调度

通常只有前五个应该算作中断症状，即使如此，也只能在归因之后才算作中断症状。上游 429 的峰值可能是提供商问题，但也可能是由一个租户超出其预留吞吐量引起的。超时可能是提供程序降级，但也可能是由于客户端断开连接或比网关超时短的应用程序级超时造成的。

这就是团队的多模型API网关需要严格的事件建模的地方。路由决策、重试尝试、回退结果、最终响应和计费结算应该可以通过关联 ID 连接起来。

将提供商事件窗口与租户影响窗口分开

请勿将提供商的广泛事件持续时间归功于客户。根据您的政策，将影响其合格流量的事件部分归功于他们。

至少使用五个窗口标记：

• 检测时间：系统首次检测到异常行为的时间
• 第一个受影响的请求：第一个出现中断症状的符合条件的租户请求
• 提供商确认时间：上游提供商发布或确认事件的时间
• 缓解时间：当您的网关应用回退、流量调整、路由禁用或其他缓解措施时
• 恢复确认：当金丝雀和实际流量返回低于阈值时

可以按租户、每个键、每个模型别名和每个服务层计算租户影响窗口。例如：

tenant_id: ten_123
model_alias: support-fast
eligible_requests: 842
failed_provider_requests: 96
degraded_latency_requests: 211
first_affected_at: 2026-05-29T11:47:08Z
last_affected_at: 2026-05-29T12:22:31Z
mitigation_applied_at: 2026-05-29T12:04:19Z
credit_status: provisional

这种分离还可以防止您过度信用。如果租户在提供商事件期间没有流量，则可能没有信用。如果租户仅路由到不受影响的模型，则可能没有信用。如果所有失败都是无效请求或预算拒绝，则事件报告应如此说明，而不要责怪提供商。

在事件发生前定义信用政策

信用政策应该是一个表格或版本化配置，而不是在压力下临时做出的支持判断。该政策不需要完全自动，但应明确资格和审批规则。

包含这些字段：

• 符合条件的症状：提供商 5XX、上游超时、流中止、延迟严重下降或其他类别
• 最短持续时间：例如，连续五分钟或受影响请求的阈值数量
• 延迟阈值：固定阈值、百分位数基线或特定于服务层的目标
• 排除的原因：客户错误、预算耗尽、租户限制、格式错误的请求、不受支持的模型、客户端断开连接
• 重试处理：成功的回退请求是否算作失败、降级或缓解
• 积分公式：受影响的使用百分比、固定钱包调整、基于计划的 SLA 积分或人工审核
• 审批权限：低于限额自动审批，高于限额运营审批，大租户财务审批
• 提供商信用处理：传递、共享、保留或与客户信用分开处理
• 证据保留：事件、请求、金丝雀和信用记录保持可查询的时间长度

建议：存储每个临时和最终信用决策的信用政策版本。如果您稍后修改政策，历史决策仍应说明当时应用了哪些规则。

在最终制作人员名单之前进行核对

在事件发生期间，客户需要快速更新状态。信贷决策可以是临时的。最终信用传递应在日志完成、延迟使用事件解决、重试和回退分类以及提供商事件后信息已审核后进行。

实用的调节工作流程如下所示：

1. 根据提供商状态、金丝雀警报或请求症状阈值创建或更新事件记录。
2. 冻结受影响的路由配置文件或将其标记为降级，以便新的路由决策可以尽可能避免它。
3. 根据请求日志和金丝雀时间表生成临时租户影响窗口。
4. 使用分类规则排除客户端和网关端原因。
5. 连接使用情况和结算记录，以便将受影响的请求与已结算的成本和客户费用记录相关联。
6. 应用信用政策版本并生成临时信用行。
7. 检查不明确的案例，尤其是部分延迟下降和高价值租户。
8. 将最终信用调整发布到钱包或发票分类账，并提供返回事件记录的链接。

这将中断处理与统一 AI API 计费 联系起来，而不是在支持票证中将积分保留为手动注释。调整应该是可审核的：谁批准了调整、应用了哪些政策、哪些请求符合条件以及调整是最终的还是可逆的。

展示客户和合作伙伴API视图

客户需要清晰的事件解释，而不是整个内部跟踪存储。转售或嵌入您的 API 的下游平台可能还需要在自己的门户内显示事件状态。合作伙伴 API 端点可以公开租户范围的事件视图。

GET /partner/incidents/{incident_id}/tenant-impact?tenant_id=ten_123

{
  "incident_id": "inc_2026_05_29_openai_azure_eastus_latency",
  "status": "final",
  "summary": "Elevated upstream latency and intermittent failures affected selected chat requests.",
  "affected_windows": [
    {
      "model_alias": "support-fast",
      "first_affected_at": "2026-05-29T11:47:08Z",
      "last_affected_at": "2026-05-29T12:22:31Z",
      "eligible_failed_requests": 96,
      "eligible_degraded_requests": 211
    }
  ],
  "affected_keys": ["key_live_abc"],
  "credit_status": "applied",
  "credit_adjustment_id": "adj_789",
  "evidence": {
    "canary_ids": ["canary_chat_eastus_01"],
    "sample_request_ids": ["req_a", "req_b"]
  }
}

保持此视图的范围。包括合成金丝雀 ID、请求相关 ID、受影响的模型、受影响的密钥和最终信用状态。默认情况下避免原始提示和完整响应正文。如果客户需要更深入的证据，请提供包含编辑和授权检查的受控导出。

客户事件报告模板

如果分类账完整，那么有用的客户报告可能会很短。它应该区分已确认的事实和可操作的解释。

事实

• 受影响的提供商和表面
• 租户影响窗口
• 符合条件的失败、超时、中止或降级请求的数量
• 受影响的模型别名、区域和客户密钥
• 已应用缓解措施和恢复确认时间

网关评估

• 症状是否归因于提供商、网关、租户配置或客户请求行为
• 后备路由是否减少了影响
• 事件是否符合信用政策阈值
• 信用是临时的、已批准的、已应用的还是被拒绝的

限制

• 提供者事件详细信息可能会在事后发布后发生变化
• 延迟降低阈值是由策略定义的，而不是通用的
• 因客户错误或预算拒绝而排除的请求不计入提供商中断影响

预测和设计赌注

预测：面向客户的中断报告将成为 AI API 经销商平台的正常功能，特别是对于在自有品牌下公开 AI 功能的 SaaS 供应商而言。随着 AI 工作负载从实验转向生产，客户将期望从云基础设施供应商那里获得相同的事件责任。

预测：提供商状态页面仍然是必要的，但还不够。更多事件将涉及部分降级：延迟峰值、流传输中断、区域容量问题、质量回归、工具调用失败或特定于账户的配额行为。这些案例需要请求级和租户级证据。

建议：在承诺强大的 SLA 信用之前先构建分类账。在有争议的中断后改造事件证据的成本很高，而且往往没有结论。

可行的结论

不要让提供商状态页面成为客户信用的唯一真实来源。构建一个中断证据分类账，将提供商事件源、合成金丝雀、请求症状、路线决策、租户影响窗口、计费记录和最终信用调整结合起来。

最低有用版本很简单：提取提供商状态 JSON，为已售模型区域层运行低容量金丝雀，按原因对请求失败进行分类，计算租户影响窗口，并在协调后应用版本化信用政策。这为支持、财务、工程和下游合作伙伴提供了相同的证据基础。它还可以让您解释事件，而无需在客户投诉时盲目地镜像上游状态页面或发放手动商誉积分。

相关阅读

• 面向客户的使用情况和调整报告