Was ist ein SLO? Praktischer Leitfaden mit Sheets-Tracker

Was ist ein SLO? Ein Service Level Objective ist ein Zuverlässigkeitsziel, das Sie für einen Service festlegen und als Zahl über einen Zeitraum ausdrücken. "99,9 % der Anfragen erfolgen erfolgreich über 30 Tage" ist ein SLO. Es teilt Ihrem Team mit, wie viel Ausfallzeit akzeptabel ist, bevor Sie aufhören, neue Features zu entwickeln und stattdessen an der Zuverlässigkeit arbeiten. Die Mathematik dahinter ist einfache Division, weshalb ein Tabellenkalkulationsprogramm dafür ausreicht.

Biscuit hat die Formeln bereits für Sie recherchiert. Sie bringen die Zahlen mit.

Die drei Akronyme, die Sie ständig sehen, sortiert

SLI, SLO, SLA. Alle werden in Meetings durcheinander geworfen, daher hier die Kurzversion:

• SLI (Service Level Indicator): das, was Sie messen. Der Anteil der Anfragen, die ohne Fehler zurückkommen, der Anteil der Seiten, die unter 300 ms laden, der Anteil der Jobs, die pünktlich fertig werden.

• SLO (Service Level Objective): das Ziel für diese Messung. "Der SLI muss über 30 Tage mindestens 99,9 % betragen."

• SLA (Service Level Agreement): ein Vertrag mit Konsequenzen, normalerweise eine Rückerstattung, der an ein Ziel gebunden ist.

Der sicherste Test kommt aus Googles SRE-Buch: Fragen Sie sich, was passiert, wenn Sie das Ziel verfehlen. Falls es keine vertraglichen Konsequenzen gibt, handelt es sich um ein SLO, nicht um eine SLA. Ihr SLO sollte enger sein als jede SLA, die Sie unterzeichnet haben, damit Sie eine Warnung bekommen, bevor ein Kunde eine Rückerstattung erhält.

In Tabellenkalkulationsbegriffen: Der SLI ist eine Spalte mit Messwerten, das SLO ist eine Zelle mit dem Zielwert, und die SLA ist ein PDF, das jemand in der Rechtsabteilung aufbewahrt.

Warum 99,9 % und 99,99 % sehr unterschiedliche Versprechen sind

Jede zusätzliche Neun reduziert Ihre erlaubte Ausfallzeit um den Faktor zehn. Über einen 30-Tage-Monat (43.200 Minuten) bleibt Ihnen bei jedem Ziel folgende Zeit:

• 99 %: 1 % Budget, 432 Minuten (7,2 Stunden) erlaubte Ausfallzeit pro 30 Tage

• 99,5 %: 0,5 % Budget, 216 Minuten (3,6 Stunden)

• 99,9 %: 0,1 % Budget, 43,2 Minuten

• 99,95 %: 0,05 % Budget, 21,6 Minuten

• 99,99 %: 0,01 % Budget, 4,32 Minuten

Diese letzte Zeile ist die Falle. Vier Minuten pro Monat heißt, dass ein Mensch die Benachrichtigung nicht einmal fertig lesen kann, bevor das Budget aufgebraucht ist. Die meisten internen Systeme, Dashboards und kleinen SaaS-Produkte brauchen das nicht, und es danach zu streben kostet echtes Geld in Redundanz und Bereitschaftsdiensten.

Überspringen Sie 99,99 %, wenn kein Kunde Sie dafür extra zahlt. Googles Rat ist deutlich: Beginnen Sie mit einem lockeren Ziel, das Sie später verschärfen können, denn ein strenges Ziel, das Sie später lockern müssen, lehrt alle, die Zahl zu ignorieren.

Das Error Budget: Die Zahl, um die sich Ihr Team wirklich streitet

Das Error Budget ist das, was das SLO übriglässt. Ziel 99,9 %, also ist das Budget 0,1 %. Über 30 Tage sind das 43,2 Minuten "schlechter" Zeit, die Sie aufbrauchen dürfen.

Denken Sie daran wie an eine Tankanzeige. Riskante Deployments leeren den Tank. Eine schlecht ausgeführte Datenmigration leert den Tank. Ein Ausfall um 3 Uhr morgens leert viel Tank. Wenn der Tank voll ist, schiff schneller aus. Wenn er leer ist, fügen Sie keine neuen Features hinzu und arbeiten an der Zuverlässigkeit.

Googles eigene Muster-Policy ist konkret dazu: Wenn ein Service sein Budget über ein vierwöchiges Fenster aufbraucht, stoppen alle Änderungen außer P0-Fixes und Security-Patches, bis der Service wieder innerhalb seines SLO ist. Das Budget ist ein Verhandlungsinstrument, keine Strafe. Es ermöglicht einem Product Manager und einem Engineer, von derselben Zelle aus zu argumentieren, statt aus dem Bauch heraus.

Lohnt sich die Mühe, wenn mehr als ein Team an demselben Service arbeitet. Overkill, wenn Sie ein einzelner Gründer mit einer Landing Page und einem Kontaktformular sind.

Das passende SLI wählen

Die besten SLIs beschreiben einen Moment, den eine Person bemerken würde. Drei decken die meisten Services ab:

• Verfügbarkeit: der Anteil der Anfragen, die erfolgreich sind. Einfach zu messen, einfach zu erklären.

• Latenz: der Anteil der Anfragen, die schneller als ein Grenzwert sind. "95 % der Suchen kehren in unter 300 ms zurück" ist besser als ein Durchschnitt, denn Durchschnitte verbergen den langsamen Tail, der Menschen nervt.

• Aktualität: bei Datenpipelines und Reports, der Anteil der Durchläufe, die vor der Frist fertig werden. Das passt gut zu Tabellenkalkulationsmenschen: "Der morgendliche Verkaufsbericht wird auf 99 % der Werktage bis 8 Uhr aktualisiert."

Schreiben Sie das SLI als Bruch auf: gute Ereignisse geteilt durch gültige Ereignisse. Diese eine Gewohnheit macht jedes SLO in einer einzigen Zelle berechenbar und zwingt Sie, zu entscheiden, was "gut" zählt, bevor der Incident eintritt, nicht während er läuft.

Für das Zeitfenster ist eine rollende 30-Tage-Periode die übliche Wahl. Ein Kalendermonat ist einfacher zum Berichten, setzt das Budget aber auf dem 1. zurück, was Teams versucht, riskante Releases am Monatsende zu pushen. In einem Sheet bedeutet ein Rolling Window einfach, die Incidents-Tabelle auf die letzten 30 Tage zu filtern mit SUMIFS(Incidents!C:C,Incidents!A:A,">="&TODAY()-30).

Bauen Sie einen SLO-Tracker in Google Sheets oder Excel in 10 Minuten

Sie brauchen kein Monitoring-Tool zum Anfangen. Sie brauchen zwei Tabellenblätter: Incidents und SLO.

Auf dem Incidents-Blatt protokollieren Sie jeden Ausfall mit einer Startzeit in Spalte A, einer Endzeit in Spalte B und der Dauer in Spalte C:

=(B2-A2)*24*60

• B2 und A2: die End- und Startzeitpunkte des Incidents.

• *24*60: konvertiert die auf Tagen basierende Differenz in Minuten.

Funktioniert in Excel und Sheets, alle Versionen.

Jetzt das SLO-Blatt. Setzen Sie diese Labels in Spalte A und die Formeln in Spalte B:

B1: 0,999                         (Ihr SLO-Ziel)
B2: 30                            (Fenster in Tagen)
B3: =B2*24*60                     (Gesamtminuten im Fenster)
B4: =B3*(1-B1)                    (Error Budget in Minuten)
B5: =SUM(Incidents!C2:C)          (Ausfallzeit bisher)
B6: =1-B5/B3                      (Tatsächliche Verfügbarkeit)
B7: =B4-B5                        (Verbleibendes Budget, in Minuten)
B8: =B5/B4                        (Anteil des Budgets aufgebraucht)

Mit einem 99,9 %-Ziel gibt B3 43.200 zurück und B4 43,2. Protokollieren Sie einen 12-Minuten-Ausfall und B8 zeigt 27,8 %. So sieht das in einer echten Zelle aus.

Eine Notiz zu C2:C in B5: Die offene Range ist Sheets-Syntax. In Excel verwenden Sie eine feste Range wie Incidents!C2:C500 oder einen Tabellenlink.

Fügen Sie eine Status-Zelle hinzu, damit niemand die Nummer lesen muss:

=IF(B8>=1,"Releases einfrieren",IF(B8>=0.5,"Vorsicht","Los gehts"))

• B8>=1: Budget vollständig aufgebraucht oder überaufgebraucht.

• B8>=0.5: Die Hälfte weg, also überprüfen Sie riskante Änderungen.

• Alles andere: grünes Licht.

Wählen Sie Ihre eigenen Schwellenwerte. Fünfzig Prozent ist ein Startpunkt, keine Naturgesetz.

Stecken Sie in der Syntax für Ihre eigene Version dieses Sheets fest? Beschreiben Sie es in einfachem Englisch und lassen Sie das Tool es schreiben.

Anfragen statt Minuten zählen

Zeitbasiertes Tracking ist leicht zu erklären, aber roh. Wenn Ihr Service um 4 Uhr morgens für 5 Minuten "ausfällt", wenn niemand online ist, tut das weniger weh als 5 Minuten um 12 Uhr mittags. Die meisten ernsthaften Teams definieren den SLI nach Anfragen statt nach Zeit.

Fügen Sie einen Export Ihres Request-Logs in ein Blatt ein, mit dem HTTP-Statuscode in Spalte B. Dann:

=1-COUNTIF(B2:B,">=500")/COUNTA(B2:B)

• COUNTIF(B2:B,">=500"): zählt Anfragen, die einen Server-Fehler zurückgaben.

• COUNTA(B2:B): zählt alle Anfragen. Eine minus der Fehlerquote gibt Ihnen die Erfolgsquote.

Das Ergebnis ist Ihr Verfügbarkeits-SLI als Bruch. Vergleichen Sie es mit der Zielzelle und Sie haben das ganze SLO in einer Zeile. Excel 2016 und 365 akzeptieren beide COUNTIF; tauschen Sie einfach B2:B gegen eine begrenzte Range aus.

Zwei ehrliche Warnungen. Tabellenkalkulationen ersticken bei Millionen von Zeilen, also exportieren Sie stattdessen tägliche Summen aus den Rohlogs. Und eine 4xx-Antwort ist normalerweise der Fehler des Nutzers, nicht Ihr Ausfall, also entscheiden Sie diese Regel einmal und schreiben Sie sie auf.

Burn Rate: Die Formel, die Sie warnt, bevor es zu spät ist

Zu wissen, dass Sie 27,8 % Ihres Budgets aufgebraucht haben, ist nett. Zu wissen, dass Sie es schneller aufbrauchen als das Kalendermonth ist nützlich. Dieses Verhältnis ist die Burn Rate.

=B8/(B9/B2)

• B8: Anteil des bisher aufgebrauchten Budgets.

• B9: Verstrichene Tage im Fenster (manuell eingeben oder =TODAY()-B10 verwenden, mit dem Startdatum des Fensters in B10).

• B2: Gesamtfenster in Tagen.

Eine Burn Rate von 1 bedeutet, dass Sie das Fenster mit exakt null Budget übrig beenden werden. Über 1, und Sie steuern auf eine Freeze zu. Unter 1, und Sie haben Spielraum. Wenn Sie 10 Tage in einem 30-Tage-Fenster sind und haben bereits 60 % aufgebraucht, ist die Burn Rate 1,8. Das ist die Nummer, die Sie auf einen Screen legen.

Das ist dieselbe Idee, die große Monitoring-Tools für Burn-Rate-Alerts verwenden. Ein Sheet wird Sie um 3 Uhr morgens nicht aufwecken, behandeln Sie es als Reporting-Layer, nicht als Alarm.

Hier ist ein Arbeitsbeispiel mit echten Zahlen. Ihr SLO ist 99,9 % über 30 Tage, also ist das Budget 43,2 Minuten. Tag 1 bis 8: Ein schlecht ausgeführtes Deploy nimmt die Checkout-Seite für 14 Minuten runter. Das ist 32,4 % des Budgets in einem Viertel des Fensters, eine Burn Rate von etwa 1,2. Nichts brennt, aber das Sheet sagt jetzt "Vorsicht", und die nächste riskante Migration bekommt einen zweiten Blick. Tag 15: Ein Provider-Ausfall fügt 30 Minuten hinzu. Insgesamt 44 Minuten, 101,9 % aufgebraucht. Die Status-Zelle schaltet auf "Releases einfrieren" um, und die Konversation über Prioritäten findet mit einer Nummer auf dem Tisch statt, statt eines Gefühls.

Das ist der ganze Wert der Übung. Nicht die Neunen, sondern die gemeinsame Zelle, auf die jeder zeigen kann.

Wenn die Tabellenkalkulation nicht mehr reicht

Ein Tracker wie dieser funktioniert für einen oder zwei Services und eine wöchentliche Überprüfung. Er bricht zusammen, wenn Sie Dutzende von Services haben, automatische Datenerfassung brauchen, oder Alerts wollen, die in Minuten losgehen statt beim nächsten Montags-Meeting.

Zeit, auf ein echtes Observability-Tool zu schauen. Datadog und Grafana haben beide native SLO-Features, die den SLI direkt aus Ihren Metrics ziehen und das Budget für Sie zeichnen.

Wählen Sie Grafana, wenn Sie Open Source wollen und bereits Prometheus laufen. Wählen Sie Datadog, wenn Sie lieber zahlen, um nichts selbst zu laufen. Wie auch immer, bewahren Sie das Sheet für das monatliche Review-Deck auf, denn jeder im Raum kann es öffnen und niemand braucht einen Login zu einem Vendor.

Wenn Sie Hilfe beim Entwurf einer ersten Reihe von SLIs für einen Service wollen, ist ein allgemeiner Assistant ein anständiger Brainstorming-Partner. Verifizieren Sie jede Zahl, die er Ihnen gibt, denn er wird freudig einen plausibel klingenden Zielwert erfinden.

Fehler, die ein SLO nutzlos machen, und was Sie am Montag tun

Ein paar Muster, die Biscuit schon schlecht enden sehen:

• Ihre aktuelle Leistung als Ziel kopieren. Wenn Sie letztes Quartal bei 99,97 % liefen, sperrt ein SLO von 99,97 % ein Tempo ein, das Sie möglicherweise nicht halten können.

• Zu viele SLOs. Zwei oder drei pro Service. Danach erinnert sich niemand mehr, welcher eine zählt.

• Messen, was einfach ist, nicht was Nutzer spüren. CPU-Nutzung ist kein SLI. Fehlgeschlagene Checkouts sind es.

• Keine Konsequenz. Ein SLO ohne Error-Budget-Policy ist ein Wunsch. Entscheiden Sie voraus, was bei 50 %, 100 % und 150 % aufgebraucht passiert.

• Das Ziel nie überprüfen. Lesen Sie es jedes Quartal durch. Wenn Sie nie an den Punkt kommen, das Budget aufzubrauchen, ist das Ziel zu locker.

Jetzt der Montagsteil. Wählen Sie einen Service. Schreiben Sie einen SLI auf in einem einzigen Satz, dem ein Nicht-Engineer folgen könnte. Setzen Sie ein lockeres Ziel, 99,5 % oder 99,9 %. Bauen Sie die zwei Blätter oben, protokollieren Sie die Incidents des letzten Monats, und sehen Sie, was das Budget sagt.

Wenn die Antwort "wir haben 300 % davon aufgebraucht" ist, haben Sie gerade herausgefunden, warum sich alle müde fühlen. Wenn die Antwort "wir haben 4 %" ist, verschärfen Sie das Ziel oder schiff schneller. In jedem Fall haben Sie jetzt eine Nummer zum Argumentieren, statt eines Gefühls.

Good boy. Jetzt gehen Sie und protokollieren Sie diese Incidents.