Wie zuverlässig muss ein Dienst sein? Diese Frage klingt einfach, ist aber in der Praxis schwieriger zu beantworten als es scheint. Zu hohe Zuverlässigkeitsziele bremsen Entwicklung aus, weil jede Änderung als Risiko gilt. Zu niedrige kosten Vertrauen und Kunden. Service Level Objectives und Error Budgets sind die Werkzeuge, mit denen Teams diese Balance bewusst steuern – nicht nach Gefühl, sondern nach Daten.
Was ist ein Service Level Objective?
Ein Service Level Objective ist ein vereinbarter Zielwert für die Qualität eines Dienstes über einen bestimmten Zeitraum. Typische SLOs definieren Verfügbarkeit (etwa 99,9 Prozent über 30 Tage), Latenz (95 Prozent aller Anfragen unter 300 Millisekunden) oder Fehlerrate (weniger als 0,1 Prozent HTTP-5xx-Antworten). Das Entscheidende am SLO ist, dass es eine interne Vereinbarung ist – kein öffentliches Versprechen, sondern ein Steuerungsziel.
SLOs werden nicht willkürlich festgelegt. Gute SLOs basieren auf historischen Betriebsdaten und orientieren sich an dem, was Nutzer tatsächlich als ausreichend empfinden. Ein Dienst, der historisch 99,95 Prozent Verfügbarkeit hatte, sollte kein SLO von 99,999 Prozent bekommen – das wäre unrealistisch und würde jede Weiterentwicklung blockieren. Ein realistisches SLO liegt leicht unter dem historischen Bestwert und lässt Spielraum für normale Betriebsschwankungen.
SLI, SLO und SLA im Vergleich
Diese drei Abkürzungen werden häufig verwechselt, beschreiben aber klar verschiedene Dinge. Der Service Level Indicator ist die tatsächlich gemessene Kennzahl – etwa die gemessene Verfügbarkeit der letzten 30 Tage in Prozent. Das Service Level Objective ist der interne Zielwert – mindestens 99,9 Prozent Verfügbarkeit. Das Service Level Agreement ist die externe, vertragliche Zusage gegenüber Kunden – etwa 99,5 Prozent mit definierten Ausgleichsleistungen bei Unterschreitung.
Die Hierarchie ist bewusst so angelegt, dass Puffer existieren. Der SLA ist konservativer als das SLO. Das SLO ist konservativer als der historische Bestwert des SLI. So entsteht ein mehrstufiges Sicherheitsnetz: Selbst wenn das interne Ziel knapp verfehlt wird, muss noch kein Kundenversprechen gebrochen werden.
Das Error Budget verstehen
Das Error Budget ist die zulässige Abweichung vom SLO – also der Raum für Ausfälle, den ein Dienst über einen Messzeitraum hat, ohne das Ziel zu verfehlen. Bei einem SLO von 99,9 Prozent Verfügbarkeit über 30 Tage ergibt sich ein Error Budget von 0,1 Prozent – das entspricht etwa 43 Minuten Ausfallzeit pro Monat.
Dieses Budget kann durch echte Ausfälle verbraucht werden, aber auch durch geplante Wartungsarbeiten, riskante Deployments oder Chaos-Engineering-Experimente. Das Budget ist nicht verschwendet, wenn es sinnvoll eingesetzt wird. Ein Team, das sein Error Budget für ein kritisches, riskantes Feature-Deployment nutzt, trifft eine bewusste Entscheidung. Ein Team, das sein Budget durch wiederholbare, behebbare Fehler aufbraucht, hat ein systemisches Problem.
Error Budget als Steuerungsinstrument
Das Geniale am Error Budget ist, dass es eine gemeinsame Sprache zwischen Entwicklungs- und Betriebsteams schafft. Anstatt subjektiver Diskussionen über Risiko und Stabilität gibt es eine objektive Antwort: Wie viel Budget ist noch übrig? Ist Budget vorhanden, können neue Features ausgerollt werden. Ist das Budget aufgebraucht, pausieren Deployments, bis neues Budget entsteht.
Diese Regel klingt streng, hat aber einen wichtigen Effekt: Sie gibt Entwicklern einen Anreiz, selbst in die Zuverlässigkeit zu investieren. Wenn Deployments ausfallbedingtes Budget verbrauchen, entsteht ein direkter Anreiz, stabileren Code zu schreiben, Tests zu verbessern und Rollback-Strategien zu planen. Zuverlässigkeit wird dadurch zur gemeinsamen Verantwortung beider Teams.
Praktische Einführung Schritt für Schritt
Teams, die SLOs einführen möchten, müssen nicht alles auf einmal angehen. Ein pragmatischer Einstieg funktioniert so: Im ersten Schritt wird für einen kritischen Dienst ein SLI definiert – idealerweise Verfügbarkeit oder Latenz, da beides leicht messbar ist. Im zweiten Schritt werden historische Monitoring-Daten ausgewertet: Wie war die Verfügbarkeit in den vergangenen 30 und 90 Tagen?
Im dritten Schritt wird ein realistisches SLO festgelegt – leicht unterhalb des historischen Durchschnittswerts. Im vierten Schritt wird das Error Budget berechnet und in einem Dashboard visualisiert, sodass alle Beteiligten den aktuellen Verbrauch im Blick haben. Im fünften Schritt wird ein Review-Zyklus eingeführt: Mindestens einmal pro Quartal werden SLOs und Budgetverbrauch gemeinsam bewertet und angepasst.
Monitoring als Datengrundlage
SLOs lassen sich nur sinnvoll einsetzen, wenn verlässliche Messdaten vorliegen. Das bedeutet: Monitoring muss vor dem SLO existieren, nicht danach. Externe Monitoring-Tools überprüfen Dienste von außen und erfassen, was Nutzer tatsächlich erleben – unabhängig davon, was interne Systeme melden. Ein HTTP-Monitor, der alle 60 Sekunden Status, Latenz und Antwortinhalt aufzeichnet, liefert genau die Datenbasis, die für einen Verfügbarkeits-SLI benötigt wird. Statusseiten, die auf diesen Daten aufbauen, kommunizieren Vorfälle transparent gegenüber Nutzern.
Häufige Anfangsfehler und wie man sie vermeidet
Teams, die SLOs einführen, begegnen regelmäßig ähnlichen Anfangsfehlern. Das SLO wird zu ambitioniert gesetzt – 99,999 Prozent klingt professionell, ist aber für die meisten Dienste schlicht unerreichbar und lähmt die Entwicklung vollständig. Zu viele SLOs werden parallel eingeführt – besser mit einem oder zwei kritischen Diensten beginnen und dann schrittweise erweitern. SLOs werden ohne Konsequenzen definiert – wenn eine Verletzung keine Reaktion auslöst, ist das SLO wertlos. Und SLOs werden nie überprüft – Dienste und Anforderungen ändern sich, und SLOs müssen diese Entwicklung widerspiegeln.
Fazit
SLOs und Error Budgets verwandeln die abstrakte Forderung nach Zuverlässigkeit in messbare, steuerbare Ziele. Sie geben Teams eine gemeinsame Sprache, objektive Entscheidungsgrundlagen und die Freiheit, innerhalb klar definierter Grenzen zu handeln. Der Start erfordert Disziplin und realistische Erwartungen. Wer den Einstieg schafft und die Konzepte konsequent anwendet, wird schnell merken: Es gibt kaum ein wirksameres Werkzeug zur Verbesserung der Systemzuverlässigkeit. Wichtig ist dabei auch der kulturelle Aspekt: SLOs funktionieren nur, wenn beide Seiten – Entwicklung und Betrieb – sie als gemeinsames Steuerungsinstrument akzeptieren und nicht als Bedrohung empfinden. Der Dialog darüber, welche Verfügbarkeitsziele realistisch und notwendig sind, ist oft wertvoller als das SLO selbst.
