微軟 Azure 的狀態歷史頁上，9 月底連著掛出兩份事後復盤。這兩起都不算全球性大故障，但根因都很典型，值得拿來對照自己的架構。

第一起：瑞典中部的 AI 服務（追蹤編號 7QL5-Z50）

2026 年 9 月 29 日 UTC 10:03 到 15:58，瑞典中部（Sweden Central）區域的 Azure OpenAI、Foundry Agent Service、Foundry Models 和 Cognitive Services 出現間歇性請求失敗、延遲升高和 HTTP 5XX 錯誤。官方給出的根因：負責取中繼資料的後端服務遇到資料庫超時，實例達到閾值後反覆重啟，健康容量隨之下降。10:14 檢測到失敗率上升，11:29 定位到超時，15:22 擴充容量並提高資源上限，15:58 恢復。

這和我們在 9 月 3 日多個 AI 服務中斷那篇裡講的是同一類風險：你的應用本身沒出問題，但它依賴的模型介面在某一個區域裡慢了、錯了。

第二起：閘道類服務，五個區域（追蹤編號 7Q30-010）

9 月 30 日 UTC 20:30 到 10 月 1 日 UTC 02:15，ExpressRoute 閘道、Azure Firewall、Application Gateway、WAF、VPN 閘道和 Azure VMware Solution 在英國南部、法國中部、北歐、東南亞、英國西部出現連通性問題。其中「東南亞」就是 Azure 的新加坡區域。官方初步復盤的根因：區域閘道管理上的一項近期變更，在一次不相關的作業系統維護進行時觸發了過量負載，而服務因為依賴方的約束無法自動擴充容量。23:05 關聯到作業系統維護並暫停，次日 01:36 恢復推進，02:15 確認緩解。

兩件事放在一起看

  • 「機器活著」不等於「服務可達」。第二起事故里，大量虛擬機器本身可能是好的，但前面的閘道、防火牆、VPN 一斷，使用者照樣連不上。監控只看主機存活是不夠的，要從外部探測完整存取鏈路。
  • 變更和維護的疊加是老問題。單獨看哪一個都沒問題，撞在一起就出事。自己的伺服器也一樣：升級、重啟、改設定儘量錯開，並留出回退路徑。
  • 把依賴畫出來。我們在上半年當機報告那篇裡建議過先畫依賴圖：哪些請求要過哪家的哪一個區域，壞了能不能切。

對服務東南亞使用者的業務

如果你的使用者主要在東南亞，關鍵入口只放在單一廠商的單一區域，遇到這類事件就只能等。比較穩妥的做法是在另一家廠商、或另一個地區放一個能接管的入口，再配合 DNS 切換。選節點的思路見如何為業務選擇低延遲的機房節點；我們的新加坡節點可以作為這類備用入口之一。