Centric Talks. Kas yra DevOps inžinierius ir kokią vertę jis kuria įmonėje (1 dalis)

Kas yra DevOps inžinierius ir kokią vertę jis kuria įmonėje (1 dalis)

Sveiki, esame „Centric IT Solutions Lithuania“ ofise Kaune. Prie mikrofono Tadas Jarockas, „Centric IT“ operacijų vadovas. Šiandien mes pradedam podcastų ciklą apie informacines technologijas, kurių metu mes kalbėsimės su IT ekspertais įvairiomis temomis.

Pirmasis ciklo podcastas yra skirtas aptarti IT pasaulyje dažnai girdimą ir linksniuojamą temą, t.y., „Development Operations“ arba trumpiau DevOps. Daugelis esame tikrai girdėję šį terminą ir turbūt teisinga pasakyti, kad šia tema interpretacijų yra begalė.

Daugelis kalbintų labai įvairiai, skirtingai supranta šią temą ir džiaugiuosi galėdamas kalbinti šiandien podcasto dalyvius – mano kolegą, „Centric IT Solutions Lithuania“ sprendimų architektą Glebą Cymliakov.

Sveikas.

Sveiki, ačiū, kad pakvietėt.

Ir „Centric“ svečias, DevOps evangelistas Tomas Stankevičius prie antro mikrofono.

Sveiki. Noriu paminėti, kad neseniai ir aš buvau jūsų kolega.

Taip. Kartu mes pabandysime pasigilinti, kas yra tie mistiniai DevOps ir išsklaidyti bent keletą mitų, kurių apie juos tikrai yra daug. Poreikis šiai temai iškilo tuomet, kai mes Kaune, „Centric IT Solutions Lithuania“ įsteigėme DevOps operacijų padalinį ir staiga supratome, kad daugelio specialistų galvose DevOps apibrėžimas yra labai stipriai išsiskaidęs, labai platus. Visgi, kas yra tas DevOps taip, kaip suprantate jūs?

Visų pirma, galbūt reikėtų pridėti ir patvirtinti, kad dabar DevOps supratimas yra labai platus ir kiekvienoje įmonėje, ir kiekvieno žmogaus galvoje jis visiškai kitaip suprantamas. Tam labai nepadeda, kad žmonės, bent jau įmonės iki šiol, labai vaikosi DevOps vien dėl mados. Nes tai šiuo metu yra labai madinga, labai pelninga, iš tikrųjų. Visi stengiasi dabar būti DevOps‘ais, nes žino, kad už tai moka pinigų. O įmonės tuo pačiu, jeigu jau dabar net nedirba su DevOps, gaunasi kaip ir atsiliekančios nuo mados ir neprestižinės. Jos tikrai irgi stengiasi daryti DevOps. Žodžiu, visi šoka į tą DevOps traukinį, bet deja, neįsigilina kas tai tiksliai yra. Tikrai norėčiau pritarti, kad samprata labai plati. Kas tai yra iš tikrųjų, geriausiai turbūt būtų pasižiūrėti ir pasigilinti iš pačių DevOps kūrėjų, kurie tai sukūrė, t.y., Andrew CLay Shafer ir Patrick Debois. Jie kartu 2008 metais susitiko vienoje iš konferencijų, pradėjo apie tai šnekėti ir tai sukūrė. Susikūrimo idėja, apskritai, gavosi komiška, nes Patrick Debois sugalvojo, kad jis turi labai daug bėdų su savo infrastruktūrom, nes jis aptarnavo nemažai programuotojų. Kiekvienas programuotojas norėdavo turėti kažkokią savo „development environment“ ir visą laiką ateidavo pas jį to prašyti. Jis, žinoma, stengdavosi padėti, bet visur nesuspėsi. Ir tuo labiau, kad tuo laiku visos automatizacijos kaip ir nebuvo. Jis tiesiog nusprendė, kad reikia apie šią temą pakalbėti, išsiskųsti ir paieškoti bendraminčių, kurie galbūt jau turi sprendimą šiam reikalui. Ir būtent jis paskelbė, kad dalyvauja konferencijoje „Azure Infrastructure“, tiksliau jis savo temą tokią pristatinėjo ir į tą konferenciją, tai temai reikėjo prisiregistruoti. Kadangi buvo limituotas vietų skaičius, tai, kad žinotų, kiek žmonių ateis, jie prašė prisiregistruoti. Ir į jo temą neprisiregistravo niekas. Jis pamatė, kad tai niekam neįdomu ir į tą savo temą netgi pats neatėjo. Patrick Debois buvo vienintelis žmogus, kuris į tą temą nuėjo ir jis nieko nerado. Tuščia. Netgi pačio pranešėjo nerado. Tačiau jis rankų nenuleido, su juo susitiko koridoriuje. Jie pradėjo apie tai šnekėtis ir nutarė, kad jiems abiem tai yra aktuali tema. Jie susitarė, kad jie tai vystys ir bandys skleisti per daugiau įmonių, per pasaulį. Ir jau sekančiais metais, 2009 m., jie įkūrė pačią pirmą konferenciją. Kadangi jie kūrė konferenciją, nežinojo, ką dabar kviesti, kam ta konferencija skirta. Sako gerai: „Developeriams“, nes mes vis dėlto jiems statom „environmentus“ ar vis dėl to kviečiam „operationus“. Sako: „o kodėl tada ne kartu juos visus?“ Nuo to ir prasidėjo. Tai ir buvo pirmoji konferencija, kuri ir vadinosi „DevOps Days“. Nuo to „DevOps“ ir prasidėjo.

Tai, ką dabar papasakojo Tomas buvo atvaizduotas priešdevopsinis pasaulis, kai „developmentas“, tai yra programinės įrangos kūrėjai ir „operationai“, tai yra tie žmonės, kurie vėliau tą veikiančią programinę įrangą prižiūri, buvo, ir daugeliu atveju dabar, yra atskiri pasauliai. Jie vienas su kitu mažai bendrauja, labai dažnai dargi vienas kitą kaltina dėl būtų ir nebūtų dalykų. Kokios tos problemos buvo ir kokios jos dar ir dabar išlieka, kurias DevOps požiūris ar kultūra galbūt gali spręsti?

Aš manau klasikinis atvejis, kurį bandė spręsti DevOps buvo būtent metimas iš vienos tvoros pusės į kitą. Tai yra iš vienos pusės mes turėjom „developerius“, iš kitos pusės turėjom „operationus“. Tas klasikinis variantas, kai „developeriai“ sukurdavo kažkokį produktą, bet jie neturėjo ne tik įgūdžių, bet ir noro tą produktą palaikyti. Ir jie tiesiog perduodavo kaip karštą bulvę tą produktą „operationams“, kurie turėjo tą produktą palaikyti. Tai pagrindinis iššūkis, dėl ko, aš manau, kilo „DevOps“ judėjimas.

Na taip. Iš tikrųjų tarp tų dviejų, sakykim, skyrių, „developerių“ ir „operationų“ buvo siena. Ir per tą sieną jie taip ir mėtydavo tą kamuoliuką, tą karštą bulvę. Ir kai kažkas neveikia, tai – „čia jūs kalti, tai jūsų infrastruktūra blogai pastatyta, mūsų kodas veikia“, o „operationai“ sako: „Nu palaukit, pas mus visa infrastruktūra veikia, jūsų kodas neveikia“. Ir būtent tai ir buvo pagrindinės bėdos, kurias stengiamasi panaikinti.

Koks yra tas DevOps filosofijos ar kultūros pagrindinis dalykas? Kaip tai gali padėti išspręsti tas problemas?

Iš tikrųjų tai labai patinka man CALMS mantra DevOps ir ji labai gerai visa tai atspindi, ką tai reiškia iš tikrųjų. CALMS – tai yra žodžių trumpinys. C – tai yra „culture“, kultūra, kur būtent parodo, kad DevOps yra labai svarbu ir pati kultūra, kuri būtent ir užtikrina, ir parodo, kad mes visi kartu esame atsakingi už išleidimą produkto ir neturi būti tų sienų ir atsakomybės kratymosi. Į tą pačią kultūrą įeina ir tai, kad mes informacija norim dalintis, o ne kaip tik vienas nuo kito slėpti, ir kad kiek įmanoma visuose susitikimuose, produkto planavimo dalyvautų kiek įmanoma daugiau tiek „operationų“, tiek „developerių“ ir t.t. Būtent C raidė tai atspindi. Sekanti raidė A – tai yra automatizacija. Gaila, bet labai daug įmonių į tai šiuo metu ir akcentuojasi ir tik apie tai kalba. Ir dažniausiai kai samdo DevOps inžinierius, galvoja apie automatizatorius, kad jie ateitų ir automatiniais įrankiais pastatytų automatiškai jiems pačią infrastruktūrą. Deja, tai nėra vien tik automatizacija, bet, kaip jau ir minėjau, tai yra visas kalnas, visa mantra. Sekanti raidė yra L – tai yra „lean“, kad kiek įmanoma daugiau išskaidyti didelius darbus, nes kaip buvo priprasta, programuotojai dirbo vadinamo „Waterfall“ metodu, kai pusę metų užsidarai ir rašai kodą, ir paskui metų gale bandai jį išleisti, o jis neveikia arba iš viso „deliverini“ ne tai, ko iš tavęs prašė. O jeigu prieinant prie „lean“, suskaldomi tie darbai į mažus sprintus. Sprintuose į dar mažesnius darbus, tai tu labai greitai gali pamatyti iš tikrųjų, kada tu eini ne į tą pusę, kas tau neveikia ir t.t. Stengiamasi, kad visa tai būtų kiek įmanoma išskaidyta. Sekanti raidė – M. Tai yra „,measurement“ – matavimas. Ir čia vėlgi akcentuojama tai, kad kiek įmanoma daugiau reiktų visko matuoti. Kiek kartų tu išleidai programinę įrangą, kiek išleidus atsiranda bėdų, kiek kainuoja valandų „supporte“, pvz., jeigu iškyla kažkokių klaidų. Matuoja viską. Netgi komandos nuotaikas matuoja. Vėliau galbūt galėsiu papasakoti, bet vienoje iš konferencijų labai gerą atvejį girdėjau, man jis užstrigo. Galėsiu galbūt pasidalinti vėliau. Ir paskutinė raidė – S. Tai būtent „sharing“ ir ji atsako už dalinimąsi, kad kiek įmanoma daugiau dalintis, nes, deja, gaila, bet iki šių laikų dar yra tokių dalykų kaip vienoje įmonėje keli projektai nesidalina nei kodu, nei kažkokių bėdų sprendimais ir t.t., dėl kažkokių tam tikrų politinių dalykų. Stengiamasi šitą dalyką panaikinti, kad to nebeliktų.

Aš dar turbūt kažkiek papildysiu Tomą iš verslo pusės. Man atrodo, kad verslas mato DevOps kaip galimybę greičiau suteikti naudą vartotojui galutiniam. Anksčiau labai dažnai pasitaikydavo atvejų, kai, tarkim nuo to laiko, kai programuotojas parašo pirmą kodo eilutę iki tol, kol ta kodo eilutė tampa produktu ir pasiekia vartotoją, praeina šeši mėnesiai. Ir tai buvo visiškai normalu. DevOps padeda pasiekti tikrai kosminius greičius, jeigu pažiūrėti į lydinčias įmones, organizacijas, kurios užsiima skaitmeniniais produktais. Jie sugeba, kad nuo kodo eilutės parašymo iki pasiekimo į produktą tos kodo eilutės, praeina dienos, valandos vietomis.

Gerai, dabar girdžiu, kad yra trumpų ciklų, iteracijų, vadinkim taip, įvedimas ir jos dažnai peržiūrimos išleidžiant produktą į rinką. Tai visiškai primena „agile“ vadinamą terminą. Ar tai reiškia, kad jeigu įmonė dirba komanda pagal „agile“, tai jau yra DevOps?

„Agile“ yra vienas iš įrankių dirbti pagal DevOps procesus, tikrai taip. „Agile“ padeda turėti trumpus ciklus tarp paties programavimo. Bet, kaip jau ir minėjau, į DevOps įeina ir kiti įrankiai, kurie padeda optimizuoti išleidimą tos programos, padeda statytis infrastruktūrą automatizuotai ir, galų gale, įeina ne tik įrankiai, bet ir komunikacija, kuri irgi, kaip jau minėjau, yra labai svarbus aspektas DevOps. Ir to reikia nepamiršti.

Girdėtas yra mitas, kad DevOps yra kažkas tokio labai naujo, kažkas tokio nelabai aiškiai nustatyto, kad tai naudoja maži startupai ar kompanijos, kur trys ar keturi kolegos susėdę kartu daro greitus, mažus išleidimus ir sako, kad mes esam DevOps. Ar taip iš tikrųjų yra? Ar nėra po tuo kažko daugiau?

Manau, kad mažos įmonės jos iš tikrųjų turi DevOps specialistų, tiesiog jie nevadina jų DevOps specialistais. Nes tai yra natūralu. Jei mes dirbam komandoj iš septynių, dešimt žmonių, tai mes turim universalias dienos praktikas, nes mes visi dirbam kartu. Manau, kad DevOps aktualėja, kai auga įmonės dydis. Tarkim, nuo dvidešimt žmonių jau labai sunku žinoti, ką galvoja tavo kolega. Ir tada atsiranda poreikis DevOps metodologijos.

Na, tikrai taip. Pritarčiau, kad mažesnės įmonės galbūt dirba pagal DevOps praktikas netgi pačios to nežinodamos, nes joms taip gaunasi automatiškai dėl to, kad jie visi kartu sėdi, visi vienas šalia kito. Ir tai daug lengviau gaunasi. Didesnėse įmonėse tai jau darosi aktualiau. Tai reikėtų pritaikyti būtent didesnėms įmonėms – pradėti dirbti pagal DevOps praktikas. Bet norėčiau pabrėžti, kad tokios kaip DevOps inžinieriaus rolės neturėtų būti ir negali būti. Ir tos mažos kompanijos, kai dirba pagal DevOps praktikas, pačios to nežinodamos, jos tikrai turi kitokius specialistus, kitokias pareigas įvardintas ir, todėl paminėjo Gleb, kad jie tikrai neturi tokių pareigų kaip DevOps inžinierius. Tokių pareigų ir neturi būti, nes jų nėra.

Tai gerai, tuomet vertėtų paklausti, tai kas yra tas standartinis, tradicinis arba suprantamas DevOps inžinierius. Kas tai yra? Ar tai programuotojas, ar tai infrastruktūrininkas, ar tai galbūt projektų vadovas, kuris viską koreguoja?

Čia labai geras klausimas ir jis tuo pačiu pašnibžda atsakymą, kad jeigu mes samdom DevOps inžinierius, jeigu ateina ir sako, aš esu DevOps inžinierius, realiai tu nežinai, ką jis daro. Kaip ir pats minėjai ką tik, nežinia, kokios pareigos tai yra. Dėl to ir negali būti DevOps inžinierius. Dėl to turi būti įvardinta ar tai yra programos automatinio išleidimo inžinierius, sakykim kaip pavyzdys, ar tai yra SRE – „Site Reliability Engineer“ ir t.t. Tai turėtų būti specifiškai nurodyta. Dėl to, kad netgi ir samdant į darbą DevOps inžinierių, gali sulaukti labai įvairių ir nežinai, ko. Tokių pareigų kaip ir nėra.

Ką pasakyti jauniems žmonėms, kurie nori tapti DevOps inžinieriais?

Aš manau, kad jeigu jie pažiūrėtų į darbo skelbimų portalus ir paieškotų DevOps pozicijų aprašymų, jie pamatytų begalę visokių DevOps aprašymų variantų. Ir tai, beje, parodo, kad mes neturim konsensuso. Kiekviena organizacija, kai ji ieško DevOps inžinieriaus, jie tai įsivaizduoja savaip.

Taip. Aš galėčiau tiktai parekomenduoti, kur galbūt padėtų susidėlioti kelią į DevOps inžinierius ir, gal tai gausis šiokia tokia reklama, bet aš tikrai nereklamuoju to – „Microsoft Azure DevOps Experts“ sertifikavimas. Jis iš tikrųjų susideda iš dviejų egzaminų. Ir būtent vienas iš egzaminų padengia tą dalį, kuri yra susijusi labiau su infrastruktūros statymu, programavimu ir kodo valdymu su artefaktoriais ir t.t. Ir kita dalis yra būtent, kuri labiau susijusi su projekto valdymu, kad jis būtų greitas, dirbama pagal „Agile“, „Scrum“ ir t.t. Ir visa tai per tuos du egzaminus yra padengiama. Ir iš tikrųjų man labai patinka būtent to egzamino visos temos padengiamos, aprašymas, nes po tuo egzaminu jos visos išvardintos. Ir labai puikiai tai parodo, į kur reikėtų sutelkti dėmesį. Tai aš, aišku, mintinai jų visų nepamenu, bet jau porą iš tų minėtų, jau sakiau. Tai programavimo padengimas, automatizavimo padengimas ir realiai iš tikrųjų DevOps inžinieriaus rolė gaunasi labai plati. Dėl to ir sakau, neišeina turėti tokios pozicijos darbe.

Aš gal dar papildysiu. Aš manau, kad būtent jauniems žmonėms, kurie norėtų dirbti DevOps srityje nereikia išsigąsti didžiulio aprašymo pozicijos, nes dažniausiai visos tos išvardintos technologijos tikrai nereikalingos. Dažniausiai organizacija ieškos kažkokio, tam tikros srities, DevOps didžiulėje srityje, specialisto.

Teoriškai, jei pagalvotum, kaip gali atrodyti koks nors vienas DevOps darbas kažkokioje hipotetinėje kompanijoje? Ką tas žmogus turėtų mokėti? Nes girdime, kad jis turi mokėti programuoti. Galima susidaryti įspūdį, kad tai yra programuotojas. Kitu atveju, jis turi taip pat užtikrinti, kad procesai gerai veiktų komandoję, kad jis gebėtų iškomunikuoti – čia yra tam tikra dalis projektų vadovo arba komandos vadovo atsakomybių. Ar tai reiškia, kad DevOps inžinierius uždirba daugiau negu jie, nes dirba tokį platų spektrą darbų?

Aš, kaip ir minėjau, iš tikrųjų nereikėtų tai vadinti DevOps inžinieriais. Reikia sakyti, kad mūsų programuotojai dirba naudojant DevOps procesus. Tai tada žinosim, kad tai yra programuotojai, jie programuoja. Ir, kaip ką tik pasakei, reikia būtinai mokėti programavimo – nebūtinai. Užtenka mokėti tiktai pačios infrastruktūros statymo arba automatizavimo ir lygiai taip pat galima dirbti pagal DevOps procesus. Dėl to ir sakau, geriausiai būtų, kad kai įmonės samdo, jos nurodytų tikslią poziciją, į kurią tu eini, ką tu atlieki. Bet kad mes dirbsim visa komanda arba visa įmonė pagal DevOps procesus – tai gali būti prirašyta šalia.

Iš tikrųjų iš patirties labai daug DevOps inžinierių ateina iš gretutinių sričių. Tai būna arba programuotojai, kurie nusprendžia, kad jiems įdomu naudotis DevOps metodologiją ir jie norėtų į ją įsigilinti, arba tai sistemų administratoriai, arba tai „quality assurance“ specialistai.

Tikrai taip. Duombazistai, „network“ specialistai, „security“ specialistai – visi. Bet reikėtų taip ir įvardinti. Tada ir įmonė žino, į kokias pareigas tiksliai samdo žmogų, ir žmogus žino, ką jis atėjęs iš tikrųjų darys. O kad visi kartu dirbsit pagal DevOps procesus, tai yra valio.