みずほ銀行、連続システム障害からの教訓

システム障害を「語り継ぐ」取り組み実施

   新システム「MINORI」は、勘定系システムを、複数のコンポーネントに分割し、コンポーネントごとに異なるアーキテクチャのハードウェアで、分散稼働させる方針を採用した。また、コンポーネントによって開発するITベンダーが異なる「マルチベンダー体制」をとった。

   本書は、「マルチベンダー体制」に問題があったとすれば、システムが複雑になり、運用しづらいものになったことだ、と指摘している。

   「こんな複雑なシステム構成は、当社なら運用部門が認めないだろう。運用が難しすぎるからだ」という、他の金融機関の情報システム担当者の声を紹介している。

   開発部門にリソースが優先的に割り当てられ、運用部門が軽視されたことが、連続システム障害の背景にあった、と見ている。

   最後に、みずほ銀行以外の国内や海外の金融機関で起きたシステム関連のトラブルを比較していて、興味深い。

   システム障害を想定した訓練を行っているかどうかが異なるという。他のメガバンクは、年に1回必ずシステム障害を想定していた訓練を行っていたのに対し、みずほ銀行は行っていなかったのだ。

   みずほ銀行では、要員を増員し、部門横断の統制組織を復活させ、障害を想定した訓練を始めるなどの対策をとっている。また、障害を「語り継ぐ」取り組みも行っている。

   タイトルの「ポストモーテム」とは、直訳すると「検視」または「死体解剖」だが、米国のIT企業では、システム障害が発生した後の「事後検証報告書」をそう呼ぶそうだ。

   特に、米グーグルの電子メールサービス「Gmail」が2011年に障害を起こした際に発表されたポストモーテムが、有名。グーグルがデータを磁気テープにバックアップしていることが初めて明らかになり、信頼感を高めた。

   今回のみずほ銀行のポストモーテムから、金融機関のみならず、システム開発にかかわる多くの人が教訓をくみ取ることだろう。（渡辺淳悦）

「ポストモーテム　みずほ銀行システム障害事後検証報告」
日経コンピュータ著
日経BP
1980円（税込）