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

SLI ist, was Sie messen, SLO Ihr Ziel, SLA die vertragliche Zusage. Erklärung der drei am häufigsten verwechselten Begriffe aus dem Google SRE.

SLI - Service Level Indicator

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

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

Ein guter SLI hat drei Schlüsseleigenschaften:

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

Ein internes Ziel dafür, welchen Wert der SLI erreichen soll. Ausgedrückt in Prozent über ein gewähltes Zeitfenster.

Beispiele:

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

Das SLO ist in der Regel strenger als das SLA, damit Sie einen Puffer haben. Wenn das SLA 99,9 % nennt, sollte das interne SLO z. B. 99,95 % betragen - so bleibt Ihnen Reserve für unerwartete Incidents, bevor Sie den Vertrag verletzen.

SLA - Service Level Agreement

Eine vertragliche Verpflichtung gegenüber Kunden. Es 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

Das SLA hat rechtliche Folgen. Das SLO ist dagegen nur ein internes Ziel.

Error Budget

Ein 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, und 0,1 % von 30 Tagen sind 43 Minuten pro Monat. Das ist Ihr Error Budget.

Praktische Folgen:

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

Praktisches Beispiel: E-Commerce-API

SLI: % der 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: Ein 99,9 % SLO bedeutet 43 Min Downtime pro Monat. Das SLA gibt einen noch größeren Puffer vor einer wirtschaftlichen 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

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

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 eine historische Uptime-Aufzeichnung mit 30/90/365-Tage-Rollup. Eine solide Grundlage für SLO-Reporting.

Monitoring starten →