Gjendja e DevOps në Rusi 2020

Si e kuptoni gjendjen e diçkaje?

Ju mund të mbështeteni në mendimin tuaj, të formuar nga burime të ndryshme informacioni, për shembull, publikime në faqet e internetit ose përvoja. Ju mund të pyesni kolegët dhe miqtë tuaj. Një tjetër mundësi është të shikoni temat e konferencave: komiteti i programit është përfaqësues aktiv i industrisë, ndaj ne u besojmë atyre në zgjedhjen e temave përkatëse. Një fushë më vete janë kërkimet dhe raportet. Por ka një problem. Hulumtimet për gjendjen e DevOps kryhen çdo vit në mbarë botën, raportet publikohen nga kompani të huaja dhe nuk ka pothuajse asnjë informacion në lidhje me DevOps ruse.

Por ka ardhur dita kur është kryer një studim i tillë dhe sot do t'ju tregojmë për rezultatet e marra. Gjendja e DevOps në Rusi u studiua bashkërisht nga kompanitë "Shpreh 42"Dhe"Ontico" Kompania Express 42 ndihmon kompanitë e teknologjisë të zbatojnë dhe zhvillojnë praktikat dhe mjetet e DevOps dhe ishte një nga të parat që foli për DevOps në Rusi. Autorët e studimit, Igor Kurochkin dhe Vitaly Khabarov, janë të angazhuar në analiza dhe konsultime në Express 42, duke pasur një sfond teknik nga operimi dhe përvojë në kompani të ndryshme. Gjatë 8 viteve, kolegët shikuan dhjetëra kompani dhe projekte - nga startup-et tek sipërmarrjet - me probleme të ndryshme, si dhe pjekuri të ndryshme kulturore dhe inxhinierike.

Në raportin e tyre, Igor dhe Vitaly shpjeguan se çfarë problemesh kishte gjatë procesit të kërkimit, si i zgjidhën ato, si dhe se si kryhen në parim kërkimet e DevOps dhe pse Express 42 vendosi të kryejë të tyren. Ju mund të shihni raportin e tyre këtu.

Hulumtimi i DevOps

Igor Kurochkin filloi bisedën.

Ne pyesim rregullisht audiencën në konferencat e DevOps: "A e keni lexuar raportin e sivjetmë të gjendjes së DevOps?" Vetëm disa ngrenë duart, por hulumtimi ynë tregoi se vetëm një e treta i studion ato. Nëse nuk keni parë kurrë raporte të tilla, le të themi menjëherë se të gjitha janë shumë të ngjashme. Më shpesh ka fraza si: "Krahasuar me vitin e kaluar..."

Këtu kemi problemin tonë të parë, të ndjekur nga dy të tjerë:

1. Nuk kemi të dhëna për vitin e kaluar. Askush nuk është i interesuar për gjendjen e DevOps në Rusi;
2. Metodologjia. Nuk është e qartë se si të testohen hipotezat, si të ndërtohen pyetje, si të bëhet analiza, të krahasohen rezultatet, të gjenden lidhjet;
3. Terminologjia. Të gjitha raportet janë në anglisht, kërkohet përkthim, ende nuk është shpikur një kornizë e përbashkët për DevOps dhe secili vjen me të vetën.

Le të shohim se si u kryen përgjithësisht analizat e gjendjes së DevOps në botë.

Informacioni historik

Hulumtimi i DevOps është kryer që nga viti 2011. I pari që i kreu ato ishte Puppet, një zhvillues i sistemeve të menaxhimit të konfigurimit. Në atë kohë, ai ishte një nga mjetet kryesore për përshkrimin e infrastrukturës në formën e kodit. Deri në vitin 2013, këto studime ishin thjesht anketa në format të mbyllur dhe pa raportim publik.

Në vitin 2013 u shfaq, IT Revolution, botues i të gjithë librave kryesorë në DevOps. Së bashku me Puppet, ata përgatitën botimin e parë "State of DevOps", ku u shfaqën për herë të parë 4 metrikë kryesore. Një vit më pas, kompania konsulente ThoughtWorks, e njohur për radarët e saj të rregullt të teknologjisë mbi praktikat dhe mjetet e industrisë, u përfshi. Dhe në vitin 2015 u shtua një seksion me metodologji dhe u bë e qartë se si e kryejnë analizën.

Në vitin 2016, autorët e studimit, pasi krijuan kompaninë e tyre DORA (Kërkim dhe Vlerësim i DevOps), publikuan një raport vjetor. Një vit më pas, DORA dhe Puppet publikuan raportin e tyre përfundimtar të përbashkët.

Dhe pastaj gjërat u bënë interesante:

Në vitin 2018, kompanitë u ndanë dhe u publikuan dy raporte të pavarura: një nga Puppet, i dyti nga DORA në bashkëpunim me Google. DORA vazhdoi të përdorë metodologjinë e saj me metrikat kryesore, profilet e performancës dhe praktikat inxhinierike që ndikojnë në metrikat kryesore dhe performancën në të gjithë kompaninë. Dhe Puppet propozoi qasjen e saj me një përshkrim të procesit dhe evolucionit të DevOps. Por historia nuk u kap; në vitin 2019, Puppet braktisi këtë metodologji dhe lëshoi ​​një version të ri të raporteve, në të cilin renditi praktikat kryesore dhe se si ato ndikojnë në DevOps nga këndvështrimi i tyre. Më pas ndodhi një gjë tjetër: Google bleu DORA-n dhe së bashku publikuan një raport tjetër. Ndoshta e keni parë.

Këtë vit gjërat u ndërlikuan. Dihet se Puppet nisi sondazhin e saj. Ata e bënë atë një javë më herët se ne, dhe tashmë ishte përfunduar. Ne morëm pjesë në të dhe pamë se cilat tema i interesonin. Puppet tani po kryen analizën e saj dhe po përgatitet të publikojë raportin.

Por ende nuk ka asnjë njoftim nga DORA dhe Google. Në maj, kur zakonisht fillonte sondazhi, erdhi informacioni se Nicole Forsgren, një nga themeluesit e DORA, ishte zhvendosur në një kompani tjetër. Prandaj, ne supozuam se nuk do të kishte asnjë hulumtim apo raport nga DORA këtë vit.

Si janë gjërat në Rusi?

Ne nuk kemi kryer asnjë kërkim mbi DevOps. Ne folëm në konferenca, duke ritreguar përfundimet e njerëzve të tjerë dhe Raiffeisenbank përktheu "State of DevOps" për vitin 2019 (mund ta gjeni njoftimin e tyre në Habré), shumë faleminderit për ta. Dhe është e gjitha.

Prandaj, ne kryem kërkimin tonë në Rusi duke përdorur metodologjitë dhe gjetjet e DORA. Ne përdorëm raportin e kolegëve nga Raiffeisenbank për kërkimin tonë, duke përfshirë sinkronizimin e terminologjisë dhe përkthimit. Dhe pyetjet që lidhen me industrinë u morën nga raportet DORA dhe pyetësori i Kukullave të këtij viti.

Procesi i kërkimit

Raporti është vetëm pjesa e fundit. I gjithë procesi i kërkimit përbëhet nga katër faza të mëdha:

Gjatë fazës së përgatitjes, ne intervistuam ekspertë të industrisë dhe përgatitëm një listë hipotezash. Në bazë të tyre, ne përpiluam pyetje dhe nisëm një anketë për të gjithë muajin gusht. Më pas kemi analizuar dhe përgatitur vetë raportin. Për DORA, ky proces zgjat 6 muaj. E përfunduam në 3 muaj dhe tani e kuptojmë se mezi kishim kohë: vetëm duke bërë analizën kupton se çfarë pyetjesh duhen bërë.

Pjesëmarrësit

Të gjitha raportet e huaja fillojnë me një portret të pjesëmarrësve, dhe shumica e tyre nuk janë nga Rusia. Përqindja e të anketuarve rusë luhatet nga 5 në 1% nga viti në vit, dhe kjo nuk na lejon të nxjerrim ndonjë përfundim.

Harta nga raporti Accelerate State of DevOps 2019:

Në studimin tonë, ne ishim në gjendje të intervistonim 889 njerëz - kjo është shumë (DORA anketon rreth një mijë njerëz në vit në raportet e saj) dhe këtu arritëm qëllimin tonë:

Vërtetë, jo të gjithë pjesëmarrësit tanë arritën në fund: përqindja e përfundimit ishte pak më pak se gjysma. Por kjo ishte e mjaftueshme për të marrë një mostër përfaqësuese dhe për të kryer analiza. DORA nuk zbulon normat e banimit në raportet e saj, kështu që këtu nuk mund të bëhen krahasime.

Industritë dhe pozicionet

Të anketuarit tanë përfaqësojnë një duzinë industri. Gjysmë punë në teknologjinë e informacionit. Më pas vijojnë shërbimet financiare, tregtia, telekomunikacioni e të tjera. Ndër pozicionet janë specialistë (zhvillues, testues, inxhinier operimi) dhe staf menaxhues (drejtues të ekipeve, grupeve, zonave, drejtorëve):

Çdo person i dytë punon në një kompani të mesme. Çdo person i tretë punon në kompani të mëdha. Shumica punojnë në ekipe deri në 9 persona. Më vete, ne pyetëm për aktivitetet kryesore, dhe shumica janë në një mënyrë ose në një tjetër të lidhur me funksionimin, dhe rreth 40% janë të përfshirë në zhvillim:

Kështu kemi mbledhur informacione për krahasim dhe analizë të përfaqësuesve të industrive, kompanive dhe ekipeve të ndryshme. Kolegu im Vitaly Khabarov do t'ju tregojë për analizën.

Analiza dhe krahasimi

Vitaly Khabarov: Shumë faleminderit për të gjithë pjesëmarrësit që përfunduan sondazhin tonë, plotësuan pyetësorët dhe na dhanë të dhëna për analiza dhe testim të mëtejshëm të hipotezave tona. Dhe falë klientëve dhe klientëve tanë, ne kemi një përvojë të pasur që na ka ndihmuar të identifikojmë çështjet shqetësuese për industrinë dhe të formulojmë hipotezat që kemi testuar në kërkimin tonë.

Fatkeqësisht, nuk mund të marrësh thjesht një listë pyetjesh nga njëra anë dhe të dhëna nga ana tjetër, t'i krahasosh disi ato, të thuash: "Po, gjithçka funksionon ashtu, ne kishim të drejtë" dhe të shkoni në rrugët tona. Jo, ne kemi nevojë për metodologji dhe metoda statistikore për t'u siguruar që nuk kemi gabuar dhe se përfundimet tona janë të besueshme. Pastaj ne mund të ndërtojmë punën tonë të mëtejshme mbi bazën e këtyre të dhënave:

Metrikat kryesore

Ne morëm si bazë metodologjinë DORA, të cilën ata e përshkruan në detaje në librin "Përshpejtoni gjendjen e DevOps". Ne kontrolluam nëse metrikat kryesore janë të përshtatshme për tregun rus, nëse ato mund të përdoren në të njëjtën mënyrë siç përdor DORA për t'iu përgjigjur pyetjes: "Si korrespondon industria në Rusi me industrinë e huaj?"

Metrikat kryesore:

1. Frekuenca e vendosjes. Sa shpesh shpërndahet një version i ri i një aplikacioni në mjedisin e prodhimit (ndryshimet e planifikuara, duke përjashtuar korrigjimet e shpejta dhe reagimin ndaj incidentit)?
2. Koha e dërgimit. Sa është koha mesatare midis kryerjes së një ndryshimi (shkrimi i funksionalitetit si kod) dhe vendosjes së ndryshimit në mjedisin e prodhimit?
3. Koha e rikuperimit. Sa kohë duhet mesatarisht për të rivendosur një aplikacion në një mjedis prodhimi pas një incidenti, degradimi të shërbimit ose zbulimit të një gabimi që prek përdoruesit e aplikacionit?
4. Ndryshime të pasuksesshme. Sa përqind e vendosjeve në një mjedis produkti çojnë në degradim ose incidente të aplikacionit dhe kërkojnë eliminimin e pasojave (kthimi i ndryshimeve, zhvillimi i një rregullimi të drejtpërdrejtë ose patch)?

Hulumtimi i DORA ka gjetur një lidhje midis këtyre metrikave dhe performancës organizative. Ne gjithashtu e kontrollojmë atë në studimin tonë.

Por për t'u siguruar që katër metrikat kryesore mund të ndikojnë në diçka, duhet të kuptoni - a janë ato disi të lidhura me njëra-tjetrën? DORA u përgjigj po, me një paralajmërim: marrëdhënia midis normës së dështimit të ndryshimit dhe tre metrikave të tjera është pak më e dobët. Kemi marrë pothuajse të njëjtën foto. Nëse koha e dorëzimit, frekuenca e vendosjes dhe koha e rikuperimit janë të ndërlidhura me njëra-tjetrën (ne kemi vendosur këtë korrelacion përmes korrelacionit Pearson dhe përmes shkallës Chaddock), atëherë nuk ka një korrelacion kaq të fortë me ndryshimet e pasuksesshme.

Në parim, shumica e të anketuarve priren të përgjigjen se kanë një numër mjaft të vogël incidentesh që ndodhin në prodhim. Edhe pse do të shohim më vonë se ka ende një ndryshim domethënës midis grupeve të të anketuarve në shkallën e ndryshimeve të pasuksesshme, ne ende nuk mund ta përdorim këtë metrikë për këtë ndarje.

Ne ia atribuojmë këtë faktit se (siç doli në procesin e analizës dhe komunikimit me disa nga klientët tanë) ka një ndryshim të vogël në perceptimin e asaj që konsiderohet një incident. Nëse kemi arritur të rivendosim funksionalitetin e shërbimit tonë gjatë dritares teknike, a mund të konsiderohet ky një incident? Ndoshta jo, sepse ne rregulluam gjithçka, jemi të shkëlqyer. A mund të konsiderohet si një incident nëse do të na duhej të riprodhonim aplikacionin tonë 10 herë në modalitetin normal dhe të njohur? Nuk duket. Prandaj, çështja e marrëdhënies midis ndryshimeve të pasuksesshme dhe metrikave të tjera mbetet e hapur. Do ta sqarojmë më tej.

Ajo që është e rëndësishme këtu është se kemi gjetur një lidhje të rëndësishme midis kohës së dorëzimit, kohës së rikuperimit dhe frekuencës së vendosjes. Prandaj, ne morëm këto tre metrika për t'i ndarë më tej të anketuarit në grupe bazuar në produktivitetin.

Sa për të peshuar në gram?

Ne përdorëm analizën e grupimeve hierarkike:

• Ne i shpërndajmë të anketuarit në hapësirën n-dimensionale, ku koordinata e secilit të anketuar është përgjigjet e tyre ndaj pyetjeve.
• Ne deklarojmë se çdo të anketuar është një grup i vogël.
• Ne kombinojmë dy grupimet më afër njëri-tjetrit në një grup më të madh.
• Gjejmë çiftin tjetër të grupimeve dhe i bashkojmë në një grup më të madh.

Kështu i grupojmë të gjithë të anketuarit në numrin e grupeve që na duhen. Duke përdorur një dendrogram (një pemë e lidhjeve midis grupimeve) ne shohim distancën midis dy grupimeve fqinje. E vetmja gjë që na mbetet është të vendosim një kufi të caktuar në distancën midis këtyre grupimeve dhe të themi: "Këto dy grupe janë mjaft të dallueshme nga njëri-tjetri, sepse distanca midis tyre është gjigante".

Por këtu ka një problem të fshehur: ne nuk kemi kufizime në numrin e grupimeve - mund të marrim 2, 3, 4, 10 grupime. Dhe ideja e parë ishte - pse të mos i ndajmë të gjithë të anketuarit tanë në 4 grupe, siç bën DORA. Por ne zbuluam se dallimet midis këtyre grupeve bëhen të parëndësishme dhe nuk mund të jemi të sigurt se i anketuari i përket me të vërtetë grupit të tij dhe jo atij fqinj. Ne ende nuk mund ta ndajmë tregun rus në katër grupe. Prandaj, ne u vendosëm në tre profile, midis të cilave ka një ndryshim statistikisht domethënës:

Më pas, ne përcaktuam profilin sipas grupit: morëm mesataret për secilën metrikë për secilin grup dhe përpiluam një tabelë të profileve të efikasitetit. Në fakt, janë marrë profilet e performancës që rezultojnë për pjesëmarrësin mesatar në secilin grup. Ne kemi identifikuar tre profile të efikasitetit: i ulët, i mesëm, i lartë:

Këtu kemi konfirmuar hipotezën tonë se 4 metrikë kryesore janë të përshtatshme për përcaktimin e profilit të performancës dhe ato funksionojnë si në tregun perëndimor ashtu edhe në atë rus. Ka një ndryshim midis grupeve, dhe ai është statistikisht i rëndësishëm. Dua të theksoj se ka një ndryshim domethënës në mesataren midis profileve të performancës për metrikën e ndryshimeve të pasuksesshme, edhe pse fillimisht nuk i kemi ndarë të anketuarit me këtë parametër.

Atëherë lind pyetja: si të përdoret e gjithë kjo?

Si të përdorni

Nëse marrim ndonjë ekip, 4 metrikë kryesore dhe e zbatojmë atë në tabelë, atëherë në 85% të rasteve nuk do të marrim një ndeshje të plotë - ky është vetëm pjesëmarrësi mesatar, dhe jo ajo që është në realitet. Ne jemi të gjithë (dhe çdo ekip) pak më ndryshe.

Ne kontrolluam: morëm të anketuarit tanë dhe profilin e performancës DORA, dhe shikuam se sa të anketuar korrespondonin me një ose një profil tjetër. Ne zbuluam se vetëm 16% e të anketuarve ranë saktësisht në një nga profilet. Të gjitha të tjerat janë të shpërndara diku në mes:

Kjo do të thotë që profili i performancës ka një shtrirje të kufizuar. Për të marrë një përafrim të parë të vendit ku jeni, mund të përdorni këtë tabelë: "Oh, duket sikur jemi më afër Mesatare ose Lartë!" Nëse e kuptoni se ku po shkoni më pas, kjo mund të jetë e mjaftueshme. Por nëse qëllimi juaj është përmirësim i vazhdueshëm, i vazhdueshëm dhe dëshironi të dini më saktë se ku të zhvilloni dhe çfarë të bëni, atëherë nevojiten fonde shtesë. Ne i quajtëm ata kalkulatorë:

• Llogaritësi DORA
• Llogaritësi Express 42* (në zhvillim)
• Zhvillimi juaj (ju mund të krijoni kalkulatorin tuaj të brendshëm).

Për çfarë nevojiten? Të kuptosh:

• A i plotëson ekipi brenda organizatës sonë standardet tona?
• Nëse jo, a mund ta ndihmojmë atë - ta përshpejtojmë në kuadër të ekspertizës që ka kompania jonë?
• Nëse po, a mund të bëjmë edhe më mirë?

Ju gjithashtu mund t'i përdorni ato për të mbledhur statistika brenda kompanisë:

• Çfarë lloj skuadrash kemi?
• Ndani ekipet në profile;
• Shih: Oh, këto ekipe po performojnë dobët (pak të ngadalta), por këto janë të shkëlqyera: ata vendosen çdo ditë, pa gabime, koha e tyre e udhëheqjes është më pak se një orë.

Dhe më pas mund të mësoni se brenda kompanisë sonë ne kemi ekspertizën dhe mjetet e nevojshme për ato ekipe që ende janë në mungesë.

Ose, nëse e kuptoni që ndiheni mirë brenda kompanisë, se jeni më mirë se shumë, atëherë mund të shikoni pak më gjerë. Kjo është pikërisht industria ruse: a mund të marrim ekspertizën e nevojshme në industrinë ruse për të shpejtuar veten? Llogaritësi Express 42 do të ndihmojë këtu (është në zhvillim e sipër). Nëse e keni tejkaluar tregun rus, atëherë shikoni Llogaritësi DORA dhe në tregun botëror.

Mirë. Dhe nëse jeni në grupin Elit sipas kalkulatorit DORA, atëherë çfarë duhet të bëni? Nuk ka zgjidhje të mirë këtu. Me shumë mundësi, ju jeni në ballë të industrisë, dhe përmirësimet e mëtejshme të përshpejtimit dhe besueshmërisë janë të mundshme përmes kërkimit dhe zhvillimit të brendshëm dhe shpenzimit të burimeve të mëdha.

Le të kalojmë në pjesën më të ëmbël - krahasimin.

krahasim

Fillimisht donim të krahasonim industrinë ruse me atë perëndimore. Nëse krahasojmë drejtpërdrejt, shohim se kemi më pak profile, dhe ato janë pak më të përziera me njëri-tjetrin, kufijtë janë pak më të paqartë:

Interpretuesit tanë të elitës janë të fshehur në mesin e performuesve të lartë, por ata janë atje - këta janë elita, njëbrirësh që kanë arritur lartësi të konsiderueshme. Në Rusi, ndryshimi midis profileve Elite dhe High nuk është ende mjaft i rëndësishëm. Mendojmë se në të ardhmen kjo ndarje do të ndodhë për shkak të rritjes së kulturës inxhinierike, cilësisë së zbatimit të praktikave inxhinierike dhe ekspertizës brenda kompanive.

Nëse kalojmë në krahasimin e drejtpërdrejtë brenda industrisë ruse, shohim se ekipet e profilit të lartë janë më të mirë në të gjitha aspektet. Ne konfirmuam gjithashtu hipotezën tonë se ekziston një lidhje midis këtyre metrikave dhe efektivitetit organizativ: Ekipet e profilit të lartë kanë shumë më shumë gjasa që jo vetëm të arrijnë qëllimet, por edhe t'i tejkalojnë ato.
Le të bëhemi ekipe të profilit të lartë dhe të mos ndalemi me kaq:

Por ky vit është i veçantë dhe ne vendosëm të kontrollojmë se si kompanitë po jetojnë në një pandemi: Ekipet e profilit të lartë përballen dukshëm më mirë dhe ndihen më mirë se mesatarja e industrisë:

• Produktet e reja u lëshuan 1,5-2 herë më shpesh,
• Rritja e besueshmërisë dhe/ose performanca e infrastrukturës së aplikacionit 2 herë më shpesh.

Kjo do të thotë, kompetencat që ata tashmë kishin i ndihmuan ata të zhvillohen më shpejt, të prezantojnë produkte të reja, të modifikojnë produktet ekzistuese, duke pushtuar kështu tregje të reja dhe përdorues të rinj:

Çfarë tjetër i ka ndihmuar ekipet tona?

Praktikat inxhinierike

Unë do t'ju tregoj për gjetjet e rëndësishme për secilën praktikë që kemi kontrolluar. Ndoshta diçka tjetër i ndihmoi ekipet, por ne po flasim për DevOps. Dhe brenda DevOps, ne shohim dallime midis ekipeve të profileve të ndryshme.

Platforma si shërbim

Ne nuk gjetëm një lidhje domethënëse midis moshës së platformës dhe profilit të ekipit: Platformat u shfaqën afërsisht në të njëjtën kohë si për ekipet e ulëta ashtu edhe për ato të larta. Por për këtë të fundit, platforma ofron mesatarisht më shumë shërbime dhe më shumë ndërfaqe softuerike për kontroll përmes kodit të programit. Dhe ekipet e platformës kanë më shumë gjasa të ndihmojnë zhvilluesit dhe ekipet e tyre të përdorin platformën, më shumë gjasa të zgjidhin problemet dhe incidentet e tyre që lidhen me platformën dhe të trajnojnë ekipe të tjera.

Infrastruktura si kod

Gjithçka këtu është mjaft standarde. Ne gjetëm një lidhje midis automatizimit të kodit të infrastrukturës dhe sasisë së informacionit të ruajtur brenda depove të infrastrukturës. Ekipet e profilit të lartë ruajnë më shumë informacion në depo: kjo përfshin konfigurimin e infrastrukturës, tubacionin CI/CD, cilësimet e mjedisit dhe parametrat e ndërtimit. Ata e ruajnë këtë informacion më shpesh, punojnë më mirë me kodin e infrastrukturës dhe kanë automatizuar më shumë procese dhe detyra për të punuar me kodin e infrastrukturës.

Interesante, ne nuk pamë një ndryshim domethënës në testet e infrastrukturës. Unë ia atribuoj këtë faktit që ekipet e profilit të lartë në përgjithësi kanë më shumë automatizim testimi. Ndoshta nuk duhet të shpërqendrohen veçmas nga testet e infrastrukturës, por mjaftojnë testet që përdorin për të kontrolluar aplikacionet dhe falë tyre mund të shohin se çfarë dhe ku janë prishur.

Integrimi dhe shpërndarja

Seksioni më i mërzitshëm, sepse ne konfirmuam: sa më shumë automatizim të keni, aq më mirë punoni me kodin, aq më shumë ka të ngjarë të merrni rezultate më të mira.

Arkitekturë

Ne donim të shihnim se si mikroshërbimet ndikojnë në performancën. Për të qenë i sinqertë, ata nuk e bëjnë këtë, pasi përdorimi i mikroshërbimeve nuk shoqërohet me një rritje të treguesve të efikasitetit. Mikroshërbimet përdoren nga ekipet e profilit të lartë dhe të ulët.

Por ajo që është domethënëse është se për ekipet e larta, kalimi në një arkitekturë mikroshërbimi i lejon ata të zhvillojnë në mënyrë të pavarur shërbimet e tyre dhe t'i nxjerrin ato. Nëse arkitektura i lejon zhvilluesit të veprojnë në mënyrë autonome, pa pritur dikë jashtë ekipit, atëherë kjo është një kompetencë kyçe për rritjen e shpejtësisë. Këtu ndihmojnë mikroshërbimet. Por thjesht zbatimi i tyre nuk luan një rol të madh.

Si i zbuluam të gjitha këto?

Ne kishim një plan ambicioz për të përsëritur plotësisht metodologjinë DORA, por na mungonin burimet. Nëse DORA përdor shumë sponsorizime dhe studimi zgjat gjashtë muaj, ne e kryem studimin tonë në një kohë të shkurtër. Ne donim të ndërtonim një model DevOps siç bën DORA, dhe ne do ta bëjmë këtë në të ardhmen. Tani për tani jemi kufizuar në hartat e ngrohjes:

Ne shikuam shpërndarjen e praktikave inxhinierike midis ekipeve të secilit profil dhe zbuluam se ekipet e profilit të lartë, mesatarisht, përdorin më shpesh praktikat inxhinierike. Ju mund të lexoni më shumë për të gjitha këto në faqen tonë raportin.

Për një ndryshim, le të kalojmë nga statistikat komplekse në ato të thjeshta.

Çfarë tjetër kemi zbuluar?

Mjete

Ne vërejmë se familja Linux OS përdor më shumë komanda. Por Windows është ende në trend - të paktën një e katërta e të anketuarve tanë vunë re përdorimin e një ose një versioni tjetër të tij. Tregu duket se e ka këtë nevojë. Prandaj, ju mund t'i zhvilloni këto kompetenca dhe të jepni prezantime në konferenca.

Midis orkestruesve, nuk është sekret që Kubernetes kryeson (52%). Orkestratori tjetër në radhë është Docker Swarm (rreth 12%). Sistemet më të njohura CI janë Jenkins dhe GitLab. Sistemi më i popullarizuar i menaxhimit të konfigurimit është Ansible, i ndjekur nga Shell ynë i dashur.

Ndër ofruesit e pritjes së cloud, Amazon aktualisht zë pozitën udhëheqëse. Pjesa e reve ruse po rritet gradualisht. Vitin e ardhshëm do të jetë interesante të shihet se si do të ndihen ofruesit rusë të cloud dhe nëse pjesa e tyre e tregut do të rritet. Ato ekzistojnë, mund të përdoren, dhe kjo është mirë:

Ia jap fjalën Igorit, i cili do të japë disa statistika të tjera.

Përhapja e praktikave

Igor Kurochkin: Më vete, ne i kërkuam të anketuarve të tregonin se si shpërndahen praktikat inxhinierike të konsideruara në kompani. Shumica e kompanive kanë një qasje të përzier që përbëhet nga një grup modelesh të ndryshme dhe projektet pilot janë shumë të njohura. Ne pamë gjithashtu një ndryshim të vogël midis profileve. Përfaqësuesit e profilit të lartë përdorin më shpesh modelin "Iniciativa nga poshtë", kur ekipe të vogla specialistësh ndryshojnë proceset e punës, mjetet dhe ndajnë zhvillimet e suksesshme me ekipet e tjera. Në Medium, kjo është një nismë nga lart-poshtë që prek të gjithë kompaninë përmes krijimit të komuniteteve dhe qendrave të ekselencës:

Agile dhe DevOps

Marrëdhënia midis Agile dhe DevOps diskutohet shpesh në industri. Kjo pyetje ngrihet edhe në Raportin e Gjendjes së Agile për 2019/2020, ndaj vendosëm të krahasojmë se si lidhen aktivitetet Agile dhe DevOps në kompani. Ne kemi zbuluar se DevOps pa Agile është i rrallë. Për gjysmën e të anketuarve, përhapja e Agile filloi dukshëm më herët, dhe rreth 20% vëzhguan një fillim të njëkohshëm, dhe një nga shenjat e një profili të ulët do të jetë mungesa e praktikave Agile dhe DevOps:

Topologjitë e ekipit

Në fund të vitit të kaluar libri “Topologjitë e ekipit", i cili propozon një kornizë për përshkrimin e topologjive të ekipit. Pyesim veten nëse do të zbatohej për kompanitë ruse. Dhe ne shtruam pyetjen: "Çfarë modelesh shihni?"

Ekipet e infrastrukturës janë vëzhguar në gjysmën e të anketuarve, si dhe ekipe të veçanta të zhvillimit, testimit dhe operimit. Ekipet individuale të DevOps shënuan 45%, ndër të cilët përfaqësuesit e Lartë janë më të zakonshëm. Më pas vijnë ekipet ndërfunksionale, të cilat janë gjithashtu më të zakonshme në High. Komandat e veçanta SRE shfaqen në profilet e larta, të mesme dhe rrallë gjenden në profilin e ulët:

Raporti DevQaOps

Ne e pamë këtë pyetje në FaceBook nga drejtuesi i ekipit të platformës Skyeng - ai ishte i interesuar për raportin e zhvilluesve, testuesve dhe administratorëve në kompani. Ne e pyetëm atë dhe shikuam përgjigjet duke marrë parasysh profilet: përfaqësuesit e profilit të lartë kanë një numër më të vogël inxhinierësh testimi dhe operacionesh për secilin zhvillues:

Planet për vitin 2021

Në planet e tyre për vitin e ardhshëm, të anketuarit vunë në dukje aktivitetet e mëposhtme:

Këtu mund të shihni kryqëzimin me konferencën DevOps Live 2020. Ne e rishikuam me kujdes programin:

• Infrastruktura si produkt
• Transformimi i DevOps
• Shpërndarja e praktikave DevOps
• DevSecOps
• Klubet e rasteve dhe diskutimet

Por biseda jonë nuk do të ketë kohë të mjaftueshme për të mbuluar të gjitha temat. Mbrapa skenave:

• Platforma si shërbim dhe si produkt;
• Infrastruktura si kod, mjedise dhe re;
• Integrimi dhe shpërndarja e vazhdueshme;
• Arkitekturë;
• Modelet e DevSecOps;
• Ekipet e platformës dhe ndërfunksionale.

Raporti E jona është voluminoze, 50 faqe dhe mund ta shikoni më në detaje.

Përmbledhja

Shpresojmë që hulumtimi dhe raporti ynë do t'ju frymëzojë të eksperimentoni me qasje të reja për zhvillimin, testimin dhe funksionimin, si dhe do t'ju ndihmojë të kuptoni qëndrimet tuaja, të krahasoni veten me të tjerët në studim dhe të identifikoni fushat ku mund të përmirësoni qasjet tuaja.

Rezultatet e studimit të parë të gjendjes së DevOps në Rusi:

• Metrikat kryesore. Kemi zbuluar se metrikat kryesore (koha e dorëzimit, shkalla e vendosjes, koha e rikuperimit dhe dështimet e ndryshimit) janë të përshtatshme për të analizuar efektivitetin e proceseve të zhvillimit, testimit dhe operacioneve.
• Profilet e larta, të mesme, të ulëta. Bazuar në të dhënat e mbledhura, është e mundur të identifikohen grupe statistikisht të ndryshme: i lartë, i mesëm, i ulët, me veçori dalluese të bazuara në metrikë, praktika, procese dhe mjete. Përfaqësuesit e profilit të lartë tregojnë rezultate më të mira se të ulëta. Ata kanë më shumë gjasa të arrijnë dhe tejkalojnë qëllimet e tyre.
• Treguesit, pandemia dhe planet për vitin 2021. Një tregues i veçantë këtë vit është mënyra sesi kompanitë u përballën me pandeminë. High performoi më mirë, përjetoi një rritje në aktivitetin e përdoruesve dhe arsyet kryesore për sukses ishin proceset efikase të zhvillimit dhe një kulturë e fortë inxhinierike.
• Praktikat DevOps, mjetet dhe zhvillimi i tyre. Planet kryesore të kompanive për vitin e ardhshëm përfshijnë zhvillimin e praktikave dhe mjeteve të DevOps, prezantimin e praktikave DevSecOps dhe ndryshimet në strukturën organizative. Dhe zbatimi dhe zhvillimi efektiv i praktikave DevOps kryhet përmes projekteve pilot, formimit të komuniteteve dhe qendrave të kompetencës, nismave në nivelet e sipërme dhe të poshtme të kompanisë.

Do të jemi të lumtur të dëgjojmë komentet, tregimet, komentet tuaja. Falenderojmë të gjithë ata që morën pjesë në studim dhe presim pjesëmarrjen tuaj vitin e ardhshëm.

Burimi: www.habr.com