5 вештина које сваки ДевОпс инжењер треба да има

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

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

Као интегратор кода у аутоматизоване цевоводе, морате да знате бар основну функционалност различитих услуга у облаку.

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

Важне ДевОпс вештине

Извор: девопсуниверсити.орг

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

Ипак, они морају да буду у стању да инкорпорирају резултате тима у један изводљив цевовод за примену, заједно са извршавањем и валидацијом различитих аутоматизованих тестова.

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

Софт Скиллс

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

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

Умрежавање

Када погледате технолошки пејзаж модерних платформи у облаку, није потребно много да бисте се изгубили. Морате да се носите са услугама система датотека, вишеструким услугама базе података, позадинским АПИ-јима, серверским или серверским архитектурама, фронт-енд сервисима, моделима машинског учења, хибридним окружењима, виртуелним приватним мрежама, балансаторима оптерећења високе доступности, разним сервисима за стримовање у реалном времену и много више.

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

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

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

Уместо да се држите старих проверених контаката, морате стално да тражите нове да бисте покрили тај нови део услуге који је управо затражио ваш тим.

Тестови софтвера

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

Ако размишљате о целом животном циклусу пројекта који укључује планирање, процену, развој, тестирање и објављивање, то никако не можете постићи без озбиљне аутоматизације у што већем броју тих корака.

Главни предуслов успеха у овој поставци (и да се на крају омогући брже време за имплементацију у производњу) је велики фокус на аутоматизацији тестирања. Брже примене уз аутоматизоване тестове резултирају краћим временом за повратне информације корисника према програмерима.

За ДевОпс инжењера, то значи интеграцију излаза различитих тимова за тестирање у ЦИ/ЦД цевовод:

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

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

Пословни аналитичари или менаџери за осигурање квалитета могу бити део мреже (ако не и директно део тима) да помогну у томе и дефинишу тачне кораке. Али онда је улога ДевОпс инжењера да га преведе у аутоматизовани извршни код.

ЦИ/ЦД и инфраструктура као код

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

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

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

Али када се уради како треба, ту сте.

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

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

Контејнеризација

Извор: авс.амазон.цом

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

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

Контејнери су дизајнирани да се лако стварају и уништавају. Инжењери ДевОпс-а ће имплементирати алате за оркестрацију контејнера као што су Кубернетес или Доцкер Сварм, који могу аутоматски да управљају постављањем контејнера, скалирањем и опоравком.

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

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

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

Закључак

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

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

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

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

Затим погледајте често постављана питања и одговоре на ДевОпс интервјуу.