Hur Ivan arbetade med DevOps-metrik. Påverkningsobjekt

En vecka har gått sedan Ivan första gången började fundera på DevOps-metriker och insåg att han måste hantera produktleveranstiden med hjälp av dem. (Time-To-Market).

Även på helgerna tänkte han på metrik: "Och vad får jag ut av att mäta tiden? Vad ger det mig?"

Verkligen, vad ger vetskapen om tiden? Anta att leveransen tar 5 dagar. Och vad händer sedan? Är det bra eller dåligt? Även om det är dåligt, måste man ändå minska denna tid. Men hur?
Dessa tankar gjorde honom orolig, men lösningen kom inte.

Ivan insåg att han hade nått kärnan. De otaliga diagrammen av metrik som han sett tidigare hade för länge sedan övertygat honom om att den standardmetoden inte skulle fungera, och att om han bara skulle skapa ett diagram (även om det är kohortbaserat), skulle det inte ge något värde.

Vad ska man göra?…

En metrik är som ett vanligt trälinjal. Mätningar som görs med det kan inte förklara orsaken, varför till att det mätta objektet är just den längd som det visade. Linjalen visar bara storleken, och inte mer. Den är inte en filosoferande sten, utan bara en träplanka som används för att mäta.

"Rostfri råtta", den älskade karaktären av författaren Harry Harrison, sa alltid: tanken måste nå botten av hjärnan och vila där, så efter att ha kämpat utan resultat i några dagar beslutade Ivan sig för att ta sig an en annan uppgift…

Några dagar senare, när han läste en artikel om nätbutiker, insåg Ivan plötsligt att den kraft av pengar som en nätbutik får, beror på hur besökarna på webbplatsen beter sig. Just de, besökarna/kunderna, ger butiken sina pengar och är dess källa. Det slutliga beloppet av pengar som butiken får påverkas av förändringar i kundernas beteende, inte av något annat.

Det visade sig att för att förändra den mätta storheten måste man påverka dem som formar detta värde, det vill säga för att förändra mängden pengar i nätbutiken måste man påverka beteendet hos kunderna på denna butik, och för att förändra leveranstiden i DevOps måste man påverka de team som "skapar" denna tid, det vill säga de som använder DevOps i sitt arbete.

Ivan insåg att DevOps-metriker inte alls borde representera diagram. De måste representera ett verktyg för att söka efter "framstående" team som formar den slutliga leveranstiden.

Ingen mätning kan någonsin avslöja orsaken till varför ett visst team tog lång tid på sig att leverera distributionen, tänkte Ivan, eftersom det kan finnas miljoner orsaker, och många av dem kan vara organisatoriska snarare än tekniska. Det vill säga, det mesta man kan förvänta sig av mätningar är att de visar teamens prestationer och resultat, och därefter måste man ändå gå till dessa team för att ta reda på vad som har hänt.

Å andra sidan fanns det en standard i Ivans företag som ålade alla team att kontrollera byggnader på flera testmiljöer. Teamet kunde inte gå vidare till nästa miljö förrän den föregående var klar. Det innebar att om man ser DevOps-processen som en sekvens av att gå igenom testmiljöer, så skulle mätningarna kunna visa den tid som lag spenderade på dessa miljöer. Med vetskap om miljö och lagets tid kunde man prata mer konkret med dem om orsakerna.

Utan att tveka lyfte Ivan telefonluren och slog numret till en person som hade god insikt i DevOps inre funktioner:

— Denis, kan du berätta om det finns något sätt att förstå om teamet har passerat en viss testmiljö?
— Självklart. Vår Jenkins sätter en flagga om byggnaden har rullat ut framgångsrikt (klarat testet) på miljön.
— Super. Vad är en flagga?
— Det är en vanlig textfil av typen "miljö_OK" eller "miljö_FAIL", som indikerar om byggnaden har klarat eller inte klarat testet. Förstår du?
— I princip ja. Skriver den i samma mapp i lagret där byggnaden ligger?
— Ja.
— Vad händer om byggnaden inte klarar testet? Måste man göra en ny byggnad?
— Aha.
— Okej, tack. Och en till fråga: förstår jag rätt att jag kan använda datumet för när flaggan skapades som datum för att passera testmiljön?
— Absolut!
— Super!

Inspirerad lade Ivan på luren och insåg att allt hade fallit på plats. Med vetskap om skapelsedatumet för byggfilen och datum för flaggorna kunde man exakt räkna ut hur lång tid teamen tog på varje testmiljö och förstå var de spenderade mest tid.

"Genom att förstå var mest tid går, kan vi identifiera team och gå till dem för att gräva fram problemet." Ivan log.

Till nästa dag satte han som mål att skissa på arkitekturen för det framväxande systemet.

Fortsättning följer…

Källa: habr.com