Тэма DevOps за апошнія некалькі год стала вельмі папулярнай. Многія мараць у яе ўліцца, але, як паказвае практыка, часта толькі з-за ўзроўню заробкаў.
Некаторыя паказваюць у сваім рэзюмэ DevOps, хаця не заўсёды ведаюць і разумеюць сутнасць тэрміна. Хтосьці лічыць, што вывучыўшы Ansible, GitLab, Jenkins, Terraform і ім падобныя (спіс можна працягваць на свой густ), то адразу стане "дэвопсам". Гэта, канешне, не так.
Некалькі апошніх гадоў я займаюся ў асноўным укараненнем DevOps у розных кампаніях. Да гэтага больш за 20 гадоў працаваў на пазіцыях ад сістэмнага адміністратара да IT-дырэктара. Цяпер – DevOps Lead Engineer ў Playgendary.
Хто такі DevOps
Ідэя напісаць артыкул узнікла пасля чарговага пытання: "хто такі DevOps?". Да гэтага часу няма ўстоянага тэрміна, што ці хто гэта. Частка адказаў ужо ёсць у гэтым . Спачатку вылучу галоўныя тэзы з яго, а затым падзялюся сваімі назіраннямі і думкамі.
DevOps – не спецыяліст, якога можна наняць, не набор утыліт, і не аддзел распрацоўшчыкаў з інжынерамі.
DevOps - гэта філасофія і метадалогія.
Іншымі словамі, гэта набор практык, які дапамагае актыўна ўзаемадзейнічаць распрацоўшчыкам з сістэмнымі адміністратарамі. Гэта значыць звязваць і інтэграваць працоўныя працэсы сябар у сябра.
З з'яўленнем DevOps структура і ролі спецыялістаў засталіся такімі ж (ёсць дэвелаперы, ёсць інжынеры), але змяніліся правілы ўзаемадзеяння. Размыліся межы паміж аддзеламі.
Мэты DevOps можна апісаць трыма пунктамі:
- Софт павінен абнаўляцца рэгулярна.
- Софт павінен рабіцца хутка.
- Софт павінен разгортвацца зручна і ў кароткія тэрміны.
У DevOps няма адзінай прылады. Наладзіць, паставіць і вывучыць некалькі прадуктаў – не значыць, што ў кампаніі з'явіўся DevOps. Інструментаў вельмі шмат і ўсё задзейнічаюцца на розных этапах, але служаць адной агульнай мэце.
І гэта толькі частка прылад DevOps
Ужо больш за 2 гады гутару людзей на пазіцыю DevOps-інжынера і да мяне прыйшло ўсведамленне, наколькі важна дакладна разумець сутнасць тэрміна. Назапасіўся спецыфічны досвед, назіранні і думкі, якімі жадаю падзяліцца.
З досведу гутарак я бачу такую карціну: у адмыслоўцаў, якія лічаць DevOps пасадай, звычайна ёсць непаразуменні з калегамі.
Быў яскравы прыклад. На сумоўе прыйшоў малады чалавек з кучай разумных слоў у рэзюмэ. На апошніх трох месцах працы ён меў стаж 5-6 месяцаў. З двух стартапаў сышоў, таму што "не ўзляцелі". А вось наконт трэцяй кампаніі сказаў, што там яго ніхто не разумее: распрацоўшчыкі пішуць код па Windows, а дырэктар прымушае гэты код "заварочваць" у звычайны Docker і ўбудоўваць у CI/CD-пайплайн. Хлопец шмат чаго негатыўнага распавёў з нагоды яго бягучага месца працы і яго калегах - так і хацелася адказаць: "Дык ты слана не прадасі".
Потым я задаў яму пытанне, якое ў маім спісе адно з першых для кожнага кандыдата.
- Што асабіста для цябе азначае DevOps?
- Наогул, ці як я гэта ўспрымаю?
Мяне цікавіла яго асабістае меркаванне. Ён ведаў тэорыю і паходжанне тэрміна, але быў катэгарычна з імі не згодзен. Ён лічыў, што DevOps - пасада. Тут і крыецца корань яго праблем. Як і іншых спецыялістаў з такім жа меркаваннем.
Працадаўцы, наслухаўшыся аб "магіі DevOps", хочуць знайсці чалавека, які прыйдзе і гэтую "магію" створыць. А суіскальнікі з разраду "DevOps - гэта пасада" не разумеюць, што пры такім падыходзе яны не змогуць апраўдаць чаканні. І, увогуле, напісалі ў сваім рэзюмэ DevOps, таму што гэта трэнд і за гэта шмат плацяць.
Метадалогія і філасофія DevOps
Метадалогія бывае тэарэтычнай і практычнай. У нашым выпадку - другое. Як я згадваў вышэй, DevOps - гэта набор практык і стратэгій, якія ўжываюцца для дасягнення заяўленых мэт. І ў кожным выпадку, у залежнасці ад бізнэс-працэсаў кампаніі, ён можа істотна адрознівацца. Што не робіць яго лепш ці горш.
Метадалогія DevOps - толькі сродак дасягнення пастаўленых мэт.
Цяпер аб тым, што такое філасофія DevOps. І гэта, мусіць, самае цяжкае пытанне.
Сфармуляваць кароткі і ёмісты адказ дастаткова складана, таму што ён яшчэ не фармалізаваны. І так як адэпты філасофіі DevOps больш займаюцца практыкай - на філасофстваванні проста няма часу. Тым не менш, гэта вельмі важны працэс. Прычым наўпрост які адносіцца да інжынернай дзейнасці. Ёсць нават спецыялізаваная вобласць пазнання - .
У маёй ВНУ такога прадмета не было, прыйшлося вывучаць усё самастойна па тых матэрыялах, якія змог знайсці ў 90-я. Тэма неабавязковая для інжынернай адукацыі, адсюль і адсутнасць фармалізацыі адказу. Але тыя людзі, якія сур'ёзна пагрузіліся ў DevOps, пачынаюць адчуваць нейкі "дух" ці "неўсвядомленую ўсёабдымнасць" усіх працэсаў кампаніі.
Я на сваім досведзе пастараўся фармалізаваць некаторыя "пастулаты" гэтай філасофіі. Атрымалася наступнае:
- DevOps не з'яўляецца чымсьці самастойным, што можна вылучыць у асобны кірунак ведаў ці дзейнасці.
- DevOps-метадалогіяй павінны кіравацца ўсе супрацоўнікі кампаніі плануючы сваю дзейнасць.
- DevOps закранае ўсе працэсы ўнутры кампаніі.
- DevOps існуе, каб змяншаць часавыя выдаткі на любыя працэсы ўнутры кампаніі для забеспячэння развіцця яе паслуг і максімальнага камфорту кліента.
- DevOps, сучаснай мовай, ёсць проактивная пазіцыя кожнага супрацоўніка кампаніі, накіраваная на зніжэнне часавых выдаткаў і паляпшэнне якасці навакольных нас IT-прадуктаў.
Думаю, што мае "пастулаты" гэта асобная тэма для абмеркавання. Але зараз ёсць ад чаго адштурхвацца.
Што робіць DevOps
Ключавое слова тут - камунікацыі. Вельмі шмат камунікацый, ініцыятарам якіх павінен быць якраз той самы DevOps-інжынер. Чаму так? Бо гэта філасофія і метадалогія, а ўжо потым інжынерныя веды.
Пра заходні рынак працы казаць са 100% упэўненасцю не магу. Але вось аб рынку DevOps у Расіі ведаю даволі шмат. Акрамя сотняў гутарак, за апошнія паўтара гады я ўдзельнічаў у сотні тэхнічных прэсейлаў па паслузе "Укараненне DevOps" для буйных расійскі кампаній і банкаў.
У Расіі DevOps яшчэ вельмі маладая, але ўжо трэндавая тэма. Наколькі я ведаю, толькі па Маскве дэфіцыт такіх спецыялістаў за 2019 год склаў больш за 1000 чалавек. А слова Kubernetes для працадаўцаў амаль як чырвоная ануча для быка. Адэпты гэтага інструмента гатовы выкарыстоўваць яго нават там, дзе гэта не трэба і эканамічна не выгадна. Працадаўца не заўсёды разумее ў якіх выпадках, што слушней выкарыстоўваць, а пры належным разгортванні ўтрыманне кластара Kubernetes варта ў 2-3 разу даражэй, чым разгортванне прыкладання па звычайнай кластарнай схеме. Выкарыстоўвайце яго там, дзе ён сапраўды патрэбен.
Укараненне DevOps з пункту гледжання грошай - дорага. І апраўдана толькі там, дзе прыносіць эканамічную выгаду ў іншых абласцях, а не само па сабе.
DevOps-інжынеры, фактычна, першапраходцы – менавіта яны першымі павінны ўкараняць у кампаніі гэтую метадалогію і выбудоўваць працэсы. Каб гэта было паспяхова, спецыяліст павінен увесь час узаемадзейнічаць з супрацоўнікамі і калегамі на ўсіх узроўнях. Як я звычайна кажу, у працэс укаранення DevOps павінны быць уцягнуты ўсе супрацоўнікі кампаніі: ад прыбіральшчыцы да CEO. І гэта абавязковая ўмова. Калі самы малодшы чалец каманды не будзе ведаць і разумець, што такое DevOps і навошта выконваюцца тыя ці іншыя арганізацыйныя дзеянні, то паспяховага ўкаранення не атрымаецца.
Таксама DevOps-інжынеру трэба час ад часу выкарыстоўваць адміністрацыйны рэсурс. Напрыклад, для пераадолення "супраціву асяроддзя" - калі каманда не гатовая прыняць інструменты і метадалогію DevOps.
Распрацоўнік павінен пісаць толькі код і тэсты. Для гэтага яму не патрэбен супермагутны наўтбук, на якім ён будзе разгортваць і падтрымліваць лакальна ўсю інфраструктуру праекту. Напрыклад, франтэндэр трымае ў сябе на наўтбуку ўсе элементы прыкладання, уключаючы базу дадзеных, эмулятар S3 (minio) і іншае. Гэта значыць марнуе шмат часу на падтрыманне гэтай лакальнай інфраструктуры і ў адзіночку дужаецца са ўсімі праблемамі такога рашэння. Замест таго, каб распрацоўваць код для фронта. Такія людзі могуць моцна супраціўляцца любым зменам.
Але ёсць каманды, якія, наадварот, рады ўкараненню новых інструментаў і метадаў, і жыва ўдзельнічаюць у гэтым працэсе. Хаця нават у такім выпадку камунікацыі паміж DevOps-інжынерам і камандай ніхто не адмяняў.
Калі DevOps не патрэбен
Бываюць сітуацыі, калі DevOps не патрэбен. Гэта факт - яго трэба зразумець і прыняць.
У першую чаргу, гэта датычыцца любых кампаній (асабліва малога бізнесу), калі іх прыбытак не залежыць напрамую ад наяўнасці або адсутнасці IT-прадуктаў, якія прадстаўляюць інфармацыйныя сэрвісы кліентам. І тут гаворка не аб сайце кампаніі, будзь ён статычнай "візітоўкай" або з дынамічнымі блокамі навін і т.п.
DevOps патрабуецца, калі ад наяўнасці гэтых інфармацыйных сэрвісаў па ўзаемадзеянні з кліентам, іх якасці і таргетаванасці залежыць задаволенасць вашага кліента і яго жаданне зноў вяртацца менавіта да вас.
Яскравым прыкладам з'яўляецца адзін вядомы банк. У кампаніі няма звыклых кліенцкіх офісаў, дакументазварот ажыццяўляецца праз пошту ці кур'ераў, а мноства супрацоўнікаў працуе з дому. Кампанія перастала быць проста банкам і, на мой погляд, ператварылася ў IT-кампанію з развітымі DevOps-тэхналогіямі.
Шмат іншых прыкладаў і лекцый можна знайсці ў запісах тэматычных мітапаў і канферэнцый. Частку з іх я наведаў асабіста - гэта вельмі карысны вопыт для тых, хто хоча развівацца ў гэтым напрамку. Вось спасылкі на YouTube-каналы з добрымі лекцыямі і матэрыяламі па DevOps:
Цяпер паглядзіце на свой бізнэс і падумайце вось пра што: як моцна ваша кампанія і яе прыбытак залежаць ад IT-прадуктаў, якія забяспечваюць узаемадзеянне з кліентам?
Калі ваша кампанія гандлюе рыбай у невялікай крамцы і адзіным IT-прадуктам з'яўляюцца дзве канфігурацыі 1С: Прадпрыемства (Бухгалтэрыя і УНФ), то ці наўрад ёсць сэнс казаць аб DevOps.
Калі ж вы працуеце на буйным гандлёвым і вытворчым прадпрыемстве (напрыклад, робіце паляўнічыя стрэльбы), то варта задумацца. Вы можаце праявіць ініцыятыву і данесці свайму кіраўніцтву перспектывы ўкаранення DevOps. Ну, і заадно, узначаліць гэты працэс. Праактыўная пазіцыя - адзін з важных пастулатаў філасофіі DevOps.
Памер і аб'ём гадавога фінансавага абароту не з'яўляецца асноўным крытэрам для вызначэння, ці патрэбен вашай кампаніі DevOps.
Уявім сабе буйное прамысловае прадпрыемства, якое не ўзаемадзейнічае напрамую з кліентамі. Напрыклад, некаторыя аўтаканцэрны і аўтамабілебудаўнічыя кампаніі. Цяпер не ўпэўнены, але, з майго мінулага досведу, шмат гадоў усё ўзаемадзеянне з кліентамі ажыццяўлялася па электроннай пошце і тэлефоне.
Іх кліенты - гэта абмежаваны спіс аўтамабільных дылераў. І да кожнага прымацаваны спецыяліст ад вытворцы. Увесь унутраны дакументаабарот адбываецца праз ERP SAP. Унутраныя супрацоўнікі, па сутнасці, з'яўляюцца кліентамі інфармацыйнай сістэмы. Але кіраванне гэтай ІС ажыццяўляецца класічнымі сродкамі кіравання кластарнымі сістэмамі. Што выключае магчымасць выкарыстання практык DevOps.
Адгэтуль выснова: для падобных прадпрыемстваў укараненне DevOps не з'яўляецца нечым крытычна важным, калі ўспомніць мэты метадалогіі з пачатку артыкула. Але не выняткоўваю, што нейкія прылады DevOps выкарыстоўваюцца імі сёння.
З іншага боку, ёсьць шмат невялікіх кампаній, якія распрацоўваюць праграмнае забеспячэнне з выкарыстаннем метадалогіі, філасофіі, практык і інструментаў DevOps. І лічаць, што выдаткі на ўкараненне DevOps з'яўляюцца выдаткамі, якія дазваляюць ім эфектыўна канкураваць на рынку ПЗ. Прыклады такіх кампаній можна ўбачыць .
Асноўны крытэр для разумення ці патрэбен DevOps: якое значэнне вашыя IT-прадукты маюць для кампаніі і кліентаў.
Калі асноўны прадукт кампаніі, які прыносіць прыбытак, гэта ПЗ – вам патрэбен DevOps. І не так важна, калі зарабляеце рэальныя грошы вы з дапамогай іншых тавараў. Сюды таксама можна аднесці інтэрнэт-крамы ці мабільныя прыкладанні з гульнямі.
Любыя гульні існуюць дзякуючы фінансаванню: прамому ці ўскоснаму з боку гульцоў. У Playgendary мы распрацоўваем бясплатныя мабільныя гульні, у непасрэдным стварэнні якіх удзельнічаюць больш за 200 чалавек. Як мы выкарыстоўваем DevOps?
Ды сапраўды таксама, як апісана вышэй. Я ўвесь час маю зносіны з распрацоўшчыкамі і тэсціроўшчыкамі, праводжу ўнутранае навучанне супрацоўнікаў метадалогіі і інструментам DevOps.
Цяпер у нас актыўна выкарыстоўваецца Jenkins як прылада CI/CD pipelines для выканання ўсіх зборачных канвеераў з Unity і наступнага дэплою ў App Store і Play Market. Яшчэ з класічнага набору прылад:
- Asana - для кіравання праектамі. Настроена інтэграцыя з Jenkins.
- Google Meet - для правядзення відэасустрэч.
- Slack - для камунікацый і розных абвестак, уключаючы натыфікацыі з Jenkins.
- Atlassian Confluence - для дакументавання і групавой працы.
У бліжэйшых планах укараніць статычны аналіз кода з дапамогай SonarQube і правесці аўтаматызаванае UI-тэставанне сродкамі Selenium на этапе Continuous Integration.
замест заключэння
Жадаю скончыць наступнай думкай: каб стаць DevOps-інжынерам высокай кваліфікацыі, жыццёва неабходна навучыцца жывым зносінам з людзьмі.
DevOps-інжынер - камандны гулец. І ніяк інакш. Ініцыятыва ў зносінах з калегамі павінна зыходзіць ад яго самога, а не пад уздзеяннем нейкіх абставін. DevOps-спецыяліст павінен убачыць і прапанаваць найлепшае рашэнне для каманды.
І так, укараненне любога рашэння запатрабуе мноства абмеркаванняў, а да канца можа ўвогуле змяніцца. Самастойна развіваючыся, прапаноўваючы і ажыццяўляючы свае задумкі - такі чалавек уяўляе ўсё большую каштоўнасць як для каманды, так і для працадаўцы. Што, у канчатковым рахунку, адбіваецца і на памеры яго штомесячнага ўзнагароджання або ў выглядзе дадатковых прэмій.
Крыніца: habr.com