Inhalt
- Vorbereitung auf den Ausfall
- Die nächsten Schritte
- Keine Bugs, kein Stress - Ihre schrittweise Anleitung zur Erstellung lebensverändernder Software, ohne Ihr Leben zu zerstören
- Lernen und Verbessern durch Übungen
Quelle: pressureUA / iStockphoto
Wegbringen:
Moderne Systeme müssen mit Chaos umgehen können, um Ausfallzeiten zu vermeiden. Deshalb ist es wichtiger denn je, Systeme gründlich zu testen und ihre Ausfallsicherheit sicherzustellen.
Trotz unserer größten Anstrengungen, diese zu vermeiden, sind IT-Vorfälle ein unvermeidlicher Teil unserer Arbeit - und es wird immer schwieriger, sich vor geschäftsbeeinträchtigenden Ausfallzeiten zu schützen. Systeme sind heutzutage eng miteinander verbunden und werden immer komplexer, und mit mehr beweglichen Teilen steigen die Chancen, dass etwas schief geht.
Dies ist einer der Gründe, warum immer mehr Unternehmen auf Microservices zurückgreifen, um die Serviceverfügbarkeit zu erhöhen und die Ausfallsicherheit zu verbessern. Dies sind zwar hervorragende Voraussetzungen für das Brechen monolithischer Anwendungen, sie können jedoch auch das Ausfallrisiko erhöhen - es sei denn, sie wurden ausdrücklich unter dem Gesichtspunkt der Belastbarkeit entwickelt.
Vorbereitung auf den Ausfall
Angesichts der inhärent chaotischen Natur verteilter Systeme sollten Dienste nicht nur entwickelt werden, um einen Ausfall zu antizipieren, sondern um sich bei einem Ausfall automatisch zu erholen. Dies bedeutet, dass Sie regelmäßig Fehler auslösen müssen, um sicherzustellen, dass Ihre Systeme dem Chaos gewachsen sind, ohne den Service für Endkunden zu beeinträchtigen. Um dies zu erreichen, müssen Sie in der Lage sein, produktionsähnlichen Datenverkehr in Testumgebungen zu simulieren.
Natürlich ist es eine gute Idee, die Belastbarkeit zu testen, bevor Änderungen an der Produktion vorgenommen werden. Wenn Sie dies nicht tun, können Sie nicht überprüfen, ob Ihre Dienste sowohl durchschnittliche als auch Spitzenlasten unterstützen. In der Tat ist es am sichersten, sicherzustellen, dass Ihr Produkt die doppelte Höchstmenge verarbeiten kann, ohne dass eine Skalierung erforderlich ist.
Wenn es um Ausfallsicherheitstests geht, sollten sich die richtigen Tools nicht zu sehr darum kümmern, wie Anforderungen behandelt werden, nur dass sie letztendlich die richtigen Auswirkungen haben. Denken Sie daran, dass der Eingabedienst unter bestimmten Bedingungen möglicherweise keine Anforderung an den Rest des Systems weiterleitet, den Fehler jedoch nicht meldet. Gehen Sie kein Risiko ein, indem Sie sicherstellen, dass die End-to-End-Validierung tatsächlich stattfindet. (Weitere Informationen finden Sie unter Tech Failures: Können wir mit ihnen leben?)
Die nächsten Schritte
Nachdem Sie verstanden haben, wie sich Dienste unter Last verhalten, müssen Sie mit der Einführung der Fehlerereignisse beginnen. Wie bei allen Softwaretests ist es am besten, über automatisierte Tools zu verfügen, mit denen Sie Szenarien einfach und schnell reproduzieren und komplexe Ereignisse koordinieren können, die sich auf verschiedene Infrastrukturtechnologien auswirken. Abgesehen von der Möglichkeit, Korrekturen und Änderungen an den Diensten zu überprüfen, können Sie auf diese Weise zufällige Fehlerszenarien in jeder Umgebung und nach einem Zeitplan ausführen.
Wichtige Fehlerereignisse hängen weitgehend vom Layout Ihrer Services ab. Sie können sie formulieren, indem Sie spezifische Fragen stellen, die für Sie relevant sind. Welche Auswirkungen hat es beispielsweise für Benutzer des Frontends, wenn eine Datenbank für einen bestimmten Zeitraum nicht mehr erreichbar ist? Können diese Benutzer noch auf der Web-Benutzeroberfläche navigieren? Können sie weiterhin Aktualisierungen ihrer Informationen herausgeben, und werden diese Aktualisierungen korrekt verarbeitet, wenn die Datenbank wieder erreichbar ist?
Wenn Sie mehrere Microservices ausführen, können Sie sich erkundigen, ob ein globaler Ausfall auftritt, wenn ein einzelner Dienst abstürzt. Oder wenn Sie einen Warteschlangenmechanismus zum Puffern der Kommunikation zwischen Diensten haben, was passiert, wenn der Verbraucherdienst (oder die Dienste) nicht mehr funktioniert? Können Benutzer weiterhin mit Ihrer Anwendung arbeiten? Und wie lange haben Sie bei einer durchschnittlichen Auslastung Zeit, bis die Warteschlangen überlaufen und Sie anfangen, s zu verlieren?
Keine Bugs, kein Stress - Ihre schrittweise Anleitung zur Erstellung lebensverändernder Software, ohne Ihr Leben zu zerstören
Sie können Ihre Programmierkenntnisse nicht verbessern, wenn sich niemand um die Softwarequalität kümmert.
Nachdem Sie einige wichtige Fragen zu Ihrer Infrastruktur definiert haben, können Sie verschiedene Möglichkeiten auflisten, um diese Fehler zu simulieren. Möglicherweise reicht es aus, einen bestimmten Dienst oder einen Datenbankserver anzuhalten. Möglicherweise möchten Sie den Hauptthread eines Dienstes blockieren, um ein Deadlock zu simulieren, während sein Container noch reagiert und ausgeführt wird. Möglicherweise möchten Sie Regeln in Ihr Netzwerk einfügen, um den Datenverkehr zwischen bestimmten Diensten zu blockieren. In Linux-Umgebungen können Sie Tools wie "tc" verwenden, um Netzwerksituationen wie hohe Latenz, verworfene, beschädigte oder duplizierte Pakete zu emulieren. (Es kann wichtig sein, Benutzer in das Testen einzubeziehen. Lesen Sie mehr in 4 Gründen, warum Endbenutzer vor dem UAT am Testen teilnehmen müssen.)
Lernen und Verbessern durch Übungen
Einer der wertvollsten Aspekte beim Erstellen von Fehlerszenarien besteht darin, dass alle potenziellen Fehlerquellen des Systems aufgezeigt werden und so der Weg zur Selbstheilungslogik beschritten werden kann. Ihr Team führt die Schritte zur manuellen Wiederherstellung von Diensten durch - eine großartige Übung, um zu bestätigen, dass es in SLAs dazu in der Lage ist. An der Automatisierung dieses Wiederherstellungsprozesses kann gearbeitet werden. In der Zwischenzeit können Sie sich jedoch darauf verlassen, dass Ihr Team den Prozess der Wiederherstellung der Dienste erfolgreich durchlaufen hat. Indem Sie die Fehlerszenarien zufällig und regelmäßig gestalten und nicht alle Details des Laufs offenlegen, können Sie auch die Ermittlung und Diagnose in den Drill einbeziehen - was schließlich ein kritischer Teil der SLAs ist.
Das Chaos Engineering nimmt die Komplexität des Systems als gegeben an, testet sie durch Simulation neuer und verrückter Bedingungen und beobachtet, wie das System reagiert. Dies ist die Aufgabe der Data Engineering-Teams, das System neu zu entwerfen und zu konfigurieren, um eine höhere Ausfallsicherheit zu erzielen. Es gibt so viele Möglichkeiten, neue und nützliche Dinge zu lernen. Beispielsweise finden Sie möglicherweise Fälle, in denen Dienste nicht aktualisiert werden, wenn sich nachgelagerte Dienste geändert haben, oder Bereiche, in denen die Überwachung vollständig fehlt. Es gibt viele aufregende Möglichkeiten, um Ihr Produkt widerstandsfähiger und robuster zu machen!