OVH の 2017 年光ネットワーク障害と冗長性の独立性

要約

事象の境界は狭い：本記事が扱うのは 2017 年 11 月 9 日のルーベ光ネットワーク障害のみである。同時に起きたストラスブールの停電は、仕組みと制御系統が異なる別の事故である。
目に見えた障害は広範囲だが全停止ではない：当時の記録は、OVH の 6 つのネットワーク接続点へ向かうルーベの接続が失われたと述べている。それは OVH のすべての経路、顧客、ワークロードが同じ形で停止したことを証明するものではない。
名目上の多様性は運用上の独立性をもたらさなかった：OVH は冗長な光接続を説明していたが、設定消失後、ルーベのリンクは同時に利用不能となり、保存済み設定から復旧する必要があった。
公開されている根本原因には 2 つの層がある：OVH は直接の原因をソフトウェア欠陥と光装置の設定消失に帰した。連動した損失は、物理経路の多様性では取り除けなかった共有の設定・監視障害領域も露呈させた。
保存済み設定は独立した復旧システムではない：保存済み設定があって復旧できたが、その存在が稼働中の光システムの可用性を維持したわけではない。バックアップの有無、復旧権限、検証済みの復旧可能性は別々に評価しなければならない。
責任は制御に従う：OVH はアーキテクチャ、展開、設定保護、監視、復旧、顧客対応を管理していた。装置メーカーは製品欠陥の調査とソフトウェア修正を管理していた。ピア、トランジット網、顧客は自らの外部多様性を管理できたが、OVH 内部の光状態は管理できなかった。
公表された修復は 2 つの問題を正しく分けた：OVH は装置メーカーと共にソフトウェアアップグレードと、光多重化システムを 2 系統に分割する計画を示した。前者は欠陥への対処、後者は再発時の影響範囲の限定を意図していた。
修復は公表だけでは証明されない：信頼できる完了確認には、トポロジーと設定の証拠、障害注入試験、独立した到達性計測、そして 1 つの制御障害でルーベの外部経路すべてを失わせることができないことの証明が必要である。

責任を割り当てる前にルーベの事象を確定する

OVH は同じ日に 2 つの重大障害を経験した。ストラスブール拠点では電力障害、ルーベでは光ネットワーク障害が起きた。OVH の後の声明は、2 つの事故が同時に発生したが無関係であると明示的に述べている。その区別こそが説明責任の出発点であり、大きな物語にまとめて消してよい細部ではない。[1]

2 つの事故を混同すると因果関係を誤る。ストラスブールは電力供給、切替装置、発電機、サービス再起動が関わった。ルーベは光伝送、設定消失、外部拠点への接続が関わった。責任を持つシステム、運用者、ベンダー、検知信号、復旧手順、予防試験はそれぞれ異なる。

したがって本記事は、ルーベの光障害から、関連リンクとホスティング拠点の接続が復旧し、その後に OVH が公表したルーベ固有の是正策までを扱う。ストラスブールの電力事故、2017 年 7 月のストレージ事故、同年 12 月の別のネットワーク事故、2021 年のストラスブール火災、2021 年の別のルーティング事象は除外する。これらは OVH の通史には役立つかもしれないが、ルーベ光障害の原因や修復の証拠としては使えない。

公開されている時系列には 2 つの有用な層がある。OVH の公式声明は、ルーベ拠点が 2 時間半以内に運用に復帰したと述べた。影響を受けたサービス事業者は別途、同じ朝に顧客から見て到達不能だった時間を記録し、光設定の回復後に復旧したと説明した。[1][4]

これらの記録は光復旧の時間枠を異なる層で述べている。すべての顧客サービスがまったく同時に復旧したとまでは言えない。ホスティング拠点は積み重なった構造であり、伝送リンクが戻り、ルーティングセッションが再確立し、経路が収束し、ロードバランサーとアプリケーション依存関係が回復し、メールキューが流れ、監視が正常化し、顧客が再試行する。公開証拠からはサービスごとの完全な復旧表は得られない。

同じ規律は事故の開始時点にも当てはまる。影響を受けたサービス事業者は同日朝、一部のネットワークからは到達できたが他からは到達できなかったと述べ、OVH は事業者側の光障害とその後の復旧を説明した。これらの見解は必ずしも矛盾しない。一方は外部の顧客から観測した影響を記録し、他方は事業者の光システム内の事象を記録している。観測者、時計、経路が異なれば境界も異なりうる。[4]

説明責任のためには、1 つの完全な時刻に強引に合わせるのではなく、そうした区別を保つ必要がある。強固な事故記録なら、外部プローブ、光アラーム、インターフェース状態遷移、コントローラーログ、ルーティングセッション変更、顧客報告を共通の時計に合わせて突き合わせる。公開資料は完全な突き合わせを提供していないため、本記事では捏造しない。

稼働中のネットワークが明らかにしたもの

影響を受けたサービス事業者の説明によると、ルーベ拠点は OVH の 6 つのネットワーク接続点へ向かう光伝送に依存していた。公開記録は複数の光パスと外部接続の広範な喪失を述べているが、すべての回線、顧客経路、依存関係について完全に検証されたトポロジーは示していない。[4]

これらの詳細が重要なのは、この事象が日常的な単一ファイバー断として説明されていないことを示すからだ。OVH と当時の記録は、光システムに影響するソフトウェアおよび設定の障害と、その後の装置メーカーとの復旧作業を述べている。入手可能な情報源は、完全な診断手順や内部の管理プレーン状態を明らかにしていない。[1][4]

公開されている根本原因の説明では、光装置の設定消失が特定された。OVH は保存済み設定を回復し、影響を受けた接続を復旧させた。同社は直接の原因をソフトウェア欠陥に帰したが、連動した経路喪失は共有設定と監視依存関係というより広い問題を浮かび上がらせた。[1][4]

これは意味のある説明だが、完全なフォレンジック報告ではない。正確なソフトウェアバージョン、最初の状態変化、プロセス停止、保存処理の順序、レプリケーションの意味論、制御プレーンの選出、人によるコマンド、アラームの時系列、内部事故記録は開示されていない。設定消失が唯一の引き金だったのか、より深い制御障害の目に見える結果の 1 つだったのかも証明されていない。

最も強く擁護できるのは、より狭い主張である。OVH の光装置はルーベの外部リンクが利用できない状態に入った。OVH はその状態をソフトウェア欠陥と設定欠落に帰した。保存済み設定の復旧により接続は戻り、OVH は後にソフトウェア修正とアーキテクチャ分離の両方を提案した。

一次証拠は稼働中のネットワークである。台帳記録はファイバー、経路、カード、バックアップが存在すると言える。設計文書はリンクが冗長であると言える。事故中に重要だったのは、光システムがルーベ到達性に必要な外部接続を提供しなくなったことだ。運用状態が名目上の構成図を上回る。

これがネットワーク基盤の説明責任の中核である。冗長性は構成要素の数だけで評価すべきではない。サービスを喪失させうる障害領域によって評価すべきである。

物理的な多様性は制御領域の独立性ではない

耐障害性のある伝送の一般的なイメージは、2 地点間の 2 本の回線である。一方のファイバーが切断されても、トラフィックは他方を使う。このモデルは狭い物理的危険には有用だが、両方の経路がソフトウェア、設定権限、監視ハードウェア、時刻同期、電力、管理アクセス、起動ロジック、共通の復旧手順を共有している場合は不完全である。

地理的に異なる 2 つの光パスでも、運用上の障害領域は 1 つになりうる。同じデータベースに支配されるカードに終端するかもしれない。同じコントローラーや監視ペアに依存するかもしれない。同じ欠陥のあるソフトウェアイメージを受け取るかもしれない。1 つの設定トランザクションを引き継ぐかもしれない。診断に 1 つの管理ネットワークを必要とするかもしれない。共通の安全状態に入ったときにフェイルクローズするかもしれない。

OVH の説明はこの区別の具体的な例である。事業者は冗長な光接続を説明していたが、設定消失時にはルーベのリンクが同時に使えなくなった。接続を維持するはずの制御は、実際に起きた共有の設定状態障害を封じ込められなかった。[1][4]

これは物理的多様性が無益だったという意味ではない。異なる危険に対処していたという意味である。耐障害性の主張は、それが封じ込める危険の種類を明示すべきである。

単一ファイバーの切断
管路または地理的経路の障害
1 台の光増幅器またはノードの喪失
1 枚のラインカードまたはシャーシの喪失
1 台のコントローラーまたは監視カードの障害
設定の破損または欠落
共通のソフトウェア欠陥
管理接続の喪失
冗長システム全体に波及した運用ミス
事故条件下での復旧失敗

ある設計は最初の 3 つを満たしても、6 番目や 7 番目で失敗しうる。保護される障害の種類を明示せずに結果を「冗長」と呼ぶことは、最も重要な問いを覆い隠す。

RFC 3439 は一般的なアーキテクチャの観点から、複雑性には実コストがあり、システムは予期しない相互作用で故障しがちだと警告している。これは OVH の事故について書かれたものではなく、同社の内部設計を証明するものでもない。構成要素、複製、自動化を追加すると、その挙動が制限され観測可能でない限り、共有状態と新たな故障モードを生みうるという有益な分析規律を提供している。[14]

NIST のサイバーレジリエントシステム指針も同様に、レジリエンスを予測、耐性、回復、適応の工学的な能力として扱う。これは後の枠組みであり、OVH が 2017 年に展開していたものを示す証拠ではない。注意深く適用すれば、ネットワークは予防の主張だけでなく、劣化の境界、復旧権限、証拠保全、障害後の適応によって評価すべきだと示唆している。[17]

ITU 勧告が述べる光伝送アーキテクチャは、レイヤー、トレイル関係、プロテクションを表す語彙を提供する。公開事実から OVH の非公開トポロジーを再構成することはできない。ここでの価値は、光伝送が単なる受動的なガラスではなく、制御、監視、復旧機能を備えた管理されたネットワークであるという一般論を補強することにある。[18]

したがって説明責任の試金石となるのは重複ではなく独立性である。運用者は、どの要素が独立で、どれが意図的に共有され、それぞれの共有要素が故障したときに何が起きるのかを特定できるべきである。

保存済み設定は運用上の可用性と同義ではない

OVH の事故説明は保存済み設定が復旧されたと述べている。この詳細は基盤保証で繰り返される問題を示す。バックアップの存在が、往々にして回復可能性と同等に扱われる。

バックアップは存在してもサービスを維持できないことがある。同じ障害領域内に保存されているかもしれない。複製が同じ欠陥ソフトウェアの影響を受けるかもしれない。同じ破損状態を含むかもしれない。システムが自動的に選択・ロードできないかもしれない。管理アクセスが使えないかもしれない。運用者が物理的な対応を必要とするかもしれない。復旧手順が遅く、曖昧で、共通障害下で未試験かもしれない。

ルーベの経緯は、技術者が最終的に保存済み設定を回復したことを示している。それは成功した復旧措置だった。同時に、回復可能な設定が存在したからといって稼働中のシステムが可用性を維持していたわけではないことも示している。[1][4]

したがって関連する管理策は「バックアップがあった」よりも精緻でなければならない。

コピーされた正確な対象は何か。完全なデータベース、生成された設定、装置状態、トランザクションログのいずれか。
それぞれのコピーを書き込んだプロセスはどれか。1 つのソフトウェア欠陥がすべてを破損させうるか。
コピーは不変か、独立してバージョン管理されていたか。
物理的・論理的に分離されたシステムに保存されていたか。
コピーが使用可能かを決める整合性規則は何か。
故障した管理コンポーネントなしで既知の正常版を選択できたか。
復旧は自動か、運用者の承認が必要か、ローカルアクセスに依存していたか。
直近の試験で完全復旧にかかった時間はどれほどか。
復旧は意図した状態を再現したか、それとも最後に複製された状態にすぎなかったか。
すべての光ノードとルーター向けリンクが正しく復帰したことを確認する証拠は何か。

公開資料はこのリストの一部にしか答えていない。設定復旧が可能だったことは示している。復旧が独立しており、事前承認され、定期的に訓練され、サービス目標に対して計測されていたことは示していない。

この区別は顧客や取締役会への報告に影響するべきである。「設定はバックアップされていた」は台帳上の記述である。「既知の正常な設定を、独立した制御経路で、試験済みの時間内に復旧でき、証拠を保全しつつ不良状態の再導入を防げる」は運用管理上の記述である。

光伝送はホスティングサービスの一部だった

ホスティングの説明責任はサーバーやデータセンターレベルで語られることが多い。ルーベの障害は、その境界が狭すぎる理由を示している。サーバーは通電され正常でも、拠点を外部相互接続点につなぐ光伝送が故障すれば到達不能になりうる。

OVH の公開ピアリング資料と現在の PeeringDB および RIPE の記録は、AS16276 と相当な相互接続範囲を特定している。これらの記録はネットワークの同一性と事業者の帰属に有用である。顧客や調査者が OVH のネットワークを他事業者と区別し、相互接続が行われうる場所を特定する助けになる。2017 年時点のルーベ回線の運用状態、特定のパケットが使用した経路、任意の 2 つの顧客サービスの独立性を証明するものではない。[8][9][10][11]

これは現実層の区別である。レジストリやディレクトリは自律システムを誰が運用するかを記録できる。ピアリングページは方針を説明できる。経路コレクターは選択された BGP 観測を保存できる。しかし、故障した光システムにトラフィックを運ばせることはできない。

逆に、光障害がネットワークの同一性を消したわけではない。AS 番号、経路、外部関係は、どのネットワークがトラフィックを発信・転送するはずだったかを診断する有意義な証拠であり続けた。記録と稼働基盤は異なる説明責任の機能を果たす。記録は権限を特定・保全し、稼働中のシステムはパケットが動くかを決める。

「冗長」ホスティングや同一事業者の複数サービスを購入する顧客は、依存関係が事業者内部で収束していないかを問う必要がある。別々のクラスタにある 2 台の仮想マシンが同じ拠点伝送を共有するかもしれない。異なる建物の 2 つのサービスが同じメトロ光システムを共有するかもしれない。広告された 2 つの経路が 1 つのコントローラーや設定データベースに収束するかもしれない。製品名やリソース数からはこうした依存関係は見えない。

Actility の報告は示唆的な外部視点を提供する。別のデータセンターでホストされる SaaS 提供は影響を受けなかった一方、一部のサービスは到達不能だったと述べている。一部の場所やネットワークからは到達でき、他からは到達できなかったとも述べている。[4] このパターンは依存関係と経路多様性に整合するが、公開データはすべての経路やサービスを対応付けるには不十分である。

顧客への教訓は単に「事業者を 2 つ使え」ではない。マルチベンダー設計は集中を減らせるが、DNS、ルーティング、データ整合性、セキュリティ、運用複雑性という独自の問題を生む。より強力な要件は、依存関係の境界を文書化し、重要な障害を試験することである。

影響は観測可能な証拠に結び付けたままにすべき

OVH は他のサービスへの直接的な影響を認め、顧客メールの受信が特に困難だったと述べた。同社は謝罪し、チームが引き続き対応に当たっていると述べた。[1] 当時の報道はルーベ環境全体にわたる大きな顧客影響を述べている。[5][6][7]

公開情報源は、影響を受けた顧客数の完全な集計、パケット損失の時系列、経路ごとの分析、サービス台帳、売上影響、最終的な SLA 表を提供していない。ルーベのすべてのワークロードが光障害の間ずっと到達不能だったことも立証していない。また、1 つの公開プローブが成功しただけでサービスが健全だったとも立証していない。

異なるネットワークは異なる挙動を観測しえた。ルーティングポリシー、キャッシュされた DNS 応答、既存セッション、代替サービス拠点、アプリケーションの再試行ロジックはすべて、目に見える影響に作用しうる。全アクセスを失った顧客もいれば、残った経路や別拠点を通じてサービスに到達できた顧客もいるかもしれない。メールはキューに溜まり後で届くため、伝送障害は恒久的な喪失ではなく遅延として現れうる。

正しい影響の記述には 3 つの層がある。

事業者が報告した基盤への影響：ルーベ拠点が OVH の説明にある外部光リンクを失った。
外部から観測されたサービス影響：顧客と少なくとも 1 つのホスティング事業者が、部分的または広範な到達不能と特定サービスの中断を報告した。
完全な影響は不明：公開記録は影響を受けたすべての顧客、フロー、経路、サービス、財務的影響を網羅していない。

これらの層を保つことで過小評価と誇張の両方を防げる。完全な影響が不明と言っても事象を矮小化するわけではない。拠点の主要光リンクを失うことは本質的に重大である。証拠が裏付けていないのに全面的な停止を主張する必要もない。

説明責任のある影響報告なら、独立ネットワークからの時間区切り付き到達性、BGP セッション状態、リンク可用性、集約トラフィック、メール滞留、主要サービスの健全性、顧客チケット量、復旧分布を公表するだろう。サンプリングの限界と時計についても述べ、伝送の復旧とアプリケーションの復旧を分けて示すだろう。

管理区分：分散責任は責任の不在ではない

ネットワーク基盤は組織の境界をまたぐ。そのため責任は「共有」されていたという曖昧な結論に陥りがちである。より良い方法は、管理に応じて責任を割り当てることである。

OVH

OVH はルーベ光ネットワークのアーキテクチャ、物理経路と制御システムの関係、権限範囲内のソフトウェア展開、設定保護、監視、事故エスカレーション、現地対応、復旧手順の順序、顧客対応、設計変更の決定を管理していた。

その管理は具体的な義務を生む。OVH は共通障害領域を特定し、ソフトウェアを安全に段階展開し、既知の正常な設定を保全し、独立した診断経路を維持し、復旧を試験し、顧客の期待を設定し、修正後の設計が再発を封じ込めることを示す証拠を作成する必要があった。

OVH が装置ソフトウェアの欠陥を作ったとは限らない。それは同社のアーキテクチャ上の責任を消さない。運用者は、1 つのベンダー欠陥が自社サービスにどう影響しうるかを選ぶ。欠陥がすべての冗長経路に及ぶか、ロールバックできるか、故障したコントローラーを迂回できるかを決める。

装置メーカー

装置メーカーは製品開発、欠陥分析、修正ソフトウェア、ベンダー診断、OVH に提供される開示情報を管理していた。公開記録によると、OVH はメーカーと共に調査し、影響を受けたソフトウェアのアップグレードを計画していた。[1][4]

ベンダーの公開報告がないため、本記事は正確なソフトウェアエラーを特定できず、欠陥が以前から知られていたかも断定できない。それでも、設定が消えた、または使用不能になった理由を特定し、修正コードが障害を防ぐことを示す製品側の作業はメーカーが担っていた。

ピアとトランジット提供事業者

外部ネットワーク事業者は自らのリンク、BGP セッション、経路優先度、監視、エスカレーションを管理していた。OVH への到達性喪失を観測し、代替相互接続がある場合は適応できた。OVH 内部の光設定を復旧することはできなかった。

明示的なインポート・エクスポートポリシーなどの BGP 運用慣行は、ドメイン間境界で不可欠である。RFC 7454 と RFC 8212 は、この光事象の診断ではなく、後の、または一般的なルーティング保護策である。光の復旧だけでは正しい経路交換を証明できないため重要である。インターフェースが復帰した後、明示的なルーティングポリシーは経路回復を限定的に保つのに役立つ。[15][16]

顧客

顧客は事業者の選択、サービス配置、外部監視、DNS とアプリケーションのフェイルオーバー、データ複製、自らの事故対応連絡を管理していた。OVH から複数の製品を購入した顧客は、それらの製品がルーベの光障害領域を共有していない証拠を求めることができた。

顧客は OVH 内部の光装置状態、設定システム、光トポロジーを管理していなかった。より多くの冗長性を購入できたはずだからといって、事業者内部の伝送障害の責任を顧客に転嫁するのは誤りである。顧客の耐障害性と事業者の説明責任は補完関係にあり、代替関係ではない。

規制当局、ディレクトリ、観測者

レジストリ、ASN、ピアリングの記録は帰属と歴史的分析を支える。計測プラットフォームは選択されたルーティング観測を保存できる。標準化団体は有用な設計・運用原則を定める。いずれもルーベのシステムを運用しておらず、復旧もできなかった。

この割り当ては 2 つの誤りを避ける。1 つ目は、ベンダーのバグを事業者の障害の完全な言い訳にすること。2 つ目は、境界外にある顧客と相互接続の管理を認めずに、すべての結果を OVH に帰すことである。説明責任は、防止、検知、封じ込め、復旧、証明する能力に従う。

検知と診断は管理面の一部である

公開記録は最初の内部アラーム、そのタイムスタンプ、重大度、担当、診断の質を開示していない。顧客が到達不能を認識し、OVH がチームを動員したことは分かっている。監視が最初に特定したのが光伝送の喪失か、管理障害か、ルーティングセッションの喪失か、トラフィック崩壊か、顧客の症状かは分からない。

検知設計は停止時間に影響するため、その欠落した証拠は重要である。「ホスト到達不能」というアラームは、光コントローラー状態、データベース健全性、カードモード、管理到達性、ルーターインターフェース状態、外部経路喪失を示す相関記録よりも有用性が低い。

共通制御の障害は監視も損ないうる。監視カード、管理ネットワーク、設定サービスが同じ障害領域を共有していれば、システムはサービスと説明用テレメトリーの両方を失いかねない。技術者はその後、広範な症状、不完全なリモートアクセス、揮発性の証拠が保全される前に機器を再起動しなければならない圧力という暗い障害に直面する。

独立した診断経路は、同じ制御プレーン上の 2 つ目のインターフェースを意味するだけでは不十分である。別系統の電力・管理アクセス、最小限の依存関係、既知のセキュリティ境界、一次系が損なわれたときに状態を取得できる能力を備えるべきである。

設計には運用上の権限も必要である。誰が設定をリセットできるか。どの証拠を最初に取得すべきか。どの既知の正常版をロードできるか。いつ現地対応が必要か。再起動のリスクを継続停止とどう比較衡量するか。存在しても迅速に承認できない復旧計画は効果的な管理策ではない。

ルーベの経緯は、光システムの復旧にバックアップの存在を確認する以上のことが必要だったことを示している。[4] これは復旧時間をアーキテクチャ上のパラメーターに変える。復旧が複数コンポーネントの再起動と順序付けに依存するなら、それらの依存関係は耐障害性試験とサービス目標に現れるべきである。

公表された修復は欠陥修正と影響範囲の制御を分けた

OVH のルーベ向け公式対策計画は 2 部構成だった。装置メーカーと共にソフトウェア欠陥を調査し、アップグレードで修正する計画。そして障害範囲を限定するため、光多重化システムを 2 つの分離したシステムに分ける計画を加速すること。[1]

この分離は技術的に重要である。ソフトウェア修正は既知の欠陥に対処する。アーキテクチャ分離は、別の欠陥や異なる共通制御障害の可能性を含む不確実性に対処する。

ソフトウェアパッチは故障クラス全体が消えたと証明できない。コード内の 1 つの経路を修復しても、共有設定、監視、管理の依存関係を変えない場合がある。逆に、既知の欠陥を修正せずにシステムを分離すると、同じソフトウェアと状態が同一に展開され、独立して故障する 2 つのシステムができるかもしれない。

したがって強力な是正計画は両方の次元を試験する必要がある。

欠陥修正

ベンダー勧告または欠陥記録を影響を受けたソフトウェアバージョンに結び付ける。
正確な故障条件、影響コンポーネント、修正後の挙動を特定する。
代表的なシステムに修正イメージを段階展開する。
設定移行、ロールバック、状態保全を検証する。
以前に設定消失を引き起こした条件を再現する。
障害がもはや発生しないことを示すログを保全する。

障害領域の分離

どの光パスが各システムに終端するかを文書化する。
必要に応じて制御、監視、設定保存、管理アクセスを分離する。
1 つの設定トランザクションが両方のシステムを無効化しないようにする。
ソフトウェア展開をカナリア方式で行い、すべての経路に達する前に停止できるようにする。
1 つのシステム喪失後も、定義されたサービス目標に十分な外部容量と到達性が残ることを証明する。
縮小トポロジー下でトラフィック移動とルーティング収束を試験する。

復旧の証拠

故障した制御コンポーネントに依存せずに既知の正常な設定を復旧する。
検知、判断、復旧、リンク復帰、経路収束の時間を計測する。
復旧前後のチェックサムとトポロジー状態を保全する。
内部リンク状態を独立した外部プローブと比較する。
最初の ping 成功で全快を宣言せず、残存エラーを記録する。

OVH の公開声明は分割を行う意向を文書化している。本記事のために固定した情報源は、完了日、実装図、独立試験、その後の再発訓練を提供していない。責任ある結論は、公表された方向性は正しい管理区分に対処したが、その有効性はこの記録では証明されていないというものだ。

冗長性の独立性をどう試験するか

運用者は障害領域マトリクスを作ることで、この事故を再現可能な監査に変えられる。顧客に関係する各経路を、物理経路、光ノード、ラインカード、シャーシ、監視システム、設定ストア、ソフトウェアリリース、管理ネットワーク、電力、時刻同期、運用者グループ、復旧権限に対して対応付ける。

マトリクスは「冗長」とされる経路の各ペアについて、どのコンポーネントが両方を依然として喪失させうるかという単純な問いに答えるべきである。

この分析はトポロジー図で隠れた依存関係をしばしば明らかにする。別々のファイバーが同じ建物に入るかもしれない。別々のシャーシが 1 つのコントローラーを使うかもしれない。別々のコントローラーが 1 つのデータベースクラスタを共有するかもしれない。別々のソフトウェアインスタンスが共通の自動化パイプラインから 1 つの不良設定を受け取るかもしれない。別々のデータセンターが 1 つの DNS、ID、ネットワーク制御サービスに依存するかもしれない。

マトリクスは試験されるまでは仮説にすぎない。有用な試験には次のものがある。

1 本の物理ファイバーを取り除き、自動光プロテクションを確認する。
1 台のシャーシを取り除き、容量が宣言された目標内に残ることを確認する。
1 つのコントローラーを隔離し、他方のシステムが危険な状態収束なしに稼働し続けることを確認する。
設定レプリカを破損または隔離し、安全な選択を確認する。
主管理経路を遮断し、独立経路で診断する。
意図的に拒否されるソフトウェアイメージをカナリアに展開し、展開の封じ込めを確認する。
時間的プレッシャーの下で既知の正常な設定を復旧する。
独立ネットワークから BGP とデータプレーンの収束を計測する。
顧客向けステータスが機器の健全性だけでなく観測されたサービスを反映することを確認する。
外部レビュー担当者が結論を再現できる十分な証拠を保持する。

合格条件は試験前に定義すべきである。「トラフィックが回復した」は曖昧すぎる。有用な条件は、最小容量、最大到達性喪失、許容パケット損失、収束時間、サービスクラス、外部観測点、証拠保持要件を明示する。

試験では保守も考慮すべきである。多くの一般的な障害はアップグレードや設定変更中に起きる。冗長システムが意図的に揃えられている時期である。ランダムなカード喪失に耐える設計も、共通の自動化ジョブが同じ不良状態を両側に押し込めば失敗しうる。

独立運用はすべてのコンポーネントを異なるものにする必要はない。完全な異種構成は複雑性とエラーを増やしうる。必要なのは、共有依存関係を明示的、限定的にし、試験済みの復旧と整合させることである。目標は多様性の見せかけではない。もっともらしい 1 つの障害が、冗長と広告されたすべての経路を静かに機能不全にできないという証拠である。

反実仮想の管理策は最初の見逃しを明確にする

反実仮想分析は、ある管理策があれば確実に事故を防げたと装うべきではない。観測可能な管理策がどこで手順を変ええたかを問うものである。

ソフトウェア欠陥を展開前に捕捉していたら

代表的なステージング環境、カナリア展開、ベンダー欠陥試験のいずれかが、本番システムに達する前に故障状態を露呈させたかもしれない。公開証拠からは、欠陥がステージングで再現不可能なまれな手順を必要としたかは分からない。したがってこの反実仮想は可能性であり、証明ではない。

光システムに独立した制御状態があったら

2 つの経路群が別々の設定権限と監視システムを持っていれば、一方の設定データベース喪失でも他方の群は稼働し続けられたかもしれない。OVH が公表したシステム分割は、共通障害範囲を減らす価値を同社が認識したことを示唆する。事故前の正確なトポロジーは非公開のため、この反実仮想の大きさは計算できない。

設定復旧に独立した経路があったら

既知の正常で不変な設定とアウトオブバンドの復旧機構があれば、診断・復旧時間を短縮できたかもしれない。事故説明は保存済み設定が最終的に復旧されたと述べている。独立した復旧経路が存在したか、どう試験されたか、復旧のどの程度が影響を受けた管理環境に依存したかは示していない。

顧客に独立したホスティング経路があったら

別のデータセンターや事業者を使う顧客は、一部のサービス影響を回避できたかもしれない。Actility は別データセンターの SaaS 提供が影響を受けなかったと報告した。[4] この観測は依存関係の多様化を支持するが、すべてのマルチサイト設計が成功したはずとは証明しない。

外部到達性の証拠が統合されていたら

独立プローブとルーティング観測は、ローカル機器の復旧と顧客到達性の区別に役立ったかもしれない。光リンクを復旧させることはできない。その価値は、より速い診断、範囲を絞った連絡、より強力な完了証明にあっただろう。

公開証拠から最初の見逃しを断定することはできない。ソフトウェア保証、アーキテクチャ、設定状態保護、監視、復旧設計、またはその組み合わせだったかもしれない。非公開の事故記録なら、権限を持ち、合理的に行動できた最も初期の管理策を特定すべきである。

結論を変えうる証拠

結論は意図的に反証可能にしてある。より強い証拠が得られれば変わるべきである。

装置とコントローラーのログは、設定消失が原因ではなく結果だったことを示せるかもしれない。ベンダー報告は特定のハードウェアまたはソフトウェア状態を特定できるかもしれない。トポロジー記録は、光経路が公開説明よりも独立していた、または別の共有コンポーネントがそれを喪失させたことを示せるかもしれない。設定履歴は、人による変更、自動化ジョブ、状態遷移が引き金だったことを示せるかもしれない。

顧客データと計測データは影響の境界を修正しうる。完全な到達性分析は、ルーベがほぼ全面的に孤立したか、かなりの接続が残っていたかを示せるかもしれない。BGP コレクターデータはどの外部セッションと経路が変わったかを確定できるが、転送の結論を裏付けるにはデータプレーン計測が依然として必要である。

是正の証拠は説明責任の判定を強めも弱めもする。コントローラー障害や設定障害の下で独立に試験された分割完了は、OVH が教訓を封じ込めに変えたことを示すだろう。両システムが依然として 1 つの障害領域を共有していると示す後の試験は、複製が独立性をもたらしていないことを示すだろう。

本記事は、深刻なネットワーク障害が起きたと言うためにそれらの記録を必要としない。修復の主張を完成させるために必要とする。

結論

OVH のルーベ障害は、冗長性が無益だという教訓ではない。冗長性は封じ込められる障害の観点で記述されなければならないという教訓である。

同社は冗長な光接続と保存済み設定を持っていた。これらの管理策は現実のリスクに対処していた。共有の光制御障害がルーベの接続を奪うのを防げず、復旧は依然として設定の回復に依存した。

OVH の後の対策計画は、ソフトウェア欠陥の修正と、1 つの障害の範囲を小さくするための光多重化システムの分割という問題の 2 層を認識していた。それは正しい概念上の分離だった。この情報源セットの公開証拠は完了も再発耐性も証明していない。

ホスティング事業者とネットワーク事業者にとって、説明責任の基準は具体的である。保護される障害クラスを明示する。共有制御領域を対応付ける。独立した診断と既知の正常な復旧を保全する。一方がトラフィックを運ぶ間に他方の喪失を試験する。事業者の外から到達性を計測する。コンポーネントの複製と運用上の独立性を区別できる十分な証拠を公開する。

ネットワークの同一性記録とトポロジー台帳は、誰が基盤を運用し、何が存在するはずかを示せる。基盤が機能し続けるかは、稼働中のコードによる証拠、観測された到達性、試験済みの復旧だけが示す。

OVH の 2017 年光ネットワーク障害が冗長性の独立性を説明責任の試金石にした

要約