11月18日のAzure障害は設定ミスによるもの – マイクロソフト

Table Of Contents

• マイクロソフトが11月18日のAzure障害は設定ミスによるものと発表
• プロトコルの覆し
• ステートメント

マイクロソフトが11月18日のAzure障害は設定ミスによるものと発表

マイクロソフトAzure、企業向けのクラウドプラットフォームは、11月18日に大規模な障害が発生し、多くのユーザーが困惑しました。マイクロソフトは声明の中で、この障害は開発者が不適切なコードを実装したことが原因であると主張しました。

プロトコルの覆し

マイクロソフトの開発者たちは、ソフトウェアのバグを解消するために作業していたようです。バグ解決のためのソリューションが、Azureクラウドサービスの大規模な障害を引き起こしたようです。マイクロソフトは、更新を展開する前にテストを行ったと述べています。しかし、制御されたテスト環境下でのソフトウェア更新の結果を正確に予測することは常に可能ではありません。したがって、マイクロソフトは新しい更新をセクションごとに展開する方針を採用しており、これをフライトと呼び、展開を制限しています。しかし、今回はおそらく過剰な熱意から、開発者たちは全体の更新パッケージを一度に展開し、すべてのサーバーに cascading effect を引き起こしました。Azureブログで発表された声明の中で、AzureチームのCVPであるジャゾン・ザンダーは次のように述べています。

結果として、11月18日のAzureへの接続率は、北バージニアの午後7時以降に97%から7%-8%に落ち込みました。ダラスのAzureデータセンターは短時間完全に障害が発生しました。ヨーロッパのデータセンターは翌日の深夜まで回復しませんでした。

彼はさらに、バグの更新/パッチのための標準展開ポリシーがあるにもかかわらず、明らかなコミュニケーションの誤りがあったと述べました。「小さなスライスにわたって変更を段階的に展開する標準のフライト展開ポリシーは遵守されませんでした」とザンダーは書いています。ザンダーは、チームが特定した主要な問題は、Azure Tableストレージのフロントエンドにおける設定の問題であると述べました。「Azure Blobストレージのフロントエンドに対して設定スイッチが誤って有効になっていました」とザンダーは書いています。

Tableストレージのフロントエンドは、Blob（大量の非構造化データを保存するためのサービス）に入るさまざまなデータタイプのシーケンスを記録し、データの取得をガイドするために使用できます。設定スイッチのエラーは無限ループを引き起こし、最終的にAzureクラウドサービスの障害を引き起こしたようです。

ステートメント

元の更新は、Azureチームによって発見されたバグを修正し、クラウドプラットフォームのパフォーマンスを向上させることを目的としていました。この更新は、アルファテストフェーズのすべてのテストで自らを証明しました。アルファテストの成功した結果は、おそらく開発者たちを興奮させ、フライト展開方法を放棄させ、一度に更新を実装させたのでしょう。その結果、11月18日に見られたのは、ユーザーに問題を引き起こす全体的な障害でした。それに応じて、Azure管理者は、今後このような事態が再発しないように自動更新の実施を行いました。

おそらくこの事件の最も明確な結果として、ザンダーは次のように書いています。「マイクロソフトAzureには明確な運用ガイドラインがありましたが、人間の判断に依存した展開ツールにギャップがありました… ツールの更新により、ポリシーは現在、展開プラットフォーム自体によって強制されています。」

ザンダーは、クラウドオペレーションはより信頼性を高める必要があることを認め、マイクロソフトはその目標に向けて引き続き取り組むと述べました。「このサービス中断があなたのアプリケーションやサービスに与えた重大な影響を心よりお詫び申し上げます」と彼は書いています。

ザンダーは、開発チームの過剰な興奮について心から謝罪したかもしれませんが、事実は、マイクロソフトが必要なテストなしに急いでパッチや更新を推進しているということです。この問題により、マイクロソフトは、BSODを引き起こすバグのあるパッチ/更新を2回リリースすることになりました。1回目は10月のKB 2949927、2回目は12月のKB 3004394で、後にそれらを削除しました。ユーザーは、マイクロソフトがリアルタイムの作業環境で検証された更新/パッチのみをリリースするためのSOPを策定することを期待しています。