パスワードを忘れた? アカウント作成
17567171 story
バグ

全銀ネット障害、インデックステーブルを生成するアプリケーションのバグの可能性が高い 34

ストーリー by nagazou
対応 部門より
NTTデータは6日、10月に発生した「全国銀行データ通信システム」で発生した障害に関連して記者会見を実施した。その際、システム総点検タスクフォースを立ち上げる方針も発表した。これには、全銀ネットでの障害だけでなく、NTTデータが管理する100~200の重要なシステムの品質を包括的に点検する取り組みが含まれるという(読売新聞ZDNET Japan)。

障害の原因に関しては、リレーコンピューター(RC)の更改作業中に発生したもので、特に金融機関の送金/着金の手数料に関連した「内国為替制度運営費」の処理に問題が発生した。この問題の原因として「あらかじめRCに設定されたテーブル」を生成するアプリケーションが内包したバグの可能性が高いと指摘している。同社は11月末までにさらに詳細な原因を調べ、金融庁に報告するとしている。

NTTデータは、これらの問題に対処するためにシステム総点検タスクフォースを立ち上げ、根本的な原因を特定するだけでなく、各種検査、テスト、本番環境の移行、運用時のバックアップなど、プロセス全体を再点検し、問題点を洗い出し、改善策を検討・実施する必要があると述べている。

あるAnonymous Coward 曰く、

NTTデータ、全銀ネットの障害対応を説明--根本原因にめども「包括的な点検が必要」
https://japan.zdnet.com/article/35211137/

RCが内国為替制度運営費の入力欄に一律「0円」を入力するようにしてエラーを発生させない暫定措置は継続中(参考コメント)。

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • by Anonymous Coward on 2023年11月09日 5時16分 (#4560703)

    何か別なものを想像してしまった。
    # 21世紀・令和の時代に間違えるわけがありません(たぶん)

  • by Anonymous Coward on 2023年11月08日 13時46分 (#4560272)

    各種検査、テスト、本番環境の移行、運用時のバックアップなど、プロセス全体を再点検し、問題点を洗い出し、改善策を検討・実施する必要がある

    問題点が「下請けSESを使ったため」とか「社員の能力が足りてなかった」みたいな話に集約されちゃいそうな気もするけど、大丈夫なんかな。

    • by Anonymous Coward on 2023年11月08日 13時55分 (#4560277)

      肝心なのは洗い出した問題に対する改善策によって再発を防げる見込みが十分にあることで、
      それさえ実現すればどのように集約されるかなど些細なことだ。

      親コメント
    • by Anonymous Coward on 2023年11月08日 14時04分 (#4560287)

      問題点:社員の危険察知能力が足りていなかった
      改善策:各部署の壁に現場猫のポスターを貼る

      親コメント
    • by Anonymous Coward

      チェックシートみたいな書類が増えるよりはマシでは。

      • by Anonymous Coward

        増えないですむのか?

    • by Anonymous Coward

      元請けの原因調査チームなら、それらの原因は結局「管理能力が足りなかった」ということになるのだが。

    • by Anonymous Coward

      > 「下請けSESを使ったため」とか「社員の能力が足りてなかった」

      こういうのを問題点と捉えない人がいるけど、
      「こういうのを抱えながら障害起こさないようにするにはどうすべきか?」というのは大事な話で
      「ミドルウェアベンダーにプロジェクトに入ってもらう」とか「識者にレビューしてもらう」とか
      やってるところはやってますよ

      • by Anonymous Coward

        そういうのは切り捨てないといつまでたっても問題点として残りますよ。
        出来ない奴にやらせるって本末転倒もいいところ。
        現実はそうもいかないって人もいるけど、そんなこと言っているからこんなことになるわけで。

        • by Anonymous Coward

          理想に向けて現実を変えていかなきゃいけない場面で
          「ゲンジツガー」って足引っ張る人ばっかりですからねえ

    • by Anonymous Coward

      ・OSが32ビットから64ビットへ更改(事実)
      ・インデックステーブルの生成に不具合(報告)
      ・メモリ不足ではない(NTTデータ談)
      以上のことから、整数ビット長の違い、カラムのサイズ違いなどが予想されるが‥‥基本設計時に、OS変更に伴うテスト仕様を洗い出しているよね。

      • by Anonymous Coward

        ・32bitと64bitでCPUアーキテクチャは同じなのか?
         違ったらいろいろ問題でそうだよね。
        ・テーブルを生成するアプリの記述言語は32bitと64bitで同じなのか?
         記述言語変わってたらコンパイラやライブラリの影響でてくるよね。
         記述言語同じでもコンパイラのバージョン違ったら振る舞い変わってるかもだよね。

        でもまあ、他のプログラムは問題は出ず(テストで問題を見つけて直した?)、このプログラムだけ問題が出たってことは
        メインのプログラムじゃないので手薄だった(スキルの低いエンジニアが対応してた、テストも甘かった)ってことなのだろうか。

        • by Anonymous Coward

          確かにメインの機器じゃなかったかと
          中継するだけのコンピュータ
          でもパケットの一部を書き換える機能がある
          ルーターの特殊なものかも知れないし
          問題のアプリがルーターの管理ツールって可能性もあるんだよね
          32bitや64bitが中継機のことと思うけど(管理ツールかも知れんけど)
          大丈夫だろって思い込みかな

          でも仮にルーターだったら、わざわざ自社でテストはしないかな
          もちろん通信テストはするけど、パケットの中身が一部壊れてたとか見逃すかもね

      • by Anonymous Coward

        コンパイラを32ビット対応の古いのから64ビット対応の新しいのにした時に、'char'のデフォルトがsignedからunsignedに変わったのが原因だったりして。テストケースは問題が起きない0-127の値しかなかったけど、本番データには128-255があった、とか。

        # 金融系でC言語使ったりしないか。

        • by Anonymous Coward

          Cへのトランスレータとかだったりしてね

        • by Anonymous Coward

          CとJAVAと公言されてたはずですよ

        • by Anonymous Coward

          # 金融系でC言語使ったりしないか。

          使うよ。
          特に右から左へデータ選別して渡すような速度が必要なリレー系のサーバでは。
          障害が起きたのがRCサーバだからC、しかも無印のCで書かれてたんじゃないかと思う。
          で、古いそーすをコンパイルして、コンパイル通ったから、まぁ実績あるし簡単な動作チェックだけしときゃいいだろと思ってテストサボってたんだと思うよ。

    • by Anonymous Coward

      問題点が「下請けSESを使ったため」とか「社員の能力が足りてなかった」みたいな話に集約されちゃいそうな気もするけど、大丈夫なんかな。

      仕様書が降りてくるころには仕様が変わっている軍曹状態かもしれない

    • by Anonymous Coward

      でも現実としてそういう話でもあるんだよな

  • by Anonymous Coward on 2023年11月08日 14時56分 (#4560325)

    そのアプリケーションそのものではなく、そのアプリケーションが呼び出すsystemcallとかsystemutility=マシンのOS等の側のバグってことはないのかな?

    • by Anonymous Coward

      リレーコンピューターへのリリース作業や配置先に誤りは無さそうです。
      インデックスファイル作成処理に問題がありそうです。
      コードに問題があるのか、使用したライブラリのバグを踏んだのか、仕様の理解不足かは調査中です。

      ってことだと思う。

  • by Anonymous Coward on 2023年11月08日 20時58分 (#4560595)

    末端のプログラマがソースコードとか調べてるのを、プログラムできない人たち10人ぐらいが
    後ろから覗き込んであーだこーだ指示なるものを出してる光景が浮かんだ。知らんけど。

  • by Anonymous Coward on 2023年11月08日 21時10分 (#4560599)

    全金ネットまたは金金ネットにしておけばトラブルは起こらなかっただろう

    • by Anonymous Coward

      金銀ネット

      # 金銀パールプレゼント (←わかる人はGGIまたはBBA)

  • by Anonymous Coward on 2023年11月09日 2時24分 (#4560669)

    単に、OS(基本ソフト)ではない部分ということを言いたかったのだろうか。
    OS以外でも既存のパッケージとカスタムメイドの部分があって、前者であることを強調したかったのではないかと邪推してしまう。
    つまり「オレのせいじゃないもん、アプリのベンダーが悪いんだもん」的な。

    • by Anonymous Coward

      プログラムを開発する立場の人にとっては、自分たちが作ったプログラム自体も、大体のものは「アプリケーション」呼びできるんよ。

    • by Anonymous Coward

      邪推ではなくて、それは単なる勘違いだと思うぞ。
      ある機能を実現するための(1つあるいは複数の)プログラムのことをアプリケーションと言うので、
      「OS以外でも既存のパッケージとカスタムメイドの部分があって」という分け方だと、むしろ「カスタムメイドの部分」こそバグを入れてしまったアプリケーションということになる。
      「既存のパッケージ」ってのはミドルウェアとかライブラリのことだろうと思うんだが、それ単体でアプリケーションと呼ぶことはあんまない。

  • by Anonymous Coward on 2023年11月09日 13時00分 (#4560944)

    手数料を事前計算してテーブル生成、
    RCにテーブルをコピーしてオンライン処理、
    の流れで、RCでテーブルのインデックスが壊れていたのは確認済み。

    事前計算だからそれを回し直して壊れるかの検証実験は比較的やりやすそうに見えるのに、
    なんで再現取れたって話ではなく「そこらへんだろう(憶測)」からの全体チェック進行中の話になっているのだろうか。
    非同期処理に置けるタイミングの問題で再現取れないって線はありうるけど、
    そもそも事前計算なら非同期やる必要がそもそも薄いから可能性低い気がするかな……

    単にデータを移す段階でハッシュが弱くてデータ化けたとか、
    稀なはずだが宇宙線などでデータが物理的に化けた不可抗力とかそういうのもありそう……

    再現作業出来ない融通の効かなさとかが未解明の理由ってオチだけは勘弁願いたい。

typodupeerror

一つのことを行い、またそれをうまくやるプログラムを書け -- Malcolm Douglas McIlroy

読み込み中...