連夜、失敗し続けた夜間バッチに、誰も気づかなかった理由

連夜、誰も気づかない。

毎晩決まった時刻に動くはずの商品同期バッチが、何日も連続で失敗していました。画面には異常の表示はなく、担当者のもとにも通知は届いていません。誰も気づかないまま、失敗は静かに積み重なっていたのです。

動いているつもりの夜間処理

夜間バッチというのは、性質上「動いていることが前提」で扱われがちです。人が介在しない時間に、人の代わりに黒子として働く仕組みだからこそ、正常に終わったのか、途中で落ちたのか、誰も確認しないまま朝を迎えてしまう。

今回問題になったのは、店舗の販売管理システムと連携する商品データの同期処理でした。毎晩、商品情報や部門情報を取り込むバッチが走る設計になっていましたが、実際には何晩にもわたって処理が失敗し続けていました。画面上は何も表示されず、担当者への連絡も一切なし。表面的には「昨日と同じように今日も動いている」ように見えていたのです。

ここで突きつけられるのは、単純な問いです。自社の自動処理は、本当に失敗したときに気づける仕組みになっているでしょうか。動いているはずという前提だけで運用されているシステムは、決して少なくありません。

沈黙を生んだ3つの穴

なぜ誰も気づかなかったのか。原因を分解すると、穴は一つではなく三つ重なっていました。

一つ目は、失敗そのものが記録に残らないことです。処理が途中で止まっても、その事実がログとして追跡できる形で保存されていませんでした。二つ目は、失敗しても誰にも通知が飛ばない構造です。仕組みとして「異常が起きたら人に知らせる」という経路が存在していませんでした。三つ目は、そもそも失敗の原因自体が毎晩発生する既知のエラーだったことです。夜ごとに同じ理由で3件のエラーが発生し、処理全体が異常終了していました。

この三つは互いに絡み合っています。毎晩同じエラーで落ちるという根本原因があり、それが記録されないために誰も気づかず、通知もされないために誰も対応しない。一つでも手当てされていれば、長期にわたる放置は生まれなかったはずです。

毎晩3件のエラーはなぜ消せなかったのか

根っこにあった毎晩3件のエラーは、データベースの重複エラー(ER_DUP_ENTRY)でした。商品コードは一致しているのに、既存のレコードと紐付いていない行が存在し、そこへ新しいデータを取り込もうとするたびに重複として弾かれていたのです。

言い換えると、システムの中に「同じ商品なのに紐付いていない同居人」が居座っていた状態でした。取込処理は毎晩この同居人にぶつかり、同じ理由で毎回転倒していたわけです。

修正では、商品コードが一致する未紐付けの行を優先して採用する形に処理を変更しました。比較的小さな修正でしたが、効果は毎晩の同期処理全体に及びます。同じ理由で同じ場所に毎晩つまずいていたエラーの温床を、根から断つ形になりました。

失敗を『残す』『飛ばす』の二段構え

重複エラーの温床を断っただけでは、まだ運用として十分ではありません。将来また別の理由で処理が失敗したとき、同じように誰も気づかないまま放置される可能性が残るからです。そこで手当てされたのが、記録と通知の二段構えでした。

まず、夜間バッチの実行結果を追跡できるログに刻む仕組みが整備されました。処理が成功したか失敗したかを、実行履歴を蓄積する専用のログから後から追える状態にしています。これにより「昨夜は本当に動いたのか」という問いに、誰でも答えられるようになりました。

続いて、失敗を検知したら担当の技術者へアラートとして通知を飛ばす仕組みが追加されました。同期処理が失敗した際に、同期失敗を示すアラートが技術者に届く経路が新設されています。記録が「後から振り返れる目」であるのに対し、通知は「今すぐ気づける耳」です。この二つが揃って初めて、障害は放置されずに人の手に渡ります。

処理を一本化して穴をふさぐ

もう一つ、構造面での補強もありました。商品や部門の取込処理は、手動で同期する経路と自動で夜間に走る経路の二つが存在していましたが、それぞれ別々のロジックで実装されていました。これでは片方を直しても、もう片方には修正が反映されません。

そこで、手動同期側の取込処理を共有のコア処理へ一本化する改修が行われました。コードの量としてはむしろ整理・削減の方向に働いた修正で、重複していたロジックが解消されています。処理の入口が複数あっても、内部の実処理は一つの経路に集約されたことで、今後どちらの経路から不具合が見つかっても、修正が両方に効くようになりました。これは今回の重複エラー対策そのものというより、同じ種類の問題が二度と別々に発生しないための地ならしです。

自社は障害に『気づける』か

今回の一連の対応を振り返ると、行われたことは大きく三つです。同じ理由で毎晩落ちていたエラーの根を断つこと、処理結果を記録に残すこと、失敗を人に知らせること。どれも単体では完結せず、三つが揃って初めて「気づける仕組み」になります。

これは特定のシステムだけの話ではありません。自社で動いている自動処理、たとえば夜間の集計、外部サービスとのデータ連携、定期レポートの生成などについて、次の三点を確認してみることをおすすめします。処理が失敗したとき、その事実は記録に残るか。記録が残るだけでなく、担当者に通知が届くか。そして、同じ理由で繰り返し失敗している既知の問題が放置されていないか。

一つでも欠けていれば、今この瞬間にも、画面の裏側で静かに失敗が積み重なっているかもしれません。動いているつもりのシステムほど、一度点検してみる価値があります。