Verlorene Daten einer Automatisierung wiederherstellen: wie du nacharbeitest, was ausgefallen ist, ohne etwas doppelt anzulegen

Was genau verloren geht, wenn eine Automatisierung ausfällt – und warum „nichts“ die falsche Antwort ist

Die erste Frage nach einem Ausfall lautet fast immer „Läuft es wieder?“. Die zweite – die kaum jemand stellt – lautet: Was ist mit dem passiert, was hereinkam, während nichts lief? Die Antwort hängt an einer Entscheidung, die am Tag des Aufbaus getroffen wurde: ob das, was hereinkommt, eine abfragbare Quelle hat oder nur als flüchtiges Ereignis existierte.

Die beiden Fälle verhalten sich genau entgegengesetzt. Liest dein Flow aus etwas, das speichert – die Bestellungen im Shop, die Tickets im CRM, die Mails in einem Postfach –, hast du nichts verloren: Die Daten liegen weiter da und warten darauf, dass sie jemand verarbeitet. Hängt dein Flow davon ab, dass dir jemand die Daten zuschiebt – ein Webhook, eine Benachrichtigung – und der Absender wiederholt nicht und hält keine Historie, dann hat sich dieses Ereignis in Luft aufgelöst. Kein Eintrag, kein Fehler, kein Bildschirm, auf dem du danach suchen könntest.

• Abfragbares holst du zurück. Bestellungen, Datensätze, Dokumente: Alles, was in der Quelle bestehen bleibt, lässt sich nach Zeitraum erneut abrufen und neu verarbeiten.
• Zugeschobenes hängt am Absender. Stripe, GitHub oder Shopify wiederholen ihre Webhooks über Stunden oder Tage; ein internes Skript oder eine selbstgebaute Integration so gut wie nie. Bevor du dich auf einen Webhook verlässt, prüf, ob sein Absender wiederholt – und wie lange.
• Halb Verarbeitetes ist der schlimmste Fall. Ein Flow, der den Datensatz angelegt hat, aber ausfiel, bevor er ihn als versendet markieren konnte, lässt das System in einem Zustand zurück, der weder erledigt noch offen ist. Genau der produziert beim erneuten Verarbeiten Dubletten.
• Still falsch Verarbeitetes ist kein Verlust, sondern eine Korruption. Dieser Plan repariert das nicht; entdeckt wird es von der Überwachung, um die es in Fehler in KI-Automatisierungen erkennen geht.

Diese Unterscheidung ist nicht akademisch: Sie entscheidet, was du versprechen kannst. Wenn jemand fragt „Ist etwas verloren gegangen?“, ist die ehrliche Antwort: von dem, was über den Shop kommt, nichts; von dem, was über den Webhook von Anbieter X kommt, hängt es davon ab, ob er wiederholt. Und wenn du das nie geprüft hast, ist genau das die erste Aufgabe – vor jedem Neuverarbeiten.

Idempotenz zuerst: die Reparatur, die Rechnungen verdoppelt

Am Tag des Ausfalls gibt es eine sehr starke Versuchung: den Stapel aus den schlechten Stunden nehmen und komplett noch einmal durchlaufen lassen. Das geht schnell, fühlt sich tatkräftig an und ist der übliche Weg, aus einem kleinen Vorfall einen teuren zu machen. Denn ein Teil dieses Stapels wurde sehr wohl verarbeitet – die ersten Minuten, alles, was in die Lücken fiel, in denen der Dienst noch antwortete – und dieser Teil läuft jetzt ein zweites Mal.

Das Bauteil, das das verhindert, heißt Idempotenz und bedeutet genau das: Dieselbe Operation zweimal auszuführen hinterlässt dasselbe Ergebnis wie einmal. Das ist kein Schalter, den man umlegt, sondern eine Eigenschaft, die man entwirft – und sie steht auf zwei konkreten Entscheidungen.

• Ein stabiler Schlüssel pro Arbeitseinheit. Die Bestellnummer, die ID der Nachricht, der Hash des Dokuments. Nie der Zeitstempel, nie ein Zähler des Laufs, nie „der neueste Datensatz“: Das ändert sich zwischen zwei Versuchen und zerlegt den Vergleich.
• Ein Schreibschritt, der prüft, bevor er anlegt. Nach diesem Schlüssel suchen und, wenn es ihn gibt, aktualisieren oder ohne Aktion aussteigen. Viele APIs liefern das fertig mit – über einen Header für den Idempotenzschlüssel oder ein natives „anlegen oder aktualisieren“; wo es das nicht gibt, baust du es von Hand mit einer eigenen Tabelle bereits verarbeiteter Schlüssel.

Praxisregel, die Diskussionen erspart: Ist ein Flow nicht idempotent, hat er keinen Wiederherstellungsplan, sondern einen Risikoplan. Und die Reihenfolge zählt – ihn idempotent zu machen kommt vor jedem Neuverarbeiten, auch wenn der Chef auf die Uhr schaut. Einen nicht idempotenten Flow neu laufen zu lassen, um zwanzig Minuten zu sparen und vierzig doppelte Rechnungen zu erzeugen, ist ein schlechtes Geschäft – das du danach auch noch erklären musst.

Wiederholungen mit wachsender Wartezeit: was wiederholt wird und was nie

Die meisten Fehler braucht niemand zu reparieren: Sie lösen sich von selbst, wenn das System kurz wartet und es noch einmal versucht. Ein abgelaufenes Zeitlimit, ein Anfragelimit, ein 503 von einem Anbieter, der gerade ausrollt. Bedingung ist, dass die Wiederholung sauber gebaut ist – und „sauber“ hat eine konkrete Form.

Wachsende Wartezeit: nicht jede Sekunde wiederholen, sondern die Versuche immer weiter auseinanderziehen – ein paar Sekunden, dann das Doppelte, dann noch einmal das Doppelte –, mit einem kleinen zufälligen Versatz, damit tausend Läufe, die gleichzeitig gescheitert sind, nicht auch gleichzeitig zurückkommen. In einer Endlosschleife gegen einen liegenden Anbieter zu hämmern hilft ihm nicht beim Aufstehen: Es hält ihn unten und verbrennt nebenbei dein Kontingent.

Und eine Unterscheidung, die nützliche von schädlichen Wiederholungen trennt: Wiederholt wird, was an der Umgebung gescheitert ist, nicht was an den Daten gescheitert ist. Ein 500 oder ein abgelaufenes Zeitlimit sind legitime Kandidaten. Ein 400, weil ein Pflichtfeld fehlt, ein 401 wegen abgelaufener Zugangsdaten oder ein 422, weil der Betrag negativ ist, werden durch Wiederholen nicht besser: Das geht direkt in die Fehlerwarteschlange, weil jeder weitere Versuch nur Lärm und Kosten ist. Ein Flow, der einen Validierungsfehler fünfmal wiederholt, zahlt fünfmal und lernt null.

Wie viele Versuche: Drei bis fünf decken praktisch alles Vorübergehende ab. Danach ist die Ursache kein Schluckauf der Umgebung mehr, und weiter zu insistieren verzögert nur den Moment, in dem ein Mensch davon erfährt. Genau dieser Moment – der Übergang vom Wiederholen zum Aufgeben – gibt dem nächsten Baustein seinen Sinn.

Die Fehlerwarteschlange: wohin geht, was nicht durchkam, und wie es neu gestartet wird

Wenn die Wiederholungen aufgebraucht sind, muss die Arbeit irgendwo landen. Gibt es diesen Ort nicht, landet sie im Log – also nirgends. Die Fehlerwarteschlange ist dieser Ort: eine Tabelle, ein Sheet, ein Kanal, egal was, solange sie zu jedem Fehler drei Dinge festhält.

• Die Originaldaten vollständig, keine Zusammenfassung und keine Fehlermeldung. Ohne die komplette Nutzlast kannst du nicht neu starten – nur nachforschen.
• Den Grund des Fehlers und den Zeitpunkt, damit du gruppieren kannst. Zweihundert Fehler mit demselben Grund sind ein Problem; zweihundert mit verschiedenen Gründen sind zweihundert Probleme.
• Den Status: offen, neu gestartet, gelöst oder mit Begründung verworfen. Ohne Status wird die Warteschlange zu einem Friedhof, den sich niemand zu leeren traut.

Was sich mit ihr ändert, ist das Gespräch. Aus „gestern ist etwas verloren gegangen“ wird „214 liegen in der Warteschlange: 190 sind am ausgefallenen Anbieter gescheitert und laufen unverändert neu, 24 sind an der Validierung gescheitert und brauchen einen Blick“. Das ist ein Vorfall, den man managen kann. Und sie liefert ein Gesundheitssignal, das keine Alarmmeldung so gut hinbekommt: Eine wachsende Warteschlange meldet ein systemisches Problem, bevor ein Kunde es tut.

Der Neustart läuft in kleinen Chargen und in Reihenfolge, nie alles auf einmal. Erst eine Handvoll, dann das Ergebnis am Ziel prüfen, und erst dann der Rest. Scheitert die erste Charge genauso, war die Ursache nicht behoben – und du hast dir gerade erspart, denselben Fehler zweihundertmal zu wiederholen. Das alles setzt den vorigen Abschnitt voraus: Ohne Idempotenz ist der Neustart einer Warteschlange ein Glücksspiel.

Abgleich: wie du findest, was nie hereinkam

Wiederholungen und Warteschlange decken ab, was gescheitert ist. Bleibt das eigentliche Loch: was nie versucht wurde. Der verlorene Webhook, der deaktivierte Auslöser, der Datensatz, den der Filter wegen eines leeren Feldes aussortiert hat. Da gibt es keinen Fehler, keinen Eintrag in der Warteschlange und nichts zu wiederholen. Es gibt nicht einmal eine Spur davon, dass überhaupt etwas hätte passieren sollen.

Der einzige Weg, das zu finden, ist aufzuhören, auf die Automatisierung zu schauen, und stattdessen die beiden Enden zu vergleichen. Genau das ist Abgleichen: die Quelle nach allem fragen, was sich in einem Zeitfenster geändert hat, das Ziel nach allem, was in demselben Fenster angelegt wurde, über den stabilen Schlüssel gegenüberstellen und die Differenz behalten. Was in der Quelle steht und im Ziel fehlt, ist exakt das, was verloren ging.

Drei Details entscheiden, ob der Abgleich taugt oder Fehlalarme produziert: nimm denselben stabilen Schlüssel wie bei der Idempotenz (vergleichst du über Kundenname oder Betrag, findest du Differenzen, die es nicht gibt); lass an den Rändern des Fensters ein paar Minuten Puffer, weil Quelle und Ziel nicht im selben Moment schreiben; und entscheide, was mit der Differenz passiert: Vernünftig ist, sie in die Fehlerwarteschlange zu schicken und über den normalen Weg neu zu starten – nicht, sie direkt über einen Seitenkanal zu schreiben, der die Validierungen des Flows überspringt.

Der Takt hängt am Schaden, nicht am Volumen. Täglich und automatisch bei allem, was Geld oder Zusagen an Kunden bewegt; wöchentlich bei Internem mit geringer Wirkung. Und vor allem dauerhaft, nicht nur nach einem Schreck: Der Abgleich lohnt sich genau deshalb, weil er die Bestellung findet, die an einem beliebigen Dienstag verloren ging, ohne dass irgendetwas ausgefallen wäre – die, von der du heute erfährst, wenn der Kunde nachfragt. Es ist dieselbe Disziplin der laufenden Pflege, die auch die Wartung von KI-Automatisierungen trägt.

Der Wiederherstellungsplan: wer ihn ausführt, in welcher Reihenfolge und mit welcher Endkontrolle

Die vier Bausteine davor sind Fähigkeiten. Zur Wiederherstellung werden sie erst durch einen kurzen, vorab geschriebenen Plan, den am schlechten Tag jemand ausführen kann, ohne zu improvisieren und ohne darauf angewiesen zu sein, dass die Person greifbar ist, die den Flow gebaut hat. Er passt auf eine halbe Seite und hat sechs Schritte.

• 1. Den Zulauf stoppen. Vor dem Wiederherstellen den Hahn zudrehen: Schluckt der Flow weiter, während du neu verarbeitest, weißt du nie, welcher Stapel welcher ist.
• 2. Das Fenster festlegen. Von wann bis wann es kaputt war. Mit Puffer auf beiden Seiten; zu viel ist besser als zu wenig.
• 3. Die Idempotenz des Flows bestätigen. Fehlt sie, wird sie hier hergestellt. Dieser Schritt wird nicht aus Eile übersprungen.
• 4. Das Fenster abgleichen. Quelle und Ziel vergleichen und die Differenz in die Fehlerwarteschlange schicken.
• 5. In kleinen Chargen neu starten, nach der ersten das Ziel prüfen, bevor der Rest folgt.
• 6. Mit einer Ergebniskontrolle abschließen, nicht mit einer Ausführungskontrolle: Datensätze im Ziel zählen und gegen die Quelle abstimmen. Dass der Neulauf „ohne Fehler beendet“ wurde, beweist gar nichts.

Und eine Sache, die nicht technisch ist, aber das Ergebnis entscheidet: Der Plan braucht einen Verantwortlichen mit Vor- und Nachnamen, keine Abteilung. Dieselbe Regel, die alles andere in Governance und Kontrolle der Automatisierung regiert: ohne Namen keine Kontrolle, nur ein Dokument. Willst du das Ganze von null aufbauen, liegt die komplette Karte im Leitfaden zum Automatisieren mit KI.

Der unbequeme Schluss: Wiederherstellung improvisiert man nicht, man installiert sie. Wiederholungen, Idempotenz, Warteschlange und Abgleich baut man, während alles gut läuft – denn an dem Tag, an dem man sie braucht, ist keine Zeit mehr dafür. Wenn deine kritischen Flows sie heute nicht haben, ist genau das, was wir tun, wenn wir einen Prozess bei der Automatisierung von Abläufen in Produktion übergeben: nicht nur, dass er läuft, sondern dass er sich erholen kann, wenn er nicht läuft.