Vad är DORA-måtvärdena? De fyra nycklar varje dev behöver

Vad är DORA-måtvärdena? De fyra nycklar varje dev behöver

Vad ar dora-matvarden? Om du har blivit frågad detta och behövde ett rent svar: de är fyra mätningar som kvantifierar mjukvaruleveransprestation. Deployment Frequency, Lead Time för ändringar, Change Failure Rate och Time to Restore Service. Utvecklat av Nicole Forsgren, Jez Humble och Gene Kim, dessa måtvärdena har validerats över tiotusentals utvecklargrupper och förvärvats av Google 2018. Den här guiden täcker vad varje mätvärde spårar, hur riktmärken ser ut i praktiken och där modellen slutar vara rätt lins.

Varifrån DORA-måtvärdena kom och varför forskningen spelar roll

DORA-programmet startade 2014 med en specifik fråga: vad gör högpresterande programvaruteam annorlunda än alla andra? Forskningsteamet körde årliga undersökningar av tiotusentals utvecklare inom olika industrier och letade efter de praktiker som förutspådde stark mjukvaruleveransprestation.

Resultatet som gjorde forskningen sticka ut var motintuitivt. Elitteam handlade inte om att välja mellan hastighet och stabilitet. De shipper snabbare och hade färre produktionsincidenter. Det resultatet underminerade den vanliga rättfärdigheten för att bromsa ned releasezykler: om vi deployer mer sällan kommer vi att bryta saker mindre ofta.

Datan sade motsatsen. Team som deployede ofta byggde bättre återkopplingsslungor, fångade problem tidigare och återhämtade sig snabbare när något gick fel. Hastighet och stabilitet var inte i opposition. De var korrelerade.

Google förvärvade DORA-programmet 2018. Teamet publicerar nu en årlig State of DevOps Report, uppdaterade sin modell 2025 med ett femte mätvärde (Rework Rate) och underhåller forskningen som en öppen initiativ på dora.dev.

De fyra mätningarna och vad var och en faktiskt mäter

Modellen uppdaterades 2025 för att lägga till Rework Rate som ett femte mätvärde, men de fyra ursprungliga nycklarna förblir basnivån för de flesta verktyg och teamdiskussioner.

Deployment Frequency

Hur ofta ditt team pushar till produktion. Det är hela definitionen.

Elitteam deployer on demand: flera gånger per dag när något är klart. Låga presterar deployer en gång i månaden eller mindre, ibland en gång var tredje månad. För en solobyggare säger vilken som helst konsekvent veckovis shippingcadence att du ligger ordentligt i den höga prestationsklassen just på denna mätning.

Deployment frequency är en proxy för pipeline-förtroende. Team som deployer sällan har oftast skör infrastruktur, tunga manuella testportar eller organisatoriska godkännandekedjor som bromsar releaser till crawlartakt. Team som shipper flera gånger dagligen har automatiserat bort de flesta av dessa flaskhalsar. Frekvensen är ett symptom, inte orsaken.

Lead Time for Changes

Tiden från att en commit når versionskontroll till att samma ändring är live i produktion.

De flesta av denna varaktighet är inte kodskrivning. Det är väntan: vänta på att pull request-kön blir fri, vänta på att CI/CD-pipelines slutas, vänta på en deploymentslot, vänta på att någon med åtkomst triggar releasen. En ledtid på ett par timmar betyder att arbetsflödet är stramt och mestadels automatiserat. En ledtid mätt i veckor betyder att något strukturellt lägger till friktion på en eller flera av dessa handoffpunkter.

För ensamutvecklare är ledtid vad som helst som står mellan att pusha en commit och att användare ser resultatet. Ibland är det en deploymentpipeline som tar tolv minuter. Ibland är det intern tveksamhet om huruvida en ändring är stabil nog att shippas.

Change Failure Rate

Procentandelen deployments som orsakar ett problem som är allvarligt nog att kräva en hotfix, rollback eller incident response.

Det här är kvalitetssignalen i DORA-modellen. 2024 State of DevOps Report placerar elitteam på omkring 5% change failure rate. Låga presterar kör på 46 till 63%. Om ungefär hälften av dina deployments kräver omedelbar intervention har din testabäckning och reviewprocess betydande strukturella luckor.

Change failure rate mäter inte kodkvalitet i abstrakt. Det mäter om de ändringar du shipper beter sig som förväntat i produktionsmiljön specifikt. En testsvit som passar lokalt men inte täcker integreringsbanan som misslyckas i produktion kommer inte att flytta denna siffra.

Time to Restore Service

När en deployment orsakar en incident, hur länge innan tjänsten är återställd?

Det var ursprungligen märkt Mean Time to Recovery (MTTR). DORA-teamet uppdaterade formuleringen 2025 till Failed Deployment Recovery Time, specifikt spårning av återhämtning från deploymentorsakkade incidenter snarare än infrastrukturfel eller tredjepartsavbrott. Distinktionen spelar roll eftersom deploymentorsakkade incidenter är helt under teamets kontroll, vilket gör dem till det rätta målet för processförbättringar.

Elitteam återställer tjänsten på under en timme. Låga presterar kan ta dagar till en vecka. Om du är en solobyggare är denna metrik helt och hållet om huruvida du har övervakning på plats alls. Team utan alert-infrastruktur får reda på misslyckanden från användarreklamationer snarare än automatiserade signaler, vilket lägger till timmar på någon återställningstid.

Hur prestationsnivåerna faktiskt ser ut

State of DevOps-rapporten grupperar team i fyra nivåer baserat på deras DORA-siffror. Elitteam deployer flera gånger per dag med ledtid under en timme, en change failure rate under 5% och kan återställa tjänsten på under en timme. Högt presterande team deployer dagligen till veckovis med ledtid på 1 dag till 1 vecka, failure rate på 5-10% och återställningstid under en dag. Medel prestationsgrupper deployer veckovis till månatlig med ledtid på 1 vecka till 1 månad, failure rate på 10-15% och återställningstid på 1 dag till 1 vecka. Låga presterar deployer månatlig eller mindre med ledtid på 1 till 6 månader, failure rate på 46-63% och återställningstid på 1 vecka till 6 månader.

Gapet mellan elit och låg är inte inkrementellt. Enligt 2024-rapporten kan lågt presterande team ta över 180 gånger längre att deployer och över 2 500 gånger längre att återhämta sig från incidenter jämfört med elitteam. Detta är inte marginella skillnader.

Att nå elitprestationsnivå är möjligt med uthållig investering i CI/CD-automatisering, testabäckning och observabilitetsverktyg. Det händer inte genom att skriva snabbare kod. Det händer genom att ta bort de manuella stegen och väntetiderna mellan att commita kod och att ha den körs i produktion på ett tillförlitligt sätt.

Hur AI-utvecklingsverktyg skiftar DORA-siffror 2026

År 2026 har AI-kodningsverktyg blivit vanliga nog att påverka DORA-måttvärdena på sätt som är värd att spåra specifikt.

Team som använder Cursor, GitHub Copilot eller liknande verktyg skriver kod snabbare, vilket tenderar att puska deployment frequency upp. Ledtid har också förkortas hos många team eftersom mer kod produceras per utvecklare per vecka, vilket innebär fler commits som flödar genom pipelinen.

Change failure rate har gått åt båda håll. Team med starka reviewprocesser och testabäckning har hållit sina felfrekvenser stabila medan de shipper mer. Team som shipper AI-genererad kod utan tillräcklig granskning har sett felfrekvenser öka. DORA-modellen bryr sig inte om hur kod skrivs. Den mäter vad som händer efter att koden shipper till produktion.

DORA 2024 State of DevOps Report fann att 41% av undersökta team rapporterade att de använder AI-assisterad utvecklingsverktyg. Dessa team visade högre deployment frequency utan proportionell ökning av change failure rate när AI-adoption kombinerades med automatiserad testning och reviewpipelines.

Voilà vad som kör på här: AI accelererar framsidan av pipelinen avsevärt. DORA berättar om den accelerationen absorberas rent eller skapar instabilitet nedströms.

Verktyg för att spåra DORA-måttvärden utan att överbygga din stack

De flesta team börjar mäta DORA-måttvärdena genom att dra data från verktyg de redan använder: GitHub eller GitLab för deployment-händelser och commit-tidsstämplar, PagerDuty eller OpsGenie för återställningstidsdata, och incidenthanteringssystemet för change failure rate-räkningar.

Flera plattformar har byggt DORA-instrumentpaneler specifikt omkring dessa fyra måttvärdena. Varje plattform erbjuder sin egen presentation av dessa mätvärden, men grundidén är densamma: ta in data från dina befintliga verktyg och presentera dem på ett sätt som gör trender synliga.

För en solobyggare utan verktygsbudget: ett skript som loggar tidsstämpeln för varje produktionsdeployment och varje återställningshändelse ger dig deployment frequency och återställningstid utan infrastrukturkostnad. Ledtid kan ungefärligt uppskattas från commit-tidsstämplar i Git-loggen. Många dev använder helt enkelt en GitHub-release eller ett Git-tag per deployment och ett kalkylblad för incidentlogning.

Där DORA-måttvärden har riktiga gränser

Att mäta DORA är användbart. Att behandla det som det kompletta bilden av ingenjörsprestation skapar flera specifika blinda fläckar värt att namnge.

Ackumulering av teknisk skuld. Hög deployment frequency med låg change failure rate berättar ingenting om huruvida kodbasen blir svårare att arbeta med över tid. Ett team kan nå elitDORA-siffror medan de stadigt ackumulerar den typ av skuld som gör varje ny feature långsammare att shippas. DORA mäter leveransutbud; det mäter inte tillståndet för vad du levererar in i.

Resultatjustering. Deployment frequency mäter utbud, inte resultat. Att shippas fem gånger per dag spelar ingen roll om ingen av dessa ändringar flyttar ett mätvärde som produkten eller verksamheten bryr sig om. Feature flags, A/B-testningsinfrastruktur och tracking av affärsmätvärden ligger helt utanför DORA-modellen.

Hållbarhet. DORA-forskningsteamet lade till en utvecklarerfarenhetsdimension till ramverket 2023, och erkände att hållbar höga prestationer kräver ingenjörer som inte springer på utbrändhet. De fyra kärnmåtvärdena spårar inte om att nå elittal kommer på bekostnad av något annat.

Använd DORA som ett baseline-diagnosverktyg, inte en poängtavla. De frågor som måtvärdena väcker är ofta mer handlingskraftiga än siffrorna själva. En change failure rate på 30% är mindre användbar än att veta vilka typer av ändringar som misslyckas oftast och varför.

Där man börjar om man aldrig spårde detta tidigare

Ett sex månader gammalt sidoprojekt utan DORA-data är normalt. De flesta små team och ensamutvecklare har aldrig mätt något av detta.

Om du börjar från noll, välj deployment frequency och lead time först. Båda är lätta att extrahera från Git commit-tidsstämplar och deploymentloggar, och de ger dig omedelbar feedback om din pipeline har onödig friktion. En ledtid på tre dagar för en ändring som tar fyrtio minuter att skriva är en signal värd att undersöka.

Change failure rate och time to restore kräver incidenter att ackumulera innan siffrorna betyder något. När något brister i produktion, logga tidsstämpeln när det upptäcktes och tidsstämpeln när det löstes. Denna data förenar sig över tid.

En praktisk vana: efter någon produktionsincident, ställ två frågor. Hur länge tog det att detektera detta problem? Hur länge från upptäckt till lösning? Dessa två siffror är indata till time to restore. Att spåra dem konsekvent i sex månader ger dig tillräcklig historia för att veta om din återställningsprocess förbättras eller förblir platt.

Tre skäl att mäta DORA-måttvärdena även som ensamutvecklare, ett skäl att inte bry sig: måtvärdena gör osynlig friktion synlig, de skapar ansvar för automationsoinvesteringar, och de ger dig något konkret att förbättra mellan funktionsarbete. Skälet att inte bry sig: om du är före lansering utan produktionsanvändare är siffrorna inte så meningsfulla än. Börja mäta när du shipper till riktiga användare regelbundet.

Det är inte en perfekt idé. Det är en genomförbar idé.