Done is niet in productie: waarom je recovery time te mooi oogt

Veel teams die DORA-metrics invoeren, zien bij recovery time een opvallend goed cijfer. Een productiefout is gemiddeld binnen enkele dagen opgelost, zegt het dashboard.

Vaak klopt dat niet. Het cijfer meet tot het moment dat het ticket op Done staat. Maar Done betekent zelden dat de fix in productie draait.

Wat DORA met recovery time bedoelt

Failed Deployment Recovery Time (vroeger Time to Restore Service) meet hoe lang het duurt om een productieprobleem op te lossen. De klok start wanneer een deployment de service breekt. Hij stopt wanneer de service in productie weer werkt.

Het woord dat telt is productie. Niet "de fix is geschreven" of "de fix is goedgekeurd", maar "de gebruiker heeft er geen last meer van".

Waar het misgaat: de ticketstatus als eindpunt

De meeste DORA-tools halen het herstelmoment uit de issue tracker: de resolution date van het bug-ticket. Dat is handig, want die datum is er altijd.

Het probleem zit in hoe teams Done gebruiken. In veel organisaties gaat een ticket op Done zodra het ontwikkelwerk klaar is. Daarna volgt nog testen, acceptatie, een release-beslissing en de eigenlijke deployment.

Bij continuous delivery is dat verschil klein. Bij een vaste releasecadans, bijvoorbeeld maandelijks, kan er weken zitten tussen Done en productie. Het dashboard toont dan het snelle deel van het herstel en laat het trage deel weg.

Een betere meting: tot de eerstvolgende productie-deployment

De oplossing is eenvoudig. Gebruik Done niet als eindpunt, maar als drempel. Het herstelmoment is de eerste productie-deployment ná de resolution date van het ticket.

Het verschil tussen beide metingen is precies de tijd die een afgewerkte fix wacht op productie. Bij een vaste releasecadans is dat vaak het grootste deel van de hersteltijd.

De aanpassing vraagt geen nieuwe werkwijze van het team. Deployments en ticketdata zijn er al; alleen de query verandert.

Waarom het uitmaakt: Dev en Ops samen meten

DORA staat voor DevOps Research and Assessment. Het framework meet bewust Dev en Ops als één geheel. Een meting tot Done meet alleen het Dev-deel.

Dat is meer dan een rekenfout. Wat je meet, bepaalt waar je verbetert. Toont het cijfer alleen ontwikkeltijd, dan gaan investeringen naar snellere fixes, betere reviews en meer testautomatisering.

Zit de echte vertraging in het releaseproces, dan levert dat weinig op. Wachttijd tot de volgende release, beschikbaarheid van testomgevingen en handmatige deploystappen blijven onzichtbaar. Correct meten richt de aandacht op de plek waar de tijd verloren gaat.

Kanttekeningen bij de meting

Ook de betere meting is een benadering. Drie dingen om in het achterhoofd te houden:

• Niet elke fix gaat mee met de eerstvolgende release. Wordt een fix bewust uitgesteld, dan onderschat de meting nog steeds de werkelijke hersteltijd.
• De koppeling tussen bug en oorzaak is een tijdvenster, geen bewijs. Tools wijzen een bug meestal toe aan de laatste deployment ervoor. Bij één productieversie tegelijk is dat verdedigbaar, maar het blijft een proxy.
• Het gemiddelde liegt. Hersteltijden zijn vaak bimodaal: veel snelle fixes, en een staart die op een volgende release wacht. Kijk naar de mediaan en de verdeling.

Ga daarom niet rechtstreeks van cijfer naar conclusie. Valideer een steekproef tickets tegen de werkelijkheid, en bespreek afwijkingen met het team.

Lessen

• Controleer wat je eindpunt betekent. Vraag het team wat Done voor hen inhoudt, voor je het als herstelmoment gebruikt.
• Meet tot productie, niet tot een ticketstatus. De eerstvolgende productie-deployment is een eenvoudige en eerlijke benadering.
• Pas de meting aan, niet de werkwijze. Een werkende delivery-flow omgooien om een tool tevreden te stellen, introduceert risico. Eerst meten zoals het is, dan gericht verbeteren.
• Een laag cijfer is input, geen oordeel. Een trage hersteltijd bij een maandelijkse cadans is vaak een gevolg van een bewuste keuze. De vraag is of die keuze nog bij de business-doelen past.

Een metric die te mooi oogt, is gevaarlijker dan een metric die slecht oogt. De eerste stuurt je verbeterwerk de verkeerde kant op.