- Chaos Engineering sollte wichtiger Bestandteil moderner DevOps und SRE Praxis sein. Ohne proaktive Schwachstellensuche kommt es zu vielen Ausfällen.
- Tests unterscheiden sich vom Chaos Engineering im Blickwinkel. Während Tests Wissen und Erfahrungen bestätigen und Fehler aufdecken, basiert das Chaos Engineering auf einem experimentellen Ansatz, welcher Hypothesen überprüft.
Es war einmal die IT, welche seit vielen Jahren möglichst robust vor sich her lebte. Generationen von Fachleuten hegen und pflegen die IT gut. Sie gaben einzelnen Bestandteilen, wie einzelnen Servern etwa, eigene Namen und erstellten sogar große Landkarten mit Visualisierungen, damit man immer gut mit der IT zurechtkam. So ging es tagein und tagaus. Eines Tages jedoch kam die Idee vom Cloud Computing in das Leben der IT und veränderte alles. Darum musste die IT sich nun anders verhalten und entsprechend anpassen. Die ruhige, starre und kontrollierte Zeit war damit ein für alle Mal vorbei. Turbulente Tage zogen über die IT und sie wurde gehörig durcheinander gerüttelt. Bis eines Tages einige pfiffige Entwickler auf die Idee kamen, die IT mit neuen Augen zu betrachten und sich fortan anders um die IT zu kümmern.
Haben Sie den Begriff “Chaos Engineering” schon einmal gehört? Kennen Sie die “Simian Army”? Sagt Ihnen der “Chaos Monkey” etwas? Kennen Sie Netflix? Ich vermute Sie konnten eine oder zwei dieser Frage mit einem bestimmten “Ja” beantworten. Konnten Sie alle vier Fragen bereits mit einer guten Zuversicht bestätigen, dann umso besser. Doch bringen wir ein wenig Licht ins Dunkel und versuchen zu verstehen, wie diese Begriffe sogar alle zusammenhängen, was es damit auf sich hat und was unsere liebe IT davon hat.
Netflix und das Chaos
Wie eingangs beschrieben basiert unsere IT der vergangenen Jahrzehnte auf der Vorstellung, dass die mittlere Betriebsdauer bis zum Ausfall (MTTF) möglichst optimiert wird – kurz gesagt: es ging um die Fehlervermeidung. Dieser Ansatz resultierte in aufwändigen Testszenarien, langen Releasezyklen, vielen Systemlandschaften (Entwicklung, Test, Pre-Prod, Prod, etc.) und vielen anderen Bestrebungen mehr, Sie kennen sie vermutlich alle. Doch genau in dieser Betrachtungsweise liegt das Problem. Systemlandschaften kann man nicht mal mehr eben skizzieren und alle Komponenten in 5 oder mehr Schichten einsortieren. Längst haben die Microservices, meistens in Containern, den Einzug in die Welt der Unternehmens IT geschafft. Damit ist die Komplexität drastisch angestiegen, da in Zeiten von programmierbarer Infrastruktur und automatisch skalierenden Systemen kein Mensch mehr Hand anlegen muss – wenn nicht die Stricke reißen. Doch genau da liegt der Kern des Problems. Wie behalte ich solch ein mächtiges Konstrukt aus einzelnen kleinen Komponenten unter Kontrolle? Wie bekomme ich die Robustheit hergestellt? Die Antwort ist trivial: Ich muss es nicht. Robustheit ist die Sichtweise aus der alten Welt der IT. Heutzutage kommt es darauf an, Systeme nicht robust, sondern anpassungsfähig zu machen. Sie kennen Charles Darwin? Keine neue Theorie also, aber für die IT dennoch ein neuer Ansatz. Der Fokus liegt also auf der Fehlertoleranz und die Kosten, welche im Schadensfall entstehen, wenn ein Microservice, ein Container, oder eine VM ausfällt. Aus betriebswirtschaftlicher Sicht betrachtet ist der Schaden sehr gering, da Microservices und Co. in wenigen Millisekunden bis Sekunden wieder neu starten können mit einer frischen Installation ohne Altlasten. Genau diese Tatsache hat man bei Netflix vor Jahren erkannt und sich über das Testen und die Anpassungsfähigkeit derartiger neuer Cloud-basierter Architekturen ausgiebig Gedanken gemacht. Zunächst wurde insbesondere darauf geachtet, soviel realistischen Traffic und so viele realistische Traffic Szenarien wie möglich zu erzeugen, um das Test-System damit zu füttern. Anfangs entwickelte Netflix dazu einen einfachen Repeater, der die echten und vollständigen Kundenanfragen auf das System innerhalb der AWS Infrastruktur kopierte. Damit identifizierte Netflix die möglichen Engpässe seiner Systemarchitektur und optimierte im Zuge dessen die Skalierbarkeit. Daraus entwickelte sich mit der Zeit dann die Simian Army, welches das berühmteste Kind der Chaos Monkey darstellt. Dies ist eine Ansammlung von Systemen, die nicht weniger darauf ausgelegt ist, als das Produktivsystem – ja genau während man einen Film oder eine Serie schaut – zu zerstören. Sehen sie nur, wie intensiv Netflix die Anpassungsfähigkeit der eigenen IT-Landschaft testet, zur Simian Army gehören u.a.:
- Chaos Monkey – zerstört zufällig Instanzen und Services
- Latency Monkey – führt künstliche Verzögerungen im Netflix eigenem REST-Client-Server Communication-Layer herbei, um einen Leistungsabfall zu simulieren
- Conformity Monkey – findet Instanzen, die nicht den Best Practices Anforderungen entsprechen und fährt diese herunter
- Doctor Monkey – überprüft Health Checks und entfernt fehlerbehaftete Instanzen
- Janitor Monkey – räumt überflüssige Instanzen weg (Ressourcenauslastung)
- Security Monkey – findet Sicherheitslücken oder Schwachstellen wie falsch konfigurierte AWS Security Groups und beendet die beanstandeten Instanzen
- 10-18 Monkey – erkennt Konfigurations- und Laufzeit Probleme innerhalb von Instanzen
- Chaos Gorilla – simuliert allerdings einen vollständigen Ausfall einer Amazon Availability Zone
Na konnten Sie wieder etwas Luft holen? Starker Tobak oder? Würden Sie mit Ihrem Produktivsystem so verfahren? Nein? Warum nicht?
Was ist also Chaos Engineering?
Chaos Engineering ist ein Ansatz, um zu lernen, wie sich Systeme verhalten, indem Sie eine Disziplin der empirischen Erforschung anwenden. So wie Wissenschaftler Experimente zur Untersuchung physikalischer und sozialer Phänomene durchführen, nutzt Chaos Engineering Experimente, um ein bestimmtes System kennenzulernen und die Schwachstellen und die Anpassungsfähigkeit zu untersuchen. Der Einsatz von Chaos Engineering verbessert die Fehlertoleranz eines Systems. Durch die Planung und Durchführung von Chaos Engineering Experimenten erfahren Sie mehr über Schwächen in Ihrem System, die möglicherweise zu Ausfällen führen können, die Kunden Schaden zufügen. Sie können diese Schwachstellen dann proaktiv angehen und über die reaktiven Prozesse hinausgehen, die derzeit die meisten Reaktionsmodelle für Vorfälle dominieren. Bleiben wir im biologischen Bereich, dann ist Chaos Engineering wie ein Impfstoff, bei dem man etwas Schädliches injiziert, um eine Immunität aufzubauen. Es geht also nicht darum, Dinge überhaupt zu zerstören, sondern darum, wie man Infrastruktur, Dienste und Systeme zuverlässiger und widerstandsfähiger macht.
Eine mögliche Definition:
“Chaos Engineering ist die Disziplin des Experimentierens an einem verteilten System, um Vertrauen in die Fähigkeit des Systems aufzubauen, turbulenten Bedingungen in der Produktion standzuhalten.”
Q&A Chaos Engineering
Kommen wir nun kurz zu einer fiktiven Frage und Antwort Runde mit unserem bunten Chaos Engineering Zoo auf der Bühne.
Bob: Sollte man Chaos Engineering in die CI/CD-Pipeline integrieren oder lieber zyklisch (Wochen oder Monate) durchzuführen?
Chaos Monkey: Ziel sollte es sein, die Experimente möglichst automatisiert ablaufen zu lassen. Dies ist natürlich, wie bei allen neuen Dingen, eine Herausforderung und geht nicht von heute auf morgen. Beginnen sollte man daher mit den einfachsten Tätigkeiten: Monitoring, Logging und Tracing. Schaffen sie zunächst die Möglichkeit die eigenen Systeme zu überwachen und beobachten. Denn sicherlich unterstützen dies nicht alle ihre Systeme. Danach geht es dann an die Erstellung von Metriken zur Messung von Erfolg oder Misserfolg der Experimente, welche auf ihr System ausgerichtet sind. Erst dann geht es in die Entwicklung und die langsame Integration in automatische Prozesse.
Jane: Es gibt im Site Reliability Engineering (SRE) das Konzept der Spieltage, an denen man u.a. alte Vorfälle von Ausfällen noch einmal nach spielt, um zu prüfen, ob diese Fehler noch auftreten können. Ist dieses Prinzip auch für das Chaos Engineering wichtig?
Doctor Monkey: Ja. Spieltage haben eine hohe Relevanz im SRE Bereich und damit auch für das Chaos Engineering. Doch die Zusammensetzung ist vielleicht noch ein wenig umfangreicher, als bei den SRE Spieltagen. Eingeladen werden sollten beispielsweise auch Manager, technische Projektleiter, Kollegen und Kolleginnen aus den Fachabteilungen – halt all jene, die zum einen ein wirtschaftliches Interesse an der Widerstandsfähigkeit des Systems haben und auch alle, welche die Prozesse und die Software und Architektur kennen.
Jack: Wie unterscheiden sich Penetrationstests oder nur Unit-Tests von diesem Ansatz?
Janitor Monkey: Anders als bei Tests kann man im Falle von Chaos Engineering nicht alle möglichen Fehlerfälle im Vorfeld betrachten. Der Blickwinkel ist ein anderer. Man muss das Chaos Engineering eher als einen wissenschaftlichen Versuch betrachten, bei dem man eine Hypothese aufstellt und diese untersucht. Die Schritte im Einzelnen sind:
- Wählen Sie eine Hypothese aus
- Wählen Sie den Umfang des Experiments aus
- Identifizieren Sie die Metriken, die Sie sich ansehen werden
- Benachrichtigen Sie das Unternehmen
- Experiment durchführen
- Analysieren Sie die Ergebnisse
- Erweitern Sie den Umfang
- Automatisieren
Man bereitet sich dann mit den Ergebnissen auf Situationen vor, die man eigentlich nicht erwartet hätte oder von denen man nicht weiß, dass diese schiefgehen. Hier ist auch eine entsprechende Aufklärungsarbeit im Unternehmen zu leisten, damit jedem die Relevanz bewusst wird und jeder an der Umsetzung und dem Erfolg mitarbeitet.
Jill: Netflix nutzt Chaos Engineering bei den Produktivsystemen, ist dies immer das Ziel von Chaos Engineering? Oder kann man auch Pre-Prod oder Testsysteme nutzen? Denn gerade in Hinblick auf SLAs und andere Verträge scheint mir der Ansatz zu gewagt.
Latency Monkey: Der Ansatz bei der produktiven Umgebung hat vor allem den Vorteil, dass es einen nachhaltigen Eindruck bei allen im Kopf hinterlässt. Jedem den sie erzählen, dass es im produktiven Betrieb geschieht, merkt es sich. Für die Evangelisierung ist es also perfekt. Davon abgesehen ist es auch sinnvoll diese Experimente in den Pre-Prod-Umgebungen durchzuführen. Damit kann dann das System auf den gewünschten Level der Widerstandsfähigkeit aufgebaut werden, um dann in die Produktion zu gehen. Jedoch sind dann einige Dinge aus dem realen System zu kopieren oder nachzubauen, wie beispielsweise der Traffic. Für die angesprochenen SLAs sollten sie ein Monitoring implementiert und Schwellwerte definiert haben. Das bedeutet, sobald diese zu fallen drohen können sie das Experiment abbrechen und dann die Auswertung durchführen, warum diese Schwellwerte von dem Experiment erreicht worden sind und wo die Ursache liegt. Auf diese Art kommt es gar nicht so weit, dass sie die SLAs reißen und ihre Kunden verstimmen.
Haben Sie noch weitere Fragen als unsere Publikumsteilnehmer? Dann vereinbaren Sie doch einfach einen Workshop mit uns.
Bereit für das Chaos?
In einer immer komplexeren IT-Welt ist es notwendig Systeme proaktiv zu untersuchen, um diese möglichst widerstandsfähig zu gestalten. Chaos Engineering ist dafür ein guter Ansatz. Die folgenden Dinge sollten Sie im Unternehmen etablieren, bevor Sie mit Chaos Engineering starten können und sind auch darüber hinaus sehr wichtig für ihren aktuellen Betrieb:
- Überwachung und Beobachtbarkeit sind wichtig: Wenn Sie keinen Überblick darüber haben, was Ihre Systeme tun, haben Sie kein Chaos Engineering – sondern nur Chaos.
- Incident Management – Warnmeldungen und Schwellwerte müssen kontrolliert und überwacht werden. Falls ein Experiment schief geht, muss ein Team auch in der Lage sein, dieses rückgängig zu machen, um beispielsweise keine SLAs zu reißen.
- Kosten für Ausfallzeiten pro Stunde: Diese sollten Sie kennen. Nur auf diese Weise können Sie sinnvolle Experimente gestalten und entsprechende KPIs aufstellen.
Wir freuen uns von Ihrer Reise in die Welt des Chaos zu hören. Melden Sie sich doch bei uns und erzählen uns, welches Tier bei Ihnen eine Verwüstung angerichtet hat. Happy Chaos!