문제
예약 작업이 여러 단계로 이어질 때, 중간 단계의 검증 도구나 하위 프로세스가 실패해도 나머지 단계가 그대로 진행되고 실행은 성공 상태로 끝날 수 있다. 보고서의 마지막 줄이 성공이라는 이유만으로 완료로 판정하면, 정작 판정의 근거가 되는 산출물은 비어 있거나 이전 상태 그대로일 수 있다.
운영 패턴
1. 예약 작업의 완료 판정 기준을 실행 상태가 아니라 정확히 하나뿐인 정준 산출물로 정한다.
2. 중간 검증이나 하위 프로세스가 실패했다는 기록을 보면, 마지막 상태가 성공이더라도 그 산출물을 처음부터 다시 확인한다.
3. 확인은 존재 여부만이 아니라 되돌려 읽기로 한다. 산출물을 다시 열어 오늘 날짜와 의도한 내용이 들어 있는지 본다.
4. 회복을 증명할 때는 실패 시각, 확인 시각, 확인 방법, 그리고 통과한 항목을 그대로 남긴다.
5. 두 개의 기록이 서로 다른 상태를 말하면, 더 낙관적인 쪽이 아니라 산출물 쪽을 따른다.
왜 중요한가
예약 작업은 여러 주체의 기록을 남긴다. 중간 실패 뒤에 이어진 성공 상태는 사실의 요약이 아니라 실행의 마지막 한 줄일 뿐이다. 기록을 서로 맞추는 기준을 산출물에 두면, 실제로 만들어진 결과와 판정이 어긋나는 지점을 곧바로 잡을 수 있다.
완료 기준
중간 실패가 있었던 실행을 성공으로 기록하려면, 정준 산출물을 직접 되돌려 읽어 오늘 날짜와 의도한 내용을 확인하고, 확인 시각과 방법을 증거로 남겼을 때뿐이다. 산출물 확인 없이 마지막 상태만으로 완료를 판정하는 일이 없어야 한다.
Problem
When a scheduled run chains several steps, a validator or child process in the middle can fail while the remaining steps continue and the run ends with a success status. Treating the final line of the report as the completion verdict lets a run pass while the artifact behind the verdict is empty or stale.
Operating pattern
1. Define the completion bar of a scheduled run as the one canonical artifact, not the run status.
2. When any record shows an intermediate validation or subprocess failure, re-verify that artifact from scratch even if the final status was success.
3. Verify by read-back, not existence: open the artifact again and confirm it carries today's date and the intended content.
4. When proving recovery, record the failure time, the verification time, the method, and the checks that passed — exactly as observed.
5. If two records disagree, follow the artifact over the more optimistic one.
Why it matters
A scheduled run leaves records from several actors. A success status after an intermediate failure is the last line of an execution, not a summary of fact. Anchoring reconciliation on the artifact catches the gap between what was actually produced and what was claimed, at the moment it appears.
Completion bar
A run with an intermediate failure may be recorded as successful only after the canonical artifact is opened and read back to confirm today's date and intended content, with the verification time and method recorded as evidence. No completion verdict rests on the final status alone.
问题
当定时任务串联多个步骤时，中间某个校验器或子进程可能失败，而其余步骤照常继续，运行最终以成功状态结束。只要报告最后一行写着成功就判定完成，判定的依据——产物本身——却可能仍是空的或过期的。
运维模式
1. 把定时任务的完成标准定义为唯一的正典产物，而不是运行状态。
2. 只要记录里出现中途校验或子进程失败，即使最终状态是成功，也从头重新核对这份产物。
3. 核对不是看它存在与否，而是读回验证：重新打开产物，确认里面是今天的日期和预期内容。
4. 证明恢复时，把失败时间、核对时间、核对方法和通过的检查项按原样记录下来。
5. 两份记录说法不一致时，跟随产物，而不是更乐观的那一份。
为什么重要
一次定时运行会留下多个主体的记录。中途失败之后的成功状态只是执行的最后一行，不是事实的总结。把对账基准放在产物上，就能在实际产出与所作判定出现分歧的那一刻抓住它。
完成标准
发生过中途失败的运行，只有在直接打开正典产物并读回确认其中是今天的日期和预期内容、且核对时间与方法已作为证据留下之后，才能记为成功。任何完成判定都不能只凭最终状态。
問題
定期実行が複数の工程をつなぐとき、途中のバリデータや子プロセスが失敗しても残りの工程は進み、実行は成功ステータスで終わることがある。報告の最終行が成功だからと完了判定すると、判定のより所である成果物は空のまま、あるいは古いままかもしれない。
運用パターン
1. 定期実行の完了基準を実行ステータスではなく、ただ一つの正典成果物に定める。
2. 中間の検証や子プロセスの失敗を示す記録があれば、最終ステータスが成功でもその成果物を最初から確認し直す。
3. 確認は存在確認ではなく読み戻しで行う。成果物を再度開き、今日の日付と意図した内容が入っていることを確かめる。
4. 回復を証明するときは、失敗時刻・確認時刻・確認方法・通過した項目をそのまま記録する。
5. 二つの記録が食い違う場合は、より楽観的な側ではなく成果物に従う。
なぜ重要か
定期実行は複数の主体の記録を残す。中間失敗の後の成功ステータスは、実行の最終行であって事実の要約ではない。突き合わせの基準を成果物に置くことで、実際に作られた結果と判定のずれを、生じた瞬間に捉えられる。
完了基準
中間失敗のあった実行を成功として記録できるのは、正典成果物を直接開いて読み戻し、今日の日付と意図した内容を確認し、確認時刻と方法を証拠として残した後だけである。最終ステータスだけに基づく完了判定を残してはならない。