BT 999障害、フォールバックルーティングと説明責任

概況

Ofcom の最終執行記録によると、BT の緊急通報処理サービスは2023年6月25日6時24分から16時56分まで中断された。このインシデントは約14,000件の緊急通報に影響し、約1時間の完全停止を含んでいた。BT は999および112の通報者を緊急機関につなぐ国家レベルの通報処理プロバイダであったため、ひとつの事業者のプラットフォーム内の障害が全国的な公衆ネットワークの継続性問題となった。[1][2][3]
規制当局はインシデントを3つのフェーズに分けた。構成ファイルのエラーが最初にプライマリプラットフォームを混乱させた。BT の災害復旧への最初の切り替えは、指示文書が不十分でチームがプロセスに不慣れだったために失敗した。最終的にトラフィックは移動したが、バックアッププラットフォームには通常のサービスを即座に復旧するのに十分な容量と機能が不足していた。[1][2][3]
BT の初期の公開レビューでは複雑なソフトウェアキャッシュ問題と3つのプライマリクラスタが説明されていたが、Ofcom のその後の決定ではメディアサーバーの構成ファイルエラーが特定された。これらの説明を混ぜて原因をでっち上げるべきではない。規制当局の最終的な説明がこの記事の結論を支配し、BT の表現は帰属する事業者の説明として残る。[2][7]
公式の影響数値は異なるものを測定している。Ofcom は12,392人の発信者による約14,000件の不成功試行を報告した。政府のレビューは、999または112にアクセスできなかった9,641人の固有発信者を報告し、さらに多くの発信者が遅延または中断された。これらの数値は異なる計数方法と両立するが、公開情報源はそれらを1つの指標にまとめるのに十分な詳細を提供していない。[3][4][5][6]
Ofcom は、BT が可用性の低下に備えるための適切かつ均衡のとれた措置を講じなかったこと、具体的には適切に定義されテストされた手順と適切なバックアップシステムを欠いていたことを認定した。2003年通信法第105A 条(1)(c)および2022年セキュリティ措置規則第9条の違反に対して、1,750万ポンドの罰金を科した。「セキュリティ侵害」という法定用語には可用性の喪失が含まれており、Ofcom がサイバー攻撃を認定したことを意味するものではない。[1][2][3][10][11]
緊急機関による深刻な被害は確認されなかったが、Ofcom は潜在的な害を極めて重大と判断した。テキストリレーの中断により、聴覚障害や言語障害のあるユーザーはリスクが高まった。証拠は、アクセシビリティと公共安全のリスク認定を支持するものであり、特定の死亡、負傷、または医学的結果に関する根拠のない主張を支持するものではない。[1][3]
説明責任は実践的な管理に従う。BT はプラットフォーム構成、アラーム範囲、障害ドメイン設計、フェイルオーバー手順、バックアップ容量、通報処理の継続性、および修復証拠を管理していた。政府と緊急機関はシステム全体の計画、公開指示、監視、および訓練を管理していた。他の通信事業者は発信ネットワークのテストと顧客通信を管理していた。Ofcom は調査、執行、および公的なフォローアップを管理していた。

国家レベルの999経路はアプリケーション機能ではなくネットワークインフラだった

最初の説明責任の問いはアーキテクチャに関するものである：BT はどのようなサービスを運用しており、公衆の依存はどこに集中していたのか？

BT は単に顧客向けの電話アプリケーションを提供していたわけではない。BT は、999および112のトラフィックを受信し、通報者が必要とする警察、消防、救急、または沿岸警備隊に通報を転送する緊急通報処理サービスを運用していた。また、聴覚や言語に困難のある人々に緊急および非緊急通信の経路を提供するリレー機能も提供していた。この役割により、BT は国家公衆ネットワークチェーンの中に位置し、その有用な成果は呼び出し音や利用可能なプロセスではなく、訓練されたハンドラーが応答し、適切な緊急機関に正常に転送される通報だった。[1][2][3]

この区別が重要なのは、インフラの保証が完全なサービス経路に従わなければならないからである。発信元のモバイルまたは固定ネットワークが正常であっても、国家処理プラットフォームが通報を受信または転送できない場合がある。サーバーが動作していても、通報が到着するとエージェントセッションが再起動することがある。災害復旧サイトに到達可能でも、吸収すべきトラフィックに対して容量が低すぎることがある。プラットフォームのダッシュボードが部分的な復旧を示していても、発信者が待機、再試行、または失敗し続けることがある。したがって、いずれかの層での可用性は緊急アクセスの不完全な尺度である。

BT の中心的役割はまた、運用権限を集中させた。同社は、プライマリ緊急通報処理プラットフォーム、災害復旧環境、切り替え手順、エージェントの技術環境、およびインシデント中に Ofcom と政府に提供する情報を管理していた。緊急機関は自らの受信業務と現地対応を管理していた。他の通信事業者は国家サービスへの発信トラフィックの配信を管理していた。政府はより広範な監視とシステム間調整を管理していた。これらの責任は相互に関連していたが、互換性はなかった。

集中化は自動的に欠陥ではない。国家処理サービスは、転送、位置情報、アクセシビリティ、および運用実践を標準化できる。専門知識を集中させ、単一のインターフェースセットを管理しやすくすることができる。説明責任のコストは、共有ポイントがそれに対応して高い証拠基準を満たさなければならないことである。実際に発生する変化の下で独立した障害ドメインを維持する必要があり、現実の国家需要を運べるバックアップ、コンポーネントの健全性だけでなくサービスの低下を特定するアラーム、およびプレッシャーの下でオペレーターが実行できる手順が必要である。

これはまた、このインシデントがレトリックを拡張することなくネットワークインフラの説明責任対象に適合する理由でもある。コールルーティング、ノード設計、共有構成、災害復旧、トラフィック容量、およびオペレーター移行をストーリーから取り除けば、中心的な失敗は消える。残るものは、なぜ何千人もの人々が緊急サービスに到達できなかったかを説明しない。ネットワークコントロールプレーンはここでは比喩ではない。因果経路そのものである。

3つのフェーズが3つの異なる管理の失敗を明らかにする

単一の停止時間は運用の順序を不明瞭にすることがある。Ofcom の3フェーズの時系列は、最初のプラットフォームの混乱、失敗した復旧試行、および制約のあるバックアップ運用を分離している。各フェーズは異なる一連の管理を指し示している。

フェーズ1は6時24分から7時33分まで続いた。Ofcom は、サーバー上のファイルの構成エラーが緊急通報処理システムを混乱させたと結論付けた。通報を受信するとエージェントシステムが再起動した。エージェントはログアウトされる可能性があった。通報は転送中に切断またはドロップされるか、キューに戻される可能性があった。BT はサービスが失敗していることを確認できたが、当初は原因を特定できなかった。災害復旧プラットフォームへのサービスの移動を試みた。[2][3]

このフェーズは検出と診断を試した。重要なサービスには、公的な成果に結びついたアラームが必要である：通報応答率、転送成功率、予期しないエージェント再起動、繰り返されるログアウト、キューのリサイクル、テキストリレーの成功率、および宛先完了。コンポーネントアラームは依然として有用であるが、ソフトウェアが技術的に稼働したままで受信した通報ごとに破壊的な状態変化を引き起こす場合、それだけでは不十分である。BT のレビューでは、期待されたアラームは影響を受けたプライマリクラスタを明確にしなかったと述べている。Ofcom は後に、警告システムの不備、および重大度、影響、推定原因、および可能な緩和策を評価するための手順の不備を指摘した。[3][7]

フェーズ2は7時33分から8時50分まで続いた。災害復旧への最初の移動試行は、人為的ミスにより失敗した。Ofcom はそのミスを、不十分な文書化とプロセスに不慣れなチームに関連付けた。サービスは部分的な混乱から完全な停止に移行した。この期間中、999または112に電話しようとする人は BT の通報処理エージェントに接続できなかった。[2][3]

このフェーズは実行を試した。災害復旧設計は、機器が存在するか、または Runbook が保存されているだけでは完了しない。当直の担当者は、いつそれを呼び出すかを認識し、プライマリプラットフォームがどの状態にあるかを理解し、曖昧さのないシーケンスに従い、誤った選択を検出し、安全に逆転または修正し、トラフィックが移動したことを確認できなければならない。プロセスは、需要が高まり、公的な結果が深刻で、技術情報が不完全な状態で機能しなければならない。

フェーズ3は8時50分から16時56分まで続いた。トラフィックは災害復旧に正常に移動し、不成功の通報率は低下したが、通常のサービスは即座に復旧しなかった。バックアッププラットフォームは需要に苦戦した。Ofcom は、その容量と機能が合理的に予想されるトラフィックのレベルに対して不十分だったと判断した。[2][3]

このフェーズは容量と縮退モード設計を試した。バックアップは、通常の機能が低下しても重要なサービスを維持する場合に許容される可能性がある。しかし、その低下は意図的で、境界があり、サービスの公的機能と一致していなければならない。緊急通報は予測可能な再試行行動を生成する：通報が失敗するか応答がない場合、発信者はしばしば再試行する。バックアップ設計は、定常状態の平均トラフィックだけでなく、そのフィードバックを考慮しなければならない。また、アクセシビリティ経路と通報を転送する能力を維持しなければならず、単に受け入れるだけでは不十分である。

3つのフェーズは、誤解を招く根本原因の物語を防ぐ。構成エラーは開始を説明する。検出と診断が弱かった理由、最初の復旧ステップが失敗した理由、または転送成功後にバックアップが需要を処理できなかった理由を説明しない。これらの後の影響は、BT の権限内の管理によって長期化された。Ofcom は、インシデントの規模と影響を、運用およびインシデント手順の欠如、ならびに災害復旧の容量と機能の低下に結びつけたときに、これを明示的に述べている。[1][2]

このシーケンスはまた、是正措置の実践的なテストを提供する。信頼できる訓練は、3つの課題すべてを再現しなければならない：曖昧なプライマリプラットフォーム障害、不確実性の下での転送決定、およびバックアップへの高い需要。クリーンな計画切り替えのみをテストすることは、このインシデントを困難にした条件を見逃すことになる。

最終的な根本原因の記録は BT の初期の説明から分離されなければならない

公開インシデントの物語は進化する。初期の事業者声明は不完全な証拠に基づくことが多く、後の規制当局の所見は完全には公開されていない文書やインタビューを使用する可能性がある。責任ある分析は、最も技術的に見えるフレーズを選択するのではなく、その進化を示すべきである。

BT の公開レビューは、プライマリ緊急通報処理プラットフォームにおける「複雑なソフトウェアキャッシュ問題」を説明していた。同レビューは、サービスが3つのプライマリクラスタを使用し、高いレベルの回復力を持ち、どのクラスタも国家全体の負荷を処理できると述べていた。また、どのクラスタが影響を受けたかをアラームが明確にしなかったとも述べていた。復旧中、対応者はそれ自体が故障しているプライマリクラスタを選択し、最初の移動の失敗に寄与した。BT は、固定電話トラフィックが8時37分までに、モバイルトラフィックが8時50分までに災害復旧に移動したと報告した。[7]

Ofcom のその後の非機密決定は、メインプラットフォーム内のメディアサーバーの構成ファイルのエラーを特定し、緊急通報に関連するメッセージサービスを制御していた。決定は、それぞれがすべてのトラフィックを処理することを意図した3つの同一ノードを持つメインプラットフォームと、別の災害復旧プラットフォームを説明していた。また、規制当局の法的所見と罰金を支持する証拠も含まれていた。[2]

2つの説明は適切なレベルで共存できる。キャッシュ動作は BT の技術的理解の一部であった可能性がある一方、構成ファイルエラーが最終的な公開規制上の所見である。一般に利用可能な情報源は、ファイル、キャッシュ、メッセージサービス、およびノード動作がどのように相互作用したかを示す低レベルの詳細を十分に提供していない。「エンジニアがすべてのノードにわたってキャッシュパラメータを変更した」などの連鎖を製造することは、決定が各要素を実際に立証しない限り、不健全である。最終決定を無視して BT の好む表現のみを繰り返すことも同様に不健全である。

したがって、この記事は主張の階層を使用すべきである。

第一に、Ofcom はメディアサーバーの構成ファイルエラーを確認し、それをプライマリ緊急通報処理の混乱に結び付けた。これは最終的な執行記録によって支持される根本原因の声明である。

第二に、BT は以前にこの問題を複雑なソフトウェアキャッシュ問題として説明し、アーキテクチャと復旧の詳細を提供していた。これらは帰属する事業者声明であり、文脈を追加するが、規制当局を覆すものではない。

第三に、公開記録は重要な未回答の質問を残している。供給者、個々のオペレーター、完全な変更チケット、正確な構成キー、完全なアラームストリーム、またはすべてのノード遷移を特定していない。これらの項目は証拠として要求されるべきであり、推論によって埋められるべきではない。

この階層は慎重な表現以上のものである。それは証拠の所有者に責任を割り当てる。BT は構成履歴、テスト結果、および内部レビューを開示できる。Ofcom は法的範囲内でその所見の根拠を説明できる。政府はシステム全体の勧告に対する進捗を公表できる。外部のアナリストはこれらの記録を比較し、ギャップを特定できる。誰も不確実性を名前のない人物やベンダーに対する告発に変えるべきではない。

同じ規律がサイバー攻撃の枠組みを拒否する。法定制度は「セキュリティ侵害」を広く使用し、可用性、パフォーマンス、または機能を損なうものを含む。Ofcom の所見は可用性障害への準備に関するものだった。公開情報源は技術的な障害を説明している。敵対的なアクセス、悪意のある構成、または外部の主体を報告していない。このイベントをサイバー攻撃と呼ぶことは、法的用語と支持されていない原因を混同することになる。

3つのプライマリノードは3つの独立した障害ドメインを確立しなかった

BT のアーキテクチャには3つのプライマリノードが含まれ、それぞれがすべての緊急通報トラフィックを処理することを意図していた。紙面上では、これは予備容量と複数の運用インスタンスを提供する。インシデントは、コンポーネント数が回復力の十分な証拠ではない理由を示している。

ノードは同一であると説明されていた。同一のシステムは運用、パッチ適用、およびスケーリングが容易である可能性があるが、感受性を共有する可能性もある。構成ファイルエラーは、共通のデプロイメントプロセスを通じて伝播するか、どこでも同じように動作するソフトウェアに影響を与える可能性がある。共有メッセージサービスは共通の制御面を作成できる。共通の管理プレーンは、名目上は別個のノードに同じ誤った状態を適用できる。公開記録はこれらの伝播経路のどれが正確に発生したかを確立していないため、記事は1つを選択すべきではない。それはより重要な結果を確立している：プライマリ構成は全国的なサービス中断を防げなかった。

独立性はもっともらしい原因に対して定義されなければならない。地理的分離はサイト喪失に対処するが、共有構成には対処しない。別個のハードウェアは一部のコンポーネント障害に対処するが、同一のソフトウェア動作には対処しない。予備コンピューティング容量は需要に対処するが、制御プレーンのエラーには対処しない。複数のインスタンスはランダム障害に対処するが、どこにでも適用されるアップデートには対処しない可能性がある。健全な設計は、各層がどの障害クラスを封じ込められるか、および共通の依存関係がどこに残るかを文書化する。

緊急通報の場合、この分析には少なくとも6つの側面が含まれるべきである。

構成独立性：悪意のあるファイル、ポリシー、またはロールアウトがすべてのプライマリノードに同時に影響を与える可能性があるか？変更はカナリアで検証され、リバーシブルか？既知の良い構成が通常のデプロイメントパスの外に残っているか？

状態独立性：悪いランタイム状態が拡散または同期する可能性があるか？メッセージストア、キャッシュ、データベース、キューは、1つの条件がすべてのノードを損なわないように十分に分離されているか？

監視独立性：影響を受けたプラットフォームの独自のテレメトリが誤解を招くか不完全な場合でも、オペレーターはサービスの成果を見ることができるか？複数のネットワークから合成999および112テストが実行されているか？

運用独立性：対応者は、失敗している同じコンソールや手順に依存することなく、ノードを分離、ドレイン、またはバイパスできるか？

復旧独立性：災害復旧は、プライマリ原因から生き残るために十分に別個の構成、ソフトウェア状態、および運用アクセスを使用しているか？

容量独立性：残りの経路は、通常の平均ボリュームだけでなく、再試行と急増需要を吸収できるか？

プラットフォームはこれらの一部を満たし、他を満たさない可能性がある。正しい説明責任の質問は「BT に冗長性はあったか？」ではない。公開記録はそれがあったことをすでに示している。質問は「その冗長性はインシデント前にどの障害クラスを含むと証明されていたか、そしてどのテストが今、発生した構成および移行障害を含むと証明しているか？」である。

すべてのシステムについての情報源によって確立された事実ではなく分析的な類推として、この区別はネットワークインフラ全体に重要である可能性がある。DNS プラットフォーム、BGP ルート制御システム、モバイルコア、認証サービス、および緊急通報チェーンは、共通の制御プレーンの背後で複数のインスタンスを使用できる。その場合、目に見えるデータプレーン数は高くなる可能性があるが、独立した管理ドメインの数は1つである。したがって、監査はトポロジだけでなく、デプロイメント権限と共有状態に従うべきである。

災害復旧は容量と運用可能性の主張だった

別の災害復旧プラットフォームの存在は必要な管理だった。インシデントは、存在だけでは十分でないことを示した。

最初の転送は失敗した。Ofcom は即時のミスを人為的ミスに帰し、不十分な文書化とプロセスへの不慣れを特定した。この所見は、個人の非難で止まる許可として読まれるべきではない。重要な復旧手順は、人とインフラストラクチャの間の設計されたインターフェースである。その明確さ、検証、リハーサル、権限、観測可能性、およびエラー復旧は組織的管理である。訓練を受けた対応者がプレッシャーの下で予測可能な誤った選択を行うことができる場合、手順とツールは精査に値する。

運用テストは、対応者が何を見たかを尋ねるべきである。各プライマリノードの健全性は明確に表示されていたか？インターフェースは、利用可能なノードとトラフィックを受信しても安全なノードを区別していたか？Runbook は前提条件とロールバックポイントを特定していたか？ツールは無効な宛先を防いだか？別のオペレーターが選択を検証できたか？チームは計画されたメンテナンスだけでなく、正確な計画外の転送をリハーサルしたか？公開決定はこれらの質問に答えていないため、それらは結論ではなく証拠要求として残る。

転送が成功すると、容量が次の問題になった。災害復旧プラットフォームは失敗した通報を減らしたが、需要に苦戦した。Ofcom は、合理的に予想されるレベルに対して不十分な容量と機能を認定した。国家緊急サービスに使用されるバックアップは、障害自体が再試行、重複試行、より長い処理時間、および公的な不確実性を引き起こす場合、静かな日の平均のみにサイジングすることはできない。需要モデルはインシデントの行動を含まなければならない。

容量にはまたいくつかの意味がある。コンピューティングとネットワークスループットは明白である。エージェント同時実行数、キュー深度、転送インターフェース、リレーサービス、ログ記録、位置情報サポート、および下流の緊急機関接続のそれぞれが制限リソースになる可能性がある。通報を受け入れても迅速に転送できないバックアップは、公的な成果を維持していない。音声をサポートしてもテキストリレーを失うバックアップは、アクセシビリティ障害を生み出している。独自の診断ログによって過負荷になるバックアップは、名目上のリソースがあっても使用可能な容量が不十分である可能性がある。

設計目標は必ずしもプライマリの完全な複製ではない。縮退モードは、それが必須サービスを維持し、緊急トラフィックを公平に優先し、制限を伝達し、安全に通常に戻る場合、防御可能である。しかし、縮退モードの決定はインシデントの前に明示的でなければならない。オペレーターは、どの機能が低下する可能性があるか、どれが決して失われてはならないか、およびアクセシビリティサービスに依存するユーザーを排除せずに需要をどのように制御するかを知っているべきである。

したがって、テストは生産主張である。低ボリュームでの成功した計画切り替えは、必要な保証のサブセットのみを示す。強力な証拠には、事前通知なしまたは最小限の通知での訓練、プライマリ状態が曖昧な場合の転送、国家負荷全体と再試行増幅、1つ以上のアクセシビリティコンポーネントの喪失、最初の復旧アクションの失敗、およびプライマリへの復旧が含まれる。訓練は、インフラストラクチャのステータスだけでなく、発信者の成果を測定するべきである。

Ofcom の所見は説明責任の線を明確にする。BT は、適切なバックアップシステムが存在するかどうか、およびそれが悪影響を制限し復旧を可能にするかどうかを管理していた。政府と緊急機関は結果に関心を持っていたが、BT のプラットフォームを構成または運用していなかった。共有監視はテストを強化するべきであり、事業者が管理する資産と手順に対する事業者の責任を希釈するべきではない。

「人為的ミス」は管理分析を開始すべきであり、終了させるべきではない

「人為的ミス」というフレーズが最終的な時系列に現れるのは、人が失敗した復旧選択を行ったためである。それは関連性があるが、システムが完全な停止に入った理由の完全な説明ではない。

人々は、組織によって設計された情報と制約を通じてネットワークインフラを運用する。Runbook は何をすべきかを伝える。コンソールは何が健全かを伝える。アクセス制御は何を変更できるかを決定する。トレーニングは習熟度を構築するか、または構築に失敗する。訓練は曖昧さを露呈するか、または露呈しない。エスカレーションルールは、いつ別の人物が決定をレビューするかを決定する。ツールは危険な選択を許可するか、またはブロックする。文書は最新または古くなっている可能性がある。

Ofcom は、失敗した転送を不十分な文書化と不慣れに結び付けた。これらの所見は、責任を孤立した行為から反復可能な組織的管理に移す。プロセスが、1つの誤った選択が国家サービスを部分的な混乱から完全な停止に移すほど重要である場合、そのプロセスはその結果を中心に検証と復旧を伴って設計されるべきである。

いくつかの実践的な管理が続く。

宛先は、単なるノード名ではなく、サービスの準備状態によって識別されるべきである。インターフェースは、候補プラットフォームが負荷の下で健全性チェックに合格したかどうかを示すべきである。Runbook には、決定基準、前提条件、不可逆的なステップ、および確認ポイントを含めるべきである。時間が許す場合、第二の資格のあるオペレーターがルートを検証するか、またはシステムが自動ガードを実施するべきである。トレーニングには、曖昧なテレメトリと部分的なプライマリ障害を含めるべきである。訓練は、チームが最初の誤った行動を検出して修正することを要求するべきである。

これらのいずれも人間の責任を排除するものではない。それは責任を使用可能にする。オペレーターは、承認された手順に従い、不確実性をエスカレーションする責任を引き続き負う。経営陣は、手順の質、人員配置、およびトレーニングに対して責任を負う。プラットフォーム所有者は、観測可能性と安全制約に対して責任を負う。エグゼクティブは、現実的な容量と訓練への資金提供に対して責任を負う。規制当局は、管理システムが信頼できるかどうかをテストする責任を負う。

代替案は弱い説明責任のサイクルである。インシデントが発生する。報告書は人為的ミスを特定する。個人はより多くのトレーニングを受ける。基礎となるインターフェース、文書、および組織の前提は変更されない。次の人は同じ罠に直面する。より強いクローズアウトは、エラーが犯しにくくなり、検出しやすくなり、復旧が安全になったかどうかを尋ねる。

このアプローチは、対応条件が本質的にストレスフルであるため、公衆ネットワークで特に重要である。需要が高まる。情報は不完全である。一般の人々にメンテナンスウィンドウを待つように伝えることはできない。手順は、イベント後の冷静なレビュー会議だけでなく、それらの条件下で判断されるべきである。

影響の数値は異なる分母を説明している

公衆の信頼は正確な影響報告に依存する。BT のインシデントは、互換性があると見なされるべきではないいくつかの公式数値を生み出した。

Ofcom の2024年の罰金通知は、6時24分から16時56分の間に、12,392人の異なる発信者による約14,000件の緊急通報試行が不成功だったと述べている。個々の発信者は複数の試行を行うことができるため、試行と発信者は当然異なる。通知はまた、このイベントが約14,000件の緊急通報に影響し、約1時間の完全停止を含んでいたと述べている。[1][3]

政府の事後調査レビューは、999または112を介して緊急サービスにアクセスできなかった9,641人の固有発信者を報告し、さらに多くの発信者が遅延または中断されたと述べている。イベントを混乱、拒否、遅延に分割している。この尺度は「アクセス不能」の異なる定義を適用するか、異なる方法で同一人物を識別するか、または異なる記録をカバーする可能性がある。公開レビューはそれ自身の条件で報告されるべきである。[4][5][6]

その後の政府の Ofcom セキュリティ報告の要約は、緊急通報試行の約23%が不成功だったと述べ、51分間の完全な失敗期間を特定している。このパーセンテージは規模を追加するが、依然として分母と時間境界を必要とする。基礎となるデータが計算をサポートしない限り、新しい発信者数を計算するために使用されるべきではない。[8]

これらの区別は衒学的ではない。それらは異なる公的被害に対応している。

不成功試行は、失敗しているサービスに置かれた負荷と再試行によって生み出される作業を測定する。固有発信者尺度は、失敗に遭遇した人またはデバイスの数を近似する。遅延した通報は最終的に接続される可能性があるが、依然として深刻なリスクを生み出す。ドロップされた転送は、エージェントが応答した後に失敗する可能性があり、これは通報がキューに到達しない場合とは運用上異なる。テキストリレーの中断は、緊急通信と通常通信の両方でユーザーに影響を与える可能性がある。

良いインシデントデータセットは、これらのカテゴリすべてを間隔ごとに保存する。試行、固有発信者、応答時間、転送成功率、放棄、再試行チェーン、発信ネットワーク、アクセシビリティ経路、および緊急機関を示す。また、個人データを保護する。すでに Ofcom の緊急通報処理期待の一部である15分間隔の集計報告は、サービスが不均一に戻った時期とバックアップが成果を改善したかどうかを示すことができる。

現在の公開記録は、深刻な全国的混乱を確立するのに十分である。特定の失敗した応答や健康成果を特定の通報に帰するには十分ではない。その境界は明確に保たれるべきである。分析が数値が何を測定し、どこで停止するかを述べるとき、公的説明責任は強められ、弱められない。

アクセシビリティ経路はコアサービスの一部である

緊急通報の回復力は、標準的な音声通話のみを通じて評価されるべきではない。BT の役割にはリレーサービスが含まれており、Ofcom は調査を拡大して、テキストリレー、緊急ビデオリレー、および緊急機関へのモバイル SMS アクセスへの影響を理解した。罰金通知は、テキストリレーの中断により、聴覚障害や言語障害のある人々が友人、家族、企業、サービスへの通話を含む通話を行うことができなくなり、危害のリスクが高まったと述べている。[1][3]

この影響には2つの説明責任の含意がある。

第一に、アクセシビリティは、縮退モードでカジュアルに削除できるオプション機能ではない。一部のユーザーにとって、リレーは緊急支援への使用可能な経路である。通常の音声を復元しながらリレーを利用不可のままにするバックアップ設計は、同等の公的アクセスを提供しない。したがって、容量計画、訓練、および監視には、サポートされる各モードを含めるべきである。

第二に、集約された音声指標は不平等な結果を隠す可能性がある。95%の応答目標は、より小さなアクセシビリティチャネルでの完全な失敗を依然として隠すことができる。サービスレベルダッシュボードは、モダリティを分離し、ある人口に実行可能な経路がない場合を表面化するべきである。公開インシデントコミュニケーションは、それらのユーザーが実際に使用できる代替手段を提供するべきである。

情報源セットは、特定の障害者が確認された深刻な結果を被ったことを確立していない。それは、アクセシビリティ経路が中断され、Ofcom がリスクを重要と見なしたことを確立している。正しい対応は、個々の因果関係を誇張することでも、構造的排除を最小化することでもない。将来のフェイルオーバーテストにリレーサービスが含まれ、バックアップ容量がそれらをカバーし、公開指示がアクセス可能であるという証拠を要求することである。

法的所見は可用性準備に関するものであり、敵対的侵入に関するものではない

Ofcom の決定は、2022年以降の通信セキュリティフレームワークを技術的な可用性障害に適用した。この適用は、ネットワークセキュリティ義務がサイバー攻撃対応よりも広いことを示すため重要である。

通信法第105A 条は、公衆電子通信ネットワークおよびサービスのプロバイダが、セキュリティ侵害のリスクを特定し低減し、その発生に備えるための適切かつ均衡のとれた措置を講じることを要求している。法定定義には、可用性、パフォーマンス、または機能を損なうものが含まれる。電子通信（セキュリティ措置）規則の規則9は、適切な手順とバックアップを含む、そのような侵害への準備に対処している。[1][2][10][11]

Ofcom は、BT が2つの領域で十分な措置を講じていなかったと認定した。セキュリティ侵害を特定、評価、および対処するための明確に定義されテストされた手段と手順が欠けていた。また、悪影響を適切に制限し復旧を可能にする適切なバックアップシステムが欠けていた。これらの所見は、インシデントの最初の失敗した移行、不十分な警告と評価、および制約された災害復旧運用に直接対応する。[1][2]

規制当局は1,750万ポンドの罰金を科した。金額には、BT が責任を認め Ofcom の和解プロセスを完了したことによる30%の和解割引が含まれていた。Ofcom はこの問題を非常に深刻と見なし、インシデントの規模と影響は BT の管理内の要因によって長期化されたと述べた。また、是正措置と協力を考慮した。[1][2][3]

Ofcom は、第105C 条、一般条件 A3.2、および C5.8 から C5.12 を含む他の条項も検討していた。A3.2 は、公衆音声およびインターネットサービスの可能な限り完全な可用性と緊急機関への中断のないアクセスに関する。C5 条項はリレーサービスに関する。最終的なケースページは、Ofcom がこれらの条項に関する所見を行政上の優先事項として追求せず、第105A 条と規則9に焦点を当てたと述べている。したがって、記事は調査範囲をすべての条項の違反の認定に変換すべきではない。[1][9]

法的枠組みは有用な管理基準を生み出す。プロバイダは、障害が理解された後にのみ有能に反応することによって回復力義務を満たすことはできない。準備には、イベント前に必要な手順、バックアップ能力、およびテストが含まれる。義務はまた比例性に関する：国家緊急通報サービスは、その潜在的な結果および事業者のリソースに合わせた管理を必要とする。

Ofcom の緊急通報処理基準は関連する運用コンテキストを提供する。これらは、サービスの重要な性質に見合った手順、99.999%の月間可用性、迅速な応答のための十分なネットワーク、システム、および人的リソース、事業継続評価、15分データ、および停止報告を期待している。これらの基準は2023年のインシデントに先行し、期待される実践を説明している一方、その後の回復力ガイダンスは、設計、テスト、監視、対応、および復旧に関するプロバイダの期待を拡大している。[12][13][14][17]

後の文書は慎重に使用されるべきである。それらは良い回復力の証拠が現在どのように見えるかを特定できる。2023年に違反された拘束力のあるルールであったという証明として引用されるべきではない。実際の法的所見については、最終的な Ofcom 決定が権威である。

政府の監視はチェーンをテストしなければならず、事業者の管理を置き換えてはならない

政府の事後調査レビューは、このイベントをシステム全体の回復力の教訓として扱った。それは、継続的なリスク管理、より強力な政府監視、より良い公衆通信、およびさまざまなシナリオにわたる訓練を求めた。また、このイベントを86年の歴史で初めての公衆緊急通報サービスの全国的な喪失と説明した。[4][5][6]

これらの勧告は実際のガバナンスギャップに対処している。緊急通報は組織の境界を越える。BT は通報を処理する。通信事業者はそれらを発信する。緊急機関はそれらを受信する。政府部門は政策と国家レジリエンスを監督する。地域の対応者は代替手段を伝達する。1つの組織のみをテストする訓練は、チェーンが機能することを証明できない。

システム全体の監視は、共通のサービスマップ、障害シナリオ、および証拠形式を確立するべきである。マップは、各移行と依存関係をどのアクターが所有するかを特定する。シナリオには、完全なプライマリ喪失、曖昧な部分的な劣化、失敗した最初の復旧、バックアップ容量の低下、アクセシビリティ経路の障害、および矛盾する公開情報を含めるべきである。証拠は、発信ネットワークと緊急機関にわたる発信者の成果を記録するべきである。

監視はまたエスカレーションを定義するべきである。全国的な停止中、政府は事業者のエンジニアリング役割を引き継ぐことなく、タイムリーで技術的に正確な情報を必要とする。BT はそのプラットフォームと復旧に対して責任を負い続ける。政府は国家的な結果を調整し、緊急機関を支援し、一般の人々に使用可能なアドバイスを提供する責任を負い続ける。Ofcom は規制評価の責任を負い続ける。明確な境界は、各アクターが何を決定し開示しなければならないかを知っているため、協力をより迅速にする。

公衆通信は技術的な扱いに値する。代替番号は、それをサポートするネットワーク経路が十分に独立しており、受信機関が需要を吸収でき、番号がメッセージ全体で一貫しており、ユーザーがアクセスできる場合にのみ有用である。テストせずに別のチャネルを使用するようアドバイスすることは、混雑を移動させるだけでサービスを復旧させない可能性がある。したがって、訓練には、アクセシビリティと地域のバリエーションを含む、インフラの一部としてのコミュニケーションを含めるべきである。

政府は、重要な勧告が達成され、残りの作業を監督すると述べた。これは進捗声明であり、完全な証拠パックではない。耐久性のある公的保証は、各勧告を所有者、期日、完了成果物、訓練結果、および残留リスクに結び付ける。セキュリティ上の理由で詳細を公開できない場合、独立した評価者が検証し、限定された結論を公表できる。

是正措置は変化した障害行動によって測定されるべきである

Ofcom と BT はいくつかの是正措置を説明している。BT は開始エラーを修正し、障害監視を改善し、災害復旧プラットフォームを改善し、より明確な切り替えプロセスを文書化した。政府はより広範な勧告の進捗を報告した。これらの変更は障害シーケンスに対応し、罰金とクローズアウトに関連する。[3][4][7]

残る質問は有効性である。管理は、文書が追加されたと言うだけで証明されない。システムが含むことを意図した条件下で異なる動作をするときに証明される。

構成ガバナンスの場合、証拠はスキーマ検証、ピアレビュー、段階的ロールアウト、カナリア動作、自動ロールバック、および既知の良い状態の保護を示す。テストは、不正形式または安全でない構成を導入し、それがすべてのプライマリノードを損なうことができないことを実証する。

監視の場合、証拠は合成通話、エージェントセッションの安定性、キューと転送の結果、リレーサービスのチェック、および影響を受けたプラットフォームから独立したアラームを示す。テストは部分的な障害を作成し、オペレーターが影響を受けたサービス経路を迅速に特定できることを実証する。

災害復旧の場合、証拠は現在の Runbook、役割割り当て、定期的なオペレーター練習、安全な宛先の保護された選択、および曖昧なプライマリ状態の下での成功した転送を示す。テストは、意図的に失敗した最初のアクションを含み、長期化した完全停止なしでの復旧を実証する。

容量の場合、証拠は需要仮定、再試行増幅、キュー制限、エージェント同時実行数、転送スループット、およびアクセシビリティ経路負荷を示す。テストは、設計で使用される合理的に予想される国家需要以上で実行する。

公衆通信の場合、証拠は事前に合意されたメッセージ、アクセス可能な代替手段、更新を発行する権限、政府と対応者間の一貫性、および復旧後の一時的な指示の撤回を示す。

独立した保証の場合、証拠は誰がテストを目撃したか、何が失敗したか、何が再テストされたか、どのリスクが残っているかを示す。評価者は、管理が定義されたシナリオに合格したかどうかを述べるために、悪用可能な詳細を公表する必要はない。

最も強力な是正プログラムは、これらの成果物を結び付ける。構成テストは監視をトリガーする。監視は宣言されたインシデントを促進する。チームはフェイルオーバーを実行する。バックアップは負荷を運ぶ。緊急機関は成功した転送を確認する。公衆通信は必要な場合にのみ作動する。システムは証拠を失うことなくプライマリサービスに戻る。そのチェーンこそが一般の人々が実際に依存しているものである。

説明責任マトリックス

説明責任は、各保護策と証拠記録に対する実践的な管理を持つアクターに割り当てられるべきである。

段階	主要管理所有者	必要な管理	存在すべき証拠	公開不確実性
予防	BT プラットフォーム所有者	構成を検証し、デプロイメント障害ドメインを分離し、既知の良い状態を維持する	変更記録、スキーマチェック、カナリア結果、ロールバックテスト	完全な構成と承認記録は公開されていない
予防	BT アーキテクチャ所有者	プライマリノードが許容できない共通モードを共有しないことを確保する	依存関係マップ、構成ドメイン設計、注入障害テスト	非編集済みのトポロジと共有状態の詳細は公開されていない
検出	BT 運用	失敗した通報、エージェント再起動、転送ドロップ、キューリサイクル、リレー障害を検出する	合成通話、サービス成果ダッシュボード、アラーム履歴	完全なアラームストリームとしきい値設計は公開されていない
評価	BT インシデントコマンド	重大度、範囲、および推定原因を迅速に特定する	インシデントタイムライン、決定ログ、エスカレーション記録	公開情報源はすべての決定やタイムスタンプを示していない
封じ込め	BT ネットワーク運用	安全でないプライマリ容量を分離し、再試行増幅を防ぐ	トラフィック制御、安全なドレイン手順、制限されたログ記録証拠	正確な封じ込めアクションは完全には公開されていない
復旧	BT 復旧チーム	検証された安全な災害復旧先に転送する	現在の Runbook、トレーニング記録、保護されたスイッチログ、ロールバックポイント	正確な最初の転送ミスとインターフェースは部分的に編集されている
容量	BT サービス所有者	災害復旧で合理的に予想される需要を処理する	負荷モデル、ストレステスト、エージェントおよび転送スループット結果	公開文書は現在のテスト済み上限を公表していない
アクセシビリティ	BT および緊急サービスパートナー	テキスト、ビデオ、およびその他のサポートされるアクセス経路を維持する	モダリティ固有の監視およびフェイルオーバーテスト	完全な是正後アクセシビリティ結果は公開されていない
発信配信	他の通信事業者	完全な国家チェーンを通じた999/112配信をテストする	ネットワークおよびアクセスタイプ間のテストコール記録	カバレッジと頻度は完全に公開されていない
緊急対応	緊急機関	劣化運用中に通報を受信、転送、および行動する	継続計画、訓練結果、代替連絡容量	地域の準備状況は異なる可能性があり、ここでは完全に文書化されていない
公衆通信	政府および緊急機関	正確で一貫性のあるアクセス可能な指示を発行する	承認されたメッセージ、決定権限、チャネルテスト	公開証拠はすべての訓練や地域経路を示していない
規制上の説明責任	Ofcom	調査、執行、ガイド、監視	確認決定、罰金記録、フォローアッププログラム	一部の技術的証拠は機密である
検証	BT、政府、独立評価者	現実的なシナリオの下で是正管理を証明する	日付入りテスト成果物、立会い結果、残留リスク声明	公開是正要約はすべての結果を確立していない

マトリックスは2つの一般的なエラーを防ぐ。

1つ目は過度に集中した非難である。BT はプラットフォームとインシデント対応の多くを管理していたが、すべての地域の緊急計画や公開メッセージを管理していたわけではない。政府と緊急機関には独自の継続責任があった。

2つ目は希釈された責任である。このイベントを「システム全体の障害」と呼ぶことは、構成、監視、フェイルオーバー、およびバックアップ容量に対する BT の管理を不明瞭にしてはならない。共有された公的結果は、すべての技術的决定が共有されたことを意味しない。

マトリックスはまた救済策を明確にする。罰金は違反を認め、将来の失敗を抑止できる。それ自体はプラットフォームが変わったことを証明しない。政府レビューは勧告を調整できる。それ自体は BT の負荷上限をテストしない。BT の是正声明は完了した作業を特定できる。それ自体は独立した保証を提供しない。各成果物には適切な役割がある。

残りの証拠ギャップを埋めるものは何か

公開記録は、Ofcom の所見と主要な説明責任テーゼを支持するのに十分強力である。主張された修復のすべてを評価するには十分に完全ではない。いくつかの限定された開示が信頼を実質的に改善する。

構成系統：関連ファイルの目的、検証ルール、承認経路、デプロイメント範囲、およびロールバック保護。機密値を削除しても、制御シーケンスは維持できる。

障害ドメイン声明：3つのプライマリノードと災害復旧の間で共有されている構成、ソフトウェア、データ、管理、およびアクセス依存関係、および意図的に独立しているもの。

監視カバレッジマップ：音声、テキストリレー、ビデオリレー、モバイル SMS、および各緊急機関への転送に使用される合成通話およびサービス成果測定。

フェイルオーバー訓練記録：日付、シナリオ、初期条件、役割、決定ポイント、転送時間、エラー、発信者成果、バックアップ負荷、およびプライマリへの復旧結果。

容量基礎：災害復旧に使用される需要モデル（再試行増幅とモダリティ固有の要件を含む）、およびテスト済み上限と安全マージン。

Runbook 使用可能性結果：当直の可能性があるスタッフが現在の文書から手順を実行できるという証拠（主題専門家が説明できるだけでなく）。

是正措置検証表：各措置、所有者、完了日、テスト、独立レビューア、結果、残留リスク。

公的影響方法論：不成功試行、固有発信者、拒否された通報、遅延通報、ドロップされた転送、モダリティ中断の定義。これにより、異なる公式カウントを推測なしで理解できる。

すべての生データが公開されるべきではない。緊急ネットワークの詳細はセキュリティとプライバシーのリスクを生み出す可能性がある。しかし、機密性は保証の形式を変えるべきであり、それを排除するべきではない。Ofcom または独立評価者は、テストが定義されたシナリオをカバーし、測定可能なしきい値に合格したことを、構成や個人の通話記録を公開せずに確認できる。

他の公衆ネットワーク事業者への教訓

BT のインシデントは特定的であるが、管理の質問は他の共有ネットワークサービスにも適用される。

第一に、サーバーだけでなく制御プレーンを数える。1つの構成経路の背後にある3つのノードは、別個に統治された状態を持つ2つのシステムよりも独立性が低い可能性がある。DNS、BGP、モバイルコア、認証、およびコールルーティングの事業者は、共通モードを明示的にマッピングするべきである。

第二に、成功したフェイルオーバーだけでなく、失敗した復旧をテストする。インシデント中の最初のアクションは、情報が不完全なために間違っている可能性がある。回復力のあるプロセスは、エラーを検出し、その影響を制限し、明確な修正経路を提供する。

第三に、障害需要に合わせてバックアップをサイジングする。再試行、重複試行、より長い処理、および公的な不確実性が負荷を増加させる。バックアップは、通常の平均ではなく、インシデント形状の曲線に対してテストされなければならない。

第四に、プラットフォームの外部からサービス成果を監視する。内部の健全性シグナルは、顧客がトランザクションを完了できない間も緑色のままである可能性がある。合成通話とエンドツーエンドの転送チェックは、複数の発信ネットワークとアクセシビリティモードをカバーするべきである。

第五に、文書を実行可能にする。Runbook は、現在のインターフェースと権限で、それを使用する可能性が高い人々によってテストされるべきである。時間的プレッシャーの下で従うことができなければ、それは管理ではない。

第六に、縮退モードでアクセシビリティを維持する。大多数のチャネルのみを復元する回復力計画は、リレーまたは別のモダリティが主要経路であるユーザーを排除する可能性がある。

第七に、法的可用性セキュリティと敵対的侵入を区別する。ネットワークセキュリティプログラムには、構成、容量、運用継続性を含めるべきであり、敵対者防御だけではない。

第八に、適切なレベルで証拠を公開する。事業者は、テスト範囲、独立検証、および残留リスクを開示しながら、機密詳細を保護できる。曖昧な保証は、誤った信頼または憶測のいずれかを招く。

最後に、公的成果によって復旧を定義する。プラットフォームはプロセスが再起動したから復旧したのではない。緊急アクセスは、関連するネットワークとモダリティからの通報が応答され確実に転送され、バックアップが需要を維持でき、公開指示が正確で、証拠が保存されたときに復旧する。

結論

2023年6月25日の停止は、回復力の主張のすべての層が観察可能になったため、フォールバックコールルーティングを説明責任テストに変えた。

Ofcom の執行決定は法的所見を確立し、 substantial penalty を科した。BT と政府は是正作業を報告した。残る公的質問は、誰かが対応したかどうかではない。修復されたシステムが、発生した正確な組み合わせ（曖昧なプライマリ障害、共有感受性、最初の復旧ミス、再試行駆動型需要、アクセシビリティ要件、国家通話量）に対してテストされたかどうかである。

説明責任は、その質問に答えることができる管理に従う。BT はプラットフォーム回復力の技術的および運用証拠を所有する。政府と緊急機関はシステム全体の継続性と公衆通信を所有する。他のプロバイダはエンドツーエンドの発信ネットワークテストを所有する。Ofcom は規制検証と執行を所有する。

国家緊急通報サービスは、3つのノードとバックアップサイトの存在から回復力を推測するよう公衆に求めるべきではない。独立した障害ドメイン、実行可能な復旧、適切な容量、および検証された発信者成果を実証できるべきである。それが、図としての冗長性と公衆ネットワークの事実としての回復力の違いである。