Site Reliability Engineer (SRE)
SRE macht Zuverlässigkeit messbar.
Nicht gefühlt. Nicht politisch. Sondern über klare Ziele.
Ein SRE steuert Verfügbarkeit, Performance und Stabilität über SLOs und Error Budgets.
1. Kurzdefinition
Ein Site Reliability Engineer verbindet:
- Software Engineering
- Betriebsverantwortung
- messbare Zuverlässigkeitsziele
Ziel ist:
Stabilität mit bewusstem Risiko.
2. Kernkonzept: SLO & Error Budget
Service Level Indicator (SLI)
Messgröße (z. B. Antwortzeit, Erfolgsrate).
Service Level Objective (SLO)
Zielwert (z. B. 99,9 % Verfügbarkeit).
Error Budget
Erlaubte Fehlermenge innerhalb eines Zeitraums.
Wenn das Error Budget verbraucht ist:
→ Keine neuen Features.
→ Fokus auf Stabilisierung.
SRE macht Trade-offs explizit.
3. Was macht ein SRE konkret?
3.1 SLO-Definition
- Kritische User-Flows identifizieren
- Messgrößen definieren
- Realistische Zielwerte festlegen
- Monitoring implementieren
SLOs ohne Monitoring sind Illusion.
3.2 Incident Management
- Incident-Response-Prozesse
- On-Call-Strukturen
- Post-Mortems
- Root Cause Analysis
- Blameless Culture
Incidents sind Lerninstrumente.
3.3 Automatisierung
- Self-Healing-Mechanismen
- Auto-Scaling
- Recovery-Automatisierung
- Chaos-Tests
Manuelle Wiederherstellung ist Risiko.
3.4 Kapazitätsplanung
- Lastanalyse
- Forecasting
- Kosten vs. Verfügbarkeit bewerten
Zuverlässigkeit ist wirtschaftlich.
4. SRE vs. DevOps
| DevOps | SRE |
|---|---|
| Delivery-Optimierung | Reliability-Optimierung |
| Automatisierung von Deployments | Steuerung von Stabilitätszielen |
| Pipeline & Infrastruktur | SLO & Error Budget |
| Flow-Fokus | Stabilitäts-Fokus |
DevOps beschleunigt. SRE begrenzt Risiko.
5. SRE vs. Platform Engineering
| Platform | SRE |
|---|---|
| Self-Service-Infrastruktur | Zuverlässigkeitsziele |
| Developer Experience | System-Stabilität |
| Standards | Stabilitätsmessung |
Platform baut Werkzeuge. SRE misst Wirkung.
6. SRE im Qualitätskontext
Stufe 2:
- Monitoring vorhanden
Stufe 3:
- SLOs definiert
- Incident-Prozess etabliert
Stufe 4:
- Error Budgets aktiv gesteuert
- Kapazitätsplanung
- regelmäßige Incident Reviews
Stufe 5:
- formale Zuverlässigkeitsnachweise
- auditierbare Incident-Prozesse
- dokumentierte Stabilitätsmetriken
Hohe Verfügbarkeitsziele ohne SRE-Struktur sind riskant.
7. Typische Anti-Patterns
- 100 % Verfügbarkeit fordern
- SLOs ohne Business-Abgleich
- Monitoring ohne klare Indikatoren
- Post-Mortems ohne Konsequenzen
- On-Call ohne Ressourcen
Zuverlässigkeit ist keine Marketing-Zahl.
8. Wirtschaftliche Realität
Jede zusätzliche „9“ kostet exponentiell mehr:
- 99 % → relativ günstig
- 99,9 % → spürbar aufwändiger
- 99,99 % → teuer
- 99,999 % → extrem teuer
Verfügbarkeit ist Investitionsentscheidung.
9. Erfolgsindikatoren
Ein SRE ist wirksam, wenn:
- SLOs klar definiert sind
- Error Budgets aktiv genutzt werden
- Incidents strukturiert ausgewertet werden
- Stabilität planbar wird
- Feature-Druck gegen Reliability balanciert wird
Kernaussage
SRE macht Zuverlässigkeit explizit.
Er ersetzt nicht DevOps. Er ersetzt nicht Architektur.
Er macht Risiko messbar – und zwingt Organisationen zu bewussten Entscheidungen.