夜間バッチの失敗通知から運用の入口を考える
夜間バッチの失敗通知を、単なるアラートではなく、検知、判断、再実行、人への引き渡しに分けて考えた短い運用メモ。
夜間バッチが失敗したとき、Slackに赤い通知を出すだけでは運用は楽になりません。
通知自体は必要ですが、本当に困るのはその後です。誰が見るのか、再実行してよいのか、入力データを直すべきなのか、担当者へ連絡するべきなのか。この判断が毎回その場で決まると、通知は増えているのに運用は軽くなりません。
以前、夜間バッチの失敗通知を整理したときは、アラートを4つに分けて見ました。
検知
-> 原因のあたりを付ける
-> 再実行可否を判断する
-> 人に引き渡す
この分け方にすると、通知に必要な情報も変わります。終了コードだけでは足りません。対象日、入力ファイル、件数差分、前回成功時刻、再実行コマンド、連絡先まで一緒に見える方が、朝の判断はかなり楽になります。
自動復旧まで作る必要はありません。むしろ最初は、再実行してよい条件を明確にするだけで十分です。通知は、失敗を知らせるものではなく、人間が次の判断をするための画面だと考えた方が設計しやすくなります。
この感覚は、AIエージェントを運用に入れるときにもそのまま残る気がしています。エージェントが何かを検知しても、全部を自動で処理させる必要はありません。どこまで判断させ、どこから人に渡すかを先に決める方が、結果的に壊れにくくなります。