Вызначэнне DevOps вельмі складанае, таму даводзіцца кожны раз запускаць дыскусію аб гэтым нанова. Толькі на Хабры тысяча публікацый на гэтую тэму. Але калі вы гэта праглядаеце, то напэўна ведаеце, што такое DevOps. Таму што я - не. Прывітанне, мяне клічуць Аляксандр Цітоў (@), і мы мы проста пагаворым аб DevOps і я падзялюся сваім вопытам.
Доўга думаў, як зрабіць маё апавяданне карысным, таму тут будзе шмат пытанняў - тых, якія я сам сабе задаю, і тых, якія я задаю кліентам нашай кампаніі. Адказваючы на гэтыя пытанні, разуменне становіцца лепшым. Я раскажу навошта патрэбен DevOps з майго пункту гледжання, што гэта такое, зноў жа, з маёй пазіцыі, і як зразумець, што вы рухаецеся да DevOps зноў з майго пункту гледжання. Апошні пункт будзе праз пытанні. Адказваючы на іх самому сабе, вы зможаце зразумець, ці рухаецца ваша кампанія да DevOps ці ў чымсьці ёсць праблемы.
Адзін час я гуляў па хвалях зліццяў і паглынанняў. Спачатку я папрацаваў у маленькім стартапе Qik, потым яго купіла крыху вялікая кампанія Skype, якую потым купіла яшчэ крыху вялікая кампанія Microsoft. У гэты момант мне стала даступна бачанне, як трансфармуецца ўяўленне аб DevOps у розных па велічыні кампаніях. Пасля гэтага мне стала цікава ўжо з пункта гледжання рынка глядзець на DevOps, і мы з калегамі арганізавалі кампанію Экспрэс 42. Ужо 6 гадоў мы рухаемся на ёй па хвалях рынка.
Акрамя ўсяго іншага я адзін з арганізатараў суполкі DevOps Moscow і арганізатар DevOps -Days 2017, але 2018 я не арганізоўваў. Экспрэс 42 працуе са шматлікімі кампаніямі. Мы прарошчваем там DevOps, глядзім, як гэта адбываецца, робім высновы, аналізуем, расказваем свае высновы ўсім, навучаем людзей DevOps-практыкам. Увогуле, усяляк гадуем у гэтым сэнсе досвед і экспертызу.
Навошта DevOps
Першае пытанне, якое пераследуе ўсіх і заўсёды - навошта? Многія лічаць, што DevOps - гэта проста аўтаматызацыя або падобная штука, якая ўжо была ў кожнай кампаніі.
– У нас быў Continuous Integration – гэта значыць, ужо быў DevOps, і навошта ўсё гэтае бацвінне патрэбна? Там за мяжой забаўляюцца, а нам працаваць мяшаюць!
За 9 гадоў развіцця супольнасці і метадалогіі ўжо стала зразумела, што гэта ўсё ж такі не маркетынгавыя бліскаўкі, але ўсё роўна не да канца зразумела навошта ён патрэбны. Як у любой прылады і працэсу, у DevOps ёсць пэўныя мэты, якія ён у выніку вырашае.
Усё гэта звязана з тым, што свет мяняецца. Ён сыходзіць ад падыходу enterprise, калі кампаніі рухаюцца адразу да мары, як спяваў наш піцерскі класік, з кропкі А ў кропку Ў па вызначанай стратэгіі, з пабудаванай для гэтага вызначанай структурай.
У прынцыпе ў IT усё і павінна быць пабудавана пад гэты падыход. Тут IT выкарыстоўваецца выключна для аўтаматызацыі працэсаў.
Аўтаматызацыя не часта мяняецца, таму што калі кампанія коціцца па наезджанай каляіне - што там мяняць? Працуе - не чапай. Цяпер у свеце падыходы мяняюцца, і той, што называецца словам Agile, кажа аб тым, што канчатковай кропкі У адразу не відаць.
Калі кампанія ідзе па рынку, працуе з кліентам - яна пастаянна даследуе рынак і мяняе канчатковую кропку В. Прычым чым часцей кампанія мяняе свой кірунак, тым больш яна ў выніку паспяховая, таму што выбірае больш рынкавых ніш.
Стратэгію дэманструе цікавая кампанія, пра якую я даведаўся нядаўна. One Box Shave - сэрвіс па дастаўцы брытв і брытвавых прылад па падпісцы ў скрынцы. Яны ўмеюць кастамізаваць сваю «скрыначку» пад розных кліентаў. Гэтым займаецца пэўны софт, які потым адпраўляе замову на карэйскую фабрыку, якая выпускае тавар.
Гэты прадукт купіла кампанія Unilever за 1 млрд. долараў. Цяпер ён канкуруе з Gillette і ад'еў у яго значную дзель спажыўцоў на амерыканскім рынку. One Box Shave кажуць:
- 4 ляза? Вы сур'ёзна? Навошта вам гэта трэба - гэта ніяк не паляпшае якасць галення. Адмыслова падабраны крэм, отдушка і якасная брытва з двума лёзамі вырашаюць значна больш пытанняў, чым гэтыя дурныя 4 ляза Gillette! Дык хутка да 10 дойдзем?
Так свет мяняецца. Unilever заяўляюць аб тым, што ў іх ёсць крутая IT-сістэма, якая дазваляе гэта рабіць. У выніку гэта выглядае як канцэпцыя. Час выхаду на рынак, пра якую ўжо хто толькі не казаў.
Сэнс Time-to-market не ў тым, як часта мы дэплоім. Часта можна дэплоіць, але пры гэтым рэлізныя цыклы будуць доўгімі. Калі трохмесячныя рэлізныя цыклы накладваць сябар на сябра, зрушваючы на тыдзень, атрымліваецца, што кампанія як быццам дэплоіцца раз у тыдзень. А ад ідэі да канчатковай рэалізацыі праходзіць 3 месяцы.
Time-to-market - гэта пра мінімізацыю часу ад ідэі да канчатковай рэалізацыі.
У гэтым выпадку з рынкам узаемадзейнічае ПЗ. Так у One Box Shave з кліентам узаемадзейнічае сайт. У іх няма прадаўцоў - проста сайт, дзе наведвальнік клікае і пакідае пажаданні. Адпаведна, на сайце трэба ўвесь час размяшчаць нешта новае, абнаўляць яго ў адпаведнасці з пажаданнямі. Напрыклад, у Паўднёвай Карэі галяцца не так, як у Расіі, і ім падабаецца ў отдушке не пах хвоі, а, напрыклад, морквы ванілі.
Паколькі патрабуецца хутка мяняць напаўненне сайта, распрацоўка ПЗ моцна мяняецца. Праз ПЗ мы павінны даведвацца, што хоча кліент. Раней мы гэта даведваліся нейкімі абыходнымі шляхамі, напрыклад, праз бізнэс-менеджмент. Потым праектавалі, закладвалі патрабаванні ў IT-сістэму, і ўсё было крута. Цяпер па-іншаму – ПЗ праектуецца ўсімі, хто ўключаны ў працэс, у тым ліку і інжынерамі, таму што яны даведаюцца праз тэхнічныя характарыстыкі, як працуе рынак, і таксама дзеляцца з бізнесам сваімі інсайтамі.
Напрыклад, у кампаніі Qik мы раптам даведаліся, што людзям вельмі падабаецца загружаць кантакт-лісты на сервер, і яны паклалі нам праграму. Першапачаткова мы пра гэта не задумваліся. У класічнай кампаніі ўсё б вырашылі, што гэта бага, бо ў спяцы не напісана, што гэта павінна класна працаваць і наогул было рэалізавана на каленцы, выключылі б фічу і сказалі: "Гэта нікому не трэба, самае галоўнае, што асноўная функцыянальнасць працуе" . А тэхналагічная кампанія ў гэтым бачыць магчымасць і пачынае мяняць софт у згодзе з гэтым.
У 1968 годзе празорлівы хлопец Мелвін Канвей сфармуляваў наступную ідэю.
Арганізацыя, якая стварае сістэму, абмежавана дызайнам, які капіруе структуру камунікацыі ў гэтай арганізацыі.
Калі падрабязней, - каб вырабляць сістэмы іншага тыпу, трэба яшчэ ў дадатак мець камунікацыйную структуру ўнутры кампаніі іншага тыпу. Калі ў вас камунікацыйная структура верхне іерархічная, тое гэта не дазволіць вам рабіць сістэмы, якія могуць забяспечваць вельмі высокі паказчык Time-to-market.
Пачытаць можна . Ён важны для разумення культуры ці філасофіі DevOps, бо адзінае, што базава змяняецца ў DevOps - гэта менавіта структура камунікацыі паміж камандамі.
З пункту гледжання працэсу, да DevOps усе стадыі: аналітыка, распрацоўка, тэсціраванне, эксплуатацыя, праходзілі лінейна.
У выпадку DevOps усе гэтыя працэсы ідуць адначасова.
Time-to-market толькі так і можа выконвацца. Для людзей, якія працавалі ў старым працэсе, гэта выглядае некалькі касмічна, і ўвогуле так сабе.
Дык навошта патрэбен DevOps?
Для распрацоўкі лічбавых прадуктаў. Калі ў вас у кампаніі няма лічбавага прадукта, DevOps не патрэбен – гэта вельмі важна.
DevOps пераадольвае хуткасныя абмежаванні паслядоўнай схемы вытворчасці ПЗ. У ім усе працэсы адбываюцца адначасова.
Павялічваецца складанасць. Калі DevOps-евангелісты распавядаюць, што з ім вам стане прасцей выпускаць ПА – гэта трызняціна.
З DevOps усё будзе толькі складаней.
На канферэнцыі на стэндзе Авіта можна было паглядзець, што такое задэплоіць Docker-кантэйнер - нерэальная задача. Складанасць становіцца залімітавай, трэба жангляваць шматлікімі шарыкамі адначасова.
DevOps мяняе цалкам працэс і арганізацыю ў кампаніі - Дакладней, змяняе не DevOps, а лічбавы прадукт. Каб прыйсці да DevOps, трэба ўсё ж такі гэты працэс цалкам памяняць.
Пытанні для спецыяліста
А што ў вас? Пытанні, якія вы можаце сабе задаць, працуючы ў кампаніі і развіваючыся, як спецыяліст.
Ці ёсць у вас стратэгія па стварэнні лічбавага прадукта? Калі ёсць - ужо добра. Гэта значыць, што ваша кампанія рухаецца да DevOps.
Ваша кампанія ўжо стварае лічбавы прадукт? Гэта значыць, што вы можаце падняцца яшчэ на прыступку вышэй, займацца справамі цікавей - з пункту гледжання DevOps ізноў-ткі. Я толькі з гэтага пункту гледжання гавару.
Ваша кампанія адзін з лідэраў рынку ў нішы з лічбавым прадуктам? Spotify, Яндэкс, Uber - кампаніі, якія знаходзяцца на піку тэхналагічнага прагрэсу цяпер.
Задайце сабе гэтыя пытанні, і калі ўсе адказы адмоўныя, то, магчыма, вам і не варта займацца DevOps у гэтай кампаніі. Калі ж вам тэма DevOps рэальна цікавая, магчыма… вам варта перайсці ў іншую кампанію? Калі ваша кампанія хоча пайсці ў DevOps, але на ўсе пытанні вы адказалі «Не», то яна нагадвае гэтага цудоўнага насарожыка, які ніколі не зменіцца.
Арганізацыя
Як я ўжо сказаў, па законе Канвея ў кампаніі мяняецца арганізацыя. Пачну з таго, што мяшае DevOps пранікаць унутр кампаніі менавіта з пункта гледжання арганізацыі.
Праблема «студняў»
Ангельскае слова "Silo" перакладзена тут на рускую як "студзень". Сэнс гэтай праблемы ў тым, што паміж камандамі няма абмену інфармацыяй. Кожная каманда капае сваю экспертызу ўглыб, пры гэтым не будуючы агульную карту, у якой можна арыентавацца.
Нечым гэта нагадвае чалавека, які толькі прыехаў у Маскву і яшчэ не ўмее арыентавацца па карце метро. Масквічы звычайна цудоўна ведаюць свой раён, а па ўсёй Маскве арыентуюцца па карце метро. Калі ты прыязджаеш у Маскву ў першы раз, няма гэтага навыку, і ты проста дэзарыентаваны.
DevOps прапануе прайсці гэты момант дэзарыентацыі і ўсім падраздзяленням разам пабудаваць агульную карту ўзаемадзеяння.
Гэтаму перашкаджаюць два фактары.
Следства карпаратыўнай сістэмы кіравання. Яна пабудавана асобнымі іерархічнымі «студнямі». Напрыклад, ёсць пэўныя KPI у кампаніях, якія гэтую сістэму падтрымліваюць. З іншага боку, мяшаюць мазгі чалавека, якому складана выйсці за межы сваёй экспертызы і арыентавацца ва ўсёй сістэме. Гэта проста некамфортна. Уявіце сабе, што вы патрапілі ў аэрапорт Бангкока - там хутка не зарыентуешся. У DevOps таксама складана арыентавацца, і таму людзі кажуць, што трэба знайсці правадыра знайсці, каб туды патрапіць.
Але самае галоўнае, што праблема "студняў" для інжынера, які прасякнуўся духам DevOps, начытаўся Фаулера і кучу іншых кніжак, выяўляецца ў тым, што «студні» не дазваляюць рабіць «відавочныя» рэчы. Мы часта збіраемся пасля DevOps Moscow, размаўляем сябар з сябрам, і людзі жаляцца:
- Мы хацелі проста CI запусціць, а атрымалася, што менеджменту гэта не трэба.
Гэта адбываецца менавіта з-за таго, што CI и Continuous Delivery process знаходзяцца на мяжы шматлікіх экспертыз. Проста не пераадолеўшы праблему «студняў» на арганізацыйным узроўні, не атрымаецца рушыць наперад далей, што б вы не рабілі і як бы гэта сумна не было.
Кожны ўдзельнік працэсу ў кампаніі: распрацоўшчыкі бэкенда і фронтэнда, тэставанне, DBA, эксплуатацыя, сетка, капае ў свой бок, а агульнай карты не мае ніхто, акрамя кіраванца, які неяк іх аглядае і кіруе метадам "падзяляй і пануй".
Людзі змагаюцца за нейкія зорачкі ці сцяжкі, кожны капае сваю экспертызу.
У выніку, калі з'яўляецца задача ўсё гэта злучыць разам і пабудаваць агульны пайплайн, і за зорачкі і сцяжкі ўжо змагацца не трэба, з'яўляецца пытанне - а што рабіць-то наогул? Трэба неяк дамаўляцца, а як гэта рабіць, нас у школе ніхто не вучыў. Мы яшчэ са школы навучаны: восьмы клас - ого! - у параўнанні з сёмым класам! Тут тое самае.
У вашай кампаніі гэтак жа?
Каб гэта праверыць, можна задаць сабе наступныя пытанні.
Ці карыстаюцца каманды агульнымі інструментамі, ці ўносяць уклад у змены гэтых агульных інструментаў?
Наколькі часта каманды перафармуюцца - адны спецыялісты з адной каманды пераходзяць у іншую каманду? Менавіта ў DevOps-асяроддзі гэта становіцца нармальным, таму што часам чалавек проста не можа зразумець, чым займаецца іншая зона экспертызы. Ён пераходзіць у іншы аддзел, два тыдні там працуе, каб стварыць для сябе карту арыентацыі і ўзаемадзеянні з гэтым аддзелам.
Ці можна стварыць камітэт па змене і нешта змяніць? Ці для гэтага патрэбная моцная рука самага вышэйшага кіраўніцтва і распараджэнне? Нядаўна я напісаў у Facebook, як адзін малавядомы банк праз распараджэнні ўкараняе інструменты: напісалі распараджэнне, год укараняем, глядзім, што адбываецца. Гэта, вядома, доўга і маркотна.
Наколькі важна для мэнэджэраў атрымліваць асабістыя дасягненні без уліку дасягненняў кампаніі?
Калі вы для сябе адкажаце на гэтыя пытанні, стане больш зразумела, ці ёсць у вас такая праблема ў кампаніі.
Інфраструктура як код
Пасля таго, як гэтая праблема пройдзена, першая важная практыка, без якой складана рушыць наперад у DevOps далей – гэта інфраструктура як код.
Часцей за ўсё інфраструктуру як код успрымаюць так:
- Давайце ўсё аўтаматызуем на bash, абмажамся скрыптамі, каб у адмінак было менш ручной працы!
Але гэта не так.
Інфраструктура як код мае на ўвазе, што IT-сістэму, з якой працуеце, вы апісваеце ў выглядзе кода, каб увесь час разумець яе стан.
Сумесна з іншымі камандамі вы ствараеце карту ў выглядзе кода, якая ўсім зразумелая, па якой можна арыентавацца, навігаваць. Без розніцы, на чым гэта зроблена – Chef, Ansible, Salt, ці выкарыстоўваюцца YAML-файлы ў Kubernetes – няма розніцы.
На канферэнцыі калега з 2ГІС распавядаў, як яны зрабілі сваю ўнутраную штуку для Kubernetes, якая апісвае прыладу асобных сістэм. Каб апісаць 500 сістэм, ім запатрабавалася асобная прылада, які гэтае апісанне генеруе. Калі ёсць гэтае апісанне, кожны можа спраўджвацца адзін з адным, маніторыць змены, як яго памяняць і палепшыць, чаго не хапае.
Пагадзіцеся, асобныя bash-скрыпты звычайна не даюць гэтага разумення. У адной з кампаній, дзе я працаваў, была нават назва "write only"-скрыпт - калі скрыпт напісаны, а прачытаць яго ўжо немагчыма. Мяркую, што гэта вам таксама знаёма.
Інфраструктура як код - гэта код, які апісвае актуальны стан інфраструктуры. Над гэтым кодам сумесна працуе мноства прадуктовых, інфраструктурных і сэрвісных каманд, і, самае галоўнае, усе яны павінны разумець, як гэты код увогуле працуе.
Код суправаджаецца паводле лепшых практыкаў працы з кодам: сумесная распрацоўка, код-рэўю, XP-programming, тэсціраванне, пулрэквесты, CI для інфраструктур кода - гэта ўсё прыдатна і можна выкарыстоўваць.
Код становіцца агульнай мовай для ўсіх інжынераў.
Змена інфраструктуры ў кодзе не займае шмат часу. Так, у інфраструктурным кодзе таксама можа быць тэхнічны абавязак. Звычайна каманды сутыкаюцца з ім гады праз паўтара пасля таго, як пачалі ўкараняць "інфраструктуру як код" у выглядзе кучы скрыптоў ці нават Ansible, які яны пішуць як спагецці-код, і яшчэ bash-скрыпты туды падкідваюць у тэпціку!
Важна: калі вы яшчэ не паспрабавалі гэтую дрэнь, запомніце, што Ansible - не bash! Уважліва чытайце дакументацыю, вывучайце, што ўвогуле пра гэта пішуць.
Інфраструктура як код - гэта падзел інфраструктурнага кода на асобныя пласты.
Мы ў сябе ў кампаніі вылучаем 3 базавыя пласта, якія вельмі зразумелыя і простыя, але іх можа быць больш. Вы можаце паглядзець на ваш інфраструктурны код і сказаць, ці ёсць у вас гэта ўмова ці не. Калі ніякія пласты не вылучаюцца, тое трэба вылучыць час і порефакторить трошкі.
Базавы пласт - гэта як наладжваецца АС, бэкапы і іншыя нізкаўзроўневыя штукі, напрыклад, як разгортваецца Kubernetes на базавым узроўні.
Узровень сэрвісаў — гэта тыя сэрвісы, якія вы даяце распрацоўніку: лагіраванне як сэрвіс, маніторынг як сэрвіс, база дадзеных як сэрвіс, балансавальнік як сэрвіс, чарга як сэрвіс, Continuous Delivery як сэрвіс — куча сэрвісаў, якія асобныя каманды могуць падаваць распрацоўцы. Гэта ўсё неабходна апісваць асобнымі модулямі ў вашай сістэме кіравання канфігурацыяй.
Пласт, дзе робяцца прыкладанні і апісваецца, як яны будуць разгортвацца па-над двума папярэднімі пластоў.
Кантрольныя пытанні
Ці ёсць у вас у кампаніі агульны інфраструктурны рэпазітар? Ці кантралюеце вы тэхнічны доўг у інфраструктуры? Ці карыстаецеся вы практыкі распрацоўкі ў інфраструктурным рэпазітары? Ці нарэзана ваша інфраструктура на пласты? Можна зверыцца са схемай Base-service-APP. Наколькі складана ўнесці змену?
Калі вы сутыкаліся з тым, што занясенне змен займала паўтара дня, гэта значыць, што ў вас з'явіўся тэхнічны абавязак і з ім трэба папрацаваць. Вы якраз натыкнуліся на граблі тэхнічнага абавязку ў інфраструктурным кодзе. Я памятаю шмат такіх гісторый, калі каб памяняць які-небудзь CCTL, трэба перапісаць палову інфраструктурнага кода, таму што творчасць і жаданне ўсё аўтаматызаваць прывяло да таго, што ўсюды ўсё закарскурана, усе ручкі прыбраныя, і трэба рэфактарыць.
Бесперапынная пастаўка
Падабенствам дэбіт з крэдытам. Спачатку ўзнікае апісанне інфраструктуры, якое можа быць даволі базавым. Неабавязкова ўсё апісваць дэталёва, але нейкае базавае апісанне патрабуецца, каб вы маглі з гэтым працаваць. Інакш незразумела, па-над чым далей наогул рабіць бесперапынную пастаўку. Усе гэтыя практыкі разгортваюцца адначасова, калі вы прыходзіце да DevOps, але пачынаць трэба з разумення таго, што ў вас есць, і як гэтым кіраваць. Гэта як раз практыка інфраструктура як код.
Пасля таго, як стала зразумела, што ў вас ёсць, як гэтым кіраваць, вы пачынаеце прыдумляць, як код распрацоўніка максімальна хутка адправіць на прадакшн. Я маю на ўвазе разам з распрацоўшчыкам - памятаем пра праблему «студняў», гэта значыць не асобныя людзі гэта прыдумляюць, а камандай.
Калі мы з Янкам Еўтуховічам ўбачылі першую кніжку Джэза Хамбла і групы аўтараў "Continuous Delivery", якая выйшла ў 2009 годзе, то доўга думалі, як перавесці яе назву на рускую мову. Хацелі перавесці як "Пастаянна дастаўляць", але, на жаль, перавялі як "Бесперапынная пастаўка". Мне падаецца, што ў нашай назве ёсць нешта такое рускае, з напорам.
Стала дастаўляць - гэта значыць
Код, які ляжыць у прадуктовым рэпазітары, заўсёды можа быць выпампаваны ў прадакшн. Ён можа быць і не выпампаваны, але заўсёды гатовы да гэтага. Адпаведна, вы заўсёды пішыце код з цяжка вытлумачальным пачуццём некаторай турботы пад хвасцец. Яно часта з'яўляецца, калі выкочваеш інфраструктурны код. Гэта пачуццё некаторай турботы і павінна прысутнічаць – яно выклікае мазгавыя працэсы, якія дазваляюць пісаць код крыху па-іншаму. Гэта павінна быць зафіксавана ў правілах унутры распрацоўкі.
Каб увесь час дастаўляць, патрэбен фармат артэфакта, які праходзіць па інфраструктурнай платформе. Калі вы кідаеце па інфраструктурнай платформе рознага фармату "адходы жыццядзейнасці", то яна ў вас становіцца не уніфікаванай, яе складана суправаджаць, узнікае праблема тэхнічнага доўгу. Фармат артэфакта трэба выраўнаваць – гэта таксама калектыўная задача: трэба ўсім разам сабрацца, пашамацець мазгамі і прыдумаць гэты фармат.
Артэфакт бесперапынна паляпшаецца і змяняецца пад прадакшн-асяроддзе падчас праходжання па пайплайн пастаўкі. Калі артэфакт рухаецца па пайплайне, ён увесь час сутыкаецца з нейкімі нязручнымі для яго рэчамі, якія падобныя на тое, з чым сутыкаецца артэфакт, які вы выкладваеце ў прадакшн. Калі ў класічнай распрацоўцы гэтым займаецца сісадмін, які робіць выкатку, то ў DevOps-працэсе гэта адбываецца ўвесь час: тут яго нейкімі тэстамі пакруцілі, тут – у Kubernetes-кластар закінулі, які больш-менш падобны на прадакшн, тут раптам запусцілі нагрузачнае тэставанне .
Гэта нечым нагадвае гульню Пакман — артэфакт праходзіць нейкую гісторыю. Пры гэтым важна кантраляваць, ці рэальна код праходзіць гісторыю і яна неяк звязана з вашым прадакшн. Гісторыі з прадакшэн можна зацягваць унутр Continuous Delivery працэсу: было так, калі нешта ўпала, зараз давайце гэты сцэнар проста запраграмуем ўнутр сістэмы. Кожны раз код будзе праходзіць гэты сцэнар таксама, і вы не сутыкнецеся наступны раз з гэтай праблемай. Вы даведаецеся пра яе моцна раней, чым яна выйдзе да вашага кліента.
Розныя стратэгіі дэплояў. Напрыклад, вы выкарыстоўваеце AB-тэставанне або канарэечныя дэплойменты, каб па-рознаму "мацаць" код на розных кліентах, атрымліваць інфармацыю аб тым, як код працуе, і моцна раней, чым калі ён выкаціцца на 100 млн карыстачоў.
"Пастаянна дастаўляць" выглядае так.
Працэс пастаўкі Dev, CI, Test, PreProd, Prod - гэта не асобнае асяроддзе, гэта стэйджы або станцыі з незгаральнымі сумамі, па якіх праходзіць ваш артэфакт.
Калі ў вас ёсць інфраструктурны код, які апісаны як Base Service APP, то ён дапамагае не забыць усе сцэнары, і запісаць іх таксама ў выглядзе кода для гэтага артэфакта, прасоўваць артэфакт і мяняць яго па ходзе руху.
Пытанні для самаправеркі
Час ад апісання фічы да выкаткі ў прадакшэн ў 95% выпадкаў менш за тыдзень? Ці павышаецца якасць артэфакта на кожным этапе пайплайну? Ці ёсць гісторыя, па якой ён праходзіць? Карыстаецеся Ці вы розныя стратэгіі дэплою?
Калі ўсе адказы так, то вы нерэальна крутыя! Напішыце адказы ў каментары - я буду рады).
Зваротная сувязь
Гэта самая складаная практыка з усіх. На канферэнцыі DevOpsConf калега з Infobip, распавядаючы пра яе, крыху блытаўся ў словах, таму што гэта сапраўды вельмі складаная практыка пра тое, што трэба маніторыць увогуле ўсё!
Напрыклад, даўным-даўно, калі я працаваў у Qik і мы зразумелі, што трэба маніторыць увогуле ўсё. Мы гэта зрабілі, і ў нас у Zabbix з'явілася 150 000 items, якія маніторыцца ўвесь час. Гэта было страшна, тэхнічны дырэктар круціў пальцам ля скроні:
- Хлопцы, вы навошта сервак гвалтуеце незразумела чым?
Але потым здарыўся выпадак, які паказаў, што гэта рэальна вельмі крутая стратэгія.
Увесь час пачаў падаць адзін з сэрвісаў. Першапачаткова ён не падаў, што цікава, туды код не дапісваўся, таму што гэта быў базавы брокер, у якім практычна не было бізнэс-функцыянальнасці - ён проста ганяў паведамленні паміж асобнымі сэрвісамі. Сэрвіс не мяняўся 4 месяцы, і раптам стаў падаць з памылкай "Segmentation fault".
Мы былі ў шоку, адкрылі нашы графікі ў Zabbix, і высветлілася, што, аказваецца, паўтары тыдні таму моцна змяніліся паводзіны запытаў у API-сэрвісе, які выкарыстоўвае гэты брокер. Далей мы паглядзелі, што змянілася частата пасылкі вызначанага тыпу паведамленняў. Пасля высветлілі, што гэта android-кліенты. Мы спыталі:
- Хлопцы, а што ў вас здарылася паўтара тыдні таму?
У адказ пачулі цікавую гісторыю аб тым, што яны перарабілі UI. Ці наўрад хто адразу скажа, што памяняў HTTP-бібліятэку. Для android-кліентаў гэта як мыла змяніць у ваннай - яны проста гэта не памятаюць. У выніку, пасля 40 хвілін размовы, мы высветлілі, што яны ўсё ж змянілі HTTP-бібліятэку, і ў яе змяніліся дэфолтныя таймінгі. Гэта прывяло да таго, што змянілася паводзіны трафіку на API серверы, што і прывяло да сітуацыі, якая выклікала гонку ўнутры брокера, і ён пачаў падаць.
Без глыбокага маніторынгу гэта выявіць наогул немагчыма. Калі ж у арганізацыі ёсць яшчэ праблема "студняў", калі кожны перакідае сябар на сябра, гэта можа жыць гадамі. Вы проста рэстартуеце сервер, таму што немагчыма вырашыць праблему. Калі вы маніторыце, адсочваеце, трэкаеце ўсе падзеі, якія ў вас ёсць, і выкарыстоўваеце маніторынг як тэставанне - пішаце код і адразу ж паказваеце, як яго праманіторыць, таксама ў выглядзе кода (у нас ужо інфраструктура як код ёсць), усё становіцца ясна як на далоні. Нават такія складаныя праблемы лёгка адсочваюцца.
Збірайце ўсю інфармацыю аб тым, што адбываецца з артэфактам на кожнай стадыі працэсу пастаўкі - не ў прадакшн.
Маніторынг грузіце на CI, і тамака ўжо будуць бачныя нейкія базавыя рэчы. Далей вы іх убачыце і ў Test, і ў PredProd, і ў нагрузачным тэсціраванні. Збірайце інфармацыю на ўсіх стадыях, прычым не толькі метрыкі, статыстыку, але і логі: як выкацілася дадатак, анамаліі - збірайце ўсё.
У адваротным выпадку будзе складана разабрацца. Я ўжо казаў, што DevOps - гэта вялікая складанасць. Каб зладзіцца з гэтай складанасцю, трэба мець звычайную аналітыку.
Пытанні для самакантролю
Ваш маніторынг і лагіраванне - гэта сродак распрацоўкі для вас? Вашы распрацоўшчыкі, і вы ў тым ліку, калі пішуць код, думаюць аб тым, як яго заманіторыць?
Ці даведаецеся вы аб праблемах ад кліентаў? Ці разумееце вы кліента лепш з маніторынгу і лагіраванні? Ці разумееце вы сістэму лепш з маніторынгу і лагіраванні? Ці змяняеце вы сістэму проста таму, што ўбачылі, што трэнд у сістэме расце і разумееце, што яшчэ 3 тыдні і ўсё загнецца?
Калі ў вас ёсць гэтыя тры кампаненты, вы можаце падумаць аб тым, якая ў вас у кампаніі інфраструктурная платформа.
Інфраструктурная платформа
Сэнс не ў тым, што гэта набор разрозненых прылад, які ёсць у кожнай кампаніі.
Сэнс інфраструктурнай платформы ў тым, што ўсе каманды карыстаюцца гэтымі прыладамі і развіваюць іх сумесна.
Зразумела, што ёсць асобныя каманды, якія нясуць адказнасць за развіццё асобных кавалкаў інфраструктурнай платформы. Але пры гэтым адказнасць за развіццё, працаздольнасць, пасоўванне інфраструктурнай платформы нясе кожны інжынер. На ўнутраным узроўні гэта становіцца агульным інструментам.
Усе каманды развіваюць інфраструктурную платформу, ставяцца беражліва да яе як да ўласнага IDE. У сваім IDE вы ставіце розныя плагіны, каб усё было прыгожа і хутка, настройваеце гарачыя клавішы. Калі вы адчыняеце Sublime, Atom ці Visual Studio Code, у вас там сыпяцца памылкі кода і вы разумееце, што наогул немагчыма працаваць, вам адразу становіцца сумна і вы бяжыце правіць свой IDE.
Дакладна таксама ставіцеся да вашай інфраструктурнай платформы. Калі вы разумееце, што з ёй нешта не тое, пакідайце заяўку, калі не можаце паправіць самі. Калі ж там нешта простае - праўце самастойна, адпраўляйце pull request - хлопцы разглядаюць, дадаюць. Гэта некалькі іншы падыход да інжынернага інструментара ў галаве распрацоўніка.
Інфраструктурная платформа забяспечвае перанос артэфакта ад распрацоўкі кліенту з пастаянным павышэннем якасці.. У ІП запраграмаваны набор гісторый, якія здараюцца з кодам у прадакшн. За гады распрацоўкі гэтых гісторый становіцца вельмі шмат, частка з іх унікальныя і ставяцца толькі да вас - іх немагчыма нагугліць.
У гэты момант інфраструктурная платформа становіцца вашай канкурэнтнай перавагай., таму што ў яе зашыта тое, чаго няма ў інструменце канкурэнта. Чым глыбей ваша ІП, тым больш ваша канкурэнтная перавага ў сэнсе Time-to-market. Тут з'яўляецца праблема vendor lock: вы можаце ўзяць сабе чужую платформу, але выкарыстоўваючы чужы вопыт, вы не будзеце разумець, наколькі ён рэлевантны да вас. Так, не ўсякая кампанія можа пабудаваць платформу тыпу Амазона. Гэта складаная грань, дзе досвед кампаніі рэлевантны яе становішчу на рынку, і спускаць туды vendor lock нельга. Аб гэтым таксама важна падумаць.
схема
Гэта базавая схема інфраструктурнай платформы, якая дапаможа вам наладзіць усе практыкі і працэсы ў DevOps-кампаніі.
Разгледзім, з чаго яна складаецца.
Сістэма аркестрацыі рэсурсаў, якая дае CPU, памяць, дыск прыкладанням і іншым сэрвісам. Па-над гэтым - сэрвісы нізкага ўзроўню: маніторынг, лагіраванне, CI/CD Engine, сховішча артэфактаў, інфраструктура як код сістэмы.
Сэрвісы больш высокага ўзроўню: база дадзеных, як сэрвіс, чэргі як сэрвіс, Load Balance як сэрвіс, resizing карцінак як сэрвіс, Big Data фабрыка як сэрвіс. Па-над гэтым - пайплайн, які пастаўляе ўвесь час мадыфікаваны код вашаму кліенту.
Вы атрымліваеце інфармацыю аб тым, як ваша ПЗ працуе ў кліента, змяняеце, зноў пастаўляеце гэты код, атрымліваеце інфармацыю - і так пастаянна развіваеце і інфраструктурную платформу, і ваша ПЗ.
На схеме delivery pipeline складаецца з мноства стэйджаў. Але гэта прынцыповая схема, якая прыведзена для прыкладу - не трэба паўтараць яе адзін у адзін. Стейджы ўзаемадзейнічаюць з сэрвісамі, як з сэрвісамі - кожная цаглінка платформы нясе сваю гісторыю: як вылучаюцца рэсурсы, як прыкладанне запускаецца, працуе з рэсурсамі, маніторыцца, змяняецца.
Важна разумець, што кожная частка платформы нясе гісторыю, і пытаць сябе - якую гісторыю нясе гэты цаглінка, можа быць, яго варта выкінуць і замяніць іншым сэрвісам. Напрыклад, ці можна замест цаглінкі паставіць Okmeter? Магчыма, хлопцы ўжо прапампавалі гэтую экспертызу значна больш, чым мы. Але можа і не - магчыма, у нас ёсць унікальная экспертыза, нам трэба паставіць Prometheus і развіваць гэта далей.
Стварэнне платформы
Гэта складаны камунікацыйны працэс. Калі ў вас ёсць базавыя практыкі, вы запускаеце зносіны паміж рознымі інжынерамі і спецыялістамі, якія выпрацоўваюць патрабаванні і стандарты, і ўвесь час іх змяняюць да розных інструментаў і падыходам. Тут важная культура, якая ёсьць у DevOps.
З культурай усё вельмі проста - гэта супрацоўніцтва і камунікацыя, гэта значыць жаданне працаваць у агульным полі сябар з сябрам, жаданне валодаць адной прыладай разам. Тут няма ніякага rocket science усё вельмі проста, банальна. Напрыклад, мы ўсе жывем у пад'ездзе і падтрымліваем яго чысціню - такі ўзровень культуры.
А што ў вас?
Ізноў пытанні, якія вы можаце сабе задаць.
Ці выдзелена інфраструктурная платформа? Хто адказвае за яе развіццё? Ці разумееце вы канкурэнтныя перавагі сваёй інфраструктурнай платформы?
Гэтыя пытанні трэба ўвесь час сабе задаваць. Калі нешта можна вынесці на іншыя сэрвісы - трэба выносіць, калі іншы сэрвіс пачынае блакаваць ваш рух, то трэба будаваць сістэму ўнутры сябе.
Такім чынам, DevOps…
… гэта складаная сістэма, у ім павінны быць:
- Лічбавы прадукт.
- Бізнэс модулі, якія гэты лічбавы прадукт развіваюць.
- Прадуктовыя каманды, якія пішуць код.
- Практыкі Continuous Delivery.
- Платформы як сэрвіс.
- Інфраструктура як сэрвіс.
- Інфраструктура як код.
- Асобныя практыкі падтрымання надзейнасці, зашытыя ўнутры DevOps.
- Практыка зваротнай сувязі, якая апісвае ўсё гэта.
Можна выкарыстоўваць гэтую схему, падфарбаваўшы ў ёй тое, што ўжо ў вас у кампаніі ёсць у нейкім выглядзе: гэта развілося ці яшчэ трэба развіць.
Ужо праз пару тыдняў пройдзе . у складзе РИТ++. Прыходзьце на канферэнцыю, дзе вас чакае шмат крутых дакладаў пра бесперапынную пастаўку, інфраструктуру як код і DevOps-трансфармацыю. , апошні дэдлайн коштаў 20 траўня
Крыніца: habr.com