„DevOps“ padėtis Rusijoje 2020 m

Kaip suprasti kažko būseną?

Galite pasikliauti savo nuomone, suformuota iš įvairių informacijos šaltinių, pavyzdžiui, publikacijų interneto svetainėse ar patirties. Galite klausti kolegų, pažįstamų. Kitas variantas – pažvelgti į konferencijų temas: programos komitetas yra aktyvūs industrijos atstovai, todėl jais pasitikime renkantis aktualias temas. Atskira sritis – tyrimai ir ataskaitos. Tačiau yra problema. Pasaulyje kasmet atliekami DevOps būklės tyrimai, ataskaitas skelbia užsienio kompanijos, o apie rusiškus DevOps informacijos beveik nėra.

Tačiau atėjo diena, kai buvo atliktas toks tyrimas, o šiandien kalbėsime apie rezultatus. Bendrovės kartu tyrė „DevOps“ būklę Rusijoje.Express 42"Ir"Ontico“. „Express 42“ padeda technologijų įmonėms įdiegti ir plėtoti „DevOps“ praktiką bei įrankius ir viena pirmųjų prabilo apie „DevOps“ Rusijoje. Tyrimo autoriai Igoris Kuročkinas ir Vitalijus Chabarovas užsiima analize ir konsultacijomis „Express 42“, turėdami techninį išsilavinimą ir patirtį įvairiose įmonėse. Per 8 metus kolegos apžiūrėjo dešimtis įmonių ir projektų – nuo ​​startuolių iki įmonių – turinčių skirtingas problemas, taip pat skirtingą kultūrinę ir inžinerinę brandą.

Savo pranešime Igoris ir Vitalijus papasakojo, kokios problemos buvo tyrimo procese, kaip jas sprendė, taip pat kaip iš esmės atliekami DevOps tyrimai ir kodėl Express 42 nusprendė atlikti savo. Jų ataskaitą galima peržiūrėti čia.

„DevOps“ tyrimas

Pokalbį pradėjo Igoris Kuročkinas.

Mes nuolat klausiame „DevOps“ konferencijų auditorijos: „Ar perskaitėte šių metų DevOps būsenos ataskaitą? Tik nedaugelis pakelia rankas, o mūsų tyrimas parodė, kad tik trečdalis juos tiria. Jei niekada nematėte tokių pranešimų, iš karto pasakykime, kad jie visi labai panašūs. Dažniausiai yra tokios frazės: „Palyginti su praėjusiais metais ...“

Čia turime pirmąją problemą, o po jos dar dvi:

1. Praėjusių metų duomenų neturime. DevOps būklė Rusijoje niekam neįdomi;
2. Metodika. Neaišku, kaip tikrinti hipotezes, kaip statyti klausimus, kaip analizuoti, lyginti rezultatus, rasti sąsajų;
3. Terminija. Visos ataskaitos yra anglų kalba, reikalingas vertimas, bendras DevOps karkasas dar neišrastas ir kiekvienas sugalvoja savo.

Pažiūrėkime, kaip DevOps būsenos analizė buvo atlikta visame pasaulyje.

Istorinė informacija,

„DevOps“ tyrimai vykdomi nuo 2011 m. Pirmoji jas atliko konfigūracijos valdymo sistemų kūrėja „Puppet“. Tuo metu tai buvo vienas pagrindinių infrastruktūros aprašymo kodo pavidalu įrankių. Iki 2013 m. šie tyrimai buvo tiesiog uždaros apklausos ir nebuvo viešų ataskaitų.

2013 m. pasirodė IT Revolution, visų pagrindinių knygų apie DevOps leidėjas. Kartu su Puppet jie parengė pirmąjį State of DevOps leidinį, kuriame pirmą kartą pasirodė 4 pagrindinės metrikos. Kitais metais įsitraukė konsultacinė įmonė ThoughtWorks, žinoma dėl nuolatinių pramonės praktikos ir įrankių technologijų radarų. O 2015 metais buvo pridėtas skyrius su metodika ir paaiškėjo, kaip jie atlieka analizę.

2016 metais tyrimo autoriai, sukūrę savo įmonę DORA (DevOps Research and Assessment), paskelbė metinę ataskaitą. Kitais metais DORA ir Puppet paskelbė savo paskutinę bendrą ataskaitą.

Ir tada prasidėjo kažkas įdomaus:

2018 m. įmonės išsiskirstė ir buvo paskelbtos dvi nepriklausomos ataskaitos: viena iš „Puppet“, antra – iš „DORA“ kartu su „Google“. DORA ir toliau naudojo savo metodiką su pagrindinėmis metrikomis, veiklos profiliais ir inžinerine praktika, kuri daro įtaką pagrindinėms metrikoms ir visos įmonės našumui. Ir „Puppet“ pasiūlė savo požiūrį, aprašydamas procesą ir „DevOps“ evoliuciją. Tačiau istorija neprigijo, 2019 m. „Puppet“ atsisakė šios metodikos ir išleido naują ataskaitų versiją, kurioje išvardytos pagrindinės praktikos ir kaip jos veikia „DevOps“ jų požiūriu. Tada įvyko kitas įvykis: „Google“ nusipirko DORA ir kartu paskelbė kitą ataskaitą. Galbūt jūs jį matėte.

Šiais metais viskas susidėliojo. Yra žinoma, kad „Lėlė“ pradėjo savo apklausą. Jie tai padarė savaite anksčiau nei mes, ir tai jau baigėsi. Jame dalyvavome ir žiūrėjome, kokios temos juos domina. Dabar „Lėlė“ atlieka savo analizę ir ruošiasi publikuoti ataskaitą.

Tačiau DORA ir Google vis dar nepaskelbė. Gegužės mėnesį, kai paprastai prasidėdavo apklausa, pasirodė informacija, kad Nicole Forsgren, viena iš DORA įkūrėjų, persikėlė į kitą įmonę. Todėl manėme, kad šiais metais DORA tyrimų ir ataskaitos nebus.

Kaip reikalai Rusijoje?

Mes neatlikome „DevOps“ tyrimo. Kalbėjome konferencijose, perpasakojome kitų žmonių atradimus, o Raiffeisenbank išvertė 2019 m. „State of DevOps“ (jų skelbimą rasite Habré), labai jiems ačiū. Ir viskas.

Todėl savo tyrimus Rusijoje atlikome naudodami DORA metodikas ir išvadas. Savo tyrimams, įskaitant terminijos ir vertimo sinchronizavimą, naudojome kolegų iš Raiffeisenbank ataskaitą. Su pramone susiję klausimai buvo paimti iš DORA ataskaitų ir šių metų lėlių klausimyno.

Tyrimo procesas

Ataskaita yra tik paskutinė dalis. Visas tyrimo procesas susideda iš keturių pagrindinių etapų:

Pasirengimo etape apklausėme pramonės ekspertus ir parengėme hipotezių sąrašą. Jų pagrindu buvo sudaryti klausimai ir pradėta apklausa visą rugpjūčio mėnesį. Tada išanalizavome ir parengėme pačią ataskaitą. DORA atveju šis procesas trunka 6 mėnesius. Susipažinome per 3 mėnesius, o dabar suprantame, kad vos užteko laiko: tik atlikęs analizę supranti, kokius klausimus reikia užduoti.

Dalyviai

Visi užsienio reportažai prasideda dalyvių portretu, o dauguma jų – ne iš Rusijos. Rusijos respondentų procentas kasmet svyruoja nuo 5 iki 1 proc., ir tai neleidžia daryti jokių išvadų.

Žemėlapis iš „Accelerate State of DevOps 2019“ ataskaitos:

Savo tyrime pavyko apklausti 889 žmones – tai gana daug (DORA savo ataskaitose kasmet apklausia apie tūkstantį žmonių) ir čia mes pasiekėme tikslą:

Tiesa, ne visi mūsų dalyviai pasiekė pabaigą: įvykdymo procentas pasirodė kiek mažesnis nei pusė. Bet ir to pakako reprezentatyviam mėginiui gauti ir analizei atlikti. DORA savo ataskaitose neatskleidžia užpildymo procentų, todėl čia nėra jokio palyginimo.

Pramonės šakos ir pareigos

Mūsų respondentai atstovauja keliolika pramonės šakų. Pusė darbo informacinių technologijų srityje. Toliau seka finansinės paslaugos, prekyba, telekomunikacijos ir kt. Tarp pareigybių yra specialistai (kūrėjas, testuotojas, eksploatavimo inžinierius) ir vadovaujantys darbuotojai (komandų, grupių, sričių vadovai, direktoriai):

Kas antras dirba vidutinio dydžio įmonėje. Kas trečias žmogus dirba didelėse įmonėse. Dauguma dirba komandose iki 9 žmonių. Atskirai teiravomės apie pagrindines veiklas, kurių dauguma yra kažkaip susijusios su veikla, o apie 40% užsiima plėtra:

Taigi surinkome informaciją skirtingų pramonės šakų, įmonių, komandų atstovų palyginimui ir analizei. Apie analizę papasakos mano kolega Vitalijus Chabarovas.

Analizė ir palyginimas

Vitalijus Chabarovas: Labai ačiū visiems dalyviams, kurie užpildė mūsų apklausą, užpildė anketas ir suteikė mums duomenų tolesnei analizei ir hipotezių patikrinimui. Dėka savo klientų ir klientų, turime daug patirties, kuri padėjo nustatyti pramonės problemas ir suformuluoti hipotezes, kurias patikrinome savo tyrimuose.

Deja, negalima tiesiog paimti klausimų sąrašo iš vienos pusės ir duomenų, iš kitos pusės, kažkaip juos palyginti, pasakyti: „Taip, viskas veikia taip, mes buvome teisūs“ ir išsiskirstyti. Ne, reikia metodikos ir statistinių metodų, kad įsitikintume, jog neklystame ir mūsų išvados yra patikimos. Tada galime kurti tolesnį darbą remdamiesi šiais duomenimis:

Pagrindinės metrikos

Mes rėmėmės DORA metodika, kurią jie išsamiai aprašė knygoje „Accelerate State of DevOps“. Patikrinome, ar pagrindiniai rodikliai tinka Rusijos rinkai, ar juos galima naudoti taip pat, kaip DORA naudoja atsakant į klausimą: „Kaip Rusijos pramonė atitinka užsienio pramonę?

Pagrindinės metrikos:

1. Diegimo dažnis. Kaip dažnai gamybinėje aplinkoje diegiama nauja programos versija (planuojami pakeitimai, išskyrus karštąsias pataisas ir atsaką į incidentus)?
2. Pristatymo laikas. Koks yra vidutinis laikas nuo pakeitimo (funkcijos įrašymo kaip kodo) ir pakeitimo diegimo gamybos aplinkoje?
3. Atsigavimo laikas. Kiek vidutiniškai užtrunka programai atkurti gamybinėje aplinkoje po incidento, paslaugos pablogėjimo arba aptiktos klaidos, turinčios įtakos programos naudotojams?
4. Nesėkmingi pakeitimai. Koks procentas diegimų gamybinėje aplinkoje sukelia programos pablogėjimą arba incidentus ir reikalauja ištaisymo (pakeitimų atšaukimas, karštųjų pataisų ar pataisų kūrimas)?

DORA savo tyrime nustatė ryšį tarp šių metrikų ir organizacijos veiklos rezultatų. Mes tai taip pat išbandome savo tyrime.

Tačiau norėdami įsitikinti, kad keturi pagrindiniai rodikliai gali ką nors paveikti, turite suprasti – ar jie kažkaip susiję vienas su kitu? DORA atsakė teigiamai su vienu įspėjimu: ryšys tarp nesėkmingų pakeitimų (Change Failure Rate) ir trijų kitų metrikų yra šiek tiek silpnesnis. Turime maždaug tą patį vaizdą. Jei pristatymo laikas, diegimo dažnis ir atkūrimo laikas koreliuoja vienas su kitu (šią koreliaciją nustatėme per Pearsono koreliaciją ir Chaddock skalę), tada nėra tokios stiprios koreliacijos su nesėkmingais pakeitimais.

Iš esmės dauguma respondentų linkę atsakyti, kad gamyboje įvyksta gana nedaug incidentų. Nors vėliau pamatysime, kad tarp respondentų grupių vis dar yra didelis skirtumas pagal nesėkmingus pokyčius, šiam skirstymui šios metrikos dar negalime naudoti.

Tai siejame su tuo, kad (kaip paaiškėjo atliekant analizę ir bendraujant su kai kuriais mūsų klientais) šiek tiek skiriasi suvokimas, kas laikoma incidentu. Jei per techninį langą pavyko atkurti savo paslaugos veikimą, ar tai gali būti laikoma incidentu? Tikriausiai ne, nes viską sutvarkėme, esame puikūs. Ar tai gali būti laikoma incidentu, jei turėtume 10 kartų persukti programą įprastu, mums pažįstamu režimu? Atrodo, kad ne. Todėl klausimas dėl nesėkmingų pakeitimų ryšio su kitais rodikliais lieka atviras. Mes jį tobulinsime toliau.

Svarbu tai, kad nustatėme reikšmingą ryšį tarp pristatymo laiko, atkūrimo laiko ir diegimo dažnio. Todėl, norėdami toliau suskirstyti respondentus į veiklos grupes, ėmėmės šių trijų metrikų.

Kiek pakabinti gramais?

Naudojome hierarchinę klasterių analizę:

• Respondentus paskirstome n-matėje erdvėje, kur kiekvieno respondento koordinatė yra jų atsakymai į klausimus.
• Kiekvienas respondentas yra paskelbtas mažu klasteriumi.
• Sujungiame du arčiausiai vienas kito esančius klasterius į vieną didesnį klasterį.
• Surandame kitą klasterių porą ir sujungiame jas į didesnį klasterį.

Taip sugrupuojame visus savo respondentus į reikiamą grupių skaičių. Dendrogramos (ryšių tarp klasterių medžio) pagalba matome atstumą tarp dviejų gretimų klasterių. Mums belieka nustatyti tam tikrą atstumo ribą tarp šių grupių ir pasakyti: „Šios dvi grupės gana skiriasi viena nuo kitos, nes atstumas tarp jų yra milžiniškas“.

Tačiau čia yra paslėpta problema: mes neturime jokių apribojimų klasterių skaičiui – galime gauti 2, 3, 4, 10 klasterių. Ir pirmoji mintis buvo – kodėl gi nepaskirstius visų mūsų respondentų į 4 grupes, kaip tai daro DORA. Tačiau pastebėjome, kad skirtumai tarp šių grupių tampa nereikšmingi ir negalime būti tikri, kad respondentas tikrai priklauso savo grupei, o ne kaimyninei. Kol kas negalime skirstyti Rusijos rinkos į keturias grupes. Todėl apsistojome ties trimis profiliais, tarp kurių yra statistiškai reikšmingas skirtumas:

Tada nustatėme profilį pagal grupes: paėmėme kiekvienos grupės kiekvienos metrikos medianą ir sudarėme našumo profilių lentelę. Tiesą sakant, mes gavome kiekvienos grupės vidutinio dalyvio veiklos profilius. Mes nustatėme tris efektyvumo profilius: žemas, vidutinis, didelis:

Čia patvirtinome savo hipotezę, kad veiklos profiliui nustatyti tinka 4 pagrindiniai rodikliai, kurie veikia tiek Vakarų, tiek Rusijos rinkose. Tarp grupių yra skirtumas ir jis yra statistiškai reikšmingas. Pabrėžiu, kad tarp veiklos profilių yra didelis skirtumas pagal nesėkmingų pokyčių metriką pagal vidurkį, nors iš pradžių respondentų pagal šį parametrą neskirstėme.

Tada kyla klausimas: kaip visa tai panaudoti?

Kaip naudotis

Jei paimsime bet kurią komandą, 4 pagrindinius rodiklius ir pritaikysime juos prie lentelės, tada 85% atvejų negausime pilnų rungtynių - tai tik vidutinis dalyvis, o ne tai, kas yra realybėje. Mes visi (ir kiekviena komanda) esame šiek tiek skirtingi.

Patikrinome: paėmėme savo respondentus ir DORA veiklos profilį ir pažiūrėjome, kiek respondentų atitinka tą ar kitą profilį. Mes nustatėme, kad tik 16% respondentų tikrai pateko į vieną iš profilių. Visi kiti yra išsibarstę kažkur tarp jų:

Tai reiškia, kad efektyvumo profilis yra ribotas. Norėdami suprasti, kur esate pirmuoju apytiksliu, galite naudoti šią lentelę: „O, atrodo, kad mes arčiau vidutinio ar aukšto! Jei suprasite, kur eiti toliau, to gali pakakti. Bet jei jūsų tikslas yra nuolatinis, nuolatinis tobulėjimas ir norite tiksliau žinoti, kur tobulėti ir ką daryti, tuomet reikia papildomų lėšų. Mes juos pavadinome skaičiuotuvais:

• DORA skaičiuoklė
• Calculator Express 42* (kuriamas)
• Nuosavas kūrimas (galite sukurti savo vidinį skaičiuotuvą).

Kam jie reikalingi? Suprasti:

• Ar mūsų organizacijos komanda atitinka mūsų standartus?
• Jei ne, ar galime padėti, pagreitinti mūsų įmonės turimą patirtį?
• Jei taip, ar galime padaryti dar geriau?

Taip pat galite juos naudoti rinkdami statistiką įmonėje:

• Kokias komandas turime?
• Padalinkite komandas į profilius;
• Žiūrėkite: O, šios komandos neveikia (jos mažai išsitraukia), bet jos yra šaunios: jos diegiamos kiekvieną dieną, be klaidų, jų vykdymo laikas yra trumpesnis nei valanda.

Ir tada jūs galite sužinoti, kad mūsų įmonėje yra reikiamų žinių ir įrankių toms komandoms, kurios dar nėra lygios.

Arba, jei supranti, kad kompanijoje jautiesi puikiai, esi geresnis už daugelį, tuomet gali žiūrėti kiek plačiau. Tai tik Rusijos pramonė: ar galime įgyti reikiamos patirties Rusijos pramonėje, kad galėtume įsibėgėti? Čia padės „Express 42“ skaičiuoklė (ji yra kuriama). Jei peraugote Rusijos rinką, pažiūrėkite DORA skaičiuoklė ir į pasaulinę rinką.

gerai. O jei DORA skaičiuoklėje esate Elit grupėje, ką turėtumėte daryti? Čia nėra gero sprendimo. Labiausiai tikėtina, kad esate pramonės priešakyje, o tolesnis pagreitis ir patikimumas yra įmanomas naudojant vidinius mokslinius tyrimus ir plėtrą bei išleidžiant daugiau išteklių.

Pereikime prie mieliausio – palyginimo.

Palyginimas

Iš pradžių norėjome palyginti Rusijos pramonę su Vakarų pramone. Jei lyginame tiesiogiai, matome, kad turime mažiau profilių ir jie yra šiek tiek labiau susimaišę vienas su kitu, ribos yra šiek tiek neryškesnės:

Mūsų Elitiniai atlikėjai yra pasislėpę tarp Aukštųjų atlikėjų, bet jie yra – tai elitas, vienaragiai, pasiekę reikšmingas aukštumas. Rusijoje skirtumas tarp Elito ir Aukšto profilio dar nėra pakankamai reikšmingas. Manome, kad ateityje toks atsiskyrimas įvyks dėl inžinerinės kultūros didėjimo, inžinerinės praktikos įgyvendinimo kokybės ir kompetencijos įmonėse.

Jei pereisime prie tiesioginio palyginimo su Rusijos pramone, pamatysime, kad aukšto lygio komandos yra geresnės visais atžvilgiais. Taip pat patvirtinome savo hipotezę, kad yra ryšys tarp šių metrikų ir organizacijos veiklos rezultatų: aukšto lygio komandos daug labiau linkusios ne tik pasiekti tikslus, bet ir juos viršyti.
Tapkime aukšto lygio komandomis ir nesustokime ties tuo:

Tačiau šie metai yra ypatingi, todėl nusprendėme patikrinti, kaip įmonėms sekasi pandemijos metu: aukšto lygio komandoms sekasi daug geriau ir jaučiasi geriau nei pramonės vidurkis:

• 1,5–2 kartus didesnė tikimybė išleisti naujus produktus,
• 2 kartus didesnė tikimybė pagerinti taikomųjų programų infrastruktūros patikimumą ir (arba) našumą.

Tai reiškia, kad jau įgytos kompetencijos padėjo jiems greičiau vystytis, pristatyti naujus produktus, modifikuoti esamus produktus ir taip užkariauti naujas rinkas ir naujus vartotojus:

Kas dar padėjo mūsų komandoms?

Inžinerinės praktikos

Papasakosiu apie reikšmingas kiekvienos mūsų išbandytos praktikos išvadas. Galbūt dar kažkas padėjo komandoms, bet mes kalbame apie „DevOps“. „DevOps“ matome skirtumą tarp skirtingų profilių komandų.

Platforma kaip paslauga

Neradome reikšmingo ryšio tarp platformos amžiaus ir komandos profilio: platformos pasirodė maždaug tuo pačiu metu tiek žemoms, tiek aukštoms komandoms. Tačiau pastariesiems platforma suteikia vidutiniškai daugiau paslaugų ir daugiau programavimo sąsajų, skirtų valdyti per programos kodą. O platformos komandos labiau linkusios padėti savo kūrėjams ir komandoms naudotis platforma, dažniau spręsti problemas ir su platforma susijusius incidentus bei šviesti kitas komandas.

Infrastruktūra kaip kodas

Viskas čia gana standartiška. Mes nustatėme ryšį tarp infrastruktūros kodo darbo automatizavimo ir to, kiek informacijos saugoma infrastruktūros saugykloje. Aukšto profilio komandos saugyklose saugo daugiau informacijos: tai infrastruktūros konfigūracija, CI / CD konfigūracija, aplinkos parametrai ir kūrimo parametrai. Jie dažniau saugo šią informaciją, geriau dirba su infrastruktūros kodu ir automatizuoja daugiau procesų ir užduočių darbui su infrastruktūros kodu.

Įdomu tai, kad infrastruktūros testuose nepastebėjome didelio skirtumo. Tai sieju su tuo, kad aukšto lygio komandos turi daugiau testavimo automatizavimo. Galbūt juos atskirai blaško ne infrastruktūros testai, o tie testai, su kuriais tikrina aplikacijas ir jų dėka jau mato ką ir kur sugedo.

Integracija ir pristatymas

Nuobodžiausia skiltis, nes patvirtinome, kad kuo daugiau automatizavimo turėsite, kuo geriau dirbsite su kodu, tuo didesnė tikimybė, kad pasieksite geresnių rezultatų.

Architektūra

Norėjome pamatyti, kaip mikropaslaugos veikia našumą. Tiesą sakant, ne, nes mikropaslaugų naudojimas nėra susijęs su veiklos rodiklių padidėjimu. Mikropaslaugos naudojamos tiek aukšto profilio, tiek žemo profilio komandoms.

Tačiau svarbu tai, kad aukštųjų komandų perėjimas prie mikropaslaugų architektūros leidžia savarankiškai plėtoti savo paslaugas ir įdiegti. Jei architektūra leidžia kūrėjams veikti autonomiškai, nelaukiant ko nors iš išorės, tai yra pagrindinė spartos didinimo kompetencija. Tokiu atveju padeda mikropaslaugos. Ir tik jų įgyvendinimas nevaidina didelio vaidmens.

Kaip mes visa tai atradome?

Turėjome ambicingą planą visiškai atkartoti DORA metodiką, tačiau trūko išteklių. Jei DORA naudoja daug rėmimo ir jų tyrimai užtrunka pusmetį, savo tyrimą atlikome per trumpą laiką. Norėjome sukurti „DevOps“ modelį, kaip tai daro DORA, ir tai padarysime ateityje. Iki šiol apsiribojome šilumos žemėlapiais:

Išnagrinėjome inžinerinės praktikos pasiskirstymą komandose kiekviename profilyje ir nustatėme, kad aukšto lygio komandos buvo labiau linkusios naudoti inžinerinę praktiką. Daugiau apie visa tai galite perskaityti mūsų ataskaita.

Norėdami pakeisti, pereikime nuo sudėtingos statistikos prie paprastos.

Ką dar atradome?

Įrankiai

Pastebime, kad daugumą komandų naudoja Linux šeimos OS. Tačiau „Windows“ vis dar yra tendencija – mažiausiai ketvirtadalis mūsų respondentų pažymėjo vienos ar kitos jos versijos naudojimą. Atrodo, kad rinka turi tokį poreikį. Todėl šias kompetencijas galite ugdyti ir vesti pranešimus konferencijose.

Tarp orkestrantų – niekam ne paslaptis, „Kubernetes“ pirmauja (52 proc.). Kitas eilėje orkestrantas yra Docker Swarm (apie 12%). Populiariausios CI sistemos yra Jenkins ir GitLab. Populiariausia konfigūracijos valdymo sistema yra Ansible, po kurios seka mūsų mylimas Shell.

„Amazon“ šiuo metu yra pirmaujanti debesų prieglobos paslaugų teikėja. Rusiškų debesų dalis pamažu didėja. Kitais metais bus įdomu pamatyti, kaip jausis Rusijos debesų tiekėjai, ar padidės jų rinkos dalis. Jie yra, jie gali būti naudojami, ir tai gerai:

Perduodu žodį Igoriui, kuris pateiks daugiau statistikos.

Praktikos sklaida

Igoris Kuročkinas: Atskirai prašėme respondentų nurodyti, kaip įmonėje paskirstoma svarstoma inžinerinė praktika. Daugumoje įmonių taikomas mišrus požiūris, susidedantis iš skirtingų modelių, o bandomieji projektai yra labai populiarūs. Taip pat pastebėjome nedidelį skirtumą tarp profilių. Aukšto profilio atstovai dažniau taiko šabloną „Iniciatyva iš apačios“, kai nedidelės specialistų komandos keičia darbo procesus, įrankius, dalijasi sėkminga praktika su kitomis komandomis. „Medium“ tai yra „iš viršaus į apačią“ vykdoma iniciatyva, kuri paveikia visą įmonę, sukuriant bendruomenes ir kompetencijos centrus:

Agile ir DevOps

Pramonėje dažnai aptariamas Agile ir DevOps ryšio klausimas. Ši problema taip pat keliama 2019/2020 m. Agile būklės ataskaitoje, todėl nusprendėme palyginti, kaip įmonėse susieja Agile ir DevOps veikla. Mes nustatėme, kad „DevOps“ be „Agile“ yra reta. Pusei respondentų Agile plitimas prasidėjo daug anksčiau, o apie 20% stebėjo tuo pačiu metu pradžią, o vienas iš žemo profilio požymių bus Agile ir DevOps praktikų nebuvimas:

Komandų topologijos

Praėjusių metų pabaigoje išleista knyga „Komandos topologijos“, kuriame siūloma komandų topologijų apibūdinimo sistema. Mums pasidarė įdomu, ar tai taikytina Rusijos įmonėms. Ir mes uždavėme klausimą: "Kokius modelius randate?".

Pusėje respondentų stebimos infrastruktūros komandos, taip pat atskiros komandos kūrimui, testavimui ir eksploatacijai. Atskiros „DevOps“ komandos pažymėjo 45%, tarp kurių „High“ atstovai yra labiau paplitę. Toliau ateina daugiafunkcinės komandos, kurios taip pat labiau paplitusios High. Atskiros SRE komandos rodomos aukšto, vidutinio profiliuose ir retai matomos žemame profilyje:

DevQaOps santykis

Tokį klausimą „FaceBook“ išvydome iš „Skyeng“ platformos komandos komandos vadovo – jis domėjosi kūrėjų, testuotojų ir administratorių santykiu įmonėse. Mes to paklausėme ir peržiūrėjome atsakymus pagal profilius: Aukšto lygio atstovai turi mažiau bandymų ir operacijų inžinierių kiekvienam kūrėjui:

2021 m. Planai

Kitų metų planuose respondentai pažymėjo tokias veiklas:

Čia galite pamatyti sankirtą su DevOps Live 2020 konferencija. Atidžiai peržiūrėjome programą:

• Infrastruktūra kaip produktas
• „DevOps“ transformacija
• DevOps praktikos platinimas
• „DevSecOps“
• Atvejų klubai ir diskusijos

Tačiau mūsų pristatymo laiko neužtenka visoms temoms aprėpti. Liko už kadro:

• Platforma kaip paslauga ir kaip produktas;
• Infrastruktūra kaip kodas, aplinka ir debesys;
• Nuolatinis integravimas ir pristatymas;
• Architektūra;
• DevSecOps modeliai;
• Platforminės ir daugiafunkcinės komandos.

Ataskaita gavome didelį, 50 puslapių, ir galite jį pamatyti išsamiau.

Sumavimas

Tikimės, kad mūsų tyrimas ir ataskaita įkvėps jus eksperimentuoti su naujais kūrimo, testavimo ir veiklos požiūriais, taip pat padės naršyti, palyginti save su kitais tyrimo dalyviais ir nustatyti sritis, kuriose galite patobulinti savo metodus.

Pirmojo DevOps būklės Rusijoje tyrimo rezultatai:

• Pagrindinės metrikos. Mes nustatėme, kad pagrindinės metrikos (pristatymo laikas, diegimo dažnis, atkūrimo laikas ir pakeitimo gedimai) tinka kūrimo, testavimo ir operacijų procesų efektyvumui analizuoti.
• Profiliai Aukštas, Vidutinis, Žemas. Remiantis surinktais duomenimis, galime išskirti statistiškai skirtingas aukšto, vidutinio, žemo lygio grupes, turinčias savitų bruožų metrikos, praktikos, procesų ir įrankių požiūriu. Aukšto profilio atstovai rodo geresnius rezultatus nei žemi. Jie labiau linkę pasiekti ir viršyti savo tikslus.
• Rodikliai, pandemija ir planai 2021 m. Ypatingas šių metų rodiklis – kaip įmonės susidorojo su pandemija. Aukštiesiems atstovams sekėsi geriau, jie patyrė didesnį vartotojų įsitraukimą, o pagrindinės sėkmės priežastys buvo efektyvūs plėtros procesai ir stipri inžinerinė kultūra.
• DevOps praktikos, įrankiai ir jų kūrimas. Pagrindiniuose kitų metų įmonių planuose – „DevOps“ praktikų ir įrankių plėtra, „DevSecOps“ praktikų diegimas, organizacinės struktūros pokyčiai. O efektyvus DevOps praktikų diegimas ir plėtra vykdoma pasitelkiant pilotinius projektus, formuojant bendruomenes ir kompetencijos centrus, iniciatyvas aukštesniame ir žemesniame įmonės lygmenyse.

Norėtume išgirsti jūsų atsiliepimus, istorijas, atsiliepimus. Dėkojame visiems dalyvavusiems tyrime ir laukiame jūsų dalyvavimo kitais metais.

Šaltinis: www.habr.com