Om earlik te wêzen, lake Ivan faaks om de nutteloze ynspanningen fan syn kollega's fan 'e tafersjochôfdieling. Se makken grutte ynspanningen om de metriken út te fieren dy't it bedriuwsmanagement har bestelde te berikken. Se hiene it sa drok, dat se net woene dat in oar wat dien hie.
Mar it wie net genôch foar it management - se bestelden hieltyd mear en mear nije metriken, hiel gau ophâlde te brûken wat earder dien wie.
De lêste tiid hat elkenien it oer LeadTime - de tiid foar levering fan saaklike funksjes. De metrik liet in gek getal sjen - 200 dagen om ien taak te leverjen. Hoe't elkenien de hannen nei de himel opstutsen en aaien!
Nei ferrin fan tiid ferdwûn it lûd stadichoan en krige it management in opdracht om in oare metryske te meitsjen.
It wie foar Ivan folslein dúdlik dat de nije metrik like rêstich stjerre soe yn in tsjustere hoeke.
Yndied, tocht Ivan, it witten fan it nûmer fertelt gjinien hielendal neat. 200 dagen of 2 dagen - d'r is gjin ferskil, om't it ûnmooglik is om de reden troch it nûmer te bepalen en te begripen oft it goed of min is.
Dit is in typyske trap fan metriken: it liket derop dat in nije metrik de essinsje fan it bestean sil fertelle en wat geheim geheim ferklearje. Elkenien hopet hjir safolle op, mar om ien of oare reden bart der neat. Ja, om't it geheim net te finen is yn metriken!
Foar Ivan wie dit in trochjûn poadium. Hy begriep dat foar mjittingen, en alle geheimen moatte socht wurde yn , d.w.s. is dat dizze metrik wurdt foarme.
Foar in online winkel sil it objekt fan ynfloed har kliïnten wêze dy't jild ynbringe, en foar DevOps sille it de teams wêze dy't distribúsjes meitsje en útrolje mei in pipeline.
Op in dei, sittend yn in noflike stoel yn 'e seal, besleat Ivan om soarchfâldich nei te tinken hoe't hy DevOps-metriken woe sjen, rekken hâldend mei it feit dat it objekt fan ynfloed teams binne.
Doel fan DevOps Metrics
It is dúdlik dat elkenien de levertiid ferleegje wol. 200 dagen is fansels net goed.
Mar hoe, dat is de fraach?
It bedriuw hat hûnderten teams yn tsjinst, en tûzenen distribúsjes geane elke dei troch de DevOps-pipeline. De werklike levertiid sil ferskine as in distribúsje. Elk team sil syn eigen tiid en har eigen skaaimerken hawwe. Hoe kinne jo wat fine tusken dizze puinhoop?
It antwurd kaam fansels - wy moatte de probleemteams fine en útfine wat der mei har bart en wêrom it sa lang duorret, en fan 'e "goede" teams leare hoe't jo alles fluch kinne dwaan. En om dit te dwaan, moatte jo de tiid mjitte dy't teams bestege oan elk fan 'e DevOps-tribunes:
“It doel fan it systeem sil wêze om teams te selektearjen op basis fan de tiid dat se de tribune passe, d.w.s. As gefolch moatte wy in list mei kommando's krije mei de selektearre tiid, en net in nûmer.
As wy útfine hoefolle tiid yn totaal op 'e tribune is bestege en hoefolle tiid is bestege oan downtime tusken tribunes, sille wy de teams kinne fine, belje en de redenen yn mear detail begripe en se eliminearje, "tocht Ivan .
Hoe de levertiid te berekkenjen foar DevOps
Om it te berekkenjen, wie it nedich om te ferdjipjen yn it DevOps-proses en syn essinsje.
It bedriuw brûkt in beheind oantal systemen, en ynformaasje kin allinnich wurde krigen fan harren en nearne oars.
Alle taken yn it bedriuw waarden registrearre yn Jira. Doe't in taak waard oannommen, in tûke waard makke foar it, en nei ymplemintaasje, in commit oan BitBucket en Pull Request. As in PR (Pull Request) waard akseptearre, waard automatysk in distribúsje makke en opslein yn it Nexus-repository.
Dêrnei waard de distribúsje op ferskate tribunes rôle mei Jenkins om de krektens fan 'e rollout te kontrolearjen, automatyske en manuele testen:
Ivan beskreau út hokker systemen hokker ynformaasje kin wurde nommen om de tiid op 'e tribune te berekkenjen:
- Fan Nexus - Ferdieling oanmeitsjen tiid en namme fan de map dy't befette de kommando koade
- Fan Jenkins - Starttiid, doer en resultaat fan elke baan, standnamme (yn 'e baanparameters), stadia (jobstappen), keppeling nei de ferdieling yn Nexus.
- Ivan besleat Jira en BitBucket net yn 'e pipeline op te nimmen, om't ... se wiene mear besibbe oan it ûntwikkelingsstadium, en net mei it útrôljen fan 'e ôfmakke distribúsje op tribunes.
Op grûn fan de beskikbere ynformaasje is it folgjende diagram tekene:
Troch te witten hoe lang it duorret om distribúsjes te meitsjen en hoefolle tiid oan elk fan harren wurdt bestege, kinne jo de totale kosten maklik berekkenje om troch de heule DevOps-pipeline (folsleine syklus) te gean.
Hjir binne de DevOps-metriken wêrmei Ivan einige:
- Oantal distribúsjes makke
- Oanpart fan distribúsjes dy't "kamen" nei de tribune en "trochgean" de tribune
- Tiid bestege oan 'e stand (standsyklus)
- Folsleine syklus (totale tiid foar alle tribunes)
- Job doer
- Downtime tusken tribunes
- Downtime tusken baan lansearringen op deselde stand
Oan 'e iene kant karakterisearre de metriken de DevOps-pipeline heul goed yn termen fan tiid, oan' e oare kant waarden se as heul ienfâldich beskôge.
Tefreden mei it wurk goed dien, Ivan makke in presintaasje en gie te presintearje it oan it management.
Hy kaam somber werom en mei de hannen del.
"Dit is in fiasko, broer," glimke de iroanyske kollega ...
Lês mear yn it artikel "".
Boarne: www.habr.com