全銀ネットでの障害が発生して、まぁまぁ時間が経っているけれど、未だに復旧していない。1973年に稼働開始したシステムはとにかく可用性が売りだっただろうし、多くの金融機関もその実績を信用していたのではないか。

本件に関するいくつかの記事を読んでみると、障害は2系統あるシステムのコアタイムシステムのリレーコンピュータで発生したらしい。全銀ネットでは、ハードウェアの保守の絡みで6年に1回の頻度でリレーコンピュータを入れ替えてきたようだが、障害のトリガーはリレーコンピュータをリプレースしたこと。新しいリレーコンピュータの利用を開始したら、そのリレーコンピュータを使っていた金融機関で全銀ネットを利用できなくなったとのこと。

ハードウェアの保守限界の話はあるとしても、リプレースでの事案であれば旧システムに切り戻すという選択肢はなかったんだろうか。もし、そうだとすると大規模なシステムのリプレースにしてはなかなかリスクの高いリプレースだったことになるような気がしないでもない。

また、日経クロスネットの記事によれば、リレーコンピュータ上で動作するプログラムの問題であることは切り分けられているようではあるが、プログラムを改修してみてテスト環境でテストしたらやっぱりエラーが解消しないというなかなかシビれる状況になっているようだ。

全銀ネットによると、10月10日夜から11日早朝にかけて、システム障害の原因になったとみられる中継コンピューター（RC）の内国為替制度運営費（旧銀行間手数料）のチェック機能に関するプログラムの改修を急いだ。しかし、「改修プログラムをテスト環境で試したところ、エラーが継続した」（全銀ネット）としている。

全銀システム障害は11日朝時点で復旧のめど立たず、プログラム改修でもエラー継続より引用

また、全銀ネットではコアタイムシステムの代替システムとしてモアタイムシステムを稼働させており、モアタイムシステムは利用可能な状態になっているものの、代替手段をさらに用意しているとのことで、その1つがLTOテープの持ち込み。そうかぁ、バックアップテープに振替データを書き込んで全銀ネットのデータセンターに持ち込んだら、振り込めるのか…って、レガシーな業界ではテープを持ち込むっていうのが代替手段として用意される世界感なのかというのはちょっと驚いた。

全銀ネットは10日午後2時30分から代替手段による対処に着手。具体的には、全銀システムが備える「新ファイル転送」や、LTO（Linear Tape-Open）テープの持ち込みによって処理するようにした。モアタイムシステムを利用する金融機関は同システムを使っても送金を処理できるという。

全銀システムの大規模障害、中継コンピューター2台ともに不具合で冗長構成が機能せずより引用

しかしまぁ、今回、障害の影響を受けた金融機関の多くはモアタイムシステムに参加してそうだし、モアタイムシステム側は稼働し続けているわけで、金融機関がぱたっとモアタイムシステムの利用に切り替えて業務を継続することができていたら、振り込みの滞留などで大きな問題にはなってはなかったような気がしないでもない。

ただ、法人向けのインターネットバンキングシステムの仕様をちらっと調べてみると、モアタイムシステムを使った振り込みサービスがオプションサービスになっていて、別途、申込みが必要になっていたりすることもあるようだ。例えば、三菱UFJ銀行のBizStationの「24時間サービス」の仕様を読むと、全銀ネットのコアタイムシステムだけでは実現できなさそうで、モアタイムシステムを使ったサービスであることは推測できる。この24時間サービスは、少なくともサービス提供開始時には追加料金不要で利用できていたようでもあるし、今回の障害とは無関係に全銀ネットのコアタイムシステムの処理時間だけで振り込みができるので十分便利ってユーザーも少ないことを考えると、デフォルトでサービスに組み込んでおいてもよかったのではないだろうか。

そう考えると、もちろんトリガーは全銀ネットのコアタイムシステムのリレーコンピュータの不具合ではあるけれど、今回の障害の影響をアンプしちゃったのは金融機関(まぁ、利用者も込みかもしれないけれど)側のシステムやサービスの硬直性かもしれないとも思った。

ただ、まぁ、全銀ネットの業務委託を受けて障害復旧に取り組んでいるであろうNTTデータの技術者の皆さんの大変さを想像すると、一刻も早く復旧することを願うばかりである。

追記 その1:
全銀ネットのが開いた説明会の様子が記事になっていた。個人的に気になったのは切りもどしをしなかった理由に関する部分だ。

今回の障害が起きたリレーコンピュータは14行が共同で利用していたようで、そのうちの11行は影響を受けて取引が停止、残り3行は影響を受けなかったらしい。全銀ネットは切りもどしにはリスクがあると判断したと語っている。邪推かもしれないが、何の影響も受けなかった3行に対して残り11行のために切りもどしに付き合ってもらうように説得することが、全銀ネットの中の人にとってすごく大きなコストだったんじゃないだろうか。

まぁ、外野だからうだうだ言えるのは間違いないが、リレーコンピュータを切り替えるまでまともに動いていた訳なので、その状態に戻すよりも、十分にはテストしようがないドタバタのプログラム改修のリスクが低いわけがないとも思うし。

全銀ネットは日本の金融機関の信頼性の根源ともなる重要なプラットホームであり、今回の障害で、結果的にその価値の一部を部分を失った訳だが、単に一つのシステムの入れ替えで起きた障害をどうするかという視点だけでなく、国家的な重要性をもったプラットホームとしての観点があれば、別の意思決定の可能性はなかっただろうか。

プログラム修正の対応について、切り戻しの判断はなかったのか？　

　両方を検討した上でプログラム修正の選択に至った。切り戻しは選択肢の一つ。しかし、14の金融機関全てで切り戻し作業を行う必要があることを考慮するとリスクが高く、プログラム修正が良いと判断した。

切り戻しよりもプログラム修正のほうがリスクが低いと判断した理由は？

　切り戻しをする場合、14行全ての金融機関に対応を要請する必要がある。トラブルが生じていない銀行もある中で、その銀行も一緒に切り戻しを行わなければならない点を考慮すると、プログラム修正の方がリスクが低いと感じた。ベンダーの意見も踏まえて対応に至った。

「切り戻しよりリスクが低い」、全銀ネットが11日開催した説明会の一問一答より引用

追記 その2:
日経の記事によれば、全銀ネットの障害の原因はメモリー不足だったとのこと。確か、処理を簡素化したら動くようになったみたいな記事があったような気がするので、その処理がメモリーを使っていたと言うことだろうか。ただ、手数料を計算する処理か何かだったはずなので、ぱっと見は大量のメモリーを必要とする処理では無さそうだけどなぁ。いわゆる汎用機のメモリーは安くないとはいえ…メモリー不足で動かなくなるというのはなんだかお粗末な印象を受けてしまう。

実に勝手な話ではあるけれど、例えば、COBOLのランタイムのレアなバグを踏んでいて、本番環境でしか再現しないとか、今回の件を受けてベンダーが集中的にデバッグしたらバグが見つかって…とか、そういうどうしようもない理由で止まってて欲しい気がしたんだが。。。

三菱UFJ銀行など10金融機関で約250万件の送金が滞った全国銀行データ通信システム（全銀システム）の障害は、各金融機関と同システムをつなぐ機器の容量（メモリー）不足が要因だったことがわかった。機器の更新で処理量が増え、想定の容量を超えてパンクした。事前のテストが不十分だった可能性もあり、検証が求められる。

全銀ネット障害、メモリー不足が要因　事前テスト甘くより引用

追記 その3:
11月6日にNTTデータが会見を開いて、先日の全銀ネットの障害の原因について発表したようで。まぁ、全銀ネットのアプリケーションをNTTデータが開発したんだから、障害の原因はNTTデータ製のアプリケーションのバグということにはなるんだけど。決済手数料を計算するためのテーブルを生成するプログラムにバグがあって、バグの結果、テーブルが壊れた状態になるので、別のプログラムがそのテーブルを参照すると処理が異常終了するって感じかな。

事前のテストで、バグを検出できそうなポイントはいくつかありそうな気がしないでもないけれど…はてさて。

全銀ネットの10月18日の発表によると、障害はRCで処理する金融機関の送金／着金の手数料に関連した「内国為替制度運営費」で発生した。ここでの処理方法の1つに「あらかじめRCに設定されたテーブルを参照してRCが電文に金額を入力」があり、その処理にエラーが発生してRCが異常終了し、電文の送受信に影響が生じた。

　NTTデータの説明によると、障害の直接的な原因は、上記の「あらかじめRCに設定されたテーブル」を生成するアプリケーションが内包したバグの可能性が高いという。全銀システムには1100以上の金融機関が接続され、金融機関ごとに多数の取引パターンがあり、障害が発生した処理だけでも数千パターンが存在するという。処理を瞬時に完了するため、RCには「内国為替制度運営費入力・チェック」アプリケーションがあり、このアプリアプリケーションがRCのメモリー上に展開されているインデックステーブルを参照する仕組みとなっている。

NTTデータ、全銀ネットの障害対応を説明–根本原因にめども「包括的な点検が必要」より引用