Status for DevOps i Rusland 2020

Hvordan kan man overhovedet forstå tilstanden af ​​noget?

Du kan stole på din egen mening, dannet ud fra forskellige informationskilder, såsom publikationer på websteder eller erfaringer. Du kan spørge kolleger og bekendte. En anden mulighed er at se på konferencens emner: Programudvalget består af aktive repræsentanter for branchen, så vi stoler på dem, når de vælger relevante emner. Et særskilt område er forskning og rapportering. 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 der.

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. Tilstanden for DevOps i Rusland blev i fællesskab undersøgt af virksomhederne "Express 42"Og"Ontiko". Express 42 hjælper teknologivirksomheder med at implementere og udvikle DevOps-praksis og -værktøjer og var en af ​​de første, der begyndte at tale om DevOps i Rusland. Forfatterne til undersøgelsen, Igor Kurochkin og Vitaly Khabarov, er engageret i analyse og rådgivning hos virksomheden Express 42, samtidig med at de har en teknisk baggrund fra drift og erfaring med at arbejde i forskellige virksomheder. I løbet af dusinvis af virksomheder og 8 år, har og kolleger kigget på projekter fra XNUMX år og XNUMX år. startups til virksomheder, med forskellige problemer og varierende niveauer af kulturel og ingeniørmæssig modenhed.

I deres rapport talte Igor og Vitaly om de problemer, der opstod 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. Deres rapport kan ses 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, og vores forskning viste, at kun en tredjedel studerer dem. Hvis du aldrig har set disse rapporter, lad os bare sige, at de alle er meget ens. Oftest vil du finde sætninger som: "Sammenlignet med sidste år..."

Her stødte vi på vores første problem, og derefter to mere:

1. Vi har ikke data for sidste år. DevOps-tilstanden i Rusland er af ingen interesse for nogen;
2. Metodik. Det er ikke klart, hvordan man tester hypoteser, hvordan man formulerer spørgsmål, hvordan man udfører en analyse, 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 tage et kig på, hvordan DevOps-tilstandsanalyser er blevet udført rundt om i verden.

Historie

DevOps-forskning 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 i form af lukkede undersøgelser og uden offentlige rapporter.

I 2013 blev IT Revolution, udgiveren af ​​alle de store bøger om DevOps, grundlagt. Sammen med Puppet udarbejdede de den første publikation "State of DevOps", hvor 4 nøglemålinger dukkede op for første gang. Året efter kom konsulentfirmaet ThoughtWorks, kendt for sine faste teknologiradarer om industripraksis og værktøjer, med. 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 af ​​Puppet og den anden af ​​DORA i samarbejde med Google. DORA fortsatte med at udnytte sin metodik med nøglemålinger, præstationsprofiler og ingeniørpraksis, der påvirker nøglemålinger og præstationer på tværs af hele virksomheden. Og Puppet tilbød sin egen tilgang med en beskrivelse af processen og udviklingen af ​​DevOps. Men historien fangede ikke, og i 2019 opgav Puppet denne metode og udgav en ny version af rapporter, som 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. Du har måske set ham.

I år er tingene blevet svære. Det er kendt, at Puppet har lanceret sin undersøgelse. De gjorde det en uge tidligere end os, og det er allerede færdigt. Vi deltog i det og så, hvilke emner de var interesserede i. Puppet udfører i øjeblikket sin analyse og forbereder udgivelsen af ​​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 forsket i DevOps. Vi talte ved konferencer, genfortællede andres resultater, og Raiffeisenbank oversatte "State of DevOps" for 2019 (du kan finde deres meddelelse på Habr), mange tak til dem. Og det er alt.

Derfor udførte vi vores egen forskning i Rusland ved hjælp af DORA-metoder og -resultater. Vi brugte rapporten fra vores kolleger fra Raiffeisenbank til vores forskning, herunder til synkronisering af 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 hovedfaser:

Under forberedelsesfasen interviewede vi brancheeksperter og udarbejdede en liste over hypoteser. På baggrund af disse blev der udarbejdet spørgsmål og iværksat en undersøgelse for hele august måned. Derefter analyserede og udarbejdede vi selve rapporten. Hos DORA tager denne proces 6 måneder. Vi gennemførte opgaven på 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 der skal stilles.

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 mellem 5 og 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 lykkedes det at interviewe 889 personer - det er ret mange (DORA interviewer årligt omkring tusinde personer i sine rapporter) og her nåede vi målet:

Det var rigtigt, at ikke alle vores deltagere nåede til slutningen: Gennemførelsesraten var lidt mindre end det halve. Men dette var nok til at få en repræsentativ prøve og foretage en analyse. DORA oplyser ikke belægningsprocenten i sine rapporter, så det er ikke muligt at sammenligne her.

Industrier og stillinger

Vores respondenter repræsenterer et dusin brancher. Halvdelen arbejder inden for informationsteknologi. Dernæst kommer finansielle tjenesteydelser, handel, telekommunikation og andre. Stillingerne omfatter specialister (udvikler, tester, driftsingeniør) og ledelse (team, gruppe, afdelingschefer, 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. Vi spurgte separat om hovedaktiviteterne, og størstedelen er på en eller anden måde relateret til udnyttelse, mens omkring 40% er involveret i udvikling:

Så vi indsamlede oplysninger til sammenligning og analyse af repræsentanter for forskellige brancher, virksomheder og 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 forsynede os med 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 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, sådan fungerer det, 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 tager fejl, og at vores konklusioner er pålidelige. Så kan vi bygge vores videre arbejde ud fra disse data:

Nøglemålinger

Vi baserede vores tilgang på DORA-metoden, som de beskrev detaljeret i deres bog "Accelerate State of DevOps". Vi tjekkede, om nøglemålingerne er egnede til det russiske marked, om de kan bruges på samme måde som DORA gør, for at besvare spørgsmålet: "I hvor høj grad svarer industrien i Rusland til den udenlandske industri?"

Nøglemålinger:

1. Hyppighed af implementeringer. Hvor ofte implementeres en ny version af applikationen til produktionsmiljøet (planlagte ændringer, ekskl. hotfixes og hændelsesrespons)?
2. Leveringstid. Hvor lang tid tager det i gennemsnit mellem at begå 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 til et produktionsmiljø efter en hændelse, serviceforringelse eller opdagelse af en fejl, der påvirker applikationsbrugere?
4. Mislykkede ændringer. Hvor stor en procentdel af produktionsimplementeringer resulterer i applikationsforringelse eller hændelser, der kræver afhjælpning (ændringsrulning, hotfix eller patchudvikling)?

DORA fandt en sammenhæng mellem disse målinger og organisatorisk effektivitet i sin forskning. Vi tester det også i vores forskning.

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. Mens leveringstid, implementeringshyppighed og restitutionstid er korreleret (vi fandt denne korrelation ved hjælp af Pearson-korrelationen og Chaddock-skalaen), er der ikke så stærk korrelation med mislykkede ændringer.

I princippet plejer flertallet af de adspurgte at svare, at de har et ret lille antal hændelser i produktionen. Selvom vi senere vil se, at der stadig er en væsentlig forskel mellem respondentgrupperne med hensyn til forandringssvigt, kan vi endnu ikke bruge denne metrik til at skelne.

Vi tilskriver dette, at der (som det viste sig under analysen og kommunikationen 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 den normale, sædvanlige tilstand for os? Det lader ikke til. Derfor forbliver spørgsmålet om forholdet mellem mislykkede ændringer og andre målinger åbent. Det vil vi afklare yderligere.

Det, der er vigtigt her, er, at vi fandt en signifikant sammenhæng mellem leveringstider, gendannelsestider og implementeringshyppighed. Derfor tog vi disse tre målinger til yderligere opdeling af respondenter i grupper baseret på produktivitet.

Hvor meget at hænge i gram?

Vi brugte hierarkisk klyngeanalyse:

• Vi fordeler respondenter på tværs af et 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 nærmeste klynger til en større klynge.
• Vi finder det næste par klynger og kombinerer dem til en større klynge.

På denne måde 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) kan vi se afstanden mellem to tilstødende klynger. 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 grænse for 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 en nabogruppe. 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 på:

Dernæst definerede vi en profil efter klynger: vi tog medianerne for hver metrik for hver gruppe og kompilerede en tabel med præstationsprofiler. Resultaterne var faktisk præstationsprofiler for den gennemsnitlige deltager i hver gruppe. Vi har identificeret tre præstationsprofiler: Lav, Medium, Høj:

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

Det næste spørgsmål er: hvordan bruger man alt dette?

Sådan bruges

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

Vi testede det ved at tage vores respondenter og DORAs præstationsprofil og se på, hvor mange respondenter der matchede hver profil. Vi fandt ud af, at kun 16 % af de adspurgte matchede nøjagtigt en af ​​profilerne. Resten er spredt et sted imellem:

Det betyder, at præstationsprofilen har et begrænset anvendelsesområde. For at få en første idé om, 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 vil hen næste gang, er det måske 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å har du brug for yderligere ressourcer. Vi kaldte dem lommeregnere:

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

Hvorfor er der brug for dem? For at forstå:

• Opfylder teamet i vores organisation 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:

• Hvilke hold har vi;
• Opdel teams i profiler;
• Se: Åh, disse teams er underpræsterende (trækker ikke helt deres vægt), 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 der i vores virksomhed er den nødvendige ekspertise og værktøjer til de teams, der endnu ikke er på niveau.

Eller, hvis du forstår, at du inden for virksomheden har det godt, du er bedre end mange, så kan du se lidt bredere ud. 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 (under udvikling) vil hjælpe her. 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. Chancerne er, at du er på forkant med branchen, og yderligere forbedringer af hastighed og pålidelighed kan opnås gennem intern forskning og udvikling og ved at bruge flere ressourcer.

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

sammenligning

Vi ønskede i første omgang at sammenligne den russiske industri med den vestlige industri. Hvis vi sammenligner direkte, ser vi, at vi har færre profiler, og de er lidt mere blandet sammen, grænserne er lidt mere slørede:

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

Hvis vi går videre til en 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 lever i pandemien: Højprofilerede teams klarer sig meget bedre og har det bedre end branchegennemsnittet:

• Nye produkter blev udgivet 1,5-2 gange oftere,
• 2 gange større sandsynlighed for at forbedre applikationsinfrastrukturens pålidelighed og/eller ydeevne.

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

Hvad hjalp ellers vores teams?

Ingeniørpraksis

Jeg vil fortælle dig om de væsentlige resultater for hver praksis, vi testede. Der kan være andre ting, der hjalp holdene, men vi taler om DevOps. Og inden for DevOps ser vi forskelle mellem teams med forskellige profiler.

Platform som en service

Vi fandt ingen signifikant sammenhæng mellem platformsalder og teamprofil: Platforme opstod på nogenlunde samme tidspunkt for både lave og høje teams. Men sidstnævnte platform giver 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 platform-relaterede problemer og hændelser og til at træne andre teams.

Infrastruktur som kode

Alt her er ret standard. Vi fandt en sammenhæng mellem automatisering af infrastrukturkode og hvor meget information der er gemt inde i infrastrukturlageret. Højprofilerede teams gemmer flere oplysninger i repositories: Dette inkluderer infrastrukturkonfiguration, CI/CD-pipeline, miljøindstillinger og build-parametre. De gemmer disse oplysninger oftere, arbejder bedre med infrastrukturkode og har automatiseret flere processer og opgaver omkring arbejdet med infrastrukturkode.

Interessant nok så vi ikke nogen signifikant forskel i infrastrukturtestene. Jeg tilskriver dette det faktum, at højprofilerede teams generelt har mere testautomatisering. Måske skal de ikke distraheres af infrastrukturtests hver for sig, men derimod er de test, de bruger til at kontrollere applikationer, nok, og takket være dem kan de se, hvad og hvor der er brudt.

Integration og levering

Det mest kedelige afsnit, fordi vi bekræftede, at jo mere automatisering du har, jo bedre du arbejder med kode, jo større er sandsynligheden for, at du får bedre metrics.

arkitektur

Vi ville se, hvor meget mikrotjenester påvirker ydeevnen. For at være ærlig gør de det ikke, da brugen af ​​mikrotjenester ikke er forbundet med øgede 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 kommer til nytte. Men deres simple 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 vi manglede ressourcer. Mens DORA har mange sponsorater, og deres forskning tager seks måneder, 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. Indtil videre har vi begrænset os til varmekort:

Vi så på fordelingen af ​​ingeniørpraksis på tværs af teams i hver profil og fandt ud af, at højprofilerede teams i gennemsnit var mere tilbøjelige til at bruge ingeniørpraksis. 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 OS-familien bruger flest kommandoer Linux. men Windows Det er stadig populært – mindst en fjerdedel af vores respondenter rapporterede, at de bruger en eller anden version af det. Der synes at være en markedsefterspørgsel efter det. Derfor kan du udvikle disse kompetencer og præsentere på konferencer.

Blandt orkestratorer er det ingen hemmelighed, at Kubernetes er lederen (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.

Blandt cloud-hosting-tjenester har Amazon i øjeblikket den førende position. 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 overlader ordet til Igor, som vil give nogle flere statistikker.

Spredning af praksis

Igor Kurochkin: Vi bad separat respondenterne om at angive, hvordan den betragtede ingeniørpraksis er fordelt inden for virksomheden. De fleste virksomheder har en blandet tilgang, der består 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 "Bottom-up Initiative"-mønsteret, når små teams af specialister ændrer arbejdsprocesser, værktøjer og deler succesfulde udviklinger med andre teams. Hos Medium er det et top-down-initiativ, der berører hele virksomheden ved at skabe fællesskaber og ekspertisecentre:

Agile og DevOps

Forholdet mellem Agile og DevOps er et ofte diskuteret emne 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 er relateret i virksomheder. Vi fandt ud af, at DevOps uden Agile er sjælden. Halvdelen af ​​de adspurgte så spredningen af ​​Agile begynde 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 udgav bogen "Teamtopologier", som foreslår en ramme til beskrivelse af kommandotopologier. Vi spekulerede på, om det var anvendeligt for russiske virksomheder. Og vi stillede spørgsmålet: "Hvilke mønstre ser du?"

Infrastrukturteams findes i halvdelen af ​​respondenterne, såvel som separate udviklings-, test- og driftsteams. Individuelle DevOps-hold blev noteret af 45 %, blandt hvilke høje repræsentanter er mere almindelige. Dernæst kommer tværgående teams, som også er mere almindelige på High. Individuelle 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 stillede dette spørgsmål og så på svarene på tværs af profiler: Højprofilerede personer har færre test- og driftsingeniører pr. udvikler:

Planer for 2021 år

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

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

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

Men vores præsentationstid er ikke nok til at dække alle emnerne. Bag kulisserne:

• 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 viste sig at være 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, og vil hjælpe dig med at navigere, sammenligne dig selv med andre forskningsdeltagere og identificere områder, hvor du kan forbedre dine egne tilgange.

Resultater af den første undersøgelse om tilstanden af ​​DevOps i Rusland:

• Nøglemålinger. Vi fandt ud af, at nøglemålinger (leveringstid, implementeringsfrekvens, retableringstid og mislykkede ændringer) er velegnede til at analysere effektiviteten af ​​udviklings-, test- og driftsprocesser.
• Profiler Høj, Medium, Lav. Baseret på de indsamlede data kan statistisk distinkte grupper af Høj, Medium, Lav identificeres 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 de lave. De har en bedre chance for 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 øget brugerengagement og tilskrev deres succes til 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, implementering 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å top- og bundniveau i virksomheden.

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

Kilde: www.habr.com