Fehlerpfad vor dem Happy Path planen

Vom unerwünschten Ergebnis rückwärts denken

Der Entwurf beginnt mit Folgen, die nicht eintreten sollen: doppelte Buchung, verlorener Auftrag, falscher Empfänger oder unbemerkter Stillstand. Für jedes Ergebnis fragt das Team rückwärts, welcher technische oder organisatorische Auslöser dazu führen könnte. Erst danach wird der Normalablauf verfeinert. Diese Reihenfolge macht sichtbar, welche Zustände ausdrücklich behandelt werden müssen. Eine Fehlerliste ist dabei kein Anspruch auf Vollständigkeit. Sie wird mit Erfahrungen aus dem bestehenden Prozess, bekannten Abhängigkeiten und Beobachtungen aus Tests ergänzt und bei jeder wesentlichen Änderung erneut geöffnet.

Einordnung: Redaktioneller Arbeitsschritt; keine gesetzliche oder technische Vorgabe.

Fehlerklassen mit eindeutigen Reaktionen verbinden

Nicht jede Abweichung darf denselben Wiederholungsmechanismus auslösen. Ein kurzzeitig nicht erreichbarer Dienst, ein ungültiges Datenformat und eine fachlich abgelehnte Eingabe brauchen unterschiedliche Reaktionen. Das Team definiert pro Klasse: Erkennungssignal, zulässige Wiederholungen, Wartezeit, sicheren Zustand und zuständige Rolle. Unbekannte Fehler erhalten einen konservativen Sammelpfad, der den Vorgang stoppt und sichtbar macht. Freitextmeldungen allein reichen nicht; zusätzlich braucht es eine stabile Kennung, mit der ähnliche Ereignisse gruppiert werden können. So bleibt die Behandlung auch bei wechselnden Formulierungen auswertbar.

Einordnung: Redaktioneller Arbeitsschritt; keine gesetzliche oder technische Vorgabe.

Risikoanalyse als Rahmen, nicht als fertige Fehlerliste

Der BSI-Standard 200-3 beschreibt eine Methodik zur Risikoanalyse auf Basis von IT-Grundschutz. Er bestimmt nicht, welche Fehlercodes eine einzelne Automatisierung besitzen muss. Für das eigene Szenario werden Gefährdungen, Auswirkungen und vorhandene Schutzmaßnahmen nachvollziehbar zusammengeführt. Das BSI-Kompendium kann dazu Bausteine und Anforderungen als Referenz liefern. Die konkrete Übertragung bleibt eine organisatorische Aufgabe: Ein Team dokumentiert, welche Teile passen, welche nicht einschlägig sind und wo zusätzliche Maßnahmen wegen der eigenen Architektur erforderlich erscheinen.

Beleggrundlage: BSI-Standard 200-3: Risikoanalyse auf der Basis von IT-Grundschutz · IT-Grundschutz-Kompendium

Teilzustände und Wiederholungsschutz festlegen

Viele kritische Fehler entstehen, wenn ein mehrstufiger Vorgang nur teilweise abgeschlossen wurde. Deshalb wird nach jedem extern wirksamen Schritt ein unterscheidbarer Zustand benötigt. Vor einer Wiederholung prüft das System, ob die beabsichtigte Wirkung bereits eingetreten ist. Eine eindeutige Vorgangskennung kann helfen, ersetzt aber nicht die Prüfung beim empfangenden System. Wo Rückabwicklung möglich ist, werden Reihenfolge und Grenzen beschrieben. Wo sie nicht möglich ist, stoppt der Ablauf vor einer erneuten Wirkung und verlangt eine qualifizierte Entscheidung. Der manuelle Weg darf denselben Vorgang nicht versehentlich parallel fortsetzen.

Einordnung: Redaktioneller Arbeitsschritt; keine gesetzliche oder technische Vorgabe.

Meldungen nach Handlungsbedarf staffeln

Eine Fehlermeldung sollte beantworten, was betroffen ist, seit wann, in welchem Zustand der Vorgang liegt und welche nächste Handlung erwartet wird. Sensible Inhalte gehören nicht ungekürzt in Chatkanäle oder Betreffzeilen. Meldungen werden nach Dringlichkeit und Zuständigkeit geroutet, nicht einfach an eine große Verteilerliste geschickt. Für häufige, automatisch behobene Störungen kann ein Sammelbericht genügen; ein unbekannter Fehler mit geschäftlicher Wirkung verlangt eine zeitnahe Eskalation. Zusätzlich wird definiert, wann aus vielen kleinen Ereignissen ein übergreifender Vorfall wird und wer diese Schwelle überwacht.

Einordnung: Redaktioneller Arbeitsschritt; keine gesetzliche oder technische Vorgabe.

Fehlerpfade unter realistischen Bedingungen proben

Ein Test schaltet gezielt eine Abhängigkeit ab, liefert unvollständige Daten, verzögert eine Antwort und wiederholt denselben Auftrag. Beobachtet wird nicht nur, ob eine Meldung erscheint, sondern ob Daten konsistent bleiben und die Wiederaufnahme verständlich funktioniert. Die Probe findet zuerst in einer isolierten Umgebung mit ungefährlichen Testdaten statt. Für jeden Fall werden erwarteter Zustand, tatsächliches Ergebnis und Abweichung notiert. Erfolgreiche Tests belegen nur die geprüfte Konfiguration; nach Änderungen an Schnittstellen, Regeln oder Zeitlimits müssen betroffene Fälle erneut ausgeführt werden. Produktionsstörungen werden anschließend als neue Testfälle aufbereitet. Zusätzlich prüft eine zweite Person die Anweisung zur manuellen Klärung, ohne mündliche Hinweise vom Entwicklungsteam zu erhalten. Bleibt ein Vorgang dabei unentscheidbar, fehlt dem Fehlerpfad entweder Kontext, Zuständigkeit oder eine klar definierte sichere Endposition.

Einordnung: Redaktioneller Arbeitsschritt; keine gesetzliche oder technische Vorgabe.

Im Zusammenhang weiterlesen

• Abhängigkeiten in Workflows begrenzen — Abhängigkeiten verschwinden selten; beherrschbar werden sie durch klare Verträge, begrenzte Ketten und getestete Ersatzwege.
• Protokolle für Abläufe definieren — Gute Ablaufprotokolle beantworten betriebliche Fragen mit möglichst wenigen, strukturierten Daten und klar geregeltem Zugriff.
• Wiederanlauf praktisch testen — Ein Wiederanlauftest prüft nicht nur, ob Technik startet, sondern ob eine priorisierte Leistung mit den vorgesehenen Personen, Daten und Kontrollen nutzbar zurückkehrt.