Зашто је ДевОпс потребан и ко су стручњаци за ДевОпс?

Када апликација не ради, последња ствар коју желите да чујете од својих колега је фраза „проблем је на вашој страни“. Као резултат тога, корисници пате - и није их брига који део тима је одговоран за квар. ДевОпс култура се појавила управо да споји развој и подршку око заједничке одговорности за крајњи производ.

Које праксе су укључене у концепт ДевОпс-а и зашто су потребне? Шта раде инжењери ДевОпс-а и шта би требало да буду у стању да ураде? Стручњаци из ЕПАМ-а одговарају на ова и друга питања: Кирил Сергејев, системски инжењер и ДевОпс еванђелиста, и Игор Бојко, водећи системски инжењер и координатор једног од ДевОпс тимова компаније.

Зашто је ДевОпс потребан и ко су стручњаци за ДевОпс?

Зашто је ДевОпс потребан?

Раније је постојала баријера између програмера и подршке (тзв. операције). Звучи парадоксално, али они су имали различите циљеве и КПИ, иако су радили исту ствар. Циљ развоја је био што брже имплементирати пословне захтеве и додати их у радни производ. Подршка је била одговорна да обезбеди да апликација ради стабилно - а све промене су довеле стабилност у опасност. Постоји сукоб интереса - ДевОпс се појавио да га реши.

Шта је ДевОпс?

То је добро питање - и контроверзно: свет се још није коначно сложио око овога. ЕПАМ верује да ДевОпс комбинује технологије, процесе и културу интеракције унутар тима. Ово удружење има за циљ да континуирано испоручује вредност крајњим корисницима.

Кирил Сергејев: „Програмери пишу код, тестери га прегледају, а администратори постављају финални производ у производњу. Дуго су ови делови тима били помало разбацани, а онда се јавила идеја да се уједине кроз заједнички процес. Тако су се појавиле ДевОпс праксе.”

Дошао је дан када су се програмери и системски инжењери заинтересовали за рад једни других. Почела је да нестаје баријера између производње и подршке. Тако је настао ДевОпс, који укључује праксе, културу и тимску интеракцију.

Зашто је ДевОпс потребан и ко су стручњаци за ДевОпс?

Шта је суштина ДевОпс културе?

Чињеница је да одговорност за коначни резултат лежи на сваком члану тима. Најзанимљивија и најтежа ствар у филозофији ДевОпс-а је схватити да одређена особа није одговорна само за своју фазу рада, већ је одговорна за то како ће цео производ функционисати. Проблем не лежи ни на чијој страни – он се дели, а сваки члан тима помаже да се реши.

Најважнија ствар у ДевОпс култури је решавање проблема, а не само примена ДевОпс пракси. Штавише, ове праксе се не примењују „на нечијој страни“, већ у целом производу. Пројекту није потребан ДевОпс инжењер сам по себи – потребно му је решење проблема, а улога ДевОпс инжењера може бити распоређена на неколико чланова тима са различитим специјализацијама.

Које су врсте ДевОпс пракси?

ДевОпс праксе покривају све фазе животног циклуса софтвера.

Игор Бојко: „Идеалан случај је када почнемо да користимо ДевОпс праксе одмах на почетку пројекта. Заједно са архитектама планирамо какав ће архитектонски пејзаж апликација имати, где ће се налазити и како да се скалира, и бирамо платформу. Данас је микросервисна архитектура у моди – за њу бирамо систем оркестрације: потребно је да будете у могућности да управљате сваким елементом апликације посебно и да га ажурирате независно од осталих. Друга пракса је „инфраструктура као код“. Ово је назив за приступ у којем се инфраструктура пројекта креира и управља помоћу кода, а не кроз директну интеракцију са серверима.

Затим прелазимо на фазу развоја. Једна од највећих пракси овде је прављење ЦИ/ЦД-а: потребно је да помогнете програмерима да интегришу промене у производ брзо, у малим порцијама, чешће и безболније. ЦИ/ЦД покрива преглед кода, отпремање мастера у базу кода и примену апликације у окружења за тестирање и производњу.

На ЦИ/ЦД фазама, код пролази кроз капије квалитета. Уз њихову помоћ, они проверавају да ли код који излази са радне станице програмера испуњава наведене критеријуме квалитета. Овде је додато тестирање јединица и корисничког интерфејса. За брзу, безболну и фокусирану примену производа, можете одабрати одговарајући тип примене.

ДевОпс практичари такође имају место у фази подршке готовом производу. Користе се за праћење, повратне информације, безбедност и увођење промена. ДевОпс посматра све ове задатке из перспективе континуираног побољшања. Минимизирамо операције које се понављају и аутоматизујемо их. Ово такође укључује миграције, проширење апликација и подршку за перформансе."

Које су предности ДевОпс пракси?

Ако бисмо писали уџбеник о савременим ДевОпс праксама, на првој страници би биле три тачке: аутоматизација, убрзавање издања и брзе повратне информације од корисника.

Кирил Сергејев: „Прва ствар је аутоматизација. Можемо да аутоматизујемо све интеракције у тиму: написали код - увели га - проверили - инсталирали - прикупили повратне информације - вратили се на почетак. Све ово је аутоматски.

Други је убрзање издавања и чак поједностављење развоја. За купца је увек важно да производ уђе на тржиште што је пре могуће и почне да пружа предности раније од аналога конкурената. Процес испоруке производа може се бескрајно побољшати: смањити време, додати додатне контролне ознаке, побољшати праћење.

Треће је убрзање повратних информација корисника. Ако има коментаре, можемо одмах да извршимо прилагођавања и одмах ажурирамо апликацију.”

Зашто је ДевОпс потребан и ко су стручњаци за ДевОпс?

Како су повезани концепти „инжењер система“, „инжењер изградње“ и „ДевОпс инжењер“?

Они се преклапају, али припадају мало различитим областима.

Системски инжењер у ЕПАМ-у је позиција. Долазе на различитим нивоима: од јуниора до главног специјалисте.

Грађевински инжењер је више улога која се може обављати на пројекту. Сада се тако зову људи одговорни за ЦИ/ЦД.

ДевОпс инжењер је специјалиста који примењује ДевОпс праксе на пројекту.

Ако све сумирамо, добијамо нешто овако: особа на позицији системског инжењера игра улогу инжењера изградње на пројекту и тамо је укључена у имплементацију ДевОпс пракси.

Шта тачно ради ДевОпс инжењер?

ДевОпс инжењери састављају све делове који чине пројекат. Они познају специфичности рада програмера, тестера, систем администратора и помажу у поједностављивању њиховог рада. Они разумеју потребе и захтеве пословања, његову улогу у процесу развоја – и граде процес узимајући у обзир интересе купаца.

Много смо разговарали о аутоматизацији - то је оно чиме се ДевОпс инжењери баве пре свега. Ово је веома велика тачка, која, између осталог, укључује и припрему животне средине.

Кирил Сергејев: „Пре имплементације ажурирања у производ, потребно их је тестирати у окружењу треће стране. Припремају га ДевОпс инжењери. Они усађују ДевОпс културу на пројекат у целини: уводе ДевОпс праксе на свим слојевима својих пројеката. Ова три принципа: аутоматизација, поједностављење, убрзање – они доносе свуда где могу да достигну.”

Шта ДевОпс инжењер треба да зна?

Углавном, мора имати знања из различитих области: програмирања, рада са оперативним системима, базама података, монтажним и конфигурационим системима. Они су допуњени способношћу рада са инфраструктуром у облаку, оркестрацијом и системима за праћење.

1. Програмски језици

ДевОпс инжењери знају неколико основних језика за аутоматизацију и могу, на пример, да кажу програмеру: „Како би било да инсталирате код не ручно, већ помоћу наше скрипте, која све аутоматизује? Припремићемо конфигурациони фајл за њега, биће згодно и вама и нама за читање и моћи ћемо да га променимо у било ком тренутку. Такође ћемо видети ко, када и зашто то мења.”

ДевОпс инжењер може да научи један или више од ових језика: Питхон, Гроови, Басх, Поверсхелл, Руби, Го. Није неопходно да их познајете на дубоком нивоу - довољни су основе синтаксе, принципи ООП-а и способност писања једноставних скрипти за аутоматизацију.

2. Оперативни системи

ДевОпс инжењер мора да разуме на ком серверу ће производ бити инсталиран, у ком окружењу ће радити и са којим услугама ће комуницирати. Можете одабрати да се специјализујете за Виндовс или Линук породицу.

3. Системи контроле верзија

Без знања о систему контроле верзија, ДевОпс инжењер је нигде. Гит је један од најпопуларнијих система у овом тренутку.

4. Цлоуд провајдери

АВС, Гоогле, Азуре – посебно ако говоримо о Виндовс правцу.

Кирил Сергејев: „Провајдери у облаку нам пружају виртуелне сервере који се савршено уклапају у ЦИ/ЦД.

Инсталирање десет физичких сервера захтева око стотину ручних операција. Сваки сервер мора бити ручно покренут, инсталиран и конфигурисан потребан оперативни систем, инсталирана наша апликација на ових десет сервера, а затим десет пута све проверити. Услуге у облаку замењују ову процедуру са десет линија кода, а добар ДевОпс инжењер би требало да буде у стању да ради са њима. Ово штеди време, труд и новац – и за купца и за компанију.”

5. Системи оркестрације: Доцкер и Кубернетес

Кирил Сергејев: „Виртуелни сервери су подељени у контејнере, у сваки од којих можемо да инсталирамо нашу апликацију. Када има пуно контејнера, морате да управљате њима: укључите један, искључите други, направите резервне копије негде. Ово постаје прилично сложено и захтева систем оркестрације.

Раније је сваком апликацијом управљао посебан сервер - све промене у њеном раду могле су да утичу на употребљивост апликације. Захваљујући контејнерима, апликације постају изоловане и раде одвојено – свака на својој виртуелној машини. Ако дође до квара, нема потребе да губите време тражећи узрок. Лакше је уништити стари контејнер и додати нови."

6. Системи конфигурације: Цхеф, Ансибле, Пуппет

Када треба да одржавате читаву флоту сервера, морате да урадите много операција исте врсте. Дуг је и тежак, а ручни рад такође повећава шансу за грешку. Ту у помоћ прискачу конфигурациони системи. Уз њихову помоћ, они креирају скрипту која је лака за читање за програмере, ДевОпс инжењере и систем администраторе. Ова скрипта помаже да се исте операције на серверима изврше аутоматски. Ово смањује ручне операције (а самим тим и грешке).

Какву каријеру ДевОпс инжењер може да изгради?

Можете се развијати и хоризонтално и вертикално.

Игор Бојко: „Са тачке гледишта хоризонталног развоја, ДевОпс инжењери сада имају најширу перспективу. Све се стално мења, а вештине можете изградити у разним областима: од система контроле верзија до надгледања, од управљања конфигурацијом до база података.

Можете постати системски архитекта ако је запослени заинтересован да разуме како апликација функционише у свим фазама њеног животног циклуса – од развоја до подршке.”

Како постати ДевОпс инжењер?

  1. Прочитајте Тхе Пхоеник Пројецт и ДевОпс Хандбоок. Ово су прави стубови ДевОпс филозофије, а први је дело фикције.
  2. Научите технологије са горње листе: сами или путем онлајн курсева.
  3. Придружите се као ДевОпс инжењер за пројекат отвореног кода.
  4. Вежбајте и нудите ДевОпс праксе на својим личним и радним пројектима.

Извор: ввв.хабр.цом

Додај коментар