【要約】exit code 0を成功判定に使わないジョブ設計 - 障害分析 [Zenn_Python] | Summary by TechDistill
> Source: Zenn_Python
Execute Primary Source
// Problem
自動化システムを運用するエンジニアは、プロセスの正常終了が業務の成功を意味しない問題に直面する。プロセスが正常に終わっても、実態として業務が失敗しているケースが多いためである。
- ・exit code 0が、公開失敗や成果物不足といった実害を隠蔽する。
- ・自由文ログのみの管理では、障害発生時の状況把握や集計が困難になる。
- ・再実行時に外部処理が重複し、二重投稿などの副作用が発生する。
// Approach
開発者は、プロセスの成否と業務の成否を分離し、状態を構造化して記録する手法を採用する。これにより、機械的な判断と正確な再開を可能にする。
- ・
rc（プロセス分類）とfinal_status（業務状態）を分離して管理する。 - ・完了条件を「生成・品質・操作・結果」の4段階に定義し、進捗を記録する。
- ・成果物パスやJSON形式の構造化データを出力し、次工程が機械的に判断可能にする。
- ・SHA-256等のハッシュ値を用いて、重複実行を防ぐ冪等性を確保する。
// Result
この設計を導入することで、運用者は業務の真の達成度を正確に把握できるようになる。監視指標が「起動回数」から「実URLの確認件数」などの実数値へ進化する。
- ・障害発生時、最後に通過した工程から正確に処理を再開できる。
- ・PCの再起動やランナーの停止が発生しても、外部操作の重複を避けつつ復旧が可能。
- ・「処理は終わったが目的物がない」という、運用上最も厄介な状態を即座に検知できる。
Senior Engineer Insight
> 極めて実践的だ。多くの現場では「プロセスが落ちないこと」を成功と誤認し、業務上の不備を見逃す。本手法は状態を「証拠」として外部化し、分散環境での信頼性を劇的に高める。実装コストは増すが、運用時のMTTR（平均復旧時間）短縮と、誤動作によるビジネス損失防止の観点から、極めて投資対効果が高い。特に、副作用を伴う外部API操作を含むジョブでは必須の設計思想と言える。