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.

Kontinuierlicher Lebenszyklus von chaostechnischen Experimenten

Wie im vorherigen Abschnitt beschrieben, können Sie Chaos-Engineering-Experimente auf unterschiedliche Weise durchführen. In allen Fällen liegt der Schlüssel zum Aufbau eines aussagekräftigen Chaosexperiments darin, die Anwendung, historische Vorfälle und umgesetzte Abhilfemaßnahmen zu verstehen und genau zu verstehen, welche Bereiche untersucht werden müssen, z. B. Widerstandsfähigkeit oder Sicherheit. Ihr Wissen über die Anwendung hilft Ihnen, eine Hypothese über die potenziellen Schwächen der Anwendung zu formulieren und zu verstehen, wie sie den Fehler erkennt, behebt und repariert, wenn der Fehler auftritt.

Der Lebenszyklus eines Chaos-Experiments umfasst die folgenden Schritte:

Diese Schritte werden in der Abbildung veranschaulicht und in den folgenden Abschnitten erörtert.

Definieren Sie Ziele und legen Sie Erwartungen fest

Stellen Sie vor jedem Experiment sicher, dass Ihre Ziele und Erwartungen spezifisch, messbar, erreichbar, relevant und zeitgebunden sind. Definieren Sie Folgendes klar:

Wählen Sie die Zielanwendung aus

Chaos Engineering ist eine leistungsstarke Technik, erfordert jedoch eine sorgfältige Priorisierung, um den Nutzen zu maximieren. Bei der Entscheidung, worauf sich die Bemühungen im Bereich Chaos Engineering konzentrieren sollen, sollten Sie zunächst die kritischen Services Ihres Unternehmens berücksichtigen. Bitten Sie Ihre Teams, die Phasen des Softwareentwicklungszyklus zu durchlaufen und zunächst Fehler in die Testumgebungen einzuschleusen. Geschäftskritische Anwendungen stehen in direktem Zusammenhang mit Umsatz, Kundenerlebnis und Kernoperationen. Chaosexperimente mit diesen Diensten können Sicherheitslücken aufdecken, die das Unternehmen — und möglicherweise ganze Märkte — ernsthaft beeinträchtigen können, wenn sie nicht behoben werden. Konzentrieren Sie sich beispielsweise zunächst auf kundenorientierte Dienstleistungen wie Handelssysteme oder Ordersysteme. Die Priorisierung dieser zentralen Dienste bietet den größtmöglichen Schutz pro Zeitinvestition.

Schauen Sie sich nach wichtigen Diensten die grundlegenden Komponenten wie Datenbanken, Nachrichtenwarteschlangen, Netzwerke und gemeinsam genutzte Dienste an. APIs Diese können in Ihrer gesamten Organisation als gemeinsam genutzte Komponenten oder Dienste verwendet werden, sodass ihr Ausfall zu weitreichenden Problemen führen kann. Wenn die Widerstandsfähigkeit von Infrastrukturdiensten bestätigt wird, kann man sich darauf verlassen, dass sie die ihnen übergeordneten abhängigen Anwendungen nicht lahmlegen. Beispielsweise verrät ein Chaos Engineering-Experiment, bei dem ein Kafka-Cluster außer Betrieb genommen wird, viel über die Fehlertoleranz nachgeschalteter Anwendungen. Obwohl die Systeminfrastruktur nicht direkt auf den Kunden ausgerichtet ist, ist sie ein vorrangiges Ziel der Chaos-Technik.

Vergessen Sie nicht, die mentalen Lücken zwischen Mitarbeitern, Prozessen, Anlageninformationen und Abhängigkeiten von Drittanbietern abzubilden, da diese zu erheblichen Störungen führen können, wenn sie nicht mit den Zielen Ihrer Organisation im Hinblick auf die Belastbarkeit im Einklang stehen. Weitere Informationen zur Messung des ROI von Chaos Engineering finden Sie unter Quantifizierung des ROI von Chaos Engineering im Strategiedokument Investition in Chaos Engineering als strategische Notwendigkeit.

Das folgende Diagramm zeigt die Investitionsrendite, die sich aus der Durchführung von Chaosexperimenten für verschiedene Serviceebenen ergibt.

Mental Maps aufeinander abstimmen (Anwendungserkennung)

Wenn Sie Ad-hoc-Experimente oder Spieltage durchführen, beginnen Sie den Prozess der Anwendungserkennung mit einer Whiteboard-Sitzung, die sich darauf konzentriert, die Details Ihrer Anwendung zu skizzieren. (Wenn Sie die Experimente in der Chaos-Pipeline durchführen, haben Sie diese mentale Landkarte bereits angepasst, indem Sie die Zielanwendung definiert haben.) Ein guter Ansatz, um mentale Lücken zu verstehen, besteht darin, das jüngste Teammitglied zuerst ein Diagramm der Anwendung zeichnen zu lassen und dann die erfahreneren Mitarbeiter zu bitten, das Diagramm schrittweise zu erweitern. Dadurch werden etwaige Verständnislücken zwischen den Erfahrungsstufen aufgedeckt.

Das Diagramm sollte sowohl direkte Upstream- als auch Downstream-Abhängigkeiten der Anwendung sowie alle wichtigen Integrationen von Drittanbietern darstellen. Stellen Sie sicher, dass der erwartete Ablauf einer Anfrage durch die Anwendung abgestimmt ist. Stellen Sie die wichtigsten Arbeitsabläufe und Benutzerabläufe fest, um Klarheit darüber zu gewinnen, wie Kunden die Anwendung verwenden. Erwägen Sie die Verwendung eines Sequenzdiagramms, um diese Informationen zu erfassen.

Nach dieser gemeinsamen Sitzung sollte das Team über ein gemeinsames mentales Modell der Anwendung, ihrer kritischen Abhängigkeiten und ihrer Überwachungsmöglichkeiten sowie über ein Verständnis der Risiken verfügen, um eine fundierte Entscheidung treffen zu können, ob ein potenzielles Chaosexperiment fortgesetzt oder abgesagt werden soll.

Beheben Sie die bekannten Probleme mit Ihrer Anwendung

Experimente im Bereich Chaos Engineering sind darauf ausgelegt, proaktiv Defekte in einer Anwendung aufzudecken. Indem Sie Fehler wie erhöhte Latenz, Serverneustarts oder Leistungseinbußen in der Availability Zone einbeziehen, können Sie überprüfen, ob Ihre Anwendung realistische Störungen toleriert. Dieser Prozess setzt jedoch ein gewisses Maß an Stabilität und Integrität der Zielanwendung voraus. Wenn Chaosexperimente mit einer bereits problematischen Anwendung ausgeführt werden, besteht die Gefahr, dass tiefere Probleme verschleiert werden.

Bevor Teams Chaos Engineering durchführen, sollten sie alle bekannten Fehler, Bugs und Leistungsprobleme in ihrer Anwendung beheben.

Definieren Sie die Hypothese und das Experiment

Vorfälle in der Vergangenheit, die zu Störungen Ihrer Anwendung oder anderer Anwendungen in Ihrem Unternehmen geführt haben, können als hervorragende Quellen für Ideen für Chaos-Experimente dienen. Wurden frühere Ausfälle beispielsweise durch Konfigurationsfehler oder fehlende Resilienzmuster ausgelöst? Die Überprüfung der Vorfälle und die Wiederholung der Grundursachen dieser realen Misserfolge durch Chaosexperimente sind ein wirksames Mittel, um Widerstandsfähigkeit gegen ähnliche Probleme in der future zu entwickeln.

Eine weitere wertvolle Quelle für Experimentkonzepte können direkt von den Ingenieuren, Architekten und Betreibern stammen, die mit einer Anwendung am besten vertraut sind. Wenn Sie Teammitgliedern die Möglichkeit geben, hypothetische Ausfallszenarien einzureichen, von denen sie glauben, dass sie die Anwendung erheblich beeinträchtigen könnten, können Sie Ideen sammeln, die auf Insiderwissen basieren. Das Anwendungsteam kann dann bewerten, welches dieser vorgeschlagenen Szenarien die größten potenziellen Auswirkungen haben oder die größten unbekannten Risiken bergen könnte. Die gezielte Ausrichtung von Chaosexperimenten für solche risikoreichen, weniger verstandenen Szenarien kann wichtige Erkenntnisse liefern und future Probleme verhindern.

Eine dritte Quelle für Ideen ist die Durchführung von Resilienzmodellen, um die Bedingungen zu antizipieren, die zu identifizierten Geschäftsverlusten führen würden. Einige Übungen zur Resilienzmodellierung basieren auf einem komponentenbasierten Ansatz zur Erstellung eines Resilienzmodells, während andere einen systembasierten Ansatz verfolgen. Bei einem komponentenbasierten Ansatz wird die Frage gestellt: „Was passiert, wenn Komponente X extrem belastet ist oder ausgefallen ist?“ Das Team, das das Resilienzmodell entwickelt, spekuliert dann über die Auswirkungen eines solchen Szenarios auf die breitere Anwendung und identifiziert die derzeit geltenden Überwachungs- und Präventivmaßnahmen, um die Auswirkungen des Szenarios zu erkennen und abzuschwächen. Alternativ folgt ein systembasierter Ansatz einem Top-down-Prozess, um einen unerwünschten Zustand der Anwendung hervorzuheben — z. B. „Die Web-Storefront zeigt veraltete Lagerbestände“ — und fordert das Anwendungsteam auf, vorherzusehen, welcher Zustand oder welche Bedingungen dazu führen würden, dass sich die Anwendung auf diese Weise verhält.

Stellen Sie die Betriebsbereitschaft für das Experiment sicher

Sie benötigen quantifizierbare Indikatoren, um die Auswirkungen ungünstiger Bedingungen auf die Anwendung und ihr Verhalten zu messen, wie bereits im Abschnitt zur Beobachtbarkeit beschrieben. Wenn Sie das Verhalten der Anwendung messen können, können Sie feststellen, ob und in welchem Ausmaß sich die ungünstigen Bedingungen auf die Anwendung ausgewirkt haben.

Der beste Weg, um zu verstehen, ob es Auswirkungen auf Ihre Anwendung gibt, besteht darin, ihren stationären Zustand zu messen. Steady State misst, wie der normale Betrieb aussieht, und entspricht in der Regel den Geschäfts- und Kundenerfahrungsindikatoren für eine bestimmte Anwendung. Bevor Sie mit dem nächsten Schritt fortfahren, stellen Sie sicher, dass Sie über die erforderlichen Beobachtungsmöglichkeiten verfügen, um die Auswirkungen nachvollziehen zu können, und über Rollback-Mechanismen für den Fall, dass das Experiment nicht wie erwartet verläuft, bereit sind.

Führen Sie kontrollierte Experimente und Szenarien durch

Wir raten davon ab AWS, ein erstes Chaos-Experiment mit einer Anwendung durchzuführen, die sich in der Produktion befindet. Der Zweck eines Chaos-Experiments besteht darin, etwas Neues darüber zu erfahren, wie sich die Anwendung unter stressigen Bedingungen verhält. Das Verhalten der Anwendung kann während des Experiments unvorhersehbar sein, sodass die Durchführung eines Experiments zum ersten Mal in der Produktion Auswirkungen auf die Kunden haben kann. Daher sollten Sie ein anfängliches Chaosexperiment immer in einer Umgebung auf niedrigerer Ebene durchführen, die nur minimale Auswirkungen auf reale Benutzer hat, und dann Ihre Umgebungen wiederholen, nachdem Sie sich vergewissert haben und sicher sind, dass Ihre Anwendung die eingeführten Aktionen aufnehmen, sich an sie anpassen und sich von ihnen erholen kann.

Planen Sie jedes Experiment sorgfältig, indem Sie ein Dokument verwenden, das die wichtigsten Details enthält, ähnlich dem Dokument zur Versuchsplanung im Anhang. Einige der wichtigsten Bereiche, die berücksichtigt werden sollten, sind die Definition des stationären Zustands, die Hypothese und die Methode der Fehlerinjektion. Planung, Durchführung und Analyse eines Chaosexperiments können in einem einzigen Artefakt zusammengefasst werden.

Nachdem Sie den schriftlichen Plan für das Experiment fertiggestellt haben, bereiten Sie den erforderlichen Code vor, um die geplanten Störungen, die im Dokument beschrieben werden, einzufügen.

Um mögliche Auswirkungen während des Experiments zu erfassen, stellen Sie sicher, dass Beobachtungsmechanismen vorhanden sind. Wenn Sie noch nicht über eine automatisierte Methode zur Erfassung von Versuchsergebnissen verfügen, wie z. B. AWS FIS Experimentberichte, identifizieren Sie die Teammitglieder, die sich während der Ausführung Notizen machen, Screenshots von Dashboards erstellen und das Team durch das Experiment führen werden.

Lernen und verfeinern

Trefft euch nach jedem Experiment als Team, um das Chaos-Experiment noch einmal Revue passieren zu lassen und darüber nachzudenken. Bemühen Sie sich bewusst, eine tadellose Denkweise aufrechtzuerhalten. Ihr Ziel sollte es sein, einen offenen, konstruktiven Dialog zu führen, der sich ausschließlich darauf konzentriert, maximalen Lernerfolg zu erzielen, und nicht Schuldzuweisungen.

Überprüfen Sie zunächst die Steady-State-Definition und die Hypothese für das Experiment. Hat sich die Anwendung wie erwartet verhalten? Gab es Überraschungen, die Annahmen widerlegten? Erläutern Sie die positiven und schlechten Beobachtungen der Anwendung während des Experiments. Die gesammelten Daten — Metriken, Protokolle, Screenshots usw. — sollten genau die Geschichte erzählen, was passiert ist.

Gehen Sie diese Datenüberprüfung mit Neugier statt mit Urteilsvermögen an und identifizieren Sie Bereiche, in denen das Anwendungsdesign, die Dokumentation, die Überwachung oder andere Funktionen auf der Grundlage der gewonnenen Erkenntnisse verbessert werden können. Diese Aktionspunkte werden als Folgeprojekte erfasst, um die Anwendung widerstandsfähiger zu machen.

Durch diesen untadeligen Ansatz können Sie offen darüber sprechen, was schief gelaufen ist und wie Sie es beheben können. Gehen Sie davon aus, dass alle Beteiligten eine positive Absicht haben, und vertrauen Sie darauf, dass sie auf gute Ergebnisse hingearbeitet haben. Ihr gemeinsames Ziel ist Unternehmenswachstum und Weiterentwicklung durch kontinuierliches Lernen und Anpassung. Überprüfungen von Chaos-Experimenten, die auf konstruktive und untadelige Weise durchgeführt werden, bieten Ihrem Team einen sicheren Ort, an dem es wertvolle Erkenntnisse gewinnen kann, die Ihre Anwendungen und Ihr Unternehmen auf lange Sicht zuverlässiger und widerstandsfähiger machen. Der Fokus liegt weiterhin auf den Erkenntnissen, nicht auf den Menschen. Um die Erkenntnisse in Ihren Teams zu verbreiten, veröffentlichen Sie den Bericht mit den Testergebnissen an einer zentralen Stelle und bewerben Sie die Ergebnisse, damit andere daraus lernen können.