🥇DevOps-metriker – var får man datan för beräkningarna

Ärligt talat skrattade Ivan ofta åt sina kollegers meningslösa ansträngningar i övervakningsavdelningen. De gjorde enorma insatser för att genomföra de mätetal som företagsledningen beställde. De var så upptagna att de inte ville göra någonting mer för någon annan.

Men ledningen var alltid missnöjd – de beställde ständigt nya och nya mätetal, och slutade snabbt att använda de som redan hade gjorts.

På senare tid pratade alla bara om LeadTime – tiden för att leverera affärsfunktioner. Mätetalet visade ett galet nummer – 200 dagar för att leverera en uppgift. Hur alla gnodde, klagade och lyfte händerna mot himlen!

Efter ett tag tystnade oljudet och ledningen kom med en beställning på att skapa ytterligare ett mätetal.

Det var helt klart för Ivan att det nya mätetalet också skulle dö stillsamt i ett mörkt hörn.

Verkligen, funderade Ivan, att känna till siffran säger ingenting för någon. 200 dagar eller 2 dagar – det spelar ingen roll, eftersom man inte kan avgöra orsaken och förstå om det är bra eller dåligt baserat på siffran.

Det är den typiska fällan med mätetal: det verkar som om det nya mätetalet kommer att förklara livets essens och avslöja en hemlighet. Alla har så stora förhoppningar, men ingenting händer av någon anledning. För hemligheten finns inte i mätetalen!

För Ivan var detta ett förflutet stadium. Han förstod att mätetal bara är en vanlig trälinjal för mätningar, medan alla hemligheter måste sökas i påverkanens objekt, dvs. det som formar detta mätetal.

För en webbshop kommer påverkanens objekt att vara dess kunder som genererar intäkter, medan för DevOps kommer det att vara teamen som skapar och distribuerar distributioner med hjälp av en pipeline.

En gång, när han satte sig i en bekväm stol i lobbyn, bestämde Ivan sig för att noggrant tänka på hur han skulle vilja se DevOps-mätetalen med tanke på att påverkanens objekt är teamen.

Syftet med DevOps-mätetal

Det är uppenbart att alla vill minska leveranstiden. 200 dagar – det går förstås inte.

Men hur? Det är frågan.

Det arbetar hundratals team i företaget, och tusentals distributioner passerar genom DevOps-pipelinen varje dag. Den verkliga leveranstiden kommer att se ut som en fördelning. Varje team kommer att ha sin egen tid och sina egna karakteristika. Hur kan man hitta något i detta kaos?

Svaret kom av sig själv – vi måste hitta problematiska team och förstå vad som händer med dem och varför det tar så lång tid, och lära oss av de "bra" teamen hur man gör allt snabbt. För detta krävs det att vi mäter tiden som teamen tillbringar på varje DevOps-ställ.

Målet för systemet kommer att vara att välja team baserat på tiden de tar att genomgå ställena, d.v.s. vi ska i slutändan få en lista över team med valda tider istället för siffror.

Om vi får reda på hur mycket tid som totalt har spenderats på varje ställ och hur mycket tid som har gått till spillo mellan ställen, kan vi hitta teamen, kontakta dem och undersöka orsakerna mer ingående för att åtgärda dem,” tänkte Ivan.

Hur man beräknar ledtider för DevOps

För att göra beräkningarna behövde vi fördjupa oss i DevOps-processen och dess kärna.

Företaget använder ett begränsat antal system, och informationen kan endast erhållas från dem och ingen annanstans.

Alla uppgifter i företaget registrerades i Jira. När en uppgift togs i arbete skapades en branch för den, och efter genomförandet gjordes en commit i BitBucket och en Pull Request. Vid godkännande av PR (Pull Request) skapades automatiskt en distribution och sparades i Nexus-lagringen.

Därefter rullades distributionen ut på flera ställen med hjälp av Jenkins för att kontrollera korrektheten av installationen, inklusive automatiserade och manuella tester:

Ivan listade vilka system som kan ge vilken information för att beräkna tiden på ställena:

Från Nexus – Tiden för distributionsskapande och namnet på mappen där teamets kod låg.
Från Jenkins – Starttid, varaktighet och resultat av varje jobb, namnet på stället (i jobbets parametrar), stages (steg i jobbet), länk till distributionen i Nexus.
Ivan beslutade att utesluta Jira och BitBucket från flödet, eftersom de relaterade mer till utvecklingssteget och inte till distributionen av den färdiga kandidaten på ställena.

Baserat på tillgänglig information ritades följande schema:

Genom att veta hur mycket tid som går åt till att skapa distributioner och hur mycket som spenderas på var och en av dem kan man enkelt beräkna de totala kostnaderna för att genomföra hela DevOps-flödet (det fullständiga cykeln).