※ニートが興味をもった部分を紹介します。
はじめに
米国のIT企業はシステム障害が発生した後の事後検証報告書をポストモーテム（Postmortem）と呼びます。
情報システムは人が開発し運用するものです。ソフト、ハードの故障やオペレーションのミスは避けられません。
みずほ銀行が起こした合計11回のシステム障害について、原因や背景を検証し、対策や教訓などを考えてみましょう。
目次
書籍情報
タイトル
ポストモーテム
みずほ銀行システム障害事後検証報告
著者
日経コンピュータ
出版
日経BP
1年間で11回のシステム障害
みずほ銀行が2021年2月から2022年2月までの間に、合計11回システム障害起こしています。いずれも勘定系システム「MINORI」とその周辺システムによるものです。
みずほ銀行の勘定系システムMINORIは、富士通、日立製作所、日本IBM、ＮTTデータの4社によるマルチベンダー体制で開発されました。4社でのマルチベンダー体制はみずほ銀行だけです。
MINORIは、麺フレームとUNIXサーバー、Linuxサーバーが混在するシステムアーキテクチャーを採用しています。これがシステム障害の原因になったという証拠はみつかっていません。
| 発生日 | 障害箇所 |
|---|---|
| 2021年2月28日 | 定期性預金、取引共通基盤、CIF、ATM、みずほダイレクト |
| 2021年3月3日 | サブデータセンターにあるネットワーク機器 |
| 2021年3月7日 | 流動性預金、定期性預金 |
| 2021年3月12日 | 統合ファイル授受 |
| 2021年8月20日 | 業務チャンネル統合基盤 |
| 2021年8月23日 | メインデータセンターにあるネットワーク機器 |
| 2021年9月8日 | 取引共通基盤 |
| 2021年9月30日 | 統合決済管理システム |
| 2021年12月30日 | 国内為替システム |
| 2022年1月11日 | みずほダイレクト |
| 2022年2月11日 | ネットワーク機器 |
MINORIの移行リハーサルを2018年にして、ATMの1821件起こしていたが、公表せず改善策が必要と認識していませんでした。
通帳を発行しない「みずほe-口座」の取引開始に向けて一部機能を改善することになりました。そのときに、印紙税の納付額を削減するために無理なスケジュールでデータ移行計画を策定しています。
e-口座への一括切り替え処理の間のエラー監視をする体制が整っていなかったことも原因にあげられています。
e-口座への切り替え処理が始まって、インデックスファイルの使用率が許容範囲を超えて、アラートを出していたが、見逃してしまいました。
このような細かい要因が重なり、11回のシステム障害を起こしたのです。
なぜエラーは見逃されたのか
みずほリサーチ＆テクノロジーズ（MHRT）やMIデジタルサービス（MIDS）が実務を担当していました。
通常時のエラー監視の実務はMIDSが担い、e-口座への一括切り替え処理はMHRTが監視を行っていたのです。
実際にはMHRTはエラー監視ができる体制を構築できていませんでした。
24時間365日常駐する体制ではなく、休日などにシステム障害が起きた時に事務所に駆けつける必要があったのです。
なぜ営業店での顧客対応が遅れたのか
営業店での顧客対応が遅れ、ATMに通帳・カードを取り込まれた4000人以上が何時間も立ち往生してしまいました。
カードの大量取り込みを最初に検知したのは、みずほ銀行が外部に委託している「ATMセンター」です。ATMセンターの副所長は10時15分、ATMのエラーが430件発生しているとの「緊急一報メール」を送信しました。
MHRTが対応できてなかったとはいえ、他の部署も緊急メールを受信していたはずなのです。
その他の部署が顧客に適切に対応できていれば、顧客の苦痛は和らげられたはずでしょう。
銀行統合に伴うシステム障害は他行でも起きた
2002年1月15日に三和銀行と東海銀行が統合したUFJ銀行で、「口座振替システム」の不具合が起きていた。
夜間に自動集計するバッチ（プログラム）処理が遅延し、朝の業務開始時間までに間に合わなくなったことが原因です。
翌日の引き落としデータなどの次々と遅延し、最終的には175万件の引き落とし処理が遅れる結果になりました。
英国の大手銀行であるロイヤル・バンク・オブ・スコットランド（RBS）や傘下銀行で、2012年6月に発生した大規模システム障害が起きました。
勘定系システムの夜間バッチ処理が同日朝までに完了せず、翌日以降のオンライン処理が停止しました。顧客による入出金処理が全面的にできなくなったのです。
みずほ銀行が他の金融機関と比べて特殊なのは、過去20年間にわたって大規模なシステム障害を繰り返しているという点です。
みずほ銀行以外のメガバンクにおいて、市捨て宇障害によって何千、何万人もの顧客が迷惑を被ったり、経営に打撃を与えるような事態は発生していません。
他バングのシステム障害の対策
各社がシステム障害のインパクトを極小化する「ダメージコントロール」に気を配り、顧客にシステム障害の影響が出ないよう努力しているのです。
高可用性が求められるシステムについては、年に1回必ずシステム障害を想定した訓練を実行しています。
開発・テスト機を使って実際に稼働系かた待機系に切り替えてみるといった実践的な訓練を行っているのです。
他のメガバンクにおいてはシステムの統合が2000年代までに終わっていたので、定期的なシステム障害対応訓練を常に見直してきました。かなりの努力を積み重ねている結果が、安定稼働につながっています。
具体的な再発防止策
人員・経費枠の増加、社内のコミュニケーション強化、社員や現場の声の把握、現場要望起点のアプローチを実施を追加しています。
「2021年度に人員160人、経費枠80億円、投資枠100億円の規模で人員・経費を予備的に拡充」
と説明しているのです。
2010年から勘定系システムを日本IBMのメインフレーム上に構築する作業を本格的に始めたときのプロジェクトマネジャーをしていた林氏がシステムグループの副長（副CIO）に就きました。
また、失敗の経験を風化させない「語り継ぎ」にも取り組んでいるといいます。
システムを安定稼働させる仕組みとしてSREの実践を視野にいれています。グーグルが作り出した常に改良し安定稼働させる仕組みづくりは、スタートアップ企業を支えているのです。
みずほ銀行の運用と開発部門が一丸となってSREを実践する、それがみずほ銀行の再生の第一歩になるのではないでしょうか？
購入リンク
紙
amazonは↓
電子
amazonは↓
