Über unsMediaKontaktImpressum
Maik Figura 22. September 2020

Chaos-Engineering-Kochkurs

In der IT ist es ein bisschen wie beim Kochen: Gute Zutaten allein machen noch kein Sterne-Gericht. Es kommt auch auf die Kochkunst an. Um kontinuierlich tolle Gerichte zaubern zu können, müssen wir das Chaos in der Küche beherrschen und Fehler machen, um daraus zu lernen. In diesem Artikel beschäftigen wir uns damit, was resiliente Systeme sind und wie Chaos Engineering dafür sorgt, dass wir strukturiert und mit minimalem Risiko aus Fehlern lernen können, um unsere Kunden zufriedener zu machen. Wir bereiten einen Gameday vor und beschäftigen uns mit der Ritualisierung und Automatisierung von Chaos Engineering im Projektalltag. So können wir im Ernstfall richtig und besonnen reagieren. Im besten Fall vermeiden wir so größere Desaster am alles entscheidenden Gala-Dinner bei dem unsere Gäste unsere Software genießen.

Was ist Chaos Engineering nicht?

Das Wichtigste vorweg: Es geht nicht darum, ohne Sinn und Verstand Chaos zu stiften. Es geht darum, gut durchdachte Experimente zu gestalten, die Schwachstellen in unseren Organisations- und IT-Systemen ans Tageslicht zu bringen, damit sie uns und unseren Kunden nicht in der Produktion zum Verhängnis werden.

Chaos Engineering kann man zusammenfassen als "Thoughtful, planned experiments that reveal the weakness in our sociotechnical systems before they appear in production". Chaos Engineering ist also eine experimentbasierte, ganzheitliche Herangehensweise, um Schwachstellen in unseren Systemen zu finden. Dazu stellen wir Hypothesen auf, die wir im Laufe eines Experiments validieren, und dokumentieren die Ergebnisse des Versuchs. Chaos Engineering ist nicht Testing. Beim Testen wissen wir genau, was wir testen wollen, was die gewünschten Ergebnisse sind und wie wir diese messen können. Beim Chaos Engineering injizieren wir Fehler in unser System und betrachten das System aus Kundensicht. Wir verifizieren nicht, sondern validieren gewünschte Verhaltensweisen. Am ehesten ist Chaos Engineering mit dem Black-Box-Testing vergleichbar, wobei Chaos Engineering aber über testbasierte Herangehensweisen hinausgeht.

Ob ein Experiment im Rahmen eines Disasterpiece Theater [1], einem Wheel of Missfortune [2] oder einem Gameday [3] durchgeführt wird, ist egal. Wichtig ist nur, dass die experimentbasierte Herangehensweise erhalten bleibt.

Jedes Chaos-Engineering-Experiment hat immer den gleichen Aufbau. Für einen Gameday unterteilen wir ein Experiment in Vorbereitungs-, Durchführungs- und Nachbereitungsphase. Bevor wir aber einen Gameday exemplarisch vorbereiten, wollen wir zuerst der Frage nachgehen, warum wir Chaos Engineering brauchen und welchen Mehrwert es stiftet. Ein bisschen graue Theorie wird uns helfen zu verstehen, warum wir meist keine andere Wahl haben, als zu experimentieren.

Die graue Theorie

Chaos Engineering spielt seine Stärken vor allem in komplexen Systemen aus. Aber was sind komplexe Systeme und warum ist Chaos Engineering eine besonders geeignete Herangehensweise an Probleme und Herausforderungen in solchen Systemen?

In komplexen Systemen entsteht aus einzelnen aber miteinander agierenden Teilen ein Gesamtsystem. Doch obwohl wir alle Einzelteile (oder Zutaten) des Systems kennen, ist es für uns schwer oder sogar unmöglich zu verstehen, wie das System im Gesamten arbeitet oder wie es sich in bestimmten Situationen verhält. Hinzu kommt, dass IT-Systeme von Benutzern anders als erwartet verwendet werden und dadurch unerwartete Verhaltensweisen, Bugs und Systemausfälle auftreten. Es bleiben uns also nur zwei Möglichkeiten: Entweder reduzieren wir Komplexität oder wir lernen damit umzugehen.
"No Silver Bullet" beschreibt, dass es gewollte und ungewollte Komplexität gibt [4]. Gewollte Komplexität brauchen wir für die Umsetzung unseres Geschäftsprozesses und dessen nicht-funktionalen Anforderungen. Ungewollte Komplexität entsteht durch Unwissenheit und den Mangel an Informationen [5]. Diese Komplexität können wir in der Regel verringern. Lässt sich aber die Komplexität nicht weiter verringern, dann braucht es laut dem Cynefin-Framework eine auf "probe - sense - respond" basierende Vorgehensweise [6]. Nur so lassen sich Lösungen für Probleme in solchen Systemen finden.

Aber nicht nur IT-Systeme werden immer komplexer, sondern auch die Organisationssysteme, welche IT-Systeme kontrollieren und steuern. Beim Chaos Engineering betrachten wir sowohl technische Systeme als auch Organisationssysteme, weil sich beide Systeme gegenseitig beeinflussen. Ein Softwareproblem kann also seine Ursachen im Organisationssystem haben und umgekehrt. Aus dem "Law of Requisite Variety" [7] folgt, dass ein Kontrollsystem mindestens genauso komplex sein muss, wie das System, welches kontrolliert und gesteuert wird. Betrachten wir dies im Lichte von Microservices, dann ist es nicht verwunderlich, dass dort eine Umkehr der Kontrolle (Inversion of Control) sinnvoll ist. Autarke Teams und ihre zugehörigen Microservices steuern sich selbst. Damit dies gelingt, braucht es eine hohe Vertrauenskultur und resiliente Organisations- und IT-Systeme. Resilienz beschreibt dabei die Robustheit, Anpassbarkeit und Veränderbarkeit eines Systems [8]. Zusammengefasst kann ein solches System auftretende Fehler aushalten und kompensieren (sich ggf. sogar selbst heilen) und im Nachgang können Voraussetzungen und Ziele verändert werden, welche den zukünftigen Anforderungen besser gerecht werden.

Chaos Engineering schafft solche resilienten Systeme, indem es

  • unbekannte technische Schulden findet (sogenannte "dunkle technische Schulden"),
  • mögliche Fehlerquellen sichtbar macht,
  • das Lernen auf Basis von Experimenten fördert und
  • das Vertrauen und die (psychologische) Sicherheit unter den Teams und Stakeholdern stärkt.

Wenn wir die Resilienz unserer Systeme erhöhen, dann steigern wir damit auch den Umsetzungsgrad unserer nicht-funktionalen Anforderungen (Auch nicht-funktionale Anforderungen haben einen Business Value. Oder wäre es für unsere Kunden okay, wenn die Software zu 50 Prozent der Zeit nicht erreichbar ist und ab und an ein paar Daten verliert?). Ist die Erreichbarkeit der Software ein wichtiges Kriterium, dann führen wir Experimente durch, die die Erreichbarkeit unserer Software unter die Lupe nehmen. Service-Ausfälle, ungewollte Latenzen oder das Rollieren von Passwörtern können solche Experimente sein.

Mit den aus unseren Experimenten gewonnenen Erkenntnissen können wir dann Maßnahmen ableiten, welche die Erreichbarkeit erhöhen. So verwandeln wir dunkle technischen Schulden in weiße – also bekannte – technische Schulden bzw. Bugs. Wenn die Findings behoben oder mitigiert wurden, sollte das Experiment nochmals ausgeführt werden. Ist das Experiment wichtig, dann bietet sich eine Überführung in einen automatisierten Test an. Wichtige Experimente zahlen, in besonderem Maße, auf unsere nicht funktionalen Anforderungen ein. Hier sollten wir es aber wie bei End-To-End-Tests halten: weniger ist mehr. Eine Hand voll Chaos-Tests reicht oft schon, um die wichtigsten Funktionalitäten im Fehlerfall zu sichern.

Wir wissen nun warum Chaos Engineering eine geeignete Herangehensweise für komplexe Probleme ist und dass wir Komplexität zwar verringern, aber nicht gänzlich "loswerden" können. Um jetzt einen Gameday durchführen zu können, muss unser System aber noch folgende Voraussetzungen erfüllen, ohne die Chaos Engineering nicht funktioniert (Chaos Engineering kann auch dafür verwendet werden, um herauszufinden, ob man die Voraussetzungen bereits erfüllt...).

Observability

Damit wir unsere Hypothesen überhaupt validieren können, brauchen wir Sichtbarkeit in das System. Nur so können wir Abläufe nachvollziehen. Bei verteilten Systemen reicht ein klassisches Monitoring mit Zugang zu Logs meist nicht. Wir brauchen zusätzlich die Möglichkeit, Logs und Monitoringdaten aus verschiedenen Diensten einfach zu korrelieren [9]. Application-Performance-Monitoring-Plattformen bieten hier oft einen großen Mehrwert, weil sie neue Dienste automatisch einbinden (Auto-Discovery) und instrumentieren können [10]. So lassen sich auch über Prozessketten und Systemgrenzen hinweg Logs, Payloads und Exceptions korrelieren. Zusammengefasst lässt sich aber sagen: Keine Observability – keine Experimente. Es ist zu gefährlich, im Blindflug in ein System Fehler zu injizieren, weil wir riskieren, einen unkontrollierbaren Ausfall des Systems zu verursachen. Das nützt weder uns noch unseren Kunden.

Last

Am Anfang ist es einfacher, mit Chaos Engineering im kleinen Rahmen und in Testumgebungen zu starten. Dort gibt es aber oft das Problem, dass keine produktionsähnliche Last vorhanden ist. Damit wir bei unseren Experimenten "etwas sehen", brauchen wir Grundlast im System. Diese müssen wir auf Vorumgebungen selbst schaffen oder umleiten. Am besten ist, eine produktionsgleiche Last zu haben. Hier bietet sich (anonymisiertes) Traffic-Mirroring an (auch Shadowing-Traffic). Produktionslast wird dabei in eine Vorumgebung dupliziert und dort verarbeitet. Die Antwort der Vorumgebung wird aber ignoriert und dem Benutzer wird aus dem Produktivsystem geantwortet. So ist sichergestellt, dass die Last im Test der Last in Produktion entspricht. Ist dies nicht möglich, dann bietet sich ein produktionsnaher Lastgenerator an, welcher die Grundlast erzeugt.

In Organisationssystemen haben wir oft nicht die Möglichkeit, in Vorumgebungen zu experimentieren. Dort ist es daher besonders wichtig, dass wir im kleinen Rahmen und mit weniger kritischen Prozessen und Teilsystemen experimentieren.

Umgebung

Wenn wir mit Chaos Engineering starten, dann wollen wir risikoarm starten, und testen deshalb in der Regel erst mal in Testumgebungen. Fast immer unterscheiden sich aber Vorumgebungen von Produktionsumgebungen. Um aber die Produktionsumgebung selbst zu verbessern, sollten wir langfristig auch dort die Experimente durchführen. Eine risikominimierende Vorgehensweise ist es, neue Experimente in einer Vorumgebung durchzuführen. Wenn ein Experiment dort keine neuen Findings mehr liefert, werden die Ergebnisse auf die Produktion angewendet und anschließend wird das Experiment in der Produktion durchgeführt.

Zugangsrechte

Damit wir Chaos Engineering betreiben können, brauchen wir die entsprechenden Rechte und Zugänge auf das zu testende System. Wenn wir diese nicht selbst bekommen, dann sollte uns eine Person aus dem Operationsbereich zur Seite stehen. Operations hat in der Regel ein hohes Eigeninteresse an der Unterstützung von solchen Experimenten, da diese langfristig das System stabiler machen und damit Operations entlasten.

Die gleiche Logik lässt sich auf Organisationssysteme anwenden. Gibt es auf der Arbeitsebene Probleme, so wird meist "nach oben" eskaliert. Je resilienter unsere Organisationssysteme aber sind, desto weniger müssen wir an Dritte eskalieren und lösen so unsere Probleme selbst.

Gameday

Erfüllen wir diese vier Voraussetzungen, dann steht einem ersten Gameday in der Regel nichts mehr im Weg. Im nächsten Abschnitt bereiten wir exemplarisch einen technischen Gameday vor, führen ihn durch und bearbeiten die Findings.

Demoprojekt

Unser Demoprojekt ist ein Fork von Quarkus [11] und besteht aus fünf Diensten [12]:

  • Hero-Service – stellt Held*innen zur Verfügung,
  • Villain-Service – stellt Bösewichte zur Verfügung,
  • Fight-Service – lässt Bösewichte und Held*innen gegeneinander kämpfen und ermittelt Gewinner*innen,
  • Fight-UI – stellt eine Angular basierte UI zur Verfügung um Kämpfe austragen und speichern zu können und
  • Prometheus für das Monitoring.

Unter ./load-super-heros befindet sich ein Lastgenerator. Er erzeugt an den drei REST-Diensten Last. Für den Gameday brauchen wir diesen Dienst aber nicht zwingend. Die drei Backend-Dienste stellen jeweils eine REST-Schnittstelle zur Verfügung (s. Abb.1). Eine Anleitung um das Projekt aufzusetzen und zu starten findet sich in der README im Repository [13].

Vorbereitungsphase

Die Vorbereitungsphase dient dazu, nötige Absprachen zu treffen und der Vorbereitung des Experiments, sowie des Gamedays selbst. Wir bestimmen die Art der Attacke und das Angriffsziel. Werden viele Experimente in einer Organisation gemacht, so lassen sich diese anhand der beiden Punkte kategorisieren. So können wir später einfach nach Experimenten eines bestimmten Typs oder Ziels suchen.  

Danach folgt die Formulierung der Hypothese, welche unsere Vermutungen zusammenfasst. Durch den Blast-Radius beschreiben wir die Auswirkungen und die Größe des Experiments. Der Blast-Radius beschreibt alle von unserer Attacke betroffenen Systeme. Am Anfang unserer Chaos-Engineering-Karriere ist es sinnvoll, mit kleinen Experimenten (das heißt: kleiner Blast-Radius) zu starten, damit wir langsam Vertrauen in das System gewinnen können. Der Attack-Plan ist eine ausführliche Anleitung, wie die Attacke durchgeführt wird. Oft helfen hier auch Repository-Commit-Ids, des aktuellen Deployments und in welcher Umgebung das Experiment ausgeführt wird. Wichtig ist, den Attack-Plan wirklich ausführlich zu beschreiben, damit die Attacke zu einem späteren Zeitpunkt noch einmal durchgeführt werden kann.

Läuft es beim Experiment nicht gut, dann brauchen wir einen Rollback-Plan. Auch dieser sollte vorher getestet werden.

Zum Schluss beschreiben wir die Baseline des Systems. Also was "normales Verhalten" ist. Der sogenannte Steady-State ist meist eine Metrik aus der Sicht der Kunden. Bei Netflix ist sie beispielsweise: "Wie viele Menschen klicken pro Sekunde auf den Play-Button". Im Rahmen von Graceful-Degradation darf während eines Chaos-Experiments die Menge der angeklickten Filme nur in einem gewissen Rahmen sinken. In unserem Fall ist der Steady-State etwas technischer. Wir werden während des Experiments das Frontend neu laden, um zu sehen, ob weiterhin Helden und Bösewichte geladen werden. Dies kann auch automatisiert werden, indem wir alle 5 Sekunden das Browser-Tab neu laden. Die UI soll durch den Ausfall nicht geblockt sein. Das heißt, dass weiterhin Bösewichte geladen werden können. Die Anzahl, des REST-Endpunkts getRandomVillain soll weiterhin steigen. Tabelle 1 zeigt eine mögliche Dokumentationsform als Tabelle.

Tabelle 1: Vorbereitung  
Art der Attacke – Welche Art von Angriff wird durchgeführt? Latenz-Attacke
Angriffsziel – Welcher Service wird angegriffen? Hero-Service
Hypothese – Was passiert und was vermuten wir? Wenn der Hero-Service ausfällt, dann:
  • sehen Benutzende keine Fehler in der UI (http://localhost:3000),
  • es wird nach einer kurz Zeit (z. B. Timeout 250 ms) ein Ersatz-Held angezeigt
  • zufällige Bösewichte können weiterhin geladen werden.
Blast Radius Frontend, Fight-Service
Attack-Plan – Welche Befehle und Skripte werden gebraucht. So genau wie möglich, damit das Experiment später wiederholt werden kann.
  • Alle Dienste (Prometheus, Frontend & Backend) sind nach Anleitung in README gestartet: docker-compose up --build --force-recreate --remove-orphans und haben sich 2 Minuten eingependelt
  • als Umgebung wird dev verwendet
  • hero container killen: docker kill quarkus-hero
  • Rollback-Plan – Was muss für einen Rollback getan werden, sofern das Experiment fehlschlägt? Hero Container wieder starten (docker-compose up --build --force-recreate --remove-orphans hero oder docker-compose mit CTRL+C beenden und neu starten (docker-compose up --build --force-recreate --remove-orphans)
    Steady State – Was ist normal? Wie verhält sich das System und in welchem Rahmen dürfen wir uns bewegen, wenn das Experiment läuft Frontend lädt Bösewichte, Kampfliste und Helden weiterhin. Anstelle der Helden wird ein Fallback oder kein Held angezeigt. Es kann gekämpft werden
  • Anzahl an geladenen Bösewichten steigt stetig weiter (countGetRandomVillain_total) – http://localhost:9090/graph
  • Als nächstes steht die Einladung zum Gameday an. Je mehr Personen eines Teams dazukommen, desto besser. Eine mögliche Agenda könnte sein: Kurze Willkommensrunde, Architekturreview, Experiment 1, Experiment 2, Zusammenfassung und Feedback.

    Durchführungsphase

    Der große Tag ist gekommen, es ist Gameday-Zeit. Zur späteren Korrelierung von Logs, Traces und anderen Monitoringdaten ist es wichtig, die genaue Start- und Endzeit zu dokumentieren.

    Bevor das Experiment gestartet wird, prüfen wir im Team noch einmal den Steady-State und machen einen letzten Check: "Sind alle bereit, gibt es noch Fragen oder Gründe das Experiment nicht durchzuführen?" Wenn alles passt, dann geht es los und Tabelle 2 kann ausgefüllt werden. Um den Steady-State kontinuierlich zu beobachten, öffnen wir http://localhost:9090/graph und visualisieren die countGetRandomVillain_total-Metrik und stellen den Sichtbereich im Graph-Tab auf 15 Minuten. Der Einfachheit halber aktualisieren wir das Frontend alle 5 Sekunden (anstatt den Lastgenerator zu starten). Damit wir einige Daten haben, warten wir für 5 Minuten bevor wir mit dem Beenden des quarkus-hero-Containers fortfahren. Wir checken ein letztes Mal den Steady State (before) und beenden dann den quarkus-hero-Container mit docker kill quarkus-hero.

    Tabelle 2: Durchführung  
    Start- und Stoppzeit – Wann startet das Experiment und wann endet es? Am besten mit genauen Sekunden um Logs korrelieren zu können bei verteilten Systemen. Start 10:10:43 UTC; Ende 10:20:40 UTC
    Steady State before – Läuft das System im Rahmen unseres definierten Steady States? OK (https://github.com/maiksensi/quarkus-workshops/blob/main/images/ui_normal.png)
    Steady State during/after – Hält unser System den Steady State oder nicht? NOK – Abbruch und Rollback (https://github.com/maiksensi/quarkus-workshops/blob/main/images/countGetRandomVillain_total_failure.png)
    • getRandomVillain steigt nicht weiter an
    • Es wird kein Fallback geladen (https://github.com/maiksensi/quarkus-workshops/blob/main/images/timeGetRandomHero_rate_per_second_failure.png und https://github.com/maiksensi/quarkus-workshops/blob/main/images/ui_error.png)

    Nun beobachten wir weiter im Prometheus den Counter. Läuft alles nach Plan? Super, dann gibt es wahrscheinlich keine Findings. Wurde aber der Steady-State gerissen, dann kann das Experiment abgebrochen werden. Nach einer Dokumentation der Findings erfolgt dann die Wiederherstellung des Ursprungszustands. Die Dokumentation der Findings soll so genau wie möglich sein (s. Tabelle 3). Oft liegen zwischen der Dokumentation und der Mitigierung von Findings mehrere Wochen. Eine gute Dokumentation ist also essentiell.

    In unserem Demoprojekt konnten wir sehen, dass die UI blockt und dass kein Fallback (nach einem kurzen Timeout) geladen wird für Helden [14]. Auch der getRandomVillain-Counter stagniert, weil kein Held geladen werden kann [15].

    Zuerst  starten wir den quarkus-hero-Service wieder mit docker-compose up --build --force-recreate --remove-orphans hero, um den Ursprungszustand wiederherzustellen (Die getRandomVillain-counter-Metrik sollte sich nun nach kurzer Zeit wieder kontinuierlich erhöhen und das Frontend sollte "echte Helden" anzeigen). Bei einem echten Experiment kopieren wir auch Screenshots und Logs in die Tabelle 3. Damit vermeiden wir Kontextwechsel. Außerdem werden diese Daten oft innerhalb von einigen Tagen auf wenige Messpunkte reduziert oder sogar ganz gelöscht. Jedes Finding sollten wir feiern, denn wir haben Probleme gefunden, die uns meist am Wochenende um die Ohren fliegen würden (der Teufel ist bekanntlich ein Eichhörnchen).

    Tabelle 3: Nachbereitung  
    Finding – Wenn Steady State nicht eingehalten wurde, dann werden hier Findings dokumentiert. Kann einfach abgeglichen werden mit den Punkten der Hypothese
    • Es wird kein Ersatz-Held angezeigt
    • Die UI blockt (bis zum nächsten Refresh), weil kein Held abgerufen werden kann so wird auch kein Bösewicht geladen
    Handlungspunkte – Welche möglichen Handlungspunkte sehen wir und wer kümmert sich darum?
    • Fallback implementieren welcher greift, wenn einer der nachgelagerten Dienste nicht verfügbar ist

    Mitigierung

    Die Mitigierung von Findings gehört eigentlich nicht zum Chaos Engineering. Das liegt vor allem daran, dass Findings oft noch einmal in Ruhe analysiert werden müssen und dies an einem Gameday oft zu weit führen würde. In unserem Fall ist eine direkte Analyse aber möglich: der Service quarkus-fight wartet, bis eine Antwort von quarkus-hero kommt. Leider kommt diese Antwort aber nie.

    Mitigieren lässt sich das unendliche Warten mit der Implementierung eines Fallbacks [16]. Dazu bietet Quarkus mit Smallrye Fault Tolerance[17] ein geeignetes Mittel. Zuerst fügen wir den gewünschten Fallback in der Methode findRandomHero() in der Klasse io.quarkus.workshop.superheroes.fight.FightService.java hinzu:

    import org.eclipse.microprofile.faulttolerance.Fallback;
    
    @Fallback(fallbackMethod = "fallbackRandomHero")
    Hero findRandomHero() {
       return heroService.findRandomHero();
    }

    Damit die gewünschte Fallback-Methode auch greifen kann, implementieren wir sie in der gleichen Klasse:

    public Hero fallbackRandomHero() {
           LOGGER.warn("Falling back on Hero");
           Hero hero = new Hero();
           hero.name = "Fallback hero";
           hero.picture = "https://dummyimage.com/280x380/1e8fff/ffffff&text=Fallback+Hero";
           hero.powers = "Fallback hero powers";
           hero.level = 1;
           return hero;
       }

    Im Fall der Fälle erzeugen wir also einen "Dummy-Hero" und geben diesen zurück. Wichtig ist, dass beide Methoden einen Hero zurückliefern.

    Wiederholungs-Experiment

    Zuerst beenden wir alle gestarteten Dienste. Danach bauen bauen wir alle Dienste mithilfe von ./build_all_services.sh neu und führen das Experiment noch einmal aus. Diesmal sollte uns ein Fallback im Frontend angezeigt werden und ein "echter" Bösewicht [18]. Auch die getRandomVillain_count-Metrik in Prometheus sollte keinen Einbruch zeigen [19].

    Nun wissen wir auch genau, welche Fehler wir injizieren, was wir erwarten und wie wir messen. Dieses Experiment lässt sich damit auch einfach in einen Regressionstest umwandeln.

    Am Ende des Gamedays holen wir am besten noch weitere Stakeholder dazu und fassen kurz zusammen, was wir getan haben. So sind alle wichtigen Personen abgeholt.

    Die nächsten Schritte hängen immer davon ab, wieviel Chaos Engineering man wirklich braucht, wie die Akzeptanz gegenüber Chaos Engineering bei den Entwickelnden und der Organisation selbst ist. In jedem Fall bietet es sich an, kontinuierlich Gamedays zu veranstalten (z. B. einmal pro Sprint). Meiner Erfahrung nach geht es am Anfang vor allem darum, das vorhandene Tooling besser zu verstehen und die Observability zu erhöhen. Ab einem gewissen Punkt will man dann aber auch mehr Automatisierung, um einfacher Experimente durchführen zu können. Dann lohnt es sich, in Tooling zu investieren. Das kann bedeuten, dass man in kommerzielle Chaos-Engineering-Plattformen wie Gremlin oder steadybit investiert oder auch weitere Open-Source-Tools adaptiert [20].

    Und jetzt? Ist Chaos Engineering die Lösung für alles?

    Ich glaube nicht. Allein schon deswegen, weil Chaos Engineering nicht die Lösung von Problemen in den Vordergrund stellt (das macht Resilience-Engineering!), sondern das Finden und Erkennen von Problemen. Aber Chaos Engineering hilft uns allen, mit der immer komplexer werdenden IT-Welt klarzukommen, damit wir für den Ernstfall vorbereitet sind oder dieser erst gar nicht eintritt. In jedem Fall hilft ein Gameday auch Menschen zusammenzubringen, damit sie voneinander lernen und allein das ist oft schon ein Mehrwert, der Gamedays rechtfertigt. 

    Ihr seid dran

    Wir haben gemeinsam ein Experiment gestaltet und durchgeführt. Aber die Demo-Dienste geben noch einiges her. Was ist zum Beispiel, wenn ein Dienst eine sehr hohe Latenz hat (probiert mal pumba! [21])? Wie ist die Observability, wenn wir den Lastgenerator verwenden? Was ist, wenn der Fallback nicht geladen werden kann? Oder wenn er fehlerhafte Daten liefert? Oder wie wäre es gleich mit einem eigenen Gameday mit den Kolleg*innen? Alle Zutaten sind jetzt bekannt und liegen bereit. Es ist also an der Zeit, den Herd anzuschalten und den Kochlöffel zu schwingen, denn "Probieren geht über Studieren". Gebt also Chaos Engineering eine Chance.

    Quellen
    1. Disasterpiece Theater
    2. Github: Wheel of Missfortune
    3. Chaos Engineering GameDay
    4. F. P. Brooks, Jr.: No Silver Bullet – Essence and Accidents of Software Engineering
    5. U. Friedrichsen: Simplify!
    6. C. F. Kurtz, D. J. Snowden: The new dynamics ofstrategy
    7. Requisite Variety and Its Implications for the Control of Complex Systems
      In: G. J. Klir, 2012: Facets of Systems Science
    8. B. Restemeyer, J. Woltjer & M. van den Brink; 2015: A strategy-based framework for assessing the flood resilience of cities–A Hamburg case study. Planning Theory & Practice, 16(1), 45–62.
    9. Jaeger Tracing
    10. Dynatrace, Instana,
    11. Quarkus
    12. Github: Quarkus Workshop
    13. Github: Quarkus Super Heros Workshop Demo
    14. Github: Quarkus Workshop
    15. Github: Quarkus Workshop
    16. siehe Branch fallback
    17. Quarkus - Fault Tolerance
    18. Github: Quarkus Workshop
    19. Github: Quarkus Workshop
    20. Gremlin, steadybit und eine ausführliche Liste auf Github: Awesome Chaos Engineering
    21. Pumba

    Autor

    Maik Figura

    Maik ist introvertiert, stottert und liebt es Talks zu halten. Was kann da schon schief gehen? Bei der codecentric AG kümmert sich Maik um Chaos Engineering.
    >> Weiterlesen
    Kommentare (0)

    Neuen Kommentar schreiben