20.01.2026 IT Automation
Site Reliability Engineering (SRE) ist ein ingenieurwissenschaftlicher Ansatz, um den zuverlässigen, skalierbaren und performanten Betrieb von Software-Systemen sicherzustellen. Ziel von SRE ist es, Verfügbarkeit, Stabilität und Geschwindigkeit von Anwendungen messbar zu gewährleisten und systematisch zu verbessern – mithilfe von klaren Servicezielen, Automatisierung und datengetriebenen Betriebsprozessen.
In unserem Kontext bezeichnet die „Site“ ein System aus einem oder mehreren Computern, auf denen eine Anwendung läuft. Nutzer sollen jederzeit Zugriff auf diese Anwendung haben und dabei eine möglichst angenehme Nutzererfahrung erleben. Angenehme Nutzererfahrung bedeutet in den meisten Fällen vor allem Geschwindigkeit: Niemand möchte lange warten, bis der Film startet, nachdem man sich endlich für einen Titel aus der Watchlist entschieden hat. Die Anwendung soll also zuverlässig – eben reliable – sein.
Der Ursprung des Site Reliability Engineering liegt bei Google. Dort wurde SRE als Antwort auf die drängenden Fragen moderner IT-Organisationen entwickelt: Wie lassen sich hochkomplexe, verteilte Systeme mit minimalen Ausfällen und maximaler Effizienz betreiben? Während dieser Google-geprägte Ansatz SRE stark als organisatorisches und kulturelles Modell versteht, beziehen wir den Begriff „Site“ in diesem Artikel bewusst allgemeiner auf technische Systeme – unabhängig von Unternehmensgröße oder Organisationsform. Im Folgenden betrachten wir SRE daher als eine Disziplin, die durch Designprinzipien, Methoden und Tools den zuverlässigen Betrieb von Anwendungen sicherstellt.
Kurs-Empfehlung: Theorie ist der erste Schritt, doch die Beherrschung komplexer Systemarchitekturen erfordert praktische Erfahrung. Wenn Sie tiefer in die Welt der Fehlertoleranz eintauchen möchten, empfehlen wir unseren Kurs "Site Reliability Engineering & Observability – Design und Betrieb resilienter Systeme". In diesem intensiven Training lernen Sie nicht nur die Theorie hinter Microservices und Resilienz-Pattern kennen, sondern wenden diese direkt in einem Labor an.
Falls Sie sich mehr für das Site-Reliability-Engineering als ein neues Service Management Modell interessieren, empfehlen wir Ihnen den Kurs "Site Reliability Engineering (SRE) Foundation℠". Diese Schulung gibt Ihnen Antwort auf die Frage "Wie eng sollten Softwareentwicklung und Betrieb verzahnt werden und welche Regelungsprozesse werden benötigt?". Zu diesem Kurs haben Sie am Ende die Möglichkeit die dazugehörige Zertifizierungsprüfung der SRE Foundation (vom DevOps Institute by PeopleCert) erfolgreich abzuschließen.
Die Ablösung des Monolithen durch Microservices
Der Kern einer fehlertoleranten Anwendung ist ein von vornherein robust gedachtes Design. Netflix musste das auf die harte Tour lernen ist aber in diesem Zuge zum Pionier der modernen Software Architektur geworden. Bis zum Jahr 2008 betrieb Netflix – damals noch DVD-Versand-Verleih – einen sogenannten Monolithen.
Ein Monolith ist ein Software-Design, das alle Teilschritte, die zur Lösung einer Aufgabe gegangen werden müssen, in einem in sich geschlossenen Konstrukt vereint. Im Prinzip ein bisschen wie ein Auto, bei dem alle Teile fest verschraubt, verschweißt und verlötet sind. Wenn die Maschine läuft, dann läuft sie gut, aber sobald ein Teil versagt, versagt das ganze System. So war es auch bei Netflix. Ein Datenbank-Ausfall 2008 sorgte für einen 3-tägigen Stillstand, 3 Tage konnte keine DVD verliehen werden. Als Reaktion darauf wurde der Umzug in die AWS Cloud beschlossen. Erstaunlicherweise führte das jedoch nicht zu weniger, sondern zu noch mehr Ausfällen. Amazon bot zwar eine quasi-unbegrenzte Anzahl an Servern, aber keiner dieser Server hatte die Power, die die Netflix-eigenen Server hatten, auf denen der Monolith betrieben wurde.
Es musste also eine andere Lösung her – es sollte irgendwie ermöglicht werden, die Arbeit auf mehrere Maschinen zu verteilen. Die Antwort lautete Microservices. Netflix begann den Monolithen zu zerlegen und aus jedem Teilprozess eine eigene kleine Software zu machen, die nur genau eine Aufgabe erfüllt. Die Microservices untereinander kommunizieren dann einfach über ein Netzwerk. Diese Mini-Software-Komponenten konnten problemlos auf den Amazon Servern betrieben und so die Gesamtlast auf eine Vielzahl an Maschinen verteilt werden.
Zufällige Ausfälle durch den Chaos Monkey
Neben der Geburtsstunde der Microservices war der Umzug zu AWS auch die Geburtsstunde des modernen Chaos Engineerings. Netflix hat durch die gehäuften Ausfälle erkannt, dass die Annahme “Alle Server laufen immer zuverlässig” weit entfernt von der Realität ist. Netflix baute als Reaktion mit dem Chaos Monkey ein Tool, das ganz bewusst Ausfälle erzeugt. Der Chaos Monkey knipst nach dem Zufallsprinzip einfach eine bestimmte Menge an Servern aus, allerdings nur zu Bürozeiten. So sind die Entwickler gezwungen, das System so zu entwerfen, dass es trotz dieser Ausfälle funktioniert. Ausfälle und Störungen sollen nicht als Ausnahme, sondern als Standard gesehen werden.
Grundlegende Resilienz-Pattern
Wie so oft steckt der Teufel im Detail, wenn es an die Umsetzung geht. Die grundsätzlichen Konzepte zum Betrieb einer fehlertoleranten, also resilienten, Anwendung sind aber relativ simpel: Redundanz, Load Balancing und Caching.
Was ist Redundanz?
Ein Microservice, der für die Bearbeitung eines Teilprozesses zuständig ist, wird nicht nur in einfacher, sondern in mehrfacher Ausführung betrieben. Alle “Klone” des Microservices tun das gleiche. Wenn einer der Klone ausfällt, übernehmen einfach die anderen. Tools wie Docker und Kubernetes unterstützen uns bei der Umsetzung der Redundanz.
Was ist Load Balancing?
Ein Load Balancer, wie z.B HAProxy, ist dafür zuständig, Anfragen, die an einen Microservices gerichtet sind, möglichst optimal auf alle verfügbaren Klone zu verteilen. Im einfachsten Fall wird durchrotiert. Load Balancer bemerken durch regelmäßige Health Checks, wenn ein Klon nicht mehr erreichbar ist, und verteilen die Last auf die übrigen.
Was ist Caching?
Jeder Klon eines Microservices soll jede Anfrage mit gleicher Qualität beantworten können. Wenn ich zum Beispiel beim Online-Shopping verschiedene Produkte in meinen Warenkorb lege, möchte ich, dass diese auch nach dem Browser-Refresh noch vorhanden sind. An dieser Stelle kommt das Caching ins Spiel. Ein Cache ist ein Zwischenablageort für Informationen. In unserem Beispiel würde also jeder Klon den Inhalt des Warenkorbs in einem zentralen Cache ablegen und bei einer neuen Anfrage den Warenkorb des jeweiligen Users aus dem zentralen Cache abfragen. Selbiges wäre natürlich mit einer Datenbank möglich. Caches sind um einiges schneller, Datenbanken hingegen sicherer. Es kommt also immer auf den Anwendungsfall an.
Fazit zu den Resilienz-Pattern
Redundanz senkt die Ausfallwahrscheinlichkeit des Gesamtsystems (ca. 90% pro zusätzlicher Redundanz). Load Balancing verteilt die Last gleichmäßig über alle Redundanzen und entfernt nicht erreichbare Klone aus dem Pool. Caching sorgt dafür, dass jeder Klon jede Anfrage mit gleicher Qualität beantworten kann.
Darüber hinaus gibt es noch eine Handvoll weiterer Resilienz-Pattern, wie z.B. Connection Pooling, Bulkheading, Rate Limiting oder Circuit Breaking. Diese dienen der Limitierung von Traffic und Ressourcen-Bedarf.
Event-Driven Architecture
Um das Ganze auf die Spitze zu treiben, könnte man noch eine Event-Driven Architecture umsetzen. In diesem Fall sprechen die einzelnen Komponenten nicht mehr direkt miteinander, sondern kommunizieren über eine Middleware wie z.B. Kafka.
Monitoring, Logging und Alerting
Die Frage, ob ein System verlässlich ist, ist gar nicht so leicht zu beantworten. Dazu müssen zunächst sogenannte SLIs und KPIs gefunden werden. SLIs sind Service Level Indicators, also messbare und vergleichbare Größen, die die Performance einer Komponente beschreiben. Klassiker wären hier die Anzahl der geworfenen Fehler oder die Latenz. KPIs (Key Performance Indicators) beschreiben nun nicht mehr die Performance einzelner Komponenten, sondern die des Gesamtsystems. Bei Netflix sind das z.B. die Streamstarts pro Sekunde.
Service Level Objectives (SLOs) sind interne Richtwerte, die die SLIs nicht überschreiten sollten. Service Level Agreements (SLAs) sind vertraglich festgehaltene Versprechungen an die Kunden eines Services.
Was ist Monitoring & Alerting?
Sobald also SLIs und KPIs definiert wurden, kann das Monitoring eingerichtet werden. Monitoring bedeutet nichts anderes als Beobachtung. Hierzu dienen Tools wie Prometheus oder Victoria Metrics. Solche Monitoring Tools überprüfen in regelmäßigen Abständen die einzelnen Microservices, holen sich deren Metriken und speichern diese in einer Datenbank.
In gängigen Monitoring Tools können Schwellenwerte festgelegt werden. Sollte einer dieser Schwellenwerte für einen bestimmten Zeitraum über- oder unterschritten werden, wird ein Alarm ausgelöst. Mit Tools wie dem Prometheus Alertmanager können solche Alarme dann über bestimmte Kanäle kommuniziert werden.
Was ist Logging?
Nicht zu verwechseln mit dem Monitoring ist das Logging. Das Monitoring dient der Echtzeit-Überwachung eines Dienstes. Das Logging auf der anderen Seite schreibt Informationen zu den einzelnen Vorkommnissen während des Programmablaufs mit. Hier wird beispielsweise festgehalten, welcher User zu welchem Zeitpunkt welche Anfrage gestellt hat, und ob die Anfrage erfolgreich beantwortet wurde. Die Idee des Loggings ist, Probleme, die durch Monitoring entdeckt wurden, genauer unter die Lupe zu nehmen und zu beheben.
Was ist Chaos Engineering?
Chaos Engineering beschreibt das absichtliche und kontrollierte Erzeugen von Ausfällen und Störungen in einem System. Die grundlegende Idee ist, dass es früher oder später zwangsläufig zu Ausfällen kommen wird. Für genau diese Gegebenheit soll ein Bewusstsein geschaffen werden. Die Entwickler und Betreiber einer Applikation sollen durch die absichtliche Einführung von Störungen gezwungen sein, das System so zu gestalten, dass die Störungen möglichst geringen bis keinen negativen Einfluss auf die Kundenerfahrung haben. Kontrollierte Einführungen von Störungen werden als Chaos Experimente bezeichnet.
Netflix war maßgeblich daran beteiligt, das Chaos Engineering salonfähig zu machen. Inzwischen wurde dieses Konzept von allen Tech-Giganten adaptiert. Mit Chaos Experimenten kann zum einen die Resilienz eines Systems getestet und validiert werden. Zum anderen kann mit Chaos Experimenten bestimmt werden, ob ein Service geschäftskritisch ist oder nicht.
Kurs-Empfehlung: Theorie und Patterns sind die Basis, doch die wahre Resilienz eines Systems zeigt sich erst unter Last und bei echten Fehlern. Möchten Sie lernen, wie Sie die Stabilität Ihrer eigenen Infrastruktur systematisch auf die Probe stellen? Dann ist unser Kurs "Chaos Engineering – Grundlagen, Methoden und Tools" genau das Richtige für Sie.
Fazit
Neben diesen technologischen Aspekten gibt es aber noch jede Menge kulturelle und kommunikative Blickwinkel des Site Reliability und Chaos Engineerings – CALMS, Blameless, gewaltfreie Kommunikation, Offene Fehlerkultur, usw. Die Quintessenz lässt sich aber recht einfach zusammenfassen: Schimpfen hilft nichts, denn Fehler können immer und jedem passieren. Packen wir's gemeinsam an, lernen daraus und machen es in Zukunft besser!
FAQ zu Site Reliability Engineering und Chaos Engineering
Was ist der Unterschied zwischen SRE und DevOps?
Obwohl beide Disziplinen darauf abzielen, die Lücke zwischen Entwicklung und Betrieb zu schließen, gibt es einen feinen Unterschied: DevOps ist eher eine philosophische Kultur der Zusammenarbeit. Site Reliability Engineering (SRE) ist die konkrete, ingenieurwissenschaftliche Umsetzung dieser Philosophie. Man sagt oft: „SRE ist das, was passiert, wenn man einen Software-Ingenieur bittet, den IT-Betrieb zu gestalten.“ Während DevOps Prinzipien definiert, liefert SRE die Metriken (SLIs/SLOs) und Werkzeuge, um diese messbar zu machen.
Warum ist Chaos Engineering wichtig für die Systemstabilität?
Chaos Engineering hilft dabei, Schwachstellen in einer IT-Infrastruktur aufzudecken, bevor sie im Ernstfall zu echten Ausfällen führen. Durch das gezielte Herbeiführen von Fehlern – wie etwa durch den Chaos Monkey – lernen Systeme und Teams, resilienter zu werden. Anstatt auf einen Zufallsausfall zu warten, wird die Fehlertoleranz von Microservices aktiv unter kontrollierten Bedingungen getestet, um die allgemeine Verfügbarkeit (Reliability) zu erhöhen.
Was bedeuten SLI, SLO und SLA im SRE-Kontext?
Diese drei Begriffe bilden das Rückgrat der datengetriebenen Zuverlässigkeit:
- SLI (Service Level Indicator): Eine konkrete Messgröße, zum Beispiel die Antwortzeit in Millisekunden.
- SLO (Service Level Objective): Das Ziel, das man erreichen will (z. B. 99,9 % der Anfragen müssen schneller als 200 ms sein).
- SLA (Service Level Agreement): Das rechtliche Versprechen an den Kunden, was passiert, wenn die SLOs nicht eingehalten werden (z. B. Gutschriften).
Wie verbessern Microservices die Fehlertoleranz gegenüber Monolithen?
In einer Monolithen-Architektur kann ein einzelner Fehler im Code das gesamte System lahmlegen. Bei Microservices wird die Anwendung in kleine, unabhängige Einheiten zerlegt. Fällt ein einzelner Dienst aus (z. B. die Suchfunktion), können andere Teile der Anwendung (z. B. der Warenkorb oder das Login) dank Redundanz und Load Balancing oft reibungslos weiterlaufen. Dies minimiert die sogenannte „Blast Radius“ (den Schadensradius) eines Fehlers massiv.
Das könnte Sie auch interessieren
Git & GitLab Trainings von ExperTeach – Grundlagen für eine Automatisierung vom Quellcode bis zum Deployment
Docker & Kubernetes Trainings von ExperTeach – Lernen Sie containerisierten Anwendungen und deren automatisierten Verwaltung kennen
Ansible & Terraform Trainings von ExperTeach – Ansible für effizientes Konfigurationsmanagement und Terraform für modernes Provisioning
Kafka und RabbitMQ Training von ExperTeach – Lernen Sie die Grundlagen zu Message Queuing kennen
Elasticsearch Training von ExperTeach – Erhalten Sie mit diesem Kurs ein Grundverständnis für Elasticsearch
Google SRE – What is SRE Role and Responsibilities – Lesen Sie das Online Buch von den Erfindern von SRE
Netflix TechBlog: Chaos Engineering Chronik – Lesen Sie in der Chronik von Netflix zum Chaos Engineering