【IT】全銀ネット障害、メモリー不足が要因 事前テスト甘く
三菱UFJ銀行など10金融機関で約250万件の送金が滞った全国銀行データ通信システム(全銀システム)の障害は、各金融機関と同システムをつなぐ機器の容量(メモリー)不足が要因だったことがわかった。機器の更新で処理量が増え、想定の容量を超えてパンクした。事前のテストが不十分だった可能性もあり、検証が求められる。
全銀システムを構築するNTTデータなどは16日までに中継コンピューターのメモリー不足が…
https://www.nikkei.com/article/DGXZQOUB163SX0W3A011C2000000/
末端が要件定義できるわけがないんでデータ様か全銀様よね
上がだめならどうにもならない
提案したメモリ容量に対して、こういう場合でも不足はないか、あーいう場合でも不足はないか、そういう洗い出しができない集団で進めているのが問題なのです。
メモリの容量?仮想メモリは無いのか?
障害が発生したらロールバックして元に戻せばいいだろ。バックアップも無い?
こんなの人災だろ。NTTデータの分かって無いやつが外注に丸投げしてたんじゃないの。
お前COBOL時代のシステム理解してるんだすげーな
>事前のテストが不十分だった可能性もあり
これはテストの問題でなく設計の問題
テストで容量足りないとわかるのは要件定義不足
日経おじさんはスポンサーである元請は悪くないと言いたいんだろう
日銀が会員マシマシした分が要件定義後の決定で想定外だったんじゃないの?
それだったらテストの問題でなく顧客と元請の連携不足(コミュ力がない)
もしかして個人向けPCのレベルで考えてる?
メモリって言われてもどこのなんのメモリかさっぱりなんだけど??
xTechの方がちょっと詳しい
>全銀システムと各金融機関のシステムをつなぐ中継コンピューター(RC)において、メモリー不足に起因し、金融機関名などを格納したインデックステーブルに不正な値が紛れ込んだ。
> インデックステーブルはRCのディスク上にあるファイルから展開する。このファイルを作成するプログラムを実行したタイミングで、一時的に確保するメモリー領域が不足し、ファイルの内容が不正確になったという。
COBOL知らんけどISAMファイルがぶっ壊れたのか?
いま流行の、インデックスを全部、スワップアウト禁止のメモリーに置くやりかただね
このまえも何処かが事故ってニュースになった気がする
知らないところで沢山起きているのだろう
やはりインフラ屋の劣化がやばい
なるほど。スワップさせないのか。
あれって、電源落ちるとみんな喪失しないか?
いけるのか?
バックアップはないです。
メモリが物理的に不足してるのと作業用に確保するメモリが不足してるのとは全然違う話なのにな
日経の方は誤報レベルだわ
多分関係者の役職連中にもちゃんと理解してないの沢山居そう
>>52,62,66
このあたりだと、情状酌量の余地はあるな
要するに中継処理をするプログラム用の設定ファイル(インデックス)を作るプログラムがバグったと。
設定プログラムは中継プログラムが起動する前に使うだけだから、
テスト時に厳密な動作環境を作る発想がなかったろうし、
本番で中継プログラムに不具合が出ても、盲点になって修正が難しい
もちろんこういうのをしっかりこなすエキスパートもいるだろうが、
そういう人材はGAFAMとかに行っちゃうわな
もしかしたらCOBOLですらなくシェルかもしれんが
本番サーバで動くプログラムがずさんなテストしかしていなかったら責任は免れんと思うぞ
原因がわからない場合、ハードウェア起因に落ち着かせる
理由はハード投資で解決したことにできるから
で裏で調査を続けるシステム部
悪くて臭い物に蓋
わかる、転けたら新聞に載るインフラ系やってたが、ハード起因だと皆んな納得する不思議w本当は恥ずかしくて言えない低レベルのバグだったりする
若い人にはイジれないと思う
引用元: https://ift.tt/YsFHtVk