🥇State of DevOps sa Russia 2020

Paano mo naiintindihan ang estado ng isang bagay?

Maaari kang umasa sa iyong opinyon, na nabuo mula sa iba't ibang mga mapagkukunan ng impormasyon, halimbawa, mga publikasyon sa mga website o karanasan. Maaari mong tanungin ang iyong mga kasamahan at kaibigan. Ang isa pang pagpipilian ay tingnan ang mga paksa ng mga kumperensya: ang komite ng programa ay mga aktibong kinatawan ng industriya, kaya pinagkakatiwalaan namin sila sa pagpili ng mga nauugnay na paksa. Ang isang hiwalay na lugar ay pananaliksik at mga ulat. Pero may problema. Ang pananaliksik sa estado ng DevOps ay isinasagawa taun-taon sa buong mundo, ang mga ulat ay inilathala ng mga dayuhang kumpanya, at halos walang impormasyon tungkol sa Russian DevOps.

Ngunit dumating ang araw kung kailan isinagawa ang gayong pag-aaral, at ngayon sasabihin namin sa iyo ang tungkol sa mga resulta na nakuha. Ang estado ng DevOps sa Russia ay pinagsama-samang pinag-aralan ng mga kumpanya "Ipahayag 42"At"Ontico" Ang kumpanya ng Express 42 ay tumutulong sa mga kumpanya ng teknolohiya na ipatupad at bumuo ng mga kasanayan at tool ng DevOps at isa sa mga unang nagsalita tungkol sa DevOps sa Russia. Ang mga may-akda ng pag-aaral, sina Igor Kurochkin at Vitaly Khabarov, ay nakikibahagi sa pagsusuri at pagkonsulta sa Express 42, na mayroong teknikal na background mula sa operasyon at karanasan sa iba't ibang kumpanya. Sa loob ng 8 taon, tiningnan ng mga kasamahan ang dose-dosenang kumpanya at proyekto - mula sa mga startup hanggang sa mga negosyo - na may iba't ibang problema, pati na rin ang iba't ibang kultura at engineering maturity.

Sa kanilang ulat, ipinaliwanag nina Igor at Vitaly kung anong mga problema ang nagkaroon sa proseso ng pananaliksik, kung paano nila nalutas ang mga ito, pati na rin kung paano isinasagawa ang pananaliksik sa DevOps sa prinsipyo at kung bakit nagpasya ang Express 42 na magsagawa ng kanilang sarili. Maaari mong makita ang kanilang ulat dito.

Pananaliksik sa DevOps

Sinimulan ni Igor Kurochkin ang pag-uusap.

Regular kaming nagtatanong sa mga madla sa mga kumperensya ng DevOps: “Nabasa mo na ba ang ulat ng State of DevOps ngayong taon?” Iilan lamang ang nagtataas ng kanilang mga kamay, ngunit ipinakita ng aming pananaliksik na pangatlo lamang ang nag-aaral sa kanila. Kung hindi ka pa nakakita ng ganitong mga ulat, sabihin natin kaagad na lahat sila ay halos magkapareho. Kadalasan mayroong mga parirala tulad ng: "Kumpara sa nakaraang taon..."

Narito ang aming unang problema, na sinusundan ng dalawa pa:

Wala kaming data para sa nakaraang taon. Walang interesado sa estado ng DevOps sa Russia;
Pamamaraan. Hindi malinaw kung paano subukan ang mga hypotheses, kung paano bumuo ng mga tanong, kung paano magsagawa ng pagsusuri, ihambing ang mga resulta, maghanap ng mga koneksyon;
Terminolohiya. Ang lahat ng mga ulat ay nasa Ingles, kinakailangan ang pagsasalin, ang isang karaniwang balangkas para sa DevOps ay hindi pa naiimbento at ang bawat isa ay gumagawa ng kanilang sarili.

Tingnan natin kung paano karaniwang isinagawa ang mga pagsusuri sa estado ng DevOps sa mundo.

kasaysayan

Ang pananaliksik sa DevOps ay isinagawa mula noong 2011. Ang unang nagsagawa ng mga ito ay Puppet, isang developer ng mga configuration management system. Sa oras na iyon, ito ay isa sa mga pangunahing tool para sa paglalarawan ng imprastraktura sa anyo ng code. Hanggang 2013, ang mga pag-aaral na ito ay mga survey lamang sa isang saradong format at walang pampublikong pag-uulat.

Noong 2013, lumitaw ang IT Revolution, publisher ng lahat ng pangunahing libro sa DevOps. Kasama ang Puppet, inihanda nila ang unang publikasyong "State of DevOps", kung saan lumitaw ang 4 na pangunahing sukatan sa unang pagkakataon. Nang sumunod na taon, nasangkot ang consulting company na ThoughtWorks, na kilala sa mga regular na teknolohiyang radar nito sa mga kasanayan at tool sa industriya. At noong 2015, isang seksyon na may pamamaraan ang idinagdag, at naging malinaw kung paano nila ginagawa ang pagsusuri.

Noong 2016, ang mga may-akda ng pag-aaral, na lumikha ng kanilang kumpanyang DORA (DevOps Research and Assessment), ay naglathala ng taunang ulat. Nang sumunod na taon, naglabas ang DORA at Puppet ng kanilang huling pinagsamang ulat.

At pagkatapos ay naging kawili-wili ang mga bagay:

Noong 2018, nahati ang mga kumpanya at dalawang independyenteng ulat ang inilabas: isa mula sa Puppet, ang pangalawa mula sa DORA sa pakikipagtulungan sa Google. Patuloy na ginamit ng DORA ang pamamaraan nito sa mga pangunahing sukatan, mga profile ng pagganap at mga kasanayan sa engineering na nakakaapekto sa mga pangunahing sukatan at pagganap sa buong kumpanya. At iminungkahi ng Puppet ang diskarte nito na may paglalarawan ng proseso at ang ebolusyon ng DevOps. Ngunit hindi natuloy ang kuwento; noong 2019, inabandona ng Puppet ang pamamaraang ito at naglabas ng bagong bersyon ng mga ulat, kung saan inilista nito ang mga pangunahing kasanayan at kung paano nakakaapekto ang mga ito sa DevOps mula sa kanilang pananaw. Pagkatapos ay isa pang nangyari: binili ng Google ang DORA, at magkasama silang naglabas ng isa pang ulat. Marahil ay nakita mo na.

Sa taong ito naging kumplikado ang mga bagay. Nabatid na naglunsad ng survey si Puppet. Mas maaga nila itong ginawa ng isang linggo kaysa sa amin, at natapos na ito. Nakibahagi kami dito at nakita kung anong mga paksa ang interesado sa kanila. Ginagawa na ngayon ng puppet ang pagsusuri nito at naghahanda na i-publish ang ulat.

Pero wala pa ring announcement mula sa DORA at Google. Noong Mayo, kapag karaniwang nagsisimula ang survey, dumating ang impormasyon na si Nicole Forsgren, isa sa mga tagapagtatag ng DORA, ay lumipat sa ibang kumpanya. Kaya naman, inakala namin na walang gagawing pananaliksik o ulat mula sa DORA ngayong taon.

Paano ang mga bagay sa Russia?

Hindi kami nagsagawa ng anumang pananaliksik sa DevOps. Nag-usap kami sa mga kumperensya, muling ikinuwento ang mga konklusyon ng ibang tao, at isinalin ni Raiffeisenbank ang "State of DevOps" para sa 2019 (makikita mo ang kanilang anunsyo sa Habré), maraming salamat sa kanila. At lahat na.

Samakatuwid, nagsagawa kami ng aming sariling pananaliksik sa Russia gamit ang mga pamamaraan at natuklasan ng DORA. Ginamit namin ang ulat ng mga kasamahan mula sa Raiffeisenbank para sa aming pananaliksik, kabilang ang pag-synchronize ng terminolohiya at pagsasalin. At ang mga tanong na may kaugnayan sa industriya ay kinuha mula sa mga ulat ng DORA at sa Puppet questionnaire ngayong taon.

Proseso ng pananaliksik

Ang ulat ay ang huling bahagi lamang. Ang buong proseso ng pananaliksik ay binubuo ng apat na malalaking yugto:

Sa yugto ng paghahanda, nakapanayam namin ang mga eksperto sa industriya at naghanda ng listahan ng mga hypotheses. Batay sa kanila, nag-compile kami ng mga tanong at naglunsad ng survey para sa buong buwan ng Agosto. Pagkatapos ay sinuri namin at inihanda ang ulat mismo. Para sa DORA, ang prosesong ito ay tumatagal ng 6 na buwan. Nakumpleto namin ito sa loob ng 3 buwan, at ngayon ay nauunawaan namin na halos wala kaming sapat na oras: sa pamamagitan lamang ng paggawa ng pagsusuri naiintindihan mo kung anong mga tanong ang kailangang itanong.

Mga Kalahok

Ang lahat ng mga banyagang ulat ay nagsisimula sa isang larawan ng mga kalahok, at karamihan sa kanila ay hindi mula sa Russia. Ang porsyento ng mga tumutugon sa Russia ay nagbabago mula 5 hanggang 1% bawat taon, at hindi ito nagpapahintulot sa amin na gumawa ng anumang mga konklusyon.

Mapa mula sa ulat ng Accelerate State of DevOps 2019:

Sa aming pag-aaral, nakapagpanayam kami ng 889 katao - ito ay medyo marami (DORA surveys tungkol sa isang libong tao taun-taon sa mga ulat nito) at dito namin nakamit ang aming layunin:

Totoo, hindi lahat ng aming mga kalahok ay umabot sa dulo: ang porsyento ng pagkumpleto ay bahagyang mas mababa sa kalahati. Ngunit ito ay sapat na upang makakuha ng isang kinatawan na sample at magsagawa ng pagsusuri. Hindi isiniwalat ng DORA ang mga rate ng occupancy sa mga ulat nito, kaya hindi maaaring gawin dito ang mga paghahambing.

Mga industriya at posisyon

Ang aming mga respondent ay kumakatawan sa isang dosenang industriya. Kalahating trabaho sa teknolohiya ng impormasyon. Sinusundan ito ng mga serbisyong pinansyal, kalakalan, telekomunikasyon at iba pa. Kabilang sa mga posisyon ang mga espesyalista (developer, tester, operation engineer) at mga tauhan ng pamamahala (mga pinuno ng mga koponan, grupo, lugar, direktor):

Ang bawat pangalawang tao ay nagtatrabaho sa isang medium-sized na kumpanya. Ang bawat ikatlong tao ay nagtatrabaho sa malalaking kumpanya. Karamihan ay nagtatrabaho sa mga pangkat na hanggang 9 na tao. Hiwalay, nagtanong kami tungkol sa mga pangunahing aktibidad, at ang karamihan ay sa isang paraan o iba pang nauugnay sa operasyon, at humigit-kumulang 40% ang kasangkot sa pag-unlad:

Ganito kami nangongolekta ng impormasyon para sa paghahambing at pagsusuri ng mga kinatawan ng iba't ibang industriya, kumpanya, at koponan. Sasabihin sa iyo ng aking kasamahan na si Vitaly Khabarov ang tungkol sa pagsusuri.

Pagsusuri at paghahambing

Vitaly Khabarov: Maraming salamat sa lahat ng kalahok na nakakumpleto ng aming survey, nagsagot sa mga questionnaire at nagbigay sa amin ng data para sa karagdagang pagsusuri at pagsubok ng aming mga hypotheses. At salamat sa aming mga kliyente at customer, mayroon kaming maraming karanasan na nakatulong sa amin na matukoy ang mga isyu ng pag-aalala sa industriya at bumalangkas ng mga hypotheses na sinubukan namin sa aming pananaliksik.

Sa kasamaang palad, hindi ka maaaring kumuha ng isang listahan ng mga tanong sa isang banda at data sa kabilang banda, kahit papaano ihambing ang mga ito, sabihin: "Oo, lahat ay gumagana nang ganoon, tama kami" at pumunta sa aming magkahiwalay na paraan. Hindi, kailangan namin ng metodolohiya at istatistikal na pamamaraan upang matiyak na hindi kami nagkamali at ang aming mga konklusyon ay maaasahan. Pagkatapos ay maaari naming buuin ang aming karagdagang trabaho batay sa data na ito:

Pangunahing sukatan

Kinuha namin ang pamamaraan ng DORA bilang batayan, na inilarawan nila nang detalyado sa aklat na "Accelerate State of DevOps." Sinuri namin kung ang mga pangunahing sukatan ay angkop para sa merkado ng Russia, kung magagamit ang mga ito sa parehong paraan tulad ng ginagamit ng DORA upang sagutin ang tanong na: "Paano tumutugma ang industriya sa Russia sa dayuhang industriya?"

Pangunahing sukatan:

Dalas ng deployment. Gaano kadalas na-deploy ang isang bagong bersyon ng isang application sa kapaligiran ng produksyon (mga binalak na pagbabago, hindi kasama ang mga hotfix at pagtugon sa insidente)?
Oras ng paghatid. Ano ang average na oras sa pagitan ng paggawa ng pagbabago (pagsusulat ng functionality bilang code) at pag-deploy ng pagbabago sa kapaligiran ng produksyon?
Oras ng pagbawi. Gaano katagal aabutin sa average upang maibalik ang isang application sa isang kapaligiran ng produksyon pagkatapos ng isang insidente, pagkasira ng serbisyo, o pagtuklas ng isang error na nakakaapekto sa mga user ng application?
Mga hindi matagumpay na pagbabago. Ilang porsyento ng mga deployment sa kapaligiran ng produkto ang humahantong sa pagkasira ng aplikasyon o mga insidente at nangangailangan ng pag-aalis ng mga kahihinatnan (pagbabalik ng mga pagbabago, pagbuo ng hotfix o patch)?

Nakahanap ang pananaliksik ng DORA ng koneksyon sa pagitan ng mga sukatan na ito at pagganap ng organisasyon. Sinusuri din namin ito sa aming pag-aaral.

Ngunit upang matiyak na ang apat na pangunahing sukatan ay maaaring makaimpluwensya sa isang bagay, kailangan mong maunawaan - kahit papaano ay may kaugnayan ba ang mga ito sa isa't isa? Sumagot ang DORA ng oo, na may isang caveat: ang relasyon sa pagitan ng Change Failure Rate at ng iba pang tatlong sukatan ay bahagyang mas mahina. Nakuha namin ang tungkol sa parehong larawan. Kung ang oras ng paghahatid, dalas ng pag-deploy at oras ng pagbawi ay magkakaugnay sa isa't isa (itinatag namin ang ugnayang ito sa pamamagitan ng ugnayan ng Pearson at sa pamamagitan ng sukat ng Chaddock), kung gayon walang ganoong kalakas na ugnayan sa mga hindi matagumpay na pagbabago.

Sa prinsipyo, karamihan sa mga sumasagot ay may posibilidad na sumagot na mayroon silang medyo maliit na bilang ng mga insidente na nagaganap sa produksyon. Bagama't makikita natin sa ibang pagkakataon na mayroon pa ring makabuluhang pagkakaiba sa pagitan ng mga pangkat ng mga respondent sa rate ng mga hindi matagumpay na pagbabago, hindi pa natin magagamit ang sukatang ito para sa dibisyong ito.

Iniuugnay namin ito sa katotohanan na (tulad ng nangyari sa proseso ng pagsusuri at pakikipag-usap sa ilan sa aming mga customer) mayroong kaunting pagkakaiba sa pang-unawa sa kung ano ang itinuturing na isang insidente. Kung nagawa naming ibalik ang functionality ng aming serbisyo sa panahon ng teknikal na window, maaari ba itong ituring na isang insidente? Malamang hindi, dahil inayos namin lahat, magaling kami. Maaari ba itong ituring na isang insidente kung kailangan naming muling i-roll ang aming aplikasyon nang 10 beses sa normal, pamilyar na mode? Parang hindi. Samakatuwid, ang tanong ng kaugnayan sa pagitan ng mga hindi matagumpay na pagbabago at iba pang mga sukatan ay nananatiling bukas. Lilinawin pa natin.

Ang mahalaga dito ay nakakita kami ng makabuluhang ugnayan sa pagitan ng oras ng paghahatid, oras ng pagbawi, at dalas ng pag-deploy. Samakatuwid, kinuha namin ang tatlong sukatan na ito upang higit pang hatiin ang mga respondent sa mga pangkat batay sa pagiging produktibo.

Magkano na mag-hang sa gramo?

Ginamit namin ang hierarchical cluster analysis:

Ibinahagi namin ang mga respondent sa n-dimensional na espasyo, kung saan ang coordinate ng bawat respondent ay ang kanilang mga sagot sa mga tanong.
Idinedeklara namin na ang bawat respondent ay isang maliit na kumpol.
Pinagsasama namin ang dalawang kumpol na pinakamalapit sa isa't isa sa isang mas malaking kumpol.
Nahanap namin ang susunod na pares ng mga kumpol at pinagsama ang mga ito sa isang mas malaking kumpol.

Ito ay kung paano namin pinapangkat ang lahat ng aming mga respondent sa bilang ng mga kumpol na kailangan namin. Gamit ang isang dendrogram (isang puno ng mga koneksyon sa pagitan ng mga kumpol) nakikita namin ang distansya sa pagitan ng dalawang magkatabing kumpol. Ang natitira na lang sa atin ay magtakda ng isang tiyak na limitasyon sa distansya sa pagitan ng mga kumpol na ito at sabihin: "Ang dalawang grupong ito ay lubos na nakikilala sa isa't isa dahil ang distansya sa pagitan nila ay napakalaki."

Ngunit mayroong isang nakatagong problema dito: wala kaming mga paghihigpit sa bilang ng mga kumpol - maaari kaming makakuha ng 2, 3, 4, 10 kumpol. At ang unang ideya ay - bakit hindi hatiin ang lahat ng aming mga respondent sa 4 na grupo, tulad ng ginagawa ng DORA. Ngunit nalaman namin na ang mga pagkakaiba sa pagitan ng mga pangkat na ito ay nagiging hindi gaanong mahalaga, at hindi namin matiyak na ang sumasagot ay talagang kabilang sa kanyang grupo at hindi sa kalapit. Hindi pa natin maaaring hatiin ang merkado ng Russia sa apat na grupo. Samakatuwid, kami ay nanirahan sa tatlong mga profile, kung saan mayroong isang makabuluhang pagkakaiba sa istatistika:

Susunod, tinukoy namin ang profile sa pamamagitan ng cluster: kinuha namin ang mga median para sa bawat sukatan para sa bawat pangkat at nag-compile ng isang talahanayan ng mga profile ng kahusayan. Sa katunayan, nakuha ang mga resultang profile ng pagganap para sa karaniwang kalahok sa bawat pangkat. Natukoy namin ang tatlong profile ng kahusayan: Mababa, Katamtaman, Mataas:

Dito nakumpirma namin ang aming hypothesis na ang 4 na pangunahing sukatan ay angkop para sa pagtukoy sa profile ng pagganap, at gumagana ang mga ito sa parehong Western at Russian market. Mayroong pagkakaiba sa pagitan ng mga pangkat, at ito ay makabuluhan sa istatistika. Gusto kong bigyang-diin na may malaking pagkakaiba sa mean sa pagitan ng mga profile ng pagganap para sa sukatan ng mga hindi matagumpay na pagbabago, kahit na hindi namin unang hinati ang mga respondent ayon sa parameter na ito.

Pagkatapos ay lumitaw ang tanong: paano gamitin ang lahat ng ito?

Paano gamitin

Kung kukuha kami ng anumang koponan, 4 na pangunahing sukatan at ilapat ito sa talahanayan, kung gayon sa 85% ng mga kaso ay hindi kami makakakuha ng kumpletong tugma - ito ay karaniwang kalahok lamang, at hindi kung ano ang totoo. Lahat tayo (at bawat koponan) ay medyo naiiba.

Sinuri namin: kinuha namin ang aming mga respondent at ang profile ng pagganap ng DORA, at tiningnan kung gaano karaming mga respondent ang tumutugma sa isa o ibang profile. Nalaman namin na 16% lang ng mga respondent ang tumpak na nahulog sa isa sa mga profile. Ang lahat ng natitira ay nakakalat sa isang lugar sa pagitan:

Nangangahulugan ito na ang profile ng pagganap ay may limitadong saklaw. Upang makakuha ng unang pagtataya kung nasaan ka, maaari mong gamitin ang talahanayang ito: "Oh, mukhang mas malapit tayo sa Medium o High!" Kung naiintindihan mo kung saan ka susunod na pupunta, maaaring sapat na iyon. Ngunit kung ang iyong layunin ay pare-pareho, patuloy na pagpapabuti, at gusto mong malaman nang mas tiyak kung saan bubuo at kung ano ang gagawin, kailangan ng karagdagang pondo. Tinawag namin silang mga calculator:

DORA calculator
Calculator Express 42* (in development)
Ang iyong sariling pag-unlad (maaari kang lumikha ng iyong sariling panloob na calculator).

Ano ang kailangan nila? Maintindihan:

Natutugunan ba ng pangkat sa loob ng aming organisasyon ang aming mga pamantayan?
Kung hindi, maaari ba namin siyang tulungan - pabilisin ito sa loob ng balangkas ng kadalubhasaan na mayroon ang aming kumpanya?
Kung gayon, maaari pa ba tayong gumawa ng mas mahusay?

Maaari mo ring gamitin ang mga ito upang mangolekta ng mga istatistika sa loob ng kumpanya:

Anong uri ng mga koponan ang mayroon tayo?
Hatiin ang mga koponan sa mga profile;
Tingnan: Oh, ang mga team na ito ay hindi maganda ang performance (medyo mabagal), ngunit ang mga ito ay mahusay: sila ay nagde-deploy araw-araw, nang walang mga error, ang kanilang lead time ay wala pang isang oras.

At pagkatapos ay maaari mong malaman na sa loob ng aming kumpanya mayroon kaming mga kinakailangang kadalubhasaan at mga tool para sa mga koponan na kulang pa rin.

O, kung naiintindihan mo na ang pakiramdam mo ay mahusay sa loob ng kumpanya, na ikaw ay mas mahusay kaysa sa marami, kung gayon maaari kang tumingin nang medyo mas malawak. Ito ang tiyak na industriya ng Russia: maaari ba tayong makakuha ng kinakailangang kadalubhasaan sa industriya ng Russia upang mapabilis ang ating sarili? Ang Express 42 calculator ay makakatulong dito (ito ay nasa ilalim ng pag-unlad). Kung nalampasan mo ang merkado ng Russia, tingnan mo DORA calculator at sa world market.

ayos lang. At kung ikaw ay nasa pangkat ng Elit ayon sa calculator ng DORA, ano ang dapat mong gawin? Walang magandang solusyon dito. Malamang, ikaw ang nangunguna sa industriya, at ang karagdagang pagpapabilis at pagiging maaasahan ay posible sa pamamagitan ng panloob na R&D at ang paggasta ng malalaking mapagkukunan.

Lumipat tayo sa pinakamatamis na bahagi - paghahambing.

Paghahambing

Noong una, nais naming ihambing ang industriya ng Russia sa industriya ng Kanluran. Kung direkta nating ihahambing, makikita natin na mas kaunti ang mga profile natin, at medyo magkakahalo sila sa isa't isa, mas malabo ang mga hangganan:

Ang aming mga Elite-performer ay nakatago sa mga High-performer, ngunit nandoon sila - ito ang mga piling tao, mga unicorn na umabot sa makabuluhang taas. Sa Russia, ang pagkakaiba sa pagitan ng Elite at High profile ay hindi pa sapat na makabuluhan. Sa tingin namin na sa hinaharap ay magaganap ang dibisyong ito dahil sa pagtaas ng kultura ng engineering, ang kalidad ng pagpapatupad ng mga kasanayan sa engineering at kadalubhasaan sa loob ng mga kumpanya.

Kung magpapatuloy tayo sa direktang paghahambing sa loob ng industriya ng Russia, makikita natin na ang mga High profile team ay mas mahusay sa lahat ng aspeto. Kinumpirma rin namin ang aming hypothesis na may koneksyon sa pagitan ng mga sukatang ito at pagiging epektibo ng organisasyon: Ang mga high profile na team ay mas malamang na hindi lamang makamit ang mga layunin, ngunit malalampasan din ang mga ito.
Maging mga High profile team tayo at hindi titigil doon:

Ngunit espesyal ang taong ito, at nagpasya kaming suriin kung paano nabubuhay ang mga kumpanya sa isang pandemya: Ang mga high profile na koponan ay mas mahusay na nakayanan at mas mahusay ang pakiramdam kaysa sa average ng industriya:

Ang mga bagong produkto ay inilabas nang 1,5-2 beses nang mas madalas,
Tumaas na pagiging maaasahan at/o pagganap ng imprastraktura ng aplikasyon nang 2 beses na mas madalas.

Iyon ay, ang mga kakayahan na mayroon na sila ay nakatulong sa kanila na bumuo ng mas mabilis, ipakilala ang mga bagong produkto, baguhin ang mga umiiral na produkto, sa gayon ay masakop ang mga bagong merkado at mga bagong user:

Ano pa ang nakatulong sa aming mga koponan?

Mga kasanayan sa engineering

Sasabihin ko sa iyo ang tungkol sa mahahalagang natuklasan para sa bawat pagsasanay na aming sinuri. Marahil ay may iba pang nakatulong sa mga koponan, ngunit pinag-uusapan natin ang tungkol sa DevOps. At sa loob ng DevOps, nakikita namin ang mga pagkakaiba sa mga koponan ng iba't ibang profile.

Platform bilang isang serbisyo

Wala kaming nakitang makabuluhang kaugnayan sa pagitan ng edad ng platform at ng profile ng koponan: Ang mga platform ay lumitaw nang humigit-kumulang sa parehong oras para sa parehong Mababa at Mataas na mga koponan. Ngunit para sa huli, ang platform ay nagbibigay sa average ng higit pang mga serbisyo at higit pang mga interface ng software para sa kontrol sa pamamagitan ng program code. At mas malamang na tulungan ng mga platform team ang kanilang mga developer at team na gamitin ang platform, mas malamang na lutasin ang kanilang mga problema at insidente na nauugnay sa platform, at sanayin ang iba pang mga team.

Imprastraktura bilang code

Ang lahat dito ay medyo standard. Nakakita kami ng kaugnayan sa pagitan ng automation ng infrastructure code at kung gaano karaming impormasyon ang nakaimbak sa loob ng imbakan ng imprastraktura. Ang mga high profile team ay nag-iimbak ng higit pang impormasyon sa mga repository: kabilang dito ang configuration ng imprastraktura, CI/CD pipeline, mga setting ng kapaligiran at mga parameter ng build. Mas madalas nilang iniimbak ang impormasyong ito, gumagana nang mas mahusay sa code ng imprastraktura, at nag-automate ng higit pang mga proseso at gawain para sa pagtatrabaho sa code ng imprastraktura.

Kapansin-pansin, wala kaming nakitang makabuluhang pagkakaiba sa mga pagsubok sa imprastraktura. Iniuugnay ko ito sa katotohanan na ang mga High profile team sa pangkalahatan ay may mas maraming pagsubok na automation. Marahil ay hindi sila dapat magambala nang hiwalay sa pamamagitan ng mga pagsubok sa imprastraktura, ngunit sa halip ay sapat na ang mga pagsubok na ginagamit nila upang suriin ang mga application, at salamat sa kanila makikita nila kung ano at saan sila nasira.

Pagsasama at Paghahatid

Ang pinaka-nakakainis na seksyon, dahil kinumpirma namin: kung mas maraming automation ang mayroon ka, mas mahusay kang magtrabaho kasama ang code, mas malamang na makakuha ka ng mas mahusay na mga resulta.

arkitektura

Gusto naming makita kung paano nakakaapekto ang mga microservice sa performance. Sa totoo lang, hindi nila ginagawa, dahil ang paggamit ng mga microservice ay hindi nauugnay sa pagtaas ng mga indicator ng kahusayan. Ang mga microservice ay ginagamit ng parehong High at Low profile team.

Ngunit ang mahalaga ay para sa mga High-teams, ang paglipat sa isang microservice architecture ay nagbibigay-daan sa kanila na independiyenteng bumuo ng kanilang mga serbisyo at ilunsad ang mga ito. Kung pinahihintulutan ng arkitektura ang mga developer na kumilos nang awtonomiya, nang hindi naghihintay para sa isang tao sa labas ng koponan, kung gayon ito ay isang pangunahing kakayahan para sa pagtaas ng bilis. Dito nakakatulong ang mga microservice. Ngunit ang kanilang pagpapatupad ay hindi gumaganap ng malaking papel.

Paano natin natuklasan ang lahat ng ito?

Nagkaroon kami ng ambisyosong plano upang ganap na gayahin ang pamamaraan ng DORA, ngunit kulang ang mga mapagkukunan. Kung ang DORA ay gumagamit ng maraming sponsorship at ang pag-aaral ay tumatagal ng anim na buwan, ginawa namin ang aming pag-aaral sa maikling panahon. Nais naming bumuo ng isang modelo ng DevOps tulad ng ginagawa ng DORA, at gagawin namin iyon sa hinaharap. Sa ngayon, nililimitahan namin ang aming sarili sa mga mapa ng init:

Tiningnan namin ang pamamahagi ng mga kasanayan sa engineering sa mga team ng bawat profile, at nalaman namin na ang mga team ng High profile, sa karaniwan, ay gumagamit ng mga kasanayan sa engineering nang mas madalas. Maaari mong basahin ang higit pa tungkol sa lahat ng ito sa aming ulat.

Para sa isang pagbabago, lumipat tayo mula sa kumplikadong mga istatistika patungo sa mga simple.

Ano pa ang natuklasan natin?

Tools

Napansin namin na ang pamilya ng Linux OS ay gumagamit ng pinakamaraming command. Ngunit nasa trend pa rin ang Windows - hindi bababa sa isang-kapat ng aming mga respondent ang nakapansin sa paggamit ng isa o ibang bersyon nito. Mukhang may ganitong pangangailangan ang merkado. Samakatuwid, maaari mong paunlarin ang mga kakayahan na ito at magbigay ng mga presentasyon sa mga kumperensya.

Sa mga orkestra, hindi lihim na nangunguna ang Kubernetes (52%). Ang susunod na orkestra sa linya ay ang Docker Swarm (mga 12%). Ang pinakasikat na CI system ay Jenkins at GitLab. Ang pinakasikat na configuration management system ay Ansible, na sinusundan ng aming minamahal na Shell.

Sa mga cloud hosting provider, kasalukuyang sinasakop ng Amazon ang nangungunang posisyon. Ang bahagi ng mga ulap ng Russia ay unti-unting tumataas. Sa susunod na taon magiging kawili-wiling makita kung ano ang mararamdaman ng mga tagapagbigay ng ulap ng Russia at kung tataas ang kanilang bahagi sa merkado. Umiiral ang mga ito, magagamit ang mga ito, at mabuti iyon:

Ibinibigay ko ang sahig kay Igor, na magbibigay ng higit pang mga istatistika.

Paglaganap ng mga kasanayan

Igor Kurochkin: Hiwalay, hiniling namin sa mga respondent na ipahiwatig kung paano ipinamamahagi sa kumpanya ang itinuturing na mga kasanayan sa engineering. Karamihan sa mga kumpanya ay may magkahalong diskarte na binubuo ng ibang hanay ng mga pattern, at ang mga pilot project ay napakasikat. Nakita rin namin ang kaunting pagkakaiba sa pagitan ng mga profile. Mas madalas na ginagamit ng mga kinatawan ng High profile ang pattern na "Initiative from below", kapag binago ng maliliit na team ng mga espesyalista ang mga proseso ng trabaho, mga tool, at nagbabahagi ng mga matagumpay na development sa ibang mga team. Sa Medium, isa itong top-down na inisyatiba na umaantig sa buong kumpanya sa pamamagitan ng paglikha ng mga komunidad at mga sentro ng kahusayan:

Agile at DevOps

Ang relasyon sa pagitan ng Agile at DevOps ay madalas na tinatalakay sa industriya. Ang tanong na ito ay itinaas din sa State of Agile Report para sa 2019/2020, kaya nagpasya kaming ihambing kung paano nauugnay ang mga aktibidad ng Agile at DevOps sa mga kumpanya. Nalaman namin na ang DevOps na walang Agile ay bihira. Para sa kalahati ng mga sumasagot, ang pagkalat ng Agile ay nagsimula nang mas maaga, at humigit-kumulang 20% ang nakakita ng sabay-sabay na pagsisimula, at isa sa mga palatandaan ng isang Mababang profile ay ang kawalan ng mga kasanayan sa Agile at DevOps:

Mga topolohiya ng pangkat

Sa pagtatapos ng nakaraang taon ang aklat na "Mga topolohiya ng pangkat", na nagmumungkahi ng isang balangkas para sa paglalarawan ng mga topolohiya ng pangkat. Inisip namin kung ito ay ilalapat sa mga kumpanya ng Russia. At tinanong namin ang tanong: "Anong mga pattern ang nakikita mo?"

Ang mga koponan sa imprastraktura ay sinusunod sa kalahati ng mga sumasagot, pati na rin ang mga hiwalay na pangkat ng pagbuo, pagsubok at pagpapatakbo. Napansin ng mga indibidwal na DevOps team ang 45%, kung saan mas karaniwan ang mga High representative. Susunod ay ang mga cross-functional na team, na mas karaniwan din sa High. Lumilitaw ang mga hiwalay na SRE command sa High, Medium na mga profile at bihirang makita sa Low profile:

DevQaOps Ratio

Nakita namin ang tanong na ito sa Facebook mula sa pinuno ng koponan ng Skyeng platform team - interesado siya sa ratio ng mga developer, tester at administrator sa mga kumpanya. Tinanong namin ito at tiningnan ang mga sagot na isinasaalang-alang ang mga profile: ang mga kinatawan ng High profile ay may mas maliit na bilang ng mga testing at operations engineer para sa bawat developer:

Mga plano para sa 2021 na taon

Sa kanilang mga plano para sa susunod na taon, binanggit ng mga respondent ang mga sumusunod na aktibidad:

Dito mo makikita ang intersection sa DevOps Live 2020 conference. Maingat naming sinuri ang programa:

Imprastraktura bilang isang produkto
Pagbabago ng DevOps
Pamamahagi ng mga kasanayan sa DevOps
Mga DevSecOps
Mga case club at talakayan

Ngunit ang aming pag-uusap ay hindi magkakaroon ng sapat na oras upang matugunan ang lahat ng mga paksa. Sa likod ng kamera:

Platform bilang isang serbisyo at bilang isang produkto;
Imprastraktura bilang code, kapaligiran at ulap;
Patuloy na pagsasama at paghahatid;
Arkitektura;
Mga Pattern ng DevSecOps;
Platform at cross-functional na mga koponan.

Iulat Malaki ang sa amin, 50 pahina ang haba, at maaari mo itong tingnan nang mas detalyado.

Lagom

Umaasa kami na ang aming pananaliksik at ulat ay magbibigay-inspirasyon sa iyo na mag-eksperimento sa mga bagong diskarte sa pag-unlad, pagsubok, at pagpapatakbo, pati na rin makatulong sa iyo na makuha ang iyong mga saloobin, ihambing ang iyong sarili sa iba sa pag-aaral, at tukuyin ang mga lugar kung saan maaari mong pagbutihin ang iyong sariling mga diskarte.

Mga resulta ng unang pag-aaral ng estado ng DevOps sa Russia:

Pangunahing sukatan. Nalaman namin na ang mga pangunahing sukatan (tagal ng paghahatid, rate ng deployment, oras ng pagbawi, at mga pagkabigo sa pagbabago) ay angkop para sa pagsusuri sa pagiging epektibo ng mga proseso ng pag-develop, pagsubok, at pagpapatakbo.
Mga Profile na Mataas, Katamtaman, Mababa. Batay sa mga nakolektang data, posibleng matukoy ang mga pangkat na magkakaibang istatistika: Mataas, Katamtaman, Mababa, na may mga natatanging tampok batay sa mga sukatan, kasanayan, proseso at tool. Ang mga kinatawan ng High profile ay nagpapakita ng mas magagandang resulta kaysa Low. Sila ay mas malamang na makamit at lumampas sa kanilang mga layunin.
Mga tagapagpahiwatig, pandemya at mga plano para sa 2021. Ang isang espesyal na tagapagpahiwatig sa taong ito ay kung paano nakayanan ng mga kumpanya ang pandemya. Mataas na gumanap nang mas mahusay, nakaranas ng pagtaas sa aktibidad ng user, at ang mga pangunahing dahilan ng tagumpay ay mahusay na mga proseso ng pag-unlad at isang malakas na kultura ng engineering.
Mga kasanayan sa DevOps, mga tool at kanilang pag-unlad. Kasama sa mga pangunahing plano ng mga kumpanya para sa susunod na taon ang pagbuo ng mga kasanayan at tool ng DevOps, ang pagpapakilala ng mga kasanayan sa DevSecOps, at mga pagbabago sa istruktura ng organisasyon. At ang epektibong pagpapatupad at pagpapaunlad ng mga kasanayan sa DevOps ay isinasagawa sa pamamagitan ng mga pilot project, ang pagbuo ng mga komunidad at mga competence center, mga inisyatiba sa mas mataas at mas mababang antas ng kumpanya.

Ikalulugod naming marinig ang iyong mga review, kwento, feedback. Nagpapasalamat kami sa lahat ng lumahok sa pag-aaral at inaasahan ang iyong pakikilahok sa susunod na taon.

Pinagmulan: www.habr.com