Sincer să fiu, Ivan a râs adesea de eforturile zadarnice ale colegilor săi de la departamentul de monitorizare. Au făcut eforturi mari pentru a implementa metricile pe care conducerea companiei le-a ordonat să le atingă. Erau atât de ocupați încât nu doreau ca altcineva să facă nimic.
Dar nu a fost suficient pentru management - au comandat constant din ce în ce mai multe valori noi, încetând foarte repede să mai folosească ceea ce se făcuse anterior.
În ultimul timp, toată lumea a vorbit despre LeadTime - timpul pentru livrarea funcțiilor de afaceri. Valoarea a arătat un număr nebun - 200 de zile pentru a realiza o sarcină. Cât au urât toată lumea și și-a ridicat mâinile spre cer!
După ceva timp, zgomotul a scăzut treptat, iar conducerea a primit un ordin de a crea o altă măsurătoare.
Pentru Ivan îi era complet clar că noua măsurătoare va muri la fel de liniștită într-un colț întunecat.
Într-adevăr, se gândi Ivan, știind că numărul nu spune nimănui nimic. 200 de zile sau 2 zile - nu există nicio diferență, deoarece este imposibil să determinați motivul după număr și să înțelegeți dacă este bun sau rău.
Aceasta este o capcană tipică a măsurătorilor: se pare că o nouă măsurătoare va spune esența existenței și va explica un secret secret. Toată lumea speră atât de mult la asta, dar din anumite motive nu se întâmplă nimic. Da, pentru că secretul nu trebuie găsit în metrici!
Pentru Ivan, aceasta a fost o etapă trecută. El a înțeles asta pentru măsurători și toate secretele trebuie căutate , adică este că această metrică este formată.
Pentru un magazin online, obiectul de influență vor fi clienții săi care aduc bani, iar pentru DevOps, vor fi echipele care creează și lansează distribuții folosind un pipeline.
Într-o zi, așezat pe un scaun confortabil din hol, Ivan a decis să se gândească cu atenție la modul în care dorea să vadă metrica DevOps, ținând cont de faptul că obiectul de influență îl reprezintă echipele.
Scopul valorii DevOps
Este clar că toată lumea vrea să reducă timpul de livrare. 200 de zile, desigur, nu sunt bune.
Dar cum, asta este întrebarea?
Compania are sute de echipe, iar mii de distribuții trec prin conducta DevOps în fiecare zi. Timpul efectiv de livrare va apărea ca o distribuție. Fiecare echipă va avea propriul său timp și propriile sale caracteristici. Cum poți găsi ceva printre mizeria asta?
Răspunsul a apărut în mod natural - trebuie să găsim echipele cu probleme și să ne dăm seama ce se întâmplă cu ele și de ce durează atât de mult și să învățăm de la echipele „bune” cum să facem totul rapid. Și pentru a face acest lucru, trebuie să măsurați timpul petrecut de echipe la fiecare dintre standurile DevOps:
„Scopul sistemului va fi selectarea echipelor în funcție de timpul în care trec prin tribune, adică. Ca rezultat, ar trebui să obținem o listă de comenzi cu ora selectată, și nu un număr.
Dacă aflăm cât timp s-a petrecut pe tribună în total și cât timp s-a petrecut între tribune, putem găsi echipele, să le sunăm și să înțelegem mai în detaliu motivele și să le eliminăm”, a gândit Ivan.
Cum se calculează timpul de livrare pentru DevOps
Pentru a-l calcula, a fost necesar să ne adâncim în procesul DevOps și în esența acestuia.
Compania folosește un număr limitat de sisteme, iar informațiile pot fi obținute doar de la acestea și nicăieri altundeva.
Toate sarcinile din companie au fost înregistrate în Jira. Când a fost preluată o sarcină, a fost creată o ramură pentru aceasta și, după implementare, a fost făcută o comitare către BitBucket și Pull Request. Când un PR (Pull Request) a fost acceptat, o distribuție a fost creată și stocată automat în depozitul Nexus.
Apoi, distribuția a fost derulată pe mai multe standuri folosind Jenkins pentru a verifica corectitudinea lansării, testării automate și manuale:
Ivan a descris din ce sisteme ce informații pot fi luate pentru a calcula timpul de la standuri:
- Din Nexus – Ora creării distribuției și numele folderului care conținea codul de comandă
- De la Jenkins – Ora de începere, durata și rezultatul fiecărui job, numele standului (în parametrii jobului), etapele (pașii jobului), link la distribuția în Nexus.
- Ivan a decis să nu le includă pe Jira și BitBucket, pentru că... au fost mai mult legate de stadiul de dezvoltare, și nu de desfășurarea distribuției finite pe standuri.
Pe baza informațiilor disponibile, a fost realizată următoarea diagramă:
Știind cât timp este nevoie pentru a crea distribuții și cât timp este petrecut pentru fiecare dintre ele, puteți calcula cu ușurință costurile totale ale trecerii prin întreaga conductă DevOps (ciclu complet).
Iată valorile DevOps cu care a ajuns Ivan:
- Numărul de distribuții create
- Ponderea distribuirilor care „a venit” la stand și „au trecut” de stand
- Timp petrecut pe stand (ciclu stand)
- Ciclu complet (timp total pentru toate standurile)
- Durata jobului
- Timp de oprire între standuri
- Timp de nefuncționare între lansarea lucrărilor pe același stand
Pe de o parte, metricile au caracterizat foarte bine conducta DevOps în termeni de timp, pe de altă parte, au fost considerate foarte simple.
Mulțumit de munca bine făcută, Ivan a făcut o prezentare și a mers să o prezinte conducerii.
S-a întors mohorât și cu mâinile în jos.
„Acesta este un fiasco, frate”, a zâmbit ironic colegul...
Citiți mai multe în articolul „".
Sursa: www.habr.com