© good_mood/Shutterstock.com
Chaos Engineering Teil I

Auf der Reise zu unverwüstlicher Software


Seid ihr nicht auch genervt von Prio-1-Tickets an einem Freitagnachmittag? Sucht ihr nach einem Weg, der es euch ermöglicht, das Zusammenspiel all eurer Services und der Plattform, auf der sie betrieben werden, besser zu verstehen? Dann ist Chaos Engineering der richtige Ansatz, der euch helfen kann, eure Applikationen und deren Betrieb zu verbessern!

Als Entwickler, als Architekt und in jeder anderen Rolle, die in den Prozess der Erstellung und beim Betrieb einer neuen Software involviert ist, verfolgen wir gemeinsam ein Ziel, nämlich den schönsten Ort der Welt zu erreichen: die Produktion.

Wie im echten Leben planen wir unseren Aufenthalt mit viel Bedacht. Die Entwickler sichern die Implementierung der fachlichen Anforderungen mit unzähligen Unit- und Integrationstests ab. Der Architekt verfolgt mit großer Begeisterung die Umsetzung seiner über Wochen gereiften Architektur und hofft, dass die geplanten Resilience-Patterns wie vorgesehen implementiert werden.

Manche von uns dürfen und können diesen schönsten Ort jederzeit besuchen, andere konnten oder durften noch keine Continuous-Integration- und Continuous-Deployment-Pipeline aufbauen. Daher erreichen sie die Produktion unter Umständen nur zweimal im Jahr. Was uns aber alle verbindet, ist das ungute Gefühl kurz vor dem Release in Produktion.

Denn die Produktion kann auch ein Biest sein: Schnell kommt in uns das Gefühl auf, dass sie uns hasst und wirklich alles unternimmt, um uns den Aufenthalt zur Hölle zu machen. Dann befinden wir uns im „Cycle of dying Apps“ (Abb. 1), den unser Baby oder wir durchleben.

wilms_chaosengineering1_1.tif_fmt1.jpgAbb. 1: Der Cycle of Death

Voller Enthusiasmus setzen wir zunächst neue Features um oder beseitigen Bugs. All unsere Tests laufen erfolgreich durch, und dank der CI/CD-Pipeline schaffen wir es auch kontinuierlich in Produktion. Dort angekommen verfolgen wir gespannt den Start unserer Applikation. Da wir nun aufgrund der hohen Automatisierung etwas Zeit haben, beginnen wir, uns mit den üblichen Fragen zu quälen:

  • Startet meine Applikation mit der richtigen Konfiguration?

  • Meldet sie sich korrekt bei der Service Discovery?

  • Wird sie von allen anderen über die Service Discovery gefunden?

  • Wo ist die Datenbank?

  • Circuit-Breaker-Pattern, check! Sind die Fallbacks valide und funktionieren sie im Ernstfall?

Die Liste an Fragen ist schier endlos, doch zum Glück ist die Ramp-up Time nicht allzu lang. Mit einem lauten Knall und einem gar unendlichen Stacktrace werden wir aus unseren Gedanken gerissen. Hektisch beginnen wir mit der Fehlersuche und versuchen es gleich noch einmal. Der nun kommende Knall ist lauter als zuvor und nicht nur unsere Applikation ist down. Wir sind gefangen im Cycle of dying Apps! Ob die nun notwendige Post-Mortem-Analyse eure Applikation oder die Überreste des Entwicklers in den Blick nimmt, überlasse ich euch.

„You don't choose the moment, the moment chooses you! You only choose how prepared you are when it does“ (Fire Chief Mike Burtch).

In den heutigen State-of-the-Art-Architekturen ist es fast unmöglich, den Überblick zu behalten – und es gibt auch im Hause Netflix nicht viele Personen, die wissen, wie und warum Netflix funktioniert. Klar, wir sind nicht Netflix. Weder müssen wir so skalieren noch müssen wir so schnell sein und über 1 000 Deployments am Tag in Produktion bringen. Außerdem sind wir nicht gezwungen, in die gleichen Probleme wie Netflix zu laufen, sondern können aus den Fehlern und Erfahrungen des Unternehmens lernen.

Das war für mich einer der Gründe, mich näher mit dem Thema Chaos Engineering zu beschäftigen. In den vergangenen Jahren durfte ich in vielen Projekten mitarbeiten, die das Ziel hatten, eine verteilte und skalierbare Applikation zu erstellen und zu betreiben. Wir bedienten uns dabei zahlreicher Patterns aus dem Baukasten des Resilient-Software-Designs. Dabei war es uns wichtig, die richtigen Patterns zu finden und anzuwenden.

Die Implementierung ging dank zahlreicher Open-Source-Frameworks wie Hystrix [1] aus dem Hause Netflix, Resilience4j [2] oder failsafe [3] einfach von der Hand. Zudem baute unsere Applikation auf dem Spring-Boot-Framework [4] auf, und wir nutzten Spring Cloud [5].

Dennoch hatten wir dieses ungute Gefühl. Zwar war alles gut durchdacht, mit Unit- und Integrationstests getestet und unsere Code Coverage lag bei 80 bis 90 Prozent. Aber keiner von uns hatte die eingesetzten Patterns jemals in Aktion gesehen, geschweige denn sie explizit herausgefordert. So kam ich zum Thema Chaos Engineering: Ich begann, die Applikationen detaillierter zu testen, und führte Grenzsituationen gezielt und immer unter Kontrolle herbei.

Chaos Engineering History

Chaos Engineering wird in anderen Bereichen schon deutlich länger betrieben. Versetzt euch einmal in die Lage eines Piloten, der mit Mach 3 über den Atlantik fliegt. Plötzlich hat er mit Ausfällen oder sporadischen Fehlern zu kämpfen, während die Basis ihm mitteilt, sich eigentlich sicher zu sein, alle Features korrekt implementiert zu haben. Dummerweise haben sie dabei rechts und links vertauscht!

Netflix ist einer der Kerntreiber von Chaos Engineering. Wieso? 2010 beschloss Netflix die Migration all seiner Systeme vom Monolithen in die Cloud. Erst 2016 waren wirklich alle Systeme zu AWS migriert und Netflix unterhielt keine eigenen Rechenzentren mehr.

In diesem neuen Umfeld kam es in unregelmäßigen Abständen zu Ausfällen. Einzelne Instanzen in AWS stoppten oder wurden automatisch ersetzt. Damit mussten die Services umgehen können – und das natürlich nicht erst dann, wenn es die Kollegen an einem Freitagnachmittag um 16 Uhr bemerkten.

Ein Umdenken musste her, um mit den in Produktion sporadisch auftretenden Ereignissen besser umgehen zu können. Ausfälle, längere Latenzen und Fehler mussten häufiger und kontrollierter auftreten.

Was dabei den Services und insbesondere dem damaligen Leiter des Chaos-Engineering-Bereichs bei Netflix bewusst war, ist, dass man aus jedem Ausfall oder jeder Störung lernen kann. Fehler in der Software sind etwas Gutes, das die Grundlage für eine Verbesserung sein kann.

„Never let an outage go to waste“ (Casey Rosenthal). Diese Erkenntnis führte zur Geburt des Chaos Monkeys [6] bei Netflix. Der Chaos Monkey beendet zufällig Instanzen und Container virtueller Maschinen, die innerhalb einer Produktionsumgebung ausgeführt werde...

Neugierig geworden?

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang