SLO vs. SLA: der Unterschied, SLIs und Fehlerbudgets

Ein SLA (Service Level Agreement) ist ein Vertrag mit einem Kunden, der festlegt, was passiert, wenn ein Dienst ein zugesagtes Niveau verfehlt, meist eine Gutschrift (Service Credit). Ein SLO (Service Level Objective) ist das interne Ziel, an dem ein Team den Dienst ausrichtet; das SRE-Buch rät, es strenger anzusetzen als das SLA, damit Probleme behoben sind, bevor der Vertrag verletzt wird. Ein SLI (Service Level Indicator) ist die Messgröße, in der beide formuliert sind, etwa der Anteil erfolgreicher Anfragen.

Die Beispiele dienen der Veranschaulichung; die Quellen sind Googles SRE-Buch und SRE-Workbook sowie das AWS-Compute-SLA, geprüft am 1. November 2026.

Wofür stehen SLI, SLO und SLA?

Service Level Indicator, Service Level Objective und Service Level Agreement. Der Indikator ist das, was Sie messen, das Ziel der Wert, den Sie anstreben, und die Vereinbarung das, was Sie jemand anderem zusagen, mit Konsequenzen.

Das Kapitel „Service Level Objectives“ im SRE-Buch definiert ein SLA als „ausdrücklichen oder stillschweigenden Vertrag mit Ihren Nutzern, der Konsequenzen für das Einhalten (oder Verfehlen) der darin enthaltenen SLOs vorsieht“. Der Test des Kapitels ist eine einzige Frage: Was passiert, wenn die SLOs verfehlt werden? Gibt es keine ausdrückliche Konsequenz, haben Sie es fast sicher mit einem SLO zu tun.

Das Kapitel ergänzt, dass die meisten Leute SLO meinen, wenn sie SLA sagen, und dass eine echte SLA-Verletzung als Vertragsbruch vor Gericht enden kann. Wenn eine Besprechung also in einen Streit über SLA vs. SLO kippt, fragen Sie zuerst, ob eine Konsequenz, meist Geld, in einem Vertrag festgeschrieben ist.

Das SRE-Buch rät zu einer Sicherheitsmarge: „Ein strengeres internes SLO als das den Nutzern kommunizierte SLO gibt Ihnen Raum, auf chronische Probleme zu reagieren, bevor sie nach außen sichtbar werden.“ Sein Kapitel „Embracing Risk“ wendet denselben Gedanken auf einen Vertrag an: ein externes Ziel von 99,9 %, abgesichert durch ein strengeres internes.

Was ist ein Fehlerbudget?

Es ist 100 % minus das SLO: der Anteil der Anfragen oder der Zeit, der im Zeitfenster fehlschlagen darf. Solange Budget übrig ist, liefert das Team weiter aus; ist es verbraucht, hat Zuverlässigkeitsarbeit Vorrang.

Das Kapitel „Implementing SLOs“ im SRE-Workbook rechnet es vor: Bei einem SLO von 99,9 % darf ein Dienst, der in vier Wochen 3 Millionen Anfragen erhält, bei 3.000 davon scheitern; ein einzelner Ausfall mit 1.500 Fehlern verbraucht also das halbe Budget. Das Kapitel „Embracing Risk“ des Buchs erklärt den Zweck: Das Produktmanagement legt das SLO fest, das Monitoring misst die tatsächliche Uptime, und die Differenz ist die Unzuverlässigkeit, die für das Quartal bleibt. Ist dieses Budget aufgebraucht, werden Releases gestoppt oder verlangsamt.

Wie viel Ausfallzeit erlaubt 99,9 %?

Etwa 43 Minuten in einem Zeitfenster von 30 Tagen. Jede weitere Neun teilt den Spielraum durch zehn, 99,99 % lassen also knapp über 4 Minuten.

Multiplizieren Sie die 43.200 Minuten eines 30-Tage-Fensters mit dem Fehlerbudget. Beachten Sie die Warnung des Workbooks: Jede weitere Neun kostet mehr, während ihr Nutzen für die Anwender gegen null geht.

Wie sieht ein echtes SLA aus?

Es nennt einen gemessenen Prozentsatz, einen Abrechnungszeitraum, eine Staffel für Gutschriften und das, was nicht zählt. Das AWS-Compute-SLA ist ein kurzes öffentliches Beispiel.

Das Amazon Compute Service Level Agreement (zuletzt aktualisiert am 25. Mai 2022; geprüft am 1. November 2026) sagt eine Monthly Uptime Percentage von mindestens 99,99 % pro Region für EC2-Instanzen zu, die über zwei oder mehr Availability Zones verteilt sind, und 99,5 % für eine einzelne Instanz. Die Uptime ist 100 % minus der Anteil der Minuten, in denen EC2 nicht verfügbar war. Nach dem Region-Level SLA beträgt die Gutschrift unter 99,99 % 10 % der EC2-Monatsrechnung in der Region, unter 99,0 % 30 % und unter 95,0 % 100 %; bei einer einzelnen Instanz beginnt die 10-%-Stufe unter 99,5 %. Gutschriften werden mit künftigen Zahlungen verrechnet, müssen über den AWS Support beantragt werden und sind der „einzige und ausschließliche“ Rechtsbehelf, sofern die Kundenvereinbarung nichts anderes vorsieht.

Verglichen mit der Ausfalltabelle reicht die 10-%-Stufe des Region-Level SLA von etwa 4 Minuten bis 7 Stunden Nichtverfügbarkeit in einem 30-Tage-Monat. Ein SLA begrenzt, was der Anbieter schuldet; Ausfälle von Ihren Nutzern fernzuhalten, ist die Aufgabe Ihrer eigenen Ziele.

Wie wählt man SLIs für Latenz und Verfügbarkeit?

Messen Sie die Latenz als Perzentil und die Verfügbarkeit als gute Ereignisse geteilt durch alle Ereignisse, so nah am Nutzer wie möglich. Durchschnitte und reine Serverwerte verbergen die Anfragen, über die sich Leute beschweren.

Latenz. Das SRE-Buch zieht Perzentile dem Mittelwert vor, weil ein Durchschnitt flach bleiben kann, während die langsamsten Anfragen deutlich langsamer werden. Das Workbook schreibt Latenz-SLIs als Verhältnis, etwa Aufrufe unter 100 ms geteilt durch alle Aufrufe. „99 % der Checkout-Aufrufe unter 400 ms“ heißt also über das Zeitfenster dasselbe wie „p99 des Checkouts unter 400 ms“ und lässt sich direkt in einen Test übernehmen. Unser Artikel zur Tail-Latenz erklärt, warum p99 zählt, sobald eine Seite mehrere Dienste aufruft.

Verfügbarkeit. Zeitbasierte Verfügbarkeit zählt Minuten mit Uptime, wie das AWS-SLA. Anfragebasierte Verfügbarkeit zählt erfolgreiche Anfragen: „Embracing Risk“ beschreibt einen Dienst mit 2,5 Millionen Anfragen am Tag und einem Tagesziel von 99,99 %, der 250 Fehler liefern darf und das Ziel trotzdem erreicht.

Wo gehen SLOs schief?

Meist an zu vielen Zielen, an Zielen von 100 % und an Indikatoren, die dort messen, wo die Nutzer nicht sind. Jeder dieser Fehler ergibt eine Zahl, nach der niemand handelt, oder eine, die gut aussieht, während die Nutzer leiden.

• Zu viele SLOs. Das SRE-Buch rät zu so wenigen wie möglich: Wenn sich mit einem SLO nie eine Diskussion über Prioritäten gewinnen lässt, lohnt es sich wahrscheinlich nicht.
• Ziele von 100 %. Das Workbook nennt 100 % das falsche Ziel: Komponenten fallen aus, Änderungen sind die Hauptursache von Ausfällen, und ein SLO von 100 % lässt nur Zeit zum Reagieren.
• Nur am Server messen. Servermetriken übersehen Probleme, die Nutzer spüren, etwa ein langsames Skript in der Seite. Das Workbook empfiehlt, am Load Balancer oder beim Client zu messen.

Was hat Lasttesten mit SLOs zu tun?

Ein SLO liefert einem Lasttest seine Pass/Fail-Kriterien, und ein Test bei der erwarteten Spitzenlast zeigt, ob das Latenz-SLO hält, bevor dieser Verkehr eintrifft. Das Monitoring in Produktion sagt es Ihnen erst hinterher.

Das SRE-Buch stellt fest, dass mehr Anfragen pro Sekunde (QPS) oft zu höheren Latenzen führen und Dienste jenseits einer bestimmten Lastschwelle häufig eine Leistungsklippe haben. Ein Lasttest kann diese Klippe finden, wenn er bei der erwarteten Spitzenlast mit einem realistischen Anfragemix läuft und denselben SLI misst, den das SLO nutzt. Setzen Sie jeden Schwellenwert im Test etwas strenger als das SLO, wie unser Leitfaden zu Pass/Fail-Kriterien für Lasttests beschreibt. Ein Lauf dauert Minuten und kann daher keine monatliche Verfügbarkeit messen.

LoadFocus, der Herausgeber dieser Website, bewertet Lasttests anhand von Pass/Fail-Schwellenwerten, die am Test gespeichert sind: Max P95 und Max P99 der Antwortzeit, eine maximale Fehlerrate und ein Mindestdurchsatz, für Cloud-, JMeter- und k6-Tests. Sein API-Monitoring bietet SLA-/SLO-Berichte, die pro Monitor ein SLO-Ziel festlegen und Uptime, verbrauchtes Fehlerbudget und einen Status OK oder Breached zeigen.

FAQ

Wofür steht SLO? Service Level Objective: ein Zielwert für ein gemessenes Serviceniveau, etwa 99,9 % erfolgreiche Anfragen über vier Wochen. Es wird intern festgelegt, von Produkt und Engineering, und zieht für sich allein keine vertragliche Strafe nach sich.

Kann man ein SLO ohne SLA haben? Ja. Das SRE-Buch nennt die Google-Suche als wichtigen Dienst ohne öffentliches SLA, der trotzdem mit SLIs und SLOs gesteuert wird.

Sollte ein SLO jemals 100 % betragen? Nein. Ein Ziel von 100 % lässt kein Fehlerbudget übrig, jeder Fehler verletzt es also, und keine Änderung lässt sich je gefahrlos ausliefern.

Weiterlesen

• Pass/Fail-Kriterien für Lasttests: so legen Sie sie fest
• Tail-Latenz: was sie ist und wie man sie misst
• Apdex-Score: was er bedeutet und wie man ihn berechnet
• Durchsatz vs. Latenz: wie sie unter Last zusammenhängen

Die technischen Aussagen in diesem Artikel wurden nicht unabhängig geprüft.