読者です 読者をやめる 読者になる 読者になる

プロマネブログ

とあるSIerでプロマネやっているオッサンです。主にシステム開発ネタや仕事ネタ、気になった三面記事ネタの解説なんかしてたりします。

三菱東京UFJ銀行システムトラブルを勝手に分析する

テクノロジー

ニュース - 三菱東京UFJ銀行でシステムトラブル、約30億円が定期振込できず:ITpro

 

 三菱UFJ銀行のしでかしちゃった案件なんですけど、この記事からなんとなく問題となったバッチの仕様が透けて見えたのでちょっと書いてみます。

 

定期振込バッチの想定仕様

f:id:getlife:20140502011606p:plain

問題となったバッチアプリケーションの想定されるデータ処理の仕様イメージは上記のとおりとなります。

 

 

まあ、こんな感じでしょう。

勘定系で見かける、典型的なバッチ処理です。

終了判定をEOFではなく、番兵の空振りで判定しているのがちょっとクセモノかなと思います。おそらく、コントロールブレイクを使っているのかなとおもいます。

 

想定バグ事象

さて、報道されている事象からバグ内容を想定します。

 

おそらくなのですが、本来であれば

  • データを処理したけど、チェックの結果振込対象でなかった
  • 処理対象データ自体がなかった

の2つをきちんと分けて管理するべきところ、同一のものとして判定してしまったのでしょう。

 

今回の場合は、64,162件を65回イテレーション処理を行い、66回目に全件空振りとして正常終了する予定だったにも関わらず、途中データ(記事から察するに42回目データ)を番兵と誤判断してしまい、バッチ処理を終了してコミットしてしまったのではないかなと思われます。

 

上記の考察から、緊急のバグ修正として、終了判定を番兵からEOFに変えたか、データ処理カウンタとは別にデータ読み込みカウンタでも設けて終了判断するようにしたか、あたりの対応を行ったかなと思います。

 

 

今回のバグは、処理アルゴリズムのバグとなるため、おそらくは内部設計あたりでロジック設計をミスったのが原因って感じでしょうね。

プログラム仕様が甘かったのだと思います。

 

まとめ

今回のトラブルですけど、結構ありがちなトラブルですね。

 

正直、基本設計時に気づかなければ、テスト工程などでは気づくことが困難な事象かと思います。

 

バッチのテストって正直面倒で、単体・結合テストなどでは中々仕様ミスを検出できないんですよね。バッチの特性上、単独アプリケーションとして正常に稼働したとしてもシステム全体で正常なのかどうか、怪しかったりするので。

 

なので、業務テストあたりで、今回問題になったようなエラーが連続した場合の業務シナリオを作っておかなければならないんですけど、エラーがそんなにも連続するなんて思いにもよらなかったということが実情でしょうし。

銀行勘定系のようなでかいシステムですと、業務パターンの網羅性を考えるのは、それなりのスキルが必要になりますしね。。。

 

 

まあ、仕様ミス、気づけないのはどうしようもないってことで。

 

※今回のエントリは、最後のダジャレが言いたかっただけです。

 

以上

広告を非表示にする