Wie viele Fehlbestellungen erlaubt ein SLO von 99,5 %, und was bleibt nach der Störung mit 120 Fehlern?

250 Fehlbestellungen erlaubt (0,5 % von 50.000). Nach 120 Fehlern bleiben 130, das Team beobachtet den Verbrauch.

Ein Rollout verbraucht das Error Budget schnell, die nächste riskante Änderung steht an. Was sagt die Policy?

Schneller Verbrauch pausiert riskante Rollouts. Die Kapazität geht in die Stabilisierung, bis die Messung wieder im vereinbarten Verlauf liegt.

Das Team vereinbart ein strengeres SLO als 99,5 %. Was spricht dafür, was dagegen?

Dafür: Das Qualitätsziel für die Bestätigung steigt. Dagegen: Das Error Budget schrumpft, und riskante Rollouts werden früher pausiert. Der Wert muss zur Nutzererwartung und Messqualität passen.

AnsatzKapitel III · Betrieb · Baustein 8 von 10

SLIs, SLOs & Error Budgets

Ein SLI ist eine Messgröße für erlebte Servicequalität. Ein SLO legt dafür ein Ziel über ein definiertes Zeitfenster fest; das Error Budget beschreibt den erlaubten Anteil verfehlter Ereignisse.

Von Michael Meierhoff · Meierhoff Systems

ZielDer Anteil, der gelingen soll.
Error BudgetDer Rest zum Ziel ist die erlaubte Abweichung.
ReaktionEin verbrauchtes Budget ändert, was das Team tut.

Einordnung

Warum das wichtig ist

Ohne messbares Ziel streitet das Team, ob der Shop gut genug läuft und wann Stabilität vor neuen Funktionen geht. SLI, SLO und Error Budget machen diese Entscheidung überprüfbar. Observability und Deployment vertiefen eigene Bausteine.

Dieser Baustein verbindet Messung, Ziel und Handlungsregel. Observability liefert Signale; Deployment und Rollout liefern konkrete Änderungsentscheidungen.

Auf einen Blick · Von der Messung zur Reaktion

Das SLI misst die Qualität, das SLO setzt das Ziel, und der Rest bis zum Ziel ist das Error Budget.

Shop-Beispiel · Stufen durchspielen

Vom Zielwert zum Error Budget

Das Team bewertet erfolgreiche Bestellbestätigungen, die innerhalb von zwei Sekunden im Shop sichtbar werden. Ein Monatsziel und eine Reaktionsregel steuern riskante Änderungen.

So liest du das Bild

Ziel Du wählst den Zielwert, zum Beispiel 99,5 % über 30 Tage.
Error Budget Bei 99,5 % und 50.000 Bestellungen sind 250 Fehlbestellungen erlaubt.
Reaktion Mit Störung färbt sich das Budget; bei Überschreitung pausieren riskante Rollouts.

SLO-Zielwert (Bestätigung ≤ 2 s, 30 Tage): 99,5 %

0,5 %Error Budget (Anteil)
250Erlaubte Fehlbestellungen

Bei 99,5 % über 30 Tage und 50.000 Bestellungen darf der Anteil 0,5 % die Bestätigung in 2 s verfehlen: 250 Bestellungen.

Werte illustrativ

Wähle ein SLO für 30 Tage bei 50.000 Bestellungen im Monat. Schalte die Störung ein und lies Restbudget und Reaktion ab.

Nutzen & Grenzen

Hilft, wenn

Nutzererfolg lässt sich als gültige Ereignisse und messbares Qualitätsziel formulieren.
Produkt und Betrieb erhalten eine gemeinsame Grundlage, um Zuverlässigkeit und geplante Änderungen abzuwägen.

Grenzen

Durchschnittswerte verbergen langsame Randfälle; ergänze Perzentile und prüfe, welche Nutzergruppen im Nenner liegen.
Ein einziges Ziel mischt kritische und optionale Funktionen; definiere getrennte Indikatoren, wenn Folgen oder Toleranzen abweichen.
Das Ziel ist nur so gut wie die Messung dahinter; Observability liefert die Daten, die Reaktionsregel entscheidet über Releases.

In der Praxis

Nutzerrelevante Ereignisse definieren. Beschreibe, was als gültiger Versuch zählt und wann er aus Nutzersicht erfolgreich ist. Lege Messpunkt und Ausschlüsse offen. Das Ergebnis ist ein SLI, dessen Zähler und Nenner verschiedene Teams gleich interpretieren.
Ziel und Budget festlegen. Wähle Zielwert und Zeitfenster passend zur fachlichen Wirkung und geprüften Betriebsdaten. Lege fest, wie Verbrauch berechnet und in unterschiedlichen Fenstern dargestellt wird. Damit werden Zielerreichung und verbleibender Spielraum transparent.
Policy mit Handlungen verbinden. Definiere Verantwortliche, Reaktionen auf schnellen Verbrauch und Kriterien zur Wiederaufnahme regulärer Arbeit. Prüfe die Policy an historischen oder simulierten Messreihen. Das Ergebnis ist ein anwendbarer Entscheidungsrahmen, der Zielwert und konkrete Reaktionen miteinander verbindet.

Ausführliche Erklärung lesen

Ein Service Level Indicator (SLI) definiert Grundgesamtheit, Messpunkt und Regel für gute Ereignisse. Ein Service Level Objective (SLO) setzt dafür einen Zielwert über ein Zeitfenster. Das Error Budget ist der Anteil schlechter Ereignisse, der innerhalb dieses Ziels zulässig bleibt. Seine Verbrauchsrate kann aus den Signalen der Observability abgeleitet werden und konkretisiert zuvor beschriebene Qualitätsattribute.

Zähler, Nenner, Ausschlüsse und Zeitfenster bestimmen die Bedeutung eines SLI. Verschiedene Nutzerfunktionen können deshalb unterschiedliche Ziele benötigen. Eine Policy beschreibt, wie schneller Budgetverbrauch Betrieb, Release oder Fehlerbehebung beeinflusst. Das Error Budget dient als gemeinsamer Entscheidungsrahmen für Betrieb und Releases; repräsentative Messung und nachvollziehbare Regeln bestimmen seine Aussagekraft.

SRE (Site Reliability Engineering) ist der aus dem Betrieb bei Google stammende Ansatz, der SLOs und Error Budgets einsetzt.

Selbst prüfen

Teste dich in drei Stufen

AblesenIm Bild nachsehen
Wie viele Fehlbestellungen erlaubt ein SLO von 99,5 %, und was bleibt nach der Störung mit 120 Fehlern?
Lösung mit Begründung ansehen
250 Fehlbestellungen erlaubt (0,5 % von 50.000). Nach 120 Fehlern bleiben 130, das Team beobachtet den Verbrauch.
AnwendenAuf eine neue Lage übertragen
Ein Rollout verbraucht das Error Budget schnell, die nächste riskante Änderung steht an. Was sagt die Policy?
Lösung mit Begründung ansehen
Schneller Verbrauch pausiert riskante Rollouts. Die Kapazität geht in die Stabilisierung, bis die Messung wieder im vereinbarten Verlauf liegt.
BewertenEine Alternative abwägen
Das Team vereinbart ein strengeres SLO als 99,5 %. Was spricht dafür, was dagegen?
Lösung mit Begründung ansehen
Dafür: Das Qualitätsziel für die Bestätigung steigt. Dagegen: Das Error Budget schrumpft, und riskante Rollouts werden früher pausiert. Der Wert muss zur Nutzererwartung und Messqualität passen.

Vertiefen

Diese Bausteine führen die Gedanken dieser Seite weiter.

Quellen

Weiter im Lernpfad

Als Nächstes in Laufzeit & Betrieb: Deployment & Rollout.

10 Bausteine

Weiter mitDeployment & Rollout