Voraussichtliche Lesedauer: 10 Minuten

Möchtest du ein magisches Werkzeug, das dein Verständnis deiner Kunden massiv verbessert? Möchtest du genau die Features bauen, die wirklich benötigt werden? Oder magst du lieber den Nikon- und Canon-Weg, wo 90% der Features nie verwendet werden? Es gibt ein einfaches Werkzeug, dass sowohl dein Verständnis deines Kunden massiv verbessert und dabei ein Sicherheitsnetz aufspannt, das dein Team davor schützt, die Frage „Weiterentwicklung vs. Stabilisierung des Betriebs“ falsch zu beantworten. Das Werkzeug nennt sich: Reliability Stack, basierend auf SLI, SLO, und Error Budget. In diesem Artikel lernst du, wie du effizient und effektiv deinen ersten SLO einführen kannst.

Im ersten Teil der Blog-Serie „So geht IT-Operations in Produktteams heute“ haben wir uns angeschaut, was der Reliability Stack ist und warum er für dich interessant ist, wenn es dir darum geht, einen professionellen und nachhaltigen IT-Betrieb auf die Beine zu stellen. Wir sind im Detail darauf eingegangen, wie die drei Komponenten Service Level Indicator (SLI), Service Level Objective (SLO) und Error Budgets, zusammenhängen und wie du sie berechnest. In diesem Blogartikel schauen wir uns an, wie du SLO’s erfolgreich einführen und aktuell halten kannst. Dafür musst du einen 3-Schritte Prozess in deinem Team etablieren und verankern. Wie das geht, verrate ich dir in diesem Artikel.

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

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

• Im ersten Teil schauten wir uns an, wie der Reliabiltiy Stack aufgebaut ist und wie die einzelnen Komponenten, SLI, SLO und Error Budget, ineinandergreifen.
• In diesem 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.

Wie kannst du SLO’s am besten einführen?

Die Entwicklung von SLO’s ist, wenn man es auf dem Cynefin-Framework betrachtet, ein komplexes Problem. Folgt man dem Cynefin-Framework, lassen sich komplexe Problem nur mit sogenannten „emergenten Praktiken“ lösen.

Um die konkreten Praktiken zu identifizieren, führst du also folgende Schritte durch:

Probe: Suche dir eine Hypothese, die überprüft werden muss.

1. Stelle deine Hypothese auf. Ein Beispiel: Meine Benutzer sind mit meinem Produkt zufrieden, wenn 99,5% aller Anfragen unterhalb einer Sekunde beantwortet werden.
2. Baue dir mit deinem Monitoring-System einen SLI (also eine Metrik) auf, die genau diesen Sachverhalt misst.

Ergebnis: Du hast einen SLI, der anhand der Response-Zeit berechnet, wie zufrieden deine Benutzer mit deinem Produkt sind. Du hast daneben einen SLO, der besagt, dass dieser SLI über 99,5% liegen muss. Und du hast ein Error Budget, mit dem du auf einen Blick siehst, ob dein Service wie erwartet funktioniert.

Sense: Überprüfe, ob die Hypothese der Realität standhält

Sobald du deinen SLI und den passenden SLO implementiert hast, überprüfst du, ob er deine Sicht auf die Nutzerzufriedenheit verbessert hat. In dieser Phase wollen wir uns nicht auf unseren Instinkt verlassen. Stattdessen messen wir das Ergebnis. Dabei hast du mehrere Möglichkeiten:

• Befragung der Benutzer durch Formulare, zum Beispiel mit Google Forms, Microsoft Forms, SurveyMonkey oder Mentimeter
• Messung des Nutzerverhaltens mit Tools wie Matomo oder Piwik
• Labortests mit echten Benutzern, in denen du deren Verhalten beobachtest und deine Schlüsse ziehst.

Damit du sicherstellen kannst, dass deine Tests nicht dem Zufall überlassen sind, kannst du dich aus deinem Chaos Engineering-Werkzeugkasten bedienen und einen entsprechenden Versuch aufbauen:

1. Du nutzt Tools aus dem Chaos Engineering, z.B. https://chaos-mesh.org/ oder ToxyProxy, aus deinem Werkzeugkasten und manipulierst damit deinen Service, dass er den SLO nicht einhält.
2. Du nutzt klassisches A-/B-Testing, indem du mithilfe eines Load Balancers 20% deines Traffics auf deinen manipulierten Service weiterleitest und die restlichen 80% auf den normalen Service. Damit erkennst du, ob die Benutzer sich unterschiedlich verhalten. Das wiederrum lässt Rückschlüsse auf deren Zufriedenheit zu.

Wenn dein SLO relevant ist, müssten sich die Kundennutzen-Werte deiner Nutzerstudie verschlechtern. Falls dem nicht so ist, ist deine Hypothese falsch und du gehst wieder zum Probe-Schritt zurück. Achte dabei vor allem auch darauf, ab welchem SLO deine Nutzerzufriedenheit sinkt. Wenn du von einem Wert von 99,5% ausgehst, deine Nutzer aber schon mit 95% zufrieden sind, verschenkst du viel Entwicklungszeit und blockierst unnötig die Weiterentwicklung deines Produkts.

Response: Nutze deine Erkenntnisse, um deinen SLI und SLO zu optimieren

Wenn du deine Hypothese belegt hast, dann überlege dir geeignete Maßnahmen, wie du sicherstellen kannst, dass der SLO eingehalten wird. Möglichkeiten dafür sind ein Frühwarnsystem, z.B. eine Alarmierung durch das Monitoring-System, oder automatisierte Cleanup-Jobs, die sicherstellen, dass dein System im Sinne des Kundennutzen optimal läuft.

Weiter geht es wieder bei Probe mit der nächsten Hypothese. Beispiele dafür wären:

• Die Verfügbarkeit des Produktes
• Die Fehlerrate
• Die Zuverlässigkeit der Ergebnisse
• Anzahl der Incidents

Im nächsten Probe-Schritt überprüfst du dann, ob du damit einen bestehenden SLO erweiterst oder einen eigenen SLO definierst. Wie bereits im letzten Beitrag erklärt, solltest du die Anzahl der SLO’s im Rahmen halten, damit du Handlungsfähig bleibst.

Dieser Prozess läuft dauerhaft mit. Die wichtigste Erkenntnis dabei ist: Es gibt keine perfekten SLO’s. Für die meisten Fälle reicht ein „ausreichend genau“ definierter SLO.

Drei typische Fehler bei der Einführung von SLO’s

Nachdem du nun einen einfachen 3-Schritte-Prozess kennengelernt hast, mit dem du SLO’s einführen, am Leben halten und durch Lernen immer weiter verbessern kannst, kommen wir nun zu 3 Problemen und Fehlern, die häufig begangen werden.

Fehler #1: SLO mit SLA verwechseln

Den Punkt hatten wir im ersten Teil dieser Serie bereits. Da er aber wichtig ist und regelmäßig falsch gehandhabt wird, hier noch einmal. SLO’s sind keine SLA’s. Sie hängen nicht zusammen. Sie haben nur einen einzigen Bezug zueinander: Sie sind eine Metrik für Service Levels. Das ist allerdings alles. Das Service Level Agreement ist ein Versprechen an den Kunden, dass gewisse Metriken eingehalten werden. Beispiele:

• 99,5 % Verfügbarkeit
• Antwortzeiten innerhalb von 2 Sekunden in einem 95%-Quantil.
• Maximal 1% Fehlerrate bei Requests.

Service Level Objectives unterscheiden grundlegend von den SLA’s, SLO’s dienen als messbarer Repräsentant des Kunden für das Team. Anhand der SLI’s, die aus Kundensicht gute und schlechte Ereignisse unterscheiden, Der SLO gibt an, ob die Kunden zufrieden sind mit dem Service/Produkt oder nicht. Auf der Basis werden Entscheidungen zum Wohl des Kunden getroffen.

Die Anforderungen der Kunden verändern sich kontinuierlich. Die SLO’s bilden das ab. Die SLA’s sind starr und vertraglich vereinbart. Beide haben ihre Daseinsberechtigung, sind aber grundlegend verschiedene Themen.

Fehler #2: Dich an Best Practices orientieren

Best Practices sind einfache Rezepte, wie du einfache Aufgaben bewältigen kannst. Wie wir bereits gesehen haben, ist die Einführung, die Anwendung und das dauerhafte Fortführen von SLO’s kein einfaches Problem. Wenn wir an dem Cynefin-Framework orientieren, benötigen wir zur Lösung komplexer Probleme emergente Praktiken, also Praktiken, die sich immer wieder an der neuen Realität unterscheiden. Es gibt diverse Parameter, die die Realität verändern:

• Das Interesse des Kunden
• Die angebotenen Features
• Der Anwendungszweck des Produktes
• Der Lebenszyklus des Produktes
• Die Anzahl der Kunden, die das Produkt nutzen
• Die Erwartung der Kunden an das Produkt
• und viele weitere…

Diese Parameter sind variabel und liefern, je nach Konstellation, eine unterschiedliche Kundenzufriedenheit und damit unterschiedliche Anforderungen an den Reliability Stack und die SLO’s.

Um das Ganze noch ein wenig unübersichtlich zu machen.

Übrigens: Der Reliability Stack als Werkzeug (also das WAS) ist eine Best Practice für das „einfache“ Problem, den Kunden und seine Zufriedenheit messbar zu machen. Die Anwendung des Reliability Stacks (also das WIE) ist eine komplexe Aufgabe, die ständig angepasst werden muss.

Fehler #3: Kontinuierliche Anpassung der SLO’s vergessen

Der Wert der SLO’s hängt massiv davon ab, wie gut sie den Kundennutzen des Produktes widerspiegeln, um auf der Basis strategische und operative Entscheidungen zu treffen. Wie bereits im vorherigen Punkt besprochen ist der Kundennutzen ein „Moving Target“, dass sich durch diverse Ereignisse verändern kann. Falsche oder ungenaue Messwerte bei strategischen und operativen Entscheidungen sind allerdings eine große Gefahr für euer Produkt.

Deshalb ist es essenziell, die SLO’s im Auge zu behalten und immer wieder nachzujustieren. Das ist kein großer Aufwand, wenn man sie regelmäßig mit dem oben genannten Prozess durchläuft. Wann der richtige Zeitpunkt für eine Nachjustierung der SLO’s gegeben ist, hängt stark von deinen Kunden ab. In manchen Fällen reicht es, nach jeder größeren Architekturänderung oder der Einführung eines neuen Features auch die SLO’s neu zu beleuchten. In anderen Fällen muss dies in regelmäßig wiederkehrenden Intervallen, zum Beispiel quartalsweise, durchgeführt werden. Im Endeffekt ist der konkrete Rhythmus nicht entscheidend, sondern allein die Tatsache, dass man seine SLO’s dem Kundennutzen anpassen muss. Auch hier gilt es, sich immer näher an einen optimalen Rhythmus anzunähern

Fazit und Ausblick

Du weißt nun, wie du den Reliability Stack in deinem Team einführen kannst. Gemeinsam mit den Hintergründen des ersten Beitrags dieser Serie hast du nun das notwendige Wissen und Werkzeug, um erfolgreich deine ersten SLO’s zu erstellen und deine eigene Erfahrung zu sammeln. Lass dich nicht von dem oben genannten Prozess abschrecken. Er hilft dir, deine Kunden besser zu verstehen und in einen Dialog zu kommen. Nützliche Seiteneffekte sind, dass du besser verstehst, worauf es deinen Kunden wirklich ankommt. Dadurch vermeidest du viele „goldene Henkel“ an deinem Produkt, die niemand braucht, euch aber davon abhalten, echten Mehrwert für eure Kunden zu liefern.

Ich wünsche dir viel Erfolg bei der Einführung deines Reliability Stacks.

Wie geht es weiter?

In den restlichen drei Folgen schauen wir uns konkret an, wie du, zum Beispiel basierend auf den SLO’s und den Error Budgets, deinen Betrieb stabiler und beherrschbarer gestalten kannst. Die Themen sind:

• Chaos Engineering und Feuerwehrübungen
• Postmortem Analyse und Debugging
• Standardbetriebsprozesse und -vorgehen

Und jetzt du!

Hast du bereits deinen ersten SLO definiert? Wie fühlt es sich an, dieses Sicherheitsnetz aufzubauen und dabei dein Verständnis deiner Kunden zu verbessern? Oder hast du schlechte Erfahrungen gemacht, die du gerne teilen möchtest?

Ich freue mich darauf, deine Kommentare zu diesem Thema zu lesen!