Nightly-Anonymization mit BTP Job Scheduler – Cutover-Pattern für 01:00 CET

01:00 CET startet die Pipeline, 01:30 CET Cutover, 02:00 CET fertig. Was im 60-Min-Window passieren muss, wie das Service-Window kommuniziert wird, und welcher Fail-Mode greift wenn die Pipeline abreisst – als operativ funktionierender Pattern.

Das Service-Window

```mermaid gantt dateFormat HH:mm axisFormat %H:%M title Nightly-Anonymization-Window (CET)

section Service-Window
QAS unavailable    :crit, sw, 01:00, 60min

section Pipeline
Stage 1 Source     :s1, 01:00, 10min
Stage 2 Transform  :s2, after s1, 15min
Stage 3 Validate   :s3, after s2, 5min
Stage 4 Sink       :s4, after s3, 10min

section Buffer
Reserve            :buf, after s4, 20min

```

• 01:00–01:10: Stage 1 (Source-Connector) liest aus PRD
• 01:10–01:25: Stage 2 (Transform-Pipeline) anonymisiert
• 01:25–01:30: Stage 3 (Validator) prüft
• 01:30–01:40: Stage 4 (Sink-Loader) lädt in QAS
• 01:40–02:00: Buffer für Smoke-Tests + KPI-Snapshot

Total: 60 Min Service-Window für QAS, mit 20 Min Buffer für Edge-Cases.

BTP Job Scheduler Konfiguration

```yaml

anonymizer-job.yaml

• name: bamvp-anonymizer-nightly description: "Nightly PRD → QAS Anonymization" schedules:
  • cron: "0 0 1 * * *" time_zone: "Europe/Zurich" active: true retry_settings: max_retries: 0 # ← keine Retry beim Datenschutz-Job! notification_settings: on_failure: "slack-channel-bamvp-ops" on_success: "slack-channel-bamvp-ops" http: method: POST url: "https://anonymizer.qas.bamvp.example.com/api/run" auth: oauth2-clientcredentials timeout: 3600 # 60 Min ```

Wichtige Details: - max_retries: 0 – wenn die Pipeline failt, ist der Recovery-Pfad manuell, nicht „nochmal probieren“. Doppel-Läufe können Race-Conditions auslösen. - Notification an Slack/Teams sowohl bei Erfolg als auch bei Fehler – wer keine Erfolgs-Meldung hat, weiss nicht, ob der Job überhaupt lief.

Was im 60-Min-Window stillsteht

QAS ist während des Windows nicht verfügbar: - API-Calls geben 503 - BTP-Cockpit zeigt Wartungs-Banner - Tester wissen das (siehe Kommunikation unten)

Was nicht stillsteht: PRD (das ist die Quelle, läuft 24/7), DEV (synthetische Fixtures, unabhängig).

Kommunikation des Service-Windows

Drei Kanäle, alle automatisch:

Kanal 1 – BTP-Cockpit-Banner

QAS-Subaccount zeigt von 00:50 bis 02:10 ein Wartungs-Banner: „QAS-Systeme von 01:00 bis 02:00 CET nicht verfügbar (täglich Anonymisierung).“

Kanal 2 – Kalender-Integration

QAS-Verfügbarkeit ist als Outlook-Resource modelliert. Tester sehen es im Kalender wenn sie Test-Termine planen.

Kanal 3 – API-Response 503 mit Retry-After

http HTTP/1.1 503 Service Unavailable Retry-After: 1800

Tools können nach 30 Min erneut probieren, ohne dass User es manuell triggern.

Fail-Modes und Recovery

Fail-Mode A – Stage 1 (Source) failt

PRD-Tech-User abgelaufen, oder PRD-HDI down.

Recovery: Tech-User-Refresh oder PRD-Outage-Communication. QAS bleibt im alten Zustand (von gestern). Tester arbeiten mit gestrigen Daten weiter, der Bug-Repro ist davon meist nicht betroffen.

Fail-Mode B – Stage 2 (Transform) failt

Schema-Drift in PRD: neues Feld erschien, hat keine Regel in der Field-Registry.

Recovery: Privacy-Lead reviewt das neue Feld, fügt Regel hinzu, manueller Re-Run. QAS bleibt im alten Zustand bis Manuell-Run.

Fail-Mode C – Stage 3 (Validator) failt

k-Anonymity- oder Re-ID-Test schlägt fehl.

Recovery: PIPELINE STOPPT. Privacy-Lead untersucht warum (typisch: ein neuer Datensatz in seltener Kombination). Bucketing anpassen oder Datensatz droppen, manueller Re-Run.

Wichtig: bei Validator-Failure läuft Stage 4 nicht. QAS bleibt im alten Zustand. Diese Disziplin ist kritisch – man darf nie „mal kurz“ das Validator-Gate öffnen.

Fail-Mode D – Stage 4 (Sink) failt mid-flight

Disk full, Connection broke, etc.

Recovery: Pipeline ist transaktional. Bei Mid-Flight-Failure rollback automatisch. QAS bleibt im alten Zustand. Manueller Re-Run nach Disk-Fix etc.

Was nicht ins Service-Window passt

Folgende Operationen werden nicht im Anonymisierungs-Window gemacht: - QAS-Schema-Änderungen → eigenes Window (z.B. Sonntag 03:00) - HANA-Patch-Updates → eigenes Window - Salt-Rotation → eigenes Window mit Notice

Wenn diese mit dem Anonymisierungs-Job kollidieren, wird der Job für die betroffene Nacht ausgesetzt – manuell, dokumentiert.

KPI-Tracking

Nach jedem Pipeline-Run werden Metriken in einer separaten KPI-Tabelle gespeichert:

Wenn duration_seconds > 3000 (>50 Min) oder validator_violations > 0, kommt ein Soft-Alarm an den Privacy-Lead.

Operations-Aufwand

• Pipeline-Monitoring: passiv via Slack/Teams-Alerts
• Manueller Re-Run bei Fail-Modes: ~2-4× pro Quartal, 30-60 Min pro Mal
• Service-Window-Kommunikation: einmal eingerichtet, läuft

Wer das einrichten will

Ein Workshop (halbtägig) baut Ihren Anonymisierungs-Cron-Job: BTP Job Scheduler, Notification-Setup, Fail-Mode-Runbooks. Output: lauffähiger Job + Operations-Dokumentation.

Stand: 2026-05-10

SFOUR Consulting — Übersicht · Kontakt