MicrosoftのOutlook回復がトラフィック負荷で失敗し続けた
Microsoftの11月12日から13日にかけてのメール障害は、回復ループを露呈しました。
Microsoftの11月12日から13日にかけてのメール障害は、回復ループを露呈しました。復旧したサーバーがトラフィック負荷で再び応答しなくなる可能性があったのです。承認された11月13日11時4分50秒UTCの締め切り時点では、アジア太平洋地域の一部で回復が進展していましたが、他の地域では断続的な問題や作業が残っていました。このフォローアップでは、依存関係と遅延メールの保護措置について説明します。
この動画の要点
- 各操作のバックエンド依存関係を確認してください。ほとんどのコアTeams機能と直接的なSharePointファイルアクセスは機能していましたが、Exchangeに依存する機能は損なわれていました。
- Microsoftは、復旧したサーバーがトラフィックが集中すると再び応答しなくなる可能性があると報告しました。その健全性処理コンポーネントの説明は仮説のままでした。
- 延長された48時間のメールタイムアウトは、キューとバックログ処理中に遅延したメールを保持することを目的としていました。これは修復の期限や普遍的な配信保証ではありません。
- 通常のGraphスロットリングのガイダンスでは、Retry-Afterヘッダーが存在する場合はそれを尊重し、存在しない場合は指数バックオフを使用することを推奨しています。このインシデントを診断または修復するものではありません。
質疑応答
Microsoftの復旧したメールサーバーは、なぜトラフィック負荷で再び障害を起こす可能性があったのですか？
Microsoftは、復旧したサーバーがトラフィックを受信すると再び応答しなくなる可能性があると報告しました。同社の調査では、処理が過負荷になり、サーバーの健全性を処理するコンポーネントに問題がある可能性が示されましたが、最初のトリガーについては最終的なインシデントレポートを待っていました。このエピソードは、概念的に報告された復帰、作業、再発のシーケンスを説明するものであり、実証済みの内部アーキテクチャや最終的な根本原因を主張するものではありません。
Teamsの通話は機能したのに、カレンダー機能が失敗したのはなぜですか？
Microsoftの拡張されたサービス稼働状況通知によると、ほとんどのコアTeamsの通話、会議、チャットは機能していました。カレンダーとスケジューリングのシナリオはExchange Onlineに依存しており、障害中に失敗する可能性がありました。SharePointファイルへの直接アクセスも機能していました。有用なアプリケーションレベルの区別は、製品ロゴの下のすべての機能が同じ障害状態を共有していると見なすのではなく、操作の背後にある依存関係です。
48時間のメールタイムアウトは修復の期限を設定しましたか？
Microsoftは、キューとバックログの処理を優先しながら、遅延したメッセージを保持するためにメールのタイムアウトウィンドウを延長しました。これにより、回復中に遅延メールにより多くの時間が与えられました。公開された通知には、48時間の修復期限も、すべてのメッセージが受信者に届くことの保証も含まれていませんでした。したがって、保留中またはキューに入れられた通知は、時間厳守のワークフローでそれに依存する前に、実際の配信または結果の確認が必要でした。
Exchangeの障害はMicrosoft Graphアプリケーションにどのように影響しましたか？
Microsoftによると、Exchange Onlineのメール、カレンダー、連絡先へのリクエストはタイムアウトする可能性があります。アプリケーションは、異なる基盤となる依存関係を持つ操作間で異なる結果に遭遇する可能性があります。このエピソードは、操作の実際のサービス依存関係を確認することを推奨しています。Microsoftの個別の通常の調整に関するドキュメントでは、Retry-Afterヘッダーが存在する場合はそれを尊重し、存在しない場合は指数バックオフを使用することについて議論しています。これらのポリシーは、このインシデントの原因を特定したり、サービスの復旧を約束したりするものではありません。
Microsoftの復旧に関するThe Daily Diffの評決は何でしたか？
The Daily Diffの評決はNEEDS REVIEWでした。Nikoは、Microsoftの更新が、復旧したサーバーがトラフィック負荷で失敗していることを示していたため、回復をNEEDS REVIEWのままとしました。実際の作業が通る持続的なサービスが、有用な回復テストでした。このエピソードの報告締め切り時点では、Microsoftが完全なインシデントレポートと緩和策後の多層防御対策を約束していたため、最初の原因は未解決のままでした。
翻訳されたトランスクリプト
オリジナルの英語ナレーションから翻訳されています。利用可能なオーディオとキャプションはYouTubeによって管理されています。
なぜ復旧したサーバーは再び失敗したのか？
0:00 Microsoftはメールサーバーをサービスに復旧させました。 トラフィックが戻ると、再び応答しなくなる可能性がありました。 こちらが開発者向けのフォローアップです。 このビデオでは、なぜ回復が失敗し続けたのでしょうか？ そして、アプリのどの部分がまだ機能していましたか？ Microsoftはまた、遅延したメールに48時間の猶予を与えました。 それは実際に何に役立つのでしょうか？ 11月13日金曜日、これはThe Daily Diffです。
0:18 Exchange OnlineはMicrosoftのホスト型メールサービスであり、他のMicrosoft 365の機能が
どの機能がExchangeに依存していたのか？
0:22 それに依存しています。 こちらがMicrosoftのステータスページからの有用な区別です。 Teamsの通話とグループチャットはほとんど機能していました。 カレンダー機能とメールボックスデータへのリクエストは失敗する可能性がありました。 アプリケーションが実際に使用する依存関係を確認してください。 つまり、カレンダーが協力しない場合でも会議は開催できるということです。 SharePoint内のファイルへの直接アクセスも機能し続けました。 一部の共有機能は影響を受けましたが。
0:42 ウィンドウのロゴは、次のクリックに必要なバックエンドについてほとんど教えてくれません。 障害は木曜日に始まり、Microsoftは当初、アメリカ大陸でのメールボックスアクセスを 調査していました。 その後、どの地域のユーザーも影響を受ける可能性があることを確認しました。 CNNは、銀行、政府、裁判所にまたがる問題を報じました。 メールの欠落は、誰かの実際の仕事がそれに依存しているまで不便なだけです。 Microsoftの初期の説明は、利用可能なサーバーの喪失でした。
キャパシティ不足はどのようにサービスを過負荷にするのか？
1:06 これらのマシンが処理すべきだった作業が、残りのインフラストラクチャを圧迫しました。 容量がなくなると、通常の需要でもサービスを過負荷にすることができます。 誰も突然メール送信に熱中していなくても、キューは長くなります。 その後、同社は自動化されたヘルスチェックを調査しました。 これらのチェックは、サーバーが作業を引き受けることができるかを判断するのに役立ちます。 Microsoftは、サーバーの健全性を処理するコンポーネントが関与している可能性があると述べました。 これはまだ進行中の調査からの仮説です。 なぜこれらのサーバーが最初に利用できなくなったのかを正確に説明する最終的なインシデントレポートは
1:29 ありません。 更新は、オンコールシフトが朝食にだんだん興味を失っていくように読めます。
Microsoftが最初に試したことは何だったのか？
1:37 デプロイを一時停止します。 トラフィックを移動します。 サーバーを再起動します。Microsoftは、一部のサブセットを復旧させる代替のヘルスチェックを検証し、 応答しないマシンを検出して再起動する自動化システムを準備しました。 各更新は、容量を回復しようとする試みを説明していました。 そして、回復ループを説明する行が登場しました。 Microsoftは、サービスに復旧したサーバーがトラフィックを受信すると、 再び応答しなくなる可能性があると述べました。
1:59 マシンは復旧し、実際の作業を受け入れ、そして応答を停止する可能性があります。 その観察は、返信での誰かの自信満々な理論よりも強力な証拠です。 これらの状態を通して同じサーバーを想像してみてください。 利用不可。サービスに復帰。 トラフィックを受信中。再び応答不可。 これはMicrosoftの説明を図示しています。 その最後の遷移が何によって引き起こされるかは、まだ不明です。 再起動は一時的な改善をもたらす可能性がありますが、
2:18 サーバーを打ち負かす状態は未解決のままです。 電源を入れ直すというアドバイスは、残業代を請求し始めます。 エンジニアは、作業が戻った後に何が起こるかをチェックする必要があります。 顧客は、次のリクエストでもサービスが機能し続けることを必要としています。 そして次のリクエストでも。 Microsoftは、一部の場所で影響を受けるインフラストラクチャに到達する特定のトラフィックを 制限しました。 また、以前の構成を使用してサーバーのサブセットを再構築し、応答し続けるかどうかを
2:39 テストしました。 これらは報告された緩和策の実験でした。 回復中にデプロイを一時停止しても、金曜日のデプロイが元の停止の原因であったという証拠は ありません。
報告締め切り時点で何が判明していたのか？
2:48 Microsoftの金曜日のUTC11時4分の更新によると、 アジア太平洋地域の一部で回復措置が完了していました。 トラフィックは徐々に回復しており、メールボックスアクセスと遅延メール処理が改善されていました。 一部のユーザーはまだ断続的な問題に直面する可能性があり、 他の地域での回復は続いていました。 これが私たちの報告締め切りです。 Microsoftは悪意のある活動の証拠はないと述べ、 緩和策の後に完全なインシデントレポートを約束しました。
3:10 悪者を特定する前に、そのレポートを待つべきでしょう。 インターネットの探偵作業では、ページを更新し終える前に犯人を見つけることができます。 開発者にとって、Microsoft Graphは依存関係を見落としやすくします。 Exchangeメール、カレンダー、連絡先へのリクエストはタイムアウトする可能性があります。
なぜ1つのGraphリクエストが失敗するのか？
3:20 アプリケーションは、ある操作ではGraphを正常に呼び出し、別の操作では失敗する可能性があります。 無関係なリクエストが成功しても、ユーザーが必要とするメールボックス操作が完了するかどうかについては ほとんどわかりません。 ステータスページでさえ、独自の回避策が必要でした。 Microsoftは、管理者がサービスの状態を確認するために管理センターをロードできない可能性があるため、 インシデント情報を公開しました。 何が壊れているかを見つけるためのダッシュボードが、壊れているものに依存している場合、 そのダッシュボードもインシデントに参加しています。
3:46 帯域外のステータスリンクを用意しておいてください。 通常のGraphスロットリングの場合、Microsoftのガイダンスでは、リクエストが 「Too Many Requests」応答を受け取った場合、再試行遅延を尊重し、 そのヘッダーが存在しない場合は指数バックオフを使用するように指示しています。 このガイダンスはスロットリングを管理します。 この停止を診断したり、再試行でサービスが復旧することを約束したりするものではありません。 さて、48時間です。 Microsoftの拡張されたステータスページによると、キューとバックログの処理を優先し、
48時間のメールウィンドウは何に役立つのか？
4:05 遅延したメッセージを保持するためにメールタイムアウトウィンドウを延長しました。 これにより、回復中に遅延メールにより多くの時間が与えられます。 メールタイムアウトウィンドウを設定します。 Microsoftは、サービスの修正に48時間の期限を設けず、 すべてのメッセージが届くことを保証しませんでした。 したがって、配信に関する主張は正直に保ってください。 遅延通知が必ずしも消滅したわけではなく、 キューに入ったメッセージが必ずしも受信者に届いたわけではありません。
4:28 時間厳守の作業の場合、承認された独立したチャネルを通じて結果を検証してください。 バックエンドがまだ回復中の場合、クライアントウィンドウは楽観的な配信確認です。 これにより、最終的なインシデントレポートで読むべきことがたくさん残されます。 私がこれを話すよりも読む方が良いという方は、The Daily Diffが毎朝無料で 受信トレイに届きます。dailydiff.dev、以下のリンクから。 今日の評決はNEEDS REVIEWです。 Microsoft自身の更新が、復旧したサーバーがトラフィック負荷で失敗していることを示していたため、
持続的な回復は何を証明する必要があるのか？
4:49 私は回復をNEEDS REVIEWのままとします。 有用なテストは、実際の作業が通る持続的なサービスです。 最終レポートが出るまで、最初の原因は未解決のままです。 今日の差分は以上です。 Axrisiのニコールです。 責任を持ってマージしてください。 責任を持ってマージしてください。
情報源
- ExpandedMicrosoftservicehealth, reportingcutoffNovember13 11:04:50UTC; earlier10:01:07observationshistoricalMicrosoft
- Returned servers can become unresponsive again once they receive trafficMicrosoft 365 Status
- Health-processing component investigation hypothesisMicrosoft 365 Status
- Alternative health check returned a subset of serversMicrosoft 365 Status
- Isolate, restart and reintroduce traffic to test stabilityMicrosoft 365 Status
- Unavailable servers strain remaining infrastructureMicrosoft 365 Status
- Initial Exchange mailbox-access investigation in the AmericasMicrosoft 365 Status
- Users in any region may be affectedMicrosoft 365 Status
- Email timeout extended to preserve delayed messagesMicrosoft 365 Status
- Paused deployments, traffic redistribution and server restartsMicrosoft 365 Status
- Independent live reporting on the Microsoft email disruptionCNN
- Microsoft Graph throttling guidanceMicrosoft Learn
- Exchange Online service descriptionMicrosoft Learn
- Satya Nadella portrait by OFFICIAL LEWEB PHOTOS (2013), CC BY 2.0. Whole portrait-based artwork adapted by cropping, background removal, resizing and text/composition; vendor identity only, no endorsement or current reaction.OFFICIAL LEWEB PHOTOS
- Portrait-only CC BY 2.0 licence; separate from third-party source/cartoon rightsCreative Commons
- WWE still. Brief silent process commentary; WWE, The Simpsons/20th Television/Disney, Microsoft and other source owners retain copyright. Hosting and this specific editorial-use decision provide no blanket reuse grant or copyright clearance. The portrait licence is separate from third-party source/cartoon rights.WWE / Imgflip source hosting
- The Simpsons/Bob GIF. Brief silent process commentary; WWE, The Simpsons/20th Television/Disney, Microsoft and other source owners retain copyright. Hosting and this specific editorial-use decision provide no blanket reuse grant or copyright clearance. The portrait licence is separate from third-party source/cartoon rights.The Simpsons / 20th Television / Disney; GIPHY source hosting
