Россиядагы DevOps абалы 2020

Бир нерсенин абалын кантип түшүнүүгө болот?

Сиз ар кандай маалымат булактарынан түзүлгөн пикириңизге, мисалы, веб-сайттардагы басылмаларга же тажрыйбага таяна аласыз. Кесиптештерден, тааныштардан сурасаңыз болот. Дагы бир вариант – конференциялардын темаларын карап чыгуу: программалык комитет бул тармактын активдүү өкүлдөрү, ошондуктан тиешелүү темаларды тандоодо аларга ишенебиз. Өзүнчө аймак изилдөө жана отчет болуп саналат. Бирок бир проблема бар. Дүйнөдө DevOps абалы боюнча изилдөөлөр жыл сайын жүргүзүлүп, чет элдик компаниялар тарабынан отчеттор жарыяланып турат, орусиялык DevOps жөнүндө маалымат дээрлик жок.

Бирок мындай изилдөө жүргүзүлгөн күн келди, бүгүн анын жыйынтыгы тууралуу сөз кылабыз. Орусиядагы DevOps абалы компаниялар тарабынан биргелешип изилденген "Экспресс 42"Ал эми"Ontico". Express 42 технологиялык компанияларга DevOps тажрыйбаларын жана куралдарын ишке ашырууга жана өнүктүрүүгө жардам берет жана Россияда DevOps жөнүндө биринчилерден болуп сөз кылган. Иликтөөнүн авторлору Игорь Курочкин менен Виталий Хабаров Экспресс 42де талдоо жана консалтинг менен алектенишет, ошол эле учурда ар кандай компанияларда иштөө жана тажрыйба боюнча техникалык билимге ээ. 8 жыл ичинде кесиптештер стартаптардан баштап ишканаларга чейин ар кандай көйгөйлөрү бар, ошондой эле ар кандай маданий жана инженердик жактан жетилген ондогон компанияларды жана долбоорлорду карап чыгышты.

Өз баяндамасында Игорь жана Виталий изилдөө процессинде кандай көйгөйлөр бар экенин, аларды кантип чечкенин, ошондой эле DevOps изилдөөлөрү принципиалдуу түрдө кандай жүргүзүлөрүн жана эмне үчүн Express 42 өз алдынча жүргүзүүнү чечкенин айтып беришти. Алардын отчетун көрүүгө болот бул жерде.

DevOps изилдөө

Сүйлөшүүнү Игорь Курочкин баштады.

Биз дайыма 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 жана Куурчак акыркы биргелешкен отчетун чыгарышты.

Анан кызыктуу нерсе башталды:

2018-жылы компаниялар экиге бөлүнүп, эки көз карандысыз отчет жарык көргөн: бири Куурчактан, экинчиси Google менен биргеликте DORAдан. DORA өзүнүн методологиясын негизги метрикалар, аткаруу профилдери жана негизги метрикаларга жана компаниянын жалпы көрсөткүчтөрүнө таасир этүүчү инженердик практикалар менен колдонууну улантты. Ал эми куурчак процесстин жана DevOps эволюциясынын сүрөттөлүшү менен өзүнүн мамилесин сунуштады. Бирок окуя тамыр жайган жок, 2019-жылы Куурчак бул методологиядан баш тартып, негизги практикаларды жана алардын көз карашы боюнча DevOpsка кандай таасир тийгизгенин тизмелеген отчеттордун жаңы версиясын чыгарды. Андан кийин дагы бир окуя болду: Google DORAны сатып алды жана алар чогуу дагы бир отчетту чыгарышты. Сиз аны көргөн болушуңуз мүмкүн.

Быйыл иш татаалдашты. Куурчак өзүнүн сурамжылоосун баштаганы белгилүү. Алар бизден бир жума эрте кылышты, ал эми бүттү. Биз ага катышып, алар кандай темаларга кызыгып жатканын карап көрдүк. Азыр «Куурчак» өз анализин жасап, отчетун жарыялоого даярданып жатат.

Бирок дагы эле DORA жана Google тарабынан эч кандай жарыя жок. Май айында, адатта, сурамжылоо башталганда, DORAнын негиздөөчүлөрүнүн бири Николь Форсгрен башка компанияга көчүп кеткени тууралуу маалымат келген. Ошондуктан, бул жылы DORAдан эч кандай изилдөө жана отчет болбойт деп ойлогонбуз.

Россияда иштер кандай?

Биз DevOps изилдөө жүргүзө элекпиз. Биз конференцияларда сүйлөп, башка адамдардын тыянактарын айтып бердик жана Райффайзенбанк 2019-жылга "DevOps абалы" которду (алардын жарыясын 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 бир эскертүү менен оң деп жооп берди: ийгиликсиз өзгөрүүлөр (Change Failure Rate) менен башка үч көрсөткүчтүн ортосундагы байланыш бир аз алсызыраак. Бизде болжол менен бир эле сүрөт бар. Эгерде жеткирүү убактысы, жайылтуу жыштыгы жана калыбына келтирүү убактысы бири-бири менен корреляцияланса (биз бул корреляцияны Пирсон корреляциясы жана Чаддок шкаласы аркылуу түздүк), анда ийгиликсиз өзгөрүүлөр менен мындай күчтүү корреляция жок.

Негизи респонденттердин көбү өндүрүштө аз сандагы инциденттер бар деп жооп беришет. Ийгиликсиз өзгөрүүлөр боюнча респонденттердин топторунун ортосунда дагы эле олуттуу айырма бар экенин кийинчерээк көрөбүз, бирок биз бул көрсөткүчтү бул бөлүштүрүү үчүн азырынча колдоно албайбыз.

Биз муну (талдоо жана биздин кээ бир кардарлар менен баарлашууда белгилүү болгондой) окуя деп эсептелген нерсени кабыл алууда бир аз айырмачылык бар экендиги менен байланыштырабыз. Эгерде техникалык терезеде кызматыбыздын иштешин калыбына келтире алсак, муну окуя катары кароого болобу? Мүмкүн жок, анткени биз баарын оңдоп койдук, биз мыктыбыз. Эгер биз өзүбүзгө кадимки, тааныш режимде арызыбызды 10 жолу кайра толтурууга туура келсе, муну окуя деп эсептей алабызбы? Жок окшойт. Демек, ийгиликсиз өзгөрүүлөрдүн башка көрсөткүчтөр менен байланышы жөнүндө маселе ачык бойдон калууда. Биз аны андан ары тактайбыз.

Бул жерде маанилүү нерсе, биз жеткирүү убактысы, калыбына келтирүү убактысы жана жайылтуу жыштыгы ортосунда олуттуу корреляцияны таптык. Ошондуктан, биз респонденттерди эффективдүү топторго бөлүү үчүн ушул үч көрсөткүчтү алдык.

Кантип грамм турсун?

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

• Биз респонденттерди n-өлчөмдүү мейкиндикке бөлүштүрөбүз, мында ар бир респонденттин координаты алардын суроолоруна жооптору болуп саналат.
• Ар бир респондент чакан кластер деп жарыяланды.
• Биз бири-бирине эң жакын болгон эки кластерди чоңураак бир кластерге бириктиребиз.
• Кийинки жуп кластерлерди таап, аларды чоңураак кластерге бириктиребиз.

Мына ушундайча биз бардык респонденттерди бизге керектүү кластерлердин санына топтойбуз. Дендрограмманын (кластерлердин ортосундагы байланыш дарагы) жардамы менен биз эки коңшу кластердин ортосундагы аралыкты көрөбүз. Бизге калганы бул кластерлердин арасына белгилүү бир аралык чегин коюп: «Бул эки топ бири-биринен абдан айырмаланып турат, анткени алардын ортосундагы аралык өтө чоң».

Бирок бул жерде жашыруун көйгөй бар: бизде кластерлердин саны боюнча чектөөлөр жок – 2, 3, 4, 10 кластерлерди ала алабыз. Ал эми биринчи идея - эмне үчүн биздин бардык респонденттерди DORA сыяктуу 4 топко бөлбөйбүз. Бирок биз бул топтордун ортосундагы айырмачылыктар анчалык деле байкалбай калганын байкадык жана респондент чындап эле кошуна эмес, өзүнүн тобуна таандык экенине ишене албайбыз. Биз азырынча орус рыногун төрт топко бөлө албайбыз. Ошентип, биз статистикалык жактан маанилүү айырма бар үч профиль боюнча отурдук:

Андан кийин биз профилди кластерлер боюнча аныктадык: ар бир топ үчүн ар бир метрика үчүн медиананы алып, аткаруу профилдеринин таблицасын түздүк. Чынында, биз ар бир топтун орточо катышуучусунун аткаруу профилдерин алдык. Биз үч эффективдүү профилди аныктадык: Төмөн, Орто, Жогорку:

Бул жерде биз 4 негизги көрсөткүчтөр иштөө профилин аныктоо үчүн ылайыктуу деген гипотезабызды тастыктадык жана алар батыш жана орус базарларында да иштешет. Топтордун ортосунда айырма бар жана бул статистикалык мааниге ээ. Башында респонденттерди бул параметр боюнча бөлгөн жокпуз да, орточо көрсөткүч боюнча ийгиликсиз өзгөрүүлөрдүн метрикасы боюнча аткаруу профилдеринин ортосунда олуттуу айырма бар экенин баса белгилейм.

Анан суроо туулат: мунун баарын кантип колдонуу керек?

Кантип пайдалануу керек

Эгерде биз кандайдыр бир команданы, 4 негизги көрсөткүчтү алып, аны таблицага колдонсок, анда 85% учурларда биз толук дал келбейбиз - бул реалдуу катышуучу эмес, жөнөкөй катышуучу. Биз баарыбыз (жана ар бир команда) бир аз башкачабыз.

Биз текшердик: респондентибизди жана DORA көрсөткүчтөрүн алып, канча респондент тигил же бул профилге туура келерин карап чыктык. Респонденттердин 16% гана профилдердин бирине так түшкөнүн таптык. Калгандарынын баары ортодо чачырап кеткен:

Бул эффективдүү профилдин чектелген чөйрөгө ээ экенин билдирет. Биринчи жакындоодо кайда экениңизди түшүнүү үчүн бул таблицаны колдонсоңуз болот: "Ой, биз Орто же Жогоркуга жакыныраак окшойбуз!" Эгер сиз андан ары кайда барарыңызды түшүнсөңүз, бул жетиштүү болушу мүмкүн. Бирок эгер сиздин максатыңыз туруктуу, үзгүлтүксүз өркүндөтүлсө жана сиз кайда иштеп, эмне кылуу керектигин так билгиңиз келсе, анда кошумча каражат керек. Биз аларды калькулятор деп атадык:

• DORA эсептегич
• Calculator Express 42* (иштеп чыгууда)
• Өзүңүздүн иштеп чыгуу (сиз өзүңүздүн ички эсептегичиңизди түзө аласыз).

Алар эмне үчүн керек? Түшүнүү:

• Биздин уюмдагы команда биздин стандарттарга жооп береби?
• Болбосо, биздин компаниянын тажрыйбасынын алкагында биз ага жардам бере алабызбы?
• Эгер ошондой болсо, биз мындан да жакшыраак кыла алабызбы?

Сиз ошондой эле компаниянын ичинде статистиканы чогултуу үчүн аларды колдоно аласыз:

• Бизде кандай командалар бар?
• Командаларды профилдерге бөлүү;
• Караңыз: О, бул буйруктар аз аткарылууда (алар бир аз чыгарышпайт), бирок булар сонун: алар күн сайын, катасыз, бир сааттан аз убакытка орношот.

Ошондо биздин компаниянын ичинде али деңгээлге жете элек командалар үчүн керектүү тажрыйба жана инструменттер бар экенин биле аласыз.

Же болбосо, эгер сиз компаниянын ичинде өзүңүздү мыкты сезип жатканыңызды түшүнсөңүз, сиз көптөрдөн жакшыраак экениңизди түшүнсөңүз, анда бир аз кененирээк карасаңыз болот. Бул жөн эле орус өнөр жайы: биз өзүбүздү тездетүү үчүн орус өнөр жайында керектүү экспертизаны ала алабызбы? Бул жерде Express 42 эсептегич жардам берет (ал иштелип чыгууда). Эгер сиз Россиянын рыногунан ашып кетсе, анда караңыз DORA эсептегич жана дуйнелук рынокко.

Жакшы. Эгер сиз DORA эсептегичиндеги Элит тобунда болсоңуз, эмне кылышыңыз керек? Бул жерде эч кандай жакшы чечим жок. Сиз, кыязы, тармактын алдыңкы сабындасыз жана андан ары тездетүү жана ишенимдүүлүк ички R&D жана көбүрөөк ресурстарды сарптоо аркылуу мүмкүн.

Келгиле, эң таттууга - салыштырууга өтөбүз.

окшоштук

Биз адегенде орус енер жайын Батыштын енер жайы менен салыштыргыбыз келген. Эгерде биз түздөн-түз салыштырсак, бизде профилдер аз жана алар бири-бири менен бир аз аралашып кеткенин көрөбүз, чек аралар бир аз бүдөмүк:

Биздин Элиталык аткаруучулар Жогорку аткаруучулардын арасында жашырылган, бирок алар бар - булар бир топ бийиктикке жеткен элита, бир мүйүздүү адамдар. Россияда Элиталык профил менен Жогорку профилдин ортосундагы айырма азырынча анчалык деле олуттуу эмес. Келечекте бул бөлүнүү инженердик маданияттын, инженердик тажрыйбаны ишке ашыруунун сапатынын жана компаниялардын ичинде экспертизанын жогорулашынан улам болот деп ойлойбуз.

Эгерде биз Россиянын өнөр жайынын ичиндеги түз салыштырууга өтө турган болсок, анда Жогорку профилдеги командалар бардык жагынан жакшыраак экенин көрөбүз. Биз ошондой эле бул көрсөткүчтөр менен уюштуруучулук көрсөткүчтөрдүн ортосунда байланыш бар деген гипотезабызды ырастадык: Жогорку профилдеги командалар максаттарга гана жетпестен, алардан да ашып кетиши мүмкүн.
Келгиле, жогорку профилдүү команда болуп, муну менен токтоп калбайлы:

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

• жаңы продуктыларды чыгаруу 1,5-2 эсе көп,
• Колдонмонун инфраструктурасынын ишенимдүүлүгүн жана/же аткарууну жакшыртуу үчүн 2 эсе көп.

Башкача айтканда, алар буга чейин эле тезирээк иштеп чыгууга, жаңы өнүмдөрдү чыгарууга, учурдагы өнүмдөрдү өзгөртүүгө, ошону менен жаңы рынокторду жана жаңы колдонуучуларды багынтууга жардам берген:

Биздин командаларга дагы эмне жардам берди?

Инженердик практикалар

Биз сынаган ар бир практика үчүн маанилүү жыйынтыктар жөнүндө айтып берем. Балким, дагы бир нерсе командаларга жардам берген, бирок биз DevOps жөнүндө сөз болуп жатат. Жана DevOps ичинде биз ар кандай профилдеги командалардын ортосундагы айырманы көрөбүз.

Кызмат катары платформа

Биз платформа курагы менен команда профилинин ортосунда олуттуу байланышты тапкан жокпуз: платформалар төмөн жана жогорку командалар үчүн бир эле убакта пайда болгон. Бирок акыркысы үчүн платформа орто эсеп менен программалык код аркылуу башкаруу үчүн көбүрөөк кызматтарды жана программалоо интерфейстерин камсыз кылат. Ал эми платформа командалары өздөрүнүн иштеп чыгуучуларына жана командаларына платформаны колдонууга, көйгөйлөрүн жана платформага байланыштуу инциденттерди тез-тез чечүүгө жана башка командаларды үйрөтүүгө жардам беришет.

Код катары инфраструктура

Бул жерде баары абдан стандарттуу. Биз инфраструктуралык коддун ишин автоматташтыруу менен инфраструктуралык репозиторийдин ичинде канча маалымат сакталаарынын ортосундагы байланышты таптык. Жогорку профиль буйруктары репозиторийлерде көбүрөөк маалыматты сактайт: бул инфраструктуранын конфигурациясы, CI/CD конфигурациясы, айлана-чөйрөнүн жөндөөлөрү жана куруу параметрлери. Алар бул маалыматты бат-баттан сактап, инфраструктуралык код менен жакшыраак иштешет жана инфраструктуралык код менен иштөө үчүн көбүрөөк процесстерди жана тапшырмаларды автоматташтырат.

Кызыгы, биз инфраструктуралык сыноолордо олуттуу айырманы көргөн жокпуз. Мен муну Жогорку профилдеги командаларда жалпысынан тесттик автоматташтыруу көбүрөөк болгондугу менен байланыштырам. Балким, алар инфраструктуралык тесттер менен өзүнчө алаксыбаш керек, тескерисинче, алар тиркемелерди текшерген тесттер жана алардын аркасы менен алар эмнени жана кайда сынганын көрүшөт.

Интеграция жана жеткирүү

Эң кызыксыз бөлүм, анткени биз сизде автоматташтыруу канчалык көп болсо, код менен ошончолук жакшы иштесеңиз, ошончолук жакшы натыйжаларга ээ болоорун тастыктадык.

архитектура

Биз микросервистердин майнаптуулукка кандай таасир тийгизерин көргүбүз келди. Чынында, алар жок, анткени микросервистерди колдонуу натыйжалуулук көрсөткүчтөрүнүн өсүшү менен байланышпайт. Микросервистер Жогорку профиль буйруктары жана Төмөн профиль буйруктары үчүн колдонулат.

Бирок эң маанилүүсү, Жогорку командалар үчүн микросервис архитектурасына өтүү аларга өз кызматтарын өз алдынча өнүктүрүүгө жана жайылтууга мүмкүндүк берет. Эгерде архитектура иштеп чыгуучуларга командадан сырттан келген кимдир-бирөөнү күтпөстөн, өз алдынча иштөөгө мүмкүндүк берсе, анда бул ылдамдыкты жогорулатуу үчүн негизги компетенттүүлүк болуп саналат. Бул учурда, микросервис жардам берет. Жана жөн гана аларды ишке ашыруу чоң роль ойнобойт.

Мунун баарын кантип ачтык?

Бизде DORA методологиясын толугу менен кайталоо боюнча амбициялуу планыбыз бар болчу, бирок ресурстар жетишсиз болчу. ДОРА демөөрчүлүктү көп колдонсо жана алардын изилдөөлөрү жарым жылды талап кылса, биз изилдөөбүздү кыска убакыттын ичинде жүргүздүк. Биз DORA сыяктуу DevOps моделин кургубуз келди жана аны келечекте жасайбыз. Азырынча биз жылуулук карталары менен чектелдик:

Биз инженердик практиканы ар бир профилдеги командалар боюнча бөлүштүрүүнү карап чыктык жана жогорку профилдеги командалар орточо эсеп менен инженердик практиканы көбүрөөк колдоноорун таптык. Мунун баары тууралуу кененирээк биздин баракчадан окуй аласыз билдирүү.

Өзгөртүү үчүн, келгиле, татаал статистикадан жөнөкөй статистикага өтөлү.

Биз дагы эмнени таптык?

аспаптар

Биз буйруктардын көбү Linux үй-бүлөсүнүн OS тарабынан колдонулаарын байкап жатабыз. Бирок Windows дагы деле трендде - респонденттердин жок дегенде төрттөн бири анын тигил же бул версиясын колдонууну белгилешти. Базарда ушундай муктаждык бар окшойт. Ошондуктан, сиз бул компетенцияларды өркүндөтүп, конференцияларда баяндама жасай аласыз.

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

Amazon учурда булут хостинг провайдери болуп саналат. Орус булуттарынын үлүшү акырындап көбөйүүдө. Келерки жылы орус булут провайдерлери кандай сезимде болорун, алардын рыноктук үлүшү көбөйөбү же жокпу, көрүү кызыктуу болот. Алар, алар колдонсо болот, жана бул жакшы:

Мен сөздү Игорьго берем, ал дагы статистикалык маалыматтарды берет.

тажрыйбаларды жайылтуу

Игорь Курочкин: Биз респонденттерден өз-өзүнчө каралып жаткан инженердик тажрыйбалар компанияда кандай бөлүштүрүлгөнүн көрсөтүүнү суранганбыз. Көпчүлүк компанияларда ар кандай үлгүлөрдөн турган аралаш мамиле бар жана пилоттук долбоорлор абдан популярдуу. Биз профилдердин ортосунда бир аз айырмачылыкты да көрдүк. Жогорку профилдин өкүлдөрү адистердин чакан топтору иш процесстерин, инструменттерин өзгөртүп, ийгиликтүү тажрыйбаларды башка командалар менен бөлүшүп турганда “Төмөндөн келген демилге” үлгүсүн көбүрөөк колдонушат. Ортодо, бул жамааттарды жана тажрыйба борборлорун түзүү аркылуу бүт компанияга таасир этүүчү жогорудан ылдый карай демилге:

Agile жана DevOps

Agile жана DevOps ортосундагы байланыш маселеси тармакта көп талкууланат. Бул маселе 2019/2020-жылдарга карата абалдын Agile отчетунда да көтөрүлгөн, ошондуктан биз Agile жана DevOps иш-аракеттеринин компанияларда кандай байланышы бар экенин салыштырууну чечтик. Agileсиз DevOps сейрек кездешээрин таптык. Респонденттердин жарымы үчүн Agileдин жайылуусу алда канча эрте башталган жана 20%га жакыны бир эле убакта башталышын байкашкан жана Төмөнкү профилдин белгилеринин бири Agile жана DevOps практикаларынын жоктугу болот:

Буйрук топологиялары

Өткөн жылдын аягында китепКоманда топологиялары”, командалык топологияларды сүрөттөө үчүн негизди сунуштайт. Бизге анын орусиялык компанияларга колдонулушу кызык болду. Анан биз суроо бердик: "Сиз кандай үлгүлөрдү табасыз?".

Респонденттердин жарымында инфраструктуралык топтор, ошондой эле иштеп чыгуу, тестирлөө жана иштетүү боюнча өзүнчө топтор байкалат. Өзүнчө DevOps командалары 45% белгилешти, алардын арасында High өкүлдөрү көбүрөөк кездешет. Андан кийин кайчылаш-функционалдык командалар келет, алар да Жогоркуда кеңири таралган. Өзүнчө SRE буйруктары Жогорку, Орто профилдерде пайда болот жана Төмөн профилде сейрек кездешет:

DevQaOps катышы

Биз бул суроону Фейсбуктан Skyeng платформасынын командасынын лидеринен көрдүк - ал компаниялардагы иштеп чыгуучулардын, тестирлөөчүлөрдүн жана администраторлордун катышына кызыкты. Биз аны сурадык жана профилдердин негизинде жоопторду карадык: Жогорку профилдеги өкүлдөрдүн ар бир иштеп чыгуучу үчүн сыноо жана операциялык инженерлери азыраак:

2021-жылга пландар

Келерки жылдын пландарында респонденттер төмөнкүдөй иш-чараларды белгилешти:

Бул жерден DevOps Live 2020 конференциясынын кесилишин көрө аласыз. Биз программаны кылдат карап чыктык:

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

Бирок биздин презентациянын убактысы бардык темаларды камтууга жетпейт. Сахна артында калган:

• Платформа кызмат жана продукт катары;
• Код, чөйрө жана булут катары инфраструктура;
• Үзгүлтүксүз интеграция жана жеткирүү;
• Архитектура;
• DevSecOps үлгүлөрү;
• Платформа жана кайчылаш-функционалдык командалар.

билдирүү Биз көлөмдүү, 50 бет алдык, аны кененирээк көрө аласыз.

кошуу жолу менен

Биздин изилдөөбүз жана баяндамабыз сизди иштеп чыгууга, тестирлөөгө жана операцияларга жаңы ыкмалар менен эксперимент кылууга шыктандырат, ошондой эле навигациялоого, өзүңүздү изилдөөнүн башка катышуучулары менен салыштырууга жана өзүңүздүн ыкмаларыңызды жакшырта ала турган аймактарды аныктоого жардам берет деп үмүттөнөбүз.

Россиядагы DevOps абалын биринчи изилдөөнүн жыйынтыгы:

• Негизги көрсөткүчтөр. Биз негизги көрсөткүчтөр (жеткирүү убактысы, жайылтуу жыштыгы, калыбына келтирүү убактысы жана каталарды өзгөртүү) иштеп чыгуунун, тестирлөөнүн жана операциялык процесстердин натыйжалуулугун талдоо үчүн ылайыктуу экенин таптык.
• Профильдер Жогорку, Орто, Төмөн. Чогултулган маалыматтардын негизинде биз көрсөткүчтөр, практикалар, процесстер жана инструменттер боюнча айырмалоочу өзгөчөлүктөргө ээ болгон Жогорку, Орто, Төмөн статистикалык жактан ар кандай топторду ажырата алабыз. Жогорку профилдин өкүлдөрү Төмөнгө караганда жакшы жыйынтыктарды көрсөтүшөт. Алар өздөрүнүн максаттарына жетүү жана ашыра аткаруу ыктымалдыгы жогору.
• Индикаторлор, пандемия жана 2021-жылга пландар. Бул жылдын өзгөчө көрсөткүчү - бул компаниялардын пандемия менен күрөшүүсү. Жогорку өкүлдөр жакшыраак иш алып барышты, колдонуучулардын активдүүлүгүн жогорулатты жана ийгиликтин негизги себептери натыйжалуу өнүгүү процесстери жана күчтүү инженердик маданият болду.
• DevOps тажрыйбалары, куралдары жана аларды иштеп чыгуу. Компаниялардын келерки жылга негизги пландарына DevOps тажрыйбаларын жана инструменттерин өнүктүрүү, DevSecOps тажрыйбаларын киргизүү жана уюштуруу структурасын өзгөртүү кирет. Ал эми DevOps тажрыйбаларын натыйжалуу ишке ашыруу жана өнүктүрүү пилоттук долбоорлордун, жамааттарды жана тажрыйба борборлорун түзүүнүн, компаниянын жогорку жана төмөнкү деңгээлдериндеги демилгелердин жардамы менен ишке ашырылат.

Биз сиздин пикириңизди, окуяларыңызды, пикириңизди уккубуз келет. Изилдөөгө катышкандардын баарына ыраазычылык билдиребиз жана кийинки жылы катышууңуздарды чыдамсыздык менен күтөбүз.

Source: www.habr.com