全銀ネット障害、インデックステーブルを生成するアプリケーションのバグの可能性が高い 34
ストーリー by nagazou
対応 部門より
対応 部門より
NTTデータは6日、10月に発生した「全国銀行データ通信システム」で発生した障害に関連して記者会見を実施した。その際、システム総点検タスクフォースを立ち上げる方針も発表した。これには、全銀ネットでの障害だけでなく、NTTデータが管理する100~200の重要なシステムの品質を包括的に点検する取り組みが含まれるという（読売新聞、ZDNET Japan）。
障害の原因に関しては、リレーコンピューター（RC）の更改作業中に発生したもので、特に金融機関の送金/着金の手数料に関連した「内国為替制度運営費」の処理に問題が発生した。この問題の原因として「あらかじめRCに設定されたテーブル」を生成するアプリケーションが内包したバグの可能性が高いと指摘している。同社は11月末までにさらに詳細な原因を調べ、金融庁に報告するとしている。
NTTデータは、これらの問題に対処するためにシステム総点検タスクフォースを立ち上げ、根本的な原因を特定するだけでなく、各種検査、テスト、本番環境の移行、運用時のバックアップなど、プロセス全体を再点検し、問題点を洗い出し、改善策を検討・実施する必要があると述べている。
あるAnonymous Coward 曰く、
障害の原因に関しては、リレーコンピューター（RC）の更改作業中に発生したもので、特に金融機関の送金/着金の手数料に関連した「内国為替制度運営費」の処理に問題が発生した。この問題の原因として「あらかじめRCに設定されたテーブル」を生成するアプリケーションが内包したバグの可能性が高いと指摘している。同社は11月末までにさらに詳細な原因を調べ、金融庁に報告するとしている。
NTTデータは、これらの問題に対処するためにシステム総点検タスクフォースを立ち上げ、根本的な原因を特定するだけでなく、各種検査、テスト、本番環境の移行、運用時のバックアップなど、プロセス全体を再点検し、問題点を洗い出し、改善策を検討・実施する必要があると述べている。
あるAnonymous Coward 曰く、
NTTデータ、全銀ネットの障害対応を説明--根本原因にめども「包括的な点検が必要」
https://japan.zdnet.com/article/35211137/
RCが内国為替制度運営費の入力欄に一律「0円」を入力するようにしてエラーを発生させない暫定措置は継続中（参考コメント）。
リレーコンピュータ (スコア:1)
何か別なものを想像してしまった。
# 21世紀・令和の時代に間違えるわけがありません（たぶん）
Re:リレーコンピュータ (スコア:1)
NHK現代の映像の”フェイルセーフ”とゆう番組に初期の新幹線の指令室が出てくるがいかにも動いてる感じでリレーの接点音が素敵 。 違法アップロードだと思うがユーチューブに上がってる。
Re:リレーコンピュータ (スコア:1)
富士通沼津工場に動態保存してたけど、いまも動かせるのかな。
なにか見つけないといけない (スコア:0)
各種検査、テスト、本番環境の移行、運用時のバックアップなど、プロセス全体を再点検し、問題点を洗い出し、改善策を検討・実施する必要がある
問題点が「下請けSESを使ったため」とか「社員の能力が足りてなかった」みたいな話に集約されちゃいそうな気もするけど、大丈夫なんかな。
Re:なにか見つけないといけない (スコア:1)
肝心なのは洗い出した問題に対する改善策によって再発を防げる見込みが十分にあることで、
それさえ実現すればどのように集約されるかなど些細なことだ。
Re: (スコア:0)
テストカバレッジ上げましょう。
Re:なにか見つけないといけない (スコア:2)
『テストちからバレッジ』でもだいたいあってる。
Re: (スコア:0)
大きなシステムに関わったひとなら言えないなあ
Re:なにか見つけないといけない (スコア:1)
問題点：社員の危険察知能力が足りていなかった
改善策：各部署の壁に現場猫のポスターを貼る
Re:なにか見つけないといけない (スコア:3, おもしろおかしい)
実際に掲示されたもの：モチベーションアップ株式会社のポスター
Re: (スコア:0)
チェックシートみたいな書類が増えるよりはマシでは。
Re: (スコア:0)
増えないですむのか？
Re: (スコア:0)
元請けの原因調査チームなら、それらの原因は結局「管理能力が足りなかった」ということになるのだが。
Re: (スコア:0)
> 「下請けSESを使ったため」とか「社員の能力が足りてなかった」
こういうのを問題点と捉えない人がいるけど、
「こういうのを抱えながら障害起こさないようにするにはどうすべきか？」というのは大事な話で
「ミドルウェアベンダーにプロジェクトに入ってもらう」とか「識者にレビューしてもらう」とか
やってるところはやってますよ
Re: (スコア:0)
そういうのは切り捨てないといつまでたっても問題点として残りますよ。
出来ない奴にやらせるって本末転倒もいいところ。
現実はそうもいかないって人もいるけど、そんなこと言っているからこんなことになるわけで。
Re: (スコア:0)
理想に向けて現実を変えていかなきゃいけない場面で
「ゲンジツガー」って足引っ張る人ばっかりですからねえ
Re: (スコア:0)
・OSが32ビットから64ビットへ更改（事実）
・インデックステーブルの生成に不具合（報告）
・メモリ不足ではない（NTTデータ談）
以上のことから、整数ビット長の違い、カラムのサイズ違いなどが予想されるが‥‥基本設計時に、OS変更に伴うテスト仕様を洗い出しているよね。
Re: (スコア:0)
・32bitと64bitでCPUアーキテクチャは同じなのか?
違ったらいろいろ問題でそうだよね。
・テーブルを生成するアプリの記述言語は32bitと64bitで同じなのか?
記述言語変わってたらコンパイラやライブラリの影響でてくるよね。
記述言語同じでもコンパイラのバージョン違ったら振る舞い変わってるかもだよね。
でもまあ、他のプログラムは問題は出ず(テストで問題を見つけて直した？)、このプログラムだけ問題が出たってことは
メインのプログラムじゃないので手薄だった(スキルの低いエンジニアが対応してた、テストも甘かった)ってことなのだろうか。
Re: (スコア:0)
確かにメインの機器じゃなかったかと
中継するだけのコンピュータ
でもパケットの一部を書き換える機能がある
ルーターの特殊なものかも知れないし
問題のアプリがルーターの管理ツールって可能性もあるんだよね
32bitや64bitが中継機のことと思うけど（管理ツールかも知れんけど）
大丈夫だろって思い込みかな
でも仮にルーターだったら、わざわざ自社でテストはしないかな
もちろん通信テストはするけど、パケットの中身が一部壊れてたとか見逃すかもね
Re: (スコア:0)
コンパイラを32ビット対応の古いのから64ビット対応の新しいのにした時に、'char'のデフォルトがsignedからunsignedに変わったのが原因だったりして。テストケースは問題が起きない0-127の値しかなかったけど、本番データには128-255があった、とか。
# 金融系でC言語使ったりしないか。
Re: (スコア:0)
Cへのトランスレータとかだったりしてね
Re: (スコア:0)
CとJAVAと公言されてたはずですよ
Re: (スコア:0)
# 金融系でC言語使ったりしないか。
使うよ。
特に右から左へデータ選別して渡すような速度が必要なリレー系のサーバでは。
障害が起きたのがRCサーバだからC、しかも無印のCで書かれてたんじゃないかと思う。
で、古いそーすをコンパイルして、コンパイル通ったから、まぁ実績あるし簡単な動作チェックだけしときゃいいだろと思ってテストサボってたんだと思うよ。
Re: (スコア:0)
問題点が「下請けSESを使ったため」とか「社員の能力が足りてなかった」みたいな話に集約されちゃいそうな気もするけど、大丈夫なんかな。
仕様書が降りてくるころには仕様が変わっている軍曹状態かもしれない
Re: (スコア:0)
でも現実としてそういう話でもあるんだよな
「アプリケーションが内包したバグ」ということは (スコア:0)
そのアプリケーションそのものではなく、そのアプリケーションが呼び出すsystemcallとかsystemutility＝マシンのOS等の側のバグってことはないのかな？
Re: (スコア:0)
リレーコンピューターへのリリース作業や配置先に誤りは無さそうです。
インデックスファイル作成処理に問題がありそうです。
コードに問題があるのか、使用したライブラリのバグを踏んだのか、仕様の理解不足かは調査中です。
ってことだと思う。
なんか手間取ってますね (スコア:0)
末端のプログラマがソースコードとか調べてるのを、プログラムできない人たち10人ぐらいが
後ろから覗き込んであーだこーだ指示なるものを出してる光景が浮かんだ。知らんけど。
名前が悪い (スコア:0)
全金ネットまたは金金ネットにしておけばトラブルは起こらなかっただろう
Re: (スコア:0)
金銀ネット
# 金銀パールプレゼント （←わかる人はGGIまたはBBA）
アプリケーションとは？ (スコア:0)
単に、OS（基本ソフト）ではない部分ということを言いたかったのだろうか。
OS以外でも既存のパッケージとカスタムメイドの部分があって、前者であることを強調したかったのではないかと邪推してしまう。
つまり「オレのせいじゃないもん、アプリのベンダーが悪いんだもん」的な。
Re: (スコア:0)
プログラムを開発する立場の人にとっては、自分たちが作ったプログラム自体も、大体のものは「アプリケーション」呼びできるんよ。
Re: (スコア:0)
邪推ではなくて、それは単なる勘違いだと思うぞ。
ある機能を実現するための(1つあるいは複数の)プログラムのことをアプリケーションと言うので、
「OS以外でも既存のパッケージとカスタムメイドの部分があって」という分け方だと、むしろ「カスタムメイドの部分」こそバグを入れてしまったアプリケーションということになる。
「既存のパッケージ」ってのはミドルウェアとかライブラリのことだろうと思うんだが、それ単体でアプリケーションと呼ぶことはあんまない。
再現しないのか出来ないのか (スコア:0)
手数料を事前計算してテーブル生成、
RCにテーブルをコピーしてオンライン処理、
の流れで、RCでテーブルのインデックスが壊れていたのは確認済み。
事前計算だからそれを回し直して壊れるかの検証実験は比較的やりやすそうに見えるのに、
なんで再現取れたって話ではなく「そこらへんだろう(憶測)」からの全体チェック進行中の話になっているのだろうか。
非同期処理に置けるタイミングの問題で再現取れないって線はありうるけど、
そもそも事前計算なら非同期やる必要がそもそも薄いから可能性低い気がするかな……
単にデータを移す段階でハッシュが弱くてデータ化けたとか、
稀なはずだが宇宙線などでデータが物理的に化けた不可抗力とかそういうのもありそう……
再現作業出来ない融通の効かなさとかが未解明の理由ってオチだけは勘弁願いたい。