許多工程師在設計系統時，常以為只要將服務部署在像 AWS 這樣的大型雲端平台，並分散在多個可用區域（Availability Zones, AZ），就等同於實現了高可用性。然而，Coinbase 最近一次長達數小時的交易中斷的事後分析（Postmortem）給了我們一個深刻的教訓：雲端基礎設施的韌性並不等於應用程式的韌性。
這次事故的起因是 AWS US-East-1 區域中某個資料中心發生了局部冷卻系統故障。由於冷卻失效導致機架過熱，觸發了硬體保護機制而自動關機，導致部分 EC2 虛擬機與 EBS 儲存設備直接離線。雖然這在 AWS 層面僅是局部區域的故障，但卻引發了 Coinbase 全平台近乎癱瘓的連鎖反應。
效能優化與可用性的衝突
對於交易平台而言，低延遲（Low Latency）是核心競爭力。為了實現高頻交易所需的極速反應，Coinbase 的交易匹配引擎（Matching Engine）採用了 Raft 共識演算法。Raft 是一種確保分散式系統中多個節點能達成一致狀態的協議，通常需要超過半數的節點（Quorum，法定人數）在線才能運作。
為了將網路延遲降到最低，Coinbase 將這些節點放置在同一個集群放置群組（Cluster Placement Group）中。這意味著所有節點在物理位置上被刻意地安排在極近的距離。
這種設計在正常情況下表現極佳，但在這次事故中卻成了致命傷。由於節點過於集中，當 AWS 的冷卻故障導致該區域部分機架關機時，集群中的 5 個節點中有 3 個同時離線。這導致系統失去了法定人數，無法達成共識，匹配引擎隨即停止處理所有交易。
這是一個典型的工程權衡（Trade-off）：為了追求極致的效能（低延遲），犧牲了容錯能力（Resilience）。當基礎設施發生罕見故障時，缺乏自動化跨區域切換（Failover）機制的系統將無法自我恢復，必須依賴工程師手動修改代碼並重建集群，這大大延長了恢復時間。
複合式故障的放大效應
除了匹配引擎的崩潰，這次事故還揭露了另一個隱藏的依賴問題：事件串流基礎設施（Event-streaming Infrastructure）。
Coinbase 使用 Kafka 來分發營運數據。不幸的是，部分 Kafka 的工作負載也被困在了受損的可用區域中。即使後續匹配引擎開始恢復，由於 Kafka 產生了巨大的數據積壓（Backlog），導致數據流無法正常恢復，形成另一道瓶頸。
這對 Junior 工程師來說是一個重要的觀念：在複雜的分散式系統中，單一故障（Single Point of Failure）很少是導致災難的唯一原因。真正的災難通常源於多個可控的局部故障在特定時間點交織在一起，產生了不可預見的連鎖反應。
從這次事件中我們能學到什麼
首先是重新審視隱藏依賴。即便使用了多可用區域部署，如果你的核心元件（如共識集群）為了效能而將節點集中在單一區域，那麼你實際上仍然存在單點故障風險。
其次是恢復能力比預防故障更重要。Coinbase 意識到完全避免故障是不可能的，因此後續的優化重點在於如何加速恢復，包括建立自動化的跨區域恢復能力，以及簡化法定人數的重建流程。
最後，實踐混亂工程（Chaos Engineering）至關重要。許多系統的設計假設在理論上是正確的，但直到發生真實事故才發現這些假設在極端情況下會失效。定期模擬局部區域失效，能幫助團隊在災難發生前發現這些隱蔽的依賴關係。
來源：infoq.com
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。