För att vara ärlig, skrattade Ivan ofta åt de meningslösa ansträngningarna från sina kollegor från övervakningsavdelningen. De gjorde stora ansträngningar för att implementera de mått som företagets ledning beordrade dem att uppnå. De var så upptagna att de inte ville att någon annan skulle göra något.
Men det räckte inte för ledningen - de beställde hela tiden fler och fler nya mätvärden och slutade mycket snabbt att använda det som hade gjorts tidigare.
På sistone har alla pratat om LeadTime – tiden för leverans av affärsfunktioner. Mätvärdet visade ett galet antal - 200 dagar att leverera en uppgift. Hur alla tjatade och höjde händerna mot himlen!
Efter en tid tystnade bruset gradvis och ledningen fick en order om att skapa ytterligare ett mått.
Det stod helt klart för Ivan att den nya metriken lika tyst skulle dö i ett mörkt hörn.
Faktum är att, tänkte Ivan, att veta att numret inte säger någonting alls. 200 dagar eller 2 dagar - det är ingen skillnad, eftersom det är omöjligt att bestämma orsaken med antalet och förstå om det är bra eller dåligt.
Detta är en typisk fälla av mått: det verkar som att en ny mått kommer att berätta essensen av tillvaron och förklara någon hemlig hemlighet. Alla hoppas så mycket på detta, men av någon anledning händer ingenting. Ja, för hemligheten ska inte finnas i mått!
För Ivan var detta ett passerat skede. Han förstod det för mätningar, och alla hemligheter måste sökas in , dvs. är att detta mått bildas.
För en onlinebutik kommer föremålet för påverkan att vara dess kunder som tar in pengar, och för DevOps kommer det att vara teamen som skapar och rullar ut distributioner med hjälp av en pipeline.
En dag, när han satte sig i en bekväm stol i hallen, bestämde sig Ivan för att noggrant tänka igenom hur han ville se DevOps-mått, med hänsyn till det faktum att föremålet för inflytande är team.
Syftet med DevOps Metrics
Det är klart att alla vill minska leveranstiden. 200 dagar är naturligtvis inte bra.
Men hur, det är frågan?
Företaget sysselsätter hundratals team och tusentals distributioner går igenom DevOps pipeline varje dag. Den faktiska leveranstiden kommer att visas som en distribution. Varje lag kommer att ha sin egen tid och sina egna egenskaper. Hur kan du hitta något i den här röran?
Svaret uppstod naturligt - vi måste hitta problemteamen och ta reda på 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. Och för att göra detta måste du mäta tiden som team spenderar på var och en av DevOps-montrarna:
”Syftet med systemet kommer att vara att välja ut lag utifrån den tid de passerar läktaren, d.v.s. Som ett resultat bör vi få en lista med kommandon med den valda tiden, och inte ett nummer.
Om vi tar reda på hur mycket tid som spenderades på läktaren totalt och hur mycket tid som ägnades åt stillestånd mellan läktarna kan vi hitta lagen, ringa dem och förstå orsakerna mer i detalj och eliminera dem”, tänkte Ivan.
Hur man beräknar leveranstid för DevOps
För att beräkna det var det nödvändigt att fördjupa sig i DevOps-processen och dess väsen.
Företaget använder ett begränsat antal system, och information kan endast erhållas från dem och ingen annanstans.
Alla uppgifter i företaget var registrerade i Jira. När en uppgift togs på skapades en filial för den, och efter implementering gjordes en commit till BitBucket och Pull Request. När en PR (Pull Request) accepterades skapades en distribution automatiskt och lagrades i Nexus-förvaret.
Därefter rullades distributionen ut på flera montrar med Jenkins för att kontrollera riktigheten av utrullningen, automatisk och manuell testning:
Ivan beskrev från vilka system vilken information som kan tas för att beräkna tiden på läktaren:
- Från Nexus – distributionstidpunkt och namn på mappen som innehöll kommandokoden
- Från Jenkins – Starttid, varaktighet och resultat för varje jobb, monternamn (i jobbparametrarna), stadier (jobbsteg), länk till distributionen i Nexus.
- Ivan bestämde sig för att inte inkludera Jira och BitBucket i pipelinen, eftersom... de var mer relaterade till utvecklingsstadiet, och inte till att rulla ut den färdiga distributionen på montrar.
Baserat på tillgänglig information ritades följande diagram:
Genom att veta hur lång tid det tar att skapa distributioner och hur mycket tid som läggs på var och en av dem kan du enkelt beräkna de totala kostnaderna för att gå igenom hela DevOps pipeline (full cykel).
Här är DevOps-måtten Ivan slutade med:
- Antal skapade distributioner
- Andel av utdelningar som "kom" till montern och "passerade" montern
- Tid tillbringad på stativet (ställningscykel)
- Full cykel (total tid för alla läktare)
- Jobbets varaktighet
- Driftstopp mellan läktarna
- Driftstopp mellan jobblanseringar i samma monter
Å ena sidan kännetecknade måtten DevOps pipeline mycket väl tidsmässigt, å andra sidan ansågs de vara väldigt enkla.
Nöjd med det väl utförda jobbet gjorde Ivan en presentation och gick för att presentera den för ledningen.
Han kom tillbaka dyster och med händerna nere.
"Det här är ett fiasko, bro," log den ironiska kollegan...
Läs mer i artikeln "".
Källa: will.com