冷卻故障迫使維基百科進行容錯切換——而切換機制本身卻讓全球 DNS 失效

2010 年 3 月 24 日，維基媒體歐洲資料中心的冷卻系統故障，許多伺服器為保護硬體而自行關機。由於該站點負責為維基百科及其他專案處理歐洲流量，維運團隊執行了標準的快速容錯切換：變更 DNS 記錄，讓所有使用者流量轉往佛羅里達叢集。幾分鐘後，團隊發現容錯切換機制本身已損壞，所有維基媒體網站的 DNS 解析都停止運作——不僅在歐洲，而是全球皆然。

復原過程隨後又遭遇第二種更為隱蔽的故障模式。團隊原本預期解析器會在一小時內捨棄錯誤的應答，也就是該區域所宣告的負快取 TTL，但許多 ISP 的解析器忽略了這項提示，將失敗的查詢結果快取更久。變通做法相當直接：重新命名受影響的 DNS 記錄，迫使解析器必須重新查詢一個全新的名稱。與此同時，在緊急期間被停用的 secure.wikimedia.org SSL 閘道，在流量回流時不堪負荷而癱瘓，直到 UTC 21:32 才恢復。

有好幾個小時，這部全球參考百科全書完全無法解析，而且沒有可觀看的故障狀態頁——Mashable 指出，Twitter 是唯一能追蹤此事的地方。維基媒體《Signpost》記錄該網站「全球離線數小時」，團隊則在同日於技術部落格發布說明，由基礎架構工程師 Mark Bergsma 署名。

所有維基媒體網站在全球停止解析達數小時，CNN、Telegraph 與 Mashable 均報導了這起中斷事件，讀者因此無法存取。

容錯切換程序被標示為「標準快速」，但實際執行時其 DNS 步驟卻已損壞——這條復原路徑顯然從未針對真實切換進行過演練。

復原時間的估算假設 ISP 解析器會遵守所宣告的一小時負快取 TTL；許多解析器並未遵守，使一起有界的事件延長為無限期的事件。

SSL 閘道沒有餘裕：當流量湧回時，secure.wikimedia.org 超載並失效，使中斷情況更加嚴重。

歐洲的服務集中於單一設施，因此一次冷卻故障從一開始就必然導致全球流量切換。

從未演練過的容錯切換路徑只是一廂情願，而非真正的機制。應以實戰演練方式排練復原程序，且絕不可假設下游快取會按時到期。

在 DNS 記錄重新命名且新的查詢傳播開來後，存取得以恢復；SSL 閘道於同日 UTC 21:32 前恢復。同日於維基媒體技術部落格發布的公開事故檢討，為該基金會日後發布事件回顧的習慣奠定了基調。冗餘陷阱本身依然存在：2012 年 8 月，一條光纖被切斷，同時截斷了 Ashburn 與 Tampa 資料中心之間兩條「冗餘」鏈路，使維基百科再次中斷 63 分鐘，直到那時基金會才將其服務後端整合至 Ashburn。