Eerlijk gezegd lachte Ivan vaak om de vergeefse inspanningen van zijn collega's van de monitoringafdeling. Ze hebben grote inspanningen geleverd om de maatstaven te implementeren die het management van het bedrijf hen had opgedragen. Ze hadden het zo druk dat ze niet wilden dat iemand anders iets deed.
Maar het was niet genoeg voor het management: ze bestelden voortdurend meer en meer nieuwe statistieken, en stopten al snel met het gebruiken van wat eerder was gedaan.
De laatste tijd heeft iedereen het over LeadTime: de tijd voor het leveren van zakelijke functies. De statistiek toonde een bizar getal: 200 dagen om één taak te voltooien. Hoe iedereen oohte en aahede en hun handen naar de hemel hief!
Na enige tijd nam de ruis geleidelijk af en kreeg het management de opdracht om een andere maatstaf te creëren.
Het was Ivan volkomen duidelijk dat de nieuwe metriek net zo stilletjes in een donkere hoek zou sterven.
Sterker nog, dacht Ivan, het kennen van het getal zegt niemand iets. 200 dagen of 2 dagen - er is geen verschil, omdat het onmogelijk is om de reden aan de hand van het aantal te bepalen en te begrijpen of het goed of slecht is.
Dit is een typische valkuil van metrieken: het lijkt erop dat een nieuwe metriek de essentie van het bestaan zal vertellen en een geheim geheim zal verklaren. Iedereen hoopt hier zo hard op, maar om de een of andere reden gebeurt er niets. Ja, want het geheim mag niet in statistieken gevonden worden!
Voor Ivan was dit een voorbije fase. Dat begreep hij voor metingen, en alle geheimen moeten worden gezocht , d.w.z. is dat deze metriek wordt gevormd.
Voor een online winkel zullen de klanten die geld binnenbrengen het voorwerp van invloed zijn, en voor DevOps zullen het de teams zijn die distributies creëren en uitrollen via een pijplijn.
Op een dag, zittend in een comfortabele stoel in de hal, besloot Ivan goed na te denken over hoe hij de DevOps-statistieken wilde zien, rekening houdend met het feit dat teams het voorwerp van invloed zijn.
Doel van DevOps-statistieken
Het is duidelijk dat iedereen de levertijd wil verkorten. 200 dagen is natuurlijk niet goed.
Maar hoe, dat is de vraag?
Het bedrijf heeft honderden teams in dienst en elke dag gaan duizenden distributies via de DevOps-pijplijn. De daadwerkelijke levertijd verschijnt als verdeling. Elk team heeft zijn eigen tijd en zijn eigen kenmerken. Hoe kun je iets vinden in deze puinhoop?
Het antwoord ontstond vanzelf: we moeten de probleemteams vinden en uitzoeken wat er met hen aan de hand is en waarom het zo lang duurt, en van de ‘goede’ teams leren hoe we alles snel kunnen doen. En om dit te doen, moet u de tijd meten die teams op elk van de DevOps-stands doorbrengen:
“Het doel van het systeem zal zijn om teams te selecteren op basis van de tijd dat ze de tribune passeren, d.w.z. Als gevolg hiervan zouden we een lijst met opdrachten moeten krijgen met de geselecteerde tijd, en niet een nummer.
Als we erachter komen hoeveel tijd er in totaal op de stand is doorgebracht en hoeveel tijd er is besteed aan stilstand tussen stands, kunnen we de teams vinden, bellen, de redenen gedetailleerder begrijpen en ze elimineren”, dacht Ivan.
Hoe u de levertijd voor DevOps kunt berekenen
Om het te berekenen, was het nodig om je te verdiepen in het DevOps-proces en de essentie ervan.
Het bedrijf gebruikt een beperkt aantal systemen en informatie kan alleen via deze systemen worden verkregen en nergens anders.
Alle taken binnen het bedrijf werden geregistreerd in Jira. Wanneer een taak op zich werd genomen, werd er een branch voor aangemaakt, en na de implementatie werd er een commit gedaan naar BitBucket en Pull Request. Wanneer een PR (Pull Request) werd geaccepteerd, werd er automatisch een distributie aangemaakt en opgeslagen in de Nexus-repository.
Vervolgens werd de distributie op verschillende stands uitgerold waarbij Jenkins de juistheid van de uitrol controleerde, automatisch en handmatig testte:
Ivan beschreef uit welke systemen welke informatie kan worden gehaald om de tijd op de stands te berekenen:
- Van Nexus – Aanmaaktijd van de distributie en naam van de map die de opdrachtcode bevatte
- Van Jenkins – Starttijd, duur en resultaat van elke klus, standnaam (in de klusparameters), fasen (klusstappen), link naar de verdeling in Nexus.
- Ivan besloot Jira en BitBucket niet in de pijplijn op te nemen, omdat... ze hadden meer betrekking op de ontwikkelingsfase en niet op het uitrollen van de voltooide distributie op stands.
Op basis van de beschikbare informatie is het volgende diagram getekend:
Als u weet hoe lang het duurt om distributies te maken en hoeveel tijd aan elk daarvan wordt besteed, kunt u eenvoudig de totale kosten berekenen van het doorlopen van de gehele DevOps-pijplijn (volledige cyclus).
Dit zijn de DevOps-statistieken waarmee Ivan eindigde:
- Aantal gemaakte distributies
- Aandeel uitkeringen dat naar de stand “kwam” en “voorbij” de stand
- Tijd doorgebracht op de stand (standcyclus)
- Volledige cyclus (totale tijd voor alle stands)
- Duur van de taak
- Stilstand tussen stands
- Downtime tussen joblanceringen op dezelfde stand
Aan de ene kant karakteriseerden de statistieken de DevOps-pijplijn zeer goed in termen van tijd, aan de andere kant werden ze als zeer eenvoudig beschouwd.
Tevreden over het goed uitgevoerde werk, hield Ivan een presentatie en ging deze presenteren aan het management.
Hij kwam somber en met zijn handen naar beneden terug.
“Dit is een fiasco, bro”, glimlachte de ironische collega...
Lees meer in het artikel “.
Bron: www.habr.com