メモリのバグがSalesforceの中核スイッチとフェイルオーバーを破壊し、90万人の加入者が締め出された

2009年1月6日、salesforce.comは停止した。UTC 20時39分（太平洋時間の正午ごろ）から、顧客はログインもCRMデータへのアクセスもできなくなった。The Registerは、90万人以上の加入者が自社業務を支えるアプリケーションから締め出されたと報じた。Business Insiderは全停止を30〜40分と伝えた。企業が最も重要なデータをクラウドに預けられると謳っていた会社にとって、1時間近くに及ぶ全面障害が就業時間中に起きたことになる。

Salesforce自身の事後の説明は次のとおりだった。「中核ネットワーク機器がメモリ割り当てエラーにより故障しました。この故障によりデータの通過が停止しましたが、フェイルオーバー・システムにも同じメモリ割り当てエラーが存在していたため、冗長システムへの正常なフェイルオーバーが適切に発動しませんでした」。つまり、冗長機器はプライマリと同じ形で故障し、プラットフォームは手動の手順で復旧する必要があった。

このインシデントは二次的な障害も露呈させた。Salesforceの公開「トラスト」ステータスダッシュボード、すなわち自社の信頼性を宣伝するページも製品とともに停止したため、顧客は自分たちだけが影響を受けているのか判断できなかった。数百人がTwitterで障害の確認に頼った。これは、SaaSプラットフォームが故障すると、その通信レイヤーも意図的に影響範囲の外に置かれていない限り一緒に故障するという初期の実証だった。

90万人以上の加入者に対する、就業時間中の約40分間の全面サービス障害。しかも機能するフェイルオーバーはなかった。

フェイルオーバー機器は故障したプライマリと同じメモリ割り当ての欠陥を抱えていたため、「冗長」経路がトラフィックを引き継ぐことはなかった。

フェイルオーバーは正常に発動せず、完全なサービス復旧には運用チームによる手動の復旧手順が必要だった。

公開トラストダッシュボードは同じ障害領域の中にあり、顧客は状況が見えず、自分たちでTwitter上で障害を診断することを余儀なくされた。

同一の部品で構築された冗長性は、同一のバグを受け継ぐ。待機系ユニットがプライマリと同じ欠陥を抱えているなら、それは余裕ではなく鏡である。フェイルオーバー経路を多様化せよ。

Salesforceはトラストサイトに説明を掲載し、根本原因は「回避策によって対処された」と述べ、チームはハードウェアベンダーと協力して根本原因を詳述し、さらなるパッチ適用を特定し続けると述べた。The Registerとビジネス系メディアは、この障害を、導入型CRMソフトウェアに対する中核的な優位性として可用性を売り込んでいた企業にとってのクラウドコンピューティングの「暗い裏地」と位置づけた。信頼性の監視者たちは別の教訓を引き出した。すべては故障するのであり、運用者を分けるのは顧客が何が起きているかを知り得るかどうかである。すなわち、失敗だったのは稼働率ではなくコミュニケーションだった。