Hvordan Ivan lavede DevOps-målinger. Genstand for indflydelse

Der er gået en uge, siden Ivan først tænkte på DevOps-målinger og indså, at det med deres hjælp er nødvendigt at administrere produktleveringstiden (Time-To-Market).

Selv i weekenden tænkte han på metrics: "Så hvad nu hvis jeg måler tid? Hvad vil det give mig?

Ja, hvad vil viden om tid give? Lad os sige, at leveringen tager 5 dage. Så hvad er det næste? Er det godt eller dårligt? Selvom dette er dårligt, så skal du på en eller anden måde reducere denne tid. Men hvordan?
Disse tanker hjemsøgte ham, men der kom ingen løsning.

Ivan forstod, at han var kommet til selve essensen. De utallige grafer af metrikker, han havde set før, havde for længe siden overbevist ham om, at standardmetoden ikke ville fungere, og at hvis han blot plottede (også selvom det er en kohorte), vil det ikke nytte noget.

Hvordan skal man være?…

En metrik er som en almindelig trælineal. Målinger foretaget med dens hjælp vil ikke fortælle årsagen, hvorfor objektet, der måles, er præcis den længde, hun viste. Linealen vil blot vise dens størrelse, og intet mere. Hun er ikke de vises sten, men blot en træplade, som man kan måle med.

Hans yndlingsforfatter Harry Harrisons "rustfri stålrotte" sagde altid: en tanke skal nå bunden af ​​hjernen og ligge der, så efter at have lidt i flere dage uden resultat, besluttede Ivan at påtage sig en anden opgave...

Et par dage senere, mens Ivan læste en artikel om onlinebutikker, indså Ivan pludselig, at mængden af ​​penge, en onlinebutik modtager, afhænger af, hvordan de besøgende opfører sig. Det er dem, besøgende/kunder, der giver butikken deres penge og er dens kilde. Bundlinjen af ​​kontanter en butik modtager er påvirket af ændringer i kundeadfærd, ikke noget andet.

Det viste sig, at for at ændre den målte værdi var det nødvendigt at påvirke dem, der danner denne værdi, dvs. for at ændre pengebeløbet i en netbutik, var det nødvendigt at påvirke adfærden hos kunderne i denne butik, og for at ændre leveringstiden i DevOps var det nødvendigt at påvirke de teams, der “skaber” denne gang, dvs. bruge DevOps i deres arbejde.

Ivan indså, at DevOps-metrikker slet ikke burde repræsenteres af grafer. De skal repræsentere sig selv søgeværktøj "fremragende" hold, der former den endelige leveringstid.

Ingen metrik vil nogensinde vise årsagen til, at det eller det hold tog lang tid om at levere en distribution, mente Ivan, for i virkeligheden kunne der være en million og en lille vogn, og de kan godt være ikke tekniske, men organisatoriske. De der. det meste, du kan forvente at få ud af metrics, er at vise hold og deres resultater, og så skal du stadig følge disse hold med fødderne og finde ud af, hvad der er galt med dem.

På den anden side havde Ivans firma en standard, der krævede, at alle teams testede samlinger på flere bænke. Holdet kunne ikke flytte til næste standplads, før den forrige var afsluttet. Det viste sig, at hvis vi forestiller os DevOps-processen som en sekvens af passage gennem stande, så kunne metrikken vise den tid, holdene brugte på disse stande. Ved at kende holdets stand og tid, var det muligt at tale mere specifikt med dem om årsagerne.

Uden tøven tog Ivan telefonen og ringede til nummeret på en person, der er velbevandret i DevOps:

— Denis, fortæl mig venligst, er det muligt på en eller anden måde at forstå, at holdet har bestået denne eller hin stand?
- Sikkert. Vores Jenkins kasserer flaget, hvis bygningen er blevet rullet ud (bestået testen) på bænken.
- Super. Hvad er et flag?
- Dette er en almindelig tekstfil som "stand_OK" eller "stand_FAIL", som siger, at forsamlingen bestod eller ikke bestod testen. Nå, du forstår, ikke?
- Jeg tror, ​​ja. Er det skrevet til den samme mappe i depotet, hvor samlingen er placeret?
- Ja
— Hvad sker der, hvis forsamlingen ikke består prøvebænken? Skal jeg lave en ny konstruktion?
- Ja
- Nå, ok, tak. Og et andet spørgsmål: forstår jeg rigtigt, at jeg kan bruge datoen for oprettelsen af ​​flaget som datoen for standen?
- Absolut!
- Super!

Inspireret lagde Ivan på og indså, at alt var faldet på plads. Ved at kende datoen for oprettelse af build-filen og datoen for oprettelse af flagene, var det muligt at beregne ned til sekundet, hvor meget tid holdene bruger på hver stand og forstå, hvor de bruger mest tid.

"Ved at forstå, hvor der bruges mest tid, vil vi udpege hold, gå til dem og grave i problemet." Ivan smilede.

Til i morgen satte han sig til opgave at skitsere arkitekturen i det system, der tegnes.

Fortsættes ...

Kilde: www.habr.com

Tilføj en kommentar