Wichtige SRE-Prinzipien und -Methoden: positiver Kreislauf
Wenn es auf Sie gewissermaßen zutrifft, dass Ihre Tätigkeit sich in Ihrer Persönlichkeit widerspiegelt, haben wir den Kern dieses Moduls erreicht. In dieser Lektion werden zwei Methoden näher erläutert, die zu den wichtigsten für die Umsetzung von SRE zählen. Beiden liegt das Prinzip zugrunde, dass es wichtig ist, „positive Kreisläufe“ zu erstellen. Mit positiven Kreisläufen sind in diesem Kontext Methoden gemeint, die Feedbackschleifen in einer Organisation ermöglichen, durch die eine kontinuierliche Verbesserung erzielt wird. Zu diesen beiden Methoden folgen weitere Module, deshalb werden sie in dieser Einheit nur oberflächlich behandelt.
Positiver Kreislauf, Teil 1: SLIs und SLOs
Zuvor haben wir in diesem Modul ausführlich das Hinarbeiten auf das Ziel „angemessener Grad an Zuverlässigkeit“ behandelt. In diesem Abschnitt sind wir an der Stelle angelangt, an der dieses Konzept konkret wird.
Nehmen wir an, dass Sie einen neuen Dienst (der schon erstellt wurde oder noch in Planung ist) entwickeln, der an die Produktion übergeben werden soll. Im Rahmen dieses Prozesses ist es wichtig, Entscheidungen bezüglich der angestrebten Zuverlässigkeit zu treffen. Wenn Sie den Code nicht selbst schreiben, müssen diese Entscheidungen unbedingt mit den Entwicklern zusammen getroffen werden, die an der Realisierung arbeiten.
Die erste Entscheidung, die getroffen werden muss, betrifft die Indikatoren für die Integrität des Diensts (auch als Service Level Indicator oder SLI bezeichnet). Dafür können Sie sich auch folgende Frage stellen: „Woher weiß ich, dass der Dienst betriebsbereit ist und gut funktioniert?“. Es gibt viele Möglichkeiten, den SLI nachzuverfolgen, von denen wir einige später im Detail untersuchen. In der Regel handelt es sich um diese Indikatoren:
- Erfolgs- und Fehlerkennzahlen. Schließt der Dienst einen Vorgang in einem bestimmten Prozentsatz der Zeit erfolgreich ab?
- Zeitbezogene Kennzahlen. Haben wir innerhalb einer bestimmten Zeit eine Antwort zurückerhalten?
- Durchsatzbezogene Kennzahlen. Haben wir eine bestimmte Datenmenge verarbeitet?
Oder eine Kombination all dieser Kennzahlen.
Nehmen wir als einfaches Beispiel an, dass der SLI für unseren Dienst darin besteht, wie oft ein Erfolg zurückgegeben wurde (gemessen am HTTP-Code „200“ im Vergleich zu „500“ oder einem anderen Code).
Wir haben nun einen klaren Überblick, der uns verrät, wie es um den Dienst bestellt ist. Wir möchten entscheiden, welches Maß an Zuverlässigkeit wir uns vom Dienst erwarten oder wünschen. Erwarten wir beispielsweise einen bestimmten Zeitraum pro Tag, in dem der Dienst eine Ausfallquote von 20 % aufweist? Wir verwenden runde und große Zahlen, weil diese für einen verständlichen Einstieg am geeignetsten sind. In späteren Modulen steigen Komplexität und Exaktheit solcher Aussagen (z. B. „Wie viele Benutzer betrifft diese Fehlerquote? Einige? Die meisten?“). Diese Erwartung, die in Zusammenarbeit mit den Entwicklern des Diensts ausgearbeitet wird, wird als „Service Level Objective“ (SLO) bezeichnet.
Das SLO muss genau gemessen und im Überwachungssystem dargestellt werden können. Es muss ein objektives, durchdachtes Ziel für die Zuverlässigkeit des Diensts darstellen – welche Zahl ist dafür gut genug? Eine Aussage wie die folgende reicht dafür nicht aus: „Ich denke, dass der Dienst in der letzten Woche gut funktioniert hat, kann es aber nicht genau sagen.“ Der Dienst erfüllt das SLO oder nicht – die Daten müssen eindeutig sein. Wenn das SLO nicht erreicht wird (vor allem, wenn dies wiederholt auftritt), funktioniert etwas nicht richtig, und der Fehler muss behoben werden.
Fehlerbudgets
Es ist nachzuvollziehen, dass eine Organisation handelt, wenn ein Dienst sein SLO nicht erfüllt. SRE führt dieses Konzept jedoch für Fälle, in denen das SLO erfüllt oder überschritten wird, einen Schritt weiter. Einige Organisationen verwenden SLOs, um sogenannte „Fehlerbudgets“ zu erstellen.
Zur Veranschaulichung dieses Konzepts verwenden wir den Beispieldienst, der bereits erläutert wurde, und dessen SLO von 80 % Erfolg (stellen Sie sich das wie „muss 80 % der Zeit funktionieren“ vor). Mit dem SLO von 80 % Betriebszeit haben wir festgelegt, dass unser Dienst 80 % der Zeit in Betrieb sein muss. Doch was ist mit den verbleibenden 20 %? Wenn die verbleibenden 20 % Downtime ist, ist das für uns nicht weiter erheblich, da wir uns dafür entschieden haben, dass die zusätzlichen 20 % Betriebszeit für unseren Dienst kein wichtiges Ziel darstellen.
Wenn es also nicht wichtig ist, was während dieser Zeit geschieht, wie können wir dann in Bezug auf den Dienst handeln? Es ist natürlich möglich, den ausgeführten Dienst zu unterbrechen, indem wir ein Upgrade für diesen durchführen, z.B. durch ein Release mit neuen Features. Wenn das neue Release funktioniert und nicht zu erhöhter Ausfallzeit führt, ist das hervorragend. Wenn das neue Release dazu führt, dass der Dienst weniger stabil ist und 10 % der Zeit während des Debuggens Fehler zurückgibt, ist das noch in Ordnung. Damit liegen wir immer noch im Rahmen der zulässigen Unzuverlässigkeit.
Ein Fehlerbudget stellt die Differenz zwischen der potenziell perfekten Zuverlässigkeit des Diensts und der angestrebten Zuverlässigkeit dar (z.B. 100 % – 80 % = 20 %). In diesem Fall gestattet das Fehlerbudget eine Unzuverlässigkeit von 20 %. Das sind 20 % Zeit, in denen es nicht wichtig ist, ob der Dienst funktioniert oder nicht, weil die Zuverlässigkeit trotzdem im Rahmen ist. Wir können diese 20 % auf jede erdenkliche Weise verwenden (z.B. für weitere Releases), bis sie – wie bei anderen Budgets – erschöpft sind.
Fehlerbudgets werden in einigen Organisationen auch für den ungünstigeren Fall verwendet, dass das SLO nicht selbst gesetzt wird. In diesem Fall sollten Sie bestimmter vorgehen als nur „eine Maßnahme zu ergreifen“. Nehmen wir an, unser Dienst hatte Probleme und war dadurch nur 60 % der Zeit verfügbar, was sich aus dem zuvor ausgewählten SLO ergeben hat. Wir haben unser Ziel, das SLO, nicht selbst gesetzt. Unser Dienst hat sein Fehlerbudget verbraucht. Die Organisation kann nun ein geplantes Release zurückhalten, da die Zuverlässigkeit durch weitere Störungen des Systems nur verschlechtert wird. Fehlerbudgets werden in der Regel für einen bestimmten Zeitraum berechnet: einen Monat, ein Quartal usw. Auf rollierender Basis, d. h., wenn sich die Zuverlässigkeit des Dienstes verbessert, wird dieses Budget zurückgegeben.
Während des Zeitraums der abgegrenzten Releases kann die Organisation z. B. einige technische Mitarbeiter von der Entwicklung von Features abziehen und diese für die Arbeit an der Zuverlässigkeit einsetzen. Und zwar mit dem Ziel, die Quelle der Probleme zu finden, die dazu geführt haben, dass der Dienst das SLO nicht erfüllt, und diese zu beheben.
Wir sprechen in Bezug auf Fehlerbudgets von „einigen Organisationen“, da deren Implementierung ein bestimmtes Maß an Kompromissbereitschaft durch das Unternehmen erfordert, insbesondere dann, wenn das Budget für Releases eingesetzt wird. Wenn die Organisation vor der Entscheidung steht, eine neue Version zu veröffentlichen, muss sie bereit sein, die Veröffentlichung zu verschieben, sofern die Zuverlässigkeit des Diensts bisher noch nicht zufriedenstellend war. Nicht alle Organisationen sind bereit, diese Entscheidung zu treffen. Diese Entscheidung ist auch nicht die einzige mögliche Reaktion auf ein ausgeschöpftes Fehlerbudget, aber es ist diejenige, die am meisten diskutiert wird.
In einem eigenen Modul gehen wir wesentlich ausführlicher auf SLIs, SLOs und Fehlerbudgets ein. Es lohnt sich jedoch, die Aspekte dieser Methoden hervorzuheben, die sich auf den positiven Kreislauf beziehen. Theoretisch bietet es einer Organisation die Möglichkeit, die Zuverlässigkeit eines Diensts zu beschreiben, zu kommunizieren und danach zu handeln. Und zwar auf eine Weise, die alle Beteiligten veranlasst, auf mehr Zuverlässigkeit hinzuarbeiten. Diese Feedbackschleife kann sich als äußerst wichtig erweisen.
Positiver Kreislauf, Teil 2: Post-mortem-Analysen ohne Schuldzuweisungen
Das Konzept einer nachträglichen rückblickenden Analyse eines bedeutenden, typischerweise unerwünschten Ereignisses ist nicht einmal im Entferntesten spezifisch für Site Reliability Engineering. Es ist im Bereich der IT-Vorgänge jedoch nicht ungewöhnlich. Bei SRE muss jedoch erfüllt sein, dass Post-mortem-Analysen ohne Schuldzuweisungen stattfinden. Der Fokus muss während des Vorfalls auf dem Fehler des Prozesses oder der Technologie liegen, nicht auf den Handlungen bestimmter Personen. „Durch welchen Faktor des Prozesses konnte X die Aktion durchführen, die zum Fehler geführt hat? Welche Informationen standen dieser Person nicht zur Verfügung oder wurden in dem Moment nicht angezeigt, als eine falsche Entscheidung getroffen wurde? Welche Sicherheitsvorkehrungen hätten getroffen werden müssen, damit ein solch katastrophaler Ausfall nicht möglich gewesen wäre?“ Diese Art von Fragen wird in einer nachträglichen Analyse ohne Schuldzuweisungen gestellt.
Der Inhalt und die Richtung dieser Fragen sind entscheidend. Wir suchen nach Möglichkeiten, die Systeme oder Prozesse zu verbessern, nicht nach Möglichkeiten, die Personen zu bestrafen, deren Nutzung dieser Systeme oder Prozesse in gutem Glauben zu dem Ausfall beigetragen hat. Denken Sie daran: „Es ist nicht möglich, die gewünschte Zuverlässigkeit durch Entlassungen zu erreichen.“ Unserer Erfahrung nach lernt eine Organisation, die bei jedem Fehler (mit wenigen Ausnahmen) in der Produktion einen Mitarbeiter feuert, nicht aus diesen Vorfällen. Stattdessen bleibt eine Person zurück, die sich nicht mehr zutraut, eigenständig Änderungen vorzunehmen.
Durch einen gut funktionierenden Post-mortem-Analysevorgang wird jedoch ein positiver in einer Organisation eingeleitet. Die Organisation kann aus Ausfällen lernen und ihre Systeme kontinuierlich verbessern, sofern die Analyse sowie sich daraus ergebende Maßnahmen ordnungsgemäß durchgeführt wurden.
Diese Beziehung zwischen Ausfällen und Fehlern ist ein Kernprinzip von SRE, wenn die Organisation diese als Chance sieht, um daraus zu lernen und sich zu verbessern. Die Einleitung von positiven Kreisläufen, um diese Chancen zu nutzen und der Organisation zu einer verbesserten Zuverlässigkeit zu verhelfen, ist ein weiteres wichtiges Kernprinzip.
Weitere Prinzipien und Methoden, die sich auf die Menschen beziehen, die in SRE involviert sind, werden in der nächsten Lektion erläutert.