BBQを諦めた日 ― 基幹システムの夜間ジョブ障害対応で学んだこと

社内SEとして働いていると、休日や深夜に予期せぬ電話が鳴ることがあります。

今回は、私がサーバー・インフラ担当として経験した夜間ジョブ障害の話です。

基幹システムの夜間ジョブとは

多くの企業の基幹システムでは、日中の業務終了後に大量のバッチ処理が実行されます。

例えば、

• 売上データの集計

• 在庫情報の更新

• 会計システムへの連携

• 翌営業日の帳票作成

• 他システムへのデータ送信

といった処理です。

これらは一般的に「ジョブネット」と呼ばれる仕組みで管理されており、前の処理が正常終了すると次の処理が起動する形で連鎖的に実行されます。

夜間の限られた時間の中で数百本、場合によっては数千本のジョブが動いているため、1本のジョブ停止が業務全体に影響を与えることも珍しくありません。

午前4時の電話

当時、私は中途入社した会社でサーバー・インフラ担当をしていました。

ある日、大学時代のゼミ仲間とBBQに行く約束をしていました。

久しぶりの再会ということもあり、とても楽しみにしていました。

しかし、その日の午前4時。

携帯電話が鳴りました。

運用SEからの連絡です。

「夜間ジョブが止まっています」

嫌な予感がしました。

原因は“たまたま”起きた条件の重なり

通常、途中でジョブが異常終了しても後続処理が継続できるよう設計されていました。

ところが今回は状況が違いました。

あるジョブが処理対象ファイルを長時間占有してしまい、想定以上に処理時間が延伸。

その結果、後続ジョブが待ち状態となり、ジョブネット全体が停止してしまったのです。

しかも私はインフラ担当。

サーバーやOS、ジョブ管理システムは理解していても、個々の業務ジョブの内容までは把握していません。

ジョブの業務的な意味や実行順序はアプリケーションチームの管轄でした。

運用SEとの長い戦い

アプリ担当者もすぐには捕まらず、まずは運用SEと電話で状況確認を開始しました。

停止しているジョブを調査し、

• 前提条件を確認

• 関連ファイルを確認

• 実行ログを確認

• 影響範囲を確認

しながら、一つひとつ後続ジョブを手動で起動していきました。

ジョブ管理画面とサーバーログを何度も見比べながら、

「次はこれを動かして大丈夫か」

「このジョブは飛ばして問題ないか」

を慎重に判断していきます。

一歩間違えるとデータ不整合につながるため、焦りは禁物です。

気付けば午前11時

対応を続けているうちに外はすっかり明るくなっていました。

時計を見ると午前11時。

当然ながらBBQには間に合いませんでした。

楽しみにしていた予定はなくなりましたが、その日の夜間処理を無事完了させることができました。

システムとしては最悪の事態を回避できたのです。

この経験から学んだこと

この障害対応で学んだことが3つあります。

1. システムは技術だけでは動かない

インフラ担当、アプリ担当、運用担当。

それぞれが異なる知識を持っています。

障害時には技術力以上に、関係者との連携が重要です。

2. 業務知識は武器になる

「自分はインフラ担当だから」

そう考えていましたが、業務処理の流れを理解していれば、もっと早く復旧できたかもしれません。

障害対応力を高めるためには、担当領域を超えた知識も必要だと実感しました。

3. 障害対応は事前準備で差が出る

後から振り返ると、

• ジョブ依存関係の整理

• 障害時手順書の整備

• 関係者連絡網の整備

があれば、復旧時間は大幅に短縮できたと思います。

障害対応の本番は、実は障害発生前から始まっているのです。

おわりに

社内SEとして20年以上働いていますが、今でも障害対応の電話が鳴ると少し緊張します。

ただ、その経験の積み重ねが今の自分を作っているのも事実です。

BBQには参加できませんでしたが、あの日の経験は今でも鮮明に覚えています。

そして、障害対応で最も大切なのは「慌てないこと」。

どんな大規模障害でも、一つひとつ状況を整理しながら進めれば、必ず解決への道筋は見えてきます。