Шта је потребно да би ИТ компанија била успешна у 2019. Предавачи на конференцијама и скуповима говоре много гласних речи које нису увек разумљиве нормалним људима. Борба за време примене, микросервис, напуштање монолита, ДевОпс трансформација и још много, много више. Ако одбацимо вербалну лепоту и говоримо директно и на руском, онда се све своди на једноставну тезу: направите производ високог квалитета, и радите то са удобношћу за тим.
Ово последње је постало критично важно. Бизнис је коначно дошао до закључка да удобан процес развоја повећава продуктивност, а ако је све отклоњено и ради као сат, то даје и простор за маневар у критичним ситуацијама. Некада је, зарад овог маневра, нека паметна особа смислила резервне копије, али индустрија се развија и дошли смо до ДевОпс инжењера – људи који процес интеракције између развоја и екстерне инфраструктуре претварају у нешто адекватно и није везано за шаманизам.
Цела ова „модуларна“ прича је дивна, али... Тако се десило да су неки од администратора нагло названи ДевОпс, а од самих ДевОпс инжењера се почело захтевати да поседују барем вештине телепатије и видовитости.
Пре него што говоримо о савременим проблемима обезбеђивања инфраструктуре, хајде да дефинишемо шта подразумевамо под овим појмом. У садашњем тренутку ситуација се тако развила да смо дошли до дуалности овог концепта: инфраструктура може бити условно спољашња и условно унутрашња.
Под екстерном инфраструктуром подразумевамо све оно што обезбеђује функционалност услуге или производа који тим развија. То су сервери апликација или веб локација, хостинг и друге услуге које обезбеђују функционалност производа.
Интерна инфраструктура обухвата услуге и опрему коју користи сам развојни тим и други запослени, којих је обично много. То су интерни сервери система за складиштење кодова, локално распоређени менаџер задатака и све, све, све што постоји унутар корпоративног интранета.
Шта ради систем администратор у компанији? Поред рада на администрирању овог корпоративног интранета, он често сноси терет економских брига како би се осигурала оперативност канцеларијске опреме. Администратор је исти тип који ће брзо извући нову системску јединицу или резервни лаптоп спреман за употребу из задње собе, дати нову тастатуру и пузати на све четири кроз канцеларије, протежући Етхернет кабл. Администратор је локални власник и владар не само интерних и екстерних сервера, већ и извршни директор. Да, неки администратори могу да раде само у системској равни, без хардвера. Требало би да буду одвојени у посебну подкласу „администратора система инфраструктуре“. А неки се специјализују за сервисирање искључиво канцеларијске опреме; срећом, ако компанија има више од сто људи, посао никада не престаје. Али ниједан од њих није девопс.
Ко су ДевОпс? Девопс су момци који говоре о интеракцији развоја софтвера са спољном инфраструктуром. Тачније, модерни девопси су укључени у процесе развоја и примене много дубље него што су икада били укључени администратори који су једноставно отпремали ажурирања на фтп. Један од кључних задатака ДевОпс инжењера сада је да обезбеди удобан и ефикасно структуриран процес интеракције између развојних тимова и инфраструктуре производа. Управо су ови људи одговорни за примену система за враћање и имплементацију; управо ти људи преузимају део терета са програмера и максимално се концентришу на свој изузетно важан задатак. У исто време, девопс никада неће покренути нови кабл или издати нови лаптоп из задње собе (ц) КО
Шта је цака?
На питање „Ко је ДевОпс?“ половина радника на терену почиње да одговара нешто попут „Па, укратко, ово је админ који...“ и даље у тексту. Да, некада, када је професија ДевОпс инжењера тек излазила од најталентованијих администратора у погледу одржавања сервиса, разлике међу њима нису биле очигледне свима. Али сада, када су функције девопса и администратора у тиму постале радикално различите, неприхватљиво је мешати их једни с другима, па чак и изједначавати.
Али шта ово значи за посао?
Запошљавање, све је о томе.
Отварате конкурс за „Системског администратора“, а ту су наведени услови „интеракција са развојем и купцима“, „систем за испоруку ЦИ/ЦД-а“, „одржавање сервера и опреме компаније“, „администрација интерних система“ итд. на; разумете да послодавац прича глупости. Квака је у томе што би уместо „Системски администратор“ упражњено радно место требало да буде „ДевОпс инжењер“, а ако се ово звање промени, онда све долази на своје место.
Међутим, какав утисак се стиче када се чита такав конкурс? Да компанија тражи оператера са више машина који ће поставити и систем за контролу верзија и систем за праћење и који ће зубима стискати твистер...
Али да се не би повећао степен зависности од дрога на тржишту рада, довољно је назвати слободна радна места правим именом и јасно разумети да су ДевОпс инжењер и систем администратор два различита субјекта. Али незадржива жеља неких послодаваца да кандидату предоче најширу могућу листу захтева доводи до тога да „класични“ систем администратори престају да разумеју шта се дешава око њих. Шта, струка мутира а они су у заостатку за временом?
Не не и још једном не. Администратори инфраструктуре који ће управљати интерним серверима компаније, или заузимати Л2/Л3 позиције подршке и помагати другим запосленима, нису отишли и неће отићи.
Могу ли ови стручњаци постати ДевОпс инжењери? Наравно да могу. У ствари, ово је повезано окружење које захтева вештине системске администрације, али поред овога, додаје се рад са системима за праћење, испоруку и, уопште, блиска интеракција са тимом за развој и тестирање.
Још један ДевОпс проблем
У ствари, све није ограничено само на запошљавање и сталну конфузију између администратора и девопса. У неком тренутку, посао се суочио са проблемом испорука ажурирања и интеракције развојног тима са коначном инфраструктуром.
Можда је то било када је ујак светлуцавих очију устао на бину неке конференције и рекао: „Ми ово радимо и зовемо то ДевОпс. Ови момци ће решити све ваше проблеме” – и почео да прича колико је добар живот у компанији након имплементације ДевОпс пракси.
Међутим, није довољно унајмити ДевОпс инжењера да би све функционисало како треба. Компанија мора да прође потпуну ДевОпс трансформацију, то јест, улога и могућности нашег ДевОпс-а такође морају бити јасно схваћене на страни тима за развој и тестирање производа. Имамо „дивну“ причу на ову тему која у потпуности илуструје сву бруталност која се дешава на неким местима.
Ситуација. ДевОпс је неопходан за примену система за враћање верзије без да се заиста удубљује у то како ће он функционисати. Претпоставимо да у систему Корисници постоје посебна поља за име, презиме и лозинку. Излази нова верзија производа, али за програмере, „повратак“ је само чаробни штапић који ће све поправити, а они ни не знају како то функционише. Тако су, на пример, у следећој закрпи програмери комбиновали поља за име и презиме, пустили га у производњу, али верзија је из неког разлога спора. Шта се дешава? Менаџмент долази у девопс и каже „Повуци прекидач!“, односно тражи од њега да се врати на претходну верзију. Шта девопс ради? Враћа се на претходну верзију, али пошто програмери нису желели да схвате како је ово враћање урађено, нико није рекао девопс тиму да је потребно вратити и базу података. Као резултат, све нам се руши, а уместо спорог веб сајта, корисници виде грешку „500“, јер стара верзија не ради са пољима нове базе података. Девопс не зна за ово. Програмери ћуте. Менаџмент почиње да губи живце и новац и сећа се резервних копија, нудећи да се повуче са њих како би „бар нешто успело“. Као резултат, корисници губе све своје податке током одређеног временског периода.
Ораси, наравно, иду у девопс, који „није направио одговарајући систем враћања,“ и никог није брига што су лосови у овој причи програмери.
Закључак је једноставан: без нормалног приступа ДевОпс-у као таквом, он је од мале користи.
Главна ствар коју треба запамтити: ДевОпс инжењер није мађионичар, а без квалитетне комуникације и двосмерне интеракције са развојем, неће се носити са својим задацима. Програмери не могу да буду остављени сами са својим „проблемима“ или да им дају команду „не петљајте се са програмерима, њихов посао је да кодирају“, а затим се надају да ће у критичном тренутку све функционисати како треба. То не ради тако.
У суштини, ДевОпс је компетенција на граници између менаџмента и технологије. Штавише, далеко је од очигледног да би у овом коктелу требало да буде више технологије него менаџмента. Ако заиста желите да изградите брже и ефикасније развојне процесе, морате веровати свом девопс тиму. Познаје праве алате, реализовао је сличне пројекте, зна како се то ради. Помозите му, послушајте његов савет, не покушавајте да га изолујете у некакву аутономну јединицу. Ако администратори могу да раде сами, онда су девопси у овом случају бескорисни; неће моћи да вам помогну да постанете бољи ако сами не желите да прихватите ову помоћ.
И последња ствар: престаните да вређате администраторе инфраструктуре. Они имају свој, изузетно важан фронт рада. Да, администратор може постати ДевОпс инжењер, али то би требало да се деси на захтев саме особе, а не под притиском. И нема ништа лоше у томе што администратор система жели да остане систем администратор - то је његова посебна професија и његово право. Ако желите да прођете кроз професионалну трансформацију, онда никада не смете заборавити да ћете морати да изградите не само технолошке вештине, већ и менаџерске. Највероватније ће на вама као лидеру бити да спојите све ове људе и научите их да комуницирају на истом језику.
Извор: ввв.хабр.цом