教科書に載りそうな悪夢

「障害の責任について「お客さまに向き合うみずほ銀行が全ての責任を負う。（ベンダーによる）システム構築は無事に成功しており、運用面でみずほグループに不十分なところがあった。グループが責任を持って対処すべき」との見方を示した。 」

＞「今回の障害の問題は運用面にあった」

↑実はこれかなりやべーやつ
本当にみずほやばいと思うの

昔、証券会社のシステムに関わったことあるけど、エビデンスのキャプチャとかが多すぎて金融系システムには関わりたくない思った。

＞みずほ銀は27日、1年以上動いていない定期預金口座のステータスを「不稼働」に変更するデータ更新作業を行っていた。処理したデータは45万件。

自前のシステム会社作って運用するしか無いと思う。（開発までやれとは言わないけどね。

結局あれは誤作動だったのか
> ATMには不正利用の食い止めや、不完全な処理の確認のため、通帳やキャッシュカードを一時的に取り込む機能がある。これが誤作動した。
---

頭取「システム構築は成功している。運用面とハード面で不十分があった」

まー確かにそうだけど… システムも本当に成功してるんか？って不安は残るよな😅

データ移行を月末に行う危険性は現場は当然認識しているわけで、何らか上からの圧力があったんだろうな。某銀の現場軽視は2002年から変わってないんで4度目ありえるぞ。

他行のATM使うことになった人に
手数料を返します、は、いいけど、
月末支払いできなくなった人へはどうするのだろう？

【ATMの誤作動】不正利用や不完全処理のリスクを最小限に食い止めるための機能ｗ

◆
◆みずほのATMでまた障害 3日夜、29台が一時停止 先日の障害とは「別の要因」

月末とか素人目にも走る処理増えると思うけど、そのタイミングで(即時性が必要なさそうに見える)動いていない口座のステータスを変更しに行くの怖ない？

「三度目の正直」にならず、
「二度あることは三度ある」になったか…
勧銀止めてて良かった。

障害原因と関係ない所を切り離すフェールセーフ実装してる時点でminoriは問題無いとは言えないと思うんだが。取引フロー制御ってどこのフレームワークだろう?IBM?

これについてプログラムをカナダで書いている友人が、面白い指摘をしてくれた。

業界人のサンドバックと化した詳報

こういう時に常に聞こえてくるのは「甘かった」というもの。ではなぜ甘くなるのか。10年サイクルで甘かったと言い訳する事象が繰り返されるのは、考えるまでもなくみずほの体質。すぐ忘却するわけですから慣れていないということ。
↓
システム過負荷でなぜATMにトラブルが？

こっちの方が具体的っぽい？

システムのバグなどの問題かと推測してましたけど😅

これはだれか運用側が止めなかったのでしょうか😅

タコ足配線でもしてたんだろ

通帳廃止を勝手に推し進めて、結果としてATM止めたと。救いようないな、上層部。

性能的に大丈夫かどうか以前に、勘定系の月末処理とそれ以外の大規模な作業を並行してやるのは色々と厳しい。タイミングずらせなかったのかな。

カード取られるATMの動作
無かったら、もっと被害少なかった
危険すぎる機能付けるな！😓

Final Cut Proで作業してたら挙動不審になって、あ、内部ストレージ不足か⁉︎といつも慌てて外部に移しはじめる私🤡
みずほのトラブルって、まさかそんな私レベルの原因ってことなの？

異常時動作としてカードや通帳を飲んだまま停止したのが疑問だったんだけどそれは誤動作だったと

処理したデータは45万件。この作業を行うにはシステムに十分なデータの空き容量が必要だという。

高々45万件でメモリ食いつぶしたの？

システム屋には「運用でカバー」って魔法の言葉があるんだぜ？

「データ更新と月末処理がバッティング」

DBのロールバックセグメントが足りなかった的な話か。手作業での更新ではありがちなこと。ただし通常はリハーサルをやると思うけどね。

ATMを機能制限したなら、というトップブコメがあるけど、すべての口座が使えなくなったわけじゃないからなあ

そもそもシステム設計の時点からしくってるのか、試験関連工数がっつり削ってるのか？？？
にしても、ここ結構システムトラブル多いよなー

時間外で更新すればよいのに
できないんかな

キャパ不足から誤作動。リソースプランニングの重要さが分かる。

(ヽ´ω｀)今わかってるところを読んでるだけでも先に期待できなそう…

藤原頭取は「過去2回の障害の教訓については、システム構築、運用、リスク管理についてしっかり対処してきたつもりだ」 マジでー

なんだ。プログラムエラーじゃないのか、寧ろ正しく動いた結果。
システムダウンを防ぐ為に他の動きを規制した結果、カードを吸い取る…？？ここは謎。

処理件数の見込みの甘さが原因。

>データ更新と月末処理がバッティング
>ATM誤作動は“リスク軽減”の結果
→”システムに十分なデータの空き容量が必要”な作業を、通常処理が増える月末に突っ込んだPMが悪いな

みずほって20世紀の名門三行が合併したやつだけど、未だにあちら立てればこちらが立たぬ的に3システムを統合し切れてないのかな？

商用環境で負荷試験を実施しているだけなのでヨシ！

QT この障害の影響で、同行が持つATM約5900台のうち4318台が一時取引できない状態に。ATMに挿入したまま戻ってこなくなった通帳やキャッシュカードは5244枚あったという。

起きるよね、こういうことは。

ATMの「セーフモード」起動時、どの機能を切るか、の設定が正しくなかったのか。でもそれ統合時にテストしてるやろ（トリガーのリソース不足自体はあるある）＞

「今回の障害の問題は運用面にあった」って、観点がずれてる気がするんだが。
データ量が想定より多くなった時に、更新処理が止まる設計になってるのがあるべきでは。「1年以上動いていない定期預金口座のステータス変更」なんて、止まってもクリティカルじゃないでしょ。

もし、ATMとかIB止めてなかったら処理が終わらず突き抜けていたって事かな、それもやばいな。他行との取引は非整合がでるとまずいから他行でのATM引き出しは残しといたのかね。

なんか攻撃でもされたのかと思ったら過負荷ですか。。

■

過負荷でATM誤作動が起きるというのは？だけど、過負荷で一部機能を制限した中に口座のチェックシステムが含まれていてということかな。

ATM閉塞までは完全に想定通りっぽいけどね

つまり、システム上の障害運用は正常に動いたということか？

見積もり甘くて月次より1.5倍以上のデータ盛っちゃって負荷で落ちた→全体停止を阻止するためATM制限！
→処理不完全のため通帳カードを一時的に取り込みが誤作動起こしちゃった

ATMがカード食ってしまうのは最悪。

だよな、「なぜATM？」と疑問に思うよな：

非機能要件はいつも計画に見積もられ忘れる。そして、横連携がないと非機能要件も見積もれない。自分が反省すべきこともいっぱい。

要約「テストはしてたんすよ！同時に動いてる処理の考慮が抜けてただけで！」

「下請けの所為にしないところに好感が持てる」って意見を見たけど、出来る訳ないよなぁ。性能要件やし

フェイルセーフが働いたのが原因だった模様…🧐

“1年以上動いていない定期預金口座のステータスを「不稼働」に変更するデータ更新作業を行っていた。処理したデータは45万件。この作業を行うにはシステムに十分なデータの空き容量が必要だという。”

僕はストレージが勝手に伸びる世界に住んでいます。お疲れ様です。

＞ATMには不正利用の食い止めや、不完全な処理の確認のため、通帳やキャッシュカードを一時的に取り込む機能がある。これが誤作動した。
やっぱりそうか。

「リスクを最小限に食い止めるためにATMの機能が制限され、障害となって現れた。ATMには不正利用の食い止めや、不完全な処理の確認のため、通帳やキャッシュカードを一時的に取り込む機能がある。これが誤作動した。」
誤作動ではなく、正しく機能したのでは？

>銀行スタッフの対応の遅さを批判する声も上がっていた。

なんも関係無いけど、この精神が全員の仕事量を増やす原因だと気づいた。もっと余裕持って生きたい。

要件通り作られていたならシステム屋は悪くない。

本当にシステム統合した方影響ないんですかねぇ… -

仮
Oracleとして、Undo領域、temp領域が不足したとか？

引用

なんだデットロック起こしてたのか😔

前のバッチが終わってる想定で実行したんだろうけど、終了後起動にするのが安全だって身をもって教わったのがなつかしい🤔

過去の大障害に比べれば遥かに被害は小さいし本格稼働からまだまだ日も浅い事を鑑みればそこまで大騒ぎする話ではないと思うけど、重要なバッチが集中するであろう月末に不要不急（の様に記事からは類推される）かつ初物の処理をあえて実施するというリスク感覚は理解に苦しむ

データ更新と月末処理がバッティング。ATM誤作動は“リスク軽減”の結果

「ATMには不正利用の食い止めや、不完全な処理の確認のため、通帳やキャッシュカードを一時的に取り込む機能がある。これが誤作動した。」カード食われた件は仕様通りってわけではない？

通常の月末処理に加えて「データ更新作業」を行った結果「システム上の空き容量が不足」して障害発生って、作業を行っても問題はないというテストをしてから実行したんでしょ…：

(｡･ω･｡)ﾉ システム過負荷でなぜATMにトラブルが？ みずほ銀システム障害、運用面の課題あらわに NEWS

先月末のみずほ銀のATMトラブルが起こった背景の解説。簡単に言うとシステムの過負荷だが、いつもよりも負荷が重かったんだとさ。

もうメインバンクじゃないからいいですけど、みずほ銀行はこういうトラブル多いですね。

→（定期預金の）「データ更新作業自体は今回が初めてだった」（記事中）、ということは、月1回とか年1回とかの頻度ではないんですね。意外。

残高不正や二重振替などが発生していないのであれば、それほど深刻な障害という感はない。ATMがカードを飲み込む不具合（仕様？）がタチが悪すぎた。

銀行は非人道的なウチの会社でもヤバい枠扱いだから近寄らないようにしててよく知らないけど

> システム構築は無事に成功しており、運用面でみずほグループに不十分なところがあった。グループが責任を持って対処すべき

最近はあまりベンダに責を求めない風潮

どんなDBとハードウェアを使っているんだろう？

ATMを止めなければ、もっと酷いことが起こってたのね...😮

パワーワード。
過去2回の大規模障害を経てのシステム構築は「成功している」

»

成功とは？

負荷、はちょっとミスディレクションかな？ どっちかと言うと、キャパシティの問題

これつまり、前回の震災の義援金同様に、処理件数が増えたら死ぬってことだから、前回の反省踏まえてなくない？って思った。

サムネが尻尾の長い黒猫に見えた🐈
(記事は読んでない)

運用なめぷっぽいのか…

なんだかなぁ・・・。

なるほど。
みずほ銀行のトラブルの件、要するに

"基盤システムには、システム全体がダウンしないよう、一部の機能に制限を掛けて負荷の軽減を図る機能。今回もその機能が稼働。
結果として、ネットバンキングやATMをつかさどる部分の機能が制限"

＞障害が起きた28日も、みずほ銀行は約45万件のデータ更新作業を行っていた。しかしこの日は、27日を10万件上回る25万件の月末処理が重なった。

その程度で容量不足になるようなスペック

月末やっからよろしく！っていう報告の中で、あれ、ちょっとその日は不味く無い？って人居なかったのかな。

e通帳周りの処理かな～？1月に判定して2月に処理。あやしい。

想定外のシステム負荷で障害になるのは仕方ない面もあるが、利用者がATMから離れられない状況に陥ったのは最悪。

そんなにすごい件数には思えないけど裏でいろいろ大変なことをしてるのかとかカードを返さないのはいいけど障害わかってるなら取り込み機能を止めないのかとか気になる｜

何か(ｻｰﾊﾞｰ)に不可がかかると全体が止まらない分どこかにかなりの不可が発生する。。。
困ったもんですね💦😓

読んで呆れる、みずほ銀行。

「システム上の空き容量が不足した結果」「どこかで問題が起きた場合にシステム全体がダウンしないよう、一部の機能に制限を掛けて負荷の軽減を図る機能がある。今回もその機能が稼働し、全体的な障害は免れた」

1年以上動いていない定期預金口座を「不稼働」に変更するデータ更新作業と月末処理がバッティングした事が原因みたいですね。
事前にどこまで負荷を想定するかは難しい所です。。

”（ベンダーによる）システム構築は無事に成功しており、運用面でみずほグループに不十分なところがあった。グループが責任を持って対処すべき”
これが言えるのが偉い。

経営陣がこれだけ的確に説明出来るのはすごいと思うよ。

資料は部下が用意するかもだけど、説明出来るのは相応のスキルがいる。

ベンダーによるシステム構築は成功しており責任はみずほの運用にある。
とのことらしい。

まぁそういうのもよくあるよね。

手順度外視でぐっちゃぐちゃにするユーザもいる。

ビジーになってもトランザクションに不要ならさっさと返せよそこは

なるほど＞

通帳やキャッシュカードを一時的に取り込むって頭弱いの？？＞

60万件で問題なかったけど70万件でシステム止まりましたって…
普段の処理件数確認しなかったのか問いただしたくなるな

今回の件で色々と批判めいたtweetをしたけど、記事の『藤原頭取は障害の責任について「お客さまに向き合うみずほ銀行が全ての責任を負う。』で、真摯に向き合う姿勢を見たと思う。

みずほ銀行のシステムは「IT業界のサグラダファミリア」と呼ばれた。
基幹系システムは稼働期間20年を超えると非常に危険な状態になり、2025年には全体の60％を超える「2025年の崖」に。