Eine 11-Punkte-Checkliste für die Festlegung und Einhaltung von Daten-SLAs (mit einer SLA-Vorlage)

Wir wagen die Behauptung, dass kein Team zu klein ist, um ein Daten-Service-Level-Agreement (SLA) auszuarbeiten und sich dazu zu verpflichten. Was ist ein Daten-SLA? Es ist ein öffentliches Versprechen, ein quantifizierbares Maß an Service bereitzustellen. Genauso wie sich Ihre IaaS-Anbieter (Infrastruktur-as-a-Service zu einer Betriebszeit von 99,99 % verpflichten, verpflichten Sie sich, Daten in einer bestimmten Qualität und innerhalb bestimmter Parameter bereitzustellen.

Es ist wichtig, dass die Verpflichtung öffentlich ist. (Zumindest innerhalb des Unternehmens.) Öffentlichkeit schafft eine bessere Verantwortlichkeit, hilft Ihnen dabei, alle Teams auf das Wichtigste auszurichten, und ermöglicht es Ihnen, eine Struktur aufzubauen, die die Qualität unterstützt.

In diesem Leitfaden erfahren Sie, wie Sie Ihr eigenes Daten-SLA einrichten können.

Formalisierte, schriftliche Daten-SLAs machen Ihre informellen Verpflichtungen konkret und gegenseitig akzeptabel. Jede Datenbeziehung beinhaltet informelle Verpflichtungen, ob Sie sie angeben oder nicht, und sehr oft können sich zwei Parteien auf etwas einigen, ohne zu merken, dass sie über unterschiedliche Dinge sprechen.

Was genau ist also ein Daten-SLA? Es handelt sich um ein einfaches schriftliches Dokument, in der Regel mit 250 bis 500 Wörtern, das in einem gemeinsam genutzten Bereich wie einem Unternehmenswiki oder Google Doc veröffentlicht wird. Es sollte 6 Elemente enthalten:

• Zweck: Warum gibt es dieses Daten-SLA? Welche Probleme soll es Ihrer Meinung nach lösen, und wie wird es eingesetzt?

• Versprechen: Was versprechen Sie anderen Teams?

• Messung: Wie werden Sie das Daten-SLA messen, wer wird es messen und was ist der SLA-Zeitrahmen?

• Auswirkungen: Was passiert, wenn Sie Ihr Daten-SLA verpassen? Wer ist verantwortlich und welche Sanierungen stehen gegebenenfalls zur Verfügung?

• Anforderungen: Was erwarten Sie als Gegenleistung? Inwiefern sind Ihre Versprechen an Bedingungen geknüpft?

• Unterschriften: Wer verpflichtet sich zum Daten-SLA?

Wenn Sie Ihr Daten-SLA schreiben, sollten Sie es in so wenigen Worten wie möglich ausdrücken, ohne die Bedeutung zu verändern. Das erfordert viel Bearbeitung, aber wir empfehlen, alles in einem Durchgang zu schreiben und später noch einmal zu bearbeiten. Der Grund dafür ist, dass Sie, wenn Sie zu lange auf die Seite starren, das entwickeln könnten, was Schriftsteller „Angst vor dem leeren Blatt“ nennen, und es immer wieder aufschieben. Erstellen Sie jetzt einen Entwurf in schlechter Qualität, anstatt zu warten.

Hier ist ein Beispiel für ein Data Service Level Agreement:

Der Zweck dieses Dokuments ist es, ein öffentliches Versprechen unseres Teams gegenüber anderen abzugeben, eine hohe Datenqualität innerhalb genauer Parameter aufrechtzuerhalten. Wir hoffen, dass dies Verständnis schafft, uns allen hilft, zusammenzuarbeiten, und dazu beiträgt, dass unsere Teams sich gegenseitig zur Rechenschaft zu ziehen.

Unser Versprechen: Wir liefern jeden Tag bis 5:00 Uhr morgens ET Umsatzdaten mit einer Datenqualität von mindestens 95 %, damit das Team Fragen wie „Wie hoch waren die Umsätze gestern?“ beantworten kann. Wir bestätigen alle Anfragen innerhalb eines Werktages und sortieren sie nach einfachen und komplexen Tickets. Wir bearbeiten einfache Anfragen innerhalb von drei Werktagen und komplexe Anfragen innerhalb von zwei Wochen.

Wir messen die Datenqualität durch Vergleich von KPIs der Datenbereitstellung wie Startzeit und Abschlusszeit, Datensatzanzahl und Verhältnis von Null zu Datensatzanzahl sowie Verteilungs- und Drift-Scores mit den vordefinierten Standards für Datenaktualität, Datenvollständigkeit und Datentreue.

Wenn wir ein Daten-SLA verpasst haben, wird unser Team innerhalb von drei Werktagen eine öffentliche Entschuldigung veröffentlichen, in der es erklärt, warum es passiert ist und warum wir genau die Maßnahmen ergreifen, die wir ergreifen, um das Problem zu beheben.

Um dieses Versprechen erfüllen zu können, benötigen wir Ihre Hilfe. Unser Team benötigt rechtzeitig Anweisungen, Input und klares Feedback zur Verwendung der Daten sowie mindestens vier Wochen im Voraus über komplexe angeforderte Änderungen.

Bitte richten Sie alle Fragen, Kommentare und Bedenken an data-eng@team.com.

Mit Entschlossenheit,

– Ihr Data-Engineering-Team

Wenn Ihr SLA steht (oder vielleicht während Sie es bearbeiten), denken Sie darüber nach, was Sie alles einrichten müssen, bevor Sie sich daran halten können.

Einige Beispiele:

Versuchen Sie, so viel Mehrdeutigkeit wie möglich aus diesem Satz herauszuholen. Definieren Sie es konkret und unmissverständlich. Unserer Meinung nach gibt es vier Merkmale, anhand derer Sie qualitativ hochwertige Daten definieren können. Sichern Sie nach der Definition die Zustimmung anderer Teams zu dieser Definition.

Fragen Sie sich selbst:

• Was ist das Ergebnis guter Daten für das Unternehmen?
• Welche einzigartigen Merkmale zeichnen gute Daten aus?
• Welche Merkmale definieren schlechte Daten?

Zum Tracking benötigen Sie ein Observability-Tool, damit Sie tatsächlich wissen, ob Teile Ihrer Pipeline ausgefallen sind. Ohne ein solches ist es ziemlich schwierig, zu messen, ob Sie ein SLA verpassen, geschweige denn die Ursache dafür zu diagnostizieren. Es hilft Ihnen auch, Fehler zu verstehen, sodass Sie Dinge viel schneller beheben können.

Sie können Ihr Daten-SLA wie eine Metrik behandeln – einen zentralen Punkt, an dem sich alle orientieren können. Aber dabei ist natürlich auch eine Menge Komplexität verborgen, und Sie müssen eine Reihe von KPIs verfolgen, um zu wissen, was vor- und nachgelagert passiert.

Hier sind ein paar spezifische Empfehlungen:

1. Legen Sie automatische Tests fest, um die Datenqualität in ihren vier Dimensionen zu überwachen
   • Testen Sie Daten vor der Produktion
   • Test in jeder Phase: Vollständigkeit, Anomalien
2. Messen Sie, wie gut Sie Probleme entdecken, auf sie reagieren und sie angehen
   • Zeit bis zur Entdeckung
   • Zeit bis zur Lösung
   • Vorfälle pro Asset
3. Dokumentieren Sie die unmittelbaren und grundlegenden Ursachen für jedes Problem
   • Der Datenpartner hat eine Lieferung verpasst
   • Auszeit
   • Der Job bleibt in einer Warteschlange hängen
   • Unerwartete Transformation
   • Berechtigungsproblem
   • Laufzeitfehler
   • Änderungen des Zeitplans

Seien Sie vorsichtig, wozu Sie sich verpflichten. Sie können nicht überall sein und auf alles vorbereitet sein, und ein SLA von 99,999 % Betriebszeit bedeutet, dass Sie nur 5 Minuten Ausfallzeit pro Jahr haben dürfen. Um dies zu erreichen, brauchen Sie wahrscheinlich mehr Personal, mehr Transparenz, mehr Entlassungen und Mitarbeiter, die rund um die Uhr arbeiten.

Sie benötigen wahrscheinlich ein Ticketing-Tool wie Jira oder ServiceNow. Auf diese Weise können Datenbenutzer Tickets erstellen, Ihr Team kann sie verfolgen und Sie können die Art dieser Tickets verstehen, so dass Sie langfristige Lösungen finden und Problembereiche identifizieren können.

Möglicherweise möchten Sie es nicht in Ihrem SLA-Dokument für öffentliche Daten angeben, aber die Eigentümer der Datenquelle und der Pipeline definieren. Sie sind diejenigen, die letztendlich dafür verantwortlich sind, wenn etwas schiefgeht. Geben Sie auch an, was passiert, wenn sie in den Urlaub fahren oder das Unternehmen verlassen.

Richten Sie Benachrichtigungen ein, die in Ihrer Team-Messaging-App wie Slack oder einem Vorfallmanagementsystem wie PagerDuty veröffentlicht werden. Je mehr Vorfalldetails Sie in diese Benachrichtigung aufnehmen können, desto schneller können Sie eine Diagnose stellen. Diese Benachrichtigungen können Sie frühzeitig erkennen, wen Sie noch hinzuziehen müssen oder wo Sie mit Ihrer Analyse beginnen sollten. (IBM® Databand kann diese Benachrichtigungen senden und fügt nützliche Erkenntnisse und Kontext hinzu.)

Nehmen wir an, ein Datennutzer teilt Ihnen mit, dass eine Tabelle in seinem Dashboard defekt ist. Wie bestätigen und antworten Sie? Schreiben Sie es so auf, dass im Falle eines Vorfalls nicht das sogenannte Zuschauerproblem auftritt, dass jeder davon ausgeht, dass sich jemand anderes darum kümmert, und dann niemand handelt.

Abhängig von der Größe Ihres Teams und der Verteilung auf der ganzen Welt sollten Sie dies sehr ernst nehmen und einen Notfallkommandanten ernennen, wie es in der Notfallmedizin heißt. Diese Person wird zum CEO des Vorfalls und leitet alle anderen. (Dies gewährleistet eine koordinierte Reaktion und verhindert, dass mehrere Personen dasselbe Problem angehen.)

Wenn Sie die Möglichkeit haben, erstellen Sie Benachrichtigungsfelder auf den Dashboards der Mitarbeiter, damit Sie den Status des Systems mitteilen können. Wenn etwas schief geht, können Sie schreiben: „Wir haben einen Ausfall – hier ist unsere geschätzte Zeit bis zur Lösung.“ Dadurch werden wiederholte Warnungen von allen Ihren Datennutzern verbreitet, und Sie können tatsächlich reagieren.

Wenn Sie keine Benachrichtigungsfelder einrichten können, benennen Sie zumindest eine Schlüsselperson in jedem Team, die Sie informieren können und die dann alle anderen informieren wird.

Beobachten Sie, wie Ihre Datennutzer die Daten nutzen (und ob sie die Daten nutzen). Führen Sie gelegentlich formelle oder informelle Umfragen durch, um das Vertrauen in diese Daten zu messen und um Anregungen zu erhalten. Kommunizieren Sie interessierte Verbraucher, was auf Ihrer Roadmap steht.

Legen Sie regelmäßige Wartungsintervalle fest, in denen Ihr Team prüft, warum etwas nicht funktioniert hat, und überlegt, wie man es beheben kann. Fragen Sie, warum diese Probleme möglich waren, führen Sie eine verschuldensunabhängige Untersuchung durch, dokumentieren Sie Ihre Erkenntnisse, weisen Sie diese Fixes zu und überwachen Sie, wie sie funktionieren.

Wenn all dies geklärt ist, können Sie Ihr Daten-SLA bearbeiten und überarbeiten. Veröffentlichen Sie es öffentlich in Ihrem Unternehmens-Wiki oder an einem gemeinsam genutzten Ort, sichern Sie sich das Engagement aller und halten Sie sich daran.

Daten-SLAs helfen Ihnen, sich und Ihr Team in die Pflicht zu nehmen. Obwohl sie als öffentliches Versprechen an andere formuliert sind, handelt es sich in Wirklichkeit um ein bilaterales Abkommen. Sie erklären sich bereit, Daten innerhalb bestimmter Parameter zur Verfügung zu stellen, aber im Gegenzug benötigen Sie die Beteiligung und das Verständnis der Menschen.

Im Data Engineering kann viel schief gehen, und vieles davon hat mit Fehlkommunikation zu tun. Die Dokumentation Ihres SLA trägt wesentlich dazu bei, alles zu klären, damit Sie Ihr ultimatives Ziel erreichen können: das Vertrauen in die Daten in Ihrem Unternehmen zu stärken.

Erkennen Sie Probleme mit dem Allgemeinzustand der Daten jedes Mal frühzeitig und verlieren Sie keine Kosten mehr durch fehlende SLAs. Erfahren Sie, wie Sie Ihre Techniker mit fortschrittlichen Benachrichtigungen und Anomalieerkennung unterstützen können, um Qualitätsprobleme im Ansatz zu erkennen. Wenn Sie bereit sind, einen genaueren Blick darauf zu werfen, buchen Sie noch heute eine Demo.