Staat van DevOps in Rusland 2020

Hoe de staat van iets te begrijpen?

U kunt afgaan op uw mening, gevormd uit diverse informatiebronnen, bijvoorbeeld publicaties op websites of ervaring. U kunt het vragen aan collega's, kennissen. Een andere optie is om te kijken naar de onderwerpen van de conferenties: de programmacommissie zijn actieve vertegenwoordigers van de industrie, dus we vertrouwen hen bij het kiezen van relevante onderwerpen. Een apart gebied is onderzoek en rapportages. Maar er is een probleem. Onderzoek naar de staat van DevOps wordt jaarlijks in de wereld uitgevoerd, rapporten worden gepubliceerd door buitenlandse bedrijven en er is bijna geen informatie over Russische DevOps.

Maar de dag is aangebroken dat zo'n onderzoek is uitgevoerd en vandaag zullen we het hebben over de resultaten. De staat van DevOps in Rusland werd gezamenlijk door de bedrijven bestudeerd "Expres 42"En"Ontico". Express 42 helpt technologiebedrijven bij het implementeren en ontwikkelen van DevOps-praktijken en -tools en was een van de eersten die sprak over DevOps in Rusland. De auteurs van de studie, Igor Kurochkin en Vitaly Khabarov, houden zich bezig met analyse en advisering bij Express 42, terwijl ze een technische achtergrond hebben door operatie en ervaring in verschillende bedrijven. Gedurende 8 jaar hebben collega's tientallen bedrijven en projecten bekeken - van startups tot ondernemingen - met verschillende problemen, evenals verschillende culturele en technische maturiteit.

In hun rapport vertelden Igor en Vitaly welke problemen er waren tijdens het onderzoeksproces, hoe ze deze hebben opgelost, hoe DevOps-onderzoek in principe wordt uitgevoerd en waarom Express 42 besloot zijn eigen onderzoek uit te voeren. Hun rapport is in te zien hier.

DevOps-onderzoek

Het gesprek werd gestart door Igor Kurochkin.

We vragen het publiek op DevOps-conferenties regelmatig: "Heb je het DevOps-statusrapport voor dit jaar gelezen?" Weinigen steken hun hand op en uit ons onderzoek bleek dat slechts een derde hen bestudeert. Als u dergelijke rapporten nog nooit hebt gezien, laten we dan meteen zeggen dat ze allemaal erg op elkaar lijken. Meestal zijn er zinnen als: "Vergeleken met vorig jaar ..."

Hier hebben we het eerste probleem, en daarna nog twee:

1. We hebben geen gegevens van vorig jaar. De staat van DevOps in Rusland interesseert niemand;
2. Methodologie. Het is niet duidelijk hoe je hypothesen moet testen, hoe je vragen moet opstellen, hoe je moet analyseren, resultaten moet vergelijken, verbanden moet vinden;
3. Terminologie. Alle rapporten zijn in het Engels, vertaling is vereist, een gemeenschappelijk DevOps-framework is nog niet uitgevonden en iedereen bedenkt zijn eigen.

Laten we eens kijken hoe DevOps-statusanalyses over de hele wereld zijn uitgevoerd.

geschiedenis

Sinds 2011 wordt DevOps-onderzoek uitgevoerd. Puppet, een ontwikkelaar van configuratiemanagementsystemen, was de eerste die ze uitvoerde. In die tijd was het een van de belangrijkste tools om de infrastructuur in de vorm van code te beschrijven. Tot 2013 waren deze onderzoeken gewoon gesloten enquêtes en geen openbare rapporten.

In 2013 verscheen IT Revolution, de uitgever van alle grote boeken over DevOps. Samen met Puppet bereidden ze de eerste State of DevOps-publicatie voor, waarin voor het eerst 4 key metrics verschenen. Het jaar daarop raakte ThoughtWorks betrokken, een adviesbureau dat bekend staat om zijn regelmatige technologische radars van praktijken en tools in de branche. En in 2015 kwam er een paragraaf met methodologie bij, en werd duidelijk hoe ze de analyse uitvoeren.

In 2016 publiceerden de auteurs van het onderzoek, nadat ze hun eigen bedrijf DORA (DevOps Research and Assessment) hadden opgericht, een jaarverslag. Het volgende jaar brachten DORA en Puppet hun laatste gezamenlijke rapport uit.

En toen begon er iets interessants:

In 2018 zijn de bedrijven gesplitst en zijn er twee onafhankelijke rapporten uitgebracht: een van Puppet, de tweede van DORA in samenwerking met Google. DORA is haar methodologie blijven gebruiken met belangrijke statistieken, prestatieprofielen en technische praktijken die van invloed zijn op belangrijke statistieken en bedrijfsbrede prestaties. En Puppet kwam met een eigen aanpak met een beschrijving van het proces en de evolutie van DevOps. Maar het verhaal sloeg niet aan, in 2019 verliet Puppet deze methodologie en bracht een nieuwe versie van de rapporten uit, waarin de belangrijkste praktijken werden opgesomd en hoe deze DevOps vanuit hun standpunt beïnvloeden. Toen gebeurde er nog een gebeurtenis: Google kocht DORA en samen brachten ze nog een rapport uit. Misschien heb je hem gezien.

Dit jaar werd het ingewikkeld. Het is bekend dat Puppet zijn eigen enquête heeft gelanceerd. Ze deden het een week eerder dan wij, en het is al afgelopen. We deden mee en keken in welke onderwerpen ze geïnteresseerd zijn. Nu doet Puppet zijn analyse en bereidt hij zich voor om het rapport te publiceren.

Maar er is nog steeds geen aankondiging van DORA en Google. In mei, toen het onderzoek gewoonlijk begon, kwam het bericht dat Nicole Forsgren, een van de oprichters van DORA, naar een ander bedrijf was verhuisd. Daarom gingen we ervan uit dat er dit jaar geen onderzoek en rapportage van DORA zou komen.

Hoe gaat het in Rusland?

We hebben geen DevOps-onderzoek gedaan. We spraken op conferenties, vertelden de bevindingen van anderen opnieuw, en Raiffeisenbank vertaalde "State of DevOps" voor 2019 (u kunt hun aankondiging vinden op Habré), hartelijk dank aan hen. En het is alles.

Daarom hebben we ons eigen onderzoek in Rusland uitgevoerd met behulp van DORA-methodologieën en -bevindingen. We gebruikten het rapport van collega's van de Raiffeisenbank voor ons onderzoek, onder meer voor synchronisatie van terminologie en vertaling. En brancherelevante vragen werden gehaald uit DORA-rapporten en de Puppet-enquête van dit jaar.

Onderzoeksproces

Het rapport is slechts het laatste deel. Het hele onderzoeksproces bestaat uit vier grote stappen:

Tijdens de voorbereidingsfase hebben we experts uit de industrie geïnterviewd en een lijst met hypothesen opgesteld. Op basis daarvan werden vragen opgesteld en werd een enquête gelanceerd voor heel augustus. Vervolgens hebben we het rapport zelf geanalyseerd en opgesteld. Voor DORA duurt dit proces 6 maanden. We hebben elkaar binnen 3 maanden ontmoet en nu begrijpen we dat we amper tijd hadden: alleen door de analyse uit te voeren, begrijp je welke vragen je moet stellen.

Deelnemers

Alle buitenlandse reportages beginnen met een portret van de deelnemers, en de meesten komen niet uit Rusland. Het percentage Russische respondenten schommelt van jaar tot jaar tussen 5 en 1%, en hieruit kunnen geen conclusies worden getrokken.

Kaart uit het rapport Accelerate State of DevOps 2019:

In ons onderzoek zijn we erin geslaagd om 889 mensen te interviewen - dat is best veel (DORA peilt jaarlijks ongeveer duizend mensen in haar rapporten) en hier hebben we het doel bereikt:

Toegegeven, niet al onze deelnemers bereikten het einde: het voltooiingspercentage bleek iets minder dan de helft te zijn. Maar zelfs dit was voldoende om een ​​representatief monster te verkrijgen en een analyse uit te voeren. DORA vermeldt geen vulpercentages in haar rapporten, dus er is hier geen vergelijking.

Industrieën en functies

Onze respondenten vertegenwoordigen een tiental branches. Half werk in de informatietechnologie. Dit wordt gevolgd door financiële diensten, handel, telecommunicatie en andere. Onder de functies bevinden zich specialisten (ontwikkelaar, tester, operationeel ingenieur) en managementpersoneel (hoofden van teams, groepen, gebieden, directeuren):

Een op de twee werkt voor een middelgroot bedrijf. Elke derde persoon werkt in grote bedrijven. De meeste werken in teams van maximaal 9 personen. Afzonderlijk hebben we gevraagd naar de belangrijkste activiteiten, en de meerderheid houdt op de een of andere manier verband met de operatie en ongeveer 40% houdt zich bezig met ontwikkeling:

Dus verzamelden we informatie voor vergelijking en analyse van vertegenwoordigers van verschillende industrieën, bedrijven, teams. Mijn collega Vitaly Khabarov zal vertellen over de analyse.

Analyse en vergelijking

Vitaly Khabarov: Hartelijk dank aan alle deelnemers die onze enquête hebben ingevuld, vragenlijsten hebben ingevuld en ons gegevens hebben verstrekt voor verdere analyse en het testen van onze hypothesen. En dankzij onze klanten en klanten hebben we een schat aan ervaring die heeft geholpen bij het identificeren van zorgen uit de sector en het formuleren van de hypothesen die we in ons onderzoek hebben getest.

Helaas kun je niet zomaar een lijst met vragen aan de ene kant en gegevens aan de andere kant nemen, ze op de een of andere manier vergelijken, zeggen: "Ja, alles werkt zo, we hadden gelijk" en verspreiden. Nee, we hebben methodologie en statistische methoden nodig om er zeker van te zijn dat we ons niet vergissen en dat onze conclusies betrouwbaar zijn. Dan kunnen we ons verdere werk bouwen op basis van deze gegevens:

Belangrijkste statistieken

We hebben de DORA-methodiek als uitgangspunt genomen, die ze uitvoerig hebben beschreven in het boek “Accelerate State of DevOps”. We hebben gecontroleerd of de belangrijkste statistieken geschikt zijn voor de Russische markt, of ze op dezelfde manier kunnen worden gebruikt als DORA gebruikt om de vraag te beantwoorden: "Hoe komt de industrie in Rusland overeen met de buitenlandse industrie?"

Belangrijkste statistieken:

1. Implementatie frequentie. Hoe vaak wordt een nieuwe versie van de applicatie geïmplementeerd in de productieomgeving (geplande wijzigingen, exclusief hotfixes en incidentrespons)?
2. Aflevertijd. Wat is de gemiddelde tijd tussen het doorvoeren van een wijziging (functionaliteit als code schrijven) en het implementeren van de wijziging in de productieomgeving?
3. Hersteltijd. Hoe lang duurt het gemiddeld om een ​​applicatie te herstellen naar een productieomgeving na een incident, servicedegradatie of ontdekking van een bug waar applicatiegebruikers last van hebben?
4. Mislukte veranderingen. Welk percentage van de implementaties in de productieomgeving leidt tot degradatie van applicaties of incidenten en vereist herstel (terugdraaien van wijzigingen, ontwikkeling van een hotfix of patch)?

DORA heeft in haar onderzoek een verband gevonden tussen deze statistieken en de prestaties van de organisatie. We testen het ook in ons onderzoek.

Maar om er zeker van te zijn dat de vier belangrijkste statistieken iets kunnen beïnvloeden, moet u begrijpen: zijn ze op de een of andere manier met elkaar verbonden? DORA antwoordde bevestigend met één voorbehoud: de relatie tussen mislukte wijzigingen (Change Failure Rate) en drie andere metrics is iets zwakker. We hebben ongeveer hetzelfde beeld. Als levertijd, implementatiefrequentie en hersteltijd met elkaar correleren (we hebben deze correlatie vastgesteld via de Pearson-correlatie en via de Chaddock-schaal), dan is er niet zo'n sterke correlatie met mislukte veranderingen.

In principe antwoorden de meeste respondenten dat ze een vrij klein aantal incidenten in de productie hebben. Hoewel we later zullen zien dat er nog steeds een significant verschil is tussen de groepen respondenten in termen van mislukte veranderingen, kunnen we deze maatstaf nog niet gebruiken voor deze verdeling.

We schrijven dit toe aan het feit dat (zoals bleek tijdens de analyse en communicatie met enkele van onze klanten) er een klein verschil is in de perceptie van wat als een incident wordt beschouwd. Als we erin zijn geslaagd om de prestaties van onze service tijdens het technische venster te herstellen, kan dit dan als een incident worden beschouwd? Waarschijnlijk niet, want we hebben alles opgelost, we zijn geweldig. Kunnen we het als een incident beschouwen als we onze applicatie 10 keer opnieuw moeten rollen in een voor ons normale, vertrouwde modus? Het lijkt van niet. Daarom blijft de vraag naar de relatie tussen mislukte wijzigingen en andere statistieken open. We zullen het verder verfijnen.

Belangrijk hierbij is dat we een significante correlatie vonden tussen levertijden, hersteltijd en inzetfrequentie. Daarom hebben we deze drie maatstaven genomen om de respondenten verder in te delen in prestatiegroepen.

Hoeveel te hangen in grammen?

We gebruikten hiërarchische clusteranalyse:

• We verdelen respondenten over een n-dimensionale ruimte, waar de coördinaat van elke respondent hun antwoorden op vragen is.
• Elke respondent wordt tot een klein cluster verklaard.
• We combineren de twee clusters die het dichtst bij elkaar liggen tot één groter cluster.
• We vinden het volgende paar clusters en combineren ze tot een groter cluster.

Zo groeperen we al onze respondenten in het aantal clusters dat we nodig hebben. Met behulp van een dendrogram (een boom van verbindingen tussen clusters) zien we de afstand tussen twee naburige clusters. Het enige dat ons rest is een bepaalde afstandslimiet tussen deze clusters in te stellen en te zeggen: "Deze twee groepen zijn behoorlijk van elkaar te onderscheiden omdat de afstand tussen hen gigantisch is."

Maar er is hier een verborgen probleem: we hebben geen beperking op het aantal clusters - we kunnen 2, 3, 4, 10 clusters krijgen. En het eerste idee was: waarom verdelen we niet al onze respondenten in 4 groepen, zoals DORA doet. Maar we ontdekten dat de verschillen tussen deze groepen onbeduidend worden, en we kunnen er niet zeker van zijn dat de respondent echt tot zijn groep behoort, en niet tot de buurgroep. We kunnen de Russische markt nog niet in vier groepen verdelen. Daarom zijn we uitgekomen op drie profielen waartussen er een statistisch significant verschil is:

Vervolgens bepaalden we het profiel per cluster: we namen de mediaan voor elke metriek voor elke groep en stelden een tabel met prestatieprofielen samen. In feite kregen we de prestatieprofielen van de gemiddelde deelnemer in elke groep. We hebben drie efficiëntieprofielen geïdentificeerd: Laag, Gemiddeld, Hoog:

Hier hebben we onze hypothese bevestigd dat 4 sleutelstatistieken geschikt zijn om het prestatieprofiel te bepalen, en ze werken zowel op de westerse als op de Russische markt. Er is een verschil tussen de groepen en het is statistisch significant. Ik benadruk dat er een significant verschil is tussen de prestatieprofielen in termen van de metriek van mislukte veranderingen in termen van het gemiddelde, ook al hebben we de respondenten aanvankelijk niet gedeeld door deze parameter.

Dan rijst de vraag: hoe dit allemaal te gebruiken?

Hoe te gebruiken

Als we een team, 4 sleutelstatistieken nemen en deze op de tafel toepassen, dan krijgen we in 85% van de gevallen geen volledige match - dit is slechts een gemiddelde deelnemer en niet wat in werkelijkheid is. We zijn allemaal (en elk team) net even anders.

We controleerden: we namen onze respondenten en het DORA-prestatieprofiel en keken hoeveel respondenten in dit of dat profiel pasten. We stelden vast dat slechts 16% van de respondenten zeker in een van de profielen viel. De rest is ergens tussenin verspreid:

Dit betekent dat het doelmatigheidsprofiel een beperkte reikwijdte heeft. Om te begrijpen waar u zich in de eerste benadering bevindt, kunt u deze tabel gebruiken: "Oh, het lijkt erop dat we dichter bij Medium of High zitten!" Als u begrijpt waar u heen moet, kan dit voldoende zijn. Maar als je doel constante, continue verbetering is, en je wilt precies weten waar je je moet ontwikkelen en wat je moet doen, dan zijn er extra middelen nodig. We noemden ze rekenmachines:

• DORA-rekenmachine
• Rekenmachine Express 42* (in ontwikkeling)
• Eigen ontwikkeling (u kunt uw eigen interne rekenmachine maken).

Waar zijn ze voor nodig? Begrijpen:

• Voldoet het team binnen onze organisatie aan onze normen?
• Zo niet, kunnen we het dan helpen, versnellen binnen het kader van de expertise waarover ons bedrijf beschikt?
• Zo ja, kunnen we het nog beter doen?

U kunt ze ook gebruiken om statistieken te verzamelen binnen het bedrijf:

• Welke teams hebben we?
• Verdeel teams in profielen;
• Zie: Oh, deze commando's presteren ondermaats (ze trekken niet een beetje uit), maar deze zijn cool: ze worden elke dag ingezet, zonder fouten, ze hebben een doorlooptijd van minder dan een uur.

En dan kom je erachter dat er binnen ons bedrijf de nodige expertise en tools zijn voor die teams die nog niet op peil zijn.

Of, als je begrijpt dat je je goed voelt binnen het bedrijf, je bent beter dan velen, dan kun je wat breder kijken. Dit is gewoon de Russische industrie: kunnen we de nodige expertise in de Russische industrie krijgen om onszelf te versnellen? De Express 42-calculator helpt hier (deze is in ontwikkeling). Als je de Russische markt bent ontgroeid, kijk dan naar DORA-rekenmachine en naar de wereldmarkt.

Prima. En als je in de Elit-groep op de DORA-calculator zit, wat moet je dan doen? Er is hier geen goede oplossing. U bevindt zich hoogstwaarschijnlijk in de voorhoede van de branche en verdere versnelling en betrouwbaarheid is mogelijk door interne R&D en meer middelen uit te geven.

Laten we verder gaan met de zoetste - vergelijking.

Сравнение

We wilden in eerste instantie de Russische industrie vergelijken met de westerse industrie. Als we direct vergelijken, zien we dat we minder profielen hebben, en ze zijn wat meer met elkaar vermengd, de grenzen zijn wat vager:

Onze Elite-artiesten zijn verborgen tussen de High-performers, maar ze zijn er - dit zijn de elite, eenhoorns die aanzienlijke hoogten hebben bereikt. In Rusland is het verschil tussen het Elite-profiel en het High-profiel nog niet groot genoeg. We denken dat deze scheiding in de toekomst zal plaatsvinden door een toename van de engineeringcultuur, de kwaliteit van implementatie van engineeringpraktijken en expertise binnen bedrijven.

Als we verder gaan met een directe vergelijking binnen de Russische industrie, kunnen we zien dat de teams met een hoog profiel in alle opzichten beter zijn. We bevestigden ook onze hypothese dat er een verband bestaat tussen deze statistieken en de prestaties van de organisatie: teams met een hoog profiel hebben veel meer kans om niet alleen doelen te bereiken, maar ze ook te overtreffen.
Laten we spraakmakende teams worden en daar niet stoppen:

Maar dit jaar is speciaal en we hebben besloten om te kijken hoe bedrijven het doen tijdens een pandemie: spraakmakende teams doen het veel beter en voelen zich beter dan het branchegemiddelde:

• 1,5-2 keer meer kans om nieuwe producten uit te brengen,
• 2 keer meer kans om de betrouwbaarheid en/of prestaties van de applicatie-infrastructuur te verbeteren.

Dat wil zeggen, de competenties die ze al hadden, hielpen hen sneller te ontwikkelen, nieuwe producten te lanceren, bestaande producten aan te passen en zo nieuwe markten en nieuwe gebruikers te veroveren:

Wat heeft onze teams nog meer geholpen?

Technische praktijken

Ik zal u vertellen over de significante bevindingen voor elke praktijk die we hebben getest. Misschien heeft iets anders de teams geholpen, maar we hebben het over DevOps. En binnen DevOps zien we een verschil tussen teams met verschillende profielen.

Platform-as-a-Service

We vonden geen significante relatie tussen platformleeftijd en teamprofiel: platforms verschenen ongeveer tegelijkertijd voor zowel Low-teams als High-teams. Maar voor dat laatste biedt het platform gemiddeld meer diensten en meer programmeerinterfaces voor besturing via programmacode. En platformteams zijn eerder geneigd hun ontwikkelaars en teams te helpen het platform te gebruiken, hun problemen en platformgerelateerde incidenten vaker op te lossen en andere teams op te leiden.

Infrastructuur als code

Alles is hier vrij standaard. We hebben een verband gevonden tussen de automatisering van het werk van de infrastructuurcode en de hoeveelheid informatie die is opgeslagen in de infrastructuurrepository. De High profile-commando's slaan meer informatie op in de repositories: dit is de infrastructuurconfiguratie, CI/CD-pijplijn, omgevingsinstellingen en buildparameters. Ze slaan deze informatie vaker op, werken beter met infrastructuurcode en automatiseren meer processen en taken voor het werken met infrastructuurcode.

Interessant genoeg zagen we geen significant verschil in infrastructuurtests. Ik wijt dit toe aan het feit dat spraakmakende teams over het algemeen meer testautomatisering hebben. Misschien moeten ze zich niet apart laten afleiden door infrastructuurtests, maar eerder door die tests waarmee ze applicaties controleren, en dankzij hen zien ze al wat en waar ze kapot zijn gegaan.

Integratie en levering

Het saaiste gedeelte, omdat we hebben bevestigd dat hoe meer automatisering je hebt, hoe beter je met de code werkt, hoe groter de kans dat je betere resultaten krijgt.

Architectuur

We wilden zien hoe microservices de prestaties beïnvloeden. In werkelijkheid doen ze dat niet, aangezien het gebruik van microservices niet gepaard gaat met een toename van prestatie-indicatoren. Microservices worden gebruikt voor zowel High profile-opdrachten als Low profile-opdrachten.

Maar wat belangrijk is, is dat de overgang naar een microservice-architectuur voor High-teams hen in staat stelt om hun diensten zelfstandig te ontwikkelen en uit te rollen. Als de architectuur ontwikkelaars in staat stelt autonoom te handelen, zonder te wachten op iemand van buiten het team, dan is dit een sleutelcompetentie om de snelheid te verhogen. In dit geval helpen microservices. En alleen hun implementatie speelt geen grote rol.

Hoe hebben we dit allemaal ontdekt?

We hadden een ambitieus plan om de DORA-methodiek volledig te repliceren, maar hadden niet de middelen. Als DORA veel gebruik maakt van sponsoring en hun onderzoek duurt een half jaar, dan hebben wij ons onderzoek in korte tijd gedaan. We wilden een DevOps-model bouwen zoals DORA dat doet, en dat zullen we in de toekomst doen. Tot nu toe hebben we ons beperkt tot heatmaps:

We hebben gekeken naar de verdeling van technische praktijken over teams in elk profiel en ontdekten dat teams met een hoog profiel gemiddeld vaker technische praktijken gebruikten. Meer hierover leest u in onze rapport.

Laten we voor de verandering eens overschakelen van complexe statistieken naar eenvoudige.

Wat hebben we nog meer ontdekt?

Gereedschap

We zien dat de meeste commando's worden gebruikt door het besturingssysteem van de Linux-familie. Maar Windows is nog steeds in de trend - minstens een kwart van onze respondenten merkte het gebruik van een van zijn versies op. Het lijkt erop dat de markt deze behoefte heeft. Daarom kun je deze competenties ontwikkelen en presentaties geven op congressen.

Bij de orchestrators is het voor niemand een geheim, Kubernetes gaat aan kop (52%). De volgende orkestrator in de rij is Docker Swarm (ongeveer 12%). De meest populaire CI-systemen zijn Jenkins en GitLab. Het populairste configuratiebeheersysteem is Ansible, gevolgd door ons geliefde Shell.

Amazon is momenteel de toonaangevende aanbieder van cloudhosting. Het aandeel Russische wolken neemt geleidelijk toe. Volgend jaar wordt het interessant om te zien hoe Russische cloudproviders zich zullen voelen, of hun marktaandeel zal toenemen. Ze zijn, ze kunnen worden gebruikt, en dat is goed:

Ik geef het woord aan Igor, die wat meer statistieken zal geven.

Verspreiding van praktijken

Igor Kurochkin: Afzonderlijk vroegen we de respondenten om aan te geven hoe de overwogen technische praktijken in het bedrijf zijn verdeeld. In de meeste bedrijven is er een gemengde aanpak, bestaande uit verschillende patronen, en pilotprojecten zijn erg populair. We zagen ook een klein verschil tussen de profielen. Vertegenwoordigers van de High profile gebruiken vaker het patroon "Initiatief van onderaf", wanneer kleine teams van specialisten werkprocessen en tools veranderen en succesvolle werkwijzen delen met andere teams. Bij Medium is dit een top-down initiatief dat het hele bedrijf raakt door het creëren van communities en centres of excellence:

Agile en DevOps

De vraag naar de verbinding tussen Agile en DevOps wordt vaak besproken in de branche. Dit probleem komt ook aan de orde in het State of Agile Report voor 2019/2020, dus hebben we besloten om te vergelijken hoe Agile- en DevOps-activiteiten in bedrijven met elkaar verbonden zijn. We ontdekten dat DevOps zonder Agile zeldzaam is. Voor de helft van de respondenten begon de verspreiding van Agile veel eerder en ongeveer 20% zag de gelijktijdige start, en een van de tekenen van een laag profiel zal de afwezigheid van Agile- en DevOps-praktijken zijn:

Opdrachttopologieën

Eind vorig jaar verscheen het boek "Teamtopologieën”, dat een raamwerk voorstelt voor het beschrijven van commandotopologieën. Het werd voor ons interessant of het van toepassing is op Russische bedrijven. En we stelden de vraag: “Welke patronen vind je?”.

Bij de helft van de respondenten worden infrastructuurteams geobserveerd, evenals aparte teams voor ontwikkeling, testen en beheer. Afzonderlijke DevOps-teams noteerden 45%, waaronder vertegenwoordigers van High vaker voorkomen. Vervolgens komen cross-functionele teams, die ook vaker voorkomen bij High. Afzonderlijke SRE-opdrachten verschijnen in de profielen Hoog en Gemiddeld en worden zelden gezien in het profiel Laag:

DevQaOps-verhouding

We zagen deze vraag op FaceBook van de teamleider van het Skyeng-platformteam - hij was geïnteresseerd in de verhouding tussen ontwikkelaars, testers en beheerders in bedrijven. We vroegen het en keken naar de antwoorden op basis van profielen: Vertegenwoordigers met een hoog profiel hebben minder test- en operationele ingenieurs voor elke ontwikkelaar:

Plannen voor 2021-jaar

In de plannen voor het komende jaar noteren de respondenten de volgende activiteiten:

Hier zie je de kruising met de DevOps Live 2020-conferentie We hebben het programma zorgvuldig bekeken:

• Infrastructuur als product
• DevOps-transformatie
• Distributie van DevOps-praktijken
• DevSecOps
• Casusclubs en discussies

Maar de tijd van onze presentatie is niet genoeg om alle onderwerpen te behandelen. Achter de schermen:

• Platform als dienst en als product;
• Infrastructuur als code, omgevingen en clouds;
• Continue integratie en levering;
• Architectuur;
• DevSecOps-patronen;
• Platform- en multifunctionele teams.

Verslag we hebben een omvangrijke, 50 pagina's, en je kunt het in meer detail zien.

Opsomming

We hopen dat ons onderzoek en rapport u zullen inspireren om te experimenteren met nieuwe benaderingen van ontwikkeling, testen en operaties, en u zullen helpen navigeren, uzelf vergelijken met andere deelnemers aan het onderzoek en gebieden identificeren waar u uw eigen benaderingen kunt verbeteren.

Resultaten van het eerste onderzoek naar de staat van DevOps in Rusland:

• Belangrijkste statistieken. We hebben ontdekt dat belangrijke statistieken (levertijd, implementatiefrequentie, hersteltijd en mislukte wijzigingen) geschikt zijn voor het analyseren van de effectiviteit van ontwikkelings-, test- en operationele processen.
• Profielen Hoog, Gemiddeld, Laag. Op basis van de verzamelde gegevens kunnen we statistisch verschillende groepen onderscheiden van Hoog, Gemiddeld, Laag met onderscheidende kenmerken in termen van statistieken, praktijken, processen en hulpmiddelen. Vertegenwoordigers van het High profiel laten betere resultaten zien dan Low. Ze hebben meer kans om hun doelen te bereiken en te overtreffen.
• Indicatoren, pandemie en plannen voor 2021. Een bijzondere graadmeter dit jaar is hoe bedrijven met de pandemie omgingen. De hoge vertegenwoordigers deden het beter, ervoeren een grotere gebruikersbetrokkenheid en de belangrijkste redenen voor succes waren efficiënte ontwikkelingsprocessen en een sterke ingenieurscultuur.
• DevOps-praktijken, tools en hun ontwikkeling. De belangrijkste plannen van bedrijven voor het komende jaar zijn onder meer de ontwikkeling van DevOps-praktijken en -tools, de introductie van DevSecOps-praktijken en veranderingen in de organisatiestructuur. En de effectieve implementatie en ontwikkeling van DevOps-praktijken wordt uitgevoerd met behulp van proefprojecten, de vorming van communities en centres of excellence, initiatieven op de hogere en lagere niveaus van het bedrijf.

We horen graag uw feedback, verhalen, feedback. We danken iedereen die heeft deelgenomen aan het onderzoek en kijken uit naar uw deelname volgend jaar.

Bron: www.habr.com