Absichtlich Dinge kaputt machen: Chaos Engineering

Jedes System hat Schwächen, von denen niemand weiß. Eine Auszeit, die zu lang ist. Ein Wiederversuch, der ein kleines Problem in ein großes verwandelt. Ein Failover, der vor zwei Jahren beim Testen funktionierte und seitdem nie mehr. Normalerweise entdecken Sie sie während eines echten Ausfalls, zu dem schlechtesten möglichen Zeitpunkt.

Chaos Engineering geht darum, Schwächen absichtlich zu finden, auf kontrollierte Weise, bevor sie Probleme verursachen.

Die Idee

Netflix machte Chaos Engineering berühmt mit Chaos-Affe, ein Tool, das zufällig Produktionsserver beendete. Die Idee klang verrückt, aber die Logik war einfach: Wenn Server sowieso ausfallen, stellen Sie sicher, dass Ihr System damit umgeht, indem Sie aus einem Ausfall ein normales, alltägliches Ereignis machen.

Heute ist die Praxis sorgfältiger und wissenschaftlicher als zufällige Zerstörung:

1. Feststand definierenWie sieht "normal arbeiten" aus? Normalerweise mit Messwerten wie Fehlerrate, Latenz oder Bestellungen pro Minute gemessen.
2. Eine Hypothese bilden: "Wenn eine Datenbank-Replik ausfällt, bleiben die Fehlerraten unter 0,5% und die App erholt sich innerhalb von 30 Sekunden".
3. Einführung eines Fehlers- Töte die Replik.
4. BeobachtenHat der Steady-State gehalten?
5. Lernen und reparierenWenn nicht, haben Sie eine Schwäche gefunden, bevor sie einen echten Ausfall verursacht hat.

Chaos Engineering geht nicht darum, Dinge zu brechen. Es geht darum zu beweisen, dass dein System einen Schlag ertragen kann und herauszufinden, wo er nicht kann.

Was für Misserfolge?

Gemeinsame Experimente:

• Tötung von Kapseln oder Knoten: wird Kubernetes korrekt umgeschrieben? Verbinden sich die Kunden wieder?
• Netzwerklatenz hinzufügenWas passiert, wenn eine Abhängigkeit langsamer wird, nicht nach unten? (Oft schlimmer als niedergeschlagen zu sein.)
• Verringerung des Netzwerkverkehrs zwischen Diensten oder einer externen API.
• Füllplatten oder Abgasspeicher und CPU.
• Eine gesamte Verfügbarkeitszone wird nicht eingeschaltetVerlagern sich die Verkehrsströme?
• DNS-Systemen brechen oder Zertifikate.
• Erstellen einer Abhängigkeit zurück Fehler.

Dein erster Spieltag.

A Spieltag ist eine geplante Sitzung, bei der ein Team gemeinsam Chaos-Experimente durchführt. Das ist der beste Weg, um zu beginnen.

Wie ich eine führen würde:

1. Wählen Sie eine nichtproduktive Umgebung Das ist fast wie eine Produktion, wie eine Inszenierung.
2. Wählen Sie einen Dienst und ein oder zwei Experimente. Zum Beispiel: einen Pod des Checkout-Dienstes abschalten, dann 500 ms Latenzzeit zu seinen Datenbank-Aufrufen hinzufügen.
3. Schreiben Sie die Hypothese auf. für jedes Experiment vor Beginn.
4. Alle in einen Raum oder rufen Sie an.Die Dienstleister, jemand, der die Dashboards beobachtet, jemand, die das Experiment durchführt.
5. Führen Sie das Experiment durch, beobachten Sie die Kennzahlen, machen Sie Notizen.
6. - Ich habe einen Stoppknopf .Sie wissen, wie man das Experiment sofort beendet.
7. SchriftstückWas haben wir erwartet, was ist passiert, was werden wir reparieren?

Der erste Spieltag zeigt oft etwas Unerwartetes: eine fehlende Warnung, ein verwirrendes Armaturenbrett, ein veraltetes Spielbuch oder ein erneuter Sturm. Das allein macht es wert.

Ausprobierte Werkzeuge

• Chaos Mesh (CNCF): ein natives Tool für Kubernetes mit einer schönen Benutzeroberfläche. Experimente sind Kubernetes-Ressourcen: Kapsel-Tod, Netzwerkverzögerung, Stress, I/O-Fehler, Zeitverschiebung und mehr.
• Das ist ein Chaos . (CNCF): Kubernetes-Chaos mit einem großen Hub aus fertigen Experimenten und Workflows.
• AWS-Fehlinjektionsdienst und Azure Chaos Studio: Managed Services zur Einspeisung von Ausfällen in Cloud-Ressourcen, einschließlich Störungen auf AZ-Ebene.
• Gremlin: eine kommerzielle Plattform mit Sicherheitskontrollen und einer guten Benutzeroberfläche.
• Toxiproxy: ein einfaches Proxy zur Simulation von Netzbedingungen bei Tests.

Ein Chaos Mesh Experiment, das Latenzzeit erhöht:

apiVersion: chaos-mesh.org/v1alpha1
kind: NetworkChaos
metadata:
  name: checkout-db-latency
  namespace: shop
spec:
  action: delay
  mode: all
  selector:
    namespaces: ["shop"]
    labelSelectors:
      app: checkout
  delay:
    latency: "500ms"
    jitter: "100ms"
  direction: to
  target:
    mode: all
    selector:
      labelSelectors:
        app: orders-db
  duration: "5m"

Wir beginnen klein, bleiben sicher

• Beginnen Sie mit der Inszenierung, mit kleinem Sprengradius: eine Kapsel, ein Dienst.
• Versuche reversibel machen und zeitlich begrenzt.
• Sie werden genau beobachtet. und abbrechen, wenn die Dinge weiter gehen als erwartet.
• Sagen Sie es den Leuten. Vor allem zuerst.
• Vorsicht , wenn Sie in die Produktion gehen .Die Ergebnisse der Untersuchungen werden in der Regel in einem anderen Fall als in der ersten Studie ermittelt.

Hat es geholfen?

Die Wirkung im Laufe der Zeit messen:

• Anzahl der festgestellten und behobenen Schwachstellen.
• Vorfälle, die durch Fehlermodi verursacht wurden, die Sie bereits getestet hatten (sollten abfallen).
• Erholungszeit bei echten Vorfällen.
• Das Teamvertrauen bei Vorfällen, das schwer zu messen ist, aber sehr real.

Also, sollten Sie es versuchen?

Ja, auch in kleinem Maßstab. Ein Spieltag in der Inszenierung, mit einem einfachen Experiment, lehrt ein Team mehr über ihr System als Monate des Lesens von Architekturdiagrammen.

Ich denke, jedes System hat einen Bruchpunkt. Lieber am ruhigen Dienstagnachmittag als am geschäftigen Samstagabend.

Desly