Der häufigste Fehlerfall in einer Automatisierung ist nicht die klare Absage, sondern die fehlende Antwort. Die Strecke hat gesendet, das Netz ist weg, und niemand kann sagen, ob der Auftrag jetzt existiert oder nicht. Dasselbe Bild entsteht bei einem Timeout, einem 502 oder einem Status, der auf „in Bearbeitung“ stehen bleibt.
Dann stehen drei Wege offen: wiederholen, nachschauen oder an den Menschen geben. Einen vierten gibt es nicht — höchstens das Hoffen, dass schon irgendetwas Richtiges passiert sei. Hoffen erzeugt entweder einen doppelten Datensatz oder einen verlorenen Vorgang. Beides findet jemand erst Wochen später.
Dieser Beitrag entscheidet zwischen den drei Wegen im Betrieb. Warum blindes Wiederholen gefährlich ist, steht unter Idempotenz in automatisierten Abläufen. Hier geht es nicht um die Eigenschaft einer Schnittstelle, sondern um die Frage vor dem ersten produktiven Lauf: Was tut die Strecke, wenn sie das Ergebnis nicht kennt?
Was ein unklares Ergebnis ist
Ein klares Ergebnis legt den nächsten Schritt fest: bestätigt, fachlich abgelehnt, oder schon vor dem Schreiben gescheitert. Die Strecke weiß, wo sie steht.
Ein unklares Ergebnis ist das Gegenteil. Die Anfrage ist unterwegs oder schon angekommen, die Antwort fehlt oder ist nicht zu deuten.
- Timeout oder Verbindungsabbruch nach dem Senden
- Gateway-Fehler (
502,503,504), die vor und nach der Verarbeitung entstehen können - Eine Annahme ohne Endstatus — „queued“, „pending“ — und dann Stille
- Ein Teilerfolg: im ersten System angelegt, im zweiten nicht
Microsoft zieht in seinem Retry-Muster denselben Schnitt: Wiederholen eignet sich für vorübergehende Störungen, nicht für fachliche Fehler und nicht für Störungen, die voraussichtlich andauern. In vielen Strecken fehlt dieser Schnitt. Alles, was nicht 200 ist, landet in derselben Schleife.
Zwei Kosten sind ungleich: doppelt ausführen (zweiter Auftrag, zweite Buchung, zweite Nachricht) oder nicht ausführen (der Vorgang bleibt liegen, die Frist läuft). Welche teurer ist, entscheidet den Weg. Wer das nicht vorher festlegt, hat den Fehlerfall verschoben.
Drei Wege
1. Wiederholen
Wiederholen heißt: dieselbe Operation erneut anstoßen, in der Erwartung, dass der erste Versuch entweder nicht angekommen ist oder der zweite keinen neuen Zustand erzeugt.
Das ist der richtige Weg nur unter drei Bedingungen gleichzeitig:
- Der Fehler ist vorübergehend. Eine fachliche Ablehnung wird durch den nächsten Versuch nicht richtiger.
- Die Operation darf mehrfach ankommen, ohne einen zweiten fachlichen Effekt zu erzeugen — oder die Gegenstelle erkennt denselben Vorgang wieder.
- Die Zahl der Versuche ist begrenzt. Unbegrenzt wiederholen ist keine Fehlerbehandlung, sondern eine Lastspitze.
Marc Brooker hält in der Amazon Builders’ Library den Punkt fest, der am häufigsten übersehen wird: Ein Timeout bedeutet nicht, dass die Nebenwirkung ausgeblieben ist. Die Gegenstelle kann den Auftrag längst angelegt und nur die Bestätigung verloren haben. Derselbe Text warnt vor dem zweiten Schaden: Wiederholungen erhöhen die Last genau dort, wo der Dienst schon schwankt. Deshalb gehören Abstand, Streuung und eine Obergrenze dazu.
Wiederholen ist kein Reflex. Es ist der Weg für den kleinen, vorübergehenden, wiederholbaren Schritt. Fehlt eine der drei Bedingungen, ist es der falsche erste Griff.
2. Nachschauen
Nachschauen heißt: nicht noch einmal tun, sondern zuerst feststellen, was schon da ist. Die Strecke fragt das Zielsystem mit einem fachlichen Schlüssel — Belegnummer, Bestellreferenz, Vorgangs-ID — und entscheidet erst danach.
Das ist der richtige Weg, wenn die Gegenstelle eine lesbare Wahrheit anbietet und der Vorgang sich daran erkennen lässt. Viele Systeme kennen keinen Idempotenzschlüssel, aber eine Nummer, die der Vorgang schon vor dem ersten Schreiben besitzt. Dann gilt:
- Liegt der Datensatz schon vor? Der unklare Versuch ist erledigt.
- Liegt er nicht vor? Erst dann schreiben — und das neue Ergebnis wieder als möglicherweise unklar behandeln.
Die bekannte Lücke: Zwischen Prüfung und Schreiben kann ein zweiter Lauf dieselbe Leere sehen. Für einen nächtlichen Lauf mit einem Arbeiter ist das meist tragbar. Für parallele Läufe über dieselbe Menge nicht. Dann braucht es eine Sperre am eigenen Vorgangsspeicher oder den Weg zum Menschen.
Die Abfrage muss jemand betreiben. Felder ändern sich, Archivierung setzt ein, Paginierung kippt. Liefert der Abgleich plötzlich keine Treffer mehr bei gleichem Volumen, ist das ein Alarm — nicht der Anlass, alles neu anzulegen.
3. An den Menschen geben
An den Menschen geben heißt: die Automatik hält an, der Vorgang landet in einer sichtbaren Warteschlange, und eine benannte Person entscheidet mit dem Kontext, den die Strecke schon gesammelt hat.
Das ist der langsamste Weg und der einzige, der ohne Mitwirkung der Gegenstelle weder doppelt bucht noch den Vorgang verschwinden lässt. In der Prozessautomatisierung ist das der vorgesehene Ausgang für Fälle, die die Automatik nicht abdeckt — kein Notausgang, den man später nachrüstet.
Drei Dinge müssen stehen, sonst ist „an den Menschen geben“ nur ein anderer Name für Liegenlassen:
- Eine Warteschlange, die jemand sieht — nicht ein Logfile, das niemand liest
- Eine zuständige Person, die den Grenzfall entscheiden darf
- Der Kontext: was gesendet wurde, an welches System, mit welcher Referenz, zu welcher Uhrzeit, welche Antwort zuletzt kam
Google nennt in The Evolution of Automation at Google den Maßstab: Wirklich schlechte Systeme halten nicht an und rufen nicht nach Eingriff. Sie laufen weiter. Genau das passiert, wenn der unklare Fall weder wiederholt noch nachgeschaut noch zugestellt wird.
Woran Sie den Weg entscheiden
Die Reihenfolge ist fest. Sie wird nicht im Incident erfunden.
Zuerst: Ist das Ergebnis wirklich unklar? Eine fachliche Ablehnung oder ein dauerhafter Autorisierungsfehler ist kein Fall für Wiederholen. Microsoft sagt das ausdrücklich: Wiederholen ersetzt keine Behandlung von Fehlern in der Geschäftslogik.
Dann: Darf derselbe Schritt zweimal ankommen? Wenn ja — weil die Operation idempotent ist oder die Gegenstelle den Vorgang wiedererkennt —, ist Wiederholen der erste Weg, mit Obergrenze und Abstand. Wenn nein, fällt es als Erstreaktion weg. Die Begründung steht im Idempotenz-Beitrag; hier lautet die Betriebsentscheidung nur: Wiederholen ist dann kein Kandidat.
Dann: Kann die Strecke den Zustand lesen? Schlüssel und zuverlässige Abfrage machen Nachschauen zum zweiten Weg. Fehlt eines von beiden oder ist die Lücke zwischen Prüfung und Schreiben nicht tragbar, fällt auch dieser Weg weg.
Was übrig bleibt, geht an den Menschen. Das ist keine Niederlage. Es ist die Grenze des Teils, der sich vorher aufschreiben ließ.
Wenn zwei Wege noch offen sind:
| Frage | Richtung |
|---|---|
| Was kostet ein Duplikat — Storno, Kundenanruf, Buchungskorrektur? | Hoch: nicht wiederholen. |
| Was kostet Verzug — Frist, Produktion, nächster Lauf? | Hoch: nachschauen vor Mensch, wenn die Abfrage steht. |
| Kann der Mensch den Fall überhaupt entscheiden, oder fehlt ihm die Information? | Fehlt sie: zuerst die Strecke nachrüsten, nicht die Warteschlange füllen. |
Die Tabelle ersetzt keine Architektur. Sie verhindert die häufigste Fehlentscheidung: immer wiederholen, weil die Plattform genau diesen einen Knopf mitbringt.
Wann der Mensch in der Schleife bleiben muss
Nicht jeder Grenzfall wird mit der Zeit automatisch. Manche müssen beim Menschen bleiben, auch wenn die Strecke sonst trägt. Die Grenze liegt in der Art der Entscheidung, nicht im Werkzeug.
Ermessen. Wenn drei sachkundige Personen denselben Vorgang vertretbar unterschiedlich entscheiden, existiert keine Regel, die sich abbilden ließe. Die Strecke kann vorbereiten und protokollieren. Entscheiden muss ein Mensch.
Unumkehrbare Wirkung. Zahlungen, rechtlich bindende Nachrichten, Löschen, Auslösen einer Produktion. Der Preis eines Duplikats liegt über dem Preis einer Warteschlange. Nachschauen kann klären, wenn ein eindeutiger Beleg existiert. Wiederholen darf hier nicht der Default sein.
Begründungspflicht. Wo Sie einem Kunden, einem Prüfer oder einem Gericht erklären müssen, warum so entschieden wurde, brauchen Sie eine nachvollziehbare Regel oder eine nachvollziehbare Person. Ein Modell, das „wahrscheinlich“ richtig liegt, erfüllt das nicht.
Unstrukturierter Rand. Sprachmodelle überführen Text in Struktur — und das Ergebnis ist unscharf. Klassifizierung zur Warteschlange, Extraktion zur Prüfung, Entwurf zur Freigabe tragen. Ein Betrag oder eine Buchung aus einer Vorhersage ohne Prüfschritt trägt nicht. Der Mensch bleibt hier in der Schleife, weil die Ausgabe keine Bestätigung ist.
Fehlende Gegenstelle. Kein Status, kein Schlüssel, keine Wiederholbarkeit: betrieblich nur der dritte Weg. Alles andere ist Raten.
Google nennt Automatisierung einen Kraftverstärker, kein Allheilmittel: Gedankenlos eingesetzt, erzeugt sie so viele Probleme, wie sie löst. Eine Strecke, die Grenzfälle weiterdrückt, verstärkt den Grenzfall.
Zwei Bedingungen, sonst bleibt der Mensch nur auf dem Diagramm:
- Zuständigkeit vor Go-live. Wer entscheidet, steht fest, bevor der erste produktive Lauf startet. Eine Warteschlange ohne Owner ist ein Postfach im Urlaub.
- Der manuelle Weg bleibt offen. Solange die Strecke den unklaren Fall nicht nachweislich trägt, muss derselbe Vorgang von Hand zu Ende zu bringen sein.
Für wen das nicht gilt
Dieser Schnitt ist der falsche, wenn noch keine Strecke existiert. Dann steht zuerst die Reife des Prozesses — beschreibbar, mit klarem Ende, mit Regel vor dem Fall. Das gehört auf die Seite Prozessautomatisierung, nicht in eine Betriebsentscheidung über Timeouts.
Er ist auch der falsche, wenn die Gegenstelle Idempotenz und Status anbietet und der Schritt keine unumkehrbare Wirkung hat. Dann ist Wiederholen mit Schlüssel und Obergrenze der vorgesehene Weg. Einen Menschen in diese Schleife zu ziehen, erzeugt Wartezeit ohne Gegenwert.
Und er gilt nicht für einmalige Migrationen unter Aufsicht. Dort ist der Mensch schon in der Schleife. Eine Warteschlange zu bauen, die dieselbe Person fünf Minuten später selbst leert, ist Theater.
Die Entscheidung gehört in den Entwurf
Eine Strecke ohne diese Überlegung funktioniert im Normalbetrieb. Sie fällt auf, wenn das Netz einmal wackelt — und dann nicht als Fehlermeldung, sondern als doppelter Beleg oder als Vorgang, den niemand mehr findet.
Deshalb wird der unklare Fall geschrieben, bevor gebaut wird: welcher der drei Wege, mit welcher Obergrenze, welchem Schlüssel, welcher Zuständigkeit. In der ersten Strecke heißt das: Protokollierung, definierte Fehlerbehandlung, sichtbarer Weg für das, was die Automatik nicht trägt.
Eine Automatisierung, die im unklaren Fall raten muss, hat den Fehlerfall nicht entworfen, sondern verschoben.
Wie 01PC eine Strecke schneidet und warum die Fehlerbehandlung zur ersten Strecke gehört, steht unter Prozessautomatisierung. Ob Ihre Gegenstellen Wiederholen oder Nachschauen hergeben, ist eine Frage an die Schnittstellen — und oft der Grund, zuerst aufzunehmen und nicht zuerst zu bauen.
Quellen