Site Reliability Engineering im Mittelstand — Pragmatisch und ohne Google-Maßstab

Wenn im deutschen Mittelstand über Site Reliability Engineering gesprochen wird, schwingt fast immer eine Mischung aus Faszination und Skepsis mit. Faszination, weil das Konzept aus dem Hause Google eine zunächst betriebswirtschaftlich saubere Antwort auf den ewigen Konflikt zwischen Tempo und Stabilität verspricht. Skepsis, weil das berühmte O’Reilly-SRE-Buch von Beyer, Jones, Petoff und Murphy aus einer Welt mit tausenden Engineers, eigenen Rechenzentren und unbegrenzten Budgets geschrieben ist — und der zweimann-IT eines deutschen Maschinenbauers genauso fremd vorkommt wie der durchschnittliche Quartalsbericht eines Hyperscalers. Dieser Artikel zeigt, wie man die wirklich tragenden Ideen von SRE aus diesem Buch isoliert, was davon für ein 5- bis 50-köpfiges Engineering-Team im Mittelstand praktisch funktioniert, und was man bewusst weglässt. Für den Gesamtkontext siehe unseren Cloud-&-DevOps-Guide für den Mittelstand.

SRE vs. DevOps — derselbe Ursprung, unterschiedlicher Fokus

DevOps ist eine kulturelle Bewegung, die seit etwa 2009 die Trennung zwischen Entwicklung und Betrieb aufbricht — gemeinsame Verantwortung, gemeinsame Werkzeuge, gemeinsame Bereitschaft. SRE entstand parallel und unabhängig bei Google ab 2003 als Engineering-Antwort auf dieselbe Frage. Beide Strömungen teilen die Grundannahme, dass Betrieb und Entwicklung nicht trennbar sind. Der Unterschied liegt im Werkzeugkasten: DevOps gibt die Richtung vor, SRE liefert konkrete Methoden — SLOs als Zielgröße, Error-Budgets als Konfliktmechanismus, eine Toil-Obergrenze, blameless Post-Mortems und Runbook-getriebene Incident-Response.

Für die Praxis bedeutet das: ein mittelständisches Unternehmen, das DevOps eingeführt hat (gemeinsame Verantwortung, Infrastructure-as-Code, CI/CD), kann SRE als nächste Schicht obendrauf legen, ohne die Kultur grundlegend zu ändern. Es geht nicht um eine neue Abteilung, sondern um ein paar zusätzliche Kennzahlen und Routinen, die Stabilität messbar machen.

Ein Bild aus der Beratungspraxis: Teams, die DevOps ohne SRE betreiben, diskutieren bei jedem Release-Stress emotional darüber, ob „die Pipeline schneller“ oder „die Plattform stabiler“ werden muss. Teams mit SRE-Werkzeugen schauen auf das Error-Budget des Quartals und entscheiden datenbasiert. Diese eine Verschiebung — von Bauchgefühl auf belastbare Zahl — ist der eigentliche Hebel.

Das Google-SRE-Buch vs. Mittelstands-Realität

Das O’Reilly-Standardwerk beschreibt eine Welt mit eigenen Glasfasertrassen, fünfstelligen Engineering-Teams und SLO-Diskussionen, die mehrere Quartale dauern dürfen. Wer im Mittelstand versucht, dieses Modell eins zu eins zu übernehmen, scheitert garantiert — zu viel Overhead, zu wenig Kapazität. Drei Prinzipien lassen sich aber sauber in eine deutsche Mittelstands-Welt übersetzen, drei andere kann man bewusst zur Seite legen.

Übertragbar sind: erstens die Idee, Verlässlichkeit als Produktmerkmal mit einer Zielzahl (SLO) zu behandeln. Zweitens das Konzept des Error-Budgets als Entscheidungs-Werkzeug zwischen Feature-Tempo und Plattform-Investition. Drittens die Disziplin des blameless Post-Mortems, die nachhaltige Lernkurven erzeugt.

Bewusst weglassen kann man im ersten Jahr: erstens komplexe statistische Methoden zur Lastvorhersage. Zweitens vielschichtige Service-Tier-Klassifikationen mit unterschiedlichen SLOs pro Komponente. Drittens die formale Trennung zwischen SRE-Team und Produkt-Engineering — im Mittelstand ist die SRE-Rolle eher eine Querschnittsfunktion mit einigen Stunden pro Woche als ein eigenes Org-Einheit.

Was bleibt, ist ein kompaktes, alltagstaugliches Vokabular: SLI, SLO, SLA, Error-Budget, Toil, Post-Mortem, Runbook. Dieses Vokabular reicht aus, um Stabilität und Tempo in einem Mittelstands-Team strukturiert zu steuern, ohne ein Google-Buch komplett durchzuarbeiten.

SLI, SLO und SLA — Definitionen mit konkreten Beispielen

Die drei Buchstabenkürzel sind das Fundament. Sie werden im Alltag häufig durcheinandergeworfen, obwohl ihre Bedeutung sauber trennbar ist. Ein SLI (Service Level Indicator) ist eine konkrete, messbare Kennzahl — etwa „Anteil der HTTP-Antworten mit Status 200 bis 399 innerhalb von 500 Millisekunden“. Ein SLO (Service Level Objective) ist ein internes Ziel für diesen Indikator — etwa „99,5 Prozent über 30 rollierende Tage“. Ein SLA (Service Level Agreement) ist eine vertragliche Zusage gegenüber externen Kunden, typischerweise mit finanziellen Folgen bei Unterschreitung — fast immer großzügiger als der interne SLO, damit Spielraum bleibt.

Drei konkrete Beispiele aus Mittelstands-Projekten, die wir begleitet haben:

Workload	SLI	SLO	Typischer SLA
Kunden-Web-Portal (B2B-SaaS)	Anteil HTTP 2xx/3xx unter 800 ms an Login-Endpoint	99,9 % über 30 Tage	99,5 % monatlich vertraglich, 5 % Gutschrift bei Unterschreitung
Interne REST-API (ERP-Anbindung)	Anteil erfolgreicher API-Calls mit Latenz unter 1 s	99,5 % über 30 Tage	Kein externer SLA, nur internes OLA mit Fachbereich
Asynchroner Worker (Rechnungs-Versand)	Anteil Jobs, die innerhalb von 10 Minuten nach Einstellung verarbeitet wurden	99,0 % über 7 Tage	Kein SLA, fachliche Frist „Versand bis Tagesende“

Wichtig: ein SLI muss aus tatsächlich vorhandenen Telemetrie-Daten ableitbar sein, sonst bleibt er Theorie. Wer SLOs ohne Monitoring definiert, optimiert auf eine Zahl, die niemand belastbar messen kann. Die Reihenfolge ist deshalb immer: erst Telemetrie aufbauen, dann SLIs ableiten, dann SLOs vereinbaren. Mehr zum Aufbau einer geeigneten Telemetrie siehe unseren Cluster zum Observability- und Monitoring-Stack.

Error-Budgets als Steuerungs-Werkzeug

Das Error-Budget ist die elegante Folge eines SLOs. Wenn ein Service auf 99,9 Prozent über 30 Tage zielt, sind die fehlenden 0,1 Prozent — rund 44 Minuten Monat für Monat — kein Fehler, sondern erlaubter Spielraum. Dieses Budget wird durch Deployments, Wartungs-Arbeiten, Vorfälle und Experimente verbraucht. Es ist die zentrale Steuergröße zwischen Tempo und Stabilität.

Praktisch entsteht daraus eine einfache Regel: solange das Error-Budget des laufenden Quartals nicht aufgebraucht ist, hat das Produkt-Team Vorrang — neue Features dürfen ausgerollt werden, auch wenn das Risiko trägt. Sobald das Budget verbraucht ist, schaltet das Team in einen Stabilisierungs-Modus: keine neuen Features, stattdessen Aufräumen, Fehlerursachen beheben, Tests verbessern. Diese eine Regel löst den emotionalen Dauerkonflikt zwischen „die Pipeline ist zu langsam“ und „die Plattform ist zu instabil“ in eine nüchterne, datenbasierte Entscheidung auf.

Im Mittelstand reicht ein wöchentlicher Blick auf das Budget. Eine zweispaltige Tabelle im Engineering-Wiki — Budget am Monatsanfang, verbleibendes Budget heute — reicht für die ersten sechs Monate vollkommen aus. Erst wenn die Disziplin sitzt, lohnt sich ein eigenes Error-Budget-Dashboard mit automatischer Berechnung. Wer mit Cache- oder Cache-bedingten Deployment-Phasen arbeitet, sollte den geplanten Wartungsanteil bewusst aus dem Budget herausrechnen, damit echte Vorfälle sichtbar bleiben — siehe dazu auch unseren Artikel zum Zero-Downtime-Deployment.

Toil definieren und reduzieren

Toil bezeichnet im SRE-Vokabular die wiederkehrende, manuelle Routinearbeit, die nötig ist, um einen Service am Leben zu halten, aber keinen nachhaltigen Wert schafft — Server neustarten, Logs aufräumen, Zertifikate verlängern, Standardanfragen aus dem Fachbereich beantworten. Toil ist nicht böse, aber er skaliert linear mit der Größe der Plattform. Wer Toil nicht aktiv reduziert, hat keine Zeit mehr für die Investitionen, die mittelfristig den Bedarf senken.

Die Faustregel: jede Person im Engineering-Team sollte maximal 50 Prozent ihrer Zeit mit Toil verbringen, der Rest fließt in Engineering — Automatisierung, Verbesserung, Investition in Plattform-Funktionen. Im Mittelstand, wo dieselbe Person Entwicklung und Betrieb verantwortet, ist das eine starke Disziplin, die explizit gemacht werden muss, sonst frisst der Betrieb stillschweigend die gesamte Kapazität.

• Toil-Tagebuch über zwei Wochen führenJede On-Call-Person notiert in einer einfachen Tabelle alle Routine-Tätigkeiten und ihren Zeitaufwand. Nach zwei Wochen wird ausgewertet — typisch sind 8 bis 15 wiederkehrende Tätigkeiten, von denen drei bis fünf den Großteil des Aufwands ausmachen.
• Pareto-Ansatz auf die Top 3Die drei aufwendigsten Toil-Quellen werden quartalsweise mit einem konkreten Automatisierungs-Ziel adressiert — Skript, Self-Service-Aktion, Runbook-Automatisierung, Alert-Korrektur, damit nicht die Symptome sondern Ursachen verschwinden.
• Toil-Budget im Sprint-Planning sichernMindestens 20 Prozent jedes Sprints werden für Toil-Reduktion reserviert. Ohne diesen geschützten Anteil verschwinden die Investitionen sofort, sobald der nächste Kundenwunsch eintrifft.
• Erfolg messen — Toil-Trend statt absoluter WertWichtig ist nicht der absolute Toil-Wert, sondern der Trend über mehrere Quartale. Ein Team, das von 70 Prozent auf 40 Prozent Toil-Anteil sinkt, hat seine Engineering-Kapazität de facto verdoppelt — ohne Stelle.

Post-Mortems blameless durchführen

Ein blameless Post-Mortem ist die strukturierte Aufarbeitung eines Vorfalls mit dem expliziten Ziel, Lerneffekte zu maximieren und Schuldzuweisungen zu vermeiden. Die Grundannahme: Menschen handeln in jedem Moment auf Basis der Informationen, die ihnen verfügbar sind. Wenn ein Vorfall entstanden ist, liegt die Ursache fast nie an „dem einen Klick“, sondern an der Kette aus Werkzeugen, Prozessen und Entscheidungen, die diesen Klick möglich gemacht haben.

Ein gutes Post-Mortem-Dokument hat sieben Abschnitte: Zusammenfassung in drei Sätzen, Zeitstrahl mit Minuten-Marken, Auswirkungen mit konkreter Zahl (Kundenanrufe, Umsatz, Ausfallzeit), beitragende Faktoren (technisch und organisatorisch), was gut lief, was hat geholfen, und konkrete Maßnahmen mit Verantwortlichem und Termin. Im Mittelstand reichen zwei A4-Seiten — länger liest niemand, kürzer fehlt Substanz.

Eine Beobachtung aus der Praxis: die schwierigste Hürde ist nicht das Format, sondern die Kultur. Wenn die Geschäftsführung beim ersten ernsten Vorfall „den Schuldigen“ sucht, ist die Methode tot. Wer Post-Mortems einführen will, muss diese Verhandlung vor dem ersten Vorfall mit der Leitung führen — und am besten den Begriff „blameless“ in einer kurzen schriftlichen Erklärung verankern, die für alle gilt, vom Praktikanten bis zum Geschäftsführer.

On-Call-Modelle für kleine Teams

Bereitschaftsdienst ist das organisatorische Herz der Reaktionsfähigkeit. Im Mittelstand stellen sich drei typische Konstellationen, jede mit einem passenden Modell:

Team-Größe	Empfohlenes Modell	Rotations-Rhythmus	Wichtige Regeln
3–4 Engineers	1+1 (Primary + Backup)	Wöchentlich, 2–3 Wochen Pause	Pflicht-Übergaben Montag, Zeitausgleich oder Pauschale, harter Manager-Backup
5–8 Engineers	1+1 mit Themen-Spezialisierung	Wöchentlich, 4–6 Wochen Pause	Trennung nach Plattform/Anwendung, gemeinsame Runbooks
2 Standorte + Partner	Follow-the-Sun light	Tageszeit-Wechsel innerhalb der Geschäftszeit	Nur ausgewählte Services, Nachtzeit über externen Managed-Service

Drei Regeln gelten unabhängig vom Modell. Erstens: maximal eine On-Call-Woche pro Monat pro Person — wer häufiger Bereitschaft trägt, brennt aus, Reaktionsqualität sinkt, Krankenstand steigt. Zweitens: jede Bereitschaft endet mit einer dokumentierten Übergabe, schriftlich, mit allen offenen Themen. Drittens: der Manager ist die letzte Eskalations-Stufe — nicht für jeden Vorfall, aber als verlässliche Rückfall-Linie, wenn Primary und Backup ausfallen. Dieser Manager-Backup ist im Mittelstand besonders wichtig, weil die Bank kleiner ist als bei großen Konzernen.

Für sehr kleine Teams unter drei Personen lohnt sich oft kein eigener Bereitschaftsdienst außerhalb der Geschäftszeit — die Belastung übersteigt den Nutzen. Hier ist ein bewusster Verzicht auf 24/7-Verfügbarkeit oder ein externer Managed-Service für die Nachtstunden meist die ehrlichere Wahl als ein überlastetes Mini-Team.

Incident-Response und Runbooks

Ein Incident ist nicht erst dann ein Incident, wenn ein Server brennt — sondern sobald ein SLO gefährdet ist oder Nutzer spürbare Auswirkungen melden. Das frühe Definieren entscheidet darüber, ob das Team strukturiert reagiert oder erst in der Krise improvisiert. Eine schlanke Incident-Response-Struktur hat drei Rollen: Incident-Commander (steuert, kommuniziert, eskaliert), Tech-Lead (analysiert technisch) und Communications-Lead (informiert Stakeholder, Kunden, Geschäftsführung). In kleinen Teams werden zwei oder alle drei Rollen von einer Person übernommen — solange sie sauber benannt sind, funktioniert das Modell auch zu zweit.

Runbooks sind die schriftliche Verlängerung dieses Modells. Ein Runbook ist eine kurze, ablauforientierte Anleitung für eine konkrete Vorfall-Klasse — „Datenbank antwortet nicht“, „Login-Service liefert 503“, „Disk auf Logserver voll“. Gute Runbooks sind kurz (eine bis zwei Seiten), enthalten die ersten drei diagnostischen Befehle, die häufigsten Ursachen und die Eskalations-Adresse, falls die Standard-Schritte nicht greifen.

Im Mittelstand entsteht die beste Runbook-Bibliothek nicht in einem dedizierten Projekt, sondern als Nachsatz jedes Post-Mortems: für jeden Vorfall, der wieder auftreten könnte, entsteht ein Runbook-Eintrag oder wird ein bestehender ergänzt. Nach zwölf Monaten hat das Team eine echte, gelebte Bibliothek statt einer leeren Schablone.

Capacity-Planning ohne Data-Scientist

Capacity-Planning klingt nach komplexer Mathematik, ist im Mittelstand aber überraschend pragmatisch lösbar. Drei Zahlen reichen für die meisten Workloads: aktuelle Auslastung, Wachstumsrate der letzten zwölf Monate und planbare Sondereffekte (neue Kunden, saisonale Spitzen, Migration). Ein einfaches Tabellen-Modell mit diesen drei Eingaben liefert für 80 Prozent der Mittelstands-Szenarien eine ausreichend belastbare Vorhersage.

Praktisch heißt das: monatlich CPU-, RAM-, Disk- und Netzwerk-Auslastung der wichtigsten Komponenten in ein Spreadsheet eintragen. Quartalsweise prüfen, welche Ressource zuerst eine 70-Prozent-Schwelle erreicht — diese Schwelle ist der Auslöser für Hardware-Bestellung oder Cloud-Skalierungsplan. Eine Auslastung über 80 Prozent dauerhaft ist Warnstufe Rot — dann ist die Maßnahme bereits zu spät.

Für Services mit sehr schwankender Last (Webshop, Event-Plattform) lohnt sich zusätzlich ein einfaches Headroom-Konzept: man definiert die maximale erwartete Spitze (etwa Black-Friday-Last) und stellt sicher, dass die aktuelle Kapazität diese Spitze plus 30 Prozent Sicherheit abdeckt. Diese 30 Prozent sind kein wissenschaftlicher Wert, aber im Mittelstand robust und praktikabel — wer es genauer braucht, kann später auf Forecast-Modelle umstellen.

Reliability vs. Velocity — den Konflikt strukturiert lösen

Der Dauer-Konflikt zwischen Verlässlichkeit und Geschwindigkeit existiert in jedem Engineering-Team. SRE bietet mit Error-Budget und SLO einen sauberen Mechanismus, um diesen Konflikt aus dem Bauchgefühl in eine datenbasierte Entscheidung zu überführen. Die Regel: wenn das Budget aufgebraucht ist, hat Stabilität Vorrang. Wenn es vorhanden ist, hat Tempo Vorrang.

Damit diese Regel funktioniert, braucht es drei Voraussetzungen. Erstens müssen SLOs realistisch gewählt sein — zu hoch und das Budget ist permanent aufgebraucht, zu niedrig und das Budget hat keine Aussagekraft. Zweitens muss das Budget in der Sprache des Produktteams kommuniziert werden — „Wir haben noch 18 Minuten Spielraum diesen Monat“ wirkt deutlich anders als „Service hat 99,932 Prozent Verfügbarkeit“. Drittens muss die Geschäftsführung den Mechanismus mittragen — wenn jeder Manager bei Budget-Erschöpfung eine Sonder-Ausnahme erzwingen kann, ist die Methode tot.

Auch das Zusammenspiel mit dem Team-Aufbau zählt: ein konsequent SRE-orientiertes Team braucht klare Rollen — Plattform, Entwicklung, Produkt — und eine gemeinsame Verständigung über Verantwortlichkeiten. Wer hier organisatorische Lücken hat, sollte parallel den DevOps-Team-Aufbau angehen.

Der 90-Tage-SRE-Startplan

Ein realistischer Einstieg in SRE-Methoden gelingt in drei Monaten, wenn die Schritte klein und konkret bleiben. Der folgende Plan ist in mehreren Mittelstands-Projekten getestet und bewusst ohne Tool-Auswahl als Voraussetzung geschrieben — Werkzeuge sind sekundär, die Disziplin ist primär.

Phase	Wochen	Ziel	Konkretes Ergebnis
1 — Bestand aufnehmen	1–3	Ist-Zustand sichtbar machen	Liste aller produktiven Services, vorhandene Telemetrie, Top-5-Vorfälle der letzten 12 Monate dokumentiert
2 — SLOs für Top-3	4–6	Erste drei SLOs vereinbaren	Drei SLO-Definitionen pro Service mit SLI, Zielwert und Messfenster, schriftlich von Produkt und Engineering unterschrieben
3 — Error-Budget-Routine	7–9	Wöchentliches Budget-Review etablieren	Wiki-Seite mit Budget-Tabelle, wöchentliches 20-Minuten-Meeting, Eskalations-Regel dokumentiert
4 — Post-Mortem-Vorlage	10–12	Erste 2 Post-Mortems durchlaufen	Schablone im Wiki, „blameless“-Erklärung von Geschäftsführung, mindestens 2 Vorfälle nach Vorlage aufgearbeitet

Nach diesen 12 Wochen verfügt das Team über das tragende Gerüst — SLOs, Budgets, Post-Mortems. Toil-Reduktion, Runbook-Aufbau und Capacity-Planning sind dann die Themen für Monat vier bis zwölf, in dieser Reihenfolge. Wer die Reihenfolge umdreht und zuerst Runbooks baut, ohne SLOs zu haben, baut Bibliotheken ohne Steuerungsgröße — sichtbares Engagement ohne messbaren Effekt.

Reepa-Coaching — wie wir mittelständische Teams begleiten

Reepa Solutions begleitet mittelständische Engineering-Teams pragmatisch in die SRE-Methodik. Wir bauen kein Buch nach, sondern arbeiten am vorhandenen Team mit dem vorhandenen Tooling. Ein typisches Coaching-Engagement dauert drei bis sechs Monate mit ein bis zwei Tagen pro Woche und liefert vier konkrete Ergebnisse: definierte SLOs für die Top-Services, eine etablierte Error-Budget-Routine, mindestens drei durchgeführte Post-Mortems nach Vorlage und ein klares On-Call-Modell, das zur tatsächlichen Team-Größe passt.

Was wir nicht tun: ein Standard-Framework überstülpen, eine neue Abteilung empfehlen oder zwingend ein neues Monitoring-Werkzeug verkaufen. SRE-Coaching ist Methoden-Arbeit am Team, nicht Tool-Verkauf — und genau das macht den Unterschied zwischen einem Programm, das nach sechs Monaten lebt, und einer Power-Point, die in der Schublade verschwindet.

Häufige Fragen