© vicnt, 123RF

Bevor es andere tun, können Admins in ihren Produktionssystemen – testweise – einfach selbst Chaos verbreiten. So bemerken sie im Optimalfall schon früh schwer kalkulierbare Stolpersteine.

“Vertrauen ist gut, Kontrolle ist besser.” Jeder kennt dieses Sprichwort und in den meisten Situationen handeln Entwickler auch so. Programmieren sie eine neue Applikation, legen sie Wert auf eine hohe Testabdeckung. Oft beschäftigen Unternehmen unzählige Qualitätssicherer, bevor sie ihr Produkt über die Ziellinie schieben – im Fall einer Webanwendung in die Produktion.

Doch dann – nach dem Releasetermin – scheinen alle Ängste vergessen. Zugleich übersehen und ignorieren die Betreiber der Anwendung häufig eine unsichtbare Gefahr, die in jeder komplexen Umgebung lauert: das Chaos.

Fällt das Wort in operativ tätigen IT-Abteilungen – oder gar auf IT-Management-Ebene – zucken die Verantwortlichen schon mal nervös zusammen. Chaos will niemand, schon gar nicht in der aus komplexen Prozessen komponierten EDV. Daher sichern Dutzende Unittests einzelne Applikationskomponenten ab und liefern Integrationstests Aufschluss über das Zusammenspiel der bekannten Bausteine. Ausgeklügelte Quality Gates und hoch optimierte Releaseprozesse versprechen volle Sicherheit beim anstehenden Gang in die Produktion. Eigentlich sollte nichts mehr schiefgehen – oder?

Chaos regiert

Doch selbst riesige Provider mit viel Erfahrung und starkem technischen Background erleben hier und da Ausfälle, mitunter verursacht durch Naturkatastrophen, oft schlicht Folge von technischem oder menschlichem Versagen. Selbst Netzwerke mit verteilten Komponenten entwickeln gern ein Eigenleben und verhalten sich leider nicht immer deterministisch. Oder anders formuliert: Jede produktiv eingesetzte IT ist anfällig für Chaos.

Verteilte Systeme, Microservices, Container: Was sich für Architekten und IT-Ingenieure heute wie eine bunte Spielwiese anfühlt, entpuppt sich für die operative IT dann als Hölle auf Erden. Im Worst Case kippen die Planer einen Stapel fremder Technologien vor den Betrieblern aus. Denen fällt die ehrenvolle Aufgabe zu, den Haufen zu ordnen. Denn auch in den Zeiten von Devops existiert “die andere Seite des Zauns” noch immer. Nach wie vor betreuen Entwickler ihr Produkt oft nicht in der Produktion, was die Unsicherheit potenziert.

Selbst im positivsten Fall, wenn also Mitarbeiter ihre Software vom Reißbrett bis in die Produktion begleiten, braucht in komplexen Umgebungen jemand einen Überblick über die Infrastruktur. Welche Umsysteme gibt es und wie reagieren diese? Wie sieht es mit der Verfügbarkeit aus? Wie sehr kann sich ein Admin auf die SLAs von Drittanbieter-Systemen verlassen? Stehen und fallen seine Versprechen gegenüber den Kunden beispielsweise mit der Verlässlichkeit dieser Systeme, die er nicht unter Kontrolle hat? Wer kann da noch ruhig schlafen?

Die Welt der Microservices

In aktuellen Architekturen stecken, anders als zu Bare-Metal-Zeiten, deutlich mehr Unwägbarkeiten. Die Applikationen sollen weltweit laufen, Admins müssen die Instanzen maßschneidern und dabei die Kosteneffizienz beachten. Das versteckte Geflüster in den Netzen erhöht die Komplexität weiter: Viele Services bedeutet auch, dass Komponenten viel untereinander kommunizieren.

Zudem fallen solche IT-Landschaften selten homogen aus. Es gibt nicht nur “die eine” Datenbank, sondern mehrere. Dazu kommt eine größere Palette an Diensten, gern auch in exotischen Programmiersprachen. Es gibt Message Queues, Key Value Stores, Caches und Vaults.

Oft genug soll dann ein einziger Admin diesen komplexen Flohzirkus unter Kontrolle halten. Weil die Flöhe aber in vielen Sprachen, über mehrere Dienste und weltweite Rechenzentren hinweg miteinander reden, entstehen unzählige potenzielle Bruchstellen.

Auftritt Chaos Engineering

Trotz dieser Hindernisse schaffen es viele Produkte am Ende doch irgendwie in die Produktion. Die Entwicklung hat gute Arbeit geleistet und sogar Fallbacks in das ein oder andere System integriert. Andere, noch weniger verstandene Systeme, laufen seit dem Produktionsgang stabil.

Die Admins könnten nun theoretisch durchatmen. Insgeheim beschäftigt sie aber die Frage, ob alle Services wie erwartet arbeiten und ob die Fallbacks halten. Ist die Infrastruktur wirklich sicher? Sollte das nicht mal jemand praktisch ausprobieren?

Was wäre wenn?

Solche “Was wäre wenn?”-Szenarien spielt das Chaos Engineering durch. Es orientiert sich an den Installationen moderner Einsatz- und Rettungsteams aus der wirklichen Welt und erlaubt so etwas wie regelmäßige Katastrophenschutzübungen. Die Idee: Was sich für kritische Infrastrukturen der Gesellschaft bewährt, kann der IT nicht schaden.

Chaos Engineering ist kein im Elfenbeinturm geborenes, womöglich esoterisches Konzept. Erst Recht kein mutwillig destruktives, auch wenn der Begriff zunächst ein wenig so klingen mag. Denn der Chaos Engineer möchte das Chaos, das sich ihm in Produktionsumgebungen in den Weg stellt, möglichst im Zaum halten (Abbildung 1).

Abbildung 1: Chaos findet nicht nur auf der technischen Ebene statt.

Das bedeutet zum Beispiel, das gesamte System unter kontrollierten Bedingungen Stresstests zu unterziehen. Eine problematische Alternative wäre es, zu warten, bis die kauflustigen Kunden in der Weihnachtszeit diesen Test außerhalb der eigenen Kontrolle selbst starten. Kontrolle ist in diesem Fall ein Schlüsselwort. Es geht beim Chaos Engineering um kontrollierte Experimente, um dem Chaos gezielt Grenzen zu stecken. Mit den so gewonnenen Erfahrungen lassen sich dann resiliente Applikationen entwickeln.

Echte Werte

Gute Metriken sind dabei kriegsentscheidend. Test- und Messergebnisse sollen die Realität widerspiegeln, um reale Erkenntnisse zu gewinnen und daraus konkrete Handlungsschritte abzuleiten. Daher zieht das Chaos Engineering nur begrenzt Daten von Testsystemen heran. Die Admins wollen schließlich wissen, wie sich ein reales System unter realen Bedingungen verhält. Also nutzen sie das Monitoring des Produktivsystems für die Business-Metriken. Existiert ein solches nicht, setzen sie es auf. Dann ermitteln sie den so genannten Steady State.

Wo liegt das Problem?

Der Begriff Steady State gehört zur Chaos-Engineering-Terminologie und lässt sich in ein paar Sätzen erklären. Angenommen, Admins prüfen ein System insbesondere unter den Gesichtspunkten seiner Belastbarkeit und Ausfallsicherheit. In diesem Fall müssen sie zunächst klären, wie sich Last negativ auf das konkrete System auswirkt.

Wie machen sich die Lastspitzen aus Business-Perspektive bemerkbar? Verkauft das Unternehmen effektiv weniger seiner Produkte? Oder warten die Nutzer einfach etwas länger, bleiben aber dennoch auf der Plattform? Und welche Veränderungen sind zu erwarten, wenn ein Besucheransturm erfolgt?

Dazu müssen sie zunächst wissen, wie lange eine reguläre Bestellung überhaupt unter guten Performance-Bedingungen dauert und wie sich das System regulär verhält. Das erfordert eine Bestandsaufnahme. Doch Statistiken im technischen Sinne helfen am Anfang kaum weiter. Vielmehr geht es um Kriterien, die das Geschäft widerspiegeln und das Nutzerverhalten einbeziehen.

Für einen Onlineshop zählen etwa abgeschlossene Verkäufe pro Minute oder die Anzahl der Beschwerden pro Tag. Diese Business-Metriken im Verhältnis zu definierten Rahmenbedingungen repräsentieren dann den Steady State, das normale Verhalten des Systems.

Dazu zählen aber auch technische Metriken. Dank dieser erkennen Admins frühzeitig Fehler, die sich nicht direkt im Steady State niederschlagen. Womöglich arbeitet das Auto-Scaling einiger Instanzen ungewöhnlich stark. Oder die ersten Requests laufen ständig in Netzwerk-Time-outs und nur die Fallbacks antworten. Dies sollten sie beheben, bevor das Problem zum Nutzer eskaliert. Kurzum: Systemerfahrene Techniker erkennen an kleinen Unregelmäßigkeiten Gefahren und handeln präventiv.

Hypothese

Zeit für ein Beispiel. Mögliche Schwachstellen einer verteilten Anwendung verbergen sich gern hinter Datenbankverbindungen oder genauer gesagt beim Connection-Handling. Meist gibt es dafür einen Fallback, weil der Admin weiß, dass eine Verbindung auch mal instabil sein kann. Um dieses System zu testen, stellt er etwa folgende Hypothese auf: “Der Kommentar-Service übersteht einen Neustart der Datenbank und ist danach in der Lage, weiterhin Anfragen zu beantworten.” Dies überprüft er dann in einem Chaos-Experiment.

Blast Radius

Vorher muss er aber die Sicherheitsnetze aufspannen, denn er möchte kontrollierte Tests anschieben, keine wilden Brandherde entfachen. Daher steckt er einen Sicherheitsbereich ab und sorgt dafür, dass der Test auch nur jene Systeme beeinflusst, die Teil des Versuchs sind und unter seiner Kontrolle stehen. Erst wenn das der Fall ist, kann er den so genannten Blast Radius (Abbildung 2) im Laufe der Experimente Schritt für Schritt erweitern. Im konkreten Beispiel sollte er also sichergehen, dass auch ein Misserfolg des Experiments nur den Kommentarservice betrifft und nicht noch weitere Applikationen mit in den Abgrund reißt.

Chaos-Experiment

Nun ist alles präpariert. Die Business-Metriken, um die Hypothese zu testen, stehen, der Steady State ist ermittelt. Im nächsten Schritt startet der Admin die Datenbank neu, schiebt so den geplanten Eingriff an und beobachtet das System mit Hilfe des Monitoring. Der praktische Teil des Chaos-Experiments besteht also darin, die Hypothese am produktiven System zu untersuchen.

Untersuchen und anpassen

Danach gilt es, diese Ergebnisse auszuwerten, um die Hypothese zu bestätigen oder zu widerlegen. Antwortet der Kommentar-Service erwartungsgemäß, ist das Experiment gelungen. Weiter zur nächsten Baustelle. Verweigert er die Antwort, ist das Experiment gescheitert und ein neues Ticket wandert ins Backlog – meist mit hoher Priorität.

Game Day

Chaos Engineering lässt sich also abstrakt mit dem Bild von produktionsnahen Integrations- und Systemtests beschreiben. Speziell handelt es sich um Tests, die ein System auf die Feuerprobe stellen. Die ersten Tests schiebt der Admin jedoch bereits in der Theorie am Schreibtisch an, beim so genannten Game Day.

Abbildung 2: Der Chaos-Stifter richtet einen erweiterbaren Blast Radius ein, der die Folgen potenzieller Auswirkungen begrenzt.

Dabei stellen er und sein Team Hypothesen auf und diskutieren sie. Welche Katastrophen könnten das System gefährden, welche Ausfälle steckt es locker weg? Würden etwa alle Dienste einen Neustart der Datenbank überleben? Oder Schlimmeres? Falls ja, Chapeau! Falls nicht, gilt es, die Services resilienter zu machen und beim nächsten Mal weitere theoretische Angriffe zu starten.

Sind auf dem Papier keine Schlachten mehr zu gewinnen, lassen sich die Theorien im Praxisexperiment der Produktion testen oder – für eher Vorsichtige – in einem produktionsnahen Testsystem. Je weiter sich der Admin aber von der tatsächlichen Anwendung entfernt, desto unzuverlässiger sind die Testergebnisse.

Kleines Chaos

Wie aber mit dem Chaos Engineering beginnen? Als niedrig hängende Frucht und somit erster Angriffspunkt gilt immer die Kommunikation zwischen Systemkomponenten. Hier bekommt der Admin einfach einen Fuß in die Tür, wenn er die Hostsysteme unter Kontrolle hat. Er kann stupide einzelne Systeme herunterfahren, aber auch mit Linux-Bordmitteln die (Netzwerk-)Antwortzeiten eines Hostrechners manipulieren, etwa mit so genannten Fault Injections. Das klappt unter anderem über das Tool Stress [1], das Last auf der CPU des Systems erzeugt:

stress --cpu 2 --timeout 30s --verbose

In diesem Beispiel generiert Stress auf zwei Workern für 30 Sekunden Volllast (Abbildung 3).

Abbildung 3: Einfaches Chaos lässt sich bereits mit traditionellen Linux-Tools wie Stress anzetteln.

Das Werkzeug Tc (Traffic Control, [2]) ist in der Lage, die Netzwerk-Kommunikation gezielt zu manipulieren:

tc qdisc add dev lo root netem delay 100ms
tc qdisc del dev lo root

Der erste Befehl baut in jedes über den Netzwerkadapter gesendete Paket eine Verzögerung von 100 Millisekunden ein (»delay 100ms«). Die zweite Zeile deaktiviert das Delay wieder.

Bereits mit diesen beiden Werkzeugen ruft ein Admin gezielt Beeinträchtigungen hervor und startet erste Chaos-Experimente auf kleiner Flamme.

Fortgeschrittenes Chaos

Wer mit Docker arbeitet und die Resilienz seines Systems prüfen möchte, kann zu Pumba [3] greifen, um Chaos-Experimente auf Container-Ebene zu starten. Läuft Pumba auf dem Docker-Host, ist es leicht, das Verhalten eines oder mehrerer Container zu manipulieren. Die Unterbrechung aller Prozesse für 10 Sekunden lässt sich beispielsweise mit einem simplen Kommando initiieren:

pumba pause --duration 10s

Dank der vorgestellten CLI-Befehle verursacht der Admin mit wenigen Handgriffen schon ein ordentliches Maß an kontrolliertem Chaos. So muss er nicht erst auf den unkontrollierten Nutzeransturm um Weihnachten warten, bis die Systeme in die Knie gehen.

Natürlich ist das Ausführen manueller Kommandos nur ein Hilfsmittel, um erste Erfahrungen mit kleinen, simplen Systemen zu sammeln. Nimmt die Komplexität der Systeme zu, gibt es also beispielsweise viele heterogene Microservices, die in verteilten Container-Umgebungen laufen, müssen Chaos-Stifter ein wenig weiter ausholen.

Zum professionellen Testen großer Systeme gibt es mittlerweile auch im Chaos-Engineering-Bereich verschiedene PaaS-Lösungen. Zu nennen ist hier etwa die Chaos Platform von Chaos-IQ [4], sie stellt Werkzeuge wie das Chaos Toolkit [5] und das Chaos Hub bereit.

01 apiVersion: extensions/v1beta1
02 kind: DaemonSet
03 metadata:
04   name: pumba
05   namespace: shoppingdemo
06 spec:
07   template:
08     metadata:
09       labels:
10         app: pumba
11         type: chaos-engineering-tool
12         com.gaiaadm.pumba: "true" # prevent pumba from killing itself
13       name: pumba
14     spec:
15       containers:
16         - image: gaiaadm/pumba:master
17           imagePullPolicy: Always
18           name: pumba
19           args:
20             - --interval
21             - "15s"
22             - netem
23             - --tc-image
24             - gaiadocker/iproute2
25             - --duration
26             - "5s"
27             - delay
28             - --time
29             - "5000"
30             - "re2:.*fashion-pod*"
31           resources:
32             requests:
33               cpu: 10m
34               memory: 5M
35             limits:
36               cpu: 100m
37               memory: 20M
38           volumeMounts:
39             - name: dockersocket
40               mountPath: /var/run/docker.sock
41       volumes:
42         - hostPath:
43             path: /var/run/docker.sock
44           name: dockersocket

Mit dem Chaos Toolkit gießt der Admin seine Experimente in Skripte und dokumentiert sie auf diese Weise auch gleich. Für viele verbreitete Plattformen wie Kubernetes gibt es bereits Schnittstellen, die es erlauben, Systeme automatisiert mit Fault Injections verschiedenster Art zu unterwandern. Das Chaos Hub erweitert das Chaos Toolkit um Optionen zur Kollaboration. Es erlaubt, die Arbeitsschritte rund um die Experimente sowie die Resultate mit anderen zu teilen.

Pumba-Angriffe lassen sich in Kombination mit Kubernetes problemlos über das Chaos Toolkit steuern. Um einen Chaos-geladenen Container zu erzeugen, der mit Hilfe von Pumba alle anderen Container, deren Namen den Teilstring »fashion-pod« tragen, mit einem Fünf-Sekunden-Netzwerk-Delay infiziert, würde bereits das Kubernetes-Skript aus Listing 1 reichen.

Die Werteliste »args« des einzigen Containers enthält hier die Pumba-Konfiguration. Dieser Angriff lässt sich mit einem geskripteten Chaos-Toolkit-Experiment schließlich automatisiert und nachvollziehbar dokumentiert im Chaos Hub ablegen. Das Chaos-Toolkit-Skript aus Listing 2 repräsentiert am Ende das gesamte Experiment.

01 {
02   "version": "1.0.0",
03   "title": "Inject latency in a fashion pod",
04   "description": "Inject latency via Pumba into a fashion pod",
05   "tags": [
06     "microservice",
07     "kubernetes",
08     "pumba"
09   ],
10   "steady-state-hypothesis": {
11     "title": "Services are all available and healthy",
12     "probes": [
13     {
14       "name": "api-gateway-must-still-respond",
15       "provider": {
16         "type": "http",
17         "url": "http://host/startpage",
18         "timeout": [0.25, 0.50]
19       },
20       "tolerance": 200,
21       "type": "probe"
22     }
23     ]
24   },
25   "method": [
26   {
27     "type": "probe",
28     "name": "all-services-are-healthy",
29     "tolerance": true,
30     "provider": {
31       "type": "python",
32       "module": "chaosk8s.probes",
33       "func": "all_microservices_healthy",
34       "arguments": {
35         "ns": "shoppingdemo"
36       }
37     }
38   },
39   {
40     "type": "action",
41     "name": "deploy_pumba_as_daemon_set",
42     "provider": {
43       "type": "process",
44       "path": "kubectl",
45       "arguments":{
46         "apply":"",
47         "-f":"../pumba-inject-latency-all-fashion-services.yaml"
48       }
49     },
50     "pauses": {
51       "after": 15
52     }
53   },
54   {
55     "type": "probe",
56     "name": "check-gateway-response",
57     "provider": {
58       "type": "process",
59       "path": "ab",
60       "timeout": 60,
61       "arguments": {
62         "-n": "500",
63         "-c": "4",
64         "-s": "1",
65         "-g": "output.data",
66         "https://host/startpage": ""
67       }
68     }
69   }
70   ],
71   "rollbacks": [
72   {
73     "type": "action",
74     "name": "delete_pumba_as_daemon_set",
75     "provider": {
76       "type": "process",
77       "path": "kubectl",
78       "arguments":{
79         "delete":"",
80         "-f":"../pumba-inject-latency-all-fashion-services.yaml"
81       }
82     }
83   }
84   ]
85 }

Im ersten Teil definiert das Skript Metadaten zum Experiment (»version«, »tags« und so weiter), einen Soll-Zustand (»steady-state-hypothesis«, Zeile 10) und zuletzt Prüfroutinen, die diesen Zustand beschreiben (»probes«, Zeile 12).

Im Mittelteil (»method«, Zeile 25) befinden sich die spannenden Passagen. Sie beschreiben unter anderem die Angriffe (»”type”: “action”«, Zeile 40), hier findet auch das Deployment des Pumba-Containers als Daemon Set statt (»”deploy_pumba_as_daemon_set”«).

Da die Experimente auf produktiven Infrastrukturen stattfinden, müssen die Chaos-Stifter nach einem Experiment – egal ob es erfolgreich ausgegangen ist oder nicht – hinter sich wieder aufräumen (»rollbacks«). Das bedeutet unter anderem, die Pumba-Artefakte nach dem Ende der Experimente wieder entfernen. Über Chaos Toolkit startet der Admin das Skript:

chaos Skriptname --org Organisation --workspace Public

Es übernimmt die weitere Ausführung und dokumentiert das Ergebnis im öffentlichen Workspace eines Chaos-Hub-Accounts.

Auf dem Schirm

Detailliertes Monitoring ist für erfolgreiches Chaos Engineering ausschlaggebend. Schließlich möchte der Admin gern wissen, wie sich das System während der Experimente verhält.

Für diesen Job erweist sich das Expertentool Instana [6] als perfekt geeignet. Es überwacht verteilte Container-Umgebungen effektiv und ohne großen Aufwand zu erzeugen. Der Admin installiert den Instana-Agenten auf dem Container-Host, wo er auch alle laufenden Container in der Umgebung analysiert. Art und Zusammenspiel der einzelnen Anwendungen erkennt er dabei automatisch und visualisiert sie. So kann er die Kommunikation untereinander und die Metriken der einzelnen Komponenten lückenlos überwachen.

Das Experiment soll die angegriffenen Services besonders genau im Auge behalten. Das Verhalten zum Zeitpunkt eines Angriffs lässt sich dann mit dem Verhalten im Regulärbetrieb vergleichen. Die im Experiment gestarteten Angriffe heben sich gegebenenfalls deutlich in den Metriken hervor.

Gehen die Metriken während des Experiments allerdings zu stark in den Keller (Abbildung 4), sollte der Admin unbedingt rechtzeitig die Notbremse ziehen. Schließlich arbeitet er auf dem Produktionssystem.

Abbildung 4: Die Auswirkungen des Experiments finden sich auch in den Metriken wieder.

Wer sich weiter in das Thema einlesen möchte, findet grundlegende Literatur unter [7] und [8]. Beide Werke sind frei verfügbar und erläutern ausführlich die Prinzipien des Chaos Engineering.

Fazit

Entschließt sich eine IT-Abteilung, Chaos Engineering einzuführen, ist dies sicher nicht frei von Aufwand. Auf der Nutzenseite findet sich aber nicht nur ein resilientes System mit vorhersagbarem Verhalten, sondern auch das gute Gefühl, für mehr Eventualitäten gewappnet zu sein. Und beides ist mitunter mehr wert als die Implementierungskosten.

Zusätzlich erzwingt Chaos Engineering ein gut durchdachtes Monitoring, das ohnehin eine wertvolle Investition ist. Einen detaillierten Überblick über sein System zu haben, das ist in komplexen Umgebungen oft fundamental.

Chaos Engineering lässt sich aber auch für kleine Applikationen sinnvoll anwenden. Die hier vorgestellten Tools erlauben manuelle Fault Injections zum Teil bereits ohne hohe Kosten. Das ermöglicht kleine Experimente mit geringem Aufwand. Natürlich steigt der Testaufwand mit der Systemgröße, die gesammelten Erfahrungen machen sich aber nachhaltig bezahlt. Wichtig ist am Ende, die Experimente regelmäßig und automatisiert auszuführen, also das Chaos zu umarmen.