Chaos Engineering in der Produktion hat ein klares Problem: Die vorhandenen Werkzeuge sind exzellent im Sicherheitsmanagement, aber nahezu vollständig unfähig, die Absicht hinter Experimenten zu validieren. Während aktuelle Systeme sicherstellen, dass ein Test innerhalb des Fehlerbudgets bleibt und das System überlebt, beantworten sie nicht die entscheidende Frage: Hat das Experiment das richtige Szenario geprüft, um das Wissen über das System zu erweitern? Viele Teams sammeln zwar Skripte, gewinnen aber keine neuen Erkenntnisse, da sie Sicherheit und informativen Wert verwechseln. Ein neuer Ansatz, basierend auf einer patentierten Architektur, fordert eine Trennung zwischen Sicherheitslayer und Intent-Layer. Der Sicherheitslayer beantwortet, wie viel das System brechen darf. Der Intent-Layer definiert hingegen, welches spezifische Verhalten getestet werden soll, um eine bestimmte Annahme über die Systemresilienz zu validieren. Ohne diese Unterscheidung führen Chaos-Programme oft zu statischen Skripten, die die sich ständig ändernde Mikrodienst-Architektur nicht abbilden und somit an der Realität vorbeitesten. Die vorgeschlagene Intention-basierte Architektur beginnt mit einer maschinenlesbaren Spezifikation. Anstatt nur zu definieren, welche Pods heruntergefahren werden sollen, legt diese Spezifikation eine überprüfbare Hypothese fest. Ein Beispiel wäre die Annahme, dass der Checkout-Prozess die Service-Level-Objektive (SLOs) einhält, auch wenn der Bestandsdienst hohe Latenzen aufweist. Das System generiert daraufhin automatisch Experimente, die kritische Pfade für dieses spezifische Verhalten identifizieren, anstatt willkürlich Komponenten anzugreifen. Die Sicherheit wird dabei dynamisch und kontextbezogen bewertet. Anstatt feste Schwellenwerte zu nutzen, berechnet das System ein kontinuierliches „Resilience-Budget". Es prüft nicht nur, ob die Infrastruktur gesund ist, sondern ob das spezifische Zielverhalten, wie etwa die Abschlussrate eines Kaufs, gefährdet ist. So wird ein Experiment sofort abgebrochen, wenn sich das geschäftskritische Verhalten verschlechtert, auch wenn die technischen Metriken auf den ersten Blick noch stabil erscheinen. Dieser Ansatz berücksichtigt zudem den Benutzerkontext und finanzielle Signale. Ein Datenbank-Timeout kann während des Anmeldeprozesses katastrophal sein, während es bei einer Hintergrundverarbeitung kaum auffällt. Intention-basierte Werkzeuge verstehen diese Unterscheidung und skalieren die Experimente entsprechend dem tatsächlichen Geschäftsrisiko in Dollar statt nur in technischen Metriken. Fachleute aus der Industrie betonen, dass dies eine echte künstliche Intelligenz-Problematik ist und nicht nur eine Frage der Orchestrierung. Deterministische Regeln reichen nicht aus, um komplexe Kausalketten bei Ausfällen zu modellieren. Es werden kausale Modelle benötigt, die aus jedem Experiment lernen und die Abhängigkeiten im System kontinuierlich aktualisieren. Um dieses Potenzial zu erschließen, benötigt die Branche drei wesentliche Bausteine: Ein standardisiertes Schema für Intentionsspezifikationen, eine strukturierte Erfassung von Experiment-Ergebnissen und Metriken zur Bewertung der Hypothesenqualität. Bis heute werden Ergebnisse oft in Dokumentationen oder E-Mails verborgen und gehen als Lernsignal verloren. Die Einführung dieser Infrastrukturen würde Chaos Engineering von einer Sammlung von Tests zu einem lernenden System transformieren, das die Ausfallsicherheit kontinuierlich verbessert, anstatt nur Skripte zu produzieren.