Mitglied werden – KI-Tutor mit vollen Antworten

Training Module

Chaos Engineering Grundlagen

In diesem 140-Minuten-Modul lernt ihr Chaos Engineering als hypothesengetriebene Disziplin kennen, nicht als Synonym für “einfach mal etwas kaputt machen”. Ihr arbeitet die vier Schritte heraus Steady-State-Hypothese, Variablen identifizieren, Experiment mit bewusst begrenztem Blast-Radius und Lernen, und wendet sie danach in zwei Hands-on-Blöcken auf einem selbst gebauten lokalen kind-Cluster an: Zuerst injiziert ihr einen Pod-Ausfall per kubectl delete pod und eine künstliche Netzwerklatenz, danach simuliert ihr CPU-/Memory-Ressourcendruck in einer kleinen Microservices-Fallstudie und trefft die Entscheidung “Experiment abbrechen oder fortsetzen” anhand eines vorher festgelegten Kriteriums. Zum Abschluss ordnet ihr Game Days und eine Reifegrad-Leiter von Dev über Staging bis kontrollierter Produktion ein. Kein Chaos-Mesh-, LitmusChaos- oder Gremlin-Setup: Dieses Grundlagenmodul fährt bewusst den einfachen, abhängigkeitsarmen Weg mit Standard-kubectl, tc und einem Stress-Container, komplett lokal, kein Cloud-Account, keine Kostenwirkung.

Academy Briefing vereinbaren

Oder sofort per Mail an mail@mhm-dl.de

Format

140 Minuten, live (remote oder vor Ort), Input & zwei Hands-on-Blöcke auf einem selbst gebauten kind-Cluster

Teilnehmende

DevOps-Engineers und SRE-nahe Rollen nach “DevOps Betrieb” oder “DevOps Monitoring”, die Resilienz aktiv statt nur reaktiv prüfen wollen

Voraussetzungen

Kein eigener Cloud-Account nötig: der Cluster läuft lokal per kind. Docker, kubectl und kind lokal installiert, Grundkenntnisse Docker/Kubernetes vorausgesetzt.

Warum dieses Training für deine Organisation wirkt

Hypothese statt Zerstörung

Teilnehmende erleben direkt, dass Chaos Engineering mit einer überprüfbaren Steady-State-Hypothese beginnt und nicht mit einem zufälligen Kill-Befehl: ohne Hypothese kein Lernergebnis, nur Zufallsschaden.

Blast-Radius als Entscheidungsdisziplin

In der Ressourcen-Stress-Übung trefft ihr die Entscheidung “Experiment abbrechen oder fortsetzen” anhand eines vorher festgelegten Kriteriums: Blast-Radius-Kontrolle ist eine aktive Entscheidung, nicht eine nachträgliche Entschuldigung.

Einfacher Werkzeugkasten, lokal reproduzierbar

Kein Chaos-Mesh- oder LitmusChaos-Setup: kubectl delete pod, tc für Netzwerklatenz und ein einfacher Stress-Container reichen für die Lernziele dieses Grundlagenmoduls, komplett auf einem selbst gebauten kind-Cluster.

Was Teilnehmende mitnehmen

  • Chaos Engineering als hypothesengetriebene Disziplin erklären: die vier Schritte Steady-State-Hypothese, Variablen identifizieren, Experiment mit begrenztem Blast-Radius, Lernen, sowie die Abgrenzung zu “einfach kaputt machen”.
  • Einen eigenen lokalen kind-Cluster bauen und eine kleine Microservices-Fallstudie (Frontend/Backend) darauf ausrollen.
  • Eine Steady-State-Hypothese formulieren, einen Pod-Ausfall per kubectl delete pod injizieren und beobachten, ob die Hypothese hält oder widerlegt wird.
  • Künstliche Netzwerklatenz per tc/netem simulieren und den Effekt auf die Fallstudie live beobachten.
  • CPU-/Memory-Ressourcendruck mit einem einfachen Stress-Container simulieren, den Blast-Radius bewusst eingrenzen (Dauer, Umfang, Monitoring) und die Entscheidung “Experiment abbrechen oder fortsetzen” anhand eines vorher festgelegten Kriteriums begründen.
  • Game Days als geplante, funktionsübergreifende Chaos-Übung einordnen, inklusive Debrief als Blameless Post Mortem (Rückverweis auf DevOps Betrieb, keine Doppelerklärung).
  • Eine Reifegrad-Leiter von Dev über Staging bis kontrollierter Produktion anwenden und anhand einer Checkliste einschätzen, ob ein System für produktive Chaos-Experimente bereit ist.

Für wen dieses Modul ideal ist

  • • DevOps-Engineers und SRE-nahe Rollen, die nach “DevOps Betrieb” oder “DevOps Monitoring” Resilienz aktiv statt nur reaktiv prüfen wollen
  • • Teams, die Fehlertoleranz bisher nur behaupten und erstmals mit einem begrenzten, kontrollierten Experiment belegen wollen
  • • Alle, die den Unterschied zwischen geplantem Chaos Engineering und ungeplantem Produktionsausfall praktisch statt nur begrifflich verstehen wollen

Rahmendaten

  • • Dauer: 140 Minuten live (remote oder vor Ort)
  • • Format: Input, Live-Demo, zwei Hands-on-Blöcke auf einem selbst gebauten lokalen kind-Cluster
  • • Voraussetzungen: Kein eigener Cloud-Account nötig, Docker/kubectl/kind lokal installiert, Grundkenntnisse Docker/Kubernetes vorausgesetzt

Modulaufbau & Agenda

  1. Konzept (30 min): Chaos Engineering als eigenständige Disziplin, die vier Schritte Steady-State-Hypothese, Variablen identifizieren, Experiment mit begrenztem Blast-Radius, Lernen, Abgrenzung zu “einfach kaputt machen”, Bezug zu Blameless Post Mortem und Error Budget (Rückverweis auf DevOps Betrieb und DevOps Monitoring, keine Doppelerklärung).

  2. Hands-on 1: Pod-Fehlerinjektion (35 min): einen lokalen kind-Cluster bauen, eine kleine Frontend/Backend-Fallstudie ausrollen, eine Steady-State-Hypothese formulieren, einen Backend-Pod per kubectl delete pod löschen und das Verhalten beobachten, danach Netzwerklatenz per tc/netem simulieren, Abgleich mit der Musterlösung.

  3. Hands-on 2: Ressourcen-Stress (35 min): CPU-/Memory-Druck mit einem einfachen Stress-Container in derselben Fallstudie simulieren, Blast-Radius bewusst eingrenzen (Dauer, Umfang, vorab festgelegtes Abbruchkriterium), die Entscheidung “Experiment abbrechen oder fortsetzen” anhand des SLO-Werts aus DevOps Monitoring treffen und begründen, Abgleich mit der Musterlösung.

  4. Transfer & Abschluss (40 min): Game Days als geplante, funktionsübergreifende Übung mit Debrief als Blameless Post Mortem, Reifegrad-Leiter Dev → Staging → kontrollierte Produktion, Checkliste “bereit für Chaos Engineering in Produktion?”, Verweis auf Kubernetes Cluster-Recovery und Kubernetes Multi-Master Disaster Recovery als Anschlussmodule für den Recovery-Teil, den ein Chaos-Experiment aufdeckt.

Abgrenzung: Dieses Modul behandelt bewusst kein Chaos-Mesh-, LitmusChaos- oder Gremlin-Setup (eigenständige Tool-Installationen mit eigenem Betriebsaufwand, nicht Teil dieses Grundlagenmoduls), keine produktive Ausführung eines Experiments (nur Simulation auf dem lokalen Cluster) und keine erneute Herleitung von Blameless Post Mortem oder Error Budget (dafür DevOps Betrieb bzw. DevOps Monitoring). Auch die etcd-/Control-Plane-Wiederherstellung nach einem echten Ausfall wird hier nicht vertieft, dafür die eigenständigen Module Kubernetes Cluster-Recovery und Kubernetes Multi-Master Disaster Recovery.

Hands-on Inhalte (Auszug)

Konzept & Fallstudie

  • Die vier Schritte: Steady State, Hypothese, Experiment, Lernen
  • Eigenen lokalen kind-Cluster mit einer Frontend/Backend-Fallstudie bauen
  • Kein Cloud-Account, keine Kostenwirkung

Pod-Fehlerinjektion

  • Steady-State-Hypothese formulieren und per Beobachtungs-Loop prüfen
  • Backend-Pod per kubectl delete pod löschen, Verhalten beobachten
  • Netzwerklatenz per tc/netem simulieren und wieder entfernen

Ressourcen-Stress

  • CPU-/Memory-Druck mit einem einfachen Stress-Container simulieren
  • Blast-Radius bewusst eingrenzen: Dauer, Umfang, Abbruchkriterium vorab festlegen
  • Entscheidung “abbrechen oder fortsetzen” anhand des SLO-Werts begründen

Transfer

  • Game Days als geplante, funktionsübergreifende Chaos-Übung
  • Reifegrad-Leiter Dev → Staging → kontrollierte Produktion
  • Checkliste “bereit für Chaos Engineering in Produktion?”

Dieses Modul ist Teil unserer Pilotphase. Gemeinsam mit euch definieren wir passende Metriken (z. B. Zeit bis zur ersten begründeten Abbruch-/Fortsetzungsentscheidung, Trefferquote der Steady-State-Hypothesen) und werten sie im Anschluss transparent aus. Ergebnisse veröffentlichen wir, sobald sie belastbar sind.

Bereit, das Modul zu buchen?

Wir passen die Fallstudie und die Experiment-Kriterien auf eure tatsächliche Systemlandschaft an.

Academy Briefing anfragen