記憶體錯誤擊垮 Salesforce 核心交換器與其容錯切換——90 萬名訂閱用戶被鎖在外

2009 年 1 月 6 日，salesforce.com 全面停擺。自 UTC 20:39（太平洋時間約中午）起，客戶無法登入，也無法存取其 CRM 資料；《The Register》報導，超過 90 萬名訂閱用戶被鎖在他們賴以經營業務的應用程式之外。《Business Insider》則稱整起中斷持續 30 至 40 分鐘。對一家標榜企業可將最重要的資料交給其雲端的公司而言，將近一小時的全面故障，偏偏發生在上班時間。

Salesforce 事後自行提出的說明是：「一台核心網路設備因記憶體配置錯誤而故障。此故障使其停止傳遞資料，但並未正確觸發順暢切換至備援系統，因為容錯切換系統同樣存在記憶體配置錯誤。」換句話說，備援設備以與主要設備相同的方式故障，平台必須以手動步驟才能復原。

這起事件也暴露出第二層故障。Salesforce 對外宣傳其可靠性的「信任」狀態儀表板——那個用來行銷其可靠度的頁面——連同產品一起停擺，客戶因此無從得知自己是否為唯一受影響者。數百人轉向 Twitter 確認中斷情況，這是一項早期示範：當 SaaS 平台故障時，其溝通層也會隨之故障，除非刻意將其置於影響範圍之外。

超過 90 萬名訂閱用戶在上班時間經歷約 40 分鐘的全面服務故障，且容錯切換完全失效。

容錯切換設備帶有與故障的主要設備相同的記憶體配置缺陷，因此「備援」路徑從未承接流量。

容錯切換並未順暢觸發；恢復完整服務需要營運團隊以手動步驟復原。

對外的信任儀表板位於同一個故障域內，使客戶完全失去資訊，只能自行在 Twitter 上診斷這起中斷。

以相同零件建構的備援，會繼承相同的缺陷。若待命機組帶有與主要機組相同的缺陷，它就只是一面鏡子，而非一道餘裕——容錯切換路徑必須多樣化。

Salesforce 在信任網站上發布說明，表示根本原因已「透過因應措施處理」，並表示其團隊將持續與硬體供應商合作，詳查根本原因並找出進一步的修補方案。《The Register》與商業媒體將這起中斷定調為雲端運算對該公司而言的「黑暗襯裡」——這家公司正是以可用性作為相對於就地部署 CRM 軟體的核心優勢來銷售。關注可靠性的人則得出不同的教訓：一切都會故障，而區分營運者的關鍵在於客戶能否得知正在發生什麼事——故障所在是溝通，而非正常運作時間。