Hoffnung ist keine Strategie: 7 Prinzipien des Site Reliability Engineering (SRE)

Site Reliability Engineering (SRE) ist ein Ansatz, der Betriebsprobleme so behandelt, als wären es Softwareprobleme. Er wurde ursprünglich im Jahr 2003 von Ben Treynor Sloss, einem Ingenieur bei Google, benannt und beschrieben. Als Disziplin zielt SRE darauf ab, die Verfügbarkeit, Leistung und Effizienz eines bestimmten Systems aufrechtzuerhalten.

SRE lässt sich schwer beschreiben. Es handelt sich dabei eher um einen Ansatz oder eine Disziplin als um eine vorgeschriebene Reihe von Aufgaben, und es nimmt je nach den Bedürfnissen eines bestimmten Unternehmens verschiedene Formen an. Glücklicherweise gibt es sieben Prinzipien des Site Reliability Engineering, die ein SRE-Team zum Erfolg verhelfen können.

Ein Großteil der Softwareentwicklung konzentriert sich zu Recht auf die Erstellung, einschließlich DevOps, einem verwandten, aber eigenständigen Bereich, der sich mehr mit dem gesamten Lebenszyklus eines Produkts befasst. Aber die Arbeit ist noch lange nicht abgeschlossen, wenn das System startet. Im Vorwort des Google-Leitfadens zu SRE stellen die Autoren fest, dass „40 bis 90 % der Gesamtkosten eines Systems erst nach seiner Herstellung anfallen“. SRE befasst sich mit den Geschehnissen nach der Markteinführung und möchte sicherstellen, dass ein Produkt so nutzbar wie möglich bleibt.

Das wichtigste Element von SRE ist die Systemzuverlässigkeit und Betriebszeit. Der beste Dienst der Welt nützt niemandem, wenn er nicht funktioniert. SRE konzentriert sich daher auf die Minimierung von Ausfallzeiten und das Schaffen zuverlässiger Systeme.

SRE-Teams stellen außerdem sicher, dass alle Elemente eines Produkts auf dem neuesten Stand sind, indem sie Software- und Sicherheitsupdates sorgfältig verwalten. Standards und Vorschriften können sich ändern, und Entwicklungsteams sorgen für kontinuierliche Einhaltung.

SRE-Verfahren können auch Kosten reduzieren. Viele der Kernprinzipien von SRE befassen sich mit Effizienzsteigerungen, die zu erheblichen Kosten- und Aufwandsersparnissen führen können, auch durch Automatisierung und Ressourcenmanagement.

Zu den sieben Prinzipien von SRE gehören:    

• Risikoakzeptanz
• Service Level Objectives (Service-Level-Ziele)
• Eliminierung von Mühsal
• Überwachung
• Automatisierung
• Release-Engineering
• Einfachheit

Auch wenn SRE sehr wichtig ist, um Ausfallzeiten zu verwalten und zu begrenzen, bedeutet diese Tendenz nicht, dass das Ziel darin besteht, dass Dienste eine perfekte, zu 100 % verfügbare Servicezuverlässigkeit aufrechterhalten können. Eine der wichtigsten Säulen von SRE ist in der Tat, dass eine 100-prozentige Zuverlässigkeit nicht nur unrealistisch, sondern auch nicht unbedingt ein bevorzugtes Ergebnis ist.

Bei SRE wird das Risiko auf einem Kontinuum verstanden, bei dem die Risikoreduzierung mit zunehmender Annäherung der Zuverlässigkeit an 100 % exponentiell schwieriger und kostspieliger wird. Der Versuch, die Zuverlässigkeit von 99,99 % auf 99,999 % zu verschieben, ist viel schwieriger als eine Verschiebung von 80 % auf 99 %. Die Ressourcen, die benötigt werden, um sich den 100 % immer weiter zu nähern, verringern die Fähigkeit eines Entwicklungsteams, andere Aufgaben zu erledigen, etwa neue Funktionen und Updates zu entwickeln. Stattdessen hat ein Team Fehlerbudgets, die ein angemessenes Maß an Fehlern darstellen.

Ein weiterer Punkt, der gegen absolute Zuverlässigkeit spricht, so kontraintuitiv dies auch erscheinen mag, ist, dass Kunden Zuverlässigkeitsverbesserungen ab einem bestimmten Schwellenwert in der Regel nicht mehr bemerken. Es ist nicht nur kostspielig, sondern bringt auch wenig Nutzen. Im Idealfall wird ein Ziel gesetzt und erreicht, aber nicht übermäßig überschritten.

Stattdessen verwendet SRE Metriken, um die Akzeptanz des Ausfallzeitrisikos zu messen. In einer Metrik würde ein zu 99,99 % zuverlässiges Jahr 52,6 Minuten Ausfallzeit beinhalten. Komplexere Metriken berücksichtigen das Potenzial von Ausfallzeit an einem Standort oder einem Element eines Dienstes, während andere aktiv bleiben.

Ein SRE-Team muss jeden Dienst bewerten und ein akzeptables Maß an Unzuverlässigkeit festlegen. Wie viel Ausfallzeit ist zulässig? Haben verschiedene Arten von Fehlern, die auf unterschiedliche Ursachen zurückzuführen sind, unterschiedliche Auswirkungen auf das Nutzererlebnis? Wie viel (sowohl in Bezug auf den Arbeitsaufwand als auch finanziell) wird es kosten, diesen Wert zu überschreiten? Wo lässt sich ein Gleichgewicht finden?

Die Auswahl von Zielen und das Messen dessen, wie effektiv diese Ziele erreicht werden und warum, ist für ein SRE-Team von entscheidender Bedeutung. Ein Service Level Objective oder SLO ist ein spezifisches, messbares Ziel, das ein Qualitätsniveau darstellt, das ein SRE-Team als Ziel festgelegt hat. Diese SLOs können in Form verschiedener Metriken vorliegen, aber Verfügbarkeit, Abfragerate, Fehlerrate und Antwortzeit sind ihnen allen gemein.

Diese Ziele werden mit einem Service Level Indicator (SLI) gemessen, der eine Rohmessung einer Leistung wie z. B.Latenz darstellt. In diesem Fall wäre der SLI die Latenz und das SLO würde dafür sorgen, dass diese unter einem bestimmten Schwellenwert bleibt. SLOs wiederum können Teil eines Service Level Agreements oder SLAs sein. Das ist ein Vertrag zwischen Anbieter und Nutzer, der die SLOs sowie die Konsequenzen festlegt, wenn sie nicht eingehalten werden.

Die Auswahl von SLOs kann schwierig sein. Im Idealfall sollten SLOs auf das ausgerichtet sein, was für Benutzer am wichtigsten ist. Für einen Cloud-Gaming-Dienst könnte sich das SLO beispielsweise auf geringe Latenz beziehen. Für einen Abrechnungsservice wäre die Latenz jedoch nicht so wichtig.

Im Idealfall verwendet ein Site Reliability Engineer relativ wenige SLOs, um sich auf das Erreichen dieser Ziele zu konzentrieren; am wichtigsten ist es, die Hauptaufgabe richtig zu erledigen. Es ist auch wichtig, realistische Ziele zu setzen. Wie wir bereits besprochen haben, ist Perfektion weder ein realistisches noch ein erstrebenswertes Ziel.

Die Entwickler von SRE legen Wert darauf, „Mühsal“ als eine Kategorie von Arbeit zu definieren, die sich mit der Arbeit überschneidet, aber nicht mit ihr identisch ist. Mühselig sind hingegen jene manuellen Arbeitsaufgaben, die linear skalieren, typischerweise manuell erfolgen und sich wiederholen und die häufig durch Automatisierung erledigt werden können.

Arbeit, die immer wieder erledigt werden muss, wird als mühselig eingestuft; vorzugsweise sollte eine einzelne Aufgabe nur ein- oder zweimal durchlaufen werden müssen. Arbeit, die nicht zu einer Verbesserung des Produkts führt, ist ebenfalls mühsam. „Wenn Ihr Dienst nach Abschluss einer Aufgabe im selben Zustand bleibt, war die Aufgabe wahrscheinlich mühselig“, schreibt Vivek Rau von Google. Funktionsverbesserungen, Fixes und Optimierungen sind keine mühsame Angelegenheit – aber das manuelle Herunterladen von Metriken ist es. Die Reaktion auf einen Vorfall, die eine umfangreiche Koordination zwischen Technikern und Betriebsteams beinhalten kann, ist nicht mühselig, und die Taktik für das Vorfallmanagement sollte vor der Veröffentlichung geplant werden.

Es gibt auch kognitive Mühsal. Hatten Sie schon einmal ein Grundrezept, das Sie immer wieder verwenden, bei dem Sie aber jedes Mal die Zutaten und Mengenangaben nachschlagen müssen? Das ist kognitive Mühsal: Es ist Verschwendung von Zeit und Mühe, etwas immer wieder neu lernen zu müssen. Stattdessen fordert SRE die Erstellung von mehr Leitfäden und Standards, die es überflüssig machen, sich ständig an Methoden und Aufgaben zu erinnern oder diese neu zu erlernen.

Einer der wichtigsten Bestandteile des Site Reliability Engineering ist die Überwachung: der Einsatz von Tools zur kontinuierlichen Messung, Analyse und Verbesserung der Funktionen und der Leistung. Zu diesen Kernfunktionen gehören oft die sogenannten „vier goldenen Signale“ der Überwachung:

Latenz: Wie lange dauert es grundsätzlich, eine Anfrage zu erfüllen? Beachten Sie, dass dies variieren kann, je nachdem, ob die Anfrage erfolgreich war oder nicht. Manchmal kann die Bearbeitung einer Fehlermeldung erheblich länger dauern.

Verkehr: Wie hoch ist die Last oder die Nachfrage, die auf den Dienst zukommt? Die spezifischen Einheiten können variieren. vielleicht sind es Seitenaufrufe, vielleicht sind es Transaktionen, vielleicht sind es HTTP-Anfragen.

Fehler: Zu den Fehlern, die in der Regel anhand der Rate gemessen werden, gehören das Abrufen falscher Daten, das langsamere Abrufen von Daten als in einem SLA festgelegt oder das Nichtabrufen von Daten.

Sättigung: Im Grunde ist die Sättigung ein Maß dafür, wie nahe ein Dienst an der Kapazitätsgrenze ist. Es ist wichtig, die Sättigung zu verstehen, da einige Dienste ausfallen, sich verlangsamen oder mehr Fehler erzeugen, wenn sie sich einer Sättigung von 100 % nähern.

Es gibt viele Überwachungstools, die Daten erfassen, Benchmarks festlegen, Probleme beheben und analysieren, nützliche Observability-Dashboards bereitstellen und SREs auf potenzielle Ausfälle oder andere Probleme aufmerksam machen können. Wichtig ist auch, dass Sie nach der Behebung eines Vorfalls aussagekräftige Postmortem-Berichte erstellen, in denen der Kontext des Vorfalls, die Ursachen und Auslöser, die Auswirkungen, die Lösungsmethode und die Lehren für die Zukunft erläutert werden. Eine detaillierte, objektive Analyse kann von unschätzbarem Wert sein, wenn es darum geht, einen Fehler nicht zweimal zu machen.

Wie bei vielen anderen Elementen der modernen Technologie besteht das Ziel der Automatisierung in einem Workflow darin, Techniker von sich wiederholenden Aufgaben, die keinen Mehrwert schaffen, zu befreien. In der neu gewonnenen freien Zeit können sie sich dann Aufgaben widmen, die die Automatisierung nicht erledigen kann: Kreation, Ideenfindung, umfassende Anleitungen und mehr.

Automatisierung kann für die folgenden Ziele besonders wertvoll sein:

Konsistenz: Der Nachteil sich wiederholender, manueller Aufgaben besteht nicht nur darin, dass sie langweilig sein können und Zeit für wertvollere Tätigkeiten wegnehmen. Durch ein automatisiertes Durchführen solcher Aufgaben, wie beispielsweise der Erstellung von Benutzerkonten, können Fehler und Inkonsistenzen nahezu ausgeschlossen werden. Ein neuer Mitarbeiter könnte Dinge anders machen als ein alter; ein Benutzer könnte versehentlich einen Wert in das falsche Feld eingeben. Ein automatisierter Prozess wird dies (im Allgemeinen) nicht tun.

Skalierbarkeit: Skalierbarkeit ist ein großer langfristiger Vorteil der Automatisierung. Nehmen wir unser vorheriges Beispiel der Erstellung eines Benutzerkontos. Wenn Kontenerstellungen exponentiell zunehmen, steigt auch die Arbeitslast der Person, die für die Einrichtung der Konten verantwortlich ist, exponentiell an und zieht diesen Mitarbeiter von anderen, potenziell wertvolleren Aspekten seines Aufgabenbereichs ab. Ein automatisiertes System hat dieses Problem nicht.

Schnelligkeit: Bestimmte Aufgaben, wie das Finden und Beheben von Fehlern im Code, können einen Menschen sehr viel Zeit kosten. Automatisierte Softwaresysteme sind in der Lage, riesige Datenmengen zu überwachen, und können durch fortschrittliche Mustererkennung und andere Tools Fehler oft schneller erkennen als Menschen. Fixes können genauso schnell vorgenommen werden, oft ohne menschliches Zutun.

Natürlich lauern bei jedem Automatisierungsprozess Gefahren. Dazu gehören:

Vorlaufkosten: Automatisierungen müssen erstellt werden, bevor sie eingesetzt werden können. Dies kann viel Zeit, Aufwand und sogar Hardwarekosten verursachen. Der Wert der Automatisierung muss als Gleichgewicht zwischen dem Aufwand für ihre Erstellung und den tatsächlichen Ressourcen betrachtet werden, die nach der Einführung eingespart werden.

Wartung: Automatisierte Aufgaben mögen den Anschein erwecken, als ob sie ewig laufen könnten, aber das ist oft nicht der Fall. Der Automatisierungscode muss auf dem neuesten Stand gehalten und mit anderen Code und Systemupdates synchronisiert werden. Wenn neue Funktionen hinzugefügt werden, muss der Automatisierungscode möglicherweise auch durch menschliches Eingreifen aktualisiert werden, um neue Aktionen aufzunehmen oder Fehler zu vermeiden.

Künstliche Intelligenz eröffnet einige neue und aufregende Möglichkeiten für SRE, am deutlichsten im Bereich der Automatisierung. Sowohl die anfänglichen Kosten als auch die Wartung können theoretisch durch neue KI-Modelle reguliert werden. Allerdings bringt KI auch neue potenzielle Problembereiche mit sich: vor allem im Bezug auf Halluzinationen, Sicherheit und Datenschutz.

Release-Engineering ist eine Teildisziplin des Software-Engineering, die sich speziell auf die Schritte konzentriert, die zur Veröffentlichung von Software erforderlich sind. Zu diesen Schritten gehören Versionierung, Veröffentlichungszeitpläne, kontinuierliche oder periodische Builds, die Auswahl und Erfassung von Release-Metriken und vieles mehr. Bei SRE wird das Release-Engineering von Anfang an integriert und nicht erst im Nachhinein. Ziel ist es, eine zufällige Zuweisung von Release-Engineering-Aufgaben in letzter Minute zu vermeiden.

Release-Engineering als Disziplin umfasst mehrere Schlüsselprinzipien. Dazu gehören:

Automatisierung und Self-Service: Im Idealfall können viele Release-Prozesse automatisiert werden und erfordern nur minimale oder gar keine Interaktionen von Technikern. Dies gewährleistet schnelle und stabile Releases.

Schnelligkeit: Beim Release-Engineering wird eine Philosophie der schnellen, häufigen Veröffentlichungen bevorzugt. Wenn Sie schnell neue Versionen herausbringen, vielleicht sogar so oft wie möglich, gibt es weniger Änderungen zwischen den Versionen. Diese Geschwindigkeit erleichtert das Testen und die Fehlersuche.

Hermetische Builds: Build-Prozesse sollten völlig unabhängig von der Build-Maschine selbst sein und die gängigsten Compiler, Bibliotheken und Tools verwenden. „Wenn zwei Personen versuchen, dasselbe Produkt mit derselben Revisionsnummer im Quellcode-Repository auf verschiedenen Maschinen zu erstellen, erwarten wir identische Ergebnisse“, schreibt Dinah McNutt von Google.

Standards und Richtlinien: Aus Sicherheitsgründen ist es wichtig, dass bestimmte Aufgaben überprüft werden, einschließlich der Bereitstellung, Änderungen am Quellcode, neuen Versionen und Änderungen an der Build-Konfiguration.

Ein Großteil des Site Reliability Engineering dient der Einfachheit. Software ist, schreibt Max Luebbe von Google, „von Natur aus dynamisch und instabil“. Vor diesem Hintergrund ist Einfachheit der Schlüssel, um potenzielle Probleme zu minimieren und zu versuchen, diese inhärente Instabilität einzudämmen.

Zu diesem Zweck fördert Site Reliability Engineering verschiedene Aufgaben, die ein Projekt vereinfachen und verdeutlichen können.

1. Es ist hilfreich, sorgfältig auszuwählen, welche Funktionen aufgenommen werden sollen, aber es kann ebenso hilfreich sein, einfach alle Funktionen zu streichen, die den Nutzen des Produkts nicht wesentlich erhöhen. Mehr Funktionen bedeuten mehr Komplexität.
2. Kleinere, häufigere Releases ermöglichen eine viel einfachere Fehlersuche und -behebung. Eine neue Version mit Dutzenden neuer Funktionen könnte Fehler verursachen, die sehr schwer aufzuspüren sind. Ein Release mit einer neuen Funktion? Potenzielle Probleme können nur von einer Stelle kommen.
3. Ebenso kann es verlockend sein,APIs durch die Verwendung mehrerer Endgeräte, Microservices und mehr komplexer zu gestalten. Das sollte vermieden werden. Einfachere APIs lassen sich schneller einrichten, benötigen weniger Dokumentation und reduzieren den Zeitaufwand und die Kosten für die Integration.