2026 年 9 月 3 日，多个 AI 服务在同一时段出现异常。这件事值得写，不只是因为影响面，而是因为它又一次示范了「第三方观察」和「厂商确认」之间的距离——这个区分决定了你复盘之后会把钱和人投到哪里。

已确认的部分

  • OpenAI 的状态页标记了 ChatGPT 与 Codex「错误率升高」。这是一手来源。
  • Downdetector 的用户上报量从 5,000 多条一路涨到 74,000 条以上，是当年该平台上 AI 服务较大的一次上报峰值。
  • 故障窗口大致在美国东部时间 10:58 到 14:56，接近四个小时。
  • 9 月 4 日早间，第三方监测显示 ChatGPT 与 Codex 已恢复正常。

只是归因、尚未被一手来源证实的部分

多家媒体把同时段多家 AI 服务的异常归因于 Azure East US 区域故障，并称 Claude 与 Grok 在同一窗口受影响，而运行在 Google Cloud 上的 Gemini 峰值上报量仅约 500 条。

但截至本文写作时，微软公开的 Azure 状态历史页并没有列出 2026 年 9 月对应的 East US 事件——该页当时可见的最近一份事后复盘，是 2026 年 7 月 23 日 West US 的网络连通性问题（跟踪号 ZJV6-SGG）。

这不代表媒体报道是错的，厂商的事后复盘经常要几天甚至几周才公开。它代表的是：在你看到一手确认之前，这条因果链只能记作「据报道」，不能当成事实写进你的架构决策。这和我们在《排名在 8 月 1 日到 3 日剧烈波动，而谷歌什么都没确认》里用的是同一条纪律：多个监测同时飘红只能证明相关，不能证明因果。

不管根因是什么，工程结论都一样

如果你的产品调用了托管的模型 API，那就是一条硬依赖：它挂了，你的功能就挂了，而你既没有修复权也没有知情权。这一点不因根因是 Azure、是供应商自身、还是别的什么而改变。可以立刻落实的几条：

  • 设死超时。不要用 SDK 的默认值（很多是无限或极长）。一次模型调用超过你能接受的秒数，就应该失败并进入降级路径，而不是把用户的请求线程挂在那里。
  • 重试要带指数退避和抖动，并且要能区分「限流」和「区域性故障」——后者重试再多次也没用，只会放大雪崩。
  • 准备降级路径。返回缓存结果、转异步排队、或者给一句诚实的提示文案，都比让界面转圈四个小时强。
  • 把请求队列化，让用户请求和模型调用解耦。故障期间的表现从「丢单」变成「变慢」，这是架构层面最划算的一次改动。
  • 让供应商可切换。至少把模型调用抽象到配置层，能在不改代码的情况下切到另一家。注意：如果你打算用自托管模型兜底，请先读本批第二篇——自托管组件的暴露面是另一个问题。
  • 建自己的状态页和告警。你应该比用户先知道，而不是从工单里知道。

依赖清单要写下来，而不是记在脑子里

我们在上半年中断模式的复盘里建议过画一张依赖地图：把 DNS、CDN、证书签发、对象存储、账号与账单、带外访问逐项列出来，标注「它挂了会发生什么」。托管模型 API 现在也该是这张表上的一行。

一台你完全控制的独立实例，在这张表里能承担几个别人替不了的角色：托管状态页和降级页（它不能和主业务同生共死）、承接切换 DNS 之后的临时源站、做一份不在同一个供应商里的备份落点。VPS 备份策略讲了怎么让这份副本真的可恢复，CDN 是什么、什么时候需要讲了源站与 CDN 的责任边界。SharkCloud 在日本、新加坡、香港、美国都有节点，把兜底那一台放在另一个供应商、另一个地区，是这张依赖地图上最容易补的一格。