Chaos Engineering: Für kontrollierte Unordnung sorgen

Das Thema Chaos Engineering erfährt immer mehr Aufmerksamkeit. Aber warum soll man absichtlich etwas kaputt machen?

Architektur/Methoden  –  31 Kommentare

(Bild: Shutterstock.com / von makasana photo)

Für Entwickler ist es ein primäres Ziel, stabile, sichere und fehlerfreie Software zu entwickeln, die auch in Produktion keine Nerven kostet und von der weiteren Arbeit abhält. Um dieses Ziel zu erreichen, schreiben Entwickler Unit- und Integrationstests, die das erwartete Verhalten überprüfen und sicherstellen, dass die getesteten Muster zu keinem Fehler führen. In zeitgemäßen Architekturen finden sich allerdings viele Komponenten, die diese nicht abdecken können. Es gibt unbekannte Server oder Komponenten, die es schaffen, das Gesamtsystem zum Ausfall zu bringen.

Deshalb hat das Streaming-Portal Netflix in den letzten Jahren das Thema Chaos Engineering vorangetrieben und viel zu seiner wachsenden Bedeutung beigetragen. Es startete mit der Entwicklung eines Chaos Monkey, der die Aufgabe hat, laufende AWS-EC2-Instanzen per Zufall zu zerstören.

Das Wissen, dass die Instanzen jederzeit ausfallen können, hat bei Entwicklern, Operations und beim Applikationsdesign zu einem Umdenken geführt. Die Wahrscheinlichkeit von einem Ausfall betroffen zu sein erhöht sich deutlich und muss durch den Einsatz passender Pattern aus dem Werkzeugkasten des Resilient Software Design gemildert und aktiv bekämpft werden.

Komplexität moderner Systeme

Zeitgemäße und hochverfügbare Systeme sind komplex und nicht auf den ersten Blick zu begreifen. Es muss sichergestellt sein, dass die autonom entwickelten und jederzeit neu deployen Applikationen ihre benötigten Ressourcen und Abhängigkeiten finden und auf sie zugreifen können. Ein temporärer Ausfall durch ein neues Deployment oder einen Fehler in einer Abhängigkeit darf nicht zum Ausfall der Applikation führen. Die Applikation muss mit den Störungen umgehen können und mit einem passenden Verhalten darauf reagieren.

Im Fokus müssen dabei die Kunden stehen. Er soll jederzeit das Gefühl und die Sicherheit haben, dass das System in einem stabilen Zustand ist. Aus Unternehmenssicht ist der durch einen Ausfall mögliche Umsatzverlust eine direkte Auswirkung. Eine weitere ist ein möglicher Schaden des Rufs, den der Service bei den Kunden genießt. Ist die Verfügbarkeit und das Verhalten unbefriedigend, spricht sich das in einer vernetzten Welt schnell herum und hat ebenfalls eine direkte Auswirkung auf den Umsatz. Ist es zu solch einer Welle der Entrüstung in den sozialen Medien gekommen, können Unternehmen darauf nicht mehr angemessen und kontrolliert reagieren.

Neben dem Ziel, eine stabilere Software zu entwickeln, sollte man den sozialen Aspekt beim Chaos Engineering nicht unterschätzen. Es geht nicht darum, etwas zu zerstören, sondern die richtigen Menschen an einen Ort zu bringen und gemeinsam das Ziel einer stabilen und fehlertoleranten Software zu verfolgen. Chaos Engineering darf nicht dazu dienen, Kollegen ihre gemachten Fehler oder falsch getroffenen Entscheidungen beim Entwickeln der Software vorzuführen oder sie zu beschuldigen. Das Ziel sollte sein, Software zu verbessern und Kunden den bestmöglichen Service anzubieten. Auch wenn im Hintergrund die Hütte brennt, darf das keinen gravierenden Einfluss auf den Kunden haben.

Die Grundlagen des Testens

Beim Entwickeln von Software sichert man die Implementierung durch Tests in unterschiedlichen Ausprägungen ab. Dabei verweisen Entwickler gerne auf die Testpyramide, die veranschaulicht, in welchem Umfang man welche Testart schreiben sollte. Die Testpyramide veranschaulicht jedoch auch ein Dilemma: Je weiter man sich mit einem Testszenario nach oben bewegt, desto mehr Aufwand, Zeit und Kosten entstehen.

Die Testpyramide (Abb. 1)

Beim Erstellen von Unit-Tests schreiben Entwickler Testfälle, um das erwartete Verhalten zu überprüfen. Die zu testende Komponente ist entweder von allen Abhängigkeiten befreit, oder man hat ihr Verhalten mit Mocks fest im Griff. Die Tests können die Fehlerfreiheit nicht garantieren. Sollten Entwickler des Moduls in der Implementierung der Komponente einen Denkfehler gehabt haben, tritt der Fehler in den Tests auf, unabhängig davon, ob die Entwickler erst die Tests und dann den Code implementiert haben. Eine mögliche Abhilfe schafft das sogenannte Extreme Programming, bei dem sich Entwickler beim Schreiben der Tests und der Implementierung der Funktionen kontinuierlich abwechseln.

Ein Unit-Test im Detail (Abb. 2)

Um Entwicklern und Verantwortlichen mehr Freizeit gönnen zu können, folgen nach den Unit-Tests noch Integrationstests, die das Zusammenspiel einzelner Komponenten überprüfen. Integrations-Tests laufen im Idealfall nach den erfolgreich getesteten Unit-Tests automatisiert durch und testen voneinander abhängige Komponenten.

Integrationstest im Überblick (Abb. 3)

Durch eine hohe Testabdeckung und Automatisierung erreicht man einen stabilen Zustand der Anwendung. Aber wer kennt nicht das ungute Gefühl auf dem Weg zur Produktion? Nur unter realen Bedingungen kann man erkennen, wie sich die einzelnen Bausteine der Gesamtarchitektur verhalten. Das ungute Gefühl hat der Einsatz zeitgemäßer Microservices-Architekturen verstärkt, die Komplexität und lose Kopplung hat zugenommen. Es muss mit viel Bedacht daran gearbeitet werden, die lose Kopplung aufrechtzuerhalten, um nicht in einem verteilten Monolithen zu landen.

Erosion der Softwarearchitektur

In Zeiten von Microservices und deren loser Kopplung erreicht man schnell eine Softwarearchitektur, die sich unter dem Begriff Distributed System zusammenfassen lässt. Die entwickelten Systeme sind einzeln für sich schnell zu begreifen, ihre Aufgabe ist einfach zu verstehen und sie lassen sich schnell deployen und skalieren. Das führt in den meisten Fällen zu einer Architektur, die wie folgt aussieht:

Eine typische Softwarearchitektur beim Einsatz von Microservices (Abb. 4)

Architekturdiagramme vermitteln eine klare und abstrakte Sicht auf die entwickelte Software. Beim Betrieb der Architektur treten jedoch Szenarien auf, die sich nicht aus einem Architekturdiagramm ableiten lassen. Darunter liegende Schichten sind nicht zu erkennen, auch die eingesetzte Hardware ist nicht zu fassen. Es sind unzählige Komponenten notwendig, um eine performante und robuste Anwendung zu betreiben. In der Produktion erwarten Entwickler etwas, was dem folgenden Architekturdiagramm nahekommt.

Softwarearchitektur in alltäglichen Projekten (Abb. 5)

Der Load Balancer kennt nicht alle Instanzen des Gateways oder kann sie im Netzwerk dank einer Firewall-Regel nicht erreichen. Die Service Discovery kann sich nicht synchronisieren und liefert unterschiedliche Ergebnisse. Die eine oder andere Applikation ist tot, doch die Service Discovery bekommt den Ausfall nicht mit. Die Last wird wegen fehlender Instanzen nicht verteilt und führt zu einer erhöhten Last auf einzelne Knoten. Das kommt manchen vielleicht vertraut vor. Die meisten Entwickler wissen, was es heißt, sich mit defekter Hardware, fehlerhafter Virtualisierung, falsch konfigurierten Firewalls und langwierigen Abstimmungen innerhalb des Unternehmens auseinandersetzen zu müssen.

Was kommt danach?

Der Ansatz zeigt, wo Probleme liegen können. Ein Blick auf eine äußerst komplexe Architekur wie die von Netflix hilft, das Ausmaß einer zeitgemäßen Microservices-Architektur noch besser begreifen zu können.

"Resiliency through Failure" (A. Tseitlin, QCon NY, 2013) (Abb. 6)

Umso beeindruckender ist, wie gut die Architektur von Netflix funktioniert und auf mögliche Fehler reagieren kann. Wenn man sich Vorträge des Netflix-Teams anschaut, stößt man früher oder später über die Aussage: "Keiner weiß, wie und warum das funktioniert." Diese Erkenntnis hat bei Netflix das Thema Chaos Engineering ins Leben gerufen.

Um das Verhalten der komplexen und hochverfügbaren Systeme besser zu verstehen, setzt Netflix Chaos Engineering ein, um den Entwicklern, Operations und anderen Beteiligten die Sicherheit und das Vertrauen in die von ihnen entwickelte und betrieben Software zu vermitteln. Ein Ausfall in Produktion führt bei allen Beteiligten zu einem klaren Verhalten: Sie reagieren zielgerichtet und fokussieren sich auf die vom Ausfall betroffene Komponente, ohne sich die Zeit nehmen zu müssen, das große Ganze im Blick zu haben.

Die für alle unangenehmen Ausfälle treten in Produktion vereinzelt und unkontrolliert auf. Durch Chaos Engineering ist es möglich, die Ausfälle kontinuierlich und kontrolliert stattfinden zu lassen. Die Beteiligten haben die notwendige Zeit und Mittel, den Ausfall und das Verhalten zu analysieren.

Die Regeln des Chaos Engineering

Damit Chaos Engineering kontrolliert und kontinuierlich stattfinden kann, gibt es ein paar zentrale Regeln, die jedem bewusst sein müssen. Ohne ein definiertes Vorgehen und eine Absprache führt Chaos Engineering nur zu weiterem Chaos, aus dem keine Verbesserung erwirkt werden kann

  1. Man sollte mit Kollegen über geplante Chaos-Experimente vorher sprechen.
  2. Wenn die Konsequenzen des Experiments bereits klar sind, lohnt es sich nicht.
  3. Chaos Engineering soll Hypothesen beweisen oder widerlegen und nicht für Überraschungen sorgen.
  4. Chaos Engineering soll helfen, verteilte Systeme besser zu verstehen.
  5. Der Radius der Experimente sollte begrenzt sein.
  6. Man sollte während des Experiments immer Herr der Lage sein.

Prinzipien des Chaos Engineering

Das Chaos Engineering sollte immer die folgenden Phasen durchlaufen. Ein kleiner Start mit einem geringen Radius ist zu empfehlen. Einfach irgendwo einen Stecker zu ziehen und abzuwarten, was passiert, hat nichts mit Chaos Engineering zu tun. Man soll kein unkontrolliertes Chaos auslösen, sondern es aktiv bekämpfen und ihm vorbeugen. Empfehlenswerte Lektüren sind die [Link auf principlesfchaos.org:Website%20principlesofchaos.org] und ein kostenloses E-Book zum Thema.

Die Level des Chaos Engineering

Beim Chaos Engineering geht es nicht nur darum, etwas an der Infrastruktur zu ändern, um Schwachstellen oder die sogenannten Dark Debts zu finden. Unter Dark Debts versteht man die "dunklen" technischen Schulden, die zu den denkbar ungünstigen Zeitpunkten in Erscheinung treten. Es ist bekannt, dass Fehler oder Schwachstellen vorhanden sind, wie sie sich aber im Betrieb der Applikation verhalten und unter welchen Umständen sie auftreten, ist unbekannt. Die Dark Debts gilt es gezielt ans Licht zu bringen, unter kontrollierten und limitierten Bedingungen. Treten die Dark Debts in Produktion auf, fehlt schlichtweg die Zeit, sich ihrer in Ruhe anzunehmen und sie zu eliminieren.

Chaos Engineering findet auf vielen Ebenen statt. Man führt es auf insgesamt sechs Leveln durch. Dabei geht es darum, Fehler in der Kommunikation und in der Behandlung von Ausfällen innerhalb des Teams und aller beteiligten Ressourcen zu erkennen. Hier kommen die Unternehmenskultur und das Zusammenspiel aller Beteiligten zum Tragen. Ein Experiment hat nicht zum Ziel, eine Schwachstelle und einen Schuldigen zu finden, sondern darum, die Schwachstellen zu erkennen und zu beseitigen. Das kann heißen, dass manche Prozesse für den Betrieb der Anwendung falsch oder sogar störend sind. Das kann man mit Experimenten der ersten drei Level feststellen. Man kann herausfinden, wie schnell ein Service-Ticket geöffnet wird, sollte ein wichtiger Service ausfallen, und wie lange es dauert, bis der Service wieder verfügbar ist. Vieles lässt sich automatisieren, aber auch das muss funktionieren und testbar sein.

Die Level des Chaos Engineering (Abb. 7)

Die unteren drei Level sind die, auf denen man mit geeigneten Chaos-Tools Angriffe und Veränderungen durchführen kann. Der Chaos Monkey von Netflix beschränkt sich zum Beispiel auf das Level "Infrastruktur" und schaltet AWS-EC2-Instanzen ab. Was mit einem Chaos Monkey begann, hat sich zu einem eigenständigen Bereich in vielen Unternehmen entwickelt. Mit Plattformen wie dem Chaos Toolkit lassen sich Experimente kontinuierlich und automatisiert durchführen.

Die Phasen des Chaos Engineering

Ziel des Chaos Engineering ist es, das bestehende Chaos und dessen Auswirkungen aktiv zu bekämpfen. Es muss daher zwingend kontrolliert stattfinden und darf nicht zu weiterem Chaos führen. Deshalb ist es wichtig, ein einheitliches und kontrolliertes Vorgehen zu definieren, das allen Beteiligten bekannt sein muss. Hierfür bietet Chaos Engineering ein erprobtes und stabiles Vorgehen.

Die Phasen Chaos Engineering (Abb. 8)

Im Vorfeld sind entsprechende Metriken zu ermitteln und während der Ausführung zu überwachen. Die Metriken sind so zu wählen, dass mit einem Blick erkennbar ist, ob es Anomalien im System gibt, die einen Abbruch des Experiments erfordern. Die dann stattfinden Post-Mortem-Analyse muss die notwendigen Daten liefern, um den Fehler oder das unerwartete Verhalten zu analysieren und geeignete Gegenmaßnahmen zu implementieren. Das sind die nötigen Erkenntnissse, um die gebauten und betriebenen Systeme stabiler zu gestalten. Experimente, die eine Anomalie festgestellt haben, müssen kontinuierlich durchgeführt werden, vergleichbar mit Regressionstests. Experimente, die eine bisher nicht bekannte Schwachstelle aufgespürt haben, sollen durch die kontinuierliche und automatisierte Ausführung ein Wiederkehren des ungewünschten Verhaltens verhindern. Durch das Einführen eines neuen Features oder ein neues Deployment können Fehler wiederkehren und zu einem erneuten Ausfall führen.

Der Learning Loop von Russ Miles (Abb. 9)

Steady State

Es ist wichtig, Metriken zu definieren und kontinuierlich zu überwachen, die eine sichere Aussage zum Gesamtzustand des Systems geben. Metriken können sowohl technisch als auch fachlich sein.

Nach Meinung des Autors überwiegen die fachlichen Metriken die technischen. Netflix überwacht während eines Chaos-Experiments die Anzahl der erfolgreichen Klicks, um ein Video zu starten. Das ist die Kernmetrik und sie ist fachlicher Art. Können Kunden keine Videos starten, hat das unmittelbare Auswirkungen auf die Kundenzufriedenheit. Betreibt man beispielsweise einen Onlineshop, könnte die Anzahl der erfolgreichen Bestellungen oder die Anzahl der in den Warenkorb gelegten Artikel eine wichtige fachliche Metrik sein.

Aktuell werden in Unternehmen und beim Betrieb der Systeme nur die technischen Metriken wie die CPU-Auslastung, die Auslastung des Arbeitsspeichers und die Verfügbarkeit des Netzwerks betrachtet. Das vermittelt aber nicht, ob das Gesamtsystem korrekt arbeitet. In Zusammenarbeit mit dem Fachbereich findet man Metriken, die mit einem Blick zu erkennen geben, ob das System sich im Normalzustand befindet.

Die Werte sollen dann auch historisch vorliegen und als Grundlage dienen, um Anomalien zu erkennen. Der Betrieb, die Entwickler und der Fachbereich können damit zum Beispiel wissen, wie viele Bestellungen sie pro Minute an einem Montagmorgen um 9:45 Uhr haben. Das versetzt Unternehmen nicht nur in die Lage zu erkennen, ob ein laufendes Chaos-Experiment erfolgreich und ohne Fehler im System durchgeführt wird, es gibt ihnen ebenfalls außerhalb des Chaos Engineering die Gewissheit darüber, wie Kunden ihre Service nutzen. Wenn die gewählten Metriken dann noch mit dem Umsatz verknüpft werden, sind die Beteiligten in der Lage zu ermitteln, wie hoch ein möglicher Umsatzverlust bei einer Minute Downtime ist. Die Erkenntnis vermittelt den Entwicklern und dem Betrieb eine detailliertere Sicht auf das System und führt zu einer anderen Wahrnehmung der möglichen Auswirkungen einer Änderung.

Hypothese über das Experiment

Im Vorfeld sollte man sich Gedanken machen, was bei einem Experiment passieren könnte, und es nutzen, die Behauptung unter Beweis zu stellen. Scheitert man daran, müssen die Erkenntnisse helfen, den Fehler zu lokalisieren und gezielt im Team beziehungsweise im Unternehmen zu adressieren.

Das ist mitunter der schwierigste Teil: Es geht nicht um die Suche nach einem Schuldigen. Als Chaos Engineer will man lernen, wie sich ein System verhält, und die Erkenntnisse an die Entwickler zurückgeben. Deshalb ist es wichtig, alle Beteiligten früh mit an Bord zu holen und sie an den Experimenten teilhaben zu lassen.

Um ein Experiment kontrolliert zu testen, muss man sich die Frage stellen, welche Fehler in einer realen Anwendung einer Applikation eintreten können. Mögliche Beispiele wären:

  • Ausfall eines Node im Kafka-Cluster
  • Package-Drops im Netzwerk
  • Hardwarefehler
  • Max-Heap-Size einer JVM
  • Latency
  • Malformed Responses

Die Liste lässt sich beliebig erweitern und ist immer eng mit der gewählten Architektur verbunden. Auch wenn eine Anwendung nicht bei einem der namhaften Cloud-Provider gehostet ist, kann im Rechenzentrum des Unternehmens einiges schiefgehen.

Der Blast-Radius

Um jederzeit die Kontrolle innerhalb der Ausführung eines Chaos-Experiments zu behalten, müssen Entwickler klare Grenzen setzen: den Blast-Radius. Über ihn kann man steuern, welche Komponenten ein Experiment beeinflusst und welche Services durch die Änderungen unmittelbar betroffen sind. Vor der Ausführung ist allen Beteiligten klar, was und in welchem Ausmaß verändert wird. Sollte nun während des Experiments eine Komponente außerhalb des definierten Radius ein verändertes Verhalten ausweisen, muss das Experiment stoppen und eine Analyse starten. Die daraus resultierenden Funde müssen die Teams und Verantwortlichen erfahren: Es gilt die Fehler zu eliminieren und im Anschluss das Experiment erneut auszuführen.

Wenn das vorgesehene Experiment erfolgreich durchgelaufen ist, wird der Blast-Radius erweitert und es werden weitere Komponenten beeinflusst. So ist es zum Beispiel möglich, mehrere Instanzen eines skalierten Service mit Fehlern oder einer höheren Latenz antworten zu lassen. Ebenso ist es denkbar, nicht nur einen Service zu beeinflussen sondern auch weitere Services der Komponente unter Test zu verändern. Der Blast-Radius kennt rein formal kein definiertes Ende, es ist jedoch zu beachten das es irgendwann eine logische Grenze gibt, bei der der Blast Radius eine Größe erreicht hat, die er in Produktion nicht erreichen kann beziehungsweise auf den das System nicht mehr reagieren kann. Der Ausfall eines kompletten Rechenzentrums wäre hier ein Beispiel.

Wenn die gesamte Applikation in nur einem Rechenzentrum betrieben wird und das Experiment einen Totalausfall simuliert und dennoch erwartet wird, dass das System mit diesem Szenario umgehen soll, ist die Grenze eindeutig überschritten. Setzt man aber auf einen der namhaften Cloud-Provider und sichert die Verfügbarkeit durch eine Verteilung auf mehrere geographische Zonen, so ist es absolut valide, den Ausfall einer Zone zu testen. Dies ist oftmals auch Teil der Disaster Recovery und kann mit Chaos Engineering auch automatisiert getestet werden. Dank der Steuerung über den Blast-Radius und des Steady State kann dies in mehreren und sich steigernden Schritten erfolgen.

Beispiel eines Chaos-Experiments

Die Applikation besteht aus mehreren Microservices, die über eine REST-API und eine Service Discovery verbunden sind. Zur Absicherung hält der "Product-Service" einen lokalen Cache des Warenbestands aus dem "Warehouse-Service" vor. Daten aus dem Cache sollen immer dann geliefert werden, wenn der Warehouse-Service nicht innerhalb von 500 Millisekunden antwortet. Erreichen können Entwickler das Verhalten im Umfeld von Java zum Beispiel mit Hystrix oder resilience4j. Dank der Bibliotheken können Anwender einfach und effektiv Fallbacks und weitere Resilience-Pattern implementieren.

Ein Beispiel für ein Chaos-Experiment (Abb. 10)

Nachfolgend fasst eine Tabellen die wichtigen Infos zusammen, die für ein erfolgreiches Experiment notwendig sind. Jedes Chaos-Experiment erfordert eine detaillierte Planung, beteiligte Personen und notwendige Ressourcen müssen bereitstehen.

Target Warehouse-Service
Experiment
Latency
Hypothese Durch die erhöhte Latenz beim Aufruf des Warehouse-Service werden 30 Prozent der Requests aus dem lokalen Cache des Product-Service geliefert.
Blast-Radius Product- und Warehouse-Service
Vorheriger Status OK
Status danach ERROR
Erkenntnisse Product-Service Fallback schlug fehl und führte zu Exceptions, da der Cache nicht alle Requests beantworten konnte.
(Tabelle: Übersicht über ein Chaos-Experiment)

Wie am Ergebnis des Experiments zu erkennen, hat man zwar das eine oder andere Resilience-Pattern eingesetzt, dennoch kam es zu Fehlern. Diese gilt es nun zu beseitigen und mit der erneuten Durchführung des Experiments zu testen.

Automatisierte Experimente

Es genügt nicht, ein Experiment zu starten und danach nie wieder. Chaos Engineering muss kontinuierlich stattfinden. Systeme ändern sich ständig, neue Versionen gehen in Produktion, Hardware wird ausgetauscht, jemand hat die Firewall-Regeln angepasst oder mal eben den Server neu gestartet.

Die hohe Kunst ist es, die Kultur des Chaos Engineering im Unternehmen und den Köpfen der Mitarbeiter zu platzieren. Netflix hat das gezielt herbeigeführt, in dem sie eine Reihe an Tools – die sogenannte Simian Army – auf die Erzeugnisse ihrer Entwickler losgelassen hat, und das auch noch in Produktion.

Die notwendige Umgebung

Für die ersten Experimente sollte man eine Umgebung wählen, die identisch mit der in Produktion betriebenen ist. Ansonsten erlangt man keine aussagekräftigen Erkenntnisse. Sobald die ersten Schritte getan sind und es zu Verbesserungen kam, kann der Weg weiter in Richtung Produktion gehen, um auch dort die Experimente durchzuführen.

Ziel des Chaos Engineering ist es, dass es in Produktion betrieben wird. Lasttestumgebungen haben eine definierte und kontrollierte Last, die leider nicht der der Produktion entspricht. Kunden benutzen Services nicht nur so, wie Entwickler es sich vorstellen. Sie interagieren oftmals anders mit den Services als erwartet. Diese Last und die dadurch entstehenden Requests sind notwendig, um zu erkennen, ob es Fehler im Design oder im Betrieb der Software gibt.

In deutschen Unternehmen ist die Akzeptanz noch sehr gering, Chaos Engineering auch in Produktion durchzuführen. Der Weg in die Produktion ist trotz automatisierter Deployments aufwendig und langwierig. Solange ein kontinuierliches Deployment in Produktion nicht gegeben ist, muss eine Umgebung gewählt und vorbereitet werden, die der der Produktion am nächsten ist. Wichtig ist, dass dort eine identische Infrastruktur und Deployment-Prozesse vorhanden sind. Chaos Engineering nur in einer Testumgebung ohne eine kontinuierliche Grundlast führt nicht zu den Erkenntnissen und Verbesserungen, die man für die Produktion benötigt. Sollten die Experimente nur in einer Entwicklungs-Stage stattfinden, ist sie im Anschluss viel eher für den Einsatz als Produktion geeignet, als es die dafür vorgesehene Produktionsumgebung ist.

Fazit

Der Artikel hat die Grundlagen, Prinzipien und die Idee hinter Chaos Engineering erklärt. Das Thema ist wichtig und es herrscht ein großer Nachholbedarf in deutschen Unternehmen, auch wenn nicht jede Firma die gleichen Anforderungen wie Netflix hat. Chaos Engineering kann helfen, ein Vertrauen in die Leistungsfähigkeit eines Systems zu gewinnen, um den turbulenten Bedingungen in der Produktion besser standhalten zu können.

Der Fokus auf Kunden und ihre Erfahrungen im Umgang mit den entwickelten System gerät leider immer mehr in den Hintergrund. Es fehlen geeignete Metriken, um auf einen Blick zu erkennen, in welchem Zustand das System ist. Moderne und hochverfügbare Systeme sind komplex und bestehen aus vielen Komponenten, deren Zusammenspiel sichergestellt werden muss. Ein Ausfall in Produktion kann zu einem unkontrolliertem Verhalten führen – oft fehlt die Zeit und Ruhe, um eine detaillierte Auswertung des Fehlers durchzuführen.

Chaos Engineering schafft die notwendigen Rahmenbedingungen und eine Veränderung in der Kultur, die zu einer stabileren Software führt. Noch wichtiger ist das erlangte Vertrauen in die Software und die gewonnen Erfahrungen im Betrieb der heutigen komplexen Systeme. (bbo)

Benjamin Wilms
arbeitet als Senior Developer und Chaos Engineer bei der codecentric AG. Seine aktuellen Schwerpunktthemen sind Skalierbarkeit und Resilience in verteilten Anwendungen. Er teilt und diskutiert seine Ideen regelmäßig als Speaker auf Konferenzen sowie als Autor von Artikeln und Blogposts.