Es gibt diesen einen Moment im Leben eines jeden Entwicklers, in dem das Herz kurz stehen bleibt und die Zeit sich verlangsamt. Meistens ist es der Moment, in dem man realisiert, dass man gerade einen Fehler gemacht hat, der sich nicht mit STRG+Z beheben lässt. Das sind keine netten Anekdoten für Partys, das sind Kriegsnarben. Und genau so ein Moment hat meine Sicht auf IT-Architektur und Krisenmanagement nachhaltig geprägt.

Mein "Erweckungsmoment" passierte ganz am Anfang, als Prepaid-Hoster noch recht klein war. Ich wollte die Dev-Datenbank aufräumen. Dachte ich zumindest. In Wahrheit befand ich mich auf dem Produktivsystem. Gemerkt habe ich es erst, weil ich die "Alle auswählen" Funktion einer Seite genutzt habe und eigentlich nach 3 Seiten fertig sein sollte. Naja, bei Seite 5 wurde ich dann stutzig.

Der Moment, in dem dir klar wird, dass die Ladezeit gerade deshalb so lange ist, weil du echte Kundendaten ins Nirvana schickst, brennt sich ein. Der Tag bestand dann nur noch aus dem Wiederherstellen von Backups, dem Parsen von Mails und kaltem Schweiß.

Learning 1: Environment Isolation & Visuelle Warnungen
Seither haben Dev-Systeme bei uns einen fetten, unübersehbaren roten Header-Strip. Software muss uns vor unserer eigenen Betriebsblindheit schützen. Wenn alles "flutscht", macht man Fehler. Deshalb bauen wir Systeme heute so, dass sie in kritischen Momenten antizyklisch reagieren. Ein Nutzer muss gewarnt werden, bevor es ernst wird. Aus diesem Grund ist es bei uns verpflichtend, den Checkout-Button exakt "Kostenpflichtig bestellen" zu nennen! Das ist nicht nur rechtlich relevant, sondern ein kognitiver Stopp-Schild, das dem Nutzer ins Gesicht schreit: "Halt! Ab hier wird es ernst."

Learning 2: Handeln statt Hoffen (Die Feuertaufe)
Jahre später kam die Prüfung für das nächste Level. Der Brand im OVH-Rechenzentrum in Straßburg. Das war kein eigener Fehler, sondern höhere Gewalt. Während 90% der Hosterszene wie das Kaninchen vor der Schlange wartete und hoffte, dass "OVH das schon fixt", haben wir anders reagiert.

Wir haben nicht gewartet. Wir haben entschieden, sofort Geld in die Hand zu nehmen. Wir haben uns teure Hetzner AX-Lines über das Rechenzentrum-Telefon gesichert - all das noch während die Server in Frankreich wahrscheinlich noch qualmten. Wir haben unkonventionelle Lösungen gesucht, Backups auf völlig neue Infrastrukturen migriert und die Nacht durchgemacht. Auch Jahre nach dem Vorfall erinnern wir uns oft daran zurück, wie unsere Kunden unser schnelles Handeln zu schätzen wussten.

Das ist der Unterschied zwischen einem Administrator und einem Technischen Leister. Der Administrator wartet auf Anweisungen oder den Restore. Der CTO handelt, um das Business zu retten, auch wenn der Weg dahin improvisiert wirkt. Diese "Panik" hat uns gelehrt: Verlasse dich niemals auf eine einzelne Schnittstelle oder einen einzelnen Standort. Und wenn die Hütte brennt, bau eine neue - sofort.

Heute definieren diese beiden Ereignisse meine Arbeit: Systeme müssen so sicher sein, dass man sie nicht versehentlich zerstören kann (Red Header). Aber wenn das Unmögliche passiert, muss die Architektur so flexibel sein, dass wir handlungsfähig bleiben.