Ein Deploy ging vor einer Stunde raus und die Fehlerraten steigen seitdem. Was machst du?

Erst zurückrollen, dann untersuchen, es sei denn, der Deploy enthielt eine Datenbankmigration, die den Rollback unsicher macht. Bestätige, dass die Zeitachse zum Deploy passt, prüf, ob sich die Fehler auf die Instanzen der neuen Version konzentrieren, und geh dann auf das vorherige Artefakt zurück oder schieb den Traffic zurück. Sobald sich die Fehlerrate erholt hat, halte den fehlerhaften Build in einer Staging-Umgebung verfügbar, damit du diagnostizieren kannst, ohne dass Nutzer dafür zahlen.

Default ist zurückrollen. Eine Stunde steigender Fehler ist kein Rätsel, das man live löst, es ist eine Blutung, die man stoppt, und das vorherige Artefakt ist als gut bekannt. Bevor ich abdrücke, mache ich zwei schnelle Checks. Erstens: Beginnt die Fehlerkurve tatsächlich zur Deploy-Zeit oder stieg sie schon davor, denn wenn sie früher begann, ist der Deploy ein Zufall und der Rollback verbrennt zehn Minuten. Zweitens: Enthielt das Release eine Schemamigration, denn dann muss ich wissen, ob der alte Code noch gegen das neue Schema funktioniert. Haben wir Expand and Contract sauber gemacht, tut er das und der Rollback ist sicher. Hat jemand eine Spalte gedroppt, ist der Rollback jetzt die gefährliche Option und ich gehe stattdessen auf einen Forward Fix oder ein Feature Flag. Sobald sich die Fehler erholen, lasse ich den schlechten Build in Staging deployt, damit wir ohne Kunden reproduzieren können. Danach würde ich darauf drängen, warum ein Canary das nicht gefangen hat, denn eine Stunde Impact heißt, der Rollout hat die Fehlerrate nicht gegen eine Baseline beobachtet.