明かされた「みずほの障害」の理由、 組織論だけではない課題とは?
コメント
選択しているユーザー
①確か月末バッチ処理に合わせてE通帳への切り替え処理を追加で行った結果、定期預金DBテーブルのインデックス領域がバーストして更新ができなくなり、それを察知したMINORI本体が取引をキャンセルさせるはずがなぜかカード咥えたATMごとぶち落としていったのが初回。
②外為のやつはストレージ障害起因で、溜まった処理終わらず。
どちらも正直、設計が良くない部分が一因と見ています。
月末バッチ処理に合わせてE通帳切り替え処理を加えたのはNGなのは当然として、ATMのやつはMINORIがフェールセーフに倒せてないですし、周知が遅すぎました。
ストレージ障害のやつは設計通りにフェールオーバーできてないという結果。
メガバンクさんなので正直運用だけでカバーできるほど処理が甘くないように思います。
あと報告書についてですが、組織論だと共通でわかりやすいので、メディアは取り上げがちなのだと思います。悪い言い方をすると、システムのことがわからないので取り上げないのではないでしょうか。
直接的原因はそこではないと思います。
同じ技術者として端的に申し上げるならば、MHRTご担当の知識不足だったのではないかと見ています。
自戒込めて、頑張っていきたいです。ミスは誰にでもあり得ますし。。
注目のコメント
#みずほ #MINORI
<以前のPickより>
<論点1>処理件数とその想定
いわゆる「27日の処理」(給与振込後の引落し処理や振替処理等)と月末最終営業日の処理と週末の処理がすべて重なった・・・これをきちんと想定していたか、想定していたとしてそれに対する手当てが十分だったか。また、ここ重ねるように非定常的な「定期預金のデータ移行作業」を行ったようだが、その判断プロセス、判断ロジックは適切だったのか。
<論点2>前回(2011年3月の)システム障害を受けての再発防止策(1とも関連)
2011年3月の大きなシステム障害も、上限値/システムキャパシティと日次処理が起因となって発生したもので、再発防止策もシステム全体の上限値の再点検や、運用時の上限値をどう監視し管理していくかが一つ大きな対策になっていたはずである。そのルールやスキームはいまどのように動いているのか。
<論点3>シャッターの閉め方(閉塞の仕方)
会見ではハブアンドスポーク型でハブの高負荷時(障害時)にはスポークを減らす仕組みにしている・・・というようなこと言っていたが、スポークの減らし方→ATMシステムのシャッターの閉め方(閉塞の仕方)は適切なのか。不正等の防止のためにカードや通帳を収容するというようなことを言っていたが、顧客のことを考えていない提供者側の都合ではないか。例えば、コンビニの中央管制塔が障害でコントロールできなくなったときに、エッジの店舗にお客様を閉じ込めたままシャッターを閉めるか。
<論点4>お客様対応
障害発生、検知後のお客様への告知や誘導、その方法、利用メディア等は適切だったか。
<論点5>連絡体制、現場責任体制、コンティンジェンシープラン
非営業日にATMで障害が起きたときの連絡体制、実行責任体制は計画されていたか。ATMは支店の管理責任下にあるのか、中央(ATM管理部門?)の管理責任下にあるのか、このあたりのコンティンジェンシープラン、連絡体制、実行責任の所在のあり方は適切なのか。
<おまけ>MINORIは成功・・・の錯誤
記者会見で「MINORIは成功したが運用がダメだった」のようなことを言っていたが、この考え方がもはや時代遅れではないか。システム(開発プロジェクト)は完成したら終わり=成功ではない、運用し成長しビジネス価値を出し続けてこそ価値がある。途中から読めなくてわかりませんが、トランザクションの制御に問題が有りそうです。また問題発生時の対応はおそらく人力で、根本的な原因を除去する手段がない場合、罹災範囲を拡大させそうな雰囲気の図です。もうちょい読みたかった。