Microsoft 365の大規模障害、原因は未検証アップデートがデプロイシステムのバグにより通常のプロセスをバイパスして本番環境へ直接デプロイされたこと

マイクロソフトのサービス「Microsoft 365」で、日本時間の9月29日午前6時半頃から約3時間ほど障害が発生し、全世界でOneDriveやOutlook、Teamsなどのサービスに接続しにくくなっていました。

We're investigating an issue affecting access to multiple Microsoft 365 services. We're working to identify the full impact and will provide more information shortly.

— Microsoft 365 Status (@MSFT365Status) September 28, 2020

直接の原因はAzure Active Directory（Azure AD）のバックエンドサービス障害で、これによりAzure ADの認証に依存しているサービス全体が影響を受けました。

しかし根本的な原因についてはもう少し複雑な要因がからんでいます。マイクロソフトはこれについて「Azure status history」で9月28日に詳細を報告していますので、以下、その詳細からポイントを抜粋して紹介しましょう。

デプロイサービスの潜在的バグによりデプロイが失敗

報告では「Root Cause」（根本原因）として、次のように説明しています。

On September 28 at 21:25 UTC, a service update targeting an internal validation test ring was deployed, causing a crash upon startup in the Azure AD backend services. A latent code defect in the Azure AD backend service Safe Deployment Process (SDP) system caused this to deploy directly into our production environment, bypassing our normal validation process.

9月28日午後9時25分（世界協定時）、内部検証用テストリング向けのサービスアップデートがデプロイされ、これがAzure ADバックエンドサービスの起動をクラッシュさせた。Azure ADバックエンドサービスセーフデプロイメントプロセス（SDP）システムの潜在的なバグが、これを通常の検証プロセスをバイパスして本番環境へ直接デプロイしてしまった。

ややぶっきらぼうな説明の仕方なので少し推測を入れつつ文脈を読み取らないといけないのですが、次のように整理できると思います。

• 検証用の領域（検証用テストリング）に向けてサービスアップデートをデプロイした
• それがAzure ADバックエンドサービスをクラッシュさせた
• セーフデプロイメントプロセスのコードに存在していた潜在的なバグが顕在化した
• バグによって未検証のアップデートが検証プロセスをバイパスして本番環境にデプロイされてしまった

なぜセーフデプロイメントプロセスの潜在的なバグが顕在したか、その理由は明示的には説明されていませんが、文脈から推測すると、前段のAzure ADバックエンドサービスのクラッシュが引き起こしたと見られます。

Azure ADのアップデートは何段階にも分かれていたはずだった

マイクロソフトの説明によると、Azure ADのアップデートは通常、まずユーザーデータを含まない検証用領域にデプロイされ、次にマイクロソフト社員しかユーザーが存在しない領域に対してデプロイされ、そこで検証されて問題がなければ最終的に本番環境にデプロイされるという手順が設けられており、これらは5段階に分かれて数日かけて行われるとのこと。

ところが、これを安全に実行するための「Azure ADバックエンドサービスセーフデプロイメントプロセス（SDP）システム」（以下SDPシステム）のコードに潜在的なバグがあり、これがすべての段階をすっ飛ばして全段階に対して同時にデプロイを実行。

これが障害を引き起こしたとしています。

メタデータが壊れて自動ロールバックに失敗、手動で対応

障害発生後の対応は次のように説明されました。

• 障害が発生して5分以内に運用チームが障害を検出。約30分にわたってAzure ADサービスのスケールアウトや障害の起きたサーバのフェイルオーバーなどによる緩和措置を実施。
• 約30分後には原因を究明し、自動ロールバックを実行したものの、すでにSDPサービスのメタデータが壊れてしまっており、自動ロールバックに失敗。

We're not observing an increase in successful connections after rolling back a recent change. We're working to evaluate additional mitigation solutions while we investigate the root cause. Please visit https://t.co/AEUj8uAGXl for additional information on this issue.

— Microsoft 365 Status (@MSFT365Status) September 28, 2020

• 約75分後にはSDPサービスをバイパスして、手動でサービス構成のアップデート作業による復旧を開始。約150分後にこの作業が終了。
• 約180分後にサービスが正常状態に復帰。

その後マイクロソフトはSDPシステムのコードのバグを修正。正常に動作していた最後の時点でのメタデータのリストアを可能にすることで、メタデータが壊れて自動ロールバックに失敗することがないように修正する、などの対応策を発表しています。