Stand van DevOps in Rusland 2020

Hoe om die toestand van iets te verstaan?

Jy kan staatmaak op jou mening, gevorm uit verskeie bronne van inligting, byvoorbeeld publikasies op webwerwe of ervaring. Jy kan kollegas, kennisse vra. Nog 'n opsie is om na die onderwerpe van die konferensies te kyk: die programkomitee is aktiewe verteenwoordigers van die bedryf, so ons vertrou hulle in die keuse van relevante onderwerpe. 'n Aparte area is navorsing en verslae. Maar daar is 'n probleem. Navorsing oor die stand van DevOps word jaarliks ​​in die wêreld gedoen, verslae word deur buitelandse maatskappye gepubliseer, en daar is byna geen inligting oor Russiese DevOps nie.

Maar die dag het aangebreek dat so 'n studie gedoen is, en vandag sal ons oor die resultate praat. Die toestand van DevOps in Rusland is gesamentlik deur die maatskappye bestudeer "Express 42"En"Ontico". Express 42 help tegnologiemaatskappye om DevOps-praktyke en -instrumente te implementeer en te ontwikkel en was een van die eerstes wat oor DevOps in Rusland gepraat het. Die skrywers van die studie, Igor Kurochkin en Vitaly Khabarov, is besig met ontleding en konsultasie by Express 42, terwyl hulle 'n tegniese agtergrond van bedryf en ondervinding in verskillende maatskappye het. Vir 8 jaar het kollegas gekyk na dosyne maatskappye en projekte - van beginners tot ondernemings - met verskillende probleme, sowel as verskillende kulturele en ingenieursvolwassenheid.

Igor en Vitaly het in hul verslag vertel watter probleme in die proses van navorsing was, hoe hulle dit opgelos het, asook hoe DevOps-navorsing in beginsel uitgevoer word en waarom Express 42 besluit het om sy eie te doen. Hulle verslag kan besigtig word hier.

DevOps Navorsing

Die gesprek is deur Igor Kurochkin begin.

Ons vra gereeld die gehoor by DevOps-konferensies: "Het jy die DevOps-statusverslag vir hierdie jaar gelees?" Min steek hul hande op, en ons studie het getoon dat slegs 'n derde hulle bestudeer. As jy nog nooit sulke verslae gesien het nie, kom ons sê dadelik dat hulle almal baie soortgelyk is. Dikwels is daar frases soos: "Vergeleke met verlede jaar ..."

Hier het ons die eerste probleem, en daarna nog twee:

1. Ons het nie data vir verlede jaar nie. Die toestand van DevOps in Rusland is vir niemand van belang nie;
2. Metodologie. Dit is nie duidelik hoe om hipoteses te toets, hoe om vrae te bou, hoe om te ontleed, resultate te vergelyk, verbande te vind nie;
3. Terminologie. Alle verslae is in Engels, vertaling word vereis, 'n gemeenskaplike DevOps-raamwerk is nog nie uitgevind nie en elkeen kom met hul eie vorendag.

Kom ons kyk hoe DevOps-staatontledings regoor die wêreld gedoen is.

Historiese inligting

DevOps-navorsing word sedert 2011 gedoen. Puppet, 'n ontwikkelaar van konfigurasiebestuurstelsels, was die eerste wat dit uitgevoer het. Op daardie tydstip was dit een van die hoofinstrumente om die infrastruktuur in die vorm van kode te beskryf. Tot 2013 was hierdie studies bloot geslote opnames en geen openbare verslae nie.

In 2013 het IT Revolution verskyn, die uitgewer van alle groot boeke oor DevOps. Saam met Puppet het hulle die eerste State of DevOps-publikasie voorberei, waar 4 sleutelmaatstawwe vir die eerste keer verskyn het. Die volgende jaar het ThoughtWorks, 'n konsultasiefirma bekend vir sy gereelde tegnologie-radars oor bedryfspraktyke en -gereedskap, betrokke geraak. En in 2015 is 'n afdeling met metodologie bygevoeg, en dit het duidelik geword hoe hulle die analise uitvoer.

In 2016 het die skrywers van die studie, nadat hulle hul eie maatskappy DORA (DevOps Research and Assessment) geskep het, 'n jaarverslag gepubliseer. Die volgende jaar het DORA en Puppet hul laaste gesamentlike verslag vrygestel.

En toe begin iets interessants:

In 2018 het die maatskappye verdeel en twee onafhanklike verslae is vrygestel: een van Puppet, die tweede van DORA in samewerking met Google. DORA het voortgegaan om sy metodologie te benut met sleutelmaatstawwe, prestasieprofiele en ingenieurspraktyke wat sleutelmaatstawwe en maatskappywye prestasie beïnvloed. En Puppet het sy eie benadering aangebied met 'n beskrywing van die proses en die evolusie van DevOps. Maar die storie het nie wortel geskiet nie, in 2019 het Puppet hierdie metodologie laat vaar en 'n nuwe weergawe van die verslae vrygestel, wat die sleutelpraktyke gelys het en hoe dit DevOps uit hul oogpunt beïnvloed. Toe gebeur nog 'n gebeurtenis: Google het DORA gekoop, en saam het hulle nog 'n verslag vrygestel. Jy het hom dalk gesien.

Vanjaar het dinge ingewikkeld geraak. Dit is bekend dat Puppet sy eie opname van stapel gestuur het. Hulle het dit 'n week vroeër as ons gedoen, en dit het reeds geëindig. Ons het daaraan deelgeneem en gekyk na watter onderwerpe hulle belangstel. Nou doen Puppet sy ontleding en berei voor om die verslag te publiseer.

Maar daar is steeds geen aankondiging van DORA en Google nie. In Mei, toe die opname gewoonlik begin het, het inligting gekom dat Nicole Forsgren, een van die stigters van DORA, na 'n ander maatskappy verhuis het. Daarom het ons aanvaar dat daar vanjaar geen navorsing en verslag van DORA sal wees nie.

Hoe gaan dit in Rusland?

Ons het nie DevOps-navorsing gedoen nie. Ons het by konferensies gepraat en ander mense se bevindings oorvertel, en Raiffeisenbank het "State of DevOps" vir 2019 vertaal (jy kan hul aankondiging op Habré vind), baie dankie aan hulle. En dit is al.

Daarom het ons ons eie navorsing in Rusland gedoen deur DORA-metodologieë en -bevindings te gebruik. Ons het die verslag van kollegas van Raiffeisenbank gebruik vir ons navorsing, insluitend vir sinchronisasie van terminologie en vertaling. En industrie-relevante vrae is geneem uit DORA-verslae en vanjaar se Puppet-vraelys.

Navorsingsproses

Die verslag is slegs die laaste deel. Die hele navorsingsproses bestaan ​​uit vier hoofstappe:

Tydens die voorbereidingsfase het ons onderhoude gevoer met bedryfskenners en 'n lys van hipoteses opgestel. Op grond daarvan is vrae saamgestel en 'n opname is vir die hele Augustus van stapel gestuur. Daarna het ons die verslag self ontleed en voorberei. Vir DORA neem hierdie proses 6 maande. Ons het binne 3 maande ontmoet, en nou verstaan ​​ons dat ons skaars genoeg tyd gehad het: slegs deur die analise uit te voer, verstaan ​​jy watter vrae jy moet vra.

Участники

Alle buitelandse verslae begin met 'n portret van die deelnemers, en die meeste van hulle is nie van Rusland nie. Die persentasie Russiese respondente wissel van jaar tot jaar tussen 5 en 1%, en dit laat geen gevolgtrekkings toe nie.

Kaart van die Accelerate State of DevOps 2019-verslag:

In ons studie het ons daarin geslaag om onderhoude met 889 mense te voer - dit is nogal baie (DORA stem jaarliks ​​oor 'n duisend mense in sy verslae) en hier het ons die doel bereik:

Dit is waar, nie al ons deelnemers het die einde bereik nie: die persentasie voltooiing was effens minder as die helfte. Maar selfs dit was genoeg om 'n verteenwoordigende steekproef te verkry en 'n ontleding te doen. DORA maak nie vulpersentasies bekend in sy verslae nie, so daar is geen vergelyking hier nie.

Nywerhede en posisies

Ons respondente verteenwoordig 'n dosyn nywerhede. Halfwerk in inligtingstegnologie. Dit word gevolg deur finansiële dienste, handel, telekommunikasie en ander. Onder die poste is spesialiste (ontwikkelaar, toetser, operasionele ingenieur) en bestuurspersoneel (hoofde van spanne, groepe, gebiede, direkteure):

Een uit twee werk vir 'n mediumgrootte maatskappy. Elke derde persoon werk in groot maatskappye. Die meeste werk in spanne van tot 9 mense. Afsonderlik het ons gevra oor die hoofaktiwiteite, en die meerderheid hou op een of ander manier verband met die operasie, en ongeveer 40% is besig met ontwikkeling:

So het ons inligting ingesamel vir vergelyking en ontleding van verteenwoordigers van verskillende nywerhede, maatskappye, spanne. My kollega Vitaly Khabarov sal oor die ontleding vertel.

Ontleding en vergelyking

Vitaly Khabarov: Baie dankie aan al die deelnemers wat ons opname voltooi het, vraelyste ingevul het en ons van data voorsien het vir verdere ontleding en toetsing van ons hipoteses. En danksy ons kliënte en kliënte het ons 'n magdom ervaring wat gehelp het om bedryfskwessies te identifiseer en die hipoteses te formuleer wat ons in ons navorsing getoets het.

Ongelukkig kan jy nie net 'n lys vrae aan die een kant en data aan die ander kant neem, dit op een of ander manier vergelyk, sê: "Ja, alles werk so, ons was reg" en versprei. Nee, metodologie en statistiese metodes is nodig om seker te maak dat ons nie verkeerd is nie en ons gevolgtrekkings betroubaar is. Dan kan ons ons verdere werk bou op grond van hierdie data:

Sleutelmaatstawwe

Ons het die DORA-metodologie as basis geneem, wat hulle in detail beskryf het in die boek “Accelerate State of DevOps”. Ons het gekyk of die sleutelmaatstawwe geskik is vir die Russiese mark, of dit op dieselfde manier gebruik kan word as wat DORA gebruik om die vraag te beantwoord: "Hoe stem die bedryf in Rusland ooreen met die buitelandse industrie?"

Sleutelmaatstawwe:

1. Ontplooiingsfrekwensie. Hoe gereeld word 'n nuwe weergawe van die toepassing na die produksie-omgewing ontplooi (beplande veranderinge, uitgesluit hotfixes en insidentreaksie)?
2. Afleweringstyd. Wat is die gemiddelde tyd tussen die aanbring van 'n verandering (skryf funksionaliteit as kode) en die implementering van die verandering na die produksie-omgewing?
3. Hersteltyd. Hoe lank neem dit gemiddeld om 'n toepassing na 'n produksie-omgewing te herstel na 'n voorval, diensagteruitgang of ontdekking van 'n fout wat toepassinggebruikers raak?
4. Onsuksesvolle veranderinge. Watter persentasie van ontplooiings in die produksie-omgewing lei tot toepassingsdegradasie of insidente en vereis remediëring (terugrol van veranderinge, ontwikkeling van 'n hotfix of pleister)?

DORA het in sy navorsing 'n verband gevind tussen hierdie maatstawwe en organisatoriese prestasie. Ons toets dit ook in ons studie.

Maar om seker te maak dat die vier sleutelmaatstawwe iets kan beïnvloed, moet jy verstaan ​​- is hulle op een of ander manier verwant aan mekaar? DORA het bevestigend geantwoord met een waarskuwing: die verband tussen onsuksesvolle veranderinge (Change Failure Rate) en drie ander maatstawwe is effens swakker. Ons het omtrent dieselfde prentjie gekry. As afleweringstyd, ontplooiingsfrekwensie en hersteltyd met mekaar korreleer (ons het hierdie korrelasie vasgestel deur die Pearson-korrelasie en deur die Chaddock-skaal), dan is daar nie so 'n sterk korrelasie met onsuksesvolle veranderinge nie.

In beginsel is die meeste van die respondente geneig om te antwoord dat hulle 'n taamlik klein aantal voorvalle in produksie het. Alhoewel ons later sal sien dat daar steeds 'n beduidende verskil tussen die groepe respondente is in terme van onsuksesvolle veranderings, kan ons nog nie hierdie maatstaf vir hierdie verdeling gebruik nie.

Ons skryf dit toe aan die feit dat (soos dit geblyk het tydens die ontleding en kommunikasie met sommige van ons kliënte) daar 'n effense verskil is in die persepsie van wat as 'n voorval beskou word. As ons daarin geslaag het om die prestasie van ons diens tydens die tegniese venster te herstel, kan dit as 'n voorval beskou word? Seker nie, want ons het alles reggemaak, ons is wonderlik. Kan ons dit as 'n voorval beskou as ons ons aansoek 10 keer in 'n normale, bekende modus vir ons moes herrol? Dit blyk nie. Daarom bly die vraag oor die verhouding van onsuksesvolle veranderinge met ander maatstawwe oop. Ons sal dit verder verfyn.

Belangrik hier is dat ons 'n beduidende korrelasie tussen afleweringstye, hersteltyd en ontplooiingsfrekwensie gevind het. Daarom het ons hierdie drie maatstawwe geneem om die respondente verder in prestasiegroepe te verdeel.

Hoeveel om te weeg in gram?

Ons het hiërargiese groepontleding gebruik:

• Ons versprei respondente oor 'n n-dimensionele ruimte, waar die koördinaat van elke respondent hul antwoorde op vrae is.
• Elke respondent word as 'n klein groepie verklaar.
• Ons kombineer die twee trosse naaste aan mekaar in een groter groep.
• Ons vind die volgende paar trosse en kombineer hulle in 'n groter groep.

Dit is hoe ons al ons respondente groepeer in die aantal groepe wat ons benodig. Met behulp van 'n dendrogram ('n boom van verbindings tussen trosse) sien ons die afstand tussen twee naburige trosse. Al wat vir ons oorbly, is om 'n sekere afstandsbeperking tussen hierdie trosse te stel en te sê: "Hierdie twee groepe is redelik onderskeibaar van mekaar omdat die afstand tussen hulle reusagtig is."

Maar hier is 'n verborge probleem: ons het geen beperkings op die aantal trosse nie - ons kan 2, 3, 4, 10 trosse kry. En die eerste idee was - hoekom nie al ons respondente in 4 groepe verdeel, soos DORA doen nie. Maar ons het gevind dat die verskille tussen hierdie groepe onbeduidend word, en ons kan nie seker wees dat die respondent werklik aan sy groep behoort, en nie aan die naburige een nie. Ons kan nog nie die Russiese mark in vier groepe verdeel nie. Daarom het ons op drie profiele besluit waartussen daar 'n statisties beduidende verskil is:

Vervolgens het ons die profiel volgens groeperings bepaal: ons het die mediaan vir elke maatstaf vir elke groep geneem en 'n tabel van prestasieprofiele saamgestel. Trouens, ons het die prestasieprofiele van die gemiddelde deelnemer in elke groep gekry. Ons het drie doeltreffendheidprofiele geïdentifiseer: Laag, Medium, Hoog:

Hier het ons ons hipotese bevestig dat 4 sleutelmaatstawwe geskik is vir die bepaling van die prestasieprofiel, en hulle werk beide in die Westerse en Russiese markte. Daar is 'n verskil tussen die groepe en dit is statisties betekenisvol. Ek beklemtoon dat daar 'n beduidende verskil tussen die prestasieprofiele is in terme van die metriek van onsuksesvolle veranderinge in terme van die gemiddelde, al het ons nie aanvanklik die respondente deur hierdie parameter verdeel nie.

Dan ontstaan ​​die vraag: hoe om dit alles te gebruik?

Hoe om te gebruik

As ons enige span, 4 sleutelmaatstawwe neem en dit op die tabel toepas, sal ons in 85% van gevalle nie 'n volledige wedstryd kry nie - dit is net 'n gemiddelde deelnemer, en nie wat in werklikheid is nie. Ons is almal (en elke span) effens anders.

Ons het nagegaan: ons het ons respondente en die DORA-prestasieprofiel geneem, en gekyk hoeveel respondente by hierdie of daardie profiel pas. Ons het gevind dat slegs 16% van die respondente beslis in een van die profiele geval het. Al die res is iewers tussenin gestrooi:

Dit beteken dat die doeltreffendheidsprofiel 'n beperkte omvang het. Om te verstaan ​​waar jy in die eerste benadering is, kan jy hierdie tabel gebruik: "O, dit lyk of ons nader aan Medium of Hoog is!" As jy verstaan ​​waarheen om volgende te gaan, kan dit genoeg wees. Maar as jou doelwit konstante, voortdurende verbetering is, en jy wil meer presies weet waar om te ontwikkel en wat om te doen, dan is bykomende fondse nodig. Ons het hulle sakrekenaars genoem:

• DORA sakrekenaar
• Sakrekenaar Express 42* (in ontwikkeling)
• Eie ontwikkeling (jy kan jou eie interne sakrekenaar skep).

Waarvoor is hulle nodig? Om te verstaan:

• Voldoen die span binne ons organisasie aan ons standaarde?
• Indien nie, kan ons dit help, dit bespoedig binne die raamwerk van die kundigheid waaroor ons maatskappy beskik?
• Indien wel, kan ons nog beter doen?

U kan dit ook gebruik om statistieke binne die maatskappy in te samel:

• Watter spanne het ons?
• Verdeel spanne in profiele;
• Sien: O, hierdie opdragte is onderpresteer (hulle trek nie 'n bietjie uit nie), maar dit is cool: hulle ontplooi elke dag, sonder foute, hulle het 'n aanlooptyd van minder as 'n uur.

En dan kan jy uitvind dat daar binne ons maatskappy die nodige kundigheid en gereedskap is vir daardie spanne wat nog nie op peil is nie.

Of, as jy verstaan ​​dat jy goed voel binne die maatskappy, jy is beter as baie, dan kan jy 'n bietjie wyer kyk. Dit is net die Russiese bedryf: kan ons die nodige kundigheid in die Russiese bedryf kry om onsself te versnel? Die Express 42-sakrekenaar sal hier help (dit is onder ontwikkeling). As jy die Russiese mark ontgroei het, kyk dan na DORA sakrekenaar en na die wêreldmark.

Goed. En as jy in die Elit-groep op die DORA sakrekenaar is, wat moet jy doen? Hier is geen goeie oplossing nie. Jy is heel waarskynlik aan die voorpunt van die bedryf, en verdere versnelling en betroubaarheid is moontlik deur interne R&D en die besteding van meer hulpbronne.

Kom ons gaan oor na die soetste – vergelyking.

vergelyking

Ons wou aanvanklik Russiese industrie met Westerse industrie vergelyk. As ons direk vergelyk, sien ons dat ons minder profiele het, en hulle is 'n bietjie meer gemeng met mekaar, die grense is 'n bietjie meer vaag:

Ons Elite-presteerders is weggesteek onder die Hoë-presteerders, maar hulle is daar - dit is die elite, eenhorings wat aansienlike hoogtes bereik het. In Rusland is die verskil tussen die Elite-profiel en die Hoë-profiel nog nie beduidend genoeg nie. Ons dink dat hierdie skeiding in die toekoms sal plaasvind as gevolg van 'n toename in ingenieurskultuur, die kwaliteit van implementering van ingenieurspraktyke en kundigheid binne maatskappye.

As ons oorgaan na 'n direkte vergelyking binne die Russiese bedryf, kan ons sien dat die hoëprofielspanne in alle opsigte beter is. Ons het ook ons ​​hipotese bevestig dat daar 'n verband tussen hierdie maatstawwe en organisatoriese prestasie is: Hoëprofielspanne is baie meer geneig om nie net doelwitte te bereik nie, maar dit ook te oorskry.
Kom ons word hoëprofielspanne en stop nie daar nie:

Maar hierdie jaar is spesiaal, en ons het besluit om te kyk hoe ondernemings in 'n pandemie vaar: Hoëprofielspanne vaar baie beter en voel beter as die bedryfsgemiddelde:

• 1,5-2 keer meer geneig om nuwe produkte vry te stel,
• 2 keer meer geneig om die betroubaarheid en/of werkverrigting van die toepassingsinfrastruktuur te verbeter.

Dit wil sê, die vaardighede wat hulle reeds gehad het, het hulle gehelp om vinniger te ontwikkel, nuwe produkte bekend te stel, bestaande produkte te verander en sodoende nuwe markte en nuwe gebruikers te verower:

Wat het ons spanne nog gehelp?

Ingenieurspraktyke

Ek sal jou vertel van die beduidende bevindinge vir elke praktyk wat ons getoets het. Miskien het iets anders die spanne gehelp, maar ons praat van DevOps. En binne DevOps sien ons 'n verskil tussen spanne van verskillende profiele.

Platform as 'n diens

Ons het nie 'n beduidende verband tussen platformouderdom en spanprofiel gevind nie: Platforms het omtrent dieselfde tyd vir beide Lae-spanne en Hoëspanne verskyn. Maar vir laasgenoemde bied die platform gemiddeld meer dienste en meer programmeringskoppelvlakke vir beheer deur middel van programkode. En platformspanne is meer geneig om hul ontwikkelaars en spanne te help om die platform te gebruik, hul probleme en platformverwante voorvalle meer gereeld op te los en ander spanne op te voed.

Infrastruktuur as kode

Alles is redelik standaard hier. Ons het 'n verband gevind tussen die outomatisering van die werk van die infrastruktuurkode en hoeveel inligting binne die infrastruktuurbewaarplek gestoor word. Die hoëprofiel-opdragte stoor meer inligting in die bewaarplekke: dit is die infrastruktuurkonfigurasie, CI/CD-pyplyn, omgewingsinstellings en bouparameters. Hulle stoor hierdie inligting meer gereeld, werk beter met infrastruktuurkode en outomatiseer meer prosesse en take om met infrastruktuurkode te werk.

Interessant genoeg het ons nie 'n beduidende verskil in infrastruktuurtoetse gesien nie. Ek skryf dit toe aan die feit dat hoëprofielspanne oor die algemeen meer toetsoutomatisering het. Miskien moet hulle nie afsonderlik afgelei word deur infrastruktuurtoetse nie, maar eerder daardie toetse waarmee hulle toepassings nagaan, en danksy hulle sien hulle reeds wat en waar hulle gebreek het.

Integrasie en aflewering

Die verveligste afdeling, want ons het bevestig dat hoe meer outomatisering jy het, hoe beter jy met die kode werk, hoe groter is die kans dat jy beter resultate sal kry.

Argitektuur

Ons wou sien hoe mikrodienste prestasie beïnvloed. In werklikheid doen hulle nie, aangesien die gebruik van mikrodienste nie geassosieer word met 'n toename in prestasie-aanwysers nie. Mikrodienste word gebruik vir beide hoëprofielopdragte en laeprofielopdragte.

Maar wat belangrik is, is dat die oorgang na 'n mikrodiensargitektuur vir hoë spanne hulle in staat stel om hul dienste onafhanklik te ontwikkel en uit te voer. As die argitektuur ontwikkelaars toelaat om outonoom op te tree, sonder om te wag vir iemand buite die span, dan is dit 'n sleutelbevoegdheid om spoed te verhoog. In hierdie geval help mikrodienste. En net die implementering daarvan speel nie 'n groot rol nie.

Hoe het ons dit alles ontdek?

Ons het 'n ambisieuse plan gehad om die DORA-metodologie volledig te herhaal, maar het nie die hulpbronne gehad nie. As DORA baie borgskap gebruik en hul navorsing duur 'n halfjaar, het ons ons navorsing in 'n kort tydjie gedoen. Ons wou 'n DevOps-model bou soos DORA doen, en ons sal dit in die toekoms doen. Tot dusver het ons ons beperk tot hittekaarte:

Ons het na die verspreiding van ingenieurspraktyke oor spanne in elke profiel gekyk en gevind dat hoëprofielspanne gemiddeld meer geneig was om ingenieurspraktyke te gebruik. Jy kan meer hieroor lees in ons verslag doen.

Kom ons skakel vir 'n verandering van komplekse statistieke na eenvoudiges oor.

Wat het ons nog ontdek?

Tools

Ons neem waar dat die meeste van die opdragte deur die OS van die Linux-familie gebruik word. Maar Windows is steeds in die neiging - ten minste 'n kwart van ons respondente het kennis geneem van die gebruik van een of ander van sy weergawes. Dit blyk dat die mark hierdie behoefte het. Daarom kan jy hierdie bevoegdhede ontwikkel en aanbiedings by konferensies maak.

Onder die orkestreerders is dit vir niemand 'n geheim nie, Kubernetes is aan die voorpunt (52%). Die volgende orkeseerder is Docker Swarm (sowat 12%). Die gewildste CI-stelsels is Jenkins en GitLab. Die gewildste konfigurasiebestuurstelsel is Ansible, gevolg deur ons geliefde Shell.

Amazon is tans die voorste verskaffer van wolkgasheer. Die aandeel Russiese wolke neem geleidelik toe. Volgende jaar sal dit interessant wees om te sien hoe Russiese wolkverskaffers sal voel, of hul markaandeel sal toeneem. Hulle is, hulle kan gebruik word, en dit is goed:

Ek gee die woord aan Igor, wat nog statistieke sal gee.

Verspreiding van praktyke

Igor Kurochkin: Afsonderlik het ons respondente gevra om aan te dui hoe die oorwoë ingenieurspraktyke in die maatskappy versprei word. In die meeste maatskappye is daar 'n gemengde benadering, wat uit 'n ander stel patrone bestaan, en loodsprojekte is baie gewild. Ons het ook 'n effense verskil tussen die profiele gesien. Verteenwoordigers van die Hoë profiel gebruik meer dikwels die "Inisiatief van onder"-patroon, wanneer klein spanne spesialiste werkprosesse, gereedskap verander en suksesvolle praktyke met ander spanne deel. By Medium is dit 'n bo-na-onder-inisiatief wat die hele maatskappy raak deur die skepping van gemeenskappe en sentrums van uitnemendheid:

Agile en DevOps

Die kwessie van die verband tussen Agile en DevOps word dikwels in die bedryf bespreek. Hierdie kwessie word ook geopper in die State of Agile-verslag vir 2019/2020, so ons het besluit om te vergelyk hoe Agile en DevOps-aktiwiteite in maatskappye verbind is. Ons het gevind dat DevOps sonder Agile skaars is. Vir die helfte van die respondente het die verspreiding van Agile baie vroeër begin, en ongeveer 20% het die gelyktydige begin waargeneem, en een van die tekens van 'n Lae profiel sal die afwesigheid van Agile en DevOps-praktyke wees:

Beveltopologieë

Aan die einde van verlede jaar het die boek "Spantopologieë”, wat 'n raamwerk voorstel vir die beskrywing van beveltopologieë. Dit het vir ons interessant geword of dit van toepassing is op Russiese maatskappye. En ons het die vraag gevra: "Watter patrone vind jy?".

Infrastruktuurspanne word by die helfte van die respondente waargeneem, asook aparte spanne vir ontwikkeling, toetsing en bedryf. Afsonderlike DevOps-spanne het 45% opgemerk, waaronder verteenwoordigers van High meer algemeen voorkom. Vervolgens kom kruisfunksionele spanne, wat ook meer algemeen by High voorkom. Afsonderlike SRE-opdragte verskyn in die Hoë, Medium-profiele en word selde in die Lae-profiel gesien:

DevQaOps-verhouding

Ons het hierdie vraag op FaceBook van die spanleier van die Skyeng-platformspan gesien - hy was geïnteresseerd in die verhouding van ontwikkelaars, toetsers en administrateurs in maatskappye. Ons het dit gevra en gekyk na die antwoorde gebaseer op profiele: Hoëprofielverteenwoordigers het minder toets- en bedryfsingenieurs vir elke ontwikkelaar:

Planne vir 2021

In die planne vir die volgende jaar het die respondente die volgende aktiwiteite opgemerk:

Hier kan jy die kruising met die DevOps Live 2020-konferensie sien. Ons het die program noukeurig nagegaan:

• Infrastruktuur as 'n produk
• DevOps transformasie
• Verspreiding van DevOps-praktyke
• DevSecOps
• Gevalklubs en besprekings

Maar die tyd van ons aanbieding is nie genoeg om al die onderwerpe te dek nie. Agter die skerms gelaat:

• Platform as 'n diens en as 'n produk;
• Infrastruktuur as kode, omgewings en wolke;
• Deurlopende integrasie en aflewering;
• Argitektuur;
• DevSecOps-patrone;
• Platform en kruisfunksionele spanne.

verslag ons het 'n lywige, 50 bladsye, en jy kan dit in meer besonderhede sien.

Opsomming

Ons hoop dat ons navorsing en verslag jou sal inspireer om met nuwe benaderings tot ontwikkeling, toetsing en bedrywighede te eksperimenteer, asook jou sal help om te navigeer, jouself met ander deelnemers aan die studie te vergelyk en areas te identifiseer waar jy jou eie benaderings kan verbeter.

Resultate van die eerste studie van die toestand van DevOps in Rusland:

• Sleutel statistieke. Ons het gevind dat sleutelmaatstawwe (afleweringstyd, ontplooiingsfrekwensie, hersteltyd en veranderingsfoute) geskik is vir die ontleding van die doeltreffendheid van ontwikkelings-, toetsings- en bedryfsprosesse.
• Profiele hoog, medium, laag. Gebaseer op die versamelde data, is dit moontlik om statisties verskillende groepe van Hoog, Medium, Laag te onderskei met eiesoortige kenmerke in terme van metrieke, praktyke, prosesse en gereedskap. Verteenwoordigers van die Hoë profiel toon beter resultate as Laag. Hulle is meer geneig om hul doelwitte te bereik en te oorskry.
• Aanwysers, pandemie en planne vir 2021. 'n Spesiale aanwyser vanjaar is hoe maatskappye die pandemie hanteer het. Die Hoë-verteenwoordigers het beter gevaar, verhoogde gebruikersbetrokkenheid ervaar, en die hoofredes vir sukses was doeltreffende ontwikkelingsprosesse en 'n sterk ingenieurskultuur.
• DevOps-praktyke, gereedskap en hul ontwikkeling. Die hoofplanne van maatskappye vir die volgende jaar sluit in die ontwikkeling van DevOps-praktyke en -instrumente, die bekendstelling van DevSecOps-praktyke en veranderinge in die organisasiestruktuur. En die effektiewe implementering en ontwikkeling van DevOps-praktyke word uitgevoer met behulp van loodsprojekte, die vorming van gemeenskappe en sentrums van uitnemendheid, inisiatiewe op die boonste en onderste vlakke van die maatskappy.

Ons sal graag jou terugvoer, stories, terugvoer wil hoor. Ons bedank almal wat aan die studie deelgeneem het en sien uit na u deelname volgende jaar.

Bron: will.com