アカウント名:
パスワード:
一度に流してシステムが落ちたとしか聞こえないんだけど？システムを理解してないのか設計ミスなのかそこんところがはっきりしないのは怖い
印紙税節約のための「みずほe–口座」への強制移行絡みが原因で起きた障害と考えると酷いな。
https://www.mizuhobank.co.jp/retail/products/direct/about/service/dire... [mizuhobank.co.jp]
バッチの処理件数が増えることでメモリ使用量増えるのがイマイチ理解できない。1件1件の処理は独立で、メモリ使用量は基本一定（増えたとしても並列で走らせる分くらい）だと思うのだけど。バッチ処理全体を一つのトランザクションと見なして、コミット前のデータをメモリに置いてるのかな。
メインフレームでCOBOL使うようなシステムはメモリ管理をアプリケーションでやるんだと思う想定データ件数に対してメモリ容量なり実行時間予測なりをしてアプリを書く作法で作っていて、想定を超えたデータが流れてきたらならメモリが足りない、実行時間が間に合わないのどっちかになる。
高級なプログラミング言語ならそんなことでは悩まないが、別途ガベコレが起きないようチューニングしたり処理移譲してるDBのほうのチューニングしたり、結局対応は必要
メインフレームのメモリ管理はOSの仕事で、アプリは関知しません。
管理って言葉はOSがやっているレイヤは含まないつもりで言ってはいるんだけど、メインフレームを触ってない私は適切な言葉で話せない気がする
そうなんですよね。システムのキャパシティ（空き容量）が不十分だった、というのがメモリを指すのかストレージを指すのか曖昧で。最初のうちはバッチ処理が28日中に終わらず月を跨いだのが原因か、なんて言われてましたけど。
たしかIBMのメインフレームでは、OSより下のレベルでメモリやストレージを全部まとめて単一の仮想メモリ空間として見せるような作りになってるので、曖昧というかOSからは区別できない。
https://ja.wikipedia.org/wiki/%E5%8D%98%E4%B8%80%E3%83%AC%E3%83%99%E3%... [wikipedia.org]
IBMのAS/400(と呼ばれていた時代)でも、HDDは主記憶装置って呼んでましたね。
メモリを指すのかストレージを指すのか曖昧で。
障害の原因となったメモリーを5倍に増強したそうです。https://www.nikkei.com/article/DGXZQODF034AN0T00C21A3000000/ [nikkei.com]
その辺の素人決済システムならともかく大手の金融システムがその程度でコケるって時点でありえないんだけどなぁ。余程ケチっているのか、依頼はケチってないが下請け下請けで実行部隊に回る金が小さくて実質低レベルな実働部隊が動いてるからゴミシステムになってしまうのか。
それこそ数億十数億なんて金かけるなら、超一流どころを集めて組めるだろうにな。その辺の有象無象じゃなくて。
どこぞのちょっとした店舗のオンラインショップがテレビで紹介されたから集中して落ちた、とかならわかるけどさ。
> それこそ数億十数億なんて金かけるなら、超一流どころを集めて組めるだろうにな。
今回は MINORI（新基幹システム）関係ないらしいけど、MINORI開発はトータル50万人月だそうだから、超一流どころで賄うのはむりでしょ。どう考えても有象無象が大量に入ってる。
誰がやっても同じ時間かかる仕事ならその通りだけど開発は担当者の能力によって所要時間変わるからね。
無能に実装させると実装に時間かかり、不具合満載でさらにデバッグ、修正にも時間食う。開発費減らそうと人件費安い開発者導入したら、開発に時間かかって逆に費用かかる。
50万人月は奴隷大量導入した証であって、賃金100倍の超一流を使ったら5000人月もかからなかったかもしれない。というかかからないでしょう。5000人月でもどんだけって感じなのに50万人月って頭おかしいよ。
＃100万円/人月として50万人月＝5000億円。それを5000人月にすると1億円/人月ｗ
コード書くのと、（仕様書とか変更履歴書とかの）書類書くのと、どっちが時間かかる？この規模の仕事だと。
ソースコードを日本語で書いてるだけの分厚い仕様書な。見るたびにこの仕様書書いてる奴が実装しろよと思う。あれは無駄すぎる。こういうの日本式の開発の悪いところ。
あと、コード書くのにかかる工数と、テストにかかる工数の比較も。
テスト工数(軽微な修正と再テストを含む)って、システム規模に対して二乗だっり、指数関数的に増えるというのが経験的な感覚。
# 大規模な修正が必要になった場合のことは置いておく。
行政絡みのシステムになるので資料が膨大になるのは日本に限らないけどな
仕様書の英文がほぼそのままソースコードになる筈（＝仕様書不要論が成立する筈）の、COBOLで構築された米国防総省の年金システムリメイクが失敗し続けているのは、仕様書の作成・更新をバカにして手抜きしたからじゃねーの？https://it.srad.jp/story/13/07/14/0555217/ [it.srad.jp]
ホワイトボックスで単体試験ケース作ると発狂する品質管理部門が居るんだもん
> 余程ケチっているのか、依頼はケチってないが下請け下請けで実行部隊に回る金が小さくて> 実質低レベルな実働部隊が動いてるからゴミシステムになってしまうのか。 あのシステムの火消しプロマネ(要実績)を、最大でも月130万の契約社員で雇おうってんだからお察し。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
身近な人の偉大さは半減する -- あるアレゲ人
60万件の処理を (スコア:1)
一度に流してシステムが落ちたとしか聞こえないんだけど？
システムを理解してないのか設計ミスなのかそこんところがはっきりしないのは怖い
Re:60万件の処理を (スコア:1)
予断で言うなら、
バッチ処理がメモリー不足で異常終了したとき、予防的に機能制限モードに入って、ATMデータ処理とか強制中断になった。
ATMはセンター側から信号が途絶えて、取引が成立したかわからないので、カードを取り込んで休止になった。
バッチ処理で1年間利用の無かった人の通帳をe口座?へ変更するプログラムは、今回が初めて動かした感じだから、メモリーの定義部分のプログラムミスなのかな。
年度内に終らせろって経営からの急な指示が遠因ということかな。
Re: (スコア:0)
印紙税節約のための「みずほe–口座」への強制移行絡みが原因で起きた障害と考えると酷いな。
https://www.mizuhobank.co.jp/retail/products/direct/about/service/dire... [mizuhobank.co.jp]
Re: (スコア:0)
バッチの処理件数が増えることでメモリ使用量増えるのがイマイチ理解できない。
1件1件の処理は独立で、メモリ使用量は基本一定（増えたとしても並列で走らせる分くらい）だと思うのだけど。
バッチ処理全体を一つのトランザクションと見なして、コミット前のデータをメモリに置いてるのかな。
Re:60万件の処理を (スコア:1)
メインフレームでCOBOL使うようなシステムはメモリ管理をアプリケーションでやるんだと思う
想定データ件数に対してメモリ容量なり実行時間予測なりをしてアプリを書く作法で作っていて、
想定を超えたデータが流れてきたらならメモリが足りない、実行時間が間に合わないのどっちかになる。
高級なプログラミング言語ならそんなことでは悩まないが、別途ガベコレが起きないようチューニングしたり
処理移譲してるDBのほうのチューニングしたり、結局対応は必要
Re: (スコア:0)
メインフレームのメモリ管理はOSの仕事で、アプリは関知しません。
Re: (スコア:0)
管理って言葉はOSがやっているレイヤは含まないつもりで言ってはいるんだけど、
メインフレームを触ってない私は適切な言葉で話せない気がする
Re: (スコア:0)
そうなんですよね。
システムのキャパシティ（空き容量）が不十分だった、というのがメモリを指すのかストレージを指すのか曖昧で。
最初のうちはバッチ処理が28日中に終わらず月を跨いだのが原因か、なんて言われてましたけど。
Re: (スコア:0)
たしかIBMのメインフレームでは、OSより下のレベルでメモリやストレージを全部まとめて
単一の仮想メモリ空間として見せるような作りになってるので、曖昧というかOSからは区別できない。
https://ja.wikipedia.org/wiki/%E5%8D%98%E4%B8%80%E3%83%AC%E3%83%99%E3%... [wikipedia.org]
Re: (スコア:0)
IBMのAS/400(と呼ばれていた時代)でも、HDDは主記憶装置って呼んでましたね。
Re: (スコア:0)
メモリを指すのかストレージを指すのか曖昧で。
障害の原因となったメモリーを5倍に増強したそうです。
https://www.nikkei.com/article/DGXZQODF034AN0T00C21A3000000/ [nikkei.com]
Re: (スコア:0)
その辺の素人決済システムならともかく
大手の金融システムがその程度でコケるって時点でありえないんだけどなぁ。
余程ケチっているのか、依頼はケチってないが下請け下請けで実行部隊に回る金が小さくて
実質低レベルな実働部隊が動いてるからゴミシステムになってしまうのか。
それこそ数億十数億なんて金かけるなら、超一流どころを集めて組めるだろうにな。
その辺の有象無象じゃなくて。
どこぞのちょっとした店舗のオンラインショップがテレビで紹介されたから集中して落ちた、とかならわかるけどさ。
Re:60万件の処理を (スコア:1)
> それこそ数億十数億なんて金かけるなら、超一流どころを集めて組めるだろうにな。
今回は MINORI（新基幹システム）関係ないらしいけど、
MINORI開発はトータル50万人月だそうだから、
超一流どころで賄うのはむりでしょ。
どう考えても有象無象が大量に入ってる。
Re: (スコア:0)
誰がやっても同じ時間かかる仕事ならその通りだけど開発は担当者の能力によって所要時間変わるからね。
無能に実装させると実装に時間かかり、不具合満載でさらにデバッグ、修正にも時間食う。
開発費減らそうと人件費安い開発者導入したら、開発に時間かかって逆に費用かかる。
50万人月は奴隷大量導入した証であって、賃金100倍の超一流を使ったら5000人月もかからなかったかもしれない。というかかからないでしょう。5000人月でもどんだけって感じなのに50万人月って頭おかしいよ。
＃100万円/人月として50万人月＝5000億円。それを5000人月にすると1億円/人月ｗ
Re: (スコア:0)
コード書くのと、（仕様書とか変更履歴書とかの）書類書くのと、どっちが時間かかる？
この規模の仕事だと。
Re: (スコア:0)
ソースコードを日本語で書いてるだけの分厚い仕様書な。見るたびにこの仕様書書いてる奴が実装しろよと思う。あれは無駄すぎる。こういうの日本式の開発の悪いところ。
Re: (スコア:0)
あと、コード書くのにかかる工数と、テストにかかる工数の比較も。
テスト工数(軽微な修正と再テストを含む)って、システム規模に対して
二乗だっり、指数関数的に増えるというのが経験的な感覚。
# 大規模な修正が必要になった場合のことは置いておく。
Re: (スコア:0)
行政絡みのシステムになるので資料が膨大になるのは日本に限らないけどな
Re: (スコア:0)
仕様書の英文がほぼそのままソースコードになる筈（＝仕様書不要論が成立する筈）の、COBOLで構築された米国防総省の年金システムリメイクが失敗し続けているのは、仕様書の作成・更新をバカにして手抜きしたからじゃねーの？
https://it.srad.jp/story/13/07/14/0555217/ [it.srad.jp]
Re: (スコア:0)
ホワイトボックスで単体試験ケース作ると発狂する品質管理部門が居るんだもん
Re: (スコア:0)
> 余程ケチっているのか、依頼はケチってないが下請け下請けで実行部隊に回る金が小さくて
> 実質低レベルな実働部隊が動いてるからゴミシステムになってしまうのか。
あのシステムの火消しプロマネ(要実績)を、最大でも月130万の契約社員で雇おうってんだからお察し。