SRE als Produktdisziplin — was ein SRE-Engagement tatsächlich verändert

SRE — Site Reliability Engineering — gehört zu den am weitesten verbreiteten und zugleich am häufigsten missverstandenen Engineering-Disziplinen des letzten Jahrzehnts. Die meisten mittleren und großen Engineering-Organisationen behaupten, „SRE zu machen“. Deutlich weniger betreiben die Disziplin tatsächlich so, wie sie das ursprüngliche SRE-Buch von Google beschreibt: als Softwareentwicklung, angewandt auf den Betrieb, mit expliziten Error Budgets, SLOs, die die Priorisierung beeinflussen, und einer harten Obergrenze für operativen Toil.

Was SRE genau bedeutet

Die ursprüngliche Google-Formulierung ruht auf drei tragenden Eigenschaften:

1. SRE ist Softwareentwicklung, angewandt auf den Betrieb

SREs sind Softwareentwickler — sie schreiben Code, liefern Systeme aus und automatisieren den Betrieb. Sie sind kein umbenanntes Ops-Team mit derselben Aufgabe und einem schickeren Titel. Die Frage „Schreibt Ihr SRE eigentlich Code?“ ist ein echter Test; Teams, die ihn nicht bestehen, haben eine Betriebsfunktion, keine SRE-Funktion.

2. Error Budgets beeinflussen die Priorisierung

Das SLO definiert die Messlatte. Das Error Budget ist die Differenz zwischen 100 % und dem SLO-Zielwert. Ist das Error Budget aufgebraucht, verschiebt sich die Priorisierung des Produktteams — die Feature-Arbeit pausiert, Zuverlässigkeitsarbeit hat Vorrang. Ist das Error Budget gesund, kann die Feature-Arbeit weiterlaufen.

Entscheidend ist: Das ist ein Vertrag, keine Empfehlung. Eine SLO-Verletzung hat echte Folgen für die Produkt-Roadmap. Organisationen, die SLOs haben, sie aber die Roadmap nicht beeinflussen lassen, haben Observability, keine SRE-Praxis.

3. Operativer Toil ist begrenzt (oft auf 50 %)

Die Google-Formulierung lautet: SREs dürfen höchstens 50 % ihrer Zeit mit operativem Toil verbringen (wiederkehrender, manueller, automatisierbarer Arbeit). Der Rest muss in Softwareentwicklung fließen, die Toil reduziert. Dadurch verbessert sich die Funktion mit der Zeit selbst — der Toil sinkt, die Engineering-Kapazität steigt.

Teams, die die Toil-Grenze strukturell überschreiten, haben eine Betriebsfunktion, die sich als SRE ausgibt. Die Disziplin erodiert über Monate, bis die Funktion nicht mehr vom klassischen Betrieb zu unterscheiden ist.

Drei Engagement-Modelle

Im Jahr 2026 sind drei strukturell unterschiedliche SRE-Modelle im produktiven Einsatz:

Modell 1: eingebettetes SRE

SREs sitzen in den Produktteams. Ein Produktteam umfasst 2–5 Engineers, von denen einer die SRE-Funktion übernimmt. Dasselbe Team verantwortet Features und Zuverlässigkeit; der SRE prägt Architektur und Bereitschaftsdienst von innen heraus.

Stärken: Ausrichtung zwischen SRE- und Produktprioritäten, schnelles Feedback, keine Reibung zwischen Teams.

Schwächen: Die SRE-Qualität schwankt von Team zu Team, abhängig von der eingebetteten Person. Zentrale SRE-Expertise wächst nicht kumulativ. Über viele Produktteams hinweg lässt sich das Modell kaum skalieren, ohne an Konsistenz zu verlieren.

Passt für: Organisationen mit 100–300 Engineers, in denen jedes Produktteam klare Verantwortung trägt und pro Team etwa ein Engineer mit SRE-Kompetenz verfügbar ist.

Modell 2: zentrale SRE-Funktion

SREs sitzen in einer eigenen Funktion mit eigener Berichtslinie. Sie beraten die Produktteams, setzen Zuverlässigkeitsstandards, betreiben gemeinsam genutzte Infrastrukturkomponenten und die Services auf dem kritischen Pfad.

Stärken: SRE-Expertise wächst kumulativ. Standards sind über Teams hinweg konsistent. Services auf dem kritischen Pfad haben dedizierte Verantwortliche für ihre Zuverlässigkeit.

Schwächen: Reibung zwischen Teams, wenn SRE-Empfehlungen mit den Prioritäten der Produktteams kollidieren. Es besteht das Risiko, dass SRE als Bremse statt als Ermöglicher wirkt.

Passt für: Organisationen ab 300 Engineers mit mehreren Services auf dem kritischen Pfad und einer klaren Platform-Engineering-Funktion. Häufig mit Platform Engineering als Schwesterfunktion kombiniert.

Modell 3: hybrid (eingebettet plus zentral)

Eingebettete SREs in den Produktteams kümmern sich um die teamspezifische Zuverlässigkeit. Eine zentrale SRE-Funktion betreibt die gemeinsame Infrastruktur, setzt Standards und übernimmt die Eskalation bei teamübergreifenden Incidents.

Stärken: verbindet die Vorteile beider Ansätze. Das häufigste Muster in großen Organisationen (Google, Netflix, große Fintechs).

Schwächen: erfordert eine erhebliche Größe, um die doppelte Investition zu rechtfertigen. Unterhalb von 500 Engineers lässt sich der Overhead kaum amortisieren.

Passt für: Organisationen ab 500 Engineers mit mehreren Geschäftsbereichen und einem umfangreichen Portfolio zuverlässigkeitskritischer Workloads.

Wo SRE zum Theater wird

Muster, die wir in Assessments beobachten:

Theater 1: SLOs existieren, beeinflussen die Roadmap aber nicht

SLOs sind dokumentiert. Dashboards zeigen die SLO-Einhaltung. Quartalsreviews erwähnen SLO-Trends. Die Priorisierung der Produktteams läuft jedoch unabhängig vom Zustand des Error Budgets. Kommt es zu einer SLO-Verletzung, folgt eine incidentbezogene Feuerwehraktion, aber keine Neupriorisierung der Roadmap.

Das ist Observability mit SLO-Etiketten, keine SRE-Praxis. Für Kaufentscheidungen ist die Unterscheidung wichtig: Organisationen in diesem Zustand brauchen nicht mehr Dashboards, sondern ein anderes Governance-Modell.

Theater 2: SRE-Titel für klassischen Betrieb

Betriebsingenieure werden in „SRE“ umbenannt, ohne dass sich ihre Arbeitsinhalte ändern. Sie verbringen weiterhin 90 % ihrer Zeit mit der Ticket-Queue. Über Shell-Skripte hinaus schreiben sie keinen Code. Über das Error Budget haben sie keinerlei Entscheidungsbefugnis.

Das ist ein Etikettenwechsel, kein Wandel der Disziplin. Typisch für Übergänge von DevOps zu SRE, in die kein Executive Sponsor investiert hat.

Theater 3: Error Budgets definiert, aber nie angewendet

Error Budgets werden berechnet. Einige Dashboards zeigen sie an. Es gibt aber keinen Prozess dafür, was passiert, wenn sie aufgebraucht sind. Faktisch ist das dasselbe wie gar kein Error Budget.

Abhilfe: Schreiben Sie das explizite Protokoll für den Feature-Stopp auf, das beim Aufbrauchen des Error Budgets greift. Lassen Sie es von der Produktführung absegnen. Testen Sie es einmal mit einem künstlichen Budgetverbrauch, bevor Sie davon ausgehen, dass es in Produktion funktioniert.

Theater 4: Post-Mortems ohne Maßnahmen

Nach Incidents finden Post-Mortems statt. Sie werden geschrieben. Sie landen in einem Ordner. Keine einzige Maßnahme wird bis zum Abschluss verfolgt. Dieselbe Klasse von Incidents tritt innerhalb von sechs Monaten erneut auf.

Abhilfe: Maßnahmen aus Post-Mortems kommen in dasselbe Backlog wie die Feature-Arbeit — mit benannten Verantwortlichen, Fälligkeitsterminen und expliziter Priorisierung. Ein Post-Mortem hat nicht funktioniert, wenn seine Maßnahmen nicht umgesetzt werden.

Was ein SRE-Engagement von Ænix liefert

Typischerweise arbeiten wir mit Organisationen, deren SRE-Praxis sich in einem von drei Zuständen befindet:

• Vor SRE — keine formale SRE-Funktion; Zuverlässigkeit ist incidentgetriebene Feuerwehrarbeit. Das Engagement umfasst die Definition der Funktion, einen Einstellungsplan und erste SLOs für kritische Services.
• SRE im Theater-Zustand — SRE-Titel und Dashboards gibt es, die Disziplin ist aber nicht angekommen. Das Engagement diagnostiziert, welche Theater-Muster wirken, entwirft Korrekturen und umfasst häufig funktionsübergreifende Governance-Arbeit.
• Reifes SRE, das wachsen muss — die Disziplin funktioniert in einem Geschäftsbereich und muss nun auf die ganze Organisation skalieren oder neue Service-Familien aufnehmen (AI/GPU-Workloads, Edge Compute, souveräne Cloud). Das Engagement konzentriert sich auf Konsistenz und Wissenstransfer.

Arbeitsstrang 1 — SLO-Definition

Für jeden kritischen Service definieren wir:

• SLI (Service Level Indicator) — was wir messen
• SLO (Service Level Objective) — den Zielwert
• Error Budget — die Differenz zwischen 100 % und dem SLO
• Burn-down-Policy — was geschieht, während das Budget verbraucht wird
• Erholungsschwelle — was die Priorität der Feature-Arbeit wiederherstellt

Ænix definiert Ihre SLOs nicht isoliert für Sie — wir moderieren den Workshop, in dem Engineering- und Produktführung sie gemeinsam erarbeiten. SLOs ohne gemeinsame Verantwortung setzen sich nicht durch.

Arbeitsstrang 2 — Incident-Response-Prozess

Rollen (Incident Commander, Protokollführung, Kommunikation). Schweregrad-Klassifizierung. Aufbau der Runbooks. Eskalationswege. Vorlage für Blameless Post-Mortems. Nachverfolgung der Maßnahmen.

Häufig ist das der Arbeitsstrang mit der größten Hebelwirkung — das Framework vervielfacht die Wirksamkeit bei jedem künftigen Incident.

Arbeitsstrang 3 — Toil messen und reduzieren

Wir inventarisieren die aktuelle Arbeit des SRE- bzw. Ops-Teams und kategorisieren sie: Toil (wiederkehrend, manuell, automatisierbar) gegenüber Engineering (dauerhaft, automatisierungserzeugend). Dann messen wir den Toil-Anteil.

Wir empfehlen die 3–5 Automatisierungen, die den meisten Toil abbauen, staffeln sie nach ROI und übergeben sie dem Engineering-Team zur Umsetzung; bei Bedarf unterstützen wir.

Arbeitsstrang 4 — Observability-Stack

Die Standardempfehlung von Ænix für Observability: VictoriaMetrics für Metriken, VictoriaLogs für Logs, OpenTelemetry für Tracing, wo sinnvoll. Selbst gehostet (souveränitätsfreundlich, im großen Maßstab mit weniger Overhead als Prometheus + Loki, kein Datenabfluss an einen SaaS-Anbieter).

Bei Organisationen, die bereits einen anderen Stack nutzen, arbeiten wir mit dem Vorhandenen, statt einen Austausch zu forcieren. Der Observability-Stack ist wichtig; die SRE-Disziplin ist wichtiger.

Arbeitsstrang 5 — Design der Funktion

Empfehlung für das eingebettete, zentrale oder hybride Modell passend zum Profil der Engineering-Organisation. Personalplanung. Einstellungsprioritäten. Berichtslinie. Schnittstelle zu Platform Engineering (sofern eigene Funktion) und zu den Produktteams.

Die Zuverlässigkeits-Defaults von Cozystack

Organisationen, die ein Ænix-Plattformprodukt betreiben, haben bei der SRE-Praxis einen Vorsprung, weil die Plattform mit SRE-tauglichen Voreinstellungen ausgeliefert wird:

• Integrierte Observability — VictoriaMetrics + VictoriaLogs sind vorinstalliert, mit Alert-Regeln für die Plattformkomponenten
• Deklarative Änderungshistorie — Tenants und Services sind Kubernetes-Ressourcen, verwaltet über GitOps; jede Änderung hat einen Commit, einen Autor und ein Review
• Backup- und Restore-Muster — Velero plus PITR pro Anwendung; RPO / RTO werden im Engagement pro Service dokumentiert

SLO-Definitionen und Werkzeuge für Fehlerinjektion (Chaos Engineering) sind keine Plattformfunktionen; sie werden im Engagement mit Ihnen entworfen.

So kann sich das SRE-Engagement auf die organisationsspezifische Arbeit konzentrieren (Design der Funktion, an Geschäftsprioritäten ausgerichtete SLOs, Governance), statt das technische Fundament neu aufzubauen.

Wann dieses Engagement passt

Gute Passung:

• Engineering-Organisation mit über 200 Engineers, in der Zuverlässigkeit zum Thema auf Vorstandsebene wird
• Ein Muster jüngster Incidents hat Zuverlässigkeitslücken offengelegt
• Regulatorisch getriebene RTO/RPO-Pflichten (DORA Artikel 11–12, NIS2 Artikel 21 Absatz 2 Buchstabe c)
• Bestehende Investitionen in Observability, aber keine klare SRE-Disziplin
• Eine Platform-Engineering-Funktion existiert oder wird aufgebaut (SRE ergänzt Platform Engineering ganz natürlich)

Bedingte Passung:

• Kleinere Organisationen (unter 100 Engineers) — meist eingebettetes SRE statt einer eigenen Funktion; das Ænix-Engagement kann schlanker ausfallen (Workshop plus Beratung statt eines mehrmonatigen Engagements)
• Organisationen mit reifem SRE in einem Geschäftsbereich, das ausgeweitet werden soll — der Umfang kann enger gefasst werden

Schlechte Passung:

• Reine Feuerwehr-Kultur ohne Rückendeckung der Engineering-Führung für den Wandel der Disziplin — ein SRE-Engagement ohne Unterstützung des Managements verkommt zu einem Incident-Response-Training; das ist hilfreich, aber nicht das, was wir anbieten

Weiterführende Inhalte

• SRE-Consulting-Leistungen — die kommerzielle Landingpage
• DevOps-Best-Practices für 2026 — die acht DevOps-Praktiken einschließlich SRE
• Platform Engineering vs DevOps vs SRE — Begriffe und Design der Funktion
• Cloud-Engineering-Disziplinen — die sieben Disziplinen, die sich gegenseitig verstärken