Was passiert, wenn eine Automatisierung scheitert?
Der Normalfall ist schnell gebaut. Was eine Automatisierung betreibbar macht, ist ihr Verhalten, wenn etwas nicht klappt — und die Frage, wer es merkt.
Das lernen Sie
Zwei Fehlerarten, zwei Antworten
Vorübergehende Störung
- Zielsystem nicht erreichbar, Zeitüberschreitung
- Antwort: erneut versuchen, mit wachsendem Abstand
- Nach der letzten Wiederholung: in die Nacharbeit
Fachliche Ablehnung
- Pflichtangabe fehlt, Wert unbekannt, Regel verletzt
- Antwort: nicht wiederholen — es ändert sich nichts
- Sofort in die Nacharbeit, mit dem Grund
Wer beide gleich behandelt, bekommt eines von zwei Problemen: Entweder wird eine fachliche Ablehnung endlos wiederholt und belastet das Zielsystem — oder eine kurze Störung wirft Vorgänge weg, die beim zweiten Versuch durchgelaufen wären.
Die Nacharbeit ist kein Fehlerprotokoll
Ein Protokoll schreibt mit, was passiert ist. Eine Nacharbeit ist eine Arbeitsliste: Jeder Eintrag ist ein Vorgang, der eine Entscheidung braucht, mit dem Grund daneben und einer Möglichkeit, ihn nach der Korrektur erneut anzustoßen.
Ohne diese Liste landen gescheiterte Vorgänge im Protokoll, das niemand liest — und fallen beim Monatsabgleich auf, wenn die Korrektur teurer ist.
Praktisch gehören dazu: eine Übersicht mit Anzahl und Alter der offenen Fälle, die Möglichkeit zur Wiedervorlage nach der Korrektur, und eine Zuständigkeit. Eine Liste ohne Zuständigen wächst.
Wiederholungen brauchen eine Obergrenze
Bei einer vorübergehenden Störung ist Wiederholen richtig — aber nicht beliebig oft und nicht im Sekundentakt. Üblich ist ein wachsender Abstand und eine feste Obergrenze, nach der der Vorgang in die Nacharbeit geht.
Dazu gehört eine zweite Eigenschaft: Die Verarbeitung muss wiederholbar sein, ohne doppelte Wirkung. Wenn ein Auftrag beim ersten Versuch angelegt wurde und erst die Antwort verloren ging, darf der zweite Versuch keinen zweiten Auftrag erzeugen. Dafür trägt jeder Vorgang eine eindeutige Kennung, die das Zielsystem wiedererkennt.
Ein Beispiel aus der Praxis
Der Ausfall, den niemand bemerkte
Eine nächtliche Übertragung lief über Wochen zuverlässig. Dann änderte sich auf der Gegenseite ein Zugangsschlüssel. Die Übertragung scheiterte — still, jede Nacht. Aufgefallen ist es nach elf Tagen, als jemand Zahlen vermisste.
Die Lehre ist nicht, dass die Übertragung einen Fehler hatte. Sie hatte keinen Wächter: Niemand prüfte, ob sie überhaupt gelaufen ist. Eine Überwachung, die meldet, wenn ein Lauf AUSBLEIBT, ist wichtiger als eine, die bei einem Fehler meldet — ein ausbleibender Lauf meldet sich nämlich nie von selbst.
Wer merkt, dass nichts mehr läuft?
Das ist die Frage, die am häufigsten offen bleibt. Drei Dinge beantworten sie:
Mit diesen drei Angaben wird aus einer Automatisierung etwas, das man betreiben kann. Ohne sie ist sie ein Stück Technik, das funktioniert, solange niemand hinsieht.
Häufige Missverständnisse
Über den Autor
Fabian Lücker ist geschäftsführender Gesellschafter der PHP-Schmiede KG in Rheine und seit 2007 in der Softwareentwicklung tätig. Er verantwortet Entwicklung und Konzeption und schreibt hier über Entscheidungen, die in echten Projekten anfallen.