【ブックレビュー】ポストモーテム　みずほ銀行システム障害　事後検証報告

twitterでも「GitHubが繋がらなくなった』「AWSが障害発生した」と度々トレンドになるように、たとえ一流のエンジニアが開発運用しているサービスでも障害は発生します。それはそうでしょう。規模も大きすぎてすべてをコントロールするのは困難でしょうし。トラブルのニュースが流れるたびに、中で奮闘しているエンジニアのことを思うと胃が痛くなります。

企業が利用・提供するサービスで障害あるいはヒヤリハットが発生した際、何が原因だったのか、どう対応したのか、改善しなければならない点は何か、をまとめたものをポストモーテムと呼びます。GoogleがかつてGmailの障害におけるポストモーテムを公開し、結果としてGoogleへの信頼が高まったという話があります。他社の障害対応はは他山の石になるため、僕ももっと読みたいのですが、企業秘密が関わることもあり、また恥ずべきものというイメージもあるのかなかなか公開されないのが現状。この本は2021年大きな問題となった、みずほ銀行のATMで障害が発生し、お金を引き落とせなくなるなど利用者に重大なダメージを与えた障害のポストモーテムとのことなので参考になるかと思い読んでみました。ちなみにこの本、「ポストモーテム」と銘打っていますが、自分の考えるポストモーテムよりは些か文学的な書かれ方をされています。本来はこんな長文では書かれず、箇条書きで書かます。それだと読み物にはならないからでしょうが。

みずほは３つの銀行が統合して生まれたスーパーメガバンク。組織も従業員も顧客も大きいですし。そんなみずほ銀行が業務で利用しているシステムも間違いなく巨大なシステムのはず。エンジニアの苦労が忍ばれます。そんなシステムの大規模障害は、バグだけでなく、仕様の問題、ハードウェアの故障、検証で発覚した問題を解消しなかった問題、ヒューマンエラー、そして組織の体質。それらが超巨大なシステムの中で少しずつ連鎖反応あるいはタイムラグで1年にわたり発生していたようです。発生した障害のタイムラインを読むと、現場が地獄だったことが想像できます・・・。『7つの不手際のうち1つでも正しく処置できていればこれほど大きなトラブルにはならなかった』という結論は本当につらい。その不手際の真因も統合の前から脈々と続いていた問題だったことをみずほ銀行のシステムの歴史から紐解きます。そういえば大学生の頃、みずほ銀行で2重振込や2重引き落としのニュースがあったなぁ。「2重振込ならぜひ発生してほしいｗ」なんて冗談で当時言っていましたが、現場としてはたまったものではなかったのでしょう。

過去複数回の大規模障害を教訓に刷新された基幹系システムMINORIは過去のコードを採用せず、SOAを採用し、できるだけ生のコードを書かせなくして属人性を排除するなど優れたアーキテクチャで構成されていました。でもマシンだけでは駄目でマンも正しく動かなければならない・・・そのためにはやっぱり障害対応組織を作ることと、年に1度は復旧デモンストレーションを行うことが必要と、思ってはいるんですけど・・・てやつですね。

このポストモーテムから以下のような教訓を得ました。

疎結合＝正義、密結合＝悪ではなく、やりたいことを実現する優れたアーキテクチャをシステムの重要性などを考慮して採用する必要がある。
- 速度の関係でディスクではなくメモリにデータを保存する場合、容量のサイズには気をつける必要がある。なおAWSのマネージドキャッシュは自動で大きさを拡張するのでそこは大丈夫と思われる。念のためキャッシュサイズを監視することが大事。
利用者の声を聞くべく、twitterで自社名、自社プロダクトの単語を引っ張ってSlackに通知できるように・・・はtwitter APIの有料化により難しくなったのか。
障害発生時に自分たちで集まり、情報を共有、対応を勧めていけるようCSIRTはやっぱり必要。
事前に定めていた復旧手順では復旧できないというのはあるあるである。やっぱり年に1度は復旧デモンストレーションを行わなくてはという気持ちになりました。なった、だけだと駄目なのは分かっているのですが・・・。
「積極的に声を上げることでかえって責任問題となるよりも、自分の持ち場でやれることはやっていた、といえる行動をとる方が、合理的な選択」は大組織ならではなのかもしれませんが、風通しの良さと心理的安全性の大切さを感じました。