Che cosa sono le metriche DORA?

Sviluppate dal team DevOps Research and Assessment (DORA) di Google, le metriche DORA forniscono benchmark standard del settore per la consegna del software e la maturità DevOps.

Alla base, le metriche DORA si concentrano su due dimensioni:

1. Velocità effettiva: quanto velocemente i team DevOps possono distribuire software.
   
   
2. Stabilità: come i team DevOps possono distribuire software in modo affidabile e sicuro.

Le metriche orientate alla produttività rivelano quanto velocemente le modifiche al codice si spostano nel ciclo di vita dello sviluppo software (dall'ideazione alla produzione), mentre le metriche orientate alla stabilità mostrano con quale frequenza le distribuzioni si rompono e quanto velocemente i team si riprendono. Insieme, forniscono ai leader aziendali e ai team DevOps insight riproducibili e basati su prove sulle prestazioni DevOps. Le aziende non devono fare affidamento su misure soggettive delle prestazioni o indicatori di vanità come "righe di codice scritte" o "ore lavorate".

Il monitoraggio delle metriche DORA consente ai team DevOps di vedere come si posizionano rispetto ai livelli di prestazioni riconosciuti dai settori (bassi, medi, alti ed élite) e se sono allineati agli obiettivi aziendali. Aiuta le aziende a identificare oggettivamente i colli di bottiglia nelle pipeline di integrazione continua/consegna continua (CI/CD), nei test software e nella gestione degli incidenti.   

Le metriche DORA facilitano inoltre la comunicazione da parte della dirigenza dello stato di salute dei reparti di ingegneria agli stakeholder aziendali e giustificano gli investimenti in strumenti avanzati di automazione, observability e progettazione dell'affidabilità del sito (SRE) che contribuiscono a ottimizzare le pratiche DevOps.

In DevOps, DORA si riferisce al team di ricerca e valutazione DevOps che ha reso popolari le metriche di prestazioni per i team di sviluppo software.

DORA, ora parte di Google Cloud, è nata come un progetto di ricerca indipendente che studiava come i processi di consegna del software influenzino i risultati aziendali. Il team di DORA era interessato a rispondere a una domanda chiave: cosa rende i team software ad alte prestazioni diversi da quelli a basse prestazioni?

Hanno raccolto dati di sondaggi e telemetria da migliaia di team e hanno scoperto che un piccolo insieme di metriche relative alla consegna e alle operazioni era fortemente predittivo delle prestazioni complessive. Nello specifico, tali metriche sono la frequenza di distribuzione, il tempo di preavviso per le modifiche, il tasso di fallimento delle modifiche e il tempo di ripristino in caso di distribuzione non riuscita. I risultati hanno anche dimostrato che velocità di rilascio e stabilità del software possono andare di pari passo, così i team non devono dare priorità a uno rispetto all'altro.

Col tempo, i quattro indicatori sono diventati le metriche standard DORA, che hanno fornito benchmark standard di settore per le prestazioni di erogazione del software. Nel 2024, il team di ricerca di DORA ha aggiunto una quinta metrica al framework, il tasso di rielaborazione della distribuzione.  

Le cinque metriche DORA possono essere raggruppate in due categorie principali: "velocità effettiva" e "stabilità".

Le metriche di velocità effettiva includono la frequenza di distribuzione, il tempo di preavviso per le modifiche e il tempo di ripristino in caso di distribuzione non riuscita, che insieme descrivono quante modifiche un'applicazione può gestire e con quale rapidità le modifiche vengono implementate in produzione.

Le metriche di stabilità includono l tasso di fallimento delle modifiche e il tasso di rielaborazione della distribuzione, che misurano la proporzione di distribuzioni che causano guasti e la quota di distribuzioni non pianificate o causate da incidenti di produzione.

La frequenza di distribuzione misura con quale frequenza un team implementa con successo il codice in produzione per un periodo di tempo (per giorno, per settimana, per mese).

La frequenza di distribuzione è uno dei segnali più visibili di quanto un team software sia agile e sicuro nel proprio processo di consegna. Quando un team distribuisce codice in produzione molte volte al giorno, di solito significa che i processi automatizzati di build, test e distribuzione stanno funzionando senza intoppi e che sono in atto meccanismi di osservabilità solidi. Queste condizioni consentono ai team di sviluppo di rilasciare software senza timore di rompere il sistema.

Al contrario, i team che implementano solo una volta al mese (o anche meno frequentemente) spesso si affidano a rami di codice di lunga durata, test manuali, protocolli di approvazione complessi e grandi giorni di rilascio. Tutti questi fattori rallentano il ciclo di feedback degli utenti e aumentano il costo della correzione dei difetti.

In particolare, un'elevata frequenza di distribuzione non è un segno di salute se si tratta di interruzioni o rollback frequenti. I team ad alte prestazioni combinano un'elevata frequenza di distribuzione con pratiche solide di assicurazione della qualità (test automatizzati multilivello, distribuzioni sfalsate, caratteristiche e pratiche di monitoraggio in tempo reale) che aiutano i team a eseguire spesso minimizzando i rischi per gli utenti.

Dal punto di vista della leadership, monitorare la frequenza di distribuzione nel tempo può rivelare colli di bottiglia nella pipeline di consegna del software. Ad esempio, un calo nella frequenza di distribuzione dopo l'introduzione di un nuovo comitato di approvazione potrebbe indicare che il processo è troppo pesante. Al contrario, un aumento costante della frequenza di distribuzione, abbinato a un miglioramento delle metriche di affidabilità, è un forte indicatore che gli investimenti nelle pipeline CI/CD e nelle pratiche DevOps stanno dando i loro frutti.

Il lead time per le modifiche (chiamato anche lead time delle modifiche) misura il tempo necessario affinché una modifica del codice raggiunga la distribuzione e venga eseguita con successo nella produzione live dopo che la modifica è stata impegnata nel ramo di codice principale in un sistema di controllo della versione.

Questa finestra end-to-end copre tutto, inclusi il tempo di compilazione, l'esecuzione dei test, la revisione del codice, le approvazioni, le fasi della pipeline e la distribuzione effettiva. Rivela quanto velocemente un sistema può trasformare una decisione in un cambiamento tangibile per gli utenti finali.

Quando i tempi di implementazione sono brevi (meno di un'ora), le organizzazioni possono intervenire agli incidenti quasi in tempo reale. Ad esempio, se un team di sicurezza segnala una vulnerabilità, il team di ingegneria può implementare una correzione, convalidarla tramite controlli automatici e metterla in funzione in un intervallo di tempo molto breve. Questo rapido ciclo di feedback collega direttamente il lavoro di sviluppo ai risultati aziendali, perché i team possono misurare rapidamente l'impatto dei cambiamenti e adattarsi di conseguenza.

Ridurre i tempi di implementazione delle modifiche richiede quasi sempre ai team DevOps di automatizzare e semplificare la pipeline di distribuzione. Questo processo include tipicamente l'investimento in strumenti di integrazione continua (CI) affinché ogni commit venga costruito e testato rapidamente, e la semplificazione dei processi di approvazione affinché le approvazioni siano integrate nei workflow di sviluppo.  

Il tempo di recupero fallito nella distribuzione, chiamato anche tempo medio di recupero (MTTR) o tempo medio per ripristinare il servizio, valuta quanto tempo ci vuole per ripristinare il servizio alla normalità dopo un guasto correlato alla distribuzione.

La correzione del servizio potrebbe richiedere agli sviluppatori di annullare una modifica errata, distribuire un hotfix (una piccola modifica urgente del codice rilasciata fuori dal ciclo di rilascio normale) o comunque mitigare l'impatto del problema affinché gli utenti possano riutilizzare il sistema normalmente.

Quando il tempo di ripristino è breve (pochi minuti), di solito significa che diversi componenti DevOps stanno lavorando bene insieme.

L'observability è forte. I dati di telemetria in tempo reale, metriche, log e tracce, sono completamente aggregati e centralizzati nelle dashboard. Gli incidenti vengono rilevati rapidamente (spesso automaticamente) e senza attendere che gli utenti si lamentino.

L'avviso è regolato in modo appropriato affinché gli ingegneri vengano avvisati tempestivamente ma non sopraffatti dal rumore.

I team DevOps si affidano a runbook (guide tattiche passo dopo passo per svolgere compiti tecnici), playbook (guide strategiche di livello superiore che descrivono come i team dovrebbero rispondere a una situazione) e procedure di rollback documentate. Questi framework eliminano le congetture per determinare cosa fare nel bel mezzo di un'interruzione.

I lunghi tempi di recupero (ore o addirittura giorni) spesso indicano pratiche operative deboli. Il rilevamento potrebbe essere scarso, quindi i fallimenti produttivi persistono finché i clienti non li segnalano. La diagnosi è un processo lento, perché la raccolta dei dati è frammentaria, i messaggi di errore non sono chiari o i team non hanno una comprensione condivisa di come si comporta il sistema in caso di guasto. In questi ambienti, ogni incidente diventa un evento ad alto stress e ad alto rischio invece di un semplice esercizio di risoluzione dei problemi con un protocollo di risoluzione chiaro.

Quando abbinati alle altre metriche DORA, tempi di recupero falliti aiutano a garantire che, anche se le distribuzioni falliscono occasionalmente, il guasto sia contenuto e i tempi di risposta brevi.

Il tasso di errore delle modifiche (CFR) è una metrica di "qualità della consegna" che indica ai team DevOps la frequenza con cui le distribuzioni falliscono negli ambienti di produzione live. Qualsiasi distribuzione di produzione problematica che costringa il team a intervenire immediatamente, invece di attendere il successivo rilascio pianificato per risolvere il problema, è considerata una distribuzione "fallita".

Il monitoraggio del CFR nel tempo aiuta i team a comprendere con quale affidabilità implementano le modifiche e funge da contrappeso alle metriche di produttività (frequenza di distribuzione, tempi di consegna delle modifiche) che privilegiano la velocità.

Il CFR è tipicamente espresso in percentuale e si calcola dividendo il numero di distribuzioni fallite per il numero totale di distribuzioni nello stesso periodo e poi moltiplicando per 100.

Un basso tasso di fallimento delle modifiche indica che un team sta inviando modifiche che generalmente si comportano come previsto in produzione. Quando il CFR è basso e stabile, i team possono aumentare in sicurezza la frequenza di distribuzione e abbreviare i tempi di modifica senza danneggiare l'esperienza dell'utente.

Tuttavia, un elevato tasso di fallimento delle modifiche suggerisce che troppe modifiche stanno destabilizzando il sistema. Le cause possono includere test incompleti o inaffidabili, ambienti di staging e di test diversi da quelli di produzione, distribuzioni troppo estese o monitoraggio e avvisi lenti. Un CFR elevato indica che l'organizzazione dovrebbe dare priorità a modifiche più piccole e incrementali e a pratiche di distribuzione più sicure (come le versioni canary, in cui una nuova app o caratteristiche vengono distribuite a un piccolo gruppo di utenti prima della versione più ampia) in modo che meno modifiche si trasformino in incidenti di produzione.

Il tasso di rielaborazione delle distribuzioni è una metrica di stabilità che misura la frazione di distribuzioni di un team che richiedono rilavorazioni. "Rielaborazione" si riferisce a qualsiasi distribuzione che viene attivata da un bug o da un incidente in produzione e non fa parte dell'addestrare originale pianificato.

Il tasso di rielaborazione delle distribuzioni completa le quattro metriche originali DORA rendendo visibile il lavoro reattivo. Rivela quanto dello sforzo di sviluppo di un team viene speso per ripulire gli errori passati invece di far progredire il prodotto.

Un basso tasso di rielaborazione indica generalmente che i team DevOps individuano la maggior parte dei problemi prima che raggiungano gli utenti finali e dedicano la maggior parte del loro tempo a lavori che creano valore (ottimizzazioni pianificate e rifattori). Un tasso di rielaborazione elevato significa che i team dedicano troppo tempo alle attività antincendio.

I tassi di rielaborazione sono particolarmente preziosi se combinati con altre metriche chiave. Ad esempio, se un team ha un'alta frequenza di distribuzione e un basso tasso di rielaborazione, ciò segnala che il team sta distribuendo rapidamente nuove iterazioni software senza sacrificare la qualità. Ma se il team mostra un'alta frequenza di distribuzione insieme a un alto tasso di rielaborazione, significa che sta inviando molto codice ma anche sprecando molto tempo a correggerlo.

È importante sottolineare che un tasso di rielaborazione diverso da zero è normale (e spesso salutare). Anche i migliori team di sviluppo possono commettere errori, e le applicazioni software ben realizzate richiederanno comunque miglioramenti e aggiornamenti di caratteristiche nel tempo. L'obiettivo non è raggiungere lo 0% di rielaborazione, ma limitare le rielaborazioni a una piccola e prevedibile percentuale di tutte le distribuzioni.

Per ogni metrica DORA, i team sono classificati in uno dei quattro livelli di prestazioni, élite, alto, medio o basso, e ogni livello si basa su soglie stabilite per le metriche. Le soglie sono:

Poiché il tasso di rielaborazione della distribuzione è una metrica più recente, non ha ancora stabilito soglie o livelli di prestazioni. Tuttavia, molte aziende e team DevOps tengono traccia delle proprie linee di base di rielaborazione e mirano a una tendenza al ribasso nel tempo. L'utilizzo dei dati sul tasso di rielaborazione insieme al tasso di fallimento delle modifiche e ad altre metriche di affidabilità aiuta i team a migliorare i tassi di rielaborazione delle distribuzioni senza correggere troppo basandosi su un singolo numero. 

Le metriche DORA supportano l'approccio DevOps più ampio allo sviluppo software, che dà priorità alla collaborazione continua tra team multidisciplinari attraverso le funzioni di sviluppo app e operazioni. Gli ambienti DevOps possono avere successo solo nella misura in cui lo sono i team che li compongono.

Le metriche DORA consentono alle aziende di quantificare le prestazioni dei team in base a criteri strettamente allineati ai flussi di valore e ai risultati aziendali più ampi. Ad esempio, le prestazioni alte ed d'élite hanno maggiori probabilità di raggiungere obiettivi di redditività, time-to-market e soddisfazione del cliente.

Le culture DevOps sono anche caratterizzate da un impegno verso una comunicazione fluida e una responsabilità condivisa tra gli stakeholder della consegna del software, tutti i quali lavorano insieme per costruire software di alta qualità e accelerare l'innovazione dei prodotti. Pertanto, molte organizzazioni utilizzano metriche DORA per creare un ciclo di feedback di miglioramento continuo. Le metriche misurano la performance di ogni squadra. I team possono discutere le opportunità di miglioramento sulla base delle misurazioni, sperimentare nuovi approcci e rimisurare le prestazioni per verificare quali modifiche migliorano effettivamente le pratiche di distribuzione.

È importante sottolineare che le metriche DORA sono diagnostiche, non punitive. Aiutano a rivelare modelli sistemici nei processi di sviluppo, invece di concentrarsi sul lavoro dei singoli sviluppatori.