全銀ネット障害、損害を補償へ。根本原因は特定できず暫定対策のまま運用 100
ストーリー by nagazou
暫定 部門より
暫定 部門より
10日の午前から11日にかけて発生した全国銀行データ通信システム（全銀システム）障害に関して、全国銀行資金決済ネットワーク（全銀ネット）は18日、障害の影響で個人や企業が追加で負担した費用を加盟する金融機関が補償すると発表した（全国銀行資金決済ネットワーク発表[PDF]、三菱UFJ銀行[PDF]、NHK、CNET）。
補償の対象は、送金を急ぐために利用者が二重で行った振り込みの取り消しに伴う手数料などの返金や、予定日に振り込みができないことで発生した「延滞金・遅延損害金」、残高不足による借り入れで生じた「金利」の支払いなどとなっている。今回の障害では振り込みなど約506万件の決済処理が遅れるなどの影響が出ている。
原因に関してはタレコミにあるように、システムと金融機関をつなぐ中継コンピューターの基本ソフトの仕様変更を巡り、プログラムの設定ミスで部分的な容量不足が生じたためと、16日に各社で一斉に報じられている。18日の会見では、先の報道で指摘された問題に関しては、「現時点でそれがテーブルにどう影響したか分からない」との回答があった。現時点では根本的な原因は特定できず、暫定的な代替対応のまま運用しているとのこと（共同通信、ITmedia）。
maia 曰く、
補償の対象は、送金を急ぐために利用者が二重で行った振り込みの取り消しに伴う手数料などの返金や、予定日に振り込みができないことで発生した「延滞金・遅延損害金」、残高不足による借り入れで生じた「金利」の支払いなどとなっている。今回の障害では振り込みなど約506万件の決済処理が遅れるなどの影響が出ている。
原因に関してはタレコミにあるように、システムと金融機関をつなぐ中継コンピューターの基本ソフトの仕様変更を巡り、プログラムの設定ミスで部分的な容量不足が生じたためと、16日に各社で一斉に報じられている。18日の会見では、先の報道で指摘された問題に関しては、「現時点でそれがテーブルにどう影響したか分からない」との回答があった。現時点では根本的な原因は特定できず、暫定的な代替対応のまま運用しているとのこと（共同通信、ITmedia）。
maia 曰く、
10日に起きた全銀システム（全国銀行データ通信システム）の障害は、
①各金融機関と全銀システムをつなぐ中継コンピューター（以下、RC）のメモリー不足が要因だった。機器の更新で処理量が増え、想定の容量を超えた（日経）。
②RCの仕様変更を巡り、プログラムの設定ミスで部分的な容量不足が生じた（大分合同新聞）
③RCのメモリー不足に起因し、金融機関名などを格納したインデックステーブルに不正な値が紛れ込んだ。インデックステーブルはRCのディスク上にあるファイルから展開する。このファイルを作成するプログラムを実行したタイミングで、一時的に確保するメモリー領域が不足し、ファイルの内容が不正確になった（日経XTECH）
いや、どの記事もまあまあ同じことを指しているけど。
全銀システムはこれまでほぼ8年周期でシステムの刷新が行なわれてきて、第7次から第8次への移行過程で行われた機器のリプレイスで起きた障害（ImpressWatch
銀行間手数料 (スコア:5, 興味深い)
今回障害を受けなかった方の銀行の中の人です。
暫定運用はいいんですが銀行間手数料が0円で応答されると振込1件ごとにエラー検知しちゃって面倒なんですよ……
行内事務の都合で安易に無視設定もできず非常に困ってます。
これ「来年の次回メンテで直すよ！」なんて言われたらキレるかも。
10/14となった設定の具体的な内容 (スコア:3, 興味深い)
以前の記事に書かれていた、14機関のうち10機関だけで発生したのは「設定の仕方などが異なっていた」から、という部分。
https://srad.jp/comment/4544730 [srad.jp]
https://xtech.nikkei.com/atcl/nxt/news/18/16074/ [nikkei.com]
具体的には、
内国為替制度運営費は取引種別によって金額が異なる。その入力方法には（1）金融機関側であらかじめ電文に金額を入力してRCに送信、（2）RCが保有するテーブルを参照してRCが電文に金額を入力、の2パターンがある。今回、トラブルが生じたのは（2）の方法を採用していた10金融機関だった。
https://xtech.nikkei.com/atcl/nxt/column/18/00001/08534/ [nikkei.com]
ということだそうです。
メモリ容量の見積もり (スコア:1)
ソフトウェア開発側からすると載せれるだけ載せろという話にしかならないし、
ハードウェア保守側からすると最小限構成の方が安定性や、交換リスクが軽減するという話になる。
プロデューサーサイドからすると予算枠があるから最小構成に偏りがちなんだよね。
どういう論理構成やプレゼンでメモリマシマシの構成を進言すれば良いんだろうか。
おすすめの論点とかありますか？
Re: (スコア:0)
更改なら現行のスループットや負荷状況の実績を算出
過去から現在の負荷の伸び率から将来においての予測を立てて拡張が必要になった際は
予備を開放すればいけるでしょう、という構成見積もりなら見た
0から構築は知らん
Re: (スコア:0)
こういう話は数字で議論する事じゃないですかね？
機能を実現するために必要なメモリー容量を見積もって交渉する事で過去リソース不足の問題解消してきましたし。
ただ、多い少ない、早い遅い、だけでは相手もどう対応して良いかわからないと思いますよ。
Re: (スコア:0)
> 機能を実現するために必要なメモリー容量を見積もって
この辺真面目にやるとえらいコストかかるんだよなぁ。でもJTCはそういうの大好きなんだよね。
アメリカだとざっくり見積もってハードおごっとけですむんだけど。
機体に穴開けてグラム単位の軽量化してたゼロ戦の日本と、
クソでかエンジンで余裕持たせりゃいいだろグラマンのアメリカとの違いを感じる。
はたして補償はいくらになるやら (スコア:0)
これに関わった技術者の代わりに吐こうと思いますｳﾞｫｴ
トラブルはエンジニアの勲章 (スコア:0)
得ようと思って得られる経験ではないからね。
トラブル（対応）は若いうちに経験しとくもんだようんうん。
Re: (スコア:0)
残業代くらいちゃんと出ただろう
かな
Re:はたして補償はいくらになるやら (スコア:1)
現在運行情報のある路線
事故・遅延情報はありません
ほっ。
メモリー不足で不正な値に (スコア:0)
そんなことありうる? 配列インデックスのオーバーフロー的なことが起きたのでは? と指摘されてるな
Re:メモリー不足で不正な値に (スコア:2, すばらしい洞察)
printf入れると動作が変わるやつだな...
Re:メモリー不足で不正な値に (スコア:1)
コメントだよ
Re:メモリー不足で不正な値に (スコア:2, すばらしい洞察)
メモリー不足で不正な値になるパターンなんて無数にある。
ソースコードもハードウェア構成も熟知している当事者でさえ、現時点では分からないって言ってるのに
ネット上でアレコレ想像したところで意味ないよね。
Re:メモリー不足で不正な値に (スコア:2, すばらしい洞察)
ネットで○○が原因だろって言ってる人は色々いるけど、なんかその人の想像力の限界が表れてるなーって感じがする。
Re: (スコア:0)
今日の会見の内容はこの記事が詳しいが
https://www.businessinsider.jp/post-276987 [businessinsider.jp]
メモリー不足どうこうは仮説でしか無さそう
Re: (スコア:0)
「インデックスファイルが破損した」ねぇ・・・。
「テストは十分に行っていた」ねぇ・・・。
現時点で、変な憶測は述べたくないけど、あえて言うなら、プログラムが技術的に稚拙とまで評された
「富士通Japan製コンビニ交付システムの住民票誤発行」（今年３月から連続した事件）のようなレベルの原因だと思う。
（参考） https://www.asahi.com/articles/ASR7H65DXR76ULFA027.html [asahi.com]
Re:メモリー不足で不正な値に (スコア:1)
本当にテストは十分だったんですか？は無敵の言葉
＃お客の仕様ミス＆保証外の動作条件の組み合わせで出た市場不具合について、
＃「弊社の仕様が不十分なのは周知の事実！なぜ信じた！？」
＃「保証外の条件でも保証すべき！市場不具合が出たのはそちらのテストが不十分だったからだ！！」
＃「対策費はすべてお前が持て！市場不具合において、弊社が負担したことは一度たりともない！！！」
＃と自動車メーカに叩かれてる最中なのでAC
Re:メモリー不足で不正な値に (スコア:1)
「弊社の仕様が不十分なのは周知の事実！なぜ信じた！？」
「なぜ信じた」！？
すげえな。
事実ならば是非社名を晒してほしいわ。
そのメーカーの宣伝は信じちゃいけないんだからな。
Re:メモリー不足で不正な値に (スコア:2, 興味深い)
社名はバラせないなあ。
バラすと、そこの車が売れなくなる。
そこの車が売れなくなると、そこの車の生涯生産台数が減る。
そこの車の生涯生産台数が減ると、うちの部品に対し生産減らせ！ただし値段は維持！という命令が来る。
自動車メーカーとの契約で、開発費や設備費は前払い一切ナシ、すべて部品単価に上乗せとなっているので、値段を維持したまま生産を減らすと赤字になる。
つまり、社名をバラすとうちが赤字になるので社名をバラせない。
Re: (スコア:0)
構造体をsizeof使わず固定値でやったとかね……
Re: (スコア:0)
既存の32bitバイナリでdump、64bitバイナリでloadしたらアラインメントがずれた、とか
Re:メモリー不足で不正な値に (スコア:1)
// いうしかあるまい
Re: (スコア:0)
批判するのは簡単だからなぁ
こういうのを魔に受けて現場をこきつかってたら
技術力ある有能な人は当然転職して居なくなって
というのが今の現状でしょうね
Re:メモリー不足で不正な値に (スコア:1)
「魔に受けて」
妙に納得した。言い得て妙というやつ。
Re: (スコア:0)
明日の現状に期待
Re: (スコア:0)
では君に全銀の案件を進呈しよう
Re: (スコア:0)
ISDNをあえて残すレベルまで多重化していたと言われる全銀を落としたんだからテスト十分は絶対にありえないな…
「完璧な経営計画だったのに働かない社員が悪い」と社長が言い放った某社のあの頃とおなじくらい
Re: (スコア:0)
スラドの文章上のことだけからいえば、DBとしてのインデックス機能じゃなくてアプリとしてのインデックス用途テーブルに見える。
Re:メモリー不足で不正な値に (スコア:1)
COBOLでしょ。文字通りインデックスファイルというものがあった気がする。
Re: (スコア:0)
記者会見によると、CとJavaを使ってたらしいよ。
Re:メモリー不足で不正な値に (スコア:1)
50年間も守り続けているのだから、てっきりメインフレームのアセンブラだと思っていたよ。
Re:メモリー不足で不正な値に (スコア:1)
仕様を把握してCとJavaで一から作り直すのはもはや仕様が迷宮クラスで不可能なので、
COBOLで書かれたプログラムを、インデックスファイルの仕様や処理も含め
CとJavaで機械的にエミュレーションしてるだけだったりして…
よく知らないけど、一般論としてはそういうのわりとあるって話を旧名twitter現Xで見かけました。
(全銀のこれがそうなのかは不明)
そういう作りだと、当然元のCOBOLのプログラムよりもさらに読みづらいプログラムになってるわけで
原因調査中だけどよく分からんってのも普通にありえそう。
Re: (スコア:0)
調査した本人たちがテーブルにどう影響したか分からないと言ってんだから外野の妄想に何の意味が。
まさかここやトゥイッターランドでよく見かける、断片的な情報だけ見て俺はわかってるけどあいつらはわかってない的な？
Re:メモリー不足で不正な値に (スコア:1)
何かを勘違いしているようですが、ここは雑談サイトですよ。
ワイワイ話せるだけで十分に意味があるかと。
Re: (スコア:0)
それ言ってる記者が勘違いしてる可能性もあるよ
メモリ破壊のことを、自分が知ってる知識からメモリ不足と勘違いとかね
32bitで作ったバッチ処理を64bitのOSで動かしたら何が起こるか
intのサイズ違い、アロケーションの違いなど
昔メモリのアドレスを自分で計算して作ったプログラムが
メモリ破壊してしまった経験はあるね
条件が揃わないと再現しなかったりするから厄介な不具合になるけど
Re: (スコア:0)
小人さんも高齢なんだよ察して差し上げろ
# やらかした原因作った人がえらすぎて有耶無耶になったんかねぇ
JavaVMのヒープの指定 (スコア:0)
してない場合余ってるメモリ空間をごっそり使うみたいな感じだった気がするけどそれ系？
Re: (スコア:0)
全銀がJava対応するのって今回の改修からだっけ？
最近は新人研修でJavaやらなくなったし、なんかCOBOL化の道を辿ってる気がするのだけど。
Re:JavaVMのヒープの指定 (スコア:1)
// ライブラリ回りで全然違うものになるそうで
(オフトピ) 同日発生したゆうちょ銀行の障害 (スコア:0)
同日発生した、ゆうちょダイレクト・ゆうちょ通帳アプリの障害による送金料金の差額は、手続き不要で口座に返金されるそうです。
https://www.jp-bank.japanpost.jp/news/2023/news_id001984.html [japanpost.jp]
思ったほど混乱がなかった (スコア:0)
銀行間決済なんて「国家の重要インフラです」って面してるけど、今回意外に社会は混乱しなかった。
元からそこそこ時間掛かったりするし数日止まっても大丈夫じゃね？
…と考えると、50年無停止だとかの現状システムはオーバースペックではないかしら？
システム移行時やランダムに数年に1回止まるくらいに緩くしたらコストはどれほど安くなるのか気になるところ。
まぁわざわざきちんと動いてるものを多少コスト削って半端にしたいと思う人は居ないが。
社会保障なんかもそういう理由で削れないのよね。
Re: (スコア:0)
> コストはどれほど安くなるのか気になるところ。
みずぽの偉い人はそう考えてたんじゃないですかね？
結果めちゃくちゃ止まるお高いシステムに。
Re: (スコア:0)
ごとおび締めがどうというがあったけど、作業日の感じは
月末締めとか給料日とか10日締めとか（これはたぶん？）避けてるかんね。
Re: (スコア:0)
10/7〜9が休みでその翌日の営業日に10日を迎えている。
3日間の休みで結構な量の取引が溜まっていたので最悪の条件でリリース作業を行ったのではないか。
これが10/6〜8が休みで9日が翌営業日なら取引が分散して起こらなかったのではないだろうか。
しかし、最初のリリースで発覚してよかったと思う。
これが、全RCを入れ替えたあとに起こっていたら全国的に今回以上の大騒動だったと思う。
それにしても障害時の切り戻しとか考えていなかったんかね。
Re: (スコア:0)
完全戻しのコンチプランと対策前進の両面かな
今回みたく正常に動作する銀行もいる場合だと後者で行くこともある
Re: (スコア:0)
連休明けの五十日というアクセス集中が予想される日にリリース予定立てるような抜けた組織が障害の切り戻しとか見通せたら普通に凄いと思うが。
富士通の名前出てるな... (スコア:0)
https://togetter.com/li/2243863 [togetter.com]
> 報道からの推察では 富士通のDB Symfoware のインデックスファイルの容量に上限超過を疑ってます。
> NTTデータが元受けではあるけど、担当区分としては富士通なんだよな…
まあまだ推測の段階だけどね。
Re: (スコア:0)
乞食発見
Re: (スコア:0)
乞食というか、やっぱ祭りには参加しなくちゃじゃない？
そのうえでなにかもらえたらラッキーじゃん