みずほ銀行の障害原因について

2021/8/20に発生したみずほ銀行の障害原因について、整理する。

(1)ハードディスクが1台故障：問題点１

(2)ほぼ同時に、もう１台故障：問題点２

　→ハードディスクの2台故障に備えていなかった：問題点2-1

(3)バックアップデータの複製に失敗した：問題点３

(4)災対切替に時間がかかった：問題点４

表層的な問題点だけでも４つ挙げたがが、個人的見解として重要視すべきは問題点３の「バックアップデータの複製に失敗した」である。

(3)バックアップデータの複製に失敗した：問題点３

なぜ、バックアップデータの複製に失敗したのか？

それは、データの複製中に壊れたからである。：問題点３ー１

例として1TBデータの複製に1分かかるとしよう。複製開始から30秒経過した時に、複製元が故障すると、複製先のデータが中途半端な状態に陥ってしまう。

データの書き込み途中に強制電源オフすると、読みだせなくなってしまうのと同じである。

では、なぜデータの複製中に壊れること想定しなかったのか：問題点３ー１ー１

それは、二重障害は対象外とする仕様に基づいて設計したからである。

ここからの原因分析は重要である。

・なぜ、二重障害は対象外とする仕様としたのか：問題点３ー１ー１ー１

・なぜ、二重障害は対象外とする仕様の例外として、備えなかったのか：問題点３ー１ー１ー２

さて、話は一旦脇道に逸れる。

良くあるRPO(※1)＝24時間＝毎朝４時の時点に戻せば良いという場合、

毎日４時の時点をバックアップすれば良いかというと、それは間違いである。

※1：RPO=目標復旧時点

なぜなら４時の時点のバックアップには処理時間が必要であり、

バックアップ中に故障が発生した場合は、前日の４時のデータからしか戻せないからである。

例えば、火曜日４時の時点のバックアップに３０分かかるとし、

４時２０分の時点で障害が発生した場合、

バックアップから戻せるのは月曜日の４時のデータである。

つまり、RPO=24時間20分となる。

整理すると、RPOにはバックアップ時間(データ複製時間)を考慮しなければならない。

システム→バックアップ→災対へのデータ複製に1時間かかるのであれば、

RPOは24時間とせずに25時間でなければならない。

また、RPOはデータ複製時間(上記例では1時間)以内に設定することは不可能である。

では、みずほ銀行のRPOが１時間と設定されていたらどうだろう。

もしくは業務上の制限でRPO=5秒と設定されていたらどうだろう。

（以下、未整理）