Ресейдегі DevOps жағдайы 2020

Сіз бір нәрсенің күйін қалай түсінесіз?

Сіз әртүрлі ақпарат көздерінен, мысалы, веб-сайттардағы жарияланымдардан немесе тәжірибеден алынған пікіріңізге сене аласыз. Әріптестеріңіз бен достарыңыздан сұрай аласыз. Тағы бір нұсқа – конференциялардың тақырыптарын қарау: бағдарлама комитеті саланың белсенді өкілдері болып табылады, сондықтан біз оларға өзекті тақырыптарды таңдауда сенеміз. Жеке сала - зерттеулер мен есептер. Бірақ мәселе бар. DevOps жағдайы туралы зерттеулер бүкіл әлем бойынша жыл сайын жүргізіледі, есептерді шетелдік компаниялар шығарады, ал ресейлік DevOps туралы ақпарат жоқтың қасы.

Бірақ мұндай зерттеу жүргізілетін күн келді, бүгін біз оның нәтижелері туралы айтатын боламыз. Ресейдегі DevOps жағдайын компаниялар бірлесіп зерттеді »Экспресс 42«Ал»Онтико" Express 42 компаниясы технологиялық компанияларға DevOps тәжірибелері мен құралдарын енгізуге және дамытуға көмектеседі және Ресейде DevOps туралы алғашқылардың бірі болды. Зерттеудің авторлары Игорь Курочкин мен Виталий Хабаров Экспресс 42-де талдау және кеңес берумен айналысады, олардың техникалық білімі мен әртүрлі компаниялардағы тәжірибесі бар. 8 жыл ішінде әріптестер әртүрлі проблемалары бар, сондай-ақ мәдени және инженерлік жетілуі әртүрлі ондаған компаниялар мен жобаларды - стартаптардан бастап кәсіпорындарға дейін қарады.

Өз баяндамасында Игорь мен Виталий зерттеу процесінде қандай мәселелер болғанын, оларды қалай шешкенін, сондай-ақ DevOps зерттеулері негізінен қалай жүргізілетінін және Express 42 неліктен өздерін жүргізуге шешім қабылдағанын түсіндірді. Сіз олардың есебін көре аласыз осында.

DevOps Research

Әңгімені Игорь Курочкин бастады.

Біз DevOps конференцияларында аудиториядан үнемі сұраймыз: «Сіз осы жылғы DevOps жағдайының есебін оқыдыңыз ба?» Кейбіреулер ғана қолдарын көтереді, бірақ біздің зерттеулеріміз оларды тек үшінші біреудің ғана зерттейтінін көрсетті. Егер сіз мұндай есептерді ешқашан көрмеген болсаңыз, олардың барлығы өте ұқсас екенін бірден айтайық. Көбінесе «өткен жылмен салыстырғанда ...» сияқты тіркестер бар.

Міне, бізде бірінші мәселе бар, содан кейін тағы екеуі:

1. Бізде өткен жылдың деректері жоқ. Ресейдегі DevOps жағдайы ешкімді қызықтырмайды;
2. Әдістеме. Гипотезаларды тексеру, сұрақтарды құру, талдау, нәтижелерді салыстыру, байланыстарды қалай табуға болатыны түсініксіз;
3. Терминология. Барлық есептер ағылшын тілінде, аударма қажет, DevOps үшін ортақ негіз әлі ойлап табылған жоқ және әркім өзінше ойлап табады.

Әлемдегі DevOps жағдайына талдаулар қалай жүргізілгенін қарастырайық.

Тарихи негіз

DevOps зерттеулері 2011 жылдан бері жүргізіліп келеді. Оларды бірінші болып конфигурацияларды басқару жүйелерін жасаушы Қуыршақ жүргізді. Ол кезде код түріндегі инфрақұрылымды сипаттайтын негізгі құралдардың бірі болды. 2013 жылға дейін бұл зерттеулер жабық форматта және көпшілік алдында есеп берусіз жай ғана сауалнамалар болды.

2013 жылы DevOps бойынша барлық негізгі кітаптарды шығарушы IT Revolution пайда болды. Қуыршақпен бірге олар «DevOps күйі» атты алғашқы басылымды дайындады, онда 4 негізгі метрика алғаш рет пайда болды. Келесі жылы ThoughtWorks консалтингтік компаниясы салалық тәжірибелер мен құралдар бойынша тұрақты технологиялық радарларымен танымал болды. Ал 2015 жылы әдістемесі бар бөлім қосылып, талдауды қалай жүргізетіні белгілі болды.

2016 жылы зерттеу авторлары өздерінің DORA (DevOps Research and Assessment) компаниясын құрып, жылдық есебін жариялады. Келесі жылы DORA және Puppet бірлескен қорытынды есебін шығарды.

Содан кейін қызық болды:

2018 жылы компаниялар бөлініп, екі тәуелсіз есеп шығарылды: біреуі қуыршақтан, екіншісі Google-мен бірлесіп DORA-дан. DORA өз әдістемесін негізгі метрикалармен, өнімділік профильдерімен және компаниядағы негізгі көрсеткіштер мен өнімділікке әсер ететін инженерлік тәжірибелермен қолдануды жалғастырды. Қуыршақ процесті және DevOps эволюциясын сипаттайтын өзіндік көзқарасты ұсынды. Бірақ оқиға орындалмады; 2019 жылы Қуыршақ бұл әдістемеден бас тартты және есептердің жаңа нұсқасын шығарды, онда негізгі тәжірибелер және олардың DevOps-қа олардың көзқарасы бойынша қалай әсер ететіні көрсетілген. Содан кейін тағы бір оқиға болды: Google DORA-ны сатып алды және олар бірге басқа есеп шығарды. Мүмкін сіз көрген шығарсыз.

Биыл жағдай күрделене түсті. Қуыршақ өз сауалнамасын бастағаны белгілі. Олар мұны бізден бір апта бұрын жасады, қазірдің өзінде аяқталды. Біз оған қатысып, олардың қандай тақырыптарға қызығатынын қарадық. Қазір Қуыршақ сараптамасын жасап, баяндамасын шығаруға дайындалып жатыр.

Бірақ DORA мен Google-дан әлі хабарландыру жоқ. Мамыр айында сауалнама әдетте басталған кезде, DORA негізін қалаушылардың бірі Николь Форсгрен басқа компанияға ауысты деген ақпарат келді. Сондықтан біз биыл DORA-дан ешқандай зерттеулер мен есеп болмайды деп болжадық.

Ресейде жағдай қалай?

Біз DevOps туралы ешқандай зерттеу жүргізген жоқпыз. Біз конференцияларда сөз сөйлеп, басқа адамдардың тұжырымдарын айтып бердік, ал Райффайзенбанк 2019 жылға арналған «ДевОпс күйін» аударды (олардың хабарландыруын Habré сайтынан таба аласыз), оларға үлкен рахмет. Және бәрі.

Сондықтан біз Ресейде DORA әдістемелері мен нәтижелерін пайдалана отырып, өз зерттеулерімізді жүргіздік. Біз Райффайзенбанктегі әріптестердің есебін зерттеу үшін, соның ішінде терминология мен аударманы синхрондау үшін пайдаландық. Ал салаға қатысты сұрақтар DORA есептерінен және биылғы қуыршақ сауалнамасынан алынды.

Зерттеу процесі

Есеп тек қорытынды бөлім болып табылады. Бүкіл зерттеу процесі төрт негізгі кезеңнен тұрады:

Дайындық кезеңінде біз сала мамандарымен сұхбаттасып, гипотезалар тізімін дайындадық. Солардың негізінде біз сұрақтар құрастырып, бүкіл тамыз айына сауалнама жүргіздік. Сосын баяндаманың өзін талдап, дайындадық. DORA үшін бұл процесс 6 айға созылады. Біз оны 3 айда бітірдік, енді уақытымыз аз болғанын түсіндік: талдау жасау арқылы ғана қандай сұрақтар қою керектігін түсінесіз.

қатысушылар

Шетелдік репортаждардың барлығы қатысушылардың портретімен басталады және олардың көпшілігі Ресейден емес. Ресейлік респонденттердің пайызы жыл сайын 5-тен 1 пайызға дейін ауытқиды, бұл ешқандай қорытынды жасауға мүмкіндік бермейді.

Accelerate State of DevOps 2019 есебінің картасы:

Зерттеу барысында біз 889 адаммен сұхбаттасу мүмкіндігіне ие болдық – бұл өте көп (DORA жыл сайын өз есептерінде мыңға жуық адамнан сауалнама жүргізеді) және біз өз мақсатымызға жеттік:

Рас, біздің қатысушылардың барлығы да соңына жеткен жоқ: аяқтау пайызы жартысынан сәл аз болды. Бірақ бұл репрезентативті үлгіні алу және талдау жүргізу үшін жеткілікті болды. DORA өз есептерінде толтыру пайызын ашпайды, сондықтан мұнда салыстыру жоқ.

Салалар мен лауазымдар

Біздің респонденттер ондаған саланың өкілдері. Жартысы ақпараттық технология саласында жұмыс істейді. Одан кейін қаржылық қызмет, сауда, телекоммуникация және т.б. Лауазымдар арасында мамандар (әзірлеуші, сынақшы, пайдалану инженері) және басқарушы персонал (топтардың, топтардың, учаскелердің жетекшілері, директорлар) бар:

Әрбір екінші адам орта компанияда жұмыс істейді. Әрбір үшінші адам ірі компанияларда жұмыс істейді. Көбісі 9 адамнан тұратын командаларда жұмыс істейді. Біз негізгі қызмет түрлері туралы бөлек сұрадық, олардың көпшілігі операцияға қатысты, ал шамамен 40% әзірлеуге қатысады:

Біз әртүрлі салалардың, компаниялардың және командалардың өкілдерін салыстыру және талдау үшін ақпаратты осылай жинадық. Талдау туралы әріптесім Виталий Хабаров айтып береді.

Талдау және салыстыру

Виталий Хабаров: Біздің сауалнамамызды аяқтаған, сауалнамалар толтырған және гипотезаларды әрі қарай талдау және сынау үшін бізге мәліметтер берген барлық қатысушыларға үлкен рахмет. Клиенттеріміз бен тұтынушыларымыздың арқасында бізде салалық алаңдаушылықтарды анықтауға және зерттеуімізде тексерген гипотезаларды тұжырымдауға көмектескен бай тәжірибеміз бар.

Өкінішке орай, сіз бір жағынан сұрақтар тізімін және екінші жағынан деректерді ала алмайсыз, қандай да бір түрде оларды салыстыра алмайсыз: «Иә, бәрі солай болды, біз дұрыс болдық» деп айтып, өз жолымызбен жүре аласыз. Жоқ, қателеспегенімізге және тұжырымдарымыздың сенімділігіне сенімді болу үшін әдіснама мен статистикалық әдістер қажет. Содан кейін біз келесі деректер негізінде өз жұмысымызды құра аламыз:

Негізгі көрсеткіштер

Біз DORA әдістемесін негізге алдық, олар оны «DevOps күйін жеделдету» кітабында егжей-тегжейлі сипаттады. Біз негізгі көрсеткіштердің ресейлік нарыққа сәйкес келетінін тексердік, оларды DORA «Ресейдегі өнеркәсіп шетелдік өнеркәсіпке қалай сәйкес келеді?» Деген сұраққа жауап беру үшін қолданатын әдіспен қолдануға бола ма, жоқ па?

Негізгі көрсеткіштер:

1. Орналастыру жиілігі. Қолданбаның жаңа нұсқасы өндіріс ортасына қаншалықты жиі қолданылады (жоспарланған өзгерістер, түзетулерді және оқиғаға жауап беруді қоспағанда)?
2. Жеткізілім мерзімі. Өзгерістерді жасау (функционалдылықты код ретінде жазу) мен өзгертуді өндіріс ортасына енгізу арасындағы орташа уақыт қанша?
3. Қалпына келтіру уақыты. Оқиғадан, қызметтің нашарлауынан немесе қолданба пайдаланушыларына әсер ететін қатені анықтағаннан кейін қолданбаны өндірістік ортада қалпына келтіру орта есеппен қанша уақытты алады?
4. Сәтсіз өзгерістер. Өндіріс ортасындағы орналастырулардың қанша пайызы қолданбаның нашарлауына немесе инциденттерге әкеледі және түзетуді қажет етеді (өзгерістерді қайтару, түзетуді немесе патчты әзірлеу)?

DORA зерттеулері осы көрсеткіштер мен ұйымдық өнімділік арасындағы байланысты тапты. Біз оны зерттеуімізде де тексереміз.

Бірақ төрт негізгі көрсеткіш бір нәрсеге әсер ете алатынына көз жеткізу үшін сіз түсінуіңіз керек - олар бір-бірімен қандай да бір түрде байланысты ма? DORA иә деп жауап берді, бір ескертумен: Өзгерту сәтсіздігі деңгейі мен қалған үш көрсеткіш арасындағы байланыс сәл әлсіз. Біз шамамен бірдей суретті алдық. Егер жеткізу уақыты, орналастыру жиілігі және қалпына келтіру уақыты бір-бірімен корреляцияланса (біз бұл корреляцияны Пирсон корреляциясы және Чаддок шкаласы арқылы орнаттық), онда сәтсіз өзгерістермен мұндай күшті корреляция болмайды.

Негізінде, респонденттердің көпшілігі өндірісте орын алатын оқиғалардың өте аз саны бар деп жауап береді. Сәтсіз өзгерістер жылдамдығында респонденттердің топтары арасында әлі де айтарлықтай айырмашылық бар екенін кейінірек көретін болсақ та, біз бұл көрсеткішті осы бөлу үшін әлі пайдалана алмаймыз.

Біз мұны (талдау және біздің кейбір тұтынушылармен қарым-қатынас барысында белгілі болғандай) оқиға деп саналатын нәрсені қабылдауда шамалы айырмашылық бар екендігімен байланыстырамыз. Егер техникалық терезеде қызметіміздің функционалдығын қалпына келтіре алсақ, мұны оқиға деп санауға бола ма? Жоқ шығар, өйткені біз бәрін жөндедік, біз кереметпіз. Егер қосымшаны әдеттегі, таныс режимде 10 рет қайталау керек болса, бұл оқиға деп санауға бола ма? Жоқ сияқты. Сондықтан, сәтсіз өзгерістер мен басқа көрсеткіштер арасындағы байланыс мәселесі ашық күйінде қалады. Оны әрі қарай нақтылайтын боламыз.

Бұл жерде маңыздысы жеткізу уақыты, қалпына келтіру уақыты және орналастыру жиілігі арасындағы маңызды корреляцияны таптық. Сондықтан біз респонденттерді өнімділікке қарай топтарға бөлу үшін осы үш көрсеткішті алдық.

Граммен қаптау қанша?

Біз иерархиялық кластерлік талдауды қолдандық:

• Біз респонденттерді n өлшемді кеңістікке таратамыз, мұнда әрбір респонденттің координатасы олардың сұрақтарға жауаптары болып табылады.
• Біз әрбір респондентті шағын кластер деп жариялаймыз.
• Біз бір-біріне жақын екі кластерді үлкенірек бір кластерге біріктіреміз.
• Біз кластерлердің келесі жұбын тауып, оларды үлкенірек кластерге біріктіреміз.

Осылайша біз барлық респонденттерді бізге қажетті кластерлер санына топтастырамыз. Дендрограмманы (кластерлер арасындағы байланыстар ағашы) пайдалана отырып, біз көршілес екі кластер арасындағы қашықтықты көреміз. Бізге қалғаны осы кластерлер арасындағы қашықтыққа белгілі бір шектеу қою және: «Бұл екі топ бір-бірінен айтарлықтай ерекшеленеді, өйткені олардың арасындағы қашықтық орасан зор».

Бірақ бұл жерде жасырын мәселе бар: бізде кластерлердің санына ешқандай шектеулер жоқ - біз 2, 3, 4, 10 кластерді ала аламыз. Ал бірінші идея - неге біздің барлық респонденттерді DORA сияқты 4 топқа бөлмеске? Бірақ біз бұл топтар арасындағы айырмашылықтардың елеусіз болатынын анықтадық және респонденттің көрші топқа емес, шынымен де өз тобына жататынына сенімді бола алмаймыз. Біз Ресей нарығын әлі төрт топқа бөле алмаймыз. Сондықтан біз үш профильге тоқтадық, олардың арасында статистикалық маңызды айырмашылық бар:

Содан кейін профильді кластерлер бойынша анықтадық: біз әр топ үшін әрбір метрика үшін медиананы алып, өнімділік профильдерінің кестесін құрастырдық. Шын мәнінде, біз әр топтағы орташа қатысушының өнімділік профилін алдық. Біз үш тиімділік профилін анықтадық: төмен, орташа, жоғары:

Мұнда біз 4 негізгі көрсеткіш өнімділік профилін анықтау үшін қолайлы және олар батыс және ресейлік нарықтарда жұмыс істейді деген гипотезамызды растадық. Топтар арасында айырмашылық бар және ол статистикалық тұрғыдан маңызды. Сәтсіз өзгерістер метрикасының өнімділік профильдері арасында орташа мәнде айтарлықтай айырмашылық бар екенін атап өткім келеді, дегенмен біз бастапқыда респонденттерді осы параметр бойынша бөлген жоқпыз.

Сонда сұрақ туындайды: мұның бәрін қалай пайдалануға болады?

Қалай пайдалануға болады

Егер біз кез келген команданы, 4 негізгі көрсеткішті алып, оны кестеге қолданатын болсақ, онда 85% жағдайда біз толық сәйкестікке ие болмаймыз - бұл шын мәнінде емес, орташа қатысушы. Біз бәріміз (және әрбір команда) сәл өзгешеміз.

Біз тексердік: біз респонденттерді және DORA өнімділік профилін алдық және қанша респондент осы немесе басқа профильге сәйкес келетінін қарадық. Біз респонденттердің тек 16% профильдердің біріне дәл енгенін анықтадық. Қалғандарының бәрі бір жерде шашыраңқы:

Бұл тиімділік профилінің шектеулі ауқымы бар екенін білдіреді. Қай жерде екеніңізді анықтау үшін мына кестені пайдалана аласыз: «О, біз Орташа немесе Жоғарыға жақынырақ сияқтымыз!» Әрі қарай қайда бару керектігін түсінсеңіз, бұл жеткілікті болуы мүмкін. Бірақ егер сіздің мақсатыңыз тұрақты, үздіксіз жетілдіру болса және сіз қай жерде даму керектігін және не істеу керектігін дәлірек білгіңіз келсе, онда қосымша қаражат қажет. Біз оларды калькулятор деп атадық:

• DORA калькуляторы
• Калькулятор Express 42* (әзірлеуде)
• Сіздің жеке дамуыңыз (сіз өзіңіздің ішкі калькуляторыңызды жасай аласыз).

Олар не үшін қажет? Түсіну:

• Біздің ұйымдағы команда біздің стандарттарымызға сәйкес келе ме?
• Егер жоқ болса, біз оған көмектесе аламыз ба - біздің компанияның тәжірибесі аясында оны тездете аламыз ба?
• Егер солай болса, біз одан да жақсырақ жасай аламыз ба?

Сондай-ақ оларды компания ішінде статистиканы жинау үшін пайдалануға болады:

• Бізде қандай командалар бар?
• Командаларды профильдерге бөлу;
• Қараңыз: О, бұл командалар төмен жұмыс істейді (сәл баяу), бірақ бұл тамаша: олар күн сайын қатесіз орналасады, олардың жеткізу уақыты бір сағаттан аз.

Сонда сіз біздің компанияда әлі де деңгейге жетпеген командалар үшін қажетті тәжірибе мен құралдар бар екенін біле аласыз.

Немесе, егер сіз компанияда өзіңізді керемет сезінетініңізді, сіз көптеген адамдардан жақсы екеніңізді түсінсеңіз, сіз сәл кеңірек қарай аласыз. Бұл дәл Ресей өнеркәсібі: біз өзімізді жылдамдату үшін ресейлік индустрияда қажетті тәжірибені ала аламыз ба? Мұнда Express 42 калькуляторы көмектеседі (ол әзірленуде). Егер сіз ресейлік нарықтан асып кетсеңіз, қараңыз DORA калькуляторы және әлемдік нарыққа.

Жақсы. Ал егер сіз DORA калькуляторы бойынша Elit тобында болсаңыз, онда не істеу керек? Бұл жерде жақсы шешім жоқ. Сірә, сіз саланың алдыңғы қатарындасыз және ішкі ҒЗТКЖ және үлкен ресурстарды жұмсау арқылы одан әрі жеделдету мен сенімділікті жақсартуға болады.

Ең тәттіге - салыстыруға көшейік.

Салыстыру

Біз бастапқыда Ресей өнеркәсібін батыс өнеркәсібімен салыстырғымыз келді. Тікелей салыстыратын болсақ, бізде профильдер аз екенін көреміз және олар бір-бірімен сәл араласқан, шекаралар біршама бұлыңғыр:

Біздің Элита-орындаушылар Жоғары орындаушылардың арасында жасырынған, бірақ олар бар - бұл элита, айтарлықтай биіктерге жеткен жалғыз мүйізділер. Ресейде элиталық және жоғары профильдер арасындағы айырмашылық әлі де маңызды емес. Болашақта бұл бөліну инженерлік мәдениеттің, инженерлік тәжірибені енгізу сапасының және компаниялар ішінде сараптаманың артуы есебінен болады деп ойлаймыз.

Егер біз ресейлік индустрияның ішінде тікелей салыстыруға көшетін болсақ, жоғары профильді командалардың барлық жағынан жақсырақ екенін көреміз. Біз сондай-ақ осы көрсеткіштер мен ұйымдық тиімділік арасында байланыс бар деген гипотезамызды растадық: Жоғары профильді командалар мақсаттарға қол жеткізіп қана қоймай, олардан да асып түседі.
Жоғары профильді команда болайық және мұнымен тоқтап қалмаймыз:

Бірақ биылғы жыл ерекше және біз компаниялардың пандемияда қалай өмір сүріп жатқанын тексеруді шештік: Жоғары профильді командалар айтарлықтай жақсы күреседі және саланың орташа деңгейінен жақсы сезінеді:

• Жаңа өнімдер 1,5-2 есе жиі шығарылды,
• Қолданба инфрақұрылымының сенімділігін және/немесе өнімділігін арттыру ықтималдығы 2 есе жоғары.

Яғни, олар тезірек дамытуға, жаңа өнімдерді енгізуге, бар өнімдерді өзгертуге, сол арқылы жаңа нарықтар мен жаңа пайдаланушыларды бағындыруға көмектескен құзыреттер:

Біздің командаларға тағы не көмектесті?

Инженерлік тәжірибелер

Біз тексерген әрбір тәжірибе үшін маңызды нәтижелер туралы айтып беремін. Мүмкін, командаларға тағы бір нәрсе көмектесті, бірақ біз DevOps туралы айтып отырмыз. DevOps ішінде біз әртүрлі профильдегі командалар арасындағы айырмашылықтарды көреміз.

Платформа қызмет ретінде

Біз платформаның жасы мен команда профилі арасында маңызды байланыс таппадық: платформалар төмен және жоғары командалар үшін шамамен бір уақытта пайда болды. Бірақ соңғысы үшін платформа орта есеппен қосымша қызметтерді және бағдарлама коды арқылы басқару үшін қосымша бағдарламалау интерфейстерін ұсынады. Платформа командалары өздерінің әзірлеушілері мен топтарына платформаны пайдалануға, олардың проблемалары мен платформаға қатысты оқиғаларды жиі шешуге және басқа командаларды оқытуға көмектесуі ықтимал.

Инфрақұрылым код ретінде

Мұнда бәрі өте стандартты. Біз инфрақұрылымдық кодты автоматтандыру мен инфрақұрылым репозиторийінде қанша ақпарат сақталатыны арасындағы байланысты таптық. Жоғары профильді топтар репозиторийлерде қосымша ақпаратты сақтайды: бұған инфрақұрылым конфигурациясы, CI/CD құбыры, орта параметрлері және құрастыру параметрлері кіреді. Олар бұл ақпаратты жиі сақтайды, инфрақұрылымдық кодпен жақсы жұмыс істейді және инфрақұрылымдық кодпен жұмыс істеу үшін көбірек процестер мен тапсырмаларды автоматтандырды.

Бір қызығы, біз инфрақұрылымдық сынақтарда айтарлықтай айырмашылықты көрмедік. Мен мұны жоғары профильді топтарда тестілеуді автоматтандырудың көбірек болуымен байланыстырамын. Мүмкін, олар инфрақұрылымдық сынақтармен бөлек алаңдамауы керек, керісінше олар қосымшаларды тексеретін сынақтар және олардың арқасында олар нені және қай жерде бұзылғанын көреді.

Интеграция және жеткізу

Ең қызықсыз бөлім, өйткені біз растадық: сізде автоматтандыру неғұрлым көп болса, кодпен соғұрлым жақсы жұмыс істесеңіз, соғұрлым жақсы нәтижелерге қол жеткізу ықтималдығы жоғары.

сәулет

Біз микросервистердің өнімділікке қалай әсер ететінін көргіміз келді. Шынымды айтсам, олай емес, өйткені микросервистерді пайдалану тиімділік көрсеткіштерінің артуына байланысты емес. Микросервистер жоғары профиль пәрмендері үшін де, төмен профиль пәрмендері үшін де пайдаланылады.

Бірақ маңыздысы, жоғары командалар үшін микросервис архитектурасына көшу оларға өз қызметтерін дербес дамытуға және оларды шығаруға мүмкіндік береді. Егер архитектура әзірлеушілерге командадан тыс біреуді күтпей-ақ автономды әрекет етуге мүмкіндік берсе, онда бұл жылдамдықты арттырудың негізгі құзыреті. Бұл жерде микросервистер көмектеседі. Бірақ жай ғана оларды жүзеге асыру үлкен рөл атқармайды.

Мұның бәрін біз қалай аштық?

Бізде DORA әдістемесін толығымен қайталау үшін амбициялық жоспарымыз болды, бірақ ресурстар жетіспеді. Егер DORA демеушілік көмекті көп қолданса және олардың зерттеулеріне жарты жыл қажет болса, біз зерттеуімізді қысқа мерзімде жасадық. Біз DORA сияқты DevOps үлгісін жасағымыз келді және оны болашақта жасаймыз. Әзірге біз жылу карталарымен шектелдік:

Біз әр профильдегі командалар арасында инженерлік тәжірибелердің таралуын қарастырдық және жоғары профильді командалар орта есеппен инженерлік тәжірибені жиі қолданатынын анықтадық. Мұның бәрі туралы толығырақ біздің мақаладан оқи аласыз есеп.

Өзгеріс үшін күрделі статистикадан қарапайымға ауысайық.

Біз тағы не аштық?

Құралдар

Біз командалардың көпшілігін Linux отбасының ОЖ пайдаланатынын байқаймыз. Бірақ Windows әлі де трендте - респонденттердің кем дегенде төрттен бірі оның бір немесе басқа нұсқасын пайдалануды атап өтті. Нарықта осындай қажеттілік бар сияқты. Сондықтан сіз осы құзыреттерді дамыта аласыз және конференцияларда баяндамалар жасай аласыз.

Оркестрлер арасында Кубернетестің (52%) жетекші екені ешкімге құпия емес. Келесі оркестр - Docker Swarm (шамамен 12%). Ең танымал CI жүйелері Дженкинс және GitLab болып табылады. Ең танымал конфигурацияны басқару жүйесі - Ansible, одан кейін біздің сүйікті Shell.

Бұлтты хостинг провайдерлерінің арасында қазіргі уақытта Amazon жетекші орынды алады. Ресейлік бұлттардың үлесі бірте-бірте артып келеді. Келесі жылы ресейлік бұлттық провайдерлердің қалай сезінетінін және олардың нарықтағы үлесі арта ма, соны білу қызықты болады. Олар бар, оларды пайдалануға болады және бұл жақсы:

Игорьге сөз беремін, ол тағы да статистикалық мәліметтер береді.

Тәжірибелердің таралуы

Игорь Курочкин: Біз респонденттерден қарастырылған инженерлік тәжірибенің компанияда қалай таралатынын көрсетуді сұрадық. Көптеген компаниялар әртүрлі үлгілер жиынтығынан тұратын аралас тәсілге ие және пилоттық жобалар өте танымал. Біз профильдер арасында шамалы айырмашылықты да көрдік. Жоғары профиль өкілдері «Төменнен бастама» үлгісін жиі пайдаланады, бұл кезде шағын мамандар топтары жұмыс процестерін, құралдарды өзгертіп, сәтті әзірлемелермен басқа командалармен бөліседі. Medium-да бұл қауымдастықтар мен шеберлік орталықтарын құру арқылы бүкіл компанияны қозғайтын жоғарыдан төмен бастама:

Agile және DevOps

Agile және DevOps арасындағы қарым-қатынас салада жиі талқыланады. Бұл сұрақ 2019/2020 жылдарға арналған Agile күйінің есебінде де көтерілген, сондықтан біз компаниялардағы Agile және DevOps әрекеттерінің қалай байланысты екенін салыстыруды жөн көрдік. Agile жоқ DevOps сирек кездесетінін анықтадық. Респонденттердің жартысы үшін Agile-тің таралуы айтарлықтай ерте басталды, ал шамамен 20% бір уақытта басталуды байқады, ал төмен профиль белгілерінің бірі Agile және DevOps тәжірибесінің болмауы болады:

Топ топологиялары

Өткен жылдың соңында кітап «Топ топологиялары«, ол команда топологияларын сипаттау үшін негізді ұсынады. Бұл ресейлік компанияларға қатысты ма деп ойладық. Ал біз: «Сіз қандай өрнектерді көріп тұрсыз?» Деген сұрақты қойдық.

Респонденттердің жартысында жеке әзірлеу, тестілеу және пайдалану топтары сияқты инфрақұрылымдық топтар бар. Жеке DevOps командалары 45% атап өтті, олардың арасында Жоғары өкілдер жиі кездеседі. Одан кейін жоғарыда жиі кездесетін кросс-функционалды командалар келеді. Бөлек SRE пәрмендері Жоғары, Орташа профильдерде пайда болады және Төмен профильде сирек кездеседі:

DevQaOps қатынасы

Біз бұл сұрақты Facebook-те Skyeng платформасы командасының жетекшісінен көрдік - оны компаниялардағы әзірлеушілер, тестерлер мен әкімшілер қатынасы қызықтырды. Біз оны сұрадық және профильдерді ескере отырып жауаптарды қарадық: Жоғары профиль өкілдерінде әрбір әзірлеушіге арналған тестілеу және операциялық инженерлердің саны аз:

2021 жыл үшін жоспар

Келесі жылға арналған жоспарларында респонденттер келесі іс-шараларды атап өтті:

Мұнда DevOps Live 2020 конференциясымен қиылысуды көре аласыз. Біз бағдарламаны мұқият қарап шықтық:

• Инфрақұрылым өнім ретінде
• DevOps трансформациясы
• DevOps тәжірибелерін тарату
• DevSecOps
• Кейс клубтары және пікірталас

Бірақ біздің презентациямыздың уақыты барлық тақырыптарды қамтуға жеткіліксіз. Сырттағы күбір-сыбыр әңгіме:

• Қызмет және өнім ретінде платформа;
• Инфрақұрылым код, орта және бұлт ретінде;
• Үздіксіз интеграция және жеткізу;
• Архитектура;
• DevSecOps үлгілері;
• Платформа және кросс-функционалды командалар.

Есеп Біздікі көлемді, көлемі 50 бет, оны толығырақ қарауға болады.

Қорытындылау

Біздің зерттеулеріміз бен есептеріміз сізге әзірлеуге, тестілеуге және жұмыс істеуге арналған жаңа тәсілдермен тәжірибе жасауға шабыттандырады, сондай-ақ өз ұстанымдарыңызды алуға, зерттеу барысында өзіңізді басқалармен салыстыруға және өзіңіздің көзқарастарыңызды жақсартуға болатын салаларды анықтауға көмектеседі деп үміттенеміз. .

Ресейдегі DevOps жағдайын бірінші зерттеудің нәтижелері:

• Негізгі көрсеткіштер. Біз негізгі көрсеткіштердің (жеткізу уақыты, орналастыру жылдамдығы, қалпына келтіру уақыты және қателерді өзгерту) әзірлеу, тестілеу және операциялық процестердің тиімділігін талдау үшін қолайлы екенін анықтадық.
• Профильдер Жоғары, Орташа, Төмен. Жиналған деректерге сүйене отырып, статистикалық түрде әртүрлі топтарды анықтауға болады: Жоғары, Орташа, Төмен, көрсеткіштерге, тәжірибелерге, процестерге және құралдарға негізделген ерекше белгілері бар. Жоғары профильдің өкілдері төменге қарағанда жақсы нәтиже көрсетеді. Олар өз мақсаттарына жетуге және одан асып кетуге бейім.
• Көрсеткіштер, пандемия және 2021 жылға арналған жоспарлар. Биылғы жылдың ерекше көрсеткіші – компаниялардың пандемиямен қалай күрескені. Жоғары өкілдер жақсырақ жұмыс істеді, пайдаланушылардың белсенділігін арттырды және табысқа жетудің негізгі себептері тиімді даму процестері мен күшті инженерлік мәдениет болды.
• DevOps тәжірибелері, құралдары және олардың дамуы. Компаниялардың келесі жылға арналған негізгі жоспарларына DevOps тәжірибелері мен құралдарын дамыту, DevSecOps тәжірибелерін енгізу және ұйымдық құрылымдағы өзгерістер кіреді. Ал DevOps тәжірибесін тиімді енгізу және дамыту пилоттық жобалар, қауымдастықтар мен құзырет орталықтарын қалыптастыру, компанияның жоғарғы және төменгі деңгейіндегі бастамалар арқылы жүзеге асырылады.

Біз сіздің пікірлеріңізді, әңгімелеріңізді, пікірлеріңізді тыңдауға қуаныштымыз. Зерттеуге қатысқандардың барлығына алғысымызды білдіреміз және келесі жылы қатысуларыңызды күтеміз.

Ақпарат көзі: www.habr.com