Tech
DevOps spiegato a chi firma, non a chi programma
DevOps non è una persona né un prodotto: è il modo in cui il software arriva in produzione. Si giudica con quattro numeri — ogni quanto rilasciate, quanto passa da idea a produzione, quanti rilasci creano guasti, quanto ci mettete a rimettere in piedi. Rilasciare spesso e in piccolo riduce il rischio invece di aumentarlo.
"DevOps" è una di quelle parole che nei preventivi compaiono senza spiegazione, e che alla domanda "ma in pratica cosa comprate?" ricevono una risposta piena di nomi di strumenti. Proviamo a dirlo senza gergo.
DevOps non è un ruolo da assumere e non è un prodotto da comprare. È il modo in cui una modifica al software passa dal computer di chi la scrive alle mani di chi la usa: quanto ci mette, quante volte va storto, e cosa succede quando va storto.
Perché dovrebbe interessarvi
Perché è la differenza fra due aziende che hanno lo stesso software e vivono due vite diverse.
Nella prima, una correzione richiesta lunedì arriva ai clienti dopo tre settimane, il rilascio si fa di venerdì sera perché "se si rompe abbiamo il weekend", e ogni aggiornamento è una notte in bianco. Nella seconda, la stessa correzione è in produzione mercoledì mattina, il rilascio si fa alle undici di martedì e se qualcosa non va si torna indietro in cinque minuti.
La differenza non è la bravura di chi programma. È tutto quello che c'è intorno al programmare.
I quattro numeri che dicono come state
Su questo esiste una ricerca ampia e consolidata nel settore, e la buona notizia è che si riduce a quattro domande che potete fare al vostro fornitore anche senza sapere una riga di codice.
- Ogni quanto rilasciate? Una volta al trimestre o più volte a settimana? Le squadre che rilasciano spesso rilasciano poco per volta, e poco per volta significa poco da controllare quando qualcosa non torna.
- Quanto passa da "lo facciamo" a "è in produzione"? È la misura della vostra velocità di reazione al mercato, non della vostra velocità di scrittura.
- Quanti rilasci creano un guasto? Un numero onesto sta sotto il quindici per cento. Se nessuno lo sa, è già una risposta.
- Quanto ci mettete a rimettere in piedi? È il numero più importante di tutti: non conta quante volte cade, conta quanto resta a terra.
Notate cosa non c'è in questa lista: quanti server, quale piattaforma, quali strumenti. Sono mezzi. Questi quattro sono i fini.
Rilasciare spesso non è spericolato: è l'unico modo per rilasciare in piccolo. E in piccolo, quando si rompe qualcosa, si sa subito cosa.Il ribaltamento che spiazza chi decide
Il paradosso: rilasciare spesso riduce il rischio
L'istinto dice il contrario: se ogni rilascio è pericoloso, meglio farne pochi. Ma è proprio l'inverso, e la ragione è semplice.
Un rilascio trimestrale contiene tre mesi di modifiche. Quando qualcosa si rompe — e si romperà — dovete cercare la causa in mezzo a centinaia di cambiamenti fatti da persone diverse, alcune delle quali sono in ferie. Un rilascio settimanale contiene una settimana di lavoro: se si rompe, il sospettato è uno solo.
In più, i rilasci rari diventano eventi: si accumula tensione, si aggiunge "già che ci siamo" un'altra modifica, e la cosa che doveva ridurre il rischio lo moltiplica.
Cosa c'è dietro, in concreto
Quando dietro c'è il lavoro giusto, quei quattro numeri migliorano da soli. Ecco cosa lo rende possibile, detto in italiano.
- Ambienti che si rifanno uguali. Il server nasce da un file scritto e versionato, non da una sessione al terminale andata bene. Se sparisce stanotte, domani ne esiste uno identico.
- Controlli automatici prima del rilascio. Una batteria di prove che gira a ogni modifica e blocca la strada se qualcosa non torna. È il collega instancabile che ricontrolla sempre le stesse cose.
- Un modo per tornare indietro. Pensato prima, non durante l'emergenza. Sapere che si torna indietro in cinque minuti cambia il modo in cui si decide.
- Misure e allarmi. Accorgersi che qualcosa non va prima che ve lo dica un cliente. Un allarme che suona sempre, però, è un allarme spento.
- Copie di sicurezza provate davvero. Un backup mai ripristinato non è un backup: è un file di cui vi fidate.
Le domande da fare a un fornitore
Cinque domande, e si capisce molto dalle facce prima ancora che dalle risposte.
- Se stanotte il server sparisce, quanto ci mettete a rifarlo? E l'avete mai provato?
- Come tornate indietro se un rilascio va male? Chi lo decide e in quanto tempo?
- Quando è stato ripristinato l'ultimo backup, e chi ha verificato che i dati fossero completi?
- Chi vi avvisa quando il sistema è lento, voi o i nostri clienti?
- Se la persona che ha costruito questa parte domani non c'è, chi altro sa metterci mano?
Nessuna richiede competenza tecnica per essere fatta, e tutte richiedono una pratica reale per avere una risposta.
Quanto vi serve, davvero
Un'azienda con un gestionale e un sito non ha bisogno dello stesso impianto di una piattaforma con migliaia di utenti. Ma le fondamenta sono le stesse, e su qualsiasi scala costano poco: ambiente ricostruibile, prove automatiche, ritorno indietro possibile, backup verificati, allarmi sulle cose che contano.
Il resto — orchestrazioni complesse, ambienti che si moltiplicano da soli — arriva quando i numeri lo giustificano. Comprare quella complessità prima del tempo è il modo più comune di spendere molto per peggiorare i quattro indicatori invece di migliorarli.
Se non conoscete i vostri quattro numeri, non serve un progetto per scoprirli: bastano le domande della lista qui sopra, fatte a chi vi tiene in piedi i sistemi. Le risposte dicono già dove intervenire.