Wer will schon Chaos?

Java Magazin 3.19 erschienen: Chaos Engineering – Reise zur unverwüstlichen Software

Sebastian Meyen

„Chaos“ klingt ja nach etwas, das wirklich keiner will oder brauchen kann. Und da kommen schon die Software-Hipster und predigen das neue „Chaos Engineering“ … Chaos zu stiften ist jedoch weder Zweck noch Ziel, sondern ein Mittel, komplexe Systeme in kontrollierter Art und Weise auf Herz und Nieren zu testen.

Einen solchen Ansatz benötigen wir noch nicht unbedingt, wenn wir es mit Systemen zu tun haben, die im klassischen Sinn „kompliziert“ sind. Solche Systeme zeichnen sich dadurch aus, dass es bei Ereignissen klare Ursache-Wirkung-Relationen zu erkennen gibt, die man analysieren, dokumentieren und vorhersagen kann. Bei „komplexer“ Software ist davon auszugehen, dass Fachleute deren innere Mechanismen hinreichend kennen und im Idealfall Fehler komplett vermeiden.

Geht in einem solchen Umfeld doch mal etwas schief, ist dies auf menschliche Fehler, mangelhafte Dokumentation oder etwa die Unübersichtlichkeit des Systems zurückzuführen. Die klassische Optimierungsstrategie lautet meistens: Kontrolle erhöhen, damit bekommt man schon alles in den Griff.

Komplexe Systeme hingegen sind solche, bei denen die Beziehung zwischen Ursache und Wirkung von Ereignissen nur im Nachhinein und auch nicht mit absoluter Sicherheit wahrgenommen werden kann.

In solchen Umgebungen ist nicht Fehlerfreiheit die Königstugend der Softwareentwickler, sondern die sog. Mean Time to Recover (MTTR). In anderen Worten: Das Auftreten eines Fehlers bedeutet keinen Skandal, den es zu vermeiden gilt; Fehler gehören vielmehr zum normalen Gang der Dinge, und es kommt darauf an, ob wir in der Lage sind, schnell zu analysieren und ebenso schnell pragmatische Lösungen für deren Behebung umzusetzen.

Warum man also an komplexe Systeme herangehen und mit einer klaren Hypothese ausgestattet Durcheinander stiften sollte, erfahren Sie im ersten Teil des von Sebastian Wilms verfassten Titelthemas dieser Ausgabe (Seite 58). Im zweiten Teil geht der Autor dann auf konkrete Werkzeuge und Vorgehensweisen für erste konstruktive Chaos-Experimente ein (Seite 66).

Bemerkenswert an dem Thema ist, dass es nicht nur darum geht, komplexe technische Abhängigkeitsstrukturen ausfindig zu machen und für den Fehlerfall frühzeitig Reparaturstrategien zu entwickeln, sondern auch um den menschlichen Faktor.

In diesem Sinne ließe sich Chaos Engineering mit einer Feuerwehrübung oder anderen Notfallszenarien in der analogen Welt vergleichen: Selbst wenn alle Prozesse bis ins Kleinste definiert, selbst wenn alle Rollen umfassend erprobt und klar zugewiesen sind – erst im Zusammenspiel aller Faktoren und unter simulierten Realbedingungen beginnt man zu verstehen, was sich wirklich in einem komplexen System ereignet.

Verwandte Themen:

Geschrieben von
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu: