Site Reliability Engineering (SRE) ist eine Disziplin, die Methoden des Software-Engineerings auf den Betrieb überträgt. SRE-Teams definieren Zuverlässigkeit über SLOs, wägen Releases gegen ein Error Budget ab, begrenzen manuellen Toil, automatisieren Betriebsaufgaben und lernen aus Störungen durch schuldfreie Postmortems, damit Systeme auch beim Wachstum zuverlässig bleiben.
Was ist Site Reliability Engineering (SRE)?
Site Reliability Engineering (SRE) ist ein Ansatz für den Betrieb von Produktionssystemen, der Betrieb als Softwareproblem behandelt. Er entstand Anfang der 2000er-Jahre bei Google. Ben Treynor Sloss, der das Team gründete, beschrieb SRE als das, was passiert, wenn man einen Softwareentwickler bittet, ein Operations-Team zu entwerfen. Bekannt wurden die Ideen durch Googles Bücher Site Reliability Engineering (2016) und The Site Reliability Workbook (2018), die beide kostenlos online verfügbar sind.
SRE ist zugleich Berufsbezeichnung und Sammlung von Praktiken. Viele Unternehmen übernehmen die Praktiken, ohne ein eigenes SRE-Team zu gründen, und verankern sie in Produkt- oder Platform-Engineering-Teams.
Die zentralen SRE-Prinzipien
- Zuverlässigkeit wird aus Nutzersicht definiert. Service Level Indicators (SLIs) messen, was Nutzer erleben, SLOs setzen Ziele dafür, etwa 99,9 % erfolgreiche Anfragen über 30 Tage.
- 100 % ist das falsche Ziel. Nutzer merken keinen Unterschied zwischen 99,99 % und 100 %, die Kosten dafür sind aber enorm. Die Differenz zwischen SLO und 100 % ist das Error Budget.
- Error Budgets verbinden Tempo und Stabilität. Solange Budget übrig ist, wird ausgeliefert; ist es aufgebraucht, hat Zuverlässigkeitsarbeit Vorrang. Alerts auf die Burn Rate zeigen, wie schnell das Budget verbraucht wird.
- Toil wird begrenzt. Das SRE-Buch von Google empfiehlt, operative Arbeit unter 50 % der Zeit zu halten, damit der Rest in Engineering fließt, das Toil dauerhaft beseitigt.
- Monitoring orientiert sich an Symptomen. Ein Mensch wird nur alarmiert, wenn Nutzer betroffen sind oder es gleich sein werden, typischerweise anhand der vier Golden Signals Latenz, Traffic, Fehler und Sättigung.
- Störungen sind Lerngelegenheiten. Schuldfreie Postmortems betrachten Systeme und Prozesse, nicht die Frage, wer einen Fehler gemacht hat.
- Änderungen sind die häufigste Ausfallursache. Schrittweise Rollouts, schneller Rollback und Release-Automatisierung senken das Risiko jedes Deployments.
Beispiel: Error Budget
Eine illustrative API hat ein Verfügbarkeits-SLO von 99,9 % über ein rollierendes 30-Tage-Fenster. Das Error Budget beträgt 0,1 % der Anfragen. Bei 50 Millionen Anfragen im Monat sind das 50.000 fehlgeschlagene Anfragen oder rund 43 Minuten Totalausfall. Verbraucht ein fehlerhaftes Release an einem Nachmittag 30.000 davon, sind 60 % des Monatsbudgets weg. Nach einer üblichen Error-Budget-Policy werden riskante Launches pausiert, und der nächste Sprint fließt in die Ursachenbehebung, bessere Tests oder eine zusätzliche Canary-Stufe.
SRE und DevOps
DevOps ist eine breite kulturelle Bewegung, die die Trennung zwischen Entwicklung und Betrieb aufheben will. SRE ist eine konkrete Umsetzung davon, mit klaren Praktiken und Zahlen. Google fasst das Verhältnis als „class SRE implements interface DevOps“ zusammen. In der Praxis überschneiden sich beide stark: Automatisierung, gemeinsame Verantwortung, kleine Änderungen und Messbarkeit. DORA-Metriken beschreiben die Delivery-Performance, SLOs und Error Budgets die Zuverlässigkeit, die jede Auslieferung schützen muss. Reife Teams beobachten beides.
Was SREs im Alltag tun
- SLIs und SLOs mit Product Ownern festlegen und Error-Budget-Policies pflegen.
- Alerting, Dashboards und Runbooks aufbauen und verfeinern.
- In der Rufbereitschaft mitarbeiten und die Incident Response leiten.
- Deployments, Kapazitätsplanung, Failover und wiederkehrende Betriebsaufgaben automatisieren.
- Architekturen auf Zuverlässigkeit prüfen: Redundanz, Timeouts, Retries, Graceful Degradation.
- Postmortems moderieren und deren Maßnahmen bis zum Abschluss verfolgen.
Typische Fehler bei der Einführung
- Das Betriebsteam in „SRE“ umbenennen, ohne die Priorisierung der Arbeit zu ändern.
- SLOs festlegen, die niemand durchsetzt, sodass das Error Budget folgenlos bleibt.
- Auf jede Ursachenmetrik wie CPU alarmieren statt auf nutzerseitige Symptome.
- Nur SREs in die Rufbereitschaft nehmen und damit die Rückkopplung zu den Entwicklern kappen.
- Googles Zahlen übernehmen, ohne sie an eigene Größe und Risiken anzupassen.
SLI, SLO und SLA
SRE unterscheidet drei verwandte Begriffe. Ein Service Level Indicator (SLI) ist eine Messgröße, meist ein Verhältnis aus guten Ereignissen zu allen Ereignissen, etwa der Anteil der HTTP-Anfragen, die innerhalb von 300 ms ohne 5xx-Status beantwortet werden. Ein Service Level Objective (SLO) ist ein internes Ziel für diesen Indikator über ein Zeitfenster, zum Beispiel 99,9 % über 30 Tage. Ein Service Level Agreement (SLA) ist ein externer Vertrag mit Konsequenzen wie Gutschriften, wenn er verfehlt wird. SLOs werden in der Regel strenger angesetzt als SLAs, damit das Team reagiert, lange bevor eine vertragliche Zusage in Gefahr gerät. Gute SLIs werden möglichst nah am Nutzer gemessen, etwa am Load Balancer oder im Browser, statt tief in einem einzelnen Service. So spiegeln sie wider, was Kunden tatsächlich erleben, und nicht nur den Zustand einer Komponente.
Wie Obseria unterstützt
Obseria enthält in jedem Tarif SLOs mit Error Budgets, Alerting, Dashboards und Incident Management. Metriken, Logs, Traces und Profile liegen in einem Datenspeicher, sodass sich eine SLO-Verletzung bis zu den fehlerhaften Spans verfolgen lässt. Obseria Intelligence kann Root-Cause-Untersuchungen mit nachvollziehbarer Beweiskette durchführen, und Automatisierungs-Workflows als Code ersetzen wiederkehrende manuelle Schritte.