- バッチ処理を新しく作るときの設計や、既存のバッチ運用を引き継いで改修を行う際の方針
- 面倒なので運用時に考えること・手数を減らしたい
- バッチ処理結果データの保持期限・削除基準は決まっているか？
- 保持期限を過ぎたデータを削除する処理は実装されているか？
- 処理失敗時に事態を把握するため、バッチ処理を行う対象データの範囲、バッチ処理の開始時刻・終了時刻をログに出力しているか
- 処理失敗時、途中から再開できるようにどの処理・どの行でコケたかを出力しているか
- パフォーマンス劣化を監視するためのバッチ処理の所用時間を開始時刻・終了時刻から毎回計算せずとも済むようにログに出力しているか
- 終了見込み時間を報告できるようにするため、処理の進捗状況が分かるようなログを出力しているか
- ログからコピペしてすぐにlessできるように結果ファイルの絶対パスを出力しているか
- ログローテーションの設定はされているか？
- 処理が途中で失敗したりkillされたとしても、再実行するだけでリカバリ可能なロジックになっているか？
- 処理に必要なディレクトリやファイルの有無は事前にチェックしているか？
- 前処理が失敗している場合、無理やり動かずちゃんとエラーで落ちるか？
- バッチが複数回動作しなかった場合、手動実行を回数分ループさせてリカバリが必要な処理か？
- 実行時に引数で範囲指定して一括実行ができるか？
- リカバリ作業の内容がルーチン化できる内容か？
- リカバリ作業をワンボタンで行えるようにコマンド化しているか？
- 前回の処理が生き残っている間に次の処理が動くと不具合があるか？
- 処理が多重起動しないようにロックファイルを生成しているか？
- 処理途中にコケてもロックファイルが削除されるか？
- 運用上、ジョブが混雑している等で一時的に動作を止めておきたいケースはあるか？
- crontabのコメントアウト処理忘れなど、オペミスをなくすために停止ファイルを参照して起動防止をしているか？
- 実行時の引数に応じてログだけ吐き出すdryrunオプションはあるか？
- 手動実行時、入力された引数から処理内容を確認させるダイアログは出しているか？
- 処理が失敗した場合にメールやメッセージが運用者に飛ぶようになっているか？