Nassim Nicholas Taleb hat mit Antifragilität (2012) einen Begriff geprägt, der eine Lücke in unserer Sprache geschlossen hat: Wir wissen etwas mit zerbrechlich oder fragil etwas anzufangen, ebenso mit robust oder resilient. Die Zuschreibung einer Eigenschaft, die von Fehlern, Instabilität oder gar Zerstörungsabsicht profitiert, hatte er nicht gefunden. Dabei ist das Konzept lange bekannt: Aus der griechischen Mythologie kennen wir die Hydra , deren Köpfe nachwachsen, wenn sie abgeschlagen werden.
Taleb führt weitere, ganz reale Analogien aus der Biologie an: Das menschliche Immunsystem oder biologische Puffer, die nicht nur Attacken wegstecken, sondern ihre Wirkung danach sogar verstärken. Es gibt sicher Grenzen, aber die Idealwelt sieht eine Skala vor, bei der robust im natürlichen Nullpunkt liegt. Das Maß der Zerbrechlichkeit liegt links davon. Neu ist die Skala auf der rechten Seite, die angibt, wie ein System sich verbessern kann.
Bei der Hydra mag die Antifragilität nicht skalieren; irgendwann erreicht die Anzahl der Köpfe ein unpraktisches Ausmaß. Schlagen wir dagegen den Bogen zur Systemarchitektur, IT-Sicherheit und Softwareentwicklung. Immer wieder werden Plattformen und Computerprogramme attackiert, im besten Fall durch Sicherheitsforscher, im schlechtesten durch gut ausgerüstete und begabte kriminelle Banden.
Wir finden in Organisationen folgende Muster im Umgang mit Fragilität:
- Risiken aus dem Weg gehen und sie “managen” – Ein Beispiel ist Risikomanagement nach ITIL. Dabei wird die Verantwortung an Gremien delegiert (und damit diffundiert). Man hofft, mit Verlangsamung und Governance auf das Ausbleiben der großen Katastrophen zu erreichen. Tritt diese dann allerdings doch ein, sind die Folgen meist sehr schmerzlich und oft irreversibel.
- Systeme robust gestalten – Die Paradedisziplin der Ingenieurskunst versucht durch Ausbildung und Awareness die üblichen Fehlerquellen zu vermeiden.
- Chaos Engineering einführen – Dabei werden Fehler bewusst und kontrolliert herbeigeführt, um Schwachstellen zu finden, bevor es die Umgebung tut.
Der Trugschluss der künstlichen Stabilität
Hier liegt eine der unbequemsten Implikationen für Systemarchitekten: Übertriebene Stabilisierung erzeugt versteckte Fragilität. Taleb nennt das das Fragilisierungsproblem durch Eingriff. Ein System, das nie Störungen ausgesetzt wird, akkumuliert unsichtbare Risiken. Die Ausfallpfade rosten zu, das Operations-Team verlernt den Umgang mit Krisen, Abhängigkeiten wachsen unkontrolliert weil niemand testet, ob sie wegbrechen können. Das klingt abstrakt, ist es aber nicht. Wer schon einmal ein System nach drei Jahren “stabiler” Produktionszeit in einer ungeplanten Katastrophe gesehen hat, erkennt das Muster sofort: Alle Runbooks sind veraltet. Der On-Call kennt die Infrastruktur nur aus Diagrammen. Die Konsequenz ist radikal: Stabilität, die nie geprobt wird, ist eine Illusion.
Vorhersagen sind schwierig, vor allem, wenn sie die Zukunft betreffen. – Niels Bohr
Chaos Engineering: Antifragilität als Praxis
Genau hier schließt Chaos Engineering an: Der Begriff wurde bei Netflix geprägt, konkretisiert in den Principles of Chaos Engineering (2019). Die Grundidee: Wenn Fehler in Produktion unvermeidlich sind, dann ist kontrolliertes Einführen von Fehlern besser als darauf zu warten, dass sie unkontrolliert auftreten. Das ist Antifragilität als Engineering-Disziplin. Der Ablauf kann wie folgt aussehen:
- Steady State definieren Was ist normales Systemverhalten? Latenz, Fehlerrate, Durchsatz. Ohne Baseline keine Aussage.
- Hypothese formulieren “Wenn wir Availability Zone B verlieren, übernimmt der Load Balancer innerhalb von 30 Sekunden, ohne dass Endnutzer Fehler sehen.”
- Experiment durchführen Blast Radius klein halten. Beginne mit Staging, gehe in Production nur wenn du verstehst, was du tust.
- Beobachten Nicht raten. Messen. Vergleich gegen Steady State.
- Lernen und ändern Das Experiment hat nur Wert, wenn es eine Konsequenz hat: ein gefixter Fehler, ein verbessertes Runbook, eine geänderte Architekturentscheidung.
Chaos Engineering ist kein organisiertes Vandalismus. Es ist wissenschaftliche Methodik angewendet auf Produktionssysteme. Der Unterschied liegt im Hypothesen-getriebenen Vorgehen. Wer einfach zufällig Services killt, lernt nichts Strukturiertes. Wer vorher eine präzise Hypothese aufstellt und dann misst, ob sie stimmt, betreibt echtes Engineering. Und darin liegt auch die Verbindung zu Talebs Denken auf der architekturellen Ebene:
- Kleine, häufige Störungen sind besser als große, seltene. Wer regelmäßig einen Pod neustartet, lernt mehr als wer einmal im Jahr einen Datacenter-Failover übt.
- Dezentralisierung reduziert Korrelation zwischen Ausfällen. Microservices, die unabhängig ausfallen können, sind antifragiler als ein Monolith — vorausgesetzt, die Blast-Radius-Isolation funktioniert.
- Optionalität — Talebs Lieblingskonzept — bedeutet in Systemarchitektur: Mehrere Deployment-Strategien, mehrere Cloud-Regionen, mehrere Datenbankfallbacks. Nicht alles auf einmal, aber die Option muss existieren und getestet sein.
Fazit
Chaos Engineering ist keine Lizenz zum Zerstören — es ist die Disziplin, Systeme durch kontrollierte Störungen klüger zu machen. Antifragilität entsteht nicht durch mehr Schutz, sondern durch besseres Lernen. Wer Fehler systematisch herbeiführt, bevor die Umgebung es tut, behält die Initiative. Das Ziel ist kein System, das nie ausfällt — das ist Illusion. Das Ziel ist ein System, das nach jedem Ausfall ein bisschen besser ist als vorher.
In diesem Sinne: Bitte werfen!
Quellen und Links
- Antifragilität von Nassim Nicholas Taleb
- Chaos Engineering
Kommentare