Backfills

Kurzzusammenfassung

• Backfills korrigieren historische Zeiträume kontrolliert, ohne produktive Läufe zu destabilisieren.
• Business-Nutzen: reproduzierbare Historie für Modellvergleich, Backtesting und Audit.
• BPMN-Leitpfad: Task Plan backfill window → Gateway Operational impact acceptable? → Outcome Window processed/rejected.
• Betriebsregel: Backfills laufen nur in isolierten Deployments mit separater Queue.

Ziel

Historische Neuberechnungen sind planbar, nachvollziehbar und inklusive Downstream-Auswirkungsanalyse (Features, Modelle, Dashboards) dokumentiert.

Ablauf

BPMN-Schritt	Mechanik (Task/Gateway/Outcome)	Artefakte & Verantwortlich
Task: Define backfill plan	Zeitraum, Ursachen, Datenquellen, Ressourcenlimits festlegen	Artefakt: Backfill Plan; Responsible: Data Engineering
Task: Launch isolated deployment	Separates Deployment/Schedule mit Rate-Limits starten	Artefakt: Backfill Deployment + Runs; Responsible: MLOps
Gateway: Operational impact acceptable?	Prüft SLA, Kosten, Queue-Impact auf EOD/Scoring	Nein: verschieben/abbrechen; Accountable: Product Owner
Outcome: Reconcile results	Soll/Ist-Abgleich und Referenz auf betroffene Modellversionen	Artefakt: Reconciliation Report

Kontrollen

Governance- und Risiko-Aspekte

• Kein Verdrängen kritischer produktiver Schedules.
• Jeder Backfill-Run referenziert Registry-/Feature-Versionen.
• Fehler im Backfill nutzen denselben Incident-Prozess wie Prod-Runs.

Messbare Akzeptanzkriterien

Kriterium	Grenzwert	Verantwortlich	Eskalation
Backfills mit genehmigtem Plan	100 %	Product Owner	ohne Plan: Startblock
Abweichung Soll/Ist nach Backfill	≤ 0.5 % Datensätze	Data Engineering	> 1 %: P2 Incident
Eskalationszeit bei fehlgeschlagenem kritischem Backfill	≤ 15 min	MLOps	> 20 min: On-Call Lead

Entscheidung

• Plan, Deployment und Limits sind freigegeben.
• Impact-Gateway wurde dokumentiert entschieden.
• Reconciliation/Incident-Handover ist abgeschlossen.

Safe-Backfill-Mechanik

1) Chunking

• Backfill-Fenster werden in deterministische Chunks geteilt (z. B. Tag/Woche/Partition) statt als Monolith verarbeitet.
• Chunk-Grösse richtet sich nach Laufzeitprofil und Wiederanlaufkosten; Ziel: kurze, isolierbare Fehlerspannen.
• Jeder Chunk hat eine eindeutige chunk_id und referenziert denselben Daten-/Code-Stand (As-of-Prinzip).

2) Concurrency Caps

• Separate Backfill-Work-Pools mit harten Concurrency-Limits verhindern Verdrängung produktiver Läufe.
• Zusätzlich gelten task-/tag-basierte Limits für kritische Shared Resources (DB, Feature Store, Registry).
• Bei SLA-Risiko werden Backfill-Runs automatisch gedrosselt oder deferred.

3) Reconciliation

• Nach jedem Chunk erfolgt Soll/Ist-Abgleich (Row Counts, DQ-Metriken, KPI-Drift, Modellinput-Konsistenz).
• Reconciliation ist nicht optional: nur validierte Chunks dürfen als abgeschlossen markiert werden.
• Abweichungen werden je nach Schweregrad sofort remediert oder als Incident übergeben.

4) Stop-Conditions

Backfill wird automatisch pausiert/abgebrochen bei:

1. wiederholtem Chunk-Fehlschlag über Schwellwert,
2. signifikanter KPI-Verschlechterung gegenüber Baseline,
3. Überschreitung definierter Kosten-/Laufzeitbudgets,
4. Beeinträchtigung priorisierter Produktions-SLAs.

KPI-Grenzen (operativ)

KPI	Grenzwert (Stop/Review)	Aktion
Chunk Failure Rate	> 5 % pro Backfill-Job	Pause + Ursachenanalyse
Reconciliation-Abweichung (Rows)	> 0.5 % Warnung, > 1.0 % Stop	Incident + Datenprüfung
P95 Chunk Runtime	> 2x Planwert	Concurrency reduzieren / Chunk verkleinern
Produktions-Queue-Latenz durch Backfill	> 10 min	Sofort drosseln oder anhalten
Kritische KPI-Drift im Zielprozess	> definierter Guardrail (z. B. +/−3 %)	Backfill stoppen, fachliche Freigabe nötig

Zweck

Re-Runs historischer Zeiträume für Datenkorrekturen, Reproduzierbarkeit und Modellvergleich.

Leitlinien

• As-of-Ausführung mit fixierten Abhängigkeiten
• Trennung von Produktiv- und Backfill-Runs
• Dokumentierte Auswirkungen auf Feature- und Modellversionen