Steat fan DevOps yn Ruslân 2020

Hoe te begripen de steat fan wat?

Jo kinne fertrouwe op jo miening, foarme út ferskate boarnen fan ynformaasje, bygelyks, publikaasjes op websiden of ûnderfining. Jo kinne freegje kollega's, kunde. In oare opsje is om te sjen nei de ûnderwerpen fan 'e konferinsjes: de programmakommisje binne aktive fertsjintwurdigers fan' e yndustry, dus wy fertrouwe har by it kiezen fan relevante ûnderwerpen. In apart gebiet is ûndersyk en rapporten. Mar der is in probleem. Undersyk nei de steat fan DevOps wurdt jierliks ​​yn 'e wrâld útfierd, rapporten wurde publisearre troch bûtenlânske bedriuwen, en d'r is hast gjin ynformaasje oer Russyske DevOps.

Mar de dei is kommen dat sa'n stúdzje waard útfierd, en hjoed sille wy prate oer de resultaten. De steat fan DevOps yn Ruslân waard mienskiplik studearre troch de bedriuwen "Express 42"En"Ontico". Express 42 helpt technologybedriuwen mei it ymplemintearjen en ûntwikkeljen fan DevOps-praktiken en ark en wie ien fan 'e earsten dy't praat oer DevOps yn Ruslân. De skriuwers fan 'e stúdzje, Igor Kurochkin en Vitaly Khabarov, binne dwaande mei analyze en konsultaasje by Express 42, wylst se in technyske eftergrûn hawwe fan operaasje en ûnderfining yn ferskate bedriuwen. Foar 8 jier hawwe kollega's sjoen nei tsientallen bedriuwen en projekten - fan startups oant bedriuwen - mei ferskate problemen, lykas ek ferskate kulturele en technyske maturiteit.

Yn har rapport fertelden Igor en Vitaly hokker problemen yn it proses fan ûndersyk wiene, hoe't se se hawwe oplost, lykas hoe't DevOps-ûndersyk yn prinsipe útfierd wurdt en wêrom Express 42 besleat har eigen te fieren. Har rapport is te besjen hjir.

DevOps Undersyk

It petear waard begûn troch Igor Kurochkin.

Wy freegje it publyk geregeld by DevOps-konferinsjes, "Hasto it DevOps-statusrapport foar dit jier lêzen?" In pear stekke har hannen op, en ús stúdzje liet sjen dat mar in tredde har studearre. As jo ​​sokke rapporten noch noait sjoen hawwe, lit ús daliks sizze dat se allegear heul gelyk binne. Meastentiids binne der útdrukkingen lykas: "Yn ferliking mei ferline jier ..."

Hjir hawwe wy it earste probleem, en dêrnei noch twa:

1. Wy hawwe gjin gegevens foar ferline jier. De steat fan DevOps yn Ruslân is foar gjinien fan belang;
2. Metoade. It is net dúdlik hoe te testen hypotezen, hoe te bouwen fragen, hoe te analysearjen, fergelykje resultaten, fine ferbinings;
3. Terminology. Alle rapporten binne yn it Ingelsk, oersetting is ferplicht, in mienskiplik DevOps-ramt is noch net útfûn en elkenien komt mei har eigen.

Litte wy ris sjen hoe't DevOps-steatanalyses rûn de wrâld binne dien.

Histoaryske eftergrûn

DevOps-ûndersyk wurdt útfierd sûnt 2011. Puppet, in ûntwikkelder fan systemen foar konfiguraasjebehear, wie de earste dy't se útfierde. Op dat stuit wie it ien fan 'e wichtichste ark foar it beskriuwen fan' e ynfrastruktuer yn 'e foarm fan koade. Oant 2013 wiene dizze stúdzjes gewoan sletten enkêtes en gjin iepenbiere rapporten.

Yn 2013 ferskynde IT Revolution, de útjouwer fan alle grutte boeken oer DevOps. Tegearre mei Puppet hawwe se de earste State of DevOps-publikaasje taret, wêr't 4 wichtige metriken foar it earst ferskynden. It folgjende jier rekke ThoughtWorks, in konsultaasjeburo bekend om har reguliere technologyradars oer yndustrypraktiken en ark, belutsen. En yn 2015 waard in seksje mei metodyk tafoege, en it waard dúdlik hoe't se de analyze útfiere.

Yn 2016 publisearren de auteurs fan 'e stúdzje, nei't se har eigen bedriuw DORA (DevOps Research and Assessment) makke hawwe, in jierferslach publisearre. It folgjende jier brochten DORA en Puppet har lêste mienskiplike rapport út.

En doe begûn wat nijsgjirrichs:

Yn 2018 splitten de bedriuwen en waarden twa ûnôfhinklike rapporten frijlitten: ien fan Puppet, de twadde fan DORA yn gearhing mei Google. DORA is trochgien mei it benutten fan har metodyk mei wichtige metriken, prestaasjesprofilen en yngenieurpraktiken dy't ynfloed hawwe op wichtige metriken en bedriuwsbrede prestaasjes. En Puppet bea in eigen oanpak mei in beskriuwing fan it proses en de evolúsje fan DevOps. Mar it ferhaal naam gjin woartel, yn 2019 ferliet Puppet dizze metodyk en publisearre in nije ferzje fan 'e rapporten, dy't de wichtichste praktiken opnoemde en hoe't se DevOps beynfloedzje út har eachpunt. Doe barde der in oar barren: Google kocht DORA, en tegearre publisearren se in oar rapport. Jo hawwe him miskien sjoen.

Dit jier waard de dingen yngewikkeld. It is bekend dat Puppet in eigen enkête hat lansearre. Se diene it in wike earder as ús, en it is al einige. Wy hawwe der oan meidien en sjoen yn hokker ûnderwerpen se ynteressearre binne. No docht Puppet syn analyze en taret him op om it rapport te publisearjen.

Mar d'r is noch gjin oankundiging fan DORA en Google. Yn maaie, doe't de enkête gewoanlik begon, kaam ynformaasje dat Nicole Forsgren, ien fan 'e oprjochters fan DORA, nei in oar bedriuw ferhuze wie. Dêrom binne wy ​​der fan útgien dat der dit jier gjin ûndersyk en rapport komme soe fan DORA.

Hoe binne dingen yn Ruslân?

Wy hawwe gjin DevOps-ûndersyk dien. Wy sprieken op konferinsjes, fertelden de befinings fan oare minsken, en Raiffeisenbank hat "State of DevOps" oerset foar 2019 (jo kinne har oankundiging fine op Habré), in protte tank oan har. En it is alles.

Dêrom hawwe wy ús eigen ûndersyk útfierd yn Ruslân mei DORA-metodologyen en befinings. Wy hawwe it rapport fan kollega's fan Raiffeisenbank brûkt foar ús ûndersyk, ynklusyf foar syngronisaasje fan terminology en oersetting. En yndustry-relevante fragen waarden nommen út DORA rapporten en dit jier Puppet fragelist.

Undersyksproses

It rapport is mar it lêste diel. It hiele ûndersyksproses bestiet út fjouwer grutte stappen:

Tidens de tarieding faze, wy ynterviewd yndustry saakkundigen en taret in list fan hypotezen. Op basis dêrfan binne fragen gearstald en is in enkête úteinset foar de hiele augustus. Dêrnei hawwe wy it rapport sels analysearre en makke. Foar DORA duorret dit proses 6 moannen. Wy troffen binnen 3 moannen, en no begripe wy dat wy amper genôch tiid hiene: allinich troch it útfieren fan 'e analyze begripe jo hokker fragen jo moatte stelle.

Leden

Alle bûtenlânske rapporten begjinne mei in portret fan 'e dielnimmers, en de measten fan harren binne net út Ruslân. It persintaazje Russyske respondinten fluktuearret fan jier nei jier tusken de 5 en 1%, en dit lit gjin konklúzjes lûke.

Kaart fan it rapport Accelerate State of DevOps 2019:

Yn ús stúdzje slagge it ús om 889 minsken te ynterviewe - dit is nochal in soad (DORA stelt jierliks ​​​​oer tûzen minsken yn har rapporten) en hjir hawwe wy it doel berikt:

Wier, net al ús dielnimmers berikten it ein: it persintaazje foltôging blykte wat minder as de helte te wêzen. Mar ek dit wie genôch om in represintative stekproef te krijen en in analyze te fieren. DORA iepenbiere gjin fill persintaazjes yn har rapporten, dus d'r is hjir gjin fergeliking.

Industries en posysjes

Us respondinten fertsjintwurdigje in tsiental yndustry. De helte wurket yn ynformaasjetechnology. Dit wurdt folge troch finansjele tsjinsten, hannel, telekommunikaasje en oaren. Under de posysjes binne spesjalisten (ûntwikkelder, tester, operaasje-yngenieur) en managementpersoniel (haden fan teams, groepen, gebieten, direkteuren):

Ien op de twa wurket foar in middelgrutte bedriuw. Elke tredde persoan wurket yn grutte bedriuwen. De measten wurkje yn teams fan maksimaal 9 minsken. Apart fregen wy oer de wichtichste aktiviteiten, en de mearderheid is op ien of oare manier relatearre oan 'e operaasje, en sawat 40% is dwaande mei ûntwikkeling:

Dat wy sammele ynformaasje foar fergeliking en analyze fan fertsjintwurdigers fan ferskate yndustry, bedriuwen, teams. Myn kollega Vitaly Khabarov sil fertelle oer de analyze.

Analyse en ferliking

Vitaly Khabarov: Tige tank oan alle dielnimmers dy't ús enkête foltôge, fragelisten ynfolje en ús gegevens hawwe levere foar fierdere analyze en testen fan ús hypotezen. En tank oan ús kliïnten en klanten, wy hawwe in skat oan ûnderfining dy't hat holpen identifisearje yndustry soargen en formulearje de hypotezen dy't wy testen yn ús ûndersyk.

Spitigernôch kinne jo net gewoan in list fan fragen oan 'e iene kant en gegevens oan' e oare nimme, se op ien of oare manier fergelykje, sizze: "Ja, alles wurket sa, wy hiene gelyk" en fersprieden. Nee, metodyk en statistyske metoaden binne nedich om der wis fan te wêzen dat wy net ferkeard binne en ús konklúzjes betrouber binne. Dan kinne wy ​​ús fierdere wurk bouwe op basis fan dizze gegevens:

Key Metrics

Wy namen de DORA-metodology as basis, dy't se yn detail beskreaun hawwe yn it boek "Accelerate State of DevOps". Wy kontrolearren oft de kaai metriken binne geskikt foar de Russyske merk, oft se kinne brûkt wurde op deselde wize as DORA brûkt om te beäntwurdzjen de fraach: "Hoe komt de yndustry yn Ruslân oerien mei de bûtenlânske yndustry?"

Key metriken:

1. Ynset frekwinsje. Hoe faak wurdt in nije ferzje fan 'e applikaasje ynset yn' e produksjeomjouwing (plande feroarings, útsein hotfixes en ynsidint-antwurd)?
2. Levertiid. Wat is de gemiddelde tiid tusken it begean fan in feroaring (skriuwen fan funksjonaliteit as koade) en it ynsetten fan de feroaring yn 'e produksjeomjouwing?
3. Herstel tiid. Hoe lang duorret it gemiddeld om in applikaasje te herstellen nei in produksjeomjouwing nei in ynsidint, tsjinstdegradaasje, of ûntdekking fan in brek dy't tapassingsbrûkers beynfloedet?
4. Mislearre feroarings. Hokker persintaazje fan ynset yn 'e produksjeomjouwing liedt ta tapassingsdegradaasje of ynsidinten en fereaskje sanearring (weromdraaien fan feroaringen, ûntwikkeling fan in hotfix of patch)?

DORA hat yn har ûndersyk in ferbining fûn tusken dizze metriken en organisatoaryske prestaasjes. Wy testen it ek yn ús stúdzje.

Mar om der wis fan te wêzen dat de fjouwer wichtige metriken wat kinne beynfloedzje, moatte jo begripe - binne se op ien of oare manier besibbe oan elkoar? DORA antwurde befêstigjend mei ien warskôging: de relaasje tusken mislearre feroarings (Change Failure Rate) en trije oare metriken is wat swakker. Wy krigen sawat deselde foto. As leveringstiid, ynsetfrekwinsje en hersteltiid mei-inoar korrelearje (wy hawwe dizze korrelaasje fêststeld troch de Pearson-korrelaasje en fia de Chaddock-skaal), dan is d'r gjin sa'n sterke korrelaasje mei mislearre feroarings.

Yn prinsipe hawwe de measte respondinten de neiging om te antwurdzjen dat se in frij lyts oantal ynsidinten yn produksje hawwe. Hoewol't wy letter sille sjen dat der noch in signifikant ferskil is tusken de groepen respondinten yn termen fan mislearre feroarings, kinne wy ​​dizze metrik noch net brûke foar dizze yndieling.

Wy skriuwe dit oan it feit dat (sa't bliken die by de analyze en kommunikaasje mei guon fan ús klanten) in lyts ferskil is yn 'e belibbing fan wat as in ynsidint beskôge wurdt. As wy it slagge om de prestaasjes fan ús tsjinst te herstellen tidens it technyske finster, kin dit dan as in ynsidint wurde beskôge? Wierskynlik net, want wy hawwe alles reparearre, wy binne geweldich. Kinne wy ​​it as in ynsidint beskôgje as wy ús oanfraach 10 kear op 'e nij moatte rôlje yn in normale, fertroude modus foar ús? It liket net. Dêrom bliuwt de fraach fan 'e relaasje fan mislearre feroarings mei oare metriken iepen. Wy sille it fierder ferfine.

Wichtich hjir is dat wy in wichtige korrelaasje fûnen tusken leveringstiden, hersteltiid, en ynsetfrekwinsje. Dêrom namen wy dizze trije metriken om de respondinten fierder te ferdielen yn prestaasjesgroepen.

Hoefolle hangen yn gramm?

Wy hawwe hiërargyske klusteranalyse brûkt:

• Wy fersprieden respondinten oer in n-diminsjonale romte, wêrby't de koördinaat fan elke respondint har antwurden op fragen is.
• Elke respondint wurdt ferklearre in lyts kluster.
• Wy kombinearje de twa klusters it tichtst by elkoar yn ien grutter kluster.
• Wy fine it folgjende pear klusters en kombinearje se yn in grutter kluster.

Dit is hoe't wy al ús respondinten groepearje yn it oantal klusters dat wy nedich binne. Mei help fan in dendrogram (in beam fan ferbinings tusken klusters) sjogge wy de ôfstân tusken twa oanbuorjende klusters. Alles wat foar ús bliuwt is om in bepaalde ôfstânslimyt tusken dizze klusters yn te stellen en te sizzen: "Dizze twa groepen binne aardich fan elkoar te ûnderskieden, om't de ôfstân tusken har gigantysk is."

Mar d'r is hjir in ferburgen probleem: wy hawwe gjin beheiningen op it oantal klusters - wy kinne 2, 3, 4, 10 klusters krije. En it earste idee wie - wêrom net al ús respondinten op te dielen yn 4 groepen, lykas DORA docht. Mar wy fûnen dat de ferskillen tusken dizze groepen ûnbelangryk wurde, en wy kinne der net wis fan wêze dat de respondint echt ta syn groep heart, en net ta de oanbuorjende. Wy kinne de Russyske merk noch net yn fjouwer groepen ferdiele. Dêrom hawwe wy fêstlein op trije profilen wêrt't d'r in statistysk signifikant ferskil is:

Dêrnei hawwe wy it profyl bepaald troch klusters: wy namen de mediaan foar elke metrik foar elke groep en makken in tabel mei prestaasjesprofilen. Eins krigen wy de prestaasjesprofilen fan 'e gemiddelde dielnimmer yn elke groep. Wy hawwe trije effisjinsjeprofilen identifisearre: Low, Medium, High:

Hjir befêstigje wy ús hypoteze dat 4 kaaimetriken geskikt binne foar it bepalen fan it prestaasjesprofyl, en se wurkje sawol yn 'e westerske as Russyske merken. Der is in ferskil tusken de groepen en it is statistysk signifikant. Ik beklamje dat d'r in signifikant ferskil is tusken de prestaasjesprofilen yn termen fan 'e metrik fan mislearre feroaringen yn' e gemiddelde fan 'e gemiddelde, ek al hawwe wy de respondinten yn earste ynstânsje net ferdield troch dizze parameter.

Dan komt de fraach: hoe kinne jo dit alles brûke?

Hoe brûke

As wy in team nimme, 4 wichtige metriken en tapasse it op 'e tafel, dan sille wy yn 85% fan' e gefallen gjin folsleine wedstriid krije - dit is gewoan in gemiddelde dielnimmer, en net wat yn 'e realiteit is. Wy binne allegear (en elk team) wat oars.

Wy hawwe kontrolearre: wy namen ús respondinten en it DORA-prestaasjeprofyl, en seagen hoefolle respondinten by dit of dat profyl passe. Wy fûnen dat mar 16% fan 'e respondinten definityf yn ien fan' e profilen foel. De rest is earne tuskenyn ferspraat:

Dit betsjut dat it effisjinsjeprofyl in beheinde omfang hat. Om te begripen wêr't jo binne yn 'e earste benadering, kinne jo dizze tabel brûke: "Oh, it liket derop dat wy tichter by Medium of High binne!" As jo ​​begripe wêr't te gean neist, dit kin genôch. Mar as jo doel konstante, trochgeande ferbettering is, en jo wolle krekter witte wêr't jo moatte ûntwikkelje en wat te dwaan, dan binne ekstra fûnsen nedich. Wy neamden se rekkenmasines:

• DORA rekkenmasine
• Calculator Express 42* (yn ûntwikkeling)
• Eigen ûntwikkeling (jo kinne jo eigen ynterne rekkenmasine oanmeitsje).

Wêr binne se foar nedich? Begripe:

• Is it team binnen ús organisaasje oan ús noarmen?
• Sa net, kinne wy ​​it helpe, it fersnelle yn it ramt fan de saakkundigens dy't ús bedriuw hat?
• As dat sa is, kinne wy ​​noch better dwaan?

Jo kinne se ek brûke om statistiken binnen it bedriuw te sammeljen:

• Hokker teams hawwe wy?
• Diel teams yn profilen;
• Sjoch: Och, dizze kommando's binne ûnderprestearjend (se lûke net in bytsje út), mar dizze binne cool: se sette elke dei yn, sûnder flaters, se hawwe in leadtiid fan minder as in oere.

En dan kinne jo útfine dat binnen ús bedriuw de nedige saakkundigens en ark is foar dy teams dy't noch net op 'e hichte binne.

Of, as jo begripe dat jo geweldich fiele binnen it bedriuw, jo binne better dan in protte, dan kinne jo in bytsje breder sjen. Dit is gewoan de Russyske yndustry: kinne wy ​​de nedige saakkundigens yn 'e Russyske yndustry krije om ússels te fersnellen? De rekkenmasine Express 42 sil hjir helpe (it is yn ûntwikkeling). As jo ​​de Russyske merk útgroeid hawwe, sjoch dan nei DORA rekkenmasine en nei de wrâldmerk.

Moai. En as jo yn 'e Elit-groep binne op' e DORA-rekkenmasine, wat moatte jo dwaan? Der is gjin goede oplossing hjir. Jo binne nei alle gedachten oan 'e foarop fan' e yndustry, en fierdere fersnelling en betrouberens is mooglik troch ynterne R & D en besteegje mear middels.

Lit ús gean nei de swietste - ferliking.

Fergeliking

Wy woene earst de Russyske yndustry fergelykje mei westerske yndustry. As wy direkt fergelykje, sjogge wy dat wy minder profilen hawwe, en se binne in bytsje mear mingd mei elkoar, de grinzen binne wat waziger:

Us Elite-artysten binne ferburgen ûnder de hege artysten, mar se binne der - dit binne de elite, ienhoarnen dy't wichtige hichten hawwe berikt. Yn Ruslân is it ferskil tusken it Elite-profyl en it High-profyl noch net signifikant genôch. Wy tinke dat dizze skieding yn 'e takomst komt troch in tanimming fan yngenieurkultuer, de kwaliteit fan ymplemintaasje fan yngenieurpraktiken en ekspertize binnen bedriuwen.

As wy trochgean nei in direkte ferliking binnen de Russyske yndustry, kinne wy ​​sjen dat de hege profyl teams binne better yn alle opsichten. Wy befêstigje ek ús hypoteze dat d'r in relaasje is tusken dizze metriken en organisatoaryske prestaasjes: Teams mei hege profyl binne folle mear kâns om net allinich doelen te berikken, mar se ek te oertsjûgjen.
Litte wy hege profylteams wurde en stopje dêr net:

Mar dit jier is spesjaal, en wy besletten om te kontrolearjen hoe't bedriuwen it dogge yn in pandemy: Teams mei hege profyl dogge it folle better en fiele har better dan it sektorgemiddelde:

• 1,5-2 kear mear kâns om nije produkten frij te meitsjen,
• 2 kear mear kâns om de betrouberens en / of prestaasjes fan 'e applikaasje-ynfrastruktuer te ferbetterjen.

Dat is, de kompetinsjes dy't se al hiene holpen har rapper te ûntwikkeljen, nije produkten te lansearjen, besteande produkten te feroarjen, en dêrmei nije merken en nije brûkers te feroverjen:

Wat hat ús teams noch holpen?

Engineering praktiken

Ik sil jo fertelle oer de wichtige befinings foar elke praktyk dy't wy testen. Miskien hat wat oars de teams holpen, mar wy hawwe it oer DevOps. En binnen DevOps sjogge wy in ferskil tusken teams fan ferskate profilen.

Platfoarm as in tsjinst

Wy fûnen gjin signifikante relaasje tusken platfoarmleeftyd en teamprofyl: Platfoarms ferskynden sawat deselde tiid foar sawol Low-teams as High-teams. Mar foar de lêste biedt it platfoarm gemiddeld mear tsjinsten en mear programmearring-ynterfaces foar kontrôle fia programmakoade. En platfoarmteams binne mear kâns om har ûntwikkelders en teams te helpen it platfoarm te brûken, har problemen en platfoarm-relatearre ynsidinten faker op te lossen, en oare teams opliede.

Ynfrastruktuer as koade

Alles is hjir aardich standert. Wy fûnen in relaasje tusken de automatisearring fan it wurk fan 'e ynfrastruktuerkoade en hoefolle ynformaasje is opslein yn' e ynfrastruktuerrepository. De kommando's mei hege profyl bewarje mear ynformaasje yn 'e repositories: dit is de ynfrastruktuerkonfiguraasje, CI / CD-pipeline, omjouwingsynstellingen en buildparameters. Se bewarje dizze ynformaasje faker, wurkje better mei ynfrastruktuerkoade, en automatisearje mear prosessen en taken foar wurkjen mei ynfrastruktuerkoade.

Ynteressant hawwe wy gjin signifikant ferskil sjoen yn ynfrastruktuertests. Ik skriuw dit ta oan it feit dat teams mei hege profyl mear testautomatisaasje hawwe yn 't algemien. Miskien moatte se net apart ôfliede wurde troch ynfrastruktuertests, mar earder dy tests wêrmei't se applikaasjes kontrolearje, en troch har sjogge se al wat en wêr't se brutsen hawwe.

Yntegraasje en levering

De meast saaie seksje, om't wy befêstige dat hoe mear automatisearring jo hawwe, hoe better jo wurkje mei de koade, hoe wierskynliker jo bettere resultaten krije.

arsjitektuer

Wy woene sjen hoe't mikrotsjinsten de prestaasjes beynfloedzje. Yn wierheid dogge se net, om't it gebrûk fan mikrotsjinsten net assosjearre is mei in tanimming fan prestaasjesindikatoren. Mikrotsjinsten wurde brûkt foar sawol hege profyl kommando's as lege profyl kommando's.

Mar wat wichtich is, is dat foar High-teams de oergong nei in mikroservice-arsjitektuer har mooglik makket om har tsjinsten selsstannich te ûntwikkeljen en út te rollen. As de arsjitektuer ûntwikkelders yn steat stelt om autonoom te hanneljen, sûnder te wachtsjen op immen bûten it team, dan is dit in wichtige kompetinsje foar it ferheegjen fan snelheid. Yn dit gefal helpe mikrotsjinsten. En krekt harren útfiering net spylje in grutte rol.

Hoe hawwe wy dit alles ûntdutsen?

Wy hiene in ambisjeus plan om de DORA-metodology folslein te replikearjen, mar miste de middels. As DORA in protte sponsoring brûkt en harren ûndersyk in heal jier duorret, hawwe wy ús ûndersyk yn koarte tiid dien. Wy woenen in DevOps-model bouwe lykas DORA docht, en wy sille dat yn 'e takomst dwaan. Oant no hawwe wy ússels beheind ta waarmtekaarten:

Wy seagen nei de ferdieling fan yngenieurpraktiken oer teams yn elk profyl en fûnen dat hege profylteams gemiddeld mear kâns wiene om yngenieurpraktiken te brûken. Jo kinne mear oer dit alles lêze yn ús melde.

Lit ús foar in feroaring oerstappe fan komplekse statistiken nei ienfâldige.

Wat hawwe wy oars ûntdutsen?

Tools

Wy observearje dat de measte kommando's wurde brûkt troch it OS fan 'e Linux-famylje. Mar Windows is noch altyd yn 'e trend - op syn minst in kwart fan ús respondinten notearre it gebrûk fan ien of oare fan har ferzjes. It liket derop dat de merk dit ferlet hat. Dêrom kinne jo dizze kompetinsjes ûntwikkelje en presintaasjes meitsje op konferinsjes.

By de orkestrators is it foar gjinien geheim, Kubernetes stiet foarop (52%). De folgjende yn line orkestrator is Docker Swarm (sawat 12%). De populêrste CI-systemen binne Jenkins en GitLab. It populêrste konfiguraasjebehearsysteem is Ansible, folge troch ús leafste Shell.

Amazon is op it stuit de liedende provider fan wolkhosting. It oandiel Russyske wolken nimt stadichoan ta. Takom jier sil it nijsgjirrich wêze om te sjen hoe't Russyske wolkproviders har fiele, oft har merkoandiel sil tanimme. Se binne, se kinne brûkt wurde, en dat is goed:

Ik jou de flier troch oan Igor, dy't wat mear statistiken jaan sil.

Fersprieding fan praktiken

Igor Kurochkin: Apart fregen wy respondinten om oan te jaan hoe't de beskôge yngenieurpraktiken yn it bedriuw ferdield binne. Yn 'e measte bedriuwen is d'r in mingde oanpak, besteande út in oare set fan patroanen, en pilotprojekten binne tige populêr. Wy seagen ek in lyts ferskil tusken de profilen. Fertsjintwurdigers fan it hege profyl brûke faker it patroan "Inisjatyf fan ûnderen", as lytse teams fan spesjalisten wurkprosessen, ark feroarje en suksesfolle praktiken diele mei oare teams. By Medium is dit in inisjatyf fan boppen nei ûnderen dat it heule bedriuw beynfloedet troch de oprjochting fan mienskippen en sintra fan treflikens:

Agile en DevOps

De fraach nei de ferbining tusken Agile en DevOps wurdt faak besprutsen yn 'e yndustry. Dit probleem wurdt ek oanbrocht yn it State of Agile-rapport foar 2019/2020, dus wy besletten om te fergelykjen hoe't Agile en DevOps-aktiviteiten binne ferbûn yn bedriuwen. Wy fûnen dat DevOps sûnder Agile seldsum is. Foar de helte fan 'e respondinten begon de fersprieding fan Agile folle earder, en sawat 20% observearre de simultane start, en ien fan' e tekens fan in leech profyl sil it ûntbrekken fan Agile en DevOps-praktiken wêze:

Kommando topologyen

Ein ferline jier kaam it boek "Team topologyen”, dy't in ramt foarstelt foar it beskriuwen fan kommandotopologyen. It waard nijsgjirrich foar ús oft it jildt foar Russyske bedriuwen. En wy stelden de fraach: "Hokker patroanen fine jo?".

Ynfrastruktuerteams wurde waarnommen yn 'e helte fan' e respondinten, lykas aparte teams foar ûntwikkeling, testen en eksploitaasje. Separate DevOps-teams notearren 45%, ûnder hokker fertsjintwurdigers fan High faker binne. Dêrnei komme cross-funksjonele teams, dy't ek faker binne op High. Separate SRE-kommando's ferskine yn 'e High, Medium-profilen en wurde selden sjoen yn it Low profyl:

DevQaOps ratio

Wy seagen dizze fraach op FaceBook fan de teamlieder fan it Skyeng-platfoarmteam - hy wie ynteressearre yn 'e ferhâlding fan ûntwikkelders, testers en behearders yn bedriuwen. Wy fregen it en seagen de antwurden op basis fan profilen: Fertsjintwurdigers mei hege profyl hawwe minder test- en operaasje-yngenieurs foar elke ûntwikkelder:

Plannen foar 2021 jier

Yn 'e plannen foar it folgjende jier hawwe de respondinten de folgjende aktiviteiten opmurken:

Hjir kinne jo de krusing sjen mei de DevOps Live 2020-konferinsje. Wy hawwe it programma soarchfâldich besjoen:

• Ynfrastruktuer as produkt
• DevOps-transformaasje
• Ferdieling fan DevOps-praktiken
• DevSecOps
• Case clubs en diskusjes

Mar de tiid fan ús presintaasje is net genôch om alle ûnderwerpen te dekken. Efter de skermen:

• Platfoarm as tsjinst en as produkt;
• Ynfrastruktuer as koade, omjouwings en wolken;
• Trochrinnende yntegraasje en levering;
• Boukunde;
• DevSecOps patroanen;
• Platfoarm en cross-funksjonele teams.

Melde we krigen in voluminous, 50 siden, en do kinst sjen it yn mear detail.

Omheech op

Wy hoopje dat ús ûndersyk en rapport jo sille ynspirearje om te eksperimintearjen mei nije oanpakken foar ûntwikkeling, testen en operaasjes, en ek helpe jo te navigearjen, josels te fergelykjen mei oare dielnimmers oan 'e stúdzje, en gebieten te identifisearjen wêr't jo jo eigen oanpak kinne ferbetterje.

Resultaten fan 'e earste stúdzje fan' e steat fan DevOps yn Ruslân:

• Key metrics. Wy hawwe fûn dat wichtige metriken (levertiid, ynsetfrekwinsje, hersteltiid, en feroaringsfouten) geskikt binne foar it analysearjen fan de effektiviteit fan prosessen foar ûntwikkeling, testen en operaasjes.
• Profilen Heech, Medium, Leech. Op grûn fan 'e sammele gegevens kinne wy ​​​​statistysk ferskillende groepen fan Heech, Medium, Leech ûnderskiede mei ûnderskate funksjes yn termen fan metriken, praktiken, prosessen en ark. Fertsjintwurdigers fan it hege profyl litte bettere resultaten sjen as Low. Se binne mear kâns om te berikken en oertreffe harren doelen.
• Yndikatoaren, pandemy en plannen foar 2021. In spesjale yndikator dit jier is hoe't bedriuwen omgean mei de pandemy. De hege fertsjintwurdigers gongen better, ûnderfûnen ferhege brûkersbetrokkenheid, en de wichtichste redenen foar sukses wiene effisjinte ûntwikkelingsprosessen en in sterke yngenieurkultuer.
• DevOps-praktiken, ark en har ûntwikkeling. De wichtichste plannen fan bedriuwen foar it folgjende jier omfetsje de ûntwikkeling fan DevOps-praktiken en ark, de ynfiering fan DevSecOps-praktiken, en feroaringen yn 'e organisaasjestruktuer. En de effektive ymplemintaasje en ûntwikkeling fan DevOps-praktiken wurdt útfierd mei help fan pilotprojekten, de foarming fan mienskippen en sintra fan treflikens, inisjativen op 'e boppeste en legere nivo's fan it bedriuw.

Wy wolle graach jo feedback, ferhalen, feedback hearre. Wy tankje elkenien dy't meidien hat oan it ûndersyk en sjogge út nei jo dielname takom jier.

Boarne: www.habr.com