Abych byl upřímný, Ivan se často smál marnému úsilí svých kolegů z oddělení monitoringu. Vynaložili velké úsilí na implementaci metrik, které jim vedení společnosti nařídilo dosáhnout. Byli tak zaneprázdnění, že nechtěli, aby někdo jiný něco dělal.
Ale managementu to nestačilo – neustále objednávali stále nové a nové metriky a velmi rychle přestali používat to, co se dělalo dříve.
V poslední době všichni mluví o LeadTime – době pro poskytování obchodních funkcí. Metrika ukazovala šílené číslo – 200 dní na splnění jednoho úkolu. Jak všichni ooh a aah a zvedli ruce k nebi!
Po nějaké době hluk postupně utichl a management dostal příkaz k vytvoření další metriky.
Ivanovi bylo naprosto jasné, že nová metrika stejně tiše zemře v temném koutě.
Opravdu, pomyslel si Ivan, znalost čísla nikomu vůbec nic neříká. 200 dní nebo 2 dny - není žádný rozdíl, protože není možné určit důvod podle čísla a pochopit, zda je to dobré nebo špatné.
Toto je typická past metrik: zdá se, že nová metrika prozradí podstatu existence a vysvětlí nějaké tajné tajemství. Všichni v to tolik doufají, ale z nějakého důvodu se nic neděje. Ano, protože tajemství by nemělo být nalezeno v metrikách!
Pro Ivana to byla prošlá fáze. Rozuměl tomu pro měření a všechna tajemství je třeba hledat v , tj. je, že tato metrika je tvořena.
Pro internetový obchod budou objektem vlivu jeho klienti, kteří přinášejí peníze, a pro DevOps to budou týmy, které vytvářejí a zavádějí distribuce pomocí potrubí.
Jednoho dne se Ivan posadil do pohodlného křesla v hale a rozhodl se pečlivě promyslet, jak chce vidět metriky DevOps, přičemž vzal v úvahu skutečnost, že objektem vlivu jsou týmy.
Účel DevOps Metrics
Je jasné, že každý chce zkrátit dobu dodání. 200 dní je samozřejmě k ničemu.
Ale jak, toť otázka?
Společnost zaměstnává stovky týmů a každý den procházejí potrubím DevOps tisíce distribucí. Skutečná dodací lhůta se zobrazí jako distribuce. Každý tým bude mít svůj vlastní čas a své vlastní charakteristiky. Jak můžete mezi tím nepořádkem něco najít?
Odpověď vyvstala přirozeně – musíme najít problémové týmy a zjistit, co se s nimi děje a proč to trvá tak dlouho, a naučit se od „dobrých“ týmů, jak vše udělat rychle. A k tomu je potřeba měřit čas strávený týmy na každém ze stánků DevOps:
„Smyslem systému bude výběr týmů na základě času, kdy projdou tribuny, tzn. V důsledku toho bychom měli dostat seznam příkazů s vybraným časem, nikoli číslo.
Pokud zjistíme, kolik času se na tribuně celkem strávilo a kolik času se věnovalo prostojům mezi tribunami, můžeme týmy najít, zavolat jim a podrobněji pochopit důvody a odstranit je,“ zamyslel se Ivan.
Jak vypočítat dodací lhůtu pro DevOps
Pro jeho výpočet bylo nutné ponořit se do procesu DevOps a jeho podstaty.
Společnost používá omezený počet systémů a informace lze získat pouze z nich a nikde jinde.
Všechny úkoly ve firmě byly evidovány v Jira. Když byl úkol přijat, byla pro něj vytvořena větev a po implementaci byl proveden commit do BitBucket a Pull Request. Když byl přijat PR (Pull Request), distribuce byla automaticky vytvořena a uložena v úložišti Nexus.
Dále byla distribuce spuštěna na několika stojanech pomocí Jenkins pro kontrolu správnosti zavedení, automatické a ruční testování:
Ivan popsal, z jakých systémů lze čerpat informace pro výpočet času na stáncích:
- From Nexus – Čas vytvoření distribuce a název složky, která obsahovala kód příkazu
- Od Jenkinse – Čas zahájení, trvání a výsledek každé úlohy, název stánku (v parametrech úlohy), fáze (kroky úlohy), odkaz na distribuci v Nexusu.
- Ivan se rozhodl nezahrnout Jiru a BitBucket do procesu, protože... souvisely spíše s vývojovou fází, a ne s vyvalováním hotové distribuce na stojanech.
Na základě dostupných informací byl nakreslen následující diagram:
Když víte, jak dlouho trvá vytvoření distribucí a kolik času je stráveno na každé z nich, můžete snadno spočítat celkové náklady na průchod celým potrubím DevOps (celý cyklus).
Zde jsou metriky DevOps, se kterými Ivan skončil:
- Počet vytvořených distribucí
- Podíl distribucí, které „přišly“ ke stánku a „prošly“ stánkem
- Čas strávený na stojanu (cyklus stojanu)
- Celý cyklus (celkový čas pro všechny stojany)
- Délka zaměstnání
- Prostoje mezi stojany
- Prostoje mezi spuštěním úlohy na stejném stojanu
Na jednu stranu metriky charakterizovaly plynovod DevOps velmi dobře z hlediska času, na druhou stranu byly považovány za velmi jednoduché.
Ivan, spokojený s dobře odvedenou prací, udělal prezentaci a šel ji prezentovat vedení.
Vrátil se zachmuřený a se svěšenýma rukama.
"To je fiasko, brácho," usmál se ironický kolega...
Více se dočtete v článku “".
Zdroj: www.habr.com