「先生大変です！みずほちゃんのATMが次々と通帳やカードを吸い込んでます！」
世間に驚きと笑いをもたらした「みずほちゃんATM暴走事件」から1年。システム障害の原因と対策についてまとめたのが「ポストモーテム みずほ銀行システム障害事後検証報告」です。
ポストモーテムとは検死の意味。そこから事後検討や反省会の意味で使われます。
みずほ銀行ばかりがなぜ重大なシステム障害を繰り返すのか、他のメガバンクとの違いは何なのか、そんな内容を一通り知ることができます。ただ読後の感想としてはみずほ銀行だけが特別というよりは、銀行に限らず大規模なシステムを抱えるあらゆる業界で同じような構造になりつつあるのではないかという危惧を感じました。
【日経CP：ポストモーテム みずほ銀行システム障害事後検証報告】なぜみずほちゃんのATMは5000件を超える通帳やカードを次々に吸い込んだのか。システム障害の原因と対策に迫る本書。思ったのは非常時を想定した訓練は大事だということ。だがセンター切替訓練を毎年実施できているシステムはどれほどか
— Keiya | 強くなりたい (@2R8R9) July 30, 2022
本書の感想
大規模システムMINORIくん
みずほ銀行の勘定系システムはMINORIという名前です。その開発費用はなんと35万人月で4,500億円程度と言われています。この数字ってけいやの感覚からするととてつもなく高いです。開発期間は8年程度らしいので1年あたり35÷8≒4万人月、1ヶ月あたりでは4÷12≒3000人月です。つまり、1ヶ月あたり3000人が8年間動かないと消費できない工数ということになります。
なんかの計算間違いかと思うくらいですが、試しにエンジニア一人あたりのレート（1時間あたりの人件費）を6,000円で計算してみると、
35万人月×20日（1月あたり稼働日）×8時間（1日あたりの稼働時間）×6,000円＝3,360億円
となり、だいたい開発費のオーダーと合っているので実態を表している数字なのかなと思いました（残りの1,140億円はサーバーの購入費用とかその他経費でしょうか。それにしては金額が高すぎるので、実際のエンジニアの平均レートはもっと高いのかもしれません）。
銀行系のシステムってこのくらいの費用がかかるのは普通なのですかね。にわかに信じ難いくらい高いというのが率直な感想です。
MINORIくんの機器更新周期は10年
MINORIくんのサーバーやストレージ機器の更新周期は10年くらいで計画されていたらしいのですが、この周期が長いという指摘がされています。なんでもミッション・クリティカル・システムのITインフラは5年周期で刷新するのが一般的なのだとか。
これを読んだけいやの感想は「GAFAのような利益率10%以上のビジネスならいざ知らず、儲けに四苦八苦しているビジネスは費用抑制のために限界ギリギリまでITインフラを使い倒すのが普通なのでは？」というものでした。
みずほ銀行のシステム障害は、ITインフラのハードウェア故障がきっかけとなった場合も多いので、こういう例が増えるとどの業界も5年に1度とかになるのかもしれません。しかし、そうなるととにかく金がかかります。昨今は半導体不足も深刻なので、そういう面でも心配です。
非常時を想定した訓練は重要
本書を読んでいて一番身につまされる感じがしたのが、みずほ銀行はシステム障害を想定した稼働系から待機系への切り替え訓練を実施していなかったという内容です。そのため、実際にシステム障害に直面した際に、手順がない！手順を作れ！ぶっつけ本番！みたいになって遅々として復旧が進まなかったようです。
しかし、これはみずほ銀行だけが特別にサボっていたという話なのでしょうか？
けいやにはそうは思えず、多くのシステムで障害を想定した訓練までは十分にできていないのではないかと予想します。その理由はお金が無いから。
リスク対策はやればやるほどお金がかかりますが、それをやったからと言って儲かるという話ではないため、なかなか予算を確保できないのが実情なのではないかと。あるいはこれは資本主義と言うか、株式会社の限界なのかとも思えるほどです。良識のある株主が、自分の利益だけを考えずに（あるいは長期的な目線での利益を考えて）、ちゃんとリスク対策にお金をかけるよう企業に圧力をかけることができる日がいつか来るのでしょうか、と思った次第です。
そんな感想を持ちつつ読み進めた本書できらりと光ったのがセブン銀行です。セブン銀行はなんと定常的な運用の中でセンター切り替えを実施しているとのことです。これを東阪交互運用方式というのですが、名前から推測するに東京に主センター、大阪に従センターがあって、定期的に運用センターを切り替えているということでしょう。しかも切り替えに要するダウンタイムは30秒とのこと。これは日常的にシステム障害訓練を実施していることと同じなので素晴らしいなと思いました。
センター切り替えのような非定常的な作業は訓練をしっかりやっておかないと、いざというときに必ず失敗します。切り替え手順書の机上確認のような訓練では不十分です。けいやもシステムエンジニアの端くれですが、経験上強くそう思います（そしてそれを許す予算や時間が確保されないこともよく知っています）。〆
コメント