(Koha deri në Treg).
Neven gjatë fundjavave ai mendonte për metrikat: «E çfarë, nëse e mas kohën? Çfarë do të më sjellë kjo?»
Me të vërtetë, çfarë ka përfituar nga njohuria e kohës? Supozoni se dërgimi zgjat 5 ditë. Dhe çfarë pastaj? A është mirë apo keq? Pavarësisht se është keq, duhet ndonjëherë ta pakësojmë këtë kohë. Por si?
Këto mendime nuk i jepnin paqe, por zgjidhja nuk po vinte.
Ivan e kuptonte se kishte arritur në thelb. Grafikat e pafundme të metrikave që kishte parë deri tani e kishin bindur se qasja standarde nuk do të funksiononte, dhe se nëse thjesht ndërtonte një graf (), nuk do të kishte asnjë dobi.
Çfarë të bëj?…
Metrika është si një linjë druri e zakonshme. Masat e bëra me ndihmën e saj nuk do të thonë arsyen, pse përse objekti i matur është pikërisht gjatësi e asaj që ajo tregoi. Linja thjesht do të tregojë madhësinë e saj, dhe asgjë më shumë. Ajo nuk është një gur filozofik, por thjesht një copë druri që përdoret për të matur.
«Nderi i çelikut» i shkrimtarit të tij të preferuar Harry Harrison gjithmonë thoshte: mendimi duhet të arrijë në fund të trurit dhe atje të qëndrojë, kështu që pas disa ditësh pa rezultat, Ivan vendosi të merret me një detyrë tjetër…
Pas disa ditësh, duke lexuar një artikull mbi dyqanet online, Ivan papritmas kuptoi se shuma e parave që merr një dyqan online varet nga sjellja e vizitorëve të faqes. Pikërisht ata, vizitorët/klientët, u japin dyqanit paratë e tyre dhe janë burimi i tyre. Hyrjet në shumën përfundimtare të parave që merr dyqani ndikojnë ndryshimet në sjelljen e klientëve, dhe asgjë tjetër.
Ishte e qartë se për të ndryshuar vlerën e matur, duhej të ndikoheshin ata që formojnë atë vlerë, dmth. për të ndryshuar shumën e parave të dyqanit online, duhej të ndikoheshin sjelljet e klientëve të këtij dyqani, dhe për të ndryshuar kohën e dërgimit në DevOps, duhej të ndikoheshin ekipet që krijojnë atë kohë, dmth. ata që përdorin DevOps në punën e tyre.
Ivan e kuptoi se metrikat DevOps nuk duhet të përfaqësonin aspak grafika. Ato duhet të përfaqësonin një mjet kërkimi për të gjetur ekipet «të shkëlqyera» që formojnë kohën e përfundimtare të dërgimit.
As Ivan thought, no metric will ever show the reason why a certain team took so long to deliver a distribution. In reality, there can be a million and one reasons, and they may not be technical but organizational. That is, the most one can hope to get from metrics is the performance of teams and their results, and then one will still have to go to these teams in person to figure out what went wrong.
On the other hand, in Ivan's company, there was a standard requiring all teams to test builds on several stands. A team could not move on to the next stand until the previous one was passed. Thus, if you imagine the DevOps process as a sequence of passing stands, metrics could show the time teams spent at these stands. Knowing the stand and the team's time, one could talk more specifically with them about the reasons.
Without much thought, Ivan picked up the phone and dialed the number of a person well-versed in the ins and outs of DevOps:
— Denis, can you tell me if there’s a way to understand that a team has passed a certain stand?
— Of course. Our Jenkins drops a flag if the build has been successfully rolled out (passed the check) on the stand.
— Super. And what is a flag?
— It’s a regular text file like "stand_OK" or "stand_FAIL" that indicates whether the build passed or failed the stand. You got it, right?
— Basically, yes. Is it written in the same folder in the repository where the build is stored?
— Yes.
— What happens if the build fails the stand? Will I need to create a new build?
— Yep.
— Alright, thanks. And one more question: do I correctly understand that I can use the date of the flag creation as the date for passing the stand?
— Absolutely!
— Great!
Inspired, Ivan hung up and realized that everything fell into place. Knowing the creation date of the build file and the creation dates of the flags, it was possible to calculate with precision down to the second how much time teams spent on each stand and understand where they spent the most time.
"Understanding where the most time goes, we will pinpoint the teams, approach them, and dig into the problem." Ivan smiled.
For tomorrow, he set himself the task of sketching the architecture of the emerging system.
To be continued...
Burimi: habr.com
