三菱東京UFJ銀行システムトラブルを勝手に分析する
三菱UFJ銀行のしでかしちゃった案件なんですけど、この記事からなんとなく問題となったバッチの仕様が透けて見えたのでちょっと書いてみます。
定期振込バッチの想定仕様
問題となったバッチアプリケーションの想定されるデータ処理の仕様イメージは上記のとおりとなります。
- １０００件１イテレーションとして振込指示データを処理(上記図の箱１つで１０００件分のデータイメージ)
- イテレーション内処理データが１件以上あった場合は次のイテレーションを処理
- イテレーション内処理データが０件だった場合は、バッチ終了。(番兵)
まあ、こんな感じでしょう。
勘定系で見かける、典型的なバッチ処理です。
終了判定をEOFではなく、番兵の空振りで判定しているのがちょっとクセモノかなと思います。おそらく、コントロールブレイクを使っているのかなとおもいます。
想定バグ事象
さて、報道されている事象からバグ内容を想定します。
おそらくなのですが、本来であれば
- データを処理したけど、チェックの結果振込対象でなかった
- 処理対象データ自体がなかった
の２つをきちんと分けて管理するべきところ、同一のものとして判定してしまったのでしょう。
今回の場合は、64,162件を６５回イテレーション処理を行い、６６回目に全件空振りとして正常終了する予定だったにも関わらず、途中データ(記事から察するに４２回目データ)を番兵と誤判断してしまい、バッチ処理を終了してコミットしてしまったのではないかなと思われます。
上記の考察から、緊急のバグ修正として、終了判定を番兵からEOFに変えたか、データ処理カウンタとは別にデータ読み込みカウンタでも設けて終了判断するようにしたか、あたりの対応を行ったかなと思います。
今回のバグは、処理アルゴリズムのバグとなるため、おそらくは内部設計あたりでロジック設計をミスったのが原因って感じでしょうね。
プログラム仕様が甘かったのだと思います。
まとめ
今回のトラブルですけど、結構ありがちなトラブルですね。
正直、基本設計時に気づかなければ、テスト工程などでは気づくことが困難な事象かと思います。
バッチのテストって正直面倒で、単体・結合テストなどでは中々仕様ミスを検出できないんですよね。バッチの特性上、単独アプリケーションとして正常に稼働したとしてもシステム全体で正常なのかどうか、怪しかったりするので。
なので、業務テストあたりで、今回問題になったようなエラーが連続した場合の業務シナリオを作っておかなければならないんですけど、エラーがそんなにも連続するなんて思いにもよらなかったということが実情でしょうし。
銀行勘定系のようなでかいシステムですと、業務パターンの網羅性を考えるのは、それなりのスキルが必要になりますしね。。。
まあ、仕様ミス、気づけないのはどうしようもないってことで。
※今回のエントリは、最後のダジャレが言いたかっただけです。
以上
