Mein Vortrag auf dem JUG Saxony Day am 13.09. 2019 zum Thema Chaos Engineering

1. Chaos
Kata
Fitnesstraining
für DevOps Teams
Ramon Anger
flexis AG
Radebeul, 13.09.2019

2. Coder?
DevOps?
Chaos Engineering?
Chaos Kata?

3. http://www.peakpx.com/590485/brown-coffee-sack, gemeinfrei
Seit 1996 Java Entwickler
Grundnahrungsmittel -> natürlich
Kaffee

4. Früher. Ganz früher
wurden Release gemalt
1-2 Releases pro Jahr
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
Und das in deutlich
komplexeren Systemen

7. Was heißt Komplexere
Systeme?
eBay: 1000+ Microservices
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

8. Wie gehen die großen Player
mit Ausfällen um?
Gibt es da ü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! Werner Vogels (CTO Amazon):
… Everything fails all the
time.
We lose whole datacenters!
Those things happen…
Und warum?

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. Wie kann man
Chaos
Engineering
trainieren?

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

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

27. 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

28. 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

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
[Muss natürlich
vorbereitet und
kommuniziert werden]

30. Wie kann man
Chaos
Engineering
trainieren?

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

32. 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

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
Kenne deine Tools
Kenne deine Umgebung

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 Umgebung
Experimente?
Experimente in der Organisation?

35. Katas
* Organisation
* IT-System
Wie kann man
Chaos
Engineering
trainieren?

36. 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
https://de.slideshare.net/BilalAybar/chaos-engineering-gameday-on-aws
Experiment in der Organisation
* DevOps Team
* Bad Guy
* IT Operations?
* Andere Beteiligte?

37. 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
https://de.slideshare.net/BilalAybar/chaos-engineering-gameday-on-aws
[Wie hat das Team agiert?
War die Auswirkung überhaupt
sichtbar?]
Experiment in der Organisation
* DevOps Team
* Bad Guy
* IT Operations?
* Andere Beteiligte?

38. Katas
* Organisation
* IT-System
Wie kann man
Chaos
Engineering
trainieren?

39. Chaos Paranoia Was kann schon schiefgehen?

40. 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
Experiment am Code (Service)

41. Experiment: Adressservice unter
Hochlast
Webservice zur Gültigkeitsprüfung
von Adressen …
Ergebnis:
Service liefert in den ersten
sechs Sekunden 23.938 mal 503
(unavailable) zurück
Anfragen an DataStore wurden 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
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) zurück
Anfragen an DataStore wurden 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
Chaos Kata
Experiment am Code (Service)

43. 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
Chaos Kata
Experiment am Code (Service)

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
Chaos Kata
Experiment am Code (Service)
Maßnahmen priorisieren und
einzeln prüfen
Lösungen einzeln umsetzen
Experiment mit Einzellösung
wiederholen
<— Kata

45. Chaos Kata gewöhnen uns an
potentielle 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
Experiment am Code (Service)

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

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

49. Smyte Acquisition by Twitter
on 21.06.2018
San Francisco-based startup
that provides companies with
tools to alleviate trolling,
spam, harassment and improve
security
… A vendor notified us of
their acquisition at 6am
this morning and shut down
their APIs 30 minutes later,
creating a production outage
for npm (package publishes
and user registrations) …
… it appears that some
customers have been shut out
of smyte's API immediately,
without prior warning

50. 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
Liste potentieller Tool-Quellen: https://github.com/dastergon/awesome-chaos-engineering

51. 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
https://medium.com/netflix-techblog/
chap-chaos-automation-platform-53e6d528371f
Chaos
Engineering
Tools
Liste potentieller Tool-Quellen: https://github.com/dastergon/awesome-chaos-engineering

52. Nach einem Chaos Experiment
ist man immer schlauer und
kann besser erklären, warum
der Fehler auftreten musste.
Vielen Dank
Chaos
Engineering