Datenpipelines müssen fachlich und nicht nur technisch überwacht werden.

Ein Importjob ist pünktlich gestartet, ohne Exception durchgelaufen und mit Status „Success" beendet. Trotzdem fehlen im Shop tausende Produkte. Preise sind veraltet, Bilder wurden nicht aktualisiert oder ein Herstellerfeed enthält plötzlich nur noch die Hälfte der erwarteten Datensätze.

Technisches Monitoring beantwortet:

• Läuft der Prozess?
• Ist die Infrastruktur erreichbar?
• Trat ein Fehler auf?

Fachliches Monitoring beantwortet:

• Sind die richtigen Daten angekommen?
• Sind sie vollständig, aktuell und plausibel?
• Können die abhängigen Geschäftsprozesse damit arbeiten?

Geschäftskritische Datenpipelines benötigen beide Perspektiven.

Die vier Grunddimensionen fachlicher Datenqualität

1. Aktualität

Wie alt sind die Daten im Verhältnis zur erwarteten Lieferung?

Beispiele:

• letzter erfolgreicher Preisstand,
• Zeitpunkt des letzten Bestandsupdates,
• Alter eines CRM-Exports,
• Verzögerung zwischen Quelländerung und Zielsystem.

2. Vollständigkeit

Sind alle erwarteten Datensätze und Pflichtinformationen vorhanden?

Beispiele:

• Zahl aktiver Produkte,
• Anteil Produkte mit Preis,
• Anteil Varianten mit Bild,
• Zahl übertragener Bestellungen,
• fehlende Sprachfassungen.

3. Gültigkeit

Entsprechen Werte Schema und Fachregeln?

Beispiele:

• Preise größer oder gleich null,
• zulässige Währungen,
• bekannte Kategorien,
• gültige Datumsintervalle,
• konsistente Einheiten,
• referenzierte Objekte vorhanden.

4. Konsistenz

Passen zusammengehörige Informationen zueinander und zu anderen Systemen?

Beispiele:

• Shopbestellung existiert im ERP,
• aktives Produkt besitzt freigegebene Variante,
• Bestandsstatus passt zur verfügbaren Menge,
• Übersetzung basiert auf aktueller Quelle,
• Dokumentversion gehört zum Produktzeitraum.

Erfolgreicher Job, fehlerhaftes Ergebnis

Typische Ursachen:

• Quelle liefert formal gültige, aber unvollständige Datei.
• API antwortet erfolgreich mit leerer Ergebnismenge.
• Mapping weist neue Kategorie still einem Default zu.
• Import verarbeitet nur den ersten Teil einer Pagination.
• Preisdatei besitzt eine andere Währung als erwartet.
• Delta-Feed überspringt Änderungen wegen falschem Zeitstempel.
• Produktbilder sind technisch erreichbar, aber enthalten Platzhalter.
• Datensätze werden importiert, jedoch wegen fehlender Freigabe nicht veröffentlicht.

Keine dieser Situationen muss eine technische Exception erzeugen.

Erwartungen als Data Contracts

Für jede Quelle oder Pipeline sollten fachliche Erwartungen definiert werden.

Beispiel Herstellerfeed:

Lieferung:                       täglich bis 04:00 Uhr
Erwartete aktive Produkte:       18.000–22.000
Maximale Mengenabweichung/Tag:   5 %
Pflichtfelder:                   SKU, Titel, Kategorie, Preis
Erlaubte Währungen:              EUR
Maximaler Anteil ohne Bild:      2 %
Löschungen nur mit explizitem Status

Verletzt eine Lieferung den Contract, wird sie nicht zwingend sofort vollständig verworfen. Sie kann:

• blockiert,
• in Quarantäne gespeichert,
• teilweise verarbeitet,
• mit Warnung übernommen,
• zur manuellen Freigabe gestellt werden.

Die Reaktion hängt von der Regel und dem Risiko ab.

Baselines und Anomalien

Feste Grenzwerte reichen nicht immer. Manche Daten verändern sich saisonal oder wachsen kontinuierlich.

Zusätzlich können Baselines betrachtet werden:

• durchschnittliche Datensatzanzahl der letzten 30 Tage,
• typische Preisänderungsverteilung,
• übliche Zahl neuer Produkte pro Woche,
• erwartete Bestellmenge je Wochentag,
• normale Fehlerquote je Quelle.

Auffälligkeiten:

• plötzlich 70 Prozent weniger Produkte,
• ungewöhnlich viele Preisänderungen über 50 Prozent,
• keine neuen Bestellungen während normaler Geschäftszeit,
• stark steigende Zahl unbekannter Kategorien,
• Übersetzungsfeedback unmittelbar nach einem Modellwechsel.

Anomalieerkennung ersetzt keine festen fachlichen Regeln. Sie ergänzt sie dort, wo das normale Verhalten nicht durch einen einzelnen Grenzwert beschrieben werden kann.

Schema Drift und semantische Drift

Schema Drift

Die Quelle ändert Struktur oder Datentyp:

• Feld umbenannt,
• neues Pflichtfeld,
• Zahl wird als Text geliefert,
• verschachtelte Struktur verändert.

Diese Änderungen lassen sich häufig technisch erkennen.

Semantische Drift

Das Feld heißt weiterhin gleich, bedeutet aber etwas anderes.

Beispiel:

• stock enthält früher physischen Bestand, später verkaufbare Menge.
• price wechselt von netto zu brutto.
• Statuscode 1 bedeutet nicht mehr „aktiv", sondern „freigegeben".

Semantische Drift ist gefährlicher, weil die Pipeline technisch weiterläuft. Data Contracts, Verteilungsvergleiche und Abstimmung mit Quellen sind entscheidend.

Quarantäne statt stiller Fehler

Datensätze, die Regeln verletzen, sollten nicht pauschal verschwinden oder ungeprüft live gehen.

Eine Quarantäne speichert:

• Rohdatensatz,
• Quelle und Lieferzeit,
• verletzte Regeln,
• Transformationsstand,
• betroffene Zielobjekte,
• Bearbeitungsstatus,
• mögliche Korrektur.

Fachbereich oder Datenverantwortliche können Fälle prüfen und nach Korrektur gezielt neu verarbeiten.

Technisches und fachliches Dashboard verbinden

Ein gutes Operations Dashboard zeigt beide Ebenen.

Technisch

• Jobstatus,
• Laufzeit,
• Queue-Länge,
• Fehler und Retries,
• Ressourcenauslastung,
• API-Antwortzeiten.

Fachlich

• Datenalter,
• gelesene und veröffentlichte Datensätze,
• Qualitätsquote,
• Produkte ohne Preis oder Bild,
• ungeklärte Mappings,
• fehlende Bestellübergaben,
• Abweichungen zwischen Systemen.

Der Betreiber erkennt dadurch, ob ein grüner Job tatsächlich ein grünes Geschäftsergebnis erzeugt hat.

Alerts müssen handlungsfähig sein

Ein Alert sollte enthalten:

• betroffene Pipeline und Quelle,
• verletzte Erwartung,
• Ausmaß,
• Beginn und letzter guter Zustand,
• betroffene Verbraucher oder Geschäftsprozesse,
• empfohlene erste Prüfung,
• Link zu Dashboard, Runbook oder Quarantäne.

Schlecht:

Besser:

Der zweite Alert macht Risiko und Schutzmaßnahme sichtbar.

Schweregrade am Geschäftseffekt ausrichten

Nicht jeder Datenfehler ist ein Incident höchster Priorität.

Kritisch

• Bestellungen gehen verloren,
• falsche Preise werden verkauft,
• geschützte Daten werden öffentlich,
• massenhafte Produktdeaktivierung droht.

Hoch

• wichtige Quelle deutlich veraltet,
• großer Sortimentsanteil ohne Preis,
• Statusrückfluss aus ERP gestört.

Mittel

• einzelne unbekannte Kategorien,
• erhöhte Zahl fehlender Bilder,
• nicht kritische Übersetzungen veraltet.

Niedrig

• vereinzelte redaktionelle Qualitätswarnungen.

Die Einstufung bestimmt Bereitschaft, Reaktionszeit und Eskalation.

Ownership und Runbooks

Jede Pipeline benötigt:

• technischen Owner,
• fachlichen Owner,
• Quellansprechpartner,
• definierte Service- und Datenziele,
• Runbook für typische Fehler,
• Eskalationsweg,
• Rückfall- oder Schutzstrategie.

Der technische Owner kann eine API reparieren. Der fachliche Owner entscheidet, ob ein ungewöhnlicher Preisbestand legitim ist. Beide Rollen sind notwendig.

Data SLOs

Neben Infrastruktur-SLOs können Datenziele definiert werden.

Beispiele:

• 99 Prozent der Preisänderungen innerhalb von 15 Minuten im Shop,
• täglicher Produktfeed bis 05:00 Uhr vollständig verarbeitet,
• weniger als 0,5 Prozent aktive Produkte ohne Preis,
• keine Bestellung länger als zehn Minuten ohne ERP-Bestätigung,
• 98 Prozent der veröffentlichten Übersetzungen basieren auf aktueller Quelle.

Ziele müssen zum Geschäftsprozess passen und dürfen nicht nur technisch bequem gewählt werden.

Automatische Schutzmaßnahmen

Bestimmte Abweichungen können automatische Reaktionen auslösen:

• ungewöhnlich kleiner Vollfeed deaktiviert keine Produkte,
• veralteter Preisfeed stoppt bestimmte Verkäufe,
• unbekannte Kategorie leitet Produkt in Quarantäne statt Default,
• fehlgeschlagene Bestellübergabe wird wiederholt und priorisiert,
• alte Indexversion bleibt aktiv, wenn neuer Suchindex unvollständig ist,
• problematisches Übersetzungsmodell wird zurückgerollt.

Automatisierung verhindert nicht jede Störung. Sie begrenzt den Schaden und schafft Zeit für Analyse.

Nach dem Incident: fachliche Ursache und Systemverbesserung

Ein Incident Review sollte nicht bei „API war kurz nicht erreichbar" enden.

Zu fragen ist:

• Warum wurde der fachliche Schaden nicht früher erkannt?
• Welcher Contract oder Alert fehlte?
• War der Fallback richtig?
• Welche Datensätze müssen korrigiert werden?
• Können Tests oder Baselines den Fall künftig erkennen?
• Muss die Quelle oder das Datenmodell angepasst werden?
• Welche Nutzer oder nachgelagerten Systeme sind betroffen?

So verbessert jeder Vorfall die Datenplattform und nicht nur den einzelnen Job.