Mein Vortrag auf den XPDays am 07.11. 2019 in Filderstadt zum Thema Chaos Engineering.

1. Chaos
Kata
Fitnesstraining
für DevOps Teams
Ramon Anger
flexis AG
XPDays 2019 Stuttgart, 07.11.2019

2. Wer von Euch macht …
Software Entwicklung?
DevOps?
Chaos Engineering?
Chaos Kata?

3. http://www.peakpx.com/590485/brown-coffee-sack, gemeinfrei
Seit 1997 Java Entwickler
(Entwicklungsleiter, Projektleiter,
Architekt, Consultant, Agiler Coach)
Grundnahrungsmittel -> natürlich Kaffee
Ramon Anger
flexis AG

4. Früher. Ganz früher …
wurden Release gemalt
Maximal 1-2 Releases pro Jahr
Gern mit den „veralteten“ Inhalten
DIN-A0 Plakate im Betrieb:
NEVER TOUCH A RUNNING SYSTEM!
NEVER CHANGE A RUNNING SYSTEM!
Rembrandt und Saskia im Gleichnis vom verlorenen Sohn. (1635/36), gemeinfrei

5. Copyright JD Hancock, licensed under a Creative Commons Attribution 3.0
Unported License, http://photos.jdhancock.com/photo/2010-06-30-223624-the-
pride-of-one.html
Dann wechselte das Wetter.
Schneller (besser sofort) liefern:
sicherer, skalierbarer
besser wartbar/betreibbar
näher am Betriebssystem

6. Dann wechselte das Wetter.
Schneller (besser sofort) liefern:
sicherer, skalierbarer
besser wartbar/betreibbar
näher am Betriebssystem
Copyright JD Hancock, licensed under a Creative Commons Attribution 3.0
Unported License, http://photos.jdhancock.com/photo/2010-06-30-223624-the-
pride-of-one.html
Viel komplexere Systeme

7. Was heißt Komplexere
Systeme?
eBay: 1000+ Microservices /
10.000+ Instanzen
https://www.infoworld.com/article/3041064/what-ebay-looks-like-under-the-hood.html
Netflix: 600+
https://blog.imaginea.com/microservices-architecture-an-experience/
AWS: 170+ angebotene „Services“
https://mytechdecisions.com/it-infrastructure/inside-amazon-web-services-aws-by-the-numbers/
Quelle: https://news.cornell.edu/stories/2019/03/help-ai-microservices-divvy-tasks-improve-cloud-apps
Zalando: 1700+
https://www.infoq.com/news/2016/02/Monolith-Microservices-Zalando/
Twitter: 1000
https://res.infoq.com/presentations/microservices-optimization-ml/en/slides/sl3-1517968620043.jpg
Uber: 1000+
http://highscalability.com/blog/2016/10/12/lessons-learned-from-scaling-uber-to-2000-engineers-1000-ser.html
Spotify: 800
https://blogs.oracle.com/de-cloud/was-sind-microservices
Amazon: 100-150 „Services“ für
eine Webseite
http://highscalability.com/amazon-architecture

8. Gibt es in solch komplexen
Landschaften überhaupt
Ausfälle?
https://status.aws.amazon.com/ am 11.09.2019
https://developers.facebook.com/status/dashboard/ am 11.09.2019

9. Everything fails
all the time!
Werner Vogels (CTO Amazon):
… Everything fails all the time.
We lose whole datacenters!
Those things happen …

10. Everything fails
all the time!
Warum?
Werner Vogels (CTO Amazon):
… Everything fails all the time.
We lose whole datacenters!
Those things happen …

11. Technical Dept?

12. Technical Dept
* kann aufgebaut werden
* im Code sichtbar
* durch Refactoring entfernen

13. Technical Dept
Dark Dept?
* kann aufgebaut werden
* im Code sichtbar
* durch Refactoring entfernen

14. Technical Dept
* kann aufgebaut werden
* im Code sichtbar
* durch Refactoring entfernen
* Fehler beim Zusammenspiel von
Komponenten
* nicht auf Code beschränkt
* kann bedingt bewusst aufgebaut werden
* kann „überall“ auftreten
* Auswirkungen in komplexen Systemen
sichtbar
Dark Dept

15. Gray Failure
• Sporadischer (hoher) Leistungsverlust
• Zufällige Paketfehler/-verluste
• Sporadisch eingeschränkte (Ressourcen-)
Verfügbarkeit
• Unklare Lastspitzen
• Non-fatal Errors
Gray Failure: The Achilles' Heel of Cloud-Scale Systems
https://www.cs.jhu.edu/~huang/paper/grayfailure-hotos17.pdf
https://commons.wikimedia.org/wiki/File:ThreeSirensPress_-_Dorian_Gray.jpg, gemeinfrei

16. Gray Failure
• Sporadischer (hoher) Leistungsverlust
• Zufällige Paketfehler/-verluste
• Sporadisch eingeschränkte (Ressourcen-)
Verfügbarkeit
• Unklare Lastspitzen
• Non-fatal Errors
<— mit Resilience Mustern begegnen
https://commons.wikimedia.org/wiki/File:ThreeSirensPress_-_Dorian_Gray.jpg, gemeinfrei

17. Es geht immer
irgendwie um
Resilience
Resilience:
* Elastizität
* Widerstandsfähigkeit
* Wiederanlauffähigkeit
Betroffen:
* Organisation
* IT-System
https://pxhere.com/en/photo/865929, gemeinfrei

18. Es geht immer
irgendwie um
Resilience
Resilience Muster/Lösungen:
* Redundancy
* Auto scaling
* Immutable infrastructure
* Statelessness
* Backoff algorithms
* Timeout
* Idempotent operations
* Service degradation
* Fallback
* Rejection
* Circuit breaker
* Health check
* Caching caching
* Bulkhead
* Loose coupling
* Self-containment
* Fail fast
* Bounded queues
* Shed Load
* Monitoring
https://pxhere.com/en/photo/865929, gemeinfrei

19. Chaos Engineering Services sind gut getestet
Integration der Services ist hart/
komplex/mit Überraschung verbunden
Integration im Cloud-Zeitalter
funktioniert anders als in der
„IT-Steinzeit“
Find the hard to find bugs
Quelle: https://news.cornell.edu/stories/2019/03/help-ai-microservices-divvy-tasks-improve-cloud-apps
https://pixabay.com/de/photos/hammer-nagel-geb%C3%A4ude-tool-arbeit-3717210/

20. Geschichten die das
Entwicklerleben schreiben …
* Chaos Monkey mal eben in
Produktion starten und schauen
was passiert
* Prod-DB stoppen und erwarten,
dass die Standby-DB übernimmt
* LoadBalancer überbrücken und
alle Anfragen auf einen einzelnen
Prod-Server leiten (Lastprüfung)
Chaos Engineering
done wrong

21. … ohne die Aktion vorher kommuniziert zu haben!
Chaos Engineering
done wrong
Geschichten die das
Entwicklerleben schreiben …
* Chaos Monkey mal eben in
Produktion starten und schauen
was passiert
* Prod-DB stoppen und erwarten,
dass die Standby-DB übernimmt
* LoadBalancer überbrücken und
alle Anfragen auf einen einzelnen
Prod-Server leiten (Lastprüfung)

22. Chaos Engineering
done wrong
Copyright: Telegraph.co.uk

23. Messen, was man tut
Exakt ein Ziel auswählen
Gut kommunizieren!
Wirkungsradius minimieren
* unverfängliche Umgebung nutzen
* Anzahl Fehler begrenzen
* Anzahl betroffene Maschinen/
Container begrenzen
* Region begrenzen
Chaos Engineering

24. Management-fähiges
Vokabular für
Chaos Engineering:
Resilience Engineering
Planung im öffentlichen Raum
* Verkehr (Verkehrsführung)
* Gebäude (Fluchtwege, Raumanordnung)
Industrie
* Sicherheit in Fertigungsanlagen
DevOps
https://github.com/lorin/resilience-engineering

25. Wie kann man
Chaos Engineering
trainieren?

26. Wie funktioniert Chaos Engineering eigentlich?
Wie kann man
Chaos Engineering
trainieren?

27. * Chaos Hypothesis Backlog
* Chaos Experiment
Wie funktioniert
Chaos Engineering
eigentlich?

28. Chaos Hypothesis
Backlog
1. Bilde System / Service
Architektur ab
2. Suche potentielle Fehlstellen
3. Stelle Hypothesen zum
Verhalten auf
A. (Fast) sicheres Wissen
B. Idee/Vermutung
4. Bewerten
A. Schaden
B. Wahrscheinlichkeit
Ergebnis: Backlog
—> Priorisieren
—> Pflegen/Aktualisieren
BacklogSystem Architektur Problem/
Experiment

29. Chaos Experiment
1. Wähle Hypothese aus Backlog
2. Starte mit stabilem System
3. Erzeuge Fehlerfall
4. Vergleiche Hypothese mit
gemessener Systemreaktion
5. Ziehe Konsequenzen aus dem
Ergebnis
A. Code/Konfiguration/
Architektur
B. Automatisieren
C. Betriebshandbuch
D. Nihil
http://principlesofchaos.org

30. Chaos Experiment
1. Wähle Hypothese aus Backlog
2. Starte mit stabilem System
3. Erzeuge Fehlerfall
4. Vergleiche Hypothese mit
gemessener Systemreaktion
5. Ziehe Konsequenzen aus dem
Ergebnis
A. Code/Konfiguration/
Architektur
B. Automatisieren
C. Betriebshandbuch
D. Nihil
http://principlesofchaos.org
[Muss natürlich
vorbereitet und
kommuniziert werden]

31. Wie kann man
Chaos Engineering
trainieren?

32. Wie kann man
Chaos Engineering
trainieren?
Wie funktionieren Katas bei DevOps?

33. Tools kennen und anwenden
• Git
• Jenkins, Gitlab
• Docker
• Kubernetes
• Puppet, Chef, Ansible …
Verändere eine einzelne Codezeile
• mit sichtbarem Output in App
• die nur einmal ausgeführt wird
• in potentiellem Performance
Bottleneck
• in Infrastruktur-Automation
und deploye die Änderung
DevOps Kata

34. Tools kennen und anwenden
• Git
• Jenkins, Gitlab
• Docker
• Kubernetes
• Puppet, Chef, Ansible …
Verändere eine einzelne Codezeile
• mit sichtbarem Output in App
• die nur einmal ausgeführt wird
• in potentiellem Performance
Bottleneck
• in Infrastruktur-Automation
und deploye die Änderung
DevOps Kata
Kenne deine Tools
Kenne deine Umgebungen

35. Tools kennen und anwenden
• Git
• Jenkins, Gitlab
• Docker
• Kubernetes
• Puppet, Chef, Ansible …
Verändere eine einzelne Codezeile
• mit sichtbarem Output in App
• die nur einmal ausgeführt wird
• in potentiellem Performance
Bottleneck
• in Infrastruktur-Automation
und deploye die Änderung
DevOps Kata
Kenne deine Tools
Kenne deine Umgebungen
Experimente?
Experimente in der Organisation?
(Adversarial) Game day

36. Katas
* Organisation
* IT-System
* (Prozesse)
Wie kann man
Chaos Engineering
trainieren?

37. (Adversarial) Game Day
Ein Experiment zu einer Zeit an
einem Ort
1. Ziel definieren
Welches Ergebnis wird erwartet?
2. Experiment vorbereiten
Umgebung, Test(s) vorbereiten
Rollen/Aufgaben verteilen
3. Zeitpunkt/Ziel kommunizieren!
4. Experiment durchführen
Annahmen validieren
5. Auswerten
6. Maßnahmen definieren
Chaos Kata
Experiment in der Organisation
* DevOps Team
* Bad Guy
* IT Operations?
* Andere Beteiligte?

38. (Adversarial) Game Day
Ein Experiment zu einer Zeit an
einem Ort
1. Ziel definieren
Welches Ergebnis wird erwartet?
2. Experiment vorbereiten
Umgebung, Test(s) vorbereiten
Rollen/Aufgaben verteilen
3. Zeitpunkt/Ziel kommunizieren!
4. Experiment durchführen
Annahmen validieren
5. Auswerten
6. Maßnahmen definieren
Chaos Kata
[Wie hat das Team agiert?
War die Auswirkung des Experiments
überhaupt sichtbar?]
Experiment in der Organisation
* DevOps Team
* Bad Guy
* IT Operations?
* Andere Beteiligte?

39. Katas
* Organisation
* IT-System
* (Prozesse)
Wie kann man
Chaos Engineering
trainieren?

40. Chaos Paranoia Was kann schon schiefgehen?

41. Experiment: Adressservice unter
Hochlast
Webservice zur Gültigkeitsprüfung
von Adressen …
Ziel: 10.000 Service-Anfragen pro
Sekunde per Lasttreiber über API-
Gateway; 30 Sekunden lang
Scope: Einzelne Instanz, Pre-
Production
Erwartungshaltung:
Service verarbeitet Last ohne
Fehler 503 (unavailable) zurück
zuliefern
Anfragen an DataStore werden zu
über 95% aus Cache beantwortet
Gestiegene Last ist per
Monitoring deutlich sichtbar
Chaos Kata Beispiel
Experiment am Code (Service)

42. Experiment: Adressservice unter
Hochlast
Webservice zur Gültigkeitsprüfung
von Adressen …
Ergebnis:
Service liefert in den ersten
sechs Sekunden 23.938 mal 503
(unavailable)
Anfragen an DataStore in den
ersten sechs Sekunden zu 42.3%
aus Cache beantwortet
Gestiegene Last in den ersten
sechs Sekunden per Monitoring
deutlich sichtbar (Lastanstieg
gegenüber Normal: 452%)
Chaos Kata Beispiel
Experiment am Code (Service)

43. Experiment: Adressservice unter
Hochlast
Webservice zur Gültigkeitsprüfung
von Adressen …
Ergebnis:
Service liefert in den ersten
sechs Sekunden 23.938 mal 503
(unavailable)
Anfragen an DataStore in den
ersten sechs Sekunden zu 42.3%
aus Cache beantwortet
Gestiegene Last in den ersten
sechs Sekunden per Monitoring
deutlich sichtbar (Lastanstieg
gegenüber Normal: 452%)
API-Gateway nach sechs Sekunden
abgestürzt; innerhalb der
verbleibenden 24 Sekunden nicht
wieder verfügbar
Automatischer Neustart des API-
Gateway 42 Sekunden nach Absturz
Experiment am Code (Service)
Chaos Kata Beispiel

44. Experiment: Adressservice unter
Hochlast
Webservice zur Gültigkeitsprüfung
von Adressen …
Maßnahmen:
Pufferungs-Strategie für
Adressservice prüfen
Caching-Strategie DataStore
prüfen
Backup-Strategie API-Gateway
untersuchen
Wiederanlaufdauer API-Gateway
Instanz prüfen
Automatisierung des Experiments
für CI prüfen
Experiment am Code (Service)
Chaos Kata Beispiel

45. Experiment: Adressservice unter
Hochlast
Webservice zur Gültigkeitsprüfung
von Adressen …
Maßnahmen:
Pufferungs-Strategie für
Adressservice prüfen
Caching-Strategie DataStore
prüfen
Backup-Strategie API-Gateway
untersuchen
Wiederanlaufdauer API-Gateway
Instanz prüfen
Automatisierung des Experiments
für CI prüfen
Experiment am Code (Service)
Maßnahmen priorisieren und einzeln
prüfen
Lösungen einzeln umsetzen
Experiment mit Einzellösung wiederholen
<— Kata
Chaos Kata Beispiel

46. Chaos Kata gewöhnen uns an echte
Incidents
Headless Chicken Mode bleibt aus
Zusammenarbeit zwischen
Beteiligten ist erprobt
Wissen, wo man hinschauen muss
Erfahrung ermöglicht schnellen
Wechsel in Lösungsmodus
Chaos Kata

47. Kata planen und durchführen
Gemeinsam planen -> paralleles
Schrauben vermeiden
Regelmäßig durchführen (z.B.
wöchentlich zur selben Zeit)
Kurze Durchführungsdauer
(Sekunden bzw. Minuten)
Vorbereitung/Auswertung dauert
natürlich länger
Umgebung und Fokus vorher
kommunizieren
Chaos Kata

48. Chaos Paranoia Muss das alles geprüft werden?

49. Chaos Paranoia Muss das alles geprüft werden?
1. Risikobewertung
2. Priorisierung
<— gehört bereits zum Chaos Hypothesis Backlog

50. Freitag: Projektorganisation final
verlassen
Folgender Montag:
* Build-Pipeline läuft nicht mehr
* Services in Produktion laufen
nicht mehr
* Services in Produktion nicht
mehr startbar
?
Neulich …

51. Freitag: Projektorganisation final
verlassen
Folgender Montag:
* Build-Pipeline läuft nicht mehr
* Services in Produktion laufen
nicht mehr
* Services in Produktion nicht
mehr startbar
* Mein Benutzer-Account wurde am
Freitag gelöscht
* Build-Pipeline und Services
liefen unter meinem Benutzer-
Account
* automatischer Neustart der
Produktion am Wochenende
Neulich …

52. Freitag: Projektorganisation final
verlassen
Folgender Montag:
* Build-Pipeline läuft nicht mehr
* Services in Produktion laufen
nicht mehr
* Services in Produktion nicht
mehr startbar
* Mein Benutzer-Account wurde am
Freitag gelöscht
* Build-Pipeline und Services
liefen unter meinem Benutzer-
Account
* automatischer Neustart der
Produktion am Wochenende
Servicebenutzer-Account war aus
Sicherheitsgründen abgelehnt
worden
Neulich …

53. Freitag: Projektorganisation final
verlassen
Folgender Montag:
* Build-Pipeline läuft nicht mehr
* Services in Produktion laufen
nicht mehr
* Services in Produktion nicht
mehr startbar
* Mein Benutzer-Account wurde am
Freitag gelöscht
* Build-Pipeline und Services
liefen unter meinem Benutzer-
Account
* automatischer Neustart der
Produktion am Wochenende
Servicebenutzer-Account war aus
Sicherheitsgründen abgelehnt
worden
Super Kata-Idee!
Neulich …

54. https://www.gremlin.com/
https://github.com/Netflix/
chaosmonkey
https://github.com/codecentric/
chaos-monkey-spring-boot
https://chaostoolkit.org/
https://byteman.jboss.org/
https://github.com/Optum/ChaoSlingr https://github.com/chaosblade-io
https://github.com/linki/chaoskube
https://github.com/alexei-led/pumba
https://github.com/bloomberg/powerfulseal
http://wiremock.org/
https://github.com/mefellows/muxy/
https://github.com/lucky-sideburn/
KubeInvaders
https://github.com/xmatters/
cthulhu-chaos-testing
https://github.com/Shopify/toxiproxyhttps://github.com/osrg/namazu
Chaos
Engineering
Tools

55. Nach einem Chaos Experiment
ist man immer schlauer und
kann besser erklären, warum
der Fehler auftreten musste
…
auch wenn der aufgetretene
Fehler nicht erwartet wurde
Vielen Dank
Chaos Engineering