Hoe meet je DevOps-succes: de 4 cruciale metrics die je moet kennen (DORA, 2025)

Als je een delivery-organisatie leidt, heb je waarschijnlijk weleens een dashboard met twintig "DevOps-metrics" onder je neus gekregen. De meeste daarvan zijn ijdelheidscijfers. Het signaal dat een decennium aan kritiek heeft overleefd is smal: vier metrics, jaarlijks gevalideerd onder tienduizenden practitioners door het DORA-onderzoeksprogramma van Google, die zowel de software delivery-prestaties als de organisatie-uitkomsten voorspellen. Dit is een werkdocument over wat die vier metrics in hun huidige vorm zijn, hoe goed er in cijfers daadwerkelijk uitziet, en de grootste verandering sinds 2023: AI zit nu midden in je pipeline en hervormt deze cijfers stilletjes, niet altijd in jouw voordeel.

Diagram van de pijlers van engineering-productiviteit dat laat zien hoe de vier DORA-delivery-metrics throughput tegen stabiliteit afwegen

Twee dingen om je eigen te maken voordat we de metrics een voor een doorlopen. Ten eerste zijn de vier metrics bewust opgesplitst in twee tegengestelde paren: throughput (deployment frequency, lead time) en stabiliteit (change failure rate, recovery time). Je leest ze samen. Een team dat tien keer per dag deployt maar bij een derde van die deploys productie sloopt, presteert niet hoog, het is roekeloos. Het onderzoek is hier consistent: high performers blinken op alle vier uit, en een team dat zwak is op een van de vier is meestal zwak op alle vier, omdat dezelfde onderliggende werkwijzen (kleine batches, geautomatiseerd testen, snelle feedback) ze allemaal aandrijven (InfoQ, 2024 DORA analysis). Ten tweede is de terminologie veranderd. Als je in een stuurgroep nog steeds "MTTR" aanhaalt, loop je een versie achter.

De vier metrics, in hun huidige vorm

1. Deployment Frequency

Hoe vaak je succesvol naar productie uitbrengt. Dit is de zuiverste proxy voor batchgrootte: teams die vaak deployen verschepen noodgedwongen kleine wijzigingen, en juist dat maakt alles stroomafwaarts veiliger. De elite-band is on-demand, meerdere deploys per dag; low performers zitten tussen een keer per week en een keer per maand (Octopus Deploy / DORA benchmarks). De valkuil is het cijfer in isolatie vieren. Frequentie is alleen betekenisvol wanneer de stabiliteit tegelijkertijd standhoudt, en dat is precies waarom je het nooit alleen rapporteert.

2. Lead Time for Changes

De doorlooptijd vanaf het moment dat een commit landt tot diezelfde commit in productie draait. Dit is de werkelijke cyclustijd van je pipeline, en het legt alles bloot tussen het toetsenbord van een engineer en de klant: reviewwachtrijen, handmatige goedkeuringspoorten, instabiele testsuites, release trains die alleen op donderdag vertrekken. Elite-teams halen minder dan een dag, van commit tot productie; low performers meten dit in weken of maanden (Octopus Deploy / DORA benchmarks). Voor gereguleerde teams is lead time de plek waar je change management- en functiescheidingscontroles zichtbaar worden als latency. Het doel is niet de controles weghalen, maar het bewijs automatiseren zodat de controle milliseconden kost, geen dagen.

3. Change Failure Rate

Het percentage deployments dat resulteert in een gedegradeerde service die herstel vereist (een hotfix, rollback of patch). Dit is het stabiliteitstegenwicht voor deployment frequency. De banden zijn concreet en het waard om uit je hoofd te kennen: elite is 5%, high 10%, medium 15%, en low performers lopen helemaal op tot ruwweg 64% (Octopus Deploy / DORA benchmarks). Een change failure rate boven de 15% is zelden een toolingprobleem; het wijst meestal op gaten in testen en review die geen enkele hoeveelheid dashboarding oplost.

4. Failed Deployment Recovery Time

Dit is de metric die de meeste leiders nog steeds bij de naam verkeerd hebben. DORA heeft "Mean Time to Recovery (MTTR)" met pensioen gestuurd en rapporteert nu Failed Deployment Recovery Time: specifiek hoe lang het duurt om de service te herstellen na een mislukte deployment, niet na zomaar een incident (Octopus Deploy / DORA benchmarks; DORA metrics history). De afbakening is bewust, want het isoleert het deel van het herstel dat je daadwerkelijk via je releaseproces in de hand hebt. Elite-teams herstellen in minder dan een uur; high performers binnen een dag. Merk ook op dat DORA deze metric bij throughput indeelt in plaats van bij stabiliteit, met als redenering dat snel herstel zelf een functie is van hoe snel je een fix kunt verschepen (DORA metrics history). De praktische conclusie is onveranderd: investeer in directe rollback zonder gedoe. Een revert met een klik is meer waard dan welk post-incidentprocesdocument dan ook.

Voorbij de vier: Rework Rate en Reliability

De canonieke vier blijven de industriestandaard, maar ze als het complete plaatje behandelen is inmiddels een fout. DORA heeft een vijfde metric toegevoegd, Rework Rate, gedefinieerd als het aandeel deployments dat ongeplande fixes zijn die door een productieprobleem worden getriggerd, als aanvulling op change failure rate. Waar change failure rate de deploys vangt die stukgingen, vangt rework rate de instabiliteit die daarna naar boven komt als ongepland productiewerk (Octopus Deploy / DORA benchmarks). DORA volgt daarnaast een bredere Reliability-dimensie die bekijkt of de service zijn eigen beschikbaarheids- en latencydoelen haalt (Octopus Deploy / DORA benchmarks). Als je team volwassen is op de vier, is rework rate het volgende cijfer dat ik op het bord zou zetten, want het vangt een faalpatroon dat de oorspronkelijke vier missen: het trage gedruppel van "we hebben het verscheept en daarna drie dagen lang lopen babysitten."

De AI-variabele: een versterker, geen oplossing

Dit is het deel dat sinds de versie van dit advies uit 2023 echt is veranderd, en het deel dat je aandacht het meest verdient. In het DORA-rapport van 2025, gebaseerd op bijna 5.000 respondenten, gebruikt nu 90% AI op het werk en meldt ruim 80% productiviteitswinst, en voor het eerst werd de relatie tussen AI en throughput positief (Google Cloud, 2025 DORA report). Dat is het goede nieuws, en het is echt. Het ongemakkelijke nieuws is dat AI nog steeds correleert met slechtere delivery-stabiliteit: meer change failures en meer rework (Google Cloud, 2025 DORA report). Het rapport van 2024 kwantificeerde de rem onomwonden: een toename van 25% in AI-adoptie liep samen met ruwweg een daling van 1,5% in throughput en een afname van 7,2% in stabiliteit, naast 39% van de practitioners die weinig tot geen vertrouwen in AI-gegenereerde code meldden (Google Cloud, 2024 DORA report). Het mechanisme is geen mysterie: AI maakt het triviaal om grotere changesets te produceren, wat direct ingaat tegen het small-batch-principe dat elk van de vier metrics beloont (InfoQ, 2024 DORA analysis).

De hoofdconclusie van DORA is de zin om mee te nemen naar je volgende planningsoverleg: "AI doesn't fix a team; it amplifies what's already there" (Google Cloud, 2025 DORA report). Een team met sterke tests, snelle feedback en gedisciplineerde batchgroottes zet de snelheid van AI om in veilige snelheid. Een team zonder die fundamenten zet diezelfde AI om in snellere productie-incidenten. Precies daarom meet je alle vier de metrics in plaats van alleen op velocity te jagen: de vier zijn je vroegtijdige waarschuwingssysteem voor de vraag of AI je sterke of je zwakke punten versterkt. Het rapport is even duidelijk dat de grootste ROI niet komt van meer tooling kopen maar van het verbeteren van het onderliggende systeem, en het wijst platform engineering aan als de sleutel-enabler. 90% van de organisaties heeft nu minstens een intern developer platform geadopteerd, en die platformlaag is wat de small-batch- en snel-herstellende werkwijzen herhaalbaar maakt over teams heen (Google Cloud, 2025 DORA report).

Hoe je dit gebruikt

Instrumenteer de vier metrics rechtstreeks vanuit je deployment pipeline en incidenttooling, niet vanuit een enquête. Rapporteer throughput en stabiliteit elke keer naast elkaar, en voeg rework rate toe zodra de vier stabiel zijn. Stel doelen vast aan de hand van de gepubliceerde banden in plaats van je eigen banden te verzinnen. En wanneer een AI-codeerassistent in je stack belandt, houd je change failure rate en rework rate het komende kwartaal net zo nauwlettend in de gaten als de productiviteitswinst, want bij dat tweede cijfer komt de rekening binnen. De metrics zijn sinds 2023 niet ingewikkelder geworden. De omgeving eromheen wel, en juist daarom is ze goed meten nu belangrijker dan toen. Voor hoe dit aansluit op ons bredere delivery-werk, zie onze DevOps and Cloud engineering-praktijk.