Chaos Engineering ist ein Ansatz zum Testen der Fehlertoleranz von Software, der absichtlich Fehler in Live-Bereitstellungen provoziert. Es enthält ein Element der Zufälligkeit, um die Unvorhersehbarkeit der meisten Ausfälle in der realen Welt nachzuahmen.
Die Idee, einem System Chaos zu verleihen, wird im Allgemeinen Netflix zugeschrieben. Im Jahr 2011 veröffentlichte das Unternehmen Chaos Monkey, ein Tool, das es entwickelt hat, um Teile seiner Produktionsinfrastruktur zu deaktivieren. Durch zufällige Ausfälle in überwachten Umgebungen konnte Netflix versteckte Probleme entdecken, die bei regelmäßigen Tests unbemerkt blieben.
Chaos Engineering bietet einen Immunreaktionseffekt. Es ist ähnlich wie wir gesunde Menschen impfen. Sie führen absichtlich eine Bedrohung ein, die möglicherweise kurze, aber beobachtbare Probleme verursacht, um eine stärkere langfristige Widerstandskraft zu entwickeln.
Resilienz aufbauen
Es’ Sie können davon ausgehen, dass jedes ausreichend große System Fehler enthält, von denen Sie nichts wissen. Trotz all Ihrer automatisierten Tests und der täglichen Praxisnutzung können Sie nicht alles erfassen. Einige Probleme treten nur in sehr spezifischen Szenarien auf, wie z. B. der Verlust der Konnektivität zu einem Drittanbieterdienst.
Chaos Engineering akzeptiert, dass unvorhergesehene Betriebsprobleme immer eine Tatsache sein werden, selbst in vermeintlich wasserdichten Produktionsumgebungen. Während viele Organisationen am Ende ein “warten und sehen” Herangehensweise, das Spielen von Schlägen, wenn echte Berichte eintreffen, funktioniert Chaos Engineering nach dem Prinzip, dass ein kurzer Ausfall, den Sie aufrufen, immer besser ist, als einer, den der Kunde zuerst sieht.
Werbung
Wenn Sie Dinge absichtlich unterbrechen, können Sie die allgemeine Ausfallsicherheit Ihres Systems bestimmen. Was passiert, wenn die Datenbank ausfällt? Wie wäre es mit einem Ausfall Ihres E-Mail-Versanddienstes eines Drittanbieters? Die größte Stärke von Chaos Engineering ist seine Fähigkeit, Ereignisse zu reproduzieren, die mit Komponententests und dem Einsatz in der realen Welt normalerweise nicht abgedeckt werden.
Chaos-Testtools werden oft gegen reale Bereitstellungen ausgeführt, um Diskrepanzen zwischen Entwicklungs- und Produktionsumgebungen zu beseitigen. Sie müssen jedoch nicht so viel Risiko eingehen: Solange Sie sicher sind, dass Sie Ihre Infrastruktur genau replizieren können, können Sie die Technik in einer Sandbox-Staging-Umgebung verwenden.
Chaos zu Ihren Systemen hinzufügen
Sie haben mehrere Möglichkeiten, wenn Sie Ihrer Infrastruktur etwas Chaos hinzufügen möchten. Zu diesem Zweck entwickelte automatisierte Tools bieten einen Ausgangspunkt, können jedoch schwierig in Ihre eigene Infrastruktur zu integrieren sein. Normalerweise müssen Sie sich in VM- oder Container-Management-Plattformen integrieren, damit das Tool mit Ihren eigenen Instanzen interagieren kann.
Im Fall von Chaos Monkey müssen Sie Spinnaker, die Continuous Delivery-Plattform von Netflix, verwenden. Obwohl es eine breite Kompatibilität mit beliebten öffentlichen Cloud-Anbietern bietet, ist es auch eine weitere Abhängigkeit, die Sie Ihrem Stack hinzufügen.
Wenn Sie Kubernetes verwenden, verwendet kube-monkey die ursprünglichen Netflix-Prinzipien und verpackt sie für die Verwendung in Ihrem Cluster. Es funktioniert auf Opt-in-Basis, sodass Kubernetes-Ressourcen mit dem Label kube-monkey/enabled für eine zufällige Beendigung in Frage kommen.
Pumba bietet ähnliche Funktionen für normale Docker-Container. Es kann Containerabstürze provozieren, Ressourcenkapazitäten wie CPU und Arbeitsspeicher belasten und Netzwerkausfälle verursachen.
Werbung
Ein Tool, das speziell auf Netzwerkfehler abzielt, ist Toxiproxy von Shopify. Dadurch wird ein TCP-Proxy bereitgestellt, der eine Vielzahl von Netzwerkbedingungen simuliert. Sie können den Datenverkehr Ihrer Anwendung über Toxiproxy filtern, um zu sehen, wie das System mit hoher Latenz oder reduzierter Bandbreite arbeitet.
Für eine erweiterte Kontrolle ist VMWare's Mangle ein “Chaos Engineering . Orchestrator” die auf mehrere unterschiedliche Bereitstellungsmechanismen abzielt. Es funktioniert mit Kubernetes, Docker, VMware vCenter und generischen SSH-Verbindungen. Mit Mangle können Sie benutzerdefinierte Fehler für Anwendungs- und Infrastrukturkomponenten definieren. Anwendungsfehler sollten einen einzelnen Dienst betreffen. Infrastrukturfehler zielen auf gemeinsam genutzte Komponenten ab, die mehrere Dienste außer Betrieb setzen könnten.
Während Chaos Engineering am häufigsten mit Backend-Entwicklung und DevOps in Verbindung gebracht wird, wächst das Interesse auch bei Frontend-Ingenieuren. React Chaos ist eine Bibliothek, die zufällige Fehler von React-Komponenten auslöst, sodass Sie flockige UI-Abschnitte identifizieren können, die Ihre gesamte App zum Absturz bringen könnten.
Designing Your Own Chaosexperimente
Wenn Sie ein Open-Source-Chaos-Tool nicht erfolgreich einsetzen können, entwerfen Sie stattdessen Ihre eigenen Experimente. Erstellen Sie eine Liste der Annahmen in der Umgebung Ihrer Anwendung. Identifizieren Sie die Verbindungen zwischen den Diensten und überlegen Sie, was passieren würde, wenn einer ausfällt.
Dann müssen Sie Ihre Hypothese überprüfen. Brechen Sie das System und beobachten Sie die Konsequenzen. Bestimmen Sie als nächstes, ob der Effekt akzeptabel war. Ist die App abgestürzt und hat dem Benutzer einen Stack-Trace angezeigt? Oder wurde eine Ausfallstatusseite angezeigt und der Stack-Trace per E-Mail an Ihre Bereitschaftsmitarbeiter gesendet?
Es ist wichtig, jeden Test klein und fokussiert zu halten. Dadurch werden die Auswirkungen im Falle eines Produktionsausfalls begrenzt und Sie können sicher sein, dass das Problem von der getesteten Annahme herrührt und nicht von einem anderen Teil des Systems.
Werbung
Stellen Sie immer sicher, dass Sie ein klares Wiederherstellungsverfahren haben, bevor Sie ein Chaos-Experiment manuell durchführen. Einen provozierten Ausfall in einen ungeplanten Live-Ausfall zu verwandeln, ist das Letzte, was Sie wollen. Wenn Sie einen Dienst beenden, denken Sie an die Zeit, die Sie benötigen, um ihn erneut zu starten. Bei längeren Ausfällen kann es zu negativen Auswirkungen auf Ihre Anwendung kommen: Wenn Sie einen E-Mail-Verteilungsdienst abbrechen, kann es zu einem Rückstand kommen, den Sie bearbeiten müssen, wenn er wieder online geht. Diese Aspekte müssen in Ihren Aktionsplan aufgenommen werden, bevor Sie mit der Arbeit beginnen.
Nachdem Ihr Experiment abgeschlossen ist, müssen Sie möglicherweise Ihr System aktualisieren, bevor Sie den Test erneut ausführen. Das Testen Ihres Fixes verbessert die Situation tatsächlich und lässt Sie sicher sein, dass Ihr System jetzt für dieses spezielle Szenario widerstandsfähig ist.
Hier eine Zusammenfassung des Chaos-Experiment-Prozesses:
- Entwickeln Sie eine Hypothese: “Das System ist widerstandsfähig gegenüber erhöhter Netzwerklatenz.”
- Entwerfen Sie ein fokussiertes Experiment: “Wir werden die Latenz bei 70 % der Anfragen künstlich auf 500 ms erhöhen.” Stellen Sie sicher, dass Sie eine klare Rollback- und Wiederherstellungsstrategie haben.
- Führen Sie den Test durch:Beobachten Sie die Auswirkungen auf Ihre Anwendung. Machen Sie schädliche Änderungen an Produktionsumgebungen so schnell wie möglich rückgängig.
- Analyse der Ergebnisse: Wenn Sie feststellen, dass Ihr System nicht widerstandsfähig genug war, implementieren Sie Verbesserungen und wiederholen Sie den Vorgang.
Die nicht-technische Seite des Chaos Engineering
Chaos Engineering wird normalerweise als technische Aufgabe für Entwicklungs- und Betriebsteams angesehen. — schließlich ist “Engineering” liegt im Namen. Neben dem A und O von Netzwerken und Diensten ist es wichtig, auch die menschliche Seite zu betrachten. Man kann sich leicht vorstellen, dass Ihr System nur von einer Datenbank, einigen App-Servern und einem stabilen Netzwerk abhängt. Das ist normalerweise nicht der Fall.
Überlegen Sie, wie Ihr System reagieren würde, wenn Teammitglieder nicht verfügbar wären. Ist Wissen leicht zugänglich, wenn ein Administrator unerwartet zurücktreten muss? Besonders in kleineren Organisationen ist es üblich, dass ein “Team” ein einzelner Mensch zu sein. Was passiert, wenn Ihr Netzwerkmitarbeiter während eines Live-Ausfalls krank wird?
So wie Sie die technischen Aspekte testen, indem Sie Dienste abbrechen, können Sie auch menschliche Szenarien vorhersehen. Versuchen Sie, Schlüsselpersonen gezielt auszuschließen, während Sie einen Ausfall proben. War der Rest des Teams in der Lage, den Service wieder in einen akzeptablen Zustand zu versetzen? Wenn dies nicht der Fall wäre, könnten Sie davon profitieren, mehr vom System und seinen Abhängigkeiten zu dokumentieren.
Zusammenfassung
Der Begriff “Chaos Engineering” bezieht sich auf die Praxis, Dinge in der Produktion absichtlich zu unterbrechen, um zuvor verborgene Probleme aufzudecken. Obwohl der Ansatz zunächst entmutigend erscheinen mag, können Ihnen spezielle Tools wie Chaos Monkey helfen, mit minimalem Risiko anzufangen.
Werbung
Das Hinzufügen von Chaos ist eine nützliche Technik, da es sowohl vorübergehende als auch systemische Probleme aufdeckt. Sie werden möglicherweise feststellen, dass eine Spitzenauslastung des Speichers Auswirkungen auf Ihre Infrastruktur hat, dass jedoch eine erhöhte Netzwerklatenz sporadisch Auswirkungen auf bestimmte Teile Ihres Stapels hat.
Der effektive Einsatz von Chaos Engineering kann Ihnen helfen, Fehler schneller zu finden , bevor Ihre Kunden sie bemerken. Es hilft Ihnen, die Widerstandsfähigkeit Ihres Systems aufzubauen, indem es die Antizipation von Problemen fördert. Die meisten Teams gehen Probleme immer noch reaktiv an, was zu einer erhöhten Zykluszeit führt, die die Effizienz behindert.
Chaos Engineering wird am besten als Denkweise und nicht als spezifisches Verfahren oder Softwareprodukt behandelt. Wenn Sie erkennen, dass Systeme zum Chaos neigen, werden Sie natürlich anfangen, Unterstützung für mehr “Was-wäre-wenn” Szenarien in Ihren Code.
Es lohnt sich immer, über das “Unmögliche” Ereignisse wie ein Rechenzentrumsausfall oder eine schwere Netzwerküberlastung. In Wirklichkeit sind sie nicht unmöglich, nur extrem selten. Wenn sie zuschlagen, sind dies wahrscheinlich die zerstörerischsten Ereignisse, auf die Ihr System stößt, es sei denn, Ihre Infrastruktur ist darauf vorbereitet, mit Fallback-Routinen damit umzugehen.