IT Services
Marketing

Wie Unternehmen von DevOps zu SRE wachsen

Rustam Atai15 Min.

Wenn wir über DevOps und SRE sprechen, stellen sich viele vor, dass ein Unternehmen eines Tages einfach entscheidet: „Wir wechseln jetzt zu SRE“. In der Realität passiert das fast nie. Unternehmen wechseln nicht von DevOps zu SRE über Nacht. Sie wachsen schrittweise in Richtung SRE, während Systeme komplexer werden, Teams wachsen und Ausfälle immer teurer werden.

Es ist besser, SRE nicht als Jobtitel zu sehen, sondern als Reifegrad einer Engineering-Organisation. DevOps geht darum, eine zuverlässige Pipeline für die Bereitstellung von Software aufzubauen. SRE geht darum, dass diese Pipeline stabil, skalierbar und zuverlässig funktioniert.

Site Reliability Engineering wurde ursprünglich bei Google entwickelt, um Software-Engineering-Prinzipien auf Operations und Infrastruktur anzuwenden, mit dem Ziel, hochskalierbare und zuverlässige Systeme zu bauen. (DevOps Institute)

DevOps löst zuerst das Delivery-Problem, SRE das Reliability-Problem

In der DevOps-Phase beschäftigen sich Unternehmen hauptsächlich mit der Bereitstellung von Software. Deployments sind schwierig, Umgebungen unterscheiden sich, Infrastruktur wird manuell erstellt und Releases sind stressig. Das Hauptziel ist es, Deployments automatisiert und reproduzierbar zu machen.

Teams bauen CI/CD-Pipelines, nutzen Infrastructure as Code, Container, Cloud-Plattformen sowie Monitoring und Logging. Sobald DevOps funktioniert, können Entwickler häufig deployen und Infrastruktur wird automatisiert verwaltet.

Aber hier passiert etwas Wichtiges. Wenn Deployments einfacher werden, steigt die Anzahl der Änderungen. Und je mehr Änderungen es gibt, desto höher ist die Wahrscheinlichkeit, dass etwas kaputt geht. Systeme werden verteilt, Microservices entstehen, Kubernetes wird eingesetzt, Queues, Caches und externe APIs kommen hinzu. Ausfälle sind nicht mehr selten – sie werden normal.

An diesem Punkt erkennt das Unternehmen, dass das Hauptproblem nicht mehr Delivery ist, sondern Reliability.

Schritt 1: Observability

Bevor ein Unternehmen SRE betreiben kann, muss es verstehen, was im Production-System passiert. Monitoring allein reicht nicht. Observability bedeutet, dass man verstehen kann, warum etwas passiert ist, nicht nur dass etwas passiert ist.

Moderne Observability umfasst:

  • Metriken
  • strukturierte Logs
  • Distributed Tracing
  • Service-Dashboards
  • User-Experience-Metriken

Observability ist ein zentraler Bestandteil moderner Reliability-Strategien, da sie hilft, Ausfälle schneller zu erkennen und Ursachen zu analysieren. (Unanswered)

Wenn Unternehmen anfangen, nicht mehr zu fragen „Ist der Server erreichbar?“, sondern „Kann der Benutzer eine Bestellung abschließen?“, dann bewegen sie sich bereits in Richtung SRE-Denken.

Schritt 2: Incident Management wird ein Prozess

In unreifen Organisationen verlaufen Incidents chaotisch. Jemand bemerkt ein Problem, schreibt in Slack, alle springen in einen Call und versuchen, etwas zu reparieren.

Mit wachsender Reife wird Incident Management ein strukturierter Prozess:

  • Incident Commander
  • Severity Levels
  • Kommunikationskanäle
  • Postmortems
  • Maßnahmen nach dem Incident

Der wichtigste Punkt ist, dass Organisationen anfangen, aus Fehlern systematisch zu lernen. Reliability verbessert sich nicht, weil Menschen schneller reagieren, sondern weil Systeme und Prozesse verbessert werden.

Schritt 3: SLO – hier beginnt echtes SRE

Vor SRE sagen Teams oft: „Das System muss zuverlässig sein“ oder „Das System muss schnell sein“. Das ist nicht messbar.

SRE führt Service Level Indicators (SLI), Service Level Objectives (SLO) und Error Budgets ein. SLI sind Messwerte wie Latenz oder Fehlerquote, SLO sind Zielwerte für diese Messwerte. (Xurrent)

Zum Beispiel:

  • 99.9 % erfolgreiche Requests
  • 95 % Requests unter 300 ms
  • Service ist 99.95 % verfügbar

Diese Metriken definieren, wie zuverlässig ein Service sein soll.

Schritt 4: Error Budget verändert die Arbeitsweise

Das Error Budget ist eines der wichtigsten Konzepte im SRE. Wenn ein Service ein SLO von 99.9 % hat, dann sind 0.1 % Fehler erlaubt. Dieses „erlaubte Versagen“ nennt man Error Budget.

Error Budgets helfen, Geschwindigkeit und Stabilität zu balancieren. Wenn das Error Budget noch verfügbar ist, können Teams schneller neue Features deployen. Wenn das Error Budget fast aufgebraucht ist, muss die Stabilität verbessert werden. (ciopages.com)

Dieses Modell verwandelt Reliability in eine messbare Business-Entscheidung.

Schritt 5: Toil reduzieren und Automatisierung

Ein weiteres wichtiges Ziel von SRE ist die Reduzierung von sogenanntem Toil – repetitiver manueller Arbeit wie:

  • Services neu starten
  • Logs manuell analysieren
  • Skripte manuell ausführen
  • gleiche Incidents immer wieder fixen

SRE-Teams versuchen, diese Aufgaben zu automatisieren und zu eliminieren. Ein zentrales Prinzip von SRE ist, dass Operations ein Softwareproblem ist und durch Automatisierung gelöst werden sollte. (DevOps Institute)

Das Ziel ist nicht, Incidents schneller zu lösen, sondern weniger Incidents zu haben.

Schritt 6: Platform Engineering

Wenn Unternehmen wachsen, wird Infrastruktur zu komplex, damit jedes Team sie selbst verwaltet. Deshalb entstehen Platform-Teams, die interne Plattformen und Self-Service-Tools für Entwickler bauen.

Platform Engineering baut:

  • CI/CD Plattform
  • Kubernetes Plattform
  • Observability Tools
  • Deployment Templates
  • Secrets Management
  • Self-Service Infrastruktur

SRE und Platform Engineering arbeiten oft zusammen: Platform Teams bauen die Infrastruktur, SRE definiert Reliability-Standards und Incident-Prozesse.

Schritt 7: Reliability wird eine Business-Metrik

Der letzte Schritt passiert, wenn Reliability nicht mehr nur ein technisches Thema ist, sondern ein Business-Thema.

Unternehmen beginnen Fragen zu stellen wie:

  • Wie viel Umsatz verlieren wir durch Downtime?
  • Wie beeinflusst Latenz unsere Conversion Rate?
  • Wie viele Incidents können wir uns leisten?
  • Wie viel Engineering-Zeit geht für Incidents verloren?

In diesem Moment wird Reliability Teil der Produkt- und Business-Strategie. Dann existiert SRE nicht mehr nur als Engineering-Praxis, sondern als Business-Funktion.

Fazit

Unternehmen wechseln nicht plötzlich von DevOps zu SRE. Sie wachsen in SRE hinein.

Der typische Weg sieht so aus: Automatisierung und CI/CD → Observability → Incident Management → SLO → Error Budgets → Automatisierung von Operations → Platform Engineering → SRE Team.

DevOps baut die Delivery-Pipeline. SRE sorgt dafür, dass diese Pipeline zuverlässig und skalierbar ist.

Die meisten Unternehmen brauchen beides – aber zu unterschiedlichen Zeitpunkten ihrer Entwicklung.