Mi, emberek szeretjük elmosni a vonalakat, az egyik ilyen próbálkozás a DevOps. Az SDLC-gyűrűben lévő DevOps-szal a dolgok másként alakultak, és mi az? Az olyan kulcsfontosságú tényezők nyomon követése, mint az alkalmazás teljesítménye, minősége és sebessége, folyamatos folyamattá válik. E mérések nélkül nehéz lehet megbízható, adatvezérelt döntéseket hozni.
De milyen skálán mérjük a teljesítményt? Jönnek a mérőszámok.
A DevOps mérőszámai biztosítják a szükséges betekintést az alkalmazkodáshoz, optimalizáláshoz és végső soron jobb szoftver gyorsabb, gyorsabb szállításához.
Ez a blog arról szól, hogy miért fontosak a DevOps mérőszámai. Különféle szempontokról is szól, amelyekre érdemes gondolni, amikor döntéseket hoznak.
Miért tartsa szemmel a DevOps mérőszámait?
A DevOps mutatóinak szemmel tartásával a következőket érheti el:
- Vizsgálja meg a hosszú távú mintákat a megfigyelhetőségre vonatkozó adatokkal.
- Konfiguráljon hasznos figyelmeztetéseket erős jellel és kis zajjal.
- Hozzon létre praktikus irányítópultokat a jelentéskészítéshez és a tervezéshez.
- Hozzon létre elérhető SLA-kat, SLO-kat és SLI-ket.
- Hozzon létre egy belső adattárat a legjobb szoftverfejlesztési gyakorlatok számára.
Jó „adatvezéreltnek” lenni, de fennáll annak a veszélye, hogy túlterheli az elemzés. Az érték kimutatásához mindössze néhány intézkedésre van szükség.
Négy alapvető DevOps-mutató a figyeléshez
A négy DevOps-mutató néven is ismert,A négy kulcsés viszonyítási alapként szolgálnak a DevOps csapat teljesítményének értékeléséhez, az alacsonytól az elitig. Az „alacsony” pontszám gyenge teljesítményt, míg az „elit” a DevOps-célok elérése felé tett kivételes előrelépést jelenti.
A Google DevOps Research and Assessment (DORA) csapata négy elsődleges mérőszámot azonosított a DevOps teljesítményének mutatójaként, sebességmérőkre (DF és CLT) és stabilitási mérőszámokra (MTTR és CFR) osztva:
A DevOps teljesítményének DORA Metrics mutatói:
- Telepítési gyakoriság (DF)
- Átfutási idő módosítása (CLT)
- Átlagos helyreállítási idő (MTTR)
- Hibaarány módosítása (CFR)
A gyakoribb üzembe helyezés, a rövidebb változtatások átfutási ideje, a kevesebb meghibásodás és a szolgáltatás gyorsabb helyreállítása mind a nagy teljesítményű csapatok jellemzői. Ez fordítva igaz az alulteljesítő csapatokra, ami eredménytelenséget és rossz ügyfélélményt eredményez.
Nézzük meg közelebbről az egyes mutatókat.
1. Telepítési gyakoriság
A kódfrissítések átmeneti vagy éles kiadásának gyakoriságát a telepítési gyakoriság méri. A DevOps csapat termelékenysége, reakcióideje, fejlesztői készségei, csapatkohéziója és eszközhatékonysága egyaránt mérhető közvetlenül vagy közvetve. A hatékony csapatok szükség szerint képesek végrehajtani a módosításokat, és ezt gyakran a nap folyamán. Ezzel szemben a gyengén teljesítő csapatok néha heti vagy havi telepítésre korlátozódnak.
Az üzembe helyezés gyakoriságát az egyes vállalatok eltérően számítják ki. Például érdemes lehet kiszámítani a telepítési gyakoriságot a sikeres folyamatfuttatásokhoz. A mérés azonban a „telepítés” definíciójától függően is változhat. Az egyes kisebb lehívási kérések vagy kódfrissítések telepítése nagy gyakoriságot eredményez. A dolgok azonban kezdenek kicsit másképp kinézni, ha a telepítést egy bizonyos idő elteltével tervezik.
Bár például a heti üzembe helyezésről a napi üzembe helyezésre való váltás azt mutatja, hogy a folyamatos üzembe helyezés hogyan javíthatja a fejlesztési folyamatot, pusztán erre a DevOps-mutatóra támaszkodva helytelen feltételezésekhez vezethet. Például, ha az előző negyedévhez képest háromról 3,3-ra növelte a napi telepítések számát, akkor technikailag 10%-kal „sikeresebb”, de ez nem jó mutatója a sikernek. Az általános fejlődés értékeléséhez további mérőszámokat kell figyelembe vennie.
Olvassa el még: 6 ok, amiért szüksége van a DevOps szolgáltatásra
2. Változtassa meg az átfutási időt
Azt az időt, amely alatt a kódmódosítás az elkötelezettről a telepítettre vált át, „módosítási időnek” nevezik. Lényegében felteszi a kérdést: „Milyen gyorsan tudunk egy kódsort módosítani és működőképessé tenni a termelésben?”
Míg egy közepesen vagy gyengén teljesítő csapat az átlagos átfutási idejét napokban, hetekben vagy akár hónapokban méri, a jól teljesítő csapatok általában órákban számítják ki az átlagos átfutási idejét. Ha a változtatások átfutási ideje nagyon hosszú, akkor a szoftverfejlesztési vagy -telepítési folyamatban teljesítménykorlátok vannak. A változtatás átfutási idejének csökkentése növeli a változó igényekre való reagálási képességét. A kis tételekben történő munkavégzés, a tesztek automatizálása és a trönk alapú fejlesztések használata egyaránt segíthet a változtatások átfutási idejének lerövidítésében.
A módosítási átfutási idő meghatározásához a lekérési kérelmek létrehozásához szükséges idő és a fő ágba való egyesítése közötti átlagos különbséget használják. A változtatások átlagos átfutási ideje 90 osztva 10-zel, ha egy hónapban 10 módosítást hajtana végre, és a véglegesítéstől az üzembe helyezésig tartó összes nap 90 lenne. Ez azt jelentené, hogy minden változtatás átlagosan 9 napot vesz igénybe.
Hónapokba telhet a termék igényeinek és kilátásainak azonosítása, de előfordulhat, hogy a kód véglegesítése csak néhány napot vesz igénybe. Ezért, bár a változtatások átfutási ideje értékes statisztika, önmagában használni naiv.
3. MTTR (átlagos helyreállítási idő)
A szolgáltatáskimaradások vagy teljes meghibásodások észlelésének és kijavításának sebességét az átlagos helyreállítási idő méri.
Míg a gyengén teljesítő csapatok egy hetet is igénybe vehetnek, mire felépülnek a rendszer meghibásodása után, a jól teljesítő csapatok gyakran kevesebb, mint egy óra alatt felépülnek. Az átlagos idő, amíg egy probléma megoldódik, az MTTR meghatározása alapján történik. Ezt az intézkedést nyomon követéssel, automatizált teszteléssel és hatékony problémakezeléssel lehet befolyásolni.
Mivel a statisztikai tervezés így vagy úgy torzíthatja a jelentést, az MTTR értékét az elmúlt években számos alkalommal megkérdőjelezték. Ezenkívül az átlagok megtévesztőek lehetnek, és elfedik a rendszerek tényleges viselkedését. Ezért próbálja meg a mértéket más mérőszámokkal együtt figyelembe venni, még akkor sem, ha nem szabad teljesen figyelmen kívül hagynia.
Fedezze fel megoldásainkat: DevOps mint szolgáltatás
4. Módosítsa a hibaarányt
A gyártás után gyorsjavítást igénylő kódmódosítások vagy -telepítések százalékos arányát változási hibaaránynak nevezzük. Egyszerűen fogalmazva: „Milyen gyakran valóban „sikeres” egy változtatás?
Ahogy a hiba előrehaladtával halad a csővezetéken keresztül, a véglegesítés előtti egységteszt meghiúsulásától a termelési leállásig, a költség vagy a kár nő. A statisztika lényegesen nehezebben mérhető, ha egy csővezeték szakasz meghibásodik, ami azt jelenti, hogy az előző szakaszok nem tudták azonosítani a problémát.
A meghibásodás tág értelemben olyan hibaként vagy problémaként definiálható, amely problémákat okoz az ügyfelek számára az éles üzembe helyezést követően. A telepítés előtt megoldott, teszteléssel azonosított problémák nem tartoznak ebbe a fontos intézkedésbe. A változási kudarcok aránya a gyengén teljesítő csapatok esetében elérheti a 60%-ot, míg a jól teljesítő csapatok esetében kevesebb, mint 15%. A változtatások meghibásodási aránya ugyanazokkal a stratégiákkal csökkenthető, amelyek csökkentik az átfutási időt, például a trönk alapú fejlesztéssel, az automatizált teszteléssel és a kis tételekben történő munkavégzéssel.
Hogyan számítsuk ki a DevOps-mutatókat?
A következő tanácsok segítenek abban, hogy a legtöbbet hozza ki a DevOps mérőszámaiból:
- Alapvonalak megállapítása: Mielőtt valóban nyomon követhetné a fejlődését vagy ünnepelhetné a győzelmeket, tudnia kell, honnan indul. Ez olyan, mintha az eredményjelzőt néznénk a játék kezdete előtt.
- Kerülje el, hogy a mérések céllá váljanak: „Amikor egy intézkedés célponttá válik, megszűnik jó intézkedés lenni” a Goodhart-törvény szerint. Fennáll a veszélye, hogy szem elől téveszti azt, ami a DevOps sikere szempontjából fontos, ha egyetlen figurához kötődik.
- Kezdje kicsiben: A versenytársak előtt maradhat új funkciók gyors hozzáadásával. Kisebb, könnyebben kezelhető kötegekben hajthat végre módosításokat vagy üzembe helyezéseket. A kisebb változtatások könnyebben érthetők, gyorsabban áthaladnak a telepítési folyamaton, és könnyebben visszavonhatók. A hiba helyreállítása is gyorsabb.
- Legyen óvatos az egyszerűséggel: Csábító lehet egyetlen, könnyen érthető mérőszámra összpontosítani, de a valóság az, hogy egyetlen figura sem képes megragadni a teljes képet. A DevOps több, mint egy statisztika; ez egy gondolkodásmód és egy utazás a szoftverfejlesztés körül.
- Tegyen igazságos összehasonlításokat: Előfordulhat, hogy a mérések nem teljesen egyeznek, ha két különböző projekt vagy akár két különböző időszak mérőszámait hasonlítja össze. A helyzetek változóak, és a kontextus döntő fontosságú.
- Nézze meg közelebbről: Válasszon olyan mutatókat, amelyek egyértelműen mutatják a csapat és a projektek értékét, még akkor is, ha egy kicsit több munkára van szükségük a figyeléshez. Egyszerű megmérni, mi van közvetlenül előtted.
- Vizsgálja meg az ügyfelek megjegyzéseit: A felhasználóknak még akkor is problémái lehetnek, ha a telepítés zökkenőmentesen megy. A DORA adatokkal nem lehet meghatározni a felhasználói boldogságot. Ha meg szeretné tudni, hogy mit kell javítani, nézze meg, mit mondanak az emberek. Mindez az értékáram-menedzsment alá tartozik.
- Keresse a problémák trendjeit: Folyamatosan ugyanazok a nehézségek jönnek elő? Ez komolyabb, odafigyelést igénylő problémákra utalhat.
- Tartsa szemmel a közeli baleseteket: Nem csak a felmerült problémákat, hanem azokat is, amelyek majdnem megtörténtek. Sokat tanulhat tőlük arról, hogyan kerülheti el a szoftverszállítási problémákat a jövőben.
- Költségcsökkentés nyomon követése: Mutassa be, hogyan csökkenti a DevOps a költségeket vagy akadályozza meg a további kiadásokat. Költségvetését ez indokolja.
- Az állásidő csökkentése: Azt szeretné, ha rendszere mindig működőképes maradna, mert az állásidő ronthatja cége hírnevét és bevételkiesést eredményezhet. Tegyen meg mindent, hogy távol maradjon tőle.
Hogyan értelmezik a DevOps mérőszámait?
Ügyesen kell kezelnie a DevOps-metrikák használata során gyűjtött statisztikákat. Ha nem vagy éber, az átlagok könnyen félrevezethetnek. Ahogyan egy kiugró érték torzíthatja az észleléseket, az is, ha csak az átlagokra hagyatkozik a következtetések levonásakor, az elhomályosíthatja az adatok valódi eloszlását.
Gondoljon arra, hogy kiküszöböli adataiból a kiugró értékeket. A hétköznapi teljesítményről alkotott felfogását eltorzíthatják ezek az extrém számadatok. Ez nem lehet a szokásos üzembe helyezési idő, például, ha egy központi telepítés sokkal tovább tart, mint a többi, váratlan problémák miatt.
Az adatgyűjtő-kezelés is előnyös lehet. Ehhez a kapcsolódó adattípusokat csoportosítják, így a csoportosításokon belüli minták megvizsgálhatók. Például az átfutási idők kiszámításakor tartsa távol egymástól a hibajavításokat és az új funkciók telepítését. Ez lehetővé teszi annak meghatározását, hogy az egyik típus rutinszerűen hosszabb ideig tart-e, mint a másik, és miért.
Végül, nem utolsósorban, folyamatosan kérdőjelezd meg az adataidból levont következtetéseket. Milyen narratívát árulnak el a tények? Mi lehet a kihagyása? Például a változtatási sikertelenségi arány drámai javulása azt jelzi, hogy a telepítések valóban megbízhatóbbak, vagy ritkábban telepíti, ami csökkenti a sikertelenség esélyét?
Ha több időt és energiát fektet be a termékfejlesztés korai szakaszaiba, az csökkenti a problémák valószínűségét a telepítés során. Tekintsd úgy, mint egy hajó szivárgásának javítását, amikor az még kiköt, nem pedig a tengeren. Ez a proaktív stratégia garantálja, hogy terméke megbízható és gyorsabban használható legyen, miközben időt takarít meg. Ne feledje azonban, hogy a DevOps csapata nem tudja közvetlenül befolyásolni a termék teljesítményének minden területét. Értékük ellenére a DORA mérések alkalmanként olyan elemeket tárnak fel, amelyek közvetlen ellenőrzésen kívül esnek, mint például az általános vállalati eljárások vagy a döntéshozatali ütemtervek. Például elkerülhetetlenül megnőne az átfutási idő, ha vállalkozásának olyan szabályzata lenne, amely alapos biztonsági ellenőrzést ír elő a bevezetés előtt.
Nézze meg: Zuci összefog a globális felhőalapú tesztplatform-szolgáltatóval, a Sauce Labs-szal
Az ésszerű célok kitűzését segíti, ha megérti annak határait, amit közvetlenül befolyásolhat. Megpróbálhatja például egyszerűsíteni a telepítési folyamat egyéb szempontjait, hogy pótolja az elveszett időt, még akkor is, ha esetleg nem tudja felgyorsítani a vállalat által előírt biztonsági ellenőrzéseket.
A DevOps metrikák jobb mérése A DORA hasznos keretet kínál a technológiai szolgáltatások fejlesztésének és kezelésének javításához, különösen, ha a Kubernetesre való váltáson gondolkodik.
Ezt azonban az Ön helyzetéhez kell igazítani, más mérőszámokkal együtt kell használni, egyetlen pillanatnak kell tekinteni, és nem kell manipulálni.
E kulcsfontosságú DevOps KPI-k átfogó célja a folyamat teljesítményének meghatározása és a fejlesztendő területek meghatározása.
