For at være ærlig lo Ivan ofte af den forgæves indsats fra sine kolleger fra overvågningsafdelingen. De gjorde en stor indsats for at implementere de målinger, som virksomhedens ledelse beordrede dem til at opnå. De havde så travlt, at de ikke ønskede, at andre skulle gøre noget.
Men det var ikke nok for ledelsen - de bestilte konstant flere og flere nye målinger og holdt meget hurtigt op med at bruge det, der var blevet gjort tidligere.
På det seneste har alle talt om LeadTime - tiden for levering af forretningsfunktioner. Metrikken viste et vanvittigt tal - 200 dage til at levere én opgave. Hvor alle sukkede og aaede og løftede deres hænder mod himlen!
Efter nogen tid forsvandt støjen gradvist, og ledelsen modtog en ordre om at oprette en anden metrik.
Det var fuldstændig klart for Ivan, at den nye metrik lige så stille ville dø i et mørkt hjørne.
Faktisk, tænkte Ivan, idet han ved, at nummeret ikke fortæller nogen noget overhovedet. 200 dage eller 2 dage - der er ingen forskel, fordi det er umuligt at bestemme årsagen ved tallet og forstå, om den er god eller dårlig.
Dette er en typisk fælde af metrik: det ser ud til, at en ny metrik vil fortælle essensen af eksistens og forklare en eller anden hemmelig hemmelighed. Alle håber så meget på dette, men af en eller anden grund sker der ikke noget. Ja, for hemmeligheden skal ikke findes i metrics!
For Ivan var dette et bestået stadium. Det forstod han til målinger, og alle hemmelighederne skal søges ind , dvs. er, at denne metrik er dannet.
For en onlinebutik vil genstanden for indflydelse være dens kunder, der bringer penge ind, og for DevOps vil det være de hold, der skaber og udruller distributioner ved hjælp af en pipeline.
En dag, da han satte sig ned i en behagelig stol i hallen, besluttede Ivan omhyggeligt at tænke igennem, hvordan han ønskede at se DevOps-målinger, idet han tog højde for, at objektet for indflydelse er teams.
Formål med DevOps Metrics
Det er klart, at alle ønsker at reducere leveringstiden. 200 dage er selvfølgelig ikke godt.
Men hvordan, det er spørgsmålet?
Virksomheden beskæftiger hundredvis af teams, og tusindvis af distributioner går gennem DevOps-pipelinen hver dag. Den faktiske leveringstid vil fremgå som en fordeling. Hvert hold vil have sin egen tid og sine egne karakteristika. Hvordan kan du finde noget i dette rod?
Svaret opstod naturligt - vi skal finde problemholdene og finde ud af, hvad der sker med dem, og hvorfor det tager så lang tid, og lære af de "gode" teams, hvordan man gør alting hurtigt. Og for at gøre dette skal du måle den tid, holdene bruger på hver af DevOps-standene:
”Formålet med systemet vil være at udvælge hold ud fra den tid, de passerer tribunerne, dvs. Som et resultat bør vi få en liste over kommandoer med den valgte tid og ikke et tal.
Hvis vi finder ud af, hvor meget tid der blev brugt på standen i alt, og hvor meget tid der blev brugt på nedetid mellem standene, kan vi finde holdene, ringe til dem og forstå årsagerne mere detaljeret og eliminere dem,” tænkte Ivan.
Sådan beregnes leveringstid for DevOps
For at beregne det var det nødvendigt at dykke ned i DevOps-processen og dens essens.
Virksomheden anvender et begrænset antal systemer, og information kan kun hentes fra dem og ingen andre steder.
Alle opgaver i virksomheden var registreret i Jira. Når en opgave blev påtaget, blev der oprettet en filial til den, og efter implementering blev der foretaget en commit til BitBucket og Pull Request. Når en PR (Pull Request) blev accepteret, blev en distribution automatisk oprettet og gemt i Nexus-lageret.
Dernæst blev distributionen rullet ud på flere stande ved hjælp af Jenkins til at kontrollere rigtigheden af udrulningen, automatisk og manuel test:
Ivan beskrev fra hvilke systemer, hvilke oplysninger der kan tages for at beregne tiden på tribunerne:
- Fra Nexus – distributionstidspunkt og navnet på den mappe, der indeholdt kommandokoden
- Fra Jenkins – Starttidspunkt, varighed og resultat af hvert job, standnavn (i jobparametrene), stadier (jobtrin), link til distributionen i Nexus.
- Ivan besluttede ikke at inkludere Jira og BitBucket i pipelinen, fordi... de var mere relateret til udviklingsstadiet, og ikke til udrulning af den færdige distribution på stande.
På baggrund af de tilgængelige oplysninger blev følgende diagram tegnet:
Når du ved, hvor lang tid det tager at oprette distributioner, og hvor meget tid der bruges på hver af dem, kan du nemt beregne de samlede omkostninger ved at gennemgå hele DevOps-pipelinen (fuld cyklus).
Her er DevOps-metrics Ivan endte med:
- Antal oprettede distributioner
- Andel af uddelinger, der "kom" til standen og "passerede" standen
- Tid brugt på stativet (standcyklus)
- Fuld cyklus (samlet tid for alle stande)
- Jobvarighed
- Nedetid mellem standene
- Nedetid mellem joblanceringer på samme stand
På den ene side karakteriserede metrikken DevOps-pipelinen meget godt med hensyn til tid, på den anden side blev de betragtet som meget simple.
Tilfreds med det veludførte arbejde lavede Ivan en præsentation og gik for at præsentere den for ledelsen.
Han kom dyster tilbage og med hænderne nede.
"Dette er en fiasko, bro," smilede den ironiske kollega ...
Læs mere i artiklen "'.
Kilde: www.habr.com