みずほ銀行、INDEX FILE容量超過で取引禁止機能が自動で作動→そのあと手動で禁止解除→被害拡大 [雷★]
■ このスレッドは過去ログ倉庫に格納されています
(略)
取消情報管理テーブルのINDEX FILEの容量超過が発生した9時50分からパーコレート エラーが急激に発生(1 分間に 4.14 回発生)し ATM 処理区画の閉塞が始まっていたが、10 時 19 分から自動で取引サービスの禁止機能が順次作動し(上記第 4・1・(1)・ア・(イ)の 時系列表のとおり、ATM 処理区画の各系統における各取引サービス(対象:「定期預金通帳 を記帳する」及び「定期性預金通帳を表紙見返し作成」)禁止機能は、10 時 19 分から 11 時 48 分にかけて作動している。)、パーコレートエラーの発生頻度が一気に低減(1 分間で 0.93 回)した。しかし、12 時 2 分から 12 時 8 分にかけて、ATM 処理区画の各系統における取引 サービス(対象:「定期性預金通帳を記帳する」)禁止機能の作動条件となっているエラー回 数の上限を大幅に引き上げる変更(30 回から 999 回)、すなわち取引サービス禁止機能の作 動条件の緩和(事実上の取引サービス禁止の解除措置)を行った結果、再びパーコレートエ ラーの発生頻度が高まり(1 分間で 4.33 回)、ATM 処理区画の閉塞に拍車がかかり、多くの 処理区画が短時間に閉塞されて ATM に係る顧客影響が急激に拡大した(下記図 20 参照)。
当面の障害対応策としてこのような措置をとった理由は、過去にも取引サービス禁止機 能の作動条件を緩和し対応した同種の経験があった点にあるとされる。
上記第 4・1・(1)・ア・(イ)の処理区画閉塞の発生状況の図 9 にパーコレートエラーの 発生状況を重ねてみると、下記図 19 のとおりであり、取引サービス禁止の作動条件の緩和 によりパーコレートエラーが急増し、ATM 処理区画の閉塞が進んだことが見て取れる。なお、 ATM 区画ごとにパーコレートエラーが発生(赤■)し、5 回発生すると区画閉塞(グレー■) に至っている模様(9 時 50 分~12 時 59 分)を示すのが下記図 21 である。
(略)
https://www.mizuho-fg.co.jp/release/pdf/20210615release_3_jp.pdf
【図 19】パーコレートエラー及び区画閉塞の発生状況
https://i.imgur.com/8asVm32.png 見通しもなく制限解除するとかアホだろ
運用すらまともに回ってない銀行のおままごとだな もうみずほやめようかな
職場の口座だからそういうわけにもいかないか 運用もよくわからない素人がマニュアル見ながらやってるんだろうな みんな怒られたくないから見逃して大問題になった案件だな
システム開発は防御策を置いておきましたって言えるし
運用はマニュアルに書かれてないから大丈夫だと思いましたって言える >>13
キャッシュカード回収手数料を請求されるよ INDEX FILEって、DBのTABLEに保存できるデーターの個数のこと？
それの数を本番運用中に変更したの？
それはそれで凄いなぁ 普通に監視してないわけ？
今日日企業の業務システムですら監視してんだけど 昔、客のデーターベースが急に遅くなったからハードウェア故障に違いないと言われて障害調査したら、
客が一週間ぐらい前に組み込んだジョブがインデックス無い検索をパラパラとたまにやるのでその時だけ異常にI/O 増えるのが原因だったことがある >>24
おれも
オンラインアプリも三菱と比べてセキュリティ低いし替え時かもな 弊社請求書の振込先にみずほがあったら恥ずかしいレベル >>42
数千億かけてシステム作ったんだけど下請けへの要求が高すぎ間に合わずとりあえず動けばいいで稼働開始。 でもジャップは他行に移動しないでみずほを使い続けます Oracleかなんか使ってんのか？
結構初歩的なミスだろ 未だにみずほの口座使ってるやつは自業自得としか言えん システムがうんこすぎて倒産するという世界初の銀行になるかもな。 アスペルガーが仕事を急ぎすぎて、
忙しい時期に仕事をさらに入れた。
村だけ！
自分さえ良ければが招いた！
アスペをコントロールできない会社！ 美しいIT後進国の姿
いまだに職員の中に技術者をIT土方と馬鹿にしてる連中もいるんだろうな たかし君は誕生パーティに来てくれた友達に、りんご1個とみかん1個を配ることにしました
おかあさんは「これくればあれば足りるわね」とりんご1箱20個とみかん20個を買って来ました
たかし君は友達をもっと呼ぶことにしました
たかし君はおかあさんに聞きました「全部で30人くらい来るけど大丈夫？」「大丈夫よ」
おかあさんはりんご20個を追加で買って来ました
誕生日が来たので、たかし君は友達にりんごとみかんを配り始めます
「おかあさんみかんが足りないんだけど？」
「あら、いけない、りんごが増えたらみかんもふやさないといけなかったのね！」
その日、りんごとみかんを同じ数だけ食べないと体長40ｍの怪物の変身してしまう
インデクス星人のたかし君は、りんごとみかんを両方人数分確保しなければいけないという
誰でもわかることを考えられなかったおかあさんのせいで
みかんを食べられなかった太郎君が吐く4000度の火炎放射に
焼かれて死んでしまったのでした 銀行なのに俺みたいなとりあえず再起動してみようぜって人間が指揮取ってたのかｗ このシステム作るのに３０００億ぐらいかけたんだろ
みずほは本当に面白いな >>1
こんなんだからこそハゲバンクにアホほど貸せるんだな しかし、最低限の事もわかってないんだな。こんな連中にお金を扱わせたら駄目でしょうに 限界値テストもしてなかったのか
非機能の担当者いないんだろ
みずほのプロパーにIT担当者いないわけ？ こんな銀行が隣国に融資してるのか
革命が起きたら現物回収に行きそうだな え？インデクスのサイズ固定にしてたの？多少の処理速度なんてパワーでなんとかなるんだから自動拡張にしといたらいいのに >>81
ITのわからんIT担当者はそらいるだろう このINDEX FILEってのはいまどきのDBMSのじゃないんだろな？ システム会社の社員として名前だけ登録させてもらえれば
バレずに毎月お金だけもらえそう
それくらい誰も管理できていない >>81
普通容量に迫ったら警告されるように作ると思うんだけど、根本的な可用性の設計ミスってんじゃない？ 火災発生で防火シャッターが降りたのを運用が誤作動だと勘違いして勝手に解除して延焼が進んだような感じ？ みずほ銀行システム統合、苦闘の19年史
っていうカッコつけた本出したあとにこのザマだからな >>86
今どきのぎんこうはほとんどコネ採用しかいない 安全装置がはたらいたけど「よくわからないけど解除ヨシ！」してより惨事ってことん 日給100万のエンジニア1人雇うより日給一万を50人雇え言ったのはここだっけ？ こんなクソ銀行ってわかってるのに、口座数は日本2位だっけ？ 過去にもってその時原因把握しなかったの？
インデックスのサイズなんて一番ケアするところじゃん？
ヤバない？ エラーをむりやり解除して運用って現場だったら命落としかねない愚行だぞ >>112
たぶん運良く回避できたパターンがあったんやろうな >>81
日常からアラーム鳴りっぱなしだったんじゃね？
それでも今まではATM端末で少し処理待ちが長くなるくらいで問題なく復帰していたんだと思う >>107
100万出したら99万円中抜きされて1万円の人がやってくるですね >>117
中抜きって中間業者を通さずに直接取引する事
サヤ抜きのこと？ IndexFileがなんなのか？Oracle使ってんのか？
こんなこと言ってるレベルの奴はみずほの派遣技術者よりレベル低いのに偉そうにしててワロタw
まあ新システムで業務側や運用経験低いのもあるけど、これだけの規模でデータ移行するんだから
IBMの人間関わらせてないのか？って疑問はある。昔は基盤系で必ず口うるさいのがいたもんだが。 炭鉱でカナリアが死んでます！(エラーレート上昇)
↓
よしもっとカナリアを増やそう！
ちょっと何やってるかわからん・・・ 下請けくんには罰として納期の短縮と工数削減を実施します
今後は品質を上げてください まぁ、みずほをメインバンクとして使っている顧客側にも問題があるわけですよ
例えればしょっちゅう事故起こすような航空会社や証券会社使いたくないだろ みずほ銀行がウンコなのは今に始まったことじゃない
驚きなのは、未だにこの銀行を利用している人たちが大量に存在すること
まー好きな銀行使えばいいけどさ >>41
テーブルに貼るインデックスじゃないんかね。容量超過でレコード追加できないとか？ 何をしているの、この銀行は。
こんなの全員、出向だわよ。 >>1
彡彡ミミ, ”宮廷女官チャングムの誓い” の要点は、
( ´・ω・) "チョ・グァンジョ" にあり！
/ 丶 何で安全装置発動したか分からないけど禁止解除して通常運用ヨシ！ >>1
ほーん、アホが上に立つとこうなる案件
縁の下で支えてるシステム管理者大切にせーよ >>35
どこと言う話ではなく、先回りして考えるタイプの人は、すぐに閑職に回しちゃうんだろうね。やれと言ったらやるんだよ。みたいな感覚って、日本人には共通してると思う。 >>124
今回の件でCIOがIBMの部長クラスから招くとか日経テレ東でいってた
外部からこのクラス入れるのはみずほとして例外中の例外だって 止めたら怒られるから制限解除したんだろ、気持ちはわかる
それでうまくいったこともあったんだろうな >>111
どうやら検索によく使うテーブルで、パフォーマンス上の懸念があったので
開発のある段階でそれまでディスク上に作ってたインデックスだけメモリに常駐させるようにした
ところが 引継ぎやドキュメントの問題で
そういう経緯でこのインデックスがメモリ上にあるということを把握してる人がほとんどおらず
テーブルの領域 および他の物理インデックスは自動拡張にしてファイル領域をメインで監視していたため
このテーブルの件数が増えたらメモリに作ったインデックスも増えるということを考慮できず
結果、インデックスが拡張できませんエラーが出て処理がこけて
そこからドミノ倒しのようにシステムが破綻していって最終的にATMがカードを吸い込んだ >>52
オレも両方使ってるけど、色々な落差がひどいよな >>35
障害対応した奴や報告した奴の評価が下がるらしいからどんどん人材流出するだろうね そりゃ実力で力付けた銀行じゃないからな
宝くじを独占して50%以上の回収が安定してるから銀行として成り立ってるだけ
そしてメガバンクとしてのブランドを手に入れたらメインバンクとして利用するアホが増えた
その結果として海外出資までして調子に乗ってる
本当の実力者ってのは勝つ時の力も負けた時の力も見えている
みずほは実力でのし上がったわけじゃないから負けた時に復旧する力は持ち合わせていない
今回みたいなトラブル＝負けた時にプラマイゼロまで持っていける力がないってことよ
勝てる企業と負ける企業を選別するのもまた利用者 >>8
サブシステムだからザルよ
どこの会社も基幹系も外部との出入口以外はザルよ＠金融のシステム社畜 >>81
そもそも観点から落ちてるのにいくらテストしようがわからんよ。
それにテスト環境は本番環境と違ってたんだろうからすり抜けたのも明らか。
作れてもせいぜい本番相当であって同じ環境・条件までは難しいのが現実だからね。大手銀行はどこでも。 >>123
COBOLは皮レベルで
中身はアセンブラのスパゲッティどころかブラックホール なろう小説レベルの事案
＞え、社内システム全てワンオペしている私を解雇ですか？ 友達が残高たりてたのにカードの引き落としが失敗しててカード会社から葉書来てたのってこれ絡みだろうか >>41
テーブルのデータを検索するための索引を保存するための領域。データが増えれば索引のサイズも増える。
自動的に拡張されるが、上限までいくと自動拡張されない。最初に十分な領域確保しておかないとこうなる。
ディスクに空きがあれば、本番運用中に別の領域確保してインデックスファイルを追加することは可能。 >>145
スゲーアホだな。
メインメモリに頻繁にレコード追加されるテーブルのインデックスファイル置いたらどうなるかくらい予想つくだろ… >>150
宝くじの勧銀なんてと蔑んでいたろ富士は ○年後には「あんな時代もあった。あんな銀行もあった」ねと言われる銀行 インデックスファイルのサイズを超過するとどういう不具合が起こるのか誰も把握していないのが原因な気もする
テーブルのインデックスを張れない→検索レスポンスが大幅に低下→タイムアウトか？ まあ、よくあるDBの容量不足によるシステム不具合みたいだけど、漏れてくる情報の端々から中身がブラックボックス化しているのが分かって怖いわ。預金他の銀行に移そう‥ >>163
そのシステムが使っているのはRDBなんだろうか？との疑問もある >>172
インデックスを追加できないならテーブル本体も追加できなくなる >>125
炭坑でカナリアが死んでます。
↓
各現場に二羽はいないといけない規則です。
↓
カナリアを増やそう。
つまり何のための規則かがわからない社員ばかりになると起こる。 インデックスだけ拡張できなかったって話はこの前の4月の段階で発表されてて
ワイ氏はその当時からバカかこいつらって言ってたんだが
ようやく周知されてこれが笑い話だというのが通じる人が出て来てうれしいｗ 今どきCOBOLなんかで書いているのが原因
知らんけど >>176
このレベルだとRDBじゃないだろうね
今で言うKVSみたいな感じだろ 貯金データーが収納しているサーバーへアクセスが出来なくなり ATMへ規制が掛かった
サーバーがLOCKした原因は？ 発注元「一人月120万円のエンジニアだぞ、さぞかし質も高いだろう」
一次受け「よしプロジェクト管理するぞ！二次受けヨロ！」
二次受け「よし労務管理するぞ！三次受けヨロ！」
三次受け「ゴミ雇って適当に働かせたろ」
こうして高価なゴミが爆誕するのである みずほのシステム部門と取引（下請けじゃなくてね）を何度かしたけど、酷かったよ。
自分達の責任回避、金額は安く。こればっかりの奴らだった。 >>1
「濁音」の表示が変で記事が読みにくいんですが。 >>141
>>142
ありがとう。やっぱそうだよねー
承認出してるみずほが悪いんだけど、IBMとしてもサイズ溢れるけどいいの？ってくらい最低限の指摘
してなかったらボロクソに絞られるのは目に見えてる。富士通も巻き添えかな。
日立はまあ高みの見物だろうけど。 >>181
フクイチの時は放射線被曝上限を引き上げて万事うまくいった
意味は深い Windowsでファイルネームが文字数制限超えると使えなくなるみたいな話か >>1
～ リレーショナル・データベースの重要な点 ～
データの完全性 （トランザクション処理） >>1
システム管理者が「エラーは何故起きているのか」を把握せずに運営してるってこと？ 報告書の他のエラーの説明にコミットだのロールバックだの出てくるから
データベースソフトは何か使ってんじゃないの？ 設計段階でいろいろ見落とし過ぎだろう。どこの会社請け負っているの？ まさか、朝鮮系なのか？ >>179
DBMSだろ。細かく容量制限かけて満杯でDBが動かなくなるのはよくある事。 >>81
みずほだけは誰もやりたがらない
無駄死には御免だ 銀行レベルならしきい値監視ぐらいしてるだろうに・・・ とりあえずよーわからんから値増やそってすげぇやべぇ運用してんのなw 「トランザクション」 は成功か失敗かのどれかしかありません。
失敗した場合は 「トランザクション」 実行前に戻ります。
中途半端に成功したとか、
中途半端に失敗したとか、 そういうことは絶対にありません。 ← ★ こんな馬鹿な連中に金を預けてるような奴が居ることが全く理解出来ない >>7
中国に外注だすのか？
今の物作りジャパンなんてこんなもんよ >>125
カナリヤ増やしたけど作業員殆ど死にました 次にみずほ行く機会あったら解約しようと思いつつコロナで出不精なっていて放置なってるな
これで解約増えたらそのうち落ち着くとか我慢比べだろか… >>194
エラー原因がわかったけど、それを解消する手段の影響を確認せず、よりヤバイ状況になった
てか、対応方法がダメだった これカッコ書き多様の文章で何もお伝えしたくない感しかないなｗｗｗ
参照や引用はせめて文章から分離して付記ぐらいにしろよな 仕様がそもそもうんこで運用が考えずに崖に突っ込んでみたと言う楽しいお話有難う御座いました >>185
3次受けが人を見つけてこい4次受ヨロってなる
先は長い >>194
正にこれだろうね
でも日本のIT現場だとだいたいそうだね
まさか銀行レベルでも同様だとはね 新規勘定系はしゃーない
デバッグ数量のけたが違うからな
どこがやっても人柱不可避 基本設計、確認、テスト、リリース判定のいずれの段階においても問題を洗い出し、障害の発生を未然に防止することはできなかった
ってよP67にある
全ての役割がダメだった エラー回数多いから自動停止
↓
停止条件を３０倍に手動変更
↓
エラー回数が３０倍になり全停止
こんな感じ？ インデックスファイルって何語よ？
リレーショナルデータベースにそんな別立てのファイルあったっけ？ >>222
停止条件の数字に9を打てるだけ打ったら良かったのにな みずほのシステムってデスマーチ案件で相当話題になってたやつだよね？
またこういうエラーを何度も繰り返しそうだな で障害発生後の対応がまた最悪
しかも2018年の障害は昨日まで隠してた 完全に詰まって水を流すと汚水が溢れるから
自動で水が止まるシステムを作りました
ある日いっぱいうんこしてたら水が流れなくなりました
なので手動で水を流すようにしました
これで解決するとおもいましたまる
こんなんやろ >>202
監視対象となっていなかった
大ブラックホール
メモリー上に置いていたのまでは認識
それがトランザクション量に比例して膨れるものだとは思ってない
のでリリース前テストではトランザクション処理速度のチェックのみ
キャパシティチェックなし インデックス何？聞いたことがない？RDBMSなの？とか言うてるプログラマが
しこしこ100件くらいのデータでテストデータやってる裏で
DBエンジニアが本番のデータベースにインデックス張ってパフォーマンスみてる >>210
多分分かっていないでやったと思うぞ
何だかうざいエラーがピーピー鳴っているけれどいつもこのおまじないをすれば黙って勝手に復旧するのでヨシ！ >>81
リソースの７０％まで使われる前提でシステム組んでたんじゃね？
まあ通常のテストじゃ最大どれだけリソース食うかわからんけど普通は２０％程度使われる前提でシステムを組むぞ。 派閥争いのせいでシステム統合できず
やっと取り掛かったらエラーエラーエラーってぼろぼろだな
今回のも大昔の化石プログラムだったりして >>221
サマリーの方には仕組は悪くない、見抜けなかった運用が悪いとかいてるんだよな。
この期に及んでまだ責任逃れかと思った。 報告書さらっと読んだだけなんで概略として、インデックスの領域を処理速度向上を目的にディスクからメモリーにする仕様変更したけど、仕様変更の共有ミスとか変更承認の所在が曖昧とかもあったな。
本来なら、メモリーも自動拡張するんだけどその設定ミスってとか、リリース前のテストで限界まで回してみての確認漏れてたとかも書いてあったな。
失敗から学ぶ教材として。いっそこれそのまま、ITの教科書にのせたら？ >>1の文章になんか変な文字がたくさん紛れ込んでるのは何なんだぜ？ 担当者達の脂汗を感じるけど
報告内容はおもしろいな
つか明日は我が身だ… 取禁作動(エラー上限30回)してエラーが減ったから
取禁解除(エラー上限999回)したら一気にエラーが増えて閉塞した
てこと？ システム君「体調不良だから病院行ったら、検査入院することなりました」
みずほ銀行「その程度の体調不良で入院とかしてんじゃねえよ」と検査結果待たずに退院させる
みたいなもんか
どこでもやってるな みずほにお金振り込まれた日に全額降ろして住信SBIに入れてる
手数料無料だしデビットカード使うとポイントつくよ ATM情報程度の数値データしかないならいちいちインデックス作るなよｗ
今時のサーバーならINDEX使わずに検索しても早いだろ。 >>25
PDFからコピペするとこうなったりするな。理屈は知らん 開発じゃなくて運用って言ってる企業は潰れたほうがいいぞ 金融系エンジニアなんて末端は文系だし、プロパーは業務知識だけのおじさんだからそもそもRDBのindexがなんなのか分かってない可能性すらある >>260
デカい会社にはDBだけ何十年もやってたDBおじさんいるよ 巨大システムだからな、他行も潜在的にバグが隠れてるはず、コンピューター系の職員は今必死だろうな データベースの問題か
その場しのぎでやってると起きるやつ
とりあえずは問題ないけど後から問題が起きるがどうせ俺もういないしみたいな
派遣がやってるとこうなる見本みたいな 畑違いの文系ばかりが役職占めて理系、とりあわけエンジニアが薄給だから起こる典型だな 下っ端の受注先を、何かあるたびに変えてたりしてな
問題起こした時とか、毎度入札して変わるとか、
開発の下請けも変えてたりして
なんだか、運用の引継ぎが出来てない？
仕様を知ってたらオーバーフローとか防げそう 管理ができないならもうサービスやめろよ貸し出しだけやってろ法人だけの個人を相手にするな 硬直化と事なかれ主義とITﾘﾃﾗｼｰ０と日本の問題点の縮図のような案件だな あいつがやった
おれのせいじゃない
しらない
すんだこと >>233
とあるメーカーのサーバー用ソフトウェアがメモリの9割使用前提だったの思い出した
他のプロセスが動いてるときは融通するのかと思ったけどそんな事はなくその後どうなったのか俺は知らない 目覚ましのスヌーズボタン連打して気がついたら・・・、遅刻。 散々トラブル起こしてるのに、
いまだにみずほ使ってる奴は発達障害者か何かか？ この前仕事でみずほ行ったら30分以上かかると言われたのでやめたな。他の銀行は空いてる普通の日。
当座しか使ってなかったからよかった 報告書を読んだが長いだけジャン。
159ページ3/7障害について
1、プログラムミスに関する検査の強化
バカバカしいから略
2、プログラミングミスを発見する方策
①設計担当者と再鑑者で分けてレビューしましょう。←良くあるやつで何処でも手順が決まっているがチェック表埋めるだけなのよね。変かなって思っても実行環境無かったら確認出来ないからね。
②共通処理の改修では、本来の目的外の利用についても各種テストする。←目的外の利用とかサラっととんでも無い事書くなよ。
③テストを実施する際の前提条件を見直し、テストによる障害検出の向上を図る。←いっそ最初から出来を悪くすれば？障害検出件数は増えるぞ。
まあハード障害とかにも言及してるし2002年の障害もサラっと凄い事書いている。ツボったのは改善提案の方だな。安西先生の以下略。 あパーコレートエラーは
取引メインの回復処理機能では回復不可と判断し、制御機能Aに該当取引の異常終了処理を委ねること
と用語説明にはある。
エラーをキャッチしたが手に負えないので再度投げた感じがする。言語がわからないからどう投げたかは言えません。 業務が複雑すぎるのが原因何じゃ？
ITに押し付けたらあかん 昔、某行のCIF開発部隊に参加してた身から言うと、ATMや勘定系トランザクションのキックが、なんでCIFからやねんwと
各サービスを疎結合に作り変えたMINORIのくせに、初っ端にCIFを排他ロック、トランザクションの最後の最後でアンロックてww
CIFコケてカード食われるなんて考えられんわ
勘定系オンからCIFなんか参照だけ（後で一括バッチ）でいいっての
頭悪い設計やなー >>288
報告書にもあるけど通帳飲み込んだままにするユーザー軽視が悪い
あれが無ければその日のうちに終わる問題で4月まで解決が長引く事はなかった 配電盤のブレーカーが頻繁に落ちるのに
原因追求せずにガムテープ固定したようなもの？ みずほ銀行に相続で手続きに行ったら難癖つけられ引き出せなかった
上から下まで腐ったヤツだらけだ みずほのお友だちイオン
イオン銀行のキャッシングの実態
http://johnsonforassembly.com/news/814.html
「利息日割り計算できないイオン銀行」なんと・・・・・「金利計算機能」が・・・・・「無茶苦茶」
https://www.aeonbank.co.jp/sp/news/2017/1130_01.html
「重要」キャッシングローン等をご利用のお客様へのご返金に関するお知らせ(イオン銀行ホームページ)
２４８，７７４件におよぶ「利息の取り過ぎ」
１０７，２３４，１９８円「利息の取り過ぎ」
２５万件に及ぶ「貸金業法ならびに利息制限法違反」
１億円以上及ぶ「貸金業法ならびに利息制限法違反」etc みずほのお友だちイオン
*「ニュース解説」イオン銀行のシステム不備によるイオンカ―ド過剰請求、新たに約１万７５００人に返金
今回、全ての調査が完了したと発表した。返金総額は４０００万円に上る。
http://itpro.nikkeibp.co.jp/atcl/column/14/346926/032700905/(日経コンピュータ、日経XTECH)
*イオンカードで大量「過剰請求」システム障害「10年放置」の犯罪的所業
https://www.sentaku.co.jp/articles/view/15896(雑誌選択、選択出版)
「利息日割り計算できないイオン銀行」なんと・・・・・「金利計算機能」が・・・・・「無茶苦茶」
２４８，７７４件におよぶ「利息の取り過ぎ」
１０７，２３４，１９８円「利息の取り過ぎ」
２５万件に及ぶ「貸金業法ならびに利息制限法違反」
１億円以上及ぶ「貸金業法ならびに利息制限法違反」etc みずほのお友だちイオン
GAFAに無いリアルな強みを活かすイオン金融部門
https://diamond.jp/articles/-/263776
この2人まじで言ってるのか
日割り計算できないシステム
なんと・・・「金利計算機能」ができないイオン銀行・・・・・「無茶苦茶」
https://www.aeonbank.co.jp/sp/news/2017/1130_01.html
「重要」キャッシングローン等をご利用のお客様へのご返金に関するお知らせ(イオン銀行ホームページ)
システム投資1000億の無駄使いに経営陣がコロコロ変わる原因がこれ＊金融庁もお仲間みたいね 銀行に派遣されているエンジニアの大半は、技術よくわからん人ばっかりだしなぁ 30回から999回に変更とか、30 倍のエラーリトライ増やしてとうすんの？ >>300-302
ガセはアカン
イオン銀は日立のNEXTBASE
ぐぐってみ >>68
日本の文系役員が多すぎるんだわ。みずほなんて、役員ポスト残しすぎ。 >>305
俺当時勤めてた会社に入って2ヶ月でみずほの統合作業にぶっこまれて1年半ほぼなんの指示も無かったよ こんなになっても絶対改善はしないんだからな
上は責任のなすりつけ合い、
頭取たちは自分の退職金しか興味ない、
洪水よ我が亡き後に来たれ、を地で行く連中ばかり >>316
日本の縮図だよな。東芝の粉飾決算もそうだったし。
「俺たちだけ大金貰って逃げ切れれば、後は会社（国）が
どうなろうが知ったこっちゃない」
が官僚から政治家、大企業役員まで、殆どがこのメンタリティ。
原発中抜きもカビマスクも同じ。日本がどうなろうが、私服が
肥やせればそれでいいというサイコパスばかり。
そろそろ日本にもスターリンが必要なのではないか？ >>317
そこで独裁者を待ち望むのも日本人的だよなw
自分の頭で考えたくない、自分は何もしたくない
そういうとこやぞw >>132
給料用は三菱
あとはネットのSBIと楽天使ってる
ぶっちゃけメガバンは三菱一択じゃね >>318
ふむ、その前に革命だな。俺も賃貸住まいだから革命のときには
革命軍につくけどな。 >>39
データベース知ってる人間の基準がSQL書けます、だったかもしれんぞ。 >>311
クレジットシステムは富士通だよ
きちんと調べろ・・
銀行日立システムとクレジット富士通システムの合作だ >>311
イオン銀行日立システムじゃ融資が伸びなくて
イオンクレジットシステムを統合したのがイオンフイナンシャル設立と共にできたイオン銀行カードだ
きちんと調べろ >>311
こりゃみなイオン銀行カードの富士通システムだ
https://www.aeonbank.co.jp/sp/news/2017/1130_01.html
「重要」キャッシングローン等をご利用のお客様へのご返金に関するお知らせ(イオン銀行ホームページ)
２４８，７７４件におよぶ「利息の取り過ぎ」
１０７，２３４，１９８円「利息の取り過ぎ」
２５万件に及ぶ「貸金業法ならびに利息制限法違反」
１億円以上及ぶ「貸金業法ならびに利息制限法違反」etc >>311
ちなみにイオン銀行持株会社の代表取締役社長はみずほから来とる >>1
PDFは全部「許可しない」なのに全文引用できるの？ (-_-;)y-~
末端の機械(ATM)の速度が遅すぎるんやと思うけどな。
でも、
経営陣は減価償却の終わってるHDDやDDR3を捨てたくないセクシーなエコ信者なんやろ。
なので、今後も大規模障害は発生する。
こう思うんやがな。 あと20年もしたら今の高齢者いなくなるんだから、いまのうちに通帳とカード不要なシステム組んだほうが勝ち組～ 金勘定している組織でコレだからな(´・ω・｀)
一番楽して儲けられる連中が能スカスカ。 これでもまだ業績が落ちれば給料が減ってゆくゆく営業が成り立たなくなるからまだいい
税金だけで食ってる連中はこれ以上に酷い >>223
テーブルスペースをインデックス専用に割り当てることはある >>333
最近外部disk使うからあんまなくね？ (-_-;)y-~
稼働中のATMの全HDDとメモリを交換、T中さん中抜きも含めて、総額500億円です、
ダメ！絶対ダメ！
そして、また障害を起こす・・・ 文字化け見たいな事になってるのは俺だけなの？
読みにくいんだけど プログラムのことなんか全く分からない法学部・経済学部卒のお偉いさんがいっぱいいそう。 僕が思うにハイパフォーマンスを持つビモーターのキャパシティがピーキーなエキゾーストノートとクオリティの高いテレスコピックフォークとモノショックのバランスがヘモグロビンだと考えるね (-_-;)y-~
末端の遅い機械に合わせたプログラム組むと、
中央の処理速度も落ちるのは当たり前なんやが、
これを許さんわけやろｗ
今より遅くても確実な処理プログラムだと、経営陣の実績に関わるわけで、
前回のプロジェクトが失敗だったということになる。 >>334
外部diskとはFC接続のストレージ装置のことか？
病的にパフォーマンスを気にするなら、玉やバスを分離するとこまで突き詰める >>342
そうそう
外部diskって入れたdiskの数だけ速度が上がるものじゃ？
わざわざ分けてやるのは速度のためじゃないのかなぁ？
おれはあんま大規模やったことないからよく知らないんだけどさ >>337
大丈夫。
理学だろうが工学だろうが大規模システム初めてなら同じだから。
むしろ契約書の穴潰しできるのなら法学部は役立つ。 >>20
1個人と会社組織を同じ土俵で比べるって何なの？
まともにみずほ擁護出来ないなら黙ってなよ みずほのシステムがちゃんと動いている方がむしろ奇跡。 >>233
みずほさんは知りませんが。
リソースは常にギリギリ100%、余裕なんて一切持つなと役員から檄が飛ぶ。
それがコストカットに全てを賭ける今の銀行ビジネスです。 >>291
さんMINORIとか言うと危険でっせ。何を召喚するか知れませぬ。コロナシステムから何から🤫 みずほじゃないが受け入れテスト時にオラクルのレコード上限値を越えた話があった
設計時に気づけないんだと呆れたのを覚えてる
上層部が和製コンサルに騙されて情シス担当無視して突き進んだらしい
その和製コンサルは上場企業でほかにも訴訟沙汰になっている
ＩＴ音痴のバカ社長が企業破滅に向かわせることがある >>337
プログラムが分かっててもなぁ
原理原則が分かってない人がやれば、どのみち同じ事なんだよ
論理っていうのはそういうモノ >>1
>エラー回 数の上限を大幅に引き上げる変更(30 回から 999 回)、
>事実上の取引サービス禁止の解除措置)を行った結果、
ここらへんはインターネットプロトコルにならって
３０回 →６０回 →１２０回、みたいに倍々ゲームにしないのかね、
何を根拠に決めたのかね、昭和５０年代とかの話だったりして。 >>145
怖いよーこういうのゴロゴロ仕込んで7000億システムなのかなぁ
まさに船頭多くして、だなぁなんも革新的安定性を感じない、
昭和のニオイすらしてくる、、、 今はディスク容量、金さえあればほぼ無限に出来るだろ そもそもみずほは、朝鮮半島の為に、
作られた銀行だから日本の銀行とは
目的が違う。
だからLINEやサムスンなど韓国企業への
融資が多い。韓国経済がヤバイと
みずほもヤバイと聞いた事がある >>312
理系が考えて仕事しないから、こうなってんだろ？ 長い。Ａ４一枚か二枚でまとめないと。
ビジネス文書の基礎がなってない。 ゲームとかなら一から作り直した方が早かったりするけどね
銀行の全ての業務を把握してる人が銀行側にもいないのが根本的な問題じゃないの？ >>364
みずほの中の人じゃないが、流石にいないことはないと思う。
ただ、銀行の中では元々、システム開発は成功しても評価が下がる、
失敗すると鬱退職を余儀なくされるほど猛バッシングを受ける業務。
それに加え、最近は配置数を今までの半分以下にすべく上層部が騒いでる。
なので、優秀な人はアサインされないし、そもそも人数も絶対に足りない。
今なら同じ畑でもRPA（AI）を触る業務に人気が集中してる。
業務には役立ちそうにないけどシステム開発部隊より待遇が数倍良い。 今のやり方じゃ永遠に起こるんじゃねこれ
開発環境を見直すべきだよまず
ベンダー集合体なんて無理。デグレ起きまくり。 おまえら銀行の決済システムに SQL なんか使ってるわけないだろ
一日分の決済を溜めて、夜間にバッチで更新する
そもそも業務がそうなってるのにSQLなんかで即時更新したら業務の実態とあわなくなるじゃん 韓国に5000億貸し込んでる馬鹿銀行
日本から出て行けばいいのに どうせシステム作る時も思いっきり人件費と時間削って突貫工事でやったんだろ？ｗ >>146
三菱の方が使い勝手もサービスも悪いから解約したよ
なんなんだ >>119
でも実際に
できるエンジニアって普通の100倍くらいの効率で仕事進められるんじゃね？ 例の大規模プロジェクトは成功した扱いらしいけど、この様でww >>373
今は仕様そのまんま作る奴だけだろうしな
昔なら業務概要も把握してる人（何年もいればそりゃ分かる）も多く（人たりないときは仕様書作成にも駆り出されてた）、設計者にコレは他にバグ出るよってＰＧレベルでも出来てた
単純にプログラム書けるだけってことでコロコロ人員変えるとこはヤバい
てか、そうなった 限界テストをやってないから、限界超えると何が起こるか分からなかったんだろうな
まあ限界テストは面倒だから、初期設定でリソース増やしておけば大丈夫だあwってなるしな 金融庁「ソフバンにやらせたほうがよくね？」
こう思っても不思議でもなんでもないな >>1
プギャーmp
ほんとにダメなシステム組んでるよな
インデックスファイルオーバーなんて小さな口座情報を
一気に転送させすぎてんだよ
そこに新規口座作ったり口座の管理情報変更したから落ちたんだろ
すげえなぁ
さすがだなぁF
なんびとたりとも、なんびとたりとも、
俺の前をはしらせねえ！ >>376
エラー吐くけど、
なんかの間違いに違いないのでオフするんだよ
こういうとこ 東証のトラブルはは
「ストレージ装置のデフォルト値が勝手にマニュアルから変えられて挙動が変わったのを
ちゃんとテスやって自分で見つけろ」（そうすればトラブルが起こらなかった）という若干の無理難題だったが
このみずほのは普通に水準以上のSEがデータベースの設計と運用やってれば１００％起こらない >>384
普通に水準以上じゃ無いSEなんだよ
文系上がりの官僚型SEなんだわ
最後にはお前の会社を潰そ位の勢いで来るからww >>384
見積もり以上のインデックスになったんだろう。どこかのインデックスが。 PDF見てみたけどINDEXファイルは処理速度向上のためメモリ常駐の仕組みなんだと
それが割当メモリ100%使って更新できなくなった
なるほどねーディスクだったら足りなくなるわけないものな これもコロナ災害なんよね
強制紙通帳廃止なんてやるから 安全装置を外してコスト削減しました！
ってのが文系の手柄だもんな >>390
パフォーマンス改善のためにIndexをメモリ上に置くように変更→Indexが溢れる→「こうすりゃ直るぜ」メモリ上のIndexと関係ないストレージのパラメータを現場で勝手に変更→カードキャプターみずほ爆誕 誰一人中身わからないまま巨大システム運用してるんだな
こういうのって生き字引みたいな爺がいてそいつに聞いたらわかるみたいなのないのかな >>390
詳しい説明資料が出る前の
みずほの少し前の説明資料みたら拡張できなかったインデックスを「制御系ファイル」とか書いてて
自分で勝手にインデックスはって勝手にオンメモリにしたくせに
ボンクラが設計ミスじゃないってことにして押し通そうとしてた形跡が見てとれて見苦しかったw 日本の契約文化はランプサム契約なの、これがIT発展の阻害要因になってる。
見積もりを出したらその金額で確定する契約
海外はコスト・レインバース契約
最初の見積もりなんてほとんど意味がない、増工、仕様変更はもちろん
コスト変動は施主の負担になる。
日本人には理解不能だと思うが、極端に言えば
契約後にスタッフの人件費が上がったらその差額も施主に請求しちゃう
だから海外は発注側は防衛のため見積もり仕様書を緻密に記載する
日本では詳細設計レベルまで出来上がってる。
コレに対して明瞭にデビエーションなりをつけて見積もり出さないとさすがに追加請求はできない。
ところが日本はランプサムだからザル仕様書で発注する。
施主優位だから元請けが追加請求を言い出しても最後の最後は下請け呼びつけてｺﾞﾙｧすればいい。
ところがこれでは発注側も学べない、技術に適応する動機やインセンティブがない
責任まるっと丸投げでいいんだから
今回はインデックスファイルのメモリー展開が主因みたいけど
これとてこの仕様や意思決定が曖昧なのは想像がつく。
海外だと見積仕様段階でアラートの設計閾値や対処まで明記されてるわ >>397
んな貴重な人は居ない
使い捨ての爺いばかりなり メモリ管理は難しい。
マックもウィンドウズもスマホもフリーズする原因はたいていコレ。基本的にRAMのやりくりが滞って起こるが、みずほのコレはそれじゃないっぽい。
単純に記憶装置の容量不足だとしたら本当にクソ。 >>401
SAIL/ESAで動いてるんだから、通帳なし口座への切替なんてバッチジョブを動かすなら、
JCLで別にメモリ領域を確保しろよwって話だ
バッチをオン共通基盤で流すバカがどこにいるよw >>336
Unicodeは、何通りかの正規化のパターンがある
Mac等で採用してるのは、「だ」を「た+゛」で表すパターン
Windowsなどでは、それを再正規化しないとこういう表示になる
と推測してます 1GBくらいのデータしか突っ込んだことないから、
rdbのインデックスのメリットがいまいちわからん。
この列を必ず検索するから速くなりますよ、って機能でしょ。
一つのテーブルにその列分インデックス張っても結果は良好なのかしら。 >>405
みずほ銀の勘定系は階層型DB（IBM IMS）なんで、RDBで言うインデックスとは意味合いが違うんじゃないかと
https://ja.wikipedia.org/wiki/IMS
おそらく、トランザクション実行前のデータを一時保持するワークテーブルのようなものじゃないかな 頭取から社員まで全員見て見ぬふりでヨシしないから
一番下の現場が仕方なく無理矢理ヨシしたら大惨事という >>407
なるほど、トランザクションに特化したデータベースがあるんだね。
レストランで注文受けたけど、座ってる客の多くが待てど暮らせど料理が来なくて
カウンターに注文票があふれて
そのうち一枚、二枚と床に落ちる的な？ 報告書を読む限り、障害当日にインデックス領域の拡張を終わらせているみたいだけど、
これって、問題の先送りをやっただけだよなw
またやらかすに1票だわw
おまとめや口座一括移行みたいな臨時・随時ジョブは、オンや日次・月次の定例ジョブとは別の領域を用意しないと、
何の解決にもならん
昔は当たり前だったんだけどな >>410
並べた注文表(調理中も含む)を文系が任意に捨てて
既に調理中の注文表と辻褄がわなくなって死亡 間に入るコンサルやPMが本番のピーク件数とか計算して要件決めろとか言うくせに、
開発現場はまったくそういうの考慮せずに作ってることはよくある
大量トランザクション流すテストでインデックス溢れ起こしてふざけんなって怒ると、
当初の設計にないからと追加の予算を要求してくる なんでも現場の責任にしてる限り解決しない
上流の責任だ >>415
逆だぞ、上流が想定してないからこうなる
予算決めるときにこういうこと考えたか？って話よ
下流工程で優秀なやつがいて気づいたとしても無かったことにされるのがSEあるあるだから 上流のやつらが予算ガーと言ってる限り無くならないよね >>419
そりゃ下流に考慮する予算と期間を与えてない上流が悪い
つじつま合わせを下流にやらせてる自覚を持たないからいつまでも改善しない 前はこれで解決出来たんだから、これで解決できない新システムが悪い。
と言う考え方。 >>189
2002年も銀行色弱いIBMでやる予定が銀行の取引先である日立や富士通も使わざるを得なくてグダグダになった
半年以上に当時の富士総研や第一勧銀情報システムはこのままでは4/1の本番は無理と銀行に伝えていた
それでも銀行のシステム担当役員がもう発表してるから絶対に4/1本番は変えないって潰された
で、今回も結局マルチベンダーで前回の反省を全く活かせずグタグタ
みずほ情報総研の連中は丸投げして使いもんにならん 新しい銀行を立ち上げて
順次移動していただいた方がいいのでは？ >>189
あと何故かIBMを評価してるけどかなりやらかしてるからなあそこ
クレカ会社のシステム更改でリリースまで1年も切ってシステム間のテストやるのに全然対応できてないからおかしいと思ったら、全然開発できてないからリリースを2年延期させてと言ってきた
で、協力会社などに金全然払ってなくて訴訟沙汰にもなった
消費者金融会社のシステムでIBMの担当者が月末日今日でこの現場最後ですみたいなことを客側にも平気で言ってきたり、開発トラブっててもろくなサポートしないからユーザー側役員が怒ってIBM切ったりなどなど
他にも色々あるけどね >>415
いや、1日あたりの想定増加数などは現行システムを元に算出して開発側にも伝わってる
それに基づいて性能試験などしてるからな システム「ごめん。このままだと落とすけど、どうする？」 >>428
上流が予算と期間を取らないからだろ？
下流に責任を押し付けてる限り失敗は続く
テストしてくださいというならテスト期間を今の10倍くらい用意しろ >>431
いや俺の担当してたところは全然余裕のスケジュールだったよ
むしろ周囲が遅延しまくってた関係でやることねーなって日もあったくらい >>425
外資にいたことあるけどマルチベンダーサポート契約は保守内容として普通にある
IBMでもHPでもマイクロソフトでも頼めば全部責任持ってくれる
バラバラに契約されると誰も責任取ってくれないよ
そのほうがまとめるのはみずほ情報総研さんね、となるから責任逃れできておいしい
>>415
間に入るコンサルが曲者でなあ
技術力もあってこうやって算出するんだとレクチャーするべきで、できないならコンサルとしての存在価値がない
日本は再委託や請負で入ってきた怪しげなコンサルで炎上する仕事ばかり
素人幹部が騙されて情シス無視して送り込んでくるケースとかは地獄になる
そもそも開発要員が多重請負でどこの会社の所属か全くわからないのはセキュリティ上ありえない
中国人とかまともな通訳なしでやらせてたりするからコメントも難解でいずれ保守で詰むだろうなという・・・
誰もやりたがらないので外国人入れてるけど外国人も嫌がってる もう少し読みやすい文章にしてくれませんか。
自分のところにこんな報告書が来たら、即刻書き直しを命じてるわ。 >>433
「テスト」に必要なお金と期間を用意しなければ人員をリリースしちゃうからそれじゃだめ みずほだけしょっちゅうトラブル起こしてない？
こんなとこに金預けられないわ >>434
2002年はIBMだけにするって決まってたんだけど、銀行の役員から日立や富士通も使えって強制されてああなってしまったんだよ だいたい本番データみたいなテストデータつくるのどんだけ手間かかると思ってんだよ。
1年とか余裕で必要だよ！
本番データでテストさせろよ 移行の全件テストとかはしていると思うけど同時に動く処理系は違うからな～。優先度の高い処理系が並行に動いていたら移行とかワリを食いそう。 >>439
ちょうどそれよりちょっと前に情シス子会社リストラや解散している銀行がかなりあったんだよな
それでシステムのことわかる人間が残っていたらよかったんだけど
>>435
原因の一つに国語力の問題もあると示したかったのではないだろうか
このような文書で要件定義や指示を出しています、ってことだから
文書出すのが遅れた理由も書ける人間がいないんだろう
コミュ力言ってるベテランオジサンほどコミュ力がない 自動閉塞してるのに、解除されるとか
システム作ったがわもう呆れてるやろ 対応策
タイムリーな判断ができる組織づくりって
お前らが勝手に判断しないのが最善なのでは… >>447
濁点の位置で全く違…わないな、やっぱり システムがやばいのはみずほだけでないと思う
11億抜かれてすぐ気づかない銀行もすごいし抜ける状況もすごい
https://www.dailyshincho.jp/article/2016/10290559/
11億円詐取の「三井住友」元副支店長 “企業内リンチ”乗り越えの経歴 >>75
その投資の何割が実働者コストなのかな？
こうゆうの失敗の繰り返しは、費用もマンパワーも
間接的な部分で無駄消費してるとしか考えられん。 最善の策は銀行員が運用や障害対応関わらないこと。邪魔なんだよ。 >>410
COBOLの世界の話なんで色々概念違う
DBの最大レコード数が設定してあって
プログラム内でそれを越えないように最大件数を定数で持たせてた
で、DBの設定変えずに、プログラムの方だけ大きくした、みたいな話 >>1
システムって誤魔化しきかないからなぁ
それと反してソースコードはなんだかんだで誤魔化せて、
アヤしいなという部分は委託という形で外注・派遣にプレゼントして、
１か月ほど触らせて「あ゛壊したネッ」なんてアホやって済ましてるから、
こういう事になるのサ（一般論ネ）。
日本の企業システムが全くソフトウェアに会ってないよね、、、 酷いな。内部統制は報告が無いから完璧、みたいな評価なんやろな。 ３．１１の災害のときにみずほのＡＴＭが止まって預金封鎖かとおもったが
今思えば素でトラブってたんだろうな サグラダファミリア完成と思ったけど、ただのハリボテだったみたいだな >>462
なるほど
トラブル起こせるようにしておけば預金封鎖でも安全な銀行経営ができるね みずほはゴミの集まり
電通、パソナ、みずほ
利権ビジネスの代表 >>460
派遣のせいにしてもかかった時間は戻ってこない
指揮命令やコードレビューもしていない丸投げなら偽装請負
顧客がバカでない限り派遣のせいにして終わりにはできない
建前上派遣を指揮監督するのは派遣先だから
派遣会社は責任を取らなくていい無敵な業態
仮に派遣社員に責任があっても弁済できることは少ない
企業側としては業務委託のほうが都合がいいよ
委託は委託で委託先がクズだとクソ野郎問題みたいなのが常態化する 金融系、勘定系システムなら裏で1か月くらい回し問題ない確認してからリリースするだろ
Webに行って長いこと経ったが金融系の奴ら脳死でレベル下がりすぎ、昔はみんなやっとった >>451
大胆すぎるw試算して何が起きるかすら考えてなさそう
今もCOBOLやってる奴ならAIコーダーのがまだマシかな ■ このスレッドは過去ログ倉庫に格納されています
