11 月 18 日晚間，Cloudflare 全球多項服務包含 CDN、Access、WARP、Dashboard 等功能，陸續出現大範圍異常，影響眾多網站與使用者的連線品質。
這類雲端大型服務商的事故並非第一次出現。過去幾年，我們也曾看過 Facebook 大當機、CrowdStrike 造成全球系統中斷、Microsoft 更新問題、重大漏洞事件等。
在今日高度依賴云端服務的環境中，任何單點故障（Single Point of Failure, SPOF）都可能導致整體服務中斷。
這次事件，再次提醒企業：
網站或應用服務，必須具備 備援計劃。
為什麼 Cloudflare 異常會讓網站無法連線？
多數企業的網站導入 Cloudflare 主要是為了：
- CDN 加速
- DDoS 防護
- WAF 防火牆
- 雲端 Proxy
- Access 驗證與 Zero Trust
- 防洩露 IP 的反向代理
然而，一旦這些功能同時失效（甚至只失效其中兩項），網站可能出現：
- DNS 解析延遲
- 靜態檔案無法載入
- 完整網站拒絕連線
- 後端服務雖正常，但前端入口完全堵塞
這些都是典型的單點故障會導致的風險。
為什麼企業架構必須具備備援計劃？
在我們過往服務半導體廠、醫療院所、政府單位與國家級網路環境的經驗中，
“等待恢復（Wait for Recovery）從來不是選項”。
成熟的架構必須至少具備：
✔ 多路徑（Multi-Path）
例如多家 DNS / 多個 Proxy Provider。
✔ 備援計畫（Fallback Plan）
例如 Cloudflare 失效時，能立即自動切換到後備路徑。
✔ 可觀測性（Observability）
異常必須能被即時偵測，而不是依靠客服電話或使用者回報。
沒有以上基本要素，網站就會在單點故障時陷入完全癱瘓。
企業可以如何降低單點故障風險？
以下是我們在架構設計中常用的策略，皆適用於任何規模的企業：
1. 多 DNS 架構（例如：Cloudflare + Route53）
單一 DNS Down 仍能保持對外可解析。
2. 多入口（例如：Cloudflare + Fastly 或 Cloudfront）
避免前端 Proxy 成為單點。
3. 自動 Fallback / Bypass 機制
一旦 CDN 層異常，自動改走最原始來源（Origin）。
4. 監控外部路徑而非只監控後端伺服器
因為這類事件中，後端伺服器往往根本沒問題。
我們對客戶網站所做的第一件事
Cloudflare 異常發生後，我們第一時間針對客戶網站進行測試，啟動備援機制，
確認所有客戶網站皆正常運作，並未受到此次異常影響。
這正是備援機制的價值所在。
結語：雲端會出問題，但架構不能跟著一起倒
全球性的雲端異常層出不窮，這是現代 IT 的常態。
然而企業的網站、API、後端系統，卻不該因單一服務商異常而全面停擺。
如果您的網站或服務目前：
- 只有單一入口
- 完全依賴 Cloudflare
- 沒有備援機制
- 需要架構健檢
我們很樂意協助您規劃一套更堅韌的、高可用的架構。
