アカウント名:
パスワード:
一度に流してシステムが落ちたとしか聞こえないんだけど？システムを理解してないのか設計ミスなのかそこんところがはっきりしないのは怖い
印紙税節約のための「みずほ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万の契約社員で雇おうってんだからお察し。
その足し算あってる？
45+15=60万件はいけたが、45+25=70万件で落ちた、とITmediaの記事は読めばいいのかな？
そういうことみたいですね。ディスクフルで落っこちたみたいだけど、件数次第で起きる障害。運用でカバーらしいけど、実施タイミングや件数といった運用含めたシステム設計が考慮不足だった感じ。
ディスク空きがカツカツなRDBシステムでupdate文を投げたらトランザクションログが肥って止まりました的なミスなのかね。
2019年にリプレースしたシステムでそんなディスクカツカツな運用だったのか。なんかよく分からんな。でも銀行だし特殊なお高い超高速なディスクだったりするのかな。うちらの感覚とは違うのかもな。
遮断できないDOS攻撃の様なものなので負荷がかかればどうしても落ちる。負荷設計はコストの兼ね合いなのでシステム担当がどうあがいても無理な場合がある。
今回は二重引き落としや振替などの誤送信無くシステムが処理された、という意味では正常。
データ更新1件と月末処理1件が同じ負荷とは限らんやろー
み〇ほ銀行にコンピュータシステムが分かる行員も役員もおらず単なる素人集団です。何をすればよいのか分からないまま20年経ちました。
しかし銀行のシステムってしょぼいなきょうび2万円のPCでも毎秒万件単位のトランザクションは軽くこなせるよなサグラダファミリアっていうか、そびえ立つクソみたいなシステム
そりゃ求められる品質が違うからでしょ。メモリエラーが起きても大丈夫、データを保持するサーバーとの通信中に回線が死んでもデータ不整合を起こさない、処理中にCPUや電源が死んでもデータの健全性だけは守り抜く・・そういう処理を実装しようとすると、どーしても処理速度は遅くなるんじゃないかな。
多分、金融系システムの巨大さを知ると、腰抜かすと思うよ。あと求められる信頼性とかね。
より多くのコメントがこの議論にあるかもしれませんが、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万の契約社員で雇おうってんだからお察し。
Re: (スコア:0)
その足し算あってる？
Re:60万件の処理を (スコア:2, 参考になる)
45+15=60万件はいけたが、45+25=70万件で落ちた、
とITmediaの記事は読めばいいのかな？
Re: (スコア:0)
そういうことみたいですね。
ディスクフルで落っこちたみたいだけど、件数次第で起きる障害。
運用でカバーらしいけど、実施タイミングや件数といった運用含めたシステム設計が考慮不足だった感じ。
ディスク空きがカツカツなRDBシステムでupdate文を投げたらトランザクションログが肥って止まりました的なミスなのかね。
Re: (スコア:0)
2019年にリプレースしたシステムでそんなディスクカツカツな運用だったのか。なんかよく分からんな。
でも銀行だし特殊なお高い超高速なディスクだったりするのかな。うちらの感覚とは違うのかもな。
Re:60万件の処理を (スコア:1)
遮断できないDOS攻撃の様なものなので
負荷がかかればどうしても落ちる。
負荷設計はコストの兼ね合いなのでシステム担当がどうあがいても無理な場合がある。
今回は二重引き落としや振替などの誤送信無くシステムが処理された、
という意味では正常。
Re: (スコア:0)
データ更新1件と月末処理1件が同じ負荷とは限らんやろー
Re: (スコア:0)
み〇ほ銀行にコンピュータシステムが分かる行員も役員もおらず単なる素人集団です。何をすればよいのか分からないまま20年経ちました。
Re: (スコア:0)
しかし銀行のシステムってしょぼいな
きょうび2万円のPCでも毎秒万件単位のトランザクションは軽くこなせるよな
サグラダファミリアっていうか、そびえ立つクソみたいなシステム
Re: (スコア:0)
そりゃ求められる品質が違うからでしょ。
メモリエラーが起きても大丈夫、データを保持するサーバーとの通信中に回線が死んでもデータ不整合を起こさない、処理中にCPUや電源が死んでもデータの健全性だけは守り抜く・・そういう処理を実装しようとすると、どーしても処理速度は遅くなるんじゃないかな。
Re: (スコア:0)
多分、金融系システムの巨大さを知ると、腰抜かすと思うよ。
あと求められる信頼性とかね。