Scheduled Job
Geplanter Auftrag
Ein geplanter Job startet die Backend-Arbeit zu einer gewählten Zeit oder in einem wiederkehrenden Intervall. Seine Regeln müssen festlegen, was nach einem verspäteten, verpassten oder sich überschneidenden Start passiert.
time zone + schedule + missed-run deadline + overlap policy -> one job attempttimeZone: Asia/TaipeiSpringen beim Laufen✓time zone + schedule + missed-run deadline + overlap policy -> one job attemptJOBEin weiteres Beispiel
Ein Kubernetes CronJob startet jeden Tag um 02:30 Uhr in `Asia/Taipei` ein Backup. Seine Richtlinie überspringt einen neuen Lauf, solange der letzte aktiv ist. Er begrenzt auch, wie spät ein verpasster Lauf starten darf. Das Backup verwendet die geplante Startzeit als Sicherheitswert für Wiederholungen.
Hauptteile
- 01Zeitplan und Zeitzone
- 02nächster geplanter Start
- 03Verpasste-Lauf-Regel
- 04Überlappungsrichtlinie
- 05Ausführende Identität
- 06Verlauf ausführen und Warnung
Verwenden Sie es, wenn
Verwenden Sie es für regelmäßige Backups, Berichte, Aufräumarbeiten oder andere zeitgebundene Aufgaben. Definieren Sie die Zeitzone, die Regel für verspätete Ausführung, die Überlappungsregel und das sichere Wiederholungsverhalten.
Nutze es nicht, wenn
Gehe nicht davon aus, dass ein Zeitplan genau in der Sekunde oder genau einmal ausgeführt wird. Verwende einen Ereignis-Trigger, wenn die Arbeit zu einer Datenänderung gehört, anstatt zu einer Uhrzeit.
In Code verwendeter Name
time zone + schedule + missed-run deadline + overlap policy -> one job attempt Vor dem Ausliefern
Check contracts and invariants, authorization, and input limits. Test retries, one-time effects, timeouts, and partial failures. Verify data integrity, compatibility, monitoring, recovery, and rollback.
Outcome: Complete the task with Geplanter Auftrag (Scheduled Job). User context: Ein Kubernetes CronJob startet jeden Tag um 02:30 Uhr in `Asia/Taipei` ein Backup. Seine Richtlinie überspringt einen neuen Lauf, solange der letzte aktiv ist. Er begrenzt auch, wie spät ein verpasster Lauf starten darf. Das Backup verwendet die geplante Startzeit als Sicherheitswert für Wiederholungen. Technical concept or control: Geplanter Auftrag (Scheduled Job). Why it fits: Verwenden Sie es für regelmäßige Backups, Berichte, Aufräumarbeiten oder andere zeitgebundene Aufgaben. Definieren Sie die Zeitzone, die Regel für verspätete Ausführung, die Überlappungsregel und das sichere Wiederholungsverhalten. Do not use it when: Gehe nicht davon aus, dass ein Zeitplan genau in der Sekunde oder genau einmal ausgeführt wird. Verwende einen Ereignis-Trigger, wenn die Arbeit zu einer Datenänderung gehört, anstatt zu einer Uhrzeit. Engineering requirements: Define inputs, outputs, contracts, and rules that must always hold. Set authorization and input checks. Define failures, timeouts, retries, one-time effects, data moves, and compatibility limits. Operations: Add useful signals and logs that hide sensitive data. Set capacity limits and write an operator guide. Test recovery and rollback. Acceptance criteria: Contract and failure-path tests pass. Data and authorization rules still hold during retries and partial failures. Check performance limits, monitoring, recovery, and rollback. Evidence and limits (evidence boundary): Kein einziger offizieller Standard kontrolliert den gesamten Begriff. Seine Bedeutung kann sich zwischen Teams, Plattformen oder Frameworks ändern. Unknowns to confirm: Where the code runs, data stores, traffic shape, consistency needs, and the security boundary. Also confirm the compatibility period, service goals, and rollback limits.
Diese Anfrage prüfen
Review how Geplanter Auftrag (Scheduled Job) is used now. Definition: Ein geplanter Job startet die Backend-Arbeit zu einer gewählten Zeit oder in einem wiederkehrenden Intervall. Seine Regeln müssen festlegen, was nach einem verspäteten, verpassten oder sich überschneidenden Start passiert. Release checks: Check contracts and invariants, authorization, and input limits. Test retries, one-time effects, timeouts, and partial failures. Verify data integrity, compatibility, monitoring, recovery, and rollback. Before changing code, list the evidence, gaps, severity, and the smallest safe fix.