Defensive Engineering: Systeme gegen Katastrophen

Ein junger Entwickler bei einem mittelgroßen Fintech-Unternehmen führte an einem Freitagnachmittag ein Datenbank-Migrationsskript aus. Das Skript sollte verwaiste Datensätze in einer Staging-Umgebung aufräumen. Stattdessen verband es sich mit der Produktionsdatenbank und löschte 4,2 Millionen Transaktionsdatensätze von Kunden. Das Backup? Drei Tage alt. Das Unternehmen verbrachte die nächsten 72 Stunden im vollen Incident-Response-Modus und rekonstruierte Datensätze manuell aus den Logs der Zahlungsdienstleister. Die Gesamtkosten lagen über 400.000 USD, für Entwicklungszeit, Kundengutschriften und die Meldungen an Aufsichtsbehörden.

Das Skript hatte keine Umgebungsprüfung. Keinen Dry-Run-Schalter. Keine Bestätigungsabfrage, die zeigte, mit welcher Datenbank es verbunden war. Der Connection-String kam aus einer Umgebungsvariable, die auf dem Laptop des Entwicklers zufällig noch auf Produktion gesetzt war, aus einer Debugging-Session zwei Wochen zuvor. Jeder einzelne dieser Fehler war vermeidbar.

Warum „Bist du sicher?“-Dialoge nicht funktionieren

Der häufigste Sicherheitsmechanismus in der Software ist der Bestätigungsdialog. Er ist auch der nutzloseste. Studien zur Bestätigungsmüdigkeit zeigen, dass Nutzer nach ein paar Begegnungen praktisch jede „Bist du sicher?“-Abfrage ohne Hinsehen wegklicken. Die Abfrage wird unsichtbar, nur ein weiterer Klick auf dem Weg zu dem, was man ohnehin schon vorhatte.

Das Problem ist nicht, dass Bestätigungen eine schlechte Idee wären. Das Problem ist, dass generische Bestätigungen null Information liefern. „Möchtest du wirklich fortfahren?“ sagt dir nicht, was du gerade tust. Vergleiche das mit: „Du bist dabei, 4.217.893 Zeilen aus der Tabelle transactions in prod-us-east-1 zu löschen. Gib zur Bestätigung den Namen der Datenbank ein.“ Die zweite Variante zwingt dich, wirklich zu lesen, was passiert. Das ist der Unterschied zwischen einer Bremsschwelle und einer Molly Guard.

Was eine Molly Guard ist und warum sie wichtig ist

Der Begriff „Molly Guard“ stammt von einer physischen Plastikabdeckung über dem Big Red Button auf Mainframes, die versehentliche Abschaltungen verhindern soll. Angeblich ist sie nach der kleinen Tochter eines Programmierers benannt, Molly, die ständig darauf drückte. In der Software ist eine Molly Guard jeder Mechanismus, der destruktive Aktionen versehentlich schwer auslösbar macht, sie aber bei beabsichtigter Nutzung weiterhin möglich lässt.

Das Linux-Paket molly-guard macht genau das. Es fängt die Befehle shutdown, reboot und halt in SSH-Sitzungen ab und verlangt, dass du den Hostnamen der Maschine eintippst, die du herunterfahren willst. Du kannst dich nicht einfach durchklicken. Du musst beweisen, dass du weißt, auf welcher Maschine du gerade bist.

$ sudo reboot
Good grief! You're on a remote SSH session to prod-web-03.
Please type the hostname to confirm: prod-web-03
# Compare with the useless version:
$ sudo reboot
Are you sure? (y/n): y
# *types y without reading, muscle memory*

Das Prinzip ist einfach: Die Bestätigung sollte Informationen verlangen, die beweisen, dass der Bediener die Aktion versteht. Ein „j“ zu tippen beweist nichts. Den Hostnamen, den Tabellennamen oder die Anzahl betroffener Datensätze einzutippen beweist, dass du die Warnung gelesen hast.

Dry-Run-Modi: Erst anschauen, dann feuern

Jede destruktive Operation sollte einen Dry-Run-Modus haben. Nicht „sollte“ im Sinne von Best Practice, sondern „sollte“ im Sinne von: Du wirst irgendwann bereuen, keinen zu haben. Ein Dry Run führt die vollständige Logik einer Operation aus, protokolliert genau, was passieren würde, und hört dann auf. Keine Seiteneffekte. Volle Transparenz.

Das Muster ist leicht umzusetzen. Hier ist ein Migrationsskript mit eingebautem Dry-Run:

#!/bin/bash
set -euo pipefail
DRY_RUN=${DRY_RUN:-true}  # Default to dry-run!
DB_HOST=$(get_db_host)
DB_NAME=$(get_db_name)
echo "Target: $DB_HOST / $DB_NAME"
echo "Mode: $([ "$DRY_RUN" = true ] && echo 'DRY RUN' || echo 'LIVE')"
ROWS=$(psql -h "$DB_HOST" -d "$DB_NAME" -t -c \
"SELECT count(*) FROM orphaned_records WHERE created_at < now() - interval '90 days'")
echo "Records to delete: $ROWS"
if [ "$DRY_RUN" = true ]; then
echo "Dry run complete. Set DRY_RUN=false to execute."
exit 0
fi
# Require explicit confirmation for live runs
read -p "Type '$DB_NAME' to confirm deletion: " CONFIRM
if [ "$CONFIRM" != "$DB_NAME" ]; then
echo "Aborted."
exit 1
fi
psql -h "$DB_HOST" -d "$DB_NAME" -c \
"DELETE FROM orphaned_records WHERE created_at < now() - interval '90 days'"
echo "Deleted $ROWS records."

Beachte drei Dinge: Der Standard ist der Dry-Run (du musst dich aktiv für die Zerstörung entscheiden, nicht dagegen), das Skript zeigt dir Zieldatenbank und Zeilenanzahl, bevor es irgendetwas tut, und selbst im Live-Modus musst du den Datenbanknamen eintippen. Drei Verteidigungsebenen. Jede einzelne hätte den Vorfall verhindert, den ich eingangs beschrieben habe.

Sicherheitsnetze bei Datenbankmigrationen

Datenbankmigrationen gehören zu den riskantesten Operationen in jeder Deployment-Pipeline. Sie sind oft nicht umkehrbar, laufen gegen gemeinsam genutzten Zustand, und eine fehlerhafte kann die gesamte Anwendung lahmlegen. Trotzdem behandeln die meisten Teams sie wie einen beliebigen Deploy-Schritt.

Hier ist eine Hierarchie von Sicherheitsmechanismen, von einfach bis absolut wasserdicht:

1. Umgebungsprüfungen – Das Migrationsskript prüft, ob es die beabsichtigte Umgebung anspricht, bevor es ausgeführt wird. Klingt offensichtlich. Du würdest staunen, wie oft das fehlt.
2. Snapshots vor der Migration – Vor jeder Migration automatisch einen Datenbank-Snapshot erstellen. Schlägt die Migration fehl oder verursacht Probleme, kannst du in Minuten statt Stunden wiederherstellen.
3. Zeilenanzahl-Wächter – Würde eine Migration mehr als N Zeilen betreffen, explizite Bestätigung verlangen. Eine Migration, die unerwartet Millionen Zeilen berührt, ist fast immer ein Bug.
4. Statement-Timeouts – Aggressive Timeouts für Migrationsabfragen setzen. Eine Migration, die 45 Minuten läuft, sperrt Tabellen und beeinträchtigt die Performance. Lieber früh scheitern.
5. Nur abwärtskompatibel – Erzwingen, dass jede Migration mit dem aktuell deployten Code kompatibel ist. Das heißt: keine Spaltenumbenennungen, keine NOT-NULL-Spalten ohne Default, keine Spalten löschen, die noch referenziert werden.

# Rails example using strong_migrations gem
class AddPhoneToUsers < ActiveRecord::Migration[7.1]
def change
# This will raise an error with a safe alternative:
# add_column :users, :phone, :string, null: false
#
# Instead, do it in two steps:
add_column :users, :phone, :string
# Then in a separate migration after backfill:
# change_column_null :users, :phone, false
end
end

Werkzeuge wie strong_migrations in Rails, squawk für PostgreSQL und skeema für MySQL fangen gefährliche Muster ab, bevor sie in die Produktion gelangen. Wenn du nichts dergleichen einsetzt, verlässt du dich darauf, dass Code Reviews subtile Migrationsprobleme finden. Und Reviewer übersehen Dinge.

Soft Deletes und Undo-Fenster

Hard Deletes sind eine dauerhafte Entscheidung, getroffen in einem Moment der Gewissheit. Das Problem: Diese Gewissheit liegt oft daneben. Soft Deletes, also Datensätze als gelöscht markieren, ohne sie tatsächlich zu entfernen, geben dir ein Zeitfenster, um Fehler zu korrigieren.

-- Hard delete: gone forever
DELETE FROM projects WHERE id = 4872;
-- Soft delete: recoverable
UPDATE projects
SET deleted_at = now(),
deleted_by = 'user:priya'
WHERE id = 4872;
-- Recovery is trivial
UPDATE projects
SET deleted_at = NULL,
deleted_by = NULL
WHERE id = 4872;

Der Trade-off ist real: Soft Deletes erhöhen die Komplexität von Abfragen (du brauchst überall WHERE deleted_at IS NULL), benötigen mehr Speicher und können Verwirrung darüber stiften, in welchem Zustand die Daten wirklich sind. Aber bei allen nutzerseitigen Daten, bei denen versehentliches Löschen möglich ist, lohnt sich der Trade-off. GitHub löscht dein Repository tatsächlich erst nach 90 Tagen. Slack behält gelöschte Nachrichten aus Compliance-Gründen. Der Papierkorb von Gmail leert sich erst nach 30 Tagen. Das sind keine Zufälle, sondern bewusste technische Entscheidungen.

Dasselbe Prinzip gilt für Infrastruktur. Statt eine EC2-Instanz zu terminieren, stoppe sie zuerst. Statt eine Datenbank zu droppen, benenne sie in mydb_deleted_20260315 um und setze dir eine Kalendererinnerung, sie erst in zwei Wochen wirklich zu löschen. Die Kosten, eine gestoppte Instanz oder umbenannte Datenbank ein paar Tage zu behalten, sind vernachlässigbar im Vergleich zu den Kosten einer Wiederherstellung aus dem Backup.

Deployment-Sicherheit: Canaries, Circuit Breaker und Rollbacks

Deployments sind eine weitere Kategorie destruktiver Aktionen, die die meisten Teams nicht mit genug Vorsicht behandeln. Ein fehlerhaftes Deployment kann die Produktion genauso wirksam lahmlegen wie eine gedroppte Datenbank, und es passiert weitaus häufiger.

Das minimal sinnvolle Setup für Deployment-Sicherheit umfasst:

• Canary-Deployments – 1 bis 5 % des Traffics auf die neue Version leiten. Steigen die Fehlerraten, automatisch zurückrollen, bevor der Wirkungsradius wächst.
• Automatische Rollback-Auslöser – Schwellenwerte für Fehlerrate, Latenz und Health Checks definieren, die automatisch einen Rollback auslösen. Verlass dich nicht darauf, dass ein Mensch um 2 Uhr nachts etwas bemerkt.
• Deploy-Freezes während Incidents – Gibt es einen laufenden Incident, werden alle Deployments blockiert. Während der Feuerwehreinsätze brauchst du als Letztes, dass jemand unabhängige Änderungen ausrollt.
• Ein-Klick-Rollback – Zurückrollen sollte leichter sein als vorwärts zu deployen. Wenn dein Rollback-Prozess aus SSH-Verbindungen und manuellen Befehlen besteht, hast du gar keinen Rollback-Prozess.

# Kubernetes progressive delivery with Argo Rollouts
apiVersion: argoproj.io/v1alpha1
kind: Rollout
spec:
strategy:
canary:
steps:
- setWeight: 5
- pause: { duration: 5m }
- analysis:
templates:
- templateName: error-rate-check
- setWeight: 25
- pause: { duration: 5m }
- setWeight: 50
- pause: { duration: 10m }
- setWeight: 100
# Auto-rollback if error rate exceeds 1%
abortScaleDownDelaySeconds: 30

Das Muster dahinter ist schrittweise Verpflichtung. Du gehst nicht von 0 auf 100 % in einem Schritt. Du machst kleine Schritte, prüfst jeden einzelnen und behältst auf jeder Stufe die Möglichkeit zum Rückzug. Das ist langsamer als ein YOLO-Deployment auf alle Instanzen auf einmal, aber beim ersten Mal, wenn es ein fehlerhaftes Deployment abfängt, bevor es alle Nutzer trifft, wirst du jede zusätzliche Minute zu schätzen wissen.

Architektonische Prävention: Das Falsche unmöglich machen

Die besten Sicherheitsmechanismen verlangen nicht, dass du vorsichtig bist. Sie machen es strukturell unmöglich, das Falsche zu tun. Das ist der Unterschied zwischen einer Leitplanke und einem Warnschild.

• Unveränderliche Infrastruktur – Wenn du dich nicht per SSH auf Produktionsserver einloggen kannst, kannst du dort auch nicht versehentlich Befehle ausführen. Wenn Deployments immer frische Instanzen aus einem bekannten Image sind, kann es keinen Konfigurationsdrift geben.
• Least-Privilege-Zugriff – Entwickler sollten keine Produktions-Datenbankzugangsdaten auf ihren Laptops haben. Punkt. Nutze Just-in-Time-Zugriffstools, die temporäre Zugangsdaten mit Audit-Trails vergeben.
• Getrennte Zugangsdaten pro Umgebung – Verwenden Staging und Produktion unterschiedliche Credential-Stores, kannst du mit Staging-Tooling buchstäblich nicht versehentlich auf die Produktion zugreifen.
• Löschschutz – AWS erlaubt es, den Kündigungsschutz für EC2-Instanzen und den Löschschutz für RDS-Datenbanken zu aktivieren. Schalte ihn für alles ein, was wichtig ist. Das ist eine Konfigurationsänderung von fünf Sekunden, die eine ganze Klasse katastrophaler Fehler vollständig verhindert.

Wenn jemand mit einem einzigen Befehl versehentlich die Produktion zerstören kann, liegt das Problem nicht bei der Person, sondern beim System, das einen einzigen Befehl die Produktion zerstören lässt.

Ich habe erlebt, wie Teams auf Produktionsvorfälle mit mehr Dokumentation, mehr Checklisten und mehr Schulungen reagiert haben. Das hilft, aber all das setzt darauf, dass Menschen perfekt sind. Sind sie nicht. Die bessere Reaktion ist, das System so zu verändern, dass der Fehler gar nicht erst passieren kann. Falls doch, ist der Wirkungsradius begrenzt und die Wiederherstellung schnell.

Eine Kultur aufbauen, die Sicherheit an erste Stelle setzt

Werkzeuge und Architektur sind wichtig, aber die Kultur entscheidet, ob sie tatsächlich umgesetzt werden. Teams, die Sicherheitsmechanismen als Mehraufwand oder Bürokratie betrachten, werden sie unter Termindruck überspringen. Und Termindruck ist dauerhaft.

Das wirksamste Muster, das ich gesehen habe, ist, Sicherheitsmechanismen als erstklassige Engineering-Anforderung zu behandeln, nicht als nettes Extra. Jede destruktive Operation bekommt ein Design-Review, das gezielt fragt: Was passiert, wenn dies gegen das falsche Ziel läuft? Was passiert, wenn es zweimal läuft? Was passiert, wenn es mit veralteten Daten läuft? Wie machen wir es rückgängig?

Blameless Post-Mortems sind mittlerweile Pflicht. Die seltenere Praxis, die ich für wichtiger halte, ist aber das Pre-Mortem. Bevor du eine riskante Änderung startest, holst du das Team zusammen und fragst: „Angenommen, das ist furchtbar schiefgegangen. Was ist passiert?“ Menschen sind erstaunlich gut darin, Fehlermodi zu erkennen, wenn man es als Vorstellungskraft statt als Vorhersage rahmt. Die identifizierten Fehler werden zu den Sicherheitsmechanismen, die du baust.

Der junge Entwickler, der die Produktionsdatenbank gelöscht hat? Der ist immer noch im Unternehmen. Heute gehört er zu den stärksten Verfechtern des defensiven Engineerings im Team. Der Vorfall war nicht seine Schuld, sondern ein Systemversagen. Und das System lässt sich jetzt deutlich schwerer kaputt machen.