Ein Ausfall in der Produktion ist keine gute Gelegenheit zum Üben. Bis das Team koordiniert reagiert, Kommunikationswege klar sind und Rollback-Prozeduren wie geplant funktionieren, ist wertvolle Zeit verloren. Game Days sind der Versuch, genau das vorher zu durchdenken und zu üben – unter kontrollierten Bedingungen, bevor es ernst wird.
Was ist ein Game Day?
Ein Game Day – auch als Fire Drill, Chaos Day oder Resilience Test bezeichnet – ist ein geplantes, zeitlich begrenztes Experiment, bei dem ein Team bewusst Fehler in eine Systemumgebung einführt und anschließend beobachtet, wie das System und das Team reagieren. Der Begriff stammt aus der frühen SRE-Praxis bei Unternehmen wie Google und Amazon, die erkannt haben: Systeme verhalten sich unter Druck anders als erwartet, und Teams brauchen Übung, um im Ernstfall effektiv zu reagieren.
Das Ziel ist nicht Chaos um des Chaos willen. Es geht darum, Schwachstellen zu finden, bevor sie in der Produktion sichtbar werden, und Prozesse zu testen, bevor sie gebraucht werden.
Game Days und Chaos Engineering: Was ist der Unterschied?
Chaos Engineering bezeichnet das breitere Konzept des systematischen Experimentierens an laufenden Systemen, um Vertrauen in deren Resilienz aufzubauen. Game Days sind eine strukturiertere, stärker auf das Team fokussierte Variante – mit klar definierten Zielen, einer festgelegten Zeitbox und einem dedizierten Moderationsteam.
Chaos Engineering in der ursprünglichen Netflix-Tradition läuft oft kontinuierlich und automatisiert in der Produktion. Game Days dagegen sind bewusst gesetzte Events: mit Vorbereitung, Durchführung und Nachbereitung. Beide Ansätze ergänzen sich sinnvoll und adressieren unterschiedliche Lernbedürfnisse.
Typische Szenarien in einem Game Day
Was konkret simuliert wird, hängt von den bekannten Schwachstellen und Lernzielen des Teams ab. Klassische Szenarien sind:
- Instanzausfall: Ein oder mehrere Server werden unerwartet beendet. Wie schnell erkennt das Monitoring den Ausfall? Startet die Anwendung automatisch neu?
- Datenbankausfall: Die primäre Datenbankinstanz wird gestoppt. Greift das Failover? Wie lange dauert es, bis der Dienst wieder vollständig verfügbar ist?
- Netzwerkpartitionierung: Dienste können temporär nicht miteinander kommunizieren. Entstehen Datenverluste? Laufen Queues voll?
- Latenzinjektion: Externe APIs antworten bewusst mit hoher Latenz. Halten Circuit Breaker, oder entstehen Cascading Failures?
- Schlüsselrotation: API-Keys werden gewechselt. Konfigurieren sich Services automatisch neu, oder entstehen Ausfälle?
- On-Call-Simulation: Das gesamte Incident-Response-Prozedere wird durchlaufen – Alert, Eskalation, Kommunikation, Postmortem.
Einen Game Day vorbereiten
Ein Game Day ohne gute Vorbereitung ist ein unkontrolliertes Experiment. Folgende Elemente sind entscheidend:
Klares Ziel definieren
Was soll der Game Day zeigen? Jede Session braucht eine konkrete Hypothese: „Wir glauben, dass unser Load Balancer einen Pod-Ausfall innerhalb von 30 Sekunden ausgleicht." Oder: „Wir wollen wissen, ob unser On-Call-Team nach einem Alert innerhalb von zehn Minuten koordiniert kommuniziert." Ohne klare Hypothese fehlt der Maßstab für Erfolg oder Misserfolg.
Umgebung und Zeitpunkt auswählen
Anfänger starten in Staging oder einer dedizierten Testumgebung. Fortgeschrittene Teams führen Game Days in der Produktion durch – mit sorgfältiger Planung, expliziten Rollback-Optionen und zu Zeiten mit niedrigem Traffic, um die Auswirkungen auf Nutzer zu begrenzen.
Rollback-Plan bereithalten
Für jeden injizierten Fehler muss klar sein, wie er rückgängig gemacht wird und wer die Entscheidung zum Abbruch treffen darf. Explizite Abbruchkriterien – etwa „wenn die Fehlerrate 10 % überschreitet" – verhindern, dass ein Experiment außer Kontrolle gerät.
Beobachter benennen
Während das Team reagiert, beobachten Moderatoren das Geschehen unabhängig: Wie kommuniziert das Team? Welche Monitoring-Panels werden geöffnet? Welche Schritte kommen zu spät? Diese Außenperspektive ist gold wert für das anschließende Postmortem.
Durchführung: Was am Tag selbst passiert
Ein typischer Game Day läuft in klar getrennten Phasen ab:
- Briefing (15–30 Min.): Ziele, Szenarien und Regeln werden erläutert. In manchen Formaten wissen die reagierenden Engineers das genaue Szenario bewusst nicht im Voraus, um echte Reaktionen zu erzeugen.
- Fehlerinjektion: Das Moderationsteam führt die geplanten Aktionen aus – manuell oder über Werkzeuge wie Gremlin, Chaos Monkey, Litmus oder AWS Fault Injection Service.
- Reaktionsphase: Das Team reagiert wie im Ernstfall. Alarme kommen – oder kommen nicht. Prozesse greifen – oder versagen.
- Stopp und Stabilisierung: Nach der definierten Zeitbox oder nach Erreichen eines Abbruchkriteriums wird der Normalzustand wiederhergestellt und verifiziert.
- Hot-Retrospektive (30–60 Min.): Direkt im Anschluss: Was ist aufgefallen? Was hat überrascht? Was hat gut funktioniert und was nicht?
Das Postmortem nach dem Game Day
Ein Game Day ohne strukturiertes Nachbereiten ist nur halb so wertvoll. Das Postmortem dokumentiert Beobachtungen, priorisiert Findings und leitet konkrete, zugeordnete Maßnahmen ab. Wichtig dabei: keine Schuldzuweisungen. Game Days sind blame-free Übungen – das Ziel ist Systemverbesserung, nicht Fehlersuche bei einzelnen Personen.
Typische Erkenntnisse nach einem Game Day:
- Fehlende oder zu unspezifische Monitoring-Alerts
- Runbooks, die veraltet oder unvollständig sind
- Kommunikationswege, die unter Druck nicht funktionieren
- Failover-Mechanismen, die deutlich länger brauchen als angenommen
- Monitoring-Dashboards, die das Team im Ernstfall nicht kennt oder nicht findet
- Unklare Zuständigkeiten bei Eskalationen
Welche Werkzeuge Teams nutzen
Die Werkzeugauswahl für Fehlerinjektionen reicht von einfach bis umfangreich:
- Gremlin: Kommerzielles Chaos-Engineering-Tool mit breitem Fehlerkatalog – CPU-Stress, Netzwerkverzögerung, Ressourcenknappheit.
- Chaos Monkey (Netflix): Das Original – beendet zufällig Instanzen in der Produktion und zwingt Teams zur Resilienz.
- Litmus: Open-Source-Tool für Kubernetes-Umgebungen mit einem großen Katalog an Chaos-Experimenten.
- AWS Fault Injection Service (FIS): Cloud-native Lösung für AWS-Infrastruktur mit tiefergehender Integration in EC2, EKS und RDS.
Für einfache Game Days ohne spezielle Werkzeuge reichen oft manuelle Eingriffe: einen Pod per kubectl löschen, eine Netzwerkregel setzen oder einen Prozess beenden. Der Wert liegt nicht im Werkzeug, sondern im strukturierten Lernen daraus.
Wie oft sollten Game Days stattfinden?
Eine pauschale Antwort gibt es nicht. Viele Teams starten mit einem Game Day pro Quartal und steigern die Frequenz, wenn die Prozesse gefestigt sind. Wichtiger als Häufigkeit ist Kontinuität: Ein Game Day pro Jahr, nach dem nichts passiert, ist weniger wertvoll als ein einfacher vierteljährlicher Failover-Test, der tatsächlich zu Verbesserungen führt.
Fazit
Game Days sind kein exklusives Werkzeug großer Tech-Unternehmen. Auch kleine SRE-Teams oder DevOps-Teams können regelmäßige, fokussierte Resilienz-Übungen durchführen – angefangen mit einem einfachen Staging-Failover-Test bis hin zu strukturierten Produktions-Experimenten. Wer nie geübt hat, wie sein Team auf einen Ausfall reagiert, erfährt es beim nächsten echten Ausfall – ungeplant und unter Druck.
Die wichtigste Erkenntnis aus Game Days ist fast immer dieselbe: Nicht das System, sondern die Prozesse rund um das System sind die eigentliche Schwachstelle. Und Prozesse lassen sich trainieren.
Bildquelle: Pexels
Quellen: Google SRE Book (Beyer et al.), Netflix Tech Blog zu Chaos Engineering, Gremlin Chaos Engineering Guide, DORA State of DevOps Report 2024
