Microsoft 365：復旧しても処理能力が戻らないとき
Microsoft 365で続いている障害により、単なるトラフィックの急増よりも深刻な障害モードが明らかになりました。
サーバーはヘルスチェックに失敗し、サービスから次々と離脱し始めました。残ったインフラが退避したトラフィックを吸収したことで、利用可能な処理能力への負荷が高まりました。
その後Microsoftは、安全な接続の確立を担うプロセスが過負荷になっていたことを特定しました。復旧したサーバーの一部は、トラフィックが戻ると再び応答しなくなりました。
ここが重要な点です。
ヘルスチェックに合格したサーバーが、本番トラフィックを処理できるとは限りません。
Microsoftは、最近のネットワーク変更を調査しながら、制御された再起動、トラフィックの制限、設定変更を試みてきました。初期の復旧の兆候は有望でしたが、その後の緩和策では期待された改善が得られませんでした。
障害はExchange Onlineにとどまらず、Teams、Copilot、Microsoft Graphの一部など、これに依存するサービスにも広がっています。
より広い教訓は、設置済みの処理能力ではなく、実際に活用できる処理能力が重要だということです。
密接に連携したクラウドプラットフォームでは、サーバーを復旧させても、実際のワークロードを処理する能力が戻らなければ、システムは同じ障害サイクルから抜け出せない可能性があります。
今後注目すべきなのは、通常のトラフィック下で復旧が持続するかどうか、そしてMicrosoftによる根本原因の分析です。
#stocks
$MSFT.US
Microsoft 365で続いている障害により、単なるトラフィックの急増よりも深刻な障害モードが明らかになりました。
サーバーはヘルスチェックに失敗し、サービスから次々と離脱し始めました。残ったインフラが退避したトラフィックを吸収したことで、利用可能な処理能力への負荷が高まりました。
その後Microsoftは、安全な接続の確立を担うプロセスが過負荷になっていたことを特定しました。復旧したサーバーの一部は、トラフィックが戻ると再び応答しなくなりました。
ここが重要な点です。
ヘルスチェックに合格したサーバーが、本番トラフィックを処理できるとは限りません。
Microsoftは、最近のネットワーク変更を調査しながら、制御された再起動、トラフィックの制限、設定変更を試みてきました。初期の復旧の兆候は有望でしたが、その後の緩和策では期待された改善が得られませんでした。
障害はExchange Onlineにとどまらず、Teams、Copilot、Microsoft Graphの一部など、これに依存するサービスにも広がっています。
より広い教訓は、設置済みの処理能力ではなく、実際に活用できる処理能力が重要だということです。
密接に連携したクラウドプラットフォームでは、サーバーを復旧させても、実際のワークロードを処理する能力が戻らなければ、システムは同じ障害サイクルから抜け出せない可能性があります。
今後注目すべきなのは、通常のトラフィック下で復旧が持続するかどうか、そしてMicrosoftによる根本原因の分析です。
#stocks
$MSFT.US