(Time-To-Market).
Selv i helgene tenkte han på beregninger: «Så hva om jeg måler tid? Hva vil det gi meg?
Ja, hva vil kunnskap om tid gi? La oss si at leveringen tar 5 dager. Så, hva er neste? Er det bra eller dårlig? Selv om dette er dårlig, må du på en eller annen måte redusere denne tiden. Men hvordan?
Disse tankene hjemsøkte ham, men ingen løsning kom.
Ivan forsto at han hadde kommet til selve essensen. De utallige grafene med beregninger han hadde sett før hadde for lenge siden overbevist ham om at standardtilnærmingen ikke ville fungere, og at hvis han bare plottet (), vil det ikke være til nytte.
Hvordan være?…
En metrikk er som en vanlig trelinjal. Målinger gjort med dens hjelp vil ikke fortelle årsaken, Hvorfor objektet som måles er nøyaktig den lengden hun viste. Linjalen vil ganske enkelt vise størrelsen, og ingenting mer. Hun er ikke de vises stein, men rett og slett en treplate å måle med.
«Ratten i rustfritt stål» til favorittforfatteren hans Harry Harrison sa alltid: en tanke må nå bunnen av hjernen og ligge der, så etter å ha lidd i flere dager til ingen nytte, bestemte Ivan seg for å ta en annen oppgave ...
Et par dager senere, mens han leste en artikkel om nettbutikker, innså Ivan plutselig at hvor mye penger en nettbutikk mottar avhenger av hvordan besøkende på nettstedet oppfører seg. Det er de, besøkende/kunder, som gir butikken pengene sine og er dens kilde. Bunnlinjen med kontanter en butikk mottar er påvirket av endringer i kundeadferd, ikke noe annet.
Det viste seg at for å endre den målte verdien var det nødvendig å påvirke de som danner denne verdien, dvs. for å endre pengebeløpet til en nettbutikk var det nødvendig å påvirke atferden til kundene til denne butikken, og for å endre leveringstiden i DevOps var det nødvendig å påvirke lagene som «skaper» denne gangen, dvs. bruke DevOps i arbeidet sitt.
Ivan innså at DevOps-beregninger ikke skulle representeres av grafer i det hele tatt. De må representere seg selv søkeverktøy "enestående" lag som former den endelige leveringstiden.
Ingen metrikk vil noen gang vise årsaken til at dette eller det laget brukte lang tid på å levere en distribusjon, mente Ivan, for i virkeligheten kan det være en million og en liten vogn, og de kan godt være ikke tekniske, men organisatoriske. De. det meste du kan forvente å få ut av beregninger er å vise team og deres resultater, og da må du fortsatt følge disse lagene med føttene og finne ut hva som er galt med dem.
På den annen side hadde Ivans selskap en standard som krevde at alle lag testet sammenstillinger på flere benker. Laget kunne ikke flytte til neste stand før den forrige var fullført. Det viste seg at hvis vi forestiller oss DevOps-prosessen som en sekvens av å passere gjennom tribuner, så kan beregningene vise tiden teamene bruker på disse tribunene. Ved å kjenne til lagets stand og tid, var det mulig å snakke mer spesifikt med dem om årsakene.
Uten å nøle tok Ivan opp telefonen og slo nummeret til en person som er godt kjent med DevOps:
— Denis, vær så snill, fortell meg, er det mulig på en eller annen måte å forstå at laget har passert denne eller den standen?
- Absolutt. Vår Jenkins forkaster flagget hvis bygget har rullet ut (bestått testen) på benken.
- Supert. Hva er et flagg?
- Dette er en vanlig tekstfil som "stand_OK" eller "stand_FAIL", som sier at forsamlingen bestod eller sviktet standen. Vel, du forstår, ikke sant?
- Ja jeg tror det. Er det skrevet til samme mappe i depotet der sammenstillingen er plassert?
- Ja
— Hva skjer hvis forsamlingen ikke består prøvebenken? Må jeg bygge nytt?
- Ja
- Vel, ok, takk. Og et annet spørsmål: forstår jeg riktig at jeg kan bruke datoen for opprettelsen av flagget som dato for standen?
- Absolutt!
- Super!
Inspirert la Ivan på røret og innså at alt hadde falt på plass. Ved å vite datoen for opprettelse av byggefilen og datoen for opprettelse av flaggene, var det mulig å beregne ned til sekundet hvor mye tid lagene bruker på hver stand og forstå hvor de bruker mest tid.
"For å forstå hvor mest tid brukes, vil vi finne team, gå til dem og grave i problemet." Ivan smilte.
For i morgen satte han seg i oppgave å skissere arkitekturen til systemet som tegnes.
To be continued ...
Kilde: www.habr.com