TheWhiteCode

23:40 Uhr, vier Leute in einer Telefonkonferenz, einer teilt seinen Bildschirm, und im Hintergrund läuft ein Diagramm, das niemand ansieht. Um 00:12 ging der Deploy durch, um 00:40 war der Rollback fertig, und um 01:30 saßen wir da und haben darüber geredet, warum wir das nicht um 14 Uhr gemacht haben.

Es gab keinen technischen Grund für die Nacht. Es gab eine Gewohnheit, die niemand hinterfragt hat, und ein Argument, das immer gleich klingt: „Dann merkt es keiner." Genau das ist das Problem. Wenn es keiner merkt, merkt es auch keiner, wenn es kaputt ist.

Woher das Ritual kommt

Die Idee ist alt und hatte mal einen Kern: Wenn dein System nur zu Bürozeiten genutzt wird, ist die Last um Mitternacht am niedrigsten, und ein Neustart trifft niemanden. Das galt für Installationen auf einem Server, bei denen ein Deploy ein Neustart war, und es galt für Teams, die keinen Weg hatten, eine Änderung zurückzunehmen, ohne alles neu auszurollen.

Beides ist in den meisten Projekten nicht mehr wahr. Deploys sind rolling oder blau-grün, ein Rollback ist ein Befehl, und die Last um Mitternacht ist bei einem globalen Publikum nicht niedriger, sondern nur anders verteilt. Das Ritual ist geblieben, die Begründung nicht.

Was die Nacht wirklich kostet

Der offensichtliche Preis ist die Nacht. Der teurere Preis ist die Blindheit. Um Mitternacht ist niemand im System unterwegs, also gibt es keine Nutzerbeschwerden, keine Support-Tickets und keine Daten, an denen du siehst, ob die Änderung funktioniert. Du deployst und hoffst, und du erfährst das Ergebnis am nächsten Morgen, wenn alle gleichzeitig aufschlagen.

Der dritte Preis ist die Entscheidung. Um 00:40 ist niemand mehr kreativ. Die Optionen sind „zurückrollen" oder „nochmal versuchen", und beides ist eine schlechte Wahl, wenn der Fehler in der Datenmigration liegt. Ein Rollback um 14 Uhr hat mehr Alternativen, weil die Leute, die das Feature gebaut haben, wach sind und das Monitoring lesen können.

Die erste Zeile ist die einzige, die oft wirklich zutrifft. Ein System, das nur zwischen 8 und 18 Uhr benutzt wird, hat um 3 Uhr keine Last, und dann ist die Nacht tatsächlich der billigere Zeitpunkt. Alles andere in der Tabelle spricht für den Tag.

Was ein Fenster am Tag braucht

Fünf Dinge, und wenn eines fehlt, verschiebst du den Release und nicht die Uhrzeit. Ein Feature-Flag, damit du abschalten kannst, ohne zu deployen. Einen Rollback, den du geübt hast und der unter fünf Minuten dauert. Ein Dashboard, das die drei wichtigsten Kennzahlen zeigt, und einen Alarm darauf. Eine Person, die nicht am Deploy beteiligt ist und nur zusieht. Und einen Grund, warum gerade jetzt.

Der letzte Punkt klingt banal und ist der wichtigste. „Weil es Freitag ist und wir es diese Woche schaffen wollten" ist kein Grund. „Weil wir seit Montag fünf Tage mit dem Flag im Testsystem laufen und die Fehlerrate gleich geblieben ist" ist einer. Der Unterschied ist nicht die Formulierung, sondern ob jemand nachgesehen hat.

Das Publikum ist der Punkt

Der Titel dieses Textes ist keine Metapher. Ein Release am Tag hat Publikum: Nutzer, die etwas merken, Support, der Anrufe bekommt, und Kollegen, die im selben Raum sitzen und sehen, dass du nervös bist. Das ist unangenehm und genau deshalb nützlich. Ein Fehler, der vor Publikum passiert, wird in Minuten gefunden; derselbe Fehler um Mitternacht wird in Stunden gefunden, meistens von jemandem, der nicht weiß, dass deployt wurde.

Ich habe das in einem Projekt umgedreht und die Release-Zeit auf 10 Uhr gelegt, mit einer halben Stunde Beobachtung danach. Die ersten zwei Releases waren peinlich, weil zwei Fehler sofort sichtbar wurden. Die nächsten zehn waren langweilig, und langweilig ist bei Releases das Ziel.

Fazit

Nächtliche Releases sind kein Zeichen von Sorgfalt, sondern meistens ein Zeichen dafür, dass Rollback und Beobachtung fehlen. Deploye dann, wenn du den Fehler sehen kannst, und sorge dafür, dass Zurücknehmen billiger ist als Weitermachen. Ein Release ohne Publikum ist keine Risikominimierung, es ist ein Blindflug mit Zeitstempel.

Wann hast du zuletzt deployt, ohne dass jemand zugesehen hat, und wie lange hätte es gedauert, den Fehler zu bemerken, wenn er aufgetreten wäre?