みずほ銀行システム障害の報告書を読んだ結果
-
- いいね！939
報告書読解第一弾
(๑╹◡╹๑)
@tsuchie88
やたらと「区画」って言葉が出てくるけど、これIBM用語だよなぁ？ 仮想マシンか論理または物理的に分離されたパテーションのことなんだろうけど。 pic.twitter.com/SJA2oGfj5a
2021-06-15 19:56:05
拡大
(๑╹◡╹๑)
@tsuchie88
イメージはわかるが、ATM取引で手数料テーブル舐めないのおかしくね？ pic.twitter.com/RGf99FVz6I
2021-06-15 19:58:02
拡大
(๑╹◡╹๑)
@tsuchie88
みずほのデジタル比率、件数ベースでも金額ベースでも10%割ってるのか。まさか1桁%台だとは思わなかった。SMBCやMUFGの1/3規模じゃん。ここまで遅れてるとは pic.twitter.com/h0YWg6rhRJ
2021-06-15 20:01:19
拡大
(๑╹◡╹๑)
@tsuchie88
「お客様の利便性」じゃなくて印紙税節減目的と正直に書いてあるのはえらい(コスト削減効果は印紙税16億+通帳コスト1000万円)けど、これスケジュールありきの移行計画なんだなぁ たのしー pic.twitter.com/uVgqLY0pmG
2021-06-15 20:05:43
拡大
(๑╹◡╹๑)
@tsuchie88
？？？？ これ笑うとこ？？？？ 笑うとこ？？？？ これマジ？？？？ ありえへんやろ？？？？ pic.twitter.com/WmLcbHCczB
2021-06-15 20:08:56
拡大
(๑╹◡╹๑)
@tsuchie88
@WangChangHardy UPDATEやINSERT処理が頻発すると、INDEXのファイルがでかくなったり断片化してでかくなることあるんですけど、これってINDEX領域がインメモリな領域にあったので容量一杯になって止まったっぽいんですけど。普通そういう実装するなら、監視するけど、どうも最後まで原因をつかんでなかったっぽい感じが
2021-06-15 20:38:20
(๑╹◡╹๑)
@tsuchie88
発端は定期性預金DBのINDEX領域の容量超過だけど、排他処理でCIFつかんだままの取引が全部死んだということなのか？ これだと、つかんだままの処理だけがダメだったのか、CIF自体がロック多発で新規取引を受け付けなかったのかよくわからんな。一番重要なところだと思うけど。 pic.twitter.com/LTpHCcsWkQ
2021-06-15 20:42:04
拡大
拡大
(๑╹◡╹๑)
@tsuchie88
前者の問題だとこれだけ大規模な障害になる理由がわからんし、後者なら区画閉塞に伴って終息するんじゃないのか？ どっちの理由にしても、MINORIに刷新する最大の理由だった「バッチレス・オンラインシステム化」の前提崩れてるし、設計ミスやろって言われてもしょうがない気がするんだけど
2021-06-15 20:44:52
(๑╹◡╹๑)
@tsuchie88
世の中的には、「経営陣とリモートワーク貴族が悪くて、現場とエンジニアは悪くない」って展開を期待してるのかもしれないけど、「全員邪悪でした」って展開で読む気をなくしてきた。この後、IT統括部や経営陣の責任が続くんやで。体力もたんわ！
2021-06-15 20:52:31
(๑╹◡╹๑)
@tsuchie88
@WangChangHardy 読み進めると、取消情報を格納するテーブルのINDEXをメモリ上に置いてたので、大量のINSERTでINDEXが肥大化してボリュームを溢れたってことみたいです。 pic.twitter.com/jYaqdw5KnH
2021-06-15 20:59:17
拡大
(๑╹◡╹๑)
@tsuchie88
在宅でエラーを確認しようとしても、リモートアクセス環境がしょぼくてログを確認できなかったでござるの巻 pic.twitter.com/QeOrBE0UgZ
2021-06-15 21:06:18
拡大
(๑╹◡╹๑)
@tsuchie88
これ以下は、システム以外の対応になるけど、にちようびだし、おひるだし、みんなおひるねしてたんだね。 pic.twitter.com/Yu6pGVZ5e7
2021-06-15 21:24:27
拡大