PR

 みずほフィナンシャルグループ(FG)は5月20日、みずほ銀行が3月に引き起こした大規模システム障害の全貌を明らかにした。本誌が合計38ページの報告資料を検証したところ、30の不手際が重なり影響が拡大した事実が判明した。
 大規模障害を招いた直接の原因は、システム部門の不手際だ。システム全体の仕様や機能をつかみきれず、障害後には運用ミスを重ねた。だが根本的な原因は、経営陣のITガバナンスの欠如にある。老朽化したシステムの刷新を怠り、障害対応では経営判断が後手に回った。
 これらは、みずほ銀に限ったことではない。基幹システムのブラックボックス化、運用ミスの多発、経営陣のIT軽視は、多くの企業が抱える問題である。
 3度目の大規模障害を防ぐために、みずほ銀は経営主導でITガバナンスの強化とシステム刷新を果たす必要がある。

 東日本大震災から3日後の2011年3月14日。この日の午前に最初のトラブルは発生した。テレビ局が東日本大震災の義援金を番組などで呼びかけたところ、みずほ銀行東京中央支店のテレビ局の義援金口座(以下、口座a)に、振り込みが殺到した。午前10時16分、振り込みによって生じた「取引明細」の件数が上限値を超え、口座aに対する「預金・取引内容照会」ができなくなった。取引明細は通帳の記帳に使う。

 みずほ銀は口座aを、格納できる取引明細の上限値が小さい「個人・通帳口」として間違って設定していた表1の1)。

表1●みずほ銀行30の不手際
本文中の太字にそれぞれ対応する
[画像のクリックで拡大表示]

 みずほ銀は口座の種類を二つの属性の組み合わせによって区別している。一つは「個人」か「法人」か。もう一つは、取引明細を通帳に記帳する「通帳口」か、記帳しない「リーフ口(ぐち)」かである。これら二つの属性によって、格納できる取引明細の上限値が変わる。通常、義援金口座のような大量振り込みが予想される口座は、リーフ口として登録する。リーフ口の場合、取引明細が上限値を超えることはない。取引明細を保存しないからだ。

 みずほ銀が口座aの開設手続きを実施したのは2005年9月のことである。この際、みずほ銀は口座aを「個人・リーフ口」にしていた。ところが2007年12月、テレビ局から「振り込み明細を通帳で把握したい」との要望を受け、「個人・通帳口」に変更した。

夜間バッチでも上限オーバー

 午後3時以降に受け付けた振り込み依頼は、夜間バッチで入金処理する。午後10時7分、口座aの夜間バッチが異常終了した。

 実は夜間バッチでも、一つの口座につき何件まで処理できるかを示す上限値の設定があった。口座aは、振り込み処理の前に明細を退避する準備処理で、この上限値をオーバーした。このとき、現場にいたシステム担当者は、このような上限値が勘定系システム「STEPS」に存在することを知らなかった(2)。

 担当者は異常終了時のエラーメッセージなどから上限値の存在を突きとめ、上限値を拡大した。その後バッチ処理を再実行したが、また異常終了した。先の異常終了によって、一部の振り込みデータが欠落していた(3)からだ。再実行には欠落データの復元が必要だ。結果的に、この復元に8時間を費やした(4)。復元作業の過程で、翌朝のオンライン起動に向けたタイムリミットの午前6時までに夜間バッチが完了しないのは確実になった。

 みずほ銀のシステム担当役員である萩原忠幸常務執行役員は、15日午前3時30分頃になって初めて、IT・システム統括部から障害の報告を受けた。担当役員が障害発生を知るまで、最初のトラブルから17時間かかった(5)。

為替未送信に気付かず

 午前5時、萩原常務執行役員は、店舗の営業を開始する午前9時までにオンラインシステムを稼働するよう指示した。萩原常務執行役員は午前7時に、障害発生を西堀利頭取に報告した。トラブル発生から21時間後のことだ(6)。

 みずほ銀は昼間のオンラインと夜間バッチを、同じハードウエア(富士通製メインフレーム)で交互に実行する。オンラインとバッチの並行処理は想定せず、準備もしていなかった(7)。

 午前7時、みずほ銀はオンラインを稼働するために、夜間バッチを中断してバッチの日替わり処理を実施した。これが新たなトラブルをもたらした。

 この夜間バッチの中断によるトラブルは四つある。一つめは、夜間バッチの後に実行するはずだった15日指定の「仕向為替(他行向けの振り込み依頼)」31万件が、すべて未送信になったことだ。しかもIT・システム統括部は15日午後5時にこの問題が顕在化するまで、14日午後10時7分に夜間バッチが異常終了してから19時間もの間、為替未送信の恐れに気付かなかった(8)。

 二つめのトラブルは、オンラインの稼働遅延だ。夜間バッチの中断によって、融資や外国為替などの業務が不可能になった。そのため、営業店でこれらの取引ができないようにする「取引抑止オペレーション」の実行を余儀なくされた。みずほ銀は当初、取引抑止オペレーションの作業時間を30分と見積もっていたが、実際には5倍の2時間30分かかった(9)。営業店端末を使った15日の取引開始時刻は、営業店開店時刻の午前9時から1時間25分遅れ、午前10時25分になった。

 夜間バッチの中断によるトラブルの三つめは、顧客サービスの停止である。例えば法人向けEBサービスで取引明細を提供できなくなった。口座振替結果データの一部が作成不能になったり、外貨定期預金の自動継続・解約などができなくなったりもした。これらの障害は22日まで続いた。

 四つめのトラブルは、夜間バッチを中断した後の自動運用手順を用意していなかった(10)ことだ。みずほ銀は「TARGET」と呼ぶ夜間バッチの自動運行システムを使っている。富士通が開発したものだ。TARGETは一晩に約3万件のジョブを自動実行している。

3万ジョブが手動に

 このTARGETをいったん使わないようにすると、その後の夜間バッチをすべて手作業で実行しなければならない手順だった。しかも、手作業による運用手順についても、3万ジョブの終盤に異常が発生した場合だけを想定していた。今回のように夜間バッチが初期段階で異常終了する場合については想定していなかった(11)。

 本来は、初期段階で障害が発生した場合の対応を、想定しておくべきだった。障害対応手順の実効性を確認していなかった(12)わけだ。このため、再実行に膨大な時間と作業量が必要になっただけでなく、作業の漏れや運用操作ミスが多発した(13)。

 こうした運用手順の不備を事前に見つけられなかった背景には、システム監査が不十分であったことがある。

 みずほ銀はSTEPSを含む「預金・為替システム群」のシステム運用リスクについて、最高レベルではなく、それよりも一段階低く見積もっていた(14)。本来であればリスクを最高とすべき領域であるにもかかわらずだ。

携帯送金で再び上限オーバー

 15日の午前10時25分に営業店端末を使った取引ができるようになると、営業店では従業員が端末を使って1件ずつ、未送信為替の送信を始めた。顧客企業における資金決済の不渡りなどを防ぐためだ。ところがみずほ銀はその後、営業店が送信した為替も含めて、バッチ処理で為替データを一括送信した。営業店とIT・システム統括部の連携不足によって、二重振り込みが多発した(15)。

 15日午後3時過ぎ、前日に続いて再び、義援金の振り込みが急増した。携帯電話事業者が携帯電話を使った振り込みサービスによる義援金を呼びかけたためだった。

 実は、この携帯電話事業者は14日、義援金口座(以下、口座b)に大量の振り込みが集まるとの見通しをみずほ銀の担当部門に知らせていた。しかし、この連絡は、みずほ銀のIT・システム統括部には伝わらなかった(16)。担当部門がシステム子会社であるみずほ情報総研の担当者にしか連絡せず、同社の担当者もみずほ銀のIT・システム統括部に連絡しなかったからだ。

 その結果、勘定系システムのSTEPSで再び、夜間バッチの上限値オーバーが発生した。16日午前7時17分に夜間バッチが異常終了したのだ。同様のトラブルによって、システムが2日連続で異常終了した(17)わけだ。異常終了の発生時刻が夜間バッチにしては遅いのは、前日分の再処理を優先していたからだとみられる。

 2日連続で上限値オーバーが起こった根本的な原因は、みずほ銀がシステムを取り巻く外部環境の変化やサービスの拡充に合わせて、システムを見直してこなかったことにある。

設定を23年間見直さず

 みずほ銀のSTEPSは1988年に稼働を開始した。当時は、ATMの24時間稼働も、インターネットバンキングも、携帯電話を用いた振り込みサービスも存在しなかった。その後、これらのサービスを追加する一方、みずほ銀はバッチ処理の上限値の設定を、23年間一度も見直さなかった(18)。

 さらに、携帯電話での振り込みといった新サービスを導入する際に、夜間バッチの負荷テストを行っていなかった(19)。

 みずほフィナンシャルグループなどによるシステムに関する内部・外部監査が機能していなかった(20)ため、こうした問題に気付くこともなかった。みずほ銀はシステム監査において、「システム運用管理体制」のリスクを最高レベルとしていない(21)など、リスクの大きさを正しく把握することができていなかった。

 夜間バッチが異常終了した原因は、口座bの振り込みデータを振り分ける(分割する)処理で、上限値をオーバーしたためだった。ところが、みずほ銀のシステム担当者は夜間バッチのエラーメッセージを読み誤った(22)。振り分け処理の上限値オーバーであったにもかかわらず、前日と同様に、明細退避処理でエラーが起こったと判断してしまった。

 みずほ銀のシステム担当者は16日午後7時20分から翌17日午前4時13分までの間に、明細退避処理の上限値を拡大するなどして、夜間バッチを再実行した。もちろん、それでは振り分け処理のエラーは解消しない。

 その後、原因が口座bの振り分け処理にあることを突きとめ、一時的に口座bのデータを除外した上で、夜間バッチを再実行した。その結果、17日午前5時20分に口座bのデータを除く15日分の夜間バッチを完了した。

操作ミスでデータ誤削除

 続いて口座bの処理を進めるにあたって、新たなミスが発生した。17日午後1時30分、夜間バッチの手動化によって未処理になっていた、不要データの削除処理を手動で実行した。ここで操作ミスがあり、必要なデータまで削除してしまった(23)。みずほ銀がデータ喪失に気付いたのは、削除から9時間後の午後10時26分だった。そこから喪失データの特定に5時間、データの再作成に11時間を要した(24)。そのため、口座bを含めた15日分の夜間バッチの完了は、さらに遅れた。

ついにATMが全面停止

 システム障害はついに、ATMの全面停止にまで広がった。

 16日午前8時から午前8時33分まで、ATMが停止した。24時間稼働でない店舗などのATMを起動する際に欠かせない、朝の日付切り替え処理を失念した(25)のが原因である。通常時は午前8時までに、自動処理によって切り替えを実行していたが、この時点でTARGETが使えなくなっていたので、手動で実行する必要があった。その作業指示が漏れた。

 翌17日の午前0時、ATMは再び停止した。午前0時に実行すべきオンラインの日替わり処理を忘れていたため、ATMの日付不整合が発生した。日付不整合によって、午前0時以降にATMを使用した700件の顧客の取引が成立しなくなった。対応に手こずり、ATMが復旧したのは17日午前5時20分だった。

 17日午後5時20分にも、ATMが停止した。STEPSが異常終了し、すべてのATMで取引ができなくなった。原因は取引履歴(ログ)ファイルの退避を忘れた(26)ことである。

 STEPSは取引発生のつど、取引履歴をファイルに蓄積する。ファイルの容量が一定以上になると、ログファイルを自動的に退避する。ところが、運用を手動に切り替えていたにもかかわらず、退避操作を忘れた結果、ログファイルの容量超過によってSTEPSが異常終了した(27)。みずほ銀はログファイルを手動で退避し、午後9時36分にATMの動作を再開させた。

オンラインとバッチを並行処理

 夜間バッチの遅れが解消されず、さらにATMの全面ダウンも引き起こしたことから、みずほ銀は18日、抜本的な障害対応に乗り出すことを決めた。障害対応にシステムのリソースを集中するため、18日から22日にかけて、店舗外ATMやインターネットバンキングなどの停止を決めた()。さらに3連休の間はすべてのATMを止めることにした。

図●みずほ銀行のシステム構成と、トラブルが波及した箇所
[画像のクリックで拡大表示]

 18日午後1時30分、みずほ銀本店ビル22階に、障害対策チームのオペレーションルームを設けた。そこに、みずほ銀のIT・システム統括部とシステム運用部、みずほ情報総研、システム運用を担うみずほオペレーションサービスの担当者が集まった。障害発生から5日後にようやく、3社の障害対策チームが一本化した(28)。

 これに前後して、手動で行っていた夜間バッチを効率化するため、TARGETを改良し、処理を自動化できるようにもした。

 18日からの巻き返しによって、19日午後7時5分に15日分の夜間バッチが完了した。それでも夜間バッチの遅延は依然深刻で、22日朝までに夜間バッチを解消できない恐れが高まった。そこで21日にはSTEPSを改良して、昼間のオンラインと夜間バッチを並行処理する準備を進めた。

 TARGETやSTEPSの改良といったシステム上の手当が遅れたのは、システムの基本構造や処理方式などを熟知するシステム要員が決定的に不足していた(29)のと、みずほ情報総研などの子会社で、銀行実務を知る要員が減少していたためである。

 22日からは、昼間のオンライン中に、21日分までの夜間バッチも並行処理し始めた。これが奏功し、22日分の夜間バッチから、通常の自動運行が回復した。すべての遅れが解消したのは24日、トラブル発生から10日後のことだ。

 みずほ銀が設置した「システム障害特別調査委員会」が5月20日に発表した「調査報告書」を読み解くと、経営陣のシステム障害に対する判断が後手に回っていたことが分かる。

後手に回った経営判断

 例えば、夜間バッチの異常終了が2日続いた翌日の16日午前6時に、萩原常務執行役員は西堀頭取に「前日に続き営業開始が遅れるが、それでも一部の重要な夜間バッチを優先して完了させたい」と報告している。西堀頭取はこれを了承した。

 だが、営業開始を数時間遅らせただけでは、事態は改善しなかった。ここでオンラインを1日止める決断を下し、トラブルの根本的な解決に乗り出せば、その後の被害を抑えられた可能性がある。

 16日午後9時には、西堀頭取は翌17日の営業方針について、夜間バッチの解消を優先するのではなく、営業店端末の開始を優先するよう指示している。夜間バッチが週内に解消できない場合は、19日からの三連休で解消するようにとの方針も示した。

 バッチ処理について、異常が起きた部分だけを取り除き、他の処理は自動で進められる仕組みがあれば、これは正しい判断である。だが、みずほ銀にはそうした仕組みがないことは、16日午後9時の時点では知り得たはずである。そう考えると、この判断についても適切であるとは言いがたい。

 ATMが全面停止した17日の午後11時には、西堀頭取は18日と19日からの三連休の合計4日間、ATMなどのサービスの利用を制限することを指示した。この決断が、システム障害を収束の方向に向かわせた。であればこそ、もう少し早く決めていればと悔やまれる。システム障害特別調査委員会は報告書で、障害時に陣頭指揮を執るマネジメント人材が不足していた(30)と厳しく指摘している。

出典:日経コンピュータ 2011年6月9日号 pp.20-25
(記事は執筆時の情報に基づいており、現在では異なる場合があります)