Як увогуле зразумець стан чагосьці?
Можна спадзявацца на сваё меркаванне, сфармаванае з розных крыніц інфармацыі, напрыклад, публікацый на сайтах ці досведу. Можна спытаць у калег, знаёмых. Яшчэ варыянт - паглядзець на тэмы канферэнцый: праграмны камітэт - гэта актыўныя прадстаўнікі індустрыі, таму мы ім давяраем у выбары актуальных тэм. Асобны напрамак - гэта даследаванні і справаздачы. Але ёсць праблема. Даследаванні стану DevOps штогод праводзяцца ў свеце, справаздачы публікуюцца замежнымі кампаніямі і аб расійскім DevOps інфармацыі тамака амаль няма.
Але надышоў той дзень, калі такое даследаванне правялі, і мы сёння раскажам пра атрыманыя вынікі. Стан DevOps у Расіі даследавалі сумесна кампаніі «»І«». Кампанія «Экспрэс 42» дапамагае тэхналагічным кампаніям укараняць і развіваць DevOps практыкі і прылады і адна з першых пачала расказваць пра DevOps у Расіі. Аўтары даследавання – Ігар Курочкін і Віталь Хабараў займаюцца ў кампаніі «Экспрэс 42» аналізам і кансалтынгам, маючы пры гэтым тэхнічны бэкграўнд з эксплуатацыі і досвед працы ў розных кампаніях. За 8 гадоў калегі паглядзелі дзясяткі кампаній і праектаў - ад стартапа да энтэрпрайзу - з рознымі праблемамі, а таксама рознай культурнай і інжынернай сталасцю.
У сваім дакладзе Ігар і Віталь распавялі, якія праблемы былі ў працэсе даследавання, як яны іх вырашылі, а таксама пра тое, як у прынцыпе праводзяцца даследаванні DevOps і чаму "Экспрэс 42" вырашылі правесці сваё. Іх справаздачу можна паглядзець .
Даследаванні DevOps
Размову пачаў Ігар Курачкін.
Мы рэгулярна задаём пытанне аўдыторыі на DevOps канферэнцыях: "Ці чыталі вы справаздачу стану DevOps за гэты год?" Паднімаюць рукі адзінкі, а наша даследаванне паказала, што толькі трэць вывучаюць іх. Калі вы ніколі не бачылі такія справаздачы, скажам адразу, што ўсе яны вельмі падобныя. Часцей за ўсё там сустракаюцца фразы кшталту: «У параўнанні з мінулым годам…»
Тут у нас узнікла першая праблема, а за ёй яшчэ дзве:
- У нас няма звестак за мінулы год. Стан DevOps у Расіі нікому не цікава;
- Метадалогія. Незразумела, як правяраць гіпотэзы, як будаваць пытанні, як праводзіць аналіз, параўноўваць вынікі, знаходзіць сувязі;
- Тэрміналогія. Усе справаздачы на англійскай мове, патрабуецца пераклад, агульнага фрэймворка па DevOps яшчэ не вынайшлі і кожны прыдумляе сваё.
Давайце паглядзім, як увогуле праводзіліся аналізы станаў DevOps у свеце.
Гістарычная даведка
Даследаванні DevOps праводзяцца з 2011 года. Першай іх правяла кампанія Puppet – распрацоўшчык сістэм кіравання канфігурацыяй. На той момант гэта быў адзін з асноўных інструментаў для апісання інфраструктуры ў выглядзе кода. Да 2013 года гэтыя даследаванні былі проста ў выглядзе апытанняў у закрытым фармаце і без публічных справаздач.
У 2013 годзе з'явілася кампанія IT Revolution, выдавец усіх асноўных кніг па 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 не праводзілася. Мы выступалі на канферэнцыях, пераказваючы чужыя высновы і Райффайзенбанк перавёў «State of DevOps» за 2019 год (вы можаце знайсці іх анонс на Хабры), вялікі ім дзякуй. І гэта ўсё.
Таму мы правялі ўласнае даследаванне ў Расіі, выкарыстоўваючы метадалогіі і высновы DORA. Мы выкарыстоўвалі справаздачу калегаў з Райффайзенбанка для свайго даследавання, у тым ліку і для сінхранізацыі тэрміналогіі і перакладу. А актуальныя для індустрыі пытанні ўзялі са справаздач DORA і апытальніка Puppet гэтага года.
Працэс даследавання
Справаздача - гэта толькі фінальная частка. Увесь працэс даследавання складаецца з чатырох вялікіх этапаў:
На этапе падрыхтоўкі мы апыталі экспэртаў з індустрыі і падрыхтавалі спіс гіпотэз. На іх аснове склалі пытанні і запусцілі апытанне на ўвесь жнівень. Потым мы прааналізавалі і падрыхтавалі саму справаздачу. У DORA гэты працэс займае 6 месяцаў. Мы ўклаліся ў 3 месяцы, і зараз разумеем, што часу нам ледзь хапіла: толькі выконваючы аналіз ты разумееш, якія пытанні трэба задаваць.
Удзельнікі
Усе замежныя справаздачы пачынаюцца з партрэта ўдзельнікаў, і большасць з іх - не з Расіі. Працэнт расійскіх рэспандэнтаў плавае ад 5 да 1% з году ў год, і гэта не дазваляе зрабіць якія-небудзь высновы.
Карта са справаздачы Accelerate State of DevOps 2019:
У нашым даследаванні ў нас атрымалася апытаць 889 чалавек – гэта дастаткова шмат (DORA у сваіх справаздачах штогод апытвае каля тысячы чалавек) і тут мы дасягнулі мэты:
Праўда, не ўсе нашы ўдзельнікі дайшлі да канца: працэнт запаўнення атрымаўся крыху менш за палову. Але і гэтага хапіла для атрымання рэпрэзентатыўнай выбаркі і правядзенні аналізу. DORA у сваіх справаздачах не раскрывае працэнта запаўнення, таму тут параўнаць не атрымаецца.
Галіны і пасады
Нашы рэспандэнты прадстаўляюць дзясятак галін. Палова працуе ў сферы інфармацыйных тэхналогій. Далей ідуць фінансавыя паслугі, гандаль, тэлекамунікацыі і іншыя. Сярод пасад гэта спецыялісты (распрацоўшчык, тэсціроўшчык, інжынер эксплуатацыі) і кіраўнік склад (кіраўнікі каманд, груп, напрамкаў, дырэктары):
Кожны другі працуе ў кампаніі сярэдняга памеру. У буйных кампаніях працуе кожны трэці. Большасць працуюць у камандах да 9 чалавек. Асобна мы пыталіся пра асноўныя актыўнасці, і большасць так ці інакш злучана з эксплуатацыяй, а распрацоўкай займаецца каля 40%:
Так мы сабралі інфармацыю для параўнання і аналізу прадстаўнікоў розных галін, кампаній, каманд. Пра аналіз раскажа мой калега Віталь Хабараў.
Аналіз і параўнанне
Віталь Хабараў: Вялікі дзякуй усім удзельнікам, якія прайшлі нашае апытанне, запоўнілі анкеты і далі нам дадзеныя для далейшага аналізу і праверкі нашых гіпотэз. А дзякуючы нашым кліентам і заказчыкам у нас ёсць багаты вопыт, які дапамог вызначыць хвалюючыя індустрыю пытанні і сфармуляваць гіпотэзы, якія мы праверылі ў нашым даследаванні.
На жаль, нельга проста ўзяць спіс пытанняў з аднаго боку і дадзеныя - з другога, неяк іх супаставіць, сказаць: "Так, усё так і працуе, мы мелі рацыю" і разысціся. Не, патрэбна метадалогія і статыстычныя метады, каб быць упэўненым, што мы не памыліліся і нашыя высновы дакладныя. Тады мы можам на аснове гэтых дадзеных будаваць нашу далейшую працу:
Ключавыя метрыкі
За аснову мы ўзялі метадалогію DORA, якую яны падрабязна апісалі ў кнізе "Accelerate State of DevOps". Мы праверылі, а ці падыходзяць ключавыя метрыкі для расійскага рынка, ці можна іх выкарыстоўваць гэтак жа, як выкарыстоўвае DORA, каб адказаць на пытанне: "Наколькі індустрыя ў Расіі адпавядае замежнай індустрыі?"
Ключавыя метрыкі:
- Частата разгортванняў. Як часта адбываецца разгортванне новай версіі прыкладання на прадуктовае асяроддзе (планавых змен, выключаючы хотфіксы і рэакцыю на інцыдэнты)?
- Тэрмін пастаўкі. Колькі ў сярэднім часе праходзіць паміж коммітам змены (напісаннем функцыянальнасці ў выглядзе кода) і разгортваннем змены на прадуктовым асяроддзі?
- Час аднаўлення. Колькі ў сярэднім часе займае аднаўленне прыкладання на прадуктовым асяроддзі пасля інцыдэнту, дэградацыі сэрвісу або выяўлення памылкі, якая ўплывае на карыстальнікаў прыкладання?
- Няўдалыя змены. Які працэнт разгортванняў на прадуктовым асяроддзі прыводзіць да дэградацыі прыкладання або інцыдэнтам і патрабуе ўхілення наступстваў (адкат змен, распрацоўку хотфікса або патча)?
DORA у сваіх даследаваннях знайшла сувязь паміж гэтымі метрыкамі і арганізацыйнай эфектыўнасцю. Мы яе таксама правяраем у нашым даследаванні.
Але каб пераканацца, што чатыры ключавыя метрыкі могуць на нешта ўплываць, трэба зразумець - а паміж сабой яны неяк звязаныя? DORA адказала сцвярджальна з адной агаворкай: сувязь паміж няўдалымі зменамі (Change Failure Rate) і трыма іншымі метрыкамі крыху слабей. У нас атрымалася прыкладна такая ж карціна. Калі тэрмін пастаўкі, частата разгортвання і час аднаўлення паміж сабой карэлююць (мы ўсталявалі гэтую карэляцыю праз карэляцыю Пірсана і праз шкалу Чеддока), то з няўдалымі зменамі такой моцнай карэляцыі няма.
У прынцыпе, большая частка рэспандэнтаў схільная адказваць, што ў іх даволі-такі малая колькасць інцыдэнтаў адбываецца на прадакшэне. Хоць у далейшым мы ўбачым, што паміж групамі рэспандэнтаў усё роўна ёсць значная розніца па паказчыку няўдалых змен, для гэтага падзелу мы пакуль не можам выкарыстоўваць гэтую метрыку.
Мы гэта злучаем з тым, што (як высвятлілася падчас аналізаў і зносін з некаторымі нашымі замоўцамі) ёсць невялікая розніца ва ўспрыманні, што лічыць інцыдэнтам. Калі мы паспелі аднавіць працаздольнасць нашага сэрвісу падчас тэхнічнага акна - ці можна лічыць гэта інцыдэнтам? Мусіць, не, таму што мы ўсё выправілі, мы - малайцы. Ці можна лічыць інцыдэнтам, калі нам прыйшлося ў нармальным, звыклым для нас рэжыме 10 разоў перавыкаціць наша дадатак? Здаецца, не. Таму пытанне ўзаемасувязі няўдалых змен з іншымі метрыкамі застаецца адкрытым. Мы будзем удакладняць яго надалей.
Тут важна, што мы знайшлі значную карэляцыю паміж тэрмінамі пастаўкі, часам аднаўлення і частатой разгортвання. Таму гэтыя тры метрыкі мы ўзялі для далейшага падзел рэспандэнтаў на групы па прадукцыйнасці.
Колькі вешаць у грамах?
Мы выкарыстоўвалі іерархічны кластарны аналіз:
- Размяркоўваем рэспандэнтаў па n-мернай прасторы, дзе каардыната кожнага рэспандэнта - іх адказы на пытанні.
- Кожнага рэспандэнта аб'яўляем маленькім кластарам.
- Аб'ядноўваем два найболей набліжаных сябар да сябра кластара ў адзін кластар пабольш.
- Знаходзім наступную пару кластараў і аб'ядноўваем іх у кластар пабольш.
Так мы групуем усіх нашых рэспандэнтаў у патрэбную нам колькасць кластараў. З дапамогай дэндраграмы (дрэва сувязяў паміж кластарамі) мы бачым адлегласць паміж двума суседнімі кластарамі. Усё, што нам застаецца - усталяваць нейкі ліміт адлегласці паміж гэтымі кластарамі і сказаць: «Гэтыя дзве групы паміж сабой досыць адрозныя таму, што адлегласць паміж імі гіганцкая».
Але тут ёсць прыхаваная праблема: у нас няма абмежаванняў на колькасць кластараў - можам атрымаць 2, 3, 4, 10 кластараў. І першай ідэяй было - чаму б не дзяліць усіх нашых рэспандэнтаў на 4 групы, як гэта робіць DORA. Але высветлілі, што адрозненні паміж гэтымі групамі становяцца нязначнымі, і мы не можам быць упэўнены, што рэспандэнт сапраўды належыць сваёй групе, а не суседняй. Расейскі рынак мы пакуль не можам падзяліць на чатыры групы. Таму мы спыніліся менавіта на трох профілях, паміж якімі ёсць статыстычна значнае адрозненне:
Далей мы па кластарах вызначылі профіль: мы ўзялі медыяны для кожнай метрыкі па кожнай групе і склалі таблічку профіляў эфектыўнасці. Фактычна атрымаліся профілі эфектыўнасці сярэдняга ўдзельніка кожнай групы. Мы вылучылі тры профіля эфектыўнасці: Low, Medium, High:
Тут мы пацвердзілі нашу гіпотэзу аб тым, што 4 ключавыя метрыкі падыходзяць для вызначэння профіля эфектыўнасці, і яны працуюць як на заходнім, так і на расійскім рынку. Розніца паміж гуртамі ёсць, і яна статыстычна значная. Падкрэслю, што паміж профілямі эфектыўнасці па метрыцы няўдалых змен ёсць значная розніца па сярэднім, нават нягледзячы на тое, што мы першапачаткова не дзялілі рэспандэнтаў па гэтым параметры.
Далей узнікае пытанне: як усім гэтым карыстацца?
як карыстацца
Калі ўзяць любую каманду, 4 ключавыя метрыкі і прымяніць да табліцы, то ў 85% выпадкаў мы не атрымаем поўнага супадзення - гэта ўсяго толькі сярэдні ўдзельнік, а не тое, што ёсць у рэальнасці. Мы ўсе (і кожная каманда) крыху адрозніваемся.
Мы праверылі: узялі нашых рэспандэнтаў і профіль эфектыўнасці DORA, і паглядзелі, колькі рэспандэнтаў адпавядаюць таму ці іншаму профілі. Мы атрымалі, што ўсяго толькі 16% рэспандэнтаў сапраўды патрапілі ў адзін з профіляў. Усе астатнія раскіданыя недзе пасярэдзіне паміж імі:
Гэта значыць, што ў профіля эфектыўнасці ёсць абмежаваная вобласць ужывання. Для разумення, дзе вы знаходзіцеся ў першым набліжэнні, можна выкарыстоўваць гэтую табліцу: "О, здаецца, мы бліжэй да Medium або High!" Калі вы разумееце, куды вам рухацца далей, гэтага можа хапіць. Але калі ваша мэта - пастаяннае, бесперапыннае паляпшэнне, і вы хочаце больш дакладна ведаць, куды развівацца і што рабіць, то патрэбны дадатковыя сродкі. Мы іх назвалі калькулятары:
- Калькулятар DORA
- Калькулятар Экспрэс 42* (у распрацоўцы)
- Свая распрацоўка (можна скласці свой унутраны калькулятар).
Навошта яны патрэбны? Каб зразумець:
- Каманда ўнутры нашай арганізацыі адпавядае нашым стандартам?
- Калі не, то ці можам мы ёй дапамагчы - паскорыць яе ў рамках той экспертызы, якая ёсць у нашай кампаніі?
- Калі так, дык ці можам зрабіць яшчэ лепш?
Яшчэ вы з іх дапамогай можаце сабраць статыстыку ўсярэдзіне кампаній:
- Якія ў нас каманды ёсць;
- Падзяліць каманды на профілі;
- Убачыць: О, гэтыя каманды ў нас underperforming (крыху не выцягваюць), а гэтыя — класныя: яны дэплояць кожны дзень, без памылак, lead time у іх менш за гадзіну.
І тады вы можаце высветліць, што ўсярэдзіне нашай кампаніі ёсць неабходныя экспертыза і прылады для тых каманд, якія пакуль яшчэ не дацягваюць.
Ці, калі вы разумееце, што ўнутры кампаніі вы адчуваеце сябе выдатна, вы лепш за многіх, - то можна зірнуць крыху шырэй. Гэта якраз расейская індустрыя: ці можам мы атрымаць неабходную экспертызу ў расійскай індустрыі, каб паскорыцца самім? Тут дапаможа калькулятар Экспрэс 42 (ён у працэсе распрацоўкі). Калі вы перараслі расейскі рынак, то глядзіце на і на сусветны рынак.
Добра. А калі вы знаходзіцеся ў гурце Elit па калькулятары DORA, то што рабіць? Добрага рашэння тут няма. Хутчэй за ўсё вы знаходзіцеся на перадавой індустрыі, і далейшае паскарэнне і павышэнне надзейнасці магчымыя за кошт унутранага R&D і марнаванняў вялікіх рэсурсаў.
Пяройдзем да самага салодкага - параўнанні.
параўнанне
Мы першапачаткова хацелі параўнаць расейскую індустрыю з заходняй індустрыяй. Калі параўноўваць наўпрост, то бачым, што ў нас менш профіляў, і яны крыху больш перамяшаныя паміж сабой, межы крыху больш за размытыя:
Нашы Elite-перформеры схаваныя сярод High-перформераў, але яны ёсць - гэта эліта, аднарогі, якія дасягнулі значных вышынь. У Расіі розніца паміж профілем Elite і профілем High пакуль недастаткова значная. Мы думаем, што ў будучыні гэты падзел адбудзецца ў сувязі з павышэннем інжынернай культуры, якасці ўкаранення інжынерных практык і экспертызы ўнутры кампаній.
Калі пераходзіць да прамога параўнання ўсярэдзіне расійскай індустрыі, то мы бачым, што каманды профіля High лепш па ўсіх паказчыках. Таксама мы пацвердзілі нашу гіпотэзу аб тым, што ёсць сувязь паміж гэтымі метрыкамі і арганізацыйнай эфектыўнасцю: каманды профіля High значна часцей не толькі дасягаюць мэт, але і пераўзыходзяць іх.
Давайце станавіцца камандамі профіля High і не спыняцца на дасягнутым:
Але гэты год асаблівы, і мы вырашылі яшчэ праверыць, як кампаніі жывуць ва ўмовах пандэміі: каманды профіля High значна лепш спраўляюцца і адчуваюць сябе лепш, чым у сярэднім па індустрыі:
- У 1,5-2 разы часцей выпускалі новыя прадукты,
- У 2 разы часцей падвышалі надзейнасць і / або прадукцыйнасць інфраструктуры прыкладанняў.
Гэта значыць тыя кампетэнцыі, якія ў іх ужо былі, дапамаглі ім развівацца хутчэй, выводзіць новыя прадукты, мадыфікаваць ужо існуючыя прадукты, тым самым заваёўваючы новыя рынкі і новых карыстальнікаў:
Што яшчэ дапамагло нашым камандам?
Інжынерныя практыкі
Раскажу пра значныя знаходкі па кожнай практыцы, якія мы праверылі. Магчыма, нешта яшчэ дапамагло камандам, але мы гаворым пра DevOps. І ў рамках DevOps мы бачым адрозненне сярод каманд розных профіляў.
Платформа як сэрвіс
Мы не знайшлі значнай сувязі паміж узростам платформы і профілем каманды: Платформы з'явіліся прыкладна ў адзін і той жа час і ў Low-каманд, і ў High-каманд. Але ў апошніх платформа дае ў сярэднім больш сэрвісаў і больш праграмных інтэрфейсаў для кіравання праз праграмны код. А платформенныя каманды часцей дапамагаюць сваім распрацоўшчыкам і камандам карыстацца платформай, часцей вырашаюць іх праблемы і інцыдэнты, звязаныя з платформай, і навучаюць іншыя каманды.
Інфраструктура як код
Тут усё даволі стандартна. Мы знайшлі ўзаемасувязь паміж аўтаматызацыяй працы інфраструктурнага кода і тым, колькі інфармацыі захоўваецца ўнутры інфраструктурнага рэпазітара. Каманды профіля High захоўваюць у рэпазітарах больш інфармацыі: гэта і канфігурацыя інфраструктуры, CI/CD пайплайна, налады акружэнняў і параметры зборкі. Яны часцей захоўваюць гэтую інфармацыю, лепш працуюць з інфраструктурным кодам і аўтаматызавалі больш працэсаў і задач па рабоце з інфраструктурным кодам.
Цікава, што мы не ўбачылі значнай розніцы па інфраструктурных тэстах. Я злучаю гэта з тым, што ў каманд профіля High у цэлым больш аўтаматызацыі тэставання. Магчыма, ім не варта адцягвацца асобна на інфраструктурныя тэсты, а дастаткова тых тэстаў, якімі яны правяраюць прыкладанні, і дзякуючы ім ужо бачаць, што і дзе ў іх зламалася.
Інтэграцыя і пастаўка
Самая сумная частка, таму што мы пацвердзілі: чым больш у вас аўтаматызацыі, чым лепш вы працуеце з кодам, тым верагодней атрымліваеце лепшыя паказчыкі.
Архітэктура
Мы хацелі паглядзець, наколькі мікрасэрвісы ўплываюць на прадукцыйнасць. Калі па праўдзе – не ўплываюць, бо прымяненне мікрасэрвісаў не звязана з павышэннем паказчыкаў эфектыўнасці. Мікрасэрвісы прымяняюцца як у каманд профілю High, так і ў каманд профілю Low.
Але значна тое, што для High-каманд пераход на мікрасэрвісную архітэктуру дазваляе ім незалежна распрацоўваць свае сэрвісы і выкочвацца. Калі архітэктура дазваляе распрацоўнікам дзейнічаць аўтаномна, не чакаць кагосьці вонкавага па стаўленні да каманды, тое гэта з'яўляецца ключавой кампетэнцыяй для падвышэння хуткасці. У гэтым выпадку мікрасэрвісы дапамагаюць. А проста іх укараненне вялікай ролі не гуляе.
Як мы ўсё гэта выявілі?
У нас быў амбіцыйны план поўнасцю прайграць метадалогію DORA, але не хапіла рэсурсаў. Калі DORA выкарыстоўвае вялікую спонсарскую падтрымку і даследаванне ў іх займае паўгода, сваё даследаванне мы правялі ў сціслыя тэрміны. Мы хацелі пабудаваць мадэль DevOps, як гэта робіць DORA і мы зробім гэта ў будучыні. Пакуль мы абмежаваліся цеплавымі картамі:
Мы паглядзелі, якое размеркаванне інжынерных практык у каманд кожнага профіля, і выявілі, што каманды профіля High у сярэднім гушчару ўжываюць інжынерныя практыкі. Аб усім гэтым можна падрабязней прачытаць у нашым .
Для разнастайнасці пераключымся са складанай статыстыкі на простую.
Што мы знайшлі яшчэ?
Інструменты
Мы назіраем, што больш за ўсё каманд выкарыстоўвае АС сямейства Linux. Але Windows усё яшчэ ў трэндзе - не менш за чвэрць нашых рэспандэнтаў адзначылі выкарыстанне той ці іншай яго версіі. Здаецца, што ў рынку ёсць гэтая патрэба. Таму вы можаце развіваць дадзеныя кампетэнцыі і выступаць з дакладамі на канферэнцыях.
Сярод аркестратараў, ні для каго не сакрэт, лідзіруе Kubernetes (52%). Наступны па чарзе аркестратар - Docker Swarm (каля 12%). Найбольш папулярныя CI-сістэмы – Jenkins і GitLab. Найбольш папулярная сістэма кіравання канфігурацыяй – Ansible, а за ім – наш з вамі каханы Shell.
Сярод хмарных хостынгаў пакуль якое лідыруе становішча займае Amazon. Доля расійскіх аблокаў паступова нарошчваецца. У наступным годзе будзе цікава паглядзець, як расійскія хмарныя правайдэры будуць сябе адчуваць, ці павысіцца іх доля рынку. Яны ёсць, імі можна карыстацца, і гэта добра:
Перадаю слова Ігару, які дасць яшчэ крыху статыстыкі.
Распаўсюджванне практык
Ігар Курачкін: Асобна мы прасілі рэспандэнтаў указаць, як разгледжаныя інжынерныя практыкі распаўсюджваюцца ў кампаніі. У большасці кампаній назіраецца змяшаны падыход, які складаецца з рознага набору патэрнаў, а пілотныя праекты карыстаюцца вялікай папулярнасцю. Таксама мы ўбачылі невялікую розніцу паміж профілямі. Прадстаўнікі профіля High часцей выкарыстоўваюць патэрн "Ініцыятыва знізу", калі невялікія каманды спецыялістаў мяняюць працоўныя працэсы, інструменты, дзеляцца паспяховымі напрацоўкамі з іншымі камандамі. У Medium гэта - ініцыятыва зверху, якая закранае ўсю кампанію стварэннем супольнасцяў і цэнтраў кампетэнцый:
Agile і DevOps
Пытанне аб сувязі Agile і DevOps часта абмяркоўваецца ў індустрыі. Гэтае пытанне паднімаецца і ў справаздачы State of Agile Report за 2019/2020 год, таму мы вырашылі параўнаць як звязаныя Agile і DevOps актыўнасці ў кампаніях. Мы высветлілі, што DevOps без Agile сустракаецца рэдка. У паловы рэспандэнтаў распаўсюджванне Agile пачалося прыкметна раней, а адначасовае пачатак назіралі каля 20%, а адной з прыкмет Low-профіля будзе адсутнасць Agile і DevOps практык:
Камандныя тапалогіі
У канцы мінулага года выйшла кніга «», у якой прапанаваны фрэймворк для апісання камандных тапалогій. Нам стала цікава, а ці дастасуем ён да расійскіх кампаній. І мы задалі пытанне: "Якія патэрны сустракаюцца ў вас?".
Інфраструктурныя каманды назіраюцца ў паловы рэспандэнтаў, таксама, як і асобныя каманды распрацоўкі, тэсціравання і эксплуатацыі. Асобныя DevOps каманды адзначылі 45%, сярод якіх прадстаўнікі High сустракаюцца часцей. Следам ідуць кросфункцыянальныя каманды, якія таксама часцей сустракаюцца ў High. Асобныя каманды SRE з'яўляюцца ў профілях High, Medium і рэдка сустракаюцца ў профіля Low:
Суадносіны DevQaOps
Гэтае пытанне мы ўбачылі ў FaceBook у тымліда платформеннай каманды Skyeng – яго цікавіла суадносіны распрацоўшчыкаў, тэсціроўшчыкаў і адміністратараў у кампаніях. Мы задалі яго і паглядзелі на адказы з улікам профіляў: у прадстаўнікоў профіля High на кожнага распрацоўніка даводзіцца меншая колькасць інжынераў тэставання і эксплуатацыі:
Планы на 2021 год
У планах на наступны год рэспандэнты адзначылі наступныя актыўнасці:
Тут бачна скрыжаванне з канферэнцыяй DevOps Live 2020. Мы ўважліва азнаёміліся з праграмай:
- Інфраструктура як прадукт
- DevOps трансфармацыя
- Распаўсюджванне DevOps практык
- DevSecOps
- Кейс-клубы і дыскусіі
Але часу нашага выступу не хопіць, каб разгледзець усе тэмы. За кадрам засталося:
- Платформа як сэрвіс і як прадукт;
- Інфраструктура як код, асяроддзі і аблокі;
- Бесперапынная інтэграцыя і пастаўка;
- Архітэктура;
- Патэрны DevSecOps;
- Платформенныя і крос-функцыянальныя каманды.
у нас атрымаўся аб'ёмным, на 50 старонак, і вы можаце паглядзець яго больш падрабязна.
Падводзім вынікі
Мы спадзяемся, што наша даследаванне і справаздачу натхняць вас на эксперыменты з выкарыстаннем новых падыходаў да распрацоўкі, тэсціравання і эксплуатацыі, а таксама дапамогуць вам зарыентавацца, параўнаць сябе з іншымі ўдзельнікамі даследавання і вызначыць вобласці, у якіх вы можаце палепшыць уласныя падыходы.
Вынікі першага даследавання стану DevOps у Расіі:
- Ключавыя метрыкі. Мы высветлілі, што ключавыя метрыкі (тэрмін пастаўкі, частата разгортвання, час аднаўлення і няўдалыя змены) падыходзяць для аналізу эфектыўнасці працэсаў распрацоўкі, тэсціравання і эксплуатацыі.
- Профілі High, Medium, Low. На аснове сабраных дадзеных можна вылучыць статыстычна якія адрозніваюцца групы High, Medium, Low з адметнымі прыкметамі па метрыках, практыкам, працэсам і прыладам. Прадстаўнікі профіля High паказваюць лепшыя вынікі, чым Low. У іх больш шанцаў дасягнуць і перавыканаць пастаўленыя мэты.
- Паказчыкі, пандэмія і планы на 2021 год. Адмысловы паказчык у гэтым годзе, як кампаніі справіліся з пандэміяй. Прадстаўнікі High зладзіліся лепш, выпрабавалі рост актыўнасці карыстальнікаў, а асноўнымі прычынамі поспеху сталі эфектыўныя працэсы распрацоўкі і моцная інжынерная культура.
- DevOps практыкі, інструменты і іх развіццё. У асноўныя планы кампаній на наступны год уваходзяць развіццё DevOps практык і інструментаў, укараненне практык DevSecOps, змена арганізацыйнай структуры. А эфектыўнае ўкараненне і развіццё DevOps практык выконваецца з дапамогай пілотных праектаў, фармаваннем супольнасцяў і цэнтраў кампетэнцый, ініцыятыў на верхнім і ніжнім узроўнях кампаніі.
Будзем рады пачуць вашыя водгукі, гісторыі, зваротную сувязь. Дзякуем усім, хто ўдзельнічаў у даследаванні, і спадзяемся на ваш удзел у наступным годзе.
Крыніца: habr.com