Hali ya DevOps nchini Urusi 2020

Jinsi ya kuelewa hali ya kitu?

Unaweza kutegemea maoni yako, yaliyoundwa kutoka kwa vyanzo mbalimbali vya habari, kwa mfano, machapisho kwenye tovuti au uzoefu. Unaweza kuuliza wenzako, marafiki. Chaguo jingine ni kuangalia mada za mikutano: kamati ya programu ni wawakilishi hai wa tasnia, kwa hivyo tunawaamini katika kuchagua mada zinazofaa. Eneo tofauti ni utafiti na ripoti. Lakini kuna tatizo. Utafiti juu ya hali ya DevOps unafanywa kila mwaka ulimwenguni, ripoti zinachapishwa na makampuni ya kigeni, na karibu hakuna taarifa kuhusu DevOps ya Kirusi.

Lakini siku imefika ambapo utafiti kama huo ulifanyika, na leo tutazungumza juu ya matokeo. Hali ya DevOps nchini Urusi ilisomwa kwa pamoja na kampuni "Express 42"Na"Ontiko". Express 42 husaidia makampuni ya teknolojia kutekeleza na kuendeleza mbinu na zana za DevOps na ilikuwa mojawapo ya wa kwanza kuzungumza kuhusu DevOps nchini Urusi. Waandishi wa utafiti, Igor Kurochkin na Vitaly Khabarov, wanahusika katika uchambuzi na ushauri katika Express 42, huku wakiwa na historia ya kiufundi kutokana na uendeshaji na uzoefu katika makampuni mbalimbali. Kwa miaka 8, wenzake wameangalia kadhaa ya makampuni na miradi - kutoka startups kwa makampuni ya biashara - na matatizo tofauti, pamoja na ukomavu tofauti wa kitamaduni na uhandisi.

Katika ripoti yao, Igor na Vitaly waliambia ni shida gani zilikuwa katika mchakato wa utafiti, jinsi walivyotatua, na vile vile utafiti wa DevOps unafanywa kimsingi na kwa nini Express 42 iliamua kufanya yake. Ripoti yao inaweza kutazamwa hapa.

Utafiti wa DevOps

Mazungumzo yalianzishwa na Igor Kurochkin.

Tunauliza hadhira mara kwa mara kwenye mikutano ya DevOps, "Je, umesoma ripoti ya hali ya DevOps ya mwaka huu?" Wachache huinua mikono yao, na uchunguzi wetu ulionyesha kwamba ni theluthi pekee iliyowachunguza. Ikiwa hujawahi kuona ripoti kama hizo, wacha tuseme mara moja kwamba zote zinafanana sana. Mara nyingi kuna misemo kama: "Ikilinganishwa na mwaka jana ..."

Hapa tunayo shida ya kwanza, na baada yake mbili zaidi:

1. Hatuna data ya mwaka jana. Hali ya DevOps nchini Urusi haina maslahi kwa mtu yeyote;
2. Mbinu. Si wazi jinsi ya kupima hypotheses, jinsi ya kujenga maswali, jinsi ya kuchambua, kulinganisha matokeo, kupata uhusiano;
3. Istilahi. Ripoti zote ziko kwa Kiingereza, tafsiri inahitajika, mfumo wa kawaida wa DevOps bado haujavumbuliwa na kila mtu anakuja na yake.

Hebu tuangalie jinsi uchambuzi wa hali ya DevOps umefanywa kote ulimwenguni.

historia

Utafiti wa DevOps umefanywa tangu 2011. Puppet, msanidi wa mifumo ya usimamizi wa usanidi, alikuwa wa kwanza kuiendesha. Wakati huo, ilikuwa moja ya zana kuu za kuelezea miundombinu katika mfumo wa nambari. Hadi 2013, tafiti hizi zilikuwa tafiti zilizofungwa tu na hakuna ripoti za umma.

Mnamo 2013, Mapinduzi ya IT yalionekana, mchapishaji wa vitabu vyote kuu kwenye DevOps. Pamoja na Puppet, walitayarisha uchapishaji wa kwanza wa State of DevOps, ambapo metriki 4 muhimu zilionekana kwa mara ya kwanza. Mwaka uliofuata, ThoughtWorks, kampuni ya ushauri inayojulikana kwa rada zake za kawaida za teknolojia kwenye mazoea ya tasnia na zana, ilihusika. Na mnamo 2015, sehemu iliyo na mbinu iliongezwa, na ikawa wazi jinsi wanavyofanya uchambuzi.

Mnamo 2016, waandishi wa utafiti huo, baada ya kuunda kampuni yao ya DORA (Utafiti na Tathmini ya DevOps), walichapisha ripoti ya kila mwaka. Mwaka uliofuata, DORA na Puppet walitoa ripoti yao ya mwisho ya pamoja.

Na kisha kitu cha kuvutia kikaanza:

Mnamo 2018, kampuni ziligawanyika na ripoti mbili huru zilitolewa: moja kutoka kwa Puppet, ya pili kutoka DORA pamoja na Google. DORA imeendelea kutumia mbinu yake kwa kutumia vipimo muhimu, wasifu wa utendakazi, na mazoea ya uhandisi ambayo huathiri metriki muhimu na utendaji wa kampuni nzima. Na Puppet alitoa mbinu yake mwenyewe na maelezo ya mchakato na mageuzi ya DevOps. Lakini hadithi haikukita mizizi, mnamo 2019 Puppet aliachana na mbinu hii na akatoa toleo jipya la ripoti, ambalo liliorodhesha mazoea muhimu na jinsi yanavyoathiri DevOps kutoka kwa maoni yao. Kisha tukio lingine likatokea: Google ilinunua DORA, na kwa pamoja wakatoa ripoti nyingine. Huenda umemwona.

Mwaka huu, mambo yamekuwa magumu. Puppet inajulikana kuwa ilizindua uchunguzi wake mwenyewe. Walifanya hivyo wiki moja mapema kuliko sisi, na tayari imekwisha. Tulishiriki ndani yake na tukaangalia ni mada gani wanavutiwa nayo. Sasa Puppet anafanya uchambuzi wake na anajitayarisha kuchapisha ripoti hiyo.

Lakini bado hakuna tangazo kutoka kwa DORA na Google. Mnamo Mei, uchunguzi ulipoanza, habari zilikuja kwamba Nicole Forsgren, mmoja wa waanzilishi wa DORA, alikuwa amehamia kampuni nyingine. Kwa hivyo, tulidhani kwamba hakutakuwa na utafiti na ripoti kutoka DORA mwaka huu.

Mambo vipi nchini Urusi?

Hatujafanya utafiti wa DevOps. Tulizungumza kwenye mikutano, tukieleza upya matokeo ya watu wengine, na Raiffeisenbank ilitafsiri "State of DevOps" kwa mwaka wa 2019 (unaweza kupata tangazo lao kwenye Habré), shukrani nyingi kwao. Na ni yote.

Kwa hiyo, tulifanya utafiti wetu wenyewe nchini Urusi kwa kutumia mbinu na matokeo ya DORA. Tulitumia ripoti ya wenzetu kutoka Raiffeisenbank kwa utafiti wetu, ikijumuisha kusawazisha istilahi na tafsiri. Na maswali yanayohusiana na tasnia yalichukuliwa kutoka kwa ripoti za DORA na dodoso la Puppet la mwaka huu.

Mchakato wa Utafiti

Ripoti ni sehemu ya mwisho tu. Mchakato mzima wa utafiti una hatua nne kuu:

Wakati wa awamu ya maandalizi, tuliwahoji wataalam wa sekta na kuandaa orodha ya dhana. Kwa msingi wao, maswali yalikusanywa na uchunguzi ulizinduliwa kwa mwezi mzima wa Agosti. Kisha tukaichambua na kuitayarisha ripoti yenyewe. Kwa DORA, mchakato huu unachukua miezi 6. Tulikutana ndani ya miezi 3, na sasa tunaelewa kuwa tulikuwa na wakati wa kutosha: ni kwa kufanya uchambuzi tu ndipo unaelewa ni maswali gani unahitaji kuuliza.

Wajumbe

Ripoti zote za kigeni huanza na picha ya washiriki, na wengi wao sio kutoka Urusi. Asilimia ya washiriki wa Kirusi hubadilika kutoka 5 hadi 1% mwaka hadi mwaka, na hii hairuhusu hitimisho lolote kufanywa.

Ramani kutoka kwa Ripoti ya Kuharakisha Hali ya DevOps 2019:

Katika utafiti wetu, tuliweza kuhoji watu 889 - hii ni mengi sana (kura za DORA kuhusu watu elfu kila mwaka katika ripoti zake) na hapa tumefikia lengo:

Ukweli, sio washiriki wetu wote waliofikia mwisho: asilimia ya kukamilika iligeuka kuwa chini ya nusu. Lakini hata hii ilitosha kupata sampuli ya mwakilishi na kufanya uchambuzi. DORA haifichui asilimia ya kujaza katika ripoti zake, kwa hivyo hakuna ulinganisho hapa.

Viwanda na nafasi

Waliojibu wetu wanawakilisha viwanda kadhaa. Nusu ya kazi katika teknolojia ya habari. Hii inafuatiwa na huduma za kifedha, biashara, mawasiliano ya simu na mengine. Miongoni mwa nafasi hizo ni wataalamu (msanidi programu, mjaribu, mhandisi wa operesheni) na wafanyikazi wa usimamizi (wakuu wa timu, vikundi, maeneo, wakurugenzi):

Mmoja kati ya wawili anafanya kazi kwa kampuni ya ukubwa wa kati. Kila mtu wa tatu anafanya kazi katika makampuni makubwa. Wengi hufanya kazi katika timu za hadi watu 9. Kando, tuliuliza juu ya shughuli kuu, na nyingi zinahusiana kwa namna fulani na operesheni, na karibu 40% wanahusika katika maendeleo:

Kwa hivyo tulikusanya habari kwa kulinganisha na uchambuzi wa wawakilishi wa tasnia tofauti, kampuni, timu. Mwenzangu Vitaly Khabarov atasema juu ya uchambuzi.

Uchambuzi na kulinganisha

Vitaly Khabarov: Shukrani nyingi kwa washiriki wote waliokamilisha uchunguzi wetu, walijaza dodoso na kutupa data kwa uchambuzi zaidi na majaribio ya nadharia zetu. Na shukrani kwa wateja na wateja wetu, tuna uzoefu mwingi ambao umesaidia kutambua maswala ya tasnia na kuunda dhana tulizojaribu katika utafiti wetu.

Kwa bahati mbaya, huwezi kuchukua tu orodha ya maswali kwa upande mmoja na data kwa upande mwingine, kwa namna fulani kulinganisha, sema: "Ndio, kila kitu kinafanya kazi kama hiyo, tulikuwa sahihi" na kutawanya. Hapana, tunahitaji mbinu na mbinu za takwimu ili kuwa na uhakika kwamba hatujakosea na hitimisho letu ni la kutegemewa. Kisha tunaweza kuunda kazi yetu zaidi kulingana na data hizi:

Vipimo muhimu

Tulichukua mbinu ya DORA kama msingi, ambayo walielezea kwa undani katika kitabu "Accelerate State of DevOps". Tulikagua ikiwa metriki muhimu zinafaa kwa soko la Urusi, ikiwa zinaweza kutumika kwa njia sawa na DORA hutumia kujibu swali: "Sekta nchini Urusi inalinganaje na tasnia ya kigeni?"

Vipimo muhimu:

1. Mzunguko wa upelekaji. Ni mara ngapi toleo jipya la programu hutumwa kwa mazingira ya uzalishaji (mabadiliko yaliyopangwa, bila kujumuisha marekebisho motomoto na majibu ya matukio)?
2. Wakati wa utoaji. Ni wakati gani wa wastani kati ya kufanya mabadiliko (utendaji wa uandishi kama nambari) na kupeleka mabadiliko kwenye mazingira ya uzalishaji?
3. muda wa kurejesha. Je, inachukua muda gani kwa wastani kurejesha programu katika mazingira ya utayarishaji baada ya tukio, uharibifu wa huduma au ugunduzi wa hitilafu inayoathiri watumiaji wa programu?
4. Mabadiliko yasiyofanikiwa. Ni asilimia ngapi ya utumaji katika mazingira ya uzalishaji husababisha uharibifu wa programu au matukio na kuhitaji urekebishaji (urejeshaji wa mabadiliko, uundaji wa hotfix au kiraka)?

DORA katika utafiti wake imepata uhusiano kati ya vipimo hivi na utendaji wa shirika. Pia tunaijaribu katika somo letu.

Lakini ili kuhakikisha kuwa metriki nne muhimu zinaweza kuathiri kitu, unahitaji kuelewa - je, zinahusiana kwa namna fulani? DORA ilijibu kwa uthibitisho kwa tahadhari moja: uhusiano kati ya mabadiliko ambayo hayajafaulu (Badilisha Kiwango cha Kushindwa) na vipimo vingine vitatu ni dhaifu kidogo. Tulipata picha sawa. Ikiwa muda wa uwasilishaji, marudio ya utumaji, na muda wa kurejesha unahusiana (tulianzisha uwiano huu kupitia uunganisho wa Pearson na kupitia mizani ya Chaddock), basi hakuna uwiano mkubwa kama huo na mabadiliko ambayo hayajafaulu.

Kimsingi, wengi wa wahojiwa huwa na mwelekeo wa kujibu kuwa wana idadi ndogo ya matukio katika uzalishaji. Ingawa tutaona baadaye kwamba bado kuna tofauti kubwa kati ya vikundi vya waliojibu kuhusu mabadiliko ambayo hayajafanikiwa, bado hatuwezi kutumia kipimo hiki kwa kitengo hiki.

Tunahusisha hili kwa ukweli kwamba (kama ilivyotokea wakati wa uchambuzi na mawasiliano na baadhi ya wateja wetu) kuna tofauti kidogo katika mtazamo wa kile kinachochukuliwa kuwa tukio. Ikiwa tuliweza kurejesha utendaji wa huduma yetu wakati wa dirisha la kiufundi, je, hii inaweza kuchukuliwa kuwa tukio? Pengine si, kwa sababu sisi fasta kila kitu, sisi ni kubwa. Je, tunaweza kulichukulia kama tukio ikiwa tulilazimika kusajili upya maombi yetu mara 10 katika hali ya kawaida, tunayoizoea? Inaonekana sivyo. Kwa hiyo, swali la uhusiano wa mabadiliko yasiyofanikiwa na metrics nyingine bado wazi. Tutaiboresha zaidi.

Muhimu hapa ni kwamba tulipata uwiano mkubwa kati ya nyakati za kujifungua, muda wa urejeshaji, na marudio ya matumizi. Kwa hivyo, tulichukua vipimo hivi vitatu ili kuwagawanya zaidi waliojibu katika vikundi vya utendakazi.

Ni kiasi gani cha kunyongwa katika gramu?

Tulitumia uchanganuzi wa nguzo za daraja:

• Tunasambaza wajibu juu ya nafasi ya n-dimensional, ambapo uratibu wa kila mhojiwa ni majibu yao kwa maswali.
• Kila mhojiwa anatangazwa kuwa nguzo ndogo.
• Tunachanganya makundi mawili yaliyo karibu zaidi kwa kila mmoja kwenye nguzo moja kubwa.
• Tunapata jozi inayofuata ya makundi na kuchanganya katika kundi kubwa zaidi.

Hivi ndivyo tunavyoweka wahojiwa wetu wote katika idadi ya makundi tunayohitaji. Kwa msaada wa dendrogram (mti wa uhusiano kati ya makundi), tunaona umbali kati ya makundi mawili ya jirani. Kilichobaki kwetu ni kuweka kikomo cha umbali fulani baina ya makundi haya na kusema: "Makundi haya mawili yanatofautiana kwa sababu umbali kati yao ni mkubwa."

Lakini kuna shida iliyofichwa hapa: hatuna vizuizi kwa idadi ya vikundi - tunaweza kupata nguzo 2, 3, 4, 10. Na wazo la kwanza lilikuwa - kwa nini tusiwagawanye wahojiwa wetu wote katika vikundi 4, kama DORA inavyofanya. Lakini tuligundua kwamba tofauti kati ya makundi haya inakuwa ndogo, na hatuwezi kuwa na uhakika kwamba mhojiwa kweli ni wa kundi lake, na si wa jirani. Bado hatuwezi kugawanya soko la Urusi katika vikundi vinne. Kwa hivyo, tulikaa kwenye profaili tatu ambazo kuna tofauti kubwa ya kitakwimu:

Kisha, tulibainisha wasifu kwa makundi: tulichukua wastani kwa kila kipimo kwa kila kikundi na tukakusanya jedwali la wasifu wa utendakazi. Kwa kweli, tulipata wasifu wa utendaji wa mshiriki wastani katika kila kikundi. Tumetambua profaili tatu za ufanisi: Chini, Kati, Juu:

Hapa tulithibitisha dhana yetu kwamba vipimo 4 muhimu vinafaa kwa ajili ya kubainisha wasifu wa utendakazi, na vinafanya kazi katika masoko ya Magharibi na Urusi. Kuna tofauti kati ya vikundi na ni muhimu kitakwimu. Ninasisitiza kuwa kuna tofauti kubwa kati ya wasifu wa utendakazi kulingana na kipimo cha mabadiliko ambayo hayajafanikiwa kulingana na wastani, ingawa mwanzoni hatukugawanya waliojibu kwa kigezo hiki.

Kisha swali linatokea: jinsi ya kutumia haya yote?

Jinsi ya kutumia

Ikiwa tutachukua timu yoyote, metrics 4 muhimu na kuitumia kwenye jedwali, basi katika 85% ya kesi hatutapata mechi kamili - huyu ni mshiriki wa wastani, na sio ukweli. Sisi sote (na kila timu) ni tofauti kidogo.

Tuliangalia: tulichukua wahojiwa wetu na wasifu wa utendaji wa DORA, na tukaangalia ni wangapi waliojibu wanaofaa hii au wasifu huo. Tuligundua kuwa ni 16% tu ya waliohojiwa walianguka katika mojawapo ya wasifu. Wengine wote wametawanyika mahali fulani kati:

Hii ina maana kwamba wasifu wa ufanisi una upeo mdogo. Ili kuelewa mahali ulipo katika makadirio ya kwanza, unaweza kutumia jedwali hili: "Lo, inaonekana tuko karibu na Kati au Juu!" Ikiwa unaelewa wapi pa kwenda, hii inaweza kuwa ya kutosha. Lakini ikiwa lengo lako ni la mara kwa mara, uboreshaji unaoendelea, na unataka kujua zaidi mahali pa kuendeleza na nini cha kufanya, basi fedha za ziada zinahitajika. Tuliwaita mahesabu:

• Kikokotoo cha DORA
• Calculator Express 42* (inatengenezwa)
• Ukuzaji mwenyewe (unaweza kuunda kikokotoo chako cha ndani).

Wanahitajika kwa ajili gani? Kuelewa:

• Je, timu ndani ya shirika letu inafikia viwango vyetu?
• Ikiwa sivyo, tunaweza kuisaidia, kuharakisha ndani ya mfumo wa utaalamu ambao kampuni yetu inayo?
• Ikiwa ndivyo, je, tunaweza kufanya vizuri zaidi?

Unaweza pia kuzitumia kukusanya takwimu ndani ya kampuni:

• Je, tuna timu gani?
• Gawanya timu katika wasifu;
• Tazama: Oh, amri hizi hazifanyi kazi vizuri (hazitoi kidogo), lakini hizi ni baridi: zinasambaza kila siku, bila makosa, zina muda wa chini wa saa moja.

Na kisha unaweza kujua kuwa ndani ya kampuni yetu kuna utaalamu na zana muhimu kwa timu hizo ambazo bado hazijafikia kiwango.

Au, ikiwa unaelewa kuwa unajisikia vizuri ndani ya kampuni, wewe ni bora kuliko wengi, basi unaweza kuangalia kidogo zaidi. Hii ni sekta ya Kirusi tu: tunaweza kupata ujuzi muhimu katika sekta ya Kirusi ili kuharakisha sisi wenyewe? Kikokotoo cha Express 42 kitasaidia hapa (iko chini ya maendeleo). Ikiwa umezidi soko la Kirusi, basi angalia Kikokotoo cha DORA na soko la dunia.

Sawa. Na ikiwa uko katika kikundi cha Elit kwenye kikokotoo cha DORA, unapaswa kufanya nini? Hakuna suluhisho nzuri hapa. Una uwezekano mkubwa wa kuwa mstari wa mbele katika tasnia, na kuongeza kasi na kutegemewa kunawezekana kupitia R&D ya ndani na kutumia rasilimali zaidi.

Wacha tuendelee kwa tamu zaidi - kulinganisha.

Kulinganisha

Hapo awali tulitaka kulinganisha tasnia ya Urusi na tasnia ya Magharibi. Ikiwa tunalinganisha moja kwa moja, tunaona kuwa tuna maelezo mafupi, na yamechanganywa zaidi na kila mmoja, mipaka ni kidogo zaidi:

Waigizaji wetu wa Wasomi wamefichwa kati ya Wasanii wa Juu, lakini wapo - hawa ni wasomi, nyati ambao wamefikia urefu mkubwa. Huko Urusi, tofauti kati ya wasifu wa Wasomi na Wasifu wa Juu bado sio muhimu vya kutosha. Tunadhani kwamba katika siku zijazo utengano huu utatokea kutokana na ongezeko la utamaduni wa uhandisi, ubora wa utekelezaji wa mazoea ya uhandisi na ujuzi ndani ya makampuni.

Ikiwa tunaendelea kwa kulinganisha moja kwa moja ndani ya sekta ya Kirusi, tunaweza kuona kwamba timu za Wasifu wa Juu ni bora katika mambo yote. Pia tulithibitisha dhana yetu kwamba kuna uhusiano kati ya vipimo hivi na utendaji wa shirika: Timu za wasifu wa juu zina uwezekano mkubwa wa kufikia malengo, lakini pia kuzizidi.
Wacha tuwe timu za wasifu wa Juu na tusiishie hapo:

Lakini mwaka huu ni maalum, na tuliamua kuangalia jinsi kampuni zinavyofanya katika janga: Timu za wasifu wa juu zinafanya vizuri zaidi na zinahisi bora kuliko wastani wa tasnia:

• 1,5-2 mara zaidi uwezekano wa kutolewa bidhaa mpya,
• Uwezekano wa mara 2 zaidi wa kuboresha kutegemewa na/au utendakazi wa miundombinu ya programu.

Hiyo ni, ujuzi ambao tayari walikuwa nao uliwasaidia kukuza haraka, kuzindua bidhaa mpya, kurekebisha bidhaa zilizopo, na hivyo kushinda masoko mapya na watumiaji wapya:

Ni nini kingine kilisaidia timu zetu?

Mazoea ya uhandisi

Nitakuambia juu ya matokeo muhimu kwa kila mazoezi ambayo tulijaribu. Labda kitu kingine kilisaidia timu, lakini tunazungumza juu ya DevOps. Na ndani ya DevOps, tunaona tofauti kati ya timu za wasifu tofauti.

Jukwaa kama Huduma

Hatukupata uhusiano muhimu kati ya umri wa jukwaa na wasifu wa timu: Mifumo ilionekana kwa wakati mmoja kwa timu za Kiwango cha chini na timu za Juu. Lakini kwa mwisho, jukwaa hutoa, kwa wastani, huduma zaidi na miingiliano zaidi ya programu kwa udhibiti kupitia nambari ya programu. Na timu za majukwaa zina uwezekano mkubwa wa kusaidia wasanidi programu na timu zao kutumia mfumo, kutatua matatizo yao na matukio yanayohusiana na jukwaa mara nyingi zaidi, na kuelimisha timu nyingine.

Miundombinu kama kanuni

Kila kitu ni kawaida hapa. Tulipata uhusiano kati ya uwekaji kiotomatiki wa kazi ya msimbo wa miundombinu na ni habari ngapi huhifadhiwa ndani ya hazina ya miundombinu. Amri za Wasifu wa Juu huhifadhi habari zaidi kwenye hazina: huu ni usanidi wa miundombinu, bomba la CI / CD, mipangilio ya mazingira na vigezo vya ujenzi. Wanahifadhi maelezo haya mara nyingi zaidi, hufanya kazi vizuri zaidi na msimbo wa miundombinu, na kubinafsisha michakato na kazi zaidi za kufanya kazi na msimbo wa miundombinu.

Inashangaza, hatukuona tofauti kubwa katika vipimo vya miundombinu. Ninahusisha hii na ukweli kwamba timu za wasifu wa Juu zina otomatiki zaidi ya majaribio kwa ujumla. Labda hawapaswi kuchanganyikiwa tofauti na vipimo vya miundombinu, lakini badala ya vipimo hivyo ambavyo huangalia maombi, na shukrani kwao tayari wanaona nini na wapi wamevunja.

Ujumuishaji na utoaji

Sehemu inayochosha zaidi, kwa sababu tulithibitisha kuwa kadiri unavyokuwa na otomatiki zaidi, ndivyo unavyofanya kazi na msimbo bora zaidi, ndivyo uwezekano wa kupata matokeo bora zaidi.

usanifu

Tulitaka kuona jinsi huduma ndogo huathiri utendakazi. Kwa kweli, hawana, kwani matumizi ya microservices haihusishwa na ongezeko la viashiria vya utendaji. Huduma ndogo hutumika kwa amri zote mbili za Wasifu wa Juu na amri za wasifu wa Chini.

Lakini muhimu ni kwamba kwa timu za Juu, mpito kwa usanifu wa huduma ndogo huwaruhusu kukuza huduma zao kwa uhuru na kuzindua. Ikiwa usanifu unaruhusu watengenezaji kutenda kwa uhuru, bila kungoja mtu wa nje wa timu, basi hii ni uwezo muhimu wa kuongeza kasi. Katika kesi hii, microservices husaidia. Na utekelezaji wao tu hauna jukumu kubwa.

Tumegunduaje haya yote?

Tulikuwa na mpango kabambe wa kuiga kikamilifu mbinu ya DORA, lakini tulikosa rasilimali. Ikiwa DORA inatumia ufadhili mwingi na utafiti wao unachukua nusu mwaka, tulifanya utafiti wetu kwa muda mfupi. Tulitaka kuunda muundo wa DevOps kama DORA hufanya, na tutafanya hivyo katika siku zijazo. Kufikia sasa tumejiwekea kikomo kwa ramani za joto:

Tuliangalia usambazaji wa mbinu za uhandisi katika timu katika kila wasifu na tukagundua kuwa timu za wasifu wa Juu, kwa wastani, zilikuwa na uwezekano mkubwa wa kutumia mbinu za uhandisi. Unaweza kusoma zaidi juu ya haya yote katika nakala yetu ripoti.

Kwa mabadiliko, wacha tubadilike kutoka kwa takwimu ngumu hadi rahisi.

Tumegundua nini kingine?

Vyombo vya

Tunaona kwamba amri nyingi hutumiwa na OS ya familia ya Linux. Lakini Windows bado iko katika mwenendo - angalau robo ya washiriki wetu walibainisha matumizi ya moja au nyingine ya matoleo yake. Inaonekana kwamba soko lina hitaji hili. Kwa hivyo, unaweza kukuza uwezo huu na kufanya mawasilisho kwenye mikutano.

Miongoni mwa waimbaji, sio siri kwa mtu yeyote, Kubernetes anaongoza (52%). Mwimbaji anayefuata katika mstari ni Docker Swarm (karibu 12%). Mifumo maarufu zaidi ya CI ni Jenkins na GitLab. Mfumo maarufu wa usimamizi wa usanidi ni Ansible, ikifuatiwa na Shell yetu pendwa.

Amazon kwa sasa ndiye mtoa huduma anayeongoza wa kukaribisha wingu. Sehemu ya mawingu ya Kirusi inaongezeka hatua kwa hatua. Mwaka ujao itakuwa ya kuvutia kuona jinsi watoa huduma wa wingu wa Kirusi watakavyohisi, ikiwa sehemu yao ya soko itaongezeka. Wao ni, wanaweza kutumika, na hiyo ni nzuri:

Ninapitisha sakafu kwa Igor, ambaye atatoa takwimu zaidi.

Usambazaji wa mazoea

Igor Kurochkin: Kando, tuliwauliza waliojibu waonyeshe jinsi mbinu za uhandisi zinazozingatiwa zinasambazwa katika kampuni. Katika makampuni mengi, kuna mbinu mchanganyiko, yenye seti tofauti ya mwelekeo, na miradi ya majaribio ni maarufu sana. Pia tuliona tofauti kidogo kati ya wasifu. Wawakilishi wa Wasifu wa Juu mara nyingi zaidi hutumia mchoro wa "Mpango kutoka chini", wakati timu ndogo za wataalamu zinabadilisha michakato ya kazi, zana, na kushiriki mazoea yenye mafanikio na timu zingine. Katika Medium, huu ni mpango wa juu chini ambao unaathiri kampuni nzima kupitia uundaji wa jumuiya na vituo vya ubora:

Agile na DevOps

Swali la uhusiano kati ya Agile na DevOps mara nyingi hujadiliwa katika sekta hiyo. Suala hili pia limetolewa katika Ripoti ya Hali ya Agile ya 2019/2020, kwa hivyo tuliamua kulinganisha jinsi shughuli za Agile na DevOps zimeunganishwa katika kampuni. Tuligundua kuwa DevOps bila Agile ni nadra. Kwa nusu ya waliohojiwa, kuenea kwa Agile kulianza mapema zaidi, na karibu 20% waliona kuanza kwa wakati mmoja, na moja ya ishara za Wasifu wa Chini itakuwa kutokuwepo kwa mazoea ya Agile na DevOps:

Topolojia za amri

Mwishoni mwa mwaka jana, kitabuTopolojia za timu”, ambayo inapendekeza mfumo wa kuelezea topolojia za amri. Ilikuwa ya kuvutia kwetu ikiwa inatumika kwa makampuni ya Kirusi. Na tuliuliza swali: "Je! unapata mifumo gani?".

Timu za miundombinu huzingatiwa katika nusu ya waliohojiwa, pamoja na timu tofauti za maendeleo, majaribio na uendeshaji. Timu tofauti za DevOps zilibainisha 45%, kati ya ambayo wawakilishi wa High ni wa kawaida zaidi. Inayofuata inakuja timu zinazofanya kazi mbalimbali, ambazo pia zinajulikana zaidi katika High. Amri tofauti za SRE huonekana katika Wasifu wa Juu, Wastani na hazionekani kwa wasifu wa Chini:

Uwiano wa DevQaOps

Tuliona swali hili kwenye Facebook kutoka kwa kiongozi wa timu ya jukwaa la Skyeng - alivutiwa na uwiano wa wasanidi programu, wanaojaribu na wasimamizi katika makampuni. Tuliiuliza na tukaangalia majibu kulingana na wasifu: Wawakilishi wa wasifu wa juu wana wahandisi wachache wa majaribio na uendeshaji kwa kila msanidi:

Mipango ya 2021

Katika mipango ya mwaka ujao, wahojiwa walibaini shughuli zifuatazo:

Hapa unaweza kuona makutano ya mkutano wa DevOps Live 2020. Tulikagua mpango kwa makini:

• Miundombinu kama bidhaa
• Mabadiliko ya DevOps
• Usambazaji wa mazoea ya DevOps
• DevSecOps
• Vilabu vya kesi na majadiliano

Lakini wakati wa uwasilishaji wetu hautoshi kufunika mada zote. Kushoto nyuma ya pazia:

• Jukwaa kama huduma na kama bidhaa;
• Miundombinu kama kanuni, mazingira na mawingu;
• Ushirikiano wa Kuendelea na Utoaji;
• Usanifu;
• mifumo ya DevSecOps;
• Jukwaa na timu zinazofanya kazi mbalimbali.

Ripoti tulipata voluminous, kurasa 50, na unaweza kuiona kwa undani zaidi.

Akihitimisha

Tunatumai kuwa utafiti na ripoti yetu itakuhimiza kujaribu mbinu mpya za ukuzaji, majaribio na utendakazi, na pia kukusaidia kusogeza, kujilinganisha na washiriki wengine katika utafiti, na kutambua maeneo ambapo unaweza kuboresha mbinu zako mwenyewe.

Matokeo ya utafiti wa kwanza wa hali ya DevOps nchini Urusi:

• Vipimo muhimu. Tumegundua kuwa vipimo muhimu (muda wa uwasilishaji, marudio ya utumaji, muda wa urejeshaji, na kushindwa kwa mabadiliko) vinafaa kwa kuchanganua ufanisi wa michakato ya ukuzaji, majaribio na utendakazi.
• Profaili Juu, Kati, Chini. Kulingana na data iliyokusanywa, tunaweza kutofautisha vikundi tofauti vya kitakwimu vya Juu, Kati, Chini na vipengele mahususi kulingana na vipimo, mbinu, michakato na zana. Wawakilishi wa Wasifu wa Juu wanaonyesha matokeo bora kuliko ya Chini. Wana uwezekano mkubwa wa kufikia na kuzidi malengo yao.
• Viashiria, janga na mipango ya 2021. Kiashiria maalum mwaka huu ni jinsi makampuni yalivyokabiliana na janga hili. Wawakilishi wa Juu walifanya vyema, walipata ongezeko la ushiriki wa watumiaji, na sababu kuu za kufaulu zilikuwa michakato ya maendeleo yenye ufanisi na utamaduni dhabiti wa uhandisi.
• DevOps mazoea, zana na maendeleo yao. Mipango kuu ya makampuni kwa mwaka ujao ni pamoja na uundaji wa mbinu na zana za DevOps, kuanzishwa kwa mbinu za DevSecOps, na mabadiliko katika muundo wa shirika. Na utekelezaji bora na maendeleo ya mazoea ya DevOps unafanywa kwa msaada wa miradi ya majaribio, uundaji wa jumuiya na vituo vya ubora, mipango katika ngazi ya juu na ya chini ya kampuni.

Tungependa kusikia maoni yako, hadithi, maoni. Tunamshukuru kila mtu aliyeshiriki katika utafiti na tunatazamia ushiriki wako mwaka ujao.

Chanzo: mapenzi.com