Ciao, e benvenuto nella prima puntata della settantatreesima stagione. Nella stagione scorsa abbiamo imparato a costruire gli occhi per vedere dentro i nostri sistemi. Ma vedere apre subito una domanda scomoda: di chi è il compito di agire su ciò che vediamo? Chi possiede, davvero, il sistema che gira in produzione? Chi si sveglia la notte quando cade? La risposta a queste domande è un modo di lavorare che ha un nome ormai abusato e quasi sempre frainteso: DevOps. E oggi cominciamo a smontare il fraintendimento.
Partiamo dalla storia, perché DevOps nasce per curare una malattia precisa. Per decenni, in tante aziende, chi faceva software era diviso in due tribù separate da un muro. Da una parte gli sviluppatori: pagati per cambiare le cose, aggiungere funzioni, andare veloci. Dall'altra chi mandava in produzione e teneva su i server: pagato per l'esatto contrario, cioè per la stabilità, per far sì che niente si rompesse, e quindi diffidente verso ogni cambiamento. Due gruppi con obiettivi opposti, premiati per cose opposte, che si guardavano in cagnesco da una parte e dall'altra di un muro.
Vediamo cosa succedeva a quel muro, perché è il cuore del problema. Gli sviluppatori finivano il loro lavoro e lo lanciavano oltre il muro, all'altra squadra: ecco il codice, adesso è un tuo problema mandarlo in produzione. E quando qualcosa si rompeva, e si rompeva sempre, cominciava il rimpallo delle colpe. Gli sviluppatori dicevano: sul mio computer funzionava. Gli altri rispondevano: allora è colpa di come l'avete scritto. Nessuno possedeva davvero il risultato finale, quello che l'utente vedeva. Ognuno possedeva solo il suo pezzetto, e il muro in mezzo ingoiava ogni responsabilità. Ed è il peggior modo possibile di lavorare: due squadre che dovrebbero remare insieme finiscono per remare l'una contro l'altra.
Immagina tutto questo come una fabbrica malfatta, perché sarà la nostra immagine per la stagione. C'è un reparto che progetta e costruisce i pezzi, e un altro reparto, dall'altra parte di un muro, che deve assemblarli e spedirli ai clienti. I due reparti non si parlano. Il primo scavalca il muro e butta di là i suoi pezzi, spesso incompleti, senza istruzioni. Il secondo si arrangia, impreca, e quando un cliente si lamenta i due si accusano a vicenda. Una fabbrica così produce poco, produce male, e rende infelici tutti quelli che ci lavorano. Il lavoro non scorre: si accumula, si inceppa, e ogni consegna è una battaglia.
E qui arriva la magia, il modo sbagliato ma comodo di pensare alla soluzione. La magia dice che DevOps è una cosa che compri. È un insieme di strumenti: installi quello per i contenitori, quello per orchestrarli, quello per la catena di rilascio, e come per incanto sei diventato veloce e affidabile. Oppure la magia dice che DevOps è un reparto: assumi un DevOps engineer, o crei un team DevOps, gli deleghi tutto il problema, e te ne lavi le mani. In entrambi i casi l'idea è la stessa: esiste una scorciatoia, un prodotto o una persona, che ti regala il risultato senza dover cambiare niente di come lavori davvero. È un'idea seducente proprio perché non chiede niente di difficile.
Vediamo allora la macchina che c'è sotto, perché è tutta un'altra cosa. DevOps non è uno strumento, non è un titolo, non è un reparto. È una scelta culturale su come le persone lavorano insieme. È la decisione di abbattere quel muro, così che le stesse persone che costruiscono una cosa siano anche quelle che la mandano in produzione e ne sentono le conseguenze. Gli strumenti che tutti associano a DevOps, i contenitori, le catene di rilascio, l'automazione, non sono la sostanza: sono solo l'espressione fisica di quella scelta. E se prendi gli strumenti senza fare la scelta culturale, ottieni quello che si chiama un culto del cargo: imiti i gesti di chi ha successo sperando che la magia arrivi, ma senza capire cosa li rende efficaci.
Voglio lasciarti con la domanda che questa stagione terrà al centro, perché ribalta il modo di vedere le cose. La vera domanda di DevOps non è quali strumenti uso, ma: chi possiede il risultato, dall'idea fino all'utente, e ne sente davvero le conseguenze? Il muro tra chi costruisce e chi fa funzionare non è fatto di mattoni: è fatto di obiettivi contrapposti, di responsabilità divise, di persone che non si parlano. E DevOps, prima di essere qualunque tecnologia, è il tentativo paziente di abbattere quel muro. Nelle prossime puntate vedremo come, un mattone alla volta.
Per oggi ci fermiamo qui. Abbiamo raccontato la malattia da cui nasce DevOps: due tribù divise da un muro, gli sviluppatori premiati per il cambiamento e chi tiene su i server premiato per la stabilità, obiettivi opposti e un continuo rimpallo di colpe, come una fabbrica dove il reparto che costruisce e quello che spedisce si odiano. La magia dice che DevOps è uno strumento da comprare o un reparto a cui delegare. La macchina sotto è che DevOps è una scelta culturale: abbattere il muro, così che chi costruisce una cosa la mandi anche in produzione e ne senta le conseguenze. Gli strumenti senza la cultura sono solo un culto del cargo. Nella prossima puntata: costruisci, e fallo funzionare. Nelle note trovi qualche spunto. Se ti è utile, condividila. Grazie per l'ascolto, e ci sentiamo alla prossima.