Der nächtliche Import läuft seit Tagen nicht, und keiner merkt es? So überwachen Sie geplante Jobs
Bestellimport, Lagerabgleich und Nachtberichte fallen still aus, und man merkt es erst, wenn ein Kunde anruft. So überwachen Sie geplante Jobs rechtzeitig.
Vlado Pandžić · Gründer · Senior .NET-Architekt
Veröffentlicht · 6 Min. Lesezeit
Ein Szenario, das häufiger vorkommt, als jemand zugibt: Jede Nacht um 2 Uhr holt ein Job neue Bestellungen aus dem Webshop und trägt sie ins ERP ein. Er läuft seit Jahren, und niemand denkt an ihn.
Am Dienstag ändert der Partner, der den Webshop betreibt, die Zugangsdaten. Um 2 Uhr startet der Job, der Webshop weist ihn ab, und der Job endet. Still.
Am Freitag ruft ein Kunde an: Wo ist meine Ware? Erst dann schaut jemand nach und merkt, dass drei Tage Bestellungen nie im System angekommen sind.
Warum geplante Jobs still ausfallen
- Sie laufen im Hintergrund. Kein Bildschirm, niemand schaut hin, mitten in der Nacht.
- Der Fehler landet in einem Log, das niemand liest. Irgendwo auf einem Server gibt es eine Datei, in der genau steht, was passiert ist. Niemand öffnet sie.
- Sie laufen über ein altes Werkzeug auf einem alten Server. Die Windows-Aufgabenplanung auf einem Server, von dem keiner mehr weiß, wer ihn eingerichtet hat.
- Am tückischsten: Der Job endet „erfolgreich“, tut aber nichts. Er startet, meldet keinen Fehler und überträgt null Bestellungen. Alles sieht gut aus, und nichts ist gut.
Um welche Jobs es geht
Fast jedes Unternehmen hat mehrere solcher Jobs, ohne dass jemand sie je aufgelistet hat:
- Import von Bestellungen aus dem Webshop oder aus Partnerportalen
- Abgleich von Beständen und Preisen zwischen Systemen
- Export von Daten an die Buchhaltung
- nächtliche Berichte per E-Mail an die Geschäftsführung
- Backups von Datenbanken und Dokumenten
- Erneuerung von Zertifikaten und Bereinigung alter Daten
Jeder davon ist im Grunde das, worüber wir im Artikel über Systemintegration geschrieben haben: Automatisierung, die Handarbeit ersetzt. Aber eine Automatisierung, die still stoppt, ist schlimmer als Handarbeit, denn Handarbeit bemerkt wenigstens jemand.
Ein Log, das niemand liest, oder eine Warnung, die von selbst kommt
02:00:01 Import started
02:00:03 Connecting to shop API
02:00:04 401 Unauthorized
02:00:04 Import finished
Dasselbe am Mittwoch, Donnerstag und Freitag.
Bestellimport fehlgeschlagen
Der Webshop hat den Zugriff verweigert (401). Letzter erfolgreicher Import: Sonntag um 02:00, 164 Bestellungen.
Benachrichtigt: Vertriebsleitung · IT
Derselbe Fehler, zwei völlig unterschiedliche Folgen. Links drei Tage verlorene Bestellungen und verärgerte Kunden. Rechts weiß fünf Minuten nach dem Fehler jemand, was passiert ist, und bis zum Morgen ist es behoben.
Vier Fragen, die eine gute Überwachung stellt
Zu wissen, ob ein Job einen Fehler gemeldet hat, reicht nicht. Eine gute Überwachung prüft bei jedem Job vier Dinge:
- Ist er überhaupt gestartet? Wenn der Server ausgefallen ist oder jemand den Zeitplan geändert hat, gibt es keinen Fehler, weil gar nichts passiert ist.
- Ist er ohne Fehler durchgelaufen?
- Hat er getan, was er soll? Überträgt der Import sonst 120 bis 180 Bestellungen und heute null, stimmt etwas nicht, auch ohne Fehlermeldung.
- Wie lange hat er gedauert? Ein Job, der früher zwei Minuten brauchte und jetzt zwei Stunden, fällt wahrscheinlich morgen aus.
All das landet auf einem Bildschirm:
| Job | Letzter Lauf | Ergebnis | Status |
|---|---|---|---|
| Bestellimport aus dem Webshop | heute 02:00 | 0 Bestellungen (sonst 120–180) | Warnung |
| Export an die Buchhaltung | gestern 23:00 | nicht gestartet | Fehler |
| Bestandsabgleich | heute 03:00 | 2.412 Artikel | In Ordnung |
| Nächtlicher Vertriebsbericht | heute 06:00 | an 4 Adressen gesendet | In Ordnung |
So merken Sie, dass ein Job steht: vier Wege
Es braucht nicht alles auf einmal. Man beginnt mit dem Einfachsten, und jeder nächste Weg fängt ab, was der vorherige übersieht.
- 1Der Job meldet seinen Ausfall
- 2Der Job meldet sich lebendig
- 3Prüfung des Ergebnisses
- 4Zentrale Überwachung
- Der Job meldet seinen Ausfall selbst. Tritt ein Fehler auf, schickt der Job eine E-Mail oder eine Teams-Nachricht mit einer Beschreibung, was passiert ist. Das sind ein paar Zeilen Code im bestehenden Job. Aber wenn der Job gar nicht startet, gibt es niemanden, der die Nachricht schickt.
- Der Job meldet sich lebendig. Am Ende jedes erfolgreichen Laufs meldet sich der Job bei einem externen Dienst zur Überwachung geplanter Jobs. Der Dienst weiß, dass er jede Nacht bis 2:30 Uhr eine Meldung erwartet, und schickt selbst eine Warnung, wenn keine kommt. So fällt auch ein ausgefallener Server oder ein geänderter Zeitplan auf, denn der Dienst wartet auf eine Meldung, die nie kam. Solche Dienste gibt es mehrere, mit kleinen monatlichen Kosten oder kostenlos für wenige Jobs.
- Prüfung des Ergebnisses. Morgens schaut eine Abfrage in der Datenbank, wie viele Bestellungen über Nacht angekommen sind, und vergleicht mit dem Üblichen. Null statt 150 heißt Warnung, auch wenn kein Job einen Fehler gemeldet hat. Nur so fällt der tückischste Fall auf.
- Zentrale Überwachung. Gibt es viele Jobs, senden alle ihre Daten an eine Stelle, zum Beispiel an Application Insights, über das wir im Artikel zur Anwendungsüberwachung geschrieben haben. Dort liegt der Bildschirm aus der Tabelle oben, mit Regeln wie: der Job ist seit 26 Stunden nicht erfolgreich gelaufen, er hat null Datensätze übertragen, er hat dreimal so lange gedauert wie sonst.
| Weg | Fehler | Nicht gestartet | 0 Datensätze | Langsamer Job | Aufwand |
|---|---|---|---|---|---|
| Job meldet seinen Ausfall | ✓ | – | – | – | gering |
| Job meldet sich lebendig | ✓ | ✓ | – | – | gering |
| Prüfung des Ergebnisses | ✓ | ✓ | ✓ | – | gering bis mittel |
| Zentrale Überwachung | ✓ | ✓ | ✓ | ✓ | mittel |
Für die meisten Unternehmen decken der zweite und der dritte Weg zusammen fast alles ab, und sie sind in wenigen Tagen eingerichtet, ohne die Server anzufassen.
Müssen die Jobs nach Azure umziehen?
Nicht unbedingt. Die Überwachung kommt zu den Jobs dort, wo sie schon laufen: auf dem alten Server, in der Windows-Aufgabenplanung oder in der Anwendung. Ein Umzug in Azure Functions heißt, jeden Job neu zu schreiben und neu zu testen, und das ist keine Kleinigkeit.
Ein Umzug lohnt sich, wenn sich ohnehin etwas ändern muss: wenn der alte Server geht, zum Beispiel wegen des Support-Endes von Windows Server 2016, oder wenn der Job ohnehin überarbeitet wird. Dann bekommen Jobs in Azure Functions die Überwachung fast von selbst, und es gibt keinen Server mehr, der ausfällt und den Job mitnimmt. Wenn Sie einen Job doch nach Azure Functions verlagern, zeigt unser kostenloser Azure Functions Cron-Ausdruck Generator, wann er genau läuft.
Was Sie diese Woche tun können
Listen Sie alle geplanten Jobs im Unternehmen auf: was sie tun, wann sie laufen und wo. Beantworten Sie dann für jeden eine Frage: Wer wird benachrichtigt, wenn dieser Job ausfällt?
In den meisten Unternehmen lautet die häufigste Antwort „niemand“. Das heißt: Bei jedem dieser Jobs erfahren Sie es erst, wenn ein Kunde anruft.
Wie wir arbeiten
Genau das machen wir: Wir fügen bestehenden geplanten Jobs dort, wo sie laufen, eine Überwachung hinzu, damit Sie sofort wissen, wenn einer stoppt oder nicht tut, was er soll, und richten Warnungen ein, die die richtige Person erreichen. Einen Umzug nach Azure schlagen wir nur vor, wenn er sich lohnt. Wir beginnen mit einer Liste der Jobs und mit denen, die am meisten kosten, wenn sie stoppen. Der erste Schritt ist ein kostenloses 30-minütiges Gespräch.
Dieser Artikel dient nur der allgemeinen Information und ist keine Rechts-, Steuer-, Finanz- oder sonstige Fachberatung. Szenarien, Beispiele und Berechnungen dienen der Veranschaulichung. Nutzungsbedingungen und Haftungsausschluss.