新着Pick
320Picks
Pick に失敗しました

選択しているユーザー
もし自分が謝る立場だったら、この説明を担当の方からされても納得できないと感じました。自分が納得いくまで担当の方に質問し続けるでしょうね。
人気 Picker
今回の障害に巻き込まれてしまった皆さんは本当に大変だったと思います。
さて、障害原因の詳細分析は今後進むと思いますが、「過負荷」が原因となるトラブルは、今後のデジタル社会で更に増える可能性があります。今回の原因とは別かもしれませんが、サイバーの世界では、規模の急拡大が容易に起こりうるためです。フィジカル世界の延長線での経験的な規模見積が通用しなくなります。将来的な重要な技術として急激な規模拡大への対処技術が重要になります。その成功事例はスケールアウトのパラダイムを切り開いたgoogleですが、googleも数多くの失敗を克服して技術を積み上げてきましたし、今だに「取組み中」でもあります。もう一つ重要になるのは、同時に大規模になるリスクへの対処です。サイバー世界では、そのメリットの伝搬(広がり)スピードは凄まじいですが、トラブルの広がりも瞬時です。大規模リスクへの対処策が社会の安全・安心にとって最も重要かもしれません。
データ移行作業でシステムが過負荷になったまではわかるとして、この発表だけだと、何故それでATMでキャッシュカードが吸い込まれたままで出てこなくなったのかがわかりませんね。

データ移行による過負荷で勘定系か過負荷になり、ATMと接続されている中継サーバが応答待ち状態になっていて、ATMがささったとか、、?

金融庁が報告徴求命令を出すという報道もあるので、詳細な報告書がでてくるのを待ちましょう。
銀行にとって今後は非金融事業者向けのBaaS(Banking as a Service)ソリューション提供も重要な事業のひとつになると考えられるなか、度重なるシステムトラブルは、個人顧客が離れていくこともさることながら、よりシステムトラブルに過敏に反応する非金融事業者から敬遠されることにつながるように思います。
金融機能があちこちに「溶ける」流れのなか、裏側の機能提供インフラとしての銀行の安定性は厳しく求められ、信頼のリカバリーはこれまで以上に難しくなりそうですね(個人顧客は時間が経てば忘れるとしても、BaaSソリューションを利用する非金融事業者のデューデリジェンスではそう簡単に見逃されないという意味で)。
処理量が一時的に急増してシステムが吸収しきれないような問題を回避するためによりスケーラビリティーの高いデータベースをスケーラブルなクラウドインフラ上で動かすべしですよとクラウドベンダーは言いたいところだと思うけど、こんなセンシティブなトランザクションデータがクラウドに移せる日は来るのか・・・
システムのキャパオーバーが原因だとすると お粗末な原因かと言える。何より残念なのは ATM に通帳やカードが飲み込まれたままの顧客に対して 的確な対応ができなかったこと。
もし長時間 顧客がATMの前で待つことを前提とするのなら  現在のプロセスと対応マニュアルを見直すことも早急に。
この原因の説明が仮に本当だったとしたら、普通に考えてありえないと思います。
普段から、それなりの規模の企業の情報システムを担当しているものなら、どんなシステム変更であろうとも、本番移行作業は月末月初の繁忙期の本番移行は避けるはず。
負荷が集中することはわかっているのに、そんな移行計画を立てるわけがなく、そんな計画のレビューが通過するなんてあり得ません。

それとも、その処理ボリュームを読み違え、ハードウエアの事前の増強規模を見誤った?
それとも本当の原因は隠してる??
いずれにしても、これはお粗末です。

これまでみずほ銀行のシステムの取材を続けてきた日経BP社の報告を待ちたいと思います。
"定期預金のデータ移行作業が45万件、月末処理が25万件"というのがどれくらい重い処理なのか感覚が分かりませんが、それほど特殊な作業にも聞こえないのが怖いですね。今後も起こり得そうな気が。。。
東証がしたシステム障害時の説明に比べると、なんだか納得感なし。

データ移行処理がたくさんあると、ATMにカード吸い込まれるんだ?
◾️バッチ処理のリスクより
月単位の何かは、古い習慣の名残り。人間ベースの制約。
そろそろ、月や日単位の当たり前、バッチ処理に依存しない業務設計が求められている気がします。仕事は溜め込まない。 全ての商流で。

今後益々リアルタイムの価値は高まり、
オペレーションリスクも細切れに出来るでしょう。

◾️マイグレーションのリスクより
頻繁なクエリー実行を期待する設計から遠ざかってみると、何か新しいアーキテクチャが見えて来そうです。

例えば、顧客の入出金(実績記録の蓄積)と、業務用のサマライズは別物として実装してみる、ひとつのRDBに同居させない、などです。

毎回ガラガラポンの集計するのではなく、いくつものプールを設けて、個別のトランザクションを 他のトランザクションから隔離してみる、必要に応じたプール間の調整で全体を整合させるイメージも思いつきます。プールの壁が障壁となって、何らかのリスク低減も得られるかもしれません。もちろん各プールの粒度は、人間では到底コントロールできないレベルでも良いと思います。

夢のような話かもしれませんが、マイグレーションミスの防止だけでなく、バーチャル通貨やバーチャルワールド、パラレルワールド(シミュレーションによる加速未来計測やAI学習フィールド)との融合をも狙った、頻繁なデータスキーマ改造の余力も視野に入ってると素敵だと思います。
リーダー企業にはリーダーたるべき振る舞いがあると思います。今回は過負荷が原因ということで、想定される負荷に対して余裕のあるリソースの割り当てをすべきだったと学びますね。なぜなら、みずほという日本のリーダーの金融機関だからです。

このような作業について、サイジングかプロビジョニングと言う過程でクリアにしておくべきでしょうね。
株式会社みずほフィナンシャルグループ(英語: Mizuho Financial Group, Inc.、略称:MHFG)は、東京都千代田区に本社を置く日本の銀行持株会社である。 ウィキペディア
時価総額
3.89 兆円

業績

株式会社みずほ銀行(みずほぎんこう、略称:みずほ、英語: Mizuho Bank, Ltd.、略称:MHBK)は、本店を東京都千代田区に置く、みずほフィナンシャルグループ傘下の都市銀行。3大メガバンクの一角を占める。 ウィキペディア

業績