Was ist Chaos Engineering & warum ist es wichtig?
Warum ist Chaos Engineering wichtig? Schauen wir uns zuerst an, warum Quality Assurance (QA) überhaupt existiert.
Ganz einfach: QA existiert, weil wir, egal wie sehr wir uns bemühen, perfekte Software zu erstellen, die immer das tut, was sie soll, in der realen Welt nie ganz ankommen.
Fehler schleichen sich ein. Maschinen interpretieren unseren Code anders, als wir es beabsichtigen. Dinge passieren. Qualitätssicherung existiert, um diese unbeabsichtigten Probleme zu finden, bevor es unsere Kund:innen tun.
Was ist Chaos Engineering?
Chaos Engineering ist ein disziplinierter Ansatz, um potenzielle Ausfälle zu identifizieren, bevor sie zu Ausfällen führen. Bei Chaos Engineering entwirfst du Experimente zur Fehler-Injektion und vergleichst, was du erwartest, mit dem, was tatsächlich in deinen Systemen passiert. Du „lässt absichtlich Dinge schiefgehen“, um zu lernen, wie du robustere Systeme baust.
Warum ist Chaos Engineering wichtig?
Weil sich Systeme verändern. Traditionell führt QA eine Vielzahl von Tests und Testarten durch, um diese Probleme proaktiv zu finden, lange bevor der Code in Produktion geht. Diese Tests laufen am Ende eines Builds und bevor der Code öffentlich ausgerollt wird, meist im Staging- oder Testsystem statt beim Testen in Produktion.
Bisher ist alles gut, wenn wir in einem traditionellen Softwareentwicklungs- und Deployment-Modell arbeiten. Monolithische Architekturen und Deployments auf firmeneigene Maschinen bieten viel Kontrolle. Daraus ergibt sich Stabilität. Daher ähneln diese Staging- und Testumgebungen oft der Produktionsumgebung und erlauben erfolgreiches Testen.
Verteilte Systeme sind anders. Die Cloud ist anders. Wir kontrollieren die Infrastruktur nicht. Sie ändert sich ständig. Die Infrastruktur verändert sich gemäß unserem Design mit einzelnen Services, Microservices und Load Balancing, das zusätzliche Rechenknoten hinzufügt oder entfernt, wie benötigt. Failover-Systeme passen sich an, um Risiken zu managen. Die ständige Veränderung verursacht unerwartete, neuartige Verhaltensweisen. Das sind Verhaltensweisen, die wir nicht immer vorhersehen, aber mithilfe einer Testmethode namens Chaos Engineering provozieren und nachstellen können.
Testmethoden müssen sich anpassen, wenn sich Systeme wandeln
Wir können nicht effektiv alles testen, was unser Produktionscode und die Umgebung erleben werden, indem wir in irgendeiner anderen Umgebung testen. Wir können vieles testen – Aspekte, die traditionelle QA sehr gut abdeckt und weiterhin tun sollte, vielleicht sogar vermehrt automatisiert in der Build-Pipeline. Aber die bisherige QA kann nicht testen, wie unser verteiltes System zum Beispiel reagiert, wenn die Netzwerke zwischen einem Datenspeicher und mehreren Rechenknoten überlastet sind und die Latenz steigt.
Unsere automatisierten und manuellen Tests berücksichtigen diese sich rasant ändernde Produktionsumgebung, in der sich Services je nach Bedarf ein- und ausschalten, nicht ausreichend. Die einzige Möglichkeit zu testen, ob ein verteiltes System unter neuartigen Bedingungen, ausgelöst durch produktionstypische Änderungen, verlässlich bleibt, ist es wie bei allen Testparadigmen zu machen: ausprobieren und herausfinden.
Wie Chaos Engineering funktioniert: Durch Fehler testen und lernen
Wir alle haben Ziele für Verfügbarkeit. Wir alle wollen die Performance verbessern. Dafür müssen wir jede Ressource nutzen, um so viel wie möglich darüber zu lernen, wie unsere Systeme mit Fehlern umgehen – sei es ein Nutzungsfehler beim Ausfüllen eines Formulars oder eine Systemkomponente in der Cloud, die nicht wie erwartet arbeitet.
„Was passiert, wenn…?“ ist eine Frage, die wir alle gern stellen. Dann probieren wir es aus und finden es heraus.
Da sich unsere Systeme und deren Architektur in bislang nie dagewesener Weise entwickelt haben, müssen wir auch unsere Testmethoden weiterentwickeln, um besser zu verstehen, wie die verteilten Systeme mit Fehlern umgehen und wie Fehler bei Komponenten und Abhängigkeiten das Gesamtsystem beeinflussen. Ganzheitliches Testen dieser Art ist die Aufgabe von Chaos Engineering, denn es kann das komplette System unter realen Produktionsbedingungen überprüfen.
Ein Chaos-Engineering-Programm startet klein: Es testet Dinge, die wir bereits wissen oder von denen wir glauben, sie zu wissen:
- Wird unser Überwachungssystem Netzwerk-Latenzen oberhalb bestimmter Schwellen aktiv erkennen?
- Löst das einen Alarm an den Bereitschaftsingenieur aus oder vielleicht automatisierte Gegenmaßnahmen?
- Hat sich unsere Konfiguration im Lauf der Zeit verändert oder starten wir noch immer Rechenknoten entsprechend der Vorgaben?
Wie schlägt sich jede Service-Instanz unter leichter Last? Unter mittlerer Last? Unter hoher Last? Sie sollten sich alle gleich verhalten und unser Load Balancing sollte die Belastung angemessen auf sie verteilen. Was passiert, wenn eine Instanz wegen Problemen mit unserem Load-Balancer plötzlich wesentlich mehr Anfragen erhält als die anderen?
Systematisches Testen chaotischer Systeme bringt entscheidende Vorteile
Wir testen nach wissenschaftlicher Methode, beginnen im Kleinen und handeln gezielt. Bereits bei den ersten Experimenten achten wir darauf, den Explosionsradius – also die Menge der Dienste und Komponenten, die potenziell betroffen sein könnten – sowie die Stärke der Versuchsparameter zu minimieren.
Wenn wir hier erfolgreich sind, können wir Schritt für Schritt weiter vorgehen und so entweder unser Vertrauen in das System oder unsere priorisierte Liste an Verbesserungen ausbauen. Sobald wir diese Verbesserungen vorgenommen und mit demselben Chaos-Experiment und denselben Parametern erneut getestet haben, wird das System bestehen – und wir wissen, dass es zuverlässiger ist als zuvor.
Nur so können wir erfahren, wie unsere Systeme tatsächlich mit Ausfällen in der Produktion umgehen, wo letztendlich unsere Kundschaft die Auswirkungen spüren würde. Wenn wir kleine Probleme jetzt entdecken, bevor sie sich zu großen auswachsen, können wir dafür sorgen, dass immer weniger systemische Ausfälle auftreten.
Dadurch wird Chaos Engineering zu einem herausragenden Werkzeug für Zuverlässigkeit. Es ist eine Disziplin, mit der wir in der Cloud und im großen Maßstab das tun können, was früher nur in kleineren, kontrollierten Umgebungen mit klassischer Qualitätssicherung möglich war.
Das bedeutet letztlich weniger großflächige Produktionsausfälle und Störungen. Tatsächlich gilt: Wenn Chaos Engineering konsequent eingeführt und angewendet wird, haben die zu erwartenden Service- und Komponentenausfälle, die in der chaotischen Cloud vorkommen, keinerlei Auswirkungen auf unsere Kundschaft. Sie werden nicht einmal bemerken, dass ein Fehler aufgetreten ist – 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:
Mit dem Newsletter kannst du weitere Podcasts und Artikel von The QA Lead immer auf dem neuesten Stand verfolgen. Melde dich hier dafür an.
Du kannst außerdem Mitglied werden, um Zugang zum The QA Lead Community-Forum zu erhalten. Dort kannst du Best Practices mit anderen QAs und Qualitätsexperten austauschen. Wir hoffen, dich dort zu sehen!
Verwandter Artikel: DIE 10 BESTEN SOFTWARETOOLS FÜR QUALITY ENGINEERING: EIN UMFASSENDER LEITFADEN
