Úprimne povedané, Ivan sa často smial z márnej snahy svojich kolegov z oddelenia monitoringu. Vynaložili veľké úsilie na implementáciu metrík, ktoré im vedenie spoločnosti nariadilo dosiahnuť. Boli takí zaneprázdnení, že nechceli, aby niekto iný niečo robil.
Ale manažmentu to nestačilo – neustále objednávali nové a nové metriky a veľmi rýchlo prestali používať to, čo bolo urobené predtým.
V poslednej dobe každý hovorí o LeadTime – čase na poskytovanie obchodných funkcií. Metrika ukazovala šialené číslo – 200 dní na dodanie jednej úlohy. Ako všetci ooh a aah a zdvihli ruky k nebu!
Po určitom čase hluk postupne utíchol a manažment dostal príkaz na vytvorenie ďalšej metriky.
Ivanovi bolo úplne jasné, že nová metrika rovnako potichu zomrie v tmavom kúte.
Naozaj, pomyslel si Ivan, znalosť čísla nikomu nič nehovorí. 200 dní alebo 2 dni - nie je žiadny rozdiel, pretože nie je možné určiť dôvod podľa čísla a pochopiť, či je to dobré alebo zlé.
Toto je typická pasca metrík: zdá sa, že nová metrika prezradí podstatu existencie a vysvetlí nejaké tajné tajomstvo. Všetci v to veľmi dúfajú, ale z nejakého dôvodu sa nič nedeje. Áno, pretože tajomstvo by sa nemalo nájsť v metrikách!
Pre Ivana to bola prekonaná etapa. Pochopil to na merania a treba hľadať všetky tajomstvá , t.j. je, že táto metrika je vytvorená.
Pre internetový obchod budú objektom vplyvu jeho klienti, ktorí prinášajú peniaze, a pre DevOps to budú tímy, ktoré vytvárajú a zavádzajú distribúcie pomocou potrubia.
Jedného dňa sa Ivan posadil do pohodlného kresla v hale a rozhodol sa dôkladne premyslieť, ako chce vidieť metriky DevOps, berúc do úvahy skutočnosť, že objektom vplyvu sú tímy.
Účel metrík DevOps
Je jasné, že každý chce skrátiť dodaciu dobu. 200 dní samozrejme nie je dobré.
Ale ako, to je otázka?
Spoločnosť zamestnáva stovky tímov a každý deň prechádzajú cez plynovod DevOps tisíce distribúcií. Skutočný čas dodania sa zobrazí ako distribúcia. Každý tím bude mať svoj vlastný čas a svoje vlastné charakteristiky. Ako môžete medzi týmto neporiadkom niečo nájsť?
Odpoveď sa objavila prirodzene – musíme nájsť problémové tímy a zistiť, čo sa s nimi deje a prečo to trvá tak dlho, a naučiť sa od „dobrých“ tímov, ako robiť všetko rýchlo. Aby ste to dosiahli, musíte zmerať čas strávený tímami na každom z DevOps stánkov:
“Účelom systému bude výber tímov na základe času, ktorý prejdú tribúnami, t.j. V dôsledku toho by sme mali dostať zoznam príkazov so zvoleným časom a nie číslo.
Ak zistíme, koľko času sa na tribúne celkovo strávilo a koľko času sa venovalo prestojom medzi stánkami, budeme vedieť tímy nájsť, zavolať im a podrobnejšie pochopiť dôvody a odstrániť ich,“ zamyslel sa Ivan. .
Ako vypočítať čas doručenia pre DevOps
Na jej výpočet bolo potrebné ponoriť sa do procesu DevOps a jeho podstaty.
Spoločnosť používa obmedzený počet systémov a informácie je možné získať iba z nich a nikde inde.
Všetky úlohy v spoločnosti boli zaregistrované v Jire. Keď bola úloha prevzatá, bola pre ňu vytvorená vetva a po implementácii bol vykonaný commit do BitBucket a Pull Request. Po prijatí PR (Pull Request) sa automaticky vytvorila distribúcia a uložila sa do úložiska Nexus.
Ďalej bola distribúcia zavedená na niekoľkých stojanoch pomocou Jenkinsa na kontrolu správnosti zavedenia, automatického a manuálneho testovania:
Ivan opísal, z ktorých systémov je možné čerpať informácie na výpočet času na stojanoch:
- From Nexus – Čas vytvorenia distribúcie a názov priečinka, ktorý obsahoval kód príkazu
- Od Jenkinsa – Čas začiatku, trvanie a výsledok každej úlohy, názov stánku (v parametroch úlohy), fázy (kroky úlohy), odkaz na distribúciu v Nexuse.
- Ivan sa rozhodol nezaradiť Jiru a BitBucket do procesu, pretože... súviseli skôr s vývojovou fázou, a nie s vysunutím hotovej distribúcie na stojany.
Na základe dostupných informácií bol nakreslený nasledujúci diagram:
Keď viete, ako dlho trvá vytvorenie distribúcií a koľko času sa strávi na každej z nich, môžete jednoducho vypočítať celkové náklady na prechod celého potrubia DevOps (celý cyklus).
Tu sú metriky DevOps, s ktorými Ivan skončil:
- Počet vytvorených distribúcií
- Podiel distribúcií, ktoré „prišli“ do stánku a „prešli“ stánkom
- Čas strávený na stojane (cyklus stojana)
- Celý cyklus (celkový čas pre všetky stojany)
- Trvanie práce
- Prestoje medzi stojanmi
- Prestoje medzi spustením úloh na rovnakom stojane
Na jednej strane metriky charakterizovali plynovod DevOps veľmi dobre z hľadiska času, na druhej strane boli považované za veľmi jednoduché.
Ivan spokojný s dobre vykonanou prácou urobil prezentáciu a išiel ju odprezentovať vedeniu.
Vrátil sa zachmúrený a so spustenými rukami.
"Toto je fiasko, braček," usmial sa ironický kolega...
Prečítajte si viac v článku “".
Zdroj: hab.com