Site Reliability Engineering – kurz SRE – wurde von Google erfunden und hat sich seitdem weltweit als eigenständige Disziplin im IT-Betrieb etabliert. Der Grundgedanke ist verblüffend einfach: Software-Engineering-Methoden auf Operations-Probleme anwenden. Anstatt manuelle, fehleranfällige Prozesse zu wiederholen, automatisieren SRE-Teams alles, was sich automatisieren lässt – und messen alles andere. Was nicht gemessen wird, kann nicht verbessert werden – dieses Prinzip zieht sich durch alle Aspekte der SRE-Praxis.
Die Kernidee hinter SRE
Klassische IT-Operationsteams und Entwicklungsteams haben oft gegensätzliche Ziele. Entwickler wollen neue Features schnell ausliefern. Operations möchte Stabilität und Ausfallsicherheit. SRE löst diesen Konflikt durch klare Vereinbarungen: Es wird gemeinsam definiert, wie zuverlässig ein System sein muss – und wie viel Ausfallzeit akzeptabel ist. Diese Kennzahl nennt sich Error Budget und ist das Herzstück der SRE-Philosophie. Sie macht aus einem emotionalen Konflikt eine sachliche Entscheidung.
Ist das Error Budget aufgebraucht, werden keine neuen Features mehr ausgerollt – bis das Budget wieder aufgefüllt ist. Damit wird Zuverlässigkeit nicht als Selbstzweck betrachtet, sondern als produktstrategische Entscheidung. Teams können bewusst entscheiden: Wir nehmen dieses Risiko in Kauf, um schneller zu liefern. Diese Transparenz schafft Vertrauen zwischen Entwicklung und Betrieb auf eine Art, die rein kulturelle Ansätze selten erreichen.
Toil: Die stille Produktivitätsfalle
Ein zentrales Konzept in SRE ist Toil – manuelle, wiederholbare und auf Dauer wertlose Arbeit. Toil ist zum Beispiel das händische Neustarten eines Dienstes nach einem bekannten Fehler, das Skalieren einer Datenbank per Hand oder das Bearbeiten von Tickets, die eigentlich ein Skript erledigen könnte. Toil ist dabei nicht dasselbe wie schlechte Arbeit – oft steckt viel Kompetenz dahinter. Das Problem ist, dass Toil keinen dauerhaften Wert erzeugt: Dieselbe Aufgabe muss morgen wieder erledigt werden.
SRE-Teams haben das Ziel, Toil unter 50 Prozent ihrer Arbeitszeit zu halten. Alles darüber ist ein Alarmsignal: Das Team kämpft ums Überleben statt das System zu verbessern. Der erste Schritt zur Toil-Reduktion ist seine Sichtbarmachung – deshalb erfassen gute SRE-Teams, wie viel Zeit pro Woche für welche Aufgabentypen aufgewendet wird. Was sichtbar ist, kann adressiert werden.
Service Level Indicators und Objectives
SRE arbeitet mit präzisen Kennzahlen für Dienstqualität. Ein Service Level Indicator (SLI) ist eine konkret messbare Größe – etwa der Prozentsatz erfolgreicher HTTP-Anfragen in den letzten 30 Tagen oder der Anteil von Anfragen, die unter 200 ms beantwortet wurden. Ein Service Level Objective (SLO) ist der vereinbarte Zielwert für diesen Indikator: mindestens 99,9 Prozent erfolgreiche Anfragen zum Beispiel.
Diese Ziele werden nicht willkürlich festgelegt, sondern auf Basis historischer Daten und Nutzeranforderungen bestimmt. Ein SLO von 99,999 Prozent klingt gut – ist aber für die meisten Dienste weder erreichbar noch notwendig. Zu hohe SLOs lähmen Teams, weil kein Budget für Experimente oder Deployments bleibt. Zu niedrige SLOs signalisieren Kunden mangelnde Qualität. Das richtige SLO zu finden ist eine der anspruchsvollsten Aufgaben in SRE.
Postmortems und schuldfreie Analyse
Wenn etwas schiefläuft – und in jedem System läuft früher oder später etwas schief – folgt in SRE-Teams eine strukturierte Nachanalyse: das Postmortem. Anders als in Umgebungen, in denen Schuld gesucht und verteilt wird, steht beim Postmortem die Frage im Vordergrund: Welche systembedingten Ursachen haben diesen Vorfall möglich gemacht? Die Antwort ist fast immer keine einzelne Person, sondern ein Zusammenspiel aus unvollständigen Tests, fehlenden Alarmen, unklaren Runbooks oder mangelhafter Kommunikation.
Gute Postmortems werden schriftlich festgehalten, im Team geteilt und mit konkreten Maßnahmen verbunden. Sie sind kein Abschlussbericht, sondern ein Lernwerkzeug. Teams, die regelmäßig Postmortems durchführen, bauen mit der Zeit ein kollektives Wissen über ihre Systeme auf, das weit wertvoller ist als jede Dokumentation.
Runbooks: Handlungsanweisungen für den Ernstfall
Runbooks sind dokumentierte Schritt-für-Schritt-Anleitungen für bekannte Probleme. Sie beschreiben, wie ein bestimmter Alarm zu interpretieren ist, welche Befehle ausgeführt werden sollen, wann eskaliert wird und wie der Dienst wieder in einen stabilen Zustand gebracht wird. Gute Runbooks sind kurz, konkret und direkt aus dem Monitoring-System verlinkt.
Ein Runbook, das während eines nächtlichen Vorfalls aufgerufen wird, muss auch unter Schlafentzug und Stress verständlich und ausführbar sein. Das bedeutet: keine langen Texte, keine Voraussetzung von Spezialkenntnissen, klare Entscheidungspunkte. Runbooks richten sich nicht nur an Experten, sondern auch an Personen, die zum ersten Mal On-Call-Dienst übernehmen.
Monitoring als Fundament
Kein SRE-Ansatz funktioniert ohne verlässliches Monitoring. Wer nicht weiß, ob ein Dienst gerade läuft, kann weder SLIs messen noch Error Budgets verwalten. HTTP-Monitore überprüfen Dienste von außen und erfassen, was Nutzer tatsächlich erleben. Heartbeat-Checks erkennen stille Ausfälle, bei denen ein Prozess einfach aufgehört hat zu arbeiten, ohne einen klassischen Fehler zu melden. DNS-Monitoring stellt sicher, dass Domänen korrekt aufgelöst werden. Zusammen bilden diese Prüfungen das Fundament, auf dem SRE aufbaut.
SRE in kleinen Teams
SRE wird oft als Google-Konzept für Hyperscaler missverstanden. Dabei sind die Grundprinzipien für Teams jeder Größe relevant. Ein fünfköpfiges Entwicklungsteam profitiert genauso von klar definierten Verfügbarkeitszielen, automatisierten Alarmen und strukturierten Postmortems wie eine 500-köpfige Engineering-Organisation. Der Unterschied liegt im Umfang, nicht im Ansatz. Kleine Teams können mit einfachen Mitteln starten: ein Monitoring-Tool einrichten, ein SLO in einem Dokument festhalten und nach jedem größeren Vorfall eine kurze Retrospektive durchführen. Wichtig ist, überhaupt anzufangen.
Fazit: SRE als kontinuierlicher Verbesserungsprozess
SRE ist kein Zertifikat und kein festgelegter Prozess – es ist eine Denkweise und ein kontinuierlicher Verbesserungszyklus. Teams, die anfangen, ihre Systeme mit SLOs zu steuern, Toil aktiv abzubauen und aus Vorfällen zu lernen, werden über Zeit belastbarere Dienste betreiben. Die Werkzeuge und Konzepte sind erlernbar. Die schwerste Aufgabe ist oft die erste: ehrlich hinschauen, was heute wirklich passiert – und dann bereit sein, es systematisch zu verbessern. Wer damit anfängt und die Erkenntnisse konsequent umsetzt, hat den wichtigsten Schritt bereits getan.
