DevOpsi olukord Venemaal 2020

Kuidas mõista millegi olekut?

Võite tugineda oma arvamusele, mis on kujunenud erinevatest teabeallikatest, näiteks veebisaitidel avaldatud väljaannetest või kogemustest. Küsida võib kolleegidelt, tuttavatelt. Teine võimalus on vaadata konverentside teemasid: programmikomisjon on valdkonna aktiivsed esindajad, seega usaldame neid teemade valikul. Omaette valdkond on uuringud ja aruanded. Kuid on probleem. DevOpsi seisu kohta tehakse maailmas igal aastal uuringuid, aruandeid avaldavad välismaised ettevõtted ja Venemaa DevOpsi kohta pole peaaegu mingit teavet.

Kuid kätte on jõudnud päev, mil selline uuring läbi viidi ja täna räägime tulemustest. Ettevõtted uurisid ühiselt DevOpsi olukorda Venemaal.Ekspress 42"Ja"Ontico". Express 42 aitab tehnoloogiaettevõtetel juurutada ja arendada DevOpsi praktikaid ja tööriistu ning oli üks esimesi, kes Venemaal DevOpsist rääkis. Uuringu autorid Igor Kurotškin ja Vitali Habarov tegelevad Express 42 analüüsi ja nõustamisega, omades samas tehnilist tausta tegutsemisest ja kogemusi erinevates ettevõtetes. 8 aasta jooksul on kolleegid vaadanud kümneid ettevõtteid ja projekte – alustavatest ettevõtetest kuni ettevõteteni –, millel on erinevad probleemid, aga ka erinev kultuuriline ja insenertehniline küpsus.

Igor ja Vitali rääkisid oma aruandes, millised probleemid olid uurimistöös, kuidas nad neid lahendasid, aga ka seda, kuidas DevOpsi uuringuid põhimõtteliselt tehakse ja miks Express 42 otsustas omad läbi viia. Nende aruannet saab vaadata siin.

DevOpsi uuringud

Vestlust alustas Igor Kurotškin.

Küsime regulaarselt DevOpsi konverentside kuulajatelt: "Kas olete lugenud selle aasta DevOpsi olekuaruannet?" Vähesed tõstavad käsi ja meie uuring näitas, et ainult kolmandik uurib neid. Kui te pole selliseid aruandeid kunagi näinud, siis ütleme kohe, et need on kõik väga sarnased. Enamasti on sellised fraasid nagu: "Võrreldes eelmise aastaga ..."

Siin on meil esimene probleem ja pärast seda veel kaks:

1. Meil puuduvad andmed eelmise aasta kohta. DevOpsi seis Venemaal ei paku kellelegi huvi;
2. Metoodika. Pole selge, kuidas hüpoteese testida, küsimusi üles ehitada, kuidas analüüsida, tulemusi võrrelda, seoseid leida;
3. Terminoloogia. Kõik aruanded on inglise keeles, tõlge on vajalik, ühist DevOpsi raamistikku pole veel leiutatud ja igaüks mõtleb välja oma.

Vaatame, kuidas DevOpsi olekuanalüüse on maailmas tehtud.

Ajaloolised andmed

DevOpsi uuringuid on tehtud alates 2011. aastast. Esimesena viis need läbi konfiguratsioonihaldussüsteemide arendaja Puppet. Sel ajal oli see üks peamisi tööriistu, millega taristut koodi kujul kirjeldada. Kuni 2013. aastani olid need uuringud lihtsalt suletud küsitlused ja avalikud aruanded puudusid.

2013. aastal ilmus IT Revolution, kõigi suuremate DevOpsi käsitlevate raamatute väljaandja. Koos Puppetiga valmistasid nad ette esimese State of DevOpsi väljaande, kus esmakordselt ilmusid 4 põhimõõdikut. Järgmisel aastal osales konsultatsioonifirma ThoughtWorks, mis on tuntud oma tavapäraste tehnoloogiaradarite poolest tööstusharu tavade ja tööriistade kohta. Ja 2015. aastal lisandus metoodikaga rubriik ja sai selgeks, kuidas nad analüüsi teevad.

2016. aastal avaldasid uuringu autorid, olles loonud oma ettevõtte DORA (DevOps Research and Assessment), aastaaruande. Järgmisel aastal avaldasid DORA ja Puppet oma viimase ühise aruande.

Ja siis algas midagi huvitavat:

2018. aastal läksid ettevõtted lahku ja avaldati kaks sõltumatut aruannet: üks Puppetilt, teine ​​DORAlt koos Google'iga. DORA on jätkanud oma metoodika kasutamist põhimõõdikute, jõudlusprofiilide ja inseneritavadega, mis mõjutavad põhimõõdikuid ja kogu ettevõtte jõudlust. Ja Puppet pakkus oma lähenemisviisi protsessi ja DevOpsi arengu kirjeldusega. Kuid lugu ei juurdunud, 2019. aastal loobus Puppet sellest metoodikast ja avaldas aruannete uue versiooni, kus loetleti peamised tavad ja kuidas need DevOpsi nende vaatenurgast mõjutavad. Siis juhtus veel üks sündmus: Google ostis DORA ja koos avaldasid nad uue aruande. Võib-olla olete teda näinud.

Sel aastal läks asi keeruliseks. Puppet on teatavasti algatanud oma küsitluse. Nad tegid seda nädal varem kui me ja see on juba lõppenud. Võtsime sellest osa ja vaatasime, mis teemad neid huvitavad. Nüüd teeb Puppet oma analüüsi ja valmistub aruande avaldamiseks.

Kuid DORA ja Google pole ikka veel teatanud. Maikuus, kui küsitlus tavaliselt algas, tuli info, et DORA üks asutajatest Nicole Forsgren on kolinud teise ettevõttesse. Seetõttu eeldasime, et sel aastal DORA uuringut ja aruannet ei tule.

Kuidas on lood Venemaal?

Me ei ole DevOpsi uuringuid teinud. Rääkisime konverentsidel, jutustasime ümber teiste inimeste leide ja Raiffeisenbank tõlkis 2019. aasta "State of DevOps" (nende teadaande leiate Habré lehelt), suur tänu neile. Ja ongi kõik.

Seetõttu viisime Venemaal läbi oma uuringud, kasutades DORA metoodikaid ja leide. Kasutasime oma uurimistööks, sealhulgas terminoloogia ja tõlke sünkroniseerimiseks Raiffeisenbanki kolleegide aruannet. Ja valdkonnaga seotud küsimused võeti DORA aruannetest ja selle aasta Nuku küsimustikust.

Uurimisprotsess

Aruanne on alles viimane osa. Kogu uurimisprotsess koosneb neljast peamisest etapist:

Ettevalmistusfaasis intervjueerisime valdkonna eksperte ja koostasime hüpoteeside nimekirja. Nende põhjal koostati küsimused ja käivitati küsitlus terveks augustiks. Seejärel analüüsisime ja koostasime aruande ise. DORA puhul võtab see protsess 6 kuud. Kohtusime 3 kuu jooksul ja nüüd saame aru, et meil oli napilt aega: ainult analüüsi tehes saate aru, milliseid küsimusi peate esitama.

Osalejad

Kõik välisreportaažid algavad osalejate portreega ja enamik neist pole Venemaalt. Vene vastajate osakaal kõigub aasta-aastalt 5–1% ja see ei võimalda järeldusi teha.

Kaart Accelerate State of DevOps 2019 aruandest:

Meie uuringus õnnestus meil küsitleda 889 inimest - see on üsna palju (DORA küsitleb oma aruannetes igal aastal umbes tuhat inimest) ja siin oleme saavutanud eesmärgi:

Tõsi, kõik meie osalejad lõpuni ei jõudnud: täitmisprotsent osutus veidi alla poole. Kuid ka sellest piisas esindusliku valimi saamiseks ja analüüsi läbiviimiseks. DORA ei avalda oma aruannetes täiteprotsente, seega pole siin võrdlust.

Tööstusharud ja ametikohad

Meie vastajad esindavad tosinat tööstust. Pool tööd infotehnoloogia alal. Sellele järgnevad finantsteenused, kaubandus, telekommunikatsioon jm. Ametikohtade hulgas on spetsialistid (arendaja, testija, operatiivinsener) ja juhtivtöötajad (meeskondade, rühmade, valdkondade juhid, direktorid):

Iga teine ​​töötab keskmise suurusega ettevõttes. Iga kolmas inimene töötab suurettevõtetes. Enamik töötab kuni 9-liikmelistes meeskondades. Eraldi küsisime põhitegevuste kohta ja enamus on kuidagi seotud tegevusega ning ca 40% tegeleb arendusega:

Nii kogusimegi infot erinevate tööstusharude, ettevõtete, meeskondade esindajate võrdlemiseks ja analüüsimiseks. Analüüsist räägib kolleeg Vitali Khabarov.

Analüüs ja võrdlus

Vitali Khabarov: Suur tänu kõigile osalejatele, kes täitsid meie küsitluse, täitsid küsimustikud ja andsid meile andmeid edasiseks analüüsiks ja hüpoteeside kontrollimiseks. Tänu oma klientidele on meil palju kogemusi, mis on aidanud tuvastada tööstusharu probleeme ja sõnastada hüpoteese, mida oma uurimistöös testisime.

Kahjuks ei saa te lihtsalt võtta ühelt poolt küsimuste loendit ja teiselt poolt andmeid, neid kuidagi võrrelda, öelda: "Jah, kõik töötab nii, meil oli õigus" ja hajutada. Ei, metoodikat ja statistilisi meetodeid on vaja selleks, et olla kindlad, et me ei eksi ja meie järeldused on usaldusväärsed. Seejärel saame nende andmete põhjal edasise töö üles ehitada:

Peamised mõõdikud

Võtsime aluseks DORA metoodika, mida nad kirjeldasid üksikasjalikult raamatus “Accelerate State of DevOps”. Kontrollisime, kas võtmemõõdikud sobivad Venemaa turule, kas neid saab kasutada samamoodi nagu DORA kasutab, et vastata küsimusele: "Kuidas vastab Venemaa tööstus välistööstusele?"

Peamised mõõdikud:

1. Kasutuselevõtu sagedus. Kui tihti rakenduse uut versiooni tootmiskeskkonda juurutatakse (kavandatud muudatused, välja arvatud kiirparandused ja reageerimine juhtumitele)?
2. Tarne aeg. Kui suur on keskmine aeg muudatuse tegemise (funktsiooni koodina kirjutamise) ja muudatuse tootmiskeskkonda juurutamise vahel?
3. Taastumisaeg. Kui kaua kulub keskmiselt rakenduse taastamiseks tootmiskeskkonda pärast vahejuhtumit, teenuse halvenemist või rakenduse kasutajaid mõjutava vea avastamist?
4. Ebaõnnestunud muudatused. Kui suur protsent tootmiskeskkonnas juurutamistest viib rakenduse halvenemiseni või intsidentideni ja nõuab parandustöid (muudatuste tagasivõtmine, käigultparanduse või paiga väljatöötamine)?

DORA on oma uurimistöös leidnud seose nende mõõdikute ja organisatsiooni tulemuslikkuse vahel. Testime seda ka oma uuringus.

Kuid veendumaks, et neli peamist mõõdikut võivad midagi mõjutada, peate mõistma – kas need on kuidagi üksteisega seotud? DORA vastas jaatavalt ühe hoiatusega: suhe ebaõnnestunud muudatuste (Change Failure Rate) ja kolme muu mõõdiku vahel on veidi nõrgem. Meil on umbes sama pilt. Kui tarneaeg, juurutamise sagedus ja taastamisaeg on omavahel korrelatsioonis (meie tuvastasime selle korrelatsiooni Pearsoni korrelatsiooni ja Chaddocki skaala kaudu), siis ebaõnnestunud muudatustega nii tugevat korrelatsiooni pole.

Põhimõtteliselt kipub enamik vastajatest vastama, et neil on tootmises üsna vähe intsidente. Kuigi hiljem näeme, et ebaõnnestunud muudatuste osas on vastajate rühmade vahel siiski märkimisväärne erinevus, ei saa me selle jaotuse puhul seda mõõdikut veel kasutada.

Selle põhjuseks on asjaolu, et (nagu selgus analüüsi käigus ja mõne meie kliendiga suhtlemise käigus) on väike erinevus intsidendi tajumises. Kui meil õnnestus tehnilise akna ajal oma teenuse toimivus taastada, kas seda võib pidada intsidendiks? Ilmselt mitte, sest parandasime kõik ära, oleme suurepärased. Kas seda võib pidada vahejuhtumiks, kui peaksime oma rakendust 10 korda tavalises, meile tuttavas režiimis uuesti kerima? Tundub, et mitte. Seetõttu jääb lahtiseks küsimus ebaõnnestunud muudatuste seose kohta teiste mõõdikutega. Täiustame seda veelgi.

Siin on oluline, et leidsime olulise korrelatsiooni tarneaegade, taasteaegade ja juurutamise sageduse vahel. Seetõttu võtsime need kolm mõõdikut, et jagada vastajad veelgi tulemusrühmadesse.

Kui palju riputada grammides?

Kasutasime hierarhilist klastri analüüsi:

• Jaotame vastajad üle n-mõõtmelise ruumi, kus iga vastaja koordinaadiks on vastused küsimustele.
• Iga vastaja kuulutatakse väikeseks klastriks.
• Kombineerime kaks üksteisele kõige lähemat klastrit üheks suuremaks klastriks.
• Leiame järgmise klastripaari ja ühendame need suuremaks klastriks.

Nii rühmitame kõik oma vastajad vajaliku arvu klastritesse. Dendrogrammi (klastritevaheliste seoste puu) abil näeme kahe naaberklastri vahemaad. Meil jääb üle vaid seada nende klastrite vahele teatud vahemaa ja öelda: "Need kaks rühma on üksteisest üsna eristatavad, kuna nendevaheline kaugus on hiiglaslik."

Kuid siin on varjatud probleem: meil pole klastrite arvule piiranguid - saame 2, 3, 4, 10 klastrit. Ja esimene mõte oli – miks mitte jagada kõik meie vastajad 4 gruppi, nagu DORA teeb. Kuid leidsime, et erinevused nende rühmade vahel muutuvad ebaoluliseks ja me ei saa olla kindlad, et vastaja kuulub tõesti tema, mitte naaberrühma. Me ei saa veel jagada Venemaa turgu nelja rühma. Seetõttu otsustasime kolme profiiliga, mille vahel on statistiliselt oluline erinevus:

Järgmisena määrasime profiili klastrite kaupa: võtsime iga rühma jaoks iga mõõdiku mediaani ja koostasime toimivusprofiilide tabeli. Tegelikult saime iga rühma keskmise osaleja sooritusprofiilid. Oleme tuvastanud kolm efektiivsusprofiili: madal, keskmine, kõrge:

Siin kinnitasime oma hüpoteesi, et jõudlusprofiili määramiseks sobivad 4 võtmemõõdikut, mis toimivad nii lääne kui ka Venemaa turul. Rühmade vahel on erinevus ja see on statistiliselt oluline. Rõhutan, et tulemusprofiilide vahel on märkimisväärne erinevus ebaõnnestunud muutuste mõõdiku osas keskmise osas, kuigi me ei jaganud vastajaid algselt selle parameetri järgi.

Siis tekib küsimus: kuidas seda kõike kasutada?

Kuidas kasutada

Kui võtame suvalise meeskonna, 4 peamist mõõdikut ja rakendame selle tabelisse, siis 85% juhtudest ei saa me täielikku vastet - see on lihtsalt keskmine osaleja, mitte see, mis tegelikkuses on. Oleme kõik (ja iga meeskond) veidi erinevad.

Kontrollisime: võtsime oma vastajad ja DORA tulemusprofiili ning vaatasime, kui palju vastajaid sellele või teisele profiilile sobib. Leidsime, et ainult 16% vastanutest langes kindlalt mõnda profiili. Kõik ülejäänud on laiali kuskil vahepeal:

See tähendab, et tõhususe profiilil on piiratud ulatus. Et mõista, kus te esimeses lähenduses asute, võite kasutada seda tabelit: "Oh, tundub, et oleme keskmisele või kõrgele lähemal!" Kui saate aru, kuhu edasi minna, võib sellest piisata. Aga kui Sinu eesmärk on pidev, pidev täiustamine ja soovid täpsemalt teada, kuhu areneda ja mida teha, siis on vaja lisaraha. Me nimetasime neid kalkulaatoriteks:

• DORA kalkulaator
• Calculator Express 42* (arenduses)
• Oma arendus (saate luua oma sisemise kalkulaatori).

Milleks neid vaja on? Aru saama:

• Kas meie organisatsiooni meeskond vastab meie standarditele?
• Kui ei, siis kas saame seda aidata, kiirendada meie ettevõtte oskusteabe raames?
• Kui jah, kas saame veel paremini hakkama?

Samuti saate neid kasutada ettevõttesisese statistika kogumiseks:

• Millised meeskonnad meil on?
• Jagage meeskonnad profiilideks;
• Vaadake: Oh, need käsud ei toimi (nad ei tõmbu vähe välja), kuid need on lahedad: neid rakendatakse iga päev, ilma vigadeta, nende teostusaeg on alla tunni.

Ja siis saate teada, et meie ettevõttes on olemas vajalikud teadmised ja tööriistad nendele meeskondadele, kes pole veel tasemel.

Või kui mõistad, et tunned end ettevõtte sees suurepäraselt, oled paljudest parem, siis võid vaadata veidi laiemalt. See on ainult Venemaa tööstus: kas me saame Venemaa tööstusest vajalikke teadmisi, et ennast kiirendada? Siin on abiks Express 42 kalkulaator (see on väljatöötamisel). Kui oled Venemaa turust välja kasvanud, siis vaata DORA kalkulaator ja maailmaturule.

Hästi. Ja kui olete DORA kalkulaatori Elit grupis, mida peaksite tegema? Siin pole head lahendust. Tõenäoliselt olete tööstuse esirinnas ning edasine kiirendus ja töökindlus on võimalik sisemise uurimis- ja arendustegevuse ning suuremate ressursside kulutamise kaudu.

Liigume edasi kõige magusama – võrdluse juurde.

Võrdlus

Tahtsime esialgu võrrelda Venemaa tööstust lääne tööstusega. Kui me võrdleme otse, siis näeme, et meil on vähem profiile ja need on omavahel veidi rohkem segunenud, piirid on veidi hägusamad:

Meie eliitesinejad on peidus Kõrgete esinejate seas, kuid nad on seal – need on eliit, ükssarved, kes on saavutanud märkimisväärseid kõrgusi. Venemaal ei ole Elite ja High profiili erinevus veel piisavalt märkimisväärne. Arvame, et tulevikus toimub see eraldumine tänu insenerikultuuri kasvule, inseneripraktikate rakendamise kvaliteedile ja ettevõtete sisesele asjatundlikkusele.

Kui liigume edasi otsese võrdluse juurde Venemaa tööstuse sees, näeme, et kõrge profiiliga meeskonnad on igas mõttes paremad. Samuti kinnitasime oma hüpoteesi, et nende mõõdikute ja organisatsiooni tulemuslikkuse vahel on seos: kõrge profiiliga meeskonnad ei saavuta palju tõenäolisemalt eesmärke, vaid ka ületavad neid.
Hakkagem kõrgetasemelisteks meeskondadeks ja ärgem lõpetagem sellega:

Kuid see aasta on eriline ja otsustasime kontrollida, kuidas ettevõtetel pandeemia ajal läheb: kõrge profiiliga meeskondadel läheb palju paremini ja nad tunnevad end paremini kui valdkonna keskmine:

• 1,5-2 korda suurem tõenäosus uute toodete väljalaskmiseks,
• Rakenduste infrastruktuuri töökindlus ja/või jõudlus paraneb 2 korda tõenäolisemalt.

See tähendab, et juba omandatud pädevused aitasid neil kiiremini areneda, uusi tooteid turule tuua, olemasolevaid tooteid muuta, vallutades seeläbi uusi turge ja uusi kasutajaid:

Mis meie meeskondi veel aitas?

Inseneritavad

Räägin teile iga testitud praktika olulistest leidudest. Võib-olla aitas meeskondi midagi muud, kuid me räägime DevOpsist. Ja DevOpsis näeme erinevusi erinevate profiilidega meeskondade vahel.

Platvorm kui teenus

Me ei leidnud olulist seost platvormi vanuse ja meeskonna profiili vahel: platvormid ilmusid umbes samal ajal nii madalate kui ka kõrgete meeskondade jaoks. Kuid viimase jaoks pakub platvorm programmikoodi kaudu juhtimiseks keskmiselt rohkem teenuseid ja rohkem programmeerimisliideseid. Ja platvormimeeskonnad aitavad suurema tõenäosusega oma arendajatel ja meeskondadel platvormi kasutada, lahendavad sagedamini probleeme ja platvormiga seotud juhtumeid ning koolitavad teisi meeskondi.

Infrastruktuur kui kood

Siin on kõik üsna standardne. Leidsime seose infrastruktuuri koodi töö automatiseerimise ja infrastruktuuri hoidlasse salvestatud teabe vahel. Kõrge profiiliga käsud salvestavad hoidlatesse rohkem teavet: see on infrastruktuuri konfiguratsioon, CI / CD konveier, keskkonna sätted ja ehitusparameetrid. Nad salvestavad seda teavet sagedamini, töötavad paremini infrastruktuuri koodiga ja automatiseerivad rohkem protsesse ja ülesandeid infrastruktuuri koodiga töötamiseks.

Huvitaval kombel ei näinud me infrastruktuuri testides olulist erinevust. Pean selle põhjuseks asjaolu, et kõrge profiiliga meeskondadel on üldiselt rohkem testimise automatiseerimist. Võib-olla ei peaks neid eraldi segama taristutestid, vaid pigem need testid, millega nad kontrollivad rakendusi ja tänu neile juba näevad, mida ja kus nad on murdnud.

Integreerimine ja kohaletoimetamine

Kõige igavam osa, sest kinnitasime, et mida rohkem automatiseerimist sul on, mida paremini koodiga töötad, seda suurem on tõenäosus saada paremaid tulemusi.

arhitektuur

Tahtsime näha, kuidas mikroteenused mõjutavad jõudlust. Tegelikult nad seda ei tee, kuna mikroteenuste kasutamist ei seostata tulemusnäitajate tõusuga. Mikroteenuseid kasutatakse nii kõrge profiiliga käskude kui ka madala profiiliga käskude jaoks.

Kuid oluline on see, et kõrgmeeskondade jaoks võimaldab üleminek mikroteenuste arhitektuurile iseseisvalt oma teenuseid arendada ja kasutusele võtta. Kui arhitektuur võimaldab arendajatel tegutseda autonoomselt, ootamata kedagi meeskonnaväliselt, on see kiiruse suurendamise võtmepädevus. Sel juhul aitavad mikroteenused. Ja lihtsalt nende rakendamine ei mängi suurt rolli.

Kuidas me seda kõike avastasime?

Meil oli ambitsioonikas plaan DORA metoodikat täielikult korrata, kuid meil puudusid vahendid. Kui DORA kasutab palju sponsorlust ja nende uurimine võtab aega pool aastat, siis tegime oma uurimistöö ära lühikese ajaga. Tahtsime luua DevOpsi mudeli, nagu teeb DORA, ja teeme seda ka tulevikus. Seni oleme piirdunud soojuskaartidega:

Vaatasime inseneritavade jaotust iga profiili meeskondade vahel ja leidsime, et kõrge profiiliga meeskonnad kasutasid keskmiselt tõenäolisemalt inseneritavasid. Selle kõige kohta saate rohkem lugeda meie lehelt lähtub aruandest.

Vahelduseks lülitume keeruliselt statistikalt lihtsale.

Mida me veel avastasime?

Töövahendid

Märkame, et enamikku käskudest kasutab Linuxi perekonna operatsioonisüsteem. Kuid Windows on endiselt trendis – vähemalt veerand meie vastajatest märkis selle ühe või teise versiooni kasutamist. Tundub, et turul on see vajadus. Seetõttu saate neid pädevusi arendada ja konverentsidel ettekandeid teha.

Orkestrite seas pole see kellelegi saladus, esikohal on Kubernetes (52%). Järjekorras järgmine orkestrant on Docker Swarm (umbes 12%). Kõige populaarsemad CI-süsteemid on Jenkins ja GitLab. Kõige populaarsem konfiguratsioonihaldussüsteem on Ansible, millele järgneb meie armastatud Shell.

Amazon on praegu juhtiv pilvemajutusteenuse pakkuja. Vene pilvede osakaal tasapisi suureneb. Järgmisel aastal on huvitav näha, kuidas Venemaa pilvepakkujad end tunnevad, kas nende turuosa kasvab. Nad on, neid saab kasutada ja see on hea:

Annan sõna Igorile, kes annab veel statistikat.

Praktikate levitamine

Igor Kurochkin: Eraldi palusime vastajatel näidata, kuidas ettevõttes vaadeldavaid inseneritavasid levitatakse. Enamikus ettevõtetes on kombineeritud lähenemisviis, mis koosneb erinevatest mustritest ja pilootprojektid on väga populaarsed. Nägime ka väikest erinevust profiilide vahel. Kõrge profiili esindajad kasutavad sagedamini mustrit “Algatus altpoolt”, kui väikesed spetsialistide meeskonnad vahetavad tööprotsesse, tööriistu ja jagavad edukaid praktikaid teiste meeskondadega. Mediumis on see ülalt-alla algatus, mis mõjutab kogu ettevõtet kogukondade ja tippkeskuste loomise kaudu:

Agile ja DevOps

Tööstuses arutatakse sageli Agile'i ja DevOpsi vahelise seose küsimust. See probleem on tõstatatud ka 2019/2020 agiilse seisu aruandes, mistõttu otsustasime võrrelda, kuidas on Agile ja DevOpsi tegevused ettevõtetes omavahel seotud. Leidsime, et ilma Agileta DevOps on haruldane. Poolte vastanute jaoks algas Agile'i levik palju varem ja umbes 20% täheldas samaaegset käivitamist ning üks madala profiili märke on Agile'i ja DevOpsi praktika puudumine:

Käskude topoloogiad

Eelmise aasta lõpus ilmus raamat "Meeskonna topoloogiad”, mis pakub välja käsutopoloogiate kirjeldamise raamistiku. Meile sai huvitav, kas see on rakendatav ka Venemaa ettevõtetele. Ja esitasime küsimuse: "Milliseid mustreid te leiate?".

Infrastruktuuri meeskondi vaadeldakse pooltel vastajatel, samuti eraldi meeskondi arenduseks, testimiseks ja käitamiseks. Eraldi DevOpsi meeskonnad märkisid 45%, mille hulgas on High esindajad sagedamini. Järgmisena tulevad ristfunktsionaalsed meeskonnad, mis on ka High'is tavalisemad. Eraldi SRE-käsud kuvatakse kõrge ja keskmise profiiliga ja neid näeb harva madalal profiilil:

DevQaOpsi suhe

Seda küsimust nägime FaceBookis Skyeng platvormi meeskonna tiimijuhilt – teda huvitas arendajate, testijate ja administraatorite suhe ettevõtetes. Küsisime seda ja vaatasime vastuseid profiilide põhjal: kõrge profiiliga esindajatel on iga arendaja jaoks vähem testi- ja operatsiooniinsenere:

2021 aasta plaanid

Järgmise aasta plaanides märkisid vastajad ära järgmised tegevused:

Siin näete ristumiskohta DevOps Live 2020 konverentsiga. Vaatasime programmi hoolikalt üle:

• Infrastruktuur kui toode
• DevOpsi teisendus
• DevOpsi praktikate levitamine
• DevSecOps
• Juhtumiklubid ja arutelud

Kuid meie ettekande aeg ei ole kõigi teemade käsitlemiseks piisav. Kulisside taha jäänud:

• Platvorm teenuse ja tootena;
• Infrastruktuur kui kood, keskkonnad ja pilved;
• Pidev integreerimine ja kohaletoimetamine;
• Arhitektuur;
• DevSecOpsi mustrid;
• Platvorm ja funktsionaalsed meeskonnad.

Aruanne saime mahuka, 50 lehekülge ja seda saate täpsemalt näha.

Kokkuvõtteks

Loodame, et meie uurimus ja aruanne inspireerivad teid katsetama uusi lähenemisviise arendusele, testimisele ja toimimisele, samuti aitavad teil navigeerida, võrrelda end teiste uuringus osalejatega ja tuvastada valdkonnad, kus saate oma lähenemisviise täiustada.

Venemaa DevOpsi olukorra esimese uuringu tulemused:

• Peamised mõõdikud. Oleme leidnud, et põhimõõdikud (tarneaeg, juurutamise sagedus, taastumisaeg ja muudatuste tõrked) sobivad arendus-, testimis- ja toimimisprotsesside efektiivsuse analüüsimiseks.
• Profiilid kõrge, keskmine, madal. Kogutud andmete põhjal saame eristada statistiliselt erinevaid kõrge, keskmise, madala rühmi, millel on mõõdikute, praktikate, protsesside ja tööriistade poolest eristuvad tunnused. Kõrge profiili esindajad näitavad paremaid tulemusi kui madalad. Nad saavutavad ja ületavad oma eesmärke tõenäolisemalt.
• Näitajad, pandeemia ja plaanid aastaks 2021. Selle aasta erinäitaja on ettevõtete pandeemiaga toimetulemine. Kõrgetel esindajatel läks paremini, nad kogesid suurenenud kasutajate kaasatust ning peamisteks edu põhjusteks olid tõhusad arendusprotsessid ja tugev insenerikultuur.
• DevOpsi praktikad, tööriistad ja nende arendamine. Ettevõtete järgmise aasta põhiplaanides on DevOpsi praktikate ja tööriistade arendamine, DevSecOps praktikate juurutamine ning organisatsiooni struktuuri muudatused. Ja DevOpsi praktikate tõhus juurutamine ja arendamine toimub pilootprojektide, kogukondade ja tippkeskuste moodustamise, ettevõtte kõrgema ja madalama tasandi algatuste abil.

Meile meeldiks kuulda teie tagasisidet, lugusid, tagasisidet. Täname kõiki uuringus osalenuid ja ootame teie osalemist järgmisel aastal.

Allikas: www.habr.com