Was unterscheidet SRE von klassischem Betrieb?
SRE wendet Software-Engineering-Prinzipien auf den IT-Betrieb an. Statt reaktiv Tickets abzuarbeiten, definieren SRE-Teams Service Level Objectives, arbeiten mit Error Budgets und automatisieren manuelle Tätigkeiten systematisch weg. Ziel ist messbare Zuverlässigkeit statt gefühlter Stabilität.
Auch bekannt als: SRE · Site Reliability Engineering
Ist Site Reliability Engineering (SRE) bei Ihnen gerade ein Thema?
Wir fragen kurz, wie dringend das Thema bei Ihnen gerade ist. Je nach Antwort zeigen wir Ihnen direkt den passenden nächsten Schritt — ganz ohne Formular.
Im Alltag arbeitet SRE mit einer Kette aus drei Größen. Zuerst legt das Team fest, was Zuverlässigkeit für einen Service bedeutet, und misst es als Service Level Indicator (SLI), etwa den Anteil erfolgreicher Anfragen. Dann setzt es ein Service Level Objective (SLO), zum Beispiel 99,9 Prozent erfolgreiche Anfragen über 30 Tage. Die Differenz zu 100 Prozent ist das Error Budget. Solange Budget übrig ist, darf das Team Features ausliefern und Risiken eingehen. Ist es verbraucht, geht Stabilisierung vor. Die Entscheidung folgt damit einer Zahl, die beide Seiten vorher vereinbart haben.
Den Ansatz hat Ben Treynor Sloss ab 2003 bei Google aufgebaut, mit einer einfachen Regel: Betriebsaufgaben werden wie ein Software-Problem behandelt. SRE-Teams sollen höchstens die Hälfte ihrer Zeit mit operativer Arbeit verbringen, der Rest gehört der Automatisierung. Wächst ein System, soll die Betriebslast nicht im selben Maß mitwachsen. Zu DevOps verhält sich SRE wie eine konkrete Umsetzung zu einer Haltung. Google selbst beschreibt SRE als eine Implementierung von DevOps, mit festen Praktiken wie dem Abbau von Toil und Blameless Postmortems, also Nachbesprechungen von Vorfällen ohne Schuldzuweisung.
In der Industrie wird SRE dort relevant, wo digitale Services für die Produktion kritisch werden, etwa Plattformen für Maschinendaten oder die Steuerung von Edge-Flotten. Der typische Fehlstart ist die Umbenennung: Das Ops-Team heißt ab Montag SRE, trägt aber dieselbe Rufbereitschaft, dieselben Tickets und denselben Frust, und nach einem halben Jahr hat sich nur die Signatur in den E-Mails geändert. Ohne vereinbartes Error Budget und ohne geschützte Zeit für Automatisierung bleibt es beim klassischen Betrieb.
Seit etwa 2024 verschiebt sich die Praxis an zwei Stellen. Viele SRE-Praktiken wandern ins Platform Engineering, wo interne Entwicklerplattformen SLOs, Monitoring und Deployment-Pfade als Self-Service anbieten, statt dass jedes Team sie neu baut. Außerdem verändert KI die Incident-Response. Anomalie-Erkennung, automatisch korrelierte Alarme und von Sprachmodellen erstellte Zusammenfassungen verkürzen die Diagnose. Saubere SLOs und eine geübte Rufbereitschaft ersetzen sie nicht.
SLO für eine Maschinendaten-Plattform
Ein Industrieunternehmen stritt bei jeder Störung seiner IIoT-Plattform (Industrial Internet of Things) neu darüber, ob das nächste Feature warten muss. Es definiert ein SLO von 99,9 Prozent Verfügbarkeit und vereinbart, dass bei verbrauchtem Error Budget nur noch Stabilisierungsarbeit ausgerollt wird. Die Priorität folgt jetzt dem Budgetstand, und die Diskussion darüber dauert fünf Minuten statt einer Sitzung.
30 Prozent geschützte Zeit gegen wiederkehrende Eingriffe
Ein SRE-Team verbrachte fast die ganze Woche mit manuellen Eingriffen, Neustarts und Zertifikatswechseln. Es erhält 30 Prozent geschützte Zeit, in der keine Tickets zugewiesen werden, und automatisiert die häufigsten Eingriffe zuerst. Nach einem Jahr ist der manuelle Aufwand spürbar gesunken, und in manchen Bereitschaftswochen klingelt das Telefon nachts kein einziges Mal.
Wo steigen Sie bei SRE ein?
SRE macht Zuverlässigkeit messbar und Betrieb automatisierbar — der beste Einstieg hängt an Ihrem größten Schmerz. Zwei Klicks geben die Richtung.
Was belastet den Betrieb am meisten?
- Worin unterscheidet sich SRE von DevOps?
- DevOps ist eine Kultur, die Entwicklung und Betrieb zusammenführt, SRE ist eine konkrete Umsetzung dieser Idee mit festen Praktiken wie SLOs, Error Budgets und dem Abbau von Toil. DevOps sagt, dass beide Seiten gemeinsam Verantwortung tragen sollen. SRE sagt, wie das im Betrieb gemessen und entschieden wird.
- Was sind SLI, SLO und SLA im SRE-Kontext?
- Ein Service Level Indicator (SLI) ist die gemessene Größe, etwa die Fehlerrate. Ein Service Level Objective (SLO) ist das interne Ziel dafür. Ein Service Level Agreement (SLA) ist die vertragliche Zusage an Kunden, meist mit Vertragsstrafen bei Verletzung. SLOs liegen bewusst strenger als SLAs, damit das Team gegensteuern kann, bevor der Vertrag verletzt ist.
- Braucht jedes Unternehmen ein eigenes SRE-Team?
- Nein. Kleinere Organisationen wenden SRE-Praktiken oft in bestehenden DevOps- oder Plattform-Teams an, ohne eine eigene Rolle zu schaffen. Entscheidend sind messbare Zuverlässigkeitsziele, ein vereinbartes Error Budget und Zeit für Automatisierung, nicht der Name im Organigramm.
- Wie unterscheidet sich SRE von Platform Engineering?
- SRE sichert die Zuverlässigkeit laufender Services über SLOs, Error Budgets und Automatisierung. Platform Engineering baut interne Entwicklerplattformen, die solche Praktiken als Self-Service bereitstellen, etwa vorkonfigurierte Pipelines, Monitoring und Deployment-Pfade. In vielen Organisationen liefert SRE die Regeln, die Plattform-Teams danach in ihre Produkte einbauen.
- Was macht ein Site Reliability Engineer?
- Ein Site Reliability Engineer sorgt dafür, dass Services zuverlässig laufen, und behandelt Betriebsaufgaben dabei als Software-Problem. Er definiert SLIs und SLOs, überwacht das Error Budget, automatisiert wiederkehrende manuelle Arbeit, leitet die Incident-Response und moderiert Blameless Postmortems. Die Rolle verlangt Programmierkenntnisse und Betriebserfahrung zugleich.
Wo steht Ihr Team bei Site Reliability Engineering (SRE)?
Uns interessiert, wo Ihr Team bei diesem Thema steht. Auf Basis Ihrer Antwort schlagen wir Ihnen den sinnvollsten nächsten Schritt vor — ganz ohne Formular.
Weiterführende Primärquellen zu Site Reliability Engineering (SRE): Normtexte, Hersteller- und Projektdokumentation. Alle Ziele öffnen in einem neuen Tab.
- /01Google SRE BookSite Reliability Engineering(externe Seite, öffnet in neuem Tab)
Das frei lesbare Standardwerk, in dem Google die Disziplin beschreibt.
- /02GoogleThe Site Reliability Workbook(externe Seite, öffnet in neuem Tab)
Der Praxisband mit Umsetzungsbeispielen zu SLOs, Alarmierung und Betrieb.
- /03Google SRE BookService Level Objectives(externe Seite, öffnet in neuem Tab)
Das Kapitel zu SLI, SLO und SLA, dem Kern der SRE-Steuerung.
Erstgespräch.
Kostenlos.
90 Tage zum Ergebnis.
Wir klären gemeinsam, wie Sie in 90 Tagen die ersten messbaren Industrial-DevOps-Erfolge erzielen.
Industrie · Automotive · Finance