Chaos Engineering
Inhaltsverzeichnis
Was ist Chaos Engineering?
Chaos Engineering ist ein kreativer Ansatz zur Qualitätssicherung, der die Grenzen zwischen Infrastruktur und Anwendungen aufhebt und eine Anwendungsplattform als Ganzes betrachtet. Bei der Qualitätssicherung (QA) zur Absicherung der Anwendungsqualität wurden bisher Infrastruktur und Software oft separat betrachtet und getestet.
Bei der Software-QA werden die entwickelten Artefakte mit den bekannten und bewährten Methoden durch inkrementelle Tests (z.B. Unit Tests, Integrationstests und Systemtests) abgesichert. Gleiches gilt für Infrastruktur-QA, mit der die Umgebung ausgiebig getestet wird, bevor das System freigegeben wird.
Klassischer Testansatz, bei dem die beiden getesteten Teile (Anwendungen & Infrastruktur) in Produktion zusammenlaufen.
Wozu Chaos Engineering?
Mit steigender Komplexität von Anwendungen und Umgebungen erhöht sich aber die Wahrscheinlichkeit, dass gravierende Probleme erst beim Zusammenspiel von Anwendungen und Infrastruktur auftreten. Dann entsteht “Dark Debt”, also Schwächen im Zusammenspiel von Applikationen und Infrastruktur (aka “Anwendungsplattform”), die so lange unentdeckt bleiben, bis ein Szenario eintritt, in dem die Dark Debt zu fatalen Problemen der Plattform führt.
Netflix hat daher vor einiger Zeit die Methode “Chaos Engineering” etabliert, bei der die Anwendungsplattform ganzheitlich betrachtet und getestet wird. Chaos Engineering soll nicht die vorherigen Tests von Software Artefakten und Infrastruktur ersetzen! Es ergänzt diese um eine Absicherung der Resilienz der Gesamtplattform unter Realbedingungen.
Ergänzende Chaos Tests, die in Produktion die Resilienz der gesamten Plattform regelmäßig testen.
Welche Prinzipien gelten für die Umsetzung?
Auch wenn der Name es anders vermuten lässt, ist die Herangehensweise alles andere als chaotisch. Es gelten verschiedene Prinzipien und klare Regeln für Chaos Engineering Tests:
- Bilde zunächst eine Hypothese, die Du mit einem Chaos Engineering Test beweisen bzw. widerlegen möchtest. Kein zielloses Herumgeteste!
- Messe vor jedem Test den “steady state”, also den Zustand, in dem die Plattform einwandfrei läuft. Nur so bekommst Du nutzbare Ergebnisse Deiner Tests.
- Definiere mit Deinem Team mögliche Szenarien für einen Chaos Test. Sind diese Szenarien möglich, aber unwahrscheinlich, hast Du vermutlichen einen guten Chaos Test gefunden.
- Teste in Produktion (Jaja, hier steigt der Blutdruck, aber mal ehrlich, wer kann sicher behaupten, dass die Test- und Integrationsumgebungen wirklich 100%ig identisch zur Produktion sind?). Und wenn Du nicht in Produktion testest, tun es Deine Anwender! Wichtig dabei ist der nächste Punkt…
- Teste nur einen sehr eingeschränkten Teil Deiner Anwendungsplattform (“Blast radius”) und reduziere damit den Schaden eines möglicherweise erfolgreichen Tests. Chaos Tests sind keine Holzhammermethode, sondern eher das chirurgische Messer, mit dem sehr punktuelle Schwachpunkte ermittelt und analysiert werden sollen.
- Sorge für bestmögliche Sichtbarkeit durch Monitoring oder, besser, mit einem APM-Tool, um Veränderungen im System während des Chaos Experiments bestmöglich beobachten zu können. Dies verhindert, dass Dein Test unbeabsichtigt den Blast radius verlässt und erleichtert die Analyse auftauchender Fehler deutlich.
- Automatisiere Deine Chaos Tests wann immer möglich! Dies dient der einfachen und schnellen Wiederholbarkeit und der bestmöglichen Reproduzierbarkeit von gefundenen Fehlern.
Der Learning Loop von Russ Miles.
Gameday
Natürlich darf ein bisschen Gamification auch bei Chaos Engineering nicht fehlen. Die Durchführung von Chaos Tests kann im Rahmen eines Game Days stattfinden. Das ist kein Muss, ich finde den Gamification-Faktor aber besonders effektiv, bei den von mir durchgeführten Game Days war der entstehende Wettbewerb für die Teams motivierend und für das Testergebnis hilfreich. Es gibt verschiedene Varianten einen Game Day durchzuführen.
Ich habe mit der folgenden Möglichkeit besonders gute Erfahrungen gemacht, Ihr müsst mit Euren Teams aber selber den besten Ansatz finden.
Durchführung:
Ein Game Day dauert – je nach Komplexität der Plattform – einen halben oder einen ganzen Tag.
Das Team besteht idealerweise aus einem Mix aus Entwicklern, QA Engineers und OPs, die an Entwicklung und Betrieb der Plattform beteiligt sind. Das Team teilt sich zu Beginn des Game Days in zwei Gruppen auf:
Gruppe 1: Die Schurken („Villains“) haben die Aufgabe Chaos im System anzurichten bei freier Wahl der Mittel (natürlich innerhalb des im Vorfeld definierten Blast radius).
Gruppe 2: Die Einsatzkräfte („first responders“) haben die Aufgabe das Chaos der Villains möglichst abzuwenden und entstandenen Schaden zu analysieren.
Zu Beginn des Gema Days werden Vereinbarungen bzgl. Blast radius und sinnvoller Anwendungsszenarien getroffen. Dann teilen sich die Gruppen auf, z.B. in verschiedene Meetingräume (bzw. virtuelle Meetingräume in Zoom, Teams etc.).
Zu Ende jedes Game Days werden gemeinsam – Villains und First responder – die Findings analysiert und dokumentiert. Daher dauert die „Angriffsphase“ meistens 2-4 Stunden, um genügend Zeit für Vor- und Nachbereitung zu haben. Die abschliessende Analyse und Dokumentation ist wichtig, um die Plattform im Nachgang kontinuierlich zu verbessern.
Es werden zwei Game Days hintereinander veranstaltet, einmal im Quartal hat sich bei meinen Projekten als guter Rhythmus herausgestellt. Zusätzlich zu Chaos Tests werden natürlich Resilienztests automatisiert und kontinuierlich auf der Plattform durchgeführt.
Welche Tools helfen bei der Umsetzung?
Mittlerweile gibt es eine Vielzahl von Werkzeugen für die Umsetzung von Chaos Engineering. Ich stelle nachfolgend nur eine kleine Auswahl der gängigsten Tools vor, die ich aus der Praxis empfehlen kann. Natürlich gilt auch hier, dass Ihr das passende Werkzeug (oder den passenden Werkzeugkasten) für die Aufgabe und Eure Anwendungsarchitektur finden müsst.
Gremlin wurde in den letzten Jahren stark weiterentwickelt und hat sich quasi zum Platzhirsch der kommerziellen Chaos Engineering Werkzeuge gemausert. Es bietet eine Vielzahl verschiedener Chaos Experimente und kann sowohl über eine Webanwendung, als auch per Automatisierung (z.B. in einer Jenkins Pipeline) ausgeführt werden. Zudem bietet es eine gut funktionierende Autodiscovery an, mit der Service Endpunkte selbständig erkannt werden
Der Klassiker von Netflix. Leider recht limitiert in den Möglichkeiten, die sich darauf beschränken virtuelle Instanzen in Verbindung mit Spinnaker herunterzufahren und so Instabilität hervorzurufen. Chaos Monkey ist bestandteil der Toolsammlung “Simian Army”, mit der verschiedene Angriffsszenarien durchgeführt werden können. Nachteile: Simian Army ist kein homogenes Werkzeug, sondern eine bunte Sammlung von Tools, die man selbst konfigurieren muss. Außerdem habe ich den Eindruck, dass die Tools teilweise nicht mehr sonderlich gepflegt werden.
Werkzeug mit dem sich verschiedene Chaos Methoden durchführen lassen. Die Experimente werden in JSOn Dateien konfiguriert, damit ist Chaos Toolkit ziemlich flexibel. Außerdem lässt es sich perfekt in eine CI-/CD-Pipeline (z.B. Jenkins) zu Automatisierungszwecken einbinden.
Weitere:
Natürlich kann man auch mit Tools wie ToxiProxy oder auch Charles Proxy eingeschränkt Chaos herstellen, indem man beispielsweise die Kommunikation zwischen Endpunkten drosselt und beobachtet, wie sich die einzelnen Anwendungsteile dann verhalten.
Fazit
Mit Chaos Engineering kann man einfach und mit weitgehend vorhandenen Mitteln die Resilienz einer Anwendungsplattform spürbar erhöhen. Es ist eine gute Ergänzung zu kontinuierlichen Tests und Continuous Integration Ansätzen. Zudem verbessern Game Days die Verteilung von Know How im Team, indem man die Schwächen der Plattform gemeinsam findet und behebt.
Und nicht zuletzt: Chaos Engineering macht Spaß und fördert neben der Plattformstabilität auch den Teamgeist! 🙂
Stephan Rossbach
Verwandte Artikel
Book Review: Scrum Mastery
Scrum Mastery: From Good to Great Servant Leadership – Ein Game-Changer für alle, die Scrum ernst nehmen und den Unterschied zwischen good und great Servant Leadership kennen wollen.
Book Review: Agile Meetings and Workshops
„Agile Meetings und Workshops“ von Claudia Thonet ist ein Arbeitsbuch, das sich leider völlig in gestalterischen Details verliert und dafür zu wenig auf die theoretischen Grundlagen eingeht.
5 Jahre AGILE ANTS !
Wie schnell die Zeit vergeht: 5 Jahre AGILE ANTS!
Dieses Jahr sind wir 5 Jahre alt geworden und haben das auch gebührend gefeiert.
Lest unsere Story im neuesten Blogbeitrag!