Ein SLA (Service Level Agreement) ist eine vertragliche Vereinbarung zwischen einem Anbieter und seinen Kunden, die messbare Service-Levels wie 99,95 Prozent monatliche Verfügbarkeit zusagt und regelt, was bei Nichteinhaltung geschieht, meist Service Credits. Es basiert auf SLIs, sollte großzügiger sein als interne SLOs und legt Messung, Ausnahmen und Ansprüche fest.
Was ist ein SLA?
Ein SLA (Service Level Agreement) ist eine formelle Zusage eines Anbieters an seine Kunden über die zu erwartende Servicequalität. Typische SLAs garantieren eine Mindestverfügbarkeit pro Monat, manchmal auch Reaktionszeiten im Support oder maximale Latenzen, und sie legen eine Kompensation fest, falls der Anbieter das Ziel verfehlt. In Cloud- und SaaS-Verträgen ist das meist eine Service-Gutschrift (Service Credit): ein Prozentsatz der Monatsgebühr, der dem Kunden gutgeschrieben wird.
Ein SLA ist in erster Linie ein geschäftliches und rechtliches Dokument. Es beantwortet die Frage: Was hat der Anbieter zugesagt, wie wird gemessen, und was erhält der Kunde, wenn die Zusage gebrochen wird?
SLA vs. SLO vs. SLI
Die drei Begriffe bauen aufeinander auf und werden oft verwechselt:
| Begriff | Bedeutung | Beispiel | Zielgruppe |
|---|---|---|---|
| SLI (Service Level Indicator) | Eine Messgröße für das Verhalten eines Services | Anteil erfolgreicher HTTP-Requests pro Minute | Engineering |
| SLO (Service Level Objective) | Ein internes Ziel für einen SLI über ein Zeitfenster | 99,95 % erfolgreiche Requests über 28 Tage | Engineering und Produkt |
| SLA (Service Level Agreement) | Eine vertragliche Zusage mit Konsequenzen | 99,9 % monatliche Verfügbarkeit, sonst Service Credit | Kunden, Recht, Vertrieb |
Die Faustregel: Das SLO ist strenger als das SLA. Liegt Ihr internes Ziel bei 99,95 Prozent und der Vertrag sagt 99,9 Prozent zu, bleibt dem Engineering durch Error Budgets und Alarme auf die Burn Rate Spielraum, Probleme zu erkennen und zu beheben, bevor ein Vertragsbruch entsteht.
Was Verfügbarkeitswerte bedeuten
Verfügbarkeitsziele lassen sich in erlaubte Ausfallzeit übersetzen. Für einen Monat mit 30 Tagen:
| Verfügbarkeit | Ausfallzeit pro 30-Tage-Monat | Ausfallzeit pro Jahr |
|---|---|---|
| 99 % | ca. 7,2 Stunden | ca. 3,65 Tage |
| 99,9 % | ca. 43 Minuten | ca. 8,8 Stunden |
| 99,95 % | ca. 22 Minuten | ca. 4,4 Stunden |
| 99,99 % | ca. 4,3 Minuten | ca. 53 Minuten |
Jede zusätzliche Neun kostet deutlich mehr Engineering-Aufwand. Denken Sie außerdem an die zusammengesetzte Verfügbarkeit: Ein Service, der seriell von drei Komponenten mit je 99,9 Prozent abhängt, erreicht ohne Redundanz bestenfalls etwa 99,7 Prozent.
Was ein gutes SLA enthält
- Geltungsbereich: welche Services, Regionen und Tarife das SLA abdeckt.
- Definition von Verfügbarkeit: was als nicht verfügbar gilt, etwa eine Fehlerrate über einem Schwellwert für eine Minute, gemessen durch das Monitoring des Anbieters.
- Messzeitraum: in der Regel ein Kalendermonat.
- Ausnahmen: geplante Wartung, höhere Gewalt, vom Kunden oder von Drittanbietern verursachte Probleme.
- Service Credits: eine gestaffelte Tabelle, beispielhaft 10 Prozent der Monatsgebühr unterhalb des Ziels und 25 Prozent unterhalb einer niedrigeren Schwelle, oft mit Obergrenze.
- Anspruchsverfahren: wie und innerhalb welcher Frist der Kunde Gutschriften beantragen muss. Häufig werden sie nicht automatisch gewährt.
Ein SLA als Anbieter festlegen
- Von gemessenen Werten ausgehen. Prüfen Sie, welche Verfügbarkeit Ihr Service in den letzten sechs bis zwölf Monaten tatsächlich erreicht hat, gemessen mit kundennahen SLIs.
- Zuerst das interne SLO festlegen. Wählen Sie ein Ziel, das das Team dauerhaft halten und mit einer Error-Budget-Policy absichern kann.
- Puffer einplanen. Setzen Sie das vertragliche SLA unter das SLO, damit eine schlechte Woche nicht sofort Geld kostet.
- Abhängigkeiten einrechnen. Cloud-Regionen, DNS, CDNs und Dritt-APIs haben eigene SLAs. Ihre Zusage kann sinnvollerweise nicht über dem liegen, was Ihr kritischer Pfad leisten kann.
- Präzise Definitionen schreiben. Klären Sie mit der Rechtsabteilung, was als Ausfallzeit gilt, wie gemessen wird und welche Ereignisse ausgenommen sind, bevor der erste Incident die Formulierung auf die Probe stellt.
Ein SLA überwachen
Als Kunde brauchen Sie unabhängige Belege: synthetische Checks von mehreren Standorten gegen die Endpunkte des Anbieters sowie die Fehlerrate und Latenz, die Ihre eigenen Services beim Aufruf sehen. Als Anbieter sollten Sie das SLA mit SLIs hinterlegen, die das Kundenerlebnis messen, nicht nur interne Health Checks. In beiden Fällen gilt: Bewahren Sie die Rohdaten lange genug auf, um einen Anspruch oder ein Audit zu belegen, und dokumentieren Sie jede Verletzung mit Zeitachse und Postmortem.
Typische Fehler
- Das SLA gleich dem SLO setzen. Dann bleibt kein Puffer vor einem Vertragsbruch.
- Verfügbarkeit für Komponenten zusagen, die Sie nicht kontrollieren, ohne Abhängigkeiten einzurechnen.
- Unklare Definitionen von Ausfallzeit, die zu Streit darüber führen, ob eine Verletzung vorlag.
- Service Credits als Ersatz für Geschäftsschäden verstehen. Gutschriften sind meist gering und oft die einzige vereinbarte Kompensation. Prüfen Sie Haftungsregeln mit Ihrer Rechtsabteilung.
Wie Obseria hilft
Für Obseria selbst gilt ein SLA von 99,95 Prozent. In der Plattform definieren Sie SLIs und SLOs auf beliebigen Signalen, verfolgen Error Budgets und Burn Rate, führen synthetische Checks von über 50 Standorten aus und veröffentlichen Statusseiten, damit Ihre Kunden dieselben Verfügbarkeitsdaten sehen, die Sie Ihren eigenen SLAs zugrunde legen.