Fehlalarm beim Taifun: Wie ein Product Manager die dunkelste Stunde übersteht wie einen Sturm

Erst ein Satz, der vielleicht wehtut: Die allermeisten „dunkelsten Stunden”, die du in deinem Leben erlebst, enden genauso wie dieser Taifun — als Fehlalarm. Und das Wort „Fehlalarm” bringt einen Product Manager schneller um als der Sturm selbst.

Taifun „Bawei”, der neunte der Saison, ist letzte Nacht nach Süden abgedreht. Er hat Zhoushan nicht frontal getroffen, sondern sich zu einem gewöhnlichen Taifun abgeschwächt und Kurs auf die Küste zwischen Wenling in Zhejiang und Xiapu in Fujian genommen. Und so wirken hier in Zhoushan und Putuo die Fähren, die schon am 9. Juli eingestellt wurden, die gestrichenen Flüge und die Fischerboote, die über Nacht Boot für Boot vom Ankerplatz zum Westkai von Shenjiamen verlegt wurden — im Nachhinein alle wie vergebliche Mühe. Heute Morgen hat schon jemand in der Gruppe geschrieben: „Hätte man gewusst, dass es nicht nötig ist, hätte man die Boote nicht über Nacht wegfahren müssen.”

Bleib bei diesem Satz stehen. Denn das Interessanteste an der ganzen Sache steckt genau in diesem „Hätte man gewusst”.

Im letzten Beitrag ging es um Putuoshan, und meine These war: Bitte nicht Guanyin darum bitten, den Taifun für dich abzuwehren, sondern lieber den Deich bauen — schreib das „Nicht-getroffen-worden-Sein” nicht einer geheimnisvollen Schutzmacht zu, das ist eine falsche Ursachenzuschreibung. Dieser Beitrag geht einen Schritt weiter: Der Deich steht — und in der Nacht, in der der Alarm wirklich losgeht, was genau musst du als der Verantwortliche dann tun?

Meine Antwort lautet: Einen Taifun zu überstehen ist nie ein einzelner Handgriff, sondern drei aufeinanderfolgende Handlungen — vor dem Taifun: gründlich vorbereiten; mitten im Taifun: den Sturm auf sich nehmen; nach dem Taifun: den Müll wegräumen. Diese drei Dinge, selbst wenn neun von zehn Malen Fehlalarm sind, darf man kein einziges auslassen. Genau so übersteht ein Product Manager seine dunkelste Stunde.

1. Vor dem Taifun: Deine Gelassenheit ist alles, was du früher angelegt hast

In der dunkelsten Stunde ist das Trügerischste die „Gelassenheit”.

Du siehst Leute, deren System mitten in der Nacht abstürzt, deren Daten nicht mehr stimmen, deren Chef anruft — und sie sitzen trotzdem ruhig da und arbeiten die Sache Punkt für Punkt ab. Du denkst, das sei angeborene psychische Stärke, spontane Improvisation. Ist es nicht. In der dunkelsten Stunde ist kein Gramm dieser Gelassenheit im Moment gewachsen; sie ist ganz und gar in jenen „Tagen ohne Taifun” Stück für Stück angelegt worden.

Für jemanden, der Produkte und Systeme baut, ist das „Angelegte” etwas sehr Konkretes: ein Rollback-Schalter, den man jederzeit drücken kann; ein Canary-Release, das erst 1 % des Traffics zum Ausprobieren rauslässt, statt alle 100 % der Nutzer auf einen Schlag ins Wasser zu stoßen; ein Ring aus Monitoring und Alarmen, der dich wissen lässt, wo es blutet, bevor die Nutzer schimpfen; ein aufgeschriebener und wirklich geprobter Notfallplan; und die Puffer aus Vertrauen und Cashflow, die man in normalen Zeiten Stück für Stück ansammelt, bevor man sie braucht.

Das Schlüsselwort hier ist „wirklich geprobt”.

Am 31. Januar 2017 hatte GitLab einen Vorfall, über den bis heute immer wieder erzählt wird. Ein Ingenieur setzte spät in der Nacht auf der falschen Datenbank einen Löschbefehl ab und löschte die Daten der Produktionsdatenbank. Die Löschung selbst war noch nicht der Weltuntergang — was allen wirklich den Rücken kalt werden ließ, war das, was danach kam: Sie hatten fünf Backups und Replikationsmechanismen, und bei der Untersuchung stellte sich heraus, dass keiner davon wirklich funktionierte. Das automatische pg_dump-Backup war wegen eines Konfigurationsfehlers in Wahrheit nie erfolgreich durchgelaufen; das Fehlschlagen des Backups hätte eigentlich eine Warn-E-Mail auslösen sollen, doch diese Warn-Mails wurden von den DMARC-Einstellungen stillschweigend abgewiesen, niemand bekam sie. Azure hatte zwar Disk-Snapshots, aber deren Wiederherstellung hätte über 18 Stunden gedauert. Was GitLab am Ende vom Abgrund zurückholte, war ein Snapshot, den ein Ingenieur sechs Stunden vor dem Vorfall zufällig von Hand angelegt hatte. Nur wegen dieses einen „Zufalls” verloren sie am Ende bloß sechs Stunden Daten.

Diese Geschichte legt die wahre Bedeutung von „gründlich vorbereiten” schonungslos offen: Du glaubst, du hättest einen Deich gebaut — und wenn der Taifun kommt, merkst du, dass er nur aufgemalt war. Fünf Backups klingt bombensicher, aber keines davon war je ernsthaft verifiziert oder geprobt worden. Ein Notfallplan, der nie geprobt wurde, ist kein Notfallplan, sondern ein Wunsch. Der Satz „Wir haben ein ausgereiftes Disaster-Recovery-Konzept”, den du in ein Dokument geschrieben hast, ist vor dem Taifun nichts anderes als ein frommer Segensspruch.

Eine noch härtere Variante ist, gar nicht erst auf den Taifun zu warten. Netflix hält sich ein Programm namens „Chaos Monkey”, dessen tägliche Aufgabe es ist, in der Produktionsumgebung, ausgerechnet am ruhigen, sonnigen Tag, zufällig ein paar gerade arbeitende Maschinen abzuschalten. Das klingt nach Selbstverstümmelung, ist in Wahrheit aber die ehrlichste Art zu proben — statt zu warten, bis der echte Taifun kommt und man merkt, dass der Deich aufgemalt war, lässt man lieber selbst jeden Tag einen tollwütigen Affen ins Rechenzentrum, um das noch heile System einmal absichtlich kaputtzumachen und zu sehen, ob es sich wirklich wieder fängt oder nicht. Die Gelassenheit dessen, der Chaos Monkey überstanden hat, ist echte Gelassenheit; die Gelassenheit dessen, der nie so durchgeschüttelt wurde, ist nur Glück, das noch nicht aufgebraucht ist.

Und genau hier taucht der „Fehlalarm” der ersten Ebene auf: Die Rollbacks, Proben und Backups, die du angelegt hast, wirst du zum allergrößten Teil ein Leben lang kein einziges Mal brauchen. Dass du sie nicht brauchst, lässt es umsonst erscheinen. Aber dreh die Perspektive einmal um — die friedlichen Tage, die du erlebt hast, sind nicht Glück, sondern mit Vorbereitung erkauft. Wer sich nie „umsonst vorbereitet”, ist bloß noch nicht an der Reihe gewesen.

2. Mitten im Taifun: Du musst ganz vorne im Regen stehen

Egal wie gründlich die Vorbereitung war, in dem Moment, in dem der Taifun dir wirklich ins Gesicht schlägt, tut es trotzdem weh. Jetzt zählt etwas anderes: Verantwortung übernehmen.

Mitten in der Krise gibt es zwei Dinge, die der Verantwortliche auf keinen Fall tun darf — flüchten und Schuld abwälzen.

Flüchten heißt, sich selbst zu verstecken und zu warten, bis der Sturm vorbei ist; Schuld abwälzen heißt, hektisch danach zu suchen, „wer diesen Knopf gedrückt hat”. Beide Handlungen können dir im Moment etwas Erleichterung verschaffen, aber sie erledigen gleichzeitig das Teuerste: die Frage, ob dein Team sich noch traut, nach vorne zu gehen. Verantwortung übernehmen heißt schlicht das Gegenteil — stell dich ganz nach vorne und triff die Entscheidung, die im Moment am schwersten ist, aber sofort getroffen werden muss. Erst die Blutung stoppen: Wenn es zurückzurollen gilt, dann rollbacken; wenn etwas abgeschaltet werden muss, dann abschalten; wenn etwas gestrichen werden muss, dann streichen; wenn ein Fehler zuzugeben ist, dann zugeben; wenn die Nutzer informiert werden müssen, dann nicht bis morgen warten. Die Rechnung nimmst du erst mal auf deine Kappe.

Wieder GitLab an jenem Tag. Sie taten etwas, das bis heute sehr kontraintuitiv wirkt: Sie stellten die Wiederherstellung der Datenbank öffentlich in einen Livestream. Tausende Leute sahen live zu, wie sie die peinliche Löschung und die Tatsache, dass alle fünf Backup-Schichten nutzlos waren, Stück für Stück offenlegten und Stück für Stück reparierten. Das war keine Show. Das ist die härteste Form von „Verantwortung übernehmen” — ich habe es vermasselt, ich repariere es vor aller Augen, ich verstecke mich nicht. Erst wenn eine Firma so etwas wagt, wissen die Ingenieure im Team: Wenn hier etwas schiefgeht, ist der erste Reflex reparieren, nicht verstecken.

Vergleiche das mit den Orten, wo bei jedem Vorfall zuerst eine Sitzung zur Schuldzuweisung einberufen wird. Kaum passiert etwas, ist das Erste, woran alle denken, wie sie sich reinwaschen: schnell die Logs sichern, schnell Screenshots vom Chatverlauf machen, und „für dieses Modul bin ich nicht zuständig” ist sofort raus. Das Gegenteil von Verantwortung übernehmen ist nicht Panik, sondern Abschieben. Wer die Verantwortung nach unten aufs Team und nach außen aufs „Pech” abschiebt, von dem behalten alle, wenn der Sturm vorbei ist, nur das Bild in Erinnerung, wie er sich hinten verkroch.

Dieser Abschnitt ist von den drei Dingen der schwerste, denn im Regen zu stehen ist wirklich kalt. Drei Uhr nachts, die Sache ist noch völlig unklar, alle Augen sind auf dich gerichtet — dieses Gefühl ist nicht angenehm. Aber was dein Team in diesem Moment beobachtet, war noch nie, ob du in Panik bist oder eine Musterlösung parat hast — sie beobachten, ob du, als das Feuer am größten war, einen Schritt nach vorne oder einen Schritt zurück gemacht hast. Was in der dunkelsten Stunde wirklich gewogen wird, ist die Richtung dieses einen Schritts.

3. Nachdem der Taifun weg ist: Der Müll überall ist die eigentliche Prüfung

Der Taifun ist durchgezogen, der Himmel klart auf — und damit kommt die gefährlichste Nachlässigkeit. Viele haben den Sturm überstanden und sterben am Ende doch am „keine Lust zum Aufräumen”.

Das Chaos, das nach dem Sturm überall herumliegt, ist der Ort, an dem sich das Können wirklich zeigt. Aufräumen heißt nicht nur, das Durcheinander zu beseitigen und das System wieder zum Laufen zu bringen — das ist bloß Wiederherstellung. Echtes Aufräumen heißt, den Schmerz von diesmal in eine Regel zu verwandeln, in die man nächstes Mal nicht mehr tritt: Die Retrospektive muss bis auf die Mechanismusebene reichen und die Lektion von diesmal in eine Prüfung verwandeln, die nächstes Mal automatisch greift, in eine beseitigte Gefahrenquelle, in einen aktualisierten Notfallplan.

Knight Capital ist genau am Nicht-Aufräumen gestorben. Am Morgen des 1. August 2012 brachte diese Hochfrequenzhandels-Firma ein Stück neuen Code online; ein Ingenieur deployte ihn von Hand auf 8 Server und übersah einen einzigen davon. Ausgerechnet auf diesem einen Server lag noch ein längst stillgelegtes, aber nie gelöschtes Stück alten Funktionscodes mit dem Codenamen „Power Peg”. Der neue Code verwendete einen gleichnamigen Schalter wieder, und so wurde auf dieser einen nicht aktualisierten Maschine dieser tote Code, der eigentlich im Grab hätte liegen sollen, wieder zum Leben erweckt und begann wie wild, Orders an den Markt zu schicken. In 45 Minuten wurden fast 397 Millionen Aktien über 154 Titel gehandelt — ein Vorsteuerverlust von 440 Millionen Dollar. Die Firma wurde noch im selben Jahr zum Jahresende übernommen und war weg.

Sieh dir an, wie kurz diese Kette ist: Ein Stück Schrottcode, das man hätte löschen sollen, aber zu faul war zu löschen, plus ein Deployment ohne Prüfung, das eine Maschine übersah — und das kostete eine ganze Firma das Leben. Das ist das Nicht-Aufräumen in seiner Extremform — Müll verschwindet im System nicht von selbst, er wartet nur still auf den Funken, der ihn entzündet.

Und noch einmal zurück zu GitLab. Ebenfalls ein potenziell tödlicher Vorfall, und danach schrieben sie einen bis zur Selbstgeißelung offenen Retrospektiv-Bericht, listeten Punkt für Punkt auf, wie jede einzelne der fünf Backup-Schichten versagt hatte, und reparierten sie Punkt für Punkt. Der eine kehrt den Müll zu Immunität zusammen, der andere lässt den Müll liegen und wartet, bis er explodiert. Wie diese beiden Firmen heute jeweils dastehen, weißt du ja.

Beim Aufräumen gibt es noch eine Stelle, die man besonders leicht falsch macht: Fege den Mechanismus, nicht die Menschen. Zweck der Retrospektive ist, dass „diese Grube das nächste Mal automatisch aufgefüllt wird”, nicht, den armen Kerl zu erwischen, der den falschen Knopf gedrückt hat. Sobald du anfängst, Menschen zu jagen, ist das Erste, was alle lernen, sich beim nächsten Vorfall zuerst zu verstecken; reparierst du nur den Mechanismus und fragst nicht, wer es war, trauen sich alle, das Problem im ersten Moment laut auszurufen. Diese „Es geht um die Sache, nicht um die Person”-Retrospektive wurde nicht zuerst vom Internet erfunden, sondern ist aus der Luftfahrt herausgewachsen: Wenn ein Flugzeug abstürzt, ist der einzige Zweck der Untersuchungskommission, dass Flugzeuge desselben Typs künftig nicht mehr vom Himmel fallen — und nicht, den Piloten an den Schandpfahl zu nageln, denn sobald man anfängt, Menschen zu nageln, wird die nächste Crew, die einen Fehler macht, ihn verschweigen, und Verschweigen lässt das nächste Flugzeug noch schlimmer abstürzen. Google hat dieses Prinzip später in sein SRE-Handbuch geschrieben und ihm einen Namen gegeben: „blameless postmortem”. Der GitLab-Ingenieur, der die Datenbank löschte, wurde nicht öffentlich hingerichtet, und das war keine Weichheit, sondern Klarheit — einmal Schmerz gehabt zu haben ist noch kein Wachstum; den Schmerz in eine Regel zu verwandeln, die man nie wieder bricht, das ist es.

4. Zurück zu dem Satz „Hätte man gewusst, hätte man nicht über Nacht verlegen müssen”

Jetzt zurück zum Anfang, zu dem Satz von heute Morgen: „Hätte man gewusst, hätte man die Boote nicht über Nacht wegfahren müssen.”

Dieser Satz ist in Wahrheit das Spiegelbild jener falschen Ursachenzuschreibung aus dem letzten Beitrag. Damals schrieben die Leute die „Sicherheit” dem Schutz Guanyins zu; diesmal schreiben sie die „Sicherheit” dem Umstand zu, dass „ohnehin nichts passiert wäre”. Der eine schreibt das Verdienst der Göttin gut, der andere dem Glück — beide streichen dir insgeheim die Vorbereitung fürs nächste Mal.

Doch die Wahrheit ist: Die allermeisten „Fehlalarme” sind genau das, wie erfolgreiche Vorbereitung aussieht. Wenn eine Organisation über all die Jahre nie einen einzigen „umsonst geschufteten” Moment erlebt hat, gibt es nur zwei Möglichkeiten — entweder betrügt sie sich selbst und deutet jeden Glücksfall als „unser System hat keine Probleme”; oder sie ist bereits einmal wirklich umgeworfen worden und hat mit Blut Lehrgeld bezahlt. Knight Capital hatte nie einen „Fehlalarm”, weil es jedes folgenlose Deployment vor dem Go-Live als „mit dem Prozess ist alles in Ordnung” las — bis zu jenen 45 Minuten.

Taifun „Bawei” ist diesmal nach Süden gezogen, und Zhoushan wird höchstwahrscheinlich heil davonkommen. Aber was jene Fischer heute Nacht ruhig schlafen lässt, ist nicht die Laune, mit der der Taifun sich kurzfristig anders entschieden hat, sondern jene Boote, die in der letzten Nacht über Nacht vom Ankerplatz weggefahren wurden.

Ob die nächste dunkelste Stunde frontal auf dich niederfährt, kannst du nicht entscheiden. Entscheiden kannst du nur jene drei Dinge, die wer einen Taifun übersteht, nie auslässt: vor dem Taifun den Deich so bauen, dass er die Wellen wirklich abhält und nicht auf Papier gemalt ist; mitten im Taifun dich ganz nach vorne stellen und jenen Regen abbekommen; nach dem Taifun den Müll überall wegfegen und ihn zu einer Regel fegen, die man nie wieder bricht. Machst du diese drei Dinge vollständig, werden andere sagen, du hättest Glück gehabt; machst du sie dir bei einem davon leicht, kommen jene 45 Minuten von Knight Capital früher oder später auch an dich.