おはようございます。こんにちは。こんばんは。
ミッド（＠mid_v_lab）です
みずほ銀行で、「また」システム障害、5度目だ！！
みずほ銀行は20日午後、「12時頃にシステムが復旧しすべての取引が可能」となったと発表した。同行ではシステム障害で一時すべての店舗窓口で入出金や振り込みなどの手続きが出来なくなっていた。システム障害は今年だけで5度目になる。
引用元：日本経済新聞
とニュースで騒がれていました。
普段あまり銀行行かないので、
くらいに思っていますが、1年間に5回というとめちゃくちゃ多い印象を受けます。
お金を預かる機関として、社会インフラとして、5回は多すぎるというのが世間一般の正直な感想だと思います。
政府もかなり厳しい目を向けているので、もし6回目が発動したならば、利用者は離れていく＆法的なsomethingがあるんでしょうか。
とはいえ、わたくしはSE（System Engineer）畑の人間なので、きちんと障害内容を見てから、みずほ銀行はきちんとした対応したのか否かを判断したいなと思いました。
5回同じ理由での障害なら是非もなし。
障害内容から「みずほ」大丈夫なんかワレ？を考えてみます。
5回目（2021年8月20日）の障害内容
まず、今回のシステム障害の原因をみてみましょう。
原因は『DBサーバのハード故障』のようです。
みずほFGによると、業務チャネル統合基盤のDBサーバーが故障したのは8月19日午後8時57分。詳細な原因は調査中だが、「かなり複雑な壊れ方をした。冗長構成のバックアップ機器への切り替えは機能したが、（バックアップ機器に）故障が波及したようにみえる」（みずほFGの石井哲執行役デジタルイノベーション担当役員兼IT・システムグループ長兼事務グループ長）。
引用元：日経XTECH
DBサーバは、色んな情報が詰まっているサーバになります。
例えば、口座に紐づく残金情報や個人情報なんかも、このDBサーバに格納されているので、エンジニアがDBサーバの故障と聞くと
と思います。
みずほの方のおっしゃっている内容はよくわかりませんが、要約すると
- DBサーバ壊れる
- バックアップ機に切り替えできなかった
という感じ。
DBサーバというのは、データの集積場所なので、結構バックアップ体制が入念に実施されています。
機器自体をメイン・バックアップといった形で、二重化（冗長化）するのはもちろんのこと、中身のデータも日々バックアップが取得されていて、別の場所に保存されています。
インフラ系の会社ではBCP（Business Continuity Plan、事業継続計画）を意識して、地震などの災害に備えて機器の場所も冗長化しているなんて対策を取っている場合もありますね。（ディザスタリカバリってやつです）
話が脱線しましたが、みずほ銀行ではDBサーバの障害のために、バックアップ機器を用意していたが、それが使い物にならなかったというのが、障害に至った原因ですね。
なお、バックアップ機器が動かなかった原因としてハード故障ではなく、データ移行の失敗が原因のようですね。（ハードとソフトの2重障害か？）
過去4回の障害原因は？
今回は、DBサーバのハード障害でしたが、過去4回の原因はなんだったのか？振り返ってみましょう。
| 2021年2月28日 | e-口座一括切替処理によるファイル使用率100%（人的ミス？） |
|---|---|
| 2021年3月3日 | ネットワークカード故障 |
| 2021年3月7日 | プログラム考慮ミス（人的ミス） |
| 2021年3月12日 | 共通ストレージ装置内の通信制御装置故障 |
（引用元：みずほ銀行ニュースリリースより）
4回中2回はハード故障、2回は人的ミスのように見受けられます。
1回目（2月28日）
記念すべき？1回目の障害は、処理を流したらファイル利用率が100%で張り付いて、色んな仕組みの更新処理が止まった結果、ATM内に通帳やカードが取り込まれたままになりました。
全国で5244件取り込まれたということなので、大変な事態ですね。
ハード故障ではなく、処理によるものですので、なんとも判断しづらいです。
文面からは読み取れませんでしたが、「定例的に行われていた処理」なのか、「たまたまその時間帯に実施したのか」のどちらかによって「ギルティーorノンギルティー」が決まる感じですね。
普段やっていた処理が、この時たまたまファイル使用率が100%で張り付いてしまったのだとしたら、人的ミスとは言い難いですし。
「普段のファイル使用率と、処理後のファイル使用率をきちんと見ていたのかどうか」が普段からきちんとやっていたかの分かれ目になる気がします。
2回目（3月3日）
2回目の障害は、ハード障害でした。メインからサブへの切り替えに3分掛かり、その3分間通信が不安定だったようです。
これはしょうがない範疇かなと思います！
普段ならHPにぺろっとニュース記事でるくらいのトラブルですが、時期が悪かったでしょう。
3回目（3月7日）
3回目の障害は、完全なる人的ミスですね。
あるある～♪な感じですが、レビューとかで誰も気付かなかったのかな・・という部分に、みずほ内の体制大丈夫かな？と不安を隠しきれません。
また、デカい障害出したばかりなのに、新しいシステムリリースでトラブルを積み上げていくところに、驚きを隠せません。
一般的な感覚であればデカい障害を起こしたばかりなので、新しいプログラムリリースは必要なものだけにして、あとの重要度の低いものは延期すると思います。
事前に見えなかった考慮不足とかって、どうしても発生するものなので。
こういう面でも、横連携というか会社全体としての方針は大丈夫なの？と気にしてしまいます。（今回のが重要度の高いリリースだったのかもしれませんが）
4回目（3月12日）
ここで、再度襲来するハード障害。
私が中の人だったら、さじ投げたい気分になっていることでしょう。
泣きっ面に蜂とは、まさにこの状況。「ご愁傷様です」としか言えませんね。
こちらに関しても、障害部分の機器交換したけど回復せずに、復旧に時間が掛かったという感じです。5回目の時と非常に状況が似ています。
ハード障害なのでタイミングは神のみぞ知るって感じですが、障害時のリカバリ手順・範囲みたいなものが不足しているのかな？という印象を受けます。
少なくともハード障害3回で、内2回は交換しても駄目、バックアップに切り替えたけど駄目、では「それはバックアップの仕組みとして大丈夫ですか？」という疑念があります。
みずほ銀行の対応は・・・
結局みずほ銀行の対応はどうだったのかな・・・というと、
という感想を持ちました。辛めの採点です。
採点理由として、
- インフラ系の企業であること
- システムリリースなどの対応が少し甘い
- ハード障害に対するリカバリ手順・範囲が不足していそう
という理由です。
特に「インフラ系」という部分を鑑み、採点を辛めにつけました。
みずほでは、4回の障害のあとの原因分析として、
- 危機事象に対応する組織力の弱さ
- ITシステム統制力の弱さ
- 顧客目線の弱さ
- それらが容易に改善されない体質ないし企業風土がある
以上4つの原因をあげています。
①～③はふむふむ、という感じですが、④って・・・
メガバンクなので、半沢直樹ばりの派閥争いでもあるのか知らないですけど、ニュースリリース読んでて吹きました。
①②は訓練としっかりとした体制を作ればどうとでもなると思いますし、
③は分析するまでもなく信用がだだ落ちしてますので、
顧客影響のないようにシステム改修などを進めて頂ければと思います。
④はオバマ元大統領の「Change！」というセリフを送っておきましょう。
まとめ
みずほ銀行の5度にわたるシステム障害の原因をご紹介しました。
訓練や体制にしたって、一両日中中にすぐに作れるわけではないので、数年掛けて整えていく感じになると思います。
3年後のみずほ銀行が、「さすがメガバンクだ」「いつも安定して使いやすい！」「この機能が凄い良い♪」みたいに評価されるように、
今は耐え忍び、膿を抜ききるチャンスだと捉えて、是非頑張って頂きたいと思います。
みずほ内の企業風土がどうかは全く知らないですけど、SEって軽視されがちな職種なのでそういうのも無くなっていけばな～と思います。
営業みたいに新しい販路を生み出す訳でもないし、開発部隊みたいに新しい仕組みを生み出すわけではないんですけど、
いつも使ってる仕組みを、いつも使えるように整備しておく大事な仕事なので。
こういうシステム障害系のニュースがあると、ついつい原因に目がいってしまうのがSEの悪い癖！
ではでは
