Articoli
Tutorial
Guide interattive
Metriche DevOps
Perché, cosa e come misurare il successo in DevOps
TOM HALL
DevOps Advocate & Practitioner
Il vecchio adagio secondo cui non è possibile migliorare ciò che non si misura è vero per DevOps come per qualsiasi altra pratica. Per tenere fede alla promessa di DevOps, ovvero il rilascio più rapido di prodotti di qualità superiore, i team devono raccogliere, analizzare e misurare numerose metriche, che forniscono i dati essenziali di cui i team DevOps hanno bisogno per avere la visibilità e il controllo sulla pipeline di sviluppo.
Cosa sono le metriche DevOps?
Le metriche DevOps sono punti dati che rivelano direttamente le prestazioni di una pipeline di sviluppo software DevOps e aiutano a identificare e rimuovere rapidamente eventuali colli di bottiglia nel processo. Queste metriche possono essere utilizzate per tenere traccia sia delle capacità tecniche che dei processi dei team.
Fondamentale, DevOps rende più sfumato il confine tra team di sviluppo e operativi, consentendo una maggiore collaborazione tra sviluppatori e amministratori di sistema. Le metriche consentono ai team DevOps di misurare e valutare i flussi di lavoro collaborativi e di monitorare i progressi nel raggiungimento di obiettivi di alto livello, tra cui maggiore qualità, cicli di rilascio più rapidi e migliori prestazioni delle applicazioni.
Quattro metriche DevOps critiche
Sebbene esistano numerose metriche utilizzate per misurare le prestazioni DevOps, di seguito sono riportate quattro metriche chiave che ogni team DevOps dovrebbe misurare.
1. Lead time per le modifiche
Una delle metriche DevOps critiche da monitorare è il lead time per le modifiche. Da non confondere con la durata ciclo (esaminata di seguito), il lead time per le modifiche è il periodo di tempo che intercorre tra il commit di una modifica del codice nel branch del trunk e il momento in cui si trova in uno stato utilizzabile, ad esempio, quando il codice supera tutti i necessari test preliminari al rilascio.
2. Tasso di errore delle modifiche
Il tasso di errore delle modifiche è la percentuale di modifiche al codice che richiedono correzioni rapide o altre correzioni dopo la produzione. Non misura gli errori rilevati dai test e corretti prima della distribuzione del codice.
3. Frequenza di distribuzione
Comprendere la frequenza con cui il nuovo codice viene distribuito in produzione è fondamentale per capire i risultati di DevOps. Molti professionisti utilizzano il termine "consegna" per indicare le modifiche al codice rilasciate in un ambiente di staging di pre-produzione e riservano il termine "distribuzione" alle modifiche del codice rilasciate in produzione.
4. Tempo medio di ripristino
Il tempo medio di ripristino (MTTR) misura il tempo necessario per il ripristino da un'interruzione parziale del servizio o da un'interruzione totale. Si tratta di una metrica importante da monitorare, indipendentemente dal fatto che l'interruzione sia il risultato di una distribuzione recente o di un errore di sistema isolato.
Scopri la soluzione
Strumenti per un team DevOps eccellente
materiale correlato
L'importanza della struttura del team in DevOps
Come misurare, utilizzare e migliorare le metriche DevOps
Analogamente ad altri elementi del ciclo di vita DevOps, alle metriche DevOps si applica una cultura del miglioramento continuo. La possibilità di ricevere feedback rapidi in ogni fase dello sviluppo, unita alla competenza e all'autorità necessarie per implementare il feedback, sono i tratti distintivi dei team ad alte prestazioni. Nel libro DevOps "Accelerate", gli autori osservano che le quattro metriche chiave elencate sopra sono supportate da 24 funzionalità adottate dai team software ad alte prestazioni. La maggior parte di queste funzionalità (CI/CD, automazione dei test, lavoro in piccoli batch, monitoraggio e apprendimento continuo) verrà trattata di seguito, ma vale la pena leggere "Accelerate" per approfondire la ricerca che supporta queste pratiche.
Lead time per le modifiche
I team ad alte prestazioni in genere misurano i lead time in ore, rispetto ai team con prestazioni medie e basse che misurano i lead time in giorni, settimane o addirittura mesi.
L'automazione dei test, lo sviluppo basato su trunk e il lavoro in piccoli batch sono elementi chiave per migliorare il lead time. Queste pratiche consentono agli sviluppatori di ricevere rapidamente feedback sulla qualità del codice di cui eseguono il commit, in modo da poter identificare e correggere eventuali difetti. I lead time lunghi sono quasi garantiti se gli sviluppatori lavorano su grandi cambiamenti esistenti in branch separati e si affidano a test manuali per il controllo della qualità.
Tasso di errore delle modifiche
I team ad alte prestazioni hanno tassi di errore delle modifiche inclusi in un intervallo tra lo 0% e il 15%.
Le stesse pratiche che abilitano lead time più brevi (automazione dei test, sviluppo basato su trunk e lavoro in piccoli batch) sono correlate a una riduzione dei tassi di errore delle modifiche. Tutte queste pratiche semplificano notevolmente l'identificazione e la correzione dei difetti.
Il monitoraggio e il reporting dei tassi di errore delle modifiche non sono importanti solo per identificare e correggere i bug, ma anche per garantire che i nuovi rilasci di codice soddisfino i requisiti di sicurezza.
Frequenza di distribuzione
I team ad alte prestazioni possono distribuire le modifiche su richiesta e spesso lo fanno più volte al giorno. I team con prestazioni inferiori sono spesso limitati a una distribuzione settimanale o mensile.
La possibilità di effettuare la distribuzione su richiesta comporta una pipeline di distribuzione automatizzata che integri i meccanismi di test e feedback automatizzati a cui si fa riferimento nelle sezioni precedenti e riduca al minimo la necessità di intervento umano.
Tempo medio di ripristino
I team ad alte prestazioni effettuano un ripristino rapido dagli errori di sistema, di solito in meno di un'ora, mentre i team con prestazioni inferiori possono impiegare fino a una settimana.
La capacità di eseguire rapidamente il ripristino da un errore dipende dalla capacità di identificare rapidamente il verificarsi di errore e di distribuire una correzione o di eseguire il rollback delle eventuali modifiche che hanno determinato l'errore. Ciò avviene in genere monitorando continuamente lo stato di integrità del sistema e avvisando il personale operativo in caso di errore. Il personale operativo deve disporre dei processi, degli strumenti e delle autorizzazioni necessari per risolvere gli imprevisti.
L'attenzione rivolta all'MTTR rappresenta un allontanamento dalla pratica storica di focalizzarsi sul tempo medio tra errori (MTBF). Riflette la maggiore complessità delle applicazioni moderne e quindi una maggiore aspettativa di errore. Rafforza inoltre la pratica dell'apprendimento e del miglioramento continui. Invece di aspettare che la distribuzione sia "perfetta" per evitare qualsiasi errore (e quindi di modificare il vecchio "tabellone segnapunti" MTBF), i team effettuano distribuzioni continue. L'MTTR non si concentra sull'individuazione delle persone o dei fattori "colpevoli" di aver rovinato un record MTBF "perfetto", ma incoraggia l'utilizzo di retrospettive imparziali per aiutare i team a migliorare i processi e gli strumenti a monte.
Altre metriche correlate
Un'altra metrica pertinente è la durata ciclo, ovvero il tempo che un team impiega per lavorare su un elemento fino a quando questo non è pronto per il rilascio. Nel mondo dello sviluppo, la durata ciclo indica il periodo che intercorre dal momento in cui gli sviluppatori effettuano un commit fino a quello in cui viene distribuito in produzione. Questa metrica DevOps chiave aiuta i coordinatori progetto e i responsabili tecnici a comprendere meglio quali siano gli aspetti più efficaci nella pipeline di sviluppo e, di conseguenza, ad allineare meglio il loro lavoro alle aspettative di stakeholder e clienti, garantendo un rilascio più rapida per il loro team.
I report sulla durata ciclo consentono ai lead di progetto di stabilire una linea di base per la pipeline di sviluppo che può essere utilizzata per valutare i processi futuri. Quando i team ottimizzano la durata ciclo, gli sviluppatori in genere hanno meno lavoro in corso e meno flussi di lavoro inefficienti.
Nella gestione dei prodotti Lean, l'attenzione si concentra sulla mappatura del flusso di valore, che è una visualizzazione del flusso dal concetto del prodotto o della funzione fino alla consegna. Le metriche DevOps forniscono molti dei punti dati essenziali per una mappatura e una gestione efficaci del flusso di valore, ma dovrebbero essere migliorate con altre metriche aziendali e di prodotto per un'autentica valutazione end-to-end. Ad esempio, i grafici burn-down degli sprint forniscono informazioni sull'efficacia dei processi di stima e pianificazione, mentre un Net Promoter Score indica se il risultato finale soddisfa le esigenze dei clienti.
In conclusione...
Il miglioramento continuo è un principio fondamentale dei team che praticano DevOps. La capacità di misurare e monitorare le prestazioni durante i lead time per le modifiche, il tasso di errore delle modifiche, la frequenza di distribuzione e l'MTTR consente ai team di accelerare la velocity e aumentare la qualità.
Open DevOps di Atlassian offre tutto ciò di cui hanno bisogno i team per sviluppare e utilizzare il software. I team possono creare la toolchain DevOps che preferiscono grazie alle integrazioni con i fornitori e le app del Marketplace leader del settore. Provalo subito.
Condividi l'articolo
Argomento successivo
Letture consigliate
Aggiungi ai preferiti queste risorse per ricevere informazioni sui tipi di team DevOps e aggiornamenti continui su DevOps in Atlassian.