DevOps-mått för att mäta framgången i dina processer
Så du har börjat införa DevOps i ditt företag. Men hur kan du se om det förbättrar era processer? Du måste mäta framgången på något sätt, och det kan du göra genom att övervaka några viktiga DevOps-mätvärden.
Det finns många sätt att bedöma kvaliteten på ett system eller en applikation, men i den här artikeln fokuserar jag på viktiga mätvärden som hjälper till att utvärdera kvaliteten på era processer. Genom att följa dessa indikatorer kan du få djupare insikter i era styrkor och svagheter, förbättra era bästa metoder för DevOps och använda rätt verktyg och programvara för kontinuerlig förbättring.
Varför är DevOps-mätvärden viktiga?
Som vi upptäckte ovan kan gemensamma mål och mätvärden vara en utmaning för team som inför DevOps i en verksamhet. Utan DevOps-mätvärden skulle det inte finnas någon testning eller mätning och inga förbättringar av utvecklingen. Det skulle bara vara iterationer av samma programvara baserade på gissningar och idéer, som kastas ut i tomheten, varefter man försöker med något nytt. Utan återkoppling eller mätvärden för produktframgång för att förstå hur något presterar finns det ingen riktning.
Continue Reading for Free
Create a free account to finish this article, plus get ongoing access to timely insights and practical resources.
Have an account? Log In
Ekonomiavdelningar vill till exempel hålla kostnaderna så låga som möjligt, medan utvecklare vill hålla prestandan så hög som möjligt. Dessa två mål behöver inte överensstämma om inte riskerna har bedömts och teamen förstår varandras mål.
Medan dina utvecklare kanske väljer att lansera en ofullständig produkt och hantera det senare, leder kostnaden för denna påverkan till teknisk skuld. Genom att införa DevOps kan målen och strategierna för båda teamen samordnas, och du kan hjälpa dina utvecklare att förstå kostnadseffekten av deras tekniska beslut.
Detta är bara en liten del av DevOps och betydelsen av gemensamma mätvärden.
5 viktiga DevOps-mätvärden (DORA)
Att införa DevOps och förstå principbaserade ramverk är en sak, men det är med DevOps-mätvärden som du verkligen börjar se fördelarna med detta samarbetsinriktade angreppssätt på programvaruutvecklingens livscykel. Precis som med de flesta affärsstrategier finns det oändligt många mätvärden du kan välja att mäta för att främja tillväxt, beroende på din bransch, målgrupp och dina mål.
Google Clouds team för forskning och utvärdering av DevOps (DORA) är det längst verksamma forskarteamet av sitt slag. De identifierade ursprungligen fyra viktiga mätvärden för att mäta prestandan hos de ”elitteam” som arbetade med DevOps. Sedan dess har ett femte viktigt mätvärde lagts till, och deras klusteranalys identifierar endast tre nivåer av DevOps-team: hög, medel och låg, där ”elit” tillhör det förflutna.
1. Distribueringsfrekvens (DF)
DF mäter hur ofta du lyckas lansera till produktion. Detta mätvärde handlar om konsekvens och är en utmärkt indikator på måluppfyllelse.
Team i kategorin ”elit” skulle konsekvent distribuera till produktion flera gånger om dagen, medan team med låg prestanda skulle ligga närmare en gång var sjätte månad.
Att förbättra DF är så enkelt som att lansera flera mindre uppdateringar. Den främsta fördelen med detta är att synliggöra eventuella processhinder, flaskhalsar eller komplexa projekt som kräver uppmärksamhet. Större team kan föredra att distribuera med regelbundna intervall genom att bygga agila lanseringståg; detta bidrar till att minska överbelastningen som följer av ett extremt tempo och många involverade personer.
2. Ledtid för ändringar (LTC)
LTC avser den tid det tar för en ändring att nå produktion. Detta mätvärde är en bra indikator på teamets responsförmåga och smidighet, eftersom det mäter hur snabbt teamet kan agera på användarnas behov och önskemål.
Den tidigare ”elitstandarden” innebar ett mål på mindre än en dag för LTC, medan team med lägre prestanda kunde behöva mer än sex månader. Att prestera i den lägre delen av skalan för LTC beror sannolikt på ineffektiva processer.
Du kan förbättra detta mätvärde genom att förbättra automatiseringsprocesserna, särskilt testningen. Genom att förbättra din pipeline för kontinuerlig integrering och kontinuerlig leverans (CI/CD) kan du få ut uppdateringar i produktion snabbare. En risk att vara uppmärksam på här är dock hållbarheten. Om ditt team inte kan upprätthålla detta förbättrade tempo kan du drabbas av en dålig användarupplevelse och potentiella säkerhetssårbarheter.
3. Frekvens för misslyckade ändringar (CFR)
CFR är andelen driftsättningar som orsakar ett fel i produktionen. Felet kan bestå av driftstopp, återställningar eller försämrad tjänst. Det här mätvärdet visar hur effektivt ditt team är när ni driftsätter ändringar.
Riktvärdena för elitprestanda är 0–15 %, medan hög, medelhög och låg prestanda alla ligger inom intervallet 16–30 %.
Att förbättra CFR handlar om kvalitet snarare än kvantitet. Företag släpper varierande antal ändringar och har därför också varierande antal fel. Ändringar av högsta kvalitet leder dock till färre fel, oavsett om de driftsätter ändringar två gånger om året eller två gånger om dagen.
4. Genomsnittlig återställningstid (MTTR)
MTTR är den tid det tar för ditt team att återställa tjänsten efter ett fel eller en störning. Det här mätvärdet mäter inte bara teamets smidighet, utan är också ett bra mått på programvarans stabilitet.
Om du siktar på en ”elitnivå” behöver MTTR vara mindre än en timme. Team med låg prestanda kan behöva mer än sex månader.
Du kan förbättra MTTR genom att fokusera på mindre och snabba lanseringar, vilket gör det enklare att hitta och åtgärda fel. Du kan också utforska funktionsflaggor för att ge teamet mer kontroll – särskilt om de är experimentella.
Det finns ytterligare ett mätvärde att ta upp.
5. Tillförlitlighet
Det femte mätvärdet är tillförlitlighet. Det här mätvärdet upptäcktes senare av DORA-teamet (2021), eftersom man tidigare mätte tillgänglighet som ett riktvärde för tillförlitlig programvara. Man beslutade dock att tillförlitlighet bättre omfattar tillgänglighet, svarstid, prestanda och skalbarhet. Det innebär i praktiken att man mäter driftsättningsprestanda parallellt med utvecklingen.
Andra vanliga DevOps-mätvärden
Cykeltid
Cykeltid är den totala tiden från det att en uppgift påbörjas tills den levereras. På ytan mäter den teamets arbetstempo. Du kan dock undersöka mätvärdet djupare för att hitta flaskhalsar, till exempel långa köer och utdragna pullförfrågningar.
En kortare cykeltid visar på ett effektivt arbetsflöde, minskar flaskhalsar och ökar utvecklingshastigheten.
Så mäter du cykeltid
Cykeltid beräknas genom att tidsstämplar för incheckningar, kodsammanslagningar och driftsättningar följs i verktyg som GitHub, GitLab eller Jenkins.
Cykeltid = driftsättningstid – incheckningstid
För att förbättra cykeltiden bör team:
- Optimera CI/CD-pipelines för snabbare integrering och driftsättning.
- Automatisera byggen och tester.
- Förbättra samarbetet mellan utvecklings- och driftteamen.
- Minska beroenden mellan uppgifter för att minimera flaskhalsar.
Genomsnittlig upptäcktstid (MTTD)
Det här är den genomsnittliga tiden det tar för ditt team att uppmärksamma ett fel. Ett lågt MTTD visar på effektiva system för övervakning och aviseringar, vilket möjliggör snabb hantering och lösning av incidenter.
Så mäter du MTTD
MTTD kan mätas genom att följa den genomsnittliga tiden mellan det att ett problem uppstår och att det upptäcks av övervakningsverktyg eller rapporteras av användare. För att sänka MTTD behöver man förbättra automatiserad övervakning, förfina aviseringsmekanismer och säkerställa proaktiv upptäckt av problem.
Godkända automatiserade tester
Det är bra att sträva efter god testtäckning, särskilt automatiserade tester. Här syftar jag på enhets-, integrations-, användargränssnitts- och test från början till slut. God täckning räcker dock inte för att säkerställa programvarans kvalitet. Det viktiga är andelen av dessa tester som godkänns.
Målet är förstås att andelen godkända tester ska ligga så nära 100 % som möjligt. Genom att övervaka det här mätvärdet kan du också se hur ofta ny utveckling orsakar fel i befintliga tester.
Så mäter du andelen godkända automatiserade tester
Beräkningen är en enkel procentsats: multiplicera antalet godkända tester med 100 och dividera sedan med det totala antalet tester. Du kan hämta den här informationen från pipelineverktyget som kör byggena (Jenkins, Azure DevOps, CircleCI med flera).
Antalet kan vara en bra indikator på produktens kvalitet. Det kan dock också vara problematiskt om du har instabila eller opålitliga tester.
Andel defekter som släpps igenom
Andelen defekter som släpps igenom anger hur många buggar som missas under testningen och släpps till produktion – hur många som har ”sluppit igenom”. Detta mått är idealiskt för att följa upp om du vill förbättra testnings- och automatiseringsprocesserna.
I en utopisk värld skulle alla våra appar vara fria från defekter. Så är dock sällan fallet. Helst upptäcks defekter under utvecklings- och testfaserna i DevOps-processen, inte i produktion.
Detta mått hjälper till att fastställa effektiviteten i dina testprocesser och den övergripande kvaliteten på ditt program. En hög andel defekter som släpps igenom tyder på att processerna måste förbättras och att mer automatisering behövs, medan en låg andel (helst nära noll) indikerar en applikation av hög kvalitet.
Så mäter du andelen defekter som släpps igenom
För att mäta detta kan du använda ditt verktyg för buggspårning och för varje öppen defekt följa upp var den har upptäckts – i test- eller produktionsmiljön (eller någon annan miljö som du använder, till exempel UAT).
Kundärenden
Kundnöjdhet är en drivande faktor för innovation, och av goda skäl: en felfri användarupplevelse är god kundservice och motsvarar vanligtvis en ökning av försäljningen. Därför är kundärenden, särskilt under processen för eskalering av ärenden, en bra indikator på hur väl din DevOps-övergång fortskrider.
Kunder ska inte fungera som kvalitetskontroll genom att rapportera defekter och buggar. Därför är en minskning av antalet kundärenden ett gott tecken på god applikationsprestanda.
CPU- och minnesanvändning
Identifierar trender i resursanvändningen.
Svarstid
Mäter den tid det tar för applikationen att svara på förfrågningar.
Felfrekvens
Följer antalet misslyckade förfrågningar över tid.
Genomströmning
Mäter antalet förfrågningar som behandlas per sekund.
Fördröjning för API-förfrågningar
Mäter fördröjningen mellan att en förfrågan skickas och att ett svar tas emot.
Prestanda för databasfrågor
Följer tiderna för frågekörning och möjliga flaskhalsar.
Analys av användarbeteende
Övervakar trender i funktionsanvändning och engagemang.
Genomsnittlig tid mellan fel (MTBF)
MTBF mäter den genomsnittliga tiden mellan systemfel, driftstopp eller incidenter. Detta mått utvärderar dina programvarusystems tillförlitlighet och stabilitet och belyser effektiviteten i strategierna för förebyggande underhåll och felbegränsning.
Tid till begränsning (TTM)
Tiden det tar att åtgärda ett problem efter att det har upptäckts är TTM. Detta mått hjälper till att bedöma processerna för incidenthantering och lösning och visar hur effektiva dina team är när det gäller att hantera och återhämta sig från problem.
Ledtid för förändringar (CLT)
CLT utgör ett riktmärke för den fullständiga processen för implementering av förändringar, inklusive utveckling, testning, granskning och driftsättning. En kortare CLT innebär snabbare leveranscykler och ökad agilitet.
Så fastställer du KPI:er med DevOps-mått
Nu när du har en god förståelse för vilka mått du kan använda för att implementera och optimera DevOps i din verksamhet vill du utforska nyckeltal (KPI:er) för att fastställa mål och riktvärden för ditt team.
Mått jämfört med KPI:er
Du kanske undrar vad skillnaden mellan mått och KPI:er är. Ett mått är vad du mäter. Det är en kvantifierbar mätning som ger information om en specifik prestationsaspekt. Alla mått är inte nödvändigtvis kopplade till specifika mål eller riktvärden.
KPI:er är däremot en typ av mått som är strategiskt utvalda och definierade för att återspegla de mest kritiska aspekterna av prestation och framsteg mot strategiska mål. KPI:er är vanligtvis kopplade till målsättningar och har ofta tillhörande mål, tröskelvärden eller riktmärken som måste uppnås.
Fastställa KPI:er för ditt DevOps-team
Det första steget när du ska fastställa KPI:er för ditt DevOps-team är att koppla DevOps-mätvärden till företagets strategi och mål. Genom att prioritera de viktigaste mätvärdena att följa kan du börja fastställa mål och riktvärden för kontinuerliga förbättringar. När du väljer rätt mätvärden behöver du ta hänsyn till företagets storlek, produkt och marknad. Fokusera på det som ger de mest användbara insikterna och undvik den vanliga fallgropen med ett överflöd av mätvärden.
Att övervaka dina KPI:er är lika viktigt som att fastställa dem. Utforska verktyg för datavisualisering som ger teamet realtidsdata på intuitiva instrumentpaneler. Detta säkerställer full insyn, skapar ansvar och gör det möjligt för alla att arbeta tillsammans mot gemensamma mål. Därmed anpassas utvecklings- och driftteamen samtidigt som införandet och mognaden av DevOps stöds.
Om vi utgår från DORA:s centrala mätvärden kan vi se riktvärdena för varje mätvärde baserat på team med elit-, hög, medelhög och låg prestation. Den här tabellen kan hjälpa dig att fastställa KPI:er för ditt eget företag, beroende på vad du definierar som prioriterat.
När du fastställer dina KPI:er är det bäst att noggrant ta hänsyn till ditt team och din verksamhet utan att jämföra dem med andra företag. Om vi tar CFR som exempel är riktvärdet detsamma för hög, medelhög och låg prestation. Detta beror i hög grad på din driftsättningsfrekvens, men kan också påverka den åt andra hållet. Om ditt team ägnar all sin tid åt att åtgärda fel får de mindre tid över till att utveckla och släppa uppdateringar. KPI:er kan också förändras när ditt DevOps-team mognar. Vattentäta processer för automatisering och testning bör automatiskt innebära att du kan höja ribban för dina mål.
Så använder du DevOps-mätvärden för att skala upp
Eftersom den globala DevOps-marknaden förväntas nå 24.71 miljarder dollar senast 2027 (en sammansatt årlig tillväxttakt på 22.9 %, baserat på en marknadsstorlek på 10.84 miljarder dollar 2023) kan du se detta som ett tecken om du letar efter rätt tidpunkt att börja införa DevOps i din verksamhet.
DevOps påskyndar inte bara utvecklingen och minskar tiden till marknadslansering, utan förbättrar också samarbetet genom att avskaffa stuprör, höjer kvaliteten genom kontinuerlig testning och återkopplingsloopar samt använder resurser effektivt, vilket sparar pengar. Slutligen är DevOps lätt att skala upp och stöder företagstillväxt till nya nivåer. År 2021 fick 83 % av IT-beslutsfattarna ett högre affärsvärde genom att införa DevOps.
Prestationsmätning och kontinuerliga förbättringar
Övervakning av prestanda är nyckeln till att skala upp en verksamhet som använder DevOps. Det är ett snabbfotat arbetssätt med ett kontinuerligt produktionsflöde, så mätning och rapportering bör ske lika ofta. DevOps-mätvärden gör det möjligt att följa prestandan i utvecklings- och leveransprocesserna. Genom att kvantifiera viktiga aspekter som driftsättningsfrekvens, ledtid och ändringsfelfrekvens kan du identifiera flaskhalsar, ineffektivitet och förbättringsområden. Detta gör det möjligt att ofta optimera arbetsflöden och processer.
Genom att följa mätvärden som ändringsfelfrekvens och genomsnittlig återställningstid kan du identifiera trender som gör det möjligt att upptäcka problem tidigt. Detta proaktiva arbetssätt innebär att du kan vidta korrigerande åtgärder och minimera påverkan på kunderna, vilket skapar tillförlitlighet – ännu en viktig faktor för att skala upp med bibehållen hög kvalitet.
Slutligen hjälper användningen av DevOps-mätvärden ditt DevOps-team att mogna genom att främja en kultur av kontinuerliga förbättringar. Återkopplingsloopar främjar lärande och utveckling; det måste alltid finnas utrymme för att experimentera med olika metoder.
Vilka DevOps-mätvärden stöder företagstillväxt?
När du fastställer KPI:er bör de flesta mätvärden bedömas inom ditt team och användas för att stödja tillväxt, snarare än att jämföras med andra företag och grupper på olika mognadsnivåer.
En låg LTC kan till exempel visa att ditt team är effektivt, men om de inte kan upprätthålla takten är den inte hållbar och kan så småningom påverka användarupplevelsen. Detta mätvärde bör följas över tid i stället för att fastställa en KPI som motsvarar ett högpresterande eller till och med elitmässigt, moget DevOps-team. Att fastställa KPI:er för att minska LTC månad för månad, kvartal för kvartal eller år för år visar på tillväxt inom ditt team och din verksamhet.
CFR är ett värdefullt mått eftersom alla inte har samma antal fel eller problem, men genom att uttrycka detta i procent kan du mäta hur framgångsrika dina driftsättningar är. Ditt team kan ha mycket få fel om ni släpper ändringar sällan, men om varje driftsättning orsakar ett problem kommer CFR att vara mycket hög. Om du följer CI/CD-metoder kan du se ett högre antal fel, men om din CFR är låg har du en fördel eftersom du har snabbhet och kvalitet som stödjer tillväxt. MTTR bör också mätas över tid för att säkerställa en stabil utveckling.
DORA fann att team på alla nivåer av utvecklingsprestanda fick bättre resultat när de fokuserade på operativ prestanda. Det kan innebära att fastställa KPI:er för incidentrapporter eller öppna ärenden, applikationens drifttid och tillgänglighet.
Ett stort antal öppna ärenden kan tyda på ett problem med kundnöjdheten, men att sträva efter en minskning över tid visar på tillväxt inom detta område. Du kan gå djupare och mäta svarstider och kötider för att påskynda förbättringen av detta mått.
Det enda måttet som helt kombinerar utveckling och drift i ett DevOps-team är cykeltiden. Detta skapar utrymme för att bygga en kultur av återkoppling och tillväxt. När andra mått förbättras och automatiseringen mognar bör du förvänta dig att cykeltiden minskar. Om din kundservice håller hög kvalitet och utvecklingsfelen är få har du hittat en vinnande kombination för att skala upp verksamheten.
Avslutande tankar
Precis som alla andra metoder är DevOps endast framgångsrikt om det implementeras korrekt. Och du kan inte känna till resultatet förrän du vet hur du använder DevOps-mått.
Självklart innebär implementering av DevOps-mått sina utmaningar. Det kräver ett strategiskt tankesätt, en samarbetskultur och ett åtagande om kontinuerlig förbättring. Resultatet blir dock optimerade arbetsflöden och processer som du kan bygga en stabil grund för att skala upp verksamheten på.
Om du vill hålla dig uppdaterad med nyheter och artiklar, prenumerera på vårt nyhetsbrev!
