Close

Metriche DevOps

Perché, cosa e come misurare il successo in DevOps

TOM HALL

Advocate e professionisti DevOps


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.

What are DevOps metrics?


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


Though there are numerous metrics used to measure DevOps performance, the following are four key metrics every DevOps team should measure.

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.

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.

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.

Mean time to recovery

Mean time to recovery (MTTR) measures how long it takes to recover from a partial service interruption or total failure. This is an important metric to track, regardless of whether the interruption is the result of a recent deployment or an isolated system failure.

Scopri la soluzione

Strumenti per un team DevOps eccellente

materiale correlato

L'importanza della struttura del team in DevOps

How to measure, use, and improve DevOps metrics


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.

Other related metrics


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 conclusion…


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à. Scopri di più su come Atlassian ti aiuta a offrire ai clienti valore in modo più rapido ed efficiente con Code in Jira e Deployments in Jira (Distribuzioni in Jira).

Tom Hall
Tom Hall

Tom Hall è DevOps Advocate e Practitioner, lettore vorace e pianista dilettante.
Tra i traguardi degli ultimi 20 anni vanta certificazioni Novell, EMC, VMware e AWS. Dal 2016 aiuta a organizzare i DevOpsDays ad Atlanta e ad Austin, Texas.


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.

Illustrazione su Devops

Community DevOps

Illustrazione su Devops

Workshop di simulazione

Illustrazione di una mappa

Inizia gratis

Iscriviti alla nostra newsletter DevOps

Thank you for signing up