MicrosoftのAzureクラウドコンピューティングプラットフォームが最近、閏年バグのために、部分的なサービス停止を被った。サービスを提供しているサーバーとソフトウェアが2月29日 00:00 USTになったら、障害が起き始めた。日付の変化が閏年を正しく考慮していないコードの欠陥を露呈した。そして追加のサーバーが配置されると、障害は Windows Azureクラウドプラットフォーム中に次々と伝搬し始めた。
では、障害の真因は何だったのか？ Laing氏の説明 によると、アプリケーション仮想マシン（VM)は、このVMとホストOS間のセキュアな通信を容易にするために、転送証明書を使っている。転送証明書が生成されると、1年間だけの寿命となるように設計されている。元々バグのあるコードは、現在の日付を取って、年フィールドに1を加えて、満了日としていた。その結果、2012年2月29日に作成された転送証明書は、2013年2月29日が満了日になったが、これは存在しない日である。このエラーのために、新しい転送証明書が作成できなくなり、ヒューズが燃えた。
Laing氏は、予防、検知、レスポンス、回復に関して、Microsoftはいくつかもの手段を嵩じた、と結論している。Microsoftは、33%のクレジットを「 Windows Azureコンピューティング、アクセスコントロール、サービスバス、キャッシングの全ての顧客に対して」、実際の利用に影響があったかどうかにかかわらず、支払う。
Windows Azure Service Dashboard
Windows Azure 停止の推移（時刻はPST)
2012-02-28 16:00 USTが2012年2月29日 00:00になった時にエラーが始まった。新しいVMは、適切な証明書を生成できなかった。25分間の沈黙の後に、ホストOSがVM生成プロセスを再スタートしたが、これも失敗するだろう。25分間隔で、全部3回の再スタートを試みるプロシージャコールがあった。
2012-02-28 17:15 障害が起きて、正確に75分（ 3 x 25 分）後に、エラー閾値に達し、障害のあるクラスターが最初の対応者に、障害のあるシステムが回復できないことを通知した。
2012-02-28 18:38 対応チームが問題の原因となる最初の日時を確認した。
2012-02-28 18:55 問題に対するチーム評価に基づいて、顧客が更なるダメージの原因にならないように、Microsoftは世界中の全クラスタでサービス管理機能をオフにした。
2012-02-28 22:00 対応チームは、アップデートコード用のテストとロールアウト計画を作成した。
2012-02-28 23:20 コードのアップデートを完了した。
2012-02-29 01:50 対応チームは、テスト用クラスタにテストとアップデートしたコードの入ったアプリケーションをリリースした。
2012-02-29 02:11 1つの製品クラスタにパッチを出した時には、チームは全クラスタにパッチをデプロイし始めていた。
2012-02-29 02:47 7つのクラスタは、部分的にアップデートされた状態のままだった。これらは元々のバグで被害があった時に、アップデートされていたのである。これらの7つは、デプロイ前にテストをしなかった別のアップデートがなされており、このアップデートは、ネットワーク接続性を停止する、別のバグをもたらした。
2012-02-29 03:30 修正されたパッチがこの7つのクラスタように作られ、今回は、デプロイ前にテストされた。修正版は 05:40にインストールが予定された。
2012-02-29 05:23 Microsoftは大多数の顧客へのサービス管理は回復した、とアナウンスした（別個の7つのクラスタは除く）。
2012-02-29 05:40 7つのクラスタがネットワーク機能を回復するために、アップデートを受け取り始めた。
2012-02-29 08:00 7つのクラスタは、ほとんど稼働できる状態になった。いくつかの個々のサーバーが様々な停止によって引き起こされたエラーを経験した。Microsoftのスタッフがそれらを修復するために1日中働き続けた。
2012-03-01 02:15 全クラスタとサービスの機能が完全に回復した。