Unternehmen mit hoher Resilienz, digital ausgereiften Systemen und guter Observability durch Dashboards und andere Tools sollten Chaos-Engineering nutzen, da sie sofort auf Probleme reagieren können, die durch Experimente entstehen.Unternehmen, denen es an dieser Observability mangelt⁴ (Link befindet sich außerhalb von ibm.com), brauchen möglicherweise zu lange, um die experimentellen Ausfälle zu beheben, die sie durch Chaos-Engineering erzeugen.

Chaos-Engineering ist auch ein Muss für Unternehmen, die Clouds, insbesondere Public Clouds, und cloudnative Anwendungen nutzen. Die Public Cloud bringt potenzielle Ausfallprobleme mit sich, die eine Koordination mit dem Cloud-Provider erfordern, was eine andere Herangehensweise als bei On-Premise-Problemen erfordert. 

Laut Constellation Research⁵ (Link befindet sich außerhalb von ibm.com) behandeln Unternehmen, die die Cloud nutzen, IT-Vorfälle immer noch häufig ohne Berücksichtigung der unterschiedlichen Auswirkungen von Cloud und Software-as-a-Service (SaaS) auf diese Vorfälle. 

Darüber hinaus schafft die zunehmende Verwendung von Microservices, die die Anzahl der in einem System ausgeführten Hosts oder Container erhöht, einzigartige Herausforderungen (Link befindet sich außerhalb von ibm.com), die durch Chaos-Experimente aufgedeckt und gelöst werden können. Die Komplexität wird vom Code-Design in den Systembetrieb verlagert, was die Komplexität zwar nicht beseitigt, aber eine stärkere Automatisierung ermöglicht.

Chaos-Engineering kann Unternehmen auch dabei helfen, die Geschwindigkeit ihrer Pipelines für kontinuierliche Integration und kontinuierliche Bereitstellung (CI/CD) zu erhöhen. Die Integration von Chaos-Engineering in CI/CD, wie es Netflix getan hat⁶ (Link befindet sich außerhalb von ibm.com), ermöglicht es Unternehmen, kontinuierliche Experimente zu automatisieren und gleichzeitig deren mögliche Auswirkungen zu kontrollieren. 

Und da Unternehmen zunehmend über APIs mit Partnern verbunden sind, kann ein Problem in ihren Systemen auch negative Auswirkungen auf andere Unternehmen haben.

Der Einsatz von Chaos-Engineering hilft Unternehmen, die Schwachstellen in ihrer Architektur zu erkennen und zu beheben, wodurch sie schließlich zukünftige Ausfälle vorhersehen können. Erfolgreiches Chaos-Engineering hilft Unternehmen, technische Ausfälle mit erheblichen Auswirkungen auf den Kunden zu minimieren, und unterstützt den Aufbau stärkerer und widerstandsfähigerer komplexer Systemarchitekturen. Sobald sich ein Unternehmen für Chaos-Engineering entschieden hat, ist der nächste Schritt die Entscheidung, ob es in der Vorproduktions- oder Produktionsumgebung ausgeführt werden soll.

DevOps-Teams haben mehrere Möglichkeiten, Chaos-Engineering-Experimente durchzuführen, um verschiedene Systemprozesse zu testen.

• Latenz-Injektion: DevOps-Teams erstellen absichtlich Szenarien, die eine langsame oder fehlgeschlagene Netzwerkverbindung emulieren. Dazu gehören Netzwerkverzögerungen oder langsamere Reaktionszeiten.
• Fehlerinjektion: Dabei werden absichtlich Fehler in das System eingebracht, um festzustellen, wie sie sich auf andere abhängige Systeme auswirken und ob sie die Services unterbrechen. Beispiele für Fehlerinjektionen sind das Herbeiführen von Festplattenausfällen, das Beenden von Prozessen, das Herunterfahren eines Hosts oder das Herbeiführen von Leistungs- oder Temperaturerhöhungen. Fehlerinjektionen können Unternehmen dabei helfen, einzelne Fehlerquellen zu identifizieren, die im Falle eines Fehlers zum Ausfall des gesamten Systems führen können.
• Lastgenerierung: Dies bedeutet, dass das System absichtlich belastet wird, indem ein erhebliches Volumen an Datenverkehr weit über den normalen Betrieb hinaus gesendet wird. Dies hilft den Site Reliability Engineers (SREs), etwaige Engpässe im System zu verstehen, was ihnen wiederum ermöglicht, besser skalierbare Systeme zu bauen. 
• Canary-Tests: Dabei wird ein neues Produkt oder eine neue Funktion für eine kleine Gruppe von Benutzern veröffentlicht. Auf diese Weise wirken sich Störungen oder Bugs nur auf einen Prozentsatz der Besucher aus, sodass der Rest der Zielgruppe auf das bestehende Website-Erlebnis zugreifen kann.

Die Schaffung des idealen Chaos-Engineering-Prozesses erfordert mehrere Prinzipien, um sicherzustellen, dass ein Unternehmen ein verteiltes System in großem Umfang einsetzen kann. 

• Verstehen des Systems: Dazu gehört umfassendes Wissen über das gesamte System, seine neuen Eigenschaften und Funktionen sowie seine Topologie, Architektur, Abhängigkeiten, sein Verhalten im stabilen Zustand, seine Ausgabereaktion und Merkmale wie Verfügbarkeit, Latenz und Durchsatz.
  
• Akzeptieren von Fehlern: Auf den ersten Blick scheint es paradox zu sein, dass Softwareingenieure einen Vorfall herbeiführen, obwohl sie eigentlich darauf eingestellt sind, solche Vorfälle zu verhindern. Allerdings wird es bei IT-Services immer wieder zu Störungen kommen, und es ist besser, sie in einer kontrollierten Umgebung zu erleben, um präventiv eine Lösung zu finden, als nach Feierabend, wenn das Team eines Unternehmens nicht arbeitet, oder wenn das Team noch nie mit diesem speziellen Problem konfrontiert war.
• Bestimmen des Verhaltens im stabilen Zustand: Zunächst muss das technische Team definieren, wie sich das System bei korrektem Betrieb verhalten soll. Nur so kann man vergleichen, wie sich Experimente auf diesen stabilen Zustand auswirken.
• Identifizierung von realistischen Vorfällen: Chaos-Engineering-Experimente sollten sich so nah wie möglich an das halten, was an einem normalen Tag passieren könnte, anstatt unwahrscheinliche Situationen zu simulieren. Netzwerk- und Infrastrukturausfälle, fehlerhafter Code, Stromprobleme und Überlastung durch zu viel Datenverkehr sind mögliche Vorfälle.
• Planung eines Game-Days: Das Chaos-Engineering-Team kann die Umgebung an einem sogenannten Game-Day untersuchen, an dem mehrere Tests an einem bestimmten Tag stattfinden, um die Ressourcen zu maximieren und so viele Probleme wie möglich zu identifizieren und zu lösen. 
• Nutzung von Automatisierung: Unternehmen jeder Größe können Chaos-Engineering nutzen, indem sie Experimente automatisieren, bei denen eine manuelle Durchführung zu aufwändig wäre. Dadurch wird die Belastung der IT-Teams während des Chaos-Engineering-Prozesses teilweise verringert. Zu den Aspekten, die Unternehmen automatisieren können, gehören die Planung von Experimenten, die Fehlersuche und die Bereitstellung der Infrastruktur.
• Berücksichtigung des Explosionsradius: Beim Chaos-Engineering ist es wichtig, darauf zu achten, dass der Explosionsradius möglichst klein ist, sodass die Schäden für die Kunden so gering wie möglich sind. Einige Möglichkeiten zur Minimierung des Explosionsradius sind:
  • Konzentration auf eine Teilmenge von Services: Chaos-Engineering, insbesondere in einer Produktionsumgebung, sollte den Service eines Unternehmens nicht grundlegend stören. Wenn Sie eine bestimmte Untergruppe von Services anvisieren, können Sie die Auswirkungen eines Vorfalls minimieren und sicherstellen, dass er nicht das gesamte System lahmlegt.
  • Durchführung des Experiments für eine begrenzte Zeit: Das Experiment sollte einen Anfang und ein Ende haben. Der Sinn des Experiments besteht darin, einen Vorfall zu verursachen und ihn zu lösen, anstatt ihn für eine lange Zeit unkontrolliert laufen zu lassen.
  • Durchführung des Experiments außerhalb der Spitzenlastzeiten: Unternehmen sollten versuchen, Experimente nicht zu Spitzenzeiten durchzuführen, es sei denn, sie wollen speziell messen, wie sich eine hohe Kapazität während eines Vorfalls auf das System auswirkt. 
  • Durchführung des Experiments in der Entwicklungsumgebung: Der einfachste Weg, um sicherzustellen, dass der Service für die Kunden nicht unterbrochen wird, ist die Durchführung in der Vorproduktionsumgebung. Das bedeutet jedoch, dass sich die Bedingungen von denen der Produktionsumgebung unterscheiden und möglicherweise ein falsches Bild von den Vorgängen vermitteln. Um dies zu minimieren, sollten Sie sicherstellen, dass Ihre Vorproduktions- und Produktionsumgebungen einander so weit wie möglich widerspiegeln. 
  • Experimente mit jeder Komponente: Das Experimentieren beim Chaos-Engineering hört nie auf, da sich das System eines Unternehmens ständig verändert. Ein Ziel sollte auch sein, „alles“ zu testen; untersuchen Sie alle Komponenten, Schichten, Services – und ihre Abhängigkeiten während des gesamten Prozesses.

Unternehmen, die Chaos-Engineering einsetzen, müssen entscheiden, ob sie Chaos-Tests in ihren Produktions- oder Vorproduktionsumgebungen durchführen wollen. Es gibt mehrere Gründe, warum Chaos-Engineering in Produktionsumgebungen am vorteilhaftesten ist. Live-Umgebungen bieten die genaueste Umgebung, um zu verstehen, wie sich ein Vorfall auf die Customer Experience auswirkt. Ein weiterer Grund ist, dass die Vorproduktionsumgebung möglicherweise nicht genau die gleichen Einstellungen wie die Live-Umgebung hat, was zu einer gewissen Variabilität bei den Experimenten führt.

So könnte es beispielsweise passieren, dass ein Vorfall in einer Vorproduktionsumgebung keine realistische Reaktion hervorruft, da das Volumen des Datenverkehrs nicht dem der Live-Umgebung entspricht. Die Vorproduktionsumgebung hat außerdem vielleicht nicht die gleichen Sicherheitskonfigurationen wie die Live-Umgebung. 

Einige Unternehmen befürchten, absichtlich Probleme mit ihrer Live-Website zu verursachen, und führen daher ihre Experimente auf ihrer Vorproduktions- oder Entwicklungs-Website durch. Dadurch wird sichergestellt, dass auftretende Probleme die Live-Customer-Experience nicht beeinträchtigen. Um dies zu umgehen, verwenden einige Unternehmen zunächst Vorproduktionsumgebungen, um den Prozess in den Griff zu bekommen, bevor sie in die Live-Produktionsumgebung wechseln.

Unternehmen entscheiden je nach ihrer Risikotoleranz, welche Umgebung sie verwenden. Letztendlich zielt Chaos-Engineering darauf ab, tatsächliche Probleme im großen Maßstab zu testen. Deshalb vermitteln Produktionsumgebungen das genaueste Bild davon, was passiert und was behoben werden muss.