Site Reliability Engineering
Site Reliability Engineering (SRE)
Die Disziplin, die Software-Engineering auf Infrastruktur- und Betriebsprobleme anwendet. Lernen Sie SLOs, Error Budgets, Toil-Reduktion und Incident Management für hochverfügbare Systeme.
Inhaltsverzeichnis
Schnellübersicht
Auf dieser Seite lernen Sie alles über Site Reliability Engineering:
- Definition: Was ist SRE und wie unterscheidet es sich von DevOps?
- Kernmetriken: SLI, SLO, SLA und Error Budgets
- Toil-Reduktion: Automatisierung repetitiver Aufgaben
- Incident Management: Detection, Response, Resolution, Postmortem
- Best Practices: Monitoring, Automation, Capacity Planning
- FAQ: Häufige Fragen zu SRE
1. Was ist Site Reliability Engineering?
Definition
Site Reliability Engineering (SRE) ist eine Disziplin, die Software-Engineering-Ansätze auf Infrastruktur- und Betriebsprobleme anwendet. SRE wurde ursprünglich bei Google entwickelt und hat sich als Standard für den Betrieb hochverfügbarer, skalierbarer Systeme etabliert.
Das Ziel von SRE ist es, Zuverlässigkeit als Feature zu behandeln – genauso wie Performance, Sicherheit oder neue Funktionen. SREs schreiben Code, um manuelle Operationen zu automatisieren, definieren messbare Zuverlässigkeitsziele (SLOs) und managen Error Budgets, um die Balance zwischen Innovation und Stabilität zu finden.
Benjamin Treynor Sloss (Google): „SRE ist das, was passiert, wenn man einen Software-Ingenieur bittet, ein Operations-Team zu leiten."
SRE vs. DevOps
SRE und DevOps überschneiden sich stark, haben aber unterschiedliche Schwerpunkte:
DevOps
- Kultur der Zusammenarbeit zwischen Dev und Ops
- CI/CD-Pipelines und schnelle Releases
- Infrastruktur als Code (IaC)
- Fokus auf Geschwindigkeit und Agilität
- Breite Prinzipien, keine spezifischen Metriken
SRE
- Konkrete Implementierung von DevOps-Prinzipien
- Messbare Zuverlässigkeitsziele (SLOs)
- Error Budgets als Steuerungsinstrument
- Fokus auf Zuverlässigkeit und Verfügbarkeit
- Toil-Reduktion durch Automatisierung
Merksatz
„DevOps ist die Philosophie, SRE ist die Umsetzung." DevOps definiert das „Was" und „Warum", SRE liefert das „Wie" mit konkreten Praktiken, Tools und Metriken.
2. Kernmetriken: SLI, SLO, SLA & Error Budgets
Diese vier Konzepte bilden das Fundament jeder SRE-Praxis. Sie machen Zuverlässigkeit messbar und steuerbar.
SLI
Ein quantitativer Indikator, der das Verhalten eines Services misst. SLIs sind die Rohdaten der Zuverlässigkeit.
• Verfügbarkeit: 99,95% erfolgreiche Requests
• Latenz: p95 = 200ms
• Fehlerrate: 0,05% 5xx-Responses
SLO
Das Ziel oder der Zielbereich für einen SLI. SLOs definieren, was „zuverlässig genug" bedeutet.
• Verfügbarkeit ≥ 99,9% pro Monat
• p95-Latenz ≤ 300ms
• Fehlerrate ≤ 0,1%
SLA
Ein vertragliches Agreement mit Konsequenzen bei Nichteinhaltung. SLAs sind extern und rechtlich bindend.
• Verfügbarkeit ≥ 99,95%
• Bei Verletzung: 10% Gutschrift
• Internes SLO: 99,98% (Puffer!)
Error Budget
Die Differenz zwischen 100% und dem SLO. Das Error Budget ist die erlaubte Unzuverlässigkeit – Ihr Spielraum für Innovation.
• Error Budget = 0,1% = 43,2 Min/Monat
• Budget verbraucht → Release-Stopp
• Budget übrig → Experimente erlaubt
Error Budget berechnen
Formel: Error Budget = (1 − SLO) × Zeitfenster
- SLO 99,9% → 0,1% Error Budget → 43,2 Minuten Downtime/Monat erlaubt
- SLO 99,95% → 0,05% Error Budget → 21,6 Minuten Downtime/Monat erlaubt
- SLO 99,99% → 0,01% Error Budget → 4,32 Minuten Downtime/Monat erlaubt
Regel: Wenn das Error Budget aufgebraucht ist, werden keine neuen Features released, bis die Zuverlässigkeit wiederhergestellt ist. Dies erzwingt die Balance zwischen Innovation und Stabilität.
3. Toil-Reduktion & Automatisierung
Toil ist manuelle, repetitive, taktische Arbeit, die keinen dauerhaften Wert schafft und mit dem Wachstum des Systems skaliert. SRE zielt darauf ab, Toil auf maximal 50% der Arbeitszeit zu begrenzen.
Charakteristika von Toil
Repetititiv
Die gleiche Aufgabe wird immer wieder durchgeführt, ohne dass sich der Ansatz ändert.
Manuell
Erfordert menschliche Intervention und kann nicht vollständig automatisiert werden (noch nicht).
Skalierend
Der Aufwand wächst linear oder exponentiell mit dem Systemwachstum (mehr Server = mehr Arbeit).
Kein dauerhafter Wert
Die Arbeit hinterlässt keinen bleibenden Nutzen – sie muss morgen wiederholt werden.
- Manuelles Patchen von 100+ Servern
- Wiederholtes Beheben desselben Alerts
- Manuelle Kapazitätsplanung per Spreadsheet
- User-Onboarding ohne Self-Service
- Log-Rotation und Cleanup per Hand
- Datenbank-Backups ohne Automatisierung
- Automatisierung: Scripts, Ansible, Terraform
- Self-Service-Tools: User können selbst agieren
- Alert-Tuning: Nur actionable Alerts
- Runbooks: Standardisierte Prozeduren
- Infrastructure as Code: Reproduzierbare Deploys
- ChatOps: Automation via Chat-Bots
Die 50%-Regel
Google's SRE-Praxis: SREs sollten maximal 50% ihrer Zeit mit operativer Arbeit (Toil + On-Call) verbringen. Die anderen 50% sind für Engineering-Projekte reserviert: Automatisierung, Tool-Entwicklung, Architekturverbesserungen. Wird diese Grenze überschritten, muss das Team entweder Personal aufstocken oder Toil eliminieren.
4. Incident Management
Incidents sind unvermeidbar. SRE fokussiert sich auf strukturierte Response-Prozesse und lernorientierte Postmortems.
Detection (Erkennung)
Monitoring-Systeme erkennen Anomalien und lösen Alerts aus. Ziel: MTTD (Mean Time To Detect) minimieren. Gute Detection erfolgt automatisch, bevor Nutzer den Ausfall bemerken.
Response (Reaktion)
On-Call-Ingenieur wird alarmiert, bewertet die Severity und beginnt mit der Diagnose. Klare Rollen: Incident Commander, Communications Lead, Operations Lead.
Resolution (Lösung)
Mitigation (schnelle Linderung) hat Priorität vor Root-Cause-Fix. Ziel: MTTR (Mean Time To Resolve) minimieren. Workarounds sind akzeptabel, um Service schnell wiederherzustellen.
Postmortem (Nachbereitung)
Blameless Postmortem: Fokus auf Systemfehler, nicht menschliches Versagen. Dokumentation von Timeline, Impact, Root Cause und Action Items. Veröffentlichung intern für organisationales Lernen.
Blameless Postmortem – Warum?
Wenn Menschen Angst vor Bestrafung haben, vertuschen sie Fehler. Blameless Postmortems schaffen psychologische Sicherheit und fördern ehrliche Analysen. Die Frage ist nie „Wer hat das getan?", sondern „Welche Systembedingungen haben dies ermöglicht?".
5. SRE Best Practices
Monitoring & Observability
- Die drei Säulen: Metrics, Logs, Traces
- Golden Signals: Latency, Traffic, Errors, Saturation
- Alert nur bei Symptomen, nicht bei Ursachen
- SLI-basiertes Monitoring statt Infra-Metriken
- Dashboards für SLO-Compliance
Automatisierung
- Infrastructure as Code (Terraform, Pulumi)
- CI/CD-Pipelines für alle Changes
- Auto-Scaling basierend auf Metriken
- Self-Healing-Systeme (Auto-Restart, Failover)
- Chaos Engineering für Resilienz-Tests
Capacity Planning
- Regelmäßige Lasttests und Prognosen
- Headroom für Traffic-Spitzen einplanen
- Quota-Management und Rate Limiting
- Automatische Skalierungsregeln
- Kapazität als Teil des SLO-Managements
SRE-Kultur
- Blameless Postmortems als Standard
- Error Budgets als Entscheidungshilfe
- 50%-Regel für Toil vs. Engineering
- Shared Ownership zwischen Dev und SRE
- Continuous Learning und Wissenstransfer
6. FAQ – Häufige Fragen & Antworten
Häufige Fragen zu SRE
Ja, SRE ergänzt DevOps. DevOps ist eine Kulturphilosophie, SRE bietet konkrete Praktiken und Metriken zur Umsetzung. Wenn Ihr DevOps-Team Schwierigkeiten hat, Zuverlässigkeit messbar zu machen oder Toil zu reduzieren, ist SRE der nächste logische Schritt.
Viele Organisationen starten mit DevOps und führen später SRE-Praktiken ein, sobald die Grundlagen (CI/CD, IaC) etabliert sind.
SLOs sollten business-getrieben sein, nicht technisch:
- Fragen Sie: „Was erwarten unsere Nutzer wirklich?"
- Nicht 99,99% anstreben, nur weil es gut klingt
- Historische Daten analysieren: Was war die tatsächliche Verfügbarkeit?
- Business-Impact bewerten: Kostet 0,01% mehr Verfügbarkeit den Aufwand?
- SLOs regelmäßig überprüfen und anpassen
Tipp: Starten Sie mit konservativen SLOs und steigern Sie sie schrittweise, basierend auf gemessener Performance.
Error Budget Exhaustion Policy aktivieren:
- Release-Stopp: Keine neuen Features, nur Bugfixes und Zuverlässigkeitsverbesserungen
- Fokus auf Remediation: Technische Schulden abbauen, Monitoring verbessern
- Postmortem durchführen: Warum wurde das Budget verbraucht?
- Action Items umsetzen: Automatisierung, Kapazität, Architektur
- Kommunikation: Stakeholder informieren, Transparenz schaffen
Das Error Budget ist kein Bestrafungsinstrument, sondern ein Steuerungsinstrument, das die Balance zwischen Innovation und Stabilität erzwingt.
Systematischer Ansatz zur Toil-Eliminierung:
- Toil identifizieren: Tracking über Zeiterfassung oder Umfragen
- Priorisieren: Welches Toil skaliert am stärksten? Welches frisst die meiste Zeit?
- Automatisieren: Scripts, Tools, Self-Service-Portale
- Messen: Hat die Automatisierung den Toil tatsächlich reduziert?
- Iterieren: Nächste Toil-Quelle angehen
Wichtig: Nicht alles auf einmal automatisieren. Fokussieren Sie sich auf die größten Pain Points und bauen Sie schrittweise auf.
MTTD (Mean Time To Detect): Durchschnittliche Zeit, bis ein Incident erkannt wird. Ziel: Minimieren durch proaktives Monitoring und Alerting.
MTTR (Mean Time To Resolve): Durchschnittliche Zeit, bis ein Incident behoben ist (von Detection bis Recovery). Ziel: Minimieren durch Runbooks, Automatisierung und klare Prozesse.
Beide Metriken sind wichtig: Schnelle Detection nützt nichts, wenn die Resolution lange dauert. Und schnelle Resolution hilft nicht, wenn der Incident erst nach Stunden bemerkt wird.
Es gibt verschiedene Modelle:
- Dediziertes SRE-Team: Eigenständiges Team, das Services betreut (Google-Modell)
- Embedded SREs: SREs sind in Produktteams integriert
- SRE-Platform-Team: Baut Tools und Plattformen, die Dev-Teams nutzen
- SRE-as-a-Service: Zentrales Team berät und unterstützt andere Teams
- Kein SRE-Team: Dev-Teams übernehmen SRE-Praktiken selbst
Empfehlung: Starten Sie mit SRE-Praktiken in bestehenden Teams. Wenn die Organisation wächst und die Komplexität zunimmt, erwägen Sie ein dediziertes SRE-Team oder Platform-Team.
SRE-Erfolg ist multidimensional:
- Zuverlässigkeit: SLO-Compliance-Rate, MTTR, MTTD
- Toil-Reduktion: Prozentuale Reduktion manueller Arbeit
- Velocity: Release-Frequenz, Lead Time for Changes
- Kultur: Postmortem-Qualität, Psychological Safety
- Business-Impact: Revenue-Impact von Incidents, Customer Satisfaction
Wichtig: Messen Sie nicht nur technische Metriken. Der ultimative SRE-Erfolg ist ein zuverlässiger Service, der Business-Ziele unterstützt.
Essentielle Tool-Kategorien:
- Monitoring: Prometheus, Grafana, Datadog, New Relic
- Logging: ELK Stack, Loki, Splunk
- Tracing: Jaeger, Zipkin, OpenTelemetry
- Alerting: PagerDuty, OpsGenie, Alertmanager
- IaC: Terraform, Pulumi, CloudFormation
- CI/CD: GitLab CI, GitHub Actions, Jenkins
- Incident Management: Jira Service Management, Statuspage
Tipp: Tools sind Mittel zum Zweck. Beginnen Sie mit einfachen Lösungen und skalieren Sie, wenn die Anforderungen wachsen. Die beste Toolchain ist die, die Ihr Team tatsächlich nutzt.
Zusammenfassung
Die wichtigsten Punkte
- SRE: Software-Engineering-Ansatz für Infrastruktur- und Betriebsprobleme
- SLI: Quantitativer Indikator (z.B. Verfügbarkeit, Latenz)
- SLO: Zielwert für SLI (z.B. 99,9% Verfügbarkeit)
- SLA: Vertragliches Agreement mit Konsequenzen
- Error Budget: Erlaubte Unzuverlässigkeit = 100% − SLO
- Toil: Repetitive, manuelle Arbeit ohne dauerhaften Wert
- 50%-Regel: Max 50% Zeit für Toil, Rest für Engineering
- Incident Management: Detection → Response → Resolution → Postmortem
- Blameless Postmortems: Fokus auf System, nicht Menschen
- Monitoring: Golden Signals (Latency, Traffic, Errors, Saturation)
Erste Schritte mit SRE
- SLOs definieren: Beginnen Sie mit einem kritischen Service
- SLIs implementieren: Messen Sie Verfügbarkeit und Latenz
- Error Budgets tracken: Dashboard für SLO-Compliance
- Toil messen: Erfassen Sie manuelle Arbeit
- Erste Automatisierung: Eliminieren Sie das größte Toil
- Postmortem-Kultur etablieren: Blameless, dokumentiert, geteilt
Weiterführende Themen
Die philosophische Grundlage für SRE – Collaboration, Automation, Measurement.
Zur DevOps-KulturScrum, Kanban und iterative Entwicklung als Basis für SRE-Praktiken.
Zu Agile MethodenStrukturierte Änderungsprozesse für stabile Produktionssysteme.
Zu Change ManagementCloud-native Architekturen, Container und Infrastructure as Code.
Zu Cloud & Infrastruktur