みずほ銀行において、システム障害の発生を最小化するための提案[*11]
みずほ銀行が、2021年2月28日から3月12日にかけて起こした、システム障害(以下、2021年春障害)に関する調査報告書(以下、本件報告書)は、同年6月15日に公表された。公表後3ヶ月経過しても、再発防止策を探る目的で書かれた論考が、Web上で見当たらなかったため、拙文をしたためた。
本件報告書が扱うシステム障害は、2月28日、3月3日、3月7日、3月12日に発生した4件である。当該4件を顧客に与えた影響の大きさ順に、個別に論じる。順番は、【1】2月28日→【2】3月12日→【3】3月7日→【4】3月3日である。
なお、みずほフィナンシャルグループは、8月20日(業務チャネル統合基盤のデータベース・サーバーのハードウエア故障により、店舗窓口取引に支障発生)、8月23日(東京や神奈川、大阪などでATMが一時利用停止)、9月8日(ATMとインターネットバンキングが一時利用停止)、9月30日(マネーロンダリング対策実施せず)、12月30日(他行への振込障害)、2022年1月11日(法人向けインターネットバンキングの不具合)、2月11日(ATM障害)にもシステム障害を起こしている。
【0】本件報告書の評価
本件報告書の評価は、高いとは言えない。本件報告書は、東日本大震災義援金を処理しきれずに起きたシステム障害(以下、2011年障害)を117及び119-121頁で扱っている。しかし2011年障害と2021年春障害の類似性を対比し、明示していない。評価が高くないのは、そのためである。拙文で実施したこの対比作業(【5】を参照)は、みずほ銀行が、同じ過ちを繰り返したことを明らかにしてくれる。そして運用管理者の力量が、如何に不足しているかを明らかにしてくれる。問題の所在を明確にしなければ、対策の実効性は期待できない。
【1】2月28日に発生した障害(以下、28障害)
28障害の概要は、以下の通りである。①e-口座一括切替処理において、諸般の理由により処理ボリュームが膨大となり、定期性預金システムにおける取消情報管理テーブルのインデックスファイル使用率が100％になった。このため、②テーブル更新ができなくなり、定期性預金取引の更新取引が不可になった。その影響で、③定期性預金システムにアクセスする更新取引が全て不可になった。そのため、④CIF(顧客を特定する記号番号)排他状態が発生した。⑤CIF排他状態が生じたため、定期性預金システムにアクセスしない更新取引を含めて、全ての更新取引ができなくなった。⑥全ての更新取引ができないため、元帳不整合懸念のあるエラーが大規模に発生した状態となった。⑦元帳不整合懸念のあるエラーが発生した場合は、通帳・カードがATMに取り込まれる仕様であったため、多くの顧客の通帳・カードがATMに取り込まれた。
MINORIはSOA(サービス指向アーキテクチャ)の思想を取り入れて開発されたシステムで、連鎖障害の影響範囲拡大回避を一つの目標としていたが、事象的には目標を達成したとは言えない。
上述の通り、通帳とカードをATMが取り込んでしまい、多くの顧客をATM前で何時間も待たせるという事態を招いてしまった28障害での考察ポイントは、A．発生原因の特定及び、将来の発生最小化、B．拡大原因の特定及び、将来の発生最小化、である。
本件報告書を読む限りにおいて、28障害を発生・拡大させた主因は、システム運用管理の守備範囲に属する。より直截的に言うならば、運用管理者の力量不足が、障害を発生させ・拡大させた。したがって、将来の障害発生・拡大を最小化するには、運用管理のプロを外部から導入することが、本質的に重要と思われる。みずほ銀行が採用し、運用管理者であるみずほリサーチ＆テクノロジー(MHRT)に出向するという形態で、ビジネス実装すれば良いだろう。また、金融庁をレポーティングラインに加えるという策は、検討に値する。この具体的なイメージは、後述する。
もちろん、それはプロの運用管理人材を導入すれば、全ての問題が解決するという意味ではない。そこを起点にすべきという提案である。適切な起点をつくり、突破口を開かなければ、巨大で複雑な問題は解決しない。
もちろん、運用管理に根差す原因以外にも、システムの仕様、及びシステム設計に根差す原因が、28障害を発生させている。それぞれについて考察する。
(1) 運用管理に根差す原因
運用管理に根差す原因は2つあると考えられる。本件報告書で明らかにされている通り、28障害のトリガーは、「e-口座一括切替処理の最中に、定期性預金システムにおける取消情報管理テーブルのインデックスファイル使用率が100％を超えてしまった」ことである。インデックスファイル使用率の警戒値として、設定されていた80％を超えたために送信されたアラートは、運用管理者であるMHRT ITインフラ第一部に無視されてしまった[*1]。そのため、状況はみずほ銀行やMHRTの関係各部に共有されず、対応がとられることもなかった。これが運用管理に根差す原因①である。ここで、運用管理者が、迅速かつ適切な対応をしていれば、そもそも障害は発生しなかった。
無視してしまった理由の一つは、インデックスファイル使用率が100％を超えたら、どんな事態が発生するかを運用管理者が理解していなかったからであろう。そして、理解していなかった理由の一つは、途中で「取消情報管理テーブルのインデックスファイルがメモリ領域に常駐する仕組み(メモリ常駐)」に、仕様が変更されたからである。なお、これは運用管理の守備範囲ではないが、行内ルールに反して、メモリ常駐の仕様変更は、定期性預金システムに関する基本設計書(物理テーブル一覧)に記載されていなかった。
本件報告書では、開発部隊(MHRT開発本部第一事業部第一部)と運用管理者との間で、十分な情報連携が行われなかったことを指摘しているが、その一方で、運用管理者は「メモリ常駐の事実自体は認識していた」と記述されている。システム企画段階や開発初期の段階、あるいは仕様変更が行われる場において、運用管理者は、積極的かつ能動的に参加して、仕様変更を運用管理のオペレーションに反映させるイメージを醸成することが望ましいとされている。本件では、メモリ常駐の影響を見定めるために、しつこくヒアリングをかけるという一手間が要求されるだろう。それを可能たらしめる、外部のプロ人材を導入する必要があると考えられる。また、運用管理者が必要な分だけヒアリングをかけることを可能にするには、運用管理者が金融庁に直接レポーティングすることは、有効と考えられる。なお、本件報告書の再発防止策には、広い視野を持つ専門人材の外部登用があげられているが、その記述内容では曖昧で実効性に乏しい。
運用管理に根差す原因②は、取引サービス禁止機能に係る作動条件の緩和である。MINORIは、同一の取引サービスで1系統30回エラーが発生すると当該取引を禁止する仕様となっていた。担当者[*2]は、この30回という設定を999回に緩和してしまった。そのせいで、パーコレートエラーの頻度が高まり、ATM処理区画閉塞が促進され、顧客被害が拡大した。作動条件の緩和を行わなければ、被害が拡大することはなかったであろう。
999回への緩和には、薄弱ながらも根拠はあった。それは、「過去にも取引サービス禁止機能の作動条件を緩和することで、障害が収まった。」という成功体験である。しかし、それは、時間を稼げば障害が(自然に)収まってくれるだろうという、現実逃避の発想であり、プロの発想ではない。力量不足は明らかで、外部のプロ人材導入は不可避である[*3]。
(2)仕様に根差す原因
システム仕様に根差す原因も、2つある。①元帳不整合懸念のあるエラーが発生した場合、通帳とカードがATMが取り込まれる仕様であったこと。②パーコレートエラーが累計5回発生すると、処理区画が閉塞される仕様であった。そしてATM処理区画閉塞が、通帳とカードをATMが取り込むトリガーになる仕様であったこと。
①に関する本質的な問題は、「MINORI稼働後、過去3回にわたり、通帳とカードがATMが取り込まれる障害が生じていた。つまり、仕様変更の機会があったにもかかわらず、変更を見送っている。」ということである。本件報告書の再発防止策によれば、ようやく原則として、通帳とカードを返却する仕様に改修した(MINORIの先代システムであるSTEPSでも、取り込む仕様ではない)。これは、本質的には、(法人顧客ではなく)個人顧客軽視の組織文化が生み出したと言える。
②は実現容易性が微妙であるものの、パーコレートエラーの累積は、処理区画閉塞よりも、障害元であるシステムを切り離すという仕様であることが望ましかったと思われる。そうであれば、顧客が被った被害は拡大しなかったであろう。
障害発生時に、通帳やカードを取り込むのではなく、取引を停止した上で、返却するという仕様であれば、28障害において大きな批判を浴びた「顧客を長時間待たせた」という事態は避けられた可能性が高い。しかし、システム障害の発生最小化を主眼とするならば、28障害は、みずほ銀行において頻発するシステム障害の一つと捉えるべきである。そして、その場合、28障害の"主因"は、仕様ではなく、運用管理の守備範囲に帰属すると認識すべきと考える。
(3)設計に根差す問題
パーコレートエラーという本件報告書に頻出する用語の定義は、本件報告書にはない。IBMのサイトを見る限りにおいて、パーコレートとは「エラー処理・例外処理のために、別の処理プログラム(モジュール)に、処理タスクを移管する」ことを意味しているようである。そこで、パーコレートエラーとは「パーコレートが行えず、処理タスクが『たらい回し若しくは、宙ぶらりん』になっている状態」と推測できる。
本件では、次のようなエラーフローが発生した：①定期性預金システムにおける取消情報管理テーブルのインデックスファイル使用率が100％を超えた。そのため、②テーブル更新ができなくなり、定期性預金の更新取引ができなくなった。しかし、③更新取引ができなくなり、更新取引エラーが発生した一方で、エラー内容が「元帳の整合状態不明」だったため、自動取消が実行された。さらに、④取消対象となる更新取引が、テーブルに存在しなかったため、自動取消ができす、自動取消エラーが発生した。
つまり、更新取引エラーの処理である自動取消処理もエラーを起こして(二重エラーの発生)、パーコレートできなくなった＝受け入れてくれる処理プログラムがなくなった。前述の通り、MINORIは、パーコレートエラーの累計が5回に達すると、処理区画が閉塞される仕様となっていた。設計思想としてフェイルセーフを標榜するならばを、パーコレートエラーに該当する状況が発生した場合、全ての例外処理タスクを安定吸収する処理モジュールを用意しておくことが望ましいと思われる。
なお本件報告書には、「パーコレートエラーと判断する機能を有するミドルウェアの詳細な動作は省略する。」と書かれている。
(4)他の問題
組織や文化、現場オペレーションの問題も存在しているが、それらについては、ここで論じない。それは、システムにおける根本的な問題を解決すれば事足りると考えているからではない。以下のような理由からである。
先述の通り、適切な起点をつくり、突破口を開かなければ、巨大で複雑な問題は解決しない。組織や文化、現場オペレーションに対する方策は、ややもすると情緒的で即効性がない方策になり、突破口を開く適切な起点とはなり難い。適切な起点とならない方策まで含めると、対応は、日本の組織が好む総花的なものとなる。優先順位が曖昧になり、対策全体の実効性が大きく減じてしまう。
【2】3月12日に発生した障害(以下、12障害)
12障害の概要は、以下の通りである。MINORI共通基盤Bに在するストレージ装置内の通信制御装置が故障した。この装置故障により、ストレージとサーバの接続が切断され、当該サーバ上で稼働していた統合ファイル授受システム等が停止した。基盤の異なるシステム間でファイルを受け渡すための、統合ファイル授受システムの停止は、外為システムにも障害を及ぼした。外為システムの障害により、集記依頼データ送信が実行できず、(1)外為被仕向送金の入金案内処理の遅延及び、(2)国内他行向け仕向送金の入金案内処理の遅延、が発生した。
12障害での考察ポイントは、システムの復旧作業が遅れた原因の特定及び、再発防止策である。作業遅れの主因は、以下に示す詳細な過程で明らかなように、システム運用管理者の力量が不足していたためである。そして、再発防止策は、プロ運用管理人材の外部導入と考えられる。ビジネス実装等については、28障害と同じである。
(1) 外為被仕向送金の入金案内処理の遅延
当該遅延の復旧作業は遅れたわけだが、その詳しい過程は以下の通りであった。
①システム運用管理担当者[*4]は、根拠なく、統合ファイル授受システムが、(他システムにファイルを受け渡す)時間までには、復旧すると想定した。
②しかし統合ファイル授受システムは復旧しなかった。このため、外為システムでは、システム上誤った処理が実行された。
③誤った処理が実行されたため、「誤った処理が実行された場合の復旧手続き」を行う必要があったが、該当する手続きは実行されなかった。
④不適切な復旧手続きが実行されたため、統合ファイル授受システム復旧後に「ちぐはぐな」処理[*5]が実行された。
⑤ちぐはぐな処理が実行されたため、外為システムで取引エラーが発生した。
⑥外為システム取引エラーを分析して、③に遡り、「誤った処理が実行された場合の復旧手続き」を行った。
このような経緯で、復旧が遅れた。
上記過程の肝を③と捉えると、正解行動のハードルは高く感じる。誤った処理の実行検知は難しいと想像できるからである。しかし、肝は①であると考えると、ハードルを高くは感じないだろう。そして、実際肝は、①と考えられる。統合ファイル授受システムが、a)特定の時間まで復旧するシナリオと、b)普及しないシナリオで、復旧作業の違いを認識して、準備しさえすれば事足りたはずである。
(2) 国内他行向け仕向送金の入金案内処理の遅延
当該遅延の復旧作業は遅れたが、その詳しい過程は以下の通りである。
①システム運用管理担当者[*6]は、根拠なく、統合ファイル授受システムが、(他システムにファイルを受け渡す)時間までには、復旧すると想定した。
②しかし統合ファイル授受システムは復旧しなかった。送信対象である、集記依頼データ存在せず、データ送信が異常終了した。
③「外為被仕向送金の入金案内処理の遅延」に手間取ったため、運用管理担当者は、集記依頼データ送信の異常終了を検知していなかった[*6]。
④しかも、(送金処理に係るステータス確認を実施していないことからも推認されるが)送金処理は、順次適切に実行されるはずだと誤認した。
⑤結果、集記依頼データの再送信は行わなかったため、送金処理未了のまま、ステータスは、処理実行済になっていた。
⑥さらに、送金処理未了を他部署から通知されるも、運用管理担当者は、これを無視した[*7]。
⑦再度通知されて、ようやく送金処理未了を認識し、集記依頼データを再送信した。
このような経緯で、復旧が遅れた。
国内他行向け仕向送金も外為被仕向送金と同じ、障害発生の主因は①である。運用管理者の力量が不足していると考えられる。
(3)システム設計において修正が必要と思われる箇所
先にあげた「ちぐはぐ」な処理は、接続された2つのモジュールAとB内で、データに対する条件が異なるために発生している。比喩的には、Aではデータを受け入れるが、Bでは受け入れない場合が存在するため、異常終了を惹起する。これはシステム設計で対処できる問題であり、この設計思想がMINORIの脆弱性の一つかも知れない。
【3】3月7日に発生した障害(以下、07障害)
07障害の概要は、以下の通りである。貸越明細テーブル更新[*8]に伴い、総合口座定期預金システムの初期化が必要となった。しかし、プログラムに初期化処理の組込み漏れがあったため、結果的に、システムにバグを作ってしまった。新たに作られたシステムのバグのため総合口座定期入金にかかる集中記帳処理時にエラーが発生した。このエラーのため、定期預金入金取引が成立しなかった。
07障害の考察ポイントは、発生原因の特定と再発防止である。発生原因は、プログラムの設計ミスであり、設計担当者の認識に誤りがあったことにある。再発防止策は、適切なテスト設計をすることであり、運用管理のスキルアップは結果的に、これに資することとなる。
なお、07障害対象者の6割強(15/24)は、みずほ銀行の関係者らしい[*12]。
【4】3月3日に発生した障害(以下、03障害)
03障害の概要は、以下の通りである。データセンターにて、ネットワーク機器内のネットワークカードが故障して、ATMとMINORIの通信ができなくなった。ATMは通信エラーを認識し、通帳とカードの取り込みが発生した。ちなみに、不幸なことに、ネットワークカードの故障は、カードが完全に壊れたものではなかった。このため、断続的に接続が発生し、別ネットワークカードへの切替に時間(3分)を要した。切替に時間を要してATMに通信エラーと認識されなければ[*9]、別のネットワークカードに問題なく切り替えられ、障害は発生しなかったと考えられている。
03障害の考察ポイントは、再発防止である。再発防止策は、通信障害の発生を、通帳とカードの取り込み要件とする仕様の変更である。
【5】2011年障害と2021年春障害が、類似していること及び、再発防止策が機能しなかったことについて[*10]
2011年障害が起きたときのシステムは、MINORIの先代にあたるSTEPSである。
(1)28障害との類似性
① 2011年障害は、処理件数の上限値をオーバーしたために、東日本大震災義援金の振込口座に対する一括処理が異常終了した、というシステム障害である。これが最終的に、ATM障害に繋がった。またログ容量超過によっても勘定系が全面停止している。
28障害は、定期性預金システムにおける取消情報管理テーブルのインデックスファイル使用率が上限値をオーバーしたために、e-口座一括処理が異常終了した、というシステム障害である。これが最終的に、ATM障害に繋がった。
② 2011年障害では、運用管理者は、一括処理の処理件数に上限値があることを知らなかったため、障害の発生を予見できなかった。
28障害では、運用管理者は、インデックスファイル使用率に上限値があることは知っていたが、厳密なキャパシティ管理が必要であることまでは認識していなかった。そのため、どのような障害を発生させるかについては、予見できなかった。実際、エラーメッセージを無視している。
③ 2011年障害の発生時は、前日夜間の一括処理による送信準備を全て完了しないと、翌日の全ての振込が送信できない仕組みになっていた。そのため、義援金振込口座とは無関係な振り込みについても、送信できなくなるが、それは認識されていなかった。
28障害は、定期性預金の更新取引が不可になると、他預金の更新取引も不可になることを認識していなかった。
④ 2011年障害では、異常終了した場合の実行手順をマニュアルに記載していなかった。
28障害では、インデックスファイル使用率に上限値を課すことになるメモリ常駐について、基本設計書(物理テーブル一覧)に記載されていなかった。
⑤ 2011年障害では、義援金受付に際し、処理件数が膨大になることが予想されたにも関わらず、運用管理者(当時のみずほ情報総研)はシステム全体の処理能力をチェックしなかった。そして、義援金受付にあたり事前に負荷テストを実施していなかった。さらに、負荷テストを実施していないことに、誰も気づかなかった。
28障害では、e-口座一括処理で膨大なトランザクションが発生することが予想されたにも関わらず、そしてメモリ常駐に仕様変更したために、確認が必須となるメモリ容量に関する影響調査は行われなかった。容量面での確認を行わないまま、テスト工程は全て完了して品質に問題なく、e-口座一括処理にて性能評価を実施済で、リスク軽減対策も済んでいる、とした。その結果、e-口座一括処理の対象口座数での実機テストは実施されなかった。また、システムを相互に連結した状態での多様な障害回復テストも不十分であった。
⑥ 2011年障害発生前に、システム障害の実例をもとに作成され、金融庁や日本銀行が公表していた検査マニュアルや論文等に、2011年障害とよく似た事例が掲載されていた。にも関わらず、そういった情報を活用した形跡はなかった。
28障害発生前に、通帳・カード取込み事例は、金融庁の「金融機関のシステム障害に関する分析レポート」(2020年6月公表)において紹介されていた。つまり、通帳・カード取込みにより顧客影響が発生するケースがあることについて、監督当局の問題意識が提示されていた。にも関わらず、自行のATM仕様を見直すことはなかった。
(2)12障害との類似性
2011年障害では、異常終了した場合の再実行に必要な、異常終了時のシナリオを準備していなかったため、即興で異常終了時のシナリオを作り実行した。
12障害では、異常終了時のシナリオはあったが、異常終了を検知できずに、正常終了時のシナリオを実行した。
これはピンとこない記述かもしれないが、言いたいことは、以下の通りである。10年前に同じようなこと＝異常終了につき再実行、が起きたのだから、類似性を想起すべきではないかということである。
(3) 再発防止策が機能しなかったこと
2011年障害の再発防止策では、①データフロー図を作成し、仕様追加などに際しても適宜アップデートすることで、障害の発生を予防する。②エラー処理を強化する。が実施されたはずである。策としては、どちらも真っ当であるが、MINORIには承継されなかったと思われる。防止策が正しく承継されていれば、2021年春障害の影響は、もっと小さかったはずである。
【6】本件報告書に関して、些細なこと
(1) 読み手を混乱させる記述
本件報告書65頁に、「急激な容量の使用量増加を考慮したメモリ使用率のしきい値の設定、及び常時監視が必要であった。」との記述がある。実際は、定期性預金システムにおける取消情報管理テーブルのインデックスファイル使用率に、しきい値80％が設定されており、それを示すシステムログが確認されている(本件報告書50頁)。読み手を混乱させる可能性がある。
(2) パーコレートエラーの定義が本件報告書にない
既に記述しているが、本件報告書には、パーコレートエラーの定義がない。重要な用語なので、読み手のことを考えれば、定義は必要だと思われる。
(3) 順番が変えた方が読みやすい
12障害において、国内他行向け仕向送金の入金案内処理の遅延は、「外為被仕向送金の入金案内処理の遅延に手間取り」、「集記依頼データ送信の異常終了を検知していなかった」ことが原因の一つである。したがって、国内他行向け仕向送金について記述したセクションは、外為被仕向送金セクションの後である方が、読み手には読みやすいと思われる。
(4) 表記がピンとこないこと
最上位の該当する章立ての表記が、第1、第2、第3・・・である。これは弁護士ローカルなのかもしれないが、一般には見慣れない表記である。読み手の読みやすさを考慮すれば、他の表記を検討するべきと思われる。
【尾 注】
*1 本件報告書によれば、データセンターの監視を行っているMIDSから連絡を受けたみずほリサーチ＆テクノロジー(MHRT)は、障害対応として、原因調査・影響調査・原因分析等の必要な対応を行う。併せて、みずほ銀行に対して、状況及び調査・分析結果を報告し、復旧対応策を提案する。みずほ銀行は、復旧対応策を承認し、実施の指示を出す。
インデックスファイル使用率の警戒値として、設定されていた80％を超えたために送信されたアラートを無視した(本件報告書の正確な記述は、見逃していた。又は、確認はしたものの、対応の必要があることの認識をしていなかった)のは、MHRTの ITインフラ第一部である。
*2 取引サービス禁止機能に係る作動条件の緩和を指示したのは、みずほ銀行のIT・システム統括第一部である。
*3 運用管理者の力量不足を示す傍証としては、以下もあげられる：(1)取引サービス禁止機能作動条件の緩和を行う一方で、メニュー抑制(ATM画面上の取引メニューから定期性預金に関するメニューを削除すること)や定期性預金システムの切り離しを行っており、障害復旧対応に一貫性がない。(2)MIDSからMHRTに、エラーメッセージが電話で口頭伝達されたが、伝達時刻やメッセージの種類・内容につき、両者に認識齟齬がある。MIDS側は管理表に記載がなく、MHRT側にも記録やメモが残っていない。メール等で文書伝達された形跡もない。
*4 当場面の担当者は、MHRT第一事業部第二部である。
*5 外為システムを構成するモジュールの一つである「残高確定等」は、ある時点で受信済のデータで自動実行される。一方、別の構成モジュールである「外決接続トリガー」は、データ受領が実行条件となり、データ未受領であると処理は実行されない。12障害のケースでは、残高確定等がデータ未受領の状態で時限実行され、外決接続トリガーは実行されていない。正しくは、「残高確定等はデータ未受領の状態で時限実行された」として復旧作業すべきであったが、実際は「残高確定等はデータ受領の状態で正しく実行された」と誤認して、復旧作業を行った。このため、残高確定されていない状態で、外為システムと外決システムが接続され、取引エラーが発生した。
*6 当場面の担当者は、MHRT第一事業部第二部である。
*7 当場面の担当者は、みずほ銀行のIT・システム統括第一部である。
*8 みずほ銀行では、カードローンの支払延滞者に対して、規定通りに、遅延損害金利率を適用することになった。このため、遅延損害金利率の適用要否を判別するための、延滞フラグを貸越明細テーブルに追加することとなっていた。
*9 タイムアウトは1分に設定されていた。
*10 日経コンピュータ(山端・岡部・中田・大和田・谷島)、みずほ銀行システム統合、苦闘の19年史 史上最大のITプロジェクト「3度目の正直」、日経BP、2020
*11 2021年9月21日付け日経新聞朝刊の1面に、「金融庁がみずほ銀行のシステムを管理する」という趣旨の記事が掲載された。本質的な主張は、拙文と同じである。
*12 日経コンピュータ、ポストモーテム、みずほ銀行システム障害事後検証報告、日経BP、2022