状態ファイルが9日間runningのまま：集計監視の死角

複数のバッチを運用していると、ダッシュボードの合計値が静かな安心を与えます。処理量は進み、平均も崩れず、目立つエラーもない。個人ラボで長時間処理を預かり、止めどきを判断したい運用者にとっては、まず見たい数字でしょう。

ただし、合計が健全であることは、全ての構成要素が健全である証拠ではありません。

ある方針変更で、バッチ処理Aを別レーンへ移管しました。移管先は当日にエラー0で完走し、データ損失もありませんでした。実害はゼロです。それでも、後から状態ファイルを確認すると、移管前のレーンは9日間にわたり running を主張したままでした。

発見の契機は、内部ダッシュボードにレーン別の個別進捗パネルを追加したことです。追加初日の描画で、「実行中なのに更新なし」という矛盾に stale バッジが点灯しました。バッジの誤作動ではありません。設計された閾値どおり、正しく反応していました。問題は、それまで旧レーンにバッジを表示する面そのものがなかったことです。

合計値だけでは個別レーンの停止を隠す

総量だけを見る画面では、移管先のレーンが処理を進めていれば、全体は正常に見えます。停止した旧レーンは合計の中に混ざり、異常として輪郭を持ちません。

これは表示の美観ではなく、検知能力の問題です。構成要素を合計してしまうと、個別の停止は他の健全な要素に薄められます。レーン別に見た初日に化石化した状態が出た事実は、「以前は見落としていた」というより、「見るための面が存在しなかった」ことを示しています。

進捗を見ること自体の重要性は、状態ではなく進捗を確認する監視の記録でも扱いました。そこからさらに進めるなら、進捗をどの粒度で見るかを決める必要があります。集計だけでは、進捗監視も盲目になり得ます。

状態ファイルが9日間更新されなかった

このバッチのワーカーは、進捗を状態ファイル（JSON）へ20秒ごとに書き込んでいました。一方で、終了ステータスの書き込みは正常終了の経路にだけ置かれていました。

移管時、元のワーカーは kill されました。そのため最終処理は動かず、周期的な書き込みが最後に保存した running が残りました。その後、この状態ファイルを更新する主体は存在しません。状態だけが、すでに終わった仕事を「実行中」と報告し続けたわけです。

状態ファイルは事実そのものではなく、ある時点の自己申告です。AIエージェントの「設定しました」という報告と同じく、自己申告だけでは完了を確認できません。自己申告を証拠と区別して検証する考え方は、機械が書いた status: running にもそのまま適用できます。

移管後のレーンが監視対象から外れた

既存の stale 検査、ストール監視、ウォッチドッグは、いずれも現行レーンを対象にしていました。これは現行の処理を守るには自然な設計です。

しかし移管が完了した瞬間、旧レーンの状態ファイルの整合性には所有者がいなくなりました。移管先は正常に完走しているため、通常の監視は問題なしと判断します。旧レーンは停止済みでありながら running を残し、しかも誰も訂正しない状態になりました。

データの実害がなくても、状態の嘘を放置する理由にはなりません。再実行が必要か、処理がまだ資源を使うのか、容量をどう見積もるか。後の判断が、古い自己申告に静かに汚染されるからです。

移管済みを終端状態として持つ

対応では、状態を「実行中」でも「完了」でもない第3の状態、すなわち「移管済み」へ書き換えました。あわせて、移管先、移管時刻、経緯をメタデータとして残します。ダッシュボードでは専用チップで表示し、実行中の集計から除外しました。

重要なのは、移管を完了扱いに偽装しないことです。元のレーンは正常終了したわけではありません。一方、running のままでもありません。「移管済み」は、現実の処理責任が別レーンへ移ったことを表す状態です。

プロセスを kill して所有権を移すなら、そのプロセスが所有していた状態も、kill した側が始末する必要があります。停止手順はプロセスを止めた時点で終わりではなく、最終状態が現実と整合するまで続きます。

集計パネルとレーン別パネルを併設する条件

運用者が比較すべきなのは、集計画面だけで済ませるか、個別レーンの状態も併せて持つかです。後者は画面も確認対象も増えますが、異常を異常の形のまま見せられます。

レーン別パネルが向いているのは、個別の停止が再実行や資源配分の判断を変える環境です。向かないのは、個別状態を見ても行動が変わらず、集計だけで運用判断が完結する環境です。ただし、その前提は定期的に確認した方がよいでしょう。処理の移管や分割を始めた時点で、合計だけの画面は不足しやすくなります。

状態の更新時刻と終端条件を検査する

汎用化すると、検出すべき矛盾は明快です。

• in-progress を主張しているのに、対応する生きたプロセスがない
• in-progress を主張しているのに、進捗の増分がそのジョブの最大所要時間を超えて止まっている

どちらも、状態ファイルと現実を突き合わせることで見つかります。ジョブキュー、ETLのパーティション、シャーディングされたワーカー、マイクロサービスの成功率、CIのフレーキーテストでも考え方は同じです。全体の成功率が高くても、特定の構成要素だけが失敗し続けている可能性は残ります。

最後に、ダッシュボードと停止手順を確認するときの問いを残します。

• その数字は、いくつの構成要素を合計しているか。ひとつが止まったとき、数字は異常として動くか。
• kill を含む停止手順に、そのプロセスが書いていた状態ファイルを整合させる工程は入っているか。
• 「実行中」という自己申告を、生きたプロセスや進捗の増分と定期的に照合しているか。

集約は異常を薄めます。合計と平均は、死んだレーンを健全な数字の中に隠します。粒度は見た目の問題ではなく、検知能力そのものです。状態を現実と突き合わせ、停止の最後に状態を片付ける。それだけで、次の運用判断はかなり静かになります。