Diese Folge ist absolutes Chaos, aber das ist gewollt und
kontrolliert unmessbar, denn es geht um Chaos Engineering.
Das ist eine Technik, bei dem man mit Experimenten versucht
festzustellen, wie sich das eigene System bei Ausfällen
aller Art verhält. Lass uns mal anschauen, wie
genau das geht. Und damit herzlich Willkommen
zufolge 92 des to do Developer Podcast mit Robin Manuel Thiel
und Malte Lantin. Das war ein klasse Intro voller
Energie, ich. Bin hellauf.
Begeistert. Absolut.
Und ja, ich begrüße Euch alle herzlich zu dieser Folge hier
aus meinem Hotelzimmerstudio und das Schöne ist, wir beiden,
Robin Wanne und ich sind uns so nah wie lange nicht und das
Romantische ist wir sitzen extra ein paar Kilometer voneinander
entfernt in separaten Räumen, um die bestmögliche Audioqualität
zu gewährleisten. Wir hätten uns gerne gesehen,
aber da der Podcast darunter gelitten hätte, haben wir das
nicht getan, von daher. Größtes Opfer für diesen
Podcast. Aber vielleicht klappt es beim
nächsten Mal auch mit einem persönlichen Treffen.
Wir haben uns ja vor 2 Wochen schon getroffen.
Aber das nächste Treffen steht bestimmt bald an.
Dieses Mal nicht. Also erstmal herzliche Grüße
hier aus München von. Ja, mir malte und Robin Manuel.
Genau. Wir sind zusammen hier und wir
haben aber noch nie auch nur eine einzige Folge zusammen im
gleichen Raum aufgenommen und wir hatten so n bisschen sorge,
dass das mit der Technik nicht funktioniert.
Wir wollen das aber auf jeden Fall irgendwann mal machen und
wir üben mal dran. Aber das war die Folge.
Worden sind diese, das war zu zu Risky das jetzt hier irgendwie
auf kurz vor knapp noch mal zu machen.
Aber ihr solltet eigentlich keinen Unterschied merken.
Und das Thema, was wir heute haben, Chaos Engineering, finde
ich persönlich super spannend. Wir haben uns ja in der
Vergangenheit häufiger mit dem Betrieb von Applikationen in
Cloud Plattformen auseinandergesetzt und gerade da
hat man ja die Infrastruktur. Nicht unter der Kontrolle, da
ist jemand anders für die Infrastruktur verantwortlich und
ich glaub deswegen ist es n super spannendes Thema.
Aber bevor wir einsteigen erstmal natürlich unsere
Danksagung und da auch auf jeden Fall noch mal herzlichen Dank an
Fabian und Chris für diecafe.de und virtuell ausgegeben habt
vielen Dank dafür, das reicht auf jeden Fall für die Zeit bis
zur nächsten Folge vielen Dank. Ja, danke auch von meiner Seite.
Und dann genug. Sagen genug gequatscht.
Jetzt fangen wir auch direkt an. KOS engineering.
Was ist das? Ich fand den Satz ganz cool, den
ich irgendwie in der Vorbereitung gelesen habe, da
hat jemand klingt auch sehr deutsch, aber da hat jemand
geschrieben, das ist hypothesengetriebene
Resilienzverbesserung des eigenen Systems.
Durch systematisches, kontrolliertes Chaos.
Es hört sich so n bisschen so an, als wird das aus einem aus
einem akademischen Paper kommen, das.
Bedeutet, dass wir uns im Vorfeld Gedanken machen, wie
sich unser System verhalten sollte, wenn bestimmte Dinge
passieren, die wir nicht unter Kontrolle haben oder weil Fehler
passieren. Bestimmte Komponenten in unserem
System ausfallen und wir nutzen. Tools dazu, diese Fehler durch
ein automatisiertes System, welches wir gezielt steuern,
deswegen kontrolliert, dass wir diese Ausfälle in unser System
einbringen, bestimmte Komponenten ausfallen lassen und
dann beobachten können, wie sich unser System, unsere Software
unter diesen Ausfällen verhält, um dann eine Gegenüberstellung
zu machen zwischen unserer Annahme im Vorfeld, also wie
sollte sich unser System verhalten und dem wie es sich
tatsächlich verhält. Das heißt, wir gehen davon aus.
Dass irgendwas immer schief gehen wird.
Wir machen uns Gedanken darüber, wie soll sich unser System
verhalten und testen dann, ob sich unser System wirklich so
verhält, wie wir es geplant hatten.
Genau. Ich find den Ansatz eigentlich
spannend, dass man immer von dieser ja Vermutung ausgeht.
Irgendwas wird wahrscheinlich immer irgendwo failen und wir
sind alle nicht nicht perfekt und irgendwo ist immer noch ein
Mensch in dieser Loop mit drin, dass man quasi auch das eigene
System für diese Ausfälle designt und schon von
vornherein. Für Resilienz oder Resiliency?
Aufbaut, so dass man halt einfach sagt Okay, wenn keine
Ahnung, entweder ich einen Fehler mache als developer oder
wenn in meiner Deployment Pipeline irgendwo ein Fehler
passiert oder wenn auf einem Server irgendwo ein Fehler
passiert oder wenn vielleicht sogar irgendwas fehlschlägt, was
ich gar nicht hätte beeinflussen können, zum Beispiel weil du
hast gerade gesagt, ich bei einem Cloud Provider bin und da
meine Anwendung betreibe und auch da passieren Fehler.
Auch die haben eine SLA. Vielleicht.
Die Sie, die sie mir versprechen von 99,99 oder 9 5%
Verfügbarkeit aber auch darüber hinaus gibt es ja ne kleine
Verfügbarkeit die die nicht gewährleistet ist.
Und da kann ich eben gucken, kann meine Anwendung damit
umgehen, wenn. Irgendwo wahrscheinlich n Mensch
in dieser Pipeline einen Fehler macht und das zu testen und das
auch kontinuierlich zu testen und das direkt in den
Denkprozess von meiner Architektur und von meiner
Anwendung mit einzubauen find ich eigentlich ziemlich
spannend. Ich weiß zum Beispiel, dass
Netflix das so macht. Also Netflix hat das mit ihren
Engineering Teams eigentlich so n bisschen diesen Begriff
geprägt und ins Leben gerufen und Netflix lässt sogar in ihren
Productionclustern permanent sogenannte.
Keine Chaos Monkeys laufen und alle Teams wissen, dass es
einfach ein bisschen Chaos gibt, auch in Produktion.
Und die wissen aber nie, wann es sie trifft.
Also man kann sich das vorstellen, das sind so kleine
Äffchen, die im im Cluster, bei denen man Kabel rausrupfen oder
mal irgendwo. Den den Netzwerk Traffic
irgendwie entweder ganz runter, Trottel oder einfach mal kappen
oder da ist mal irgendwo ne Datenbank die ausfällt und alle
Teams wissen, dass es jetzt nicht viel, aber so n bisschen
Chaos immer immer immer in diesem Cluster gibt und das
fängt schon in Death an, aber Netflix zieht das Halt bis zur
Produktion durch, die sind aber auch absolute Profis da drin
können wir keinem empfehlen direkt damit zu starten das in
Produktion auch zu testen, aber das hat halt zur Folge, dass
alle Teams bei Netflix ihre Services direkt Resilienz bauen,
weil sie wissen es könnte sein, dass mich irgendwann dieser
Chaos Monkey trifft. Und die Teams bei Netflix werden
halt daran gemessen, wie verfügbar, wie performant ihre
Anwendungen sind. Und auch rückblickend waren.
Und wenn ich aber weiß, dass das ja vielleicht meine meine
Jahresbewertung beeinflussen kann, wenn ich mich nicht auf
diesen Chaos Monkey da vorbereite, dann baue ich
natürlich direkt meine Anwendung, so dass da auch ruhig
mal was ausfallen darf. So wie ich es gelesen hatte, hat
Netflix damit angefangen, als sie damals von der eigenen
Infrastruktur in. Die Cloud umgezogen sind.
Ich glaub sie laufen auf AWUS und als sie damals diesen
Schritt gemacht haben, haben Sie gesagt, OK, jetzt haben wir
nicht mehr alles unter Kontrolle, jetzt ist der
Zeitpunkt gekommen, wo wir wirklich sicherstellen müssen,
dass wir gegenüber solchen Ausfällen.
Ja, für solche Ausfälle gewappnet sind, dass wir darauf
vorbereitet sind, insbesondere weil wir natürlich einen Dienst
bereitstellen, der erst mal im ganzen Land, aber mittlerweile
natürlich international jederzeit zur Verfügung stehen
muss. Es ist ja keine Business
Applikation, die ich vielleicht irgendwie nur zu bestimmten
Zeiten zur Verfügung stellen muss, sondern 24 / 7 muss diese
Applikation zur Verfügung stehen, um für die Kunden eine
gute Qualität zu liefern und du hattest gerade gesagt.
Solche Cloud Provider bieten mir einen SLA, eine
Verfügbarkeitsgarantie, aber selbst dort ist ja
einkalkuliert, dass es bestimmte Zeiten gibt, die sich teilweise
nur im Bereich von Minuten bewegen, in denen die Software
selbst innerhalb des Versprechens des Anbieters
vielleicht gar nicht verfügbar ist, weil bestimmte Komponenten
ausfallen können, für die der Anbieter dann nicht mal eine
finanzielle Haftung übernimmt, wenn dort dieser Ausfall
stattfindet. Aber ein ganz triviales Beispiel
ist ja etwas, das auch. Bei mir im Eigenbetrieb
passieren kann, was bei einem Dienstleister passieren kann,
was bei dem Hyperscaler passieren kann, ist n Großbrand
im Datacenter hat niemand unter Kontrolle, kann aber mal
passieren und da hilft mir der beste SMA meines Dienstleisters
nicht, dann krieg ich vielleicht Geld zurück, aber trotzdem ist
meine Applikation ausgefallen. Und solche Szenarien sind
natürlich die maximal größte Katastrophe.
Das ist ein komplettes Data Center ausfällt, in der
vielleicht meine Applikation läuft.
Ich kann mich darauf vorbereiten, indem ich
vielleicht in mehreren Regionen oder mehreren Rechenzentren
meine Applikation bereitstelle, aber ich bin nie 100% davor
geschützt, dass irgendwelche Komponenten ausfallen, und sei
es, es gab ja dieses berühmte Beispiel von den Servern, die
jede Nacht ausfielen, weil die Putzkraft immer den Stecker
gezogen hat, um besser staubsaugen zu können.
Und selbst solche trivialen Dinge können natürlich
passieren. Hardwareausfälle, menschliches
Versagen, menschliche Fehler, und das kann halt die komplette
Infrastruktur betreffen, da brauche ich vielleicht
Redundanz, es kann einzelne Komponenten betreffen, aber es
kann natürlich auch die Art und Weise, wie.
Daten zur Verfügung stehen, betreffen.
Es kann einfach eine Verlangsamung der Performance
sein. Ich habe zum Beispiel eine
Überlast von bestimmten Hardware Ressorts oder wie du vorhin
gesagt hattest, dass das Netzwerk ist langsam.
Oder ich hab halt bestimmte andere Probleme in meiner
Applikation. Ne bestimmte Speicherauslastung,
die ich gar nicht eingeplant hatte, weil bestimmte
Komponenten softwaretechnisch nicht so entwickelt wurden, wie
ich es ursprünglich gedacht hatte.
Das heißt, es kann immer etwas passieren und dementsprechend
muss ich mir Gedanken darüber machen, was sind die Szenarien,
auf die ich vorbereitet sein möchte.
Man kann nie 100% sicher sein, dass man gegenüber allen
Eventualitäten. Geschützt ist und von daher muss
man sich, und das finde ich eigentlich so schön, an dieser
Formulierung, die Ihr vorhin genannt hat, man muss bestimmte
Hypothesen aufstellen und bestimmte Szenarien aufstellen
und sagen, okay, das sind die Bereiche, auf die ich mich
vorbereite, weil das sind die wahrscheinlichsten Probleme, die
auftreten können, und da muss ich entsprechend drauf reagieren
können. Genau.
Und auch wenn das jetzt natürlich so in der Welt der
Hyperscaler, also wenn ich jetzt bei Adws, Google Cloud oder
Azure oder irgendwo bin, dann. Sinkt natürlich massiv die
Wahrscheinlichkeit, dass ich, selbst wenn das da n Großbrand
im Rechenzentrum geben sollte. Ich darf von überhaupt irgendwas
mitkriege oder da ist natürlich keine Putzkraft die die nachts
den den den Stecker zieht und auch da sind natürlich ganz viel
auch irgendwie virtualisiert, das heißt, selbst wenn da mal
irgendwie ne Server brennt, dann wird meine wird da meine meine
virtuelle Instanz einfach irgendwo anders hin umgezogen
und ich brich da wahrscheinlich gar nichts mehr mit oder das
passiert innerhalb von Sekunden, dass der Server dann mal
irgendwie neu gestartet wird oder so, aber ich muss ja auch
testen, ob meine Anwendung, selbst wenn mein Anbieter diese
SLS von maximal 5 Minuten im Jahr Ausfall oder sowas einhält,
ob. Meine Anwendungen dann trotzdem
auch. Sobald dann mein Rechenzentrum
wieder online geht, auch wieder online geht, also ob die auch
dann damit umgehen kann auch. Wenn das sich halt um einen
Ausfall von einer Millisekunde handelt, dass sie, dass sie
davon halt irgendwie recovery kann und da gibt es eine ganze
Menge verschiedener Use Cases, warum man das machen will und
ich würde sagen, bevor wir gleich in der Folge beschreiben,
wie man es denn macht, gehen wir damals kurz durch und.
Wir haben uns hier nämlich mal so n Paar aufgeschrieben und den
einen haben wir ja grad schon genannt so SLAS überprüfen also
auch die eigenen ne. Also auch wenn ich irgendwie nen
Service bereitstelle, dann muss ich ja auch meinen Kunden mein
Kundinnen irgendwie sagen, ja, gerade wenn ich den Cloud
Service baue, der hat ne gewisse, Wir garantieren
vertraglich ne gewisse Verfügbarkeit oder überhaupt
garantieren zu können, muss ich natürlich auch mal gucken, wie
verhält sich denn mein System wenn mir mal n Server wegbricht?
Ich kann nicht, da kann ich das weiterhin garantieren oder wenn
das Netzwerk mal langsam ist oder wie auch immer.
Und eine andere Sache, die ich spannend fand, ist so.
Kann ich mal der mal simulieren? Wie verhält sich denn mein
System unter Last? Das kann ja auch Chaos sein,
also funktioniert mein Auto scaling in beide Richtungen,
wenn ich auf einmal viel Last habe, werden automatisch neue
Server dazu gebucht, wenn die Last weggeht geht das
automatisch weg. Diese Server kann ich dann
wieder Kosten sparen. Also dieses wie verhält sich
mein System in verschiedenen Situationen, ohne dass ich
erstmal nen Ausfall gab, aber einfach eine Veränderung, das
finde ich schon mal eigentlich ein ganz ganz spannendes.
Ein Thema, was ich ja gerade schon genannt hat, ist auch halt
disaster Recovery. Wie schnell kann mein System
sich wieder erholen, wenn ich halt auf eine andere
Infrastruktur wechseln muss, weil irgendwie n Datacenter
ausfällt, ob bestimmte Komponenten ausfallen, das heißt
wie reagiert man System da drauf, wie schnell bin ich da
auch zeitlich und ein Punkt den ich persönlich fast am
wichtigsten finde ist, wie verhält sich die menschliche
Komponente, wie verhält sich mein Support Team, mein
Engineering Team wenn solche Incidents auftreten und das sind
ja. Sehr stressige Situationen,
Totalausfall der Applikation oder ein kritischer Ausfall,
dass bestimmt Teile meiner Applikation nicht mehr
funktionieren, habe ich da das richtige System in Place für,
kann ich engineer's Pagen kann ich halt mit den Leuten
arbeiten, wenn tatsächlich ein Großausfall ist.
Ich hab tatsächlich vor einiger Zeit mal so eine so ein Post
mortem gelesen, wo tatsächlich bei einem großen SARS Provider
eine komplette Datenbank gekillt wurde durch einen menschenlichen
Fehler ich glaube wir hatten es mal in einer Folge erwähnt.
Die Situation und wenn so etwas passiert, wie kann ich
sicherstellen, dass ich nicht nur die richtigen Leute
innerhalb von sehr kurzer Zeit zur Verfügung habe, sondern
diese Leute auch konzentriert unter Stress arbeiten können?
Weil am Ende kann ich bestimmte Dinge automatisieren.
Ganz häufig müssen Menschen diese Recovery auch mitsteuern.
Sie müssen eingreifen und bestimmte Dinge sind halt auch
dann vielleicht in der Übung, wenn ich das auf meiner Dev
Testumgebung mache. Easy, da kümmere ich mich drum,
da hab ich keinen Druck. Aber wenn dann wirklich die
Supporttickets Supporttickets Reinlaufen in als
Hunderttausende, dann stellt sich natürlich n ganz anderer
Stress ein und funktioniert mein Team dann trotzdem noch und
daher finde ich wirklich diese Incident drills ganz spannend,
dass ich tatsächlich auch simuliere.
Wir stellen uns vor, dass unser Produktivsystem und wir
reagieren genauso wie wir reagieren würden, wenn es unser
Produktivsystem wäre und holen genau die.
Gleichen Leute rein. Also ganz toll testen,
vielleicht einfach in dem Fall in der Test aber sicherstellen,
dass meine Leute dann halt in diesen stressigen
Autorsituationen in der Produktion richtig reagieren.
Genau einen letzten Punkt, den du hier noch in den Notizen drin
hast, wo wir uns auch darauf vorbereiten müssen, ist das
Thema Zertifikate. Wie oft ist schon eine
Applikation irgendwie offline gegangen, weil ein Zertifikat
ausgelaufen ist? Oder wir haben einen Security
Security. Ein Zertifikat rotieren wie
reagiert meine Applikation da drauf?
Das sind auch so Dinge, die möchte man nicht in Produktion
das erste Mal machen, sondern man möchte darauf vorbereitet
sein und von daher, es gibt ganz viele solche Use Cases die halt
ganz grob in diesem Bereich Chaos Engineering reinfallen,
weil wir durch Chaos Engineering diese Situation simulieren
können. Wir können uns in die Situation
bringen, dass wir mit diesem Problem umgehen müssen, dass wir
das Problem lösen müssen. Genau.
Und das muss natürlich. Also ich habe jetzt hier
Zertifikate. Stellvertreterhaft für alle
möglichen Arten von Security Incidents auch aufgeschrieben.
Das kann, ja kann ja sein, wir haben dann einen Eindringling
und müssen das jetzt irgendwie das System so abschotten, dass
da der Blastradius mit möglichst gering ist.
Aber wie du gerade schon sagst, das muss also Chaos Engineering
muss nicht immer was sein, wir simulieren was wo ein Mensch
dann drauf reagieren muss, dass das Feld jetzt eher so in diese
kack Kategorie Wir schulen unser unser Support Team so geht gegen
Incident, sondern im Idealfall sind das natürlich alles so
Stresstests, von denen sich das ohne mein System mehr oder
weniger automatisch recovered, wahrscheinlich mehr automatisch
recovered, wenn ich eben nicht viel weniger ich selber betreibe
und je mehr ich wirklich halt an einem Hyperscale an Cloud
Provider gebe, aber auch da will ich ja eben diese diese
Validierung haben. Dass mein System auf bestimmte
Szenarien gut oder richtig reagieren kann und was gut und
was richtig ist, das muss ich natürlich für mich selber
definieren, weil Resilience ist natürlich auch immer teuer, das
heißt, ich kann ja sagen, ja, ich möchte eigentlich in jedem
Rechenzentrum der Welt eine Version von meiner Applikation
laufen haben, und wenn jetzt ein Meteorit das Rechenzentrum.
Dann soll das automatisch in B weiterlaufen.
Kann ich mich natürlich gegen schützen technisch.
Ist aber wahnsinnig teuer, weil ich ja natürlich in jedem
Rechenzentrum einmal meine Infrastruktur aufbauen muss.
Deswegen ist es eigentlich immer ganz wichtig, wenn man sich aber
überlegt, OK, was möchte ich also gegen was möchte ich denn
wirklich geschützt sein und bei was ist es mir einfach nicht das
Geld wert, dass ich mich da. Dass ich mich dagegen auch
aufstelle und dann, wenn ich diese Experimente habe oder wenn
ich einfach weiß, OK, das sind, das sind die Dinge, gegen die
ich mich schützen, das und das sind die Parameter, dann kann
ich das einfach kontinuierlich validieren.
Also ich hab mit Teams gesprochen, zum Beispiel die.
Einmal im Quartal ein solches ein.
Ein solches Konto des Chaos laufen lassen.
Ich hab mit Teams gesprochen, die das quasi kontinuierlich
Laufen haben, da gibt es einfach, das wird konstant
gemacht. Ich hab mit ihm gesprochen, die
das als in ihres EICD Pipeline eingebaut haben, die gesagt
haben, wenn immer wenn wir ein Deployment machen machen wir
danach einmal so einen Chaos Test um zu schauen ob die n ob
die Veränderungen die wir gemacht haben immer noch unseren
Anforderungen entspricht. Das heißt, es ist in einem so n
bisschen selber überlassen und wahrscheinlich auch wieder sehr
ja abhängig vom Use Case, aber. Wie macht man es denn jetzt?
Also wenn ich jetzt so, wenn ich jetzt sage, OK, ich möchte, ich
möchte anfangen mit Chaos engineering, ich find das
spannend mein System da zu testen.
Wie gehe ich da vor? Ja, ich fänd gerade die Punkte,
die du genannt hast ganz wichtig.
Warum sich erstmal Gedanken machen, was sind die Szenarien,
auf die ich mich vorbereite und was ist dann die richtige
Strategie um halt so ein Chaostesting oder so ne
Ernstfall Simulation zu machen? Läuft es in bestimmten
Zeitabständen oder läuft es regelmäßig regelmäßig,
vielleicht eher im Sinne von Testen der
Selbstheilungsfunktion meiner Applikation und andere Dinge
vielleicht um unser unser Support Personal zu schulen, das
heißt ich muss mir erstmal jetzt Gedanken machen, was sind die
Szenarien? Welche Applikationen und welchen
Workout möchte ich jetzt eigentlich?
Letzten Endes testen und Resilienter machen.
Dann gehe ich hin, basierend auf meinem Szenario.
Was sind die Komponenten, die ich ausfallen lassen möchte und
wann möchte ich diese ausfallen lassen?
Und wie soll meine Applikation darauf reagieren?
Dann muss natürlich diese Applikation in einer
realistischen Situation sein. Das heißt, ich muss auch
irgendwie n low Test laufen lassen.
Ich muss user Traffic simulieren, ich muss das Ganze
dauerhaft Monitoren um natürlich dann auch nachher die
entsprechenden Informationen, dass man Applikationen haben wie
hat meine Applikation reagiert, wie sie, wie haben sich die
Metriken verändert, wie war die Hardware Nutzung, wie haben
andere Komponenten darauf reagiert als bestimmte
Komponenten ausgefallen sind. Ich meine es kann natürlich auch
sein, ich habe irgendwie. Ohnehin eine Redundanz in meiner
Applikation eingebaut. Aber wie reagieren?
Vielleicht in meinem Cluster? Die einzelnen Komponenten da
drauf. Wenn ich so und so viele VM s
aus dem Cluster einfach rausnehme, weil diese VM s
vielleicht ausgefallen sind. Das heißt wie geht dann die Last
hoch in den anderen Komponenten und nachdem ich das alles
definiert und in die Richtige, in das richtige Setup gebracht
habe, brauche ich natürlich das Tool um das ganze Halt zu
skripten zu automatisieren, je nachdem in unregelmäßigen
Abständen. Oder natürlich jedes Mal, wie du
gerade gesagt hast, innerhalb meiner CI, um bestimmte Dinge
abzudecken. Es ist so ein bisschen so das
Gesamtvorgehen, wie ich jetzt daran gehen würde, wenn man mit
dem Thema neueinsteigt. Genau.
Ich find aber einen ganz wichtigen Punkt ist immer, dass
man wissenschaftlich vorgeht. Was meine ich damit meine ich,
dass man erst eine Hypothese aufstellt, wie sich das System
verhalten sollte bei einem Autogramm, dann lässt man das
Chaos Experiment laufen. Und dann muss man dabei
natürlich die nötigen Analytics einsammeln, um festzustellen, ob
meine Hypothese stimmt. Und dann baue ich, je nachdem,
ob sie stimmt oder nicht, Verbesserung in mein System an.
Und wenn ich diesem Pattern immer Folge, kann ich eigentlich
sehr gut für diese Hypothese, also erst schreibe ich diese
Hypothesen nieder, die ich testen möchte, das ist dann
gleichzeitig auch schon die Szenarien, gegen die ich mich ja
schützen möchte, und dann sage ich okay ich mache das
Experiment, ich sammle die Analytics ein, das ist ein ganz,
ganz, ganz, ganz wichtiger Punkt.
Festzustellen, stimmt man die Hypothese oder nicht und baut
dann die Verbesserung ein, wie du gerade schon gesagt hast.
Diese Experimente haben eigentlich immer dieselben 5
Komponenten. Es gibt einmal die App, also
welcher Workout soll auch die Reserve soll auf seine Resilienz
validiert werden, es gibt die Targets die ich angreifen
möchte, also welche Infrastrukturkomponenten sollen
attackiert werden und in diesem Experiment involviert sein, also
aus Gewissen dieser Blast Radius den ich dann immer im Experiment
mache, dann brauche ich natürlich Traffic, das ist der
dritte Punkt hast du gerade schon gesagt repräsentativ
repräsentativen User Traffic generieren es hilft mir nichts
zu wissen ja wenn. Da 3 User drauf sind, macht es
gar nichts, wenn da mal eine WM ausfällt, sondern es muss halt
repräsentativen Traffic haben und dann der für mich wichtigste
Punkt observability ich brauche Telemetrie, ich brauche
Metriken, vielleicht habe ich ja irgendwo meine Alerts, ich
werde. App Health Monitoring
wahrscheinlich ja irgendwo haben und das zusammen nehm ich dann
in meinen Chaos Experiment und das sind dann zufällige oder
gescriptete Störungen an meinen Tardigits, also an diesen
Infrastrukturkomponenten, die attackiert werden sollen und das
kann ich dann eben abfeuern. Und letztendlich führt das
natürlich zu so einem System der kontinuierlichen Verbesserung.
Ich glaube, wir alle kennen dieses Bild dieser Dev ops 8 und
wenn wir uns jetzt das Ganze erweitern um entsprechende.
Tests der Infrastruktur, um die Resilienz zu erhöhen.
Wir haben ja klassischerweise, wenn wir über diesen
kontinuierlichen Prozess in Dev Ops sprechen, in erster Linie
unsere Software im Blick, das heißt, wir testen dort
regelmäßig, kriegen Feedback, entweder während unserer Tests
oder von den Usern und verbessern dann unsere Software.
Aber jetzt ergänzen wir das um die weitere Ebene der
darunterliegenden Infrastruktur, um unsere Anwendung so resilient
zu machen, dass selbst bei bestimmten Ausfällen bestimmter
Infrastrukturkomponenten unsere Anwendungen.
Weiterhin gut funktioniert und ich glaub wir können kein System
von Anfang an so bauen, dass es auf alle Eventualitäten
vorbereitet ist, die irgendwo realistisch sind, sondern wir
müssen diese Tests laufen lassen.
Wir müssen. Ja, zufällig und deswegen ja
Chaos, bestimmte Komponenten in bestimmten Abständen ausfallen
lassen und schauen, wie reagiert unsere Anwendung dadrauf, um
auch wirklich diese Verbesserung hereinbringen zu können, weil
ich glaube, niemand kann tatsächlich auch auf alle Dinge
von vornherein vorbereitet zu sein und ich glaube, in der
Softwareentwicklung sind wir auch seit vielen Jahren an dem
Punkt, dass wir diese diese Annahme so ein bisschen auch
schon über Bord geworfen werden, dass wir über Bord geworfen
haben, dass wir uns schon bei der Planung der Software auf
alle Eventualitäten vorbereiten können.
Wir müssen wirklich das Ganze testen.
Wir müssen schauen, wie reagiert die Anwendung, um das Ganze dann
zu verbessern, und das sehen wir im Ganzen in bestimmten
Industrien seit vielen Jahren, gerade wenn es jetzt um so
Hardware Nahentwicklung geht. Ich glaube einige von euch sind
natürlich auch in der Embedded Entwicklung, wo es darum geht
irgendwelche Software für Industriemaschinen, für Autos
oder zu entwickeln und dort findet das natürlich seit vielen
Jahren. Hat dort werden bestimmte
Ausfalltests durchgeführt, um zu schauen, wie reagiert meine
Software, wenn eine bestimmte Hardware Komponente in meinem.
Autor in meiner Waschmaschine et cetera ausfällt.
Wie reagiert dann das darauf, insbesondere in
sicherheitskritischen Systemen, wie zum Beispiel im Auto?
Wie reagiert dann meine Software daraus, wenn ein bestimmter
Sensor ausfällt oder wenn bestimmte andere Komponenten
ausfallen? Da kennen wir das schon, weil
wir da aus rein Sicherheitsgründen schon davon
ausgehen müssen, dass wir darauf reagieren müssen, aber das
gleiche können wir natürlich auch bei beliebiger anderer
Software machen, die wir auf komplexer Infrastruktur
betreiben, wenn wir unsere Software vielleicht irgendwie
auf einem ganz simplen System einen Server mit einer
Datenbank. Da gibt es wenig, was da letzten
Endes zufällig passieren kann. Da kann vielleicht der ganze
Server ausfallen oder vielleicht die Datenbank oder der
Webserver, aber am Ende kann nicht so viel passieren, aber
heutzutage ist ja die Infrastruktur, auf der unsere
Software läuft, meist weitaus komplexer, wir haben ganz viele
verschiedene Komponenten und insbesondere wenn wir Cloud
native Applikationen bauen, Applikationen auf solchen
Plattformdiensten in Hyperscaler Cloud haben wir so viele
verschiedene Komponenten. Die unabhängig voneinander
völlig verschiedene Störungen haben können.
Und da ist natürlich dann wichtig, sich entsprechend
darauf vorzubereiten und dafür gibt es glücklicherweise
mittlerweile entsprechende Tools, die wir da nutzen können.
Das heißt, wir sind da nicht komplett auf uns alleine
gestellt, wir brauchen jetzt kein Admin, der dann
irgendwelche Skripte abfeuert, um mal eine Komponente aus dem
System rauszunehmen. Sondern wir haben dort
entsprechende Werkzeuge, auf die wir zurückgreifen.
Können genau da haben wir uns ja in der Vorbereitung ein Paar
angeschaut. Also einmal finde ich es
natürlich spannend, dass zumindest 2 der großen Cloud
Provider haben wir gefunden, dass die quasi schon so ein
Chaos Engineering Tool oder Service mit in ihrer Plattform
eingebaut haben, das einmal bei Microsoft Azure gibt es das
Chaos Studio und bei AWS gibt es den False Injection Service und
die haben natürlich den großen Vorteil, dass die schon eine
tiefe Integration in die eigene Cloud Plattform haben, das heißt
ich kann da so Autages und Slowdowns zum Beispiel von der
gemanagten Datenbank oder auch den Shutdown von der VM oder
sowas. Einfach simulieren, weil ich
natürlich dadurch, dass das tiefe Migration diese Plattform
ist. Da halt auch einfach direkt den
Zugriff drauf habe. Also ich kann zum Beispiel auch
irgendwie Memory oder Disc oder CPU Failiers.
Polieren ich kann den Delay also einfach mal ne langsame
Netzwerkverbindung, wirklich trotteln und die haben natürlich
auch dann ne sehr gute Integration in die eigene
Monitoring Tools oder in die eigenen Services.
Also ich zum ne ist kein Geheimnis, ich arbeite viel wie
mit Microsoft Azure, die haben einen gemanagten kubanetis
Service und da kann ich dann direkt auch in diesem Asia Chaos
Studio in den gemanagten Kubanitus Service rein und dann
da auch welche irgendwelche Fehler simulieren, das heißt da
bei Azure und Adobe AS gibt es einfach schon fertig von der
Plattform einen eigenen Service. Bei Google habe ich jetzt nichts
gefunden. Wenn jemand zuhört und da einen
eigenen Service von Google kennt, könnt ihr das ja gerne
auch irgendwie in den Kommentaren ergänzen.
Dann reichen wir das nächste Folge nach.
Es gibt dann aber auch ganz, ganz viele eigene, so Open
Source Tools, die man selber betreiben kann.
Und ne ich hab mir das kommt alles ja so n bisschen aus
dieser Netflixwelt, die sind ja auch sehr große Verfechter von
Kubanetis, das heißt sie haben nicht nur Chaos Engagement
geprägt, sondern auch direkt ein Tool mitgebracht.
Hier Chaos Monkey ist soweit ich weiß direkt von Netflix und da
drauf hat sich auch noch Chaos Mesh gebildet.
Das ist ein Open Source Experiment, was dann auch der
Cloud Native Computing Foundation übergeben wurde und
was noch mal ein bisschen komplexer ist, aber da kann ich
dann wirklich auch quasi alles wirklich simulieren, was in
meinem Kubanitus Cluster. Quasi fehlschlägt.
Und dann gibt es darüber hinaus aber noch ganz viele Tools, die
eben nicht nur in meinem, also in einer einzelnen Infrastruktur
im Klasse, sondern auch wirklich über so Cloud übergreifend
Experimente durchführen. Du hast dir da glaube ich ein
Paar angeguckt, malte. Wir haben und Netflix hat das im
Laufe der Zeit auch immer mehr erweitert über die
Infrastruktur, Komponenten, den raus hinaus haben sie neben
Chaos Monkey auch ein Tool wie latency months, was halt
latexancy. Einführt oder n Tool was halt
bestimmte Komponenten außerhalb der internen IT Konformität
bringt. Also wie reagiert dann mein
System da draus? Das heißt Sie haben so ne ganze
Familie von Werkzeugen entwickelt, dann gibt.
Natürlich. Monkey ne ist immer irgendwas
Monkey. Genau, also.
Sie nennen es irgendwie Simeon Army.
Ich hab jetzt nicht geschaut, was sich da hinter verbirgt
hinter diesem Begriff, aber sie haben halt wirklich diese ganze
Familie von von Tools. Und darüber hinaus gibt es
tatsächlich noch ganz viel in der Open Source Welt und auch an
kommerziellen Tools. Es gibt halt sowas wie Chaos
Toolkit, was n Open Source Framework ist, was man
tatsächlich für ganz viele verschiedene Szenarien verwenden
kann, auch für verschiedene Cloud Plattformen, wenn man
keine dieser eingebauten Dienste nutzen kann oder möchte.
Es gibt speziell für Docker ausgelegte Tools für Docker
Container, um dort gerade so Netzwerkstörungen reinzubringen,
Container zu stoppen, das Tool ich da gefunden habe, nennt sich
Pamba oder Pumbaa. Dann gibt es noch andere Open
Souls Tools speziell für Cobanitis.
Du hast gerade schon glaube ich erwähnt Cube Monkeys, es gibt
lithmus, also ganz viele Tools, halt speziell in dieser Cloud
native cubinitis Welt und ein ganz populäres Tool für Chaos
Engineering ist auch Gremlin, mit dem ich sehr viel auch
tatsächlich. Machen kann auch visuell
skripten kann, da gibt es auch ne UI wo ich das Ganze
entsprechend vorbereiten kann und auch verschiedene
Komponenten adressieren kann, das heißt sowohl im Open Source
Bereich als auch im Bereich der kommerziellen Tools gibt es
einiges und. Was du jetzt noch in die Liste
mit aufgenommen hast und dass ich ursprünglich gar nicht
gedacht hatte, ist halt das ganze Thema.
Wie mache ich das eigentlich bei Web Applikationen Clientside
dazu gesagt Hier Chrome Developer Tools bringt ja auch
einiges mit, zum Beispiel wie kann ich eine schlecht
Internetverbindung simulieren oder wie kann ich einen CPU
Thread legen oder andere Systemeinschränkungen simulieren
die natürlich auftreten können. Ja, also es sind natürlich nicht
nur Backend Systeme, sondern auch frontends.
Einfach simulier mal. Der User fährt mit seinem iphone
in den Tunnel, mal kurz kein Internet.
Wie verhält sich meine Anwendung, das ist ja auch
spannend im Frontend. Man macht ja einfach einen
Retriever oder gibt es eine große rote Fehlermeldung und
alle meine meine Arbeit ist weg, wir hatten ja vor, ich habe 2
folgen über das Thema offline first gesprochen und da kam mir
das natürlich auch auf und dann wer sich schon ein bisschen
tiefer in die Chrome developer Tools rein gefuchst hat, er hat
auch schon mal gesehen, dass man da auch langsames Internet
simulieren kann, was manchmal fast noch schwieriger ist als
einfach so ein binären Zustand wie online oder offline, wenn
das Internet etwas sehr langsam ist, funktioniert meine
Anwendung noch oder wenn die CPU ist, weil die vielleicht auf
einem schwachen Gerät. Sondern auf dem Gerät, auf dem
der User gerade unterwegs ist. Auch viele andere Sachen
passiert auch das finde ich spannend, aber wie gesagt, keine
Sorge, müsst ihr diese ganzen Tools, die wir gerade genannt
haben, nicht nicht merken. Wir machen uns natürlich die
Mühe und packen euch die ganzen Links dazu in die Shownotes von
der Folge. Aber ich glaub, da gibt es auch
kein bestes Tool. Ich würd sagen, klickt euch da
mal durch, schaut euch an, was euch am besten gefällt und dann
klein anfangen, denn das ist glaub ich das Wichtige, dass man
mal so n Mindestklein anfangen, das ist wie mit Unittest der
erste ist schon fast der Wichtigste, dass man zumindest
mal irgendwie was hat. Und dann, wenn man sich für so n
Tool entschieden hat und wenn man sich diese Szenarien
ausgesucht hat, die man eigentlich abdecken möchte, also
was wogegen möchte mich denn schützen, dann ist die
Vorgehensweise eigentlich immer dieselbe.
Also man macht, ich hab jetzt diese Hypothese, ich hab meine.
Meine Targets und meine App definiert, die ich testen
möchte. Mein blastradius ich hab meine
Analytics an Bord und dann funktioniert es eigentlich immer
gleich, dann macht man dann ist es der erste wichtige Punkt und
es ist witzigerweise auch der Punkt.
Den ich am Anfang, als ich mit dem Thema angefangen hab, halt
vergessen habe, ist, dass man natürlich einmal so diese
Workload Baseline nenn ich das mal ausmacht, also einfach bei
einem bestimmten realistischen User Traffic.
Wie ist denn meine durchschnittliche Response Time,
wie ist denn meine feature Verfügbarkeit, was sind denn
meine Fehlerquoten und was sind denn das sind so die Häufigkeit
meiner Fail frequests damit ich überhaupt mal irgendwas hab
gegen das ich messen kann. Ich hab immer so Chaos
Engineering also Chaos Experimente gestartet also ja
okay ja klar hier meine Verfügbarkeit geht runter.
Was ist denn eine normale Verfügbarkeit für mich?
Was ist denn eine normale Response Time?
Also das einfach einmal messen, also diese Workload baseline
habe ich es genannt, machen dann natürlich das Experiment starten
klar, dann die Telemetrie einsammeln, dann auch ganz
wichtig das Experiment wieder stoppen, auch hier, ich war mal
bei einem Kunden wo wir das eingeführt haben und ja haben
dann am Tag drauf uns gewundert, dass das die Anwendung immer
noch sich nicht erholt hat und irgendwie kaputt ist und alles
super langsam ist und dann um nur um dann feststellen, dass
wir das Experiment nie gestoppt haben und diese Chaos Monkeys
Monkeys da weiter wie wild irgendwelche Stecker raus
gerupft und zufällig zufällig irgendwelche wms runtergefahren
haben das mag jetzt Netflix können, weil die das in
Produktion immer machen. Aber ich sag mal, die wenigsten
Kunden sind jetzt so groß wie Netflix und haben auch irgendwie
das das Team. Also auf jeden Fall auch mal das
Experiment wieder stoppen, gerade wenn man sich noch noch
nicht entschieden hat, dass das n kontinuier n Kontinuum sein
soll. Und dann natürlich Monitoren, ob
und wie schnell das System wieder auf diese Baseline, die
man im ersten Schritt festgestellt hat, zurückfällt,
weil das ist ja auch eigentlich das Spannende.
Ne, ich hab Chaos, mein System mag ja dagegen reagieren, aber
wenn dieses Chaos aufhört und im Idealfall hört es ja irgendwann
auf, skaliert mein Cluster dann wieder runter zum Beispiel oder
bleiben diese WM Star, diese zusätzlich gebuchten wms für
immer stehen und erzeugen Kosten und wie schnell schaffe ich das
denn auf meine Baseline wieder zurückzufallen, weil das ist ja
auch einfach interessant und ich glaube, wenn man diese
Vorgehensweise. Immer macht also Baseline
ausmachen, Experiment starten, Telemetrie einsammeln,
Experiment stoppen und dann Monitoren.
Wie schnell ich auf diese Baseline Zurückfalle, dann hat
man glaube ich schon einen sehr sehr guten Start, das ist so ein
bisschen wie dieses. Arrange Act acert pattern, wenn
ich irgendwelche Unit Tests zum Beispiel schreibe, wo ich
einfach immer nach der gleichen Art und Weise unittests baue,
würde ich das bei Chaos entstehen übrigens einfach immer
nach diesem Pattern bauen. Ihr könnt es gerade im Podcast
nicht sehen und ich glaub, du hast es auch nicht gesehen, wie
ich mich zurückhalten musste, weil ich gerade im Kopf dieses
diesen Film hatte. Wie du mit einem LKW voller
Affen zum Kunden fährst, die auf das Data Center loslässt und
dann mit dem Lkw wieder nach Hause fährst und merkst, die
Affen sind immer noch beim Kunden.
Also das war dieses Bild, was gerade entstand, als so dieses
Szenario beschrieben und einfach einfach großartig.
Wo sind meine Affen vergessen? Sehr schön.
Also ihr wisst jetzt, wie das grundsätzliche Vorgehen ist.
Wie sollten wir jetzt einsteigen oder welche Best Practices gibt
es? Einige haben wir gerade schon
genannt, ich glaube das Wichtigste ist klein anfangen,
andere sagen hier so Crawl Walk run, das heißt, wir sollten eine
Grundlage legen und das Netflix Level, das können wir auch in
ein paar Jahren erreicht haben, dann gehen wir in dem Vorgehen
vor wie. Wir es vorhin beschrieben haben,
wir stellen unsere Hypothesen auf, wir machen unsere Tests,
Wir sammeln Telemetrie, nehmen die Learnings und nutzen diese
Learnings für eine kontinuierliche Verbesserung
unserer Applikationen. Dabei ganz wichtig immer die
Menschen mit einbeziehen, nicht einfach hingehen und so ein
Experiment durchführen, ohne dass das entsprechend
verantwortliche Engineering Team auch weiß, dass wir darauf wert
legen, weil natürlich wir die Leute nicht irgendwie am Ende
bloßstellen wollen, sondern wir wollen dafür sorgen, dass die
Leute ihre Architektur. Testen können, dass die Leute
die Applikationen oder die Komponenten der Applikation, für
die sie verantwortlich sind, kontinuierlich verbessern
können. Das heißt, Wir müssen die
Menschen mitnehmen, wir müssen auch dafür sorgen, dass unser
Support Personal darauf vorbereitet ist, was passiert
oder wie reagiere ich darauf, wenn wir bestimmte Ausfälle
haben. Und zu solchen Incidents können
natürlich auch. Themen wie Sicherheitslücken
gehören, das heißt? Ich muss aufpassen, wenn ich
solche Experimente durchführe, dass ich da nicht irgendwie aus
Versehen einen Backdoktor aufmache oder Zugriffe auf meine
Infrastruktur erlaube, die letzten Endes zu einer
Sicherheitsverletzung führen können.
Ganz viel dieser Tools brauchen natürlich sehr umfangreiche
Rechte auf meine Infrastruktur, um bestimmte Komponenten zu
beeinflussen, bestimmte Services außer Betrieb zu nehmen et
cetera. Da muss ich natürlich genau
drauf achten, welche Rechte hat dieses Tool, wer hat Zugriff auf
dieses Tool, um nicht letzten Endes Außenstehenden zu
umfangreiche Rechte auf meine Infrastruktur über diese Chaos
Tools zu geben, da bin ich natürlich im Vorteil, wenn ich
solche in die Cloud Plattform integrierten Werkzeuge habe,
weil sie genau dieses Role Based Access Control der Plattform mit
übernehmen, aber immer wenn ich irgendwelche externen Tools
verwende, die dann. Umfangreiche Rechte auf meine
Infrastruktur haben, muss ich darauf achten, dass ich nicht
durch mein Chaos testing irgendwelche Sicherheitslücken
in meine Infrastruktur reinbringe oder sogar
Datenschutzverletzungen begehe, weil dann Leute, die diese Tests
durchführen, plötzlich Zugriff auf irgendwelche Daten haben,
die Sie nicht sehen sollten. Das heißt, das muss ich
entsprechend berücksichtigen. Auch ganz wichtig, das Ganze
entsprechend zu dokumentieren, an Hypothesen zu dokumentieren,
meine Experimente zu dokumentieren und auch zu
dokumentieren, welche Verbesserungen ich daraus
abgeleitet habe, damit wir auch langfristig daraus lernen
können. Und auch dieses Wissen dann
weitergegeben, kann. Weitergegeben werden kann an
andere Leute, die vielleicht später das Unternehmen im
Unternehmen dazu kommen oder vielleicht neu ins Team dazu
kommen und das Experiment selber auch nicht so miterlebt haben,
aber trotzdem die Learnings mitbekommen.
Das ist doch ne super. Zusammenfassung ich würd noch
einen Satz gerne, bevor wir die Folge abschließen hinzufügen,
nämlich einfach. Der Hauptgrund, warum ich Chaos
Engineering als wichtig erachte, ist, ich will nicht zum ersten
Mal einen Ausfall erleben, wenn der in Produktion passiert,
mitten in der Nacht und nicht aus dem Bett geklingelt werde,
sondern ich will einfach wissen, wie mein System drauf reagiert
und dafür ist genau diese Schritte, die malte auch gerade
noch mal sehr gut zusammengefasst hat.
Dass ich halt einfach nicht zum allerersten Mal wie Ochs vorm
Berg stehe. Wenn jetzt irgendwas nicht
funktioniert, sondern ich habe das schon mal in einer
hoffentlich kontrollierten Umgebung erlebt und ich weiß
einfach sehr genau, wie ich reagiere und ich weiß, ich kenne
auch mein System und weiß auch, wie mein System reagiert.
Macht ihr Chaos Engineering schon?
Das würde mich eigentlich mal interessieren, weil ich finde
immer, ich weiß nie ob das so ne Bubble ist, weil alle sind immer
sehr interessiert wenn man drüber redet, ich kenn aber gar
nicht so wahnsinnig viele Teams die es wirklich machen.
Von daher machen wir mal ne kleine Umfrage, zumindest wenn
ihr auf Spotify uns hört unter die Folge, da könnt ihr mal
abstimmen, ob das bei euch, also ob es nicht interessant ist oder
ob das wirklich schon bei euch zum Einsatz kommt, das da, da
bin ich mir einfach immer unsicher, ich find es aber.
Irre spannend. Ich muss aber auch sagen, ich
mache es aber auch nicht immer selber und.
Lass uns generell auch mal irgendwie n Kommentar da und
lass uns wissen, wie euch die Folge gefallen hat.
Wenn sie euch gut gefallen hat, dann lasst natürlich auch gerne
ne gute Bewertung, da freuen wir uns auch immer sehr, wenn ihr
uns nen Kaffee ausgebt. Da gibt's nen Link zu unten in
den Show Notes zu bei mir Coffee, da freuen wir uns immer
sehr oder wenn ihr zu eurem eigenen Kaffee vielleicht die
passenden Nerd Tasse haben wollt, schaut auch gern mal in
unserem kleinen Shop vorbei. Beide Links findet ihr in der
Beschreibung von der Folge und auf jeden Fall würden.
Wir uns natürlich freuen, wenn ihr auch in 2 Wochen wieder
reinhört, wenn es eine neue Folge des to do Developer
Podcasts gibt. Alle 2 Wochen Montagmorgen eine
neue Folge wir freuen uns, wenn ihr dabei seid, bis dahin habt
eine Gute. Zeit.
Und schreibt ganz viel. Kommt bis dann.