バッチの異常終了にどう気づき、どう流し直すか — 監視とリランの設計

オンプレのバッチ運用は、オペレータの目視・電話連絡・手順書という「人の仕組み」で回ってきました。AWS移行はこの暗黙知を明文化して自動化する絶好の機会です。逆に言えば、監視とリランを設計しないままバッチだけ移すと、人の仕組みも失った最悪の状態になります。

01「気づく」の設計：異常終了と遅延の2種類

検知すべきは2種類あります。1つは異常終了——終了コードやエラーログをCloudWatchで拾い、SNSで通知（監視10選の作法）。もう1つが忘れられがちな遅延です。「毎朝5時までに終わるはずのバッチが、まだ走っている／そもそも起動していない」は、異常終了の通知では捕まえられません。「所定時刻に完了マーカーがなければ通知」という締切監視を、業務影響の大きいジョブには必ず付けてください。

02通知は2段階に分ける

深夜に人を起こす価値がある失敗（翌朝の業務に影響する基幹ジョブ）と、翌営業日で間に合う失敗（レポート系）を同じ通知先に流すと、数週間で全部が無視されます。SNSトピックをwarning／criticalの2つに分け、ジョブごとに「これは誰かを起こすべきか」を仕分ける——この仕分け表自体が、オンプレ運用の暗黙知の棚卸しになります。

03「流し直す」の設計：リラン手順書

異常終了の後、どこから・どうやって流し直すか。オンプレではベテランの頭の中にあったこの判断を、ジョブごとに明文化します。最低限の項目は：

• 再実行の起点（最初から／失敗ステップから——ステート分割が効く場所）
• 二重実行の防止（処理済みマーカー・実行中ロックの確認方法）
• データの巻き戻し要否（中途半端に書き込まれたデータの扱い）
• 再実行のリミット（何時までに完了しなければ業務側にエスカレーションするか）

04べき等性は最強のリラン対策

「同じ入力で何度実行しても結果が同じ」——べき等性が確保されたジョブは、リラン判断が「とりあえず最初から流し直す」で済みます。処理前ファイルの退避、洗い替え方式（DELETE-INSERT）、処理済みテーブルでの重複排除など、実現手段は古典的なもので十分です。移行時にべき等性だけは改修投資する価値があります。運用の単純さは、そのまま深夜対応の速さです。

05実行履歴は資産になる

SSMやStep Functionsに残る実行履歴は、単なるログではなく改善の材料です。月次で「失敗回数の多いジョブ」「実行時間が伸びているジョブ」を棚卸しすると、障害の芽を先に摘めます。この月次レビューまで含めて運用設計です——私たちのマネージド運用では、この棚卸しを標準メニューにしています。