要約

  • 9月7日09時19分（CEST）、RIPE NCCは二つのバックエンドサービスを再起動してRRC18を解決済みとしたが、根本原因は不明で調査を続けると明記した。
  • 09時33分（CEST）には、RRC24でupdateとbviewの公開が止まったと告知し、RRC18を映したような事象で共通原因を疑っているものの未特定で、他のRRCも除外できないとした。

14分という数字から、障害が一つの収集器から別の収集器へ移った物語を作ることはできない。09時19分と09時33分は公開ステータスの投稿時刻である。RRC24が実際に公開を止めた時刻でも、RRC18の再起動との因果を測る時計でもない。「類似」と「共通原因を疑う」はRIPE NCCが選んだ暫定的な表現であり、同一原因の認定ではない。

それでも、この801秒は制度上の変化を正確に示す。一つ目の投稿は、出力が戻った一方で原因が開いたままの事故を閉じた。二つ目の投稿は、同じ外形の問題を別の収集器で認め、調査範囲がさらに広がる可能性を公にした。

RRC18の記録を分解する

RRC18の最初の告知は9月4日18時14分（CEST）に出た。RISのupdateファイルとbviewファイルが公開されておらず、最後に挙げられたupdateはupdates.20260904.1335.gz、bviewはbview.20260904.0800.gzだった。ここから分かるのは、RIPE NCCが指し示した公開オブジェクトの時刻までである。検知時刻、影響したファイル総数、全てのRIS提供経路の状態は分からない。

翌5日、RIPE NCCはRRC18のメッセージ処理系を詳しく調べても根本原因を特定できないと更新した。その後、欠けていたupdateとbviewを公開し、RRC18の公開フローは復旧、監視へ移ったとした。7日の最終更新では、二つのバックエンドサービスを再起動して問題を解消したと説明した。同じ段落で、原因はなお不明でトラブルシュートを続けるとも書いた。

ここには二種類の「終わり」がある。利用者が期待する公開物を再び取得できるようになった、という運用上の終わり。そして、公開停止を生んだ条件を特定し、範囲を定め、再発との関係を説明できるようになった、という原因上の終わりである。RRC18は前者に到達したが、後者には到達したと述べていない。

性格の異なる二つのRRC

公式の収集器一覧によれば、RRC18はスペイン・バルセロナのCATNIXに接続するIXP型の収集器である。RRC24はウルグアイ・モンテビデオでLACNICがホストする、地域向けのマルチホップ収集器だ。設置場所も収集方法も異なる。

この違いは、共通原因を証明する材料ではない。むしろ調査で残すべき問いをはっきりさせる。両者の公開経路が共有する依存関係、配備単位、フェイルオーバーのまとまりは何か。あるいは、二つの別々の故障が同じ外部症状を示しただけなのか。

RRC24の公開記録は調査中だった。二つの再起動対象の名称も、問題を起こした設定も、ソフトウェア版も示していない。また、他のRRCがすでに影響を受けたとは書いていない。「今後数時間または数日、同じ問題を除外できない」という警戒範囲を示しただけである。

データについても同じ慎重さが要る。RISは収集器ごとにMRTデータを公開する。bviewは経路状態を表すダンプで通常8時間ごと、updateは変化を記録して通常5分ごとに作られる。公開停止は、これらを証拠として使う研究者や運用者にとって重要だ。しかし、BGP経路自体への影響、収集データの消失や破損、全てのインターフェースの停止は、この障害ページからは確認できない。

RIPE NCC側の合理性

サービスを先に戻し、原因を後から調べるのは通常の事故対応である。原因が完全に分かるまで公開停止を続ける方が、利用者にとっては悪い。RIPE NCCはRRC18の不足分を公開し、フローを復旧させ、再起動という措置を説明した。それと同時に、原因が不明であることも、RRC24との関係が仮説であることも、範囲が広がり得ることも隠さなかった。

復旧したRRC18を障害中の色に置き続けると、現在の可用性を誤って示す。ステータスページがまず「今、使えるか」を答える道具なら、解決済みにする判断には十分な理由がある。

問題は判断ではなく、表示できる状態の数だ。一つの緑色だけでは、「公開は戻った」と「原因は閉じた」を区別できない。原因調査は閉じたページの文章の中にだけ残り、RRC24のような次の事象が出なければ注意から消えやすい。

公開できる故障領域レシート

内部トポロジーや設定を明かす必要はない。事故番号と収集器に結び付いた小さなレシートで十分である。症状の分類、復旧措置、サービス復旧時刻を記録し、原因の状態を別欄に置く。

原因欄は「未特定」「仮説を調査中」「裏付けあり」「棄却」「確認済み」のように更新できる。複数事故の接続を疑う場合は、配備、依存関係、フェイルオーバーの同じまとまりを、機密を漏らさない安定トークンで示す。再発監視の対象と終了日、フォローアップの責任者、原因を閉じた日時、訂正履歴も残せる。

この形式なら、RRC18の公開復旧と原因未解決を同時に保持できる。後にRRC24が無関係と判明すれば、過去を書き換えず仮説を棄却できる。共通層が見つかれば、最初のタイムラインを維持したまま二つの事故を結べる。

8月25日には別のRIS事象があり、bviewは生成されたがフェイルオーバー後の設定不備で公開されず、監視の穴も認められた。これは生成と配信を区別し、ファイル単位で監視する議論の対象である。9月の二件と同じ原因だという証拠ではない。本稿はその対策を繰り返さず、復旧後も残る故障領域の説明責任だけを扱う。

情報源