Warum Ihre ServiceNow-Scheduled-Jobs kollidieren
Jeder Job sieht für sich genommen vernünftig aus. Niemand betrachtet den gesamten Zeitplan auf einmal.
Wie Jobs tatsächlich kollidieren
Geplante Jobs werden fast immer unabhängig voneinander konfiguriert, von unterschiedlichen Personen, zu unterschiedlichen Zeitpunkten - nichts erzwingt, dass das Gesamtbild weiterhin zusammenpasst.
Dieselbe Tabelle, überlappende Zeitfenster
Zwei Jobs schreiben innerhalb desselben Zeitfensters auf dieselben Datensätze - wer zuletzt fertig wird, gewinnt still, und keiner der beiden Jobs weiß vom anderen.
Lang laufende Jobs verschieben sich in die Startzeit des nächsten Jobs
Ein Job, der früher zwei Minuten brauchte, braucht jetzt zwanzig, weil das Datenvolumen wächst - und der Zeitplan drumherum war nie dafür ausgelegt.
Retry-Stürme
Die eigene Retry-Logik eines fehlgeschlagenen Jobs überlappt mit seinem nächsten regulär geplanten Lauf - dieselbe Arbeit zweimal gleichzeitig versucht.
Abhängige Jobs ohne explizite Reihenfolge
Job B geht davon aus, dass Job A bereits gelaufen ist und sein Ergebnis produziert hat - nichts auf der Plattform erzwingt diese Annahme tatsächlich.
So wird es geprüft
Der konfigurierte Zeitplan und die tatsächliche Ausführungshistorie erzählen zwei unterschiedliche Geschichten - der Konflikt zeigt sich meist nur in der zweiten.
Tatsächliche Laufzeitfenster lesen, nicht nur den Cron-Ausdruck
Der konfigurierte Zeitplan eines Jobs sagt, wann er starten soll. Seine Ausführungshistorie sagt, wie lange er tatsächlich gebraucht hat und ob das mit etwas anderem überlappte - nur Zweiteres zeigt, was wirklich passiert ist.
Ausführungshistorie auf Überlappung prüfen, nicht nur auf Fehlschläge
Ein Job kann für sich erfolgreich sein und trotzdem mit einem anderen kollidiert sein, der gleichzeitig auf dieselbe Tabelle schreibt - Erfolg bedeutet nicht, dass sich die beiden Läufe nicht gegenseitig beeinflusst haben.
Muster, die zuerst geprüft werden sollten
- Jobs auf derselben Tabelle mit überlappenden konfigurierten Zeitfenstern
- Jobs, deren tatsächliche Laufzeit inzwischen die Lücke vor dem nächsten Job übersteigt
- Jobs mit Retry-Logik ohne Backoff
- Jobs mit einer nicht dokumentierten Abhängigkeit vom Ergebnis eines anderen Jobs
Die manuelle Variante skaliert nicht
Diese Prüfung richtig durchzuführen bedeutet, das echte konfigurierte Zeitfenster und die tatsächliche Ausführungshistorie jedes aktiven Jobs zu lesen - und diesen Abgleich jedes Mal zu wiederholen, wenn ein neuer Job hinzukommt oder sich die Laufzeit eines bestehenden ändert. Auf einer echten Instanz mit Dutzenden geplanter Jobs ist das kein einmaliges Audit - es ist eine dauerhafte Verpflichtung, für die niemand Zeit hat.
Diese Prüfung läuft kontinuierlich, automatisch
Unsere eigene Plattform, neo.ai, liest das reale Laufzeitfenster jedes geplanten Jobs nach Zeitplan und macht echte Überlappungen sichtbar, bevor sie in der Produktion kollidieren - auf einer Heatmap visualisiert, nicht in einer Tabelle vergraben, die niemand öffnet. Das ist eine von sieben Kategorien, die sie auf einer ServiceNow-Instanz überwacht.