DevOps è solo automazione?

DevOps è solo automazione?

 09 Sep 2022 -  Giulio Vian -  ~3 minuti

Un grosso equivoco su DevOps è che il suo scopo sia automatizzare. Nulla di più errato. L’automazione è un mezzo per un fine assai diverso. Il fine di DevOps è ottimizzare, massimizzare, il valore fornito agli utenti mediante la catena del lavoro IT.

Per massimizzare il valore dobbiamo ridurre le dimensioni dei nostri rilasci. Rilasci con meno funzionalità ma più frequenti. Rilasci più frequenti sono meno efficienti se pensiamo di gestirli manualmente. Apri un ticket, ottieni l’accesso ai sistemi, blocca il traffico al sistema,installa gli aggiornamenti, controlla che funzioni, riapri il traffico, chiudi il ticket. Per rilasciare più frequentemente il processo di rilascio deve essere quanto più possibile automatizzato.

Non ho ancora spiegato perché rilasci più piccoli massimizzano il valore all’utente. Poniamo di rilasciare tre funzionalità in un trimestre. Ciascuna funzionalità porta un 10% di incremento di fatturato conseguente al corrispondente aumento di utenti paganti attratti dalle nuove funzionalità. È chiaramente una situazione ipotetica ma aiuta a chiarire con maggior facilità. Se consideriamo l’arco temporale del trimestre, abbiamo che per tre mesi non c’è alcun aumento di fatturato fino al giorno del rilascio. Il giorno seguente abbiamo un incremento del 30%. Se rilasciamo una funzionalità al mese guadagneremmo il 10% in più dopo il primo mese e per i due successivi; allo scadere del secondo mese ho un altro 10%. Quindi con il rilascio massivo ho un +30% solo dopo il terzo mese, con rilasci minori ho potuto avere anche un +10% al secondo mese e un +20% al terzo, insomma un +30% con un mese d’anticipo.

Oltre al vantaggio economico diretto, consideriamo i vantaggi indiretti. Il primo, più evidente, è la riduzione del rischio, sia per quanto riguarda l’aspetto tecnico che per quello imprenditoriale. Il rischio tecnico diminuisce perché cambio meno componenti (almeno meno righe di codice), la risoluzione (troubleshooting) è più semplice, il deploy più rapido, la durata del disservizio minore, e via dicendo. Diminuisce il rischio imprenditoriale perché la telemetria ovvero i sondaggi degli utenti mi dicono se la funzionalità stia piacendo e devo correggere il tiro, dopo aver rischiato un mese di sviluppo invece che tre. Potrò quindi cambiare priorità mese per mese, settimana per settimana, giorno per giorno con spreco molto minore rispetto ad un rilascio più grosso con maggiori interdipendenze. Di riflesso si riduce il rischio commerciale, di offrire cioè qualcosa che non interessa ai miei utenti, perché la mia offerta diventa maggiormente dinamica e posso adeguarmi rapidamente alla concorrenza.

L’automazione è dunque strumentale per l’obiettivo di rilasciare meno e più frequentemente. Se servono tre giorni per rilasciare, diventa impossibile rilasciare più volte in un mese. È indispensabile che i miei rilasci scendano sotto le quattro ore complessive.

Tutto questo ragionamento si basa sui principi Lean. Mentre la gestione tradizionale enfatizza l’efficienza, per cui la dimensione del lotto di lavoro è determinata dai costi e ottimizzata a ogni fase di lavorazione, la prospettiva lean, popolarizzata da pubblicazioni come The Goal   , punta a ottimizzare il prodotto finale.

Voi che ne pensate?

comments powered by Disqus