冷却障害によりウィキペディアのフェイルオーバーが強制され、そのフェイルオーバー自体が世界中のDNSを壊した

2010年3月24日、ウィキメディアの欧州データセンターで冷却が故障し、多くのサーバーがハードウェアを保護するために自ら電源を切った。この拠点はウィキペディアおよびその他のプロジェクトの欧州向けトラフィックを処理していたため、運用チームは標準的な迅速フェイルオーバーを実行した。つまり、DNSエントリを変更してすべてのユーザートラフィックをフロリダのクラスタへ移した。数分後、チームはフェイルオーバー機構自体が壊れていることを発見し、すべてのウィキメディアサイトのDNS解決が、欧州だけでなく世界中で機能しなくなった。

復旧はその後、より目立たない第二の障害モードに直面した。チームは、ゾーンが通知するネガティブキャッシュTTLである1時間以内にリゾルバが誤った応答を破棄すると予想していたが、多くのISPのリゾルバはそのヒントを無視し、失敗したルックアップをより長くキャッシュした。回避策は強引なものだった。影響を受けたDNSレコードの名前を変更し、リゾルバに新しい名前を追わせるようにしたのである。一方、緊急時に無効化されていたsecure.wikimedia.orgのSSLゲートウェイは、戻ってきたトラフィックに耐えられずダウンし、UTC 21:32まで復旧しなかった。

数時間にわたり、世界の参照百科事典は単に解決不能となり、監視できる障害情報のストリームもなかった。Mashableは、これを追跡できる唯一の場所がTwitterだったと指摘した。ウィキメディアのSignpostは、サイトが「数時間にわたり世界中でオフライン」になったと記録し、チームは同日、インフラエンジニアのMark Bergsmaの署名入りで技術ブログに説明を投稿した。

すべてのウィキメディアサイトが世界中で数時間にわたり解決不能となり、読者がアクセスできなくなったこの障害は、CNN、Telegraph、Mashableによって報じられた。

フェイルオーバー手順は「標準的な迅速」と銘打たれていたが、実際に実行するとそのDNSステップが壊れていた。つまり、復旧経路は実際の切り替えに対して一度も試されていなかったことは明らかである。

復旧の見積もりは、ISPのリゾルバが通知された1時間のネガティブキャッシュTTLを守ることを前提としていたが、多くのリゾルバは守らず、限定的なはずの障害を終わりの見えないものに引き延ばした。

SSLゲートウェイには余裕がなかった。トラフィックが一気に戻るとsecure.wikimedia.orgが過負荷になってダウンし、障害を悪化させた。

欧州向けの配信が単一の施設に集中していたため、1回の冷却故障がそもそも世界的なトラフィック切り替えを必要とした。

一度も試されたことのないフェイルオーバー経路は、仕組みではなく希望にすぎない。復旧手順は実際の訓練として演習し、下流のキャッシュが予定どおり失効するとは決して仮定してはならない。

DNSレコードの名前を変更し、新しいルックアップが伝播した後にアクセスは回復した。SSLゲートウェイは同日UTC 21:32までに復旧した。ウィキメディアの技術ブログに同日公開された公開事後分析は、後に財団が障害の回顧録を公開する習慣を築くきっかけとなった。冗長性の罠自体は残った。2012年8月、1本の光ファイバー切断がAshburnとTampaのデータセンター間の「冗長」な2本の回線を両方とも切断し、ウィキペディアをさらに63分間ダウンさせた。そしてその後に初めて、財団は配信バックエンドをAshburnに統合した。