Hoe Ivan DevOps-statistieken gebruikte. Voorwerp van invloed

Er is een week verstreken sinds Ivan voor het eerst nadacht over DevOps-statistieken en zich realiseerde dat het met hun hulp nodig is om de levertijd van producten te beheren (Time-to-Market).

Zelfs in het weekend dacht hij na over statistieken: “En wat als ik de tijd meet? Wat zal het mij opleveren?

Wat zal kennis van de tijd opleveren? Laten we zeggen dat de levering 5 dagen duurt. Dus, wat is het volgende? Is het goed of slecht? Zelfs als dit slecht is, moet je deze tijd op de een of andere manier verkorten. Maar hoe?
Deze gedachten achtervolgden hem, maar er kwam geen oplossing.

Ivan begreep dat hij tot de essentie was gekomen. De talloze grafieken van metrieken die hij eerder had gezien, hadden hem er al lang geleden van overtuigd dat de standaardaanpak niet zou werken, en dat als hij eenvoudigweg een plot maakte (ook al is het een cohort), zal het geen nut hebben.

Hoe te zijn?…

Een metriek is als een gewone houten liniaal. Metingen die met zijn hulp zijn gedaan, zullen de reden niet vertellen, waarom het te meten object heeft precies de lengte die ze liet zien. De liniaal toont eenvoudigweg de grootte ervan, en meer niet. Ze is niet de steen der wijzen, maar eenvoudigweg een houten plank om mee te meten.

De “roestvrijstalen rat” van zijn favoriete schrijver Harry Harrison zei altijd: een gedachte moet de onderkant van de hersenen bereiken en daar liggen, dus na een aantal dagen tevergeefs te hebben geleden, besloot Ivan een andere taak op zich te nemen...

Een paar dagen later, toen hij een artikel over online winkels las, realiseerde Ivan zich plotseling dat de hoeveelheid geld die een online winkel ontvangt afhangt van hoe bezoekers van de site zich gedragen. Zij zijn het, bezoekers/klanten, die de winkel hun geld geven en de bron zijn. Het nettobedrag aan contant geld dat een winkel ontvangt, wordt beïnvloed door veranderingen in het gedrag van klanten, en niet door iets anders.

Het bleek dat het, om de gemeten waarde te veranderen, nodig was om degenen die deze waarde vormden te beïnvloeden, d.w.z. om de hoeveelheid geld van een online winkel te veranderen, was het nodig om het gedrag van de klanten van deze winkel te beïnvloeden, en om de levertijd in DevOps te veranderen, was het nodig om de teams te beïnvloeden die deze keer ‘creëren’, d.w.z. gebruiken DevOps in hun werk.

Ivan realiseerde zich dat DevOps-statistieken helemaal niet in grafieken mogen worden weergegeven. Ze moeten zichzelf vertegenwoordigen zoekfunctie “uitstekende” teams die de uiteindelijke levertijd bepalen.

Geen enkele maatstaf zal ooit de reden aantonen waarom dit of dat team er lang over deed om een ​​distributie te leveren, dacht Ivan, omdat er in werkelijkheid wel een miljoen en een klein karretje konden zijn, en die zouden wel eens niet technisch, maar organisatorisch kunnen zijn. Die. het meeste dat je van statistieken kunt verwachten, is het tonen van teams en hun resultaten, en dan moet je deze teams nog steeds met je voeten volgen en ontdekken wat er mis mee is.

Aan de andere kant had Ivans bedrijf een norm die vereiste dat alle teams de assemblages op verschillende banken moesten testen. Het team kon pas naar de volgende tribune gaan als de vorige klaar was. Het bleek dat als we ons het DevOps-proces voorstellen als een opeenvolging van het passeren van stands, de statistieken de tijd konden weergeven die teams op deze stands doorbrachten. Omdat we de stand en tijd van het team kenden, was het mogelijk om specifieker met hen te praten over de redenen.

Zonder aarzelen pakte Ivan de telefoon en draaide het nummer van iemand die goed op de hoogte is van de ins en outs van DevOps:

— Denis, vertel me alsjeblieft, is het mogelijk om op de een of andere manier te begrijpen dat het team dit of dat standpunt heeft gepasseerd?
- Zeker. Onze Jenkins gooit de vlag weg als de build met succes is uitgerold (de test heeft doorstaan) op de bank.
- Super. Wat is een vlag?
- Dit is een normaal tekstbestand zoals “stand_OK” of “stand_FAIL”, waarin staat dat de vergadering de stand heeft gehaald of gezakt. Nou, je begrijpt het toch?
- Ik denk van wel. Wordt het naar dezelfde map in de repository geschreven waar de assembly zich bevindt?
- Ja
— Wat gebeurt er als het geheel de testbank niet doorstaat? Moet ik een nieuwbouw doen?
- Ja
- Nou, oké, bedankt. En nog een vraag: begrijp ik het goed dat ik de datum van creatie van de vlag kan gebruiken als datum van de stand?
- Absoluut!
- Super!

Geïnspireerd hing Ivan op en besefte dat alles op zijn plaats was gevallen. Door de datum van creatie van het bouwbestand en de datum van creatie van de vlaggen te kennen, was het mogelijk om tot op de seconde te berekenen hoeveel tijd de teams aan elke stand besteden en te begrijpen waar ze de meeste tijd doorbrengen.

“Om te begrijpen waar de meeste tijd wordt besteed, zullen we teams identificeren, naar hen toe gaan en het probleem onderzoeken.” Iwan glimlachte.

Voor morgen stelde hij zichzelf de taak om de architectuur van het te tekenen systeem te schetsen.

Wordt vervolgd ...

Bron: www.habr.com

Voeg een reactie