SLI vs SLO vs SLA: Unterschiede und wie man sie setzt

Kurz gesagt: SLI ist was Sie messen, SLO ist welches Ziel Sie erreichen wollen, SLA ist die vertragliche Verpflichtung. Diese Begriffe aus dem Google-SRE-Buch gehören zu den meistgenutzten Phrasen im Betrieb von Webdiensten - und werden oft vermischt.

Kurz gesagt: SLI ist was Sie messen, SLO ist welches Ziel Sie erreichen wollen, SLA ist die vertragliche Verpflichtung. Diese Begriffe aus dem Google-SRE-Buch gehören zu den meistgenutzten Phrasen im Betrieb von Webdiensten - und werden oft vermischt.

SLI - Service Level Indicator

Konkrete Metrik, mit der Sie die Zuverlässigkeit des Dienstes quantifizieren. Beispiele:

% der Requests, die in HTTP 2xx oder 3xx endeten, in den letzten 30 Tagen
% der Requests mit Response Time unter 500 ms
% korrekt zugestellter E-Mails (delivered, nicht bounced)
Verhältnis erfolgreicher Zahlungstransaktionen zu allen Versuchen

Schlüsseleigenschaften eines guten SLI:

Messbar - es gibt eine konkrete Methode der Datenerhebung
Benutzerrelevant - spiegelt die echte Kundenerfahrung wider, keine interne technische Metrik
Spezifisch - „uptime" ist zu vage; „% erfolgreicher Requests an /api/v1/orders in einem 5-Minuten-Fenster" ist ein SLI

SLO - Service Level Objective

Internes Ziel, welchen Wert der SLI erreichen soll. Ausgedrückt in Prozent über ein Zeitfenster.

Beispiele:

„99,9 % der Requests an /api/orders sollen in HTTP 2xx in 30 Tagen enden"
„95 % der Requests sollen Response Time unter 200 ms in 7 Tagen haben"
„99,5 % der Zahlungstransaktionen gehen erfolgreich in einem Kalendermonat durch"

SLO ist höher als SLA, damit Sie einen Puffer haben. Wenn SLA 99,9 % sagt, sollte das interne SLO z. B. 99,95 % sein - damit Sie Reserve für unerwartete Incidents haben.

SLA - Service Level Agreement

Vertragliche Verpflichtung gegenüber Kunden. Definiert was passiert, wenn Sie das SLO nicht einhalten - typisch:

Service Credits - Sie erstatten einen Teil der Monatsgebühr (10-50% je nach Größe des Verstoßes)
Termination Rights - der Kunde kann den Vertrag ohne Sanktion kündigen
Reporting-Pflicht - Sie müssen Postmortem und Uptime-Reports veröffentlichen

SLA hat rechtliche Folgen. SLO ist ein internes Ziel.

Error Budget

Schlüsselkonzept der SRE: Downtime, die Sie sich ohne Verletzung des SLO leisten können.

Beispiel: SLO = 99,9 % Uptime in 30 Tagen. Das sind 0,1 % erlaubter Downtime. 0,1 % von 30 Tagen = 43 Minuten pro Monat. Das ist Ihr Error Budget.

Praktische Folgen:

Wenn Sie 35 Min Downtime im Monat hatten, bleiben 8 Min bis zum „SLO Breach". Das Team sollte bei weiteren Deploys konservativ sein.
Wenn Sie 5 Min Downtime hatten, haben Sie 38 Min Budget für Risiken - Sie können aggressivere Änderungen, A/B-Tests, Experimente machen.
Error Budget löst den Konflikt zwischen Innovationsgeschwindigkeit (Dev-Team) und Stabilität (Ops-Team). Beide verfolgen dieselbe Zahl.

Praktisches Beispiel: E-Commerce-API

SLI: % HTTP-Requests an POST /api/checkout, die in 2xx endeten, gemessen in 1-Minute-Buckets über die letzten 30 Tage.

SLO: ≥ 99,9 % erfolgreiche Requests in einem rollierenden 30-Tage-Fenster.

SLA (für Enterprise-Kunden):

≥ 99,5 % Uptime in einem Kalendermonat
Bei 99,0-99,5 % = 10% Credit der Monatsgebühr
Bei 95,0-99,0 % = 25% Credit
Bei < 95,0 % = 50% Credit + Recht, den Vertrag zu kündigen

Error Budget: 99,9 % SLO bedeutet 43 Min Downtime / Monat im Budget. SLA gibt einen noch größeren Buffer vor wirtschaftlicher Penalisierung.

Zusammenfassung: Tabelle

Begriff	Was es ist	Für wen
SLI	Konkrete Zuverlässigkeitsmetrik	Engineering-Team
SLO	Internes Ziel für SLI	Engineering + Product
SLA	Vertragliche Verpflichtung	Kunde + Legal
Error budget	Downtime, die Sie sich vor SLO-Breach leisten können	Engineering Risk Management

Praktische Fehler

SLO zu ehrgeizig. 99,99 % erfordert Active-Active-Redundanz in mehreren Regionen. Für eine kleine Firma unrealistisch.
Nur Uptime-SLO. Die Website kann „up" sein und trotzdem unbenutzbar. Fügen Sie Latency-SLO und Error-Rate-SLO hinzu.
SLA ohne automatische Messung. Ein manuell berechneter SLA-Report ist nicht vertrauenswürdig. Investieren Sie in automatisches Uptime-Tracking.
SLO ohne Konsequenzen. Wenn ein SLO-Breach niemanden interessiert, kümmert sich niemand darum. Verlinken Sie auf Deploy Freeze, On-Call Escalation, etc.

Fazit

Das SLI/SLO/SLA-Framework ist keine Papier-Bürokratie - es ist die Sprache, mit der das Engineering-Team mit Business-Stakeholdern über Zuverlässigkeit kommuniziert. Ohne diese Begriffe wird die Diskussion über Stabilität subjektiv („unsere Website ist instabil"). Mit ihnen ist sie zahlenbasiert („in den letzten 30 Tagen haben wir 99,87 % SLI erreicht, was unter unserem 99,9 % SLO liegt - hier ist der Aktionsplan").

Messen Sie SLI in Echtzeit

ePulz.io bietet historische Uptime-Aufzeichnung mit 30/90/365-Tage-Rollup. Grundlage für SLO-Reporting.

Monitoring starten →