(Time-To-Market).
Zelfs in het weekend dacht hij aan de metrieken: "En wat als ik de tijd meet? Wat brengt het mij?"
Inderdaad, wat brengt het weten van de tijd? Stel dat de levering 5 dagen duurt. En dan? Is dat goed of slecht? Zelfs als het slecht is, moet je die tijd toch op de een of andere manier verkorten. Maar hoe?
Deze gedachten lieten hem niet met rust, maar de oplossing kwam niet.
Ivan begreep dat hij bij de kern van de zaak was aangekomen. De talloze grafieken van metrieken die hij eerder had gezien, hadden hem al lang overtuigd dat de standaardaanpak niet zou werken, en dat als je gewoon een grafiek zou maken (), het helemaal niets zou opleveren.
Wat te doen?ā¦
Een metriek is als een gewone houten liniaal. Metingen die met haar zijn gedaan, zullen niet vertellen waarom het gemeten voorwerp precies die lengte heeft die ze heeft aangegeven. waarom De liniaal toont gewoon de grootte ervan, en niet meer. Het is geen filosofische steen, maar gewoon een houten plank die gemeten wordt.
"De roestvrijstalen rat" van zijn favoriete schrijver Harry Harrison zei altijd: gedachten moeten de bodem van de hersens bereiken en daar uitrusten, daarom besloot Ivan, na enkele dagen te hebben geworsteld zonder resultaten, zich met een andere taak bezig te houdenā¦
Na een paar dagen, terwijl hij een artikel over webwinkels las, realiseerde Ivan zich ineens dat het bedrag geld dat een webwinkel ontvangt, afhangt van het gedrag van de websitebezoekers. Zij, de bezoekers/cliĆ«nten, geven hun geld aan de winkel en zijn de bron ervan. De uiteindelijke hoeveelheid geld die de winkel ontvangt, wordt beĆÆnvloed door veranderingen in het gedrag van de klanten, en niets anders.
Het bleek dat om de meetwaarde te veranderen, je invloed moest uitoefenen op degenen die die waarde vormen, dat wil zeggen, om het bedrag geld van een webwinkel te veranderen, moest je invloed uitoefenen op het gedrag van de klanten van die winkel, en om de levertijd in DevOps te veranderen, moest je invloed uitoefenen op de teams die die tijd "creƫren", dat wil zeggen, op de teams die DevOps in hun werk gebruiken.
Ivan begreep dat DevOps-metrieken helemaal geen grafieken zouden moeten zijn. Ze zouden moeten dienen als een hulpmiddel voor het vinden van "uitmuntende" teams die de uiteindelijke levertijd vormen.
Geen enkele metric zal ooit de reden tonen waarom een specifiek team lang deed over het opleveren van een distributie, dacht Ivan, want in werkelijkheid kunnen er miljoenen redenen zijn, en deze kunnen heel goed organisatorisch van aard zijn in plaats van technisch. Met andere woorden, het enige wat we van metrics kunnen verwachten, is het tonen van teams en hun resultaten, en dan moet je nog steeds naar die teams toe om te achterhalen wat er aan de hand is.
Aan de andere kant had Ivan's bedrijf een standaard die alle teams verplichtte om builds op meerdere omgevingen te testen. Een team kon niet naar de volgende omgeving gaan voordat de vorige was doorlopen. Dit betekende dat als je het DevOps-proces zou voorstellen als een reeks omgevingen, de metrics zouden kunnen laten zien hoeveel tijd de teams op deze omgevingen hebben besteed. Door de omgeving en de tijd van het team te kennen, kon er gerichter met hen worden gesproken over de oorzaken.
Zonder lang na te denken, pakte Ivan de telefoon en belde iemand die goed thuis was in de diepten van DevOps:
ā Denis, kun je me vertellen of je op een of andere manier kunt begrijpen of het team een specifieke omgeving heeft doorlopen?
ā Natuurlijk. Onze Jenkins laat een vlag vallen als de build succesvol is uitgerold (de test op de omgeving heeft doorstaan).
ā Geweldig. Maar wat is een vlag?
ā Het is een gewoon tekstbestand zoals "omgeving_OK" of "omgeving_FAIL", dat aangeeft of de build de omgeving heeft doorstaan of niet. Snap je het?
ā In principe wel. Wordt het in dezelfde map van de opslag geschreven waar de build ligt?
ā Ja.
ā Wat gebeurt er als de build de omgeving niet doorstaat? Moet er een nieuwe build gemaakt worden?
ā Ja.
ā OkĆ©, bedankt. En nog een vraag: begrijp ik het goed dat ik de datum van het doorlopen van de omgeving kan gebruiken als de datum waarop de vlag is aangemaakt?
ā Absoluut!
ā Geweldig!
GeĆÆnspireerd legde Ivan de hoorn neer en realiseerde hij zich dat alles op zijn plek viel. Door de aanmaakdatum van het build-bestand en de aanmaakdatums van de vlaggen te kennen, kon hij tot op de seconde nauwkeurig berekenen hoeveel tijd de teams aan elke omgeving besteden en begrijpen waar ze de meeste tijd verliezen.
"Door te begrijpen waar de meeste tijd naartoe gaat, kunnen we doelgericht de teams identificeren, naar hen toe gaan en het probleem uitgraven." Ivan glimlachte.
Voor morgen stelde hij zichzelf de taak om een architectuur voor het opkomende systeem te schetsen.
Wordt vervolgdā¦
Bron: habr.com
