A DevOps helyzete Oroszországban 2020

Egyáltalán hogyan érti valaminek az állapotát?

Támaszkodhat véleményére, amely különféle információforrásokból, például webhelyeken megjelent publikációkból vagy tapasztalatokból alakult ki. Megkérdezheti kollégáit és barátait. Egy másik lehetőség a konferenciák témáinak áttekintése: a programbizottság a szakma aktív képviselői, így rájuk bízzuk a releváns témák kiválasztását. Külön terület a kutatás és a jelentések. De van egy probléma. A DevOps állapotáról évente kutatnak szerte a világon, jelentéseket tesznek közzé külföldi cégek, az orosz DevOpsról pedig szinte semmi információ.

De eljött a nap, amikor egy ilyen vizsgálatot végeztek, és ma elmondjuk Önnek a kapott eredményeket. A DevOps oroszországi állapotát a vállalatok közösen tanulmányozták "Expressz 42"És"Ontiko" Az Express 42 vállalat segít a technológiai vállalatoknak a DevOps gyakorlatok és eszközök bevezetésében és fejlesztésében, és az elsők között beszélt a DevOps-ról Oroszországban. A tanulmány szerzői, Igor Kurochkin és Vitaly Habarov az Express 42-nél elemzésekkel és tanácsadással foglalkoznak, működési műszaki háttérrel és különböző cégeknél szerzett tapasztalattal rendelkeznek. A kollégák 8 év alatt több tucat vállalatot és projektet vizsgáltak meg – startupoktól a vállalkozásokig –, amelyek különböző problémákkal, valamint eltérő kulturális és mérnöki érettséggel küzdenek.

Igor és Vitalij jelentésükben elmagyarázta, milyen problémák merültek fel a kutatási folyamat során, hogyan oldották meg azokat, valamint elvileg hogyan zajlanak a DevOps-kutatások, és miért döntött úgy az Express 42, hogy sajátot végez. Megnézheti a beszámolójukat itt.

DevOps kutatás

Igor Kurochkin kezdte a beszélgetést.

A DevOps konferenciákon rendszeresen kérdezzük a közönséget: „Olvastad az idei DevOps állapotjelentést?” Csak néhányan emelik fel a kezét, de kutatásunk szerint csak egyharmaduk tanulmányozza őket. Ha még soha nem látott ilyen jelentéseket, azonnal mondjuk el, hogy mindegyik nagyon hasonló. Leggyakrabban olyan kifejezések hangzanak el, mint: „A tavalyi évhez képest...”

Itt van az első problémánk, amit további kettő követ:

1. Tavalyi adatokkal nem rendelkezünk. Senkit nem érdekel a DevOps helyzete Oroszországban;
2. Módszertan. Nem világos a hipotézisek tesztelése, a kérdések felépítése, az elemzés, az eredmények összehasonlítása, az összefüggések keresése;
3. Terminológia. Minden jelentés angol nyelvű, fordítás szükséges, a DevOps közös keretrendszerét még nem találták ki, és mindenki előáll a sajátjával.

Nézzük meg, hogyan végezték általában a DevOps világbeli állapotának elemzését.

Történelmi háttér

A DevOps kutatást 2011 óta folytatják. Elsőként a Puppet, a konfigurációkezelő rendszerek fejlesztője végezte őket. Akkoriban ez volt az egyik fő eszköz az infrastruktúra kód formájában történő leírására. 2013-ig ezek a tanulmányok egyszerűen zárt formátumú, nyilvános jelentés nélküli felmérések voltak.

2013-ban jelent meg az IT Revolution, a DevOps-ról szóló összes főbb könyv kiadója. A Puppettel közösen elkészítették az első „State of DevOps” kiadványt, ahol 4 kulcsfontosságú mérőszám jelent meg először. A következő évben bekapcsolódott a ThoughtWorks tanácsadó cég, amely az ipari gyakorlatokat és eszközöket bemutató rendszeres technológiai radarjairól ismert. 2015-ben pedig bekerült egy módszertani rész, és kiderült, hogyan végzik az elemzést.

2016-ban a tanulmány készítői, miután létrehozták cégüket a DORA-t (DevOps Research and Assessment), éves jelentést tettek közzé. A következő évben a DORA és a Puppet kiadta közös zárójelentését.

Aztán a dolgok érdekessé váltak:

2018-ban a vállalatok szétválnak, és két független jelentést tettek közzé: az egyik a Puppettől, a másik a DORA-tól a Google-lel együttműködve. A DORA továbbra is alkalmazta módszertanát kulcsfontosságú mérőszámokkal, teljesítményprofilokkal és mérnöki gyakorlatokkal, amelyek hatással vannak a kulcsfontosságú mérőszámokra és teljesítményre az egész vállalaton. A Puppet pedig a folyamat és a DevOps fejlődésének leírásával javasolta megközelítését. A történet azonban nem fogott fel: 2019-ben a Puppet felhagyott ezzel a módszertannal, és kiadta a jelentések új verzióját, amelyben felsorolta a kulcsfontosságú gyakorlatokat és azt, hogy ezek hogyan hatnak a DevOps-ra az ő szemszögükből. Aztán egy másik dolog történt: a Google megvásárolta a DORA-t, és közösen újabb jelentést tettek közzé. Talán láttad.

Idén a dolgok bonyolulttá váltak. Ismeretes, hogy a Puppet elindította felmérését. Egy héttel korábban csinálták, mint mi, és már kész is volt. Részt vettünk rajta, és megnéztük, milyen témák érdeklik őket. A Puppet most végzi az elemzését, és készül a jelentés közzétételére.

De még mindig nem érkezett bejelentés a DORA és a Google részéről. Májusban, amikor a felmérés általában elkezdődött, olyan információk érkeztek, hogy Nicole Forsgren, a DORA egyik alapítója másik céghez költözött. Ezért azt feltételeztük, hogy idén nem lesz kutatás vagy jelentés a DORA-tól.

Hogy állnak a dolgok Oroszországban?

Nem végeztünk kutatást a DevOps-ról. Konferenciákon beszéltünk, mások következtetéseit meséltük el, a Raiffeisenbank pedig lefordította a 2019-es „State of DevOps”-t (közleményüket a Habrén találod), köszönet nekik. És ez minden.

Ezért saját kutatást végeztünk Oroszországban a DORA módszertanával és eredményeivel. Kutatásunkhoz a Raiffeisenbank munkatársainak beszámolóját használtuk fel, többek között a terminológia és a fordítás szinkronizálására. A szakma szempontjából releváns kérdéseket pedig a DORA jelentésekből és az idei Puppet kérdőívből vettük.

Kutatási folyamat

A jelentés csak az utolsó rész. A teljes kutatási folyamat négy nagy szakaszból áll:

Az előkészítés során iparági szakértőket kérdeztünk, és hipotézislistát készítettünk. Ezek alapján kérdéseket állítottunk össze, és felmérést indítottunk egész augusztus hónapra. Ezután magát a jelentést elemeztük és elkészítettük. A DORA esetében ez a folyamat 6 hónapig tart. 3 hónap alatt végeztük el, és most már tudjuk, hogy alig volt időnk: csak az elemzés elvégzésével érti meg, milyen kérdéseket kell feltenni.

Résztvevők

Minden külföldi jelentés a résztvevők portréjával kezdődik, és legtöbbjük nem Oroszországból származik. Az orosz válaszadók aránya évről évre 5 és 1% között ingadozik, és ez nem teszi lehetővé, hogy következtetéseket vonjunk le.

Térkép az Accelerate State of DevOps 2019 jelentésből:

Vizsgálatunkban 889 embert tudtunk megkérdezni - ez elég sok (a DORA évente mintegy ezer embert kérdez meg jelentéseiben), és ezzel elértük a célunkat:

Igaz, nem minden résztvevőnk ért a végére: a teljesítési arány valamivel kevesebb volt, mint a fele. De ez elég volt ahhoz, hogy reprezentatív mintát kapjunk és elemzést végezzünk. A DORA jelentéseiben nem közli a kihasználtságot, így itt nem lehet összehasonlítani.

Iparágak és pozíciók

Válaszadóink egy tucat iparágat képviselnek. Fél munka az informatikában. Ezt követik a pénzügyi szolgáltatások, a kereskedelem, a távközlés és mások. A pozíciók között vannak szakemberek (fejlesztő, tesztelő, üzemeltetési mérnök) és menedzserek (csapatok, csoportok, területek vezetői, igazgatók):

Minden második ember egy közepes méretű cégnél dolgozik. Minden harmadik ember nagyvállalatoknál dolgozik. A legtöbben legfeljebb 9 fős csapatokban dolgoznak. Külön kérdeztük a főbb tevékenységeket, amelyek többsége így vagy úgy az üzemeltetéshez kapcsolódik, és mintegy 40%-a fejlesztésben vesz részt:

Így gyűjtöttünk információkat összehasonlításhoz és elemzésekhez a különböző iparágak, cégek és csapatok képviselőiről. Vitalij Habarov kollégám mesél majd az elemzésről.

Elemzés és összehasonlítás

Vitalij Habarov: Nagyon köszönjük minden résztvevőnek, aki kitöltötte a felmérésünket, kitöltötte a kérdőíveket, és adatokat szolgáltatott nekünk hipotéziseink további elemzéséhez és teszteléséhez. Ügyfeleinknek és ügyfeleinknek köszönhetően pedig rengeteg tapasztalattal rendelkezünk, amely segített azonosítani az iparágat érintő kérdéseket, és megfogalmazni azokat a hipotéziseket, amelyeket kutatásunk során teszteltünk.

Sajnos nem lehet csak úgy, hogy egyrészt egy listát a kérdésekről, másrészt pedig az adatokat, hanem hasonlítsa össze, mondjuk: „Igen, minden így működik, igazunk volt”, és külön utakon járhatunk. Nem, módszertanra és statisztikai módszerekre van szükségünk, hogy megbizonyosodjunk arról, hogy nem tévedtünk, és következtetéseink megbízhatóak. Ezután ezen adatok alapján építhetjük fel további munkánkat:

Főbb mutatók

A DORA módszertanát vettük alapul, amelyet részletesen leírtak az „Accelerate State of DevOps” című könyvben. Megvizsgáltuk, hogy a kulcsfontosságú mutatók alkalmasak-e az orosz piacra, ugyanúgy használhatók-e, mint a DORA a következő kérdés megválaszolására: „Hogyan felel meg az oroszországi iparág a külföldi iparnak?”

Főbb mutatók:

1. Telepítési gyakoriság. Milyen gyakran kerül telepítésre egy alkalmazás új verziója az éles környezetben (tervezett változtatások, kivéve a gyorsjavításokat és az incidensekre adott választ)?
2. Szállítási idő. Átlagosan mennyi idő telik el a változtatás végrehajtása (a funkció kódként történő írása) és a változás éles környezetben történő üzembe helyezése között?
3. Gyógyulási idő. Átlagosan mennyi ideig tart egy alkalmazás visszaállítása éles környezetben egy incidens, a szolgáltatás leromlása vagy az alkalmazás felhasználóit érintő hiba észlelése után?
4. Sikertelen változtatások. A termékkörnyezetben a telepítések hány százaléka vezet az alkalmazás leromlásához vagy incidensekhez, és megköveteli a következmények kiküszöbölését (módosítások visszagörgetése, gyorsjavítás vagy javítás fejlesztése)?

A DORA kutatása összefüggést talált e mutatók és a szervezeti teljesítmény között. Tanulmányunkban ezt is ellenőrizzük.

De ahhoz, hogy megbizonyosodjon arról, hogy a négy kulcsfontosságú mérőszám befolyásolhat valamit, meg kell értenie – kapcsolódnak-e valamilyen módon egymáshoz? A DORA igennel válaszolt, egy fenntartással: a változáshiba-arány és a másik három mérőszám közötti kapcsolat valamivel gyengébb. Körülbelül ugyanazt a képet kaptuk. Ha a szállítási idő, az üzembe helyezés gyakorisága és a helyreállítási idő korrelál egymással (ezt a korrelációt a Pearson-korreláción és a Chaddock-skálán állapítottuk meg), akkor nincs ilyen erős korreláció a sikertelen változtatásokkal.

Elvileg a legtöbb válaszadó hajlamos azt válaszolni, hogy meglehetősen kevés incidens fordul elő a termelésben. Bár a későbbiekben látni fogjuk, hogy a válaszadói csoportok között továbbra is jelentős különbség van a sikertelen változtatások arányában, ezt a mérőszámot még nem használhatjuk ehhez a felosztáshoz.

Ezt annak a ténynek tulajdonítjuk, hogy (amint az elemzés és néhány ügyfelünkkel folytatott kommunikáció során kiderült) némi különbség van az incidensnek tekintett események megítélésében. Ha a műszaki ablak alatt sikerült visszaállítani a szolgáltatásunk működőképességét, az incidensnek minősülhet? Valószínűleg nem, mert mindent kijavítottunk, nagyszerűek vagyunk. Incidensnek tekinthető, ha 10-szer újra kellett görgetnünk az alkalmazásunkat normál, megszokott módban? Úgy tűnik, nem. Ezért nyitva marad a sikertelen változtatások és más mérőszámok közötti kapcsolat kérdése. A továbbiakban tisztázni fogjuk.

Itt az a fontos, hogy szignifikáns összefüggést találtunk a szállítási idő, a helyreállítási idő és a telepítési gyakoriság között. Ezért ezt a három mérőszámot vettük alapul, hogy a válaszadókat produktivitás alapján csoportokba soroljuk.

Mennyit kell lefagyni grammban?

Hierarchikus klaszteranalízist alkalmaztunk:

• A válaszadókat n-dimenziós térben osztjuk szét, ahol minden válaszadó koordinátája a kérdésekre adott válasza.
• Minden válaszadót kis klaszternek nyilvánítunk.
• Az egymáshoz legközelebb eső két klasztert egyesítjük egy nagyobb klaszterbe.
• Megkeressük a következő klaszterpárt, és összevonjuk őket egy nagyobb klaszterbe.

Így csoportosítjuk az összes válaszadónkat a szükséges számú klaszterbe. Egy dendrogram (a klaszterek közötti kapcsolatok fa) segítségével láthatjuk a két szomszédos klaszter közötti távolságot. Már csak az marad, hogy határt szabjunk e klaszterek közötti távolságnak, és azt mondjuk: „Ez a két csoport meglehetősen megkülönböztethető egymástól, mert óriási a távolság közöttük.”

De van itt egy rejtett probléma: a klaszterek számát illetően nincs korlátozás – 2, 3, 4, 10 klasztert kaphatunk. És az első ötlet az volt, hogy miért ne osszuk az összes válaszadónkat 4 csoportba, ahogy DORA teszi. De azt tapasztaltuk, hogy a különbségek e csoportok között elenyészővé válnak, és nem lehetünk biztosak abban, hogy a válaszadó valóban az ő csoportjához tartozik, és nem a szomszédhoz. Az orosz piacot még nem oszthatjuk négy csoportra. Ezért három profil mellett döntöttünk, amelyek között statisztikailag szignifikáns különbség van:

Ezután klaszterenként határoztuk meg a profilt: minden egyes metrikához vettük a mediánokat, és összeállítottuk a hatékonysági profilok táblázatát. Valójában az egyes csoportokban az átlagos résztvevő teljesítményprofiljait kaptuk meg. Három hatékonysági profilt azonosítottunk: Alacsony, Közepes, Magas:

Itt megerősítettük azt a hipotézisünket, hogy 4 kulcsfontosságú mérőszám alkalmas a teljesítményprofil meghatározására, amelyek mind a nyugati, mind az orosz piacon működnek. A csoportok között van különbség, és ez statisztikailag szignifikáns. Szeretném hangsúlyozni, hogy a sikertelen változtatások mérőszámának teljesítményprofiljai között szignifikáns különbség van, annak ellenére, hogy kezdetben nem osztottuk fel a válaszadókat ezzel a paraméterrel.

Ekkor felmerül a kérdés: hogyan lehet mindezt felhasználni?

Hogyan kell használni

Ha bármilyen csapatot, 4 kulcsfontosságú mérőszámot veszünk és alkalmazunk a táblázatra, akkor az esetek 85%-ában nem kapunk teljes meccset – ez csak az átlagos résztvevő, és nem az, ami a valóságban van. Mindannyian (és minden csapat) egy kicsit mások vagyunk.

Ellenőriztük: vettük a válaszadóinkat és a DORA teljesítményprofilját, és megnéztük, hány válaszadó felel meg egyik vagy másik profilnak. Azt találtuk, hogy csak a válaszadók 16%-a esett be pontosan valamelyik profilba. Az összes többi valahol a kettő között van elszórva:

Ez azt jelenti, hogy a teljesítményprofil hatóköre korlátozott. Az Ön tartózkodási helyének első becsléséhez használja ezt a táblázatot: „Ó, úgy tűnik, közelebb vagyunk a közepeshez vagy a magashoz!” Ha megérted, merre mész tovább, az elég lehet. De ha az állandó, folyamatos fejlesztés a cél, és szeretnéd pontosabban tudni, hogy hol és mit kell fejlesztened, akkor további forrásokra van szükség. Számológépeknek hívtuk őket:

• DORA számológép
• Calculator Express 42* (fejlesztés alatt)
• Saját fejlesztés (saját belső számológépet létrehozhat).

Mire kellenek? Megérteni:

• Megfelel-e a szervezetünkön belüli csapat a szabványainknak?
• Ha nem, akkor tudunk neki segíteni - felgyorsítani cégünk szakértelmének keretein belül?
• Ha igen, tehetünk még jobbat?

Használhatja őket a vállalaton belüli statisztikák gyűjtésére is:

• Milyen csapataink vannak?
• Ossza fel a csapatokat profilokra;
• Lásd: Ó, ezek a csapatok alulteljesítenek (kicsit lassúak), de ezek nagyszerűek: minden nap bevetnek, hiba nélkül, átfutási idejük kevesebb, mint egy óra.

És akkor megtudhatja, hogy cégünkön belül megvan a szükséges szakértelem és eszközök azon csapatok számára, amelyek még mindig alulmaradnak.

Vagy ha megérted, hogy jól érzed magad a társaságon belül, hogy jobb vagy, mint sokan, akkor kicsit tágabban nézhetsz. Pontosan ez az orosz ipar: megszerezhetjük-e a szükséges szakértelmet az orosz iparban, hogy felgyorsítsuk magunkat? Itt segít az Express 42 számológép (a fejlesztés alatt áll). Ha kinőtte az orosz piacot, akkor nézze meg DORA számológép és a világpiacra.

Bírság. És ha a DORA kalkulátor szerint az Elit csoportba tartozol, akkor mit kell tenned? Itt nincs jó megoldás. Valószínűleg Ön az iparág élvonalába tartozik, és a belső K+F és nagy erőforrások ráfordítása révén további gyorsítás és megbízhatóság javítására van lehetőség.

Térjünk át a legkedvesebb részre - az összehasonlításra.

Сравнение

Kezdetben össze akartuk hasonlítani az orosz ipart a nyugati iparral. Ha közvetlenül összehasonlítjuk, azt látjuk, hogy kevesebb profilunk van, és kicsit jobban keverednek egymással, kicsit elmosódnak a határok:

Elit-előadóink elrejtőznek a Nagy teljesítményűek között, de ott vannak - ezek az elit, egyszarvúak, akik jelentős magasságokat értek el. Oroszországban az Elite és a High profilok közötti különbség még nem elég jelentős. Úgy gondoljuk, hogy a jövőben ez a szétválás a mérnöki kultúra növekedése, a mérnöki gyakorlatok megvalósításának minősége és a vállalatokon belüli szakértelem miatt fog megvalósulni.

Ha továbblépünk az orosz iparágon belüli közvetlen összehasonlításra, azt látjuk, hogy a magas profilú csapatok minden tekintetben jobbak. Megerősítettük azt a hipotézisünket is, hogy összefüggés van e mutatók és a szervezeti hatékonyság között: a magas profilú csapatok lényegesen nagyobb eséllyel nem csak elérik a célokat, hanem túl is teljesítik azokat.
Legyünk magas rangú csapatok, és ne álljunk meg itt:

Az idei év azonban különleges, és úgy döntöttünk, hogy megvizsgáljuk, hogyan élnek a vállalatok a világjárványban: A magas rangú csapatok lényegesen jobban megbirkózni, és jobban érzik magukat, mint az iparági átlag:

• Új termékek 1,5-2-szer gyakrabban jelentek meg,
• Az alkalmazás-infrastruktúra megbízhatósága és/vagy teljesítménye kétszer gyakrabban nő.

Vagyis a már megszerzett kompetenciák segítették őket gyorsabb fejlődésben, új termékek bevezetésében, meglévő termékek módosításában, ezáltal új piacok és új felhasználók meghódításában:

Mi segített még csapatainknak?

Mérnöki gyakorlatok

Minden egyes általunk ellenőrzött gyakorlattal kapcsolatban elmondom a lényeges megállapításokat. Talán valami más is segített a csapatoknak, de a DevOps-ról beszélünk. A DevOps-on belül pedig különbségeket látunk a különböző profilú csapatok között.

A platform mint szolgáltatás

Nem találtunk szignifikáns összefüggést a platform életkora és a csapat profilja között: a platformok megközelítőleg egy időben jelentek meg mind a Low, mind a High csapatoknál. De az utóbbi esetében a platform átlagosan több szolgáltatást és több szoftveres interfészt biztosít a programkódon keresztüli vezérléshez. A platformcsapatok pedig nagyobb valószínűséggel segítenek fejlesztőiknek és csapataiknak a platform használatában, nagyobb valószínűséggel oldják meg a platformmal kapcsolatos problémáikat és incidenseiket, illetve képeznek ki más csapatokat.

Az infrastruktúra kódként

Itt minden elég szabványos. Kapcsolatot találtunk az infrastruktúra kódjának automatizálása és az infrastruktúra-tárban tárolt információ mennyisége között. A magas profilú csapatok több információt tárolnak a tárolókban: ide tartozik az infrastruktúra konfigurációja, a CI/CD folyamat, a környezeti beállítások és az összeállítási paraméterek. Gyakrabban tárolják ezeket az információkat, jobban dolgoznak az infrastruktúra kóddal, és több folyamatot és feladatot automatizáltak az infrastruktúra kóddal való munkához.

Érdekes módon az infrastruktúra-tesztekben nem tapasztaltunk szignifikáns különbséget. Ezt annak a ténynek tulajdonítom, hogy a magas profilú csapatok általában több tesztautomatizálással rendelkeznek. Talán nem kellene őket külön elvonni az infrastruktúra tesztekkel, inkább elég az alkalmazások ellenőrzésére használt tesztek, és ezeknek köszönhetően láthatják, hogy mit és hol rontottak el.

Integráció és szállítás

A legunalmasabb rész, mert megerősítettük: minél nagyobb az automatizálása, minél jobban dolgozik a kóddal, annál valószínűbb, hogy jobb eredményeket ér el.

építészet

Azt akartuk látni, hogy a mikroszolgáltatások hogyan befolyásolják a teljesítményt. Őszintén szólva nem, hiszen a mikroszolgáltatások használata nem jár együtt a hatékonysági mutatók növekedésével. A mikroszolgáltatásokat magas és alacsony profilú csapatok egyaránt használják.

Ami azonban lényeges, az az, hogy a High-teams számára a mikroszolgáltatási architektúrára való átállás lehetővé teszi számukra, hogy önállóan fejlesszék szolgáltatásaikat és terjesszék ki azokat. Ha az architektúra lehetővé teszi a fejlesztők számára, hogy autonóm módon cselekedjenek anélkül, hogy valakire várnának a csapaton kívül, akkor ez kulcskompetencia a sebesség növeléséhez. Ebben segítenek a mikroszolgáltatások. De egyszerűen végrehajtásuk nem játszik nagy szerepet.

Hogyan fedeztük fel mindezt?

Ambiciózus tervünk volt a DORA módszertan teljes megismétlésére, de nem álltak rendelkezésre az erőforrások. Ha a DORA sok szponzort vesz igénybe, és a vizsgálat hat hónapig tart, akkor rövid időn belül elvégeztük a vizsgálatot. Olyan DevOps-modellt akartunk építeni, mint a DORA, és ezt a jövőben is meg fogjuk tenni. Egyelőre a hőtérképekre szorítkoztunk:

Megvizsgáltuk a mérnöki gyakorlatok megoszlását az egyes profilokhoz tartozó csapatok között, és azt találtuk, hogy a magas profilú csapatok átlagosan gyakrabban alkalmaznak mérnöki gyakorlatokat. Minderről bővebben lapunkban olvashat jelentés.

A változatosság kedvéért váltsunk az összetett statisztikákról az egyszerűekre.

Mit fedeztünk fel még?

Tools

Megfigyeltük, hogy a Linux operációs rendszer család használja a legtöbb parancsot. De a Windows továbbra is trendben van – válaszadóink legalább negyede jegyezte meg egyik vagy másik verziójának használatát. Úgy tűnik, a piacnak megvan ez az igénye. Ezért ezeket a kompetenciákat fejlesztheti, és konferenciákon előadásokat tarthat.

A hangszerelők között nem titok, hogy Kubernetes vezet (52%). A következő hangszerelő a sorban a Docker Swarm (kb. 12%). A legnépszerűbb CI rendszerek a Jenkins és a GitLab. A legnépszerűbb konfigurációkezelő rendszer az Ansible, amelyet szeretett Shellünk követ.

A felhőtárhely-szolgáltatók között jelenleg az Amazon foglalja el a vezető helyet. Az orosz felhők aránya fokozatosan növekszik. Jövőre érdekes lesz látni, hogyan érzik magukat az orosz felhőszolgáltatók, és nő-e piaci részesedésük. Léteznek, használhatók, és ez jó:

Átadom a szót Igornak, aki ad még néhány statisztikát.

A gyakorlatok elterjedése

Igor Kurochkin: Külön megkértük a válaszadókat, hogy jelezzék, hogyan oszlanak meg a figyelembe vett mérnöki gyakorlatok a vállalaton belül. A legtöbb vállalat vegyes megközelítést alkalmaz, amely különböző mintákból áll, és a kísérleti projektek nagyon népszerűek. Láttunk egy kis különbséget a profilok között is. A Magas profil képviselői gyakrabban alkalmazzák a „Kezdeményezés alulról” mintát, amikor kis szakértői csapatok változtatják a munkafolyamatokat, eszközöket, és megosztják a sikeres fejlesztéseket más csapatokkal. A Mediumnál ez egy felülről lefelé irányuló kezdeményezés, amely az egész vállalatot érinti közösségek és kiválósági központok létrehozásán keresztül:

Agilis és DevOps

Az Agile és a DevOps kapcsolatáról gyakran esik szó az iparágban. Ez a kérdés a 2019/2020-as agilis állapotjelentésben is felvetődik, ezért úgy döntöttünk, hogy összehasonlítjuk az Agilis és a DevOps tevékenységeket a vállalatoknál. Azt találtuk, hogy az Agile nélküli DevOps ritka. A válaszadók felénél az Agilis elterjedése észrevehetően korábban kezdődött, körülbelül 20%-uk pedig egyidejű indulást észlelt, az alacsony profil egyik jele pedig az Agilis és DevOps gyakorlatok hiánya lesz:

Csapat topológiák

Tavaly év végén megjelent a „Csapat topológiák", amely keretrendszert javasol a csapattopológiák leírására. Kíváncsiak voltunk, hogy ez vonatkozik-e az orosz cégekre. És feltettük a kérdést: „Milyen mintákat látsz?”

A válaszadók felénél megfigyelhetők az infrastrukturális csapatok, valamint különálló fejlesztői, tesztelési és üzemeltetési csapatok. Az egyéni DevOps csapatok 45%-át jegyezték fel, amelyek között gyakoribbak a magas képviselők. Ezután jönnek a többfunkciós csapatok, amelyek szintén gyakoribbak a High-nál. Külön SRE parancsok jelennek meg a Magas, Közepes profilokban, és ritkán találhatók meg az Alacsony profilban:

DevQaOps arány

Ezt a kérdést a FaceBookon láttuk a Skyeng platform csapatának vezetőjétől – érdeklődött a fejlesztők, tesztelők és adminisztrátorok aránya a cégeknél. Megkérdeztük, és a válaszokat a profilok figyelembevételével néztük meg: a High profile képviselőinél kisebb számú tesztelő és üzemeltető mérnök van minden fejlesztőnél:

Tervek az 2021 évhez

A következő évre vonatkozó terveikben a válaszadók a következő tevékenységeket jelölték meg:

Itt láthatja a DevOps Live 2020 konferencia találkozását. Gondosan átnéztük a programot:

• Az infrastruktúra mint termék
• DevOps átalakítás
• A DevOps gyakorlatok terjesztése
• DevSecOps
• Esetklubok és megbeszélések

De a beszédünknek nem lesz elég ideje az összes témára. A színfalak mögött:

• Platform, mint szolgáltatás és mint termék;
• Infrastruktúra mint kód, környezetek és felhők;
• Folyamatos integráció és szállítás;
• Építészet;
• DevSecOps minták;
• Platform és többfunkciós csapatok.

Jelentés A miénk terjedelmes, 50 oldalas, részletesebben is meg lehet nézni.

Összefoglalva

Reméljük, hogy kutatásunk és jelentésünk ösztönözni fogja Önt arra, hogy kísérletezzen új fejlesztési, tesztelési és üzemeltetési megközelítésekkel, valamint segít eligazodni, összehasonlítani magát a vizsgálatban részt vevő többiekkel, és azonosítani azokat a területeket, ahol javíthatja saját megközelítéseit. .

Az oroszországi DevOps állapotát vizsgáló első tanulmány eredményei:

• Főbb mutatók. Megállapítottuk, hogy a legfontosabb mérőszámok (szállítási idő, telepítési sebesség, helyreállítási idő és változtatási hibák) alkalmasak a fejlesztési, tesztelési és üzemeltetési folyamatok hatékonyságának elemzésére.
• Profilok Magas, Közepes, Alacsony. Az összegyűjtött adatok alapján lehetőség nyílik statisztikailag különböző csoportok azonosítására: Magas, Közepes, Alacsony, metrikák, gyakorlatok, folyamatok és eszközök alapján megkülönböztető jegyekkel. A magas profil képviselői jobb eredményeket mutatnak, mint az alacsony. Valószínűbb, hogy elérik és túlszárnyalják céljaikat.
• Mutatók, járvány és tervek 2021-re. Az idei év különleges mutatója, hogy a vállalatok hogyan birkóztak meg a világjárvánnyal. A High jobban teljesített, a felhasználói aktivitás növekedését tapasztalta, és a siker fő oka a hatékony fejlesztési folyamatok és az erős mérnöki kultúra volt.
• DevOps gyakorlatok, eszközök és fejlesztésük. A cégek következő évi főbb tervei között szerepel a DevOps gyakorlatok és eszközök fejlesztése, a DevSecOps gyakorlatok bevezetése, valamint a szervezeti struktúra megváltoztatása. A DevOps gyakorlatok hatékony megvalósítása és fejlesztése pedig pilot projekteken, közösségek és kompetenciaközpontok kialakításán, kezdeményezéseken keresztül valósul meg a vállalat felső és alsó szintjén.

Örömmel fogjuk hallani véleményeiteket, történeteiteket, visszajelzéseiteket. Köszönetet mondunk mindenkinek, aki részt vett a vizsgálatban, és jövőre is számítunk a részvételére.

Forrás: will.com