Was ist ein Data SLA?

Ein Data SLA (Service Level Agreement) ist eine förmliche Zusage, ein Data Product mit bestimmten, messbaren Eigenschaften zu liefern: Aktualität, Genauigkeit, Vollständigkeit, Verfügbarkeit, Konsistenz und Schemastabilität. Es ist der Vertrag, der aus einem Datensatz statt „etwas, das Sie wahrscheinlich nutzen können“ ein „etwas, auf das Sie sich am Dienstag um 8 Uhr mit 99,5 % Sicherheit verlassen können“ macht. Wo herkömmliche SLAs der Infrastruktur Verfügbarkeit und Latenz eines Dienstes zusagen, sagen Data SLAs die Qualität und die Zeittreue der Daten zu, die dieser Dienst erzeugt.

Data SLAs sind aus zwei zusammenlaufenden Traditionen entstanden: aus der Erfahrung des IT-Betriebs mit SLAs für Anwendungsdienste und aus der schmerzhaften Einsicht des Data Engineering, dass eine Lieferung „nach bestem Bemühen“ jenseits einer kleinen Zahl von Data Consumern nicht mehr trägt. Als Data Products zu wiederverwendbaren Beständen wurden, die nachgelagerte Anwendungen, ML-Modelle, regulatorische Berichte und KI-Agenten bedienen, reichte „die Pipeline ist heute Nacht gelaufen“ nicht mehr aus. Die Data Consumer brauchten eine veröffentlichte Zusage, mit der sie planen konnten, und die Erzeuger brauchten eine ausdrückliche Grenze, die festlegte, wofür sie verantwortlich waren und wofür nicht.

Data SLA im Überblick

Ein Data SLA ist eine schriftliche, messbare und zeitlich gebundene Zusage des Erzeugers eines Data Product an seine Data Consumer darüber, welche Eigenschaften die Daten aufweisen werden. Die Zusage ist prüfbar, das heißt, jede Klausel lässt sich über eine automatische Überwachung als „erfüllt“ oder „verletzt“ bewerten, und sie hat für beide Seiten Folgen, wenn sie verletzt wird: ein geordnetes Verfahren für Vorfälle, eine förmliche Behebung und, in reifen Aufstellungen, möglicherweise eine Eskalation oder finanzielle Strafen, wenn Daten über Organisationsgrenzen hinweg geteilt werden.

Die bestimmenden Merkmale eines Data SLA:

• Konkrete Dimensionen: Jede Klausel benennt eine messbare Eigenschaft der Daten (etwa „Aktualität: Daten werden alle 4 Stunden aufgefrischt“) statt vager Absichtserklärungen („aktuelle Daten“).
• Messbare Ziele: Zahlenwerte, die die Daten erreichen müssen (etwa „99,5 % der Datensätze bestehen die Prüfungen auf Vollständigkeit“).
• Zeitliche Grenzen: Wann die Zusage gilt und über welches Messfenster (etwa „rollierendes Fenster von 30 Tagen während der Geschäftszeiten“).
• Messbarkeit: Der Erzeuger instrumentiert die Daten so, dass die SLA-Compliance fortlaufend gemessen und nicht geschätzt wird.
• Folgen: Festgelegte Reaktionen auf eine Verletzung des SLA, nämlich Alarmierung, Ursachenanalyse, Kommunikation an die Data Consumer und ein Plan zur Behebung.

Sechs Dimensionen eines Data SLA

Ein gut gebautes Data SLA behandelt sechs wiederkehrende Dimensionen. Nicht jedes Produkt braucht alle sechs, doch jede steht für eine Art von Ausfall, die den Data Consumer trifft.

1. Aktualität

Wie kürzlich wurden die Daten aktualisiert? Ausgedrückt entweder als Frequenz („alle 4 Stunden aufgefrischt“) oder als höchstzulässiger Verzug („während der Geschäftszeiten nie älter als 6 Stunden“). Verletzungen der Aktualität fallen meist am schnellsten auf, denn Analysten und Dashboards bemerken sie sofort.

2. Genauigkeit

Wie gut stimmen die Daten mit der Quelle der Wahrheit überein oder bestehen die Prüfung gegen fachliche Regeln? Oft als Prozentsatz ausgedrückt („mindestens 99,7 % der Datensätze stimmen nach dem Abgleich mit dem Quellsystem überein“). Genauigkeit ist schwerer zu messen als Aktualität, weil sie eine Referenz zum Vergleich braucht.

3. Vollständigkeit

Welcher Anteil der erwarteten Daten liegt vor? Ausgedrückt über Zeilenzahlen gegen erwartete Bandbreiten („tägliche Zeilenzahl innerhalb von ±5 % des Mittels der vergangenen 30 Tage“) oder über NULL-Raten („weniger als 0,1 % NULL-Werte in den Spalten des Primärschlüssels“). Ausfälle der Vollständigkeit deuten häufig auf gescheiterte Extraktionen weiter oben hin, die sonst keinen Alarm auslösen.

4. Verfügbarkeit

Ist das Data Product erreichbar, wenn es das sein soll? Unmittelbar aus den SLAs der Infrastruktur übernommen und in Neunen ausgedrückt („99,9 % Verfügbarkeit während der veröffentlichten Zeiten“). Bei analytischen Produkten verschwimmt die Verfügbarkeit oft mit der Aktualität; bei operativen Data Products, die laufende Anwendungen bedienen, ist sie eine eigene, harte Anforderung.

5. Konsistenz

Stimmen die Daten mit sich selbst und mit verwandten Produkten überein? Dazu zählen die referenzielle Konsistenz über verbundene Tabellen hinweg, die Konsistenz zu einem Zeitpunkt bei systemübergreifenden Lesezugriffen und die Konsistenz von Kennzahlen über Berichte hinweg. Oft die Dimension, die die meisten Data Consumer spüren und die die wenigsten SLAs ausdrücklich abdecken.

6. Schemastabilität

Wie viel Vorlauf bekommen die Data Consumer, bevor sich das Schema in brechender Weise ändert? Ausgedrückt als Vorlaufzeit („90 Tage Vorlauf für jede brechende Änderung des Schemas, mit rückwärtskompatibler Migration“) und als Art der Änderung („Ergänzungen brechen nicht; Entfernungen und Typänderungen brechen und verlangen die ausdrückliche Zustimmung des Data Consumer“). Die Schemastabilität ist die Dimension, die am stärksten darüber entscheidet, ob nachgelagerte Data Consumer sich langfristig auf das Produkt verlassen können.

Data SLA und Data Contract

„Data SLA“ und „Data Contract“ sind verwandt, aber nicht dasselbe. Ein Data Contract ist die breitere Vereinbarung zwischen Erzeuger und Data Consumer über Schema, Semantik, Zugriffsregeln, Verantwortung und Pflichten auf beiden Seiten. Ein Data SLA ist der Teil des Vertrags, der die Eigenschaften der Lieferung behandelt: die prüfbaren Zusagen zur Leistung, die der Erzeuger über die Daten macht.

In der Praxis:

• Ein Data Contract enthält typischerweise ein oder mehrere SLAs als eingebettete Klauseln.
• Ein Data SLA kann auch für sich allein stehen, bei Produkten ohne vollständigen Vertrag, etwa wenn ein internes Team sich für ein geteiltes Dashboard auf eine Frequenz der Auffrischung festlegt.
• Beides sollte versioniert, unterzeichnet und neben den übrigen Metadaten des Data Product im Katalog abgelegt werden.

Die Trennlinie verläuft entlang von Folge und Förmlichkeit. Ein Vertrag begründet Pflichten und Rechte für beide Seiten; ein SLA begründet messbare Zusagen, an denen der Erzeuger gemessen wird. Reife Organisationen bauen SLAs in Verträge ein, damit sich beide gemeinsam bewegen.

SLI, SLO und SLA im Datenkontext

Aus dem SRE (Site Reliability Engineering) übernommen und im Data Engineering zunehmend genutzt, klärt die Dreiheit aus SLI, SLO und SLA, wofür jede Messung da ist.

• SLI (Service Level Indicator): der tatsächlich gemessene Wert. „Heute wurde die Tabelle der Kunden 3 Stunden und 12 Minuten nach dem Stichzeitpunkt der Quelle aufgefrischt.“ SLIs kommen unmittelbar aus der Überwachung.
• SLO (Service Level Objective): das interne Ziel, auf das das Team hinarbeitet. „Wir wollen innerhalb von 3 Stunden nach dem Stichzeitpunkt der Quelle auffrischen.“ SLOs sind enger gesetzt als SLAs, damit Schwankungen Raum haben, ohne die äußere Zusage zu verletzen.
• SLA (Service Level Agreement): die Zusage nach außen an die Data Consumer, oft mit Folgen verbunden. „Wir sagen zu, an Geschäftstagen innerhalb von 4 Stunden nach dem Stichzeitpunkt der Quelle aufzufrischen.“ Die Data Consumer planen ihre nachgelagerte Arbeit um das SLA herum.

Das Verhältnis ist hierarchisch. Das SLI misst die Wirklichkeit. Das SLO ist das interne Ziel. Das SLA ist die nach außen versprochene Untergrenze, typischerweise eine Lockerung des SLO, um betriebliche Schwankungen aufzufangen. Reife Teams im Data Engineering instrumentieren das SLI, führen das Team am SLO und schützen das SLA als harten Vertrag mit den Data Consumern.

Error Budgets

Die Praxis des SRE führt den Begriff des Error Budget ein: das Maß an Verletzung des SLO, das dem Team „zusteht“, bevor die Arbeit an der Behebung Vorrang vor neuen Funktionen bekommt. Lautet das SLO „99,5 % Aktualität“, ist das Error Budget 0,5 % der Messfenster, in denen die Aktualität ausfallen darf. Wird das Budget zu schnell verbraucht (mehrere Vorfälle in einer Woche), wechselt das Team vom Liefern neuer Pipelines zum Stabilisieren der bestehenden. Das Error Budget ist ein selbstregelnder Mechanismus, der beides verhindert: den Perfektionismus (mehr in Verlässlichkeit zu investieren, als die Data Consumer brauchen) und die Trägheit (die Verlässlichkeit still abgleiten zu lassen).

Data SLAs festlegen und betreiben

Die praktische Arbeit mit Data SLAs verläuft in fünf Schritten.

1. Mit den Data Consumern verhandeln. Einseitig auferlegte SLAs sind entweder zu locker (die Data Consumer können sich nicht darauf verlassen) oder zu eng (die Erzeuger halten sie nicht durch). Wählen Sie die Dimensionen, die dem Data Consumer wichtig sind, setzen Sie Ziele, die zu seiner nachgelagerten Toleranz passen, und halten Sie die Vereinbarung fest.
2. Die Daten instrumentieren. Jede Dimension braucht eine automatische Messung. Prüfungen der Aktualität vergleichen Zeitstempel, Prüfungen der Vollständigkeit vergleichen Zeilenzahlen, Prüfungen der Genauigkeit fahren Abgleichsabfragen. Werkzeuge wie Monte Carlo, Soda, dbt tests und eigene Monitore gehören hierher. Der Katalog zeigt die aktuellen Werte der SLIs neben der jeweiligen Dimension.
3. Die Ziele des SLO enger setzen als die des SLA. Sagt das SLA „4 Stunden“, setzen Sie das SLO auf „3 Stunden“. Das ist nicht willkürlich: Es gibt dem Team den Vorlauf, ein Abdriften zu erkennen und darauf zu reagieren, bevor daraus eine Verletzung wird.
4. Die Reaktion auf eine Verletzung festlegen. Was geschieht, wenn ein SLA verfehlt wird? Wohin laufen die Alarme, wie wird die Statusseite aktualisiert, in welchem Zeitrahmen läuft die Ursachenanalyse, und an wen wird die Behebung zurückgemeldet? Das Runbook sollte vor der ersten Verletzung bestehen.
5. Regelmäßig überprüfen. SLAs verfallen, wenn sie nicht überprüft werden. Die Bedürfnisse der Data Consumer ändern sich, die Infrastruktur wird besser, und die Ziele müssen nachgezogen werden. Eine vierteljährliche Überprüfung, mit den Data Consumern im Raum, hält das SLA an der Wirklichkeit.

Data SLAs und Governance

SLAs sind Artefakte der Governance. Sie sind Teil des Vertrags zwischen Erzeuger und Data Consumer, sie liegen im Datenkatalog neben den übrigen Metadaten des Produkts, und sie erzeugen Nachweise, nämlich die SLA-Compliance über die Zeit, die Prüfer und Aufsicht abfragen.

• Einbindung in den Katalog. Jedes Data Product im Katalog zeigt seine aktuellen SLA-Dimensionen, die aktuellen Werte der SLIs und die jüngste Compliance. Die Data Consumer sehen das SLA, wenn sie das Produkt bewerten, und nicht erst, wenn sie sich beschweren.
• Verantwortung. Jedes SLA hat einen benannten Data Owner, der dafür geradesteht. SLAs ohne Owner sind Absichtserklärungen; SLAs mit Owner sind Zusagen.
• Prüfpfad. Die historische SLA-Compliance ist in manchen Zusammenhängen selbst ein reguliertes Artefakt. Die Anforderung von BCBS 239 an die Zeittreue von Risikodaten ist im Betrieb nichts anderes als ein Programm für SLAs. Die Fristen von DORA für die Meldung von Vorfällen sind SLAs, die die Aufsicht dem beaufsichtigten Unternehmen auferlegt.
• SLAs nach Wirkung stufen. Nicht jedes Produkt braucht strenge SLAs. Produkte der Stufe 1 (geschäftskritisch, reguliert) bekommen enge SLAs mit einer förmlichen Reaktion auf Vorfälle. Produkte der Stufe 3 (experimentell, geringe Wirkung) dürfen lockerere Ziele oder gar kein veröffentlichtes SLA haben. Die Disziplin liegt darin, das SLA am tatsächlichen Bedarf des Data Consumer auszurichten.

Fazit

Data SLAs sind der Mechanismus, der Data Products von „verfügbar“ zu „verlässlich genug, um darauf zu bauen“ bringt. Der Wechsel von der informellen Lieferung nach bestem Bemühen zu veröffentlichten, gemessenen und gesteuerten SLAs ist einer der prägenden Reifeschritte jeder Datenorganisation. Die technischen Teile, also Überwachung, Alarmierung und die Instrumentierung der SLIs, sind lösbar. Die schwerere Arbeit ist die Disziplin: SLAs ehrlich mit den Data Consumern zu verhandeln, sie auf das Maß zuzuschneiden, das das Team durchhält, die Reaktion auf eine Verletzung zu verantworten und sie regelmäßig zu überprüfen. Teams, die das tun, machen aus Daten Infrastruktur. Teams, die es nicht tun, erfahren im Kontakt mit dem Data Consumer immer wieder, dass ihre Daten eben keine Infrastruktur waren.