Was ist Chaos Engineering & warum ist es wichtig?
Warum ist Chaos Engineering wichtig? Schauen wir uns zunächst an, warum Qualitätssicherung (QA) überhaupt existiert.
Ganz einfach: QA existiert, weil wir, egal wie sehr wir versuchen, perfekte Software zu entwickeln, die sich immer so verhält, wie sie entworfen und vorgesehen ist, in der realen Welt trotzdem nie alles wie gewünscht abläuft.
Fehler schleichen sich ein. Maschinen interpretieren unseren Code anders, als wir es beabsichtigt haben. Es passieren unerwartete Dinge. Quality Engineering existiert, um diese unbeabsichtigten Probleme zu finden, bevor es unsere Kundschaft tut.
Möchten Sie mehr vom The CTO Club?
Erstellen Sie ein kostenloses Konto, um diesen Beitrag fertigzulesen und einer Community von CTOs und Technikleitern beizutreten, die praxisnahe Frameworks, Tools und Einblicke für die Entwicklung, Einführung und Skalierung KI-gesteuerter Technologien teilen.
Have an account? Log In
Was ist Chaos Engineering?
Chaos Engineering ist ein methodischer Ansatz, um potenzielle Ausfälle zu erkennen, bevor sie zu Ausfällen werden. Mit Chaos Engineering werden Fehler-Injektions-Experimente entworfen und die erwarteten mit den tatsächlichen Systemreaktionen verglichen. Man „bricht absichtlich Dinge“, um zu lernen, wie man widerstandsfähigere Systeme baut.
Warum ist Chaos Engineering wichtig?
Weil sich Systeme ständig verändern. Traditionell führt die QA eine Vielzahl von Tests und Testarten durch, um diese Probleme proaktiv zu erkennen – lange bevor der Code in Produktion geht. Diese Tests werden nach dem Build, aber vor dem öffentlichen Deployment durchgeführt, typischerweise in einer Staging- oder Testumgebung im Vergleich zum Testen in der Produktion.
Bis hierhin ist alles gut, solange wir im traditionellen Softwareentwicklungs- und Bereitstellungsmodell arbeiten. Monolithische Designs und Deployments auf firmeninternen Maschinen bieten eine große Kontrolle. Daraus ergibt sich eine gewisse Stabilität. Dadurch sind diese Staging- und Testumgebungen den Produktionsumgebungen ähnlich, was erfolgreiche Tests ermöglicht.
Verteilte Systeme sind jedoch anders. Die Cloud ist anders. Wir kontrollieren die Infrastruktur nicht. Sie verändert sich ständig. Die Infrastruktur verändert sich gemäß unserem Design, indem einzelne Services und Microservices sowie das Load Balancing bei Bedarf zusätzliche Compute-Nodes starten oder wieder entfernen. Failover-Systeme passen sich an, um Risiken zu managen. Diese ständigen Veränderungen bedingen unerwartete, emergente Verhaltensweisen. Das sind Verhaltensweisen, die wir nicht immer vorhersagen, aber mit einer bestimmten Testform – dem Chaos Engineering – reproduzieren und verursachen können.
Tests müssen sich an verändernde Systeme anpassen
Wir können nicht alles, was unser Produktiv-Code und die Umgebung erleben werden, durch Tests in einer anderen Umgebung wirksam prüfen. Wir können vieles testen – das kann die traditionelle QA gut und sollte sie auch weiterhin tun, vielleicht zum Teil zunehmend automatisiert in der Build-Pipeline. Doch die bisherige QA kann zum Beispiel nicht testen, wie unser verteiltes System reagiert, wenn die Netzwerkanbindung zwischen einem Datenspeicher und mehreren Compute-Nodes überlastet ist und die Latenz steigt.
Unsere automatisierten und manuell gesteuerten Tests berücksichtigen diese sich schnell ändernde Produktionsumgebung, in der sich Services je nach Nachfrage starten und beenden, nicht. Die einzige Möglichkeit herauszufinden, ob ein verteiltes System unter unerwartetem Verhalten durch veränderte Produktionsbedingungen zuverlässig bleibt, ist das, was alle Testparadigmen ausmacht: Es einfach ausprobieren und beobachten, was passiert.
Wie Chaos Engineering funktioniert: Lernen durch kontrolliertes Scheitern
Wir alle haben Verfügbarkeitsziele. Wir alle möchten unsere Performance verbessern. Dafür müssen wir alle verfügbaren Ressourcen nutzen, um so viel wie möglich darüber zu lernen, wie unsere Systeme mit Ausfällen umgehen – sei es das Fehlverhalten eines Nutzenden beim Ausfüllen eines Formularfeldes oder der Ausfall einer Systemkomponente in der Cloud, die nicht wie erwartet funktioniert.
„Was passiert, wenn...?" ist eine Frage, die wir alle gerne stellen. Dann probieren wir es aus und finden es heraus.
Da sich unsere Systeme und Systemarchitekturen auf nie dagewesene Weise entwickelt haben, müssen wir auch unsere Testmethoden weiterentwickeln, um besser zu verstehen, wie unsere verteilten Systeme mit Ausfällen umgehen und wie Ausfälle von Komponenten oder Abhängigkeiten das Gesamtsystem beeinflussen. Solch ein ganzheitliches Testen führt das Chaos Engineering aus – weil es unser gesamtes System so prüft, wie es in der Produktion existiert.
Ein Chaos Engineering-Programm beginnt klein und testet anfangs Dinge, die wir schon wissen oder glauben zu wissen:
- Wird unser Monitoring-System Netzwerklatenzen oberhalb eines bestimmten Schwellenwerts rechtzeitig erkennen?
- Wird dadurch eine Benachrichtigung an den diensthabenden Engineer ausgelöst oder vielleicht eine automatisierte Abhilfe?
- Hat sich unsere Konfiguration im Laufe der Zeit verändert oder starten wir noch immer Compute-Nodes gemäß den Vorgaben?
Wie schlägt sich jede Instanz des Dienstes bei leichtem Testen? Mittlerem? Schwerem? Sie sollten alle gleich reagieren und unser Lastenausgleich sollte die Last entsprechend auf sie verteilen. Was passiert, wenn eine Instanz eine deutlich höhere Last erhält als die anderen, weil unser Lastenausgleichsservice Probleme macht?
Systematisches Testen chaotischer Systeme bringt entscheidende Vorteile
Wir testen nach wissenschaftlicher Methode, beginnen klein und handeln gezielt. Frühzeitige Experimente werden so gestaltet, dass der „Blast Radius“ – also die Menge der betroffenen Dienste und Komponenten – sowie der Umfang der Versuchswerte möglichst gering ausfallen.
Nachdem wir hier erfolgreich waren, können wir Schritt für Schritt weiterarbeiten und so immer mehr Vertrauen in unser System gewinnen oder unsere priorisierte Liste mit Verbesserungen ausbauen. Sobald wir diese Verbesserungen umgesetzt und denselben Chaos-Experiment-Test erneut durchgeführt haben, besteht das System den Test, und wir wissen, dass es zuverlässiger geworden ist als zuvor.
Nur so können wir wirklich herausfinden, wie unsere Systeme im Produktionsumfeld auf Fehler reagieren – wo letztlich unsere Kunden die Folgen erleben würden. Wenn wir jetzt schon kleine Probleme finden, bevor sie sich zu großen auswachsen, können wir systemweite Ausfälle stark reduzieren.
Dies macht Chaos Engineering zu einem hervorragenden Werkzeug für Zuverlässigkeit. Es ist eine Disziplin, die es uns ermöglicht, in der Cloud und im Maßstab das zu erreichen, was früher nur in kleineren, kontrollierten Umgebungen mit traditionellem QA möglich war.
Das führt letztlich zu weniger großflächigen Produktionsausfällen und Störungen. Wenn Chaos Engineering konsequent umgesetzt wird, haben die in der Cloud zu erwartenden Ausfälle von Services und Komponenten keine Auswirkungen mehr auf unsere Kunden. Sie bekommen von Fehlern gar nichts mehr mit – und genau das ist das eigentliche Ziel.
Wie geht es weiter?
Ich habe Chaos Engineering ausführlicher in der The QA Lead Podcast-Episode mit Jonathon Wright besprochen.
Hinweis der Redaktion:
Sie können mit anderen Podcasts und Artikeln von The QA Lead auf dem Laufenden bleiben, indem Sie den Newsletter abonnieren.
Sie können außerdem Mitglied werden und Zugang zum The QA Lead Community-Forum erhalten, wo Sie Best Practices mit anderen QAs und Quality Engineers teilen können. Wir freuen uns auf Sie!
Passende Lektüre: DIE 10 BESTEN QUALITY ENGINEERING SOFTWARE TOOLS: EIN UMFASSENDER LEITFADEN
