Őszintén szólva, Iván gyakran nevetett a monitoring osztály kollégáinak hiábavaló erőfeszítésein. Óriási munkát végeztek azzal, hogy a cég vezetése által rendelt metrikákat megvalósítsák. Olyan elfoglaltak voltak, hogy senkivel nem akartak többet foglalkozni.
A vezetés pedig sosem volt elégedett – folyamatosan újabb és újabb metrikákat rendelt, nagyon gyorsan abbahagyva a korábban elkészítettekkel való foglalkozást.
Az utóbbi időben mindenki csak a LeadTime-ról beszélt – az üzleti funkciók szállítási idejéről. A metrika őrületes számokat mutatott – 200 nap a feladat szállítására. Micsoda felháborodás volt, mindenki az eget bámulta!
Néhány idő elteltével a zűrzavar fokozatosan elcsendesedett, és a vezetés újabb metrika létrehozására tett javaslatot.
Iván számára egyértelmű volt, hogy az új metrika is csendben meghal majd a sötét sarokban.
Valóban, gondolta Iván, a szám ismerete senkinek nem jelent semmit. 200 nap vagy 2 nap – nincs különbség, mert szám alapján nem lehet meghatározni az okot és megérteni, hogy ez jó vagy rossz.
Ez a metrikák tipikus csapdája: úgy tűnik, hogy az új metrika felfedi az élet lényegét és megmagyarázza a titkos titkot. Mindenki reménykedik benne, de valamiért semmi sem történik. Mert a titkot nem a metrikákban kell keresni!
Iván számára ez egy korábbi tapasztalat volt. Tudta, hogy az mérésekhez, és hogy minden titkot az , azaz abban kell keresni, ami ezt a metrikát kialakítja.
Egy online bolt esetében a hatás tárgya az ügyfelek, akik pénzt hoznak, míg a DevOps esetében a csapatok, akik disztribúciókat hoznak létre és telepítenek a csővezeték használatával.
Egyszer Iván, kényelmesen elhelyezkedve a hallban egy kényelmes fotelben, úgy döntött, hogy alaposan átgondolja, hogyan szeretné látni a DevOps metrikákat figyelembe véve, hogy a hatás tárgya a csapatok.
A DevOps metrikák célja
Nyilvánvaló, hogy mindenkinek csökkenteni szeretné a szállítási időt. 200 nap – ez természetesen elfogadhatatlan.
De hogyan, ez itt a kérdés?
A cégnél száz csapat dolgozik, és naponta több ezer disztribúció halad át a DevOps csővezetéken. A valós szállítási idő eloszlásként fog kinézni. Minden csapatnak saját ideje és saját sajátosságai lesznek. Hogyan lehet bármit is találni ebben a zűrzavarban?
A válasz magától jött – meg kell találni a problémás csapatokat, és megérteni, mi történik velük és miért tart ilyen sokáig, valamint a "jó" csapatoktól tanulni, hogyan lehet mindent gyorsan csinálni. Ehhez meg kell mérni az időt, amit a csapatok a DevOps standokon töltenek:
A rendszer célja a csapatok időalapú kiválasztása lesz, azaz végül egy kiválasztott idővel rendelkező csapatok listáját kell kapnunk, nem csupán számokat.
Ha megtudjuk, mennyi időt töltöttek összesen a standon, és mennyi időt töltöttek a standok közötti leállásokkal, akkor megkereshetjük a csapatokat, felhívhatjuk őket, és részletesen megérthetjük az okokat, és elháríthatjuk azokat – gondolta Ivan.
Hogyan kell kiszámítani a szállítási időt a DevOps számára
A számításhoz mélyebbre kellett ásni a DevOps folyamatában és annak lényegében.
A cégnél korlátozott számú rendszer használatos, és az információt csak ezekből lehet beszerezni, és sehonnan máshonnan.
Minden feladatot a cégben a Jirában regisztráltak. Amikor egy feladatot munkába vettek, létrehozták hozzá a branchet, majd a megvalósítás után commitoltak a BitBucketre és Pull Requestet készítettek. A PR (Pull Request) elfogadása után automatikusan létrejött egy disztribúció, amelyet a Nexus tárolóba mentettek.
Ezután a disztribúciót Jenkins segítségével több standon telepítették, hogy ellenőrizzék a telepítés helyességét, automatikus és manuális tesztelést végezzenek:
Ivan leírta, hogy mely rendszerekből milyen információt lehet beszerezni az idő számításához a standokon:
- A Nexusból – a disztribúció létrehozási ideje és a mappa neve, amelyben a csapat kódja található
- A Jenkinstől – a munka indításának ideje, a munka tartama és az eredmény, a stand neve (a munka paramétereiben), egyes stádiumok (a munka lépései), hivatkozás a disztribúcióra a Nexusból.
- Ivan úgy döntött, hogy a Jirát és a BitBuckettet nem vonja be a folyamatba, mivel azok inkább a fejlesztési szakaszhoz tartoztak, nem pedig a kész disztribúció standokon való átviteléhez.
A rendelkezésre álló információk alapján a következő ábrát rajzolták:
Tudva, mennyi idő a disztribúciók létrehozása és mennyi időt töltenek minden egyes disztribúcióra, könnyen kiszámítható a teljes költség a DevOps csővonal átvitelére (teljes ciklus).
Itt vannak azok a DevOps-metrikák, amelyeket Ivan végül kapott:
- Létrehozott disztribúciók száma
- A standra „bejövő” és a standon „átmenő” disztribúciók aránya
- A standon töltött idő (stand ciklus)
- Teljes ciklus (összes stand összesített időtartama)
- A munkafolyamatok időtartama
- Félidő a standok között
- Félidő a munkafolyamatok indításai között egy standon
Egyrészt a metrikák nagyon jól jellemezték a DevOps folyamatot az idő szempontjából, másrészt pedig túl egyszerűen számolták.
Boldogan, hogy jól végezte a munkát, Iván előadást készített, és elindult bemutatni azt a vezetőségnek.
Visszafele borongós arccal és lehorgasztott karokkal jött ki.
— Ez egy kudarccal végződés, testvér — mosolygott ironikusan a kolléga...
A folytatást olvasd el a "».
Forrás: habr.com
