Azure 2023年 WAN 変更障害：グローバルルーティング検証は説明責任の試金石

概要

2023年1月25日、Microsoft は、インターネットから Azure への接続、サービス間およびリージョン間の接続、ExpressRoute 接続、Microsoft 365、その他の Microsoft サービスに影響を及ぼすグローバルなネットワーク障害を経験した。Microsoft 365 の顧客向けレポートでは、影響時間帯は 07:05～12:43 UTC、Azure WAN 追跡 ID は VSG1-B90 とされている。[1][2]
Microsoft の公開説明によると、計画された変更は WAN ルーターの IP アドレスを更新するものだった。あるコマンドがネットワークデバイス間で異なる動作をし、実行されたルーターで十分に検証されていなかった。メッセージが他の WAN ルーターに到達し、隣接関係と転送テーブルが再計算され、収束中にルーターがパケットを正しく転送できなくなった。[1][2][4]
ThousandEyes は、Microsoft の AS8075 に関連するプレフィックスについて、BGP 経路の撤回、再広告、経路変更の繰り返し、直接ピアとトランジット経路の切り替え、経路イベントと相関するパケット損失を独自に観測した。この証拠は外部から見える経路の不安定性を立証するものであり、非公開のコマンドや内部テーブル状態のすべてを証明するものではない。[3]
有用な説明責任の問いは、変更が計画されていたかどうかではない。その正確なセマンティクスが、実行対象となるデバイスとソフトウェア群全体でテストされていたか、伝播が制限されていたか、経路と到達可能性の不変条件がグローバルな影響の前にロールアウトを停止できたか、である。
Microsoft は、初期の監視作業で WAN が原因と確認される前に DNS を調査したと述べた。この順序は、分類と可観測性の問題を提起する。監視はユーザー症状を特定できたのか、それとも原因となるコントロールプレーンとフォワーディングプレーンのメカニズムを迅速に区別できたのか。隠蔽や不当な遅延を証明するものではない。
ExpressRoute の冗長性は顧客側のアーキテクチャとして依然重要だが、Microsoft のプライベートバックボーンコマンド、ルーター隣接関係、転送収束、グローバルな復旧の制御を顧客に移すものではない。責任は各当事者が実際に運用する制御に従う。[8]-[11]
BGP および運用標準は、経路広告、撤回、フィルタリング、計画的なトラフィック退避を説明する。それらは Microsoft の内部状態を証明しない。RPKI のオリジン認可は、デバイス固有のコマンド、内部隣接関係の再計算、転送の継続性を検証しない。[18]-[20]
最も強力なインシデント後の証拠は、変更要求を正確なコマンドと候補状態、デバイス・バージョン別の検証マトリクス、経路不変条件、代表的なカナリア、最大伝播ドメイン、独立プローブ、自動ロールバックトリガー、保持された復旧ログに結び付けることである。
Microsoft の現在の文書は、グローバルネットワークエンジニアリング、監視、ExpressRoute、Virtual WAN の制御を説明している。これらの文書は利用可能なメカニズムと現在の設計上の主張を示すが、各制御が2023年1月に同じ形で存在したか、継続的に実施されているかを証明するものではない。[7]-[17]
公開記録は、正確なコマンド、すべてのルーターモデルとソフトウェアリリース、影響を受けた全プレフィックス、完全な顧客数、金銭的損失、規制上の認定、過失、悪意、ベンダーの欠陥を特定していない。これらの限界は調査結果の一部として残る。

計画された変更は検証済みの変更ではない

「計画された変更」という表現は安心感を与えかねない。承認、準備、既知の目的を示唆するからだ。このインシデントで Microsoft は、発端となった操作を WAN ルーターの IP アドレスを更新する計画された変更と説明した。目的は通常の保守であり、グローバルな到達可能性を変えようとするものではなかった。しかし、その作業に使われたコマンドは、報告によるとネットワークデバイス間で異なる動作をし、実行されたルーターで十分に検証されていなかった。[1][2][4]

この隔たりが最初の説明責任上の発見である。計画は組織が何を意図しているかを記録する。検証は展開されたシステムが実際に何をするかをテストする。両者は関連するが、交換可能ではない。

ルーターはテキストコマンドの汎用コンテナではない。コマンドは特定のプラットフォーム、オペレーティングシステムのリリース、機能セット、設定コンテキスト、隣接トポロジーによって解釈される。同じ構文でも、異機種混在環境ではサポートされていなかったり、展開が異なったり、スコープが異なったり、依存する操作が異なったりする。結果の設定が似ていても、ローカルな変更からプロトコルメッセージ、隣接状態、経路選択、転送エントリへの経路は異なり得る。

したがって Microsoft の公開説明は「誰かがミスをした」というよりも、より具体的な制御の失敗を示している。問題は、変更システムがどのデバイスがコマンドを受信または反応するかを把握していたか、その検証証拠がそれらのデバイスを代表していたかどうかである。あるプラットフォームでのテストは、両方がルーターと呼ばれるからといって別のプラットフォームでの動作を立証できない。ラボテストは、リスクを生むソフトウェアリリース、ピア数、経路規模、ポリシーセット、伝播経路を省略していれば、本番の安全性を立証できない。

この区別が重要なのは、ネットワークコマンドが実行可能な権限だからだ。変更記述は「IP アドレスを更新する」と言うかもしれない。ルーターはその記述を実行しない。状態を変更するコマンドとプロトコルを実行する。他のルーターは、チケットの業務目的ではなく、受信したメッセージに応答する。パケットは承認記録ではなく、結果として生じた転送テーブルに遭遇する。

したがって説明責任のある変更プロセスは、意図から運用上の効果まで連鎖を保持しなければならない。

承認された目的と正確なスコープ。
レンダリングされたコマンドまたは候補設定。
実行が期待されるデバイスモデル、ソフトウェアリリース、役割、トポロジー。
引き起こすと期待されるプロトコルメッセージと状態遷移。
真であり続けなければならない経路および到達可能性の不変条件。
それらの期待をテストするために使用されるカナリアと伝播境界。
ロールバックのトリガーと権限。
ネットワークが意図した状態に戻ったことを示す観測。

その連鎖がなければ、計画された変更は手続き的には完了していても運用上は未検証であり得る。2023年1月のインシデントが重要なのは、公開説明が日常的な目的をデバイス依存の動作とネットワーク全体の結果に結び付けているからだ。

障害メカニズムは WAN を通じて進行した

アプリケーションの停止はネットワークのような症状を生むことが多い。ユーザーはタイムアウト、ログイン失敗、読み込まれないページを見る。それらの観測だけでは、DNS、認証、アプリケーション容量、ストレージ、トランスポート経路、ルーティング制御のどれが失敗したのかを確定できない。

1月25日の入手可能な記録はより具体的である。Microsoft はこの出来事を自社の広域ネットワークに関連付けた。その説明によると、メッセージが他の WAN ルーターに送信された。それらのルーターは隣接関係と転送テーブルを再計算した。その収束中、パケットを正しく転送できなかった。[1][2][4]

隣接関係と転送は抽象的なバックグラウンドプロセスではない。ルーティング隣接関係は、どのネットワークデバイスが到達可能性情報を交換するかを確立する。コントロールプレーンはその情報とポリシーを使用して経路を選択する。フォワーディングプレーンは、パケットの送信先をルーターに指示するエントリをインストールする。変更によって多数のルーターがそれらの関係とエントリを再計算する場合、影響は最初のデバイスをはるかに超えて広がり得る。

Microsoft が説明した結果はそのメカニズムに従った。インターネット上のクライアントから Azure への接続が影響を受けた。リージョン内のサービス間接続が影響を受けた。ExpressRoute 接続が影響を受けた。Microsoft 365 と Power Platform も影響を受けた。[1][2][4][6]

この広がりは、すべてのサービスが同一の障害や継続時間を持ったことを意味しない。WAN が複数のサービス経路の下に位置していたことを意味する。共有ルーティング基盤は、サービスが同じ相互接続、バックボーン、リージョン間到達可能性に依存しているため、1つのネットワーク変更を見かけ上無関係なアプリケーション症状に変えることができる。

現在の Microsoft のグローバルネットワーク文書は、依存関係の表面を説明するのに役立つ。Microsoft は、データセンターを接続し、バックボーン上でトラフィックを運び、外部ネットワークと相互接続するプライベートなグローバル WAN を説明している。ExpressRoute はルーティング関係を通じて Microsoft サービスへのプライベート接続を提供し、Azure リージョンとサービスはトラフィック交換に事業者のネットワークに依存する。[7]-[10]

これらの現在の記述を、2023年のインシデントの完全な地図として逆読みすべきではない。しかし、WAN 制御がサービス横断的な結果をもたらし得る理由は立証している。バックボーンがパケットを正しく転送できなければ、健全なアプリケーションプロセスでも到達不能になり得る。リージョン間接続が劣化すれば、個々のホストが稼働していても分散サービスは依存関係を失い得る。ExpressRoute 経路が影響を受けた制御ドメインを通過すれば、パブリックインターネットを回避していてもプライベート回線は影響を受け得る。

だからこそ、本記事の主張はネットワークの事実を除いては成立しない。このインシデントは、ルーターを飾り物にした変更管理に関する一般的な教訓ではない。コマンド、隣接関係の再計算、転送テーブルの状態、経路変動、パケット損失、リージョン間経路、ExpressRoute 境界が因果的・証拠的な核心である。

外部 BGP 観測が第二の証拠面を提供した

Microsoft は内部の変更記録とルーターテレメトリを管理していた。独立した観測者は別種の証拠、つまりプライベートネットワークの外部から見えるルーティング変更と接続性への影響を管理していた。

ThousandEyes は、07:10 UTC 直後から Microsoft の AS8075 に関連するプレフィックスに影響する多数の BGP 経路変更を報告した。撤回に続く再広告、直接経路とトランジットプロバイダーを巻き込む変更の繰り返し、ルーティング活動とともに増加するパケット損失を観測した。一部の観測地点では、イベントの一部期間に完全なパケット損失が発生した。[3]

その証拠は、Microsoft のインシデント説明から生成されたものではないため価値がある。経路の不安定性と到達可能性の喪失が独立した観測点から見えていたことを示す。また、広範なネットワークメカニズムを検証可能にする。WAN ルーティングイベントが外部接続に影響したという主張は、事業者の管理ドメイン外での経路とパケットの観測と整合しているべきである。

独立した証拠は依然として境界を定められなければならない。BGP 観測者は、自らのコレクターやエージェントに到達する更新を見る。すべてのプライベート隣接関係、すべての内部経路、すべての転送テーブルエントリ、あるいはそれらを引き起こしたコマンドを見るわけではない。オリジンルーターが経路を削除したのか、中間ポリシーが抑制したのか、別の内部イベントがエクスポート内容を変えたのかを知らずに撤回を観測するかもしれない。

同様に、時間的相関は完全な因果関係の再構成ではない。ThousandEyes はインシデント前後の経路変更とパケット損失を見た。Microsoft の説明はコマンドと WAN 収束の内部説明を提供する。2つの記録は相互に整合しているが、どちらにも他方の証拠を主張させるべきではない。

説明責任のあるインシデント報告は、これらの面を明示的に突き合わせるだろう。

どの内部経路または隣接関係の変更が、外部で観測された各撤回を生み出したのか？
どのプレフィックスが影響を受け、どのサービスがそれらに依存していたのか？
どの直接ピア経路が消え、どのトランジット経路が代替になったのか？
十分な容量や安定した転送がない経路にトラフィックが移動したのか？
どの内部安定化イベントが、外部での安定経路の復帰に対応するのか？
公開 BGP データでは見えない内部到達性の障害があったのか？
外部プローブは、すべての Microsoft サービスが回復する前に復旧を宣言したのか？

公開タイムラインは、経路の安定化とサービスの復旧が同一のイベントではなかったことを示唆する。ThousandEyes は 08:10 頃に大規模な安定化を報告し、その後も BGP 活動が観測された。Microsoft は、08:10 直後に自動復旧が始まり、09:00 頃までに影響を受けた大部分のサービスが回復し、09:35 にネットワーク機器が安定し、残りの Microsoft 365 サービスは 12:43 までに回復したと述べた。[1][3][4]

この違いは矛盾ではない。経路の復旧は完全なサービス復旧に必要だが十分ではない場合がある。接続は再試行が必要かもしれない。キャッシュとキューは排出が必要かもしれない。依存サービスはセッションの再確立や状態の修復が必要かもしれない。責任ある記録は、ネットワーク復旧が終わり、サービス復元が続いた場所を示すべきである。

BGP の経路変動は冗長性を不安定性に変え得る

冗長経路はインターネットとクラウドネットワーク設計の基盤である。直接経路が消えても、トランジットプロバイダー経由で別の経路が利用できるかもしれない。しかし、冗長性は急速で繰り返される経路変更が無害であることを保証しない。

ThousandEyes は、主に直接ピアに影響する撤回、それに続く代替経路の使用、さらに短い直接経路の再広告を説明した。繰り返しが経路変動を生んだ。[3] 各変更はルーターに選択経路の再考を促し得る。トラフィックは容量、遅延、ポリシー、障害露出が異なる経路間を移動し得る。フォワーディング状態がコントロールプレーンの決定に追いつく間、パケットが失われ得る。

BGP 仕様は、スピーカーが到達可能性を交換し経路を撤回する方法を定義する。インターネット全体で即時的で同期した収束を約束しない。事業者はローカルにポリシーを選択し、異なる時間に更新を受信し、独自のスケジュールで転送変更をインストールする。[18]

つまり、フォールバック経路はトラフィックを受け入れるのを待つ静的な予備車線ではない。分散制御システムの一部である。多くの経路が急速に変わると、トランジット経路は突然の負荷を受けるかもしれない。直接ピアは、すべてのデバイスが同じ最適経路に合意する前に消えて戻るかもしれない。一部のネットワークは他が撤回した経路を保持するかもしれない。アプリケーション接続は移行中に異なる状態を横断し得る。

RFC 7454 などの運用ガイダンスは、規律あるルーティングポリシーとフィルタリングを強調する。RFC 8326 は、計画された BGP メンテナンスの前にトラフィックを退避させるためのグレースフルシャットダウンメカニズムを説明する。どちらの標準も Microsoft の内部インシデントへの直接的な処方箋ではなく、公開記録はどのメカニズムが使用されたかを述べていない。それらは有用な制御原則を確立する。保守は、制御されない経路撤回と再広告の爆発を許すのではなく、トラフィックを意図的かつ観測可能に移動させることを目指すべきである。[19][20]

グローバル WAN 変更にとって、関連する不変条件は単に「別の経路が存在する」ではない。より強力なセットは次のことを問うだろう。

必須プレフィックスは、少なくとも1つの検証済み経路を通じて到達可能であり続けるか？
代替経路は期待される移動に対して十分な容量を持つか？
経路変更頻度は安全な閾値未満か？
転送エントリはテストされた間隔内で収束するか？
直接ピアとトランジットの変更は独立プローブに見えるか？
同じコマンドが次の伝播ドメインに影響する前にロールアウトを一時停止できるか？
サービス経路が変わっても管理アクセスは利用可能であり続けるか？

冗長性は設計上の主張である。運用上の証明は、発生する正確な障害・変更条件下でトラフィックが冗長経路を使用できるかどうかである。

グローバル規模がブラスト半径の意味を変えた

1台のルーターに適用されたコマンドはローカルに見えるかもしれない。多数のルーターに状態の再計算を引き起こすプロトコルメッセージはローカルではない。説明責任の境界は、発端コマンドが入力されたキーボードやデバイスではなく、伝播ドメインに従わなければならない。

Microsoft の公開説明は、コマンドが他の WAN ルーターにメッセージを送信したと述べた。[4] この記述は伝播を第一級の変更プロパティにする。承認前に、事業者はどのデバイスが反応し得るか、どの状態を再計算するか、反応をどう止めるかを知っておくべきである。

グローバルバックボーンでは、ブラスト半径にはいくつかの次元がある。

デバイス範囲：変更を受信または解釈するルーターとソフトウェアバージョン。
プロトコル範囲：影響を受ける隣接関係、ルートリフレクター、ピア、制御セッション。
プレフィックス範囲：撤回、置換、または異なる選択が可能な到達可能性エントリ。
トラフィック範囲：それらのエントリを使用する顧客、サービス、リージョン間、管理フロー。
地理的範囲：制御ドメインを共有するリージョンと相互接続点。
復旧範囲：安定状態を回復するために必要なシステムと運用者。

変更はデバイス数では小さくてもプロトコル範囲で大きくなり得る。1つの設定オブジェクトに触れながら、数千の選択経路を変え得る。発端ルーターでは可逆的でありながら、残りのネットワークを再収束させたままにし得る。

これは境界付き実行の要件を生む。安全なシステムは、候補を代表的だが限定的なドメインに適用し、経路と到達可能性の不変条件を観測し、メッセージがグローバルに伝播する前に停止できるべきである。カナリアは本番ターゲットと同じコマンドセマンティクスとネットワーク役割を実行しなければならない。汎用ラボルーターや非代表的なエッジでは不十分である。

カナリアには、システムの収束動作に結び付いた期間も必要である。経路問題がメッセージがより広い集団に到達した後にのみ現れる場合、ローカルコマンド成功の5秒チェックはほとんど証明しない。観測ウィンドウには、隣接関係の変更、経路配布、転送インストール、トラフィックプローブ、遅延する自動化応答を含めるべきである。

最も強力な設計は、ブラスト半径の制限を助言的ではなく強制可能にする。展開コントローラーは各段階の許可されたデバイスセットと経路スコープを知るだろう。受信者がその境界を超えるコマンドを拒否するだろう。前進する前に明示的な証拠を要求するだろう。独立したコントローラーは、不変条件が失敗したときに認可を撤回したりロールバックをトリガーしたりできる。

公開資料は、そのような制御が存在したか、インシデント後にどう変わったかを示していない。グローバル WAN がコマンドスコープを事業者の期待の問題として扱えない理由は示している。

監視はネットワーク障害を分類する前に症状を見ていた

Microsoft の説明は、初期調査で WAN が原因と確認される前に DNS を検討したことを示す。[4] この順序を扇情的に扱うべきではない。DNS タイムアウトは広範な到達可能性問題に伴うことがあり、対応者は複数の仮説を合理的にテストする。有用な問いは、可観測性が症状とメカニズムを迅速に区別できたかどうかである。

ユーザーの視点では、DNS クエリの失敗、HTTP タイムアウト、認証失敗はすべてサービス不能に見えるかもしれない。事業者の視点では、それらは異なる層で発生し、異なる復旧権限を必要とする。ネットワークがパケットをドロップしている場合、アプリケーションレベルのアラームは共有原因を特定できないまま増殖するかもしれない。

現在の Microsoft 文書は、接続、到達可能性、トポロジー、診断証拠を収集できる Network Watcher や Connection Monitor などのツールを説明している。[12]-[15] これらの機能は、階層化された監視設計が何を保持できるかを示す。同じツール、設定、アラートが2023年1月の経路をカバーしていたことを証明するものではない。

有用なインシデント証拠セットは、信号を層別に整列させるだろう。

正確なコマンドとターゲットを示す変更コントローラーイベント。
メッセージ生成と隣接関係の変更を示すルーターログ。
選択および撤回された経路を示す経路情報。
インストールされたネクストホップを示す転送証拠。
インターネット、リージョン間、ExpressRoute 経路にわたるアクティブプローブ。
顧客に見える症状を示す DNS およびアプリケーショントランザクション。
どの障害が同じネットワーク経路を共有するかを示すサービス依存関係データ。

目標は仮説検証を排除することではない。すべての依存サービスが別々のインシデントを開始する前に、共通のネットワーク障害を判読可能にすることである。経路変動、隣接関係の再計算、パケット損失が DNS や HTTP タイムアウトと同時に増加する場合、対応システムはそれらを接続できるべきである。

監視には影響を受けた経路からの独立性も必要である。障害中の WAN 経由でしか到達できないダッシュボードは、最も必要なときに消えるかもしれない。同じルーティングドメインを共有するプローブは、互いの盲点を確認し合うかもしれない。外部 BGP 観測者、ネットワーク外の合成クライアント、分離された管理接続、事業者内部テレメトリは、それぞれ異なる限界をカバーする。

説明責任は、アラートが発火したかどうかだけでなく、アラートが何を証明できたかを問う。DNS タイムアウトは失敗したトランザクションを証明する。BGP 撤回は観測点での経路更新を証明する。転送テーブルのスナップショットはデバイス上のインストールされた状態を証明する。完全な説明には、1つが他すべての代替として扱われることなく、記録が接続される必要がある。

ExpressRoute は責任がどこで移り、どこで移らないかを示す

ExpressRoute は、接続プロバイダーと Microsoft エッジロケーションを通じて、顧客に Microsoft クラウドサービスへのプライベート接続を提供する。BGP を使用して経路を交換する。Microsoft は冗長回線、多様なロケーション、回復力のある顧客アーキテクチャを推奨する。[8]-[11]

これらの制御は重要である。1つの回線、1つのピアリングロケーション、1つのプロバイダー、1つのオンプレミスルーターに依存する顧客は、回避可能な集中を生む。顧客はセッションを監視し、広告された経路を検証し、フェイルオーバーをテストし、経路の喪失に耐えるアプリケーションを設計できる。

しかし、顧客の冗長性は Microsoft のグローバル WAN 変更の制御を移さない。顧客はコマンドを選ばず、Microsoft のルーターフリート全体でその動作を検証せず、どの WAN デバイスがメッセージを受信するかを決定せず、内部収束を制御しない。すべての Microsoft 転送テーブルを検査したり、事業者のロールアウトを停止したりすることはできない。

この境界は2つの反対の誤りを防ぐ。第一は、顧客所有アーキテクチャの障害を含め、クラウドプロバイダーがすべての顧客への結果に責任があると扱うこと。第二は、事業者が制御する共通モードイベントを免責するために顧客の回復力ガイダンスを使うこと。

責任は制御によってマッピングできる。

主体	制御	負うべき証拠
Microsoft ネットワーク事業者	WAN コマンド検証、デバイスインベントリ、伝播範囲、内部ルーティング、バックボーン復旧	正確な候補状態、デバイス/バージョンカバレッジ、経路不変条件、カナリア結果、ロールバックログ、復旧タイムライン
接続プロバイダー	顧客回線、ピアリングエッジ、経路配信、ローカルフェイルオーバー	回線・セッションログ、経路変更、容量・フェイルオーバー結果
顧客ネットワークチーム	回線多様性、オンプレミスルーティング、依存関係マップ、アプリケーションフェイルオーバー	冗長性設計、テスト済み障害モード、ローカル BGP・到達可能性記録
独立観測者	外部経路・パケット測定	観測点の範囲、タイムスタンプ、方法論、観測された限界

この表は法的責任を割り当てない。事実上の責任を運用権限と整合させる。

1月のイベントは、名目上の経路多様性を事業者の共通モードに対してテストしなければならない理由も示す。2つの顧客回線は異なる物理地点で終端しても、同じ Microsoft バックボーン制御に依存し得る。パブリックインターネットのフォールバックは、影響を受けた同じ WAN を通じてサービスに到達するかもしれない。真の回復力には、経路が共有しない障害を知ることが必要である。

Microsoft の高可用性ガイダンスは顧客側の設計に有用である。[9] インシデント記録は事業者側の評価に必要である。両方が必要であり、どちらかが他方を消すために使われるべきではない。

デバイス検証は維持される証拠システムであるべき

一度きりのラボテストは異機種混在のルーターフリートには不十分である。デバイス集団は変わる。ソフトウェアはアップグレードされる。ラインカード、機能、ポリシーテンプレート、トポロジー役割は進化する。あるバージョンで証明されたコマンドは、本番セットが変われば未証明になり得る。

コマンド動作がデバイス間で異なったという公開説明は、具体的な証拠要求を生む。コマンドセマンティクスをモデル、ソフトウェア、機能、役割に結び付けるマトリクスは何か？

そのマトリクスは、展開から切り離された静的なスプレッドシートであるべきではない。現在のインベントリから生成され、変更に結び付けられるべきである。各ターゲットについて、以下を特定すべきである。

ハードウェアファミリと関連転送コンポーネント。
ネットワークオペレーティングシステムのリリースとパッチレベル。
有効な機能セットと設定パーサーの動作。
ルーティング役割、ピア数、経路規模。
期待されるコマンド展開と状態遷移。
同じ特性を使用したラボまたは本番前の証拠。
既知の例外とブロックされた組み合わせ。
検証結果の日付と所有者。

展開コントローラーは、ターゲットに現在の証拠がない場合、フェイルクローズドすべきである。事業者は、単に進めることによって「不明」を「互換性あり」に変換できるべきではない。緊急実行が必要な場合、例外は明示的で、狭く、期限付きで、より小さいブラスト半径とより強い観測を伴うべきである。

Microsoft は、影響度の高いコマンドをブロックし、安全な実行ガイドラインを作成すると報じられている。[4] 禁止コマンドクラスが正確で、実施ポイントが安易に迂回できない場合、ブロックは価値がある。ガイドラインは解釈と遵守に依存するため弱い。

したがって、有用なフォローアップの問いは運用上のものである。

どのコマンドパターンがブロックされたか？
クライアント、自動化コントローラー、デバイス、認可サービスのどの層でブロックされるか？
エイリアス、テンプレート、API、ベンダー固有のバリアントはカバーされているか？
緊急アクセスはブロックを迂回できるか、誰が承認するか？
ブロックはトポロジーと受信者数を考慮しているか？
ソフトウェアアップグレード後、その制御はどうテストされるか？
ブロックされたコマンドが別の経路で本番に到達できないことを示す証拠は何か？

公開記録はこれらの問いに答えない。問うことは Microsoft が行動しなかったことを意味しない。修復声明を検証可能な運用証拠に変えるものを定義する。

経路不変条件が期待される現実を検証可能にする

変更システムはしばしば構文と設定差分を検証する。構文的に有効なコマンドでも、ネットワークの目的に違反し得る。経路不変条件は、その目的をシステムがテストできる形で表現する。

このインシデントでは、不変条件は少なくとも4つの層をカバーできたはずである。

隣接関係の不変条件は、どの重要なピアリングが確立されたままでなければならないか、どの計画されたリセットが許可されるか、同時に許容される喪失数を示すだろう。承認されたセット外の広範な再計算は変更を停止させるだろう。

経路の不変条件は、必須プレフィックス、オリジンとネクストホップの期待、許可される経路変更、最大撤回数を特定するだろう。到達可能性が意図された IP アドレス更新の外に移動したときに検出するだろう。

転送の不変条件は、ルーターが使用可能なネクストホップをインストールしたか、代表的なパケットがそれらを通過できるかをテストするだろう。転送状態が欠如または不整合であれば、コントロールプレーンの合意だけでは不十分である。

サービス経路の不変条件は、インターネットから Azure、リージョン間、Microsoft サービス、管理、ExpressRoute の経路をプローブするだろう。ルーター状態を顧客が実際に使用する依存関係に接続するだろう。

不変条件セットには所有権と来歴が必要である。重要な経路のリストは、サービスチームが依存関係を新たに作成しても更新しなければ陳腐化する。プローブは健全な経路のみをテストする場合、誤解を招く。期待されるプレフィックス記録は、アドレスが移管されたり、ルーティング役割が台帳更新なしに変更されたりすると危険になる。

ここでレジストリの規律は、現実を支配するふりをせずに運用を支援する。正確な識別子、プレフィックス記録、ASN 関係、経路役割、所有権メタデータは、事業者が存在すべきものを定義するのを助ける。経路を到達可能にするわけではない。実行中のコードと観測されたパケット配信が決定的な層であり続ける。

説明責任のあるシステムは、期待される台帳を複数の観測と比較する。設定出力、ルーティング情報、転送エントリ、アクティブプローブ、外部経路ビューをチェックする。不一致は自動的にインシデントの証明ではないが、違いが理解されるまで影響度の高いロールアウトを停止する理由である。

同じモデルはインシデント後のレビューも改善する。「ネットワークが復旧した」とだけ言う代わりに、どの不変条件が失敗し、それぞれがいつ正常に戻り、どれが不確実なままかを報告書は示せる。それにより復旧が監査可能になり、将来の回帰テストが具体的になる。

代表的なカナリアは伝播経路を実行しなければならない

カナリア展開は、少数のターゲットに変更を適用することとよく説明される。小ささは有用だが、代表性の方が重要である。関連する障害を示せないカナリアは、健全であっても弱い保証しか提供しない。

デバイス依存の WAN コマンドでは、代表的なカナリアは本番ターゲットのコマンドセマンティクス、ソフトウェアファミリ、ルーティング役割、ピア関係、伝播動作に一致しなければならない。また、障害がカナリアが検出すべき同じグローバルな再計算を引き起こせないよう、十分に隔離されていなければならない。

この組み合わせは難しい。コマンドの危険な効果がメッセージが多数のルーターに到達したときにのみ現れる場合、単一の隔離されたデバイスでは再現できないかもしれない。解決策はステージングを放棄することではない。外部への影響を制限しつつ関連するグラフを再現するテスト環境または境界付き本番ドメインを構築することである。

強力な手順は以下になり得る。

インベントリに対して正確なコマンドをレンダリングし、静的に解析する。
代表的なラボまたはネットワークエミュレーション環境で再実行する。
期待される隣接関係、経路、転送の変更を確認する。
独立した管理アクセスを持つ1つの境界付き本番ドメインに適用する。
完全な収束と安定期間を観測する。
内部状態を外部の経路・到達可能性プローブと比較する。
明示的な証拠が合格した後にのみ次のドメインに進む。

現在の Microsoft 文書は、グローバルネットワークエンジニアリングにおけるネットワークエミュレーションと監視の概念、および顧客向け診断ツールを説明している。[7][12]-[15] これらの資料は、そのような手順を支援し得るメカニズムを示す。2023年の正確なワークフローを立証するものではない。

カナリア記録には成功基準だけでなく失敗基準も含めるべきである。何回の撤回でロールアウトを停止するのか？どの隣接関係の変更が期待されるのか？どれだけのパケット損失が許容されるのか？ロールバックまでに収束はどれだけ続けられるのか？誰が指標が誤解を招くと宣言できるのか？

事前定義された基準がなければ、対応者はブラスト半径が拡大するまで警告を通常の収束として合理化するかもしれない。基準があれば、現実が承認されたモデルから外れたときに停止が既定の結果になる。

ロールバックは分散状態を考慮しなければならない

ネットワーク変更のロールバックは、1台のデバイスの1行を元に戻すことと常に同等ではない。他のルーターがメッセージを受信し、経路を再計算し、転送エントリをインストールし、トラフィックを移動させ、自動化をトリガーしたかもしれない。発端の設定を復元することは必要だが、ネットワークは依然として安定状態に収束しなければならない。

Microsoft は、最近の WAN 変更を根本原因と特定した時点で自動復旧がすでに始まっており、復旧措置は 08:10 UTC 直後に開始されたと述べた。[1][3][4] 公開記録はすべてのロールバック手順を開示していない。この限界は重要である。復旧証拠は、コマンドの取り消しと経路の安定化、サービスの復元を区別すべきだからだ。

検証可能なロールバック計画は以下に答えるだろう。

どの設定またはコマンドが取り消されるのか？
どのデバイスが依存状態を受信し、再収束しなければならないのか？
信頼できる望ましい状態は何か？
事業者は競合する修復措置をどう防ぐのか？
どの経路、転送、到達可能性チェックが復旧を宣言するのか？
ロールバックは影響を受けた WAN から独立した管理経路を通じて進められるか？
残存するサービス影響は継続するネットワーク障害からどう分離されるか？
インシデントはいつ安全にクローズできるか？

自動化は遅延を減らせるが、トリガーと範囲が信頼できる場合に限る。コマンドの終了ステータスのみに基づく自動ロールバックは経路障害を見逃すかもしれない。アプリケーションエラー率に基づくものは反応が遅すぎたり、無関係な問題に反応したりするかもしれない。複合トリガーは、正確な期待ネットワーク変更を保護された不変条件と比較できる。

復旧記録は因果順序も保持すべきである。経路が 08:10 頃に安定し、大部分のサービスが 09:00 頃に回復し、機器が 09:35 までに安定し、一部の Microsoft 365 影響が 12:43 まで続いた場合、単一の「解決済み」タイムスタンプは有用な区別を隠す。[1][3][4]

これらの区別は事業者が将来の訓練をテストするのに役立つ。ネットワークメカニズムの検出時間、伝播停止時間、経路安定回復時間、転送回復時間、依存サービス影響の解消時間を測定できる。1つの指標の改善は他を自動的に改善しない。

したがってロールバックはボタンではなく制御システムである。その信頼性は、分散ネットワークが意図された運用現実に戻ったという保持された証拠にかかっている。

公開測定は調整されるべきで、飾りとして扱うべきではない

インシデント報告はしばしば事後に外部測定を引用する。より強力な使い方は、独立した観測を変更・復旧の決定に統合することである。

インターネット向けネットワークでは、外部 BGP データが撤回、再広告、経路変更、ピア間の違いを明らかにできる。アクティブプローブは複数のネットワークからのパケット損失、遅延、DNS 結果、アプリケーション到達可能性を示せる。これらの信号は内部テレメトリを置き換えないが、事業者自身の観測点が見逃し得るものをカバーする。

1月のインシデントは、なぜ両方が必要なのかを示す。Microsoft は内部デバイス状態を見ることができた。ThousandEyes は Microsoft の外側の経路とパケットへの影響を見ることができた。[3] 顧客やピアは第三の境界を見るかもしれない。単一の観測点がネットワーク全体を定義することはない。

調整はタイムスタンプ、範囲、不確実性を保持すべきである。あるルーターでの内部経路変更は外部での撤回に先行するかもしれない。コレクターは中間ポリシーの遅延後に更新を受信するかもしれない。転送がすでに不整合であるため、経路が正式に撤回される前にパケットプローブが失敗するかもしれない。別のプローブは利用可能なままの経路を通じて成功し続けるかもしれない。

したがって証拠システムは、すべての信号を1つの単純化されたタイムラインに押し込むことを避けるべきである。保持すべきは以下である。

元のタイムスタンプとクロックソース。
観測点の識別情報とネットワーク。
観測されたプレフィックス、ピア、経路。
コントロールプレーン対フォワーディングプレーンの分類。
信頼度と既知の盲点。
対応すると考えられる変更・復旧措置へのリンク。

外部観測者の商用分析は中立的な全知ではない。カバレッジの選択と方法論的限界がある。事業者ダッシュボードも同じである。各情報源が何を測定したかを述べ、報告がそれらの一致と不一致をテストするとき、説明責任は向上する。

これは過大主張からも保護する。公開 BGP の経路変動は、すべての Azure プライベート経路が失敗したことを証明しない。あるネットワークからの成功したプローブは、他での失敗を否定しない。グローバルサービスというラベルは均一な影響を意味しない。記録はそれらの限界を見えるままにすることで信頼性が高まる。

RPKI はこのコマンドを検証しなかっただろう

BGP 経路変動の存在は、RPKI の自動的な推奨につながり得る。それは2つの異なる制御問題を混同するだろう。

RPKI と経路オリジン検証は、自律システムがプレフィックスをオリジネートする権限を持つかどうかをネットワークが評価するのを助ける。不正または誤ったオリジンに対する重要な保護である。公開されている説明によれば、このインシデントは Microsoft の WAN 内部の計画された変更、デバイス依存のコマンド動作、広範なルーティング収束に関するものだった。入手可能な証拠は、権限のない AS が Microsoft のプレフィックスをオリジネートしたとは述べていない。

オリジンは有効でありながら経路が運用上誤っていることがあり得る。プレフィックスは権限のある AS によって広告されても、意図しないポリシー、誤ったスコープ、不安定な収束中に行われるかもしれない。RPKI は内部コマンド、すべての隣接関係、選択されたネクストホップ、転送テーブルのインストール、カナリア設計、ロールバック手順を検証しない。

この境界はレジストリと認可データを無関係にするわけではない。正確なプレフィックスと ASN 記録は、期待されるオリジンを定義し、別種のエラーを検出するのに役立つ。それらは不変条件セットの一部であるべきだ。しかし、ネットワーク継続性の証明に格上げすることはできない。

この区別はより広い運用原則を反映する。記録は識別情報、認可、期待される関係を確立する。稼働中のルーターは到達可能性を確立する。前者は後者を制約し監査できるが、後者を支配するわけではない。パケット配信はインストールされた状態に従う。

したがって、1月のイベントでは、優先制御はデバイス検証、コマンドスコープ、経路・転送不変条件、境界付き伝播、外部観測、ロールバックである。RPKI は隣接する制御であり、証拠が主張する欠けていた修正ではない。

この正確さは公的な説明責任にとって重要である。一般的な推奨は、実際の障害を避けながら記事を技術的に精通しているように見せることができる。救済策は、記録が裏付けるメカニズムに対処する場合にのみ有用である。

現在の文書は制御の主張であり、歴史的証明ではない

Microsoft の現在のネットワーク文書は、グローバルバックボーン、直接相互接続、ExpressRoute の回復力、Network Watcher、Connection Monitor、監視設計を説明している。[7]-[17] これらの資料は、アーキテクチャと事業者・顧客が利用できるツールを理解するのに有用である。

それらはタイムマシンではない。2023年1月以降に更新されたページは、インシデント中にどの設定、ワークフロー、実施が存在したかを証明できない。また、記載されたプロセスがすべてのデバイスで継続的に実行されていることを証明できない。

この区別は修復の評価方法を形作るべきである。公開文書は以下に答えられる。

Microsoft は現在どのような設計を説明しているか？
現在利用可能な監視・回復力機能は何か？
Microsoft は顧客にどのような責任を割り当てているか？
どの証拠メカニズムが使用可能か？

単独では以下に答えられない。

正確な WAN コマンドは影響を受けたルーターでテストされたか？
どのデバイスが伝播されたメッセージを受信したか？
ロールアウト前にどの経路不変条件がチェックされたか？
修復後に類似コマンドを防止する自動ブロックがあったか？
Microsoft は代表的な条件下でロールバックを訓練したか？

永続的な修復の証拠には、運用により近い成果物が必要である。ポリシー・アズ・コードのテスト、ブロックされたコマンドのログ、検証マトリクス、カナリア記録、合成プローブ履歴、ロールバック訓練、インシデント再発データ。一部は商業上またはセキュリティ上機微であり得る。機密性は編集を正当化できるが、一般的なアーキテクチャページを証明に変えることはできない。

事業者は、悪用可能な詳細を露出せずに集約された証拠を公開できる。検証済みデバイスファミリのカバレッジ率、ブロックされた影響度の高いコマンドクラスの数、許可される最大伝播ドメイン、ロールバック訓練の頻度、独立プローブが各主要変更を確認したかどうかを報告できる。測定には定義と保持された監査記録が必要である。

同じ規律が顧客向けの主張にも当てはまる。サービスが冗長ルーティングと監視機能を提供していても、顧客は購入した経路をテストする必要がある。文書は機能を説明する。運用証拠は、その機能が特定の依存関係を保護したかどうかを示す。

説明責任は制御、証拠、修復に従う

大規模障害を非難に還元したくなる。公開証拠はより有用な割り当てを支持する。

Microsoft は計画された WAN 変更、ルーターインベントリ、コマンド実行、内部メッセージ、伝播境界、監視、復旧、公開インシデント説明を管理していた。その管理は、動作の検証、範囲の制限、証拠の保持、修復の検証という義務を生む。

ルーターベンダーは製品セマンティクスと文書を管理していたが、公開記録はベンダーを特定せず、製品欠陥を立証しない。ベンダーの過失を主張することは正当化されない。

接続プロバイダーは顧客回線と相互接続エッジを管理していた。顧客は自らのルーティング、冗長性、依存関係マッピング、アプリケーションフェイルオーバーを管理していた。これらの管理は結果と復旧オプションに影響するが、Microsoft の内部コマンドを引き起こしたり支配したりはしなかった。

独立観測者は測定システムを管理していた。彼らの義務は方法論的な明確さである。どこで測定し、何を見て、何を推論できないか。

説明責任には修復も含まれる。信頼できる修復は、単に別の公開インシデントがないことではない。障害クラスが制約されたという証拠である。この場合、以下を示すことを意味する。

デバイス依存のコマンド動作が棚卸しされ、テストされる。
影響度の高いコマンドが技術的にブロックされるか、厳格に認可される。
合格した証拠なしに伝播が定義されたドメインを超えられない。
必須経路と到達可能性が機械チェックされる。
外部観測が受け入れと復旧の一部である。
ロールバックが最初のデバイスだけでなく分散状態を復元する。
訓練がフリート変更後も制御が機能することを示す。

公開記録はそれらの証明を求めることを支持する。Microsoft がそれらを無視した、イベントを隠蔽した、法律を破った、過失があったと宣言することを支持しない。

この境界付きアプローチは寛容ではない。修辞的な非難よりも厳格な基準である。すべての発見と修復の主張が、行為者、制御、保持された記録、観測可能な結果に結び付かなければならないからだ。

次のグローバル WAN 変更のための証拠テーブル

以下の表は、インシデントを検査可能な記録に変換する。Microsoft がすべての項目を欠いていると主張するものではない。制御を証明するものを特定する。

制御	保持される記録	観測された運用結果	未解決の限界
変更承認	承認された目的、正確な範囲、所有者、時間枠	意図されたターゲットのみが実行に入った	承認はコマンドセマンティクスを証明しない
レンダリングされたコマンド	ハッシュ付きの正確なコマンドまたは候補設定	展開されたバイトがレビューされたバイトと一致した	一致しても安全とは限らない
デバイス検証	モデル、ソフトウェア、役割、機能、テストマトリクス	すべてのターゲットが現在の互換性証拠を持っていた	ラボ規模は本番と異なり得る
伝播境界	許可された受信者と隣接関係グラフ	メッセージがカナリアドメイン内にとどまった	隠れた依存関係が境界を越え得る
経路不変条件	必須プレフィックス、経路、撤回閾値	未承認の経路喪失や変動がなかった	内部経路は外部可視性を欠き得る
転送不変条件	ネクストホップとパケット配信チェック	代表的なパケットが有効な転送エントリを使用した	サンプルはすべてのフローをカバーしない
外部 BGP 観測	タイムスタンプ付き撤回、広告、経路	公開ルーティングが安定または回復した	コレクターカバレッジは不完全である
エンドツーエンドプローブ	インターネット、リージョン間、ExpressRoute、DNS、HTTP テスト	サービス経路が定義された成功閾値を満たした	プローブは顧客固有の経路を見逃し得る
自動停止	トリガー、決定ログ、ターゲット状態	より広い伝播の前にロールアウトが停止した	悪い閾値は遅すぎる停止になり得る
ロールバック	信頼できる望ましい状態とアクションログ	隣接関係、経路、転送、プローブが回復した	サービス修復はその後も続き得る
独立管理	帯域外到達可能性テスト	WAN 障害中も事業者が制御を保持した	分離されたアクセスが別の依存関係を共有し得る
修復後訓練	シナリオ、期待される障害、結果、所有者	同じ障害クラスが封じ込められた	1回の訓練は継続的なコンプライアンスを証明しない

この表は記録と結果を分離する。文書は制御が規定されたことを証明する。運用観測は実行中に何が起こったかを証明する。両方が必要である。

また未解決の限界も保持する。証拠システムは、部分的な測定を完全な確実性として提示すると誤解を招く。経路コレクターはすべてのプライベート経路を見られない。カナリアはすべての顧客経路を代表できない。成功したロールバック訓練はアップグレード後に陳腐化し得る。限界を挙げることが次のテストを生む。

境界付き検証アジェンダ

このインシデントは、憶測なしに具体的な一連の問いを支持できる。

コマンドセマンティクス

デバイス間で異なった正確なコマンド動作は何か？
どのハードウェア、ソフトウェア、役割、設定コンテキストが違いを説明するか？
候補コマンドは実行されたものと同じレンダリング形式でレビューされたか？
未検証のバリアントが本番に到達するのを防ぐ現在の制御は何か？

伝播

発端の変更からどのルーターがメッセージを受信したか？
意図された受信者セットは何だったか？
どの隣接関係と転送の再計算が期待されたか？
現在同じクラスの変更を制限する技術的境界は何か？

経路と転送状態

どのプレフィックスと経路が変わったか？
どの経路不変条件が逸脱を検出できたか？
転送はいつ不整合になり、いつ安定したか？
内部観測は外部 BGP 変動とどう調整されたか？

到達可能性

どのインターネット、リージョン間、ExpressRoute、管理経路が失敗したか？
どのプローブが機能し続け、なぜか？
代替経路には十分な容量があったか？
DNS 症状と WAN 障害を区別した証拠は何か？

復旧

どの措置が自動復旧を開始したか？
発端コマンドが取り消された後、どのシステムが再収束しなければならなかったか？
どの基準がネットワーク機器の安定を宣言したか？
一部のサービス影響が広範な経路安定化よりも長引いた理由は何か？

永続性

影響度の高いコマンドは技術的にブロックされているか、ガイダンスのみで統制されているか？
デバイス検証マトリクスはどの頻度で更新されるか？
代表的なトポロジーに対してロールバックは最後にいつ訓練されたか？
機微な設定を露出せずに継続的な実施を示せる集約証拠は何か？

これらの問いは、答えられるほど具体的で、実践を変えるほど強力である。一般的な回復力の約束ではなく、稼働中のネットワーク現実に焦点を当てる。

結論

Microsoft の2023年1月の障害は、コマンドセマンティクス、デバイスの多様性、伝播、収束が検証された状態によって制約されない場合、日常的な WAN 保守目的がグローバルインフラのイベントになり得ることを示した。

証拠は2つの面から来るため、異常に教訓的である。Microsoft の説明は、このインシデントを計画されたルーターアドレス変更、デバイス依存のコマンド動作、他の WAN ルーターへのメッセージ、隣接関係と転送の再計算、パケット転送の失敗に結び付ける。ThousandEyes は Microsoft のネットワーク周辺で BGP 撤回、再広告、経路変動、パケット損失を独自に観測した。[1]-[4]

どちらの記録も完全ではない。合わせて説明責任の基準を定義する。

変更チケットは、ルーターが実行する正確なコマンドに結び付くべきである。検証は本番のデバイスとソフトウェア集団をカバーすべきである。カナリアは伝播を制限しつつ関連トポロジーを実行すべきである。経路、転送、サービス経路の不変条件は、現実が意図から外れたときにロールアウトを停止すべきである。独立観測者は事業者のドメインを離れるものをテストすべきである。ロールバックは分散状態を復元し、経路回復からサービス復元までのタイムラインを保持すべきである。

正確なネットワーク記録は重要である。プレフィックス、AS 関係、デバイスインベントリ、トポロジー、コマンド来歴、期待される経路がシステムを検証可能にする。それらは宣言によってパケット配信を制御しない。稼働中の設定と結果の転送状態が決定的であり続ける。

それが中核的な説明責任の教訓である。コマンドと伝播ドメインを制御する事業者は、変更が計画されていたことだけでなく、ネットワークが承認どおりに動作したという証拠を提示しなければならない。顧客とプロバイダーは自らの管理範囲内で義務を保持するが、クラウド事業者のプライベートバックボーンコマンドを検証したり停止したりすることはできない。標準と RPKI は隣接するリスクを制約できるが、デバイス固有の実行経路を検証できない。

したがって最強の修復は、より広範な注意の約束ではない。意図からレンダリングされたコマンド、代表的な検証、境界付き伝播、観測された経路状態、独立した到達可能性、制御されたロールバック、繰り返しの訓練までの現在の監査可能な連鎖である。それ以下では、次のグローバル WAN 変更は証明よりも期待によって支配されたままになる。

情報源の限界

ここで使用する Microsoft 365 の顧客向けレポートは、自らを暫定的と位置付け、関連する WAN インシデントについて読者を Azure ステータス履歴に誘導する。Microsoft のステータスページは動的であり、過去の詳細には追跡識別子が必要な場合がある。当時の報道は Microsoft の後の公開説明を要約するが、内部変更記録の代替ではない。[1][2][4]

ThousandEyes は、独自の測定カバレッジから独立したルーティングとパケット観測を提供する。その BGP ビューは、すべてのプライベート Microsoft 経路、コマンド、隣接関係、転送エントリ、顧客経路を立証できない。[3]

現在の Microsoft Learn ページは、読まれた時点のアーキテクチャと利用可能な機能を説明する。2023年1月25日の制御の正確な状態やその後の継続的な実施を証明しない。[7]-[17]

公開記録は、正確なコマンド、完全なデバイス・ソフトウェアインベントリ、影響を受けた全プレフィックス、すべての内部ログ、顧客固有の損失、契約上のクレジット、規制上の認定、悪意、過失、ベンダーの欠陥を開示していない。本記事はそれらのいずれも主張しない。