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 日劇烈波動，而 Google 什麼都沒確認》裡用的是同一條紀律：多個監測同時飄紅只能證明相關，不能證明因果。

不管根因是什麼，工程結論都一樣

如果你的產品呼叫了代管的模型 API，那就是一條硬相依：它掛了，你的功能就掛了，而你既沒有修復權也沒有知情權。這一點不因根因是 Azure、是供應商自身、還是別的什麼而改變。可以立刻落實的幾條：

  • 設死逾時。不要用 SDK 的預設值（很多是無限或極長）。一次模型呼叫超過你能接受的秒數，就應該失敗並進入降級路徑，而不是把使用者的請求執行緒掛在那裡。
  • 重試要帶指數退避和抖動，並且要能區分「限流」和「區域性故障」——後者重試再多次也沒用，只會放大雪崩。
  • 準備降級路徑。回傳快取結果、轉非同步排隊、或者給一句誠實的提示文案，都比讓介面轉圈四個小時強。
  • 把請求佇列化，讓使用者請求和模型呼叫解耦。故障期間的表現從「掉單」變成「變慢」，這是架構層面最划算的一次改動。
  • 讓供應商可切換。至少把模型呼叫抽象到設定層，能在不改程式碼的情況下切到另一家。注意：如果你打算用自架模型兜底，請先讀本批第二篇——自架元件的暴露面是另一個問題。
  • 建自己的狀態頁和告警。你應該比使用者先知道，而不是從工單裡知道。

相依清單要寫下來，而不是記在腦子裡

我們在上半年中斷模式的復盤裡建議過畫一張相依地圖：把 DNS、CDN、憑證簽發、物件儲存、帳號與帳單、帶外存取逐項列出來，標註「它掛了會發生什麼」。代管模型 API 現在也該是這張表上的一行。

一台你完全控制的獨立執行個體，在這張表裡能承擔幾個別人替不了的角色：代管狀態頁和降級頁（它不能和主要業務同生共死）、承接切換 DNS 之後的臨時來源伺服器、做一份不在同一個供應商裡的備份落點。VPS 備份策略講了怎麼讓這份副本真的可復原，CDN 是什麼、什麼時候需要講了來源伺服器與 CDN 的責任邊界。SharkCloud 在日本、新加坡、香港、美國都有節點，把兜底那一台放在另一個供應商、另一個地區，是這張相依地圖上最容易補的一格。