作業領域の不足によるインデックス破損が発生

　全銀システムのトラブルが発生したのは10月10日午前8時30分。銀行間のネットワークである全銀システムが稼働するのと同時に障害が発生した。詳細はすでに掲載されているが、まずはざっくりと経緯をまとめておく。

　今回の障害では、銀行間で送金をする際の手数料である内国為替制度運営費を定めるプログラム部分で問題が起きて、金融機関と全銀センターを接続するための中継コンピュータ（RC）がシステムダウンしたというものだ。結果として、10の金融機関で全銀システムと接続して送金などを行う「テレ為替」と呼ばれる業務が行えなくなった。障害は11日まで続き、最終的な復旧は12日の朝までかかった。

　正確に言えば12月1日現時点での対応は「暫定対応」とされており、完全復旧自体はされていないが、全銀システムは通常通りの運用がされている状態だ。

　全銀システムのRCは、これまで定期的に更改（バージョンアップ）を行ってきた。前回の更改は2017年で、通称RC17シリーズと呼ばれている。RCの保守期間は6年間なので、これを刷新する形でRC23シリーズの導入が進められようとしていた。

　その第1弾として14金融機関に対して、10月の3連休（7～9日）において更改作業を実施。週明け10日の営業開始の8時30分に至ったそのタイミングで障害が発生した。

　内国為替制度運営費は、テレ為替業務において1件ごとに送金元金融機関（仕向機関）が送金先金融機関（被仕向機関）に支払う形式で、金融機関からRCを経由して全銀センターに送信される電文上に付加される。ここで後述する障害が発生してRCがダウン。電文の送受信が行えなくなった。


　復旧対応では、この内国為替制度運営費を「すべて0円にする」という対策で対処。金融機関名を参照していたデータテーブルの破損が原因だったため、テーブル自体を参照しないように設定したことで対応。本来は手数料を正しく算定しなければならないので、あくまで暫定対応が継続している状態だ。

　いずれにしてもこの対処によってRC23がシステムダウンすることなく稼働して送金などのテレ為替も問題なく動作するようになった。復旧確認ができたのは12日午前3時30分頃で、午前8時30分の営業開始からは正常に送金などが行われた。丸2日間に及ぶ長期間の障害となった。

64bit化に対応できなかった理由

　RC23で問題が発生した背景には、コンピュータのOSを32bitから64bitに変更した点が上げられる。OS自体はLinux系とのことだが、従来の32bitから64bitにしたことで、ソフトウェア的にはいくつかの変更が必要だった。

　今回問題となった内国為替制度運営費では、生成プログラムが金融機関名テーブルと金融機関コードインデックス・正読金融機関名インデックス・略読金融機関名インデックスという3つのインデックステーブルを生成してメモリ上の作業領域に展開。それを運営費付加・チェックプログラムがロードして電文に書き込む作業を行う。

　その時、64bit化による互換性対応を進める中で金融機関名テーブルのサイズが増えており、作業領域に確保する容量も多く必要になっていた。ところが、開発時点でこの容量を見誤った。4つのテーブルが生成され、あわせて適切な容量を確保すべきところを、開発工程で「確保する容量はテーブル1つずつ」と誤解していたという。

　その結果、金融機関名テーブルは容量内に収まったが、インデックステーブルがあふれてしまいデータが破損。それを読み取りにいったプログラムが異常終了してRCを巻き込んでダウンした、というのが原因だ。


　直接的な原因自体は作業領域の不足で、一部で言われていた「メモリ不足」は正確ではない。ただ、根本原因は相次ぐ「ミス」だった。

　設計・製造工程プロセスでは、OSのバージョンアップにおいて非互換対応の影響は調査したが、その修正を製造関係者のみで判断して設計関係者が参加しなかった結果、仕様書には記載のあった「テーブル全体で必要な容量を確保する」という点が見逃された。



　試験工程プロセスでは、テーブル破損をチェックできなかった点が問題で、非互換対応における異常検知で課題があったという。テーブル自体には変更がなかったことから試験の対象になっていなかった。

　レビューでも4つのテーブルがまとめて展開されることが十分認識されていなかったとのことで、詳細設計を踏まえたレビューが行われなかったことで問題が見逃された。NTTデータの佐々木裕社長は、「初歩的（なミス）というレベルではないと思う」と話しつつ、組織的にはミスを抑えられたのではないかと反省の弁を述べている。 【次ページ】切り戻しできず、「BCPの不備」を振り返る