Tillståndet för DevOps i Ryssland 2020

Hur förstår du ens tillståndet för något?

Du kan lita på din åsikt, bildad från olika informationskällor, till exempel publikationer på webbplatser eller erfarenhet. Du kan fråga dina kollegor och vänner. Ett annat alternativ är att titta på ämnena för konferenserna: programkommittén är aktiva representanter för branschen, så vi litar på att de väljer relevanta ämnen. Ett separat område är forskning och rapporter. Men det är ett problem. Forskning om tillståndet för DevOps utförs årligen runt om i världen, rapporter publiceras av utländska företag och det finns nästan ingen information om ryska DevOps.

Men dagen har kommit då en sådan studie genomfördes, och idag kommer vi att berätta om resultaten som erhållits. Tillståndet för DevOps i Ryssland studerades gemensamt av företagen "Express 42"Och"Ontiko" Express 42-företaget hjälper teknikföretag att implementera och utveckla DevOps-praxis och verktyg och var en av de första som pratade om DevOps i Ryssland. Författarna till studien, Igor Kurochkin och Vitaly Khabarov, är engagerade i analys och rådgivning på Express 42, med en teknisk bakgrund från drift och erfarenhet i olika företag. Under 8 år tittade kollegor på dussintals företag och projekt - från startups till företag - med olika problem, såväl som olika kulturell och teknisk mognad.

I sin rapport förklarade Igor och Vitaly vilka problem som fanns under forskningsprocessen, hur de löste dem, samt hur DevOps-forskning bedrivs i princip och varför Express 42 bestämde sig för att genomföra sin egen. Du kan se deras rapport här.

DevOps Research

Igor Kurochkin startade konversationen.

Vi frågar regelbundet publiken på DevOps-konferenser: "Har du läst årets State of DevOps-rapport?" Bara ett fåtal räcker upp handen, men vår forskning visade att endast en tredjedel studerar dem. Om du aldrig har sett sådana rapporter, låt oss säga direkt att de alla är väldigt lika. Oftast finns det fraser som: "Jämfört med förra året..."

Här har vi vårt första problem, följt av två till:

1. Vi har inga uppgifter för förra året. Ingen är intresserad av tillståndet för DevOps i Ryssland;
2. Metodik. Det är inte klart hur man testar hypoteser, hur man konstruerar frågor, hur man gör analyser, jämför resultat, hittar samband;
3. Terminologi. Alla rapporter är på engelska, översättning krävs, ett gemensamt ramverk för DevOps har ännu inte uppfunnits och alla kommer på sitt eget.

Låt oss titta på hur analyser av tillståndet för DevOps i världen generellt genomfördes.

Historisk information

DevOps-forskning har bedrivits sedan 2011. Den första som genomförde dem var Puppet, en utvecklare av system för konfigurationshantering. På den tiden var det ett av huvudverktygen för att beskriva infrastruktur i form av kod. Fram till 2013 var dessa studier helt enkelt undersökningar i ett slutet format och utan offentlig rapportering.

2013 dök IT Revolution upp, utgivare av alla stora böcker om DevOps. Tillsammans med Puppet förberedde de den första publikationen "State of DevOps", där 4 nyckeltal dök upp för första gången. Året därpå engagerade sig konsultföretaget ThoughtWorks, känt för sina vanliga teknikradarer om branschpraxis och verktyg. Och 2015 tillkom ett avsnitt med metodik, och det blev tydligt hur de utför analysen.

Under 2016 publicerade författarna till studien, efter att ha skapat sitt företag DORA (DevOps Research and Assessment), en årsrapport. Året därpå gav DORA och Puppet ut sin slutliga gemensamma rapport.

Och sedan blev det intressant:

Under 2018 splittrades företagen och två oberoende rapporter släpptes: en från Puppet, den andra från DORA i samarbete med Google. DORA fortsatte att använda sin metodik med nyckeltal, prestationsprofiler och ingenjörspraxis som påverkar nyckeltal och prestanda i hela företaget. Och Puppet föreslog sitt tillvägagångssätt med en beskrivning av processen och utvecklingen av DevOps. Men historien slog inte fast; 2019 övergav Puppet denna metod och släppte en ny version av rapporterna, där den listade viktiga metoder och hur de påverkar DevOps ur deras synvinkel. Sedan hände en annan sak: Google köpte DORA och tillsammans släppte de ytterligare en rapport. Kanske har du sett det.

I år blev det komplicerat. Det är känt att Puppet lanserade sin undersökning. De gjorde det en vecka tidigare än oss, och det var redan klart. Vi deltog i det och såg vilka ämnen som intresserade dem. Puppet gör nu sin analys och förbereder sig för att publicera rapporten.

Men det finns fortfarande inget tillkännagivande från DORA och Google. I maj, när undersökningen vanligtvis började, kom uppgifter om att Nicole Forsgren, en av grundarna till DORA, flyttat till ett annat företag. Därför antog vi att det inte skulle bli någon forskning eller rapport från DORA i år.

Hur är det i Ryssland?

Vi har inte gjort någon forskning om DevOps. Vi talade på konferenser, återberättade andras slutsatser, och Raiffeisenbank översatte "State of DevOps" för 2019 (du kan hitta deras tillkännagivande på Habré), stort tack till dem. Och det är allt.

Därför genomförde vi vår egen forskning i Ryssland med hjälp av DORAs metoder och resultat. Vi använde rapporten från kollegor från Raiffeisenbank för vår forskning, inklusive för att synkronisera terminologi och översättning. Och frågorna som är relevanta för branschen togs från DORA-rapporter och årets Puppet-enkät.

Forskningsprocess

Rapporten är bara den sista delen. Hela forskningsprocessen består av fyra stora steg:

Under förberedelsestadiet intervjuade vi branschexperter och utarbetade en lista med hypoteser. Utifrån dem har vi sammanställt frågor och lanserat en undersökning för hela augusti månad. Sedan analyserade vi och förberedde själva rapporten. För DORA tar denna process 6 månader. Vi slutförde det på 3 månader, och nu förstår vi att vi knappt hade tillräckligt med tid: bara genom att göra analysen förstår du vilka frågor som behöver ställas.

Участники

Alla utländska rapporter börjar med ett porträtt av deltagarna, och de flesta av dem är inte från Ryssland. Andelen ryska svarande varierar från 5 till 1 % från år till år, och detta tillåter oss inte att dra några slutsatser.

Karta från rapporten Accelerate State of DevOps 2019:

I vår studie kunde vi intervjua 889 personer – det är ganska mycket (DORA undersöker årligen cirka tusen personer i sina rapporter) och här nådde vi vårt mål:

Det är sant att inte alla våra deltagare nådde slutet: slutförandeprocenten var något mindre än hälften. Men detta räckte för att få ett representativt urval och genomföra analys. DORA avslöjar inte uthyrningsgrad i sina rapporter, så jämförelser kan inte göras här.

Branscher och befattningar

Våra respondenter representerar ett dussintal branscher. Hälften jobbar inom informationsteknik. Därefter följer finansiella tjänster, handel, telekommunikation och andra. Bland befattningarna finns specialister (utvecklare, testare, driftingenjör) och ledningspersonal (ledare för team, grupper, områden, direktörer):

Varannan person arbetar i ett medelstort företag. Var tredje person arbetar i stora företag. De flesta arbetar i team på upp till 9 personer. Separat frågade vi om huvudaktiviteterna, och majoriteten är på ett eller annat sätt relaterade till drift, och cirka 40% är involverade i utveckling:

Så här samlade vi in ​​information för jämförelse och analys av företrädare för olika branscher, företag och team. Min kollega Vitaly Khabarov kommer att berätta om analysen.

Analys och jämförelse

Vitaly Khabarov: Stort tack till alla deltagare som fyllde i vår undersökning, fyllde i frågeformulär och gav oss data för vidare analys och testning av våra hypoteser. Och tack vare våra kunder och kunder har vi en mängd erfarenhet som har hjälpt oss att identifiera frågor som är angelägna för branschen och formulera de hypoteser som vi testade i vår forskning.

Tyvärr kan du inte bara ta en lista med frågor å ena sidan och data å andra sidan, på något sätt jämföra dem, säga: "Ja, allt fungerar så, vi hade rätt" och gå skilda vägar. Nej, vi behöver metodik och statistiska metoder för att vara säkra på att vi inte hade fel och att våra slutsatser är tillförlitliga. Sedan kan vi bygga vårt fortsatta arbete utifrån dessa data:

Nyckelmått

Vi tog DORA-metoden som grund, som de beskrev i detalj i boken "Accelerate State of DevOps". Vi kontrollerade om nyckelmåtten är lämpliga för den ryska marknaden, om de kan användas på samma sätt som DORA använder för att svara på frågan: "Hur motsvarar industrin i Ryssland utländsk industri?"

Nyckeltal:

1. Distributionsfrekvens. Hur ofta distribueras en ny version av en applikation i produktionsmiljön (planerade ändringar, exklusive snabbkorrigeringar och incidentrespons)?
2. Leveranstid. Vad är den genomsnittliga tiden mellan att utföra en förändring (skriva funktionalitet som kod) och att implementera förändringen i produktionsmiljön?
3. Återhämtningstid. Hur lång tid tar det i genomsnitt att återställa en applikation i en produktionsmiljö efter en incident, tjänstförsämring eller upptäckt av ett fel som påverkar applikationsanvändare?
4. Misslyckade ändringar. Hur många procent av driftsättningar i en produktmiljö leder till programförsämring eller incidenter och kräver eliminering av konsekvenser (återställning av ändringar, utveckling av en snabbkorrigering eller patch)?

DORA:s forskning har funnit ett samband mellan dessa mätetal och organisationsprestanda. Vi kontrollerar det också i vår studie.

Men för att vara säker på att de fyra nyckelmåtten kan påverka något måste du förstå – är de på något sätt relaterade till varandra? DORA svarade ja, med en varning: förhållandet mellan Change Failure Rate och de andra tre måtten är något svagare. Vi fick ungefär samma bild. Om leveranstid, distributionsfrekvens och återhämtningstid är korrelerade med varandra (vi etablerade denna korrelation genom Pearson-korrelationen och genom Chaddock-skalan), så finns det ingen så stark korrelation med misslyckade förändringar.

I princip brukar de flesta svarande svara att de har ett ganska litet antal incidenter som inträffar i produktionen. Även om vi kommer att se senare att det fortfarande finns en signifikant skillnad mellan grupper av svarande i andelen misslyckade ändringar, kan vi ännu inte använda detta mått för denna uppdelning.

Vi tillskriver detta det faktum att det (som det visade sig i processen för analys och kommunikation med några av våra kunder) finns en liten skillnad i uppfattning om vad som anses vara en incident. Om vi ​​lyckades återställa funktionaliteten i vår tjänst under det tekniska fönstret, kan detta betraktas som en incident? Förmodligen inte, eftersom vi fixade allt, vi är fantastiska. Kan det betraktas som en incident om vi var tvungna att rulla om vår ansökan 10 gånger i normalt, välbekant läge? Det verkar inte. Därför förblir frågan om förhållandet mellan misslyckade förändringar och andra mätvärden öppen. Vi kommer att förtydliga det ytterligare.

Det som är viktigt här är att vi hittade en signifikant korrelation mellan leveranstid, återhämtningstid och distributionsfrekvens. Därför tog vi dessa tre mätvärden för att ytterligare dela upp respondenterna i grupper baserade på produktivitet.

Hur mycket att hänga i gram?

Vi använde hierarkisk klusteranalys:

• Vi fördelar respondenterna över det n-dimensionella rummet, där koordinaten för varje respondent är deras svar på frågorna.
• Vi förklarar att varje respondent är ett litet kluster.
• Vi kombinerar de två klustren närmast varandra till ett större kluster.
• Vi hittar nästa klusterpar och kombinerar dem till ett större kluster.

Så här grupperar vi alla våra respondenter i det antal kluster vi behöver. Med hjälp av ett dendrogram (ett träd av kopplingar mellan kluster) ser vi avståndet mellan två angränsande kluster. Allt som återstår för oss är att sätta en viss gräns för avståndet mellan dessa kluster och säga: "Dessa två grupper är ganska särskiljbara från varandra eftersom avståndet mellan dem är gigantiskt."

Men det finns ett dolt problem här: vi har inga begränsningar för antalet kluster - vi kan få 2, 3, 4, 10 kluster. Och den första tanken var - varför inte dela upp alla våra respondenter i 4 grupper, som DORA gör. Men vi fann att skillnaderna mellan dessa grupper blir obetydliga, och vi kan inte vara säkra på att respondenten verkligen tillhör sin grupp och inte till den angränsande. Vi kan ännu inte dela upp den ryska marknaden i fyra grupper. Därför bestämde vi oss för tre profiler, mellan vilka det finns en statistiskt signifikant skillnad:

Därefter bestämde vi profilen efter kluster: vi tog medianerna för varje mätvärde för varje grupp och sammanställde en tabell med effektivitetsprofiler. I själva verket erhölls de resulterande prestationsprofilerna för den genomsnittliga deltagaren i varje grupp. Vi har identifierat tre effektivitetsprofiler: Låg, Medium, Hög:

Här har vi bekräftat vår hypotes att fyra nyckelmått är lämpliga för att bestämma prestationsprofilen, och de fungerar på både den västra och ryska marknaden. Det finns en skillnad mellan grupperna, och den är statistiskt säkerställd. Jag skulle vilja betona att det finns en signifikant skillnad i medelvärdet mellan prestationsprofilerna för måttet för misslyckade förändringar, även om vi initialt inte delade respondenterna med denna parameter.

Då uppstår frågan: hur använder man allt detta?

Hur man använder

Om vi ​​tar vilket lag som helst, 4 nyckeltal och tillämpar det på tabellen, kommer vi i 85% av fallen inte att få en fullständig matchning - det här är bara den genomsnittliga deltagaren och inte vad som är i verkligheten. Vi är alla (och alla lag) lite olika.

Vi kollade: vi tog våra respondenter och DORAs prestationsprofil, och tittade på hur många respondenter som motsvarade en eller annan profil. Vi fann att endast 16 % av de tillfrågade föll korrekt i en av profilerna. Alla de andra är utspridda någonstans däremellan:

Det gör att prestationsprofilen har en begränsad omfattning. För att få en första uppskattning av var du är kan du använda den här tabellen: "Åh, det ser ut som om vi är närmare Medium eller High!" Om du förstår vart du är på väg härnäst kan det räcka. Men om ditt mål är ständiga, ständiga förbättringar och du vill veta mer exakt var du ska utvecklas och vad du ska göra, så behövs ytterligare medel. Vi kallade dem miniräknare:

• DORA miniräknare
• Calculator Express 42* (under utveckling)
• Din egen utveckling (du kan skapa din egen interna kalkylator).

Vad behövs de till? Att förstå:

• Uppfyller teamet inom vår organisation våra standarder?
• Om inte, kan vi hjälpa henne – skynda på det inom ramen för den kompetens som vårt företag har?
• Kan vi i så fall göra ännu bättre?

Du kan också använda dem för att samla in statistik inom företaget:

• Vad har vi för lag?
• Dela in team i profiler;
• Se: Åh, de här teamen underpresterar (lite långsamma), men de är bra: de distribuerar varje dag, utan fel, deras ledtid är mindre än en timme.

Och då kan du få reda på att vi inom vårt företag har den nödvändiga kompetensen och verktygen för de team som fortfarande kommer till korta.

Eller, om du förstår att du trivs bra inom företaget, att du är bättre än många, då kan du titta lite bredare. Detta är just den ryska industrin: kan vi få den nödvändiga expertis inom den ryska industrin för att skynda på oss själva? Express 42-kalkylatorn hjälper här (den är under utveckling). Om du har vuxit ur den ryska marknaden, titta då på DORA miniräknare och till världsmarknaden.

Bra. Och om du är i Elitgruppen enligt DORA-kalkylatorn, vad ska du då göra? Det finns ingen bra lösning här. Med största sannolikhet ligger du i framkant av branschen, och ytterligare accelerations- och tillförlitlighetsförbättringar är möjliga genom intern FoU och utgifter för stora resurser.

Låt oss gå vidare till den sötaste delen - jämförelse.

jämförelse

Vi ville först jämföra rysk industri med västerländsk industri. Om vi ​​jämför direkt ser vi att vi har färre profiler, och de är lite mer sammanblandade med varandra, gränserna är lite mer suddiga:

Våra elitartister är gömda bland högpresterande, men de finns där - det här är eliten, enhörningar som har nått betydande höjder. I Ryssland är skillnaden mellan Elit- och High-profilerna ännu inte tillräckligt stor. Vi tror att denna uppdelning i framtiden kommer att ske på grund av en ökning av ingenjörskulturen, kvaliteten på implementeringen av ingenjörspraxis och expertis inom företag.

Om vi ​​går vidare till direkt jämförelse inom den ryska industrin ser vi att högprofilerade team är bättre i alla avseenden. Vi bekräftade också vår hypotes att det finns ett samband mellan dessa mätetal och organisatorisk effektivitet: Högprofilerade team är betydligt mer benägna att inte bara uppnå mål utan också överträffa dem.
Låt oss bli högprofilerade team och inte stanna där:

Men det här året är speciellt, och vi bestämde oss för att kolla hur företag lever i en pandemi: Högprofilerade team klarar sig betydligt bättre och mår bättre än branschgenomsnittet:

• Nya produkter släpptes 1,5-2 gånger oftare,
• Ökad tillförlitlighet och/eller prestanda för applikationsinfrastruktur 2 gånger oftare.

Det vill säga de kompetenser som de redan hade hjälpte dem att utvecklas snabbare, introducera nya produkter, modifiera befintliga produkter och därigenom erövra nya marknader och nya användare:

Vad mer har hjälpt våra team?

Ingenjörspraxis

Jag ska berätta om viktiga resultat för varje praxis som vi kontrollerade. Kanske något annat hjälpte teamen, men vi pratar om DevOps. Och inom DevOps ser vi skillnader mellan team med olika profiler.

Plattform som en tjänst

Vi hittade inget signifikant samband mellan plattformens ålder och lagprofilen: Plattformar dök upp ungefär samtidigt för både låga och höga lag. Men för de senare ger plattformen i genomsnitt fler tjänster och fler mjukvarugränssnitt för kontroll genom programkod. Och plattformsteam är mer benägna att hjälpa sina utvecklare och team att använda plattformen, mer benägna att lösa sina problem och incidenter relaterade till plattformen och utbilda andra team.

Infrastruktur som kod

Allt här är ganska standard. Vi hittade ett samband mellan automatisering av infrastrukturkod och hur mycket information som lagras i infrastrukturförrådet. Högprofilerade team lagrar mer information i arkiv: detta inkluderar infrastrukturkonfiguration, CI/CD-pipeline, miljöinställningar och byggparametrar. De lagrar denna information oftare, arbetar bättre med infrastrukturkod och har automatiserat fler processer och uppgifter för att arbeta med infrastrukturkod.

Intressant nog såg vi ingen signifikant skillnad i infrastrukturtester. Jag tillskriver detta det faktum att högprofilerade team generellt har mer testautomatisering. De kanske inte ska distraheras separat av infrastrukturtester, utan snarare räcker det med testerna de använder för att kontrollera applikationer, och tack vare dem kan de se vad och var de har gått sönder.

Integration och leverans

Det tråkigaste avsnittet, eftersom vi bekräftade: ju mer automatisering du har, desto bättre arbetar du med koden, desto mer sannolikt är det att du får bättre resultat.

Arkitektur

Vi ville se hur mikrotjänster påverkar prestandan. För att vara ärlig så gör de det inte, eftersom användningen av mikrotjänster inte är förknippad med en ökning av effektivitetsindikatorer. Mikrotjänster används av både hög- och lågprofilteam.

Men det som är viktigt är att för High-teams gör övergången till en mikrotjänstarkitektur att de självständigt kan utveckla sina tjänster och rulla ut dem. Om arkitekturen tillåter utvecklare att agera självständigt, utan att vänta på någon utanför teamet, är detta en nyckelkompetens för att öka hastigheten. Det är här mikrotjänsterna hjälper. Men helt enkelt deras genomförande spelar ingen stor roll.

Hur upptäckte vi allt detta?

Vi hade en ambitiös plan för att helt replikera DORA-metoden, men saknade resurser. Om DORA använder mycket sponsring och studien tar dem sex månader, genomförde vi vår studie på kort tid. Vi ville bygga en DevOps-modell som DORA gör, och det kommer vi att göra i framtiden. För närvarande begränsade vi oss till värmekartor:

Vi tittade på fördelningen av ingenjörspraxis mellan team i varje profil och fann att team med hög profil i genomsnitt använder ingenjörsmetoder oftare. Du kan läsa mer om allt detta i vår rapport.

För en förändring, låt oss byta från komplex statistik till enkel.

Vad mer har vi upptäckt?

Verktyg

Vi observerar att Linux OS-familjen använder flest kommandon. Men Windows är fortfarande i trenden - åtminstone en fjärdedel av våra svarande noterade användningen av en eller annan version av det. Marknaden verkar ha detta behov. Därför kan du utveckla dessa kompetenser och hålla presentationer på konferenser.

Bland orkestrarna är det ingen hemlighet att Kubernetes leder (52%). Nästa orkestrator i raden är Docker Swarm (cirka 12%). De mest populära CI-systemen är Jenkins och GitLab. Det mest populära konfigurationshanteringssystemet är Ansible, följt av vårt älskade Shell.

Bland molnvärdsleverantörer har Amazon för närvarande den ledande positionen. Andelen ryska moln ökar gradvis. Nästa år ska det bli intressant att se hur ryska molnleverantörer kommer att må och om deras marknadsandel kommer att öka. De finns, de kan användas, och det är bra:

Jag ger ordet till Igor, som kommer att ge lite mer statistik.

Spridning av praxis

Igor Kurochkin: Separat bad vi respondenterna att ange hur den övervägda ingenjörspraxisen är fördelad inom företaget. De flesta företag har ett blandat tillvägagångssätt som består av en annan uppsättning mönster, och pilotprojekt är mycket populära. Vi såg också en liten skillnad mellan profilerna. Representanter för den höga profilen använder oftare mönstret "Initiativ underifrån", när små team av specialister ändrar arbetsprocesser, verktyg och delar framgångsrika utvecklingar med andra team. På Medium är detta ett top-down-initiativ som berör hela företaget genom att skapa gemenskaper och spetsforskningscentra:

Agile och DevOps

Relationen mellan Agile och DevOps diskuteras ofta i branschen. Denna fråga tas också upp i State of Agile-rapporten för 2019/2020, så vi bestämde oss för att jämföra hur Agile- och DevOps-aktiviteter i företag är relaterade. Vi har upptäckt att DevOps utan Agile är sällsynt. För hälften av de tillfrågade började spridningen av Agile märkbart tidigare, och cirka 20 % observerade en samtidig start, och ett av tecknen på en låg profil kommer att vara frånvaron av Agile och DevOps praxis:

Teamtopologier

I slutet av förra året boken "Teamtopologier", som föreslår ett ramverk för att beskriva teamtopologier. Vi undrade om det skulle gälla ryska företag. Och vi ställde frågan: "Vilka mönster ser du?"

Infrastrukturteam observeras hos hälften av de svarande, samt separata utvecklings-, test- och driftteam. Individuella DevOps-team noterade 45 %, bland vilka höga representanter är vanligare. Därefter kommer tvärfunktionella team, som också är vanligare på High. Separata SRE-kommandon visas i profilerna Hög, Medium och finns sällan i profilen Låg:

DevQaOps-förhållande

Vi såg den här frågan på FaceBook från teamledaren för Skyeng-plattformsteamet - han var intresserad av förhållandet mellan utvecklare, testare och administratörer i företag. Vi frågade det och tittade på svaren med hänsyn till profilerna: representanter för High profile har ett mindre antal test- och driftingenjörer för varje utvecklare:

Planer för 2021 år

I sina planer för nästa år noterade respondenterna följande aktiviteter:

Här kan du se korsningen med DevOps Live 2020-konferensen. Vi har noggrant granskat programmet:

• Infrastruktur som produkt
• DevOps transformation
• Distribution av DevOps-praxis
• DevSecOps
• Caseklubbar och diskussioner

Men vårt föredrag kommer inte att ha tillräckligt med tid för att täcka alla ämnen. Bakom kulisserna:

• Plattform som en tjänst och som en produkt;
• Infrastruktur som kod, miljöer och moln;
• Kontinuerlig integration och leverans;
• Arkitektur;
• DevSecOps-mönster;
• Plattforms- och tvärfunktionella team.

Rapport Vår är omfattande, 50 sidor lång, och du kan titta på den mer i detalj.

Sammanfattningsvis

Vi hoppas att vår forskning och vår rapport kommer att inspirera dig att experimentera med nya tillvägagångssätt för utveckling, testning och drift, samt hjälpa dig att få koll, jämföra dig själv med andra i studien och identifiera områden där du kan förbättra dina egna tillvägagångssätt. .

Resultat av den första studien av tillståndet DevOps i Ryssland:

• Nyckelmått. Vi har funnit att nyckelmått (leveranstid, implementeringshastighet, återställningstid och förändringsfel) är lämpliga för att analysera effektiviteten av utvecklings-, testnings- och driftprocesser.
• Profiler Hög, Medium, Låg. Baserat på den insamlade informationen är det möjligt att identifiera statistiskt olika grupper: Hög, Medium, Låg, med särdrag baserade på mått, praxis, processer och verktyg. Representanter för High profile visar bättre resultat än Low. De är mer benägna att uppnå och överträffa sina mål.
• Indikatorer, pandemi och planer för 2021. En speciell indikator i år är hur företag hanterade pandemin. High presterade bättre, upplevde en ökad användaraktivitet och de främsta skälen till framgång var effektiva utvecklingsprocesser och en stark ingenjörskultur.
• DevOps praxis, verktyg och deras utveckling. Bolagens huvudplaner för nästa år inkluderar utvecklingen av DevOps-praxis och verktyg, införandet av DevSecOps-praxis och förändringar i organisationsstrukturen. Och den effektiva implementeringen och utvecklingen av DevOps-praxis genomförs genom pilotprojekt, bildandet av gemenskaper och kompetenscentra, initiativ på den övre och lägre nivån i företaget.

Vi kommer att vara glada att höra dina recensioner, berättelser, feedback. Vi tackar alla som deltagit i studien och ser fram emot ditt deltagande nästa år.

Källa: will.com