---
title: "夜間バッチの失敗通知から運用の入口を考える"
description: "夜間バッチの失敗通知を、単なるアラートではなく、検知、判断、再実行、人への引き渡しに分けて考えた短い運用メモ。"
lang: "ja"
canonical: "https://llm-lab.dev/posts/nightly-batch-alert-agentops-note/"
source: "https://llm-lab.dev/posts/nightly-batch-alert-agentops-note.md"
publishedAt: "2024-02-08"
updatedAt: "2024-02-08"
category: "技術メモ"
tags:
  - "operations"
  - "batch"
  - "automation"
---

# 夜間バッチの失敗通知から運用の入口を考える

> [!NOTE]
> この記事で確認したこと
>
> 夜間バッチの失敗通知は、「失敗しました」で止めると運用の入口になりません。対象日、入力ファイル、件数差分、前回成功時刻、再実行コマンド、連絡先を一緒に出すと、朝に人が判断すべきことが見えやすくなります。
>
> 最初から自動復旧まで作る必要はなく、まず再実行してよい条件、入力データを直す条件、人へ引き渡す条件を分けるだけでも効果があります。通知は失敗の告知ではなく、次の判断のための画面として設計したほうが扱いやすいです。

夜間バッチが失敗したとき、Slackに赤い通知を出すだけでは運用は楽になりません。

通知自体は必要ですが、本当に困るのはその後です。誰が見るのか、再実行してよいのか、入力データを直すべきなのか、担当者へ連絡するべきなのか。この判断が毎回その場で決まると、通知は増えているのに運用は軽くなりません。

以前、夜間バッチの失敗通知を整理したときは、アラートを4つに分けて見ました。

```text
検知
  -> 原因のあたりを付ける
  -> 再実行可否を判断する
  -> 人に引き渡す
```

この分け方にすると、通知に必要な情報も変わります。終了コードだけでは足りません。対象日、入力ファイル、件数差分、前回成功時刻、再実行コマンド、連絡先まで一緒に見える方が、朝の判断はかなり楽になります。

自動復旧まで作る必要はありません。むしろ最初は、再実行してよい条件を明確にするだけで十分です。通知は、失敗を知らせるものではなく、人間が次の判断をするための画面だと考えた方が設計しやすくなります。

この感覚は、AIエージェントを運用に入れるときにもそのまま残る気がしています。エージェントが何かを検知しても、全部を自動で処理させる必要はありません。どこまで判断させ、どこから人に渡すかを先に決める方が、結果的に壊れにくくなります。