L’illusione DevOps e l’arte di automatizzare i disastri

C’è un fenomeno affascinante nel mondo IT contemporaneo: aziende che proclamano orgogliosamente di aver adottato pratiche DevOps mentre continuano a copiare file in produzione via FTP incrociando le dita. È come dichiarare di aver abbracciato la medicina moderna mentre si eseguono interventi chirurgici con coltelli da cucina. Tecnicamente possibile, ma con conseguenze prevedibilmente catastrofiche.

Quando l’automazione peggiora le cose

Esiste una categoria particolare di fallimento che merita attenzione speciale: l’illusione DevOps. Si manifesta quando un’organizzazione implementa pipeline automatizzate senza comprenderne lo scopo fondamentale. Il risultato è una versione accelerata e più efficiente di introdurre bug in produzione.

Senza una solida copertura di test automatici, la pipeline CI/CD diventa semplicemente un modo più veloce di rompere le cose. È come costruire un’autostrada per trasportare spazzatura: hai migliorato l’efficienza del processo, ma non il risultato finale. Ogni commit viene automaticamente buildato, testato superficialmente, e deployato in produzione con la velocità della luce. Il fatto che nessuno di questi passaggi verifichi realmente che il codice funzioni è un dettaglio trascurabile.

Molte organizzazioni misurano il successo del loro processo DevOps dal numero di deploy al giorno. Centinaia di rilasci settimanali vengono celebrati come vittoria, ignorando completamente che la metà richiede hotfix immediati e l’altra metà introduce regressioni scoperte solo settimane dopo. È come vantarsi del numero di operazioni eseguite da un chirurgo senza menzionare il tasso di sopravvivenza dei pazienti.

La roulette russa della produzione

Il deploy manuale via FTP rappresenta l’apice dell’antiquariato tecnologico. Modificare direttamente file sui server di produzione viola praticamente ogni principio di gestione software moderno. È giocare alla roulette russa con l’infrastruttura aziendale, dove ogni deploy diventa momento di tensione collettiva e preghiera silenziosa.

La fragilità è allarmante. Un singolo errore di battitura, un copia-incolla impreciso, una distrazione momentanea possono tradursi in downtime completo. Non c’è margine di errore, nessuna rete di sicurezza, nessuna possibilità di rollback rapido. È come camminare su una fune sopra un burrone senza imbracatura, convinti che l’equilibrio perfetto sia garantito dall’esperienza.

Il paradosso è che queste pratiche sopravvivono sotto l’illusione di essere più veloci. “Perché complicarsi la vita con sistemi automatizzati quando posso copiare quattro file in trenta secondi?” La risposta arriva puntuale il giorno in cui quei trenta secondi diventano otto ore di downtime perché il file copiato ha sovrascritto configurazioni critiche non versionate.

Il paracadute d’emergenza che non si apre

La gestione inadeguata dei rollback rivela il suo difetto solo nei momenti più critici. È scoprire che il paracadute d’emergenza è difettoso solo quando quello principale ha già fallito. Non il momento ideale per questa rivelazione.

Molti team si concentrano esclusivamente sul percorso felice del deploy senza mai testare procedure di rollback. Fino al giorno della crisi reale, quando scoprono che tornare alla versione precedente richiede interventi manuali complessi, ripristino di database, ricostruzione di configurazioni perse. Il rollback dovrebbe essere noioso come il deploy, testato altrettanto frequentemente, automatizzato con la stessa cura.

Ma testare il rollback significa ammettere che i deploy possono fallire, e questa ammissione sembra incompatibile con la narrazione dell’infallibilità tecnologica che molte organizzazioni preferiscono coltivare.

L’ambiente di produzione misterioso

Un’applicazione che funziona perfettamente in sviluppo ma crolla misteriosamente in produzione è sintomo classico di ambienti mal configurati o non standardizzati. Le differenze ambientali diventano mine nascoste che esplodono solo quando è troppo tardi.

Password hardcoded che funzionano in sviluppo ma non in produzione. Percorsi assoluti che esistono solo sulla macchina dello sviluppatore originale. Dipendenze non specificate che vengono installate casualmente sui server. Variabili d’ambiente documentate solo nella memoria dello sviluppatore che ha lasciato l’azienda sei mesi fa.

Ogni deploy diventa un’avventura imprevedibile. “Funziona sulla mia macchina” smette di essere una battuta e diventa la difesa standard quando tutto crolla. La mancanza di standardizzazione trasforma ogni server in un fiocco di neve unico, impossibile da replicare, impossibile da debuggare, impossibile da sostituire.

Pipeline ibride e il peggio di due mondi

Le implementazioni parzialmente automatizzate creano situazioni paradossali. Alcuni passaggi sono automatizzati con precisione militare, altri richiedono intervento manuale con annessa possibilità di errore umano.

Queste pipeline ibride nascono spesso da progetti di trasformazione incompiuti. Si inizia ad automatizzare con entusiasmo, poi si scopre che alcuni pezzi sono “troppo complessi” o “troppo legacy” per essere inclusi. Il risultato è un Frankenstein di processi che richiede documentazione dettagliata di quali parti sono automatiche e quali richiedono intervento umano, documentazione che naturalmente esiste solo nella tradizione orale del team.

Il fraintendimento fondamentale

DevOps non riguarda primariamente strumenti o automazione. Riguarda collaborazione e responsabilità condivisa. Quando sviluppatori e operazioni continuano a lavorare in silos separati, anche con la pipeline più sofisticata, si stanno semplicemente automatizzando conflitti esistenti invece di risolverli.

Gli sviluppatori lanciano codice oltre il muro aspettandosi che le operazioni lo gestiscano magicamente. Le operazioni implementano restrizioni senza comprendere le necessità di sviluppo. La pipeline automatizza questo processo disfunzionale, accelerando la velocità con cui le due parti non comunicano.

La vera ironia è che molte organizzazioni adottano DevOps per motivi sbagliati: perché promette vagamente maggiore velocità, perché tutti lo stanno facendo, perché sembra moderno. Non perché comprendono che richiede cambio culturale profondo, non solo installazione di strumenti.

Quando la velocità diventa il nemico

La promessa del DevOps è deployment continuo, rilasci frequenti, feedback rapido. Ma velocità senza qualità è solo un modo efficiente di produrre disastri. Come un’automobile sportiva senza freni: impressionante finché non devi fermarti.

Le metriche diventano l’obiettivo invece che lo strumento. “Facciamo dieci deploy al giorno” diventa il traguardo, indipendentemente da cosa contengono quei deploy o se introducono problemi. La frequenza sostituisce il valore come misura di successo.

Il feedback rapido perde significato se nessuno ascolta. Sistemi di monitoring sofisticati che generano alert ignorati, dashboard piene di metriche che nessuno consulta, log dettagliati che nessuno analizza. Hai tutti gli strumenti del mestiere, ma manca la disciplina per usarli efficacemente.

Costruire fondamenta solide

Il DevOps vero inizia con principi fondamentali. Controllo di versione per tutto, non solo il codice ma anche configurazioni, script, documentazione. Ambienti standardizzati che replicano fedelmente la produzione. Test automatici che verificano realmente il comportamento, non solo che il codice compili.

Automazione completa del deploy, dall’inizio alla fine, senza passaggi manuali nascosti. Procedure di rollback testate regolarmente, non teorizzate al volo durante emergenze. Monitoring che fornisce visibilità reale dello stato del sistema, non solo numeri che fanno bella figura nelle presentazioni.

Ma soprattutto richiede cultura di collaborazione dove sviluppatori si preoccupano dell’operatività e operazioni comprendono le necessità di sviluppo. Dove i fallimenti diventano opportunità di apprendimento, non cacce alle streghe. Dove la qualità è responsabilità collettiva, non compito delegato al team di QA.

La bomba a orologeria

Pratiche arcaiche come il deploy FTP sopravvivono perché sembrano funzionare finché non esplodono. È una bomba a orologeria che ticchetta silenziosamente, ignorata fino al momento della detonazione. Il tempo risparmiato con questa presunta efficienza verrà pagato con interessi esorbitanti in ore di debugging, scuse ai clienti per downtime inaspettati, notti insonni a sistemare disastri evitabili.

La vera efficienza emerge da processi solidi, ripetibili, automatizzati. Richiede investimento iniziale di configurazione, ma ripaga abbondantemente in stress risparmiato, bug evitati, sonno recuperato. Ma per alcuni, l’adrenalina del deploy manuale in produzione rimane un’esperienza insostituibile. Fino al giorno in cui qualcosa va irrimediabilmente storto e l’adrenalina si trasforma in panico puro.

Questo articolo è tratto da “Non funziona niente! – I progetti IT in crisi”, il primo libro della collana Nothing Works! — una tragicommedia aziendale per chi ha visto troppi Gantt chart trasformarsi in fiction.

Scopri la collana completa, gli altri libri e le prossime uscite su nothingworks.it

Vuoi il libro subito? Compralo su Amazon

Potrebbe interessarti anche

• Sistemista IT in una PMI: mansioni e competenze
• DIRETTORE ACQUISTI
• Perché documentare gli interventi IT potenzia la posizione del Sistemista?
• Da sistemista IT a IT Manager: un, possibile, percorso di carriera nell’ambito manifatturiero
• I problemi quotidiani di un Sistemista IT e come risolverli
• SISTEMISTA
• Quanto guadagna un Sistemista a Torino?
• SISTEMISTA IT
• Cosa fa un Sistemista in un Managed Service Provider: ruolo e giornata tipo
• Dieci clienti, un solo Sistemista: come si gestiscono le priorità in un Managed Service Provider