要約

  • 1990年1月15日のAT&T長距離障害では、ニューヨークの4ESSトールスイッチに起きた小規模なハードウェア問題が発端になったが、全国規模の説明はそこでは終わらない。AT&Tの説明によれば、通常なら4秒から6秒で処理を戻す復旧動作の後、隣接スイッチへ届いた正当なInitial Address Message（IAM）が、Direct Link Node（DLN）プロセッサの状態マップ復旧中に潜在的なソフトウェア欠陥を露出させた。
  • この事故の責任境界は、攻撃やウイルスや単一人物の過失ではなく、4ESS群に広く入った共通ソフトウェア変更、CCS7信令面での復旧通知、同一コードを走らせる二重化プロセッサ、バックアップ信令リンク、観測、隔離、ロールバックを運用者がどう検証し、段階化し、止められるようにしていたかにある。

事故と証拠範囲

この分析の範囲は、1990年1月15日にAT&Tの長距離網で起きた4ESSとCCS7信令のカスケード、当日の安定化、翌日のロールバック、技術調査に限る。後年の無線網設定障害、911関連の障害、ファイバー切断、フレームリレー、現代のSS7悪用事案とは分けて扱う。ここで問うのは、当時のAT&T長距離オペレーターが、全国の通話を支える信令ソフトウェア変更を、障害ドメインごとに隔離し、実運用相当の復旧遷移で観測し、異常時に戻せるよう管理していたかである。

公開資料が示す事実には強弱がある。AT&T自身の技術説明は、ニューヨークの4ESS、IAM、DLN、状態マップ復旧、100分の1秒以内に届く2つのIAM、二重化プロセッサ、CCS7からの一時的な隔離、バックアップ信令リンク上のトラフィック削減、前プログラムへの復帰、実験室での再現と修正を結びつけている。一方、後年のソフトウェア工学系の説明には、誤配置されたbreak文といった叙述があるが、このパケット内の一次的公開資料は欠陥のソースコードを示していない。したがって、それらは「そう説明されてきた二次的な物語」であり、確認済みの公開コード証拠ではない。

この境界設定は、記事を狭くするためではなく、責任分析を混濁させないために必要である。1990年の障害では、電話網の可用性が、音声の物理経路だけでなく、制御面の状態共有とソフトウェア版の整合性に依存していた。したがって、後年の異なるネットワーク、異なる設定変更、異なる緊急通報障害、異なるセキュリティ脅威を同じ物語へ混ぜると、何を検証し、何を直すべきだったのかが見えなくなる。ここで扱うべき証拠は、ニューヨークで始まった通常復旧、隣接スイッチのDLN状態更新、継続するCCS7メッセージ圧力、広い共通変更、バックアップリンクの扱い、当日夜の安定化、翌日の前プログラム復帰である。

ニューヨーク4ESSの復旧トリガー

AT&Tの説明では、障害は米東部時間1990年1月15日午後2時30分ごろ、ニューヨークの4ESSトールスイッチに小さなハードウェア問題が起きたところから始まった。この事象は、新規通話処理を4秒から6秒ほど一時停止し、接続先の4ESSスイッチに新しいトラフィックを送らないよう知らせる通常の障害復旧ロジックを起動した。重要なのは、この初期事象を全国障害の根本原因と呼ばないことである。小さなトランクインターフェース側の問題は引き金であり、全国的な影響を作ったのは、その後の復旧状態と共通信令ソフトウェアの相互作用だった。

もし一つのスイッチが短時間で復旧し、隣接スイッチがその状態を正常に取り込めていれば、この事象は地域的で短い障害として終わった可能性がある。長距離網の責任論で問題になるのは、復旧が失敗したことそのものよりも、復旧を知らせる仕組みが、同じ欠陥を他のスイッチでも繰り返し起こす条件になった点である。ネットワークでは「戻る」という動作も制御面の実行コードであり、障害時だけでなく、復旧時にも同じ厳しさで検証されなければならない。

ハードウェア事象とソフトウェア欠陥を分けることは、原因を細かく見せるための形式論ではない。物理的な小故障は、どの大規模網にも起き得る。設計上の問いは、その小故障が復旧手順に入った時、制御面が局所的な状態変化として吸収できるか、それとも隣接ノードへ同じ危険条件を運ぶかである。AT&Tが示した時系列では、初期のニューヨーク事象は通常復旧を起動したにすぎず、カスケードの中心は、復旧後に送られた正当な信令メッセージと、既に配備されていたソフトウェア状態との衝突にある。この分離を崩すと、対策も誤る。部品交換だけでは、同じ状態遷移欠陥を持つスイッチ群を安全にはできない。

IAMタイミングがDLN欠陥を露出させた仕組み

AT&Tの説明によれば、ニューヨークのスイッチが処理を再開すると、隣接スイッチへInitial Address Message、すなわちIAMが送られた。IAMは通話設定に関わる正当な信令メッセージであり、悪性ペイロードとして扱うべきものではない。受信側のスイッチではDirect Link Nodeプロセッサがそれを使い、ニューヨークのスイッチがサービスに戻ったことを状態マップに反映した。

欠陥が露出したのはこの状態更新の間だった。AT&Tは、DLNプロセッサが数秒間の脆弱な復旧遷移に入り、その間に2つのIAMが100分の1秒以内に到着するとデータが損傷し、プロセッサが再初期化を強いられると説明した。ここでの中心は、異常なメッセージではなく、正当なメッセージと実行中の復旧状態の組み合わせである。信令面の安全性は、仕様上有効なメッセージを受け取れるかだけでなく、そのメッセージが状態遷移の境界で連続到着したときに、状態表、プロセッサ、隣接ノード通知が一貫したまま保たれるかに依存する。

この種の欠陥を見つける試験は、単純な機能試験とは異なる。試験対象は「IAMを処理できるか」ではなく、「復旧中の状態マップ更新にIAMが密接して入ったとき、DLNがどの中間状態を通るか」である。さらに、1つ目のIAMで状態マップが更新され始め、2つ目のIAMが100分の1秒以内に届くというAT&Tが示した条件は、通常負荷の平均値だけを見ていては消える。必要なのは、間隔を縮めた到着列、復旧直後のバースト、隣接ノードごとの到着順序差、再初期化直後の再投入、状態表が完全に確定する前の追加メッセージを含む遷移試験である。

この試験は、攻撃シナリオの探索ではない。IAMは正当な通話設定メッセージであり、問題はそれが正当な時点に正当な量で届いた場合でも、実行中コードが壊れないかどうかである。通信事業者にとって、制御面の通常メッセージは常に安全であると仮定してはならない。通常メッセージであっても、復旧中、再初期化中、隣接状態の変更中、バックアップリンク切替中に届けば、実装の隠れた前提を破ることがある。したがって、状態遷移試験は、負荷試験、タイミング試験、復旧試験、二重化試験を分けずに組み合わせる必要がある。

二重化プロセッサは独立境界にならなかった

4ESS側のDLNには二重化されたプロセッサがあった。通常の信頼性設計では、片方が再初期化しても、もう片方が処理を受け継ぐことが期待される。しかしこの事例では、二重化は独立した安全境界として機能しなかった。AT&Tの説明では、最初のプロセッサがIAMの密接到着と状態マップ更新の組み合わせで再初期化すると、相方のプロセッサがトラフィックを引き受けた。しかし同じように近接したメッセージの組が、その相方の同じ脆弱な遷移にぶつかり得た。

この構造では、二つのプロセッサは物理的には重複していても、運用上の失敗ドメインは同じだった。両方が同じソフトウェア条件、同じメッセージ圧力、同じ復旧状態にさらされるなら、冗長性は「別の実装」でも「別のタイミング領域」でもなく、同じ欠陥を二回踏むだけになる。ネットワーク継続性の観点では、冗長な部品数よりも、状態遷移、コード版、メッセージ入力、隔離手段が相関しているかどうかを管理しなければならない。

二重化の評価では、片系停止時に相方が生きているかだけを確認しても足りない。相方が引き受ける瞬間には、負荷、状態、キュー、隣接ノードからの認識、バックアップ経路への期待が変化する。そこで同じコードが同じ状態マップ更新を走らせ、同じIAM間隔にさらされるなら、二重化は相関障害を遅らせるだけで、独立した障壁にはならない。独立性を主張するには、少なくとも故障を踏んだ系から引き継いだ系が、同じ脆弱状態に同じ形で入らないこと、同じメッセージ列を無制限に受けないこと、再初期化と復旧通知の順序が観測可能であることを示す必要がある。

この点は、通信インフラの説明責任に直結する。冗長構成図は、プロセッサが二つあることを示せる。しかし利用者が必要とするのは、故障時に片方が落ちても通話設定の制御が継続するという実効性である。1990年の事例では、同じロジックを走らせる二つのDLNプロセッサが、同じ復旧遷移と同じ信令圧力に接続されていた。したがって、責任ある試験は、片系だけを個別に壊すのではなく、片系の再初期化、相方への引き継ぎ、相方の状態更新、隣接ノードの復旧認識、次のIAM到着を連続した一つのシナリオとして扱わなければならない。

復旧通知が伝播機構になった

一つのスイッチがCCS7信令ネットワークから一時的に孤立すると、そのスイッチは利用不能状態を周囲へ知らせる。再初期化後には通話信令を再開し、周囲はその復旧を認識する。AT&Tが説明したカスケードでは、この復旧認識そのものが次の失敗を起こす条件になった。隣接スイッチは、利用不能から利用可能へ戻る状態を取り込む際、同じIAMタイミング条件に遭遇し得た。こうして復旧アナウンスは、安定化の信号であると同時に、同じ欠陥を別の場所で露出させる信号になった。

後年の研究は、この事故を制御面のpoison message型不安定性の例として扱っている。ただしここでも「poison」とは攻撃者の意図を意味しない。正当なプロトコルメッセージが、実装上の潜在欠陥とネットワーク管理動作の組み合わせで、制御面全体の不安定性を再生産するという意味である。この区別は重要である。悪意ある侵入を想定すれば対策は境界防御や攻撃検知に寄り過ぎる。ここで必要なのは、正当なメッセージが正当なタイミングで大量に流れても、復旧状態が破壊されないことを確認する設計である。

伝播の責任境界は、最初の故障地点だけでは決まらない。隣接スイッチが、復旧した相手をどう認識し、状態表へどう反映し、どの順序でトラフィックを戻すかが、次の障害条件を作る。復旧通知は、網を通常状態へ戻すための制御である一方、共通欠陥がある場合には、その欠陥を試す入力にもなる。したがって、事故計測では、どのスイッチが最初に再初期化したか、どの隣接ノードがその復旧を処理したか、どのIAM列が状態更新中に届いたか、どの時点でCCS7からの孤立が生じたかを分離して記録する必要がある。単に「障害が広がった」と書くだけでは、伝播を作った制御面の条件が失われる。

12月中旬の共通変更境界

広域障害を説明するもう一つの軸は、共通ソフトウェア変更である。AT&Tは、欠陥が12月中旬の更新で4ESSスイッチ群に入ったと説明した。この更新の目的は、スイッチがバックアップ信令ネットワークへより速く到達できるようにすることだった。現代的な言い方をすれば、可用性を上げるための変更が、同じ可用性制御の失敗ドメインを広げていた。

Telephonyの当時の説明としてRISKSに再録された記述は、新しいコードが114の4ESSシステムのフロントエンドプロセッサにロードされたとしている。この数は、広範な配備境界を理解するために重要である。ただし、それは全114システムが同時に失敗したという証拠ではない。公開パケットにあるのは、同一のソフトウェア条件が4ESS群に広く入っていたという境界であり、全スイッチの同時故障ログではない。責任論はここで精密でなければならない。広範な共通変更は、全国的な再現可能性を作るが、全ノード同時崩壊を証明するものではない。

共通変更を扱うとき、運用者に必要なのは、どのスイッチがどの版を走らせ、いつ更新され、どの範囲が観測期間にあり、どの条件で配備を止めるかという台帳である。バックアップ信令ネットワークへ早く到達するための変更は、表面上は復旧能力を高める変更に見える。しかし、その変更がDLNの状態更新や復旧通知の流れに触れるなら、配備対象は単なる機能追加ではなく、障害時に最も使われる制御面である。段階的露出がなければ、同じ欠陥が局所的な異常として発見される前に、広いスイッチ群で同時に潜在条件を持つことになる。

停止条件も、顧客影響が目に見えてからでは遅い。DLN再初期化の増加、短時間のCCS7孤立、隣接状態マップ更新の失敗、バックアップ信令リンク上の復旧関連メッセージ密度、同じ版を持つ複数ノードでの類似エラーなど、制御面の早い兆候を停止条件に含めなければならない。段階配備とは、単に少数から始めることではない。観測する指標、止める権限、戻す版、戻した後の確認を、配備前に決めておくことである。

検知、診断、安定化

AT&Tは当初、標準的な手順で対応したが、それだけでは不十分だったと説明している。その後、エラーメッセージのパターンやスイッチ挙動を調べ、技術支援部門とBell Labsのチームが関与した。ここで運用上の論点は、障害を単一のハードウェアイベントとして閉じず、信令プロセッサ、状態マップ、メッセージ圧力、バックアップリンクの負荷という複数の観測対象を結びつけた点にある。

安定化のため、AT&Tはバックアップ信令リンク上の信令トラフィックを一時的に停止または減少させ、影響を受けるプロセッサへのメッセージ負荷を下げたと説明した。最後のリンクが解除されたのは午後11時30分とされる。この措置は、障害の本質が通話の音声経路そのものではなく、通話を設定し、状態を共有し、復旧を伝える信令面にあったことを示す。バックアップ経路は存在しても、その経路に流れる管理・復旧メッセージが同じソフトウェア欠陥を刺激するなら、単純な代替経路では継続性を守れない。

バックアップ信令経路が独立しているかどうかは、物理的に別の道があるかだけでは決まらない。その経路へ到達する判断、経路上で処理されるメッセージ、復旧状態の認識、DLNの状態マップ更新が、同じ実行コードに支配されていれば、バックアップは独立した制御ではなく、同じ欠陥へ到達する別入口になる。1990年の事例では、問題の更新自体がバックアップ信令ネットワークへの到達を速める目的だったとされる。この事実は、バックアップの存在を安心材料として扱う前に、そのバックアップを起動し、使い、止め、戻す制御がどのコードに依存しているかを確認しなければならないことを示す。

安定化時の信令隔離は、単にトラフィックを減らす操作ではない。隔離は、どのメッセージ種別を抑えるのか、どのリンクを残すのか、どの観測を継続するのか、復旧後にどの順序で戻すのかを含む。全てを止めれば不安定性は下がるかもしれないが、同時に診断に必要な証跡も失われる。全てを流せば観測は増えるが、欠陥を刺激し続ける危険がある。責任ある制御は、この二つの間にある。疑わしい復旧関連メッセージを抑制しながら、DLN再初期化、隣接状態変更、CCS7孤立、バックアップリンク負荷を測れる状態を保つ必要がある。

ロールバックと実験室での再現

翌火曜日、AT&Tは問題の更新を外し、一時的に前のプログラムへ戻した。その後、問題を実験室で再現し、欠陥を修正し、テストしてからバックアップリンクを復旧させたと説明している。この順序は、事故後対応の中核である。まずメッセージ負荷を落として広域の不安定性を止め、次に共通変更を戻し、次に再現と修正を行う。原因、伝播、緩和、恒久修正を分けて扱うことが、公開説明でも内部制御でも必要になる。

ただし「実験室で厳しくテストしていた」という主張だけでは、変更管理の問いは終わらない。むしろ公開資料から生じる問いは、実験室テストが、復旧状態に入ったDLNへ100分の1秒以内に2つのIAMが届く条件を扱っていたか、二重化プロセッサを独立した部品ではなく結合した復旧システムとして試したか、4ESS群への配備前に段階的露出と停止条件を持っていたか、信令負荷を隔離しながら観測を失わない制御が用意されていたかである。

ロールバックも、事後に実行できたことだけで十分とは言えない。大規模通信網では、戻すべき前版が保存され、各スイッチの現在版が確認でき、戻す手順が変更対象の壊れた制御に依存せず、戻した後に信令リンクをどの順序で復帰させるかが演習されていなければならない。前プログラムへの復帰は重要な緩和だったが、次の同種事故を防ぐ観点では、前版へ戻せることを配備前に検証していたか、戻した状態で隣接ノードの状態表がどう収束するか、バックアップリンクを再開したとき同じ復旧メッセージ圧力が再発しないかを確かめる必要がある。

影響測定の限界

影響の規模について、公開資料は完全には一致しない。AT&Tや主要紙は、障害の相当部分で試みられた長距離通話のおよそ半分が失敗したと報じた。UPIは、遮断された通話が5000万件と推定され、800番号サービスやコンピューター回線サービスにも影響が出たと伝えた。後年の叙述にはさらに大きな数を使うものもある。

ここでしてはならないのは、「半分の通話」と「5000万件」を一つの精密な統計に合成すること、また未確認の金銭損失を作ることである。半分という表現は一定時間帯の試行通話に関する比率として扱うべきであり、UPIの5000万件は同紙が伝えた推定として扱うべきである。公開パケットは、顧客別、地域別、緊急通報別、金融取引別、データ回線別の完全な影響表を提供していない。測定できたこと、推定されたこと、未公開のまま残ったことを分けるのが、信頼できる事故説明の前提である。

測定では、引き金、伝播、復旧、顧客影響を混ぜないことも重要である。ニューヨークの小さなハードウェア問題が起きた時刻、隣接スイッチでDLNが再初期化した時刻、CCS7から孤立した区間、バックアップ信令リンク上のトラフィックを落とした時刻、最後のリンクが解除されたとされる午後11時30分、翌日の前プログラム復帰は、それぞれ別の測定対象である。顧客に見えた通話失敗はその結果だが、通話失敗数だけでは、どの制御面の状態がいつ壊れ、いつ収束したかは分からない。公開報告が信頼されるには、顧客影響の推定と、制御面の技術時系列を分けて示す必要がある。

4ESS、CCS7、ITU資料の使い方

この事故の制御面を理解するには、4ESSとCCS7を電話機や通話音声から切り離して考える必要がある。ITU-T Q.700は、Signalling System No. 7を共通線信令のアーキテクチャとして説明し、Message Transfer Partがユーザー機能間の信令を運ぶ構造を示す。Q.701、Q.704、Q.705、Q.706、Q.752は、構造、信令ネットワーク機能、性能、監視、測定の文脈を与える。NTIAの資料も、通信網の信頼性や相互接続を考えるための背景を提供する。

これらの資料は、1990年のAT&Tが特定の勧告に違反したことを後から証明するものではない。そう使うべきではない。役割は別にある。CCS7が、状態、ルーティング、復旧、通話設定の共有制御層であり、その整合性と継続性がベアラ網の利用可否を左右することを説明するための文脈である。つまり、この事故は「電話が多すぎた」話ではなく、信令状態の真実をどのプロセッサが、どのコード版で、どのタイミングで、どの隣接ノードに伝えたかの話である。

ITU系資料やNTIA資料を背景として使う際の注意点は、事故後の抽象論で1990年当時の個別責任を過剰に断定しないことである。ここで有効なのは、共通線信令が、通話を成立させるための制御事実を運ぶ層であり、その層の復旧状態、監視、性能、測定が通信継続性に直接関わるという読み方である。したがって、事故の教訓は、標準名を並べることではなく、実際の4ESS群で、どのDLNがどの状態にいて、どのIAMがどの順序で届き、どのバックアップリンクがどの負荷を受け、どの版のコードがそれを処理したかを説明できる運用記録を持つことにある。

トリガー、根本条件、伝播、緩和の分離

この事例の因果階段は分けておく必要がある。第一に、ニューヨークの4ESSで起きた小さなハードウェア問題が、通常の復旧処理を起動した。第二に、12月中旬の共通ソフトウェア更新によって、DLNの状態マップ復旧ロジックにタイミング依存の欠陥が入っていた。第三に、復旧後のIAMと隣接スイッチの状態認識が、同じ欠陥を別のスイッチで再現する伝播条件になった。第四に、AT&Tはバックアップ信令リンク上のトラフィックを落とし、前のプログラムへ戻し、実験室で再現して修正した。

この分離は責任を薄めるためではない。むしろ責任を明確にするためである。ハードウェアを責めるだけでは、なぜ全国規模になったのかを説明できない。ソフトウェア欠陥だけを語ると、なぜ復旧通知が伝播路になったのかが見えない。バックアップ信令網だけを語ると、なぜそのバックアップに速く到達するための更新が共通失敗ドメインになったのかが隠れる。運用責任は、これらを一つの実行中システムとして見ていたかにある。

分離した因果階段は、事後改善の単位にもなる。トリガーには、局所故障を吸収する復旧設計が必要である。潜在欠陥には、復旧遷移とメッセージ密度を含む試験が必要である。伝播条件には、隣接ノードの状態認識、バックアップリンク、共通コード配備の隔離が必要である。緩和には、信令負荷の制御、観測の維持、ロールバック権限が必要である。顧客影響には、測定値と推定値を分けた報告が必要である。どれか一つを全体原因と呼ぶと、他の制御が改善対象から外れてしまう。

実行コードと運用状態の優位性

通信網の可用性は、パンフレット上の冗長構成や「バックアップあり」という表示で決まらない。実際に走っているコード、各スイッチのソフトウェア版、信令状態、プロセッサ健康状態、復旧通知、ロールバック権限が一致しているかで決まる。1990年の事故では、バックアップへ早く到達する目的の変更、共通配備、復旧状態、IAM到着タイミング、二重化プロセッサの相関が、紙面上の冗長性よりも強い現実を作った。

したがって、責任分析は抽象的な「品質管理」では足りない。必要なのは、各スイッチがどの版を走らせているか、どのDLNがどの状態にいるか、どのIAM列が状態更新中に届いたか、どのリンクが隔離され、どのリンクが観測用に残ったか、誰がロールバックを承認できるかを記録する運用台帳である。正確な状態記録がなければ、復旧は推測に頼ることになる。推測で動く復旧は、同じ信令面にさらに不確実性を注入する。

この台帳は、監査用の静的な一覧ではなく、事故時に使える運用情報でなければならない。版の一覧があっても、DLNが再初期化中か、隣接ノードが利用不能状態を認識しているか、バックアップリンクが復旧メッセージで混んでいるかが分からなければ、現場は適切に隔離できない。逆に、リアルタイムの警報があっても、どのスイッチが12月中旬の共通変更を持つかが分からなければ、同じ欠陥を持つ範囲を特定できない。実行コード、状態、信令、版、権限は一つの運用事実として結び付けて管理される必要がある。