Voraussichtliche Lesedauer: 15 Minuten

SLO’s bzw. Service Level Objectives sind der neue Hype, getrieben durch die Site Reliability Engineering Bewegung, die Google spätestens mit der Veröffentlichung des Buchs Site Reliability Engineering 2016 und dessen Nachfolger, The Site Reliability Workbook 2018 losgetreten hat. Diese Art moderner Betriebsführung hat vielen Unternehmen die Augen geöffnet. Überall sind sogenannte SRE-Teams hervorgegangen. Eine der zentralen Komponenten des Site Reliability Engineerings ist die Nutzung der SLO’s, oder wie es später genannt wurde, dem Reliability Stack.

In diesem Artikel gebe ich dir einen Überblick über das Thema SLO. Es gibt dabei einiges zu beachten und viele Fehler, die gemacht werden können. Generell ist die Einführung von SLO’s auf der einen Seite zwar ein riesiger Gewinn, kann aber aufgrund seiner Komplexität schnell ein Fass ohne Boden werden. Es ist auf jeden Fall ein Thema für fortgeschrittene Teams, die das Thema Observability bereits sicher im Griff haben und die nächste Stufe gehen wollen.

Level: Fortgeschrittene, Profis

Die „So geht IT Operations in Produktteams heute“-Serie

Die Blogserie „So geht IT Operations in Produktteams heute“ ist in folgende Teile gegliedert:

• In diesem Teil schauen wir uns an, wie der Reliabiltiy Stack aufgebaut ist und wie die einzelnen Komponenten, SLI, SLO und Error Budget, ineinandergreifen.
• Im zweiten Teil schauen wir uns an, wie du SLOs einführen kannst und welche Fehler du vermeiden solltest.
• Im dritten Teil werden wir uns mit dem Thema Chaos Engineering beschäftigen. Wir schauen uns an, wie das Vorgehen beim Chaos Engineering dir dabei hilft, dein Produkt optimal an die Nutzerbedürfnisse anzupassen. Damit schlägst du gleich zwei Fliegen mit einer Klappe: Der Operations-Anteil deines Teams wird reduziert, die Betriebsstabilität nimmt zu und du hast viel Zeit, deinen Kundennutzen zu steigern.
• Im vierten Teil schauen wir uns an, wie du mithilfe der Postmortem-Analyse Ausfälle und Probleme im Betriebsablauf optimal nutzen kannst, um die Betriebsstabilität deines Produktes zu verbessern. Damit schaffst du Freiräume, um dein Produkt weiterzuentwickeln.
• Im fünften Teil schauen wir uns dann an, wie deine Betriebsabläufe und den IT Service Management aus Teamsicht strukturiert sein können, damit ihr die beiden Ziele „Betriebsstabilität“ und „Entwicklung neuer Features“ unter einen Hut bekommt.

Am Ende der Serie weißt du, wie modernes IT Operations in Produktteams heutzutage aussehen kann. Und wie du das ohne die Abhängigkeit von komplizierten, speziellen Cloud-Native-DevOps -Eierlegende-Wollmilchsau-Tools erreichen kannst.

SLO’s, SLI’s, Error Budget? Was ist das eigentlich?

Stell dir vor, es gibt einen Indikator, der dir Auskunft darüber gibt, ob dein Produkt jetzt in diesem Moment deine Kunden zufriedenstellt. Stell dir vor, anhand dieses Indikators kannst du sofort zwischen zwei Optionen entscheiden:

1. Ob du dich auf die Weiterentwicklung deines Produktes und das Liefern neuer, wertvoller Features konzentrieren darfst, weil dein Produkt im Moment perfekt läuft.
2. Oder ob du dich lieber um die Stabilisierung der Betriebsstabilität und Zuverlässigkeit deines Produktes kümmern solltest, um die optimaler Kundenzufriedenheit wiederherstellen zu können.

Diesen Indikator gibt es. Und der kann sogar noch viel mehr. Du bist gar nicht der, der zwingend entscheiden muss. Die Entscheidung kannst du mit der obigen Regel ganz einfach in dein Team delegieren, ohne Qualitätsverluste befürchten zu müssen.

Allerdings hat das Ganze eine Kehrseite, die leider zu oft ignoriert wird: Die Berechnung und der Aufbau dieses Indikators sind komplex. Du benötigst eine tiefgehende Erfahrung darin …

• die Möglichkeiten zu identifizieren, wie man bei deinem Produkt valide Messwerte messen kann,
• die Kernkriterien zu finden, die aussagen, ob ein Kunde zufrieden ist mit deinem Produkt und
• eine ideale Gewichtung verschiedener Kriterien inklusive der mathematischen Modelle aufzustellen

Außerdem brauchst du einen Prozess, mit dem du diesen Indikator sukzessive mit deinen neuen Erkenntnissen anreicherst und verbesserst. Dafür nutzt du das Probe-Sense-Response Vorgehen, dass im Cynefin-Modell für komplexe Aufgaben vorgesehen ist. Dazu im zweiten Teil dieser Serie mehr.

Aber jetzt der Reihe nach. Damit wir vom Gleichen sprechen, lass uns erst einmal definieren, was eigentlich SLO’s, SLI’s und Error Budgets sind und wie sie sich von den SLA’s, den Service Level Agreements, unterscheiden. Danach schauen wir uns an, wie du das Thema SLO’s angehen und die ersten Schritte gehen kannst.

Service Level Indicators (SLI)

Service Level Indicators sind, wie der Name schon sagt, Indikatoren, die bestimmen, wie gut dein Produkt im Moment aus Nutzersicht funktioniert. Der SLI hat also den Anspruch, ein Frühwarnsystem für die Zufriedenheit deiner Nutzer darzustellen. Nicht mehr, aber auch nicht weniger.

Ein SLI ist also ein aggregierter Zahlenwert, der die Zufriedenheit deiner Benutzer mit der Benutzung deines Produktes widerspiegelt.

Wie bildet man einen SLI?

Ein SLI basiert auf einer oder mehreren Metriken. Den Metriken gibst du einen Schwellwert, mit dem du entscheiden kannst, ob es ein gutes oder ein schlechtes Ereignis (Event) war. Beispiel: Du hast eine Website. Du weißt, dass Benutzer glücklich mit der Performance sind, wenn die Ladezeit < 2 Sekunden ist. Du hast also einen Schwellwert (Threshold) von 2 Sekunden. Wenn deine Website unter 2 Sekunden lädt, ist es ein gutes Ereignis, wenn sie 2 Sekunden oder länger braucht, ist es ein schlechtes Ereignis. Nun nimmst du die Anzahl guter Ereignisse und teilst sie durch die Gesamtzahl aller Ereignisse. Heraus kommt eine Prozentzahl, die besagt, dass z.B. 97% deiner Websitebesucher ein gutes Ergebnis erhalten haben. Das heißt wiederum, dass die Metrik dir verrät, dass 97% deiner Websitebesucher gut mit deiner Website klarkamen. 3% hatten dagegen ein schlechtes Erlebnis. Zusammengefasst:

SLI = Anzahl guter Ereignisse/Anzahl aller Ereignisse

Beispiel:
SLI = 291/300 = 97%

Welche Kriterien müssen gute SLI genügen?

In der Praxis haben sich ein paar Kriterien herausgebildet, die gute von ungünstigen SLI’s unterscheiden. Diese sind nach meiner Erfahrung:

1. Ein SLI muss in einem Satz für alle Stakeholder beschreibbar und verständlich sein. Er muss eingängig und eindeutig sein.
2. Ein SLI muss die Nutzerzufriedenheit widerspiegeln. Es reicht also meist nicht, eine Metrik abzubilden. Vielmehr muss der SLI einen möglichst eine Nutzererfahrung mit dem Produkt abbilden und diese als gutes oder schlechtes Ereignis interpretieren.
3. Ein SLI muss jederzeit hinterfragt werden und auf seine Nützlichkeit geprüft werden. Ein SLI kann niemals fertig sein, weil sich das System, das Nutzerverhalten und die Erwartungshaltung immer wieder ändern.

Service Level Objectives (SLO)

Das Service Level Objective ist, wie der Name schon sagt, ein Zielwert für einen Service Level Indicator. Während der Indikator nur eine Zahl ist, sagt das SLO aus, wie gut die Nutzererfahrung mindestens sein muss, damit sich dein Produktteam sicher fühlen kann, euren Kunden einen echten Mehrwert zu liefern. Wenn dein Team für das Produkt im obigen Beispiel einen SLO von 95% veranschlagt hat, dann übererfüllt es dieses Ziel mit den 97%. Wenn das SLO allerdings auf 99% liegt, dann ergibt sich eventuell ein Handlungsbedarf, da das Ziel nicht erfüllt wird. Allerdings lässt sich das nicht pauschal am SLO festlegen. Um Entscheidungen auf Basis des SLO zu treffen, müssen zusätzlich die sogenannten Error Budgets eingeführt werden.

Fallstricke bei der Bestimmung der SLO’s

Wie bei jedem komplexen Thema gibt es auch einige Fallstricke, in die man hineintappen kann. Ich habe dir die aus meiner Sicht drei wichtigsten herausgesucht.

Fallstrick #1: Zu viele 9-er

Wenn man einen Manager oder Unternehmer nach der Verfügbarkeit oder der Benutzerzufriedenheit eines Produktes fragt, ist die Antwort einfach: 100%. So einfach die Antwort, so utopisch die Forderung.

Aber auch die typischen anderen Forderungen müssen wohlüberlegt sein: 99,9995%, 99,999% und ähnliche Werte geistern durch die Gegend. In folgender Tabelle zeige ich dir, was das konkret für dich bedeutet:

Zielwert	Pro Tag	Pro Monat	Pro Jahr
99,999%	0,9s	26,3s	5m 15,6s
99,99%	8,6s	4m 23s	52m 35,7s
99,9%	1m 26,4s	43m 49,7s	8h 45m 57s
99%	14m 24s	7h 18m 17,5s	3d 15h 39m

Eine Faustregel, die dann deutlicher wird, wenn wir über das Thema Error Budget reden: Je näher dein Zielwert an der 100%-Marke liegt, desto schwieriger wird er zu erreichen sein und desto weniger Zeit habt ihr für die Weiterentwicklung. Je niedriger der Zielwert ist, desto unzufriedener können deine Kunden werden, weil ihr gewisse Fehler toleriert. Die Kunst ist es, einen gesunden Mittelweg zu finden zwischen Kundenzufriedenheit, weil der Service so gut läuft und Kundenzufriedenheit, weil neue Features zeitnah geliefert werden.

Fallstrick #2: Zu viele SLO’s

Gerade wenn man mit SLO’s beginnt, tendiert man gerne dazu, es zu übertreiben. Hier noch einen SLO und dort noch einen Nutzwert. Es gibt zwar keinen Richtwert, wie viele SLO’s sinnvoll sind, allerdings solltest du aufpassen, den Wald vor lauter Bäumen noch zu sehen. Viele Initiativen scheitern an ihrer Komplexität: SLO’s sind dafür prädestiniert zu scheitern, wenn man sich von Anfang an übernimmt.

Fallstrick #3: Abhängige Services vergessen

Dein Produkt existiert in der Regel nicht allein in der weiten Welt. Es gibt Datenbanken, Speichertechnologien, abhängige Systeme wie ein OAuth-Manager oder Services, die wichtige Daten bereitstellen, eine zugrundeliegende Plattform und, last but not least, die Internetverbindung. Alle diese Abhängigkeiten nehmen sehr starken Einfluss auf die Nutzbarkeit deines Services. Was bringt dir eine Verfügbarkeit von 99,999% deines Services, wenn die Hauptnutzer deinen Service über ihr Handy mit mobilen Daten aus dem ICE nutzen? Das schwächste Glied der Kette bestimmt die Zuverlässigkeit, vieles hast du nicht unter Kontrolle.

Fallstrick #4: SLO’s als SLA’s vereinbaren

Ein beliebter Fehler ist es, seine SLO’s als Service Level Agreements (SLA’s) zu veröffentlichen oder mit einem Kunden vertraglich festzuhalten. Das hat ein paar Nachteile. Der wichtigste Nachteil ist: Das Nutzerverhalten, die Technologie und die Erwartungen ändern sich über die Zeit. Services, die vor zwei Jahren noch einen Best-Effort-SLA genossen, können durch die Nutzung von Schnittstellen zu einer Unternehmenskritischen Anwendung werden. Konkret habe ich diesen Fall bei einem deutschen Schienenverkehrsunternehmen gesehen, bei dem das Reservierungssystem der Fernzüge durch Schnittstellen plötzlich eine sehr wichtige Komponente wurde, die eigentlich einen SLA mit Gold-Status (kurze Reaktionszeiten, 24/7 Support) benötigt hätte.

War es die letzten Jahre für die Zugbegleiter ärgerlich, wenn das Reservierungssystem ausgefallen ist und reservierte Plätze nicht als solche angezeigt wurden, hing plötzlich ein wichtiger Teil des Vertriebssystems dieses Unternehmens daran. Auch andere Partnerunternehmen hatten ähnliche Entwicklungen gemacht. Somit war der Best-Effort-SLA völlig unzureichend.

Der andere Fall ist, dass ein Produkt das Ende seines Lebenszyklus erreicht. Braucht ein Produkt, dass nur noch spärlich verwendet wird wirklich einen 24/7 Betrieb, eine Verfügbarkeit von 99,99% und Pönalen (Strafzahlungen bei Nichteinhaltung der SLA)?

SLO’s sind Ziele, die sich ein Team gibt, damit es den Kundennutzen für sich messbar machen kann. Nicht mehr, aber auch nicht weniger. Es ist ein Frühwarnsystem und ein Gradmesser, wie gut das eigene Produkt die Wünsche und Bedürfnisse erfüllt. Es ist dynamisch und passt sich der aktuellen Lage an, wird vom Team durch neue Erkenntnisse der Realität angepasst. Deshalb sind SLO’s als SLA’s für die meisten Vorhaben tödlich, da aus einem internen Arbeitsinstrument ein externes Überwachungsinstrument wird und die Erfüllung des Kundennutzen dem stumpfen Erreichen von Kennzahlen weicht.

Error Budgets

Der letzte Teil des Reliability Stacks wird gerne vergessen, liefert aber den größten Mehrwert des Reliability Stacks: Das sogenannte Error Budget. Was kannst du dir darunter vorstellen?

Stell dir vor, dein Produkt läuft nicht so rund, wie ihr es euch vorstellt. Wann müsst ihr euch darum kümmern, an der Betriebsstabilität und Zuverlässigkeit eures Produkts zu arbeiten? Oder ist die Zeit besser investiert, wenn ihr neue Features entwickelt und ausliefert? Das Error Budget nimmt euch diese schwere Frage ab. Simpel ausgedrückt heißt das: Wenn ihr euch noch innerhalb des Budgets befindet, dann entwickelt ihr besser neue Features, macht Experimente und bereitet euch auf Desaster-Szenarien vor. Wenn das Budget überschritten ist, kümmert euch darum, die Betriebsstabilität und die Zuverlässigkeit eures Produkts zu erhöhen.

Das Error Budget ist also ein Kommunikations und Entscheidungswerkzeug. Aber: Wie macht das Error Budget das? Wie kannst du dir das vorstellen?

Das Error Budget ist eine einfache Kennzahl. Sie zeigt an, wie viel Budget in Zeiteinheit (z.B. 15 Minuten, 3 Stunden) man noch hat. Dabei wird ein längerer Zeitraum mit einbezogen. Gut sind zum Beispiel 30 Tage, perfekt wäre aber ein 90 Tage Zeitfenster.

Wie berechnest du das Error Budget?

Lass uns ins eingemachte gehen: Wie kannst du das Error Budget berechnen? Es gibt verschiedene Methoden. Wir fokussieren und hier auf das sogenannte eventbasierte Error Budget. Nehmen wir unseren SLI von oben, in dem wir 97% aller Aufrufe zuverlässig verarbeitet wurden (gute Ereignisse). Nehmen wir an, dass der SLO 95% ist. Dann sieht die Berechnung des Error Budgets folgendermaßen aus:

100% - 97% = 3% // schlechte Ereignisse
100% - 95% = 5% // zulässige schlechte Ereignisse

5% - 3% = 2% // Restbudget an schlechten Ereignissen.

// Error Budget über ein 30-Tage Zeitfenster:
30 Tage * 2% = 0,6 Tage = 14,4 Stunden // Restbudget

Nehmen wir an, wir haben ein SLO von 99,5%. Dann verändert sich die Rechnung wie folgt:

100% - 97% = 3% // schlechte Ereignisse
100% - 99,5% = 0,5% // zulässige schlechte Ereignisse

0,5% - 3% = -25% // Restbudget an schlechten Ereignissen.

// Error Budget über ein 30-Tage Zeitfenster:
30 Tage * -2,5% = -0,75 Tage = -18 Stunden // Budget überschritten

Das sind zwei Beispiele, die einen wichtigen Aspekt zeigen:

Die Wahl des SLO ist entscheidend für den Erfolg deines Teams!

Der SLO entscheidet, ob und in welchem Maße die Weiterentwicklung deines Produktes möglich ist: Im ersten Fall mit dem SLO von 95% wird sich das Team in die Arbeit stürzen und Feature um Feature rausbringen. Im zweiten Fall mit dem SLO von 99,5 wird das Team alles daransetzen, das Produkt zu stabilisieren, um das SLO zu erreichen. Und beiden bei objektiv gleicher Leistung. Deshalb ist das genaue austarieren des SLO an die Nutzerbedürfnisse so extrem wichtig.

Die Beispielrechnung oben ist ein guter Startpunkt, um in das Thema SLO, SLI und Error Budget einzutauchen. Es geht aber beliebig komplex. Um dir einen Ausblick zu geben, hier zwei Fragen, die ihr euch irgendwann stellen werdet:

1. Machen wir eventbasiertes Error Budget oder zeitbasiertes Error Budget?
2. Nehmen wir ein fixes Zeitfenster, zum Beispiel Monat/Quartal oder ein wanderndes Zeitfenster, z.B. 30 oder 90 Tage?

Meine Buchempfehlung für dich, wenn du SLO’s in deinem Team etablieren möchtest!

Wenn du dich näher mit diesem Thema beschäftigen möchtest, empfehle ich dir das großartige Buch „Implementing Service Level Objectives“ (affiliate Link) von Alex Hidalgo, einem der Gründerväter der SLO’s, SLI’s und Error Budgets bei Google. Er taucht in dem Buch sehr viel detaillierter in das Thema Service Level Objectives ein und versteht es, Zusammenhänge, die in den beiden SRE-Büchern leider nur kurz angerissen wurden, zu verdeutlichen. Möchtest du ernsthaft SLO’s einführen, ist dieses Buch ein must-read. Viel wichtiger noch als die beiden oben genannten SRE-Bücher von Google.

Fazit und Ausblick

SLO’s sind ein wunderbares Beispiel für ein Werkzeug, dass auf der einen Seite eine massive Verbesserung bei deinen Kunden und in deinem Team bewirken kann. Auf der anderen Seite darfst du die Komplexität und das nötige Wissen und die Erfahrung nicht aus den Augen verlieren. Nur unter der Voraussetzung, dass ihr diese Komplexität meistert, steigert ihr eure Effektivität, damit auch eure Effizienz und dadurch auch eure Produktivität. Ihr baut euch ein Sicherheitsnetz, mit dem ihr jederzeit sicher seid, dass ihr an den richtigen und wichtigen Themen arbeitet. Es ist euer Kompass, der euch klar macht, ob die Entwicklung neuer Features oder die Stabilisierung eures Produktes jetzt das nächste wichtige Thema ist.

Wir haben uns in diesem Post angeschaut, was SLO’s sind und wie sie sich von SLA’s unterscheiden. Im nächsten Teil dieser Serie schauen wir uns an, wie du SLOs auch in deinem Team einsetzen kannst und worauf du dein Augenmerk legen musst, wenn du erfolgreich sein willst.

Und jetzt du!

Hast du bereits Erfahrungen mit SLO’s gesammelt? Oder ist dir das Thema gänzlich neu? Hat dir der Artikel einen Mehrwert geliefert? Oder gibt es Unklarheiten?

Ich freue mich darauf deine Erfahrungen und Anmerkungen zu diesem Thema zu lesen. Nutze dafür einfach die Kommentarfunktion unten!