(Time-To-Market).
Chiar și în weekend, se gândea la metrici: „Ei bine, ce dacă măsor timpul? Ce îmi va aduce asta?”.
Într-adevăr, ce va aduce cunoașterea timpului? Să presupunem că livrarea durează 5 zile. Și ce mai departe? Este bine sau rău? Chiar dacă este rău, tot trebuie să reducem cumva acest timp. Dar cum?
Aceste gânduri nu-i ofereau liniște, dar soluția nu venea.
Ivan înțelegea că a ajuns la esență. Numeroasele grafice de metrici pe care le văzuse anterior l-au convins de mult că abordarea standard nu va funcționa și că, dacă doar construiești un grafic (), nu va avea niciun efect.
Ce să facă?…
O metrică este ca o riglă de lemn obișnuită. Măsurătorile efectuate cu ajutorul acesteia nu vor spune motivul, de ce pentru care obiectul măsurat are exact lungimea arătată. Rigla va arăta doar dimensiunea sa și atât. Nu este o piatră filosofală, ci doar o bucată de lemn folosită pentru măsurare.
„Șoarecele din oțel inoxidabil” al autorului său preferat, Harry Harrison, spunea întotdeauna: gândul trebuie să ajungă la fundul creierului și să stea acolo, așa că, fără a obține rezultate după câteva zile de zbucium, Ivan a decis să se ocupe de o altă task...
După câteva zile, citind un articol despre magazinele online, Ivan a realizat brusc că suma de bani pe care o primește un magazin online depinde de comportamentul vizitatorilor site-ului. Exact ei, vizitatorii/clienții, îi oferă magazinului banii lor și sunt sursa acestora. Se pare că suma de bani obținută de magazin este influențată de schimbările în comportamentul clienților, nu de altceva.
Se dovedea că, pentru a schimba o mărime măsurată, trebuia să influențăm pe cei care formează acel indicator, adică pentru a schimba suma de bani a unui magazin online, era necesar să influențăm comportamentul clienților acestuia, iar pentru a schimba timpul de livrare în DevOps era necesar să influențăm echipele care „creează” acest timp, adică folosesc DevOps în activitatea lor.
Ivan a realizat că metricile DevOps nu trebuie să fie doar grafice. Ele ar trebui să reprezinte un instrument de căutare a echipelor „excepționale”, care formează timpul de livrare final.
Nici o metrică nu va arăta vreodată motivul pentru care o echipă a livrat o distribuție o perioadă lungă de timp, se gândea Ivan, deoarece în realitate pot exista milioane de motive, iar unele dintre ele ar putea fi complet ne-tehnice, ci organizaționale. Adică, maximul pe care te poți aștepta să-l obții de la metrici este performanța echipelor și rezultatele acestora, iar apoi va trebui să mergi personal la aceste echipe și să descoperi ce s-a întâmplat.
Pe de altă parte, în compania lui Ivan exista un standard care obliga toate echipele să verifice construcțiile pe mai multe standuri. O echipă nu putea trece la următorul stand până când nu finaliza precedentul. Rezulta că, dacă am prezenta procesul DevOps ca o succesiune de treceri prin standuri, metricile ar putea arăta timpul petrecut de echipe la aceste standuri. Știind standul și timpul echipei, se putea discuta mai concret cu ea despre motive.
Fără să stea pe gânduri, Ivan a ridicat receptorul și a completat numărul unei persoane care înțelegea bine detaliile DevOps:
— Denis, poți să-mi spui, te rog, dacă există vreo modalitate de a înțelege că o echipă a trecut printr-un stand anume?
— Desigur. Jenkins-ul nostru elimină un steag dacă construcția a fost implementată cu succes (a trecut testul) pe stand.
— Super. Și ce este un steag?
— Este un fișier text obișnuit de tipul «stand_OK» sau «stand_FAIL», care indică dacă construcția a trecut sau nu standul. Înțelegi, da?
— În principiu, da. Se scrie în aceeași folder în stocare unde se află construcția?
— Da.
— Și ce se întâmplă dacă construcția nu trece standul? Va trebui să fac o nouă construcție?
— Aha.
— Bine, mulțumesc. Și încă o întrebare: înţeleg corect că voi putea folosi data creării steagului ca dată a trecerii prin stand?
— Absolut!
— Super!
Încântat, Ivan a pus receptorul jos și a realizat că totul s-a așezat la locul său. Cunoașterea datei creării fișierului de construcție și a datelor creării steagurilor permitea calcularea cu o precizie de o secundă a timpului pe care echipele îl petrec pe fiecare stand și înțelegerea unde își pierd cel mai mult timp.
«Înțelegând unde se pierde cel mai mult timp, putem identifica echipele precise, merge la ele și să aprofundăm problema». Ivan a zâmbit.
Pentru a două zi, și-a stabilit sarcina de a schița arhitectura sistemului emergent.
Continuarea urmează...
Sursa: habr.com
