Macht kaputt was Euch kaputt macht - Failure Patterns in Tests

Kaum ein aktuelles Software-System ist in der heutigen Zeit kein verteiltes System mehr: Als Software-Entwickler programmieren wir mittlerweile Cloud-native, Event-Driven, API-Driven und Microservice-orientated, und nutzen dafür SaaS-, PaaS- und FaaS- Produkte. Doch verteilte Systeme bringen auch andere Resilienz-Paradigmen und -Notwendigkeiten mit sich, die nicht immer adressiert werden.

Dieser Talk beleuchtet kurz das gesamte Thema Resilienz in verteilten Systemen, um sich dann spezifischer auf die Notwendigkeit zu fokussieren, unsere guten alten Entwicklertests neu zu denken.

Transcript

1. Macht kaputt, was euch kaputt macht Failure Patterns in Tests
2. Vincent Fahrenholz PHP Developer @ idealo Internet GmbH vincent.fahrenholz@idealo.de fahrenholz @DrearyTown
3. Worum es heute NICHT geht - Infrastructure resilience - Simian army - Hystrix - Netflix - Microservices - SCS - Testen in Production - Chaos Engineering
4. In Production leben - Software lebt in Production - Erfüllt einen Zweck - Hat Auswirkungen - auf die Welt - auf die restliche Systemlandschaft
5. In Production leben - Auswirkungen - Resultat - Ressourcennutzung - Hardware - Verbindungen zu anderen Systemen - Menschen die den Betrieb sicherstellen - … - Potenzielle Ressourcenbindung - anfragende Systeme - Menschen
6. In Production leben Es ist vital für unsere Software, dass sie - Mit ihrer Welt klarkommt - Möglichst effizient mit dieser interagiert - Die Welt nicht ins Chaos treibt - Sich von der Welt nicht ins Chaos treiben lässt
7. Für Production designen - Welt kennen - Software verstehen - Tooling verstehen - Ressourcen verstehen - Die Augen öffnen
8. “A distributed system is one in which the failure of a computer you didn’t even know existed can render your own computer unusable” -- Leslie Lamport
9. “Everything fails, all the time” -- Werner Vogels
10. P(E) = P(a) ^ N
11. 99,8% Verfügbarkeit pro komponente, das sind... Anzahl Komponenten Wahrscheinlichkeit dass alles verfügbar ist 10 98,02% (=357D 18H 28M 48S) 100 81,86% (=298D 18H 57M 36S) 500 36,75% (=134D 3H 21M 36S) 1000 13,5% (=49D 6H 28M 47S) 2500 0,06% (=2D 4H 33M 36S)
12. “Das ist ja scheiße!” -- Vincent Fahrenholz
13. Für Production designen - Downtime == Geld - Latenz == Geld - Fehlerketten == Geld - Wartungsaufwand == Geld
14. Für Production designen - Früher - Robust systems - High availability cluster - “Never touch a running system” - Dev system === Stg System === Prod System - ...
15. Für Production designen - Früher - Robust systems - High availability cluster - “Never touch a running system” - Dev system === Stg System === Prod System - ...
16. Für Production designen - Früher - Robust systems - High availability cluster - “Never touch a running system” - Dev system === Stg System === Prod System - … Es ist nur ein Teil der Arbeit
17. Für Production designen - stabilize - Früher - Robust systems - High availability cluster - “Never touch a running system” - Dev system === Stg System === Prod System - … Es ist nur ein Teil der Arbeit
18. Für Production designen - Resilience Patterns - Bulkhead - Timeouts - Graceful recovery - Scale out - Retry - ...
19. Testen
20. TDD und Testen - TDD != Testen, da der Fokus auf der Entwicklung liegt Und auch ansonsten: - Happy Path meist getestet - Abweichungen meist weniger
21. “[...] every system will eventually end up operating out of spec; therefore, it’s vital to test the local system’s behaviour when the remote system goes wonky. Unless the designers of the remote system built in modes that simulate the whole range of out-of-spec failures that can occur naturally in production, there will be behaviours that integration testing does not verify.” -- Michael T. Nygard
22. “A better approach to [...] testing would be to [...] create test harnesses to emulate the remote system on the other end of each integration point. [...] A good test harness should be devious. It should be as nasty and vicious as real-world systems will be. The test harness should leave scars on the system under test. Its job is to make the system under test cynical. ” -- Michael T. Nygard
23. Testen Für Production designen heißt, die Antwort auf folgende Fragen kennen: - Macht die Software das, was sie machen soll? ⇒ TDD, Dev Tests - Macht die Software nicht das, was sie nicht machen soll? ⇒ Edge cases, error cases - Macht die Software nicht das, was unmöglich ist? - Reagiert die Software sinnvoll auf unvorhergesehene fehlerhafte Zustände?
24. Testen - Unit tests / Functional tests - Fehlerszenarien explizieren - Fehlerscopes explizieren - Fehlertoleranz testen - Timeouts - Circuit Breaker - Automatisierte Bereinigungen von Daten - Darstellung von Fehlern an Clients testen
25. Testen - Integration Tests - Gezielt Fehlerszenarien in Fremdsystemen erzeugen - System Mocks - Kontrollierte und beeinflussbare Test-Environments - Volatile Test-Environments
26. Fehlerquellen: Einige Ideen - Korrupte Daten - Nicht antwortende Systeme - Falsch formatierte Antworten - Authentication-Fehler - Bad-Request-Fehler - Server-Fehler - … - Zufallsgenerator?
27. tl;dr - Wir wissen nicht woher der Fehler kommen wird - … dementsprechend können wir nur sicherstellen, dass unsere Software sich so gut wie möglich davon erholt
28. tl;dr - Wir haben nicht die Möglichkeit, Systeme die uns nicht gehören zu beeinflussen - … dementsprechend können wir unsere eigenen Mocks dieser Systeme implementieren um unseres zu testen
29. tl;dr - Mögliche Fehler finden um sie durch einen Test abzusichern besteht größtenteils aus Heuristik - … umso wichtiger ist es, tatsächlich auftretende Fehlerszenarien festzuhalten
30. Einige Tools - Mayhem-Lib (PHP) - mockoon - mockable.io - Mocky
31. Vielen Dank ! Vincent Fahrenholz @DrearyTown vincent.fahrenholz@idealo.de https://www.gitlab.com/fahrenholz/mayhem
32. Referenzen & (Zusatz-)Literatur - Nygard, M. (2018) Release It! Design and deploy production-ready software (second edition). O’Reilly UK Ltd. - Friedrichsen, U. Patterns of resilience Um etwas weiter zu gehen: - Ein Twitter-Feed von Dan North über TDD (wo er sich, aber das ist nur Bonus, danach noch mit Ron Jeffries anlegt) - Ein Bugfix-Beispiel unter Anderen, das mit Integrationstests und beeinflussbarer Umgebung behoben wurde