Site Reliability Engineering in der Praxis

Site Reliability Engineering (SRE) ist per se nichts Neues. Der Begriff existiert bereits seit geraumer Zeit, die mit ihm erfasste Tätigkeit freilich noch länger: Die Anwendung von Software-Engineering und seine Prinzipien im Kontext operativer Problem- und Aufgabenstellungen war auch vor der Einführung des Berufsbilds des Site Reliability Engineer keinesfalls unüblich. Die Proaktivität in Software-Entwicklung und -Wartung, die dadurch erreicht werden soll, stellt deshalb nicht unerhebliche Vorteile in Aussicht: Mehr operative Effizienz, eine datenfundierte Grundlage zur Roadmap-Planung sowie ganz allgemein mehr Uptime und Verlässlichkeit sind allesamt Tragsäulen für langfristigen Erfolg. Kein Wunder also, dass SRE auch weiterhin anhaltend starken Auftrieb erfährt. 

Im Folgenden beleuchten wir, worauf bei der Implementierung von Site Reliability Engineering zu achten ist, gehen auf seine Leitprinzipien ein und zeigen Best Practices auf, mit denen Sie auf dem Weg zu seiner Umsetzung den höchsten Reifegrad erreichen.

Was ist SRE?

SRE bzw. Site Reliability Engineering bezeichnet die Disziplin, Problemstellungen der Bereiche DevOps und Operations durch Lösungsansätze aus der Software-Entwicklung zu adressieren. Dies erfolgt häufig proaktiv: Code sowie auch interne Anwendungen oder Services werden ausgerollt, um antizipierten Problematiken hinsichtlich Verlässlichkeit oder Performance vorzubeugen. Praktiziert wird SRE bereits seit vielen Jahren. Seine Popularität aus jüngerer Zeit geht jedoch auf Google zurück, das im März 2016 mit dem Titel Site Reliability Engineering: How Google Runs Production Systems ein umfassendes Handbuch hierzu veröffentlichte.

Gewisses Potenzial für Verwirrung birgt die Abkürzung des Begriffs, da sie sowohl den Beruf des Site Reliability Engineer als auch die in Dev- und IT-Teams angewandte Praxis des Site Reliability Engineering beschreibt. 

Ihre Organisationsstruktur richten SRE-Teams häufig am Funktionsbereich oder Service aus, den sie jeweils unterstützen, verteilen dabei etwa auch einzelne Site Reliability Engineers auf verschiedene Dev-Teams. Auf diese Weise sind sie in der Lage, potenzielle Bedenken in die Roadmap-Planung einzubringen und in enger Abstimmung mit QA-Teams zusammenzuarbeiten. Dabei sind sie an der Feature-Auslieferung ebenso beteiligt wie am Management von Staging- und Produktionsumgebungen. 

Konzeptionell möglich ist auch die Einrichtung eines eigenen Funktionsbereichs für SRE. Ein so strukturiertes SRE-Team übernimmt Aufgaben rund um Anwendungs- und Infrastruktur-Monitoring, arbeitet Standards für Metrics zur Verlässlichkeit aus, dokumentiert Probleme oder Fehler im Zusammenhang mit Release-Deployments und ist im Bereitschaftsdienst auf Abruf verfügbar. Ganz unabhängig von ihrer Organisationsstruktur ist das Ziel der Site Reliability Engineers stets die Gewährleistung bzw. Optimierung von Performance und Verfügbarkeit.  

DevOps oder SRE?

Bei vielen Unternehmen sind Initiativen rund um DevOps derzeit in vollem Gange. Die Frage, wie SRE sich vom DevOps-Themenkomplex unterscheidet, lässt sich allgemein damit beantworten, dass beide Hand in Hand gehen. Ein zwingender Bestandteil ist SRE im Kontext der Umsetzung einer DevOps-Kultur zwar nicht. Es wird jedoch häufig von Unternehmen implementiert, die auf diesem Weg schon weiter fortgeschritten sind: Mit zunehmendem Reifegrad der DevOps-Initiative geht zumeist auch der Einzug von SRE einher.

SRE ist also vielmehr organische Ergänzung denn Konzept-Gegenspieler von DevOps: Umgesetzt von einem dedizierten Team, tragen die proaktiven Prozesse von SRE letztlich zur Stärkung Ihrer DevOps-Initiative bei. Wie Sie dies angehen – integriert in Ihre Dev- und IT-Teams oder mit einem eigenen Funktionsbereich – ist dabei eine Entscheidung, für die Sie zunächst die im Allgemeinen mit SRE verbundenen Aufgaben kennen sollten.

Aufgaben des SRE-Teams

Im Kern geht es bei der Arbeit von Site Reliability Engineers um die Bestimmung von Kenngrößen: Diese sollen einen klaren Rahmen dafür definieren, ab wann Anwendungen, Services und Infrastruktur als performant und verlässlich gelten. Im Tagesgeschäft umfasst dies Aufgaben wie die Instrumentierung neuer Monitoring-Lösungen, die aber weit darüber hinaus bis zur Entwicklung von Custom-Anwendungen für den technischen Support reichen. So rollen sie etwa auch Code mit Bug Fixes in die Produktion aus, implementieren neue Features oder adressieren als Incident Responder Probleme direkt bei ihrem Auftreten. In enger Abstimmung mit dem Support-Team sorgen sie dabei dafür, dass ein konsistent positives Kundenerlebnis gewährleistet bleibt.

Im Kundenerlebnis liegt letztlich auch ihre Schlüsselrolle. Denn sie machen transparent, wie Endnutzer:innen die CX Ihrer Produkte wahrnehmen und wie Performance und Verlässlichkeit Ihrer Systeme in diesem Kontext dokumentiert werden können. Hierfür loten sie die exakten Grenzen der Service Delivery aus – also der Spanne zwischen dem, was Ihre Dev-Team ausliefern und dem, was Endnutzer:innen erhalten. Überführt in Methodiken für das Monitoring von Verlässlichkeit und Performance, ermöglichen es diese Erkenntnisse Ihren internen Teams, Risiken zu antizipieren und proaktiv Software-Optimierungen anzustoßen. 

Als Mittler, die ihre Erkenntnisse in Product- und Dev-Teams weitertragen, sorgen SREs so dafür, dass in punkto Verlässlichkeit sämtliche Bereiche des Unternehmens auf gleicher Linie sind. Entwickler:innen können diese Maßgaben wiederum nutzen, um bei neuen Feature Releases oder der Optimierung von Services in der Produktion datenfundierte Entscheidungen zu treffen. 

Leitprinzipien und Methodiken von SRE

Der Definition von Google nach lässt sich die Quintessenz dessen, was SRE als Prinzip ausmacht, im weitesten Sinne als Offenheit für Risiken beschreiben. Konkret bedeutet dies: Verlässlichkeit und Performance von Produktionsumgebungen sollten sich maßvoll an Business-Anforderungen rund um kontinuierliche Innovation und Deployment-Frequenz orientieren. Ein Beispiel wäre ein weniger kritisches Service-Element: Sofern sich dies nicht auf Kundenseite bemerkbar macht, sind dafür keine 99.999 % Verfügbarkeit vonnöten. Komplett vergeudet wäre die Zeit, wenn der mit ihrer Gewährleistung verbundene Aufwand obendrein noch Verzögerungen im Deployment-Cycle nach sich zöge. 

Ganz ähnlich wie bei DevOps soll also auch SRE die teilweise konträren Anforderungen aus Entwicklung und Operations in Einklang bringen. Diese Funktion weitet sich dabei im Zuge der voranschreitenden Umsetzung von DevOps-Prinzipien fortlaufend aus. So dienen die Prozesse, die SREs in Dev-Workflows rund um CI/CD einführen, grundsätzlich der Optimierung von Performance und Verfügbarkeit. An welchen Punkten dabei womöglich weniger Stabilität als Speed gefragt ist, eignen sie sich im engen Austausch mit den DevOps-Teams sukzessive an. Dies sowohl im Hinblick auf kritische Anwendungs- und Infrastrukturkomponenten als auch auf solche, bei denen die Zügel lockerer gehalten werden können.

Teamübergreifende Transparenz rund um den Health-Status sämtlicher Anwendungen und Systeme steht dabei im Mittelpunkt: Klarheit in dieser Hinsicht ermöglicht es SREs, das jeweils akzeptable Risikolevel zielführend abzuwägen. Die anvisierte Verfügbarkeit und tolerierbaren Performance-Probleme hängen dabei auch vom jeweils betroffenen Service ab. Hier fordern die SRE zugrunde liegenden Leitprinzipien konstantes Experimentieren sowie proaktive Methodiken zur Erfassung des Health-Status der jeweils unterstützten Services.

Modell zur Umsetzung und Reifegradbestimmung

Diverse Aspekte des SRE-Aufgabenkatalogs sind durchaus auch von Software-Engineers umsetzbar. Die Frage ist, ob dadurch die SRE zugrunde liegenden Prinzipien und Methodiken auch vollumfänglich umgesetzt werden. Daher haben wir ein Modell ausgearbeitet, über das Sie sämtliche dafür nötigen Aspekte abdecken und zugleich den Reifegrad Ihrer Initiative bestimmen können.

Auf dem Weg zur vollumfänglichen Umsetzung von SRE beinhaltet das Modell drei Grundelemente:

1. Eigens für SRE eingerichtetes Team (bzw. mindestens eine damit betraute Person)
2. Tiefgehende Einbindung von SRE in sämtliche Prozesse der Product-, Dev- und Ops-Teams
3. Eigenständigkeit des SRE-Bereichs in punkto Workflow-Automatisierung und Code-Entwicklung für nahezu alle Anwendungs- und Systembereiche

Diese drei Aspekte definieren den Reifegrad Ihrer SRE-Initiative. Die Einrichtung eines eigens mit SRE betrauten Teams bzw. die Einstellung von entsprechenden Mitarbeiter:innen bildet dabei den Ausgangspunkt. Eine fortgeschrittenere Umsetzung zeigt sich in der aktiven Einbindung des Teams in Prozessstrukturen. Bei diesem Reifegrad trägt es zu Roadmap-Entscheidungen und QA-Prozessen bei und ist in Deployment-Workflows und das Incident Management involviert. 

Vollumfänglich umgesetzt ist SRE schließlich, wenn der zugehörige Funktionsbereich in hohem Maße eigenständig agiert. Dies zeigt sich etwa darin, dass er in Eigenregie Workflows automatisiert, Anwendungen entwickelt und Lösungen rund um Monitoring und Alerting verwaltet. Dabei bringt er sich proaktiv in nahezu alle Entscheidungsprozesse ein. Potenzielle Bedenken in punkto Performance und Verlässlichkeit bringt er so frühzeitig an den Tisch und verhindert, dass diese erst adressiert werden, wenn das Kind bereits in den Brunnen gefallen ist.

Monitoring-, CI/CD- und bereichsübergreifende Automatisierung

Proaktiv zu agieren bedeutet, automatisiert zu agieren. Daher werden SREs automatisierte Prozesse in jeden nur erdenklichen Aspekt etwa der Erkennung und Behebung von Problemen bringen, der dies erlaubt. Zentral hierfür: Von CI/CD-Pipelines bis hin zum Monitoring von Produktionsumgebungen benötigen sie umfassende Transparenz ebenso wie die Befugnis, die bei proaktiv aufgedeckten Problemen rund um Performance und Verlässlichkeit nötigen Anpassungen eigenständig zu implementieren.

DevOps und IT haben heute Technologien rund um Automatisierung und Monitoring sowie künstliche Intelligenz und maschinelles Lernen an der Hand. Sie positionieren SRE-Teams bei der Erkennung von, Reaktion auf und Behebung von Problemen auf einzigartige Weise: Bei hohem DevOps- und SRE-Reifegrad machen sie diese bereits im Staging aus, ziehen dabei etwa auch automatisierte Workflows rund um das Incident Management auf oder entwickeln Systeme, die Korrekturen autonom implementieren. Zudem bestimmen SREs kritische Anwendungs- und Infrastrukturkomponenten und grenzen so den Rahmen ein, in dem schwerwiegende Probleme auftreten können.

Service-Levels (SLIs, SLOs und SLAs)

Service-Levels dienen SRE-Teams dazu, den Health-Status digitaler Produkte und Services für sämtliche Stakeholder klar nachvollziehbar abzubilden. Grundlage hierfür bilden all jene Komponenten und ihnen zugehörigen Metrics, die für die Gewährleistung einer ansprechenden CX kritisch sind. Insbesondere wichtig sind dabei die Punkte, an denen durch eine oder mehrere Komponenten Funktionalitäten für externe Kund:innen umgesetzt werden. An diesen Schnittpunkten, Systemgrenzen genannt, gilt es, die Metrics für Service-Level-Indikatoren und -Ziele zu definieren. Diese liefern dann ein aussagekräftiges und objektives Maß für die System-Performance und -zuverlässigkeit. 

• Service-Level-Indikatoren (SLIs) bestimmen die Metrics, anhand derer die Verfügbarkeit eines Systems quantifiziert wird.
• Service-Level Objectives (SLOs) bzw. Service-Level-Ziele legen die Maßgaben dafür zugrunde, welche Verfügbarkeit ein System aufweisen muss.
• Service-Level Agreements (SLAs) bilden den vertraglichen Rahmen dafür, was geschieht, wenn ein System die SLO-Ziele verfehlt.

Service-Levels gehören zwar nicht grundsätzlich zum Aufgabenspektrum von SREs. Dennoch sind sie häufig mit ihnen betraut. Anhand der im Rahmen der SLIs erfassten Metrics lassen sich Ziele für die System-Performance in SLOs festhalten, dies etwa gemäß der im Handbuch von Google als goldene Signale definierten Aspekte Latenz, Traffic, Fehlerrate und Sättigung. Ein Beispiel wäre, die Anzahl der bei einem API-Aufruf erfolgreichen bzw. fehlgeschlagenen Anfragen (SLI) im Verhältnis zum Prozentwert der Anfragen zu erfassen, die für eine ansprechende CX mindestens erfolgreich sein müssen (SLO).

Um ein klareres Bild davon zu erhalten, wie anspruchsvoll sie die Zielvorgaben der mit Kund:innen vereinbarten SLAs anlegen können, setzen SRE-Teams die SLOs für kritische Anwendungs- und Service-Komponenten häufig besonders strikt an. Von diesen ausgehend können sie über Fehlerbudgets ermitteln, wie schnell Probleme behoben werden müssen, um weiterhin SLO-konform zu bleiben. Anhand von Service-Levels können die Teams ihre Metrics in einen aggregierten Kontext setzen, der Uptime, Performance und Verlässlichkeit für das gesamte Unternehmen transparent abbildet. Auf Leadership-Ebene wiederum kann über sie direkt die Compliance sämtlicher Teams, Anwendungen und Services eingesehen und so präzise nachvollzogen werden, wie es um den Health-Status der Systeme bestellt ist.

Ihr direkter Weg zu Best Practices für SRE

SRE – und mit ihm proaktives Monitoring Ihrer Teams und Systeme auf Problematiken rund um Performance und Verlässlichkeit – lassen sich nicht über Nacht umsetzen. Erst recht nicht die zugehörigen Best Practices. Doch nicht nur Ihre DevOps-Teams werden das Ergebnis begrüßen, sondern noch viel mehr auch Ihre Kund:innen.