(略)
インデックスファイルがメモリー容量を超過
報告書によると、2月28日のシステム障害の発端は勘定系システム「MINORI」の一部である「定期性預金システム」のデータベース（DB）でトラブルが続発したことにあった。1年以上記帳がない定期預金の口座約45万件を、通帳を発行しない「みずほe-口座」へ一括して切り替える処理の作業中に、DBに存在する「取消情報管理テーブル」のインデックスファイルのサイズが、確保していたメモリー容量を超過した。その結果、DBの更新処理ができなくなった。
定期性預金システムのDBで更新処理エラーが続発したことをきっかけに、MINORIの司令塔に当たる「取引メイン」と呼ばれるシステムで、さらなる不具合が発生した。取引メインは定期性預金システムで起きたDB更新処理エラーに対応するため、その更新を自動的に取り消そうとした。しかし取り消し処理に必要な情報が定期性預金システムのDBに残っていなかったため、取り消し処理自体がエラーになる「二重エラー」が発生した。
MINORIは取引メインで二重エラーが相次ぎ発生すると、システムの全面停止を防止する措置を自動的に開始する。具体的には、勘定系システムに対するトランザクションの入り口にあたるATM処理システムや、みずほダイレクトの処理システムが稼働するメインフレームのパーティション（区画）をシャットダウン（閉塞）することで、トランザクションを抑制しようとした。ATM処理システムのパーティションが次々とシャットダウンしていった結果、ATMにおける通帳やキャッシュカードの取り込みが発生した。
2月28日のシステム障害の原因は突き詰めると、定期性預金システムのDBにおいてインデックスファイルのメモリー容量超過にあった。「一見初歩的なミス」（報告書）だが、その背景にはシステム運用における大きな問題があった。
次ページ
富士通製DBMSに特有の動作
https://xtech.nikkei.com/atcl/nxt/column/18/00001/05715/
ただし、ステータス変更自体は「それほど難易度の高い作業ではない」（片野常務）。データベースのテーブルにあるレコードのステータスを変更するだけだ。MINORIで定期性預金システムを構築したのは富士通であり、データベースは同社の「Symfoware Server」を用いている。簡単なSQLでステータスを変更できるはずだ。
https://xtech.nikkei.com/atcl/nxt/column/18/00138/030500746/ 富士通のスマホは、壊れまくった
以後、このメーカーは、信用できなくなった
なんだみずほじゃなくて富士通が悪かっただけじゃん
これみずほ叩いてた人どうするんだろ
インデックスの肥大って
db再構成で治るんじゃないの
他社に押し付けるための言い訳の設計と開発と運用だけは一級品だな
処理量とメモリ必要量を事前に予測するのが難しいんだよ
結果から直すのなんかは簡単だ
見積をケチる馬鹿が原因
トラブルなんてこんなもん
後から冷静に分析すればあっさり解決出来るほど
簡単な原因だったりするがトラブルが起きてるときは
冷静さを失いがちだからそんな分析してる余裕がない
日本製のナイフで無差別殺人をした〇〇人が「ナイフは日本製」っていうようなもん
お前ら日立製作所のせいとか言ってたのウソだったのかよ
メモリが足りなくなったのがみずほ側の責任か、
富士通側の責任かってことだな。
俺はみずほ側の気がする。
>>16
そりゃそうでしょ。
何千万行、何億行ものプログラムの中身を全て知っている人なんて世界に一人もいないかと。 まあ、メモリとか多めに見積もっても、問題が出るまで削られるもんだw
メモリの容量が足りなくなるとか、今時メモリーデータのロールイン/ロールアウトの機能がないのか、エラーメッセージで終わりか
オラみたことか
富士通ならオラクルだって使えただろうに
>>26
十数人のチームですら「あいつがつくった書類は絶対に読まない」みたいなアホがザラにいるのが日本の組織
ましてや競合他社との合併による人間関係の溝は地球が終わるまでなくならないだろう 明らかにメモリー容量超過が問題だろ。
預金口座を移動させたみずほの担当者はアホしか居ないのか？
富士通エフサスで働いたけど最悪だわ潰れろよこんな会社
ステータスの変更が難しくないとか草
そのへんのウェブアプリじゃないんだから
前日60万件は処理できた
当日70万件でメモリ不足で大障害
「メモリーについては5倍に増強した。これにより現在は復旧している」
5倍に増強だぞ。アホだろ？
これこそ見積も何もない。安心の5倍w
こんな対応するなら最初からケチるなよ
振り込まれた給料が少ない原因はこれか⋯
みずほめ…
>>20
全部知ってる必要があるようなプログラムは不味いだろ
俺が言いたいのはリソースが有限なんてことは当たり前なんだから それが制限になる点については知っておくべきだろって事
ガソリン切れたらクルマ走らなくなるよレベルの話でないのこれ >>1
そもそも、みずほの正体を知ったら怖くて金を預けられないはず
この銀行はもうダメだな
完全に
情弱者のみが預ける不良銀行ではないだろうか >>13
やるべき事はわかってたんだし考慮漏れじゃないのかね?
テスト不足かと こういうのは大体ヒアリングかけて1日どれくらい取引あるかとかバッファ持って多めに何件までは行けるようにしましょうかとか決めるんだよ
その見込みが甘かったわけだろ
行員側の知識不足だと思うが
銀行の合併が多かったがみずほは分割して再編した方よい 悪い合併
非機能要件の定義ミスじゃねーか
非機能要件は残念ながら発注側は責任持てない領域だから、ベンダーが全責務を負う必要がある
つまり富士通がアホ
前に一度システム組んだけど
何やっても糞遅くて二度と触りたくないDBだわ
これの問題点
一括で通帳なしタイプに変更する
取引ない口座だから通帳なしタイプに変更すらしていないだろうとの判断で
すでに通帳なしタイプにしてある口座を通帳なしタイプに一括に変更するなんてやってるからだろ
>>43
大量データテストの想定件数が間違ってたのが直前原因だろうね
それにしてもメモリ量もギリギリすぎるけど > MINORIで定期性預金システムを構築したのは富士通であり、データベースは同社の「Symfoware Server」を用いている。簡単なSQLでステータスを変更できるはずだ。
構築の話を書いてるがそもそも裏で別作業しても正常に動くような作りにするだけの冗長性を持たせる設計にはさせない方針だったはずだが
>>1の内容を読んで単純に富士通のせいにしている奴はITオンチ >>1
銀行が合併する前のシステムをそのまま並列して運用するなんていうシステム的アクロバットをやらせた経営陣は健在のようですなあ >>56
だってシフテムもdbもハードウェアも富士通でしょう？ >>51
リリースが迫っていて結果の決まったテストをやった…とかではないと信じたい >>1
インデックスに残っていなかったから取り消し処理も失敗したってだけの話だろ
根本は容量の部分でしょ
設計時の見積もりが甘かったせい
この部分は銀行側が明確に提示しないといけない部分
いくつもの報道で流れている通り、銀行側が技術的なことを折衝できる人間を用意しなかったことが悪い
業務を理解している人間が銀行にいなかったとか、そりゃうまくいかなくて当たり前 >>59
みずほが設計時に想定してない運用をした可能性もあるし
だとしたら運用を基準にシステムを用意・設計する富士通に罪はないよ 処理件数の見積も足りなければ
メモリ割当の見積も足りない
前日60万件処理できて当日70万件はメモリ不足ってどんだけギリギリの設定してんだよ
作業計画がどうだったのかね〜。1年以上使っていない45万件を一括で処理したんだろ。本来はその日に1年以上未操作となる口座が処理対象とかとする仕様だとする。
すると通帳扱いから消させるのは最大数万とかだろう。だから取消テーブルも数万で設計する。その処理に過去何年分も放り込んだら落ちるのは目に見えている。移行費用をケチって上層部を飛ばすとかお笑いの世界だな。
うんにゃ、統合に際し古いシステムにこだわったのが原因だろ
他も似たようなもんだろうけど、本体や冠が付いている子会社に依頼しても
プロパーは50人に1人位の管理要員だけで
後は何処の馬の骨か分からん外注がせっせと設計や構築やっとる
>>67
オフラインの夜中にやろうとしたら終わらずに翌日営業時間にずれこんだとかじゃなかったか？
週末にやればセーフだったのかもね プライドの高い連中が合併なんかするからこういうことになる
みずぽで運用してたんだろ
今更おっかぶせの言い訳するな
DBMSの問題なのか？、プログラマー側の問題なのか？
銀行システムなんだし、実装メモリはソコソコ積んでるんじゃないの？
昔のソフト開発ならプログラマが明示的にmallocしてダメならエラー処理に飛ばす、とかの必要あるけど、
こんな昔とは違うんだからメモリ管理くらいOS側でやれないもんかねぇ
>>7
問題あるから運用でカバーしなければいけないシステムってのは、割と多いので。 >>66
本体は高いだけで使えないけど、関係会社で付き合い長いところは優秀な人が多い印象
体制変わってこの先どうなるか知らんが 定期的にデータベースをコンパクト化するような
仕組みだったんだろう。それを怠ってただけな気がする
>>73
処理に不安があったのでindex部をメモリーに作った。こういう設定が出来るという事はメモリー不足時の処理も当然付属だと思うんだけどね、何のためのOSかって思うよね。 >>75
ＩＴ上流「メモリ？クラウドＡＩの５Ｇでいいっしょ？支払いはビットコインのクラファンで」
こういうトンチンカンな会話の積み重ねでこういう基礎的な問題が起きる これプログラム上のメモリーじゃないの。
バッファが足りなくなっただけじゃないの。
朝鮮ダークサイドに堕ちたみずほ銀行
東芝やシャープに続き自壊しつつある富士通
かつての輝きを失った巨大企業の末路
上から下まで富士通製なら、そら富士通が悪いで済む話なんだけどな。違うだろ。
どうせみずほが予算ケチりまくり無茶な要求したシワ寄せだろうな
>>74
なぜその運用してるのかの理由は継承されないからそのうち事故るやつな >>79
インデックス使えないとプログラムは正常に動くけど処理時間が1万倍掛かる状態になって、
結局は周りにタイムアウトやロック獲得失敗みたいなエラーを量産する事態はあるけどな。 >>1
何でIBMベンダーのはずなのにUDB使ってないんだよｗｗｗ
もしかして日立のHIRDBやNECの、NECの、(知らない)データベースも混合で使っているだろ >>82
そんな単純な話を「私は悪くない」という文書にするためのあらゆる技術が駆使された日本企業文学だぞ
作者の気持ちを考えよう 富士通は要求された仕様の通りのものを納品しただけだろ
俺がゲームでラスボスに勝てないのは開発した任天堂が悪い！
って言ってるようなもんじゃないか
これをわざわざ今年の2月末にやろうとするバカジャップww
おれじゃない
あいつかやった
しらない
すんだこと
業務系はその業務を理解するのも仕事だから。
いわれた通りのものを作ればいいってもんでもない。
半分コンサルみたいなもんだよ
シンホォウエアなら今の若者には運用無理じゃね？あれRDBじゃないし。
イメージとしては、pcでメモリ4GB、スワップ自動にするところをスワップも4GBで固定していた。Word、Excelくらいなら問題なかったが、動画編集したくなって動画エンコードしてフリーズ。しょうがないのでスワップ無制限にしたらHDDが 40GBしかなくてしばらくはしのげたが、また止まった。
ノーコードもこの辺理解しないと待てど暮らせど返答のない画面できるよ
メモリが足りなくて落ちるとかアベンドとかMinoriって結局メインフレームなんだな
もう、このシステム
誰も全体把握してないと思うよwww
設計仕様の上限を超えてパンクした
あるいは設計通りの設定がなされていなった
「旅客機が飛行中に燃料切れ」レベルの障害では？
>>101
みんな引退してるし、この世から引退してる人も少なくないし >>90
作者の気持ち（この作品が売れて教科書に載れば食っていける） >その更新を自動的に取り消そうとした。しかし取り消し処理に必要な情報が定期性預金システムのDBに残っていなかったため・・・
OSのエラーね
正直、ハードウェアに最初から潤沢に
投資しておけば防げる障害って多いと思う
人件費より安いと思うんだが
障害発生して対応するコストを考えないのよな
原発と一緒な感じがする
数年前にみずほ銀行口座解約後みずほ銀行のサイトから自分の口座を開いたら
何故かまだ開くことができたのでみずほ銀行に連絡した記憶がある
今はどうなってるか知らんが
>>109
ロールバックデータが残ってなかったん？ 最近の不祥事見てるととても機械のせいにはできないだろ
自浄作用が働かない企業なんじゃないだろうか
インデックス設計は糞な開発者がやるとほんとに糞なもの作るからな
DB冗長化とかもやってなかったんか？
基盤設計ちゃんとやったんか？
>>110
ハードウェアって謎の力でバカ高いだろ…… 情報共有システムにハッキング食らって情報漏洩とか
糞DBMSとか、富士通終わってるな
>>113
「取り消し処理に必要な情報が消えた」というアホな仕様なんじゃないの 問題
データベースソフトはどれ？
１．三四郎
２．花子
３．五郎
>>117
ソフトの方が原価ないのにライセンスとかアホみたいに高い 富士通は昔から稼働時に運用出来る最小限のシステム構成を提案してきて
1年もするとCPU、メモリ、ストレージ総取っ替えになる、移行やソフトウェアの入れ替えで他社より結局、物凄く割高になる
>>117
今回までの騒動の事後対応費用と比べて
どうかな…高いの買っても良かったんじゃないかな…
国内最大？の銀行だし >>70
そのトラブルってシステム統合前から何度もやってよね
何度繰り返せばいいのかな >>129
アマゾンかマイクロソフトに用意してもらう方がよっぽどいい 富士通系はほんとゴミだな
SKYSEAもほんとゴミ
あんなスパイウェアを会社に入れるな
みずほ「富士通が悪い」
ぼく「みずほが悪い(運用まで考えてシステム発注して当然やろ)」
一括切り替えのリハーサルとかしなかったのかな。本番データだと膨大だから、テストデータのみでサクッと終えて、おけおけってことにしたのかな
>>119
確かに。
取り消し行はメモリ上のテーブルにレコード移すとかで、ロールバックとはそこから元の場所に戻すだとして本当に移しそうとしたらインデックステーブルはバランス木構造なのでワークが無いとそこから消す操作出来ません残念とかネ。 >>111
え？解約後すぐ明細見られなくなったら困らない？
解約後何ヶ月間はあえて見られるようにしてるのでは？
システム的にも解約後に数ヶ月ごとのメンテナンスでデータ削除だと思う。 BDSMってスレタイ読んじまった。
コーヒー飲んで落ち着くわ
>>1
問題は運用にあるのに、製品に問題があるように錯覚させるミスリードはやめなよ。 >>7
アホ
Windows98のパソコンにプレステ5のゲームやらせようとしたようなもんだ
できない事をやらせておいてシステムが悪いもねーよ なんか富士通の後始末をNTTが行う、そこにNECもついてくる
これ構造化されてない？
>>13
需要が増える時にわざわざ通帳なんとかの処理やらせるからだろ
処理貯まって残業してもムリな時に、コレもついでにやっといてなんて課長に押し付けられたら普通キレるわ
機械はキレ無いけど、こうやって落ちるだけ そもそも月末で通常処理に加えて月次処理も発生する時期に
オンライン通帳へ一気に切り替えなんてスケジュールぶっ込んだみずほのアホが原因
トラックでも積載量ってもんがあるんだぞ
オーバーして詰んで走ればタイヤはパンクするしエンジンだって火吹くわ
大手でもログやバックアップの切捨てやらないと容量いっぱいで止まりそうなDBあるけどそういう管理する人置かないよな
何行も合併して成立してるメガバンクのシステムは
複雑怪奇
これを無理に統合しようと何千億もかけてこのざまなのな
メーカーも使ってる言語仕様も各々違うから正直トラブルフリーなんて極めて困難やど
>>70
月末にやったら、他の月例バッチ処理と重なってさらにメモリ圧迫したんやぞ。 富士通ってこの前もProjectWEBとかいう情報共有ツールで個人情報流出させてたけど、みずほのプロジェクトはこのツール使って無かったのか？
>>54
記事を読むと、Indexが全てオンメモリのように読める
普通はありえないけど
大規模な作業前に普通じゃない設定に変更したかもしれない みずほは何時までも縄張り意識でシステム統合できず
下手糞だなって思ってたけど多かれ少なかれシステムなんて
不具合で止まるもんだし仕方ないなって思ってはいた。
ただ、発生したトラブルが適切に共有されないだの、
誰が謝罪分書いて掲載するかが決まらないだのってのは酷いなって
お客は神では無いが信頼関係が無くなっては縁も切りたくなりますね
>>150
わかってる有能なの置いとけば良いんだけど目先のコストで切るのが多いからね
有能なら不具合出にくく暇に見えるんだろうけど このシステムを更改するときはまた大騒ぎするのだろうか
肥大化しすぎたシステムはセキュリティも心配になる
・インデックスのメモリオーバー→よくあることとは言わないが、想定される範囲の事象
・ロールバックできない→静止点が遥か昔(バックアップ設計が不十分)orジャーナルとれてないorロールバック処理を作っていないか異常終了した
・二重エラーでシステム部分閉塞→否定はしないが、閉塞発動した後の運用設計がダメダメ
製品の問題ではなく、リカバリ設計の問題
とすれば、これはシステム全体の総点検コース
メモリだって無限じゃねーんだよ
仕様の中で大切なポイントだろ
>>3
どこをどう読んだら機械のせいにできるんだ？ 想定している最大数での負荷試験をしていなかったってこと？
日本企業にあろがちなこと
つまらないところでケチってトラブル起こすんだよね
メモリなんて潤沢に積んでおけよ
行政システムも消えたり落ちたり
富士通かどうかはわからない
ハロワのシステムがよく落ちるみたいで職員が操作やり直して愚痴を言ってた
あれも富士通なのかな
undo_retentionやguaranteeの思想も無いのか 富士通は
>>16
金融界のサクラダファミリアと言われておりまして…。 情シスがダメダメだったのか
おとりつぶしだな
全員クビ、総入れ替えすべき
>>86
オラクル
ミラクル
魔太郎がくる！！
だっけ？ うちの職場もシステム入れ替えの時に富士通にやらかされまくったわ
システムは打ち合わせ通りの物だったけど
データベースそのものがデタラメになっていて
通常運用出来る様になるまで2ヶ月掛かったし手直しは自分達に投げられるわで
富士通マジでクソ
ルーターでもサーバーでも設計がおかしくて長時間メモリ使い潰してたらバグは起きるし不確定な挙動も起きる
その場合は補償対象外
CPUやメモリ100％の状態がずっと続く場合は壊れるしデータが消えてもおかしくない
機器選定や設計ができない企業は廃業したほうがいい
自社の業務ボリュームが把握できないと誰も助けてくれない
詐欺みたいに金引っ張られて終わり
自称デジタルネイティブのゆとりに任せるとこれだよ。
口ばかり達者で若いときに勉強させてないから
脳みそは非論理の塊でDBの設計も矛盾だらけで簡単にぶっ壊れる。
いやシステムの不具合よりも
カードや通帳飲み込んで何のアナウンスも通告もせず
7時間放置した事が問題なんだが
>>174
サクラダファミリアは完成見込みが立ってるだろ失礼だろ >>185
なんでもリアルタイムが当たり前とか思ってる馬鹿がシステム開発すると穴だらけになる例。 富士通ってときどき思い出したように年俸2000万で募集とか変なことをする
自社内で人材が育たないんだろうな
>>144
安定したNTで開発可能なのに9xでシステム開発してた富士通さんだよ。 >>94
日本では不思議なことにそれはSEの仕事ではなくPGの仕事なのだ。 銀行の士気っていうか店員の態度が
バブル崩壊後、ガラっと変わった気が
するね。
やっぱ、不良債権処理とか
企業が自社株発行で資金調達
するようになったことが影響
してんのかな。
でも、不良債権ってかなり政府からの
支援が有ったはずだよね。 その後も
預金金利をどんどん下げていったよね。
最近は、ネット銀行など、他の業態からの
銀行業務参入で焦ってるのかな。 店舗が
どんどん閉鎖されて店員のリストラも多い
から、銀行員の士気が下がってるのかな。
index表領域を追加すりゃいいだけの話だけど、
Fのことだからディスクケチって拡張できない状態なんだろうね
店舗や店員をガンガン切って、ネットやコンピュータでの
業務処理を代行させるべく、大々的にIT投資をやって来た
みずほ銀だけど、相次ぐトラブルで目論見がハズレまくり
なんだろね。
領域見積もりした側の見積もりが甘かっただけで、製品やサーバ管理者のせいじゃないだろこれ
このdb使ってたんだw
うちは避けてれて正解だった
ようするにコピペでシステムを組んで節約してだけどテストしてないんだろ
>>199
いや足りなかったのは物理メモリと記事に書いてある。 銀行のくせに開発費ケチったからだろ
自業自得だからね
>1年以上記帳がない定期預金の口座約45万件を、通帳を発行しない「みずほe-口座」へ一括して切り替える処理の作業中に、
この作業の責任者が無能だったのかw
エヴァンゲリオンのアスカから
そろそろクオーターの話を聞きたい時
>>162
それそれ。
あまり問題視されてないようだけどこれも一種のバグだよね。
エラー処理に失敗して顧客データをロールバックできないとかひどい。 >>208
この処理の関連テーブルのインデックスが、いつの間にかオンメモリに
仕様変更されてたことが伝わってなかった。
個々が悪いというより、全体統制が取れてなかった 預金が消えそうで嫌だなw
年金だって消えたからないとは言えん
通帳を廃止したがってるのは当然ありうる預金データが消えたときに
なかったことにするため。
ちんぽウェア使ってたんだ
コレ中身はほぼDB2じゃなかったっけ？
今どきお父さんが富士通のfmなんちゃらを買ってきたら泣くレベル
>>131
そうも思ってセールスフォースデータを公開した馬鹿企業があってだなw symfowareまだ生きてるんかい。無理矢理自社製品で頑張りたいのもわかるけど、不都合もその分…
NはほとんどOracleだったからやりやすかったわ。
なんだRDB2のマルチベンダープラットフォーム版か
>>63
当日はは別の月次処理かなんかが動いてたんじゃなかったっけ？ 糞過ぎてFグループ内でも使わないシンフォを騙されて使うみずぽさん。いい加減金の無駄と気づけ
みずほと三菱のATMが並んでいると
三菱ATMは行列、みずほATMは開店休業というのをよく見る
アラートあがってんのに無視したんやで
エラー数が閾値超えたんで縮退運転にうつったけどわざわざ閾値あげて通常運転に戻したから被害拡大したんやで
>>233
変な報告上にあげたら怒られるから、みんな見ないふりで知らんぷりしてたんだろうな。 もしかしてシンフォってFreeSQLの類以下なの？
合併合併でシステムが複雑化してるのはみずほだけじゃないのに
なんでみずほばっかポンコツなんだと思ってたらまさか
データベースエンジンに欠陥があったとは……
富士通はシンフォ諦めれよ
oracleとMSと仲いいんだからoracleかsqlserver使っとけ
あとinterstageも売れない
システムヲーカーに資源を集中しろ
これは普通に納品したシステムのデバック処理問題が
瑕疵としての一番の問題点になりますよね。
要はDBエンジンのメモリ管理っていう半ばOSレベルの部分が駄目だった訳か？
その下でいくらコーディング頑張ってもそりゃシステム障害は止まらんわなぁ…
苦しめられたエンジニアは原因解明でシンフォに殺意抱いてそう
でも富士銀は富士通じゃないし興銀も富士通じゃないし
富士通が噛んでるとすると一勧かな
>>238
オラクルがサポート有料化して以来ポスグレに乗り換えるとこ増えてるね ・インデックスをメモリに展開するＤＢ運用
・そのＤＢに対する処理追加、メモリサイズ検証した？
・テスト実施（のはず）、でもどの位のデータ量でテストした？
・運用システムにリリース、あっ、インデックスがメモリから溢れた・・・
てなところか
>>1
おいおいおい、うちのシステムこれじゃんか。
しょっちゅう止まってるぞ。
換装の時は移行でデータ抜けが頻発した >>240
まぁシンフォ扱うときはそこまで考慮してコーティングしろってことよ
もしかしたらHiRDBとかにも似たような不備があるかもしれんし >>245
データをまともに扱えないDBってうんこ以下じゃん。 速度のためインデックスをメモリに展開するように変更
この仕様を知るものは退職や異動などであんまいなくなる
そのためメモリが検討事項に上がることはなかった(仕様を知るものが少数ながら参加してたらしいけど)
これについてはどっちかというと運用の問題と思う
なお障害対応統括部隊も引継ぎの時に消えた可能性があるとか
>>205
MySQLがいいな
この要件ならauroraの方がいい >>233-234
『エラー数が閾値超えたんで縮退運転にうつったけどわざわざ閾値あげて通常運転に戻したから被害拡大したんやで』
エラー数の閾値を超える意味が全く分かっていない。
(簡単に挙げられるのなら、ソフトで自動的に挙げてしまえば済んだんだろう？）
（どこかの大国とかどこかの超大国が、放射能漏れで、安全基準を10倍にしたのと似ている）
詳細報告書に「87％でアラートが出た」と明記。
それでもガン無視。他の警告も無視。
昔国鉄の遵法闘争というのがあって、警報をわざと出させて止めて電車を遅らせる。
別の話：なんかの機械で警報出まくって何十回も解除ボタンを押した。
本人は無意識で、押した記憶さえあいまい。最後に機械が「わかった。俺が壊れてやろう」で終了。
原発なら何千人の、鉄道や飛行機でも何百人の死傷者だろうな。
メモリーオーバーフローは、ハッキングの基本中の基本だろう。
リソース割り当てでメモリーが足りなくなるのは普通のこと（開発でも運用でも）
それが出来ないのがおかしい。
PCでもメモリーが足りなくなると、固まってしまう。
特に仮想メモリーのページング領域設定(上限がある）が少ないと固まるから、増やす
メインメモリーを４GBにしてゲームをやると死ぬ（ブラウザのタブをいっぱい開いても死ぬ） >>215
「消えた年金」というお手本があるから。
上は会社がつぶれてもため込んだ役員報酬があるし、子どもも成長済み、持ち家有り
厚生年金と国民年金があれば（企業年金が無くなっても）食うには困らない。
顧客目線？？？
この次は、オンラインがダメだったときの臨時払い出しでやらかすと予想。
とりあえず俺は預貯金を数社に分散した（10万ずつ） 防衛省で導入した富士通のシステムも実用に堪えないレベル
データベースも使い物にならない
(´･ω･｀)丸投げ中抜き中身スカスカ没落国家の末路
>>205
Oracle高いからなあ。既存の案件なら嫌々使うけど新規の案件では絶対に使わんよ。
MySQLもOracle傘下みたいなもんだから嫌だな。
俺ならPostgreSQLにする。AWSならAuroraだっけかになるかもな。 セレロンでﾞRAM4GBの社畜PCレベルのゴミだったってことか
>>24
SymfowareってPostgreSQLベースだろ Oracleは元のライセンスも高いけど、使えば使うほど保守料が雪達磨式に上がっていくのがアレだな。
>>148
ってか、通帳発行に印紙代がかかる分のコストを抑えたいとか身勝手な理由で、
記帳を1年してないってだけで勝手にオンライン口座にすんなって話
印紙代って税収だぞ、国はもっと怒っていい >>162
そもそも、メモリオーバーフローになってもお構いなしに後続データを無制限に突っ込んでくるDBMSって糞すぎる
使用率100％になった時点で後続を待たせるかアベンドするかを「自動で」行うのがDBMSが管理するトランザクションだろ >>264
日曜プログマラに人気はmysql(mariaDB)という時点で
シロウトにポスグレはちと敷居が高いということに気づいたら もっともらしいこと言ってるが処理件数の見積もりが甘かっただけだろ。
無能ななんちゃって技術者にありがちな対応
足りないなら増やせば良い
根本原因は後回しってあっという間にパンクwwww
あの、ケーブルの形状無駄に複雑にしたりするだろ。
ま、そんなもんよ。
>>267
要件がOSSのDBなんだろ。
良くあるだろ。ベンダーロックイン嫌ってOSSにして、
レッドハットにコンサル料養分にされるアホなユーザーwww
んで、RHは絶対に最終責任負わないから底なし沼www >>242
三菱UFJの窓口行ったら
専用端末にFujitsu と書いてあった
静脈認証とかかな きっとメモリが32MBの486パソコンをサーバーに使ってたんだよ。64MBに増設して解決だな。
>>1
＞ 2月28日のシステム障害の原因は突き詰めると、定期性預金システムのDBにおいてインデックスファイルのメモリー容量超過にあった。「一見初歩的なミス」（報告書）だが、
＞その背景にはシステム運用における大きな問題があった。
これさ、運用に問題があったってことは設計上確保していたメモリ量が少なかった上に、上限いっぱいになったときに仮想メモリとしてディスクを使うとかの設定が漏れてたってことかね >>101
完成発表された後なのにテスト要員を募集しているなんて話も見かけた気がした oracleとかSQLServerにしろよ
まともに売れてない未発達ゴミDBなんかを使うから悪い
>>280
synfoはもともと汎用機で作られていて、インデックス領域のオーバー時はシステムアボートがかかる仕様なのよ
汎用機だったらアボートで止まった時にメモリとかディスクを増設すれば良いけど、Unix系だとCore吐いて死ぬだけ
まあ、その辺知らんかった関係者全員が悪いって話
わいも新人の頃に先輩に教えられて汎用機ってそんな事になってんのかと思ったよ >>284
なるほどね、これ使ったこと無かったけどそういう動きやったのか
やっぱ毎回そこまで確認せんとアカンな >>285
必要な分のメモリーを確保して2倍にするのが、synfoの運用方法や >>286
やっぱ富士通は製品も人も糞やなという結論だw
解説ありがとさん >>287
ちなみに汎用機全盛期は他のメーカーのもおんなじ様な物なので、その時代の富士通は悪いわけじゃ無いよ
そんなミスか現代に出るのがアカンだけで >>284
へえー
汎用機だと各プロセスが元々デバッガ上で動いてるような感じなのかな
致命的エラーで止まってもその場でパッチ当てて続行可能？
そういうの知ってる人ほとんど残ってないんじゃないかね どの富士通が入ってるのか知らんけどエフサスから下は評判悪いわ
>>15
第一勧銀からの付き合いがあるから簡単には変えられない >>62
運用まで含めてシステムだろ
そこは運用じゃないのでしりませんって客に言えるのか >>293
やっぱ一勧なんだ
三行統合時の最大のネックは
一勧システムが飛び抜けて低レベルだったこと
1980年代の古いシステムをずっと持ち越してるようで
富士銀興銀はとっくにオラクルだった ＯＢが現ＮＨＫ会長だからな
そりゃ問題頻発だろうよ
今週の株主総会どうするの？コレとかアレ(情報流出)とか
決算では優等生の報告してたけど
？ メメントでのUnDoReDo思想が無かったという事？ 思想の問題やん。
ネットワークメインが韓国製、データベース富士通っておかしな事やるからでしょ
>>302
nwメインはibmだよ。Fjは懸賞環境とおまけ扱い。 >>291
エフサスなんて中身は外部の派遣だらけだろ >>7
これで富士通が悪いと結論する
天田の悪い奴と同レベルのアホ
が運用してたのかねぇ。 トラブル発生時の対処が糞だったのに、システムのせいにしている時点で、今後も同じことを繰り返すのだろうな。。
昔から富士通のソフトはIBMのパクリだけどパクリミスがあるからなあ
＞インデックスファイルのサイズが、確保していたメモリー容量を超過した。その結果、DBの更新処理ができなくなった。
これってオラクルDBのインデックス増大問題のことだよね
10年以上前から知られているすごく有名な問題、オラクルは対応する気はないうえに
まともに使用する人に情報展開もしておらず、問い合わせたら手動でクリアしてくれ、とかほざいてくるやつ
オラクルDBのゴミっぷりはあるにしても、富士通くらいの会社がコレを知らないわけないと思うんだけど
富士通さんのＳＩは素人がやってるんですかね？
>>309
ドヤ顔のところすまんがこれオラクルじゃ無いよ >>309
IT屋って責任問われると、こういう開き直り方するんだよねえ。
確かに我々にも問題があったかもしれない、
けどそれを分からなかったあなた方にも責任がある、
的な >>313
ITに限らずBtoBの場合大抵はそうなるよ。
双方に確認の義務がある。 >>313
通信事業者にしてもSI屋にしても平気で嘘をつくことがある
障害理由を他社や他社製品のせいにしていたりは日常的
SI屋の回答に不満な顧客はメーカーとの契約を直接契約にしておくといい
直接契約なら直接質問を投げられるから 大手銀行の場合は日次で本番／災対サーバーのログを採取して監視するチームがいる
そこから警告上がってても何もしなかっただけでしょ
銀行のシステムなんて、ただのお金の増減管理するだけで、何が大変なんだよ。
知らんけど。
みずほと富士通なら、どっちが悪いかますますわからんなw
運用に問題があったという事はシステムの問題じゃないんだろ。最近の奴らはデータ容量なんかお構いなしに蓄積しやがる。要らないデータは消せよ。
>>319
みずほの田中さんに株主総会で質問したら? Symfoware Pro資格持ちですよ。
かれこれ15年くらい触ってないけど。
Oracleが好き！
select * from teikikouza；
更改案件で元は富士通で運用してましただと、落札するのNTTしかいなくなる方程式ができあがってるわ
これだから一強になっていくのに
この手のジョブかコケた後対応ミスってデータロストするとアヒィィって叫び声上げるよね
>>326
drop table teikikouza >DBに存在する「取消情報管理テーブル」のインデックスファイルのサイズが、確保していたメモリー容量を超過
どこの素人に発注したんだよｗ
>>331
発注者が素人だっただけだぞ。
多分発注で使用決めた人はもう社内に居ないって落ちだと思う 1年以上記帳がない定期預金の口座約45万件を、通帳を発行しない「みずほe-口座」へ一括して切り替える処理の作業中に、DBに存在する「取消情報管理テーブル」のインデックスファイルのサイズが、確保していたメモリー容量を超過した。
やっぱ普段やらん処理を本番機でえいやあで流した結果やないか
定期預金なんて、そもそも１年以上記帳がないことが多いだろ。
なんで、違う通帳無しの口座タイプのe口座に
一括統合させるという運用方法が必要なのか理解できんわ。
異なる契約口座なんだから、定期預金口座DBの中で処理すりゃいいじゃん。
>>334
いきなり本番機かよｶﾞｸｶﾞｸﾌﾞﾙﾌﾞﾙ
テストしないのは異常だわ。いろいろ社内体制がおかしくなってるんだろうなぁ >>13
限界テストやれば何が起こるか事前に確認できるだろ 営業時間内に、なんでDB書き換えなんかやるわけ？
富士通とか、ここのSEってCPコマンドは使わない主義？
>>334
最初はオレもそう思ったけど、報告書のクソっぷりよく見て考えが変わった。
定期で1年以上記帳しないなんて仕様なら毎日数千件は生じるだろう。だから日次処理なら巨大きな中間テーブルは要らないとも言える。
そして実行日に一年以上たっていると言う抽出条件なら専用の移管処理は要らないとも言える。
で対象が40万件にもなる場合もあるとは考えず一気に流したらアウト。違うかな？ >>1
おまいらFにひどい目に合わされすぎｗ
恨みつらみのオンパレードやないかーいｗ いやいや、運用に問題って書いてんじゃん
システムに問題があったら
損害賠償請求するよ
流石に
>>343
最後のトリガーを押したのは運用
でも、そのボタンを用意したのは開発だな >>327
ちょっと待って欲しい
元々の富士通は札入れしなかったの？ FTの末端ベンダーと20年間事をした（こちらは末端ユーザー）
取締役か大株主とつながっているから、全部泣き寝入り。
機械の不調は全部ユーザーの責任
特に独自実装の時はひどかった。間違ったキー1個を1回押しただけでサービスマンを呼ぶ事態
それで「押したのが悪い」（マニュアルにも説明会にも何も無し）。俺が上から怒られた。
ソフト実装ミスで多数のデータが吹っ飛んでも、一言も（一字）もなし。
理由はOSのバージョン確認を未実施。俺は新バージョンで使えない事をたまたま知っていた（フリーソフトを業務用にそのまま組み込んだ！！）から、被害を免れた。それまでのインチキで身に染みていたし。
リース機械の交換時に、厳密に要求（「10年前！のケーブル1本が足りない」と文句を言う）
FTにはいろいろある言いたいことがあるが
頭取が問題
2時半に事態を知ったら、緊急連絡体制を取り、臨時役員会・最高対策本部設置準備を指示すべき。
そうではなくずっと放置プレーのまま
顧客には「みずほ＝システム障害」のイメージがすり込まれているのに、トップ対応できず。
会長昇格は保留だが、実権を握る頭取には留任する。
「みずほ＝システム障害」のイメージ強化という結果を考えれば、FG本体のトップ3-7人も交代すべき。
ファーストユーザーの仕事やったよ。Symfoware 。
お笑い障害頻発でしょっちゅうPTFかかってたわｗ。
>>338
不治痛のSEなんかUNIXにログインすらできないよ。
スケジュール管理と予算管理しかできない。
下請けや子会社に丸投げしかした事ないからｗ。 小規模システムをMySQLとPostgreSQLで作り比べてみたらPostgreSQLの方がちょっとだけ速かったな
扱いやすさは慣れたら同じだから、もう好きな方使っとけって感じだ
でもPostgreSQLは文字コードで失敗しにくいから、うっかりさんにオススメ
>>351
今はできるが以前のバージョンのmysqlはviewの作成ができなかった
ポスグレは最初っからview作成できる
だからオラクルの代わりにポスグレが選ばれる >>229
りそなもシンフォだよ。
俺はこの二行には絶対口座は作らない 個人的にはHiRDBよりDB2だな
HiRDBはあんま性能よくないんだよなあ
ソニー、NEC、シャープ、富士通、エプソン
どうしてこうなった・・・
