Ciao, e benvenuto nella nona puntata della settantatreesima stagione. Siamo quasi alla fine, ed è il momento del bilancio onesto, la puntata in cui metto sul tavolo tutte le trappole, gli abusi e i limiti di DevOps. Perché DevOps è insieme una delle idee più preziose e una delle più fraintese del nostro mestiere. E capire dove e come si sbaglia vale quanto capire come si fa bene.
Partiamo dall'errore più comune di tutti, quello che abbiamo chiamato fin dall'inizio il culto del cargo. Un'azienda sente parlare di DevOps, e cosa fa? Compra tutti gli strumenti: i contenitori, l'orchestratore, la catena di rilascio, il cruscotto pieno di grafici. Assume gente con DevOps scritto sul biglietto da visita. E poi si stupisce che niente sia cambiato, che i rilasci facciano ancora paura, che i due reparti si odino come prima. È ovvio che sia così: hanno comprato gli attrezzi senza fare la scelta culturale che li rende utili. Hanno imitato i gesti di chi ha successo, sperando nella magia, senza capire cosa c'era sotto.
Vediamo la forma più beffarda di questo errore, perché è quasi comica. Molte aziende creano un nuovo reparto e lo chiamano il team DevOps. Fermiamoci un attimo a pensarci: DevOps nasce per abbattere il muro tra due reparti, e la reazione è creare un terzo reparto. Così, invece di un muro, adesso ne hai due. Oppure prendono il vecchio reparto che teneva su i server, gli cambiano il nome in qualcosa di più moderno, e continuano esattamente come prima, con gli stessi incentivi contrapposti e lo stesso muro. Cambiare l'etichetta senza cambiare la sostanza è il modo più diffuso di fingere di fare DevOps senza farlo davvero.
E qui devo essere equilibrato, perché il pericolo opposto esiste ed è altrettanto reale. Se gli strumenti senza la cultura sono un guscio vuoto, anche la cultura senza gli strumenti è solo un bel discorso. Puoi predicare quanto vuoi l'abbattere il muro, la responsabilità condivisa, il ritorno rapido: ma se poi ogni rilascio richiede due giorni di lavoro manuale, la buona volontà si schianta contro la realtà. Servono entrambe le cose, e in quest'ordine: prima la scelta culturale, che dà senso a tutto, poi gli strumenti, che la rendono concreta e sostenibile. Una senza l'altra non porta lontano.
Nota adesso un limite di cui si parla troppo poco: DevOps non è gratis, e non serve a tutti. Adottarlo davvero richiede un vero cambiamento di come è organizzata un'azienda, di chi risponde di cosa, di come le persone vengono valutate. È un investimento serio, faticoso, che tocca le abitudini e il potere delle persone. E come ogni investimento, ha senso solo se la posta in gioco lo giustifica. Un sito di poche pagine, gestito da una persona, che cambia due volte l'anno, non ha bisogno di una catena di rilascio a cinque stadi né di un reparto dedicato. Applicare tutta la macchina di DevOps a un problema piccolo è sprecare energie, e complicarsi la vita per moda.
Colleghiamo questo a un filo che percorre tutte le nostre stagioni, quello della dose giusta. Come per ogni strumento potente di cui abbiamo parlato, la domanda non è DevOps sì o DevOps no, ma: quanto, per questo problema qui? Le pratiche di DevOps si possono, e si devono, dosare. Una piccola squadra prende i principi, il rilascio piccolo, la marcia indietro, la responsabilità condivisa, e li applica in forma leggera, senza la pesantezza delle grandi organizzazioni. Perché anche DevOps, se preso senza misura, può diventare la sua stessa malattia: una burocrazia di processi e strumenti così pesante da rallentare proprio quel lavoro che doveva far scorrere. La sovra-ingegnerizzazione è sempre in agguato, anche qui.
Voglio lasciarti con il segno della vera maturità in questa materia, quello che distingue chi ha capito da chi ripete parole. La persona matura non chiede quali strumenti mi servono per fare DevOps, perché ha capito che DevOps non è una cassetta di attrezzi. Chiede: come vogliamo lavorare insieme, e quali strumenti ci aiutano a lavorare così? Sa che sta scegliendo un modo di lavorare, non comprando un prodotto. Sa che la cultura viene prima, ma che senza strumenti resta un sogno. E sa dosare tutto questo alla posta in gioco reale, senza né snobbare le buone pratiche né trasformarle in un feticcio. Cultura prima degli strumenti non vuol dire strumenti mai: vuol dire strumenti al servizio di una scelta, e mai al posto di essa.
Per oggi ci fermiamo qui. Abbiamo fatto il bilancio onesto di DevOps. L'errore più comune è il culto del cargo: comprare gli strumenti e assumere gente senza fare la scelta culturale, con la variante beffarda di creare un team DevOps, cioè un terzo reparto, o rinominare il vecchio senza cambiare gli incentivi. Ma vale anche il contrario: la cultura senza strumenti è solo un discorso, servono entrambi, prima la cultura e poi gli attrezzi. E DevOps non è gratis né universale: richiede un vero cambiamento organizzativo, ha senso solo se la posta lo giustifica, e va dosato, perché anche lui può diventare una burocrazia sovra-ingegnerizzata. La maturità è sapere che scegli un modo di lavorare, non compri un prodotto. Nella prossima e ultima puntata: un modo di lavorare. Nelle note trovi qualche spunto. Se ti è utile, condividila. Grazie per l'ascolto, e ci sentiamo alla prossima.