Negli ultimi anni il termine DevOps è diventata una buzzword per molti professionisti del mondo IT. Sono proliferati articoli specialistici e contributi che approfondiscono l’argomento, ne spiegano la filosofia, gli aspetti tecnici e le implementazioni pratiche. Questo testo non ha quindi l’obiettivo di spiegare cosa sia DevOps, né il suo impatto sul modo di lavorare delle aziende: per chi volesse approfondire tutto ciò è già presente una articolata bibliografia. Qui mi interessa prendere in considerazione alcune pratiche ampiamente diffuse per implementare DevOps e come queste vengono adottate nella pratica quotidiana, soffermandomi in particolare sull’approccio al cambiamento, sui processi gestionali e sui processi tecnici. In tutto questo il ruolo del consulente è fondamentale.

 

Sulla filosofia e sulla pratica…

La filosofia DevOps è particolarmente adatta a realtà di lavoro moderne, all’avanguardia, caratterizzate da agilità e flessibilità. In contesti meno aggiornati, più complessi e ancora molto legati a modalità di lavoro standardizzate e burocratizzate può creare una rottura importante con gli schemi presenti e, all’inizio, può fare emergere problematiche da gestire con sensibilità ed attenzione.

Ogni novità rappresenta una incognita che va gestita con oculatezza al fine di fare comprendere come i benefici che derivano siano patrimonio di tutta l’azienda.  L’automazione delle procedure e dei processi non è il preludio ad una riduzione del personale, ma è l’opportunità per una riqualificazione delle persone, che passano dall’eseguire operazioni ripetitive al gestire e programmare automatismi. Questo comporta un notevole miglioramento della qualità del lavoro. È compito del consulente spiegare in cosa consiste questo cambiamento ed accompagnare l’azienda ed i lavoratori nella transizione dalle vecchie alle nuove modalità lavorative.
Altro aspetto da considerare è il facile entusiasmo che rischia di inficiare il corretto adeguamento alla nuova filosofia di lavoro. Se ci si fa trascinare eccessivamente dalla voglia di cambiare le cose e si apportano troppi cambiamenti contemporaneamente, senza lasciare che diventano prassi consolidate, si rischia di esagerare e di non riuscire a sfruttare al meglio le potenzialità del nuovo modo di lavorare, compromettendone l’efficacia e l’efficienza. Qualsiasi innovazione richiede tempo per far sì che le persone possano prendere confidenza e consapevolezza dei nuovi strumenti, al fine di poter essere in grado di usufruire di ogni vantaggio e possibilità.

Sui processi gestionali

Una delle caratteristiche innovative più apprezzate di DevOps è a la sua flessibilità e la capacità di velocizzare i processi di gestione delle attività. Ciò si coniuga con difficoltà con le strutture di molti grandi aziende, spesso rigide, molto verticalizzate e disciplinate da una burocrazia codificata. Molto spesso sono presenti prassi stringenti che prevedono il coinvolgimento di molteplici attori, tutti necessari ai fini dell’approvazione finale di una attività o un progetto. In alcuni casi per una semplice modifica in itinere possono essere coinvolti anche 5 o 6 uffici, ciascuno nodo imprescindibile per l’autorizzazione finale. Questi processi, molto complicati e talvolta eccessivamente strutturati, hanno nelle intenzioni di chi li costruisce l’obiettivo di garantire sicurezza e diffondere consapevolezza e responsabilità a tutti i soggetti coinvolti. Tuttavia sono alla base di rallentamenti, ritardi e malfunzionamenti. Queste pratiche sono radicate nel tempo e la loro ristrutturazione è estremamente articolata, richiede energie, tempi e sensibilità. È proprio questa la sfida complessa della conversione a DevOps di aziende fortemente strutturate. Se vogliamo usare la metafora della Formula 1: le pratiche DevOps sono le auto, le persone i piloti e la struttura aziendale il tracciato. È semplice spostare la macchina da un tracciato all’altro ed è relativamente facile cambiare auto; al pilota serve allenamento e impegno ma è il suo lavoro e il cambio può anche portare benefici. È però estremamente importante che il manto stradale sia adeguato alla corsa per garantire sicurezza e guidabilità, non ci devono essere ostacoli o impedimenti. Ridefinire i processi aziendali è come rifare il manto stradale di un circuito. Non si può pretendere di comprare un pezzo di tracciato, lo si deve costruire dalle basi, con un lavoro preciso, di continua correzione e accomodamento. Ci vogliono persone qualificate, tempo, impegno e un metodo di lavoro che preveda regole nuove e approcci nuovi. È però un’attività che se portata a termine con sapienza e consapevolezza può portare l’azienda a standard produttivi e di qualità molto alti.Sui processi tecnici

I processi di continuous integration e continuous delivery sono particolarmente apprezzati a causa dei vantaggi in termini di comodità dovuti all’automatizzazione e alla velocizzazione di alcuni processi ed ai benefici tecnici che questo modo di lavorare comporta. Le problematiche che si riscontrano riguardano la questione, non banale, dell’ownership dei processi (quindi delle responsabilità ad essa connessa), della gestione degli errori e delle evolutive che sono necessarie a tenere in funzione, in maniera efficiente, le macchine DevOps. Anche a fronte di una riorganizzazione dei processi, le aziende restano strutturate a silos con uffici Dev e Ops chiaramente divisi dal punto di vista formale ma che ora lavorano congiuntamente sul medesimo processo, spalmando interventi e responsabilità in maniera diffusa, sopprimendo alcuni procedimenti e introducendone nuovi. Non c’è quindi un adattamento della struttura organizzativa in linea con la nuova operatività lavorativa. Il risultato è che si genera confusione su chi fa che cosa e, soprattutto, su chi deve agire in caso di problemi.

Il processo di continuous deployment (ovvero il rilascio in produzione ad ogni versionamento del codice), richiede un processo di QA (quality assurance) estremamente elevato e ambienti di produzione che permettano tecniche di rolling deployment all’avanguardia come canary o blue-green. L’investimento necessario per avere questo tipo di infrastruttura e processo è estremamente costoso, almeno in prima battuta, e risulta motivato in caso di necessità di rilasci in produzione in tempi estremamente rapidi. Una banca e molte altre realtà Enterprise, in genere non effettuano un numero di rilasci con una frequenza tale da motivarlo, inoltre la delicatezza di alcuni processi richiede controlli umani che difficilmente possono essere rimpiazzati da automatismi. È proprio il costo elevato di questo processo che spesso ne limita l’adozione, facendo preferire l’investimento di risorse in altre attività.

Sul continuous testing c’ è una convergenza comune sulla validità e l’importanza del principio. Tuttavia, dal lato pratico, spesso ci si trova di fronte alla necessità di optare per soluzioni che contengono tempi e costi ma comprimono il numero dei test a discapito della qualità finale del processo. Non è così raro che i vincoli dettati dalle tempistiche e dai budget obblighino a scelte di compromesso come queste.

(non) tiriamo le fila?

Molto spesso nei contesti organizzativi ed aziendali ci si trova di fronte alla fantomatica “coperta corta”: scarsità di risorse a fronte di una mole imponente di attività da portare a termine. L’unico modo per risolvere la problematica è, quindi, quello di scendere a compromessi. Spesso ci si confronta con un codice non adeguato, processi consolidati ma obsoleti e una burocrazia stringente che, con gli strumenti attuali, potrebbe essere ragionevolmente alleggerita. Se inoltre i dati e le procedure trattati sono così sensibili da richiedere alti livelli di sicurezza, si comprende bene come la coperta non sia corta, bensì cortissima e il ruolo del consulente diventa di fondamentale importanza.

Per chi scrive, i vantaggi del passaggio alla filosofia DevOps sono evidenti: condivisione, automazione e chiarezza in primis. È però indiscutibile che molte realtà non abbiano ancora i prerequisiti per il passaggio a questo modus operandi. C’è bisogno innanzitutto di formazione e conoscenza cui debbono fare seguito investimenti (tecnologici ed umani). DevOps non ha un manifesto, non ha linee guida rigide, è un modo di interpretare il lavoro e l’operatività che riunisce una serie di pratiche e principi che possono migliorare i risultati di chi vi aderisce. Non esiste però un solo modo di fare DevOps, ogni azienda deve trovare le modalità più adatte per l’applicazione di questi principi al proprio contesto. È questo il ruolo del consulente: aiutare a cucire l’abito più adatto al cliente utilizzando la stoffa DevOps.