Scheduling

Kurzzusammenfassung

• Scheduling steuert, wann Deployments für EOD, Backfills und Retraining laufen.
• Business-Nutzen: stabile Lieferzeiten für Portfolio-Entscheidungen und Reports.
• BPMN-Leitpfad: Task Plan schedule → Gateway Trigger + capacity valid? → Outcome Run queued/deferred.
• Betriebsregel: Ohne Retry-/Timeout-/Escalation-Profil keine produktive Aktivierung.

Ziel

Jedes Deployment besitzt einen belastbaren Triggerplan (Zeit/Event), Kapazitätsgrenzen und klare Eskalation bei Verzögerungen.

Ablauf

BPMN-Schritt	Mechanik (Task/Gateway/Outcome)	Artefakte & Verantwortlich
Task: Define schedule	Cron/Interval/Event inkl. Zeitzone und Wartungsfenster konfigurieren	Artefakt: Schedule Config; Responsible: MLOps
Task: Configure runtime policies	Retries, Timeout, Concurrency, Late-Run-Verhalten setzen	Artefakt: Runtime Policy; Responsible: Platform Team
Gateway: Trigger + capacity valid?	Prüft Konflikte mit kritischen Jobs (EOD, Scoring)	Nein: Deferred + Alert; Accountable: Platform Owner
Outcome: Queue/defer run	Ausführung oder Aufschub mit Grundcode	Artefakt: Scheduler Event

Kontrollen

Governance- und Risiko-Aspekte

• Priorität produktiver EOD-Flows vor Backfills.
• Event-Trigger sind idempotent und auditierbar.
• Häufige Deferrals werden als Betriebsrisiko gemeldet.

Messbare Akzeptanzkriterien

Kriterium	Grenzwert	Verantwortlich	Eskalation
Erfolgreich gestartete geplante Runs	≥ 99 % / Woche	MLOps	< 98 %: P2 Incident
Deployments mit Retry+Timeout-Profil	100 %	Platform Team	fehlend: Activation Block
Deferral-Dauer bei Kapazitätskonflikt	≤ 30 min	Platform Ops	> 60 min: Incident Manager

Entscheidung

• Triggerplan und Runtime-Policy sind freigegeben.
• Capacity-Gateway ist automatisiert und nachvollziehbar.
• Eskalationszeiten für Deferrals sind verbindlich.

⋮⋮⋮

Trigger-Typen

• Zeitgesteuert (Cron/Interval)
• Ereignisgesteuert (neue Daten, Registry-Events)
• Governance-gesteuert (manuell freigegebene Runs)

Trigger-Policy (präzise)

Zulässige Trigger-Kanäle

Trigger-Typ	Definition	Pflichtfelder	Policy-Regel
cron/interval	Zeitbasierter Start über Deployment-Schedule mit Zeitzone	deployment_id, schedule, timezone, effective_from	Nur freigegebene Wartungsfenster; keine Überlappung mit gesperrten Betriebszeiten
event	Start bei eingehendem Event (z. B. Dateneingang, Registry-Update)	event_id, event_type, occurred_at, producer, idempotency_key	Event muss idempotent verarbeitbar und schema-validiert sein
manuell	Bewusster Operator-Start für Ausnahmefälle (Hotfix, Recovery, Governance-Run)	requested_by, reason_code, ticket_ref, approved_at	Für produktive Deployments nur mit dokumentierter Freigabe

Idempotenter Event-Contract

Für eventgetriggerte Runs gilt ein verbindlicher Contract:

• Eindeutigkeit: idempotency_key ist pro fachlichem Ereignis stabil und eindeutig.
• Deduplizierung: gleiches deployment_id + idempotency_key darf maximal einen aktiven Run erzeugen.
• Unveränderlichkeit: Event-Payload wird nach Eingang nicht mutiert; Korrekturen erfolgen nur per neuem Event mit neuer Version.
• Kausalität: occurred_at und producer sind Pflicht, um Reihenfolge und Herkunft auditierbar zu machen.
• Schema-Vertrag: Event-Typen sind versioniert (event_type@vN); Breaking Changes erfordern neue Version.

Deferral-Regeln

Ein Run wird auf Deferred gesetzt, wenn mindestens eine Bedingung zutrifft:

1. Kapazitätslimit erreicht (Work Pool Concurrency Cap oder Queue-Limit).
2. Prioritätskonflikt mit höher priorisiertem EOD-/Scoring-Deployment.
3. Change-Freeze/Wartungsfenster aktiv.
4. Abhängigkeit nicht bereit (z. B. Upstream-Dataset/Block nicht verfügbar).

Verbindliche Regeln für Deferred-Runs:

• Deferred-Runs erhalten einen maschinenlesbaren deferral_reason_code.
• Jeder Deferred-Run hat eine next_evaluation_at-Zeit für erneute Einplanung.
• Nach Überschreiten der max. Deferral-Dauer (SLA) erfolgt automatische Incident-Eskalation.
• Manuelle Overrides sind nur mit Ticket-Referenz zulässig und vollständig auditpflichtig.

Retrain Trigger

Retraining wird bei Drift, KPI-Degradation oder periodischem Refit ausgelöst.

Drill-Down Kontext

Das Retraining ist als eigener Subprozess modelliert und aus dem Hauptprozess direkt drill-down-fähig verlinkt.

BPMN-Kontext

• IDs: StartEvent_Timer, Gateway_Retrain, CallActivity_RetrainJob
• Input-Bezug: Geplante oder eventbasierte Trigger (StartEvent_Timer) mit Run-Konfiguration und Policy.
• Entscheidungsbezug: Retrain-Gate (Gateway_Retrain) entscheidet anhand Drift/KPI-Policy über neuen Retrain-Run; zentrale Gate-Logik siehe /docs/research-risk/acceptance-criteria.
• Output-Bezug: Freigegebener Retrain-Job (CallActivity_RetrainJob) oder dokumentierter Deferral/No-Retrain-Entscheid.