Was ist ein SRE?

Ein Site Reliability Engineer (SRE) ist die Person, die dafür sorgt, dass Produktionssysteme im großen Maßstab laufen, mit Code, Messung und Automatisierung statt manueller Handarbeit. Die Rolle entstand 2003 bei Google, geprägt von Ben Treynor Sloss, und die treffendste Definition stammt bis heute von ihm.

„SRE ist das, was passiert, wenn man einen Softwareentwickler bittet, ein Operations-Team zu entwerfen." – Ben Treynor Sloss

Was ein SRE tatsächlich macht

Kapitel 1 des SRE-Buchs von Google nennt acht Verantwortungsbereiche: Verfügbarkeit, Latenz, Performance, Effizienz, Change-Management, Monitoring, Notfallreaktion und Kapazitätsplanung. Ein paar Praktiken aus dieser Liste sind es, die SRE vom Betrieb unterscheiden, wie er früher praktiziert wurde.

Service Level Objectives. SREs definieren in messbaren Größen, was „zuverlässig genug" heißt: eine Ziel-Latenz, ein Verfügbarkeitsprozentsatz, eine akzeptable Fehlerrate. Ein SLO macht aus der Frage „Läuft das System rund?" eine Zahl, die jeder überprüfen kann. Die zugrunde liegende Messung, auf der das SLO beruht, ist ein Service Level Indicator (SLI); ein Service Level Agreement (SLA) ist der Vertrag, der einem Kunden ein SLO zusichert, mit Konsequenzen, wenn es verfehlt wird.

Fehlerbudgets. Die originellste Idee der Disziplin beginnt mit einer Behauptung, die zunächst falsch klingt: 100 % Zuverlässigkeit sind für nahezu jeden Service das falsche Ziel. Liegt das SLO bei 99,9 % Verfügbarkeit, ist das Fehlerbudget die verbleibenden 0,1 %, rund 43 Minuten Ausfallzeit pro Monat. Das Budget formalisiert, wie viel Ausfallzeit das Unternehmen im Tausch gegen Entwicklungstempo zu tolerieren bereit ist. Solange es positiv ist, dürfen Releases schneller laufen und das Team kann mit weniger Testing auskommen. Ist es aufgebraucht, werden Launches eingefroren, und das Team konzentriert sich so lange auf Zuverlässigkeitsarbeit, bis sich das Budget wieder auffüllt. Dieser eine Mechanismus bringt die Anreize der Entwicklung mit der Zuverlässigkeit in Einklang, gesteuert vom Budget statt von einer Person.

Monitoring. Kapitel 6 des SRE-Buchs benennt die vier goldenen Signale (Four Golden Signals) als die Kernsymptome nutzerseitiger Probleme: Latenz, Traffic, Fehler und Sättigung. Außerdem teilt es die Ausgaben des Monitorings in drei Kategorien: Pages, die sofort einen Menschen verlangen, Tickets, die irgendwann Aufmerksamkeit brauchen, und E-Mail-Benachrichtigungen, die ungelesen auflaufen. Aufgabe des Monitorings ist es, jedes Signal in der richtigen Kategorie zu halten. Ein SRE-Team, das in Pages für Dinge ertrinkt, die eigentlich Tickets sein sollten, hat ein Monitoring-Problem, bevor es ein Zuverlässigkeitsproblem hat.

Notfallreaktion. Wenn etwas kaputtgeht, führen SREs die Untersuchung. Sie definieren die Runbooks, tragen den Pager, schreiben die Postmortems und verantworten die Korrekturmaßnahmen. Googles Haltung ist dabei ausdrücklich frei von Schuldzuweisungen. Rund 70 % der Ausfälle, so Googles Erfahrung, gehen auf Änderungen an einem laufenden System zurück, weshalb ein SRE zum Rollback greift, bevor er die Ursache überhaupt verstanden hat.

Toil Reduktion. Das Prinzip, das den Rest erst möglich macht: Höchstens 50 % der Zeit eines SRE sollten in Toil fließen, also in die manuelle, repetitive, automatisierbare Arbeit, die linear mit dem System mitwächst und den Laden am Laufen hält, ohne irgendetwas voranzubringen. Die anderen 50 % gehen in Engineering-Arbeit, die künftiges Toil beseitigt: Tooling, Automatisierung, Plattformverbesserungen und die Observability, die künftige Incidents überhaupt erst lesbar macht. Verbringt ein Team dauerhaft mehr als die Hälfte seiner Zeit mit Toil, ist es Googles Politik, einen Teil dieser Arbeit an das Entwicklungsteam zurückzugeben, statt sie unbegrenzt im SRE-Team versacken zu lassen.

Kapazitätsplanung, Performance, Effizienz. Die unglamouröse Hälfte des Jobs: Nachfrage prognostizieren, Infrastruktur dimensionieren, die 20 % der Ressourcen finden, die 80 % der Kosten verursachen. Weniger fotogen als Incident Response, aber in den meisten Produktionsumgebungen stecken genau hier die größten Zuverlässigkeitsgewinne.

Auffällig ist, was nicht auf dieser Liste steht. SREs bedienen keine Server von Hand, jagen keinen Tickets hinterher und sind nicht dazu da, den Frust aufzufangen, damit die Entwickler es nicht müssen. Der Kern der Disziplin lautet: Betriebsprobleme sind Softwareprobleme, und Softwareprobleme löst man mit Software.

Woher SRE kommt

2003 kam Ben Treynor Sloss zu Google, mit einem Auftrag, der einfach klang und sich als ganz eigene Disziplin entpuppte: die Produktion im Planetenmaßstab am Laufen halten, ohne das Operations-Team linear mit dem System mitwachsen zu lassen. Die klassische Antwort wäre gewesen, mehr Sysadmins einzustellen. Sloss machte es anders. Er stellte Softwareentwickler ein, gab ihnen ein Betriebsproblem und ließ sie es so lösen, wie Softwareentwickler alles lösen: mit Code, mit Messung und mit einer tiefen Abneigung gegen manuelle Wiederholung.

Öffentlich formulierte er das Modell erstmals 2014. Bis 2016 war das Team von sieben Engineers auf über tausend angewachsen. Zwei Jahre später veröffentlichte Google das Playbook als Buch, Site Reliability Engineering: How Google Runs Production Systems, und stellte den vollständigen Text kostenlos online. Heute läuft die Disziplin bei Airbnb, Dropbox, IBM, LinkedIn, Netflix, Wikimedia und in den meisten großen Engineering-Organisationen, die Produktion ernst nehmen.

Warum SRE wichtig ist

Organisationen führen SRE ein, weil die Alternativen irgendwann nicht mehr skalieren.

Zuverlässigkeit wird messbar. Ohne SLO ist „Läuft das System rund?" das, was die lauteste Stimme im Raum behauptet. Mit einem SLO darf das Team über vieles streiten, aber nicht mehr darüber, ob die Kunden die zugesagte Qualität bekommen.

Dev und Ops hören strukturell auf, sich zu bekämpfen. Ohne Fehlerbudget ist jedes Release eine Verhandlung zwischen Entwicklern, die ausliefern wollen, und dem Betrieb, der Stabilität will. Mit einem Fehlerbudget sehen beide Seiten dieselbe Zahl, und die Frage wird rechnerisch statt politisch.

Betriebswissen übersteht Personalwechsel. Postmortems, Runbooks und der Hang, Dinge aufzuschreiben, verwandeln das, was früher in den Köpfen von drei erfahrenen Engineers steckte, in etwas, das der Rest des Teams nachlesen kann. Der erfahrene Engineer kann in den Urlaub fahren; das Gedächtnis des Teams fährt nicht mit.

SRE vs. DevOps

DevOps ist eine kulturelle Bewegung. Sie besagt, dass diejenigen, die die Software bauen, sie auch betreiben sollten; dass Entwicklung und Betrieb keine getrennten Abteilungen sein sollten, die sich die fertige Software über den Zaun werfen; und dass schnelle Feedback-Schleifen mehr zählen als Förmlichkeiten. Sie ist eine Philosophie davon, wie Teams arbeiten sollten.

SRE ist ein Beruf. Es ist die konkrete, messbare, code-getriebene Umsetzung dieser Philosophie in einer klar umrissenen Rolle. Das SRE-Buch beschreibt es als „eine spezifische Implementierung von DevOps mit ein paar eigenwilligen Erweiterungen". In der Praxis gibt es eine pointiertere Variante: class SRE implements DevOps.

Wie SRE-Teams aufgebaut sind

Dieselbe Rolle kann in verschiedenen Organisationen ganz unterschiedlich verortet sein. Die Muster, die in der Praxis am häufigsten auftauchen:

Eingebettet (Embedded). Ein SRE (oder ein kleines Duo) sitzt in einem Software-Engineering-Team und verantwortet die Zuverlässigkeit der Services dieses Teams. Am häufigsten in reifen Engineering-Organisationen, in denen Zuverlässigkeit ein gemeinsames Anliegen ist.

Infrastruktur oder Plattform. Ein zentrales SRE-Team verantwortet gemeinsam genutzte Systeme: Observability-Stacks, Deployment-Pipelines, den Kubernetes-Cluster, auf dem alles andere läuft. Es ist die Plattform, auf der jedes Produktteam aufbaut.

Produkt oder Anwendung. Ein eigenes SRE-Team verantwortet die Zuverlässigkeit eines bestimmten Produkts, meist eines, das groß genug ist, dass das Produktteam die Produktion nicht glaubwürdig allein stemmen kann.

Beratend (Consulting). SREs beraten Produktteams zu Zuverlässigkeitspraktiken, ohne den Betrieb direkt zu verantworten. Google nennt sie intern „Customer Reliability Engineers".

Die meisten großen Organisationen landen am Ende bei einer Mischform: ein zentrales Plattformteam für die gemeinsame Infrastruktur, eingebettete SREs in den kritischen Produktteams und beratende SREs, die über den Rest hinweg unterstützen.

Das Fazit

SRE behandelt Zuverlässigkeit als eine messbare, budgetierbare und konstruierbare Eigenschaft des Systems, verantwortet von Software-Engineers, die sich weigern, Betriebsprobleme von Hand zu lösen. Die Alternative ist eine Kultur der Pager-Helden und eine Wand voller Dashboards.