在設計現代分散式系統時，工程師最恐懼的噩夢莫過於「連鎖崩潰」。這種現象在土木工程中被稱為「漸進式崩潰」（Progressive Collapse），指的是系統中一個微小的局部失效，在缺乏適當緩衝的情況下，觸發一連串的後續故障，最終導致整個系統的大規模癱瘓。
這類故障最危險的地方在於其「不成比例性」：初始的觸發因素看起來微不足道，但其產生的影響卻呈指數級擴大。根據 Sam Newman 在 QCon 的分享，我們可以從現實世界的建築災難與雲端服務故障中，提取出提升系統韌性（Resilience Engineering）的核心策略。
背景：從建築災難看連鎖崩潰
漸進式崩潰的概念在 1968 年的倫敦 Ronan Point 大樓事故中得到了慘痛的體現。當時一名住戶廚房發生了小規模的瓦斯爆炸，從能量級別來看，這本應是一個可生存且影響範圍極小的事故。然而，由於該建築採用了快速搭建的預製板系統，且施工品質低劣（部分接縫甚至用報紙填充而非混凝土），導致承重牆被炸毀後，上方四層樓像手風琴一樣接連坍塌。
這個案例揭示了連鎖崩潰的本質：當系統缺乏冗餘路徑且組件之間過度依賴時，單點故障會迅速演變為全局災難。這種邏輯同樣適用於數位系統。例如 AWS us-east-1 區域曾發生過一次重大故障，起因是 DynamoDB 的一個子系統在更新 DNS 路由時發生了競態條件（Race Condition，指多個進程競爭資源導致結果不確定），導致 Route 53 的 DNS 記錄被誤刪。由於大量 AWS 內部服務與外部客戶（如 Slack, Zoom）都依賴這些路由，故障迅速擴散，導致網路負載平衡器、計算資源與佇列服務接連失效，最終造成大範圍的服務中斷。
核心策略：緩解連鎖崩潰的三大維度
要防止系統陷入漸進式崩潰，不能僅僅依賴於尋找單一的「根因」（Root Cause），因為複雜系統的失效通常是多種因素共同作用的結果。韌性工程的核心在於：接受故障必然會發生，並致力於將其影響範圍控制在可接受的程度內。
第一，減少危險源（Reduce Hazards）
最直接的方法是移除可能導致災難的觸發因素。在建築案例中，這意味著禁止在高層建築中使用瓦斯；在軟體系統中，則可以是暫時關閉有缺陷的自動化功能，或實施負載脫卸（Load Shedding）。負載脫卸是指當系統達到負荷上限時，主動捨棄部分非核心請求，以確保系統不會因為資源耗盡（如 CPU 飽和或記憶體溢出）而完全崩潰。
第二，強化組件（Strengthen Components）
強化組件旨在提高單一模組的生存能力。在雲端架構中，這通常體現為增加冗餘（Redundancy）。例如，透過負載平衡器部署多個服務實例，確保單個實例失效時服務仍能運行。
對於更高層級的韌性需求，企業會考慮多區域（Multi-region）或多雲（Multi-cloud）部署。這類方案在降低停機時間與數據損失窗口（RPO/RTO）方面效果顯著，但會顯著增加成本與複雜度。Newman 提醒，雙向數據同步（Two-way synchronization）在實作上極其困難，企業在追求極高可用性時，必須在成本、複雜度與風險之間做出權衡。
第三，降低互連性（Reduce Interconnection）
降低互連性的目的是建立「隔艙」（Bulkheads），防止故障在組件間傳播。這就像潛水艇的設計，即使某個艙室破裂進水，只要關閉隔艙門，船體仍能保持浮力。
在分散式系統中，具體的實作手段包括： 獨立連接池：為不同的下游服務配置獨立的連接池，避免單一緩慢服務耗盡所有執行緒，導致其他正常服務無法運作。 斷路器（Circuit Breakers）：當偵測到某個服務故障率過高時，立即切斷請求，讓系統進入快速失敗（Fail Fast）狀態，避免請求堆積導致雪崩。 獨立實作：極端情況下，如金融業 Monzo 銀行，會為核心功能建立一套完全不共用代碼、架構不同的備用系統，以防止同一個 Bug 在主備系統中同時觸發。
技術脈絡與實務限制
雖然上述手段能提升韌性，但這裡存在一個悖論：為了處理故障而引入的複雜度，本身可能成為新的故障源。
以斷路器為例，若配置不當，可能會導致「部分失效」演變為「全面不可用」，或在恢復期間引發重試風暴（Retry Storms）。同樣地，AWS 的 DNS 故障正是因為為了提高可用性而部署了多個 DNS 執行器，結果卻因為併發處理而觸發了競態條件。
因此，韌性工程要求團隊在採取任何保護措施前，必須進行意識清醒的決策，而非盲目跟風。多雲部署是否必要？斷路器是否適配？這些問題應基於業務對數據損失的容忍度與維運能力來決定，而非單純追求技術上的完美。
影響與啟示
連鎖崩潰的教訓告訴我們，系統的安全性不在於「永不失敗」，而是在於「如何優雅地失敗」。從 Ronan Point 的建築調查到 AWS 的事後分析報告（Post-mortem），透明的故障分析是整個產業進步的基石。
對於現代開發者而言，隨著 AI 代理（AI Agents）開始參與代碼生成，軟體生產速度加快，但驗證機制（Verification）的缺失可能導致更多隱蔽的系統缺陷被引入。這使得技術品質保證（QA）與網站可靠性工程（SRE）的角色變得比以往更加重要。我們需要重新重視對系統屬性的驗證，確保在追求速度的同時，不會在數位建築中埋下導致連鎖崩潰的「報紙接縫」。
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。