Цяжка ўлавіць галоўнае, кажучы аб DevOps? Мы сабралі для вас яркія аналогіі, ударныя фармулёўкі і парады ад экспертаў, якія дапамогуць дайсці да сутнасці нават неспецыялістам. У канцы бонус - уласны DevOps супрацоўнікаў Red Hat.
Тэрмін DevOps узнік 10 гадоў таму і прайшоў шлях ад хэштэга ў Твітэры да магутнага культурнага руху ў свеце ІТ, сапраўднай філасофіі, якая заахвочвае распрацоўшчыкаў хутчэй дамагацца вынікаў, эксперыментаваць і рухацца наперад метадам ітэрацый. DevOps стаў непарыўна звязаны з паняццем лічбавай трансфармацыі. Але як гэта часта бывае з ІТ-тэрміналогіяй, за дзясятак гадоў DevOps паспеў абрасці мноствам азначэнняў, трактовак і памылак на свой рахунак.
Таму пра DevOps нярэдка можна пачуць пытанні накшталт, гэта тое ж самае, што agile? Ці гэта нейкая асаблівая метадалогія? Ці гэта проста яшчэ адзін сінонім слова "супрацоўніцтва"?
DevOps уключае ў сябе шмат розных канцэпцый (бесперапынная дастаўка, бесперапынная інтэграцыя, аўтаматызацыя і т. п.), таму вылучыць галоўнае можа быць няпроста, асабліва калі вы неабыякавыя да прадмета. Аднак гэтае ўменне вельмі карысна, усё роўна, спрабуеце вы данесці свае ідэі да начальства ці ж проста распавядаеце аб сваёй працы камусьці з родных ці знаёмых. Таму пакуль адкладзём у бок тэрміналагічныя нюансы DevOps і засяродзімся на агульнай карціне.
Што такое DevOps: 6 азначэнняў і аналогій
Мы папрасілі спецыялістаў растлумачыць сутнасць DevOps максімальна проста і коратка, каб яе каштоўнасць стала зразумела чытачу з любым узроўнем тэхнічнай падрыхтоўкі. Па выніках гэтых гутарак мы адабралі самыя яркія аналогіі і ўдарныя фармулёўкі, якія дапамогуць вам выбудаваць свой аповяд аб DevOps.
1. DevOps - гэта культурны рух
«DevOps – гэта культурны рух, у рамках якога абодва бакі (распрацоўнікі ПЗ і спецыялісты па эксплуатацыі ІТ-сістэм) прызнаюць, што софт не прыносіць рэальнай карысці да таго часу, пакуль ім не пачынае хтосьці карыстацца: заказчыкі, кліенты, супрацоўнікі, не сутнасць, – лічыць Эвеліна Эрліх (Eveline Oehrlich) старэйшы аналітык-даследчык Інстытута DevOps. – Таму абодва гэтыя бакі сумесна забяспечваюць хуткую і якасную дастаўку софту».
2. DevOps - гэта тое, што надзяляе ўладай распрацоўшчыкаў
"DevOps надзяляе распрацоўшчыкаў паўнамоцтвамі на валоданне праграмамі, іх запуск і кіраванне дастаўкай ад пачатку і да канца"
«Звычайна аб DevOps кажуць, як аб спосабе паскорыць дастаўку прыкладанняў у прадакшн за кошт выбудоўвання і прымянення аўтаматызаваных працэсаў, – кажа Джэй Шнайп (Jai Schniepp), дырэктар па платформах DevOps страхавой кампаніі Liberty Mutual. - Але для мяне гэта значна больш фундаментальная рэч. DevOps надзяляе распрацоўнікаў паўнамоцтвамі на валоданне праграмамі або пэўнымі часткамі ПЗ, на іх запуск і кіраванне дастаўкай ад пачатку і да канца. DevOps ухіляе блытаніну з адказнасцю і вядзе ўсіх удзельнікаў працэсу да стварэння аўтаматызаванай і кіраванай распрацоўнікам інфраструктуры».
3. DevOps - гэта супрацоўніцтва пры стварэнні і дастаўцы прыкладанняў
"Прасцей кажучы, DevOps – гэта такі падыход да вытворчасці і дастаўцы ПЗ, калі ўсе працуюць разам", – адзначае Гур Стаф, прэзідэнт і кіраўнік кірунку аўтаматызацыі лічбавага бізнесу кампаніі BMC.
4. DevOps - гэта канвеер
«Канвеерная зборка магчымая, толькі калі ўсе дэталі падыходзяць сябар да сябра».
Я бы параўнаў DevOps з канвеерам па зборцы аўтамабіляў, працягвае Гур Стаф. - Ідэя ў тым, каб загадзя спраектаваць і зрабіць усе дэталі так, каб потым іх можна было сабраць без індывідуальнай падганяння. Канвеерная зборка магчымая, толькі калі ўсе дэталі падыходзяць сябар да сябра. Тыя, хто праектуе і робіць рухавік, павінны падумаць аб тым, як мацаваць яго да кузава ці раме. Тыя, хто робіць тормазы, павінны падумаць аб колах, і гэтак далей. Сапраўды гэтак жа павінна быць і з софтам.
Распрацоўнік, які стварае бізнэс-логіку або карыстацкі інтэрфейс, павінен падумаць аб базе дадзеных, якая захоўвае звесткі аб заказчыках, аб сродках бяспекі для абароны карыстацкіх дадзеных, а таксама аб тым, як усё гэта будзе працаваць, калі сэрвіс пачне абслугоўваць вялікую, магчыма, нават шматмільённую. аўдыторыю карыстальнікаў».
«Зрабіць так, каб людзі супрацоўнічалі і думалі пра тыя часткі працы, якія выконваюцца іншымі, а не канцэнтраваліся выключна на сваіх уласных задачах – вось найвялікшая перашкода, якую трэба пераадолець. Калі гэта ўдаецца, у вас з'яўляюцца выдатныя шанцы на лічбавую трансфармацыю», - дадае Гур Стаф.
5. DevOps - гэта правільная камбінацыя людзей, працэсаў і аўтаматызацыя
Джэйн Грол (Jayne Groll), выканаўчы дырэктар Інстытута DevOps, прапанавала выдатную аналогію для тлумачэння DevOps. Паводле яе слоў, «DevOps - гэта як кулінарны рэцэпт, у якім ёсць тры асноўныя катэгорыі інгрэдыентаў: людзі, працэсы і аўтаматызацыя. Большасць гэтых інгрэдыентаў можна ўзяць з іншых абласцей і крыніц: Lean, Agile, SRE, CI/CD, ITIL, лідэрства, культура, інструменты. Сакрэт DevOps, як і любога добрага рэцэпту, у тым, як правільна падабраць прапорцыі і змяшаць гэтыя інгрэдыенты, каб павысіць хуткасць і рэзультатыўнасць працы пры стварэнні і выпуску прыкладанняў ».
6. DevOps - гэта калі праграмісты працуюць, як каманда Формулы-1
"Гонка плануецца не ад старту да фінішу, а наадварот, ад фінішу да старту".
«Гаворачы аб тым, чаго чакаць ад ініцыятывы DevOps, я прыводжу ў прыклад гоначную каманду NASCAR або Формулы-1, – кажа Крыс Шорт (Chris Short), галоўны мэнэджар па маркетынгу хмарных платформаў Red Hat і выдавец рассылання DevOps'ish. - У кіраўніка такой каманды адна мэта: заняць па выніках гонкі максімальна магчымае месца з улікам рэсурсаў, якія былі ў каманды, і выпаўшых на яе долю выпрабаванняў. Пры гэтым гонка плануецца не ад старту да фінішу, а наадварот, ад фінішу да старту. Спачатку ставіцца амбіцыйная мэта, а затым вызначаюцца шляхі яе дасягнення. Пасля чаго яны разбіваюцца на падзадачы і дэлегуюцца чальцам каманды».
«Увесь тыдзень перад гонкай каманда навострывае піт-стоп. Займаецца сілавымі і кардыятрэніроўкамі, каб быць у форме ў знясільваючы дзень гонак. Адпрацоўвае сумесныя дзеянні пры вырашэнні любых праблем, якія могуць узнікнуць на гонцы. Аналагічна каманда распрацоўшчыкаў павінна трэніраваць навыкі частага выпуску новых версій. Пры наяўнасці такіх навыкаў і адладжанай сістэмы бяспекі запуск новых версій у прадакшн таксама адбываецца часцей. У рамках гэтага светапогляду рост хуткасці азначае рост бяспекі», – кажа Шорт.
«Справа не ў тым, каб рабіць «правільныя рэчы», – дадае Шорт, – а ў тым, каб устараняць як мага больш рэчаў, якія стаяць на шляху да жаданага выніку. Супрацоўнічайце і адаптуйцеся з улікам зваротнай сувязі, якую вы атрымліваеце ў рэальным часе. Будзьце гатовыя да анамалій і працуйце над павышэннем якасці, каб звесці да мінімуму іх уплыў на рух да мэты. Менавіта гэта чакае нас у свеце DevOps».
Як маштабаваць DevOps: 10 парад ад экспертаў
Проста DevOps і масавы DevOps - гэта абсалютна розныя рэчы. Мы раскажам, як пераадолець бар'еры на шляху ад першага да другога.
Для многіх арганізацый шлях да DevOps пачынаецца лёгка і прыемна. Ствараюцца невялікія пасіянарныя каманды, старыя працэсы замяняюцца на новыя і першыя поспехі не прымушаюць сябе чакаць.
Нажаль, гэта толькі фальшывы бляск, ілюзія прагрэсу, як кажа Бэн Гриннел (Ben Grinnell), кіравальны дырэктар і кіраўнік кірунку лічбавых тэхналогій кансалтынгавай фірмы North Highland. Раннія перамогі вядома абнадзейваюць, але не дапамагаюць дасягнуць канчатковай мэты, а менавіта, масавага выкарыстання DevOps у арганізацыі.
Лёгка бачыць, што ў выніку фармуецца культура падзелу на "мы" і "яны".
«Часта часта арганізацыі запускаюць такія праекты-першапраходцы, лічачы, што яны пракладуць шлях да масавага DevOps, не задумваючыся, змогуць і ці захочуць пайсці гэтым шляхам астатнія, – тлумачыць Бэн Грынэл. - Каманды для рэалізацыі такіх праектаў звычайна набіраюць з самаўпэўненых "варагаў", якія ўжо рабілі нешта падобнае ў іншых месцах, але з'яўляюцца пачаткоўцамі ў вашай арганізацыі. Пры гэтым іх заахвочваюць ламаць і разбураць правілы, якія застаюцца абавязковымі для ўсіх астатніх. Лёгка бачыць, што ў выніку фарміруецца культура падзелу на “мы” і “яны”, якая перашкаджае перадачы ведаў і навыкаў”.
«І гэтая культурная праблема - толькі адна з прычын таго, што DevOps складана маштабаваць. Каманды DevOps сутыкаюцца з ростам асабліва тэхнічных складанасцяў, характэрным для хутка якія развіваюцца кампаній, якія зрабілі стаўку на ІТ-тэхналогіі», – кажа Стыў Ньюман (Steve Newman), заснавальнік і старшыня праўлення кампаніі Scalyr.
«У сучасным свеце паслугі мяняюцца адразу, як толькі з'яўляецца такая неабходнасць. Пастаянна рэалізоўваць і ўкараняць новыя функцыі, вядома, выдатна, але вось каардынаваць гэты працэс і ўстараняць праблемы, якія ўзнікаюць – сапраўдны галаўны боль, – дадае Стыў Ньюман. - У вельмі хутка якія растуць арганізацыях інжынеры ў складзе крос-функцыянальных каманд змагаюцца за тое, каб захаваць за сабой магчымасць адсочваць змены і якія параджаюцца імі каскадныя эфекты на ўзроўні залежнасцяў. Больш за тое, інжынераў зусім не радуе, калі іх пазбаўляюць такой магчымасці і ў выніку ім становіцца цяжэй разумець сутнасць праблем, якія ўзнікаюць».
Як жа пераадолець гэтыя апісаныя вышэй цяжкасці і перайсці да масавага выкарыстання DevOps у буйной арганізацыі? Эксперты заклікаюць назапасіцца цярпеннем, нават калі ваша канчатковая мэта складаецца ў тым, каб паскорыць цыкл распрацоўкі ПЗ і бізнес-працэсы.
1. Памятайце, што для змен у культуры патрэбны час
Джэйн Грол (Jayne Groll), выканаўчы дырэктар Інстытута DevOps: «На мой погляд, пашырэнне DevOps павінна быць такім жа паступовым і ітэратыўным, як і agile-распрацоўка (і ў роўнай меры закранаць культуру). У Agile і DevOps упор робіцца на невялікія каманды. Але па меры росту колькасці і інтэграцыі такіх каманд мы атрымліваем усё больш людзей, якія прымяняюць новыя метады працы, і, як следства, узнікае маштабная культурная трансфармацыя».
2. Надайце дастаткова часу планаванні і выбару платформы
Эран Кинсбрюнер (Eran Kinsbruner), кіроўны тэхнічны евангеліст кампаніі Perfecto: «Каб маштабаванне спрацавала, камандам DevOps у пачатку трэба навучыцца спалучаць традыцыйныя працэсы, прылады і навыкі, а затым павольна вырошчваць кожную асобную фазу DevOps і стабілізаваць яе. Усё пачынаецца з дбайнага планавання карыстацкіх гісторый (userstory) і струменяў стварэння каштоўнасці (valuestream), пасля чаго надыходзіць этап напісання ПА і кантролю версій з выкарыстаннем trunk-based development ці іншых падыходаў, найболей падыходных для галінавання і зліццё кода».
«Затым варта этап інтэграцыі і тэсціравання, дзе ўжо патрабуецца маштабаваная платформа для аўтаматызацыі. І тут камандам DevOps важна абраць правільную платформу, якая адпавядала б іх узроўню навыкаў і канчатковым мэтам праекту.
Наступная фаза - разгортванне ў вытворчым асяроддзі, і яно павінна быць цалкам аўтаматызавана з выкарыстаннем прылад аркестрацыі і кантэйнераў. Пры гэтым важна мець віртуалізаваныя асяроддзі на ўсіх этапах DevOps (сімулятар вытворчага асяроддзя, асяроддзе кантролю якасці і, уласна, вытворчае асяроддзе) і заўсёды выкарыстоўваць для тэстаў толькі самыя апошнія дадзеныя, каб атрымліваць актуальныя высновы. Аналітыка павінны быць разумнай і здольнай апрацоўваць вялікія дадзеныя з хуткай і дзейснай зваротнай сувяззю».
3. Пазбаўце адказнасці ад прысмаку віны
Гордан Хаф (Gordon Haff), евангеліст RedHat: «Стварэнне сістэмы і атмасферы, якая дазваляе і заахвочвае эксперыменты, дазваляе рэалізаваць так званыя паспяховыя збоі ў agile-распрацоўцы ПЗ. Гэта не значыць, што за збоі больш ніхто не адказвае. На самой справе ўсталяваць адказнага становіцца нават прасцей, паколькі "быць адказным" больш не азначае "стаць вінаватым у аварыі". Гэта значыць сутнасць адказнасці якасна мяняецца. Пры гэтым вельмі важнымі становяцца чатыры фактары: маштабы збою, падыходы, вытворчыя працэсы і стымулы». (Больш падрабязна пра гэтыя фактары можна прачытаць у артыкуле Гордана Хафа "DevOps lessons: 4 aspects of healthy experiments".)
4. Расчышчайце шлях наперад
Бэн Грынел (Ben Grinnell), кіраўнік дырэктар і кіраўнік кірунку лічбавых тэхналогій кансалтынгавай фірмы North Highland: «Каб дабіцца маштабавання, я рэкамендую разам з праектамі-першапраходцамі запускаць праграму «расчысткі шляху». Мэта гэтай праграмы - прыбіраць смецце, якое застаецца за першапраходцамі DevOps, накшталт страцілых актуальнасць правіл і іншых падобных рэчаў, каб шлях наперад заставаўся вольны».
«Дайце людзям арганізацыйную падтрымку і надайце імпульс праз камунікацыю, якая выходзіць далёка за межы групы першапраходцаў, шырока святкуючы поспехі новых метадаў працы. Трэніруйце людзей, якія задзейнічаны ў наступнай хвалі праектаў DevOps і нервуюцца з-за таго, што выкарыстоўваюць DevOps упершыню. І памятайце, што гэтыя людзі моцна адрозніваюцца ад першапраходцаў».
5. Зрабіце прылады больш дэмакратычнымі
Стыў Ньюман (Steve Newman), заснавальнік і старшыня праўлення кампаніі Scalyr: «Інструменты не трэба хаваць ад людзей, і яны павінныя быць адносна простыя ў засваенні для любога, хто гатовы выдаткаваць на гэты час. Калі магчымасць запытваць логі прадстаўлена толькі тром людзям, «сертыфікаваным» для працы з нейкай прыладай, у вас заўсёды будзе максімум тры чалавекі, здольных разабрацца з якая адпавядае праблемай, нават калі ў вас вельмі вялікае вылічальнае асяроддзе. Інакш кажучы, тут узнікае вузкае месца, якое можа прывесці да сур'ёзных (для бізнэсу) наступстваў».
6. Стварыце ідэальныя ўмовы для працы каманды
Том Кларк (Tom Clark), кіраўнік кірунку Common Platform у тэлекампаніі ITV: “Вы можаце зрабіць што заўгодна, але не ўсё адразу. Таму стаўце вялікія мэты, пачынайце з малога і рухайцеся наперад хуткімі ітэрацыямі. З часам вы запрацуеце рэпутацыю каманды, у якой усё атрымліваецца, таму іншыя таксама захочуць выкарыстоўваць вашыя метады. І не турыцеся за выбудоўваннем высокаэфектыўнай каманды. Замест гэтага забяспечце людзям ідэальныя ўмовы для працы і эфектыўнасць прыйдзе сама сабой».
7. Не забывайце аб законе Канвея і канбан-дошках
Логан Дэйгл (Logan Daigle), дырэктар па дастаўцы ПЗ і стратэгіі DevOps кампаніі CollabNetVersionOne: «Важна ўсведамляць наступствы закону Канвея. У маім вольным пераказванні гэты закон абвяшчае, што прадукты, якія мы ствараем, і працэсы, якія мы пры гэтым выкарыстоўваем, уключаючы DevOps, апыняюцца ўладкованыя гэтак жа, як і наша арганізацыя».
«Калі ў арганізацыя высокая раз'яднанасць, а пры планаванні, стварэнні і выпуску ПА кіраванне шмат разоў пераходзіць з рук у рукі, эфект ад маштабавання будзе нулявым ці недаўгавечным. Калі ж арганізацыя фармуе крос-функцыянальныя каманды вакол прадуктаў, якія фінансуюцца з арыентацыяй на рынак, то шанцы на поспех рэзка ўзрастаюць».
«Яшчэ адзін важны аспект маштабавання складаецца ў тым, каб адлюстроўваць на канбан-дошках усе працы, змешчаныя падчас выкананні (WIP, workinprogress). Калі ў арганізацыі з'яўляецца месца, дзе людзі могуць бачыць такія рэчы, гэта моцна стымулюе супрацоўніцтва, што станоўча ўплывае на маштабаванне».
8. Шукайце старыя шнары
Манюэль Паіс (Manuel Pais), кансультант па DevOps і суаўтар кнігі "Team Topologies": «Вывад практык DevOps за межы ўласна Dev і Ops і спробу прымяніць іх да іншых функцый наўрад ці можна назваць аптымальным падыходам. Гэта, несумненна, дасць пэўны эфект (напрыклад, за кошт аўтаматызацыі ручнога кіравання), але можна дабіцца значна большага, калі пачаць з разумення працэсаў дастаўкі і зваротнай сувязі».
«Калі ў ІТ-сістэме арганізацыі ёсць старыя шнары - працэдуры і механізмы кіравання, якія былі ўкаранёны па выніках мінулых інцыдэнтаў, але страцілі актуальнасць (з-за змены прадуктаў, тэхналогій або працэсаў), - то іх, безумоўна, трэба выдаляць або разгладжваць, а не аўтаматызаваць неэфектыўныя ці непатрэбныя працэсы».
9. Не пладзіце варыянты DevOps
Энтані Эдвардс (Antony Edwards), дырэктар па вытворчасці кампаніі Eggplant: «DevOps - вельмі расплывісты тэрмін, таму ў кожнай каманды атрымліваецца свой варыянт DevOps. І няма нічога горш, калі ў арганізацыі з'яўляюцца адразу 20 разнавіднасцяў DevOps, якія не вельмі добрае ўжываюцца разам. Нельга, каб у кожнай з трох каманды распрацоўшчыкаў быў свой, адмысловы інтэрфейсам паміж распрацоўкай і кіраваннем прадуктам. Як і нельга, каб прадукты мелі свае, унікальныя чаканні ў частцы апрацоўкі зваротнай сувязі пры пераносе ў сімулятар вытворчага асяроддзя. Інакш у вас ніколі не атрымаецца маштабаваць DevOps».
10. Прапаведуйце каштоўнасць DevOps для бізнесу
Стыў Ньюман (Steve Newman), заснавальнік і старшыня праўлення кампаніі Scalyr: «Папрацуйце над прызнаннем каштоўнасці DevOps. Навучыцеся і не саромейцеся расказваць аб карысці таго, што вы робіце. DevOps неверагодна эканоміць час і грошы (проста падумайце: менш прастояў, карацей сярэдні час аднаўлення), і каманды DevOps павінны нястомна падкрэсліваць (і прапаведаваць) важнасць гэтых ініцыятыў для поспеху бізнэсу. Так вы зможаце пашырыць круг адэптаў і ўзмацніць уплыў DevOps у арганізацыі».
БОНУС
На 13 верасня прыляціць наш уласны DevOps - так, у Red Hat, як у вытворцы праграмнага забеспячэння, ёсць уласныя DevOps каманды і практыкі.
Наш інжынер Марк Біргер, які займаецца распрацоўкай службаў унутранай аўтаматызацыі для іншых груп па ўсёй арганізацыі, на чыстай рускай мове раскажа ўласную гісторыю - як DevOps каманда Red Hat мігравала прыкладанні з віртуальных асяроддзяў Hat Virtualization, кіраваных Ansible у паўнавартасны кантэйнерны фармат на платформе OpenShift.
Але і гэта яшчэ не ўсё:
Пасля таго як арганізацыі перанеслі працоўныя нагрузкі ў кантэйнеры, традыцыйныя метады маніторынгу прыкладанняў могуць не спрацаваць. У другім дакладзе мы растлумачым нашу матывацыю да змены спосабу рэгістрацыі і пакажам працяг шляху, які прывёў нас да сучасных метадаў вядзення часопісаў і маніторынгу.
Крыніца: habr.com