Hogy őszinte legyek, Ivan gyakran nevetett a megfigyelő osztály kollégáinak hiábavaló erőfeszítésein. Nagy erőfeszítéseket tettek annak érdekében, hogy megvalósítsák azokat a mutatókat, amelyeket a vállalat vezetése elrendelt. Annyira elfoglaltak voltak, hogy nem akarták, hogy bárki más csináljon semmit.
De ez nem volt elég a vezetőségnek - folyamatosan újabb és újabb mérőszámokat rendeltek el, és nagyon gyorsan felhagytak azzal, amit korábban csináltak.
Az utóbbi időben mindenki a LeadTime-ról beszél – az üzleti szolgáltatások szállításának idejéről. A mérőszám őrült számot mutatott – 200 nap egy feladat elvégzésére. Hogy mindenki üvöltött és áhítozott, és az ég felé emelte a kezét!
Egy idő után a zaj fokozatosan elült, és a vezetőség utasítást kapott egy újabb mérőszám létrehozására.
Iván számára teljesen világos volt, hogy az új mérőszám ugyanolyan csendesen el fog halni egy sötét sarokban.
Valóban, gondolta Ivan, a szám ismerete senkinek sem mond semmit. 200 nap vagy 2 nap - nincs különbség, mert lehetetlen meghatározni az okot a szám alapján, és megérteni, hogy ez jó vagy rossz.
Ez a mérőszámok tipikus csapdája: úgy tűnik, hogy egy új mérőszám elmondja a létezés lényegét, és megmagyaráz valami titkos titkot. Mindenki nagyon remél ebben, de valamiért nem történik semmi. Igen, mert a titkot nem a mérőszámokban kell keresni!
Ivan számára ez egy túlhaladott szakasz volt. Ezt megértette mérésekhez, és minden titkot meg kell keresni , azaz az, hogy ez a mérőszám kialakul.
Egy online áruház esetében a befolyás tárgya az ügyfelek, akik pénzt hoznak, a DevOps esetében pedig azok a csapatok, amelyek egy folyamat segítségével disztribúciókat készítenek és vezetnek be.
Egy nap, amikor leült egy kényelmes székre a hallban, Ivan úgy döntött, alaposan átgondolja, hogyan szeretné látni a DevOps mérőszámait, figyelembe véve azt a tényt, hogy a befolyás tárgya a csapatok.
A DevOps-metrikák célja
Nyilvánvaló, hogy mindenki csökkenteni akarja a szállítási időt. 200 nap persze nem jó.
De hogyan, ez itt a kérdés?
A vállalat több száz csapatot foglalkoztat, és naponta több ezer disztribúció megy keresztül a DevOps folyamaton. A tényleges szállítási idő elosztásként jelenik meg. Minden csapatnak megvan a maga ideje és sajátosságai. Hogyan találhat bármit is ebben a káoszban?
A válasz természetesen felmerült – meg kell találnunk a problémás csapatokat, ki kell derítenünk, mi történik velük, és miért tart olyan sokáig, és tanulnunk kell a „jó” csapatoktól, hogyan kell mindent gyorsan megtenni. Ehhez pedig meg kell mérnie a csapatok által a DevOps lelátókon eltöltött időt:
„A rendszer célja az lesz, hogy a lelátón való áthaladási idő alapján válasszuk ki a csapatokat, azaz. Ennek eredményeként a parancsok listáját kell kapnunk a kiválasztott idővel, nem pedig számmal.
Ha megtudjuk, hogy összesen mennyi időt töltöttek a lelátón és mennyit a leállások között a lelátók között, akkor megkereshetjük a csapatokat, felhívhatjuk őket és részletesebben megérthetjük az okokat és megszüntethetjük” – vélekedett Ivan.
Hogyan számítsuk ki a DevOps szállítási idejét
Kiszámításához el kellett mélyedni a DevOps folyamatban és annak lényegében.
A cég korlátozott számú rendszert használ, információt csak ezekből lehet szerezni, máshol nem.
A cég minden feladatát Jira-ban regisztrálták. Amikor egy feladatot elvállaltak, egy ágat hoztak létre hozzá, majd az implementációt követően a BitBucket és a Pull Request commit. Amikor egy PR (Pull Request) elfogadásra került, a rendszer automatikusan létrehozta a disztribúciót, és azt a Nexus tárolójában tárolta.
Ezt követően a disztribúciót több standon is kihelyezték a Jenkins segítségével, hogy ellenőrizzék a közzététel helyességét, valamint az automatikus és manuális tesztelést:
Iván leírta, hogy mely rendszerekből milyen információk vehetők a lelátókon eltöltött idő kiszámításához:
- Nexusról – A terjesztés létrehozásának ideje és a parancskódot tartalmazó mappa neve
- Jenkinstől – Az egyes munkák kezdési ideje, időtartama és eredménye, stand neve (a munka paraméterei között), szakaszok (munkalépések), link a Nexusban való terjesztéshez.
- Ivan úgy döntött, hogy nem veszi be a Jira-t és a BitBucket-et, mert... inkább a fejlesztési szakaszhoz kapcsolódtak, nem pedig a kész disztribúció standokon való kiterítéséhez.
A rendelkezésre álló információk alapján a következő diagram készült:
Tudva, hogy mennyi időt vesz igénybe a disztribúciók létrehozása, és mennyi időt fordítanak rájuk, könnyen kiszámíthatja a teljes DevOps folyamat (teljes ciklus) áthaladásának teljes költségét.
Íme a DevOps mérőszámok, amelyeket Ivan végzett:
- Létrehozott disztribúciók száma
- Azon disztribúciók aránya, amelyek „érkeztek” a standra, és „áthaladtak” a standon
- Az állványon eltöltött idő (stand ciklus)
- Teljes ciklus (összes idő az összes standnál)
- A munka időtartama
- Leállás a lelátók között
- Állásidő a munkák elindítása között ugyanazon a standon
A mérőszámok egyrészt időben nagyon jól jellemezték a DevOps pipeline-t, másrészt nagyon egyszerűnek tartották őket.
Ivan elégedett volt a jól végzett munkával, és prezentációt tartott, és elment a vezetőség elé.
Komoran és lehajtott kézzel tért vissza.
„Ez egy fiaskó, tesó” – mosolygott az ironikus kolléga...
Bővebben a cikkben "".
Forrás: will.com