Vad är DORA-mått: Fem metrics som styr mjukvaruutveckling

Vad är DORA-mått? De är fem nyckeltal för mjukvaruutveckling: ledtid för ändringar, deploymentfrekvens, återhämtningstid efter misslyckad deployment, förändringsfelfrekvens och omarbetningsfrekvens. De första tre beskriver genomströmning, de två sista instabilitet. Tillsammans visar de hur snabbt ändringar når produktion och hur ofta de skadar. Använt rätt pekar de mot flaskhalsen. Använt dåligt blir de ett rapportkort som ditt team lär sig att manipulera.

Där siffrorna kommer från, och varför vokabulären fastnade

En plattformschef sitter i en kvartalsöversyn. CTO:n ställer en fråga: levererar vi snabbare än förra året, och bryter vi mindre? Utan ett delat språk är svaret en hög anekdoter. DORA-måtten finns till för att ersätta anekdoterna med fyra eller fem siffror du kan hämta från system du redan kör.

Namnet kommer från DevOps Research and Assessment, ett forskningsprogram som spenderade år på att undersöka ingenjörsteam och korrelera deras utvecklingsmetoder med organisatoriska resultat. Det är nu en del av Google Cloud, och resultaten publiceras varje år i DORA:s forskningsprogram. Boken Accelerate populariserade de ursprungliga fyra. Ramverket har reviderats sedan dess, och den revideringen betyder mer än de flesta blogginlägg erkänner.

Här är det som försvinner: måtten var aldrig avsedda som ett poängord. De kom ur ett statistiskt fynd. Team som var bra på hastighet var också bra på stabilitet. Hastighet och säkerhet var inte en kompromiss, de rörde sig tillsammans. Det är ett påstående om korrelation över många team, inte ett mål för ditt.

De fem måtten, definierade så som en on-call-ingenjör skulle definiera dem

De nuvarande definitionerna i officiell DORA-måttguide delas in i två grupper. Läs dem med en specifik tjänst i åtanke, för varje definition faller isär om du använder den på "företaget".

Ledtid för ändringar. Tiden från en commit till den commiten kör i produktion. Inte från biljetten öppnades, och inte från pull requesten godkändes. Från commit till prod. Om din pipeline tar fyrtio minuter och din releasetåg går på torsdagar domineras din ledtid av torsdagen.

Deploymentfrekvens. Hur ofta du shipper till produktion. Du kan räkna deployments över en period eller mäta gapet mellan dem. En tjänst som deployer elva gånger per dag och en som deployer en gång per månad är olika djur, och att medelvärde dem döljer båda.

Återhämtningstid efter misslyckad deployment. Hur lång tid det tar att återhämta sig när en deployment orsakar ett problem som behöver ingripande. Detta brukade kallas mean time to restore, och bytet är avsiktligt. Det räknar bara incidenter orsakade av din egen ändring, inte ett cloud provider-avbrott på en tisdag.

Förändringsfelfrekvens. Andelen deployments som behöver omedelbar intervention efteråt: en rollback, en hotfix, en snabb forward fix. Tio deployments, två av dem återkallade, en förändringsfelfrekvens på tjugo procent.

Omarbetningsfrekvens. Andelen deployments som är oplanerade, utlösta av en produktionsincident snarare än av roadmaparbete. Det här är det nyaste tillskottet, och det fångar något som förändringsfelfrekvensen missar: teamet som aldrig rullar tillbaka men spenderar hälften av sin vecka att skicka nödsituationspatchar.

Genomströmning kontra instabilitet: varför du aldrig läser ett mått ensamt

De första tre måtten är genomströmning. De två sista är instabilitet. Grupperingen är hela poängen.

Om du bara tittar på genomströmning, kommer du att fira ett team som deployer fyrtio gånger per dag och tyst rullar tillbaka en fjärdedel av dem. Om du bara tittar på instabilitet, belönar du ett team som shipper en gång per månad med en fläckfri rekord, för ingen ändrar något. Varje enda mått har ett billigt sätt att förbättra det på som gör systemet sämre.

Deploymentfrekvensen går upp när du splittar en deploy i fem tomma deploys. Förändringsfelfrekvensen går ner när du slutar räkna hotfixes som misslyckanden. Ledtiden krymper när du omdefinierar början på klockan. Det här är Goodharts lag som gör vad den alltid gör: när ett mått blir ett mål slutar det vara ett bra mått. Den officiella guiden listar det först bland sina varningar, och det är det som biter hårdast.

Så arbetesregeln är par. Läs ledtid bredvid förändringsfelfrekvens. Läs deploymentfrekvens bredvid omarbetningsfrekvens. En rörelse i en riktning utan en motsvarande historia i den andra är en signal att titta närmare, inte en vinst att tillkännage.

Benchmarks cirkulerar i varje leverantörsdeck, och de är en fälla. Det rapporterade mönstret från de senaste DORA-rapporterna är konsistent i form: det starkaste clustret av team deployer on demand, med en ledtid under en dag, och återhämtar sig från en misslyckad deployment på under en timme. Det långsammaste clustret sitter på veckor-till-månader på båda.

De siffrorna är användbara för en sak: kalibrera din intuition om vad som är möjligt. De är dåliga som mål. En betalningsservice med en obligatorisk granskningsport kommer inte att matcha en marknadsföringswebbplats, och det bör den inte försöka. Den officiella vägledningen är uttrycklig att du bara bör jämföra liknande applikationer eller tjänster, och att du bör sträva efter förbättring mot din egen baslinje snarare än tävling mellan team.

Börja med din egen median. Mät den under en månad innan du sätter något mål. Det första talet är nästan alltid skämmande, och det är okej. En baslinje som skäms är en baslinja du faktiskt litar på.

Hur du instrumenterar dem utan att bygga en dataplattform

De flesta team bygger för mycket här. Du behöver inte ett datalager. Du behöver fyra tidsstämplar och en flagga.

Tidsstämpelarna: commit merged till huvudgrenen, bygget avslutad, deployment startat i produktion, deployment avslutad. Flaggan: om deploymentet senare återkallades, hotfixades eller följdes av en oplanerad deploy inom ett definierat fönster.

Här är en minimal skiss i TypeScript. Den tar en lista med deploymentposter och returnerar de siffror som spelar roll.

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

Två beslut i det kodstycket bär vikten. För det första använder det medianen, inte genomsnittet. En dålig vecka med en tre dagars återhämtning kommer att förstöra ett genomsnitt och inte säga dig något om en typisk tisdag. För det andra beräknar det allt per tjänst. Aggregera till ett team eller en avdelning först efter att du har tittat på tjänsterna under.

Den svåra delen är inte koden. Den svåra delen är failed-flaggan. Någon måste bestämma vad som räknas som ett misslyckande, skriva ned det, och tillämpa det på samma sätt varje gång. Om din incidentspårare länkar incidenter till deploymentet som orsakade dem, får du detta nästan gratis. Om den inte gör det, börja där.

Verktygsfrågan kommer efter datafrågon. Du äger redan det mesta av rådatan. Din Git-värd har commit-tider. Din CI har bygget och deployment-händelser. Ditt incidentverktyg har misslyckandena. Arbetet är att sammanfoga dem på en delad deploymentidentifierare.

Observabilitetsplattformar är en naturlig plats för att överlägga deploymentmarkörer på toppen av felfrekvenser och latens, så du kan se vilket deploy som föregick vilken topp.

Om du hellre håller stacken öppen och self-hosted kan en dashboardlager över din egen databas med deploymenthändelser göra samma arbete till lägre kostnad, med mer ledningar på din sida.

Det finns också en kategori verktygsutveckling som läser dina databaser och leveranshistorik och ser riskkällor, såsom hotspots där kodändring och tidigare defekter grupperar. Det ersätter inte de fyra tidsstämpelarna, men det förklarar varför en tjänst har en hög förändringsfelfrekvens när dess grannar inte gör det.

En varning kring att köpa något här. En dashboard som visar siffrorna är inte samma sak som ett team som agerar på dem. Om ingen äger återhämtningsdiagrammet kommer att köpa ett snyggare diagram inte förändra något.

De spakarna som faktiskt rör varje siffra

Måtten är en diagnos. Behandlingen är någon annanstans, och den är annorlunda för var och en.

För ledtid, titta på väntan, inte arbete. Dra ett dussin senaste ändringar och markera där var och en satt stilla: väntar på recension, väntar på en byggplats, väntar på ett releasefönster. I de flesta team uppväger väntetiden arbetidtiden flera gånger över. Mindre pull requests och en tjänstegradsgräns för recension slår alla pipelineändringar.

För deploymentfrekvens är spaken batchstorlek. Mindre ändringar är lättare att granska, lättare att resonera om, och lättare att rulla tillbaka. Trunk-baserad utveckling och funktionsflaggor finns för att låta dig sammanfoga oavslutat arbete säkert, vilket är hur du avkopplar deployment från lansering.

För förändringsfelfrekvens är spaken hur mycket av sprängradien du kan se innan det är hela flottan. En utrullning som exponerar en procent av trafiken, tittar på en felfrekvens mot ett SLO, och stannar på ett brott förvandlar en skulle-ha-varit-incident till en icke-händelse. Det är gapet mellan en misslyckad deployment och en misslyckad förändring som ingen utanför teamet märkte.

För återhämtningstid är spaken återkallelsen. Om det snabbaste fixet är att rulla tillbaka, då är återhämtningstiden hur snabbt du detekterar problemet plus hur snabbt du kan trycka på knappen. Att automatisera återkallelsen på ett tröskelöverträdelse skär den mänskliga ur de första tio minuterna. Klockan tre på morgonen spelar det mer än någon runbook.

För omarbetningsfrekvens är spaken uppströms. Ett högt nummer betyder incidenter genererar deployments. Titta på vilka tjänster som producerar nödsituationspatchar, och läs deras eftersamtalen som en uppsättning snarare än en i taget.

Vad ändras när AI skriver mer av din kod

Den senaste DORA-forskningen pekar på något obehagligt för den som säljer en kodningsassistent. Assistenter påskyndar lågnivåuppgifter, men vinsterna bar sig inte klart genom till ledtid eller förändringsfelfrekvens. Mer kod skriven per timme är inte samma sak som mer värde levererat per vecka.

Om något skjuter assistenter upp trycket på recension och på din leveranspipeline. Större batcher skadar stabilitet, och recensionskapacitet skalas inte med skrivhastighet. Titta nära på din förändringsfelfrekvens och omarbetningsfrekvens under månaderna efter ett team antar en assistent. Om ledtid faller men omarbetning klättrar, blev du inte snabbare, du flyttade kostnaden.

Hur du använder dem i en retro utan att förstöra ditt team

Här är vad som fungerar i praktiken. Sätt trendlinjerna på skärmen för den senaste kvartalen och ställ en fråga: vad ändrades här, och varför? Fråga inte vem. Målet är en hypotes om systemet, inte en dom över en person.

Tre vanor håller siffrorna ärliga.

För det första, lägg dem aldrig i individuella resultatöversikter. I det ögonblick ett mått fäster vid ett namn optimerar människor måttet, och dina data slutar beskriva verklighet.

För det andra, para varje nummer med en historia. En spik i återhämtningstid är en incident med ett namn och en eftersamtal. Läs eftersamtalet innan du läser diagrammet.

För det tredje, ändra en sak i taget. Om du antar funktionsflaggor, minskar pull requests, och automatiserar återkallelser i samma månad, kommer du aldrig att lära dig vilken som rörde nålen.

Hoppa över modellsamvuxenhet-bild som sorterar din organisation i nivåer och delar ut en pokal. Det är värt ansträngningen istället: en enda sida per tjänst, uppdaterad månadsvis, som listar de fem talen, föregående månads värde, och en mening om vad som ändrades.

Antag att du hade nittio dagar med ren data på en tjänst, och du såg förändringsfelfrekvensen krypa uppåt medan deploymentfrekvensen stannade kvar. Var skulle du titta först: storleken på ändringarna, kvaliteten på recensionen, eller synligheten du har i en utrullning medan den fortfarande är liten? Ditt svar säger mer om ditt leveranssystem än något benchmark gör.