Notiz. übersetzen: Dieser Artikel setzt eine großartige Artikelserie des AWS-Technologie-Evangelisten Adrian Hornsby fort, der auf einfache und klare Weise erklärt, wie wichtig Experimente sind, um die Folgen von Ausfällen in IT-Systemen abzumildern.
„Wenn es Ihnen nicht gelingt, einen Plan vorzubereiten, dann planen Sie zu scheitern.“ - Benjamin Franklin
В In dieser Artikelserie habe ich das Konzept des Chaos Engineering vorgestellt und erklärt, wie es hilft, Fehler im System zu finden und zu beheben, bevor sie zu Produktionsausfällen führen. Es wurde auch erörtert, wie Chaos Engineering positive kulturelle Veränderungen innerhalb von Organisationen fördert.
Am Ende des ersten Teils versprach ich, über „Werkzeuge und Methoden zur Einführung von Fehlern in Systemen“ zu sprechen. Leider hatte mein Kopf diesbezüglich seine eigenen Pläne, und in diesem Artikel werde ich versuchen, die beliebteste Frage zu beantworten, die sich Menschen stellt, die sich mit Chaos Engineering befassen möchten: Was zuerst brechen?
Tolle Frage! Allerdings scheint ihn dieser Panda nicht besonders zu stören ...
Leg dich nicht mit dem Chaos-Panda an!
Kurze Antwort: Kritische Dienste entlang des Anforderungspfads gezielt ansprechen.
Längere, aber klarere Antwort: Um zu verstehen, wo man mit dem Experimentieren mit Chaos beginnen sollte, achten Sie auf drei Bereiche:
- Betrachten Absturzhistorie und Muster erkennen;
- Entscheiden über Kritische Abhängigkeiten;
- Verwenden Sie das sogenannte Selbstüberschätzungseffekt.
Es ist lustig, aber dieser Teil könnte genauso gut heißen „Eine Reise zur Selbstfindung und Erleuchtung“. Darin beginnen wir mit einigen coolen Instrumenten zu „spielen“.
1. Die Antwort liegt in der Vergangenheit
Wenn Sie sich erinnern, habe ich im ersten Teil das Konzept der Korrektur von Fehlern (COE) vorgestellt – eine Methode, mit der wir unsere Fehler – Fehler in der Technologie, im Prozess oder in der Organisation – analysieren, um deren Ursache(n) zu verstehen und zu verhindern Wiederholung in der Zukunft. Im Allgemeinen sollten Sie hier beginnen.
„Um die Gegenwart zu verstehen, muss man die Vergangenheit kennen.“ — Carl Sagan
Sehen Sie sich die Fehlerhistorie an, kennzeichnen Sie sie im COE oder bei Post-Mortem-Analysen und klassifizieren Sie sie. Identifizieren Sie häufige Muster, die häufig zu Problemen führen, und stellen Sie sich für jeden COE die folgende Frage:
„Hätte dies durch Fehlerinjektion vorhergesagt und somit verhindert werden können?“
Ich erinnere mich an einen Misserfolg zu Beginn meiner Karriere. Es hätte leicht verhindert werden können, wenn wir ein paar einfache Chaos-Experimente durchgeführt hätten:
Unter normalen Bedingungen reagieren Back-End-Instanzen auf Integritätsprüfungen von ). ELB verwendet diese Prüfungen, um Anfragen an fehlerfreie Instanzen umzuleiten. Wenn sich herausstellt, dass eine Instanz „ungesund“ ist, sendet ELB keine Anfragen mehr an sie. Eines Tages, nach einer erfolgreichen Marketingkampagne, stieg das Traffic-Volumen und die Backends begannen, langsamer als gewöhnlich auf Gesundheitschecks zu reagieren. Es sollte gesagt werden, dass diese Gesundheitskontrollen durchgeführt wurden , d.h. der Zustand der Abhängigkeiten wurde überprüft.
Für eine Weile war jedoch alles in Ordnung.
Dann begann eine der Instanzen, bereits unter ziemlich stressigen Bedingungen, mit der Ausführung einer unkritischen, regulären ETL-Cron-Aufgabe. Durch die Kombination aus hohem Datenverkehr und Cronjob stieg die CPU-Auslastung auf nahezu 100 %. Die CPU-Überlastung verlangsamte die Reaktionen auf Integritätsprüfungen weiter, sodass der ELB zu dem Schluss kam, dass bei der Instanz Leistungsprobleme auftraten. Wie erwartet stellte der Balancer die Verteilung des Datenverkehrs ein, was wiederum zu einer erhöhten Belastung der verbleibenden Instanzen in der Gruppe führte.
Plötzlich scheiterten auch alle anderen Instanzen an der Gesundheitsprüfung.
Das Starten einer neuen Instanz erforderte das Herunterladen und Installieren von Paketen und dauerte viel länger, als der ELB brauchte, um sie einzeln in der Autoscaling-Gruppe zu deaktivieren. Es ist klar, dass der gesamte Prozess bald einen kritischen Punkt erreichte und die Anwendung abstürzte.
Dann haben wir für immer die folgenden Punkte verstanden:
- Die Installation von Software beim Erstellen einer neuen Instanz dauert lange; es ist besser, dem unveränderlichen Ansatz den Vorzug zu geben .
- In schwierigen Situationen sollten Reaktionen auf Gesundheitschecks und ELBs Vorrang haben – das Letzte, was Sie wollen, ist, den verbleibenden Fällen das Leben zu erschweren.
- Das lokale Zwischenspeichern von Gesundheitsprüfungen hilft sehr (sogar für ein paar Sekunden).
- Führen Sie in einer schwierigen Situation keine Cron-Tasks und andere unkritische Prozesse aus – sparen Sie Ressourcen für die wichtigsten Aufgaben.
- Verwenden Sie bei der automatischen Skalierung kleinere Instanzen. Eine Gruppe von 10 kleinen Exemplaren ist besser als eine Gruppe von 4 großen; Fällt eine Instanz aus, werden im ersten Fall 10 % des Datenverkehrs auf 9 Punkte verteilt, im zweiten Fall 25 % des Datenverkehrs auf drei Punkte.
somit Hätte man dies vorhersehen und daher durch die Einführung des Problems verhindern können?
Ja, und zwar in mehrfacher Hinsicht.
Erstens durch Simulieren einer hohen CPU-Auslastung mit Tools wie oder :
❯ stress-ng --matrix 1 -t 60s
Stress-ng
Zweitens durch Überlastung der Instanz mit und andere ähnliche Dienstprogramme:
❯ wrk -t12 -c400 -d20s http://127.0.0.1/api/health
Die Experimente sind relativ einfach, können aber gute Denkanstöße liefern, ohne den Stress eines echten Misserfolgs durchmachen zu müssen.
Aber Hören Sie hier nicht auf. Versuchen Sie, den Absturz in einer Testumgebung zu reproduzieren und überprüfen Sie Ihre Antwort auf die Frage „Hätte dies vorhersehen und somit durch die Einführung eines Fehlers verhindert werden können?" Dies ist ein Mini-Chaos-Experiment innerhalb eines Chaos-Experiments, um Annahmen zu testen, das jedoch mit einem Misserfolg beginnt.
War es ein Traum oder ist es wirklich passiert?
Studieren Sie also die Fehlergeschichte und analysieren Sie sie COE, taggen und klassifizieren Sie sie nach „Trefferradius“ – genauer gesagt nach der Anzahl der betroffenen Kunden – und suchen Sie dann nach Mustern. Fragen Sie sich, ob dies durch die Einführung des Problems vorhersehbar und hätte verhindert werden können. Überprüfe deine Antwort.
Wechseln Sie dann zu den gängigsten Mustern mit der größten Reichweite.
2. Erstellen Sie eine Abhängigkeitskarte
Nehmen Sie sich einen Moment Zeit, um über Ihre Bewerbung nachzudenken. Gibt es eine klare Karte seiner Abhängigkeiten? Wissen Sie, welche Auswirkungen sie haben, wenn es zu einem Ausfall kommt?
Wenn Sie mit dem Code Ihrer Anwendung nicht sehr vertraut sind oder dieser sehr umfangreich geworden ist, kann es schwierig sein, zu verstehen, was der Code tut und welche Abhängigkeiten er hat. Das Verständnis dieser Abhängigkeiten und ihrer möglichen Auswirkungen auf die Anwendung und Benutzer ist entscheidend, um zu wissen, wo man mit Chaos Engineering beginnen soll: Der Ausgangspunkt ist die Komponente mit dem größten Wirkungsradius.
Das Erkennen und Dokumentieren von Abhängigkeiten nennt sich „Erstellen einer Abhängigkeitskarte» (Abhängigkeitszuordnung). Dies erfolgt in der Regel für Anwendungen mit einer großen Codebasis mithilfe von Code-Profiling-Tools. (Code-Profilierung) und Instrumentierung (Instrumentierung). Sie können eine Karte auch erstellen, indem Sie den Netzwerkverkehr überwachen.
Allerdings sind nicht alle Abhängigkeiten gleich (was den Prozess zusätzlich verkompliziert). Manche kritisch, andere - sekundär (zumindest theoretisch, da Abstürze häufig auf Probleme mit Abhängigkeiten zurückzuführen sind, die als unkritisch angesehen wurden).
Ohne kritische Abhängigkeiten kann der Dienst nicht funktionieren. Unkritische Abhängigkeiten“sollte nicht» um den Service im Falle eines Sturzes zu beeinflussen. Um Abhängigkeiten zu verstehen, müssen Sie die von Ihrer Anwendung verwendeten APIs genau kennen. Dies kann viel schwieriger sein, als es scheint – zumindest bei großen Anwendungen.
Gehen Sie zunächst alle APIs durch. Markieren Sie das Meiste bedeutsam und kritisch. Nehmen Abhängigkeiten Schauen Sie es sich aus dem Code-Repository an Verbindungsprotokolle, dann ansehen Dokumentation (Natürlich, wenn es existiert – sonst hast du es immer nochоgrößere Probleme). Verwenden Sie die Tools, um Profilierung und Rückverfolgung, externe Anrufe herausfiltern.
Sie können Programme wie verwenden netstat – ein Befehlszeilenprogramm, das eine Liste aller Netzwerkverbindungen (aktive Sockets) im System anzeigt. Um beispielsweise alle aktuellen Verbindungen aufzulisten, geben Sie Folgendes ein:
❯ netstat -a | more
In AWS können Sie verwenden (Flussprotokolle) VPC ist eine Methode, mit der Sie Informationen über den IP-Verkehr zu oder von Netzwerkschnittstellen in einer VPC sammeln können. Solche Protokolle können auch bei anderen Aufgaben hilfreich sein – beispielsweise beim Finden einer Antwort auf die Frage, warum bestimmter Datenverkehr die Instanz nicht erreicht.
Sie können auch verwenden . Mit Röntgen erhalten Sie detaillierte, „ultimative“ (Ende zu Ende) Überblick über Anfragen, während sie sich durch die Anwendung bewegen, und erstellt außerdem eine Karte der zugrunde liegenden Komponenten der Anwendung. Sehr praktisch, wenn Sie Abhängigkeiten identifizieren müssen.
AWS-Röntgenkonsole
Eine Netzwerkabhängigkeitskarte ist nur eine Teillösung. Ja, es zeigt, welche Anwendung mit welcher kommuniziert, aber es gibt noch andere Abhängigkeiten.
Viele Anwendungen verwenden DNS, um eine Verbindung zu Abhängigkeiten herzustellen, während andere möglicherweise die Diensterkennung oder sogar fest codierte IP-Adressen in Konfigurationsdateien (z. B. /etc/hosts).
Sie können zum Beispiel erstellen über iptables und sehen, was kaputt geht. Geben Sie dazu den folgenden Befehl ein:
❯ iptables -I OUTPUT -p udp --dport 53 -j REJECT -m comment --comment "Reject DNS"
Schwarzes Loch im DNS
Wenn der /etc/hosts oder andere Konfigurationsdateien finden Sie IP-Adressen, von denen Sie nichts wissen (ja, das passiert leider auch), können Sie wieder zur Rettung kommen iptables. Nehmen wir an, Sie haben es entdeckt 8.8.8.8 und weiß nicht, dass dies die öffentliche DNS-Serveradresse von Google ist. Mit Hilfe iptables Mit den folgenden Befehlen können Sie den eingehenden und ausgehenden Datenverkehr zu dieser Adresse blockieren:
❯ iptables -A INPUT -s 8.8.8.8 -j DROP -m comment --comment "Reject from 8.8.8.8"
❯ iptables -A OUTPUT -d 8.8.8.8 -j DROP -m comment --comment "Reject to 8.8.8.8"
Zugang schließen
Die erste Regel verwirft alle Pakete vom öffentlichen DNS von Google: ping funktioniert, aber Pakete werden nicht zurückgegeben. Die zweite Regel leitet alle von Ihrem System ausgehenden Pakete an das öffentliche DNS von Google weiter – als Reaktion auf ping wir bekommen Der Betrieb nicht zulässig.
Hinweis: In diesem speziellen Fall wäre die Verwendung besser whois 8.8.8.8, aber das ist nur ein Beispiel.
Wir können noch tiefer in die Materie vordringen, denn alles, was TCP und UDP verwendet, hängt tatsächlich auch von IP ab. In den meisten Fällen ist IP an ARP gebunden. Vergessen Sie nicht die Firewalls...
Wenn du die rote Pille nimmst, bleibst du im Wunderland und ich zeige dir, wie tief das Kaninchenloch reicht.
Ein radikalerer Ansatz ist trennen Fahre ein Auto nach dem anderen und schau, was kaputt ist ... werde zum „Chaos-Affen“. Natürlich sind viele Produktionssysteme nicht für einen solchen Brute-Force-Angriff ausgelegt, aber er kann zumindest in einer Testumgebung ausprobiert werden.
Die Erstellung einer Abhängigkeitskarte ist oft ein sehr langwieriges Unterfangen. Ich habe kürzlich mit einem Kunden gesprochen, der fast zwei Jahre damit verbracht hat, ein Tool zu entwickeln, das halbautomatisch Abhängigkeitskarten für Hunderte von Microservices und Befehlen generiert.
Das Ergebnis ist jedoch äußerst interessant und nützlich. Sie erfahren viel über Ihr System, seine Abhängigkeiten und Abläufe. Seien Sie auch hier geduldig: Die Reise selbst ist das Wichtigste.
3. Hüten Sie sich vor Selbstüberschätzung
„Wer wovon träumt, glaubt daran.“ — Demosthenes
Hast du jemals gehört von Selbstüberschätzungseffekt?
Laut Wikipedia ist der Overconfidence-Effekt „eine kognitive Verzerrung, bei der das Vertrauen einer Person in ihre Handlungen und Entscheidungen deutlich größer ist als die objektive Genauigkeit dieser Urteile, insbesondere wenn das Maß an Vertrauen relativ hoch ist.“
Basierend auf Instinkt und Erfahrung...
Meiner Erfahrung nach ist diese Verzerrung ein guter Hinweis darauf, wo man mit Chaos Engineering beginnen sollte.
Hüten Sie sich vor dem übermütigen Bediener:
Charlie: „Das Ding ist seit fünf Jahren nicht mehr heruntergefallen, alles ist in Ordnung!“
Absturz: „Warte... ich bin bald da!“
Voreingenommenheit als Folge übermäßigen Selbstvertrauens ist aufgrund der verschiedenen Faktoren, die sie beeinflussen, eine heimtückische und sogar gefährliche Sache. Dies gilt insbesondere dann, wenn Teammitglieder ihr ganzes Herzblut in eine Technologie gesteckt oder viel Zeit damit verbracht haben, sie zu „reparieren“.
Zusammenfassen
Die Suche nach einem Ausgangspunkt für Chaos Engineering bringt immer mehr Ergebnisse als erwartet, und Teams, die zu schnell anfangen, Dinge kaputt zu machen, verlieren das globalere und interessantere Wesen von (Chaos-)Maschinenbau - kreative Anwendung wissenschaftliche Methoden и empirische Evidenz für den Entwurf, die Entwicklung, den Betrieb, die Wartung und die Verbesserung von (Software-)Systemen.
Damit ist der zweite Teil abgeschlossen. Bitte schreiben Sie Bewertungen, tauschen Sie Meinungen aus oder klatschen Sie einfach in die Hände . Im nächsten Teil I wirklich Ich werde Werkzeuge und Methoden zur Einführung von Fehlern in Systemen betrachten. Bis!
PS vom Übersetzer
Lesen Sie auch auf unserem Blog:
- «";
- «";
- «";
- «".
Source: habr.com