Zwei Arten von Ausfall: der, der dich warnt, und der, der dich glauben lässt, alles sei gut
Wenn jemand fragt, wie man erkennt, dass eine Automatisierung fehlgeschlagen ist, denkt er fast immer an den lauten Ausfall: Der Flow bleibt stehen, das Tool schickt eine Mail, jemand repariert es. Das ist der gute Ausfall. Er ist sichtbar, begrenzt, und seine Kosten sind proportional zu der Zeit, die jemand braucht, um aufs Handy zu schauen.
Das Problem ist der andere. Der stille Ausfall bleibt nicht stehen: er endet. Er markiert den Lauf grün, bricht nichts und läuft morgen genauso schlecht weiter. Und kein Alarm schrillt, weil es technisch nichts zu melden gibt: jeder Schritt hat getan, was er sollte, und ist ohne Fehler zurückgekommen. Das Tool sagt dir die Wahrheit —«alle Schritte wurden ausgeführt»— und du liest etwas anderes —«die Arbeit wurde erledigt». Das ist nicht dasselbe.
Der Unterschied zählt, weil die Kosten nicht vergleichbar sind. Der laute Ausfall kostet Stunden. Der stille kostet Wochen, und wenn er entdeckt wird, musst du rückwärts rekonstruieren: welche Bestellungen nicht ankamen, welche Kunden keine Antwort bekamen, welche Rechnungen nicht erfasst wurden. Dieser Guide hängt an dem zur Wartung der KI-Automatisierungen, der erklärt, warum sie kaputtgehen. Hier geht es um das andere: wie du es merkst.
Die vier Gesichter des stillen Ausfalls
In Produktion wiederholen sich vier, und keine löst einen Fehler aus. Sie zu erkennen ist die halbe Arbeit.
1. Der leere Erfolg
Der Aufruf liefert eine 200 zurück, und der Body ist leer, oder enthält eine Liste mit null Elementen. Für den Flow ist das ein perfekter Erfolg: er hat Daten angefragt, eine Antwort bekommen, weitergemacht. Die Schleife danach hat sich kein einziges Mal gedreht, also hat sie nichts erzeugt, also ist nichts fehlgeschlagen. Es ist das Muster Nummer eins und das am schwersten zu erkennende, weil es im Dashboard genauso aussieht wie ein guter Tag.
2. Der Filter, der alles frisst
Jemand hat im CRM einen Feldnamen geändert, oder das Format eines Datums, und die Bedingung, die früher Datensätze durchließ, erfüllt jetzt keiner mehr. Der Flow läuft, filtert, und aus dem Filter kommt nichts. Korrekte Ausführung, null erledigte Arbeit. Der Unterschied zum vorherigen Fall steckt in einem Detail: hier kamen Daten rein, nur hat keiner das Tor passiert.
3. Die unbrauchbare Antwort, die niemand prüft
Das ist der typische Ausfall beim Automatisieren mit KI. Du bittest das Modell um eine Kategorie oder ein JSON, und es liefert eine Entschuldigung, einen Text, der erklärt, warum es nicht kann, oder das JSON eingewickelt in drei höfliche Sätze. Der nächste Schritt akzeptiert das, weil es eine Zeichenkette ist und er eine Zeichenkette erwartet hat. Ab da arbeitet der ganze Flow ganz normal mit Müll weiter. Man deckt das mit einer Formatprüfung ab, bevor es weitergeht: erfüllt die Antwort das erwartete Format nicht, stoppt der Flow und eskaliert. Der Guide zum Menschen im Loop beschreibt, wo dieses Netz je nach Fehlerkosten hingehört.
4. Der Flow, der aufgehört hat zu laufen
Der dümmste und der häufigste. Niemand hat ihn kaputtgemacht: er wurde beim Planwechsel deaktiviert, eine OAuth-Credential ist abgelaufen, jemand hat ihn an einem Donnerstag zum Testen pausiert und nie wieder aktiviert. Keine Ausführung, also kein Fehler, also nichts zu alarmieren. Den erkennst du nicht, indem du anschaust, was passiert. Du erkennst ihn, indem dir auffällt, was nicht passiert.
Was du alarmierst und was du schweigen lässt: Ein Alarm, der immer schrillt, wird von niemandem gehört
Der Fehler, der dem Fehlen von Alarmen entgegengesetzt ist, ist, alle zu haben. Ein Kanal, der vierzig Meldungen am Tag bekommt, hört spätestens in der zweiten Woche auf, ein Alarmkanal zu sein: er wird stummgeschaltet, archiviert oder ignoriert, und an dem Tag, an dem die wichtige Meldung kommt, steckt sie zwischen neununddreißig anderen. Alarmmüdigkeit ist kein Problem der Leute; es ist ein Designproblem.
Die Regel, die in Produktion hält, passt in eine Zeile: Alarmiere nur, was jemanden dazu bringt, seine Arbeit stehen zu lassen. Alles andere verschwindet nicht, es landet auf einem Dashboard, das einmal am Tag mit dem Kaffee angeschaut wird.
- Alarm an eine Person: der kritische Flow ist wirklich fehlgeschlagen; der kritische Flow läuft länger als normal nicht mehr; die Exception-Queue wächst zwei Tage in Folge; die Tagesausgaben sprengen ihren Rahmen.
- Aufs Tages-Dashboard: vereinzelte Fehler, die beim Retry gelöst wurden, Fälle, die an die menschliche Prüfung eskaliert wurden, Ausführungen, die langsamer als üblich liefen, Warnungen zum Plan-Limit, die noch nicht drücken.
- Weder das eine noch das andere: alles, was sich nie jemand anschauen wird. Wenn eine Meldung keinen Owner und keine mögliche Aktion hat, ist sie kein Alarm: sie ist ein Log-Eintrag. Lass sie in den Logs.
Fang klein an. Zwei Alarme pro kritischem Flow —er ist fehlgeschlagen, und er hat aufgehört zu laufen— und du ergänzt einen dritten erst, wenn ein echter Vorfall zeigt, dass er gefehlt hat. Alarme verdienen sich ihren Platz; sie werden nicht vorsorglich verteilt.
Der Herzschlag: den Flow erkennen, der aufgehört hat zu laufen
Das ist das Teil, das fast niemand hat und das am häufigsten rettet. Ein Herzschlag ist ein Alarm, der auslöst, wenn NICHTS passiert. Der Flow sendet bei jedem erfolgreichen Abschluss ein Signal; ein externer Dienst wartet darauf; kommt es nicht innerhalb des erwarteten Fensters an, schlägt er Alarm.
Zwei Details entscheiden, ob es funktioniert. Erstens: Der Herzschlag muss außerhalb des Tools leben, das du überwachst. Sind Wächter und Bewachter dasselbe System, meldet sich an dem Tag, an dem das System abstürzt, niemand —und genau das ist der Tag, an dem du es brauchst. Zweitens: das Zeitfenster wird nach dem echten Rhythmus des Flows kalibriert, nicht nach dem idealen. Ein Flow, der alle fünfzehn Minuten läuft, kann sich eine Stunde Spielraum leisten; einer, der täglich läuft, sollte nicht Alarm schlagen, weil er zwanzig Minuten zu spät kommt. Falsch gesetzte Fenster erzeugen Fehlalarme, und Fehlalarme erzeugen stummgeschaltete Alarme.
Abschlussprüfung: Der letzte Schritt soll belegen, dass die Arbeit angekommen ist
Der Herzschlag sagt dir, dass der Flow gelaufen ist. Er sagt dir nicht, dass er etwas Sinnvolles getan hat. Dafür gibt es die Abschlussprüfung: der letzte Schritt jedes kritischen Flows ist nicht die Aktion, sondern die Kontrolle der Aktion.
- Zähl, was reinkam und was rauskam. Wenn vierzehn Datensätze reinkamen und null erstellt wurden, ist das kein ruhiger Tag: das ist ein Ausfall. Ein Flow, der mehrere Tage in Folge null Elemente verarbeitet, verdient einen Blick, kein Häkchen.
- Prüf im Ziel, nicht in der Antwort. Dass die API Ja gesagt hat, beweist nicht, dass der Datensatz existiert. Ein Rücklesen —das Zielsystem nach dem Datensatz fragen, den du gerade erstellt hast— macht aus einer Annahme eine Tatsache.
- Gleich regelmäßig ab. Einmal am Tag Ursprung und Ziel vergleichen und schauen, was fehlt. Das ist das Einzige, was das Ereignis erkennt, das nie ankam, denn ein verlorener Webhook erzeugt keinen Fehler: er erzeugt eine Abwesenheit.
- Hinterlass die Spur. Jede Ausführung mit ihrer ID, was reinkam, was rauskam und unter welcher Version. Ohne das kannst du einen konkreten Fall nicht rekonstruieren, wenn drei Wochen später jemand danach fragt; hier greift die Governance und Kontrolle der KI-Automatisierung.
Wenn er auslöst: Schweregrad, Owner und die Dreier-Regel
Ein Alarm ohne Empfänger ist eine Benachrichtigung. Bevor du irgendetwas einschaltest, schreib drei Dinge pro kritischem Flow auf: wer reagiert (eine Person, keine Abteilung), was währenddessen passiert, während repariert wird (der manuelle Plan: von Hand weiter zu fakturieren ist kein Scheitern, das ist der Plan), und was rechtfertigt, jemanden außerhalb der Arbeitszeit anzurufen. Fast nichts rechtfertigt das; das entscheidet man besser mit kühlem Kopf, nicht um 23:40 Uhr.
Und eine Regel, die viele künftige Vorfälle spart: Schlägt derselbe Fehler dreimal zu, hört man auf, ihn zu reparieren, und redesignt ihn. Ein Fehler, der sich wiederholt, ist kein Pech, sondern eine falsche Annahme im Design des Flows —ein Fall, der nicht bedacht wurde, eine API, die nicht so zuverlässig ist wie gedacht, ein Format, das öfter wechselt, als man angenommen hat. Beim dritten Mal zu flicken garantiert nur, dass es ein viertes Mal geben wird.
Nichts davon ist teuer. Ein externer Herzschlag, eine Abschlussprüfung und zwei gut gewählte Alarme sind an einem Nachmittag pro Flow aufgesetzt, und sie sind der Unterschied zwischen selbst merken und von einem Kunden erfahren. Was wirklich kostet, ist, das über zwanzig lebende Flows durchzuhalten, ohne dass es jemandes Job ist, sie zu beobachten: das ist dann kein Automatisierungen-Bauen mehr, das ist Betrieb —und genau das machen wir bei Operations-Automatisierung. Wenn du noch entscheidest, was und womit du automatisierst, geh zurück zum Pillar zum Automatisieren mit KI; hast du es schon aufgesetzt, fang bei dem Flow an, der im Stillen den größten Schaden anrichten würde.