Formazione scritta DevOps

Quali problemi incontra l'IT senza DevOps?

In un mondo IT senza DevOps, i team di sviluppo e quelli operativi entrano spesso in conflitto. L'assicurazione della qualità delle funzionalità e dei vantaggi richiesti dal cliente, lungo tutto il processo, inizia soltanto quando il team di sviluppo passa a un progetto completamente diverso. Gli audit sulla sicurezza delle informazioni e sulla preparazione alla produzione si svolgono il giorno prima della messa in produzione prevista. Risolvere problemi software in questa fase critica del progetto, soprattutto difetti di progettazione e sicurezza che si sarebbero dovuti individuare e correggere 8 mesi prima, mette a rischio la continuità sia dell'IT sia dell'attività aziendale. Sviluppatori stanchi, team operativi poco collaborativi, gruppi isolati per il test e la sicurezza delle informazioni, project manager e product manager esigenti ma disperati, dirigenti arrabbiati, clienti e portatori di interesse IT frustrati apportano ben poco valore.

Troppi passaggi di attività e dipendenze in ogni direzione immaginabile, oltre a innumerevoli interventi manuali, non coordinati e poco trasparenti nel reparto IT. È un giorno come tanti.

Nonostante i tempi lunghi per portare a termine qualsiasi lavoro, non ci sono opzioni migliori, almeno per ora, e sai che hai ancora bisogno di questo lavoro per guadagnare.

Finalmente arriva il grande giorno. Dopo un deployment in produzione problematico e caotico che ha causato notevoli tempi di inattività, ti chiedi se abbia compromesso funzionalità già in produzione. Ti rendi conto che manca chiarezza e che non ci sono prove concrete su cosa sia realmente accaduto e su quali parti dei sistemi di produzione siano state coinvolte.

Eppure nei corridoi della grande sala IT sono già iniziati i festeggiamenti per la messa in produzione. È il momento di bere qualcosa e riprendersi dalla notte difficile e insonne. Quello che hai compromesso in produzione la scorsa notte sarà comunque un problema di qualcun altro. Niente di grave…

A questo punto ti starai chiedendo come facciano progetti tanto difficili a concludersi in un modo o nell'altro, nonostante siano passati per situazioni critiche e disperate. La risposta sta nel teorema della scimmia instancabile. In breve, il teorema afferma che una scimmia che batte a caso i tasti di una macchina da scrivere per un tempo infinito finirà certamente per scrivere un determinato testo, come l'opera completa di William Shakespeare. Non è uno scherzo.

Allo stesso modo, anche senza poter prevedere la data di fine, se il team IT rimanda abbastanza e guadagna tempo per un progetto, prima o poi lo consegnerà di sicuro.

Conflitto cronico tra sviluppo e attività operative

Tra le molte responsabilità chiave dell'organizzazione IT ci sono due grandi missioni:

1. Il team di sviluppo deve rilasciare rapidamente per rispondere alle richieste in evoluzione dei clienti e del mercato in cui opera l'azienda.
2. Il team operativo deve garantire un servizio stabile, prevedibile, sicuro e continuo ai clienti e al mercato.

Con un'organizzazione IT strutturata così, i team di sviluppo e quelli operativi hanno missioni e motivazioni in conflitto. Ciò riduce la produttività, la qualità del servizio, la soddisfazione dei clienti, i risultati dell'IT e infine le prestazioni complessive dell'azienda.

Ora hai accumulato debito tecnico

Interventi continui per fronteggiare le emergenze, soluzioni di ripiego e attività non pianificate per salvare la situazione fanno solo accumulare altro debito tecnico. Ne risentono sia lo sviluppo e le attività operative sia tutte le altre unità, tra cui architettura, sicurezza delle informazioni, test, gestione del prodotto e del rilascio, oltre ai portatori di interesse aziendali.

Puoi paragonare il debito tecnico a quello finanziario. Più debiti finanziari hai, meno opzioni hai per raggiungere i risultati desiderati. Alla fine diventa quasi impossibile prendere decisioni giuste per raggiungerli e aumentano le probabilità di contrarre altri debiti.

Con il debito tecnico succede lo stesso. Più ne hai, meno opzioni hai per creare e rilasciare le soluzioni giuste. Finisci per sovrapporre soluzioni di ripiego ad altre soluzioni di ripiego, castelli di carte su altri castelli di carte. Come sai già, è solo questione di tempo prima che tutto crolli.

La tua azienda ricava entrate dai sistemi più fragili

Un fatto poco sorprendente ma preoccupante è che i sistemi più critici per l'azienda, quelli che generano ricavi, sono anche i più soggetti a errori, guasti e interruzioni.

Questi sistemi sono di solito al centro delle attività aziendali e probabilmente non hai ancora partecipato a una riunione in cui non se ne parli. Sono i più critici e quasi tutti i progetti incidono su di essi. Per la loro importanza meritano interventi continui, modifiche urgenti e correzioni non pianificate. Eppure continuano a generare incidenti di priorità 1.

Se ne rompi uno, fai promesse ancora più grandi

Poiché l'organizzazione IT continua a disattendere le promesse e a frustrare i portatori di interesse, questi diventano più esigenti per recuperare il terreno perso. Tu e i tuoi responsabili spesso non potete che dire «perché no», a meno che non abbiate già in vista un lavoro migliore.

Poi alle organizzazioni di sviluppo e rilascio del software viene assegnata una sfida più impegnativa del solito. Poiché i sistemi critici e l'architettura IT non sono neppure lontanamente in grado di soddisfare i requisiti entro i tempi «urgenti» stabiliti, inizi a progettare nuove soluzioni di ripiego da sovrapporre a quelle esistenti.

Il lavoro non è più piacevole

Alla fine tutti sono un po' più impegnati. Nel calendario non trovi più neanche un'ora senza interruzioni per svolgere il lavoro per cui sei stato assunto e pagato. Le e-mail piovono nella posta in arrivo, quindi usi le parti meno produttive delle riunioni per scorrere e smaltire messaggi perlopiù poco chiari e inutili. Ti chiedi perché l'organizzazione non imponga un corso su come usare e scrivere le e-mail.

Di solito dipendi da altri team per poter proseguire il lavoro. Eppure le aspettative che hai comunicato un paio di settimane fa non sono ancora all'attenzione dell'altro team, perché ha appena iniziato il nuovo progetto «Horizon 2400» mentre doveva risolvere 9 incidenti di priorità 1 causati da applicazioni fragili.

Cominci a perdere la pazienza perché per andare avanti hai bisogno di alcune risposte dall'unica referente designata dell'altro team.

Non hai resistito e hai mandato un'altra e-mail per ricordare la richiesta. Questa volta hai messo in copia la sua responsabile e hai pensato che avresti dovuto farlo fin dalla prima e-mail.

Prima ancora che passino un paio di secondi, sullo schermo compaiono due risposte automatiche di assenza. La referente dell'altro team sarà ai workshop di «Horizon 2400» fino alla fine della settimana. La sua responsabile oggi è a casa malata.

CONCLUSIONE

In questo capitolo abbiamo illustrato le difficoltà della maggior parte delle aziende e dei professionisti IT. Sono spirali negative e circoli viziosi con cui convive quasi ogni azienda e professionista.

Gartner stima che le aziende di tutto il mondo sprechino ogni anno circa 600 miliardi di USD per interventi di manutenzione IT fuori budget e non pianificati, allo scopo di mantenere operativi i sistemi IT che generano ricavi. Per vedere che aspetto ha questa cifra, scriviamola per esteso: 600.000.000.000 USD.

Come avrai intuito, in un lavoro ad alto contenuto intellettuale come l'informatica è difficile capire come si arrivi a tanto spreco.

Vale la pena affrontare la sfida. DevOps ha alcune risposte per certe aziende, forse anche per la tua. Naturalmente, a condizione che sia pronta a sperimentare, imparare e adattarsi.