© kirill_makarov/Shutterstock.com
Grundlagen, Prinzipien, Mehrwert und Praxis

Chaos Engineering bei der DB


Die Deutsche Bahn (DB) hat sich einer großen Herausforderung gestellt. Sie baut im laufenden Betrieb die komplette Vertriebsplattform neu. Dabei kommen moderne Technologien zur Anwendung wie etwa Microservices und Continuous Deployment. Conways Law berücksichtigend entsteht eine verteilte Systemlandschaft, in der fachliche Zuständigkeiten wie Ticket- oder Angebotserstellung klar verortet und fachlich separiert sind. Sie bietet die notwendige Flexibilität für eine kontinuierliche und zukunftsfähige Weiterentwicklung der Plattform.

Verteilte Systeme haben aber nicht nur Vorteile. Gerade die Schnittstellen zwischen den fachlichen Komponenten und der Einsatz von unterschiedlichen Technologien sind Komplexitätstreiber. Die technische Komplexität wird zusätzlich noch dadurch erweitert, dass eine hohe Anzahl von Entwicklungsteams mit unterschiedlichen Kulturen und Arbeitsweisen an diesen Komponenten arbeiten.

Gibt es ein probates Mittel, diese Komplexität beherrschbar zu machen? Wir haben uns dazu entschieden, Chaos Engineering in den Entwickleralltag zu integrieren. Das hilft uns, auf unvorhergesehene Ereignisse schneller reagieren zu können und das Vertrauen in unsere Systeme zu erhöhen – aus technischer und prozessualer Sicht.

Die Grundlagen, Prinzipien und der Mehrwert von Chaos Engineering werden in diesem Artikel vorgestellt. Auch ein Einblick in die Voraussetzungen für einen gelungenen Start wird hier gegeben. Praxisnahe Beispiele zeigen auf, wie Chaos-Experimente strukturiert und durchgeführt werden können.

Die Geschichte eines Ausfalls

An einem Freitagabend um 18 Uhr war es so weit: Durch eine ungünstige Kombination von Konfigurationsfehlern und Softwarebugs schaukelten sich kleine Ursachen zu großen Auswirkungen hoch. Die brandneue, Microservices-basierte Betaapplikation geriet in Schieflage – Totalausfall!

Es dauerte einige Zeit, um die spezifischen Auswirkungen im Monitoring richtig zu interpretieren. Glück im Unglück: Die Entwicklerteams der betroffenen Services waren noch erreichbar, und gemeinsam mit dem Betrieb konnten der Crash Loop durchbrochen und die Services wiederbelebt werden. Der Beginn des Wochenendes verzögerte sich, erst Stunden später war die Applikation wieder erreichbar – und das, während im Fernsehen eine Werbekampagne für genau diese Applikation lief.

Im anschließenden Post Mortem wurde klar, wie komplex der Ausfall war. Erst Tage später waren alle technischen Details bekannt und analysiert. Die folgende Reproduktion der Ereignisse in einer Testumgebung gab Gewissheit darüber, dass die korrekten Annahmen über die Ursache getroffen worden waren.

So ein Ausfall zieht besondere Aufmerksamkeit auf sich, verbunden mit teilweise unangenehmen Fragestellungen. Eine Kernfrage war: Warum hatte die Armada der riesigen Testabdeckung aus automatisierten Unit-Tests, Integrationstests, Ende-zu-Ende-Tests, manuellen explorativen Tests, technischen Abnahmetests und mehr den Ausfall nicht verhindert? Eine schwierig zu beantwortende Frage, da die Ursache nicht in den exakt deterministisch reproduzierbaren Abläufen einzelner Komponenten zu finden war, sondern im chaotischen Verhalten eines komplexen verteilten Systems. Die Erkenntnis: In einem solchen Szenario greifen die Sicherheitsmechanismen der etablierten Stufen der Qualitätssicherung nur bedingt, es existiert darin eine Lücke. Um zu verstehen, wie diese entstehen konnte und welche potenziellen Methoden zum Schließen eben dieser Lücke existieren, lohnt sich ein Blick auf die theoretischen Hintergründe.

Cycle of Death

Gewollt und ungewollt werden heutige IT-Landschaften immer komplexer und die Beherrschbarkeit dieser Komplexität wird zunehmend schwieriger. Die Gründe dafür sind vielfältig. Komplexere Geschäftsprozesse, die modelliert werden müssen, steigende Benutzeranforderungen an die IT-Systeme, aber auch das Bedürfnis, die IT immer schneller an sich ändernde Bedingungen anpassen zu können. Durch die steigende technische Komplexität, die oft durch nichtfunktionale Anforderungen verursacht wird, steigt auch die Komplexität unserer Organisationssysteme, die die Softwareentwicklung steuern müssen. Zu dieser gewollten Komplexität kommt noch ungewollte Komplexität, die wir nicht zur Erreichung unserer Ziele brauchen, aber aufgrund von mangelnden Informationen und Wissen unwissend in unsere Systeme aufnehmen [1]. Gewollte und ungewollte Komplexität lässt sich zwar minimieren, aber nicht gänzlich vermeiden. Das bedeutet, wir müssen lernen, besser mit Komplexität umzugehen.

Die meisten Entwickler arbeiten heute mit und in komplexen Systemen, wie zum Beispiel hochverfügbaren und verteilten Systemen auf der Basis von Microservices. In solchen Systemen ist es unvermeidlich, dass wir uns manchmal überfordert fühlen, Abstimmungsprozesse schwerfallen, und man als Einzelner nur einen Bruchteil des Gesamtsystems versteht. Durch die hohe Komplexität wird es immer schwieriger, bei Änderungen an alle Auswirkungen zu denken. Im Nachgang neuer Deployments treten dann Fehler auf, mit denen wir nicht gerechnet haben, und dann müssen die Teams zum „Feuerlöschen“ ausrücken. Nach einem Post-Mortem-Meeting bleibt dann wenig Zeit, um Findings abzuarbeiten, denn die nächsten Features stehen bereits an. So wird aus dem Cycle of Deployment (Abb. 1) oft ein Cycle of Death (Abb. 2). Chaos Engineering verringert die Wahrscheinlichkeit eines Brandes und steigert gleichzeitig unsere Fähigkeit, Brände schnell und effizient zu löschen.

vordemberge_figura_kracht_chaos_1.tif_fmt1.jpgAbb. 1: Cycle of Deployment
vordemberge_figura_kracht_chaos_2.tif_fmt1.jpgAbb. 2: Cycle of Death

Die Unbeherrschbarkeit komplexer Systeme

Chaos Engineering als geeignete Herangehensweise für Software- und Organisationsprobleme zu verstehen, bedeutet, einen Blick in die theoretischen Grundlagen komplexer Systeme und deren Eigenschaften zu werfen [2].

Vier Eigenschaften gelten sowohl für technische Systeme als auch für Organisationssysteme (soziale Systeme):

Nichtlinearität: In komplexen Systemen passieren Events gleichzeitig. Input und Output eines solchen Systems verhalten sich nicht proportional zueinander. Darunter leidet die Nachvollziehbarkeit. Nichtlinearität führt zu spontan auftretendem Chaos und Verhaltensweisen im System selbst. Für Softwaresysteme heißt das, dass kleine Störungen im System zu großen, systemweiten Fehlern führen können. Das wird durch sich verstärkende Feedbackschleifen oft noch weiter verstärkt. Kaskadierende Fehler, die ein System komplett lahmlegen, sind die Folge.

Emergenz: Emergenz beschreibt das spontane und plötzliche Auftauchen von Events und anderen Verhaltensweisen, die be...

Neugierig geworden? Wir haben diese Angebote für dich:

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