Vissza2021-ben elindítottuk az „Öt lovas” webinar sorozatunkat, ahol alkalmanként egy-egy IT szakmai területet járunk körbe öt szakértő segítségével.
A negyedik állomáson egy izgalmas és nagy jövő előtt álló szakterület, a DevOps szerepkör helyzetét és kilátásait elemeztük ki meghívott szakértőinkkel.
A DevOps pozíció az IT szakmában egy újfajta megközelítési módot hozott a feladatok megoldásában és a problémakezelésben. Webinárunk összefoglalójában kitérünk rá, hogy egyes cégek életében mit jelent pontosan a DevOps pozíció és mi a szerepköre egy ilyen pozíciót betöltő munkatársnak. Létezik-e egyáltalán ezen a területen valóban tapasztalt szakember az IT szakmában? Milyen készségekre van szüksége egy munkatársnak, aki DevOps pozícióban szeretne dolgozni? És még sok más hasznos kérdésre kapunk választ Öt lovasunktól az alábbiakban:
Beszélgető partnereink:
Szűr Helga, IDBC Infra recruitment team leader
Hegedűs Dániel, Magyar Telekom, could engineering chapter lead
Tóth Norbert, Abesse szakmai igazgató
Meggyesi Péter, LeanNet CTO, társalapító
Köszönjük előadóinknak, hogy velünk voltatok, megosztottátok a szakmai tudásotokat, tapasztalataitokat, az „Öt lovas” webinár nézőivel.
A teljesség igénye nélkül, nézzük át a legizgalmasabb kérdéseket és válaszokat!
Mit jelent az egyes cégek számára a DevOps pozíció? Miért nehéz jó szakembert találni?
Miért van ennyi féle értelmezése és pozíciója a vállalatoknál?
Dániel szerint a DevOps kultúra és módszertan inkább a vállalatról, szervezetről szól, mintsem az egyénről és az egyéni tudásról. Azért lehet nehéz egyrészt jó szakembert találni, mert sokan csak felcsapják a lexikont, megnézik mit jelent a DevOps, (egyszerre fejlesztő és üzemeltető is), és onnantól mindenhez értenek. Viszont ez inkább annak a módszertana, hogy hogyan üljük körbe az asztalt az egyes szakterületekről és oldjunk meg problémákat. Röviden a szervezeti kultúra és munkamódszert jelenti számára.
Amint Norberttől megtudtuk, az Abesse-nél nincs ilyen pozíció, de vannak ilyen tudást igénylő munkáik. Az Abesse nagyvállalati ügyfeleknek szállít nagyvállalati szoftver termékeket, ezáltal új funkciókat és folyamatos működést kell biztosítani.
Két részre oszthatjuk a DevOpsot, az egyik a módszertan a munkaszervezés, időszervezés, valamint hogy tervezünk olyan szoftvert vagy szolgáltatást, amit hatékonyan lehet üzemeltetni és fejleszteni.
A LeanNetnél inkább a kultúrán van a hangsúly, egyre jobb szoftverre van szükség, és arra, hogy a szoftver gyorsabban tudjon szállítani a felhasználóknak. Ez sok mindent jelenthet. Akár azt is, hogy olyan emberek a DevOps-osok, akik értenek a fejlesztéshez és az üzemeltetéshez is, de nálunk és általában máshol is ezeket a feladatokat egy csapatnak kell teljesítenie, nem egy embernek. Inkább tool-okról beszélünk, amelyekbe a fejlesztők egyre jobban belelátnak, valamint az üzemeltetők munkájába is belátást nyernek. Az üzemeltetők pedig segítik a fejlesztőket, és ez oda-vissza működik.
Norbertéknél mindenki “kicsit átlát a kerítésen”, vagyis nincsenek élesen elkülönülve a területek, ugyanis fontos, hogy belelássanak egymás munkájába.
Ezek alapján világosnak tűnik a pozíció, de HR oldalon is ennyire nyilvánvaló a helyzet?
Helga szerint kezd világos lenni, de mások az elvárások a háttér tekintetében az egyes cégeknél és az egyes jelöltek hátterét illetően.
Az IDBC tekintetében olyan szakembert keresnek, aki az adott cégbe illik, a cég DevOps érettségéhez passzol-e, illetve aki ezt az egészet ki tudja alakítani.
A cégvezetők hogyan profitálnak ebből? A fejlesztőknek miért jó a DevOps?
Norbert:
Az Abessenél korábban nagyon erősen elkülönült a projektszerű szoftverek fejlesztése, mely elkészülés után átadásra kerül, majd pedig supportra. Ezt az agilis módszertanok keresztülhúzzák. A szoftveresek sokszor csak hibákat javítanak, de ennek is megvan a szerepe a kollégák fejlődésében. Viszont ha csak ezt csinálja valaki hosszú ideig, az folyamatosan egyéni problémákat okoz, például megunja a munkát, nem lát fejlődést benne.
És mi történik akkor, ha valaki csak a fejlesztésre koncentrál? Norbert megkülönbözteti a fejlesztőket és a kódolókat.
Ha nem érdekli a kollégát, hogy milyen környezetben fog működni, amit fejleszt, vagy nem biztonságos az üzemeltetés, nem foglalkozik vele, hogy a log-jait hogyan kell értelmezni, az problémát fog okozni.
A coder embereket nagyon nehéz meggyőzni, ha ki kell javítani valamit a munkájukon, sokszor nincs is rá mód.
Egy csapatnak vannak support jellegű feladatai és fejlesztés jellegű feladatai is, így egyéni érdekük lesz, hogy olyan szoftvert fejlesszenek, ami skálázható, könnyen beilleszthető a rendszerbe. Így csak az ambíciói és képességei szabnak határt a kolléga fejlődésének. Számunkra fontos volt, hogy ezt a környezetet megteremtsük a munkavállalóink számára.
Dániel olvasatában az üzleti haszon és a személyes előnyök jelentik a profitot.
A Telekomnál fentről építkezett a dolog, ennek vetettünk mindent alá, a toolokat, infrákat, szervezeti felépítést. Csökkenteni szerettük volna a ciklust, mire kikerül egy új fejlesztés. A régen megoldhatatlannak tűnő problémákra a DevOps megoldást jelent.
A DevOps legnagyobb financiális előnye, hogy gyorsabbak lettek a fejlesztési folyamatok, gyorsabban elkészül a termék. Évi pár release-ből most már el lehet jutni az Intra D release-ig.
Péter szemében a DevOps továbbgondolása az agilitásnak. Üzleti oldalon gyorsan kell szállítani az új feature-ket, mert minél hamarabb kiderül, hogy kell-e vagy nem az új feature a felhasználóknak, annál jobban megéri üzletileg.
A cél: ötlettől minél gyorsabban eljutni a felhasználókig.
Mennyire volt zökkenőmentes az átállás a DevOps módszerre?
Dánieléknél a többlépcsős volt az átállás. A Telekomban azt is megtapasztalta, hogy milyen az, amikor az iparágban legelőször állunk át egy céggel, majd pedig legutoljára egy másikkal.
A DevOps által jobban rálátunk egymás munkájára, és meg is tudjuk beszélni azt, jobban megértjük a kollégákat, véleményt is formálunk egymásnak az eredményesség érdekében.
Az Abesse vezetője így nyilatkozott: elkerülhetetlen volt az átállás. Ami először versenyelőny volt, utána elvárás lett. A piac elkezdte kikövetelni, valahol elé mentünk, valahol követtük az ügyféligényeket.
Nagyvállalati szállításban a kockázatkezelés az egyik legnagyobb előny.
A DevOps módszertannal kontrolláltabb a folyamat, automatikusabbak a működések. Minél nagyobb a kontroll, annál kockázatmentesebb a projekt.
Ha valahol hiba van és újra kell csinálni, az nagyon sok bonyodalmat okoz és hátráltat a munkában, ezért is nagyon fontos a kontroll.
És természetesen a DevOps a szoftverfejlesztés pozíciós fejlődését is jelenti.
“Mi a LeanNetnél szolgáltatói szemmel úgy látjuk, meghatározó, hogy milyen szektorban vannak a cégek. Például kis agilis cégnél könnyebb ezeket a folyamatokat összehozni, viszont bankoknál, nagyon szigorú struktúrákban ezek akár 3-4 éves projektek is lehetnek.
Nagyon komoly szervezeti és technológiai átalakítást igényel a bevezetés, különböző lépcsői vannak, melyeket be kell tartani szervezettől függően.” foglamaz Péter.
Milyen eszközrendszereket használtok a DevOps kapcsán?
Dánielnek a fektetett nyolcas DevOps modell jut eszébe erről a kérdésről.
“Az adott tool-ok kiválasztása lehet hitvallás, célok és pénztárca kérdése is. Egyedileg egy esetre szabva állítjuk össze a tool-okat, de párat felsorolok, amik alapját képezik a munkáknak: Gitlab, HEM, CI, Pubernet, Docker, Prometheus, Jaffana, Gredo, és még sok más. A fő kérdés mindig az, hogy hogyan rakjuk össze, melyiket miért választjuk.”
Norbi szerint a frontend technológiához hasonlóan nagyon sok a lehetőség. Az alábbi gondolat szerint járnak el: „Jó a sok szerzám, de még jobb, ha van pár, amihez nagyon értesz.”
A DevOps Servert használják legtöbbet telepítőcsomag előállításra és ehhez kapcsolódóan sok natív felhő szolgáltatást használnak például a Microsoft Hosted agent. Használnak még többek között Docker konténereket, ARM template-t, Terraformot is. Utóbbiakkal kóddal kell leírni, hogy milyen infrastruktúrát szeretnénk, mert a nem jól átgondolt infrastruktúra kód tud károkat okozni.
Péteréknél a DevOps inkább kulturális szinten jelenik meg, mintsem tool-ként. A legtöbb tool opensource, amiket használnak, Dánielékhez hasonlóan leginkább felhő szolgáltatások. “A mainstream tool-okon kívül tanácsadó cégként szoktunk személyre szabottan javasolni toolokat az egyes projektekhez.
Érdekességképpen a Netflix volt az első DevOps módszertant alkalmazó cég, persze abban az időben még nem létezett az említett tool-ok közül mindegyik.”
Dániel: “Nem volt más választás, át kellett állni, ezért mindent ennek vetettek alá. Számunkra a legfontosabb elemek, hogy mennyire gyorsan lehet egy nagyobb szoftvert leszállítani, a tervezési minták hogy vannak megtervezve, a napi felhő szolgáltatások használata mennyire nehézkes.”
Munkaerőpiaci vonatkozásban miért nehéz DevOps szakembert találni, milyen sajátosságai vannak a keresésnek?
Helga tapasztalatai az IDBCnél:
“Nagyon keresettek ezek a szakértők. Az ebben az iparágban dolgozók ezzel tudnak lépést tartani a versenyben. Ráadásul most vonzó kifejezés. Korábban az agilis kifejezés is ilyen volt, most pedig a DevOps lett az.
Fontos megjegyezni, hogy több ilyen szakembert keresnek, mint ahány elérhető a piacon, ráadásul inkább medior, senior szintre keresik a szakembereket. Az a tapasztalat, hogy érdemes fejleszteni a juniorokat, ha érdekeltnek és motiváltnak látjuk őket, mert akkor gyorsan fel lehet fejleszteni őket a kívánt szintre.
Az a kevés jó és tapasztalt szakember pedig tudja, hogy keresettek, biztosan most is megbecsültek a jelenlegi helyeken. Valami nagyon jót kell kínálni nekik ahhoz, hogy felálljanak.
Ha a fiatalok erre az útra lépnek, akkor jó karriert csinálnak, azt hiszem nyugodtan mondhatom ezt.”
Mennyire jutottak el a cégek oda, hogy a kineveléssel is foglalkozzanak?
Helga, recruiter, tapasztalatai szerint: “Egyre rugalmasabbak a cégek. Mindkét oldalon az a kérdés, hogy mire van szükség és a junior szempontjából mi az az 1-2 technológia, amit már jól ismer és amiben segítséget tud nyújtani a cégnek. Van pár nagy cég, amelyek 3-4 hónapos képzéseket szerveznek, utána pedig álláslehetőséget is kínálnak a képzést elvégzőknek.”
Dániel úgy gondolja, egy embertől nagyon nehéz elvárni, hogy mindenhez értsen, sőt, nagyon nehéz ilyet találni, és az még nagyobb baj, hogy az ilyen szakemberek egyedül vannak. “Hiába hajítják ki a gerelyt a stadionból, akkor is egyedül vannak. Csapatot kell építeni, nem egy embertől elvárni mindent. Tanuljanak a kollégák egymástól. Nálunk mindenre van példa, kitanítunk juniorokat, felveszünk profikat, de volt már olyan is, hogy kineveztünk egy meglévő kollégát szinte a semmiből, majd segítettük a fejlődését.”
Norbiék szakmai műhelyekben dolgoznak. Ő is úgy látja, hogy jó szakembert felvenni nagyon nehéz, a nagyvállalati szoftverfejlesztés nem triviális feladat, egy pályakezdő nem tudja hogyan kell csinálni. Fontos a kinevelés, betanítás, mentorálás. A junior részéről fontos, hogy legyen képessége, szeressen tanulni.
Milyen az ideális super senior DevOps?
Norbert: “Aki csapatot tud csinálni, szakmai műhelyet tud maga köré építeni. Aki egyedül van, nem tud a mai világban hatékonyan dolgozni. 10 év tapasztalatot pont tíz év alatt lehet megszerezni, viszont nem mindegy milyen környezetben tölti az idejét az ember. Rakétaként tud menni egy ilyen csapat előre. Egy 5 fős csapat többre képes, mint 1 ember.”
Péter: “2010-től létezik nagyjából a DevOps kifejezés. Olyan senior, aki clouddal foglalkozik, nagyon ritka. Általában ki kell nevelni.”
Dániel: “Az előttem szólók gondolatát folytatva, ezek a fogalmak, amikkel most dobálózunk, mint például a cloud, az utóbbi nagyjából 5 évben vált igazán nagyon jelentőssé. Folyamatosan változik az IT és minden terület még nagyon fiatal szakma.”
Létezik-e vajon ezek alapján igazi senior mérnök?
A fiataloknak azt javasolja Dániel, hogy karrierjük elején kóstoljanak bele az ehhez szükséges részterületekbe, és ha érdekli őket, akkor menjenek tovább ebbe az irányba.
Mivel csábíthatók az új munkaerők?
Mi az IDBC-nél megtaláljuk a piacon lévő néhány jó szakembert, viszont a kihívás inkább az, hogy találjunk megfelelő érveket, amiért a fő szakemberek munkahelyet váltsanak. Ha a megbízói oldal is tisztában van a jó érvekkel, akkor van esély, hogy sikerül elcsábítani egy seniort is.
Az Abessenél arról mesélünk nekik, hogy mit fog dolgozni, milyen ügyfélnek milyen problémákat fog megoldani, hazai vagy külföldi cégnek, magyarul vagy angolul. A széles ügyfél-portfóliónkat szoktuk még említeni, és hogy miért érdekesek a projektjeink.
A komoly jelölteket érdekli a szakmaiság, hogy mi, mint cég mit gondolunk valamiről, például egy probléma megoldásáról, hogyan közelítjük meg a feladatokat.
De ebben a szakmában az is előfordul, hogy remote dolgozik egy külföldi cégnél home office-ból. Ekkor a szakmai műhely előnyt jelenthet, hiszen együtt gondolkodnak a kollégák, a közös alkotás örömének nagy ereje van, ez inspirál, és egy egészséges versenyszellem jót tesz a munkának.
A szervezeti kultúra is nagyon fontos.
“A LeanNetnél fontos számunkra a szakmaiság, hangadók szeretnénk lenni a szakmában. Előadásaink vannak és egyetemi kapcsolatokat tartunk fent, nagyon jó külföldi ügyfelekkel dolgozunk, ahol kulturálisan sokkal többet tudunk fejlődni.”
“A Telekomnál nagyon UpToDate a tech, tényleg a most elérhető legjobb technikát biztosítjuk, nagyon jók az eszközök, többmilliós ügyfélkörhöz jutnak el és sokféle feladathoz hozzá tudnak nyúlni a munkatársak.”
“Az IDBC látásmódja szerint sok múlik azon, hogy mit tud biztosítani az ügyfél. A munkavállalóknak nagyon fontos a rugalmasság, képzési lehetőség, meetupok, szakmai konferenciák, technológiák, fejlődési lehetőségek, csapat, akikkel jó együtt dolgozni, tanulhatnak egymástól.”
Hogyan látjátok a DevOps jövőjét?
Péter: “Új paradigmák, új tool-ok jönnek, egy csapatban ott tud ülni egy olyan ember, akinek nincs köze az IT-hez, aki az ügyfél igényeit hajtja végre egy DevOps csapattal.”
Dániel: “A DevOps devalválódik valahova, fontos, hogy hagyjanak időt, hogy a szervezet utolérje magát, ne akarjunk lépcsőfokokat ugrálni, sorrendben kell haladni, azt kell adoptálni, ami a célt szolgálja.”
Norbert: “Automatizálás, kockázatcsökkentés: ez lesz a két vezér terület.
A felhő infrastruktúrában a security és az automatizált telepítés kap vezető szerepet.
Szintén nagyon fontos lesz a felhő szolgáltatás architektúra költség optimalizálása.
Egyre drágábbak a költségek. Egyre többen kérnek fel arra, hogy nézzük át, mi kell az adott architektúra tényleges működtetéséhez, hogy elégségesen futtatható legyen. A költségcsökkentés ezen a területen rendkívül komplex feladat.”
Összességében elmondhatjuk, hogy egy vállalat életében a DevOps módszer bevezetése és ezzel együtt egy ilyen szakember felvétele a legnagyobb előnyt jelentheti, viszont egy DevOps szakember, vagy inkább csapat megtalálása, kinevezése okozza a legnagyobb problémát, ráadásul minden cégnek nagyon egyedi szükségletei vannak a DevOps területén.
A vállalatok emiatt leginkább a kinevelést vagy a kiszervezést választják. Vagyis cégük igényeire szabnak egy kollégát, akiben látják a potenciált és az akaratot vagy pedig egy speciális csapatot bíznak meg cégen belül vagy kívül, akik elvégzik az összetett feladatot.
A jövő generációjának pedig mindenképp ajánljuk a DevOps és hozzá hasonló összetett módszereken alapuló munkát, hiszen ez jelenti a jövőt a szakmában. A cél mindig a minél gyorsabb és emellett magas minőségű megoldások szállítása az ügyfél felé.
Még több információért és a teljes tartalomért nézzétek meg a webinárt:
Tartsatok velünk a következő „Öt lovas” beszélgetésen is, ahol a .Net pozíciót fogjuk górcső alá venni, részletekkel hamarosan jelentkezünk.
