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.
Erste Schritte mit Chaos Engineering
Bevor Sie ein Experiment durchführen, empfehlen wir Ihnen, einige Grundlagen festzulegen, um das Beste aus Ihren Chaos-Engineering-Praktiken herauszuholen. Zu diesen Grundlagen gehören:
-
Beobachtbarkeit (Metriken, Protokollierung, Nachverfolgung von Anfragen)
-
Eine Liste von realen Ereignissen oder Fehlern, die Sie untersuchen möchten
-
Förderung organisatorischer Resilienz durch Mitwirkung von Führungskräften
-
Priorisierung kritischer Ergebnisse auf der Grundlage potenzieller Auswirkungen auf das Geschäft gegenüber neuen Funktionen, die bei der Durchführung von Chaosexperimenten entdeckt werden
Beobachtbarkeit von Chaosexperimenten
Die Beobachtbarkeit, die Metriken, Protokollierung und Nachverfolgung von Anfragen umfasst, spielt beim Chaos Engineering eine Schlüsselrolle. Wenn Sie ein Experiment durchführen, sollten Sie Geschäftskennzahlen, serverseitige Metriken, Kennzahlen zur Kundenerfahrung und Betriebsmetriken verstehen. Ohne Beobachtbarkeit können Sie kein stabiles Verhalten definieren oder ein aussagekräftiges Experiment durchführen, um zu überprüfen, ob Ihre Hypothese über Ihre Anwendung zutrifft.
Kennzahlen
Das folgende Diagramm zeigt die Arten von Metriken, die Sie für Chaosexperimente für verschiedene Arten von Anwendungen verfolgen können.
-
Geschäftskennzahlen — Steady State gibt den normalen Betrieb Ihres Systems an und wird durch Ihre Geschäftskennzahlen definiert. Sie kann durch Transaktionen pro Sekunde (TPS), Klick-Streams pro Sekunde, Bestellungen pro Sekunde oder eine ähnliche Kennzahl dargestellt werden. Ihre Anwendung weist einen stabilen Zustand auf, wenn sie erwartungsgemäß funktioniert. Stellen Sie daher sicher, dass Ihre Anwendung fehlerfrei ist, bevor Sie Experimente durchführen. Steady State bedeutet nicht unbedingt, dass ein Fehler keine Auswirkungen auf die Anwendung hat, da ein Prozentsatz der Fehler innerhalb akzeptabler Grenzen liegen kann. Der Steady-State ist Ihr Ausgangswert. Der stabile Zustand eines Zahlungssystems könnte beispielsweise als die Verarbeitung von 300 TPS mit einer Erfolgsquote von 99 Prozent und einer Hin- und Rücklaufzeit von 500 ms definiert werden. Stellen Sie sich den Steady-State visuell wie ein Elektrokardiogramm (EKG) vor. Wenn der stationäre Zustand Ihres Systems plötzlich schwankt, wissen Sie, dass ein Problem mit Ihrem Service vorliegt.
-
Serverseitige Metriken — Um zu verstehen, wie sich Ihre Ressourcen während des Experiments verhalten, benötigen Sie Einblicke in deren Leistung vor, während und nach dem Experiment. Um die Auswirkungen Ihrer Ressourcen auf zu messen AWS, können Sie Amazon verwenden CloudWatch. CloudWatch ist ein Service, der Anwendungen überwacht, auf Leistungsänderungen reagiert, die Ressourcennutzung optimiert und Einblicke in den Betriebszustand bietet. Während Ihrer Experimente sollten Sie serverseitige Messwerte wie Sättigung, Anforderungsvolumen, Fehlerraten und Latenz erfassen.
-
Kennzahlen zum Kundenerlebnis — Bei aktivierter AWS Option können Sie echte Benutzermetriken erfassen, indem Sie CloudWatchRUM verwenden, um Benutzeranfragen mithilfe von Tools wie Locust, Grafana k6, Selenium oder Puppeteer zu simulieren. Echte Benutzermetriken sind für Unternehmen, die Chaos-Engineering-Experimente durchführen, von entscheidender Bedeutung. Durch die Überwachung der Auswirkungen auf echte Benutzer während eines Experiments können sich Teams ein genaues Bild davon machen, wie sich Fehler und Störungen auf Kunden in der Produktion auswirken werden. Zu den wichtigsten Kennzahlen für das Kundenerlebnis gehören Time to First Byte (TTFB), Largest Contentful Paint (LCP), Interaction to Next Paint (INP) und Total Blocking Time (TBT).
-
Betriebskennzahlen — Interventionen messen, wie erfolgreich Sie Fehler auf automatisierte Weise beheben — zum Beispiel die erfolgreiche Latenz von Client-Anfragen während eines Neustarts von Pods, Aufgaben oder EC2-Instances mit Mechanismen wie Replikationscontroller oder automatischer Skalierung. Die Möglichkeit, bei einem Fehler automatisch einzugreifen, steht in direktem Zusammenhang mit einer guten Benutzererfahrung. Es ist von entscheidender Bedeutung zu verstehen, ob sich diese Minderungsmechanismen im Laufe der Zeit verändern. Indem Sie Kennzahlen sowohl für erfolgreiche als auch für fehlgeschlagene automatisierte Abhilfemaßnahmen definieren, erstellen Sie Wegweiser, anhand derer Sie potenzielle Regressionen in Ihrem System identifizieren können.
Protokollierung
Die zentrale Protokollierung ist entscheidend, um den Status der Komponenten Ihrer Anwendung vor, während und nach einem Chaosexperiment zu verstehen. Wir empfehlen Ihnen, Protokolle von all Ihren Anwendungskomponenten zu sammeln, um eine konsolidierte Übersicht darüber zu erhalten, was die einzelnen Komponenten zum Zeitpunkt der Installation des Experiments getan haben. Auf diese Weise erhalten Sie ein klares Bild vom Ablauf des end-to-end Experiments.
Anfragenachverfolgung
Mit der Anforderungsverfolgung können Sie den Ablauf jeder einzelnen Anfrage über die Komponenten Ihrer Anwendung hinweg beobachten, um ein umfassendes Verständnis der Auswirkungen zu erhalten, die der injizierte Fehler auf das System und seine Abhängigkeiten hat. Durch die Rückverfolgung der Anfragen können Sie erkennen, wie sich der Fehler auf verschiedene Dienste und Komponenten ausbreitet, sodass Sie den Umfang der Störung besser einschätzen können. Um Ihre Anfragen nachzuverfolgen AWS, können Sie verwenden. AWS X-Ray
Misserfolgszenarien zur Injektion von Chaosexperimenten
Das Ziel, häufig auftretende Fehler in Ihre Anwendung einzufügen, besteht darin, zu verstehen, wie die Anwendung auf diese unerwarteten Ereignisse reagiert, sodass Sie Mechanismen zur Schadensbegrenzung einrichten und Ihr System gegen solche Fehler widerstandsfähig machen können. Darüber hinaus sollten Sie Chaos Engineering verwenden, um historische Ausfallszenarien nachzuspielen, um sicherzustellen, dass Ihre Abwehrmechanismen immer noch wie erwartet funktionieren und sich im Laufe der Zeit nicht verändert haben.
Berücksichtigen Sie bei der Planung Ihrer Experimente zur Chaos-Technik die folgenden Ereignisse.
| Fehlermodus | Description |
|---|---|
Beeinträchtigung des Servers |
Starten Sie EC2-Instances neu, löschen Sie Kubernetes-Pods oder Amazon Elastic Container Service (Amazon ECS) -Aufgaben, um zu verstehen, wie Ihre Anwendung auf solche Abstürze reagiert. |
API-Fehler |
Fügen Sie Fehler in AWS und Ihren eigenen Service ein, um das Anwendungsverhalten APIs zu verstehen. |
Probleme mit dem Netzwerk |
Führen Sie Latenz oder Überlastung ein oder blockieren Sie Verbindungen, um reale Netzwerkprobleme nachzuahmen. |
AWS Beeinträchtigung der Verfügbarkeitszone |
Spielen Sie die Beeinträchtigung einer gesamten Availability Zone erneut ab, um die zonenübergreifende Wiederherstellung zu überprüfen. |
AWS-Region Beeinträchtigung der Konnektivität |
Führen Sie eine Netzwerkbeeinträchtigung erneut durch AWS-Regionen , um zu überprüfen, wie Ressourcen in der sekundären Region auf ein solches Ereignis reagieren. |
Datenbankausfälle |
Führen Sie ein Failover von Datenbankreplikaten durch, beschädigen Sie Daten oder machen Sie Datenbankinstanzen unerreichbar, um mehr über die Auswirkungen auf Ihre Anwendungs- und Wiederherstellungsstrategien zu erfahren. |
Pause bei der Datenbank- und Amazon S3 S3-Replikation |
Unterbrechen Sie die Datenbank- oder Amazon Simple Storage Service (Amazon S3) -Replikation über Availability Zones hinweg oder AWS-Regionen um die Auswirkungen nachgelagerter Anwendungen zu verstehen. |
Verschlechterung des Speicherplatzes |
Unterbrechen Sie I/O, entfernen Sie Amazon Elastic Block Store (Amazon EBS) -Volumes oder löschen Sie Dateien, um die Haltbarkeit und Wiederherstellung der Daten zu überprüfen. |
Beeinträchtigung der Abhängigkeit |
Reduzieren oder verschlechtern Sie die Leistung der nachgelagerten oder vorgelagerten Dienste, auf die Sie angewiesen sind, einschließlich der Dienste von Drittanbietern, um den end-to-end Ablauf und die Auswirkungen auf Ihre Kunden zu verstehen. |
Der Verkehr nimmt zu |
Generieren Sie Spitzen im Benutzerdatenverkehr, um die Funktionen der automatischen Skalierung zu testen und herauszufinden, wie sich die Kaltstartzeit auf den allgemeinen Anwendungsstatus auswirken kann. |
Erschöpfung der Ressourcen |
Maximieren Sie den CPU-, Arbeitsspeicher- und Festplattenspeicher, um zu überprüfen, ob Ihre Anwendung ordnungsgemäß beeinträchtigt wird. |
Kaskadierende Fehler |
Initiieren Sie primäre Ausfälle, die sich wiederum auf nachgelagerte Anwendungen und Komponenten auswirken. |
Schlechte Bereitstellungen |
Führen Sie problematische Änderungen oder Konfigurationen durch, um die Rollback-Mechanismen zu überprüfen. |
Förderung organisatorischer Resilienz
Chaos Engineering bietet den größten Nutzen, wenn es in Ihrem gesamten Unternehmen angewendet wird. Wir empfehlen Ihnen, mit einem Sponsor aus der Geschäftsleitung zusammenzuarbeiten, der Ihnen helfen kann, Resilienzziele in Ihrem gesamten Unternehmen festzulegen, Ängste, Unsicherheiten und Zweifel in Bezug auf den Bereich zu beseitigen und den Transformationsprozess einzuleiten, sodass Resilienz in die Verantwortung aller fällt.
Um das Geschäftsszenario des Aufbaus einer Chaos-Engineering-Praxis zu unterstützen, sollten Sie Ihre kritischen Geschäftsprojekte mit Chaos-Engineering-Maßnahmen verknüpfen. Wenn Sie Resilienz zu einem Vorteil und einer treibenden Kraft für die Beschleunigung machen, können Sie Ihren Erfolg im Laufe der Zeit verfolgen. Beginnen Sie mit der Anzahl kritischer Vorfälle pro Monat oder Quartal, der durchschnittlichen Wiederherstellungszeit und den Auswirkungen, die diese Vorfälle auf Ihre Kunden und Ihr Unternehmen hatten. Setzen Sie sich gemeinsam mit Ihren Teams das Ziel, die Anzahl der Vorfälle über einen Zeitraum von 6 bis 12 Monaten zu reduzieren, da als Reaktion auf Chaos-Engineering-Experimente Verbesserungen in Ihren gesamten Anwendungsstapeln vorgenommen werden.
Messen Sie, ob sich Vorfälle stark wiederholen. Nehmen wir zum Beispiel an, ein abgelaufenes TLS-Zertifikat führt zu Ausfallzeiten, da Clients keine vertrauenswürdige Verbindung aufbauen können. Wenn in einem Jahr mehrere Vorfälle auftreten, weil mehrere TLS-Zertifikate ablaufen, können Sie ein Experiment mit dem Ablauf eines TLS-Zertifikats durchführen und sicherstellen, dass Ihre Teams Benachrichtigungen erhalten oder in der Lage sind, solche Probleme automatisch zu beheben. Auf diese Weise können Sie sicherstellen, dass Sie gegen solche Fehler resistent sind.
Um den Fortschritt beim Chaos Engineering im Laufe der Zeit zu verfolgen, sollten Sie die folgenden Kennzahlen erfassen, um den Wert von Chaos Engineering über den gesamten Lebenszyklus einer Anwendung hinweg zu verdeutlichen:
-
Geringere Vorfallrate — Verfolgen Sie die Anzahl der Produktionsvorfälle im Laufe der Zeit und korrelieren Sie diese Zahl mit der Einführung von Chaos Engineering. Es wird davon ausgegangen, dass die Zahl der schwerwiegenden Vorfälle sinken wird.
-
Verbesserte mittlere Lösungszeit (MTTR) — Berechne die durchschnittliche Zeit, die zur Behebung von Vorfällen benötigt wird, und verfolge diese Daten, um festzustellen, ob sie sich mit der Zeit durch Chaos Engineering verbessern.
-
Höhere Anwendungsverfügbarkeit — Verwenden Sie Metriken auf Service-Ebene, um Verbesserungen der Verfügbarkeit aufzuzeigen, wenn die Ausfallsicherheit von Anwendungen durch Chaosexperimente zunimmt.
-
Schnellere Markteinführung — Chaos Engineering gibt Ihnen die nötige Sicherheit, um innovative Angebote schneller auf den Markt zu bringen, da Sie wissen, dass Ihre Anwendungen robust sind. Verfolgen Sie die zunehmende Geschwindigkeit der Produktveröffentlichung.
-
Senkung der Betriebskosten — Ermitteln Sie, ob Indikatoren wie Warnmeldungen, Betriebsauslastung und manueller Aufwand bei der Verwaltung von Anwendungen aufgrund von Chaos-Praktiken abnehmen.
-
Stärkung des Vertrauens — Befragen Sie Entwickler, Techniker für Standortzuverlässigkeit (SREs) und andere technische Mitarbeiter, um festzustellen, ob Chaos Engineering ihr Vertrauen in die Widerstandsfähigkeit von Anwendungen gestärkt hat. Wahrnehmungen sind wichtig.
-
Verbessertes Kundenerlebnis ‒ Connect Chaos Engineering mit positiven Ergebnissen für Kunden, wie z. B. weniger Serviceunterbrechungen, Rollbacks und Ausfällen.
Priorisierung von Problembehebungen
Wenn Sie Chaosexperimente durchführen, werden Sie wahrscheinlich Bereiche identifizieren, in denen Verbesserungspotenzial besteht, in denen die Anwendung nicht wie beabsichtigt funktioniert. Die Behebung solcher Probleme wird zu einer Aufgabe in Ihrem Backlog werden, der zusammen mit anderen Arbeiten, wie der Entwicklung von Funktionen, Priorität eingeräumt werden muss. Wir empfehlen Ihnen, sich Zeit für diese Verbesserungen zu nehmen, um future Ausfälle zu vermeiden. Erwägen Sie, diese Erkenntnisse und Problembehebungsaufgaben nach dem Ausmaß ihrer möglichen Auswirkungen zu priorisieren. Erkenntnisse, die sich direkt auf die Belastbarkeit oder Sicherheit Ihrer Anwendung auswirken, sollten Vorrang vor neuen Funktionen haben, um negative Auswirkungen auf Kunden zu vermeiden. Wenn das Team Schwierigkeiten hat, Abhilfemaßnahmen der Entwicklung von Funktionen vorzuziehen, sollten Sie sich an Ihren Sponsor in der Geschäftsleitung wenden, um sicherzustellen, dass die Prioritäten auf der Grundlage der Risikobereitschaft des Unternehmens festgelegt werden.
