Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
# Übersicht
## Vergleich von Resilienztests mit Chaos-Engineering
Resilienztests sind deterministisch. Das heißt, sie validieren bekannte Merkmale von Resilienzmechanismen wie Schutzschaltern, Wiederholungsversuchen, Failovers oder Fallbacks, die in Ihrer Anwendung implementiert wurden. Es bestätigt, wie diese Anwendungskomponenten kontrollierte Störungen mit minimalen bis keinen Auswirkungen auf die Benutzer abfangen. Daher konzentrieren sich Resilienztests auf die Validierung bekannter Fehlerquellen, die in Anwendungskomponenten eingebracht werden, um pass/fail Ergebnisse zu erzielen. Sie sollten als einen Schritt in Ihrer Pipeline kontinuierlich Resilienztests durchführen, um sicherzustellen, dass Ihre Resilienzsituation nicht beeinträchtigt wird. Bei Resilienztests führen Sie häufig keine Tests mit echten Komponenten durch, sondern simulieren APIs diese Komponenten. Dieser Ansatz ermöglicht konsistente, reproduzierbare Tests von Ausfallszenarien in einer kontrollierten Umgebung und eignet sich daher für automatisierte Pipeline-Integrations- und Regressionstests.
Im Gegensatz dazu ist Chaos Engineering nicht deterministisch. Das heißt, es basiert auf Hypothesen und verifiziert Ihr mentales Modell darüber, wie die Anwendung und ihre Abhängigkeiten (Menschen, Prozesse und Technologie) unerwartete Ausfälle absorbieren, sich daran anpassen und sich schließlich von ihnen erholen. Daher konzentriert sich Chaos Engineering auf die end-to-end Überprüfung unbekannter Fehlerquellen mit dem Ziel, Fehler frühzeitig zu erkennen und zu beheben, bevor sie zu großen Ereignissen werden. Chaos Engineering fördert kontinuierliches Lernen und sollte im Rahmen einer separaten Chaos-Pipeline oder durch Ad-hoc-Experimente geübt werden, die es Ihnen ermöglichen, mehrere Experimente zu einem beliebigen Zeitpunkt durchzuführen, ohne die Produktivität Ihres Entwicklers bei der Codebereitstellung zu beeinträchtigen.
Der Chaos-Engineering-Prozess beginnt häufig mit einem Chaos-Spieltag. Dabei handelt es sich um eine spezielle Veranstaltung, bei der Teams bewusst kontrollierte Fehler oder Ausfälle in ihre Anwendung einbauen. Der Spieltag ist progressiv: Er beginnt in Umgebungen auf niedrigerer Ebene (z. B. beim Entwickeln oder Testen) und wird mit steigendem Selbstvertrauen schrittweise in Umgebungen mit höherer Ebene (wie Staging und Vorproduktion) überführt. Durch die systematische Bearbeitung dieser Umgebungen können Teams überprüfen, ob ihre Systeme die eingeführten Fehler ordnungsgemäß tolerieren, bevor sie in die Produktion gehen. Dieser methodische Fortschritt stellt sicher, dass die Teams bis zu dem Zeitpunkt, zu dem Chaosexperimente in Produktionsumgebungen durchgeführt werden, großes Vertrauen in die Widerstandsfähigkeit ihres Systems aufgebaut haben. Der Game Day-Prozess ist ein proaktiver Ansatz zur Identifizierung von Schwächen und Schwachstellen in der Architektur und den betrieblichen Abläufen einer Anwendung und beseitigt gleichzeitig den Lernstress bei einem unerwarteten Produktionsausfall.
## Der Wert von Chaos Engineering
Komplexe Systeme sind in der heutigen Welt allgegenwärtig. Sie spielen in vielen Bereichen unseres Lebens eine entscheidende Rolle, von den Finanzmärkten bis hin zum Gesundheitswesen. Wir erwarten, dass diese Systeme immer betriebsbereit sind. Komplexe Systeme sind jedoch häufig anfällig für unerwartete Ereignisse und Verhaltensweisen, die erhebliche Folgen haben können. Organizations müssen für Störungen planen, anstatt sich zu fragen, ob sie eintreten werden. Sie können dies tun, indem sie Szenariotests für ihre kritischen oder geschäftskritischen Unternehmensdienste anwenden. Hier kommt Chaos Engineering ins Spiel.
Chaos Engineering bietet einen Ansatz zur Verwaltung komplexer Systeme, der dazu beitragen kann, Risiken zu minimieren und die Widerstandsfähigkeit zu verbessern. Um sich auf Chaosexperimente vorzubereiten, müssen die Teams Hypothesen über das Verhalten ihrer Systeme entwickeln, wodurch sie besser verstehen, wie Systeme aufgebaut sind und wie sie funktionieren. Bei dieser Vorbereitung werden oft mentale Lücken, architektonische Erkenntnisse und betriebliches Wissen aufgedeckt, das andernfalls möglicherweise unentdeckt bleiben würde. Chaos Engineering fördert das Verständnis dafür, wie komplexe Systeme auf Ausfälle reagieren, und fördert so mehr Transparenz und Rechenschaftspflicht bei Systemdesign und -management. Je häufiger Chaos Engineering in Ihrem Unternehmen angewendet wird, desto besser ist es darauf vorbereitet, operativ vorzugehen. Chaos Engineering hilft Ihnen dabei, bewährte Methoden für die Entwicklung robuster Anwendungen zu entwickeln, die Komponentenausfälle mit minimalen oder gar keinen Auswirkungen auf die Benutzer überstehen können. Auf diese Weise wird sichergestellt, dass kritische Anwendungen innerhalb der erwarteten Serviceniveaus und der erwarteten Belastbarkeit funktionieren, während gleichzeitig das Wissen des Teams über die eigenen Systeme kontinuierlich erweitert wird.
## Wir bereiten uns auf widrige Bedingungen vor
Wenn Sie darauf aufbauen AWS, nutzen Sie verschiedene Arten von Diensten, darunter zonale Dienste wie Amazon Elastic Compute Cloud (Amazon EC2), regionale Dienste wie Amazon Simple Storage Service (Amazon S3), globale Dienste wie AWS Identity and Access Management (IAM), Software-as-a-Service (SaaS) -Dienste von Drittanbietern und lokale Dienste. Jeder Servicetyp macht unterschiedliche Fehlerdomänen verfügbar, die Sie berücksichtigen müssen. Wie bereiten Sie sich auf selbst verschuldete Ereignisse oder auf Ereignisse vor, die von Dritten verursacht werden und auf die Ihr Unternehmen keinen Einfluss hat?
[Um besser zu verstehen, wie Ihre Anwendung auf widrige Bedingungen reagieren könnte, können Sie () verwenden AWS Fault Injection Service .AWS FIS](https://docs.aws.amazon.com/fis/latest/userguide/what-is.html) AWS FIS ist ein vollständig verwalteter Service für die kontrollierte Durchführung von Fault-Injection-Experimenten. Sie können diesen Service verwenden, um von Ihnen AWS bereitgestellte Szenarien wie Stromausfälle in der Availability Zone und regionsübergreifende Verbindungsprobleme einzufügen, oder Sie können Ihre eigenen Experimente erstellen, indem Sie eine Vielzahl von Fehleraktionen, die vom Service bereitgestellt werden, miteinander verknüpfen. AWS FIS ermöglicht es Ihren Teams, kontinuierlich zu üben und zu lernen, wie ihre Anwendung auf häufig auftretende Fehler reagieren und Fehler beheben würde, sobald sie entdeckt werden.
## Üben Sie kontrolliertes Chaos Engineering
Die wichtigsten Prinzipien von Experimenten mit kontrolliertem Chaos sind:
+ Beginnen Sie mit einer Umgebung, die Ihrer Produktionsumgebung ähnelt.
+ Stellen Sie eine Hypothese auf und beenden Sie die Bedingungen für Ihr Experiment.
+ Fangen Sie klein an.
+ Üben Sie die Kontrolle über Ihre Chaos-Experimente aus.
+ Lege den Umfang der Wirkung fest.
+ Informieren Sie sich über Ihre Servicebasis.
+ Planen Sie Experimente.
+ Korrigieren Sie zuerst und experimentieren Sie dann.
+ Überwachen Sie das Experiment genau.
+ Lernen Sie aus Ihren Ergebnissen.
+ Priorisieren Sie die Ergebnisse, korrigieren Sie sie und überprüfen Sie sie.
+ Verbreiten Sie die Erkenntnisse in Ihrem gesamten Unternehmen.
Um Chaos Engineering erfolgreich zu skalieren, müssen Sie Chaos-Experimente auf kontrollierte Weise durchführen. Wenn Sie verwenden AWS FIS, können Sie mithilfe von [ CloudWatchAmazon-Alarmen](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html) Stoppbedingungen erstellen. Sie können diese Bedingungen in eine Versuchsvorlage integrieren, um sicherzustellen, dass Experimente gestoppt werden, wenn sie außerhalb der Grenzwerte liegen, und auf ihren letzten bekannten Status zurückgesetzt werden. AWS FIS bietet auch Sicherheitshebel. Wenn Sie diese Hebel betätigen, werden alle laufenden Experimente auf dem Konto in der AWS FIS gestoppt und zurückgesetzt AWS-Region, einschließlich Experimenten mit mehreren Konten, und verhindert, dass neue Experimente gestartet werden. Dadurch wird verhindert, dass Fehler während bestimmter Zeiträume wie Handelszeiten, Verkaufsereignisse oder Produkteinführungen oder als Reaktion auf Integritätsalarme von Anwendungen auftreten. Der Sicherheitshebel bleibt so lange gedrückt, bis er manuell gelöst wird.
Wenn Sie ein Chaosexperiment durchführen, sollten Sie Schutzmaßnahmen festlegen, um unerwünschte Nebenwirkungen auf die Umgebung zu verhindern, insbesondere wenn die Möglichkeit besteht, dass das Experiment Anwendungen beeinträchtigt, die sich in der Produktion befinden. Wenn Sie das Experiment planen, sollten Sie mit etwaigen negativen Auswirkungen rechnen, die es auf andere Anwendungen in der Umgebung haben könnte. Beispielsweise könnten andere Anwendungen fehlerhafte Nachrichten von der Anwendung erhalten, die Teil des Experiments ist, hohe Anforderungszahlen haben oder auf Ressourcenkonflikte stoßen, wenn sie die Infrastruktur gemeinsam nutzen. Dokumentieren Sie diese Risiken und beheben Sie alle bekannten oder inakzeptablen Probleme, bevor Sie das Experiment durchführen.