Du solltest Prod kaputt machen

Kürzlich habe ich Leute erlebt, die etwas infrage stellen, an das ich fest glaube:

Du verstehst Systeme erst wirklich, wenn du sie kaputt machst und reparierst.

Manche meinen, Production sei heilig, Ausfälle seien schlecht und “Dinge kaputt machen” sei leichtsinnig. Klar, echtes Production-Zerstören ist nie das Ziel. Aber wenn du wirklich verstehen willst, wie sich Systeme unter Druck verhalten (wie sie ausfallen, sich erholen oder heimlich Daten zerstören), dann ist das absichtliche Kaputtmachen in einer sicheren Umgebung einer der besten Lehrer, die du haben kannst.

Ausfall > Theorie

Wenn alles rundläuft, wird dein mentales Modell nie getestet. Du baust einen Service, deployest ihn, und er läuft. Toll. Aber was passiert, wenn:

• die Festplatte vollläuft?
• DNS ausfällt?
• ein container OOM-killed wird?
• deine message queue Events umsortiert?

Wenn du solche Ausfälle noch nie gesehen hast, tut’s beim ersten Mal richtig weh. Hast du sie aber schon absichtlich verursacht (wenn du “failure modes” erkundet hast), bleibst du ruhig, reagierst schnell und bist effektiv.

Failure Modes erkunden

Ich weiß nicht mehr, wo ich zum ersten Mal “failure modes erkunden” gehört habe, aber der Ausdruck blieb hängen.
Er trifft’s perfekt: Bau nicht nur für den Happy Path, sondern schau dir gezielt an, wie alles reagiert, wenn’s nicht rundläuft.

Du brauchst kein Netflix-Chaos-Team und keine fancy Fault-Injection-Tools. Nur Neugier und den Willen, dir die Hände schmutzig zu machen.

Probier mal:

• Container während Last zufällig töten
• Packet loss oder hohe Latenz simulieren
• TLS-Zertifikate ablaufen lassen und beobachten, wie Clients versagen
• Netzwerk-Interfaces abschalten
• Eine DB-Tabelle sperren und schauen, wie Retries oder Timeouts ablaufen
• Deine .env-Datei löschen und die App neu starten

Du wirst überrascht sein, was alles kaputtgeht. Und was erstaunlicherweise durchhält.

Grosse Firmen machen das – und du kannst’s auch

Bei Netflix, Google oder Shopify werden region-wide Outages, API-Timeouts und Kaskadencrashes systematisch simuliert – mit Dashboards, Playbooks und Postmortems.

Das brauchst du nicht.

Du kannst die Chaos Monkey Solo Edition in dev oder staging spielen:

• Mach einen “Break Day”, an dem du Ausfälle ausprobierst
• Schreib ein Shell-Script, das jede Stunde zufällig einen Container killt
• Töte deine Datenbank mitten im Request und guck, welche Logs hochpoppen

Bei sliplane.io testen wir non-kritische Komponenten, um sicherzustellen, dass sie kritische Teile nicht mitziehen. So haben wir mal ein fettes Thundering-Herds-Problem entdeckt, bevor es eskalieren konnte!

Es macht Spaß und ist lehrreich. Trotzdem gilt:

Wo aufhören?

Das Gesetz des abnehmenden Ertrags gilt auch hier.

Hast du einmal gesehen, wie ein “Disk full”-Fehler aussieht, musst du ihn nicht jede Woche simulieren. Und es gibt einen Unterschied zwischen nützlichen Ausfällen und reinem Fantasie-Szenario. Klar, Netflix lässt ganze AWS-Regionen abschmieren, aber für die meisten von uns reichen Host-Ausfälle oder Netzwerk-Partitionen.

Konzentrier dich aufs Wahrscheinliche, nicht aufs Hollywood-Drama.

Druck formt Können

Echte Outages sind nicht nur technisch, sie sind psychologisch.

Plötzlich vibriert Slack, Grafana steht in Flammen, dein Kopf rennt auf 120 %. Alle schauen zu, jede Sekunde zählt. Wenn du so etwas nie erlebt hast, erstarrst du vielleicht, gerätst in Panik oder fängst an zu raten.

Hast du aber in einer kontrollierten Umgebung schon Schlimmeres gesehen, bleibst du cool. Du liest die Logs, vertraust deinem Instinkt und debugst, statt planlos rumzuwedeln.
Und am wichtigsten: Du reparierst es schneller.

Diese Erfahrung beeinflusst auch dein Coding:
Du gehst jetzt davon aus, dass

• das Netzwerk unzuverlässig ist
• die Datenbank mal ausfallen kann
• Retries passieren
• Nutzer zerschossene Eingaben schicken
• Dinge ausfallen und sich erholen

Du wächst von “läuft auf meinem Rechner” zu “fällt auf jedem Rechner elegant zusammen”.

Nein, du bist nicht zu gut dafür

Wenn du denkst Das passiert mir nicht, ich bin der beste Programmierer!, sorry: Vorfälle passieren selbst den Besten. Fehler sind normal – sorge dafür, vorbereitet zu sein. Lass dein Ego nicht im Weg stehen!

Abschliessende Gedanken

Du musst nicht in Production breaken.
Aber du solltest was kaputt machen.

Test-Umgebungen, Staging oder dein eigenes Laptop sind perfekte Kulissen. Mach Fehler, sieh zu, wie es crasht, und repariere es. So wirst du ein besserer Engineer: selbstbewusster, resilienter und empathischer gegenüber deiner Infrastruktur.

Fürchte das Scheitern nicht.
Erkunde es.

Liebe Grüße,
Jonas
Co-Founder sliplane.io