Ciao, e benvenuto nella settima puntata della settantatreesima stagione. Oggi affronto la convinzione più radicata e più sbagliata che ci sia nel nostro mestiere, quella che divideva le due tribù di cui parlavamo all'inizio: l'idea che velocità e stabilità siano nemiche. Che per essere sicuri bisogna andare piano, e che chi va veloce, per forza, rompe le cose. Oggi ti spiego perché è falso, e perché è vero quasi l'esatto contrario.
Partiamo dalla vecchia credenza, perché è comprensibile e ci è stata insegnata per anni. Sembra ovvio: se rilasci di rado, con calma, dopo mesi di verifiche, sei più prudente. Se rilasci in continuazione, sei un incosciente che gioca col fuoco. Da qui nascono i blocchi dei rilasci prima delle feste, i moduli da firmare in triplice copia per cambiare una virgola, la paura di toccare qualsiasi cosa. Tutto in nome della stabilità. L'intenzione è buona: rallentare per non fare danni. Ma il risultato, come vedremo, ottiene spesso l'opposto di quello che promette.
Vediamo cosa dicono i fatti, perché su questo, per fortuna, non dobbiamo tirare a indovinare: esistono ricerche fatte su migliaia di squadre reali. E il risultato è netto e sorprendente. Le squadre che rilasciano più spesso, anche molte volte al giorno, non sono le più instabili. Sono le più stabili. Rompono le cose di meno, e quando qualcosa si rompe, si rialzano molto più in fretta. Velocità e stabilità non solo non sono nemiche: vanno a braccetto. Le stesse squadre che sono veloci sono anche quelle affidabili, e le squadre lente sono spesso anche le più fragili. È l'opposto esatto di quello che l'intuizione ci suggerisce. Queste ricerche misurano poche cose semplici: ogni quanto una squadra rilascia, quanto tempo passa da quando scrive una modifica a quando la vede in produzione, ogni quanto un rilascio combina un guaio, e quanto in fretta si rimette in piedi dopo. E su tutte e quattro, chi va veloce vince anche sulla stabilità.
Nota adesso perché succede questo, perché la spiegazione è semplice e la conosci già: sono i lotti piccoli. Una squadra che rilascia spesso, per forza di cose, rilascia cambiamenti piccoli. E un cambiamento piccolo è facile da capire, facile da controllare, e se va male facile da annullare in un attimo. Una squadra che rilascia di rado accumula mesi di modifiche in un unico rilascio gigantesco: un mostro difficile da capire, impossibile da testare davvero, e terrificante da annullare. Quando quel mostro esplode, ed esplode spesso, il danno è enorme e ci metti giorni a capire quale delle mille modifiche è stata la colpevole. Rilasciare spesso è più sicuro proprio perché ogni singolo rilascio rischia meno.
Colleghiamo questo a un'idea potente della stagione scorsa, quella del budget di errore. Ti ricordi? Ci siamo dati il permesso di non essere perfetti, riservandoci un margine di errore consentito. Ecco, quel margine è precisamente ciò che ti permette di andare veloce con serenità: finché sei dentro il budget, puoi rilasciare, sperimentare, osare, perché puoi permetterti qualche piccolo inciampo. Velocità e stabilità smettono di essere in guerra e diventano due leve della stessa macchina: il budget di errore è il cruscotto che ti dice quanto forte puoi spingere sull'acceleratore senza uscire di strada.
E qui c'è un obiettivo pratico, quasi uno slogan, che riassume tutto: rendere il rilascio così noioso da poterlo fare un venerdì pomeriggio. Nel vecchio mondo, mandare in produzione era un evento drammatico: tutti col fiato sospeso, il capo che guarda, nessuno che osa farlo il venerdì per paura di rovinarsi il weekend. In una squadra matura di DevOps, il rilascio è un non-evento: succede decine di volte al giorno, in automatico, senza che nessuno trattenga il respiro. La grandezza non è nel rilascio spettacolare andato bene per miracolo: è nel rilascio talmente ordinario, sicuro e reversibile da essere diventato noioso. La noia, qui, è il segno più alto della maturità. Un rilascio che fa paura è il sintomo di un processo malato, non di un lavoro serio.
Voglio lasciarti con il capovolgimento definitivo di questa puntata, quello che devi portarti via. Andare piano non ti rende sicuro: ti rende solo più lento a scoprire i guai, e più grande il botto quando arrivano. La vera sicurezza non nasce dal muoversi con paura, ma dal costruire un sistema in cui muoversi in fretta è sicuro: piccoli passi, controlli automatici che tirano la corda, la possibilità di tornare indietro in un attimo. La domanda giusta non è dovremmo andare più piano per essere sicuri, ma: cosa ci impedisce, oggi, di andare veloci in sicurezza? Rispondere a quella domanda, e togliere quegli ostacoli uno per uno, è buona parte del lavoro di DevOps.
Per oggi ci fermiamo qui. Abbiamo demolito la convinzione più radicata del mestiere: che velocità e stabilità siano nemiche. La vecchia credenza dice che rilasciare di rado è prudente; i fatti, misurati su migliaia di squadre, dicono l'opposto, cioè che chi rilascia più spesso è anche più stabile e si rialza più in fretta. Il motivo lo conosci: i lotti piccoli sono facili da capire, controllare e annullare, mentre il rilascio gigante è un mostro terrificante. Il budget di errore è ciò che ti fa spingere l'acceleratore con serenità, e l'obiettivo è rendere il rilascio così noioso da poterlo fare un venerdì pomeriggio. Andare piano non ti rende sicuro: ti rende solo più lento a scoprire i guai. Nella prossima puntata: il giorno del rilascio. Nelle note trovi qualche spunto. Se ti è utile, condividila. Grazie per l'ascolto, e ci sentiamo alla prossima.