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.
# Anhang A ‒ Zieltypen für Chaos Engineering
Die folgenden Beschreibungen der Zieltypen enthalten reale Beispiele dafür, wie Amazon und andere Organisationen Ziele für Chaos Engineering entworfen haben.
## Ziele einer belastbaren Architektur
Einer der ersten Gründe für die Einführung von Chaos Engineering ist die Identifizierung und Reduzierung von Single Points of Failure (SPOF) in allen Systemen und Infrastrukturen. Ziel ist es, die Widerstandsfähigkeit kritischer Systeme und Architekturen zu validieren, insbesondere für neue Dienste oder Anwendungen.
Zu den Zielen einer ausfallsicheren Architektur gehört die Durchführung von Chaosexperimenten, bei denen Fehler in Dienstabhängigkeiten simuliert werden. Die Experimente bestätigen, ob Timeouts, Wiederholungsversuche, Caching-Verhalten und Circuit-Breaker-Konfigurationen korrekt funktionieren. Diese Experimente helfen dabei, Probleme aufzudecken, die behoben werden müssen, und so Vorfälle zu verhindern, die sich auf Kunden auswirken. Ein Beispiel finden Sie unter [Aufbau robuster Dienste bei Prime Video](https://aws.amazon.com/blogs/opensource/building-resilient-services-at-prime-video-with-chaos-engineering/) mit Chaos Engineering.
## Ziele der Servicewiederherstellung
Im Mittelpunkt der Servicewiederherstellungsziele steht die Verbesserung der Fähigkeit zur Wiederherstellung nach Betriebsunterbrechungen oder Infrastrukturausfällen. Beispielsweise könnte Ihr Unternehmen bestrebt sein, im Falle eines Ausfalls ein bestimmtes Recovery Time Objective (RTO) für Ihre Kerndienste zu erreichen. Teams können Chaosexperimente entwerfen, um Evakuierungsstrategien, Failover-Mechanismen und automatisierte Wiederherstellungsprozesse zu validieren und zu optimieren. Die Optimierungen reduzieren letztendlich den Zeitaufwand für die Wiederherstellung des Dienstes. Ein Beispiel finden Sie unter [AWS Lambda under-the-hoodResilienz](https://aws.amazon.com/blogs/compute/aws-lambda-resilience-under-the-hood/).
## Ziele im Hinblick auf das Nutzererlebnis
Die Aufrechterhaltung eines konsistenten und zuverlässigen Benutzererlebnisses ist von größter Bedeutung, insbesondere in Zeiten mit hohem Besucheraufkommen oder kritischen Ereignissen. Setzen Sie sich in solchen Fällen Ziele, in deren Mittelpunkt die Erfüllung bestimmter Service-Level-Ziele steht ()SLOs. Dieser kundenorientierte Ansatz stellt sicher, dass die Bemühungen um Resilienz direkt auf die Bereitstellung eines erstklassigen Benutzererlebnisses ausgerichtet sind, selbst bei Ausfällen oder verschlechterten Bedingungen. Ein Beispiel finden Sie unter [Engineering Resilience: Lessons from Amazon Search's Chaos Engineering Journey](https://community.aws/posts/amazon-search-chaos-engineering-journey).
## Metrikorientierte Ziele
Sie können Ziele auf der Grundlage quantitativer Kennzahlen festlegen, z. B. eines Resilienz-Scores, der berechnet wird, indem Services, die bewährte Best Practices für Resilienz anwenden, Punkte vergeben werden. Anschließend können Sie anhand bestimmter Chaosexperimente den Resilienzwert ermitteln. Dieser Wert kann Teams als Maßstab dienen, um ihre Fortschritte bei der Minderung bekannter Verfügbarkeitsrisiken und der Umsetzung empfohlener Resilienzmaßnahmen zu verfolgen. Es ist jedoch wichtig, solche Werte vorsichtig zu interpretieren und zu vermeiden, dass eine einzelne Kennzahl auf Kosten umfassenderer Resilienzziele überbewertet wird. [Ein Beispiel finden Sie unter Grundlegendes zu Resilienzwerten.](https://docs.aws.amazon.com/resilience-hub/latest/userguide/resil-score.html)
## Ziele zur Einhaltung gesetzlicher Vorschriften
Die Finanzdienstleistungsbranche hat sich als Vorreiter bei der Umsetzung von Chaos Engineering herausgestellt, was in erster Linie auf strenge regulatorische Anforderungen zurückzuführen ist, die robuste Widerstandsfähigkeit erfordern. Die Vorschriften werden von Finanzinstituten verlangen, dass sie Sicherheitslücken in ihren kritischen Systemen und Prozessen proaktiv identifizieren, testen und beheben. Diese Vorschriften beinhalten Folgendes:
+ Das behördenübergreifende Papier über solide Praktiken zur Stärkung der betrieblichen Widerstandsfähigkeit, herausgegeben von US-Bundesbehörden
+ Die Leitlinien der Europäischen Zentralbank zur operativen Resilienz
+ Der Vorschlag der Europäischen Kommission für einen Digital Operational Resilience Act (DORA)
Wenn es sich bei Ihrer Organisation um ein Finanzinstitut handelt, halten Sie sich an diese Vorschriften, indem Sie explizite Ziele für den Nachweis der betrieblichen Belastbarkeit durch umfassende Test- und Validierungsstrategien festlegen. Ein Beispiel finden Sie unter [London Stock Exchange Group setzt Chaos Engineering ein AWS , um die Widerstandsfähigkeit zu verbessern](https://aws.amazon.com/blogs/architecture/london-stock-exchange-group-uses-chaos-engineering-on-aws-to-improve-resilience/).