【要約】exit code 0を成功判定に使わないジョブ設計 - 実装手順 [Zenn_Python] | Summary by TechDistill
> Source: Zenn_Python
Execute Primary Source
// Problem
自動化ジョブの設計者が、プロセスの正常終了と業務目的の達成を混同することで、運用上の重大なリスクを招く問題がある。単にプログラムが動いたとしても、期待する成果が得られていないケースが多いためである。
- ・exit code 0が、業務上の失敗（公開停止や在庫不足）を隠蔽してしまう。
- ・自由文のログに依存するため、再実行時にどこまで完了したか人間が推測せざるを得ない。
- ・再試行時に外部処理が重複し、二重投稿などの副作用を引き起こす可能性がある。
// Approach
設計者は、業務状態を構造化データとして定義し、工程ごとに完了条件を明確化するアプローチを採用する。これにより、機械的な判断と安全な再開を可能にする。
- ・rc（プロセス分類）とfinal_status（業務状態）を分離して管理する。
- ・完了条件を「生成」「品質」「操作」「結果」の4段階に定義し、通過した段階を記録する。
- ・入力と結果の契約をJSON形式で固定し、成果物パスを必須とする。
- ・ハッシュ値や外部状態の確認を行い、再実行時の冪等性を担保する。
// Result
この設計を導入することで、運用担当者は正確な進捗把握と安全なリカバリが可能になる。エラー発生時でも、前回の最終工程から正確に処理を再開できる体制が整う。
- ・「タスク起動回数」ではなく「実URL確認件数」などの実効的な指標で監視が可能になる。
- ・再起動やプロセス停止が発生しても、外部操作の重複を防ぎつつ復旧できる。
- ・「cover_generation_failed」などの詳細な停止理由を構造的に把握できる。
Senior Engineer Insight
> 非常に実践的で、大規模運用を見据えた優れた設計思想だ。多くの開発者が「動くコード」に終始し、運用フェーズでの「状態の不整合」を軽視する傾向にある。この設計は、エラーハンドリングを単なる例外処理から、厳格な「状態遷移」へと昇華させている。実装コストは増すが、監視の自動化と復旧コストの低減を考えれば、ミッションクリティカルな自動化基盤では必須の要件と言える。特に、外部システムとの連携が絡むジョブでは、このレベルの設計が不可欠だ。