Failure Handling

Kurzzusammenfassung

• Failure Handling definiert den standardisierten Umgang mit technischen und fachlichen Laufzeitfehlern.
• Business-Nutzen: kürzere Recovery-Zeit und weniger Folgefehler in Downstream-Prozessen.
• BPMN-Leitpfad: Task Classify failure → Gateway Retry allowed? → Outcome Recovered/escalated.
• Betriebsregel: Compliance-/DQ-Hardstops umgehen automatische Retries.

Ziel

Fehler werden konsistent klassifiziert, mit passender Retry-Strategie behandelt und bei Bedarf innerhalb SLA an Incident Management übergeben.

Ablauf

BPMN-Schritt	Mechanik (Task/Gateway/Outcome)	Artefakte & Verantwortlich
Task: Classify failure	Fehlerkategorie (transient/permanent/data-contract/governance-block) bestimmen	Artefakt: Failure Class; Responsible: Data Engineering
Task: Execute retry strategy	Retry-Count, Backoff und Timeout deployment-spezifisch anwenden	Artefakt: Retry Log; Responsible: Prefect Worker
Gateway: Retry allowed?	Prüft Max-Retries, Hardstop-Regeln, SLA-Fenster	Nein: Incident-Handover; Accountable: Platform Owner
Outcome: Recovered/escalated	Wiederanlauf erfolgreich oder finaler Failure-State	Artefakt: Recovery Report

Kontrollen

Governance- und Risiko-Aspekte

• DQ-Fail und Policy-Verletzung führen direkt zu Incident/Pause.
• Retry-Änderungen sind versions- und releasepflichtig.
• Wiederholte Fehler gleicher Signatur triggern Problem-Management.

Messbare Akzeptanzkriterien

Kriterium	Grenzwert	Verantwortlich	Eskalation
Deployments mit dokumentierter Failure-Matrix	100 %	Platform Team	fehlend: Deploy-Block
Max. automatische Retries (transient)	≤ 3	Data Engineering	> 3 nur mit Freigabe
Eskalation nach finalem Failure-State	≤ 10 min	Platform Ops	> 15 min: Incident Manager

Entscheidung

• Fehlerklassifikation und Retry-Pfad sind dokumentiert.
• Hardstop-Regeln wurden eingehalten.
• Finale Failures wurden fristgerecht übergeben.

Strategie

• Retries für transiente Fehler
• Alerts bei wiederholtem Fehlschlag
• Hard Stops bei Regelverletzungen (DQ / Compliance)

Incident-Pfad

1. Fehlerklassifikation
2. technische oder fachliche Eskalation
3. Wiederanlauf oder Rollback nach Freigabe

Erweiterte Fehlertypologie mit Recovery-Strategien

Fehlertyp	Erkennungsmerkmale	Zulässige Recovery-Strategie	Nicht zulässig	Eskalation
transient	temporäre Netzwerk-/Servicefehler, Rate-Limits, kurzzeitige Infrastrukturprobleme	begrenzte automatische Retries mit exponentiellem Backoff + Jitter; optional Worker-Requeue	unendliche Retries, manuelle Datenkorrektur ohne Evidenz	bei finalem Failed an Incident Mgmt innerhalb SLA
permanent	deterministischer Code-/Konfigurationsfehler, reproduzierbar bei Wiederholung	sofortiger Stop, Fix-forward oder Rollback auf letzte stabile Deployment-Version	erneute identische Retries ohne Code-/Config-Änderung	direkt an Owning Team + Incident Manager
data-contract	Schema-Drift, fehlende Pflichtfelder, verletzte DQ-/Interface-Constraints	Quarantäne des Inputs, Contract-Validation-Report, ggf. gezielter Replay nach Korrektur	stilles Überspringen fehlerhafter Datensätze bei kritischen Flows	Incident inkl. Data Owner und Producer-Team
governance-block	Policy/Compliance-Verstoss, fehlende Freigabe, gesperrtes Modell/Feature	Hard Stop, manuelle Freigabe- und Ausnahmeprüfung, lückenlose Audit-Dokumentation	automatische Retries oder Umgehung von Kontrollpunkten	sofortige Governance-Eskalation (P1/P2 je Impact)

Zuordnung zu Prefect-State-Mustern

• transient: oft Crashed, TimedOut, temporär Failed mit nachfolgend Retrying/Running.
• permanent: wiederholt gleicher Failed-Signaturfingerprint ohne Änderung der Inputs.
• data-contract: Failed mit DQ-/Schema-Reason-Code und Link auf Quarantäne-Artefakt.
• governance-block: Cancelled/Paused/Failed mit explizitem Policy-Reason-Code.

Recovery-Entscheidungslogik (operativ)

1. Classify first, then act: Keine Retry-Ausführung ohne dokumentierte Fehlerklasse.
2. Retry nur für transient: Alle anderen Klassen starten direkt mit Incident- oder Governance-Handover.
3. Evidence before restart: Wiederanlauf erst nach dokumentierter Ursache + Gegenmassnahme.
4. State + Reason Code sind Pflicht: Jede Recovery-Entscheidung ist im Run- und Incident-Kontext nachvollziehbar.

BPMN-Kontext

• IDs: EndEvent_RunAborted
• Input-Bezug: Abgebrochener Run mit Fehlerkontext, Logs und Incident-Referenz.
• Entscheidungsbezug: Entscheidung über Retry, Recovery oder endgültigen Abbruch inkl. Verantwortlichkeit.
• Output-Bezug: Dokumentierter Endzustand EndEvent_RunAborted mit Post-Mortem und Folgeaktion.