DORA metrics: meet delivery snelheid en stabiliteit

Wat zijn DORA metrics? Ze zijn vijf maten voor software delivery: change lead time, deployment frequency, failed deployment recovery time, change fail rate en deployment rework rate. De eerste drie beschrijven doorvoer, de laatste twee instabiliteit. Samen zeggen ze je hoe snel veranderingen productie bereiken en hoe vaak die veranderingen schade aanrichten. Goed gebruikt, wijzen ze je naar de bottleneck. Slecht gebruikt, worden ze een rapport waarop je team leert gamen.

Waar de getallen vandaan komen, en waarom de woordkeus bleef hangen

Een platform lead zit in een kwartaalreview. De CTO stelt één vraag: zenden we sneller dan vorig jaar, en breken we minder? Zonder gedeelde woordkeus is het antwoord een verzameling anekdotes. DORA metrics bestaan om die anekdotes te vervangen door vier of vijf getallen die je uit systemen haalt die je al draait.

De naam komt van DevOps Research and Assessment, het onderzoeksprogramma dat jaren besteedde aan het bevragen van engineeringteams en hun bezorgpraktijken aan organisatorische resultaten koppelde. Het maakt nu deel uit van Google Cloud, en de bevindingen worden jaarlijks gepubliceerd in het DORA-onderzoeksprogramma. Het boek Accelerate populariseerde de oorspronkelijke vier. Het framework is sindsdien herzien, en die herziening telt meer dan wat de meeste blogs erkennen.

Hier is wat verloren gaat: de metrics waren nooit bedoeld als ranglijst. Ze kwamen voort uit een statistische bevinding. Teams die goed scoorden op snelheid scoorden ook goed op stabiliteit. Snelheid en veiligheid waren geen trade-off, ze bewogen samen. Dat is een claim over correlatie tussen veel teams, niet een doel voor de jouwe.

De vijf metrics, gedefinieerd zoals een on-call engineer ze zou definiëren

De huidige definities op de officiële DORA metrics gids splitsen in twee groepen. Lees ze met een specifieke service in gedachte, want elke definitie valt uit elkaar als je ze op "het bedrijf" toepast.

Change lead time. De tijd van een commit tot die commit in productie draait. Niet van het moment dat het ticket geopend is, en niet van het moment dat de pull request goedgekeurd is. Van commit naar prod. Als je pipeline veertig minuten duurt en je release train vertrekt op donderdagen, wordt je lead time gedomineerd door donderdag.

Deployment frequency. Hoe vaak je naar productie shipped. Je kunt deployments tellen over een periode of de tijd tussen ze meten. Een service die elf keer per dag deployed en een service die eenmaal per maand deployed zijn andere dieren, en ze middelen verbergt beide.

Failed deployment recovery time. Hoe lang het duurt om te herstellen als een deployment een probleem veroorzaakt dat tussenkomst nodig heeft. Dit heette vroeger mean time to restore, en de hernoaming is opzettelijk. Het telt alleen incidenten veroorzaakt door jouw eigen verandering, niet een cloud provider outage op een dinsdag.

Change fail rate. Het aandeel van deployments dat daarna onmiddellijke tussenkomst nodig heeft: een rollback, een hotfix, een forward fix onder druk uitgepusht. Tien deployments, twee ervan teruggezet, change fail rate van twintig procent.

Deployment rework rate. Het aandeel van deployments dat ongepland is, geactiveerd door een productie-incident in plaats van roadmap werk. Dit is de nieuwste toevoeging, en het vangt iets op wat change fail rate mist: het team dat nooit terugdraait maar half zijn week noodupdates shipped.

Doorvoer versus instabiliteit: waarom je nooit één metric alleen leest

De eerste drie metrics zijn doorvoer. De laatste twee zijn instabiliteit. Die groepering is het hele punt.

Als je alleen doorvoer volgt, vier je een team dat veertig keer per dag deployed en stil tien procent terugdraait. Als je alleen instabiliteit volgt, beloon je een team dat eenmaal per maand shipped met een onberispelijk record, omdat niemand iets verandert. Elke single metric heeft een goedkoop manier om het te verbeteren die het systeem slechter maakt.

Deployment frequency stijgt als je een deploy in vijf lege deploys splitst. Change fail rate daalt als je stopt met hotfixes als mislukkingen te tellen. Lead time krimpt als je het begin van de klok opnieuw definieert. Dit is de wet van Goodhart die doet wat ze altijd doet: wanneer een maat een doel wordt, stopt het met een goede maat te zijn. De officiële gids noemt het eerst onder haar waarschuwingen, en het is de waarschuwing die het hardst bijt.

Dus de werkende regel is paren. Lees lead time naast change fail rate. Lees deployment frequency naast rework rate. Een beweging in één richting zonder overeenkomstig verhaal in de ander is een signaal om dichterbij te kijken, niet een winst om aan te kondigen.

Benchmarks circuleren in elk vendor deck, en ze zijn een val. Het gerapporteerde patroon uit recente DORA-rapporten is consistent in vorm: het sterkste cluster van teams deployed on demand, met een lead time onder een dag, en herstelt van een mislukte deployment in onder een uur. Het langzaamste cluster zit in weken-tot-maanden bereik op beide.

Die getallen zijn nuttig voor één ding: jouw intuïtie kalibreren over wat mogelijk is. Ze zijn slecht als doelen. Een betalingsservice met een verplichte audit gate zal niet overeenkomen met een marketingsite, en die zou het niet proberen. De officiële begeleiding is expliciet dat je alleen vergelijkbare applicaties of services zou moeten vergelijken, en dat je naar verbetering tegen jouw eigen baseline zou moeten streven in plaats van competitie tussen teams.

Begin met jouw eigen mediaan. Meet het een maand voordat je een doel stelt. Het eerste getal is bijna altijd beschamend, en dat is prima. Een baseline die je beschaamd is een baseline die je daadwerkelijk vertrouwt.

Hoe je ze instrumenteert zonder een dataplatform op te bouwen

De meeste teams bouwen dit te veel. Je hebt geen warehouse project nodig. Je hebt vier timestamps en één vlag nodig.

De timestamps: commit merged naar de main branch, build afgelopen, deployment gestart in productie, deployment afgelopen. De vlag: of de deployment later teruggezet, hotfixed of gevolgd door een ongeplande deploy binnen een gedefinieerd venster was.

Hier is een minimale schets in TypeScript. Het neemt een lijst van deployment records en geeft de getallen die tellen.

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),
  };
}

Twee besluiten in die snippet dragen het gewicht. Ten eerste gebruikt het de mediaan, niet het gemiddelde. Één slechte week met een drie dagen herstel zal een gemiddelde wrakken en je niets over een typische dinsdag zeggen. Ten tweede berekent het alles per service. Aggregaat naar een team of afdeling alleen nadat je naar de services eronder hebt gekeken.

Het moeilijke deel is niet de code. Het moeilijke deel is de failed vlag. Iemand moet beslissen wat als een mislukking telt, het opschrijven, en het elke keer op dezelfde manier toepassen. Als je incident tracker incidents aan de deployment die ze veroorzaakte koppelt, krijg je dit bijna gratis. Als dat niet zo is, begin daar.

De tooling vraag komt na de data vraag. Je bezit al de meeste ruwe data. Je Git host heeft commit tijden. Je CI heeft build en deploy events. Je incident tool heeft de mislukkingen. Het werk is ze op een gedeeld deployment identificatie koppelen.

Observability platforms zijn een natuurlijke plaats om deployment markers over error rates en latency te leggen, dus je kunt zien welke deploy welke piek voorafging.

Als je de stack liever open en self-hosted houdt, doet een dashboard laag over jouw eigen database van deployment events dezelfde baan tegen lagere kosten, met meer leidingen aan jouw kant.

Er is ook een categorie tooling die je repositories en delivery geschiedenis leest en risico oppervlakt, zoals hotspots waar code churn en voorbije fouten clusteren. Het zal de vier timestamps niet vervangen, maar het verklaart waarom één service een hoge change fail rate heeft terwijl zijn buren dat niet hebben.

Een voorzichtigheid op het kopen van iets hier. Een dashboard dat de getallen toont is niet hetzelfde als een team dat erop handelt. Als niemand eigenaar is van de recovery time grafiek, verandert het kopen van een mooier dashboard niets.

De hendels die elk getal daadwerkelijk verplaatsen

Metrics zijn diagnose. De behandeling is ergens anders, en die verschilt voor elk.

Voor lead time, kijk naar wachten, niet werken. Trek een dozijn recente veranderingen en markeer waar elk inactief zat: wachten op review, wachten op een build slot, wachten op een release window. Bij de meeste teams weegt de inactieve tijd de werkingstijd meerdere keren op. Kleinere pull requests en een review service-level expectation schreeuwen elk pipeline tuning.

Voor deployment frequency, de hendel is batch grootte. Kleinere veranderingen zijn makkelijker te reviewen, makkelijker erover na te denken, en makkelijker terug te draaien. Trunk-based development en feature flags bestaan zodat je onafgewerkt werk veilig kunt mergen, dus je kunt deployen van releasing ontkoppelen.

Voor change fail rate, de hendel is hoeveel van je blast radius je kunt zien voordat het het hele fleet is. Een rollout die één procent van het verkeer blootstelt, tegen een error rate tegen een SLO kijkt, en op een inbreuk stopt verandert een zou-be incident in een niet-incident. Dat is de kloof tussen een mislukte deployment en een mislukte verandering die niemand buiten het team opmerkte.

Voor recovery tijd, de hendel is revert. Als de snelste fix terugdraaien is, dan is recovery tijd hoe snel je het probleem detecteert plus hoe snel je de knop kunt indrukken. Het automatiseren van revert op een threshold inbreuk haalt de mens uit de eerste tien minuten. Om 3 uur 's nachts telt dat meer dan elke runbook.

Voor rework rate, de hendel is upstream. Een hoog getal betekent dat incidenten deployments genereren. Kijk naar welke services de noodupdates produceren, en lees hun post-mortems als een set in plaats van één tegelijk.

Wat verandert als AI meer van jouw code schrijft

Het recente DORA onderzoek wijst naar iets onaangenaams voor iedereen die een code assistent verkoopt. Assistenten versnellen low-level taken, maar de winsten droegen niet duidelijk door naar lead time of change fail rate. Meer code geschreven per uur is niet hetzelfde als meer waarde afgeleverd per week.

Als iets, duwt een groter volume gegenereerde veranderingen druk op review en op jouw delivery pipeline. Grotere batches schaden stabiliteit, en review capaciteit schaalt niet mee met typesnelheid. Volg jouw change fail rate en rework rate nauw in de maanden na een team een assistent aanneemt. Als lead time valt maar rework stijgt, ben je niet sneller geworden, je verplaatste de kosten.

Hoe je ze in een retro gebruikt zonder je team te breken

Hier is wat in de praktijk werkt. Zet de trend lines op het scherm voor het laatste kwartaal en stel één vraag: wat veranderde hier, en waarom? Stel niet wie. Het doel is een hypothese over het systeem, niet een vonnis over een persoon.

Drie gewoonten houden de getallen eerlijk.

Eerstens, zet ze nooit in individuele performance reviews. Op het moment dat een metric aan een naam hecht, optimaliseren mensen de metric, en jouw data stopt met werkelijkheid beschrijven.

Tweedels, koppel elk getal aan een verhaal. Een piek in recovery tijd is één incident met een naam en een post-mortem. Lees het post-mortem voordat je de grafiek leest.

Derdels, verander één ding tegelijk. Als je feature flags aanneemt, pull requests krimpt, en automatic rollbacks automatiseert in dezelfde maand, zul je nooit leren welke de naald verplaatste.

Sla de maturity-model slide over die jouw org in tiers sorteert en een trofee uitdeelt. Waard de moeite in plaats daarvan: één pagina per service, maandelijks bijgewerkt, vermeld de vijf getallen, de waarde van vorige maand, en één zin over wat veranderde.

Stel dat je negentig dagen schone data op één service had, en je zag de change fail rate omhoog kruipen terwijl deployment frequency vlak bleef. Waar zou je eerst kijken: de grootte van de veranderingen, de kwaliteit van de review, of de zichtbaarheid je hebt in een rollout terwijl het nog klein is? Jouw antwoord zegt meer over jouw delivery systeem dan welke benchmark ook.