For å være ærlig lo Ivan ofte av den fåfengte innsatsen til kollegene fra overvåkingsavdelingen. De gjorde store anstrengelser for å implementere målene som selskapets ledelse beordret dem til å oppnå. De var så travle at de ikke ville at noen andre skulle gjøre noe.
Men det var ikke nok for ledelsen - de bestilte stadig flere og flere nye beregninger, og sluttet veldig raskt å bruke det som hadde blitt gjort tidligere.
I det siste har alle snakket om LeadTime – tiden for levering av forretningsfunksjoner. Beregningen viste et vanvittig tall – 200 dager på å levere én oppgave. Hvordan alle suste og aa og løftet hendene mot himmelen!
Etter en tid stilnet støyen gradvis og ledelsen fikk en ordre om å lage en annen beregning.
Det var helt klart for Ivan at den nye metrikken like stille ville dø i et mørkt hjørne.
Faktisk, tenkte Ivan, å vite at nummeret ikke forteller noen noe i det hele tatt. 200 dager eller 2 dager - det er ingen forskjell, fordi det er umulig å bestemme årsaken med antallet og forstå om det er bra eller dårlig.
Dette er en typisk felle av metrikk: det ser ut til at en ny metrikk vil fortelle essensen av eksistens og forklare en hemmelig hemmelighet. Alle håper så mye på dette, men av en eller annen grunn skjer det ingenting. Ja, for hemmeligheten skal ikke finnes i beregninger!
For Ivan var dette et bestått stadium. Han forsto det for målinger, og alle hemmelighetene må søkes inn , dvs. er at denne metrikken er dannet.
For en nettbutikk vil objektet for innflytelse være kundene som henter inn penger, og for DevOps vil det være teamene som lager og ruller ut distribusjoner ved hjelp av en pipeline.
En dag, mens han satte seg ned i en komfortabel stol i hallen, bestemte Ivan seg for å tenke nøye gjennom hvordan han ønsket å se DevOps-målinger, med tanke på det faktum at gjenstanden for innflytelse er team.
Formål med DevOps Metrics
Det er tydelig at alle ønsker å redusere leveringstiden. 200 dager er selvfølgelig ikke bra.
Men hvordan, det er spørsmålet?
Selskapet sysselsetter hundrevis av team, og tusenvis av distribusjoner går gjennom DevOps-pipelinen hver dag. Den faktiske leveringstiden vil vises som en fordeling. Hvert lag vil ha sin egen tid og sine egne egenskaper. Hvordan kan du finne noe blant dette rotet?
Svaret kom naturlig - vi må finne problemteamene og finne ut hva som skjer med dem og hvorfor det tar så lang tid, og lære av de "gode" teamene hvordan vi gjør alt raskt. Og for å gjøre dette, må du måle tiden som brukes av team på hver av DevOps-standene:
«Hensikten med systemet vil være å velge lag basert på tiden de passerer tribunen, dvs. Som et resultat bør vi få en liste over kommandoer med valgt tid, og ikke et tall.
Hvis vi finner ut hvor mye tid som ble brukt på standplass totalt og hvor mye tid som ble brukt på nedetid mellom stands, kan vi finne lagene, ringe dem og forstå årsakene mer detaljert og eliminere dem», tenkte Ivan.
Slik beregner du leveringstid for DevOps
For å beregne det var det nødvendig å fordype seg i DevOps-prosessen og dens essens.
Selskapet bruker et begrenset antall systemer, og informasjon kan kun hentes fra dem og ingen andre steder.
Alle oppgaver i selskapet ble registrert i Jira. Når en oppgave ble tatt på, ble det opprettet en gren for den, og etter implementering ble det foretatt en forpliktelse til BitBucket og Pull Request. Når en PR (Pull Request) ble akseptert, ble en distribusjon automatisk opprettet og lagret i Nexus-depotet.
Deretter ble distribusjonen rullet ut på flere stands ved å bruke Jenkins for å sjekke riktigheten av utrullingen, automatisk og manuell testing:
Ivan beskrev fra hvilke systemer hvilken informasjon som kan tas for å beregne tiden på tribunen:
- Fra Nexus – Tidspunkt for oppretting av distribusjon og navnet på mappen som inneholdt kommandokoden
- Fra Jenkins – Starttid, varighet og resultat for hver jobb, standnavn (i jobbparametrene), stadier (jobbtrinn), lenke til distribusjonen i Nexus.
- Ivan bestemte seg for ikke å inkludere Jira og BitBucket i pipelinen, fordi... de var mer knyttet til utviklingsstadiet, og ikke til utrulling av ferdig distribusjon på stands.
Basert på den tilgjengelige informasjonen ble følgende diagram tegnet:
Når du vet hvor lang tid det tar å lage distribusjoner og hvor mye tid som brukes på hver av dem, kan du enkelt beregne de totale kostnadene ved å gå gjennom hele DevOps-pipelinen (full syklus).
Her er DevOps-beregningene Ivan endte opp med:
- Antall opprettede distribusjoner
- Andel av utdelinger som "kom" til standen og "passerte" standen
- Tid brukt på stativet (standsyklus)
- Full syklus (total tid for alle stands)
- Jobbens varighet
- Nedetid mellom stands
- Nedetid mellom jobblanseringer på samme stand
På den ene siden karakteriserte beregningene DevOps-pipelinen veldig godt med tanke på tid, på den andre siden ble de ansett som veldig enkle.
Fornøyd med den vel utførte jobben holdt Ivan en presentasjon og gikk for å presentere den for ledelsen.
Han kom tilbake dyster og med hendene nede.
"Dette er en fiasko, bro," smilte den ironiske kollegaen ...
Les mer i artikkelen "'.
Kilde: www.habr.com