DevOps-ի վիճակը Ռուսաստանում 2020 թ

Ինչպե՞ս հասկանալ ինչ-որ բանի վիճակը:

Դուք կարող եք հիմնվել ձեր կարծիքի վրա, որը ձևավորվել է տեղեկատվության տարբեր աղբյուրներից, օրինակ՝ կայքերում հրապարակումներից կամ փորձից: Կարող եք հարցնել գործընկերներին, ծանոթներին. Մեկ այլ տարբերակ է դիտարկել համաժողովների թեմաները. ծրագրային հանձնաժողովը ոլորտի ակտիվ ներկայացուցիչներ են, ուստի մենք վստահում ենք նրանց համապատասխան թեմաների ընտրության հարցում: Առանձին ոլորտ են հետազոտությունները և հաշվետվությունները: Բայց կա մի խնդիր. Աշխարհում ամեն տարի անցկացվում են DevOps-ի վիճակի վերաբերյալ հետազոտություններ, զեկույցներ են հրապարակվում արտասահմանյան ընկերությունների կողմից, իսկ ռուսական DevOps-ի մասին տեղեկություն գրեթե չկա։

Բայց եկել է այն օրը, երբ նման ուսումնասիրություն է իրականացվել, և այսօր մենք կխոսենք արդյունքների մասին։ Ռուսաստանում DevOps-ի վիճակը համատեղ ուսումնասիրվել է ընկերությունների կողմից»Էքսպրես 42"Եւ"Օնտիկո«. Express 42-ն օգնում է տեխնոլոգիական ընկերություններին իրականացնել և զարգացնել DevOps-ի պրակտիկա և գործիքներ և առաջիններից մեկն էր, ով խոսեց Ռուսաստանում DevOps-ի մասին: Հետազոտության հեղինակները՝ Իգոր Կուրոչկինը և Վիտալի Խաբարովը, զբաղվում են Էքսպրես 42-ում վերլուծություններով և խորհրդատվություններով՝ միաժամանակ ունենալով տեխնիկական նախապատմություն և փորձ տարբեր ընկերություններում։ 8 տարի շարունակ գործընկերները դիտարկել են տասնյակ ընկերություններ և նախագծեր՝ սկսած ստարտափներից մինչև ձեռնարկություններ, տարբեր խնդիրներով, ինչպես նաև տարբեր մշակութային և ինժեներական հասունությամբ:

Իրենց զեկույցում Իգորն ու Վիտալին պատմել են, թե ինչ խնդիրներ են եղել հետազոտության ընթացքում, ինչպես են դրանք լուծել, ինչպես նաև, թե ինչպես է սկզբունքորեն իրականացվում DevOps հետազոտությունը և ինչու է Express 42-ը որոշել իրականացնել իր սեփականը: Նրանց զեկույցը կարելի է դիտել այստեղ.

DevOps հետազոտություն

Զրույցը սկսել է Իգոր Կուրոչկինը։

Մենք պարբերաբար հարցնում ենք DevOps կոնֆերանսների լսարանին. «Դուք կարդացե՞լ եք DevOps-ի կարգավիճակի հաշվետվությունը այս տարվա համար»: Քչերն են ձեռքերը բարձրացնում, և մեր ուսումնասիրությունը ցույց է տվել, որ միայն երրորդն է նրանց ուսումնասիրում: Եթե ​​դուք երբեք չեք տեսել նման զեկույցներ, ապա անմիջապես ասենք, որ դրանք բոլորը շատ նման են։ Ամենից հաճախ կան արտահայտություններ, ինչպիսիք են. «Անցյալ տարվա համեմատ ...»:

Այստեղ մենք ունենք առաջին խնդիրը, իսկ դրանից հետո ևս երկուսը.

1. Անցյալ տարվա տվյալներ չունենք։ Ռուսաստանում DevOps-ի վիճակը ոչ մեկին չի հետաքրքրում.
2. Մեթոդաբանությունը. Պարզ չէ, թե ինչպես ստուգել վարկածները, ինչպես կառուցել հարցեր, ինչպես վերլուծել, համեմատել արդյունքները, գտնել կապեր;
3. Տերմինաբանություն. Բոլոր հաշվետվությունները անգլերեն են, թարգմանությունը պահանջվում է, ընդհանուր DevOps շրջանակը դեռ չի ստեղծվել, և յուրաքանչյուրը գալիս է իր սեփականը:

Եկեք նայենք, թե ինչպես են DevOps-ի վիճակի վերլուծությունները կատարվել ամբողջ աշխարհում:

Պատմական տեղեկատվություն

DevOps-ի հետազոտությունն անցկացվում է 2011 թվականից։ Կոնֆիգուրացիայի կառավարման համակարգերի մշակող Փափեթն առաջինն էր, որ դրանք իրականացրեց: Այն ժամանակ դա ենթակառուցվածքը կոդի տեսքով նկարագրելու հիմնական գործիքներից մեկն էր։ Մինչև 2013 թվականը այս ուսումնասիրությունները պարզապես փակ հարցումներ էին և ոչ մի հանրային հաշվետվություն:

2013 թվականին հայտնվեց ՏՏ հեղափոխությունը՝ DevOps-ի բոլոր հիմնական գրքերի հրատարակիչը։ Puppet-ի հետ միասին նրանք պատրաստեցին առաջին State of DevOps հրատարակությունը, որտեղ առաջին անգամ հայտնվեցին 4 հիմնական չափումներ։ Հաջորդ տարի ThoughtWorks խորհրդատվական ընկերությունը, որը հայտնի է իր կանոնավոր տեխնոլոգիական ռադարներով արդյունաբերական պրակտիկաների և գործիքների վերաբերյալ, ներգրավվեց: Իսկ 2015-ին մեթոդաբանությամբ բաժին է ավելացվել, ու պարզ է դարձել, թե ինչպես են վերլուծությունը կատարում։

2016 թվականին հետազոտության հեղինակները, ստեղծելով իրենց սեփական ընկերությունը՝ DORA (DevOps Research and Assessment), հրապարակեցին տարեկան հաշվետվություն։ Հաջորդ տարի DORA-ն և Puppet-ը հրապարակեցին իրենց վերջին համատեղ զեկույցը:

Եվ հետո սկսվեց մի հետաքրքիր բան.

2018 թվականին ընկերությունները բաժանվեցին, և երկու անկախ զեկույցներ հրապարակվեցին՝ մեկը Puppet-ից, երկրորդը՝ DORA-ից՝ Google-ի հետ միասին։ DORA-ն շարունակել է օգտագործել իր մեթոդաբանությունը հիմնական ցուցանիշներով, կատարողականի պրոֆիլներով և ինժեներական պրակտիկաներով, որոնք ազդում են հիմնական չափումների և ամբողջ ընկերության կատարողականի վրա: Իսկ Puppet-ն առաջարկեց իր սեփական մոտեցումը՝ DevOps-ի գործընթացի և էվոլյուցիայի նկարագրությամբ: Բայց պատմությունը արմատ չգտավ, 2019-ին Puppet-ը հրաժարվեց այս մեթոդաբանությունից և թողարկեց հաշվետվությունների նոր տարբերակը, որտեղ թվարկվեցին հիմնական պրակտիկան և ինչպես են դրանք ազդում DevOps-ի վրա իրենց տեսանկյունից: Հետո մեկ այլ իրադարձություն տեղի ունեցավ. Google-ը գնեց DORA-ն, և նրանք միասին թողարկեցին ևս մեկ զեկույց: Դուք կարող եք տեսել նրան:

Այս տարի ամեն ինչ բարդացավ։ Հայտնի է, որ Puppet-ը սկսել է իր սեփական հարցումը: Մեզնից մեկ շաբաթ շուտ են արել, ու արդեն ավարտվել է։ Մասնակցեցինք ու նայեցինք, թե ինչ թեմաներով են նրանց հետաքրքրում։ Այժմ Puppet-ն անում է իր վերլուծությունը և պատրաստվում է հրապարակել զեկույցը։

Բայց DORA-ից ու Google-ից դեռ հայտարարություն չկա։ Մայիսին, երբ սովորաբար սկսվում էր հարցումը, տեղեկություն եկավ, որ Նիկոլ Ֆորսգրենը՝ DORA-ի հիմնադիրներից մեկը, տեղափոխվել է այլ ընկերություն։ Ուստի մենք ենթադրում էինք, որ այս տարի DORA-ի կողմից հետազոտություն և զեկույց չի լինելու։

Ինչպե՞ս են գործերը Ռուսաստանում:

Մենք չենք կատարել DevOps-ի հետազոտություն: Մենք խոսեցինք կոնֆերանսների ժամանակ՝ վերապատմելով այլ մարդկանց բացահայտումները, և Raiffeisenbank-ը թարգմանեց «State of DevOps»-ը 2019-ի համար (նրանց հայտարարությունը կարող եք գտնել Habré-ում), շատ շնորհակալություն նրանց: Եվ դա բոլորն է:

Հետևաբար, մենք Ռուսաստանում իրականացրեցինք մեր սեփական հետազոտությունը՝ օգտագործելով DORA մեթոդաբանությունները և արդյունքները: Մենք օգտագործել ենք Raiffeisenbank-ի գործընկերների զեկույցը մեր հետազոտության համար, այդ թվում՝ տերմինաբանության և թարգմանության համաժամացման համար: Իսկ ոլորտին առնչվող հարցերը վերցվել են DORA-ի հաշվետվություններից և այս տարվա Տիկնիկային հարցաշարից:

Հետազոտության գործընթաց

Զեկույցը միայն վերջին մասն է։ Ամբողջ հետազոտական ​​գործընթացը բաղկացած է չորս հիմնական քայլերից.

Նախապատրաստական ​​փուլում մենք հարցազրույց անցկացրինք ոլորտի փորձագետների հետ և պատրաստեցինք վարկածների ցանկ: Դրանց հիման վրա կազմվեցին հարցեր և անցկացվեց հարցում ամբողջ օգոստոսի համար։ Հետո մենք վերլուծեցինք և պատրաստեցինք զեկույցը։ DORA-ի համար այս գործընթացը տևում է 6 ամիս: Մենք հանդիպեցինք 3 ամսվա ընթացքում, և հիմա հասկանում ենք, որ մեզ հազիվ է բավականացրել ժամանակը՝ միայն վերլուծություններ կատարելով եք հասկանում, թե ինչ հարցեր պետք է տալ։

Մասնակիցները

Բոլոր արտասահմանյան զեկույցները սկսվում են մասնակիցների դիմանկարով, և նրանց մեծ մասը Ռուսաստանից չէ։ Ռուս հարցվածների տոկոսը տարեցտարի տատանվում է 5-ից 1%-ի սահմաններում, եւ դա թույլ չի տալիս եզրակացություններ անել։

Քարտեզ Accelerate State of DevOps 2019 զեկույցից.

Մեր ուսումնասիրության ընթացքում մեզ հաջողվեց հարցազրույց վերցնել 889 մարդու հետ. սա բավականին շատ է (DORA-ն իր զեկույցներում տարեկան հարցում է անում մոտ հազար մարդ) և այստեղ մենք հասել ենք նպատակին.

Ճիշտ է, մեր մասնակիցներից ոչ բոլորն են հասել ավարտին. ավարտվածության տոկոսը կեսից մի փոքր պակաս է ստացվել: Բայց նույնիսկ սա բավական էր ներկայացուցչական նմուշ ստանալու և վերլուծություն կատարելու համար։ DORA-ն իր հաշվետվություններում չի բացահայտում լրացման տոկոսները, ուստի այստեղ համեմատություն չկա:

Արդյունաբերություններ և պաշտոններ

Մեր հարցվողները ներկայացնում են մեկ տասնյակ արդյունաբերություն։ Կիսատ աշխատանք տեղեկատվական տեխնոլոգիաների ոլորտում. Դրան հաջորդում են ֆինանսական ծառայությունները, առևտուրը, հեռահաղորդակցությունը և այլն։ Պաշտոնների թվում են մասնագետներ (մշակող, փորձարկող, շահագործման ինժեներ) և ղեկավար անձնակազմ (թիմերի, խմբերի, տարածքների, տնօրենների ղեկավարներ).

Յուրաքանչյուր երկուսից մեկն աշխատում է միջին ընկերությունում: Ամեն երրորդ մարդն աշխատում է խոշոր ընկերություններում։ Շատերն աշխատում են մինչև 9 հոգանոց թիմերում: Առանձին-առանձին հարցրինք հիմնական գործունեության մասին, և մեծամասնությունը ինչ-որ կերպ կապված է գործողության հետ, և մոտ 40% -ը զբաղվում է մշակմամբ.

Այսպիսով, մենք հավաքեցինք տեղեկատվություն տարբեր ոլորտների, ընկերությունների, թիմերի ներկայացուցիչների համեմատության և վերլուծության համար: Վերլուծության մասին կպատմի իմ գործընկեր Վիտալի Խաբարովը։

Վերլուծություն և համեմատություն

Վիտալի Խաբարով. Շատ շնորհակալություն բոլոր մասնակիցներին, ովքեր լրացրեցին մեր հարցումը, լրացրին հարցաթերթիկներ և տրամադրեցին մեզ տվյալներ հետագա վերլուծության և մեր վարկածների փորձարկման համար: Եվ մեր հաճախորդների և հաճախորդների շնորհիվ մենք ունենք հարուստ փորձ, որն օգնել է բացահայտել ոլորտի մտահոգությունները և ձևակերպել այն վարկածները, որոնք մենք փորձարկել ենք մեր հետազոտության ընթացքում:

Ցավոք, չի կարելի մի կողմից վերցնել հարցերի ցուցակը, մյուս կողմից՝ տվյալներ, ինչ-որ կերպ համեմատել դրանք, ասել. «Այո, ամեն ինչ այդպես է ստացվում, մենք ճիշտ էինք» և ցրվել։ Ոչ, մեթոդաբանություն և վիճակագրական մեթոդներ են պետք, որպեսզի համոզվենք, որ մենք չենք սխալվում, և մեր եզրակացությունները հավաստի են։ Այնուհետև մենք կարող ենք կառուցել մեր հետագա աշխատանքը հետևյալ տվյալների հիման վրա.

Հիմնական չափումներ

Որպես հիմք մենք վերցրել ենք DORA մեթոդաբանությունը, որը նրանք մանրամասն նկարագրել են «Accelerate State of DevOps» գրքում։ Մենք ստուգեցինք, թե արդյոք հիմնական ցուցանիշները հարմար են ռուսական շուկայի համար, արդյոք դրանք կարող են օգտագործվել այնպես, ինչպես DORA-ն օգտագործում է հարցին պատասխանելու համար. «Ինչպե՞ս է Ռուսաստանում արդյունաբերությունը համապատասխանում արտասահմանյան արդյունաբերությանը»:

Հիմնական չափումներ.

1. Տեղակայման հաճախականությունը: Որքա՞ն հաճախ է հավելվածի նոր տարբերակը տեղադրվում արտադրական միջավայրում (պլանավորված փոփոխություններ, բացառելով թեժ շտկումները և միջադեպի արձագանքը):
2. Առաքման ժամանակ. Որքա՞ն է միջին ժամանակը փոփոխություն կատարելու (գործառույթը որպես կոդ գրելու) և փոփոխությունը արտադրական միջավայրում տեղակայելու միջև:
3. Վերականգնման ժամանակը. Միջին հաշվով որքա՞ն ժամանակ է պահանջվում հավելվածը արտադրական միջավայր վերականգնելու համար միջադեպից, ծառայության դեգրադացիայից կամ հավելվածի օգտատերերի վրա ազդող սխալի հայտնաբերումից հետո:
4. Անհաջող փոփոխություններ. Արտադրական միջավայրում տեղակայումների քանի՞ տոկոսն է հանգեցնում հավելվածի դեգրադացիայի կամ միջադեպերի և պահանջում վերականգնում (փոփոխությունների հետադարձ, թեժ շտկման կամ կարկատակի մշակում):

DORA-ն իր հետազոտության մեջ կապ է գտել այս ցուցանիշների և կազմակերպչական գործունեության միջև: Մենք նաև փորձարկում ենք այն մեր ուսումնասիրության մեջ:

Բայց համոզվելու համար, որ չորս հիմնական ցուցանիշները կարող են ինչ-որ բանի վրա ազդել, դուք պետք է հասկանաք՝ արդյոք դրանք ինչ-որ կերպ կապված են միմյանց հետ: DORA-ն դրական է պատասխանել մեկ նախազգուշացումով. անհաջող փոփոխությունների (Change Failure Rate) և երեք այլ չափանիշների միջև կապը մի փոքր ավելի թույլ է: Մոտավորապես նույն պատկերն ստացանք։ Եթե ​​առաքման ժամանակը, տեղակայման հաճախականությունը և վերականգնման ժամանակը փոխկապակցված են միմյանց հետ (մենք հաստատել ենք այս հարաբերակցությունը Պիրսոնի հարաբերակցության և Չադդոքի սանդղակի միջոցով), ապա անհաջող փոփոխությունների հետ նման ուժեղ հարաբերակցություն չկա:

Սկզբունքորեն, հարցվածների մեծ մասը հակված է պատասխանելու, որ արտադրության մեջ բավականին փոքր թվով միջադեպեր ունեն։ Թեև մենք ավելի ուշ կտեսնենք, որ դեռևս կա զգալի տարբերություն հարցվողների խմբերի միջև անհաջող փոփոխությունների առումով, մենք դեռ չենք կարող օգտագործել այս ցուցանիշը այս բաժանման համար:

Մենք դա պայմանավորում ենք նրանով, որ (ինչպես պարզվեց մեր որոշ հաճախորդների հետ վերլուծության և շփման ժամանակ) մի փոքր տարբերություն կա միջադեպ համարվողի ընկալման մեջ։ Եթե ​​տեխնիկական պատուհանի ժամանակ հաջողվել է վերականգնել մեր ծառայության կատարողականը, սա կարելի՞ է միջադեպ համարել։ Երևի ոչ, քանի որ մենք ամեն ինչ շտկել ենք, մենք հիանալի ենք։ Կարո՞ղ ենք դա միջադեպ համարել, եթե մենք ստիպված լինենք 10 անգամ վերաթողարկել մեր դիմումը սովորական, մեզ համար ծանոթ ռեժիմով: Թվում է, թե ոչ: Հետևաբար, անհաջող փոփոխությունների հարաբերակցության հարցը այլ ցուցանիշների հետ մնում է բաց։ Մենք այն ավելի կճշտենք:

Այստեղ կարևոր է, որ մենք զգալի կապ գտանք առաքման ժամանակի, վերականգնման ժամանակի և տեղակայման հաճախականության միջև: Հետևաբար, մենք վերցրեցինք այս երեք չափումները՝ պատասխանողներին հետագա կատարողական խմբերի բաժանելու համար:

Որքան կախված է գրամից:

Մենք օգտագործել ենք հիերարխիկ կլաստերային վերլուծություն.

• Մենք պատասխանողներին բաշխում ենք n-չափ տարածության վրա, որտեղ յուրաքանչյուր պատասխանողի կոորդինատը նրանց պատասխաններն են հարցերին:
• Յուրաքանչյուր հարցվող հայտարարվում է փոքր կլաստեր:
• Մենք միավորում ենք միմյանց մոտ գտնվող երկու կլաստերները մեկ ավելի մեծ կլաստերի մեջ:
• Մենք գտնում ենք հաջորդ զույգ կլաստերները և միավորում դրանք ավելի մեծ կլաստերի մեջ:

Այսպես մենք խմբավորում ենք մեր բոլոր հարցվողներին մեզ անհրաժեշտ կլաստերների քանակով: Դենդրոգրամի (կլաստերների միջև կապերի ծառ) օգնությամբ մենք տեսնում ենք երկու հարևան կլաստերի միջև եղած հեռավորությունը։ Մեզ մնում է այս կլաստերների միջև որոշակի հեռավորության սահման սահմանել և ասել. «Այս երկու խմբերը բավականին տարբերվում են միմյանցից, քանի որ նրանց միջև հեռավորությունը հսկայական է»:

Բայց այստեղ մի թաքնված խնդիր կա՝ մենք կլաստերի քանակի սահմանափակում չունենք՝ կարող ենք ստանալ 2, 3, 4, 10 կլաստեր։ Եվ առաջին միտքն այն էր, թե ինչու մեր բոլոր հարցվողներին չբաժանենք 4 խմբի, ինչպես անում է DORA-ն: Բայց մենք պարզեցինք, որ այս խմբերի միջև տարբերությունները դառնում են աննշան, և չենք կարող վստահ լինել, որ հարցվողն իրոք պատկանում է իր խմբին, այլ ոչ թե հարևանին։ Մենք դեռ չենք կարող ռուսական շուկան չորս խմբի բաժանել. Հետևաբար, մենք կանգ առանք երեք պրոֆիլների վրա, որոնց միջև կա վիճակագրորեն նշանակալի տարբերություն.

Այնուհետև մենք որոշեցինք պրոֆիլն ըստ կլաստերների. մենք վերցրեցինք յուրաքանչյուր խմբի միջին ցուցանիշը և կազմեցինք կատարողականի պրոֆիլների աղյուսակ: Փաստորեն, մենք ստացանք յուրաքանչյուր խմբի միջին մասնակցի կատարողական պրոֆիլները: Մենք առանձնացրել ենք երեք արդյունավետության պրոֆիլներ՝ ցածր, միջին, բարձր.

Այստեղ մենք հաստատեցինք մեր վարկածը, որ 4 հիմնական ցուցանիշները հարմար են կատարողականի պրոֆիլը որոշելու համար, և դրանք գործում են ինչպես արևմտյան, այնպես էլ ռուսական շուկայում: Խմբերի միջև տարբերություն կա և այն վիճակագրորեն նշանակալի է։ Շեշտում եմ, որ միջինի առումով անհաջող փոփոխությունների չափման ցուցանիշների միջև զգալի տարբերություն կա, թեև ի սկզբանե հարցվողներին չենք բաժանել այս պարամետրով:

Հետո հարց է առաջանում՝ ինչպե՞ս օգտագործել այս ամենը։

Ինչպես օգտվել

Եթե ​​վերցնենք որևէ թիմ, 4 հիմնական չափումներ և կիրառենք այն աղյուսակում, ապա 85% դեպքերում մենք չենք ստանա ամբողջական համընկնում. սա պարզապես միջին մասնակից է, և ոչ թե այն, ինչ կա իրականում: Մենք բոլորս (և յուրաքանչյուր թիմ) մի փոքր տարբեր ենք:

Մենք ստուգեցինք. վերցրեցինք մեր հարցվողներին և DORA կատարողականի պրոֆիլը և նայեցինք, թե քանի հարցված է համապատասխանում այս կամ այն ​​պրոֆիլին: Մենք պարզեցինք, որ հարցվածների միայն 16%-ն է հաստատապես ընկել պրոֆիլներից մեկում։ Մնացած բոլորը ցրված են ինչ-որ տեղ արանքում.

Սա նշանակում է, որ արդյունավետության պրոֆիլն ունի սահմանափակ շրջանակ: Հասկանալու համար, թե որտեղ եք գտնվում առաջին մոտավորության մեջ, կարող եք օգտագործել այս աղյուսակը. «Օ՜, կարծես թե մենք ավելի մոտ ենք միջին կամ բարձր մակարդակին»: Եթե ​​հասկանում եք, թե ուր գնալ հաջորդը, սա կարող է բավարար լինել: Բայց եթե ձեր նպատակը մշտական, շարունակական բարելավումն է, և դուք ցանկանում եք ավելի հստակ իմանալ, թե որտեղ և ինչ անել, ապա լրացուցիչ միջոցներ են անհրաժեշտ: Մենք նրանց անվանեցինք հաշվիչներ.

• DORA հաշվիչ
• Հաշվիչ Express 42* (մշակման փուլում)
• Սեփական զարգացում (կարող եք ստեղծել ձեր սեփական ներքին հաշվիչը):

Ինչի՞ համար են դրանք անհրաժեշտ։ Հասկանալ:

• Արդյո՞ք մեր կազմակերպության թիմը համապատասխանում է մեր չափանիշներին:
• Եթե ​​ոչ, կարո՞ղ ենք օգնել, արագացնել այն փորձաքննության շրջանակներում, որն ունի մեր ընկերությունը։
• Եթե ​​այո, կարո՞ղ ենք ավելի լավ անել:

Դուք կարող եք նաև օգտագործել դրանք ընկերության ներսում վիճակագրություն հավաքելու համար.

• Ի՞նչ թիմեր ունենք:
• Թիմերը բաժանել պրոֆիլների;
• Տեսեք. Օհ, այս հրամանները թերակատարում են (դրանք մի փոքր դուրս չեն գալիս), բայց դրանք հիանալի են. դրանք տեղադրվում են ամեն օր, առանց սխալների, ունեն մեկ ժամից պակաս ժամկետ:

Եվ հետո դուք կարող եք պարզել, որ մեր ընկերությունում առկա են անհրաժեշտ փորձաքննություն և գործիքներ այն թիմերի համար, որոնք դեռևս համապատասխան չեն:

Կամ, եթե հասկանում եք, որ ընկերությունում ձեզ հիանալի եք զգում, շատերից լավն եք, ապա կարող եք մի փոքր ավելի լայն տեսք ունենալ։ Սա պարզապես ռուսական արդյունաբերությունն է. մենք կարո՞ղ ենք անհրաժեշտ փորձաքննություն ստանալ ռուսական արդյունաբերության մեջ, որպեսզի արագացնենք: Այստեղ կօգնի Express 42 հաշվիչը (այն մշակման փուլում է): Եթե ​​դուք գերազանցել եք ռուսական շուկան, ապա նայեք DORA հաշվիչ և դեպի համաշխարհային շուկա։

Լավ: Իսկ եթե դու DORA հաշվիչի Elit խմբում ես, ի՞նչ պետք է անես: Այստեղ լավ լուծում չկա։ Դուք, ամենայն հավանականությամբ, արդյունաբերության առաջնագծում եք, և հետագա արագացումն ու հուսալիությունը հնարավոր են ներքին R&D-ի և ավելի շատ ռեսուրսներ ծախսելու միջոցով:

Անցնենք ամենաքաղցրին՝ համեմատությանը։

Համեմատություն

Մենք ի սկզբանե ցանկանում էինք համեմատել ռուսական արդյունաբերությունը արևմտյան արդյունաբերության հետ։ Եթե ​​ուղղակիորեն համեմատենք, ապա կտեսնենք, որ մենք ավելի քիչ պրոֆիլներ ունենք, և դրանք մի փոքր ավելի խառնված են միմյանց հետ, սահմանները մի փոքր ավելի մշուշոտ են.

Մեր էլիտար կատարողները թաքնված են Բարձր կատարողների մեջ, բայց նրանք այնտեղ են. սրանք այն էլիտան են, միաեղջյուրները, ովքեր հասել են զգալի բարձունքների: Ռուսաստանում Էլիտար պրոֆիլի և Բարձր պրոֆիլի միջև տարբերությունը դեռևս բավականաչափ էական չէ: Մենք կարծում ենք, որ ապագայում այս տարանջատումը տեղի կունենա ինժեներական մշակույթի աճի, ընկերությունների ներսում ինժեներական պրակտիկայի իրականացման որակի և փորձաքննության պատճառով:

Եթե ​​անցնենք ուղիղ համեմատության ռուսական արդյունաբերության ներսում, ապա կարող ենք տեսնել, որ բարձրակարգ թիմերն ավելի լավն են բոլոր առումներով: Մենք նաև հաստատեցինք մեր վարկածը, որ այս ցուցանիշների և կազմակերպչական գործունեության միջև կապ կա.
Եկեք դառնանք բարձր մակարդակի թիմեր և կանգ չառնենք դրանով.

Բայց այս տարին առանձնահատուկ է, և մենք որոշեցինք ստուգել, ​​թե ինչպես են ընկերությունները գործում համաճարակի պայմաններում.

• 1,5-2 անգամ ավելի հավանական է նոր արտադրանք թողարկվի,
• 2 անգամ ավելի հավանական է բարելավել կիրառական ենթակառուցվածքի հուսալիությունը և (կամ) կատարումը:

Այսինքն, այն իրավասությունները, որոնք նրանք արդեն ունեին, օգնեցին նրանց ավելի արագ զարգանալ, թողարկել նոր ապրանքներ, փոփոխել առկա ապրանքները, դրանով իսկ նվաճելով նոր շուկաներ և նոր օգտվողներ.

Էլ ի՞նչն է օգնել մեր թիմերին:

Ինժեներական պրակտիկա

Ես ձեզ կպատմեմ մեր փորձարկված յուրաքանչյուր պրակտիկայի կարևոր բացահայտումների մասին: Թերևս մեկ այլ բան օգնեց թիմերին, բայց մենք խոսում ենք DevOps-ի մասին։ Եվ DevOps-ում մենք տարբերություն ենք տեսնում տարբեր պրոֆիլների թիմերի միջև:

Հարթակը որպես ծառայություն

Մենք էական կապ չգտանք հարթակի տարիքի և թիմի պրոֆիլի միջև. հարթակները հայտնվեցին մոտավորապես նույն ժամանակ և՛ ցածր, և՛ բարձր թիմերի համար: Սակայն վերջիններիս համար հարթակը տրամադրում է միջին հաշվով ավելի շատ ծառայություններ և ավելի շատ ծրագրավորման միջերեսներ՝ ծրագրային կոդի միջոցով վերահսկելու համար։ Եվ հարթակի թիմերն ավելի հավանական է, որ կօգնեն իրենց մշակողներին և թիմերին օգտագործել հարթակը, ավելի հաճախ լուծել իրենց խնդիրները և հարթակի հետ կապված միջադեպերը և կրթել այլ թիմերին:

Ենթակառուցվածքը որպես ծածկագիր

Այստեղ ամեն ինչ բավականին ստանդարտ է: Մենք կապ գտանք ենթակառուցվածքի կոդի աշխատանքի ավտոմատացման և ենթակառուցվածքի պահեստի ներսում պահվող տեղեկատվության միջև: Բարձր պրոֆիլի հրամանները պահում են ավելի շատ տեղեկատվություն պահեստներում. սա ենթակառուցվածքի կազմաձևումն է, CI/CD խողովակաշարը, շրջակա միջավայրի կարգավորումները և կառուցման պարամետրերը: Նրանք ավելի հաճախ են պահում այս տեղեկատվությունը, ավելի լավ են աշխատում ենթակառուցվածքի կոդի հետ և ավտոմատացնում են ավելի շատ գործընթացներ և առաջադրանքներ ենթակառուցվածքի կոդի հետ աշխատելու համար:

Հետաքրքիր է, որ ենթակառուցվածքների փորձարկումներում մենք էական տարբերություն չտեսանք: Ես դա կապում եմ այն ​​փաստի հետ, որ բարձրակարգ թիմերն ընդհանուր առմամբ ավելի շատ փորձարկման ավտոմատացում ունեն: Միգուցե նրանց ուշադրությունը պետք չէ առանձին շեղել ենթակառուցվածքի թեստերով, այլ այն թեստերով, որոնցով նրանք ստուգում են հավելվածները, և դրանց շնորհիվ նրանք արդեն տեսնում են, թե ինչ և որտեղ են կոտրել:

Ինտեգրում և առաքում

Առավել ձանձրալի բաժինը, քանի որ մենք հաստատեցինք, որ ինչքան շատ ավտոմատացում ունենաք, այնքան ավելի լավ աշխատեք կոդի հետ, այնքան ավելի լավ արդյունքներ կստանաք:

ճարտարապետություն

Մենք ուզում էինք տեսնել, թե ինչպես են միկրոծառայություններն ազդում աշխատանքի վրա: Իրականում, նրանք չեն, քանի որ միկրոծառայությունների օգտագործումը կապված չէ կատարողականի ցուցանիշների բարձրացման հետ: Microservices օգտագործվում են ինչպես High Profile հրամանների, այնպես էլ Low Profile հրամանների համար:

Բայց կարևորն այն է, որ High-teams-ի համար միկրոսպասարկման ճարտարապետության անցումը թույլ է տալիս նրանց ինքնուրույն զարգացնել իրենց ծառայությունները և տարածել դրանք: Եթե ​​ճարտարապետությունը թույլ է տալիս ծրագրավորողներին գործել ինքնուրույն՝ առանց թիմից որևէ մեկին սպասելու, ապա սա արագության բարձրացման հիմնական իրավասությունն է: Այս դեպքում օգնում են միկրոսերվիսները։ Եվ պարզապես դրանց իրականացումը մեծ դեր չի խաղում։

Ինչպե՞ս բացահայտեցինք այս ամենը։

Մենք հավակնոտ ծրագիր ունեինք՝ ամբողջությամբ կրկնելու DORA մեթոդաբանությունը, սակայն չունեինք ռեսուրսներ: Եթե ​​DORA-ն մեծ հովանավորություն է օգտագործում, և նրանց հետազոտությունները տևում են կես տարի, մենք կարճ ժամանակում կատարեցինք մեր հետազոտությունը: Մենք ցանկանում էինք ստեղծել DevOps մոդել, ինչպես դա անում է DORA-ն, և մենք դա կանենք ապագայում: Մինչ այժմ մենք սահմանափակվել ենք ջերմային քարտեզներով.

Մենք ուսումնասիրեցինք ինժեներական պրակտիկաների բաշխվածությունը յուրաքանչյուր պրոֆիլի թիմերի միջև և պարզեցինք, որ բարձր մակարդակի թիմերը, միջին հաշվով, ավելի հավանական են օգտագործել ինժեներական պրակտիկա: Այս ամենի մասին ավելի մանրամասն կարող եք կարդալ մեր կայքում զեկուցել.

Փոփոխության համար եկեք բարդ վիճակագրությունից անցնենք պարզ վիճակագրության:

Էլ ի՞նչ ենք հայտնաբերել։

Գործիքներ

Մենք նկատում ենք, որ հրամանների մեծ մասն օգտագործվում է Linux ընտանիքի ՕՀ-ի կողմից: Սակայն Windows-ը դեռ միտում ունի. մեր հարցվածների առնվազն մեկ քառորդը նշել է դրա այս կամ այն ​​տարբերակների օգտագործումը: Կարծես շուկան ունի այս կարիքը։ Հետևաբար, դուք կարող եք զարգացնել այս իրավասությունները և զեկուցումներ անել կոնֆերանսներում:

Նվագախմբի կազմում դա ոչ մեկի համար գաղտնիք չէ, առաջատարն է Kubernetes-ը (52%)։ Հերթական նվագախմբի հաջորդը Docker Swarm-ն է (մոտ 12%): Ամենատարածված CI համակարգերն են Jenkins-ը և GitLab-ը: Կազմաձևերի կառավարման ամենահայտնի համակարգը Ansible-ն է, որին հաջորդում է մեր սիրելի Shell-ը:

Amazon-ը ներկայումս ամպային հոսթինգի առաջատար մատակարարն է: Ռուսական ամպերի մասնաբաժինը աստիճանաբար ավելանում է. Հաջորդ տարի հետաքրքիր կլինի տեսնել, թե ինչպես կզգան ռուսաստանյան ամպային պրովայդերները, կավելանա արդյոք նրանց մասնաբաժինը շուկայում։ Դրանք կան, դրանք կարող են օգտագործվել, և դա լավ է.

Խոսքը փոխանցում եմ Իգորին, ով ևս մի քանի վիճակագրություն կտա։

Պրակտիկայի տարածում

Իգոր Կուրոչկին. Առանձին-առանձին, մենք հարցվածներին խնդրեցինք նշել, թե ինչպես են բաշխված ինժեներական պրակտիկան ընկերությունում: Շատ ընկերություններում կա խառը մոտեցում, որը բաղկացած է տարբեր օրինաչափություններից, և պիլոտային նախագծերը շատ տարածված են: Մենք նաև տեսանք մի փոքր տարբերություն պրոֆիլների միջև: Բարձր մակարդակի ներկայացուցիչներն ավելի հաճախ օգտագործում են «Նախաձեռնություն ներքևից» օրինաչափությունը, երբ մասնագետների փոքր թիմերը փոխում են աշխատանքային գործընթացները, գործիքները և հաջողակ փորձը կիսում այլ թիմերի հետ: Medium-ում սա վերևից ներքև նախաձեռնություն է, որն ազդում է ամբողջ ընկերության վրա՝ ստեղծելով համայնքներ և գերազանցության կենտրոններ.

Արագաշարժ և DevOps

Agile-ի և DevOps-ի միջև կապի հարցը հաճախ քննարկվում է արդյունաբերության մեջ: Այս հարցը բարձրացված է նաև 2019/2020 թվականների Agile վիճակի զեկույցում, ուստի մենք որոշեցինք համեմատել, թե ինչպես են Agile-ի և DevOps-ի գործունեությունը կապված ընկերություններում: Մենք պարզեցինք, որ DevOps-ն առանց Agile-ի հազվադեպ է: Հարցվածների կեսի համար Agile-ի տարածումը սկսվել է շատ ավելի վաղ, և մոտ 20%-ը նկատել է միաժամանակյա մեկնարկը, և ցածր պրոֆիլի նշաններից մեկը կլինի Agile և DevOps պրակտիկայի բացակայությունը.

Հրամանի տոպոլոգիաներ

Անցյալ տարեվերջին գիրքը «Թիմային տոպոլոգիաներ», որն առաջարկում է հրամանի տոպոլոգիաների նկարագրության շրջանակ: Մեզ համար հետաքրքիր դարձավ, թե արդյոք դա կիրառելի է ռուսական ընկերությունների համար։ Եվ մենք հարցրինք. «Ի՞նչ նախշեր եք գտնում»:

Հարցվածների կեսում դիտարկվում են ենթակառուցվածքային թիմեր, ինչպես նաև մշակման, փորձարկման և շահագործման առանձին թիմեր: Առանձին DevOps թիմերը նշել են 45%, որոնց թվում ավելի հաճախ են High-ի ներկայացուցիչները։ Հաջորդը գալիս են բազմաֆունկցիոնալ թիմերը, որոնք նույնպես ավելի տարածված են High-ում: Առանձին SRE հրամաններ հայտնվում են High, Medium պրոֆիլներում և հազվադեպ են երևում ցածր պրոֆիլում.

DevQaOps հարաբերակցությունը

Այս հարցը FaceBook-ում տեսանք Skyeng պլատֆորմի թիմի ղեկավարի կողմից. նրան հետաքրքրում էր ընկերություններում մշակողների, փորձարկողների և ադմինիստրատորների հարաբերակցությունը: Մենք խնդրեցինք դա և նայեցինք պրոֆիլների հիման վրա ստացված պատասխաններին.

2021 թվականի պլանները

Հաջորդ տարվա պլաններում հարցվողները նշել են հետևյալ գործողությունները.

Այստեղ դուք կարող եք տեսնել DevOps Live 2020 կոնֆերանսի հետ խաչմերուկը: Մենք ուշադիր վերանայել ենք ծրագիրը.

• Ենթակառուցվածքը որպես արտադրանք
• DevOps-ի վերափոխում
• DevOps-ի պրակտիկաների բաշխում
• DevSecOps
• Գործերի ակումբներ և քննարկումներ

Բայց մեր ներկայացման ժամանակը բավարար չէ բոլոր թեմաները լուսաբանելու համար։ Կուլիսների հետևում թողեց.

• Պլատֆորմը որպես ծառայություն և որպես ապրանք;
• Ենթակառուցվածքը որպես ծածկագիր, միջավայրեր և ամպեր;
• Շարունակական ինտեգրում և առաքում;
• Ճարտարապետություն;
• DevSecOps օրինաչափություններ;
• Պլատֆորմ և բազմաֆունկցիոնալ թիմեր:

Զեկուցել մենք ստացել ենք ծավալուն, 50 էջ, և այն կարող եք ավելի մանրամասն տեսնել։

Ամփոփելով

Հուսով ենք, որ մեր հետազոտությունն ու զեկույցը կոգեշնչեն ձեզ փորձարկել մշակման, փորձարկման և գործառնությունների նոր մոտեցումներ, ինչպես նաև կօգնի ձեզ կողմնորոշվել, համեմատվել հետազոտության այլ մասնակիցների հետ և բացահայտել ոլորտները, որտեղ կարող եք բարելավել ձեր սեփական մոտեցումները:

Ռուսաստանում DevOps-ի վիճակի առաջին ուսումնասիրության արդյունքները.

• Հիմնական չափումներ. Մենք պարզել ենք, որ հիմնական չափորոշիչները (առաքման ժամանակը, տեղակայման հաճախականությունը, վերականգնման ժամանակը և փոփոխության ձախողումները) հարմար են մշակման, փորձարկման և գործառնական գործընթացների արդյունավետությունը վերլուծելու համար:
• Պրոֆիլներ Բարձր, միջին, ցածր: Հավաքագրված տվյալների հիման վրա մենք կարող ենք տարբերակել վիճակագրորեն տարբեր խմբեր Բարձր, Միջին, Ցածր՝ տարբերիչ հատկանիշներով չափումների, պրակտիկայի, գործընթացների և գործիքների առումով: High profile-ի ներկայացուցիչներն ավելի լավ արդյունքներ են ցույց տալիս, քան Low-ը: Նրանք ավելի հավանական է հասնելու և գերազանցելու իրենց նպատակները:
• Ցուցանիշներ, համաճարակ և 2021 թվականի պլաններ. Այս տարի հատուկ ցուցանիշ է այն, թե ինչպես են ընկերությունները հաղթահարել համաճարակը։ Բարձր ներկայացուցիչներն ավելի լավ գործեցին, օգտատերերի ներգրավվածության ավելացում ունեցան, և հաջողության հիմնական պատճառները զարգացման արդյունավետ գործընթացներն էին և ուժեղ ինժեներական մշակույթը:
• DevOps-ի պրակտիկա, գործիքներ և դրանց մշակում: Ընկերությունների հաջորդ տարվա հիմնական ծրագրերը ներառում են DevOps պրակտիկայի և գործիքների զարգացում, DevSecOps պրակտիկաների ներդրում և կազմակերպչական կառուցվածքի փոփոխություններ: Իսկ DevOps-ի պրակտիկայի արդյունավետ իրականացումն ու զարգացումն իրականացվում է պիլոտային նախագծերի, համայնքների և գերազանցության կենտրոնների ձևավորման, ձեռնարկությունների վերին և ստորին մակարդակներում նախաձեռնությունների միջոցով:

Մենք կցանկանայինք լսել ձեր կարծիքը, պատմությունները, արձագանքները: Մենք շնորհակալություն ենք հայտնում բոլոր նրանց, ովքեր մասնակցել են ուսումնասիրությանը և անհամբեր սպասում ենք ձեր մասնակցությանը հաջորդ տարի:

Source: www.habr.com