シンプル Batch 処理 の 5つのチェック観点


仕事上、review をする機会があります。
個人的に5つのチェック項目を設けていて、
この5つをチェックすると自分調べでそれなりのバグ検出率を誇ります。

チームメンバ指導の草稿用途に、以下記載しておきます。


前提

チェック観点は、以下の前提条件下で使用すると、
自分調べでは効果を発揮するはずです。

  • RDB への CRUD が中心

  • cron 等 の job sheduler 起動

  • jobnet が組まれていない。 (後続 job がない。)

  • 日次で変化が発生する、データ集合を処理する。

  • 同時起動数は1で、パラレル実行は発生しない。

  • ユーザー側システム部門が、IT ベンダーに対してのチェックを行う状況。


チェック観点

Transaction の Save Point の単位

データ集合を処理する際の、Transaction の Save Point を明確にします。
1件ずつコミットなのか? 一括でコミットなのか?

Shedule の設定

どのような起動間隔で実行するのかを明確にします。

リトライ時の動作

Shedule 設定に対して、起動予定時刻に起動したが、異常終了した場合、
再実行時の期待動作を確認します。
希望通りに動くのか?
動かない場合、どのような運用 SE 作業をしたら希望通りに動くのか? それに合意はとれているのか?

ここの動作は、Transaction の Save Point の単位Shedule の設定 が大きく影響します。
リトライ時の期待動作が実現できない、Transaction の Save Point の単位 だったので、
Save Point を見直したりするかと思います。

異常発生時の振舞い

異常系の発生ポイントとその時の振る舞いを確認します。
RDB アクセスであれば、クエリ発行ポイントでエラー(これはシステムエラー、アプリケーションエラー双方)
が発生した場合、どのような振る舞いとなるのか? を確認します。
ベストは発生ポイントでの、運用作業がまとめられていることですが、
まとめられていなくても、まとめていないということにユーザ側と、ベンダー側の合意がとれていること。

Logポリシー

どのようなポリシーで、ログを出してるのかを確認します。
LOG LEVEL と、出力内容について
例えば、LOOP内のログは、ループの単位がわかる、データ項目値を出力しているか等。

集合データの取得のポリシー

どういうポリシーでデータを取得しているのかを確認します。
あまりデータ精度が高くなかったりする状況で、抽出条件が甘いと、
バッチ処理内の後続処理の発行クエリでデータがとれなかったり、
変なデータがとれたりします。

システム上のエラーデータに対する処理のポリシーを聞いていくのかと

これで5つですね。


確認の仕方で気をつけていること

指摘ではなく、疑問系で、
「今回作成していただいた週次のスケジューラーバッチで、リトライ動作の観点で気をつけたところはありますか?」
みたいな形で聞いても効果はあるかと思います。
その回答を考える時に善人な(あるいはまともな)ベンダーであれば、回答考えている最中に、
気づいてくれそうに思ったりします。
そうでない人達もいるのかもしれませんが..

書いてるうちに、三段論法的なところから外れてく感じはしますが、
メモ書きとして、ざっくり残しておきます。

以上です。

コメント