IncidentHub 的 2026 上半年雲端與 SaaS 可靠性報告統計了 1,082 家服務商的 30,246 次中斷（1 月至 6 月），其中 5 月單月最多，達 6,070 次；雲端服務商這一類別貢獻了 86 家服務商的 4,723 次中斷。報告給整個半年下的判斷只有一個詞：相依風險（dependency risk）——故障沿著控制平面、邊緣／CDN、身分驗證、AI 介面一層層往下傳導。

三個值得記住的案例

  • Railway，5 月 19 日，約 8 小時：起因是 Google Cloud 的自動化帳號停權擊穿了它的控制平面、API 與資料庫，導致所有 Railway 工作負載無法連線——包括跑在 Railway 自有裸機和 AWS 上的那些。這類故障不是硬體壞了，而是平台的自動化政策執行，報告把它單列為一類新興風險。
  • Google Cloud，德里／孟買機房火災：印度區域相關流量出現了 21 天 12 小時的降級。全半年 GCP 只記錄了 2 次事件，但單次持續時間說明「次數少」不等於「影響小」。
  • Azure，4 月 24 日 East US 控制平面中斷超過 12 小時：原因涉及鎖競爭與容錯移轉未完成。控制平面掛掉時資料平面往往還活著，但你無法建立、擴充或修改任何資源——恰恰是事故處理最需要這些操作的時候。

另外兩個數字也值得記：Cloudflare 上半年記錄了 487 次事件（4 月最多，98 次），Hetzner 物件儲存 nbg1 與 hel1 分別出現 27 天 16 小時和 31 天 13 小時的降級。趨勢上，短時故障變得更常見——這類故障不會上新聞，但會把你的警報系統訓練成「狼來了」。

先分清控制平面和資料平面

很多人把「服務商掛了」理解成網站打不開。實際的破壞方式往往更彆扭：網站還在跑，但你什麼都改不了——不能擴充、不能改防火牆規則、不能簽發憑證、不能登入主控台。做應變計畫時，一定要分別回答兩個問題：「服務不可用怎麼辦」和「服務可用但我失去控制權怎麼辦」。

把相依關係圖畫出來（用不了半小時）

列一張表，每一列是一個第三方，三欄分別是「它掛了會怎樣」「換掉它要多久」「有沒有備選」：

  • 網域名稱解析（DNS）：最該和 CDN 分開的一項。DNS 在別處，你才有可能把流量繞過出問題的 CDN。
  • CDN／反向代理：確認來源站在沒有 CDN 的情況下能獨立提供服務——包括憑證。很多網站的來源站只對 CDN 回源 IP 開放，CDN 一掛就徹底失聯。
  • 憑證簽發：ACME 自動續期失敗時你有沒有警報？有沒有一份手動簽發的備用憑證？
  • 物件儲存與備份：備份必須至少有一份在另一家，並且做過還原演練。同一服務商內的多可用區，防不住帳號層級的問題。
  • 帳號與帳單本身：付款方式過期、聯絡信箱失效、被自動風控命中——Railway 的例子說明這條足以讓一切歸零。定期確認帳單聯絡人、付款方式和帳號驗證狀態。
  • 頻外存取：SSH 私鑰、主控台復原碼、機房工單入口，是否有一份不依賴於「先登入出問題的那家平台」的副本。

為什麼一台樸素的獨立 VPS 是有價值的兜底層

不是說自建就更可靠——單機沒有多可用區，硬體壞了就是壞了。但在一個由託管服務層層堆疊的架構裡，一台你完全掌控、能直接 SSH 進去、能獨立提供靜態頁面和基本服務的執行個體，是復原順序裡非常有用的一環：它可以是維護頁的存放處、是 DNS 切換後的臨時來源站、是備份的第二落點。SharkCloud 在日本、新加坡、香港、美國均有節點，把兜底執行個體放在與主力平台不同的服務商、不同的地區，這件事本身就是相依關係圖上最容易補的一格。