Atto VI: L'altra riva
Cutover
La domenica prima del lancio, preparo la pasta al limone. La preparo quasi tutte le domeniche da anni—un limone, un po’ della sua scorza, il burro che diventa seta nella padella, l’acqua di cottura amidacea che fa l’emulsione che i ricettari fanno sembrare più difficile di quanto sia. È la cosa più ordinaria che faccio in tutta la settimana. Stasera la preparo lentamente. Le dedico attenzione nel modo in cui dedichi attenzione a una cosa quando il resto della tua attenzione è da qualche parte dove non può fare niente. C’è un bicchiere di vino versato sul piano. L’ho versato per abitudine e poi l’ho guardato e ho capito che stasera non l’avrei bevuto, e lo lascio lì comunque, perché buttarlo via sembra un’ammissione e berlo sembra un’ammissione peggiore. Il runbook è accanto ai fornelli. È di quaranta pagine. L’ho stampato perché volevo tenerlo in mano, che non è una ragione che direi ad alta voce a nessuno del team.
Il runbook lo conosco. Ne ho scritto metà e ho riletto l’altra metà due volte. Stasera non lo leggo per imparare qualcosa. Lo tengo vicino al cibo perché domani un numero enorme di cose che ho provato accadranno in un ordine che ho provato, e accadrà anche qualcosa di non provato, e la pasta al limone è l’ultimo evento pienamente conoscibile tra adesso e l’altra sponda di tutto questo. Così la lascio richiedere più tempo di quanto serva. La pasta non è rilevante. È proprio per questo che è in questo capitolo.
Un cutover è il momento più provato di tutta una migrazione e resta comunque quello che più probabilmente ti sorprenderà, e questi due fatti non sono in contraddizione—sono lo stesso fatto che indossa due cappotti. Lo provi proprio perché sai che ti sorprenderà. La prova non è il modo in cui elimini la sorpresa. La prova è il modo in cui ti guadagni il diritto di essere sorpreso da qualcosa di piccolo invece che da qualcosa che fa saltare il lancio. I team che portano a casa un cutover in modo pulito non sono quasi mai quelli con il tooling più sofisticato, le dashboard più belle, tutto automatizzato. Sono quelli che hanno trattato la prova come il lavoro vero e non come una casella da spuntare, e che si sono presentati avendo già fatto pace con la parte che nessuno ama dire ad alta voce: che il rollback, nella pratica, di solito è una storia che racconti a te stesso più che una cosa che puoi fare.
Quindi prendiamo sul serio la prova, prima di tutto, perché è la parte con più leva e meno glamour.
Esegui il cutover dall’inizio alla fine, in staging, prima di eseguirlo per davvero. Poi eseguilo di nuovo. Non l’happy path—l’intero percorso, in sequenza, a orologio, con le persone che saranno davvero sveglie a fare le cose che faranno davvero, leggendo dal runbook che terranno davvero in mano. Una prova generale che dimostra solo i passaggi di cui eri già sicuro non ti ha detto niente che non sapessi. La prova generale che vale la pena di fare è quella che si rompe. Il cambio di DNS che si propaga più lentamente di quanto promettesse il foglio di calcolo. L’export dei dati che impiega novanta minuti quando il piano ne aveva preventivati quarantacinque. L’app di terze parti che deve essere riautorizzata sul nuovo store e sceglie la prova per scoprire che il flusso OAuth lancia un errore che nessuno vedeva dal proof of concept. Vuoi quelle scoperte di martedì pomeriggio due settimane prima, con il caffè e senza clienti, e non all’ora tre della cosa vera con la war room in silenzio in quel modo particolare in cui una war room diventa silenziosa quando qualcosa non va e nessuno l’ha ancora detto.
C’è una ragione per cui dev’essere l’intero percorso e non un sottoinsieme campionato, ed è la stessa ragione su cui il capitolo precedente si è soffermato così a lungo: lo staging ti sta mentendo su qualcosa, e tu non sai su cosa. Una prova completa è l’unico test onesto di quanto ti sta mentendo. Se il cutover di prova produce uno store che si comporta bene, hai delle prove. Se provi solo i passaggi che avevi capito, hai provato la tua comprensione, che non era mai stata la cosa a rischio.
E adesso la parte che andrebbe stampata in un carattere leggermente più grande e non lo è, perché il budget di produzione di questo libro è una finzione. Il rollback spesso non è reale.
Il piano avrà una sezione di rollback. È giusto che ce l’abbia. Scrivila, versionala, conservala. Ma sii onesto su cosa ti compra davvero, perché la parola rollback porta con sé una promessa che di solito non può mantenere, e la promessa è più o meno questa: se va storto, rimettiamo le cose com’erano. Il problema è l’orologio. Nel momento in cui il nuovo store comincia a prendere ordini reali—il primo cliente che fa checkout sulla nuova piattaforma—i due sistemi hanno divergato, e continuano a divergere ogni minuto in cui resti live. Il vecchio sistema non sa di quell’ordine. Non sa dell’inventario che quell’ordine ha decrementato, dei punti fedeltà che ha accumulato, della subscription che ha creato, dell’indirizzo che ha validato, del controllo antifrode che ha superato. Fai rollback al vecchio sistema un’ora dopo e non stai ripristinando uno stato pulito. Stai abbandonando un’ora di commercio reale che esiste solo sul sistema che hai appena spento, e adesso devi riconciliarla a mano, sotto pressione, mentre la cosa che ti aveva fatto venir voglia di fare rollback in primo luogo sta ancora andando a fuoco.
Questo è il catechismo a cui il libro continua a tornare, vestito in un altro costume ancora: migra le assunzioni, non solo il codice. Il piano di rollback migra un’assunzione—che il vecchio stato e il nuovo stato siano due punti di salvataggio tra cui puoi saltare—e quell’assunzione era vera fino al primo ordine, e falsa per sempre dopo. Quindi pianifica come se non potessi fare rollback. Non perché il rollback sia letteralmente impossibile in ogni caso; per alcuni guasti ristretti, colti nei primi minuti prima del volume reale, è davvero la tua mossa, e dovresti tenerlo affilato. Ma trattalo come un estintore, non come un paracadute. Un paracadute è il tuo piano per la caduta. Un estintore è per il piccolo incendio che cogli presto, e tutti nella stanza sanno che oltre una certa dimensione non stai spegnendo niente—stai evacuando. Non dire impossibile quando intendi rovinosamente costoso e lento, e non dire possiamo sempre fare rollback quando intendi possiamo, per circa undici minuti, dopo i quali la parola smette di significare qualcosa. I team che si scottano sono quelli che lasciano rollback nel piano come un oggetto di conforto, inesaminato, così che nessuno ha mai messo un prezzo su quanto sarebbe davvero costato usarlo finché, nel momento in cui ci hanno allungato la mano, non l’hanno trovato più pesante di come lo ricordavano.
Il che ci porta al runbook, e al perché una persona stampa quaranta pagine e le tiene accanto ai fornelli.
Il runbook è l’artefatto, e la sua strana proprietà è che esiste per un momento in cui nessuno lo leggerà. Il giorno stesso, non sfoglierai fino a pagina trentuno per scoprire cosa viene dopo; saprai cosa viene dopo, perché l’hai provato due volte e hai vissuto dentro questa sequenza per settimane. Il runbook non è un insieme di istruzioni per le persone che eseguono il cutover. È una promessa alle persone che non lo eseguono. È per la persona che si sveglia alle tre di notte due giorni prima del lancio con il cuore in gola, certa che qualcosa sia stato dimenticato, e che ha bisogno—non voglia, bisogno—di poter aprire un documento e vedere che qualcuno l’ha scritto. Ogni passaggio. Chi lo fa, quando, com’è fatto un fatto, cosa fare se non lo è. Il runbook converte un terrore privato in un oggetto condiviso che puoi indicare. Metà del suo valore viene consegnato prima del giorno del lancio, nel sonno che restituisce alle persone che altrimenti starebbero sveglie a fare l’audit del piano nella loro testa. Scrivilo per loro. Scrivilo come se la persona che lo legge fosse spaventata e competente e sola alle tre di notte, perché a un certo punto quella persona è reale, e in una buona migrazione quella persona sei tu.
Il giorno stesso, la disciplina è la comunicazione, e la regola è più piccola e più strana di quanto la gente si aspetti. Un canale. Uno. Non un canale per l’ingegneria e un canale per gli stakeholder e un thread laterale per il vendor e una catena di DM che tre persone portano avanti silenziosamente in parallelo—un canale, dove viene postato tutto, e una sola persona il cui unico lavoro è postare lì dentro. E la cadenza: ogni quindici minuti, a orologio, che ci siano notizie o no. Specialmente quando non ci sono notizie.
Sembra esagerato finché non ti sei seduto nel silenzio. Quando il canale diventa silenzioso durante un cutover, ogni persona che lo guarda riempie il silenzio con la propria ipotesi peggiore, e lo riempie in modo diverso, e nel giro di venti minuti hai un responsabile finance che pensa che gli ordini siano in calo, una CS manager che mette su un crisis bridge, e un ingegnere che ha dato per scontato che qualcun altro si stesse occupando del DNS perché il canale lasciava intendere una calma che in realtà era solo assenza. Nessuna notizia postato ogni quindici minuti non è rumore. È il messaggio portante. Cutover DNS completato, propagazione in corso, niente di azionabile, prossimo aggiornamento alle 14:45. Costa a chi posta otto secondi e compra a tutti gli altri la singola cosa più preziosa che puoi dare a uno stakeholder nervoso, che è sapere che qualcuno è sveglio ai comandi e che il silenzio è quello buono. Il silenzio è informazione. Assicurati che sia informazione che hai mandato apposta, e non informazione che il tuo pubblico si è inventato.
E qui c’è la parte che gli ingegneri tendono a sottovalutare, quindi noi la sopravvaluteremo apposta: le persone che contano di più durante un cutover sono di solito le persone che non sono nella war room.
La war room è piena delle persone che hanno costruito la cosa. Loro staranno bene. Parlano la lingua, sanno leggere le dashboard, sanno che la sync queue è ingolfata è un martedì e non un’emergenza. Le persone che non stanno bene sono l’agente del customer service che ha appena ricevuto un ticket da un cliente confuso e non sa se scusarsi o rassicurare, l’ops lead che guarda l’integrazione con il magazzino aspettando che il primo ordine passi, la persona del finance il cui intero rapporto con il giorno del lancio è un numero che dovrebbe salire. Hanno bisogno di sapere cosa sta succedendo. Hanno bisogno che sia in un linguaggio a cui ogni occorrenza di sync queue e propagazione e idempotency key sia stata chirurgicamente rimossa. Il nuovo store è live. Gli ordini stanno arrivando. Se un cliente dice che il suo vecchio account non funziona, ecco l’unica frase che gli dici. Ci aspettiamo che la search sembri un po’ scarna per la prima ora; è una cosa nota e si sta sistemando da sola. Scrivi quel comms packet prima del giorno, consegnalo alle persone ai margini dell’evento, e avrai prevenuto più danni nel giorno del lancio di qualsiasi quantità di monitoraggio aggiuntivo, perché il failure mode di un cutover è raramente solo tecnico. È tecnico-più-qualcuno-in-prima-linea-che-improvvisa-sotto-stress, e l’improvvisazione è la parte che puoi prevenire gratis.
Ancora una cosa sui giorni precedenti, perché è la cosa che silenziosamente affonda più cutover di quanti ne abbia mai affondati il DNS. Nell’ultima settimana, qualcuno vorrà spedire un’altra cosa.
Sarà ragionevole. Lo è sempre. Una piccola correzione di copy. Un minuscolo ritocco alla PDP. Una rapida aggiunta alle regole di spedizione perché un buyer l’ha chiesta gentilmente. La persona che chiede non è sciocca; il cambiamento è davvero piccolo, e in qualsiasi settimana normale lo spediresti senza pensarci due volte. Ma la settimana prima di un cutover non è una settimana normale. È la settimana in cui il tuo store di staging e il tuo target di produzione dovrebbero stare fermi abbastanza a lungo perché la prova significhi qualcosa, e ogni cambiamento che lasci passare è un cambiamento che la prova non ha coperto e che il runbook non menziona. Quindi dichiari un freeze, e lo tieni, e assorbi la piccola, reale, accumulante seccatura di dire a brave persone no, non questa settimana—e dai al no un posto dove andare, che è il backlog dei cambiamenti rinviati, la lista di tutto ciò che è genuinamente a posto e genuinamente in attesa e che verrà assolutamente fatto a partire dalla settimana dopo il lancio. Il freeze non è un rifiuto di quei cambiamenti. È una coda. Le persone accetteranno quasi qualsiasi no se arriva con un quando.
Così il cutover arriva, e per lo più va come l’avevi provato, e la cosa non provata si rivela piccola perché hai speso le tue sorprese in staging dove erano economiche. Gli ordini arrivano. Il canale si riempie di battiti cardiaci ogni quindici minuti. La persona sull’aereo atterra e gira la key. E a un certo punto nel tardo pomeriggio c’è un silenzio che è quello buono, quello che hai mandato apposta, e il nuovo store è semplicemente lo store adesso, nel modo in cui sarà lo store domani e ogni giorno dopo, senza niente di notevole, funzionante.
La pasta al limone della sera prima non ha mai riguardato la pasta. Riguardava il volere un’ultima cosa ordinaria e conoscibile prima di un giorno che non sarebbe stato ordinario e non poteva essere conosciuto del tutto. Quel volere non è debolezza e non è una mancanza di fiducia nel piano. È cosa si prova a tenere a qualcosa che non puoi controllare del tutto, che è l’unica descrizione onesta del mettere live una migrazione dentro cui vivranno persone reali. Provi così che il giorno sia per lo più conoscibile. Tieni il runbook vicino così che la parte inconoscibile abbia un testimone. E versi il vino che non berrai, e lo lasci sul piano, e domani—o il giorno dopo, quando i battiti si saranno fermati e lo store sarà solo lo store—torni e lo bevi, lentamente, perché la cosa per cui ti eri preparato e che non potevi controllare del tutto è successa lo stesso, e ha tenuto.