Seite 4: Die Phasen des Chaos Engineering

Inhaltsverzeichnis

Ziel des Chaos Engineering ist es, das bestehende Chaos und dessen Auswirkungen aktiv zu bekämpfen. Es muss daher zwingend kontrolliert stattfinden und darf nicht zu weiterem Chaos führen. Deshalb ist es wichtig, ein einheitliches und kontrolliertes Vorgehen zu definieren, das allen Beteiligten bekannt sein muss. Hierfür bietet Chaos Engineering ein erprobtes und stabiles Vorgehen.

Im Vorfeld sind entsprechende Metriken zu ermitteln und während der Ausführung zu überwachen. Die Metriken sind so zu wählen, dass mit einem Blick erkennbar ist, ob es Anomalien im System gibt, die einen Abbruch des Experiments erfordern. Die dann stattfinden Post-Mortem-Analyse muss die notwendigen Daten liefern, um den Fehler oder das unerwartete Verhalten zu analysieren und geeignete Gegenmaßnahmen zu implementieren. Das sind die nötigen Erkenntnissse, um die gebauten und betriebenen Systeme stabiler zu gestalten. Experimente, die eine Anomalie festgestellt haben, müssen kontinuierlich durchgeführt werden, vergleichbar mit Regressionstests. Experimente, die eine bisher nicht bekannte Schwachstelle aufgespürt haben, sollen durch die kontinuierliche und automatisierte Ausführung ein Wiederkehren des ungewünschten Verhaltens verhindern. Durch das Einführen eines neuen Features oder ein neues Deployment können Fehler wiederkehren und zu einem erneuten Ausfall führen.

Steady State

Es ist wichtig, Metriken zu definieren und kontinuierlich zu überwachen, die eine sichere Aussage zum Gesamtzustand des Systems geben. Metriken können sowohl technisch als auch fachlich sein.

Nach Meinung des Autors überwiegen die fachlichen Metriken die technischen. Netflix überwacht während eines Chaos-Experiments die Anzahl der erfolgreichen Klicks, um ein Video zu starten. Das ist die Kernmetrik und sie ist fachlicher Art. Können Kunden keine Videos starten, hat das unmittelbare Auswirkungen auf die Kundenzufriedenheit. Betreibt man beispielsweise einen Onlineshop, könnte die Anzahl der erfolgreichen Bestellungen oder die Anzahl der in den Warenkorb gelegten Artikel eine wichtige fachliche Metrik sein.

Aktuell werden in Unternehmen und beim Betrieb der Systeme nur die technischen Metriken wie die CPU-Auslastung, die Auslastung des Arbeitsspeichers und die Verfügbarkeit des Netzwerks betrachtet. Das vermittelt aber nicht, ob das Gesamtsystem korrekt arbeitet. In Zusammenarbeit mit dem Fachbereich findet man Metriken, die mit einem Blick zu erkennen geben, ob das System sich im Normalzustand befindet.

Die Werte sollen dann auch historisch vorliegen und als Grundlage dienen, um Anomalien zu erkennen. Der Betrieb, die Entwickler und der Fachbereich können damit zum Beispiel wissen, wie viele Bestellungen sie pro Minute an einem Montagmorgen um 9:45 Uhr haben. Das versetzt Unternehmen nicht nur in die Lage zu erkennen, ob ein laufendes Chaos-Experiment erfolgreich und ohne Fehler im System durchgeführt wird, es gibt ihnen ebenfalls außerhalb des Chaos Engineering die Gewissheit darüber, wie Kunden ihre Service nutzen. Wenn die gewählten Metriken dann noch mit dem Umsatz verknüpft werden, sind die Beteiligten in der Lage zu ermitteln, wie hoch ein möglicher Umsatzverlust bei einer Minute Downtime ist. Die Erkenntnis vermittelt den Entwicklern und dem Betrieb eine detailliertere Sicht auf das System und führt zu einer anderen Wahrnehmung der möglichen Auswirkungen einer Änderung.

Hypothese über das Experiment

Im Vorfeld sollte man sich Gedanken machen, was bei einem Experiment passieren könnte, und es nutzen, die Behauptung unter Beweis zu stellen. Scheitert man daran, müssen die Erkenntnisse helfen, den Fehler zu lokalisieren und gezielt im Team beziehungsweise im Unternehmen zu adressieren.

Das ist mitunter der schwierigste Teil: Es geht nicht um die Suche nach einem Schuldigen. Als Chaos Engineer will man lernen, wie sich ein System verhält, und die Erkenntnisse an die Entwickler zurückgeben. Deshalb ist es wichtig, alle Beteiligten früh mit an Bord zu holen und sie an den Experimenten teilhaben zu lassen.

Um ein Experiment kontrolliert zu testen, muss man sich die Frage stellen, welche Fehler in einer realen Anwendung einer Applikation eintreten können. Mögliche Beispiele wären:

• Ausfall eines Node im Kafka-Cluster
• Package-Drops im Netzwerk
• Hardwarefehler
• Max-Heap-Size einer JVM
• Latency
• Malformed Responses

Die Liste lässt sich beliebig erweitern und ist immer eng mit der gewählten Architektur verbunden. Auch wenn eine Anwendung nicht bei einem der namhaften Cloud-Provider gehostet ist, kann im Rechenzentrum des Unternehmens einiges schiefgehen.

Der Blast-Radius

Um jederzeit die Kontrolle innerhalb der Ausführung eines Chaos-Experiments zu behalten, müssen Entwickler klare Grenzen setzen: den Blast-Radius. Über ihn kann man steuern, welche Komponenten ein Experiment beeinflusst und welche Services durch die Änderungen unmittelbar betroffen sind. Vor der Ausführung ist allen Beteiligten klar, was und in welchem Ausmaß verändert wird. Sollte nun während des Experiments eine Komponente außerhalb des definierten Radius ein verändertes Verhalten ausweisen, muss das Experiment stoppen und eine Analyse starten. Die daraus resultierenden Funde müssen die Teams und Verantwortlichen erfahren: Es gilt die Fehler zu eliminieren und im Anschluss das Experiment erneut auszuführen.

Wenn das vorgesehene Experiment erfolgreich durchgelaufen ist, wird der Blast-Radius erweitert und es werden weitere Komponenten beeinflusst. So ist es zum Beispiel möglich, mehrere Instanzen eines skalierten Service mit Fehlern oder einer höheren Latenz antworten zu lassen. Ebenso ist es denkbar, nicht nur einen Service zu beeinflussen sondern auch weitere Services der Komponente unter Test zu verändern. Der Blast-Radius kennt rein formal kein definiertes Ende, es ist jedoch zu beachten das es irgendwann eine logische Grenze gibt, bei der der Blast Radius eine Größe erreicht hat, die er in Produktion nicht erreichen kann beziehungsweise auf den das System nicht mehr reagieren kann. Der Ausfall eines kompletten Rechenzentrums wäre hier ein Beispiel.

Wenn die gesamte Applikation in nur einem Rechenzentrum betrieben wird und das Experiment einen Totalausfall simuliert und dennoch erwartet wird, dass das System mit diesem Szenario umgehen soll, ist die Grenze eindeutig überschritten. Setzt man aber auf einen der namhaften Cloud-Provider und sichert die Verfügbarkeit durch eine Verteilung auf mehrere geographische Zonen, so ist es absolut valide, den Ausfall einer Zone zu testen. Dies ist oftmals auch Teil der Disaster Recovery und kann mit Chaos Engineering auch automatisiert getestet werden. Dank der Steuerung über den Blast-Radius und des Steady State kann dies in mehreren und sich steigernden Schritten erfolgen.