5月8日に発生した22時間におよぶシステム障害は,いくつものミスが重なったことが原因。インテグレーションを担当した富士通のデータベース(DB)用ミドルウエア製品「SafeFILE」に端を発する。

 話はゴールデン・ウイーク中の5月4日までさかのぼる。同行はユーザー増に対処するため,ハード・ディスクの容量を増強,DBファイルを拡張した。この際,「詳細は不明だが,SafeFILEにバグがある」という報告を富士通から受けた。富士通とやジャパンネット銀行の担当者は同日,SafeFILEをバグのないバージョンに置き換えた。

 そして,問題の5月8日。データの不整合が発生し,普段使っている現用系のDBサーバーがダウンした。待機系のDBサーバーに切り替わったが,障害は回復しなかった。現用系と待機系が,不整合を起こしていた同じDBファイルを参照していたからだ。このデータ不整合は,SafeFILEのバグによるものだった。

 実は,5月4日のSafeFILEのバージョン・アップの際に,本来は新バージョンのSafeFILEをインストールした状態でDBの表構造やファイル構造を作り直さなければならなかった。にもかかわらず,これらの作業を見落としていた。バグ修正前の状態でシステムが稼働。これらの問題個所の特定と対処に,22時間も費やしてしまった。

 5月20日に発生したトラブルは,現用系UNIXサーバーのCPUの故障が原因である。SafeFILEの設定ファイルの更新は済ませていたため,待機系サーバーへの切り替えと同時に障害は回復した。午後2時43分にダウン,17分後の同3時0分に復帰した。17分というのは,「UNIXサーバーなどを再起動する時間」(ジャパンネット銀行IT部の西川原康宏IT企画グループ長)である。

 ただし,疑問は残る。24時間のサービスをうたうオンライン専業銀行が,15分間も「店舗のシャッター」を閉めていいのか。再起動ではなく,ホット・スタンバイにできないのだろうか。

 同行が使っているUNIXマシンは14個のCPUを搭載する。ただし,1個でも壊れるとすべてダウンしてしまうタイプ。「1個のCPUが壊れても,残りのCPUで運用し続けることができるUNIXマシンもあるが,今は使っていない」(西川原グループ長)と言う。14個のCPUは,冗長化のためではなく,単に性能向上のために使っているのだ。

 この点に関して同氏は「CPUが壊れても1台で動き続けるUNIXマシンに変えたい。ただ,投資がかかるし,現時点ですぐに変える気はない。調査検討段階だ」と言う。

(市嶋 洋平=日経コミュニケーション)