(Time-To-Market).
Selv i weekenden tænkte han på metrikkerne: "Nå, hvad hjælper det, at jeg måler tiden? Hvad giver det mig?"
Hvad giver kendskab til tiden? Antag, at leveringen tager 5 dage. Og hvad så? Er det godt eller dårligt? Selv hvis det er dårligt, skal det jo på en eller anden måde reduceres. Men hvordan?
Disse tanker gav ham ikke ro, men løsningen kom ikke.
Ivan forstod, at han var kommet til sagens kerne. Utallige metrik-grafer, han tidligere havde set, havde længe overbevist ham om, at den standardmetode ikke ville fungere, og at selv hvis man blot lavede en graf (), ville der ikke være nogen mening med det.
Hvad så?...
En metrik er ligesom et almindeligt trælineal. Målingerne foretaget med den fortæller ikke årsagen til, hvorfor det målte objekt har præcis den længde, den viser. Linealen viser kun størrelsen, og ikke mere. Den er ikke filosofiens sten, men bare et stykke træ, man måler med.
Den "rustfrie stålrotte" fra hans yndlingsforfatter Harry Harrisons sagde altid: tanken skal nå bunden af hjernen og hvile der, derfor besluttede Ivan sig for at tage fat på en anden opgave efter at have kæmpet uden held i flere dage...
Et par dage senere, mens han læste en artikel om online butikker, indså Ivan pludselig, at den mængde penge, en online butik får, afhænger af, hvordan webstedets besøgende opfører sig. Det er netop dem, besøgende/kunder, der giver butik i deres penge og er kilden til dem. De ændringer i kundernes adfærd påvirker den samlede mængde penge, butikken modtager, og ikke noget andet.
Det viste sig, at for at ændre den målte størrelse skulle man påvirke dem, der danner denne værdi, altså for at ændre mængden af penge i online butikken skulle man påvirke adfærden hos butikkens kunder, og for at ændre leveringstiden i DevOps skulle man påvirke de teams, der "skaber" denne tid, dvs. dem der bruger DevOps i deres arbejde.
Ivan indså, at DevOps-metrikker ikke nødvendigvis skal repræsentere grafer. De skal repræsentere et værktøj til at finde "fremragende" teams, der former den samlede leveringstid.
Ingen metric vil nogensinde afsløre årsagen til, hvorfor et givent team har brugt lang tid på at levere en distribution, tænkte Ivan, da der i virkeligheden kan være millioner af årsager, og de kan sagtens være organisatoriske snarere end tekniske. Det vil sige, at det maksimalt, man kan forvente at få fra metrics, er en præsentation af teams og deres resultater, hvorefter man alligevel må gå til disse teams for at finde ud af, hvad der er sket.
På den anden side havde Ivans virksomhed en standard, der forpligtede alle teams til at teste builds på flere sandkasser. Teamet kunne ikke gå videre til næste sandkasse, før det foregående var bestået. Det betød, at hvis man forestillede sig DevOps-processen som en sekvens af at bestå sandkasser, kunne metrics vise den tid, teams brugte i disse sandkasser. Ved at kende sandkassen og teamets tid kunne man tale mere konkret med dem om årsagerne.
Uden at tænke længe tog Ivan telefonen og ringede til en person, der godt kendte til DevOps indre funktioner:
— Denis, kan du hjælpe mig med at forstå, om man på en eller anden måde kan vide, at et team har bestået en bestemt sandkasse?
— Selvfølgelig. Vores Jenkins markerer en flag, hvis builden er blevet rullet ud (bestået test) på sandkassen.
— Super. Hvad er et flag?
— Det er en almindelig tekstfil som «sandkasse_OK» eller «sandkasse_FAIL», der angiver, om builden har bestået eller ej. Forstår du?
— I princippet ja. Bliver den skrevet til den samme mappe i lageret, hvor builden ligger?
— Ja.
— Hvad hvis builden ikke bestod sandkassen? Skulle jeg så lave en ny build?
— Ja.
— Okay, tak. Og et sidste spørgsmål: forstår jeg det korrekt, at jeg kan bruge datoen for oprettelsen af flaget som datoen for at bestå sandkassen?
— Absolut!
— Super!
Opmuntrende lagde Ivan røret og indså, at alt faldt på plads. Ved at kende datoen for oprettelsen af build-filen og datoerne for oprettelsen af flagene kunne man præcist opgøre, hvor lang tid teams brugte på hver sandkasse, og forstå hvor de brugte mest tid.
«Ved at forstå hvor der går mest tid, kan vi målrettet finde teams, gå til dem og grave dybere i problemet». Ivan smilede.
Til næste dag satte han sig som mål at skitsere arkitekturen for det nye system.
Fortsætter…
Kilde: habr.com
