要約

  • BSH が掲げる「一つの契約、一つの責任窓口」は、拠点網で発生する障害の調整費用を下げる可能性がある。しかし、商流の一本化だけでは、回線、経路、設備、電源が同時に止まらないことは証明できない。
  • AS8491 の公開記録からは、実在するネットワーク資源と複数の外部経路関係が確認できる。一方、通信事業者との契約、物理経路、トラフィック比率、切替試験、SLA の実績は分からない。顧客はサービス固有の証拠を契約に組み込む必要がある。

一本の電話番号が解決する問題

支店の通信が止まったとき、最初の難問は故障箇所の修理とは限らない。誰が復旧全体を引き受け続けるのか、という組織上の問題が先に現れる。

アクセス事業者は自社の引渡し点までは正常だと言う。インテグレーターはルーターが応答していると確認する。データセンターには警報がない。アプリケーション担当者は、別の利用者からはサービスが見えると答える。それぞれの限定された観測が正しくても、支店の業務が再開できるとは限らない。チケットが窓口間を移動する間も停止時間は積み上がる。

Scientific-Production Enterprise Business Sviaz Holding LLC は、BSH のブランドでこの調整問題に応える。BSH の単一事業者サービスのページは、ロシアおよび独立国家共同体の拠点網向けに、通信サービスを一つの契約へ集約し、責任窓口を一本化すると説明する。技術サポートのページでは、専任技術者、SLA で定める応答時間、NOC による24時間の障害監視を掲げている。

この仕組みには、実績数値を推測しなくても理解できる価値がある。調整役がサービス台帳を持ち、下位の供給事業者へ連絡し、異なる番号のチケットや監視記録を一本の時系列へまとめれば、顧客は障害のたびに供給網を再発見せずに済む。現場責任者も、どの回線を誰が卸しているかを調べてから助けを求める必要がない。

ただし、契約は物理を変更しない。二つのサービスが同じ管路、同じ建物入口、同じ伝送事業者、同じ電源に依存していれば、請求書が一枚でも共通故障領域は残る。単一窓口が提供するのは、複雑性の消去ではなく、複雑性を調整する責任である。

BSH の公開情報が示す複数の役割

BSH は自社サイトで、1991年創業の独立系 IT インテグレーターと説明している。保存したトップページのメタデータには、インフラ運用の外部委託、ネットワークソリューション、モスクワとヤロスラヴリにある自社の Tier III データセンターが記載されている。同じページの構造化データは、BSH を通信事業者とも表現し、企業データ網、データセンター、IT 運用・技術支援、機器供給を事業分野として挙げる。

これは事業の位置を把握するための一次情報であって、独立した認証資料や稼働率監査ではない。どの顧客がどの施設を使うのか、二本の光回線が別々の入口を通るのか、サポートが実際に何分で応答したのかは示さない。Tier III という表現も BSH 自身の説明として扱うべきで、第三者認証の現状や対象範囲を推定してはならない。

一社がインテグレーター、通信事業者、サポート窓口、機器供給者、データセンター事業者の役割を組み合わせれば、引継ぎは減らせる。その一方で、構成情報、障害履歴、取引先との連絡経路が同じ組織に集中する可能性もある。

顧客が確認すべきなのは最終責任者の名前だけではない。BSH が直接制御できる部分、第三者に代わって調整する部分、契約範囲外の部分を分ける必要がある。この境界が平時に定義されていれば、障害時に責任の所在を交渉する時間を短くできる。

RIPE の登録が証明するもの

RIPE Database の組織オブジェクトORG-BSH1-RIPEには、Scientific-Production Enterprise Business Sviaz Holding LLC という名称、国としてロシア、組織種別として LIR、所在地としてモスクワが記録されている。作成日は2004年4月17日、最終更新日は2026年5月13日である。

自律システムのオブジェクトAS8491はBSH-ASという名称を持ち、同じ組織へ関連付けられ、状態はASSIGNEDとなっている。import と export の欄には、複数の外部自律システムに関する経路方針が宣言されている。

この記録により、企業名と公開されたインターネット番号資源の役割を結び付けられる。マーケティング上の名称だけではなく、登録されたネットワーク上の主体があることを確認できる。一方、登録情報は個別顧客のサービス設計書ではない。

経路方針の宣言は、現在のトラフィック量、商用契約、物理的な分離、あるいは自動切替の成功を意味しない。登録情報から分かるのは、誰がどの資源と関連付けられ、どのような方針が記載されているかまでだ。支店の主回線が切れた後に予備回線が動くかどうかは、現場の構成と試験で確かめなければならない。

五つの IPv4 プレフィックスと一つの IPv6 プレフィックス

2026年8月28日に保存した RIPEstat の routing-status 応答では、AS8491 から五つの IPv4 プレフィックスが観測され、対象は22,528個の IPv4 アドレスに相当した。IPv6 については一つのプレフィックスが観測された。

announced-prefixes の応答には、89.188.160.0/19、87.238.96.0/21、81.95.32.0/20、82.194.224.0/19、より具体的な87.238.101.0/24、そして2a03:8640::/32が並んでいた。

ここには数え方の注意点がある。87.238.101.0/24は、同じ一覧の87.238.96.0/21に含まれる。したがって、一覧に六行あるからといって、互いに重ならない六つの独立したアドレス空間があるとは言えない。より具体的な経路はトラフィックエンジニアリングに使われ得るが、独立した容量や物理的な冗長性を自動的に示すものではない。

同じ routing-status 応答は、その時点で IPv4、IPv6 とも、応答が集計した RIPE RIS ピアの全てから見えていたと報告した。さらに、フルルートを受信するピアのうち十未満にしか見えない、極めて可視性の低い経路は結果から除外すると明記している。

この可視性は、一定の観測方法の下で経路が広く伝播していたという事実である。稼働率ではない。パケット損失、遅延、混雑、ラストマイルの状態、アプリケーションへの到達性は測っていない。IPv6 経路が広く見えることと、特定顧客の製品で IPv6 が有効であることも別問題だ。

経路上の隣接を契約関係と読み替えない

RIPEstat の AS-neighbours 応答は、十の自律システムを経路の「left」、二つを「right」、三つを「uncertain」と分類した。AS8491 の登録方針にも複数の外部自律システムが現れる。慎重に言えるのは、AS8491 が複数の外部関係を持つ経路環境の中で観測されている、ということだけである。

left、right、uncertain は観測された AS パス上の位置を表す RIPEstat の分類であり、取引上の役割ではない。隣接する AS が有償トランジット、顧客、無償ピアのいずれかを、パスだけで確定することはできない。登録方針も、現在の常用経路ではなく、過去の関係や特定条件で使う設定を含む可能性がある。

論理経路が二つあっても、物理的には同じ管路、建物、伝送装置、卸事業者、電源を共有しているかもしれない。反対に、公開 BGP からは見えない物理分離が設けられていることもある。BGP は制御プレーンの伝播を観測する。地下の配管や建物内の給電系統までは説明しない。

公開経路情報は、結論ではなく質問を作るために使うべきだ。どの外部関係が購入するサービスに関与するのか。主系と予備系は同じ卸事業者に依存するのか。建物への引込みは分かれているのか。経路方針の変更は誰が承認し、顧客へどう通知するのか。答えはサービス台帳と試験結果の中に必要である。

「一人が持ち続ける責任」と「同時に止まらない設計」

第一の約束は責任の連続性である。誰が警報を受け、案件を閉じずに維持し、第三者へエスカレーションし、計時し、顧客へ復旧を報告するのかを定める。BSH が全設備を所有していなくても、構成と連絡先を把握し、証拠を統合できれば価値を提供できる。

第二の約束は故障領域の独立性である。どの部品が同時に止まらないよう設計され、何によって分離を確認するのかを定める。対象はサービスに応じて、アクセス事業者、伝送媒体、建物入口、相互接続地点、顧客側装置、電源、経路制御点、運用チームに及ぶ。

この二つは交換できない。顧客が共通依存を理解して受け入れたサービスであれば、BSH がその共通依存による障害を適切に調整しても矛盾はない。一方、「多様化」として販売された二回線は、NOC がすぐ返答しただけでは独立性を満たさない。

約束を分ければ、双方の境界も明確になる。顧客は契約外のアプリケーション障害まで調整役に無条件で負わせずに済む。事業者は、単なる受領確認をサービス復旧と取り違えずに済む。

SLA の時計に開始条件と終了条件を与える

BSH の SLA 解説は、応答時間、平均修復時間、復旧時間目標、責任範囲、契約上のペナルティを定義対象として挙げる。略語を並べるだけでは、実際のサービスを測ったことにはならない。

応答時間は、NOC の警報、顧客からの電話、自動チケット作成、正式な受付のいずれから始めるのか。受領確認、技術者の割当て、診断開始のどこで止めるのか。選択によって測る行動が変わる。契約が曖昧なら、双方が虚偽を述べなくても異なる成績を報告できる。

復旧の時計は、下位事業者のチケットが閉じた時ではなく、利用可能なサービスを試験して止めるべきだ。顧客エッジ装置への到達、合意した損失率と遅延、期待する経路の回復、指定地点からのアプリケーション処理など、製品に合う試験を選ぶ。元データを誰が保持し、異議がある場合にどう再計算するかも必要である。

除外時間にも同じ厳密さが要る。顧客待ち、計画保守、契約外部品の時間を差し引くなら、イベントコード、時刻、責任境界を再現できなければならない。そうでなければ、早く直すよりも時間を有利な分類へ移す動機が生まれる。

ペナルティは最後の層である。安定したサービス台帳、共有された時計、再生可能な記録がなければ、サービスクレジットは技術論争を請求書上の論争に変えるだけだ。

依存関係台帳を契約の付属書にする

主系と予備系の各サービスについて、下位事業者、アクセス媒体、建物入口、相互接続点、エッジ装置、電源、経路制御点、運用責任者を記録する。安全と商業上の秘密を守りながらも、二つのサービスが重要な故障領域を共有するかどうかは顧客が判断できなければならない。

「多様化」という記述には試験を対応させる。試験日、模擬した故障、期待動作、観測結果、未解決の例外を残す。卸事業者の名称を開示できない場合でも、重要な共通依存の有無を確認し、監査方法を合意することはできる。

台帳は納品時の静的資料ではない。卸事業者が収容を変え、光回線の入口が移り、更新後に二つのサービスが同じ設備へ集約されることがある。通知、再証明、再試験を必要とする変更を契約で列挙しておくべきだ。

最後に、証拠は持ち出せる形式でなければならない。サービス台帳、警報、チケット時系列、構成変更、試験結果は顧客の運用記憶である。単一窓口が日常的に管理しても、契約終了や事業者変更の際に顧客が失う設計であってはならない。

BSH の提案を最も強く評価する方法は、一社が全てを直接制御していると仮定することではない。複数の依存関係にまたがる復旧を、一社が調整し続ける仕組みとして評価することだ。顧客に見える窓口は簡潔でよい。その裏側の証拠まで簡略化してはならない。

出典