Status for DevOps i Russland 2020

Hvordan forstår du i det hele tatt tilstanden til noe?

Du kan stole på din mening, dannet fra ulike informasjonskilder, for eksempel publikasjoner på nettsteder eller erfaring. Du kan spørre dine kolleger og venner. Et annet alternativ er å se på temaene for konferansene: Programkomiteen er aktive representanter for bransjen, så vi stoler på at de velger relevante temaer. Et eget område er forskning og rapporter. Men det er et problem. Forskning på tilstanden til DevOps utføres årlig rundt om i verden, rapporter publiseres av utenlandske selskaper, og det er nesten ingen informasjon om russiske DevOps.

Men dagen har kommet da en slik studie ble utført, og i dag vil vi fortelle deg om resultatene som er oppnådd. Tilstanden til DevOps i Russland ble studert i fellesskap av selskapene "Express 42"Og"Ontiko" Express 42-selskapet hjelper teknologiselskaper med å implementere og utvikle DevOps-praksis og -verktøy og var en av de første som snakket om DevOps i Russland. Forfatterne av studien, Igor Kurochkin og Vitaly Khabarov, er engasjert i analyse og rådgivning ved Express 42, med teknisk bakgrunn fra drift og erfaring i forskjellige selskaper. I løpet av 8 år har kolleger sett på dusinvis av selskaper og prosjekter - fra startups til bedrifter - med ulike problemer, samt ulik kulturell og ingeniørmessig modenhet.

I sin rapport forklarte Igor og Vitaly hvilke problemer det var under forskningsprosessen, hvordan de løste dem, samt hvordan DevOps-forskning utføres i prinsippet og hvorfor Express 42 bestemte seg for å gjennomføre sine egne. Du kan se rapporten deres her.

DevOps Research

Igor Kurochkin startet samtalen.

Vi spør jevnlig publikum på DevOps-konferanser: "Har du lest årets State of DevOps-rapport?" Bare noen få rekker opp hendene, men vår forskning viste at bare en tredjedel studerer dem. Hvis du aldri har sett slike rapporter, la oss si med en gang at de alle er veldig like. Oftest er det setninger som: "Sammenlignet med i fjor ..."

Her har vi vårt første problem, etterfulgt av to til:

1. Vi har ikke data for fjoråret. Ingen er interessert i tilstanden til DevOps i Russland;
2. Metodikk. Det er ikke klart hvordan man tester hypoteser, hvordan man konstruerer spørsmål, hvordan man gjennomfører analyser, sammenligner resultater, finner sammenhenger;
3. Terminologi. Alle rapporter er på engelsk, oversettelse er nødvendig, et felles rammeverk for DevOps er ennå ikke oppfunnet og alle kommer opp med sitt eget.

La oss se på hvordan analyser av tilstanden til DevOps i verden generelt ble utført.

Historisk informasjon

DevOps-undersøkelser har blitt utført siden 2011. Den første som gjennomførte dem var Puppet, en utvikler av konfigurasjonsstyringssystemer. På den tiden var det et av hovedverktøyene for å beskrive infrastruktur i form av kode. Frem til 2013 var disse studiene ganske enkelt undersøkelser i et lukket format og uten offentlig rapportering.

I 2013 dukket IT Revolution opp, utgiver av alle de store bøkene om DevOps. Sammen med Puppet utarbeidet de den første publikasjonen "State of DevOps", der 4 nøkkeltall dukket opp for første gang. Året etter ble konsulentselskapet ThoughtWorks, kjent for sine vanlige teknologiradarer om bransjepraksis og verktøy, involvert. Og i 2015 ble det lagt til en seksjon med metodikk, og det ble tydelig hvordan de utfører analysen.

I 2016 publiserte forfatterne av studien, etter å ha opprettet selskapet DORA (DevOps Research and Assessment), en årsrapport. Året etter ga DORA og Puppet sin endelige fellesrapport.

Og så ble ting interessant:

I 2018 delte selskapene seg og to uavhengige rapporter ble utgitt: en fra Puppet, den andre fra DORA i samarbeid med Google. DORA fortsatte å bruke sin metodikk med nøkkelberegninger, ytelsesprofiler og ingeniørpraksis som påvirker nøkkelberegninger og ytelse i hele selskapet. Og Puppet foreslo sin tilnærming med en beskrivelse av prosessen og utviklingen av DevOps. Men historien slo ikke til; i 2019 forlot Puppet denne metodikken og ga ut en ny versjon av rapportene, der den listet opp nøkkelpraksis og hvordan de påvirker DevOps fra deres synspunkt. Så skjedde en annen ting: Google kjøpte DORA, og sammen ga de ut en ny rapport. Kanskje du har sett den.

I år ble ting komplisert. Det er kjent at Puppet lanserte sin undersøkelse. De gjorde det en uke tidligere enn oss, og det var allerede fullført. Vi var med og så hvilke temaer som interesserte dem. Puppet utfører nå sin analyse og forbereder publisering av rapporten.

Men det er fortsatt ingen kunngjøring fra DORA og Google. I mai, da undersøkelsen vanligvis startet, kom det informasjon om at Nicole Forsgren, en av grunnleggerne av DORA, hadde flyttet til et annet selskap. Derfor antok vi at det ikke ville komme forskning eller rapport fra DORA i år.

Hvordan er det i Russland?

Vi har ikke utført noen undersøkelser på DevOps. Vi snakket på konferanser, gjenfortalte andres konklusjoner, og Raiffeisenbank oversatte "State of DevOps" for 2019 (du kan finne deres kunngjøring på Habré), mange takk til dem. Og det er alt.

Derfor utførte vi vår egen forskning i Russland ved å bruke DORA-metodologier og funn. Vi brukte rapporten fra kolleger fra Raiffeisenbank til vår forskning, inkludert for å synkronisere terminologi og oversettelse. Og spørsmålene som er relevante for bransjen er hentet fra DORA-rapporter og årets Puppet-spørreskjema.

Forskningsprosess

Rapporten er kun den siste delen. Hele forskningsprosessen består av fire store stadier:

Under forberedelsesstadiet intervjuet vi bransjeeksperter og utarbeidet en liste med hypoteser. Basert på dem har vi satt sammen spørsmål og lansert en spørreundersøkelse for hele august måned. Deretter analyserte og utarbeidet vi selve rapporten. For DORA tar denne prosessen 6 måneder. Vi fullførte det på 3 måneder, og nå forstår vi at vi knapt hadde nok tid: bare ved å gjøre analysen forstår du hvilke spørsmål som må stilles.

Deltakere

Alle utenlandsreportasjer begynner med et portrett av deltakerne, og de fleste av dem er ikke fra Russland. Andelen russiske respondenter svinger fra 5 til 1 % fra år til år, og dette tillater oss ikke å trekke noen konklusjoner.

Kart fra Accelerate State of DevOps 2019-rapporten:

I vår studie kunne vi intervjue 889 personer - dette er ganske mye (DORA spør om tusen mennesker årlig i sine rapporter) og her nådde vi målet vårt:

Det var sant at ikke alle deltakerne våre nådde slutten: fullføringsprosenten var litt under halvparten. Men dette var nok til å få et representativt utvalg og gjennomføre analyse. DORA oppgir ikke utleiegrad i sine rapporter, så sammenligninger kan ikke gjøres her.

Bransjer og stillinger

Våre respondenter representerer et titalls bransjer. Halvparten jobber innen informasjonsteknologi. Deretter følger finanstjenester, handel, telekommunikasjon og andre. Blant stillingene er spesialister (utvikler, tester, driftsingeniør) og ledere (ledere av team, grupper, områder, direktører):

Annenhver person jobber i en mellomstor bedrift. Hver tredje person jobber i store bedrifter. De fleste jobber i team på opptil 9 personer. Hver for seg spurte vi om hovedaktivitetene, og flertallet er på en eller annen måte knyttet til drift, og ca 40 % er involvert i utvikling:

Dette er hvordan vi samlet inn informasjon for sammenligning og analyse av representanter for ulike bransjer, selskaper og team. Min kollega Vitaly Khabarov vil fortelle deg om analysen.

Analyse og sammenligning

Vitaly Khabarov: Tusen takk til alle deltakerne som fullførte undersøkelsen vår, fylte ut spørreskjemaer og ga oss data for videre analyse og testing av hypotesene våre. Og takket være våre kunder og kunder, har vi et vell av erfaring som har hjulpet oss med å identifisere problemstillinger av interesse for industrien og formulere hypotesene som vi testet i vår forskning.

Dessverre kan du ikke bare ta en liste over spørsmål på den ene siden og data på den andre, sammenligne dem på en eller annen måte, si: "Ja, alt fungerer slik, vi hadde rett" og gå hver til sitt. Nei, vi trenger metodikk og statistiske metoder for å være sikre på at vi ikke tok feil og at konklusjonene våre er pålitelige. Deretter kan vi bygge vårt videre arbeid på grunnlag av disse dataene:

Nøkkelberegninger

Vi tok utgangspunkt i DORA-metodikken, som de beskrev i detalj i boken «Accelerate State of DevOps». Vi sjekket om nøkkelberegningene passer for det russiske markedet, om de kan brukes på samme måte som DORA bruker for å svare på spørsmålet: «Hvordan samsvarer industrien i Russland med utenlandsk industri?»

Nøkkelberegninger:

1. Distribusjonsfrekvens. Hvor ofte blir en ny versjon av en applikasjon distribuert til produksjonsmiljøet (planlagte endringer, unntatt hurtigreparasjoner og hendelsesrespons)?
2. Leveringstid. Hva er gjennomsnittlig tid mellom å foreta en endring (skrive funksjonalitet som kode) og implementere endringen i produksjonsmiljøet?
3. Restitusjonstid. Hvor lang tid tar det i gjennomsnitt å gjenopprette en applikasjon i et produksjonsmiljø etter en hendelse, tjenesteforringelse eller oppdagelse av en feil som påvirker applikasjonsbrukere?
4. Mislykkede endringer. Hvor stor prosentandel av distribusjonene i et produktmiljø fører til programforringelse eller hendelser og krever eliminering av konsekvenser (rulling tilbake endringer, utvikling av en hurtigreparasjon eller oppdatering)?

DORAs forskning har funnet en sammenheng mellom disse beregningene og organisasjonens ytelse. Vi sjekker det også i vår studie.

Men for å være sikker på at de fire nøkkelberegningene kan påvirke noe, må du forstå – er de på en eller annen måte relatert til hverandre? DORA svarte ja, med ett forbehold: forholdet mellom Change Failure Rate og de tre andre beregningene er litt svakere. Vi fikk omtrent det samme bildet. Hvis leveringstid, distribusjonsfrekvens og gjenopprettingstid er korrelert med hverandre (vi etablerte denne korrelasjonen gjennom Pearson-korrelasjonen og gjennom Chaddock-skalaen), så er det ingen så sterk korrelasjon med mislykkede endringer.

I prinsippet har de fleste respondentene en tendens til å svare at de har et ganske lite antall hendelser som skjer i produksjonen. Selv om vi senere skal se at det fortsatt er en betydelig forskjell mellom gruppene av respondenter i frekvensen av mislykkede endringer, kan vi ennå ikke bruke denne beregningen for denne inndelingen.

Vi tilskriver dette at det (som det viste seg i prosessen med analyse og kommunikasjon med noen av våre kunder) er en liten forskjell i oppfatningen av hva som anses som en hendelse. Hvis vi klarte å gjenopprette funksjonaliteten til tjenesten vår i løpet av det tekniske vinduet, kan dette betraktes som en hendelse? Sannsynligvis ikke, fordi vi fikset alt, vi er gode. Kan det betraktes som en hendelse hvis vi måtte rulle applikasjonen på nytt 10 ganger i vanlig, kjent modus? Det virker ikke. Derfor forblir spørsmålet om forholdet mellom mislykkede endringer og andre beregninger åpent. Vi vil avklare det nærmere.

Det som er viktig her er at vi fant en signifikant sammenheng mellom leveringstid, gjenopprettingstid og distribusjonsfrekvens. Derfor tok vi disse tre beregningene for å dele respondentene ytterligere inn i grupper basert på produktivitet.

Hvor mye å henge i gram?

Vi brukte hierarkisk klyngeanalyse:

• Vi fordeler respondentene på tvers av n-dimensjonalt rom, hvor koordinaten til hver respondent er deres svar på spørsmålene.
• Vi erklærer at hver respondent er en liten klynge.
• Vi kombinerer de to klyngene nærmest hverandre til en større klynge.
• Vi finner neste par med klynger og kombinerer dem til en større klynge.

Slik grupperer vi alle respondentene våre i antall klynger vi trenger. Ved å bruke et dendrogram (et tre av forbindelser mellom klynger) ser vi avstanden mellom to naboklynger. Alt som gjenstår for oss er å sette en viss grense for avstanden mellom disse klyngene og si: "Disse to gruppene kan skilles ganske mye fra hverandre fordi avstanden mellom dem er gigantisk."

Men det er et skjult problem her: vi har ingen begrensninger på antall klynger - vi kan få 2, 3, 4, 10 klynger. Og den første ideen var – hvorfor ikke dele alle våre respondenter i 4 grupper, slik DORA gjør. Men vi fant at forskjellene mellom disse gruppene blir ubetydelige, og vi kan ikke være sikre på at respondenten virkelig tilhører sin gruppe og ikke til naboen. Vi kan ennå ikke dele det russiske markedet inn i fire grupper. Derfor bestemte vi oss for tre profiler, som det er en statistisk signifikant forskjell mellom:

Deretter bestemte vi profilen etter klynge: vi tok medianene for hver beregning for hver gruppe og kompilerte en tabell over effektivitetsprofiler. Faktisk ble de resulterende ytelsesprofilene for den gjennomsnittlige deltakeren i hver gruppe oppnådd. Vi har identifisert tre effektivitetsprofiler: Lav, Middels, Høy:

Her har vi bekreftet vår hypotese om at 4 nøkkeltall er egnet for å bestemme ytelsesprofilen, og de fungerer både i det vestlige og det russiske markedet. Det er forskjell mellom gruppene, og det er statistisk signifikant. Jeg vil understreke at det er en betydelig forskjell i gjennomsnittet mellom resultatprofilene for metrikken for mislykkede endringer, selv om vi i utgangspunktet ikke delte respondentene med denne parameteren.

Da oppstår spørsmålet: hvordan bruke alt dette?

Hvordan bruke

Hvis vi tar et hvilket som helst lag, 4 nøkkeltall og bruker det på tabellen, vil vi i 85% av tilfellene ikke få en fullstendig match - dette er bare den gjennomsnittlige deltakeren, og ikke det som er i virkeligheten. Vi er alle (og hvert lag) litt forskjellige.

Vi sjekket: vi tok våre respondenter og DORA prestasjonsprofil, og så på hvor mange respondenter som tilsvarte en eller annen profil. Vi fant at bare 16 % av respondentene falt nøyaktig inn i en av profilene. Resten er spredt et sted i mellom:

Dette betyr at ytelsesprofilen har et begrenset omfang. For å få en første tilnærming til hvor du er, kan du bruke denne tabellen: "Å, det ser ut som om vi er nærmere Medium eller High!" Hvis du forstår hvor du skal videre, kan det være nok. Men hvis målet ditt er konstant, kontinuerlig forbedring, og du vil vite mer nøyaktig hvor du skal utvikle deg og hva du skal gjøre, er det behov for ytterligere midler. Vi kalte dem kalkulatorer:

• DORA kalkulator
• Kalkulator Express 42* (under utvikling)
• Din egen utvikling (du kan lage din egen interne kalkulator).

Hva trengs de til? Å forstå:

• Oppfyller teamet i organisasjonen våre standarder?
• Hvis ikke, kan vi hjelpe henne – fremskynde det innenfor rammen av kompetansen som selskapet vårt har?
• Kan vi i så fall gjøre det enda bedre?

Du kan også bruke dem til å samle inn statistikk i selskapet:

• Hva slags lag har vi?
• Del team inn i profiler;
• Se: Å, disse lagene underpresterer (litt trege), men disse er flotte: de distribuerer hver dag, uten feil, ledetiden deres er mindre enn en time.

Og så kan du finne ut at i vårt selskap har vi den nødvendige kompetansen og verktøyene for de teamene som fortsatt kommer til kort.

Eller, hvis du forstår at du har det bra i bedriften, at du er bedre enn mange, så kan du se litt bredere. Dette er nettopp den russiske industrien: kan vi få den nødvendige kompetansen i den russiske industrien til å sette fart? Express 42-kalkulatoren vil hjelpe her (den er under utvikling). Hvis du har vokst ut av det russiske markedet, så se på DORA kalkulator og til verdensmarkedet.

Fint. Og hvis du er i Elit-gruppen ifølge DORA-kalkulatoren, hva skal du da gjøre? Det er ingen god løsning her. Mest sannsynlig er du i forkant av bransjen, og ytterligere forbedringer av akselerasjon og pålitelighet er mulig gjennom intern FoU og bruk av store ressurser.

La oss gå videre til den søteste delen - sammenligning.

sammenligning

Vi ønsket i utgangspunktet å sammenligne russisk industri med vestlig industri. Sammenligner vi direkte, ser vi at vi har færre profiler, og de er litt mer blandet med hverandre, grensene er litt mer utydelige:

Våre Elite-utøvere er gjemt blant High-performers, men de er der - dette er eliten, enhjørninger som har nådd betydelige høyder. I Russland er forskjellen mellom Elite- og High-profilen ennå ikke betydelig nok. Vi tror at denne divisjonen i fremtiden vil skje på grunn av en økning i ingeniørkultur, kvaliteten på implementering av ingeniørpraksis og kompetanse i bedrifter.

Hvis vi går over til direkte sammenligning innen russisk industri, ser vi at høyprofilerte team er bedre på alle måter. Vi bekreftet også hypotesen vår om at det er en sammenheng mellom disse beregningene og organisatorisk effektivitet: Høyprofilerte team har betydelig større sannsynlighet for ikke bare å oppnå mål, men også overgå dem.
La oss bli høyprofilerte lag og ikke stoppe der:

Men dette året er spesielt, og vi bestemte oss for å sjekke hvordan selskaper lever i en pandemi: Høyprofilerte team takler det betydelig bedre og føler seg bedre enn bransjegjennomsnittet:

• Nye produkter ble utgitt 1,5-2 ganger oftere,
• Økt pålitelighet og/eller ytelse av applikasjonsinfrastruktur 2 ganger oftere.

Det vil si at kompetansen de allerede hadde hjalp dem med å utvikle raskere, introdusere nye produkter, modifisere eksisterende produkter, og dermed erobre nye markeder og nye brukere:

Hva annet har hjulpet teamene våre?

Ingeniørpraksis

Jeg skal fortelle deg om viktige funn for hver praksis vi sjekket. Kanskje noe annet hjalp teamene, men vi snakker om DevOps. Og innenfor DevOps ser vi forskjeller mellom team med forskjellige profiler.

Plattform som en tjeneste

Vi fant ingen signifikant sammenheng mellom plattformens alder og lagprofilen: Plattformer dukket opp omtrent samtidig for både lavt og høyt lag. Men for sistnevnte gir plattformen i gjennomsnitt flere tjenester og flere programvaregrensesnitt for kontroll gjennom programkode. Og plattformteam er mer sannsynlig å hjelpe utviklerne og teamene sine med å bruke plattformen, mer sannsynlig å løse problemene og hendelsene relatert til plattformen, og trene andre team.

Infrastruktur som kode

Alt her er ganske standard. Vi fant en sammenheng mellom automatisering av infrastrukturkode og hvor mye informasjon som er lagret i infrastrukturlageret. Høyprofilerte team lagrer mer informasjon i repositories: dette inkluderer infrastrukturkonfigurasjon, CI/CD-pipeline, miljøinnstillinger og byggeparametere. De lagrer denne informasjonen oftere, jobber bedre med infrastrukturkode og har automatisert flere prosesser og oppgaver for å jobbe med infrastrukturkode.

Interessant nok så vi ingen signifikant forskjell i infrastrukturtester. Jeg tilskriver dette det faktum at høyprofilerte team generelt har mer testautomatisering. De bør kanskje ikke distraheres separat av infrastrukturtester, men heller testene de bruker for å sjekke applikasjoner er nok, og takket være dem kan de se hva og hvor de har gått i stykker.

Integrasjon og levering

Den kjedeligste delen, fordi vi bekreftet: jo mer automatisering du har, jo bedre du jobber med koden, jo større sannsynlighet er det for at du får bedre resultater.

arkitektur

Vi ønsket å se hvordan mikrotjenester påvirker ytelsen. For å være ærlig, gjør de det ikke, siden bruken av mikrotjenester ikke er forbundet med en økning i effektivitetsindikatorer. Mikrotjenester brukes av både høy- og lavprofilteam.

Men det som er viktig er at for High-teams lar overgangen til en mikrotjenestearkitektur dem uavhengig utvikle sine tjenester og rulle dem ut. Hvis arkitekturen lar utviklere handle autonomt, uten å vente på noen utenfor teamet, så er dette en nøkkelkompetanse for å øke hastigheten. Det er her mikrotjenester hjelper. Men rett og slett deres implementering spiller ingen stor rolle.

Hvordan oppdaget vi alt dette?

Vi hadde en ambisiøs plan for å gjenskape DORA-metodikken fullt ut, men manglet ressursene. Hvis DORA bruker mye sponsing og studien tar dem seks måneder, gjennomførte vi studien vår på kort tid. Vi ønsket å bygge en DevOps-modell slik DORA gjør, og det vil vi gjøre i fremtiden. Foreløpig begrenset vi oss til varmekart:

Vi så på fordelingen av ingeniørpraksis mellom teamene i hver profil, og fant ut at team med høyprofilen i gjennomsnitt bruker ingeniørpraksis oftere. Du kan lese mer om alt dette i vår rapporten.

For en forandring, la oss bytte fra kompleks statistikk til enkel.

Hva annet har vi oppdaget?

Verktøy

Vi observerer at Linux OS-familien bruker flest kommandoer. Men Windows er fortsatt i trenden - minst en fjerdedel av respondentene våre bemerket bruken av en eller annen versjon av den. Markedet ser ut til å ha dette behovet. Derfor kan du utvikle disse kompetansene og holde presentasjoner på konferanser.

Blant orkestratorer er det ingen hemmelighet at Kubernetes leder (52%). Neste orkestrator i rekken er Docker Swarm (ca. 12%). De mest populære CI-systemene er Jenkins og GitLab. Det mest populære konfigurasjonsstyringssystemet er Ansible, etterfulgt av vårt elskede Shell.

Blant cloud hosting-leverandører inntar Amazon for tiden den ledende posisjonen. Andelen russiske skyer øker gradvis. Neste år blir det interessant å se hvordan russiske skyleverandører vil føle seg og om deres markedsandel vil øke. De finnes, de kan brukes, og det er bra:

Jeg gir ordet til Igor, som vil gi litt mer statistikk.

Spredning av praksis

Igor Kurochkin: Hver for seg ba vi respondentene om å angi hvordan de vurderte ingeniørpraksisene er fordelt i selskapet. De fleste bedrifter har en blandet tilnærming som består av et annet sett med mønstre, og pilotprosjekter er svært populære. Vi så også en liten forskjell mellom profilene. Representanter for den høye profilen bruker oftere "Initiativ nedenfra"-mønsteret, når små team av spesialister endrer arbeidsprosesser, verktøy og deler vellykkede utviklinger med andre team. Hos Medium er dette et ovenfra-og-ned-initiativ som berører hele selskapet gjennom opprettelsen av fellesskap og kompetansesentre:

Agile og DevOps

Forholdet mellom Agile og DevOps diskuteres ofte i bransjen. Dette spørsmålet er også reist i State of Agile-rapporten for 2019/2020, så vi bestemte oss for å sammenligne hvordan Agile- og DevOps-aktiviteter i selskaper er relatert. Vi har funnet ut at DevOps uten Agile er sjelden. For halvparten av respondentene begynte spredningen av Agile merkbart tidligere, og omtrent 20 % observerte en samtidig start, og et av tegnene på en lav profil vil være fraværet av Agile og DevOps-praksis:

Teamtopologier

På slutten av fjoråret boken "Teamtopologier", som foreslår et rammeverk for å beskrive teamtopologier. Vi lurte på om det ville gjelde russiske selskaper. Og vi stilte spørsmålet: "Hvilke mønstre ser du?"

Infrastrukturteam er observert hos halvparten av respondentene, samt separate utviklings-, test- og driftsteam. Individuelle DevOps-team noterte 45 %, blant disse er høye representanter mer vanlige. Deretter kommer tverrfunksjonelle team, som også er mer vanlig på High. Separate SRE-kommandoer vises i High, Medium-profilene og finnes sjelden i Low-profilen:

DevQaOps-forhold

Vi så dette spørsmålet på Facebook fra teamlederen for Skyeng-plattformteamet - han var interessert i forholdet mellom utviklere, testere og administratorer i selskaper. Vi spurte det og så på svarene under hensyntagen til profilene: representanter for høyprofilen har et mindre antall test- og driftsingeniører for hver utvikler:

Planer for 2021

I planene for det neste året bemerket respondentene følgende aktiviteter:

Her kan du se skjæringspunktet med DevOps Live 2020-konferansen. Vi gjennomgikk programmet nøye:

• Infrastruktur som produkt
• DevOps-transformasjon
• Distribusjon av DevOps-praksis
• DevSecOps
• Saksklubber og diskusjoner

Men foredraget vårt vil ikke ha nok tid til å dekke alle temaene. Bak scenen:

• Plattform som en tjeneste og som et produkt;
• Infrastruktur som kode, miljøer og skyer;
• Kontinuerlig integrasjon og levering;
• Arkitektur;
• DevSecOps-mønstre;
• Plattform og tverrfunksjonelle team.

Rapport Vår er omfangsrik, 50 sider lang, og du kan se nærmere på den.

Oppsummering

Vi håper at forskningen og rapporten vår vil inspirere deg til å eksperimentere med nye tilnærminger til utvikling, testing og drift, samt hjelpe deg å få peiling, sammenligne deg selv med andre i studien og identifisere områder hvor du kan forbedre dine egne tilnærminger .

Resultater av den første studien av staten DevOps i Russland:

• Nøkkelberegninger. Vi har funnet ut at nøkkeltall (leveringstid, distribusjonshastighet, gjenopprettingstid og endringsfeil) er egnet for å analysere effektiviteten til utviklings-, test- og driftsprosesser.
• Profiler Høy, Middels, Lav. Basert på de innsamlede dataene er det mulig å identifisere statistisk ulike grupper: Høy, Middels, Lav, med særpreg basert på metrikk, praksis, prosesser og verktøy. Representanter for Høyprofilen viser bedre resultater enn Lav. Det er mer sannsynlig at de oppnår og overgår målene sine.
• Indikatorer, pandemi og planer for 2021. En spesiell indikator i år er hvordan selskaper taklet pandemien. High presterte bedre, opplevde en økning i brukeraktivitet, og hovedårsakene til suksess var effektive utviklingsprosesser og en sterk ingeniørkultur.
• DevOps-praksis, verktøy og deres utvikling. Selskapenes hovedplaner for det neste året inkluderer utvikling av DevOps-praksis og -verktøy, innføring av DevSecOps-praksis og endringer i organisasjonsstrukturen. Og effektiv implementering og utvikling av DevOps-praksis utføres gjennom pilotprosjekter, dannelse av fellesskap og kompetansesentre, initiativer på øvre og nedre nivå i selskapet.

Vi vil gjerne høre dine anmeldelser, historier, tilbakemeldinger. Vi takker alle som deltok i studien og ser frem til deres deltakelse neste år.

Kilde: www.habr.com