Некалькі гадоў таму шматлікія арганізацыі разглядалі DevOps як перспектыўны эксперымент, а не асноўны падыход да распрацоўкі праграмнага забеспячэння. Цяпер DevOps – правераны і магутны набор практык і інструментаў распрацоўкі і разгортвання, які дазваляе паскорыць рэлізы новых прадуктаў і павысіць прадукцыйнасць працы. Што яшчэ больш важна: эфект DevOps накіраваны на агульны рост бізнесу і павелічэнне яго прыбытковасці.
Каманда перавяла самае цікавае з , складзенага экспертамі DevOps Research & Assessment (DORA). У даследаванні ўдзельнічалі 31 спецыялістаў з усяго свету. Паглядзім, што змянілася ў галіны ў 000 годзе і як бізнэс можа павысіць эфектыўнасць дастаўкі праграмнага забеспячэння.
Як на стан DevOps уплываюць галіну і памер кампаніі
У даследаванні не выявілі сувязі паміж эфектыўнасцю DevOps і галіной арганізацыі, за выключэннем рознічнага гандлю, дзе паказчыкі былі крыху лепш. Гэта, у прыватнасці, звязана з тым, што рытэйлерам трэба аператыўна рэагаваць на ваганні попыту і патрэбнасці пакупнікоў. Па дадзеных даследаванні, высокага ўзроўню ў DevOps можа дасягнуць любая кампанія, у тым ліку фінансавы сектар і дзяржсектар.
Паказчыкі эфектыўнасці DevOps у кампаніях, дзе больш за 5000 супрацоўнікаў, былі ніжэй, чым у кампаніях, дзе менш за 5000 супрацоўнікаў. Хутчэй за ўсё, гэта звязана з тым, што ў буйных арганізацыях больш маштабныя працэсы, стражэй кантроль, складаней архітэктура IT-сістэм, што ўносіць затрымкі ў працэс распрацоўкі і выкаткі кода. Пры гэтым эксперты лічаць, што маштаб кампаніі не перашкаджае поспеху ў пабудове DevOps, проста ў некаторых выпадках гэта можа запатрабаваць больш намаганняў.
Як ацаніць узровень DevOps у кампаніі
Эксперты параўноўвалі працэсы DevOps з эталоннай ацэнкай, падзяліўшы ўдзельнікаў апытання на чатыры групы з лепшымі, добрымі, сярэднімі і нізкімі паказчыкамі.
Для справаздачы ўзялі чатыры ключавыя метрыкі ацэнкі эфектыўнасці DevOps: час выканання змен пры распрацоўцы ПЗ, частата разгортвання, частата правалаў і час аднаўлення.
Чатыры ўзроўні DevOps – ацаніце, на якім знаходзіцца ваша кампанія:
Метрыка ацэнкі эфектыўнасці дастаўкі ПЗ для асноўных сэрвісаў і дадаткаў кампаніі
Каманды з найлепшымі паказчыкамі
Каманды з добрымі паказчыкамі
Каманды з сярэднімі паказчыкамі
Каманды з нізкімі паказчыкамі
Частата разгортвання
Як часта кампанія разгортвае код у вытворчасць ці выпускае яго для канчатковых карыстачоў.
Па запыце, некалькі разгортванняў у дзень
Ад аднаго разу ў дзень да аднаго разу ў тыдзень
Ад аднаго разу ў тыдзень да аднаго разу ў месяц
Адзін раз у месяц/некалькі месяцаў
Час выканання змен
Колькі часу займае пераход ад тэста да ПЗ, паспяхова працуе ў вытворчасці.
Менш чым за дзень
Ад аднаго дня да тыдня
Ад аднаго тыдня да месяца
Ад месяца да шасці месяцаў
Час аднаўлення сэрвісу
Колькі часу ідзе на аднаўленне сэрвісу пасля інцыдэнту ці бага, які ўплывае на карыстальнікаў.
Менш за гадзіну
На працягу дня
На працягу тыдня
Ад тыдня да месяца
Частата правалаў пры зменах
Які працэнт абнаўленняў або новых рэлізаў прыводзяць да пагаршэння абслугоўвання і патрабуюць выпраўленняў.
0-15%
0-15%
0-15%
46-60%
Даследаванне выявіла наступную тэндэнцыю: колькасць каманд з высокім узроўнем паказчыкаў амаль патроілася, павялічыўшыся з 7 працэнтаў ад усіх рэспандэнтаў у 2018 годзе да 20 працэнтаў у 2019 годзе.
Размеркаванне груп распрацоўшчыкаў па ўзроўнях прадукцыйнасці.
У параўнанні з камандамі ў групе з нізкай эфектыўнасцю, каманды DevOps з высокімі паказчыкамі:
- Выканалі ў 208 разоў больш разгортванняў кода.
- У 106 разоў менш часу марнавалі на разгортванне кода.
- У 7 разоў радзей сутыкаліся з праваламі.
- У 2,604 разы хутчэй аднаўлялі працу ПЗ пасля збояў.
Акрамя таго, у каманд DevOps з высокімі паказчыкамі ў два разы больш шанцаў дасягнуць ці перасягнуць свае арганізацыйныя паказчыкі эфектыўнасці, чым у каманд з нізкімі паказчыкамі.
Многія спецыялісты думаюць, што нельга дасягнуць павелічэння ўсіх паказчыкаў адначасова, трэба ісці на кампраміс. Так, некаторыя лічаць, што павелічэнне хуткасці выкаткі рэлізаў можа негатыўна паўплываць на надзейнасць працэсу дастаўкі ПА і аказанні паслуг. Аднак даследаванні паказалі, што хуткасць і стабільнасць вынікаў не выключаюць адно аднаго.
У росце колькасці DevOps-каманд я не бачу нічога дзіўна, ён заканамерны: філасофія DevOps зараз папулярная, а колькасць стартапаў расце.
Але, на мой погляд, эксперты абралі не зусім карэктныя параметры адзнакі эфектыўнасці DevOps.
Ацэньваць яе па хуткасці выкаткі кода, сама меней, дзіўна. Гэта дастасавальна толькі да стартапам, дзе ключавым параметрам будзе хуткасць высновы прадукта на рынак, пры гэтым часта прадукт выводзіцца ў волкім выглядзе. У такіх умовах механізмы, якія паскараюць распрацоўку і дастаўку ў прадакшэн, з'яўляюцца жыццёва неабходнымі. А вось для ўстоянага ПЗ, напрыклад фінансавага ці медыцынскага, параметру частаты правалаў можа не існаваць - правалы могуць быць недапушчальныя.
Аналагічна з часам узнаўленні сэрвісу: для любога развітога сэрвісу яно павінна вылічацца секундамі, а для шматлікіх сэрвісаў просты недапушчальны, для гэтага прыдумалі тэхналогіі бясшвоўнай выкаткі (напрыклад green/blue).
Таксама не варта арыентавацца на колькасць разгортванняў кода - яно залежыць ад неабходнасці і кампетэнцый каманды распрацоўкі. Калі разгортванне злучана з даданнем новага функцыяналу - гэта адно, а калі з выпраўленнем памылак, дапушчаных пры папярэдніх разгортваннях - зусім іншае.
Дзяніс Раманенка, пазаштатны эксперт Mail.ru Cloud Solutions
Як палепшыць працэсы DevOps
У справаздачы прадстаўлены два напрамкі, якія дапамогуць палепшыць DevOps: павышэнне эфектыўнасці распрацоўкі і дастаўкі ПЗ і паляпшэнне прадукцыйнасці працы.
У кожны з напрамкаў уваходзяць свае кампаненты, палепшыўшы якія, можна дасягнуць патрэбнай мэты.
Па дадзеных справаздачы, ключ да лічбавай трансфармацыі - карпаратыўная культура. Высокаэфектыўным камандам DevOps патрэбная культура даверу і псіхалагічная бяспека, разуменне вынікаў працы і выразныя мэты. Такое асяроддзе дазваляе членам каманд прымаць узважаныя рашэнні, выказваць сваё меркаванне і быць больш творчымі.
Палепшыць эфектыўнасць распрацоўкі і дастаўкі ПЗ таксама дапамогуць хмарныя тэхналогіі, бесперапынная дастаўка, тэсціраванне аварыйнага аднаўлення, кіраванне зменамі. Прадукцыйнасць працы можна павысіць, укладваючы сродкі ў простыя ў выкарыстанні інструменты, памяншаючы тэхнічную запазычанасць, гэта значыць зніжаючы працэнт неэфектыўнага кода і састарэлых тэхналогій, арганізуючы карпаратыўную базу ведаў і доступ да знешніх рашэнняў.
Я думаю, што метадалогія і ідэалогія DevOps якраз у тым, каб гэтыя працэсы не залежалі ад вонкавых умоў, такіх як воблака ці сваё жалеза. Само па сабе воблака — не больш за прыладу, дзесьці ён дапаможа, дзесьці перашкодзіць ці будзе не запатрабаваны.
Дзяніс Раманенка, пазаштатны эксперт Mail.ru Cloud Solutions
Ніжэй разгледзім некаторыя складнікі паляпшэння эфектыўнасці DevOps-каманд.
Хмарныя тэхналогіі спрыяюць поспеху DevOps
У 2019 годзе ўсё больш арганізацый выбіраюць хмарныя рашэнні, якія значна падвышаюць прадукцыйнасць DevOps-каманд.
Якія інфраструктуры выкарыстоўваюць DevOps-каманды.
DORA выявіла, што 80% рэспандэнтаў размяшчаюць . Тым не менш толькі 29% рэспандэнтаў укаранілі ўсе пяць асноўных характарыстык хмарных вылічэнняў Нацыянальнага інстытута стандартаў і тэхналогій - гэта найважнейшы стандарт для ацэнкі каштоўнасці аблокі ў рамках DevOps.
Характарыстыка
Працэнт тых, хто выкарыстоўваў
Самаабслугоўванне па патрабаванні
Спажыўцы могуць аўтаматычна прадастаўляць вылічальныя рэсурсы
па меры неабходнасці, без удзелу правайдэра.
57%
(+ 11% з 2018 года)
Шырокі доступ да сеткі
Магчымасці аблокі даступныя праз розныя платформы,
такія як мабільныя тэлефоны, планшэты, ноўтбукі і працоўныя станцыі.
60%
(+ 14% з 2018 года)
Пул рэсурсаў
Рэсурсы правайдэра аб'ядноўваюцца ў мультытэнантны мадэль, дзе фізічныя і віртуальныя рэсурсы, дынамічна прызначаюцца па патрабаванні.
58%
(+ 15% з 2018 года)
Маштабаванасць і эластычнасць
Рэсурсы маштабуюцца гарызантальна ці вертыкальна па патрабаванні, яны практычна не абмежаваныя і могуць выдавацца ў любой колькасці ў любы час.
58%
(+135 з 2018 года)
празрыстасць
Воблачнае сістэмы аўтаматычна кантралююць, аптымізуюць і паведамляюць аб выкарыстанні рэсурсаў у залежнасці ад тыпу паслугі: захоўванне і апрацоўка дадзеных, колькасць трафіку,
актыўныя ўліковыя запісы карыстальнікаў.
62%
(+ 14% з 2018 года)
"Платформа як паслуга" (PaaS) усё больш пераходзіць да мадэлі разгортвання, засяроджанай вакол кантэйнераў. Воблачнае платформы спрашчаюць разгортванне ПА, у выніку камандам трэба турбавацца толькі аб выкананні самага кода прыкладання. Маштабаванне, планаванне рэсурсаў, адміністраванне і абслугоўванне інфраструктуры таксама пераходзіць на бок правайдэраў.
Для хмарных правайдэраў універсальным стандартам становіцца падаванне разнастайных паслуг: сеткі віртуальных машын, кіраванні ідэнтыфікацыяй і доступам (IAM), сховішчаў і баз дадзеных, машыннага навучання, інтэрнэту рэчаў (IoT), кантэйнерных рашэнняў, рашэнняў для бяспекі і іншых.
Кліенты хмарных правайдэраў аплачваюць толькі тыя рэсурсы, якія выкарыстоўваюць, што забяспечвае празрыстасць выдаткаў, у адрозненне ад традыцыйных ЦАД, дзе інфармацыю аб кошце распрацоўкі складана ці немагчыма здабыць. Рэспандэнты з кампаній, якія адказваюць хмарным характарыстыкам, пералічаным вышэй, у 2,6 разы дакладней ацэньваюць кошт працы ПЗ, у 2 разы часцей разумеюць, на якія прыкладанні сыходзіць больш рэсурсаў, у 1,65 разы часцей застаюцца ў рамках бюджэту, выдзеленага на IT.
Часам аказваецца, што наняць пісьменнага спецыяліста і ўзяць выдзеленыя магутнасці ў дата-цэнтры больш выгадна, чым аплачваць воблака. Які варыянт лепш, залежыць ад профіля і маштабу кампаніі, наяўнасці ўласнага штата IT-адмыслоўцаў і экспертызы. Напрыклад, воблака зручна выкарыстоўваць на старце бізнэсу ці калі ў кампаніі няма свайго IT-аддзела. Пры маштабаванні можа быць больш рэнтабельна ўтрымліваць усю інфраструктуру або яе частку on-premise.
Дзяніс Раманенка, пазаштатны эксперт Mail.ru Cloud Solutions
Тэхнічныя практыкі DevOps
Многія арганізацыі, якія жадаюць укараніць DevOps, шукаюць набор інструкцый ці лепшыя практыкі. Аднак аднолькавых кампаній няма, таму тое, якія практыкі абраць, залежыць ад бягучага стану бізнэсу і яго мэт.
Пры гэтым ёсць агульныя напрамкі, якія дапамагаюць палепшыць эфектыўнасць DevOps: некаторыя з іх распрацоўваюцца на ўзроўні каманды, іншыя патрабуюць намаганняў на ўзроўні арганізацыі.
Якія напрамкі росту выдзелены для DevOps-каманд у 2019 годзе:
На ўзроўні арганізацыі
- слабазвязаная архітэктура
- укараненне змен
- падтрымка кода
На ўзроўні каманды
- бесперапынная інтэграцыя
- аўтаматызацыя тэсціравання
- аўтаматызацыя разгортвання
- маніторынг
- канвеер распрацоўкі
На ўзроўні каманды і арганізацыі
- выкарыстанне хмарных сэрвісаў
- тэсціраванне аварыйнага аднаўлення
Даследаванне пацвердзіла дадатны ўплыў слабазвязанай архітэктуры на эфектыўнасць DevOps.
Слабазвязаная архітэктура - гэта калі каманды могуць незалежна тэставаць, разгортваць і змяняць сістэмы па патрабаванні, незалежна ад іншых каманд, без дадатковай падтрымкі, рэсурсаў, ухвалы, з меншай колькасцю зваротнай сувязі. Гэта дазваляе больш эфектыўна працаваць, але патрабуе высокага ўзроўню арганізацыі і кіравання.
Такі падыход магчымы толькі для стартапаў і з некаторымі агаворкамі. У іншых кампаніях можа быць іншая сытуацыя. Добры прыклад: банкаўская сфера / фінтэх. Там могуць выкарыстоўвацца выключна прапрыетарныя рашэнні, аднак будуць прымяняцца практыкі DevOps.
Дзяніс Раманенка, пазаштатны эксперт Mail.ru Cloud Solutions
Паспяховыя DevOps-каманды аўтаматызуюць усё
дазваляе выводзіць сэрвісы і прыкладанні ў прад з меншымі выдаткамі і рызыкамі, а таксама падтрымліваць рэлізы ў адпаведнасці з мэтамі арганізацыі.
Паспяховы CI/CD таксама азначае, што каманды могуць укараняць змены ў вытворчасць па патрабаванні, ім адразу ж даступная зваротная сувязь аб якасці разгортвання, яе можна хутка адпрацаваць і палепшыць наступны цыкл разгортвання.
Справаздача паказвае, што паспяховыя DevOps-каманды інвестуюць у шырокі спектр дапаможных працэсаў, практык і прылад:
- 92% выкарыстоўваюць аўтаматызаваныя прылады для зборкі;
- 87% выкарыстоўваюць аўтаматызаваныя юніт-тэсты;
- 57% распаўсюджваюць аўтаматызацыю на прыёмачныя выпрабаванні;
- 72% аўтаматызуюць разгортванні ў тэставых асяроддзях, 69% робяць тое ж самае для разгортвання ў продзе;
- 69% інтэгруюць чат-ботаў у працэс разгортвання;
- 57% інтэгруюцца з інструментамі маніторынгу.
Важна абраць правільныя прылады і тэхналогіі
Пры пабудове складаных сістэм і кіраванні крытычна важнымі для бізнесу інфраструктурамі важна падабраць тэхналогіі:
- якія лёгка выкарыстоўваць як пры першым падключэнні, так і ў сталай эксплуатацыі;
- якія дапамагаюць дасягнуць пастаўленых мэт.
У справаздачы вывучылі прылады, выкарыстоўваныя пры разгортванні праграмнага забеспячэння праз CI/CD, і інструментар аўтаматызацыі тэставання – менавіта гэтыя тэхналогіі ляжаць у аснове DevOps.
Якія тэхналогіі выкарыстоўваюць DevOps-каманды:
Тэхналогіі
Каманды з нізкімі паказчыкамі
Каманды з сярэднімі паказчыкамі
Каманды з добрымі паказчыкамі
Каманды з высокімі паказчыкамі
Спалучэнне прапрыетарных, open source і камерцыйных скрыначных прадуктаў
30%
34%
32%
33%
Галоўным чынам open source і моцна кастамізаваныя скрынкавыя рашэнні
17%
8%
7%
10%
У асноўным open source і скрынкавыя рашэнні з невялікай наладай
14%
21%
18%
20%
У першую чаргу скрынкавыя камерцыйныя рашэнні
8%
12%
8%
4%
Унутраныя распрацоўкі і прапрыетарныя рашэнні пад кампанію
20%
6%
5%
6%
У першую чаргу open source з моцнай кастамізацыяй
6%
7%
5%
12%
У першую чаргу open source з невялікай наладай
5%
12%
24%
15%
Выгода інструментаў істотна ўплывае на здольнасць каманды максымізаваць каштоўнасць абранага стэка тэхналогій: інжынеры з простымі ў выкарыстанні тэхналогіямі ў 1,5 разы часцей належаць да каманд з высокімі паказчыкамі.
На мой погляд, з гэтай табліцы складаецца адчуванне, што для таго, каб быць паспяховай DevOps-камандай, трэба прытрымлівацца моды, а не тэхнічнай задачы.
Пісьменны адмысловец выбірае прылады пад задачу, а не наадварот. Для рашэння любой задачы існуе заўсёды некалькі прылад і падыходаў. Канкрэтная прылада вызначаецца: спецыфікай задачы; наколькі з гэтай прыладай знакам персанал (наколькі вялікі парог уваходу, калі прылада новая); фінансавай складніку, калі такая прысутнічае.
Дзяніс Раманенка, пазаштатны эксперт Mail.ru Cloud Solutions
Аварыйнае аднаўленне
Кожная арганізацыя, праца якой залежыць ад працы праграмнага забеспячэння, павінна мець . У справаздачы паказана, якія віды тэсціравання катастрофаўстойлівасці выкарыстоўваюць розныя кампаніі.
Якія тыпы выпрабаванняў выкарыстоўваюць кампаніі для аварыйнага аднаўлення
Тып выпрабаванні
Каманды з нізкімі паказчыкамі
Каманды з сярэднімі паказчыкамі
Каманды з добрымі паказчыкамі
Каманды з высокімі паказчыкамі
У сярэднім
Тэсты, якія не закранаюць рэальныя сістэмы
35%
26%
27%
30%
28%
Аварыйнае пераключэнне інфраструктуры (у тым ліку ЦАД)
27%
43%
34%
38%
38%
Тэставанне адмовы прыкладання
25%
46%
41%
49%
43%
Мадэляванне інцыдэнтаў з парушэннем працы тэставых сістэм
18%
22%
23%
29%
23%
Мадэляванне інцыдэнтаў з парушэннем працы працоўных сістэм
18%
11%
12%
13%
12%
Стварэнне аўтаматызацыі і сістэм, якія парушаюць
вытворчыя сістэмы на рэгулярнай, пастаяннай аснове
9%
8%
7%
9%
8%
Толькі 40 працэнтаў рэспандэнтаў праводзяць тэсціраванне аварыйнага аднаўлення штогод, выкарыстоўваючы адзін або некалькі пералічаных метадаў. Пры гэтым у кампаніях, якія праводзяць выпрабаванні аварыйнага аднаўлення, больш высокі ўзровень даступнасці сэрвісаў. Справаздача паказвае, што DevOps-каманды з высокімі паказчыкамі ў 1.4 разы часцей улічваюць дадзеныя тэстаў аварыйнага аднаўлення ў працэсах распрацоўкі і разгортванні ПА.
Важна забяспечыць DevOps-камандам доступ да інфармацыі
Падтрымліваць прадукцыйнасць DevOps-каманд на высокім узроўні дапаможа лёгкі пошук інфармацыі для рашэння праблем. Гэта асабліва актуальна ў сучасным тэхналагічным асяроддзі, якая складаецца са складаных сістэм.
Крыніцы такой інфармацыі можна падзяліць на дзве групы:
- Унутраныя крыніцы: дакументацыя кампаніі па стварэнні і падтрымцы кода, карпаратыўныя базы ведаў, рэпазітары і іншае. Тыя DevOps-каманды, якія выкарыстоўвалі ўнутраныя крыніцы ведаў, былі ў 1,73 разоў больш прадуктыўнымі.
- знешнія крыніцы: пошукавыя сістэмы і папаўненне стэка. DevOps-каманды, якія звяртаюцца да вонкавых крыніц, былі ў 1,67 раз прадуктыўней. Вонкавыя тэхналогіі даюць вялікую перавагу для навучання і росты, асабліва ўжыванне агульнадаступных аблокаў і прылад з адчыненым зыходным кодам.
Кампаніям важна зніжаць тэхнічны доўг
Тэхнічны абавязак уключае код або сістэмы з вядомымі, але не выпраўленымі памылкамі; недастатковым пакрыццём тэстамі; нізкай якасцю кода або дызайну; артэфактамі, якія не выкарыстоўваюцца, але не выдаленыя; рэалізацыямі, якія каманда не можа эфектыўна падтрымліваць; састарэлымі тэхналогіямі; няпоўнай або састарэлай дакументацыяй.
Эксперты выявілі, што тэхнічны абавязак адмоўна ўплывае на эфектыўнасць DevOps. Каманды з высокім тэхнічным доўгам былі ў 1,6 раза менш прадуктыўнымі. Каманды з высокімі паказчыкамі ў 1,4 разы часцей мелі нізкі тэхнічны абавязак.
Ключавыя высновы даследавання аб стане DevOps
- Працэнт каманд DevOps з высокімі паказчыкамі амаль патроіўся і складае 20 працэнтаў. Гэта азначае, што бізнэс разумее перспектыўнасць практык паляпшэння распрацоўкі і дастаўкі ПЗ, кампаніі актыўней укараняюць DevOps у сваіх IT-аддзелах.
- Хуткая дастаўка прыкладанняў і сэрвісаў ляжыць у аснове трансфармацыі тэхналогій і арганізацыйных паказчыкаў. Хуткасць і стабільнасць выкаткі рэлізаў павялічвае прыбытак і задаволенасць кліентаў.
- Хмарныя тэхналогіі працягваюць быць ключавымі для дасягнення высокіх вынікаў DevOps-каманд. Выкарыстанне аблокаў дазваляе арганізаваць дастаўку ПЗ з патрэбнай хуткасцю, забяспечвае даступнасць, маштабаванасць і прадукцыйнасць інфраструктуры.
- Эфектыўнасць DevOps-каманд можна палепшыць, калі надаваць увагу прадуктыўнасці працы ўдзельнікаў каманды, забяспечыць камфортную псіхалагічную атмасферу і выкарыстанне зручных прылад.
- Павышэнне хуткасці выкаткі рэлізаў пры правільным падыходзе не ўплывае на стабільнасць працы сэрвісаў і прыкладанняў кампаніі.
Крыніца: habr.com
