A LifeInTech podcast csatornán futó, különböző szerepköröket bemutató sorozatunkban Nagy Gábor DevOps Team Lead-el beszélgettünk a munkájáról, a pozíciójához kapcsolódó feladatokról, a fejlesztésnek a DevOps-ost érintő feladatairól.
Hogyan alakult a karriered a kezdetektől?
Viszonylag régóta vagyok a szakmában, a ’90-es évek vége felé kezdtem el dolgozni. Egy kisebb utazási irodánál először webfejlesztéssel, majd ennek folyományaként szerverek karbantartásával foglalkoztam. Megtetszett az üzemeltetés, ez az akkor még nagyon klasszikus rendszergazdai szerepkör, így végül váltottam a fejlesztési részről üzemeltetési irányba. Ezt követően volt egy hosszú, tíz éves szakasz az életemben, amikor a légiirányításban dolgoztam különböző informatikai szerepkörökben. A 2010-es években felismertem, hogy a rendszergazdai szerepkör meg fog változni, át fog alakulni. Már látszott a piaci hangulatból, az eszközökből, a módszertanokból, amik akkor bejöttek, hogy váltásra lesz szükség, ha továbbra is a szakma élvonalában lévő technológiáival szeretnék foglalkozni. Ekkor úgy döntöttem, hogy otthagyom a légiirányítást és kiköltöztem három évre Norvégiába, ahol cloudos, automatizációs technológiákkal dolgoztam. Miután családi döntés eredményeként hazaköltöztünk, egy Big Data-val foglalkozó cégnél helyezkedtem el, ekkor már kifejezetten Bild Engineer, Infrastructure Engineer, illetve DevOps Engineer szerepkörben. Majd körülbelül egy éve jött a váltás, átkerültem az EPAM-hoz és azóta is itt, a jelenlegi pozíciómban dolgozom.
Mit takar pontosan ez a pozíció, amiben dolgozol, mit csinál a DevOps-os nap, mint nap?
Nagyon sokféle definíció létezik, én azt mondanám, hogy nincs egy nagyon pontos leírás, mindenki kicsit mást ért alatta, így csak az én olvasatomat mondhatom el. A DevOps Engineer egy olyan szerep, megközelítés, ami a szoftverfejlesztési ciklust elejétől a végéig felöleli. Onnantól kezdve, hogy a fejlesztő leül fejleszteni a kódját a saját laptopján, egészen odáig, hogy ez a kód kikerül egy cloudba és kiszolgál egy nagy alkalmazást. A DevOps Engineer ezt az egész folyamatot különböző területeken támogatja és segíti, hogy mindez minél zökkenőmentesebben és gyorsabban tudjon megvalósulni. Ebből is látszik, hogy kell hozzá szakmai tapasztalat a különböző területeken, így DevOps-osnak a szakma különböző területeiről érkeznek. Van, aki fejlesztői vénával, fejlesztői pozícióból gondolja úgy, hogy egy kicsit más irányba szeretne menni. Van, aki - mint én - inkább a rendszergazdai oldalról érkezik és innen kerül bele a dologba.
Van-e valami speciális az EPAM-nál ebben a szerepben, az általános DevOps-os pozícióhoz képest?
Inkább úgy fogalmaznám meg, az, hogy a DevOps-os mennyire tudja támogatni a fejlesztési folyamatot, a vállalat, a projekt érettségétől függ. A döntéshozók akik kitalálják, hogyan épüljön fel az adott projekt, az ő víziójukon, a szervezett érettségén múlik, hogy a DevOps Engineer, mennyire tudja jól összekötni a szereplőket és segíteni a szoftverfejlesztési életciklust és lesz belőle valóban DevOps-os vagy csupán átnevezett System Administrator. Úgy gondolom, hogy ebben az EPAM elöl jár, itt ez egy több életcikluson átívelő szerepkör valóban.
Említetted korábban, hogy tapasztalatra, előképzettségre van szüksége annak, aki ezzel szeretne foglalkozni. Milyen készségekre van szükség a szakmai tudáson kívül?
Akár fejlesztői, akár rendszergazdai irányból jön át valaki erre a pozícióra, az attitűd meg kell legyen benne, hogy meg akarja szeretni, ismerni, tanulni azt a részét a munkának, amit eddig kívülről ismert csupán. Ez a szépsége és a nehézsége is egyben ennek, hogy rendelkezz bármilyen típusú tudással, meg kell szerezd a hiányzó tudásrészt, ami a munkádhoz szükséges. Eszembe jut régről a tipikus mém: „Én: Nálam fut a program, részemről rendben! Rendszergazda: Ez itt nem fut, oldjátok meg, mert valami probléma van!” Ma egy teljesen más szemléletmódra, van szükség, hogy közösen próbáljuk meg kialakítani és elérni a célt. Emellett, jó, ha szinte minden területbe, ami kapcsolódik a fejlesztéshez - a tesztelésbe, az üzemeltetésbe, adott esetben egy kis projektmenedzsmentbe - valamennyire belelát az ember és össze tudja ezeket kapcsolni és az egész workflow-t egyben látni. Nyitottságra, analitikus látásmódra tehát mindenképp szükség van. Szintén fontos a jó kommunikációs készség, hiszen nagyon sokat kell másokkal egyeztetni, megérteni mások problémáit, gondolkozását, hogy egy adott dolgot ő, miért éppen úgy szeretne csinálni. Hiszen az én feladatom, hogy támogassam és segítsem, hogy meg tudja valósítani, amit elképzelt.
Mi az, ami esetleg nehéz, vagy amiben neked is fejlődnöd kellett?
Mivel – rövid fejlesztői múlttal - rendszergazdai irányból jöttem, meg kellett ismernem a fejlesztési és az ehhez kapcsolódó tesztelési módszertanokat, hogy amikor például egy rendszer kialakításáról beszélgetünk, akkor azt az eszközkészletet, szókészletet tudjam használni, amit a fejlesztő vagy a tesztelő használ. Jelenleg is próbálok ezen a területen fejlődni, mert úgy gondolom, hogy itt vannak kis hiányosságaim, rések, amiket mindenképp érdemes betömni.
Kik azok pontosan, akikkel közvetlen kapcsolatban vagy a napi munka során?
Nézzünk egy ideális, elképzelt DevOps-os szerepkört! A DevOps-os már a tervezési fázisba beszáll, hiszen ő tud abban segíteni, hogy lehet minél gyorsabb ciklusokban fejleszteni, ezeket könnyen kirakni különböző környezetekre. Ilyenkor az architecht-ekkel és részben az ügyféllel kell beszélni, illetve különféle projektmenedzserekkel, hiszen ők tudják megmondani, hogy milyen ciklusokban milyen gyorsan szeretnének iterálni. A munka egészében pedig leginkább a fejlesztőkkel kell egyeztetni, mert valójában az ő munkájukat támogatjuk, segítjük. Ebbe a körbe vonnám be a tesztelőket is, illetve a folyamat végén azt is, aki a szoftvert üzemelteti majd, hiszen az ő munkáját is segíteni kell. Amikor megtervezem, hogy egy szoftver hogyan kerül ki az éles rendszerre, akkor figyelembe kell vennem, hogy aki majd üzemelteti, hogy fog hozzányúlni, neki mi a szempont, milyen metrikákat szeretne arról a rendszerről látni, igy nyilván vele is kell egyeztetni. Összegezve, viszonylag kevés ember van a szoftverfejlesztési folyamatban, akivel egy DevOps-osnak nem kell beszélnie, mire lezárul egy projekt.
Mi ebben a szakmában a csúcs, hogyan épül fel a hierarchia?
Az EPAM-os szakmai karrierszinteknek megfelelően itt is van junior, medior, senior, lead és chief szint. DevOps Engineer-ként amíg junior, medior az ember, ennek az egész szoftverfejlesztési folyamatnak egyes részeivel foglalkozik, abban merül el jobban. Ahogy aztán fejlődik, halad előre a szakmai ranglétrán és bővül a tudása is, egyre jobban átlátja a rendszert, akkor már inkább azzal foglalkozik, hogy az elejétől a végéig, hogy fog jól, olajozottan működni az egész folyamat.
Hogy látod, nálad mi a következő lépcsőfok?
Azért is jöttem az EPAM-hoz, körülbelül egy éve, mert szerettem volna a technológiai mellett egy kicsit kitekinteni a People Management irányába. Bár mindenképp szeretnék a szakmánál maradni, de az emberekkel való foglalkozás, mások útjának az egyengetése is érdekel, a közeljövőben ezzel szeretnék foglalkozni.
