三重銀行のオンライン取引が半日ダウン、内蔵ディスク障害からのサーバー切り替えに失敗 41
ストーリー by hylom
ダブルパンチ 部門より
ダブルパンチ 部門より
11月24日午前11時30分ごろと午後4時ごろ、三重銀行のシステムに障害が発生してATMおよびネットバンキングが利用できなくなるというトラブルが発生した。原因はサーバーのハードウェア障害（三重銀行の発表PDF）。
三重銀行によると、2台のサーバーのうち1台の内蔵ディスクに障害が発生したが、もう片方のサーバーへの自動切り替えが行えず、午前11時30分ごろのトラブルに至ったという。さらに、通常2台で運用していたシステムを1台に集中して運用したために容量超過が発生してシステムが停止、午後4時頃のトラブルに至ったとのこと。
なお、障害のため振込みや引出し等を利用できず、他行経由で行った顧客に対しては、申し出を行えば手数料の差額を返還するそうだ。
もちろんネタコメント (スコア:3, おもしろおかしい)
Re: (スコア:0)
もうだれか「三重のサーバ」って噺かんがえてやれよ。
Re: (スコア:0)
読みがなが振ってないと意味不明
Re:もちろんネタコメント (スコア:1)
Re: (スコア:0)
三重と三重のダブルミーニングで笑いを取る話に仕上げるのに、ルビ振ったらネタにならんじゃないか
Re: (スコア:0)
ミエミエってことか
Re: (スコア:0)
三重大爆発を思い出す。
//何度目？
Bankingweb24 (スコア:2, 参考になる)
採用予定行が次々離脱する謎パッケージにはやっぱ地雷が埋まっているということですかねぇ。
福岡銀行で似たような事象が起きた時は最終的にIBMが100億賠償させられてます。
Re:Bankingweb24 (スコア:1)
もしかして:Bankingweb21
Re:Bankingweb24 (スコア:1)
です。
http://itpro.nikkeibp.co.jp/article/NEWS/20100506/347762/ [nikkeibp.co.jp]
なんとまあ (スコア:0)
ダメな冗長化設計のお手本のよう。
Re:なんとまあ (スコア:2)
Active-Active で負荷の増大を見越しつつ縮退運転の設計をするのはかなり大変だと思いますが。しかもシステム更新時期が引き延ばされたり… 設計時の問題だと判断するのは難しいと思います。
もちろん完全な待機系を準備できる Ative-Standby であれば話はかなり簡単になりますが、今はどこも Active-Active ができます、という宣伝文句があふれていますし、競争やコストカットの激しい分野でそれが認められるのは難しい。そんな時代かと。
Re: (スコア:0)
大変とかいってるけど、勘定系はそれができなきゃダメでしょ。
Re:なんとまあ (スコア:4, おもしろおかしい)
難しいから普通の勘定系は Active-Standby で普段は片系運転、それでピーク負荷を賄えるように設計しておいて、年に1回訓練で切り替えて交互に使うとかじゃないの。
周到なところはさらに予備系があって、同じものが3系統ある。
「三重銀行」なのだから、それくらいはしてもらいたいところだよね。
＃某大手証券会社は5系統あるそうな。
Re:なんとまあ (スコア:4, おもしろおかしい)
予算が足りない、理解が足りない、日程の余裕が足りない。
とか、3つの重しをつけられているのかもしれない。
Re:なんとまあ (スコア:1)
三重（みえ）を三重（さんじゅう）と読んでるようなコメントが
散見されますが、由来からして仕方ないか。
http://www.pref.mie.lg.jp/a/look/yurai.htm [mie.lg.jp]
-- う～ん、バッドノウハウ？
Re: (スコア:0)
そうなんだけど、勘定系というか、金と直結する業務のところほど予算削るんですよね。
結局人の金を吸い取るのが主目的なんだなと。
Re: (スコア:0)
https://ja.wikipedia.org/wiki/BankingWeb21 [wikipedia.org]
2010年に更新してまだ5年。
負荷の増加とか、更新時期引き延ばしと言うには早いのでは？
Re: (スコア:0)
単に自動切り替えができなかったという文でそこまで読み取れるもん？
Re: (スコア:0)
障害で自動切り替えできなかったってことは冗長化失敗しているだろ。
冗長化の意味理解してない人かしら？
Re:なんとまあ (スコア:1)
予算の冗長化とイイワケの冗長化はできてます。
Re: (スコア:0)
いや、これ冗長化してないのでは？
だって、通常２台全て使って処理していて、１台壊れても残りの１台で性能を落として処理を続けますと言う仕様が
１台になって過負荷でシステム停止になったのだから。
必要な性能が１００％だとしたら、５０％にダウンしても遅くなっても停止はしませんよ。ってことで
冗長化というのであれば、もとから１台で負荷をこなせる仕様になってないとだめやん。
１００％必要なところを２００％用意しないと冗長化できんでしょ。この事例なら４台サーバーを用意するとかやね
Re:なんとまあ (スコア:1)
冗長化というか2台並列で振り分けて処理してだけ？
落ちたらやばいのわかってるんだから、本体内蔵ディスクもせめてミラーにしといてデータサーバーも処理系も3台以上のクラスタ構成にするとか出来なかったのかな。
全ては「予算」次第なんでしょうけど。
Re:なんとまあ (スコア:1)
一応、2台で100%を処理できるなら、N+1構成ということで、3台用意しておけば、1台死んでも100%はカバーできるので、最低限の冗長化はできてる。
金融機関なら、最低限じゃなくてせめてもう一声ほしいところだけど。
Re: (スコア:0)
自動で切り替えができなかったとかそういう話なので一台でも十分と見ていたのでは？
Re: (スコア:0)
冗長化はしているけどシステム負荷の見積もりが甘かったということでは？
Re: (スコア:0)
冗長化できていなかったという結果はわかるけど、手本になるほどの情報はないよね。
具体的にどういうシステムを組んでいて、どのような原因でうまくいかなかったのか情報がないとね。
Re:なんとまあ (スコア:1)
(三重)銀行のシステムでもマイナンバー取り扱うんすか。
結局アチコチ駄々漏れになるんだろうけど、その後の対策どうすればいいんだろう。
Re: (スコア:0)
口座とマイナンバーを紐付けるってのに
銀行システムで取り扱わないの？
どう考えてもシステムに組み込むでしょ
Re: (スコア:0)
このタレコミで問題になっているのは可用性であって機密性ではないよ。
Re: (スコア:0)
可用性に関して連続して別の障害を発生させてしまうような状態で、機密性に関してどれだけ期待できるんでしょう？
Re: (スコア:0)
まあ、そう思うなら銀行口座にマイナンバー必須になる前に、三重銀行の口座を閉じればいいんじゃない。
個人的にはマイナンバーなんて再発行できるんだから、再発行できない誕生日の方を登録させるのを規制してほしいね。
申し出 (スコア:0)
逆に言うと、申し出しないと返金されないのか。
銀行側で口座見ればわかったりしないのかな。
Re:申し出 (スコア:3)
> 逆に言うと、申し出しないと返金されないのか。
> 銀行側で口座見ればわかったりしないのかな。
三重銀行が使えないから他行で振込みや引出し等を行ったんで三重銀行には記録はないでしょうね。
Re:申し出 (スコア:2)
午前11時35分発生の障害では他行経由で取引可能だったが、午後4時15分発生の障害では他行経由での取引も不可だったため、後者の記録は存在しないハズ。
Re: (スコア:0)
Re: (スコア:0)
2015年12月01日 19時47分現在 マイナスになっている
沈めるためにわざわざマイナスにしたのなら大きなお世話
そうでないなら捻くれ者がいる
Re: (スコア:0)
モデ権がまわってくると、使い切りたくなっちゃうものなんですよ。