Cosa sono le metriche DORA: misurare velocità e stabilità

Cosa sono le metriche DORA

Le metriche DORA sono cinque misure della consegna software: tempo di lead (change lead time), frequenza di deployment, tempo di recovery da deployment fallito, tasso di cambio fallito e tasso di deployment non pianificato. Le prime tre descrivono il throughput, le ultime due descrivono l'instabilità. Insieme ti dicono quanto velocemente i cambiamenti raggiungono la produzione e quanto spesso quei cambiamenti causano danni. Usate bene, indicano il collo di bottiglia. Usate male, diventano una pagella che il tuo team impara a manipolare.

Da dove vengono i numeri e perché il vocabolario è rimasto

Un platform lead si ritrova in una review trimestrale. Il CTO pone una domanda sola: stiamo deployando più velocemente dello scorso anno, e stiamo rompendo meno cose? Senza un vocabolario condiviso, la risposta è un mucchio di aneddoti. Le metriche DORA esistono per sostituire gli aneddoti con quattro o cinque numeri che puoi estrarre dai sistemi che già esegui.

Il nome viene da DevOps Research and Assessment, il programma di ricerca che ha passato anni a sondare team di engineering e correlare le loro pratiche di delivery con i risultati organizzativi. Fa ora parte di Google Cloud, e i risultati sono pubblicati ogni anno nel programma di ricerca DORA. Il libro Accelerate ha popolarizzato i quattro metrici originali. Il framework è stato revisionato da allora, e questa revisione ha più importanza di quanto la maggior parte dei blog ammetta.

Ecco la parte che si perde: le metriche non erano mai pensate come una classifica. Sono emerse da un risultato statistico. Team che ottenevano buoni risultati sulla velocità ottenevano anche buoni risultati sulla stabilità. Velocità e sicurezza non erano un compromesso, si muovevano insieme. Questa è un'affermazione sulla correlazione tra molti team, non un obiettivo per il tuo.

I cinque metrici, definiti come li definirebbe un SRE in on-call

Le definizioni attuali sulla guida ufficiale dei metrici DORA si dividono in due gruppi. Leggile con un servizio specifico in mente, perché ogni definizione crolla se la applichi "a tutta l'azienda".

Tempo di lead (change lead time). Il tempo da un commit a quel commit che gira in produzione. Non dal momento in cui il ticket è stato aperto, e non dal momento in cui il pull request è stato approvato. Dal commit alla prod. Se la tua pipeline richiede quaranta minuti e il tuo release train parte il giovedì, il tuo lead time è dominato dal giovedì.

Frequenza di deployment. Con quale frequenza deploys in produzione. Puoi contare i deployment in un periodo o misurare il gap tra loro. Un servizio che deploya undici volte al giorno e un servizio che deploya una volta al mese sono animali diversi, e mediare li nasconde entrambi.

Tempo di recovery da deployment fallito. Quanto tempo ci vuole per recuperare quando un deployment causa un problema che richiede intervento. Questo si chiamava tempo medio per il ripristino, e il cambio di nome è deliberato. Conta solo gli incidenti causati dal tuo cambio, non un outage del provider cloud di martedì.

Tasso di cambio fallito (change fail rate). La quota di deployment che hanno bisogno di intervento immediato dopo: un rollback, un hotfix, un forward fix pushato al volo. Dieci deployment, due di loro reverted, tasso di cambio fallito del venti percento.

Tasso di deployment non pianificato (deployment rework rate). La quota di deployment non pianificati, attivati da un incident in produzione piuttosto che da lavoro di roadmap. Questa è l'aggiunta più recente, e cattura qualcosa che il change fail rate manca: il team che non fa mai rollback ma spende metà della settimana a pushare patch di emergenza.

Throughput versus instabilità: perché non leggi mai un metrico da solo

I primi tre metrici sono throughput. Gli ultimi due sono instabilità. Il raggruppamento è tutto il punto.

Se guardi solo il throughput, celebrerai un team che deploya quaranta volte al giorno e silenziosamente reverte un quarto di loro. Se guardi solo l'instabilità, premierai un team che spedisce una volta al mese con un record immacolato, perché nessuno cambia niente. Ogni singolo metrico ha un modo economico di migliorarlo che peggiora il sistema.

La frequenza di deployment sale quando dividi un deploy in cinque deploy vuoti. Il change fail rate scende quando smetti di contare gli hotfix come fallimenti. Il lead time si riduce quando ridefinisci l'inizio dell'orologio. Questa è la legge di Goodhart che fa quello che fa sempre: quando una misura diventa un obiettivo, smette di essere una buona misura. La guida ufficiale la elenca per prima tra i suoi avvertimenti, ed è quella che morde più duro.

Quindi la regola che funziona è le coppie. Leggi il lead time accanto al change fail rate. Leggi la frequenza di deployment accanto al rework rate. Un movimento in una direzione senza una storia corrispondente nell'altra è un segnale per guardare più da vicino, non una vittoria da annunciare.

I benchmark circolano in ogni deck dei vendor, e sono una trappola. Il modello segnalato dai recenti report DORA è coerente nella forma: il cluster più forte di team deploya on demand, con un lead time inferiore a un giorno, e si recupera da un deployment fallito in meno di un'ora. Il cluster più lento si trova nel range di settimane-mesi su entrambi.

Questi numeri sono utili per una cosa: calibrare la tua intuizione su quello che è possibile. Sono scarsi come obiettivi. Un servizio di pagamenti con un gate di audit obbligatorio non corrisponderà a un sito di marketing, e non dovrebbe nemmeno provare. Le linee guida ufficiali sono esplicite nel dire che dovresti confrontare solo applicazioni o servizi simili, e che dovresti puntare al miglioramento rispetto al tuo baseline piuttosto che alla competizione tra team.

Inizia con la tua mediana. Misurala per un mese prima di impostare qualsiasi obiettivo. Il primo numero è quasi sempre imbarazzante, ed è tutto bene. Un baseline che ti imbarazza è un baseline che davvero ti fidi.

Come instrumentare senza costruire una data platform

La maggior parte dei team sovraconstruisce questo. Non hai bisogno di un progetto warehouse. Hai bisogno di quattro timestamp e un flag.

Gli timestamp: commit merged al ramo principale, build terminata, deployment iniziato in produzione, deployment terminato. Il flag: se il deployment è stato in seguito revertito, hotfixato, o seguito da un deploy non pianificato entro una finestra definita.

Ecco uno sketch minimalista in TypeScript. Accetta una lista di record di deployment e restituisce i numeri che importano.

type Deploy = {
  service: string;
  committedAt: Date;
  deployedAt: Date;
  failed: boolean;       // reverted, hotfixed, or manual intervention
  unplanned: boolean;    // triggered by an incident, not by roadmap work
  recoveredAt?: Date;    // set when failed is true
};

const median = (xs: number[]) => {
  const s = [...xs].sort((a, b) => a - b);
  return s.length ? s[Math.floor(s.length / 2)] : 0;
};

export function doraSummary(deploys: Deploy[], days: number) {
  const leadHours = deploys.map(
    d => (d.deployedAt.getTime() - d.committedAt.getTime()) / 36e5,
  );
  const failures = deploys.filter(d => d.failed);
  const recoveryMins = failures
    .filter(d => d.recoveredAt)
    .map(d => (d.recoveredAt!.getTime() - d.deployedAt.getTime()) / 6e4);

  return {
    leadTimeHoursP50: median(leadHours),
    deploysPerDay: deploys.length / days,
    changeFailRate: failures.length / Math.max(deploys.length, 1),
    recoveryMinutesP50: median(recoveryMins),
    reworkRate: deploys.filter(d => d.unplanned).length / Math.max(deploys.length, 1),
  };
}

Due decisioni in quello snippet portano il peso. Prima, usa la mediana, non la media. Una brutta settimana con un recovery di tre giorni farà a pezzi una media e non ti dirà niente su un martedì tipico. Secondo, calcola tutto per servizio. Aggrega a un team o un dipartimento solo dopo che hai guardato i servizi sottostanti.

La parte difficile non è il codice. La parte difficile è il flag failed. Qualcuno deve decidere cosa conta come un fallimento, scriverlo, e applicarlo nello stesso modo ogni volta. Se il tuo incident tracker collega gli incident al deployment che li ha causati, ottieni questo quasi gratuitamente. Se non lo fa, inizia da lì.

La questione del tooling viene dopo la questione dei dati. Già possiedi la maggior parte dei dati grezzi. Il tuo host Git ha i tempi di commit. Il tuo CI ha gli eventi di build e deploy. Il tuo incident tool ha i fallimenti. Il lavoro è unirli su un identificatore di deployment condiviso.

Le piattaforme di osservabilità sono un posto naturale per sovrapporre marcatori di deployment sopra i tassi di errore e la latenza, quindi puoi vedere quale deploy ha preceduto quale spike.

Se preferisci mantenere lo stack aperto e self-hosted, un layer di dashboard sopra il tuo proprio database di eventi di deployment fa lo stesso lavoro a un costo inferiore, con più plumbing da parte tua.

C'è anche una categoria di tooling che legge i tuoi repository e la storia di delivery e mette in superficie il rischio, come hotspot dove il code churn e i difetti passati si raggruppano. Non sostituirà i quattro timestamp, ma spiega perché un servizio ha un alto change fail rate quando i suoi vicini no.

Un'avvertenza su comprare qualsiasi cosa qui. Un dashboard che mostra i numeri non è la stessa cosa di un team che agisce su di loro. Se nessuno possiede il grafico del tempo di recovery, comprare un grafico più bello non cambia nulla.

Le leve che davvero muovono ogni numero

I metrici sono una diagnosi. Il trattamento è altrove, ed è diverso per ciascuno.

Per il lead time, guarda l'attesa, non il lavoro. Prendi una dozzina di cambiamenti recenti e marca dove ognuno stava inattivo: aspettando review, aspettando uno slot di build, aspettando una finestra di release. Nella maggior parte dei team il tempo di inattività supera il tempo di codifica parecchie volte. Pull request più piccoli e un'aspettativa di livello di servizio di review battono qualsiasi tuning della pipeline.

Per la frequenza di deployment, la leva è la dimensione del batch. Cambiamenti più piccoli sono più facili da revisionare, più facili da ragionare, e più facili da revertire. Lo sviluppo basato su trunk e i feature flag esistono per permetterti di mergare il lavoro non finito in sicurezza, il che è come decuplai lo shipping dal releasing.

Per il change fail rate, la leva è quanto del blast radius riesci a vedere prima che sia l'intera flotta. Un rollout che espone l'uno percento del traffico, guarda un tasso di errore contro un SLO, e si ferma su un breach trasforma un deployment fallito che sarebbe stato un incident in un non-evento. Questo è il gap tra un deployment fallito e un cambio fallito che nessuno al di fuori del team ha notato.

Per il tempo di recovery, la leva è il revert. Se la fix più veloce è il rollback, allora il tempo di recovery è quanto velocemente rilevi il problema più quanto velocemente puoi premere il pulsante. Automatizzare il revert su un threshold breach taglia fuori l'umano dai primi dieci minuti. A alle 3 di mattina questo importa più di qualsiasi runbook.

Per il rework rate, la leva è upstream. Un numero alto significa che gli incident stanno generando deployment. Guarda quali servizi producono le patch di emergenza, e leggi i loro post-mortem come un insieme piuttosto che uno alla volta.

Cosa cambia quando l'IA scrive più del tuo codice

La ricerca DORA recente indica qualcosa di scomodo per chiunque venda un assistente di codifica. Gli assistenti accelerano i task di basso livello, eppure i guadagni non sono chiaramente portati al lead time o al change fail rate. Più codice scritto per ora non è la stessa cosa di più valore consegnato per settimana.

Se altro, un volume più grande di cambiamenti generati spinge la pressione sulla review e sulla tua delivery pipeline. Batch più grandi nuocono alla stabilità, e la capacità di review non scala con la velocità di digitazione. Guarda il tuo change fail rate e rework rate da vicino nei mesi dopo che un team adotta un assistente. Se il lead time cade ma il rework sale, non sei diventato più veloce, hai spostato il costo.

Come usarli in una retro senza spezzare il tuo team

Ecco cosa funziona in pratica. Metti i trend line sullo schermo per l'ultimo trimestre e fai una domanda: cosa è cambiato qui, e perché? Non chiedere chi. L'obiettivo è un'ipotesi sul sistema, non un verdetto su una persona.

Tre abitudini mantengono i numeri onesti.

Prima, non metterli mai nelle review di performance individuale. Nel momento in cui una metrica si attacca a un nome, la gente ottimizza la metrica, e i tuoi dati smettono di descrivere la realtà.

Secondo, abbina ogni numero con una storia. Un spike nel tempo di recovery è un incident con un nome e un post-mortem. Leggi il post-mortem prima di leggere il grafico.

Terzo, cambia una cosa alla volta. Se adotti feature flag, riduci i pull request, e automatizzi i rollback nello stesso mese, non imparerai mai quale ha mosso l'ago.

Salta la slide del modello di maturità che sorta la tua org in tier e distribuisce un premio. Vale la pena invece: una singola pagina per servizio, aggiornata mensilmente, elencando i cinque numeri, il valore del mese precedente, e una frase su cosa è cambiato.

Supponiamo che hai novanta giorni di dati puliti su un servizio, e hai visto il change fail rate salire silenziosamente mentre la frequenza di deployment è rimasta piatta. Dove guarderesti prima: la dimensione dei cambiamenti, la qualità della review, o la visibilità che hai in un rollout mentre è ancora piccolo? La tua risposta dice più sul tuo sistema di delivery che qualsiasi benchmark.