Status for DevOps i Rusland 2020

Hvordan forstår man tilstanden af ​​noget?

Du kan stole på din mening, dannet ud fra forskellige informationskilder, for eksempel publikationer på websteder eller erfaringer. Du kan spørge dine kolleger og venner. En anden mulighed er at se på konferencernes emner: Programudvalget er aktive repræsentanter for industrien, så vi stoler på, at de vælger relevante emner. Et særskilt område er forskning og rapporter. Men der er et problem. Forskning om tilstanden for DevOps udføres årligt rundt om i verden, rapporter udgives af udenlandske virksomheder, og der er næsten ingen information om russiske DevOps.

Men dagen er kommet, hvor en sådan undersøgelse blev udført, og i dag vil vi fortælle dig om de opnåede resultater. DevOps tilstand i Rusland blev undersøgt i fællesskab af virksomhederne "Express 42"Og"Ontiko" Express 42-virksomheden hjælper teknologivirksomheder med at implementere og udvikle DevOps-praksis og -værktøjer og var en af ​​de første til at tale om DevOps i Rusland. Forfatterne af undersøgelsen, Igor Kurochkin og Vitaly Khabarov, er engageret i analyse og rådgivning hos Express 42, med en teknisk baggrund fra drift og erfaring i forskellige virksomheder. I løbet af 8 år har kolleger kigget på snesevis af virksomheder og projekter - fra startups til virksomheder - med forskellige problemer, samt forskellig kulturel og ingeniørmæssig modenhed.

I deres rapport forklarede Igor og Vitaly, hvilke problemer der var under forskningsprocessen, hvordan de løste dem, samt hvordan DevOps-forskning udføres i princippet, og hvorfor Express 42 besluttede at udføre deres eget. Du kan se deres rapport her.

DevOps Research

Igor Kurochkin startede samtalen.

Vi spørger jævnligt publikum på DevOps-konferencer: "Har du læst dette års State of DevOps-rapport?" Kun få rækker hånden op, men vores forskning viste, at kun en tredjedel studerer dem. Hvis du aldrig har set sådanne rapporter, lad os sige med det samme, at de alle er meget ens. Oftest er der sætninger som: "Sammenlignet med sidste år..."

Her har vi vores første problem, efterfulgt af to mere:

1. Vi har ikke data for sidste år. Ingen er interesseret i tilstanden af ​​DevOps i Rusland;
2. Metode. Det er ikke klart, hvordan man tester hypoteser, hvordan man konstruerer spørgsmål, hvordan man udfører analyser, sammenligner resultater, finder sammenhænge;
3. Terminologi. Alle rapporter er på engelsk, oversættelse er påkrævet, en fælles DevOps-ramme er endnu ikke opfundet, og alle kommer med deres eget.

Lad os se på, hvordan analyser af tilstanden for DevOps i verden generelt blev udført.

Historie

DevOps-undersøgelser er blevet udført siden 2011. Den første til at udføre dem var Puppet, en udvikler af konfigurationsstyringssystemer. På det tidspunkt var det et af de vigtigste værktøjer til at beskrive infrastruktur i form af kode. Indtil 2013 var disse undersøgelser blot undersøgelser i et lukket format og uden offentlig rapportering.

I 2013 dukkede IT Revolution op, udgiver af alle de store bøger om DevOps. Sammen med Puppet udarbejdede de den første State of DevOps-publikation, hvor 4 nøglemetrics dukkede op for første gang. Året efter blev ThoughtWorks, et konsulentfirma kendt for sine regelmæssige teknologiradarer om industripraksis og værktøjer, involveret. Og i 2015 blev der tilføjet et afsnit med metodik, og det blev tydeligt, hvordan de udfører analysen.

I 2016 udgav forfatterne til undersøgelsen, efter at have oprettet deres virksomhed DORA (DevOps Research and Assessment), en årsrapport. Året efter udgav DORA og Puppet deres endelige fælles rapport.

Og så blev tingene interessante:

I 2018 blev virksomhederne delt, og to uafhængige rapporter blev udgivet: en fra Puppet, den anden fra DORA i samarbejde med Google. DORA fortsatte med at bruge sin metodik med nøglemålinger, præstationsprofiler og ingeniørpraksis, der påvirker nøglemålinger og præstationer på tværs af virksomheden. Og Puppet foreslog sin tilgang med en beskrivelse af processen og udviklingen af ​​DevOps. Men historien fangede ikke; i 2019 opgav Puppet denne metode og udgav en ny version af rapporterne, hvori den oplistede nøglepraksis, og hvordan de påvirker DevOps fra deres synspunkt. Så skete der en anden ting: Google købte DORA, og sammen udgav de endnu en rapport. Måske har du set det.

I år blev tingene komplicerede. Det er kendt, at Puppet lancerede sin undersøgelse. De gjorde det en uge tidligere end os, og det var allerede afsluttet. Vi deltog i det og så, hvilke emner der interesserede dem. Puppet udfører nu sin analyse og forbereder sig på at offentliggøre rapporten.

Men der er stadig ingen udmelding fra DORA og Google. I maj, hvor undersøgelsen normalt begyndte, kom der oplysninger om, at Nicole Forsgren, en af ​​stifterne af DORA, var flyttet til en anden virksomhed. Derfor antog vi, at der ikke ville være nogen forskning eller rapport fra DORA i år.

Hvordan går det i Rusland?

Vi har ikke lavet DevOps-undersøgelser. Vi talte ved konferencer, genfortællede andres konklusioner, og Raiffeisenbank oversatte "State of DevOps" for 2019 (du kan finde deres meddelelse på Habré), mange tak til dem. Og det er det hele.

Derfor udførte vi vores egen forskning i Rusland ved hjælp af DORA-metoder og -resultater. Vi brugte rapporten fra kolleger fra Raiffeisenbank til vores forskning, herunder til at synkronisere terminologi og oversættelse. Og de spørgsmål, der er relevante for branchen, er hentet fra DORA-rapporter og dette års Puppet-spørgeskema.

Forskningsproces

Rapporten er kun den sidste del. Hele forskningsprocessen består af fire store faser:

Under forberedelsesfasen interviewede vi brancheeksperter og udarbejdede en liste over hypoteser. På baggrund af dem har vi samlet spørgsmål og iværksat en undersøgelse for hele august måned. Derefter analyserede og udarbejdede vi selve rapporten. For DORA tager denne proces 6 måneder. Vi mødtes inden for 3 måneder, og nu forstår vi, at vi knap havde tid nok: kun ved at udføre analysen forstår du, hvilke spørgsmål du skal stille.

Deltagere

Alle udenlandske rapporter begynder med et portræt af deltagerne, og de fleste af dem er ikke fra Rusland. Procentdelen af ​​russiske respondenter svinger fra 5 til 1% fra år til år, og det giver os ikke mulighed for at drage nogen konklusioner.

Kort fra Accelerate State of DevOps 2019-rapporten:

I vores undersøgelse var vi i stand til at interviewe 889 personer - det er ret mange (DORA undersøgelser omkring tusinde mennesker årligt i sine rapporter), og her nåede vi vores mål:

Det er rigtigt, at ikke alle vores deltagere nåede slutningen: fuldførelsesprocenten viste sig at være lidt mindre end halvdelen. Men selv dette var nok til at få en repræsentativ prøve og foretage en analyse. DORA oplyser ikke fyldningsprocenter i sine rapporter, så der er ingen sammenligning her.

Industrier og stillinger

Vores respondenter repræsenterer et dusin brancher. Halvdelen arbejder med informationsteknologi. Herefter følger finansielle tjenesteydelser, handel, telekommunikation og andre. Blandt stillingerne er specialister (udvikler, tester, driftsingeniør) og ledelsespersonale (ledere af teams, grupper, områder, direktører):

Hver anden person arbejder i en mellemstor virksomhed. Hver tredje arbejder i store virksomheder. De fleste arbejder i teams på op til 9 personer. Separat spurgte vi til hovedaktiviteterne, og størstedelen er på den ene eller anden måde relateret til drift, og omkring 40% er involveret i udvikling:

Så vi indsamlede oplysninger til sammenligning og analyse af repræsentanter for forskellige industrier, virksomheder, teams. Min kollega Vitaly Khabarov vil fortælle dig om analysen.

Analyse og sammenligning

Vitaly Khabarov: Mange tak til alle deltagere, som gennemførte vores undersøgelse, udfyldte spørgeskemaer og gav os data til yderligere analyse og test af vores hypoteser. Og takket være vores kunder og kunder har vi et væld af erfaring, der har hjulpet os med at identificere problemer, der bekymrer industrien, og formulere de hypoteser, som vi testede i vores forskning.

Desværre kan du ikke bare tage en liste med spørgsmål på den ene side og data på den anden side, på en eller anden måde sammenligne dem, sige: "Ja, alt fungerer sådan, vi havde ret" og gå hver til sit. Nej, vi har brug for metodologi og statistiske metoder for at være sikre på, at vi ikke tog fejl, og at vores konklusioner er pålidelige. Så kan vi bygge vores videre arbejde ud fra disse data:

Nøglemålinger

Vi tog udgangspunkt i DORA-metoden, som de beskrev detaljeret i bogen "Accelerate State of DevOps". Vi har tjekket, om nøglemålingerne er egnede til det russiske marked, om de kan bruges på samme måde, som DORA bruger til at besvare spørgsmålet: "Hvordan svarer industrien i Rusland til udenlandsk industri?"

Nøglemålinger:

1. Implementeringsfrekvens. Hvor ofte implementeres en ny version af en applikation til produktionsmiljøet (planlagte ændringer, ekskl. hotfixes og hændelsesrespons)?
2. Leveringstid. Hvad er den gennemsnitlige tid mellem at udføre en ændring (skrive funktionalitet som kode) og implementere ændringen i produktionsmiljøet?
3. Restitutionstid. Hvor lang tid tager det i gennemsnit at gendanne en applikation i et produktionsmiljø efter en hændelse, serviceforringelse eller opdagelse af en fejl, der påvirker applikationsbrugere?
4. Mislykkede ændringer. Hvilken procentdel af implementeringer i et produktmiljø fører til applikationsforringelse eller hændelser og kræver eliminering af konsekvenser (tilbagestilling af ændringer, udvikling af et hotfix eller patch)?

DORAs forskning har fundet en sammenhæng mellem disse målinger og organisatoriske præstationer. Vi tjekker det også i vores undersøgelse.

Men for at sikre, at de fire nøglemetrikker kan påvirke noget, skal du forstå - er de på en eller anden måde relateret til hinanden? DORA svarede ja, med en advarsel: forholdet mellem Change Failure Rate og de tre andre metrics er lidt svagere. Vi fik omtrent det samme billede. Hvis leveringstid, implementeringshyppighed og restitutionstid er korreleret med hinanden (vi etablerede denne korrelation gennem Pearson-korrelationen og gennem Chaddock-skalaen), så er der ikke så stærk korrelation med mislykkede ændringer.

I princippet har de fleste respondenter en tendens til at svare, at de har et ret lille antal hændelser i produktionen. Selvom vi senere vil se, at der stadig er en signifikant forskel mellem grupper af respondenter i antallet af mislykkede ændringer, kan vi endnu ikke bruge denne metrik til denne opdeling.

Vi tilskriver dette, at der (som det viste sig i processen med analyse og kommunikation med nogle af vores kunder) er en lille forskel i opfattelsen af, hvad der betragtes som en hændelse. Hvis det lykkedes os at genoprette funktionaliteten af ​​vores tjeneste under det tekniske vindue, kan dette så betragtes som en hændelse? Sandsynligvis ikke, for vi har rettet alt, vi er fantastiske. Kan det betragtes som en hændelse, hvis vi skulle genrulle vores ansøgning 10 gange i normal, velkendt tilstand? Det lader ikke til. Derfor forbliver spørgsmålet om forholdet mellem mislykkede ændringer og andre målinger åbent. Vi vil afklare det yderligere.

Vigtigt her er, at vi fandt en signifikant sammenhæng mellem leveringstider, gendannelsestider og implementeringshyppighed. Derfor tog vi disse tre målinger for yderligere at opdele respondenterne i præstationsgrupper.

Hvor meget at hænge i gram?

Vi brugte hierarkisk klyngeanalyse:

• Vi fordeler respondenter på tværs af n-dimensionelt rum, hvor hver respondents koordinat er deres svar på spørgsmålene.
• Vi erklærer hver respondent for at være en lille klynge.
• Vi kombinerer de to klynger tættest på hinanden til en større klynge.
• Vi finder det næste par klynger og kombinerer dem til en større klynge.

Sådan grupperer vi alle vores respondenter i det antal klynger, vi har brug for. Ved hjælp af et dendrogram (et træ af forbindelser mellem klynger) ser vi afstanden mellem to naboklynger. Det eneste, der er tilbage for os, er at sætte en vis grænse for afstanden mellem disse klynger og sige: "Disse to grupper er ret adskilte fra hinanden, fordi afstanden mellem dem er gigantisk."

Men der er et skjult problem her: Vi har ingen begrænsninger på antallet af klynger - vi kan få 2, 3, 4, 10 klynger. Og den første idé var - hvorfor ikke dele alle vores respondenter op i 4 grupper, som DORA gør. Men vi fandt ud af, at forskellene mellem disse grupper bliver ubetydelige, og vi kan ikke være sikre på, at respondenten virkelig tilhører sin gruppe og ikke til naboen. Vi kan endnu ikke opdele det russiske marked i fire grupper. Derfor lagde vi os til tre profiler, som der er en statistisk signifikant forskel imellem:

Dernæst bestemte vi profilen efter klynger: vi tog medianen for hver metrik for hver gruppe og kompilerede en tabel med præstationsprofiler. Faktisk fik vi præstationsprofilerne for den gennemsnitlige deltager i hver gruppe. Vi har identificeret tre effektivitetsprofiler: Lav, Medium, Høj:

Her har vi bekræftet vores hypotese om, at 4 nøglemetrikker er velegnede til at bestemme præstationsprofilen, og de virker på både det vestlige og russiske marked. Der er forskel på grupperne, og det er statistisk signifikant. Jeg vil gerne understrege, at der er en signifikant forskel i middelværdien mellem præstationsprofilerne for metrikken for mislykkede ændringer, selvom vi i første omgang ikke delte respondenterne med denne parameter.

Så opstår spørgsmålet: hvordan bruger man alt dette?

Sådan bruges

Hvis vi tager et hvilket som helst hold, 4 nøglemålinger og anvender det på tabellen, så vil vi i 85% af tilfældene ikke få en komplet match - dette er kun en gennemsnitlig deltager, og ikke hvad der er i virkeligheden. Vi er alle (og hvert hold) lidt forskellige.

Vi tjekkede: vi tog vores respondenter og DORA præstationsprofilen, og så på hvor mange respondenter der svarede til en eller anden profil. Vi fandt ud af, at kun 16 % af de adspurgte faldt nøjagtigt ind i en af ​​profilerne. Resten er spredt et sted imellem:

Det betyder, at præstationsprofilen har et begrænset omfang. For at få en første tilnærmelse af, hvor du er, kan du bruge denne tabel: "Åh, det ser ud til, at vi er tættere på Medium eller High!" Hvis du forstår, hvor du skal hen, kan det være nok. Men hvis dit mål er konstant, kontinuerlig forbedring, og du vil vide mere præcist, hvor du skal udvikle dig, og hvad du skal gøre, så er der behov for yderligere midler. Vi kaldte dem lommeregnere:

• DORA lommeregner
• Calculator Express 42* (under udvikling)
• Din egen udvikling (du kan lave din egen interne lommeregner).

Hvad skal de bruge til? At forstå:

• Er teamet i vores organisation op til vores standarder?
• Hvis ikke, kan vi så hjælpe hende – fremskynde det inden for rammerne af den ekspertise, som vores virksomhed har?
• Hvis ja, kan vi gøre det endnu bedre?

Du kan også bruge dem til at indsamle statistik i virksomheden:

• Hvilken slags hold har vi?
• Opdel teams i profiler;
• Se: Åh, disse teams er underpræsterende (lidt langsomme), men de er fantastiske: de implementerer hver dag, uden fejl, deres leveringstid er mindre end en time.

Og så kan du finde ud af, at vi inden for vores virksomhed har den nødvendige ekspertise og værktøjer til de teams, der stadig mangler.

Eller hvis du forstår, at du har det godt i virksomheden, at du er bedre end mange, så kan du se lidt bredere. Det er netop den russiske industri: Kan vi få den nødvendige ekspertise i den russiske industri til at sætte fart på os selv? Express 42-beregneren hjælper her (den er under udvikling). Hvis du er vokset ud af det russiske marked, så se på DORA lommeregner og til verdensmarkedet.

Bøde. Og hvis du er i Elit-gruppen ifølge DORA-beregneren, hvad skal du så gøre? Der er ingen god løsning her. Du er højst sandsynligt på forkant med branchen, og yderligere acceleration og pålidelighed er mulig gennem intern forskning og udvikling og brug af flere ressourcer.

Lad os gå videre til den sødeste del - sammenligning.

sammenligning

Vi ønskede oprindeligt at sammenligne russisk industri med vestlig industri. Hvis vi sammenligner direkte, ser vi, at vi har færre profiler, og de er lidt mere blandet med hinanden, grænserne er lidt mere udviskede:

Vores Elite-performere er gemt blandt High-performers, men de er der - det er eliten, enhjørninger, der har nået betydelige højder. I Rusland er forskellen mellem Elite- og High-profilerne endnu ikke markant nok. Vi tror, ​​at denne opdeling i fremtiden vil ske på grund af en stigning i ingeniørkulturen, kvaliteten af ​​implementeringen af ​​ingeniørpraksis og ekspertise i virksomheder.

Hvis vi går videre til direkte sammenligning inden for den russiske industri, ser vi, at højprofilerede teams er bedre i alle henseender. Vi bekræftede også vores hypotese om, at der er en sammenhæng mellem disse målinger og organisatorisk effektivitet: Højprofilerede teams er betydeligt mere tilbøjelige til ikke kun at nå mål, men også overgå dem.
Lad os blive højt profilerede hold og ikke stoppe der:

Men dette år er specielt, og vi besluttede at tjekke, hvordan virksomheder klarer sig i en pandemi: Højprofilerede teams klarer sig meget bedre og føler sig bedre end branchegennemsnittet:

• Nye produkter blev udgivet 1,5-2 gange oftere,
• Øget pålidelighed og/eller ydeevne af applikationsinfrastruktur 2 gange oftere.

Det vil sige, at de kompetencer, de allerede havde, hjalp dem med at udvikle hurtigere, lancere nye produkter, modificere eksisterende produkter og dermed erobre nye markeder og nye brugere:

Hvad har ellers hjulpet vores teams?

Ingeniørpraksis

Jeg vil fortælle dig om de væsentlige resultater for hver praksis, vi testede. Måske har noget andet hjulpet holdene, men vi taler om DevOps. Og inden for DevOps ser vi forskel på teams med forskellige profiler.

Platform som en service

Vi fandt ikke en signifikant sammenhæng mellem platformens alder og teamprofilen: Platforme dukkede op på nogenlunde samme tidspunkt for både Low og High teams. Men for sidstnævnte giver platformen i gennemsnit flere tjenester og flere softwaregrænseflader til kontrol gennem programkode. Og platformsteams er mere tilbøjelige til at hjælpe deres udviklere og teams med at bruge platformen, mere tilbøjelige til at løse deres problemer og hændelser relateret til platformen og træne andre teams.

Infrastruktur som kode

Alt her er ret standard. Vi har fundet en sammenhæng mellem automatisering af arbejdet med infrastrukturkoden og hvor meget information der er gemt inde i infrastrukturlageret. Højprofilkommandoerne gemmer flere oplysninger i lagrene: dette er infrastrukturkonfigurationen, CI/CD-pipeline, miljøindstillinger og build-parametre. De gemmer disse oplysninger oftere, arbejder bedre med infrastrukturkode og automatiserer flere processer og opgaver til at arbejde med infrastrukturkode.

Interessant nok så vi ikke en signifikant forskel i infrastrukturtests. Jeg tilskriver dette det faktum, at højprofilerede teams generelt har mere testautomatisering. Måske skal de ikke distraheres separat af infrastrukturtests, men snarere de tests, som de kontrollerer applikationer med, og takket være dem kan de allerede se, hvad og hvor de er gået i stykker.

Integration og levering

Den mest kedelige sektion, fordi vi bekræftede, at jo mere automatisering du har, jo bedre du arbejder med koden, jo større er sandsynligheden for, at du får bedre resultater.

arkitektur

Vi ønskede at se, hvordan mikrotjenester påvirker ydeevnen. For at være ærlig gør de det ikke, da brugen af ​​mikrotjenester ikke er forbundet med en stigning i effektivitetsindikatorer. Mikrotjenester bruges af både høj- og lavprofilhold.

Men det væsentlige er, at for High-teams giver overgangen til en mikroservicearkitektur dem mulighed for selvstændigt at udvikle deres tjenester og udrulle dem. Hvis arkitekturen tillader udviklere at handle selvstændigt uden at vente på nogen eksternt til teamet, så er dette en nøglekompetence til at øge hastigheden. Det er her mikrotjenester hjælper. Men ganske enkelt deres implementering spiller ikke nogen stor rolle.

Hvordan opdagede vi alt dette?

Vi havde en ambitiøs plan for fuldt ud at kopiere DORA-metoden, men manglede ressourcer. Hvis DORA bruger meget sponsorater og deres forskning tager et halvt år, lavede vi vores research på kort tid. Vi ønskede at bygge en DevOps-model, som DORA gør, og det vil vi gøre i fremtiden. For nu har vi begrænset os til varmekort:

Vi så på fordelingen af ​​ingeniørpraksis blandt teams af hver profil, og fandt ud af, at teams af High profile i gennemsnit bruger ingeniørpraksis oftere. Alt dette kan du læse mere om i vores rapport.

Lad os for en forandring skifte fra komplekse statistikker til simple.

Hvad har vi ellers opdaget?

Værktøj

Vi observerer, at Linux OS-familien bruger flest kommandoer. Men Windows er stadig i trend - mindst en fjerdedel af vores respondenter bemærkede brugen af ​​en eller anden version af det. Markedet ser ud til at have dette behov. Derfor kan du udvikle disse kompetencer og holde oplæg på konferencer.

Blandt orkestratorer er det ingen hemmelighed, at Kubernetes leder (52%). Den næste orkestrator i rækken er Docker Swarm (ca. 12%). De mest populære CI-systemer er Jenkins og GitLab. Det mest populære konfigurationsstyringssystem er Ansible, efterfulgt af vores elskede Shell.

Amazon er i øjeblikket den førende cloud-hostingudbyder. Andelen af ​​russiske skyer er gradvist stigende. Næste år bliver det interessant at se, hvordan russiske cloud-udbydere vil have det, og om deres markedsandel vil stige. De findes, de kan bruges, og det er godt:

Jeg giver ordet til Igor, som vil give nogle flere statistikker.

Formidling af praksis

Igor Kurochkin: Separat bad vi respondenterne om at angive, hvordan den overvejede ingeniørpraksis er fordelt i virksomheden. De fleste virksomheder har en blandet tilgang bestående af et andet sæt mønstre, og pilotprojekter er meget populære. Vi så også en lille forskel på profilerne. Repræsentanter for den høje profil bruger oftere mønsteret "Initiativ nedefra", når små teams af specialister ændrer arbejdsprocesser, værktøjer og deler succesfulde udviklinger med andre teams. Hos Medium er dette et top-down-initiativ, der berører hele virksomheden gennem skabelsen af ​​fællesskaber og ekspertisecentre:

Agile og DevOps

Forholdet mellem Agile og DevOps diskuteres ofte i branchen. Dette spørgsmål er også rejst i State of Agile-rapporten for 2019/2020, så vi besluttede at sammenligne, hvordan Agile- og DevOps-aktiviteter i virksomheder hænger sammen. Vi har fundet ud af, at DevOps uden Agile er sjælden. For halvdelen af ​​de adspurgte begyndte spredningen af ​​Agile mærkbart tidligere, og omkring 20 % observerede en samtidig start, og et af tegnene på en lav profil vil være fraværet af Agile og DevOps praksis:

Kommandotopologier

I slutningen af ​​sidste år bogen "Teamtopologier", som foreslår en ramme til beskrivelse af teamtopologier. Vi spekulerede på, om det ville gælde russiske virksomheder. Og vi stillede spørgsmålet: "Hvilke mønstre ser du?"

Infrastrukturteams observeres hos halvdelen af ​​respondenterne, såvel som separate udviklings-, test- og driftsteams. Individuelle DevOps-hold noterede sig 45%, blandt hvilke høje repræsentanter er mere almindelige. Dernæst kommer tværgående teams, som også er mere almindelige på High. Separate SRE-kommandoer vises i profilerne Høj, Mellem og findes sjældent i profilen Lav:

DevQaOps-forhold

Vi så dette spørgsmål på FaceBook fra teamlederen for Skyeng-platformsteamet - han var interesseret i forholdet mellem udviklere, testere og administratorer i virksomheder. Vi spurgte det og så på svarene under hensyntagen til profilerne: repræsentanter for den høje profil har et mindre antal test- og driftsingeniører for hver udvikler:

Planer for 2021 år

I deres planer for det næste år bemærkede respondenterne følgende aktiviteter:

Her kan du se krydset med DevOps Live 2020-konferencen. Vi har nøje gennemgået programmet:

• Infrastruktur som produkt
• DevOps transformation
• Distribution af DevOps-praksis
• DevSecOps
• Caseklubber og diskussioner

Men vores foredrag vil ikke have tid nok til at dække alle emnerne. Bag scenen:

• Platform som en service og som et produkt;
• Infrastruktur som kode, miljøer og skyer;
• Kontinuerlig integration og levering;
• Arkitektur;
• DevSecOps mønstre;
• Platform og tværgående teams.

Rapport Vores er omfangsrig, 50 sider lang, og du kan se nærmere på den.

Opsummering

Vi håber, at vores forskning og rapport vil inspirere dig til at eksperimentere med nye tilgange til udvikling, test og drift, samt hjælpe dig med at finde ud af, sammenligne dig selv med andre i undersøgelsen og identificere områder, hvor du kan forbedre dine egne tilgange .

Resultater af den første undersøgelse af staten DevOps i Rusland:

• Nøglemålinger. Vi har fundet ud af, at nøglemålinger (leveringstid, implementeringshastighed, retableringstid og ændringsfejl) er velegnede til at analysere effektiviteten af ​​udviklings-, test- og driftsprocesser.
• Profiler Høj, Medium, Lav. Baseret på de indsamlede data er det muligt at skelne statistisk forskellige grupper af Høj, Medium, Lav med karakteristiske træk i form af metrik, praksis, processer og værktøjer. Repræsentanter for den høje profil viser bedre resultater end lav. De er mere tilbøjelige til at nå og overgå deres mål.
• Indikatorer, pandemi og planer for 2021. En særlig indikator i år er, hvordan virksomheder klarede pandemien. High præsterede bedre, oplevede en stigning i brugeraktivitet, og hovedårsagerne til succes var effektive udviklingsprocesser og en stærk ingeniørkultur.
• DevOps-praksis, værktøjer og deres udvikling. Virksomhedernes hovedplaner for det næste år omfatter udvikling af DevOps praksis og værktøjer, introduktion af DevSecOps praksis og ændringer i organisationsstrukturen. Og den effektive implementering og udvikling af DevOps-praksis udføres gennem pilotprojekter, dannelse af fællesskaber og kompetencecentre, initiativer på øverste og nederste niveau i virksomheden.

Vi vil være glade for at høre dine anmeldelser, historier, feedback. Vi takker alle, der har deltaget i undersøgelsen og ser frem til din deltagelse næste år.

Kilde: www.habr.com