Per esse onestu, Ivan spessu ridia di i sforzi inutili di i so culleghi di u dipartimentu di monitoraghju. Anu fattu grandi sforzi per implementà e metriche chì a gestione di a cumpagnia li hà urdinatu per ottene. Eranu cusì occupati chì ùn vulianu micca chì nimu altru facia nunda.
Ma ùn era micca abbastanza per a gestione - anu urdinatu constantemente più è più novi metriche, cessendu assai rapidamente di utilizà ciò chì era statu fattu prima.
Ultimamente, tutti anu parlatu di LeadTime - u tempu per a consegna di e funzioni di l'affari. A metrica hà dimustratu un numeru pazzi - 200 ghjorni per furnisce una sola attività. Cumu tutti ohed è aahed è alzavanu e mani à u celu !
Dopu qualchì tempu, u rumore hà diminuitu gradualmente è a gestione hà ricevutu un ordine per creà una altra metrica.
Era cumplettamente chjaru à Ivan chì a nova metrica mori in un angulu scuru.
Infatti, hà pensatu Ivan, sapendu chì u numeru ùn dice nunda à nimu. 200 ghjorni o 2 ghjorni - ùn ci hè micca differenza, perchè hè impussibile di determinà a ragiuni per u numeru è capisce s'ellu hè bonu o male.
Questa hè una trappula tipica di metrica: pare chì una nova metrica dicerà l'essenza di l'esistenza è spiegà qualchì secretu secretu. Tutti speranu tantu per questu, ma per una certa ragione ùn succede nunda. Iè, perchè u sicretu ùn deve esse truvatu in metrica!
Per Ivan, questu era un stadiu passatu. Hà capitu chì per e misurazioni, è tutti i sicreti devenu esse cercati , i.e. hè chì sta metrica hè furmatu.
Per una tenda in linea, l'ughjettu di influenza seranu i so clienti chì portanu soldi, è per DevOps, seranu e squadre chì creanu è sparghje distribuzioni cù una pipeline.
Un ghjornu, à pusà in una sedia còmoda in a sala, Ivan hà decisu di pensà cun cura cumu vulia vede e metriche DevOps, tenendu in contu u fattu chì l'ughjettu di influenza hè squadre.
Scopu di DevOps Metrics
Hè chjaru chì tutti volenu riduce u tempu di consegna. 200 ghjorni, di sicuru, ùn hè micca bonu.
Ma cumu, questu hè a quistione?
A cumpagnia impiega centinaie di squadre, è millaie di distribuzioni passanu per u pipeline DevOps ogni ghjornu. U tempu di consegna attuale apparirà cum'è una distribuzione. Ogni squadra avarà u so tempu è e so caratteristiche. Cumu pudete truvà qualcosa trà questu mess?
A risposta hè ghjunta in modu naturali - avemu bisognu di truvà e squadre problematiche è capisce ciò chì passa cun elli è perchè ci vole tantu tempu, è amparà da i "boni" squadre cumu fà tuttu rapidamente. È per fà questu, avete bisognu di misurà u tempu passatu da e squadre in ogni stand DevOps:
"U scopu di u sistema serà di selezziunà squadre basatu annantu à u tempu chì passanu e tribune, i.e. In u risultatu, duvemu ottene una lista di cumandamenti cù u tempu sceltu, è micca un numeru.
Se sapemu quantu tempu hè statu passatu nantu à u stand in totale è quantu tempu hè statu passatu nantu à i tempi di inattività trà i stands, pudemu truvà e squadre, chjamà è capisce i motivi in più dettagliu è eliminà ", hà pensatu Ivan. .
Cumu calculà u tempu di consegna per DevOps
Per u calculà, era necessariu sfondate in u prucessu DevOps è a so essenza.
A cumpagnia usa un numeru limitatu di sistemi, è l'infurmazioni ponu esse ottenute solu da elli è in nudda parte.
Tutti i travaglii in a cumpagnia sò stati registrati in Jira. Quandu un compitu hè statu fattu, un ramu hè statu creatu per questu, è dopu a implementazione, un cummitteddu hè statu fattu à BitBucket è Pull Request. Quandu una PR (Pull Request) hè stata accettata, una distribuzione hè stata automaticamente creata è guardata in u repository Nexus.
In seguitu, a distribuzione hè stata sviluppata nantu à parechji stands cù Jenkins per verificà a correttezza di u rollout, teste automatiche è manuali:
Ivan hà descrittu da quali sistemi quale infurmazione pò esse pigliata per calculà u tempu à i stands:
- From Nexus - Distribuzione tempu di creazione è u nome di u cartulare chì cuntene u codice cumanda
- Da Jenkins - U tempu di partenza, a durata è u risultatu di ogni travagliu, u nome di stand (in i paràmetri di u travagliu), tappe (passi di u travagliu), ligame à a distribuzione in Nexus.
- Ivan hà decisu di ùn include Jira è BitBucket in u pipeline, perchè ... eranu più ligati à a tappa di sviluppu, è micca à sparghje a distribuzione finita nantu à i stands.
Basatu nantu à l'infurmazioni dispunibili, u schema seguente hè statu disegnatu:
Sapendu quantu tempu ci vole à creà distribuzioni è quantu tempu si spende per ognunu, pudete facilmente calculà i costi totali di passà per tuttu u pipeline DevOps (ciclu cumpletu).
Eccu i metrichi DevOps chì Ivan hà finitu:
- Numaru di distribuzioni creatu
- Parte di distribuzioni chì "vinutu" à u stand è "passavanu" u stand
- Tempu passatu nantu à u stand (ciclu di stand)
- Ciclu tutale (tempu tutale per tutti i stand)
- Durata di u travagliu
- Tempo di inattività trà i stand
- Tempi d'inattività trà i lanci di travagliu nantu à u listessu stand
Da una banda, e metriche carattarizavanu u pipeline DevOps assai bè in termini di tempu, da l'altra banda, eranu cunsiderate assai simplici.
Soddisfattu di u travagliu bè fattu, Ivan hà fattu una presentazione è andò à presentà à a gestione.
Riturnò lugubriu è cù e mani calate.
"Questu hè un fiasco, fratellu", hà sorrisu u cullega ironicu ...
Leghjite più in l'articulu "».
Source: www.habr.com