Was ist ein SLO? Die Zahl, die deine Entscheidungen lenkt

Was ist ein SLO? Eine Zahl, die du dir selbst versprichst: wie oft dein Service funktionieren soll, gemessen über ein festes Zeitfenster. "99.9% der Anfragen sind über 30 Tage erfolgreich" ist ein SLO. Er macht aus "die Seite fühlt sich okay an" etwas, das du nachprüfen kannst, und er sagt dir, wann du aufhören solltest, Features auszuliefern, und stattdessen Dinge reparierst.

Du brauchst dafür kein Platform-Team. Ein Solo-Dev mit einer API und einer Postgres-Datenbank kann an einem Nachmittag einen brauchbaren SLO schreiben. Hier erkläre ich, was der Begriff bedeutet, wie du die Zahl wählst und wo es schiefgeht.

Stell dir ein Side Project mit 400 wöchentlichen Nutzern vor. Eines Nachts liefert der Checkout-Endpoint ungefähr 20 Minuten lang 500er-Fehler. Niemand twittert, niemand schreibt eine Mail. Du erfährst es drei Tage später durch eine einzige Support-Nachricht.

War das schlimm? Ohne Ziel kannst du das nicht beantworten. Mit Ziel schon: Wenn dein SLO ungefähr 43 Minuten Ausfall im Monat erlaubt und du gerade 20 davon verbraucht hast, weißt du, dass du in einer einzigen schlechten Nacht fast die Hälfte deines Kontingents aufgebraucht hast. Genau dafür ist ein SLO da. Er ersetzt ein Gefühl durch ein Budget.

Die drei Abkürzungen, ohne Lehrbuchton

SLI, SLO und SLA werden ständig verwechselt, deshalb hier die Kurzfassung.

Ein SLI (Service Level Indicator) ist eine Messung. "Anteil der HTTP-Anfragen mit einem Status ungleich 5xx in den letzten 30 Tagen" ist ein SLI. Es ist ein Verhältnis aus guten Ereignissen zu allen Ereignissen.

Ein SLO (Service Level Objective) ist das Ziel für diese Messung. "Dieses Verhältnis muss mindestens bei 99.9% bleiben" ist der SLO. Er ist intern. Du setzt ihn, du kannst ihn ändern, und niemand verklagt dich deswegen.

Ein SLA (Service Level Agreement) ist ein Vertrag mit Konsequenzen, meist Rückerstattungen oder Gutschriften. Die meisten Side Projects haben kein SLA, und das ist in Ordnung. SLOs kannst du trotzdem betreiben. Das Kapitel zu SLOs im Google-SRE-Workbook ist die Standardreferenz, wenn du die lange Version willst.

Die Reihenfolge zählt: Erst wählst du den SLI, dann den SLO, und an einen SLA denkst du erst, wenn ein zahlender Kunde ihn schriftlich verlangt.

Fehlerbudgets: der Teil, der deine Arbeitsweise verändert

Ein SLO von 99.9% bedeutet auch, dass 0.1% der Ereignisse fehlschlagen dürfen. Dieser Spielraum ist dein Fehlerbudget, und er ist die nützliche Hälfte der Idee.

In einem Monat mit 30 Tagen erlaubt eine Verfügbarkeit von 99.9% ungefähr 43 Minuten Ausfallzeit. Die Rechnung: 30 Tage mal 24 Stunden mal 60 Minuten ergibt 43,200 Minuten, mal 0.001. Ein Ziel von 99% gibt dir etwa 7.2 Stunden. Ein Ziel von 99.99% gibt dir etwa 4.3 Minuten.

Genau diese letzten beiden Zahlen zeigen, warum kleine Projekte nicht zu hoch zielen sollten. Vier Minuten im Monat bedeuten: Ein schlechtes Deployment und ein Rollback brechen das Ziel schon. In der Praxis passiert dabei Folgendes: Je höher du zielst, desto mehr Zeit geht dafür drauf, die Zahl zu verteidigen, statt das Produkt zu bauen.

Das Budget liefert dir außerdem eine Regel für die nächste Entscheidung. Budget weitgehend intakt: das riskante Feature ausliefern. Budget verbraucht: zuerst das wackelige Teil reparieren. Kein Meeting nötig, nur eine Zahl auf dem Dashboard.

Der Vorteil zeigt sich vor allem, wenn du nicht allein arbeitest. Ist ein Co-Founder oder ein Kunde im Spiel, muss niemand mehr darüber streiten, ob die letzte Woche schlimm war. Die Zahl hat die Diskussion schon beendet, und man kann direkt über das nächste Problem reden.

Einen SLI wählen und die Zahl festlegen

Fang damit an, was ein Nutzer als "kaputt" bezeichnen würde. Bei einer Web-App laufen die Fragen meist auf zwei hinaus: Hat die Anfrage funktioniert, und war sie schnell genug?

Für die meisten Side Projects decken zwei SLIs 90% des Nutzens ab:

• Verfügbarkeit: gute Anfragen geteilt durch alle Anfragen, wobei gut bedeutet: keine 5xx-Antwort.

• Latenz: der Anteil der Anfragen, die unter einem Schwellenwert beantwortet werden, zum Beispiel 95% der Anfragen unter 500 ms.

Latenz schreibt man als Anteil der Anfragen unter einem Schwellenwert, nicht als Durchschnitt. Durchschnitte verstecken den langsamen Rand, und genau dort geben Nutzer auf. Ein Durchschnitt von 300 ms kann über einem p99 von 4 Sekunden liegen. Miss möglichst nah am Nutzer. Ein Health Check, der /healthz aus demselben VPC anpingt, sagt dir, dass der Prozess lebt, nicht dass sich Nutzer einloggen können. Wenn du nur eine Messung hast, prüfe einen echten Nutzerpfad wie Login oder Checkout von außen.

Die ehrliche Antwort für ein neues Projekt lautet 99% oder 99.5%. Schau dir die letzten 30 Tage an, finde heraus, was du tatsächlich geliefert hast, setze den SLO etwas darunter und zieh ihn später nach, wenn sich Nutzer beschweren.

Eine grobe Orientierung für ein Solo-Projekt:

• Hobby-Tool ohne Umsatz: 99% reicht. Ungefähr 7 Stunden Ausfall im Monat fallen den meisten Nutzern nicht auf.

• Bezahltes SaaS mit einigen Dutzend Kunden: 99.5% bis 99.9%, je nachdem, wie zeitkritisch das Produkt ist.

• Alles, worauf Kunden in Geschäftszeiten angewiesen sind: 99.9%, und teste deinen Rollback-Pfad, bevor du ihn versprichst.

Getestet. Nicht optimal. Trotzdem sinnvoll: Ein SLO, den du zu 100% einhältst, ist zu niedrig angesetzt. Ein SLO, den du jeden Monat verfehlst, glaubt niemand. Es ist gut, ihn gelegentlich zu verfehlen, denn dann erfüllt das Budget seinen Zweck.

Ist ein SLO nur Uptime-Monitoring mit Extras?

Nicht ganz, auch wenn sich beides überschneidet. Ein Ping-Monitor sagt dir, dass die Seite in einer bestimmten Minute geantwortet hat. Ein SLO sagt dir, welcher Anteil echter Nutzeranfragen über einen Monat funktioniert hat, und was das für deine nächste Entscheidung bedeutet.

Stell dir zwei Wochen vor, in denen der Ping-Monitor jede Minute grün zeigt, während eine langsame Datenbankabfrage die Dashboard-Seite für 3% der eingeloggten Nutzer in einen Timeout laufen lässt. Der Monitor sagt, alles ist gut. Der SLI sagt, du hast dein Latenzziel verfehlt. Nur eines der beiden ändert, was du am Montag tust.

Behalte den Ping-Monitor trotzdem. Er ist günstig und fängt Totalausfälle schnell ab. Betrachte ihn nur als eine Eingabe, nicht als Definition von "läuft". Der Unterschied wird übrigens nachts deutlich: Der Ping-Monitor weckt dich, wenn alles brennt. Der SLO entscheidet, ob sich das Aufstehen für den Ausreißer überhaupt lohnt.

Du brauchst keinen Anbieter, um anzufangen. Schreib das in dein Repo, in eine Datei namens SLO.md. Lege sie neben den Code, den sie beschreibt. Ändert sich das Ziel, passiert das in derselben Pull Request wie das Feature, und im Review sieht jeder, wenn jemand das Ziel lockert.

service: checkout-api
window: 30d
slis:
  availability:
    good: http_status < 500
    total: alle Anfragen außer /healthz
  latency:
    good: response_time < 500ms
    total: alle Anfragen außer /healthz
objectives:
  availability: 99.5%
  latency: 95%
if_budget_burned:
  - nicht dringende Features einfrieren
  - zuerst die größte Fehlerquelle beheben

Wenn dein Stack Anfragezähler exportiert, ist der Verfügbarkeits-SLI in Prometheus-Syntax eine Zeile:

sum(rate(http_requests_total{status!~"5.."}[30d]))
  / sum(rate(http_requests_total[30d]))

Das Verhältnis, verglichen mit deinem Ziel, ist dein ganzes SLO-Dashboard. Alles andere ist Politur. Drei Panels reichen: aktueller SLI, verbleibendes Budget und eine Burn-Rate-Linie.

Alarme auf Burn Rate statt auf jeden Ausreißer

Der Fehler, den fast alle machen: Alarm schlagen, sobald die Fehlerrate eine Schwelle überschreitet. Du wirst um 3 Uhr nachts geweckt wegen eines 90-Sekunden-Spikes, der 0.2% des Monatsbudgets gekostet hat.

Die Burn Rate löst das. Sie fragt, wie schnell du das Budget verbrauchst, verglichen mit dem Tempo, das es genau am Ende des Zeitfensters aufbrauchen würde. Eine Burn Rate von 1 heißt: Du beendest den Monat mit leerem Budget und ohne Überraschungen. Eine Burn Rate von 10 heißt: Es ist in drei Tagen leer.

Für eine Person ist ein vernünftiges Setup zwei Alarme. Ein schneller, etwa bei einer Burn Rate über 10 in einer Stunde, der dich weckt. Ein langsamer, etwa bei einer Burn Rate um 2 über einen Tag, der am Morgen als Ticket landet. Das Kapitel zu Service Level Objectives im Google-SRE-Buch erklärt die Logik dahinter, die Multi-Window-Variante steht im oben verlinkten Workbook.

Welches Tool, wenn du das ganze Ops-Team bist

Du kannst SLOs einen Monat lang mit einer Tabelle und einem Cron-Job betreiben, während du lernst, was dir wichtig ist. Sobald die Zahlen zählen, verdient sich ein Tool seinen Platz. Drei lohnen einen Blick, wobei dein Stack mehr entscheidet als die Feature-Liste.

Grafana ist der Standard für alle, die bereits Prometheus-Metriken exportieren. Der kostenlose Tarif ist für ein Side Project großzügig, und die SLO-Funktion setzt auf Daten auf, die du wahrscheinlich schon hast. Lass es weg, wenn du noch keine Metrik-Pipeline hast und keine Lust, eine aufzubauen.

New Relic hat einen kostenlosen Tarif mit 100 GB Dateneingang pro Monat und SLO-Werkzeuge direkt in der Plattform. Es passt, wenn du ein agentenbasiertes Setup mit wenig Konfiguration willst. Der Nachteil: Die Kosten werden weniger vorhersehbar, sobald du das kostenlose Kontingent überschreitest.

Datadog ist die vollständigste Option und zugleich die teuerste, mit Infrastruktur, APM und Logs, die getrennt abgerechnet werden. Lohnt sich, wenn um dich herum ein Team wächst. Für ein Solo-Projekt eher nicht, außer jemand anderes zahlt.

Egal, wofür du dich entscheidest: Widerstehe dem Drang, am ersten Tag fünfzehn SLOs zu definieren. Ein Verfügbarkeits-SLO und ein Latenz-SLO pro nutzersichtbarem Service reichen, um daraus zu lernen.

Ein durchgerechneter Monat, und wann du die Zahl überprüfst

Angenommen, dein SLO liegt bei 99.5% Verfügbarkeit über 30 Tage, und du bedienst etwa 600,000 Anfragen im Monat. Das Ziel erlaubt 0.5% Fehlschläge, also 3,000 fehlgeschlagene Anfragen, bevor das Budget leer ist.

Am 9. Tag liefert eine schlechte Migration 25 Minuten lang 500er-Antworten und kostet dich 1,100 fehlgeschlagene Anfragen. Damit hast du an einem einzigen Abend etwa 37% des Budgets verbraucht. Am 17. Tag läuft eine Drittanbieter-API in einen Timeout und verbraucht weitere 900. Jetzt stehst du bei rund 67% verbraucht, mit 13 Tagen Restlaufzeit.

Das ist der Moment, in dem sich das Budget auszahlt. Du musst nicht in Panik geraten, aber du solltest auch nicht das riskante Refactoring ausliefern, das du für Tag 20 geplant hattest. Du fügst ein Timeout und einen Fallback für diesen Drittanbieter-Aufruf hinzu, schreibst den Migrationscheck, den du übersprungen hast, und verschiebst das Refactoring auf nächsten Monat.

Die Lehre ist nicht, dass Fehler schlecht sind. Fehler werden erwartet und sind eingeplant. Die Zahl gibt dir eine ruhige, gemeinsame Antwort auf die Frage "Können wir uns dieses Risiko gerade leisten?", auch wenn du die einzige Person im Raum bist.

Überprüfe jeden SLO einmal pro Quartal oder nach jedem Monat, in dem du das Budget deutlich verfehlt oder kaum angefasst hast. Zweimal hintereinander zu verfehlen heißt entweder, dass das System echte Arbeit braucht, oder dass das Ziel für deine aktuelle Phase zu ambitioniert war. Beides sind nützliche Erkenntnisse.

Drei Fehler, die SLOs nutzlos machen

Messen, was leicht ist, statt was Nutzer spüren. CPU-Auslastung ist kein SLI. Nutzer interessiert nicht, dass deine CPU bei 40% liegt. Sie wollen, dass die Seite lädt.

Das Ziel aus Ehrgeiz setzen. "Wir wollen fünf Neunen" klingt ernst und bedeutet nichts, wenn deine Datenbank eine einzelne Instanz auf einer kleinen VM ist. Setz den SLO aus der beobachteten Realität, verbessere dann das System und zieh die Zahl erst danach an.

Das Budget nie nutzen. Wenn du jeden Monat mit 98% übrigem Budget abschließt, lieferst du zu langsam aus oder das Ziel ist zu locker. Ungenutztes Budget ist verschwendete Risikobereitschaft.

Wenn du zahlende Kunden gewinnst, frag sie, was "kaputt" für sie bedeutet. Wer einen wöchentlichen Report laufen lässt, interessiert sich für den Montagmorgen, nicht für einen Ausreißer am Samstagabend. Dein SLO kann das mit einem strengeren Ziel während ihrer Arbeitszeiten abbilden.

Welchen deiner Services würdest du im Moment am wenigsten vertrauen?