Eine Prozessinstanz schlägt fehl. Sie versucht es erneut. Auch der Retry schlägt fehl. Drei weitere Instanzen stoßen auf dieselbe defekte Abhängigkeit und starten ebenfalls Retries. Innerhalb von Minuten wächst die Queue schneller, als irgendjemand die Alerts lesen kann, und wer Rufbereitschaft hat, starrt auf Hunderte Fehlermeldungen, die alle gleich aussehen. Das ist ein Exception Storm: kein einzelner Fehler, sondern eine Kaskade, in der die Retry-Logik der Orchestrierungsschicht selbst den Schaden verstärkt, statt ihn einzudämmen.
Der Begriff kommt in keinem formalen BPM-Standard vor. Er beschreibt etwas Praktischeres und Schmerzhafteres: eine operative Häufung von Workflow-Ausnahmen, oft ausgelöst durch eine gemeinsame Abhängigkeit oder fehlerhafte Eingaben, die Retries, Queues und die menschlichen Bearbeiter gleichzeitig überfordert. Das Thema gewinnt an Bedeutung, weil Unternehmen immer mehr KI-gestützte und agentische Workflows in den Produktivbetrieb bringen: Die Zahl der Stellen, an denen solche Kaskaden entstehen können, wächst schneller als die Kontrollen, die sie aufhalten sollen.
Bevor Sie Exception Storms eindämmen können, müssen Sie Ausnahmen richtig zählen. Die meisten Teams tun das nicht. Der häufige Fehler: Sie erfassen rohe Fehlerereignisse statt eindeutiger Prozessinstanzen. Eine hängende Instanz, die 200 Retries erzeugt, sieht im Dashboard aus wie 200 Probleme. Es ist ein einziges Problem, verstärkt durch schlechte Retry-Logik. Diese Unterscheidung verändert alles: wie Sie Alerts auslösen, wie Sie Ihr Team besetzen und wie Sie in Fehlerbehebungen investieren.
Ein belastbarer Ansatz beginnt mit der Ausnahmequote: Instanzen mit mindestens einer Ausnahme geteilt durch alle Instanzen. Dazu kommen der Anteil der Fälle, die ein Retry behebt, die Lösungszeit je Ausnahmetyp und die Quote wiederkehrender Fehler. Um einen Exception Storm zu erkennen, zählen vor allem die Eingangsrate, das Wachstum der Queues, das Retry-Volumen und der Schadensradius (Blast Radius) über abhängige Workflows hinweg. Alerts auf einzelne Fehler erzeugen Rauschen. Alerts auf veränderte Raten und wachsende Queues liefern handlungsrelevante Signale.
Eine von AInformat veröffentlichte Analyse zum Exception-Management nennt eine ungefähre Aufteilung von 80/20 zwischen Happy Path und Ausnahmefällen; auf Datenausnahmen entfallen dabei rund 40 bis 50 Prozent der Gesamtmenge. Diesen Zahlen fehlen ausreichende Angaben aus Primärquellen, um sie als allgemeine Benchmarks zu verwenden, aber das Muster ist aufschlussreich: Ausnahmen sind keine Randfälle. Sie machen einen erheblichen Teil der Realität im Produktivbetrieb aus, und allein der Anteil, der auf Probleme der Datenqualität zurückgeht, kann die Bedingungen für einen Exception Storm schaffen, wenn Retries nicht begrenzt sind.
Genau hier liegen die meisten Konzepte für die Ausnahmebehandlung falsch. Sie behandeln jeden Fehler gleich: erneut versuchen, eskalieren oder in eine Sammel-Queue werfen. Ein fehlendes Freigabedokument und ein Timeout eines nachgelagerten Service sind aber grundlegend verschiedene Probleme, die grundlegend verschiedene Antworten brauchen.
Fachliche Ausnahmen (fehlende Informationen, überschrittene Freigabegrenzen, mehrdeutige Daten) brauchen Routing und menschliche Entscheidungen. Technische Fehler (Timeouts, Authentifizierungsfehler, nicht erreichbare Services) brauchen begrenzte Retries mit Backoff und Jitter, Circuit Breaker und Quarantäne-Queues. Wer beides vermischt, bekommt das Schlechteste aus beiden Welten: sinnlose Retries bei Fällen, die sich nie von selbst lösen, und unnötige Eskalationen an Menschen wegen kurzer Netzwerkaussetzer, die sich in Sekunden erledigt hätten.
Die Aufgabe der Control Plane ist die Trennung. Modellieren Sie fachliche Ausnahmen als alternative Pfade in der Prozessdefinition, nicht als Error Handler. Modellieren Sie vorübergehende technische Fehler mit begrenzten Retry-Policies, Idempotenzprüfungen und Duplikatunterdrückung. Modellieren Sie unerwartete oder nicht behebbare Fehler als Zustände nach dem Prinzip „anhalten und untersuchen“: Die Instanz stoppt, ein Incident wird angelegt, mit dem sich arbeiten lässt, und jemand, der den Kontext kennt, sieht ihn sich an. Drei Kategorien, drei Behandlungsstrategien. Aus ihrer Vermischung entstehen Exception Storms.
Kein Teil wird so oft zu oberflächlich entworfen wie dieser. Teams fügen einen Schritt „Mensch benachrichtigen“ hinzu und nennen das Human-in-the-Loop. Das ist es nicht. Eine Slack-Nachricht oder ein E-Mail-Alert ist eine Benachrichtigung. Ein persistenter Workflow-Zustand, der Neustarts übersteht, Belege an eine vorgeschlagene Aktion bindet, Identität und Befugnis der entscheidenden Person festhält, eine Frist durchsetzt und die Vorbedingungen erneut prüft, bevor die freigegebene Aktion ausgeführt wird: Das ist HITL.
Der Unterschied ist betrieblich und rechtlich relevant. Bleibt der Workflow nicht persistent, während er auf eine menschliche Eingabe wartet, kann ein Deployment oder Neustart die offene Freigabe ganz verlieren oder, schlimmer noch, die Aktion doppelt auslösen. Ist die Freigabe nicht an eine bestimmte vorgeschlagene Aktion gebunden, genehmigt der Mensch ein Konzept, keinen konkreten Schritt. Gibt es keine Frist, stauen sich veraltete Freigaben und werden irgendwann unter Bedingungen ausgeführt, die nicht mehr gelten. Das Tutorial zu persistenten Human-in-the-Loop-Mustern von Temporal zeigt die erste Hälfte davon: Der Workflow wartet auf den Menschen, ohne seinen Zustand zu verlieren, und sobald die Entscheidung gefallen ist, wird sie dauerhaft gespeichert. Die zweite Hälfte ist eine eigene Designregel: Ändert sich der zugrunde liegende Kontext, während der Mensch noch entscheidet, sollte die Freigabe ungültig werden, und die Vorbedingungen sollten erneut geprüft werden.
Die Dokumentation zum Agent Framework von Microsoft enthält explizite HITL-Konstrukte für agentische Workflows. Elastic hat einen Leitfaden zur Automatisierung der Incident Response mit menschlichen Freigabeschritten (Approval Gates) veröffentlicht, der die Bindung an Belege, Zeitlimits und Auditierbarkeit betont. Plattformübergreifend zeichnet sich dasselbe Muster ab: HITL ist ein bewusst entworfener Workflow-Zustand mit Struktur, keine informelle Eskalation auf gut Glück.
Alerts sagen Ihnen, dass ein Exception Storm läuft. Architektur verhindert ihn. Die Muster zur Eindämmung sind gut verstanden, werden aber uneinheitlich angewendet: begrenzte Retries mit exponentiellem Backoff und Jitter (damit sich Retries nicht synchronisieren und einen Service, der sich gerade erholt, mit Anfragen überrollen), Idempotenz und Duplikatunterdrückung (damit wiederholte Versuche keine doppelten Geschäftsergebnisse erzeugen), Begrenzung der Parallelität und Backpressure (damit die Orchestrierungsschicht keine neue Arbeit mehr annimmt, wenn sie die vorhandene nicht verarbeiten kann), Circuit Breaker zur Isolation von Abhängigkeiten (damit ein ausfallender Service nicht jeden Workflow mitreißt, der ihn nutzt) und Dead Letter Queues oder Quarantäne-Queues (damit Poison Messages isoliert werden, statt gesunden Traffic zu blockieren).
Keine dieser Ideen ist neu. Neu ist die Dringlichkeit. Weil KI-gestützte Workflows mehr Entscheidungspunkte, mehr Aufrufe externer Services und variablere Ausführungspfade mit sich bringen, vervielfacht sich die Zahl der Stellen, an denen ein Exception Storm entstehen kann. Ein LLM-Aufruf, der sporadisch in einen Timeout läuft, ein Modell, dessen Konfidenzwerte driften, eine Routing-Regel für Freigaben, die alles in dieselbe überlastete Queue schickt: Jedes davon ist die Saat für einen Exception Storm.
Die unbequeme Wahrheit: Nicht jede Häufung von Ausnahmen ist ein Problem der Orchestrierung. Manchmal liegt die eigentliche Ursache in der Datenqualität vorgelagerter Systeme. Manchmal ist es eine gemeinsame Abhängigkeit, an deren Zuverlässigkeit eigens gearbeitet werden muss. Das Design der Control Plane begrenzt den Schadensradius, aber es beseitigt nicht die Quelle. Teams, die zu viel in die Ausnahmebehandlung investieren, ohne die vorgelagerte Ursache anzugehen, haben am Ende sehr ausgefeilte Wege, Fehler zu verwalten, die es gar nicht geben dürfte.
Eine Control Plane (Steuerungsebene) im Sinne der Netzwerktechnik transportiert keinen Traffic. Sie entscheidet, wohin der Traffic geht. BPM verdient diese Bezeichnung, wenn es aufhört, bloß eine Engine zur Ausführung von Workflows zu sein, und zur Schicht wird, die fachliche Entscheidungen von technischer Wiederherstellung trennt, Ausnahmen nach Typ und Schwere an die richtige Stelle leitet (Mensch oder Automatisierung), Eindämmungsregeln durchsetzt, bevor Kaskaden entstehen, und so viel Audit-Kontext bewahrt, dass sich jede Entscheidung, ob automatisiert oder menschlich, im Nachhinein rekonstruieren lässt.
Die praktische Checkliste ist kürzer, als die Architekturdiskussion vermuten lässt. Trennen Sie im Prozessmodell fachliche Ausnahmen von technischen Fehlern. Begrenzen Sie jeden Retry durch Backoff, Jitter und eine Höchstzahl an Versuchen. Machen Sie menschliche Freigaben persistent, binden Sie sie an Belege, versehen Sie sie mit einer verbindlichen Frist und prüfen Sie sie vor der Ausführung erneut. Setzen Sie Alerts auf Raten und wachsende Queues, nicht auf einzelne Fehler. Und messen Sie pro eindeutiger Prozessinstanz, nicht nach der Zahl roher Ereignisse.
Ich komme immer wieder auf eine einfache Regel zurück: Bevor Sie Intelligenz feiern, entwerfen Sie Kontrolle. Wenn ein Modell Fälle weiterleiten kann, kann es sie auch falsch weiterleiten. Wenn ein Retry einen Fehler auffangen kann, kann er ihn auch verstärken. Die Demo ist nicht das System. Das System ist das, was passiert, wenn an einem Dienstag um 14:07 Uhr die dritte Abhängigkeit ausfällt und sich in der Queue bereits die Nachrichten stauen. Dort funktioniert die Control Plane oder eben nicht, und dort trennt nur eine einzige fehlende Verzweigung in einem Flussdiagramm eine behandelte Ausnahme von einem Exception Storm.
