Staða DevOps í Rússlandi 2020

Hvernig á að skilja ástand einhvers?

Þú getur reitt þig á þína skoðun, mynduð úr ýmsum upplýsingagjöfum, til dæmis útgáfum á vefsíðum eða reynslu. Þú getur spurt samstarfsmenn, kunningja. Annar möguleiki er að skoða efni ráðstefnunnar: dagskrárnefndin eru virkir fulltrúar atvinnulífsins, þannig að við treystum þeim til að velja viðeigandi viðfangsefni. Sérstakt svæði er rannsóknir og skýrslur. En það er vandamál. Rannsóknir á stöðu DevOps eru gerðar árlega í heiminum, skýrslur eru gefnar út af erlendum fyrirtækjum og nánast engar upplýsingar eru til um rússneska DevOps.

En sá dagur er runninn upp að slík rannsókn var gerð og í dag verður fjallað um niðurstöðurnar. Staða DevOps í Rússlandi var rannsakað í sameiningu af fyrirtækjunum "Express 42"Og"Ontico". Express 42 hjálpar tæknifyrirtækjum að innleiða og þróa DevOps starfshætti og verkfæri og var einn af þeim fyrstu til að tala um DevOps í Rússlandi. Höfundar rannsóknarinnar, Igor Kurochkin og Vitaly Khabarov, stunda greiningu og ráðgjöf hjá Express 42, en hafa tæknilegan bakgrunn frá rekstri og reynslu í mismunandi fyrirtækjum. Í 8 ár hafa samstarfsmenn skoðað tugi fyrirtækja og verkefna - frá sprotafyrirtækjum til fyrirtækja - með mismunandi vandamál, sem og mismunandi menningarlegan og verkfræðilegan þroska.

Í skýrslu sinni sögðu Igor og Vitaly hvaða vandamál voru í rannsóknaferlinu, hvernig þeir leystu þau, sem og hvernig DevOps rannsóknir eru framkvæmdar í grundvallaratriðum og hvers vegna Express 42 ákvað að framkvæma sínar eigin. Hægt er að skoða skýrslu þeirra hér.

DevOps rannsóknir

Samtalið hófst af Igor Kurochkin.

Við spyrjum reglulega áhorfendur á DevOps ráðstefnum: "Hefurðu lesið DevOps stöðuskýrsluna fyrir þetta ár?" Fáir rétta upp hendur og rannsókn okkar sýndi að aðeins þriðjungur rannsakaði þá. Ef þú hefur aldrei séð slíkar skýrslur skulum við segja strax að þær séu allar mjög svipaðar. Oftast eru setningar eins og: "Samborið við síðasta ár ..."

Hér höfum við fyrsta vandamálið og eftir það tvö í viðbót:

1. Við höfum ekki gögn fyrir síðasta ár. Staða DevOps í Rússlandi vekur engan áhuga;
2. Aðferðafræði. Ekki er ljóst hvernig á að prófa tilgátur, hvernig á að byggja upp spurningar, hvernig á að greina, bera saman niðurstöður, finna tengsl;
3. Hugtök. Allar skýrslur eru á ensku, þýðingar er krafist, sameiginlegur DevOps ramma hefur ekki enn verið fundinn upp og allir koma með sitt eigið.

Við skulum skoða hvernig DevOps ástandsgreiningar hafa verið gerðar um allan heim.

Saga

DevOps rannsóknir hafa verið gerðar síðan 2011. Puppet, þróunaraðili stillingastjórnunarkerfa, var fyrstur til að framkvæma þau. Á þeim tíma var það eitt helsta tækið til að lýsa innviðum í formi kóða. Fram til ársins 2013 voru þessar rannsóknir einfaldlega lokaðar kannanir og engar opinberar skýrslur.

Árið 2013 birtist IT Revolution, útgefandi allra helstu bóka um DevOps. Ásamt Puppet undirbjuggu þeir fyrstu State of DevOps útgáfuna, þar sem 4 lykilmælikvarðar birtust í fyrsta skipti. Árið eftir tók ThoughtWorks, ráðgjafarfyrirtæki sem þekkt er fyrir reglubundnar tækniratsjár um starfshætti og verkfæri í iðnaði, þátt. Og árið 2015 bættist við kafli með aðferðafræði og kom í ljós hvernig þeir framkvæma greininguna.

Árið 2016 birtu höfundar rannsóknarinnar, eftir að hafa stofnað sitt eigið fyrirtæki DORA (DevOps Research and Assessment), ársskýrslu. Árið eftir gáfu DORA og Puppet út sína síðustu sameiginlegu skýrslu.

Og þá byrjaði eitthvað áhugavert:

Árið 2018 hættu fyrirtækin og tvær sjálfstæðar skýrslur voru gefnar út: önnur frá Puppet, önnur frá DORA í tengslum við Google. DORA hefur haldið áfram að nýta aðferðafræði sína með lykilmælingum, frammistöðuprófílum og verkfræðiaðferðum sem hafa áhrif á lykilmælingar og frammistöðu fyrirtækisins. Og Puppet bauð upp á sína eigin nálgun með lýsingu á ferlinu og þróun DevOps. En sagan festi ekki rætur, árið 2019 yfirgaf Puppet þessa aðferðafræði og gaf út nýja útgáfu af skýrslunum, sem taldi upp helstu venjur og hvernig þær hafa áhrif á DevOps frá sjónarhóli þeirra. Svo gerðist annar atburður: Google keypti DORA og saman gáfu þeir út aðra skýrslu. Þú gætir hafa séð hann.

Í ár vandaðist málið. Vitað er að Puppet hefur sett af stað sína eigin könnun. Þeir gerðu það viku fyrr en við og því er þegar lokið. Við tókum þátt í því og skoðuðum hvaða efni þau hafa áhuga á. Nú er Puppet að gera greiningu sína og undirbúa útgáfu skýrslunnar.

En það er enn engin tilkynning frá DORA og Google. Í maí, þegar könnunin hófst venjulega, komu upplýsingar um að Nicole Forsgren, einn af stofnendum DORA, hefði flutt í annað fyrirtæki. Þess vegna gerðum við ráð fyrir að engar rannsóknir og skýrslur yrðu frá DORA á þessu ári.

Hvernig er ástandið í Rússlandi?

Við höfum ekki gert DevOps rannsóknir. Við töluðum á ráðstefnum, endursögðum niðurstöður annarra og Raiffeisenbank þýddi „State of DevOps“ fyrir árið 2019 (þú getur fundið tilkynningu þeirra á Habré), kærar þakkir til þeirra. Og það er allt.

Þess vegna gerðum við okkar eigin rannsóknir í Rússlandi með DORA aðferðafræði og niðurstöðum. Við notuðum skýrslu samstarfsmanna frá Raiffeisenbank fyrir rannsóknir okkar, þar á meðal til að samstilla hugtök og þýðingar. Og spurningar sem skipta máli fyrir iðnaðinn voru teknar úr DORA skýrslum og Puppet spurningalistanum í ár.

Rannsóknarferli

Skýrslan er aðeins lokahlutinn. Allt rannsóknarferlið samanstendur af fjórum meginþrepum:

Á undirbúningsstigi tókum við viðtöl við sérfræðinga í iðnaði og útbjuggum lista yfir tilgátur. Á grundvelli þeirra voru teknar saman spurningar og könnun sett af stað í allan ágúst. Síðan greindum við og útbjuggum skýrsluna sjálfa. Fyrir DORA tekur þetta ferli 6 mánuði. Við hittumst innan 3 mánaða og nú skiljum við að við höfðum varla nægan tíma: aðeins með því að framkvæma greininguna skilurðu hvaða spurningar þú þarft að spyrja.

Þátttakendur

Allar erlendar skýrslur hefjast á mynd af þátttakendum og flestar þeirra eru ekki frá Rússlandi. Hlutfall rússneskra svarenda sveiflast á milli 5 og 1% frá ári til árs og það gerir ekki kleift að draga neinar ályktanir.

Kort úr skýrslunni Accelerate State of DevOps 2019:

Í rannsókn okkar náðum við að taka viðtöl við 889 manns - þetta er frekar mikið (DORA skoðar um þúsund manns árlega í skýrslum sínum) og hér höfum við náð markmiðinu:

Að vísu náðu ekki allir þátttakendur okkar endalokum: hlutfall fullkomnunar reyndist vera aðeins minna en helmingur. En jafnvel þetta var nóg til að fá dæmigert sýni og framkvæma greiningu. DORA gefur ekki upp fyllingarprósentur í skýrslum sínum, svo það er enginn samanburður hér.

Atvinnugreinar og stöður

Svarendur okkar eru fulltrúar tugi atvinnugreina. Hálf vinna í upplýsingatækni. Þar á eftir kemur fjármálaþjónusta, verslun, fjarskipti og fleira. Meðal starfa eru sérfræðingar (framleiðandi, prófunaraðili, rekstrarverkfræðingur) og stjórnendur (forstöðumenn teyma, hópa, svæði, forstöðumenn):

Annar hver vinnur hjá meðalstóru fyrirtæki. Þriðji hver maður starfar í stórum fyrirtækjum. Flestir vinna í allt að 9 manna teymi. Sérstaklega spurðum við um helstu starfsemina og meirihlutinn tengist rekstrinum á einhvern hátt og um 40% stunda þróun:

Þannig að við söfnuðum upplýsingum til samanburðar og greiningar á fulltrúum mismunandi atvinnugreina, fyrirtækja, teyma. Samstarfsmaður minn Vitaly Khabarov mun segja frá greiningunni.

Greining og samanburður

Vitaly Khabarov: Kærar þakkir til allra þátttakenda sem luku könnuninni okkar, fylltu út spurningalista og útveguðu okkur gögn til frekari greiningar og prófunar á tilgátum okkar. Og þökk sé viðskiptavinum okkar og viðskiptavinum höfum við mikla reynslu sem hefur hjálpað til við að bera kennsl á áhyggjur iðnaðarins og móta tilgátur sem við prófuðum í rannsóknum okkar.

Því miður er ekki bara hægt að taka lista yfir spurningar annars vegar og gögn hins vegar, bera þær einhvern veginn saman, segja: „Já, allt virkar svona, við höfðum rétt fyrir okkur“ og dreift. Nei, við þurfum aðferðafræði og tölfræðilegar aðferðir til að vera viss um að okkur skjátlast ekki og að niðurstöður okkar séu áreiðanlegar. Þá getum við byggt upp frekari vinnu okkar byggt á þessum gögnum:

Helstu mælikvarðar

Við tókum DORA aðferðafræðina til grundvallar, sem þeir lýstu í smáatriðum í bókinni „Accelerate State of DevOps“. Við athuguðum hvort lykiltölurnar henti rússneska markaðnum, hvort hægt sé að nota þær á sama hátt og DORA notar til að svara spurningunni: „Hvernig samsvarar iðnaðurinn í Rússlandi erlendum iðnaði?

Helstu mælikvarðar:

1. Dreifingartíðni. Hversu oft er ný útgáfa af forritinu dreifð í framleiðsluumhverfið (fyrirhugaðar breytingar, að undanskildum flýtileiðréttingum og viðbrögðum við atvikum)?
2. Sendingartími. Hver er meðaltíminn frá því að breyting er framkvæmd (skrifa virkni sem kóða) og þar til breytingin er sett inn í framleiðsluumhverfið?
3. bata tíma. Hversu langan tíma tekur það að meðaltali að endurheimta forrit í framleiðsluumhverfi eftir atvik, þjónusturýrnun eða uppgötvun á villu sem hefur áhrif á notendur forrita?
4. Misheppnaðar breytingar. Hversu hátt hlutfall af innleiðingum í framleiðsluumhverfinu leiðir til hnignunar forrita eða atvika og krefst lagfæringar (til baka breytinga, þróun bráðaleiðréttingar eða plásturs)?

DORA hefur í rannsóknum sínum fundið tengsl milli þessara mælikvarða og frammistöðu skipulagsheilda. Við prófum það líka í rannsókninni okkar.

En til að ganga úr skugga um að lykilmælikvarðarnir fjórir geti haft áhrif á eitthvað þarftu að skilja - eru þeir einhvern veginn tengdir hver öðrum? DORA svaraði játandi með einum fyrirvara: sambandið milli misheppnaðra breytinga (Change Failure Rate) og þriggja annarra mælikvarða er aðeins veikara. Við fengum nokkurn veginn sömu mynd. Ef afhendingartími, dreifingartíðni og batatími eru í samræmi við hvert annað (við komumst að þessari fylgni með Pearson fylgni og í gegnum Chaddock kvarðann), þá er engin svo sterk fylgni við misheppnaðar breytingar.

Í grundvallaratriðum hafa flestir svarenda tilhneigingu til að svara að þeir séu með frekar fáan fjölda atvika í framleiðslu. Þó að við munum sjá síðar að það er enn marktækur munur á hópum svarenda hvað varðar misheppnaðar breytingar, þá getum við ekki enn notað þennan mælikvarða fyrir þessa skiptingu.

Við rekjum þetta til þess að (eins og það kom í ljós við greiningu og samskipti við nokkra viðskiptavini okkar) er smámunur á skynjun á því hvað telst atvik. Ef okkur tókst að endurheimta afköst þjónustu okkar í tækniglugganum, getur þetta talist tilvik? Sennilega ekki, vegna þess að við redduðum öllu, við erum frábærir. Getum við litið á það sem atvik ef við þyrftum að endurvelta umsókn okkar 10 sinnum í venjulegum, kunnuglegum ham fyrir okkur? Svo virðist ekki. Þess vegna er spurningin um tengsl misheppnaðra breytinga við aðra mælikvarða enn opin. Við munum betrumbæta það frekar.

Mikilvægt hér er að við fundum marktæka fylgni á milli afhendingartíma, endurheimtartíma og dreifingartíðni. Þess vegna tókum við þessa þrjá mælikvarða til að skipta svarendum frekar í árangurshópa.

Hversu mikið að hanga í grömmum?

Við notuðum stigveldisklasagreiningu:

• Við dreifum svarendum yfir n-vídd rými þar sem hnit hvers svaranda eru svör þeirra við spurningum.
• Hver svarandi er lýstur lítill klasi.
• Við sameinum tvo klasa næst hvor öðrum í einn stærri klasa.
• Við finnum næsta par af þyrpingum og sameinum þá í stærri þyrping.

Þannig flokkum við alla svarendur okkar í þann fjölda klasa sem við þurfum. Með hjálp dendrogram (tré tenginga milli klasa) sjáum við fjarlægðina milli tveggja nálægra klasa. Það eina sem er eftir fyrir okkur er að setja ákveðin fjarlægðarmörk á milli þessara þyrpinga og segja: "Þessir tveir hópar eru alveg aðgreindir hver frá öðrum því fjarlægðin á milli þeirra er risavaxin."

En hér er falið vandamál: við höfum engar takmarkanir á fjölda klasa - við getum fengið 2, 3, 4, 10 klasa. Og fyrsta hugmyndin var - hvers vegna ekki að skipta öllum svarendum okkar í 4 hópa, eins og DORA gerir. En við komumst að því að munurinn á þessum hópum verður óverulegur og við getum ekki verið viss um að svarandinn tilheyri sínum hópi í raun og veru en ekki nágrannahópnum. Við getum ekki enn skipt rússneska markaðnum í fjóra hópa. Þess vegna komumst við að þremur sniðum þar sem tölfræðilega marktækur munur er á milli:

Næst ákváðum við sniðið eftir klösum: við tókum miðgildið fyrir hvern mælikvarða fyrir hvern hóp og tókum saman töflu yfir frammistöðusnið. Reyndar fengum við frammistöðusnið meðal þátttakanda í hverjum hópi. Við höfum bent á þrjú skilvirknisnið: Lágt, miðlungs, hátt:

Hér staðfestum við tilgátu okkar um að 4 lykilmælikvarðar henti til að ákvarða frammistöðusniðið og þeir virka bæði á vestrænum og rússneskum mörkuðum. Það er munur á hópunum og er hann tölfræðilega marktækur. Ég legg áherslu á að það er marktækur munur á frammistöðusniðunum hvað varðar mælikvarða misheppnaðra breytinga hvað varðar meðaltal, jafnvel þó að við höfum ekki deilt svarendum með þessari breytu í upphafi.

Þá vaknar spurningin: hvernig á að nota allt þetta?

Hvernig á að nota

Ef við tökum eitthvert lið, 4 lykiltölur og notum það á töfluna, þá fáum við í 85% tilvika ekki fullkomna samsvörun - þetta er bara meðalþátttakandi, en ekki það sem er í raun og veru. Við erum öll (og hvert lið) aðeins öðruvísi.

Við athuguðum: Við tókum svarendur okkar og DORA frammistöðuprófílinn og skoðuðum hversu margir svarendur passa við þennan eða hinn prófílinn. Við komumst að því að aðeins 16% svarenda féllu örugglega inn í eitt prófílanna. Allt hitt er á víð og dreif einhvers staðar á milli:

Þetta þýðir að skilvirknisniðið hefur takmarkað umfang. Til að skilja hvar þú ert í fyrstu nálguninni geturðu notað þessa töflu: „Ó, það virðist sem við séum nær Medium eða High! Ef þú skilur hvert þú átt að fara næst gæti þetta verið nóg. En ef markmið þitt er stöðugar, stöðugar umbætur og þú vilt vita nákvæmlega hvar þú átt að þróa og hvað þú átt að gera, þá þarf viðbótarfjármagn. Við kölluðum þá reiknivélar:

• DORA reiknivél
• Reiknivél Express 42* (í þróun)
• Eigin þróun (þú getur búið til þinn eigin innri reiknivél).

Til hvers eru þau nauðsynleg? Að skilja:

• Er liðið innan stofnunarinnar okkar í samræmi við staðla okkar?
• Ef ekki, getum við aðstoðað það, hraðað því innan ramma þeirrar sérfræðiþekkingar sem fyrirtækið okkar býr yfir?
• Ef svo er, getum við gert enn betur?

Þú getur líka notað þær til að safna tölfræði innan fyrirtækisins:

• Hvaða lið erum við með?
• Skiptu liðum í snið;
• Sjá: Ó, þessar skipanir standa sig ekki mikið (þær dragast ekki út smá), en þessar eru flottar: þær birtast á hverjum degi, án villna, þær hafa innan við klukkutíma afgreiðslutíma.

Og þá geturðu komist að því að innan fyrirtækisins okkar er nauðsynleg sérfræðiþekking og verkfæri fyrir þau teymi sem eru ekki enn á pari.

Eða ef þú skilur að þér líður vel innan fyrirtækisins, þú ert betri en margir, þá geturðu litið aðeins víðar. Þetta er bara rússneski iðnaðurinn: getum við fengið nauðsynlega sérfræðiþekkingu í rússneskum iðnaði til að hraða okkur? Express 42 reiknivélin mun hjálpa hér (hún er í þróun). Ef þú hefur vaxið fram úr rússneska markaðnum, skoðaðu þá DORA reiknivél og á heimsmarkaði.

Fínt. Og ef þú ert í Elit hópnum á DORA reiknivélinni, hvað ættir þú að gera? Hér er engin góð lausn. Þú ert líklega í fararbroddi í greininni og frekari hröðun og áreiðanleiki er möguleg með innri rannsóknum og þróun og að eyða meira fjármagni.

Við skulum halda áfram að sætasta - samanburðinum.

Samanburður

Við vildum í upphafi bera rússneskan iðnað saman við vestrænan iðnað. Ef við berum beint saman sjáum við að við höfum færri snið og þau eru aðeins meira blanduð innbyrðis, landamærin eru aðeins óskýrari:

Elite flytjendur okkar eru falnir meðal High performers, en þeir eru þarna - þetta eru Elite, einhyrningarnir sem hafa náð verulegum hæðum. Í Rússlandi er munurinn á Elite prófílnum og High profile ekki enn nógu marktækur. Við teljum að í framtíðinni muni þessi aðskilnaður eiga sér stað vegna aukinnar verkfræðimenningar, gæða framkvæmdar verkfræðiaðferða og sérfræðiþekkingar innan fyrirtækja.

Ef við förum yfir í beinan samanburð innan rússneska iðnaðarins getum við séð að High profile liðin eru betri í alla staði. Við staðfestum einnig tilgátu okkar um að það sé tengsl á milli þessara mælikvarða og frammistöðu skipulagsheildar: Hátt áberandi teymi eru mun líklegri til að ná ekki aðeins markmiðum heldur fara fram úr þeim.
Verðum háttsett lið og hættum ekki þar:

En þetta ár er sérstakt og við ákváðum að athuga hvernig fyrirtækjum gengur í heimsfaraldri: Áberandi teymi standa sig miklu betur og líður betur en meðaltal iðnaðarins:

• 1,5-2 sinnum líklegri til að gefa út nýjar vörur,
• 2 sinnum líklegri til að bæta áreiðanleika og/eða frammistöðu innviða forritsins.

Það er að segja, hæfnin sem þeir höfðu þegar hjálpað þeim að þróa hraðar, setja nýjar vörur á markað, breyta núverandi vörum og sigra þar með nýja markaði og nýja notendur:

Hvað annað hjálpaði liðunum okkar?

Verkfræðihættir

Ég mun segja þér frá mikilvægum niðurstöðum fyrir hverja æfingu sem við prófuðum. Kannski eitthvað annað hjálpaði liðunum, en við erum að tala um DevOps. Og innan DevOps sjáum við mun á teymum með mismunandi snið.

Platform sem þjónusta

Við fundum ekki marktækt samband á milli aldurs vettvangs og liðssniðs: Pallarnir birtust á svipuðum tíma fyrir bæði láglið og hálið. En fyrir hið síðarnefnda veitir pallurinn að meðaltali meiri þjónustu og fleiri forritunarviðmót til að stjórna með forritskóða. Og vettvangsteymi eru líklegri til að hjálpa hönnuðum sínum og teymum að nota vettvanginn, leysa vandamál sín og vettvangstengd atvik oftar og fræða önnur teymi.

Innviðir sem kóða

Hér er allt frekar staðlað. Við höfum fundið tengsl á milli sjálfvirkrar vinnu innviðakóðans og hversu mikið af upplýsingum eru geymdar inni í innviðageymslunni. Hásniðsskipanirnar geyma frekari upplýsingar í geymslunum: þetta er uppsetning innviða, CI / CD leiðsla, umhverfisstillingar og byggingarfæribreytur. Þeir geyma þessar upplýsingar oftar, vinna betur með innviðakóða og gera sjálfvirkan fleiri ferla og verkefni til að vinna með innviðakóða.

Athyglisvert er að við sáum ekki marktækan mun á innviðaprófunum. Ég rekja þetta til þess að áberandi teymi hafa almennt meiri próf sjálfvirkni. Kannski ætti ekki að trufla þá sérstaklega með innviðaprófum, heldur þeim prófum sem þeir skoða forrit með og þökk sé þeim sjá þeir nú þegar hvað og hvar þeir hafa bilað.

Samþætting og afhending

Leiðinlegasti hlutinn, vegna þess að við staðfestum að því meiri sjálfvirkni sem þú hefur, því betur sem þú vinnur með kóðann, því meiri líkur eru á að þú náir betri árangri.

arkitektúr

Við vildum sjá hvernig örþjónustur hafa áhrif á árangur. Í sannleika sagt gera þeir það ekki, þar sem notkun örþjónustu tengist ekki aukningu á frammistöðuvísum. Örþjónustur eru notaðar fyrir bæði High profile skipanir og Low profile skipanir.

En það sem er þýðingarmikið er að fyrir High-teymi gerir umskiptin yfir í örþjónustuarkitektúr þeim kleift að þróa þjónustu sína sjálfstætt og setja út. Ef arkitektúrinn gerir forriturum kleift að starfa sjálfstætt, án þess að bíða eftir einhverjum utan teymisins, þá er þetta lykilhæfni til að auka hraða. Í þessu tilviki hjálpa örþjónustur. Og bara framkvæmd þeirra spilar ekki stórt hlutverk.

Hvernig uppgötvuðum við þetta allt?

Við vorum með metnaðarfulla áætlun um að endurtaka DORA aðferðafræðina að fullu, en skorti fjármagn. Ef DORA notar mikið af kostun og rannsóknir þeirra taka hálft ár, þá gerðum við okkar rannsóknir á stuttum tíma. Okkur langaði að smíða DevOps líkan eins og DORA gerir og við munum gera það í framtíðinni. Hingað til höfum við takmarkað okkur við hitakort:

Við skoðuðum dreifingu verkfræðiaðferða yfir teymi í hverjum prófíl og komumst að því að áberandi teymi voru að meðaltali líklegri til að nota verkfræðiaðferðir. Þú getur lesið meira um þetta allt í okkar skýrsla.

Til tilbreytingar skulum við skipta úr flókinni tölfræði yfir í einfaldar.

Hvað annað höfum við uppgötvað?

Verkfæri

Við sjáum að flestar skipanirnar eru notaðar af stýrikerfi Linux fjölskyldunnar. En Windows er enn í þróun - að minnsta kosti fjórðungur svarenda okkar benti á notkun einnar eða annarrar útgáfur þess. Svo virðist sem markaðurinn hafi þessa þörf. Þess vegna er hægt að þróa þessa hæfni og halda kynningar á ráðstefnum.

Meðal hljómsveitarstjóra er það ekki leyndarmál fyrir neinn, Kubernetes er í fararbroddi (52%). Næsti hljómsveitarstjóri er Docker Swarm (um 12%). Vinsælustu CI kerfin eru Jenkins og GitLab. Vinsælasta stillingarstjórnunarkerfið er Ansible, á eftir okkar ástkæra Shell.

Amazon er sem stendur leiðandi skýhýsingaraðili. Hlutur rússneskra skýja eykst smám saman. Á næsta ári verður áhugavert að sjá hvernig rússneskum skýjaveitum mun líða, hvort markaðshlutdeild þeirra muni aukast. Þeir eru, þeir geta verið notaðir, og það er gott:

Ég gef orðið til Igor, sem mun gefa frekari tölfræði.

Miðlun starfsvenja

Igor Kurochkin: Sérstaklega báðum við svarendur að gefa til kynna hvernig íhuguðum verkfræðiaðferðum er dreift í fyrirtækinu. Í flestum fyrirtækjum er blönduð nálgun, sem samanstendur af mismunandi mynstrum, og tilraunaverkefni eru mjög vinsæl. Við sáum líka smá mun á sniðunum. Fulltrúar High profile nota oftar mynstrið „Frumkvæði að neðan“ þegar lítil teymi sérfræðinga breyta vinnuferlum, verkfærum og deila farsælum starfsháttum með öðrum teymum. Hjá Medium er þetta frumkvæði að ofan og niður sem hefur áhrif á allt fyrirtækið með stofnun samfélaga og öndvegismiðstöðva:

Agile og DevOps

Spurningin um tengsl Agile og DevOps er oft rædd í greininni. Þetta mál er einnig tekið upp í State of Agile Report fyrir 2019/2020, svo við ákváðum að bera saman hvernig Agile og DevOps starfsemi er tengd í fyrirtækjum. Við komumst að því að DevOps án Agile er sjaldgæft. Hjá helmingi svarenda byrjaði útbreiðsla Agile mun fyrr og um 20% fylgdust með því að byrjað var samtímis, og eitt af einkennunum um lágt snið er skortur á Agile og DevOps venjum:

Skipunarstaðir

Í lok síðasta árs kom bókinStaðfræði liðsins”, sem leggur til ramma til að lýsa stjórnskipulagi. Það varð áhugavert fyrir okkur hvort það ætti við um rússnesk fyrirtæki. Og við spurðum spurningarinnar: "Hvaða mynstur finnur þú?".

Fylgst er með innviðateymum hjá helmingi svarenda, sem og sérstökum teymum fyrir þróun, prófun og rekstur. Aðskilin DevOps teymi bentu á 45%, þar á meðal eru fulltrúar High algengari. Næst koma þvervirk teymi, sem eru líka algengari hjá High. Aðskildar SRE skipanir birtast í High, Medium sniðunum og sjást sjaldan í Low sniðinu:

DevQaOps hlutfall

Við sáum þessa spurningu á Facebook frá liðsstjóra Skyeng vettvangsteymisins - hann hafði áhuga á hlutfalli þróunaraðila, prófunaraðila og stjórnenda í fyrirtækjum. Við spurðum það og skoðuðum svörin út frá prófílum: Háir fulltrúar hafa færri prófunar- og rekstrarfræðinga fyrir hvern þróunaraðila:

Áætlun fyrir 2021 ár

Í áætlunum fyrir næsta ár bentu svarendur á eftirfarandi starfsemi:

Hér má sjá gatnamótin við DevOps Live 2020 ráðstefnuna. Við fórum vandlega yfir dagskrána:

• Innviðir sem vara
• DevOps umbreyting
• Dreifing á DevOps starfsháttum
• DevSecOps
• Málaklúbbar og umræður

En tími kynningar okkar er ekki nægur til að ná yfir öll efnin. Eftir á bak við tjöldin:

• Pall sem þjónusta og sem vara;
• Innviðir sem kóða, umhverfi og ský;
• Stöðug samþætting og afhending;
• Arkitektúr;
• DevSecOps mynstur;
• Pallur og þvervirk teymi.

Skýrsla við fengum fyrirferðarmikla, 50 síður, og þú getur séð það nánar.

Toppur upp

Við vonum að rannsóknir okkar og skýrsla muni hvetja þig til að gera tilraunir með nýjar aðferðir við þróun, prófanir og rekstur, auk þess að hjálpa þér að fletta, bera þig saman við aðra þátttakendur í rannsókninni og finna svæði þar sem þú getur bætt eigin nálgun.

Niðurstöður fyrstu rannsóknarinnar á ástandi DevOps í Rússlandi:

• Helstu mælikvarðar. Við höfum komist að því að lykilmælikvarðar (afhendingartími, dreifingartíðni, endurheimtartími og breytingarbilanir) henta til að greina skilvirkni þróunar-, prófunar- og rekstrarferla.
• Snið hár, miðlungs, lág. Byggt á söfnuðu gögnunum getum við greint tölfræðilega mismunandi hópa af háum, miðlungs, lágum með sérkennum hvað varðar mælikvarða, starfshætti, ferla og verkfæri. Fulltrúar High profile sýna betri árangur en Low. Þeir eru líklegri til að ná og fara yfir markmið sín.
• Vísar, heimsfaraldur og áætlanir fyrir árið 2021. Sérstakur vísir í ár er hvernig fyrirtæki brugðust við heimsfaraldrinum. Háu fulltrúarnir stóðu sig betur, upplifðu aukna notendaþátttöku og helstu ástæður velgengni voru skilvirkt þróunarferli og sterk verkfræðimenning.
• DevOps starfshættir, verkfæri og þróun þeirra. Helstu áætlanir fyrirtækja fyrir næsta ár fela í sér þróun á DevOps starfsháttum og verkfærum, innleiðingu á DevSecOps starfsháttum og breytingar á skipulagi. Og skilvirk innleiðing og þróun DevOps starfsvenja fer fram með hjálp tilraunaverkefna, myndun samfélaga og öndvegissetur, frumkvæði á efri og neðri stigum fyrirtækisins.

Við viljum gjarnan heyra álit þitt, sögur, álit. Við þökkum öllum sem tóku þátt í rannsókninni og hlökkum til þátttöku á næsta ári.

Heimild: www.habr.com