Ein erster Game Day: ein Chaos-Experiment mit Hypothese, Blast Radius und Abbruchregel

Ziel

An einem gewählten Tag, an dem alle zuschauen, lernen, was passiert, wenn eine Komponente ausfällt, statt es nachts zu erfahren; und dabei zugleich die menschliche Reaktion (Alarme, Runbooks, Rollen) einüben.

Voraussetzungen

Monitoring, das das Steady-State-Signal nahezu in Echtzeit zeigt; eine getestete Rückgängigmachung für den Fehler; ein Eintrag im Änderungskalender und, falls Produktion betroffen ist, ein Hinweis auf der Statusseite; eine moderierende Person, die nicht zu den Reagierenden gehört.

Schritte

1. Einen plausiblen und umkehrbaren Fehler wählen: eine Replika stoppen, den Port einer Abhängigkeit blockieren, eine Queue füllen, einen Cache verfallen lassen, in Staging eine Zugangsberechtigung widerrufen. Nicht «die Datenbank lahmlegen».
2. Den stabilen Zustand definieren als, in den Worten der Principles of Chaos Engineering, eine messbare Ausgabegrösse des Systems, die normales Verhalten anzeigt (Erfolgsquote von Anfragen, abgeschlossene Checkouts pro Minute), und die Hypothese formulieren: «Dieses Signal bleibt in seinem normalen Band, während Replika 2 gestoppt ist».
3. Das erwartete Systemverhalten und das erwartete menschliche Verhalten getrennt festhalten: welcher Alarm auslöst und innerhalb welcher Zeit, welches Runbook verwendet wird, wer alarmiert wird.
4. Den Blast Radius festlegen (eine Replika, eine Region, ein Bruchteil des Traffics) und die Abbruchbedingung (das Signal verlässt sein Band für mehr als eine festgelegte Anzahl Minuten, oder irgendein für Kunden sichtbarer Fehler), mit dem Rückgängig-Befehl bereit in einem Terminal.
5. Den Start ankündigen, den Fehler injizieren, einen Timer starten. Die moderierende Person hält Zeitstempel fest: Fehler injiziert, erster Alarm, erste menschliche Handlung, Eindämmung, Wiederherstellung. Die Reagierenden handeln wie bei einem echten Alarm; die moderierende Person beantwortet keine Frage, die das Monitoring beantworten könnte.
6. Den Fehler zum geplanten Ende oder bei Abbruch rückgängig machen; den stabilen Zustand überprüfen; bestätigen, dass keine Nacheffekte bestehen (Queues geleert, Verbindungen zurückgesetzt, Alarme gelöscht).
7. Innerhalb einer Stunde ein Debriefing durchführen: Wurde die Hypothese widerlegt? Welcher Alarm hat nicht ausgelöst, welcher Runbook-Schritt war falsch, welches Dashboard fehlte? Massnahmen mit Verantwortlichen festhalten, wie bei einem Postmortem.
8. Ist eine echte Injektion noch nicht vertretbar, dasselbe Szenario zunächst als Tabletop-Übung durchführen. Das SRE-Buch beschreibt das «Wheel of Misfortune»: Eine Spielleitung präsentiert ein Szenario, und das Bereitschaftspaar schildert, was es tun würde, wobei die Gruppe aus jeder Runde lernt.

Erwartetes Ergebnis

Ein schriftlicher Bericht über die tatsächliche Wirkung eines Fehlers, eine kurze Liste gefundener Lücken, und ein Team, das das Ausrufen und Bearbeiten eines Vorfalls ohne echten Ausfall geübt hat.

Grenzen und Prüfbasis

Eine Staging-Umgebung beweist weniger als Produktion, und die Principles plädieren für Produktion, weil sich das Verhalten je nach Umgebung und Traffic unterscheidet; ein erster Durchlauf in Staging ist trotzdem der sicherere Start. Das Protokoll ist eine Synthese der zitierten Quellen; es wird kein Befund aus dessen Durchführung behauptet.