Ciao, e benvenuto nell'ottava puntata della quindicesima stagione. Nella scorsa puntata abbiamo portato il codice fino agli utenti, con il rilascio. Ma anche quando il rilascio è automatico e verificato, resta una domanda di prudenza: come lo facciamo nel modo più sicuro possibile? Perché anche il codice più collaudato può nascondere un problema che emerge solo davanti agli utenti veri. Oggi vediamo le strategie per rilasciare con prudenza, quelle tecniche accorte che permettono di introdurre le novità limitando i danni se qualcosa va storto. È l'arte di rilasciare senza rischiare grosso.
Partiamo dal riconoscere un limite onesto, che riprende un tema del podcast. Per quanto tu abbia testato il codice, i test non possono prevedere tutto: la realtà, con i suoi utenti veri, il suo traffico vero, i suoi dati veri, è sempre più ricca e imprevedibile di qualsiasi ambiente di prova. Quindi c'è sempre una piccola possibilità che una nuova versione, pur avendo superato tutti i controlli, riveli un problema solo quando incontra il mondo reale. Non è un fallimento dei test: è la natura delle cose. E la saggezza non sta nel pretendere che non accada mai, ma nel prepararsi a quando accadrà, in modo che il danno sia minimo. Rilasciare con prudenza significa proprio questo.
La prima strategia, la più importante, è il rilascio graduale: non dare la novità a tutti in una volta, ma a pochi utenti per cominciare. Invece di sostituire di colpo la vecchia versione con la nuova per tutti, la nuova versione viene mostrata all'inizio solo a una piccola fetta di utenti, mentre la grande maggioranza continua a usare la vecchia, collaudata. Osservi come si comporta la nuova versione su quel piccolo gruppo: se tutto va bene, la estendi a una fetta più grande, e poi a un'altra ancora, allargando via via, finché non copre tutti. Se invece emerge un problema, lo scopri quando ne è toccata solo una piccola parte, e non l'intera platea.
Voglio farti apprezzare la saggezza di questo, perché è un'idea potente che i tecnici chiamano ridurre il raggio dell'esplosione. Immagina un problema come un'esplosione: se rilasci a tutti in una volta e c'è un difetto, l'esplosione colpisce tutti gli utenti insieme, un disastro enorme. Se invece rilasci prima solo all'uno per cento, e c'è un difetto, l'esplosione colpisce solo quell'uno per cento, un danno piccolo e contenuto, mentre tutti gli altri restano al sicuro sulla versione buona. Rilasciare gradualmente significa fare in modo che, se qualcosa esplode, lo faccia in piccolo, colpendo pochi, invece che in grande, colpendo tutti. È l'arte di contenere i danni prima ancora che accadano.
La seconda strategia, complementare alla prima, è la capacità di tornare indietro all'istante, e qui riprendo concetti di due stagioni. Anche rilasciando gradualmente, quando scopri un problema vuoi poter annullare subito la nuova versione e riportare tutti alla vecchia, funzionante. Ricordi, dalla stagione su Docker, che gli artefatti immutabili restano intatti e disponibili; e dalla stagione su Kubernetes, che si può ordinare di tornare alla versione precedente senza interruzioni. Ecco: mettendo insieme queste capacità, se una nuova versione si rivela difettosa, basta un gesto per ripristinare in un attimo l'ultima versione buona, che è ancora lì, pronta. Il problema viene spento rapidamente, prima che si diffonda. La reversibilità immediata è la tua rete di salvataggio.
Voglio mettere insieme queste idee in un principio guida che vale sempre, oltre le tecniche specifiche: rendi i rilasci piccoli, reversibili e osservabili. Piccoli, perché una novità piccola, se sbaglia, sbaglia in piccolo, ed è facile capire cosa è andato storto. Reversibili, perché poter tornare indietro all'istante rende ogni errore rimediabile e quindi poco spaventoso. E osservabili, perché devi poter vedere, mentre rilasci, se le cose stanno andando bene o male, per accorgerti subito di un problema e reagire. Piccolo, reversibile, osservabile: se i tuoi rilasci hanno queste tre qualità, ogni errore diventa poco costoso, e rilasciare smette di far paura anche quando qualcosa, inevitabilmente, ogni tanto va storto.
Voglio farti notare come tutto questo cambi radicalmente il rapporto con l'errore, perché è la sintesi filosofica della puntata. Nel vecchio mondo dei rilasci grandi, rari e irreversibili, un errore era una catastrofe: colpiva tutti, era difficile da rimediare, e quindi si viveva nel terrore di sbagliare. In questo nuovo mondo dei rilasci piccoli, graduali e reversibili, un errore diventa un piccolo inciampo: colpisce pochi, si annulla in un attimo, si impara la lezione e si va avanti. Non si tratta di non sbagliare mai, cosa impossibile, ma di rendere gli sbagli così piccoli e rimediabili da non fare più paura. È un modo completamente diverso, e molto più sano, di convivere con l'inevitabilità dell'errore.
Per oggi ci fermiamo qui. Anche con codice collaudato, la realtà può rivelare problemi, quindi si rilascia con prudenza. La strategia principale è il rilascio graduale: dare la novità prima a pochi utenti, e allargare solo se tutto va bene, così da ridurre il raggio dell'esplosione se c'è un difetto. La seconda è poter tornare indietro all'istante, sfruttando gli artefatti immutabili e i meccanismi di Kubernetes. Il principio guida è rendere i rilasci piccoli, reversibili e osservabili, così che ogni errore sia poco costoso. Nella prossima puntata alziamo lo sguardo dalla tecnica alla cultura che sta dietro l'automazione. Nelle note trovi qualche spunto. Se ti è utile, condividila. Grazie per l'ascolto, e ci sentiamo alla prossima.