Incident Management

Kurzzusammenfassung

• Incident Management verbindet Prefect-Failure-States mit dem operativen Störungsprozess.
• Business-Nutzen: schnellere Entstörung bei transparentem Impact auf Portfolio- und Modellprozesse.
• BPMN-Leitpfad: Task Create incident → Gateway Severity confirmed? → Outcome Owned remediation.
• Betriebsregel: Kritische Failure-States erzeugen automatisch Tickets mit vollständigem Laufkontext.

Ziel

Jeder relevante Flow-Fehler wird priorisiert, einem zuständigen Team übergeben und bis RCA/Prävention nachvollziehbar geschlossen.

Ablauf

BPMN-Schritt	Mechanik (Task/Gateway/Outcome)	Artefakte & Verantwortlich
Task: Detect failed state	Prefect meldet Failed/Crash/TimedOut/Late	Artefakt: State Event; Responsible: Platform Ops
Task: Create incident payload	Deployment, Run-ID, Logs, Retry-Verlauf, betroffene Datasets/Modelle anhängen	Artefakt: Incident Ticket; Responsible: Incident Bot
Gateway: Severity confirmed?	Priorisierung nach Business-Impact (EOD verzögert, Scoring-Ausfall etc.)	Nein: manuelle Triage; Accountable: Incident Manager
Outcome: Handover + remediation	Ownership, ETA, Updates, RCA-Link verpflichtend	Artefakt: Handover Record

Kontrollen

Governance- und Risiko-Aspekte

• Incident-Payload enthält keine unmaskierten sensitiven Daten.
• Für P1/P2 ist Kommunikations- und Update-Takt definiert.
• Abschluss nur mit RCA + Präventionsmassnahme.

Messbare Akzeptanzkriterien

Kriterium	Grenzwert	Verantwortlich	Eskalation
Ticket-Erstellung nach kritischem Failure	≤ 5 min	Platform Ops	> 10 min: On-Call Lead
Ownership-Bestätigung durch zuständiges Team	≤ 15 min	Incident Manager	> 30 min: Head of Ops
RCA-Abschluss für P1/P2	≤ 2 Arbeitstage	Owning Team	> 2 Tage: Governance Review

Entscheidung

• Ticket enthält vollständigen technischen und fachlichen Kontext.
• Severity und Ownership sind bestätigt.
• RCA und Präventionsmassnahme sind dokumentiert.

Minimales Incident-Datenmodell

Ein Incident aus Prefect-Läufen muss mindestens folgende Felder enthalten:

Feld	Beschreibung	Beispiel	Pflicht
run_id	Eindeutige Prefect Run-ID zur technischen Nachverfolgung	flow-run/2f7...	Ja
deployment_id	Deployment-Referenz für Version, Schedule und Ownership	deployment/9ab...	Ja
state_history	Zeitliche Folge relevanter States inkl. Timestamps und Reason Codes	Scheduled → Late → Running → Failed	Ja
correlated_assets	Betroffene fachliche Artefakte (Datasets, Feature Views, Modelle, Dashboards)	dataset:prices_eod_v4	Ja
business_impact	Fachliche Auswirkung inkl. Kritikalität, SLA-/Deadline-Risiko, betroffene Prozesse	EOD-Report verspätet, P2	Ja

Mindestanforderungen an die Modellierung

• state_history enthält mindestens den ersten und letzten Zustand sowie alle Failure-/Deferral-Übergänge.
• correlated_assets nutzt stabile Asset-IDs statt Freitextnamen, damit automatisches Routing möglich ist.
• business_impact enthält Severity, betroffene Stakeholder und einen ETA-/Mitigationshinweis.
• Alle Felder müssen im Ticket maschinenlesbar (strukturierte Payload) und menschlich lesbar vorliegen.

Beispiel-Payload (kompakt)

{
  "run_id": "flow-run/2f7c...",
  "deployment_id": "deployment/9ab1...",
  "state_history": [
    {"state": "Scheduled", "ts": "2026-02-10T21:00:00Z"},
    {"state": "Late", "ts": "2026-02-10T21:15:00Z", "reason": "capacity_limit"},
    {"state": "Running", "ts": "2026-02-10T21:22:00Z"},
    {"state": "Failed", "ts": "2026-02-10T21:24:31Z", "reason": "data_contract_violation"}
  ],
  "correlated_assets": [
    "dataset:prices_eod_v4",
    "feature-view:alpha_signals_v2",
    "model:allocation_xgb_v17"
  ],
  "business_impact": {
    "severity": "P2",
    "impact": "EOD scoring delayed",
    "deadline_at_risk": "2026-02-10T22:00:00Z"
  }
}

Zweck

Automatische Erstellung und Nachverfolgung von Incidents bei DQ-Failures oder Prozessabweichungen.

BPMN-Detailansicht

⋮⋮⋮

BPMN-Kontext

• IDs: ServiceTask_CreateIncident
• Input-Bezug: Fehler- oder Gate-Verletzungsereignis mit Severity und Kontext.
• Entscheidungsbezug: Priorisierung und Eskalationspfad entscheiden Incident-Level und Ownership.
• Output-Bezug: Ticket/Incident mit SLA, Owner und Nachverfolgung bis Abschluss.

RACI

Aktivität	Responsible	Accountable	Consulted	Informed
Incident automatisch erzeugen	Platform Ops	Platform Owner	Data Engineering	ML Team
Priorisierung / Routing	Incident Manager	Head of Ops	Data Owner, Risk	Stakeholder
Abschluss & RCA-Dokumentation	Zuständiges Team	Team Lead	Governance	Portfolio Management

Ticket-Template

• Incident-ID, Umgebung, betroffener Flow
• Run-ID, Dataset-/Model-Versionen
• Fehlerbild und erste Hypothese
• Impact (z. B. verzögertes Scoring)
• Sofortmassnahmen + ETA
• Link zu Logs, DQ-Report, Quarantine-Record

Beispiel

Bei DQ-Fail wird ein P2-Ticket erzeugt, automatisch dem Data-Steward zugewiesen und mit der Quarantine-ID verknüpft.

Mindestinhalt des Tickets

• betroffener Flow und Task
• Run-ID, Dataset-ID, Modell-/Feature-Version
• erste Fehlerdiagnose
• Link zu Logs, DQ-Report und Quarantine-Datensatz