(Tid till marknaden).
Till och med på helgerna tänkte han på mått: ”Så vad händer om jag mäter tid? Vad kommer det att ge mig?
Ja, vad kommer kunskap om tiden att ge? Låt oss säga att leveransen tar 5 dagar. Så, vad är nästa? Är det bra eller dåligt? Även om detta är dåligt, så måste du på något sätt minska den här tiden. Men hur?
Dessa tankar förföljde honom, men ingen lösning kom.
Ivan förstod att han hade kommit till själva essensen. De otaliga graferna med mått som han hade sett tidigare hade för länge sedan övertygat honom om att standardmetoden inte skulle fungera, och att om han helt enkelt ritade (), kommer det inte att vara till någon nytta.
Hur man är?…
En metrik är som en vanlig trälinjal. Mätningar gjorda med dess hjälp kommer inte att berätta orsaken, Varför objektet som mäts är exakt den längd som hon visade. Linjalen visar helt enkelt sin storlek, och inget mer. Hon är inte de vises sten, utan helt enkelt en träskiva att mäta med.
Hans favoritförfattare Harry Harrisons "råtta av rostfritt stål" sa alltid: en tanke måste nå botten av hjärnan och ligga där, så efter att ha lidit i flera dagar utan resultat, bestämde sig Ivan för att ta sig an en annan uppgift ...
Ett par dagar senare, när han läste en artikel om nätbutiker, insåg Ivan plötsligt att summan pengar en nätbutik får beror på hur webbplatsbesökarna beter sig. Det är de, besökare/kunder, som ger butiken sina pengar och är dess källa. Summan av kontanter som en butik tar emot påverkas av förändringar i kundernas beteende, inte något annat.
Det visade sig att för att ändra det uppmätta värdet var det nödvändigt att påverka de som bildar detta värde, d.v.s. för att ändra mängden pengar på en webbutik var det nödvändigt att påverka beteendet hos kunderna i denna butik, och för att ändra leveranstiden i DevOps var det nödvändigt att påverka de team som ”skapar” den här gången, d.v.s. använda DevOps i sitt arbete.
Ivan insåg att DevOps-mätvärden inte alls borde representeras av grafer. De måste representera sig själva sökverktyg "enastående" team som formar den slutliga leveranstiden.
Ingen mätning kommer någonsin att visa anledningen till att det eller det laget tog lång tid att leverera en distribution, tänkte Ivan, för i verkligheten kan det finnas en miljon och en liten vagn, och de kan mycket väl inte vara tekniska, utan organisatoriska. De där. det mesta du kan förvänta dig av mätvärden är att visa team och deras resultat, och då måste du fortfarande följa dessa team med fötterna och ta reda på vad som är fel på dem.
Å andra sidan hade Ivans företag en standard som krävde att alla team skulle testa monteringar på flera bänkar. Laget kunde inte flytta till nästa läktare förrän den föregående var klar. Det visade sig att om vi föreställer oss DevOps-processen som en sekvens av att passera genom läktare, så kunde mätvärdena visa tiden som lag spenderade på dessa läktare. Genom att känna till lagets ställning och tid var det möjligt att prata med dem mer specifikt om orsakerna.
Utan att tveka lyfte Ivan luren och slog numret till en person som är väl insatt i DevOps:
— Denis, snälla säg mig, är det möjligt att på något sätt förstå att laget har klarat den eller den läktaren?
- Absolut. Vår Jenkins kasserar flaggan om konstruktionen framgångsrikt har rullats ut (godkänt testet) på bänken.
- Superbra. Vad är en flagga?
- Det här är en vanlig textfil som "stand_OK" eller "stand_FAIL", som säger att församlingen godkände eller misslyckades med standen. Du förstår väl?
- Jag antar det ja. Är det skrivet till samma mapp i arkivet där sammansättningen finns?
- Ja
— Vad händer om monteringen inte klarar testbänken? Behöver jag bygga ett nytt?
- Ja
- Okej, tack. Och en annan fråga: förstår jag rätt att jag kan använda datumet då flaggan skapades som datum för montern?
- Absolut!
– Superbra!
Inspirerad lade Ivan på luren och insåg att allt hade fallit på plats. Genom att veta datumet för skapande av byggfilen och datumet för skapande av flaggorna, var det möjligt att räkna ut till tvåan hur mycket tid lagen spenderar på varje läktare och förstå var de spenderar mest tid.
"För att förstå var mest tid spenderas kommer vi att peka ut team, gå till dem och gräva i problemet." Ivan log.
Till morgondagen satte han sig i uppgift att skissa på arkitekturen för det system som ritades.
Fortsättning ...
Källa: will.com