みずほ銀行システム障害の報告書を読んだ結果

(๑╹◡╹๑) @tsuchie88

リテール本部でこれだからなぁ　やはりリテール部門は解体すべきだわ。 pic.twitter.com/WjfyiurTz1

拡大

(๑╹◡╹๑) @tsuchie88

みずほ広報無能伝説 pic.twitter.com/dr3ZkzvjLc

拡大

拡大

(๑╹◡╹๑) @tsuchie88

そういう問題じゃないと思うんだが(嘆息 pic.twitter.com/O3dqULhULy

拡大

(๑╹◡╹๑) @tsuchie88

ほぇぇぇ pic.twitter.com/GWbtYeQsGc

拡大

(๑╹◡╹๑) @tsuchie88

おっ、2018年のMINORI切替リハーサル時に発生した障害は金融庁報告してたけど、一般公表してなかった事案なのか。黒塗りになってるな pic.twitter.com/nOZCsyg9XT

拡大

拡大

(๑╹◡╹๑) @tsuchie88

まぁATM取込仕様については、いいか悪いかは弊猫の中では微妙な点はあるけど、元々トラブルが多かったというのが気になるな pic.twitter.com/wu3VPf8F5R

拡大

(๑╹◡╹๑) @tsuchie88

おやすみだし・・・。 pic.twitter.com/lkYZu1Rkw4

拡大

(๑╹◡╹๑) @tsuchie88

石井ぃぃぃぃぃぃ！！！！！！！　おまえかぁぁぁぁぁ！！！！！！ pic.twitter.com/WlixVptpQQ

拡大

(๑╹◡╹๑) @tsuchie88

この結論も微妙に思えるなぁ　絶賛炎上中の海外システムの置き換えで人は必要だし、カットオーバーしたシステムに、開発中並みの人員張り付けるのはどうかと思うんだけど。 pic.twitter.com/Sx64ZGntA1

拡大

(๑╹◡╹๑) @tsuchie88

というわけで、2月28日事案についてまとめると (1)MINORI構築時に性能改善のためにIndexをインメモリ化した部分があったけど、みんな忘れてるか知らなかった (2)小銭が欲しくて、3月末に間に合うようにe-口座をリリースした。多分大丈夫じゃね？と思ってテストはやらなかった。知らんけど

(๑╹◡╹๑) @tsuchie88

(3)(1)の部分を(2)が見事に踏んで障害が発生。で、自動で取り消されるはずが無応答になった障害発生部分を要因として一種のデッドロックになった。二重障害は想定もしてないしテストもしてなかった。 (4)エラーがいっぱいでて、よくわからんけどリミッター解除した直った経験があるので解除してみた。

(๑╹◡╹๑) @tsuchie88

(5)解除したらさらに状況が悪化したので、みんなに連絡しはじめた。 (6)メールみたけど、なんかよくわかんなかったのでとりあえずヨシとした。リモートアクセスもログ全部みれへんし

(๑╹◡╹๑) @tsuchie88

(7)ATMがどんどん停止してる中で、これはやばいですよ、ホームページで告知しないと、承認お願いします！とメールおくったけど、誰も無反応だったから掲載できなかった。 (8)ATM障害はコールセンターが対応してるなら任せとけば、と思ったら、1件15分対応にかかるのに当日7人しかいなかった。

(๑╹◡╹๑) @tsuchie88

(9)1000件くらいのBCPシナリオがあったけど、そのうち休日にトラブルが発生する可能性を考慮したものが1件しかなかった。 (10)上層部にエスカレーションする仕組みが不十分だった。エスカレーションしても判断する仕組みが機能してなかった。

(๑╹◡╹๑) @tsuchie88

主要なところだけでこんな感じなんだけど、まぁ誰が悪いかというよりも「全員邪悪でした」って感じで終わりですねこれ。終了

ktgohan @ktgohan

mizuho-fg.co.jp/release/pdf/20… 読んでいてつらみがありすぎる。よく読まないとわからないつらみばかりだけれど。ちょっとこれは…

ktgohan @ktgohan

『取消情報管理テーブルは、定期性預金システムにおいて、成立済取引の事後取消等をするために必要な取引情報を格納しており、取引を制御する上で更新処理が必須のテーブルであるところ、取引情報管理テーブルのINDEX FILEは、メモリ領域に常駐する仕組みとなっている。』 えっ

ktgohan @ktgohan

『MINORI構築の終盤である2017年11月に定期性預金システムで実施される「おまとめ処理」における処理時限への影響懸念が判明し、MHBK及びMHRTの性能WGで、この課題への対応策として、同月17日、MHRTの再委託先の開発ベンダーからの提案を踏まえ、「本件メモリ常駐」への仕様変更を決定したことによる』

ktgohan @ktgohan

しかも「おまとめ処理」以外の取消情報管理テーブルのインデックスも全部オンメモリにしちゃったので、メモリ残量がゼロになったら全部更新不可。ここの仕様変更掛けたときのリスク分析まるでやってなかったってことか？

ktgohan @ktgohan

だって「定期性預金系でエラーが起きた（更新不可）」→ 呼出元にエラーが返る → 呼出元は当該処理の取引中止を指図する → 取引中止（取消）を指図されたが取消情報管理テーブル自体が呼出不能 → 死 これやんけ…

ktgohan @ktgohan

で、ATMでのキャッシュカード取り込みが多発したのは、このエラー連鎖により「元帳不整合懸念」に発展したからか… 定期性預金系の問題だけでどうしてキャッシュカード取り込みに発展したかは機序は理解したがやっぱりつらすぎる。

ktgohan @ktgohan

@Kumappus というより、オンラインバッチ系の高速化で最高レベルの地雷を仕込んだ感がありますね。動いてなければ問題はないし、瞬停で死んでも本来なら再呼出でリカバリできる可能性も高いです。

ktgohan @ktgohan

しかもこれ、データセンター側からエラー通報を受けたみずほ情報総研（現MHRT）がまともに取り合わず、発生事象の認識がクソ遅れたという十重二十重の事故ですよ。ヤバすぎる。 twitter.com/livedoornews/s…

ライブドアニュース @livedoornews

【報告書】みずほATM障害、頭取の事態把握はネットニュース経由だった news.livedoor.com/article/detail… システム障害は当初、行内での影響評価のランク付けが「S」「A1」より下の「A2」と判定され、頭取への報告は必要とされなかった。そのため、頭取はニュースを見て障害発生を知ったという。 pic.twitter.com/vcQm5UsJ9i

2021-06-15 15:48:55

ktgohan @ktgohan

おまけに2月27日（障害前日）にはその予兆の閾値超過エラーメッセージがシステム側から送出されていたのに、肝心のMHRT側がそれを見事にスルー。当初「27日にも同じ作業をやっているはずだが…」とコメントしていたみずほ側、そりゃそうですよねという事案に。スルーしてたんだから。最悪だこれ。