Álláshirdetésekben a DevOps Engineer ...

Címkék

Ha egy álláshirdetésben azt látom, hogy DevOps Engineer-t keresnek, akkor a következőre gondolok:

Rendszergazda
5% (39 szavazat)
Rendszergazda aki nem csak Perlben tud scriptelni (pl. Terraform, stb)
23% (176 szavazat)
Backend fejlesztő aki felhőt is konfigurál
14% (110 szavazat)
Full stack fejlesztő aki felhőt is konfigurál
17% (128 szavazat)
Mindenes (IT mellett kávét is főz)
38% (295 szavazat)
Egyéb, leírom a hozzászólásban
3% (27 szavazat)
Összes szavazat: 775

Hozzászólások

Szerkesztve: 2020. 07. 21., k – 08:12

Olyan, aki lop, szop, bakot ugrik, kezével citerázik, lábával zongorázik, pöcsére meg lámpást akaszt, hogy mindezt éjjel, sötétben is tudja csinálni. Élőben még nem láttam DevOps Engineer-t, de egyszer megérintenék egyet.

trey @ gépház

https://theagileadmin.com/what-is-devops/

Magyar nyelvterületen a fogalom körüli fékezetlen habzást és értetlenséget többek között a megboldogult Linux Akadémia okozta. A már állítólag linux-barát Microsofttal való együttműködés másnapján gyorsan DevOps Akadémiára lett átnevezve. De a tartalom nem változott. Ami ott van annak semmi köze a DevOps-hoz.

Nekem ez az egesz Devops... dolog kicsit erdekes. Az en ertelmezesemben a Devops nem potolja a rendszergazda-fejleszto parost, hanem "hidat" kepez a ketto kozott... De ebben is csak a sporolast latjak a cegek, az a baj....

Azért ezekhez a szavazásokhoz jó lenne még egy opció, hogy

() tudom miről van szó/csinálom

() csak dumálok mert éppen ráérek

Egyéb. Interjú tapasztalatok alapján...

Számos helyen a használt toolchain (git, jenkins, artifactory (és tetszőleges alternatíváik, lehetőleg több is)) + a futtató infrastruktúra (vmware, AWS szolgáltatások, Kubernetes (és tetszőleges alternatíváik, lehetőleg több is)) megcsinálására és karbantartására keresnek embert ilyen néven. Programozni ilyen esetekben igazából nem kell. Ez szerintem egy elég rossz értelmezés, ez nem DevOps, hanem Toolsmith. Csak az olyan rosszul hangzik.

Más helyeken igazából performance engineer-t keresnek DevOps néven, aki rá tud mutatni, ha elfogy az IOPS az adatbázis alatt, ha vacak az SQL query, vagy ha egy for ciklus közepében egyesével futtatják a queryket a kevésbé hozzáértők.

További helyeken az "infrastruktúra üzemeltető, csak legyen jobb" a célja a DevOps pozíciónak. Tipikusan olyan helyeken, ahol már nagyon elszúrták az infra konzisztenciáját, aztán nem találnak olyat, aki átlátná.

Na, ezek közül az első kettő simán érdekes lehet bizonyos embereknek, akiket érdekel a téma. A harmadikkal én szeretek foglalkozni, de ez többé-kevésbé perverzió :-D

Ez a DevOps.

Szerinted.

Na lehet, hogy ezzel nem leszek népszerű, de szerintem nincs olyan, hogy DevOps Engineer.

A DevOps szerintem nem egy munkakör, hanem egy csoportszervezési és felelősségelosztási irány.

A DevOps szerintem azt jelenti, hogy nincs külön Dev csapat és külön Ops csapat, hanem van egy csapat, amiben vannak olyan emberek is, akik a fejlesztéshez értenek, meg olyan emberek is, akiknek van üzemeltetési tapasztalatuk. Ez a csapat, ami DevOpst csinál, az miután kifejleszt valamit, nem adja oda valaki másnak, hanem megcsinálnak minden lépést, ami szükséges, egészen addig, hogy élesbe feltelepítik a cuccot. És ezután ők csinálják az éles támogatást is, ha gond van, ők nézik meg, hogy mi van a logban, mi látszik az éles környezetben. Aztán kitesztelik, átnézik, kijavítják, javított változatot kiteszik élesbe.

Viszont azt is tudom, hogy DevOps alatt legalább 3 különféle dolgot értenek különféle emberek, és nem akarom azt mondani, hogy az én véleményem a tuti, a többi hülyeség.

disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.

"A DevOps szerintem nem egy munkakör, hanem egy csoportszervezési és felelősségelosztási irány." igen is meg nem is.

Egyfelol az idobelisege a dolognak hianyzik. Mikor ez az egesz filozofia/megkozelites/whatever nepszeru lett ez csak egy elmelet volt. De a szakadek ott tatongott a ket oldal kozott, es ment az egymasra mutogatas. Szoval kellett valaki akit elfogadtak mind a devek es mond az opsok a szaketelme alapjan. Kellett valaki, akinek volt gyakorlata mindket teruleten, hogy ez az egesz kultura elterjedhessen.

A masik dolog pedig, hogy osztott felelosseg nem igazan letezik. Vagy legalabbis en tuti nem hiszek benne. Es persze mindenki felelossege a kod, de azert megis ott van a vezeto fejleszto, aki elviszi a balhet. Mindenki felelossege a projekt, de csak van egy project manager, aki felel a csapatert. Miert lenne ez maskent az kapcsolatban, hogy uzemeltetheto allapotban kell atadni a termeket?

Van az az elmelet, hogy ha melletted az utcan osszeesik valaki, akkir 100% felelosseg terhel, hjogy mentot hivj. Ha ketten vagytok, akkor mar 50-50. Gyakorlatilag 100 ember felett elveszik (1% ala megy) az ember egyeni felelossege.

A masik dolog pedig, hogy osztott felelosseg nem igazan letezik. Vagy legalabbis en tuti nem hiszek benne.

A felelős a teljes csapat.

disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.

Az nem csapat, csak 5 ember egy helyen.

Az, hogy a csapat felelős, az azt jelenti, hogy a csapatban mind az öten 100%-ig felelősek minden problémáért.

disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.

Dolgoztam pl helyen, ahol a fizetesem valamennyi hanyadaval feleltem a dolgokert. Volt is, hogy elkefeltem valamit, es honapokig vontak. Nyilvan nem a teljes osszeget, de egyfajta buntetest. Masik helyen amerikai multi alairtam, hogy minden altalam okozott karert anyagi felelosseget vallalok (izgultam is mikor elso nap megontozte a laptopomat az asszony es megteglasodott :D de azt vegul meltanyossagi alapon rendeztuk). Nyilvan usa-ban kothettem volna biztositast a sajat munkamra. Azert mert kicsi hazankban nem feltetlen szokas mashol siman elofordul.

Nem tud egy szemelyben valaki felelosseget vallalni egy egesz csapat tetteiert. Ez nonszensz. Nagyon romantikusan hangzik meg minden. De este mikor hazamegy, nem azt fogja gondolni, hogy elcsesztem, hanem azt, hogy elcsesztuk. Tuk, azaz mi, aminek resze voltam, tehat nem az enyem az osszes felelosseg.

Nem is ertem ezt hogy lehet komolyan gondolni??

Ezt hogyan kell elkepzelni?

Az a megközelítés, hogy x ember ezért felelős, y ember meg amazért, az olyan, mint mondjuk egy 4x100-as váltó futóverseny. Én vagyok a 2. versenyző. Készenállok, átveszem a stafétabotot az első futótól, futok egy kört, átadom a harmadiknak, aztán leülök, hátradőlök és figyelem a versenyt. Vagy nézem a felhőket, vagy akármi. Én megtettem a dolgomat. Most már a többiek dolgozzanak. Ha a harmadik ember megbotlik, elesik, utolsók leszünk, akkor lehet mutogatni, hogy az ő hibája.

Amikor az egész csapat felelős, azt meg úgy képzeld el, mint egy kosárlabda csapatot. Amíg megy a játék, minden játékos figyel, dolgozik, egymást segítik. Ha veszít a csapat, akkor nem az van, hogy Dezső egyszer elesett, azért vesztettünk, hanem együtt nem voltunk elég jók.

Delivery: amíg kész nincs (nem teljesíti az acceptance criteria teszteket), addig mindenki dolgozik rajta. Nincs olyan, hogy a fejlesztő azt mondja, hogy basszátok meg, én leprogramoztam, most már a DevOps munkakörben dolgozó Józsi dolgozik egyedül.

Ha a kész termék rosszul működik (és pl. anyagi kárt okoz), akkor erre a legtöbb cég két fő megoldás közül szokott választani. 1) gyorsan visszateszik a korábbi, jól működő verziót, 2) gyorsan behívják a teljes csapatot, és mindenki ráugrik, hogy elhárítsa a hibát.
Olyanra nem láttam még példát, hogy a fejlesztőktől levontak volna fizetést azért, mert mondjuk a tesztkörnyezetben nem derült ki, hogy élesbe állás után amikor jön a peak terhelés, akkor az adatbázis node-ok pár óra működés után sorra megborulnak.
Olyanra láttam már példát, hogy maga a termék nem hozta a hozzáfűzött reményeket, de ekkor sem a fejlesztőknek kellett a fizetésükből kigazdálkodni az elpocsékolt milliókat, hanem a marketing osztályról az ötletgazdát rúgták ki, aki hasraütéses alapon ígérte meg a befektetés megtérülését, tesztelések és mérések helyett. És persze ha rendesen A-B tesztekkel kimérte volna, hogy jó lesz a cucc, és mégis befürdés lett volna az eredménye, akkor őt se rúgták volna ki, betudták volna a normális üzleti kockázatnak.

Egyszóval nem tudok olyan helyzetet elképzelni, hogy gebasz van, anyagi kár keletkezik, és ettől bárkinek a fizetéséből levonnak (ha nem az volt, hogy Gipsz Jakab szerelmi bánatában összetört valamit, letörölt valamit, stb. Ilyen esetben persze Jakabnak kell a munkaszerződésében meghatározott kártérítést és egyéb retorziókat lenyelnie).

Ha esetleg van konkrét példád, a gebasz-kár-levonás dologra, akkor beírhatnád, aztán meglátjuk, hogy mit gondolunk róla.

disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.

Valahol a valaszok kozott irtam. Vontak a fizetesembol a hibam okozta kar szerzodesben definialt maximum osszeget. Honapokig. Es igazabol csak egy feltetel maradt ki egy sql-bol, csak mire kiderult mar kozjegyzo hetelesitette a sorsolast. 10+ embernek kellett a Moszkvai foci dontore szallas, belepo, repjegy par nappal az esemeny elott. Nem volt valami olcso mulatsag.

En meg ugy tudom ezt elkepzelni, a kosaras peldanal maradva. Hogy van az edzo, a seged edzo, a masszor, a manager, a center, a vedekezok, a tamadok, a 3pontos dobok, a zsakolok, stb. Egy rakas szerepkor. Es persze egy csapat, de mindenkinek megvan a feladata. Es ha buknak egyutt buknak, ha nyernek egyutt nyernek. De ha valaki elhibazza a 3 pontost minden alkalommal, akkor lecserelik, mert pontosan merik, hogy melyik terulet hogyan teljesit. A palyan levo 5 ember neha szerepet cserel egy kis idore, ha valami miatt ugy hozza a sors, de egyreszt ezek nem hosszutavu cserek, masreszt a centert nem teszik be seged edzonek. a 3 pontos dobo meg nem maszirozgatja a vedokat.

Es amikor nem gyoznek, azt mondjak a sajtoban, hogy elbuktuk a meccset, es mint csapat nem tudtunk teljesiteni, de az oltozoben ugy lecseszik a zsakolo embert, hogy folyton kiszedtek a kezebol a labdat mint a csuda. Es kirugjak az edzot, ha nem jonnek a gyozelmek. Valamint nem fog almatlanul forgolodni a masszor, mert a center ossze-vissza kuldte a jatekosokat.

Es igazabol csak egy feltetel maradt ki egy sql-bol, csak mire kiderult mar kozjegyzo hetelesitette a sorsolast. 10+ embernek kellett a Moszkvai foci dontore szallas, belepo, repjegy par nappal az esemeny elott

Érdekes. Nem szándékos károkozás esetén nem láttam még ilyen kártérítést. Lehet, hogy cégtől függ, de amilyen fejlesztéseket látok, ott jellemzően nem az van, hogy egy ember egyedül készít valamit és aztán azt senki más nem nézi meg. Kb. a minimum létszám esetén is az van, hogy egy ember megtervezi az üzleti igény szerint mit kellene csinálni és implementálja. Van egy másik ember, aki átnézi az első által készített kódot, és van egy harmadik ember, aki teszteket végez. Ha mindhárom úgy gondolja, hogy kész, akkor mondja ez a kb. 3 emberes team, hogy kész a cucc. Ezután még a megrendelő is ellenőrzi, hogy úgy viselkedik-e a cucc, ahogy kérte, és ő dönti el ennek a tesztnek a végén, hogy megy-e élesbe vagy nem.

Korábban is akartam írni, hogy kicsit másról beszéltek itt többen, mint amiről én eredetileg írtam, de ez egy jó példa, hogy lássuk a különböző felelősségeket.
Szerintem egy team felelőssége kb. az, hogy kommunikálják, hogy mikorra várható, hogy kész lesz a cucc, tegyenek meg mindent, amit lehet, hogy elkészüljenek a megígért időpontra, az általuk készre jelentett cucc technikailag megfelelő legyen, illeszkedjék a rendszer többi részéhez és menjen át a user acceptance teszten.
A megrendelő felelőssége meg az, hogy a UAT során ellenőrizze, hogy a cucc úgy működik, ahogy azt akarta.

Ebben a példában a pénzügyi felelősséget a megrendelő vállalja, ha a cucc rossz, és a moszkvai foci döntőre baromi sok embert kell kiutaztatni drágán, akkor ő volt az, aki az UAT során nem vette észre a hibát. Az ő döntése volt, hogy menjen élesbe.

Amikor én fent a team felelősségéről írtam, akkor egyáltalán nem pénzügyi felelősségről beszéltem (és nem is szoktam ilyenre példát látni). Az egyéni felelősség vs. team felelősség számomra azt jelenti, hogy ha a termék nincs kész a megígért időre, akkor nem mondjuk azt, hogy mert a Kati szabira ment, vagy mert Józsi lassan dolgozott, hanem azt mondjuk, hogy sorry, azt gondoltuk, hogy kész lesz, de nincs kész. Nem vettük figyelembe a tervezésnél a valós team kapacitást és a feladat nehezebb volt, mint amilyennek eredetileg gondoltuk. Aztán ebből a team tanulhat, legközelebb, ha valaki szabira megy, akkor nem fognak annyira bátran megígérni mindent, illetve ha valami lassan halad, akkor azzal menet közben megpróbálhatnak valamit kezdeni.

A kosárlabdás példa alapján jól látod, nem arról van szó, hogy ha valaki rosszul dolgozik, akkor ez nem derül ki és nem fogják lecserélni az embert. De ez egy másik aspektusa a dolognak. Ezt mondjuk én nem is felelősségnek hívnám, ez egyszerűen csak a team "üzemeltetése", ahogy írod, kell gyúró meg sportorvos meg edző meg miegymás, hogy a csapat maga üzemszerűen működni tudjon. És ha Gipsz Jakab mindig mindent feleolyan lassan csinál meg, mint a másik ember, aki meg tudná ugyanazt a feladatot csinálni, plusz Jakab kódja olvashatatlan szar, ami tele van hibákkal, akkor előbb-utóbb Jakabot lecserélik. Láttam arra példát, hogy az "edző" nem látta azt, hogy Jakab mennyire vacak, és a team többi tagja, akiknek erőn felül kellett dolgozni, hogy Jakab után lapátolják a szart, szóltak nekem, hogy szóljak az "edzőnek", hogy Jakab nélkül gyorsabban haladnának. Így is lett. De pont ebben is a team teljes felelősségét látom. XY, aki mondjuk tesztelő, nem mondja azt, hogy szarok rá, hogy Jakab hogyan fejleszt, mert az a fejlesztők dolga. XY is a team tagja, ő is felelősséget visel azért, hogy nincs kész a termék, és ő is látja, hogy Jakab kódját folyton vissza kell dobnia, szóval amikor arról van szó, hogy mit lehetne javítani a teamen, hogy sikerüljön időben leszállítani dolgokat, ő is azt fogja képviselni, hogy Jakabbal kezdeni kell valamit. Valószínű ő nem fogja tudni, mik a lehetőségek és mi a legígéretesebb ezek közül, de mivel ő is érintett, ő is ott lesz és aktívan megpróbál valamit tenni a dolog érdekében.

disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.

"Lehet, hogy cégtől függ" igen, en sem mondom, hogy altalanos

define: "mindent, amit lehet"

"a pénzügyi felelősséget a megrendelő vállalja" ok is vallaltak, hidd el a tolem levont osszeg toredeke volt a karnak. Annyit vontak, amit a torvinyi keret engedelyezett, mert en ugye effektiv 1000 Ft-ot kerestem netto a cuccal. De nezz utanna, valamilyen mertekben a munkavallalot lehet terhelni es a fizeteset visszatartani.

"De ez egy másik aspektusa a dolognak" igen, te a jogilag nem merheto, egyebkent is moralis alapokon nyugvo felelossegre gondolsz. Igen vegulis a csapat a felelos azert, hogy kimenjen a cucc. Es a csapat nem teljesitett, ha megsem. Egy mindenkiert, mindenki egyert romantikus tema. Amirol en beszelk, az az, hogy vannak felelosok/szerepkorok es a szerepkor mindig egyeni felelosseggel is jar. De ha csak egy emberen van a szerepkor, akkor teljes mertekben ove a felelosseg, ha ketton, akkor 50-50 es igy tovabb. Es vannak osztott szerepkorok, pl koder.

De nezz utanna, valamilyen mertekben a munkavallalot lehet terhelni es a fizeteset visszatartani.

Persze, nekem is volt olyan szerződésem, amiben konkrétan le volt írva, hogy ha én kárt okozok, akkor mennyit és hogyan lehet levonni. Viszont az, hogy én kárt okozok, azt jellemzően egyik helyen se azt jelentette, hogy egyszerűen hibát vétek munkavégzés közben. Mondom, olyanokat mondott példának a HR-es, hogy valaki valamit összetör az irodában, vagy ilyesmi. Nem azt, hogy a szoftver összeomlik terhelés alatt vagy adatvesztés lép fel. Ezek a dolgok a munka rendes részét és kockázatát jelentették.

Olyan esetben persze el tudnék ilyesmit képzelni, ha valaki nem alkalmazottként dolgozik, hanem mondjuk magánvállalkozó*, vagy esetleg egy apró cég, akik egy saját új terméket akarnak piacra juttatni, van egy darab programozó, és ha valami nem megy, akkor könnyű megtalálni ezt az embert.

*Bár amikor contractor voltam, a cégek elvárták, hogy legyen felelősségbiztosításom, szóval ha én okoztam volna valami gebaszt, az se saját zsebből ment volna.

disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.

Ez a csapat, ami DevOpst csinál, az miután kifejleszt valamit, nem adja oda valaki másnak, hanem megcsinálnak minden lépést, ami szükséges, egészen addig, hogy élesbe feltelepítik a cuccot. És ezután ők csinálják az éles támogatást is, ha gond van, ők nézik meg, hogy mi van a logban, mi látszik az éles környezetben. Aztán kitesztelik, átnézik, kijavítják, javított változatot kiteszik élesbe.
 

Amit felvázoltál az egy bizonyos méretű projektig működik, ameddig a fejlesztés, üzemeltetés és support nem bontódik szét több csapatra.
 

Pl az IBM cloud az nagy projekt vagy kicsi? Annyi csapat van, hogy megszamolni is nehez :) Es szetvalnak szerepkorok. Eppen ezert az uzemeltetes uzemeltet, azaz PaaS-t biztosit az appoknak. A fejleszto csapatok alkalmaasokat fejlesztenek, az sre csapat felugyeletet lat el, stb. Es pont ezert van arra szukseg, hogy akik vagjak az alkalmazast, azok keszen adjak at a cuccot. Csak ahhoz meg kell uzemeltetesi tapasztalat. Na bumm.

Amit felvázoltál az egy bizonyos méretű projektig működik, ameddig a fejlesztés, üzemeltetés és support nem bontódik szét több csapatra.

Ahogy én látom, a DevOps pont az az irány, hogy ahol eddig külön csapat volt a fejlesztés, üzemeltetés és support, ott lebontják a határokat és egy kézbe kerül minden terület.

A termék és a rajta dolgozó emberek szétosztása másképp történik. Nem feladatok szerint vannak elosztva, mint ahogy írod, hanem pl. egy csapat a termék egy kicsi szeletéért felel, viszont azért a szeletélt teljes mértékben. Dev + Ops + Support.

De abban igazad van, hogy nem mindenhol ezt az irányt választják, és sok helyen a mai napig úgy van szervezve a munka, mint ahogy írod. Mert nagy a projekt, és nem akarják / tudják máshogy szeletelni. Viszont ezt nem is hívom DevOps-nak.

disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.

Ezt mind szoktam volt csinalni, de nekem is a harmas a kedvencem, atlatni, atszervezni es szepen kifesulni azt ami a 99.99% szamara magic zen kung fu master jedi level.

Ez van.

Akkor tehat legkozelebb tudom mondani, hogy sajnos csak 18 ev devops tapasztalatom van.

Every single person is a fool, insane, a failure, or a bad person to at least ten people.

Cégtől függ.

Én eddig öt kategóriát láttam, egyik se fedi a DevOps fogalmat:

1, Olyan üzemeltető, aki tud fejleszteni is, leginkább script nyelveken, de érti az üzemeltetett alkalmazás nyelvét és platform eszköztárát.

2, Olyan fejlesztő, aki tud üzemeltetni is, képes úgy fejleszteni, hogy az üzemeltethető legyen, képes összerakni akár egy éles környezetet is.

3, Fejlesztői infrastruktúra üzemeltető, aki menedzseli a cég azon rendszereit, amin a fejlesztők dolgoznak.

4, Cloud üzemeltető, aki a cég felhős dolgait fejleszti és működteti.

5, Fullstack balfasz, aki egyedül csinál mindent egy kis cégnél egyedül IT alkalmazottként.

 

A DevOps fogalom viszont egy olyan fejlesztő, tesztelő, üzemeltető és opcionálisan product owner melósokból álló csapatot jelent, akik fizikailag és logikailag össze vannak zárva és egy termék teljes életciklusa rájuk van bízva és csak azzal a termékkel foglalkoznak. Na, ilyennel eddig nem találkoztam.

Engineer tehát nem rendszergazda hanem rendszermérnök. A DevOps pedig azt jelenti hogy milyen munka környezetben, csapatban, mentalitással fog dolgozni. Várhatóan fejlesztés közeli teendők, sok esetben felhő alapon, CI/CD tologatás, scriptelés, de semmiképpen konkrét fejlesztés.

Nálunk azt jelentette, hogy egyik héten fejlesztő, és belső használatú adatfeldolgozó alkalmazásokat írt, aztán másik héten operations-t végzett, tehát a production szerveren futó alkalmazásokat felügyelte, illetve bármi hiba esetén azonnal beavatkozott, hogy -lehetőleg- az adatszolgáltatási határidők lejárta elött megfixálja, illetve lefuttassa az elhasalt alkalmazásokat. És a lehetséges alkalmazások is több nyelven készültek, több szerveren futottak, szóval elég komplex feladat tudott lenni.

Ha én DevOps-ot látok leírva, akkor DevOps-ra gondolok. Viszont jellemzően a hirdetések feladói a sima rendszergazdákat keresik DevOps Engineer címzéssel.

A lényeg, sosem lehet egy munkakör neve alapján tudni, mit keresnek, el kell olvasni a részleteket.

disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.

A lényeg, sosem lehet egy munkakör neve alapján tudni, mit keresnek, el kell olvasni a részleteket.

+1, voltam már Associate (aki Scrum Masterként dolgozott), Szellemi foglalkozású alkalmazott III. (aki hatósági ügyeket intézett), Business Analyst (aki C#-ban fejlesztett), IT Application Developer (aki business analyst volt), stb.

A beosztás semmit sem jelent, még az álláshirdetés tartalma sem különösebben garancia semmire. :D

A beosztás semmit sem jelent, még az álláshirdetés tartalma sem különösebben garancia semmire. :D

Sajnos ez tényleg így van.

Pl. jelentkeztem egy Agile Deliery Manage cimkéjű állásra, a JD jó volt, az interjú során végig Agile-ról beszéltünk, és aznap visszahívtak, hogy tetszett az Agile tudásom, szerződést ajánlanak, többet fizetnének, mint amennyit kértem.

Aztán munkába álltam, és egy hónap alatt két waterfall projektet adtak, az egyikben egy darab fejlesztő dolgozott csak, a másikban 2 ember. Aztán az 1 hónap után felmondtak, mert az egyik ügyfélnek nem tudtam meggyőző érveket hozni, hogy miért is kellene CRM-be beruháznia (úgy, hogy a CRM-ről keveset, az ügyfél iparágáról meg kb. nullát tudok). A 1 hónap alatt 1 percet nem kellett Agile témakörben bármit csinálni.

disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.

Pompás hely lehet ahol 1 hónap alatt átlátták mihez nem ért a frissen felvett embet, főleg h. 1 hónap alatt egyik-másik helyen meg az összes akkóuntot se kapod meg amivel mindenhova be tudnál lépni ami a munkádhoz kell. Majd írd már meg a cég nevét, véletlenül se keveredjek hozzájuk.

Igen, hát érdekes volt.

Lehet, hogy csak belemagyarázom*, de úgy gondolom, hogy ők követtek el komoly hibákat vezetői szinten. A hibáknak következményeik lettek**, és a kisfőnöknek egyszerűbb volt engem elküldeni, mint azt mondani, hogy hát, igen, ezt én basztam el.

A cég neve Amido egyébként.

*: A felsorolt hibák és hiányosságok között voltak valósak és olyanok, amiket nem érzek saját hibámnak. Valóban eléggé összecsapott volt a prezentáció, de egy nappal a bemutatás előtt mondta egyáltalán ez az igazgató srác, hogy holnap prezentálnod kellene. Valóban elkezdhettem volna máshogy, jobban a prezentációt, ezt aláírom. Ugyanakkor nem ezen úszott el a projekt. Engem hibáztatni azért mert nem adtam az ügyfél számára a prezentációban olyan példákat, amik hatására azonnal megrendelték volna a rendszert, szerintem megint nem korrekt. Amikor ideadták a projektet és átbeszéltük, hogy mi kell (prezentációt nem említette akkor), a felsorolásból mindenre azt mondtam, hogy OK, kivéve amikor azt mondta, hogy példákat kell összeszednünk, hogy miért lesz ez jó az ügyfélnek. Akkor ott mondtam, hogy se CRM tapasztalatom nincs, se az ügyfél domaint nem ismerem, én nem fogok tudni ilyen példákat. Megkérdeztem, honnan jönnek majd ezek, vajon ő tud-e ilyeneket. Erre azt mondta, hogy a fejlesztőm az jó srác, majd ő készít példákat. Készített is, csak az ügyfél nem jött izgalomba ezektől. (Hozzáteszem, hogy eszméletlenül jó példák esetén se vagyok biztos benne, hogy az ügyfél megrendelte volna a terméket, mert a prezentáció során eléggé az volt a hangulat, hogy OK, de minek egy új rendszer drága pénzért, ami összekapcsolja az adatokat innen-onnan, miközben ezek az adatok már most is megvannak, és egy kis SQL-lel mi magunk is össze tudjuk kapcsolni, ha akarjuk). A harmadik dolog egy szubjektív vélemény volt, az igazgató srác szerint nem tudtam eléggé tanácsadóként dolgozni/viselkedni. Nem tudom, mik voltak az elvárásai, de akkor már kb. 15 évet dolgoztam tanácsadóként és jellemzően nem így gondolták a korábbi főnökeim.
**: A két "projektből" az elsőben az ügyfél szerintem nem rendelte meg a rendszert, ami miatt elég nagyot csalódtak.

+1 a tulaj meghirdetett egy Agile pozíciót, interjúztatott és kikérdezett Agile dolgokról, majd szerződést ajánlott. Az igazgató srác, akivel együtt dolgoztam ezen a projekten, teljesen más területhez értést várt tőlem, a feladatok, amiket adott, semmi Agile dolgot nem tartalmaztak. Voltaképp baromi nagy szerencse, hogy korábban kb. 10 évet dolgoztam olyasmi tanácsadó projekteken, mint amit ő adott nekem, mert ha ilyen tapasztalatom nem lett volna, csak kizárólag Agile, akkor ez alatt az 1 hónap alatt kb. sehova se jutottunk volna, pilot se lett volna és prezentáció se.

disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.

Arra gondolok, hogy ezek sem tudják, mi a DevOps.

en mar 20 eve is azt mondtam, csak az lehet jo rendszergazda aki programozni is tud, mert az erti meg a rendszer mukodeset. aki egy hibara (legyen az forditasi error, futasi hiba vagy pl. eroforras problema stb) csak guglizni tud, es nem kepes belenezni a forraskodba es feltarni a hiba okat, az max operator...

sokaig azt hittem, ezt hivjak devops-nak, de manapsag mar minden IS az :)

A'rpi

De ez fordítva is igaz, és akkor nem kéne fejlesztővel hisztizni (true story), hogy a C: gyökérbe létrehozott dezso.txt miért nem jó ötlet és, hogy nagyobb környezetben egy mappán olyan borzalmas dolgok vannak, mint a jogosultság :)

A DevOps Engineer egyébként nem Columbo felesége?

Senkinek nincs köze világod belsejéhez, neked sincs közöd mások életéhez, csak az Irgalom útján van közöd, Istenektől rendelt kötelességed.

ne is mondd... napi szinten vitatkozom az ilyen idiotakkal, hogy aszondja neki a laptopjan a WAMP alatt mukodik ez a php takolmany, az eles szerveren meg nem, ergo kovetkeztetes: szar a szerver.  pedig nem, csak case sensitive :)

a bestof eddig az volt, ahol a php cucc include-olt a c:\akarmi\bigyoka.svg-t a fooldalon. ez az o gepen jo volt, a szerveren meg nyilvan nem, de mivel htaccessbol minden ismeretlen urlt az index.php-re redirectelt, szepne vegtelen include loopba kerult, igy kb 1 percig toltotte a fooldalt. persze en es/vagy a szerver volt a hulye, nem a tisztelt developer banda...

Igen, ez nagy probléma, ahogy az orosz rendező is mondta:

Ha kijelentek valamit, nem kötelességem azt bizonyítékokkal alátámasztani. Ha mások ennek ellenkezőjét állítják, hogy megcáfoljanak, akkor nekik kell ezt bizonyítaniuk. Nem így szokás?

A fenti ábra is mutatja, hogy sajnos de, így szokás, bár ez csak annak szívás aki nem a hülyeség oldalán áll.

UI: Engem mondjuk az a része is érdekelne, hogy ilyen "expert" kollégákkal hogyan lehet profitot termelni? Mi a titok? :)

Ó, ilyen sztorik nekem is vannak, de kicsit több mint fele részben üzemeltetőkkel.

A kedvenc visszatérő sztorim az, hogy nem megy az izé, felhívom, hogy

- Nem megy az izé, mert szerintem szmötyi van a bigyón.
- Várj, megnézem... nem nincs szmötyi a bigyón.
- Hm... oké.

Pár órás szopás, hibakeresés, log és forrás elemzés után:

- Megnéztük, még mindig nem megy az izé, szóval szerintem szmötyi van a bigyón, nem lehet mástól.
- Hm... megnézem, nem nincs szmötyi a bigyón.
- Pedig mi már minden mást kizártuk.
- Hm... és most?
- Ó, megjavult, mit csináltál?
- Uhm... semmit.

Persze, hogy szmötyi volt az bigyón.

nem vagyok ra buszke, de hasonlo azert velem is elofordult uzemeltetoi oldalrol, igaz nem fejlesztokkel hanem ugyfellel...

(felhiv hogy nem megy a valami, nezzek ra a szerverre, ranezek, latszolag oke, mondom neki nem szerver hiba. oke, akkor keresik mashol. aztan kesobb eszembe jut meg valami, ami okozhatja, es tenyleg szerver gond volt...)

Nem akarok kötözködni, de nálam ez kiverte a biztosítékot.

Kedves gyuri23 és arpi_esp!

Nálam az álláspontotok több sebből is vérzik.

1. en mar 20 eve is azt mondtam, csak az lehet jo rendszergazda aki programozni is tud, mert az erti meg a rendszer mukodeset.

2. aki egy hibara csak guglizni tud, es nem kepes belenezni a forraskodba es feltarni a hiba okat, az max operator

A második mondattal egyet tudok érteni, de az első az erős túlzás.

Kurvára nem mindegy milyen cégnél vagy rendszergazda. Pl egy földhivatalban elegendő egy okj szoftverüzemeltető tudás erős word és egy gyengén középszerű excel ismeretekkel, meg toonercserlési tapasztalatokkal. A legnagyobb kihívás egy nyomtató telepítés usb porton és a kábel kontakthiba felismerése, valamint a klaviatúra szakszerű tisztítása és cseréje.

Egy komoly szoftverfejlesztő multinál már az adott szoftverek működésének alapvető ismerete és az adott szoftver Hello-bello Word!-ig való programozása elegendő kell, hogy legyen egy rendszergazdának. Esetleg egy kulabá megjelenítése parancsikonban.

Szerintem a jó rendszergazda ismérve a logok és dokumentációk értelmezése, józan paraszt logika, jó problémamegoldó képesség, kihívás szeretése, gyors tanulás és a hatékonyság.

Amit itt ebben a párbeszédben műveltek ez bőven kimerítette a nagyképűség és a sznobság minden formáját.

Ezen szerintem Trey is megsértődhetne, de inkább jobbnak látja azt, hogy nagyokat hallgat.

De nagyon örülnék, ha a szememben az a három csodabogár  (a mesterhármas) - akikből kettőt még bírok (locsemege, raynes) és egyet már kevésbé (Mr. Sznob programozók gyöngyszeme gelei from London) is kifejtené álláspontját, mert ez a vélemény szerintem tűrhetetlen.

Azzal a részével egyetértek a dolognak, hogy különböző helyeken különböző szinteket kell megugrani, épp ezért lenne jó, ha ezeknek a szinteknek lenne valami saját neve, ne mindenki "rendszergazda" legyen a tonercserélő iparostól az architectig. Uram bocsá' informatikus, és akkor belevehetünk a halmazba a webfejlesztőktől a business analystig mindenkit, aki látott már számítógépet.

Na most hogy ez a gyakorlatban hogy kivitelezhető, azt még nem tudom, és erre remek példa a DevOps, ami elvileg egy szűkebb halmazt jelölne ki. De nem, mert már ebben a threadben sincs különösebb konszenzus, hogy mit is akar jelenteni.

Szerintem a jó rendszergazda ismérve a logok és dokumentációk értelmezése, józan paraszt logika, jó problémamegoldó képesség, kihívás szeretése, gyors tanulás és a hatékonyság.

Kb. +1, ez lenne egy tök jó alap, ahonnan el lehet térni felfelé és lefelé is, és mindkettőre van igény valahol. 

Mr. Sznob programozók gyöngyszeme gelei from London

A Londont kikérem magamnak, összesen 3 napot voltam életemben, azt is két részletben. :)

Egy komolyabb helyen a opsnak egyaltalan nem faladata az alkalmazasban hibat keresni. Az o feladatuk az infrastruktura biztositasa (hw, sw), amin az alkalmazas fut. Ok adjak a PaaS-t a tobbieknek. A dev csapat adja at az alkalmazast uzemeltetheto allapotban dokumentalva es runbookokkal megtamogatva. Az sre csapat viszi tovabb az alkalmazast, garantalja az elerhetoseget, szamolgatja a replikakat, kiesesbol adodo rizikokkal jatszik, stb. Ha hiba jon, akkor a runbook alapjan belerug parat, es ha meg mindig nem mukodik, akkor riasztja a dev vagy ops csapatot attol fuggoen hol eszleltek a hibat (bar ugye az opsoknak addigra mar illett eszrevenni, hogy valami nem megyen). Az adott csapat megkeresi es elharitja a hibat. Es itt jon a csavar a tortenetben, hogy a dev-eknek altalban lovesuk sincs az uzemeltetesrol, ok Java, Go, whatever programozok. Hogyan lesz az alkalmazas kulcsra-keszen uzemeltetheto, naponta tobbszor releaselheto, rollbackelheto, stb? Hat erre jot valaszul az devops szemlelet, es lett igeny azokra a mernokokre, akik garantaljak ezeket a folyamatokat. Es ezert kell ertenie egy devops mernoknek

- Az alkalmazas tervezeshez (nem csatlakozhat a vegen a folyamatba, mert akkor szar lesz az eredmeny).

- A fejleszteshez, sot reszt is kell benne venni, hogy a) tudja/ismerje az alkalmazast b) uzemeltethetoseg szempontjabol kritikus dolgokat fejlesszen, c) tudjon benne hibat keresni/javitani es d) garantalja a megfelelo metrikakat, loggolast, stb.

- Az o feladata az automatizalt pipeline tervezese/kialakitasa, hiszen valahogy garantalni kell a program mukodeset release elott es az artifactok gyartasat minden compilance kovetelmennyel egyutt.

- Valamint a cel PaaS-nek megfeleloen deklarativan es reprodukalhatoan eloallitani a szukseges dolgokat a futtatashoz (yaml descriptorok, imagek, gitops repok, stb).

- Es nem utolso sorban a deveknek segiteni a lokalis fejlesztes kialalkitasaban.

 

Es ezt nem csak elmeletbol tudom, hanem nalunk ez igy megy, es en konkretan ezt csinalom, es nem is ma kezdtem.

Azt is latni kell, hogy a kultura terjedeseval egyre tobben szedik fel a szukseges tudast, valamint egyre egyszerubbek az eszkozok, minden eltolodott a PaaS-hez. Amikor elindult ez a devops laz, opsworks+chef-fel provisioneltem nodeokat, es mindenfele magiaval jutott az artifact megfelelo helyere, es kezzel programoztuk a release folyamatokat meg vettuk ki a loadbalancerbol az epp aktualis node-ot. Ehhez kepest ma kitesszuk a Kube Deploymentet egy repba, imaget a registrybe es gitopssal befrissul az egesz (a Kubernetes meg elintezi az LB-ket az ingresseket, a processzek kicsereleset, stb). Szoval egyre kissebb az igeny a devops ninjakra, ami jo, hiszen ez volt a cel valahol.

Ezt trollkodasbol kerdezed? :D

Nem. Altalaban nem ul minden 5-8 csapatban egy solution architech. A devops tamogatja az o munkajat, reszt vesz a tervezesben. Ezert is irtam, hogy ertenie kell hozza, es nem azt, hogy o csinalja. De ez nagyon mulik a szervezeti felepitesen. a SA altalaban business es technikal, aztan jon valami masik architech aki meg full technikal, es aztan jon a csapat, aki implementacios szinten tervez meg hianyzo dolgokat. De jo esetben valamifele kommunikacio reszekent esik ki a vegso megoldas.

Ezeket írtad, ezek közül melyiket nem látod solution architect feladatnak?

1, Az alkalmazas tervezeshez (nem csatlakozhat a vegen a folyamatba, mert akkor szar lesz az eredmeny).
2, A fejleszteshez, sot reszt is kell benne venni, hogy a) tudja/ismerje az alkalmazast b) uzemeltethetoseg szempontjabol kritikus dolgokat fejlesszen, c) tudjon benne hibat keresni/javitani es d) garantalja a megfelelo metrikakat, loggolast, stb.
3, Az o feladata az automatizalt pipeline tervezese/kialakitasa, hiszen valahogy garantalni kell a program mukodeset release elott es az artifactok gyartasat minden compilance kovetelmennyel egyutt.
4, Valamint a cel PaaS-nek megfeleloen deklarativan es reprodukalhatoan eloallitani a szukseges dolgokat a futtatashoz (yaml descriptorok, imagek, gitops repok, stb).
5, Es nem utolso sorban a deveknek segiteni a lokalis fejlesztes kialalkitasaban.

"Solution architecture activities take place during solution ideation, solution design, and solution implementation. During ideation, solution architecture establishes the complete business context for the solution and defines the vision and requirements for the solution. During design, solution architecture elaborates potential options, which may include RFIs, RFPs or prototype development. It selects the optimal option and develops the roadmap for the selected solution. During implementation, solution architecture communicates the architecture to the stakeholders, and guides the implementation team."

En nem irtam "complete business context" meg "defines the vision and requirements for the solution" "RFIs, RFPs or prototype development" "develops the roadmap for the selected solution" "solution architecture communicates the architecture to the stakeholders, and guides the implementation team" ilyenek nem csinal egy devops. legalabbis akiket ismerek egyse csinal ilyeneket. A devops ennel ketkezibb munkas nem, amit kiad a kezebol,m az nem valami vizio, vagy poc. Konkretan futtathato cucc.

Csak értelmezd, ami le van írva és illeszd bele a megfelelő kontextusba egy nagyvállalati struktúrában.

En nem irtam "complete business context" meg "defines the vision and requirements for the solution" "RFIs, RFPs or prototype development" "develops the roadmap for the selected solution" "solution architecture communicates the architecture to the stakeholders, and guides the implementation team" ilyenek nem csinal egy devops. legalabbis akiket ismerek egyse csinal ilyeneket.

Nem csinál prototípusokat? Kérdés nélkül elfogad minden üzleti igényt? Nincs víziója a rendszer követelményeiről, működéséről és megoldásokról? Nincs roadmap a fejében, hogy mit mikor kell befejezni, kiadni? Mi mivel függ össze? Nem terelgeti a fejlesztőket a helyes irányba? Egy szót nem beszél az üzleti területtel? Nem mondja el, hogy milyen technológiát miért támogat? Nem dönt technológiákról? Ha ezeket mind kihúzod, nem sok marad ám, azon kívül, hogy felhőben turkál és konkrétan üzemeltet.

A devops ennel ketkezibb munkas nem, amit kiad a kezebol,m az nem valami vizio, vagy poc. Konkretan futtathato cucc.

Akárcsak a solution architect melója az implementációs szakaszban, csak azt már nem idézted vissza és kivágtál egy csomó értelmező kifejezést.

Vannak atfedesek, de egy csomo dolgot; uzleti igeny, roadmap, nem o tervezi meg. Segit a donteshozatalban (elmondja milyen technológiát miért támogat). De pl nem beszel az uzleti terulettel, az a SA dolga. 

"nem sok marad ám, azon kívül, hogy felhőben turkál és konkrétan üzemeltet." ezek szerint az SA egy kesz megoldast ad at a csapatnak? Amivel mar nincs emmi tennivalo csak kitenni a felhobe?

Talan itt irtad le a lenyeget: "az implementációs szakaszban" az SA egy darabig vesz reszt a fejlesztesben. A devops meg eletcikluson at kiseri a fejlesztest.

De visszakerdezek, az SA fogja megcsinalni a pipelinet, hogy az uj fejlesztes konfigja elerheto legyen egy git repoban, hogy aztan a CD az alapjan automatizaltan befrissitse az alkalmazast? Vagy tolti fel az imageket a registrybe, netan rotalja a credentialt hogy le is lehessen szedni onnan? O fogja beallitani a pod meg network security beallitasokat amik kellenek az alkalmazasnak, hogy eles kornyezetben is tudjon futni? O lesz az aki a metrikakat nezve feltarja a szuk keresztmetszeteket az alkalmazasban?

 

Az operator nem tudja ezeket megcsinalni meg fingja sincs mire van szuksege az alkalmazasnak, milyen servicekkel beszelhet, melyek a kritikus servicek, Milyen authentikacios dolgok, secretek kellenek, stb. Ezek ugyanis alkalmazas szintu dolgok, es lehet 2000 ilyen alkalmazas fut az infran, amit biztosit.

A fejleszto sem tudja megcsinalni, mert fingja sincs a pl a pod securityrol, meg service meshrol, mutual TLSrol, meg monitoringrol, meg hasonlo dolgokrol, amik az eles rendszeren futnak meg az alkalmazas korul. Ezek tipikusan operational jellegu dolgok.

Az SA sem fogja megcsinalni, mert o architect, es bizonyos szintig foglalkozik az alkalmazassal

Tehat csak kene (legalabb 1) valaki a csapatba, aki tudja hogyan kell a mit uzemelteteni.

 

Rank levetitve nem ertelmezheto, mert

Nalunk van CTO, meg Cloud architect, meg IKS architect, meg Solution Architect, meg Security architect, meg Network architect meg a Network tech lead. Ok az uzlettel egyeztetve kitalaljak a viziot meg a roadmapet, meg ilyeneket. Elkeszul a high level concept dokumentacio. Aztan a Network tech lead meg megosztja a concept docot az egesz csapattal, amit a fejlesztok,devopsok jol megkopkodnek. Koroz parat a cucc, es elkeszul a vegleges high level concept doc. Ez alapjan a csapat egy resze megtervezi a konkret implementaciot, es elkeszul egy low level concept doc (ha kell POC), amit jol megkopkodnek fentebb meg mas csapatok (perf team, upgreade team, ops team, ... kit tudja hanyan)  :) Aztan a csapat nekiall es lefejleszti, teszteli, automatizalja, majd vegul uzemeltetheto allapotban atadja a fejlesztest az sre teamnek, es pont.

Talan itt irtad le a lenyeget: "az implementációs szakaszban" az SA egy darabig vesz reszt a fejlesztesben. A devops meg eletcikluson at kiseri a fejlesztest.

Nem, a solution architect (is) végigkíséri a teljes életciklust, folyamatos fejlesztési ciklus esetén folyamatosan.

De visszakerdezek, az SA fogja megcsinalni a pipelinet, hogy az uj fejlesztes konfigja elerheto legyen egy git repoban, hogy aztan a CD az alapjan automatizaltan befrissitse az alkalmazast? Vagy tolti fel az imageket a registrybe, netan rotalja a credentialt hogy le is lehessen szedni onnan? O fogja beallitani a pod meg network security beallitasokat amik kellenek az alkalmazasnak, hogy eles kornyezetben is tudjon futni? O lesz az aki a metrikakat nezve feltarja a szuk keresztmetszeteket az alkalmazasban?

Nem és igen. Ezek közül a CI/CD üzemeltető feladat az, ami általánosságban nem fér bele a solution architect feladatkörébe, a többi viszont igen. De néha a CI/CD is solution architect feladat, volt ilyen is már.

Tehat csak kene (legalabb 1) valaki a csapatba, aki tudja hogyan kell a mit uzemelteteni.

Ja, hogyne. Néha jól jön, de nem szükségszerű.

Nalunk van CTO, meg Cloud architect, meg IKS architect, meg Solution Architect, meg Security architect, meg Network architect meg a Network tech lead. Ok az uzlettel egyeztetve kitalaljak a viziot meg a roadmapet, meg ilyeneket. Elkeszul a high level concept dokumentacio.

Itt szerintem a "Solution Architect" inkább Enterprise Architect lesz, abból van egy-kettő darab cégenként. A solution architect emberből több van és dedikált projektekkel foglalkozik, illetve leginkább egy darab dedikált projekttel. Nem gyárt dokumentum hegyeket, hanem kézzelfogható megoldásokat ad, K+F, PoC alapján ad konkrét fejlesztési és üzemeltetési irányelveket, konkrét fejlesztési és üzemeltetési kereteket, szoftvereket, megoldásokat, akár CI/CD szinten és együtt dolgozik az adott csapattal, mind a fejlesztőkkel, mind a tesztelőkkel, mind az üzemeltetőkkel, nem elefántcsonttoronyban ül.

Ez alapjan a csapat egy resze megtervezi a konkret implementaciot, es elkeszul egy low level concept doc (ha kell POC), amit jol megkopkodnek fentebb meg mas csapatok (perf team, upgreade team, ops team, ... kit tudja hanyan)

Tehát a solution architect ezen a szinten dolgozik ezekkel az emberekkel. Nincs túl sok új a nap alatt, csak néha más címkét kapnak a dolgok.

Ok, ezek szerint en meg nem lattam SAt mukodes kozben. Igazabol IBM elott architectet se lattam mukodes kozben, bar volt aki annak mondta magat. Ezeket a dolgokat mindig a szerencsetlen csoro devops eng vitte, biztos ez a tapasztalat eredmenyezte a felreertesemet :) koszi

És akkor mit szólnátok a DevSecOps munkaköri leírásához? :)

Egyszer elmentem egy ilyen interjúra - már csak az érdekesség kedvéért is.

Hát tanulságos volt - de persze nem engem kerestek :D

Nem tudom mire vagy kiváncsi, de megpróbálom:

A tanulságos része az volt, hogy - egyébként teljesen  véletlenül - de sikerült "belsős útvonalon" bejutnom a "high security" épületükbe, közvetlenül az interjúztató "főnök" asztalához, ahol ő értetlenkedve nézett rám, amikor azt mondtam, hogy én jöttem az '' interjúra. Mert hát hogy a recepción kellene várnom, hogy valaki felkísérjen ;) - Szóval erős kezdés volt, remélem nem vonták indokolatlanul felelősségre azt az egyébként nagyon kedves lányt, aki mindezt lehetővé tettem nekem, és minden ajtón beengedett a saját kártyájával :D

Ezután jött az interjú - kezdve úgy hogy a leendő főnökein ~ 15 évvel voltak fiatalabbak, én meg 20 éve IT security szakmában dolgozom.. Ez már egyből kínosnak tűnő szituáció, merthát ugye ők felmérni igyekeztek az  eddigi tapasztalatomat... Aztán hamar kiderült, hogy amit ők securitynak hívnak az eléggé gyerekcipőben jár, a SIEM, SOC fogalmak majdnem hogy ismeretlenek voltak számukra..., és ők tulajdonképpen fejlesztőt keresnek, aki azért üzemeltetni is tud/akar, és a securitihoz is ért. :) Én vázoltam, hogy szerintem hogyan lehet ezt a kihívást megoldani.... és miért ne egy emberben keressék mindezt. Persze nem engem kerestek.

 

a DevSecOps fogalmat egyébként itt alább már jól leírta valaki, de a lényege - ugyan úgy mint a DevOps-nak -  hogy egy csapaton belül legyen az üzemeltetés, a felelsztés és a security is. Tehát, nem egyszemélyes super hero-kat kell keresni, hanem csapatmunkára hajlandó, ÉS a megszokásain változtatni képes fejlesztőket, üzemeltetőket, és IT biztonsági szakértőket. - szerintem.

Ezzel a temaval volt tele egy conf amin reszt vettem. Amugy annyi, hogy tobb a koder mindt a security expert, es tobb kontener szuletik, mint ahanyat at lehetne nezni. Foleg amiota egy rakas helyen devops van (most annak minoseget ne firtassuk). Ezert bizonyos folyamatokat be kell epiteni a pipelineba, es amit lehet automatizalni kell. Ilyen a secretek keresese a kodbazisban, sebezhetosegek keresese imagekben, nem biztonsagos configok kiszurese, security best practicek kikenyszeritese, stb. Mert _a biztonsag mindenki felelossege_

Mindkét területhez ért, de egyikben sem specialista.

Egy olyan ember, akinek a feladata az Infrastructure-as-Code alapú üzemeltetés.

sajnos a legtobbszor ezt ertik alatta. Csak ebben semmi dev nincs (marmint yaml editing, meg egy if a jinja templatben nem szamit annak). De igazabol ez csak modern ops, serintem 2020ban elvarhato egy opstol, hogy deklarativan reprodukalhato legyen amit csinal. Ez alap.

Azért a devops az nem YAML editing meg if a ninja templateben. A devopsos, ha kell, akkor Ansible playbookhoz hiáynzó modult ír, az meg programozás. Ha kell, akkor hiányzó Jenkins plugint ír.

Az, hogy deklaratívan építed fel az infrastruktúrát, az mind szép és jó, de a deklaratív leírót valaminek értelmeznie kell.

És szerintem nem a dev feladata Ansible playbookot írnia (pedig fent azt mondod, hogy a playbookot a devek adják át üzemeltetésre.). Nem, ez pont a devops feladata.

Pont ez a lényeg, hogy devopsos emberke az, aki infrastructure-as-code alapon az alkalmazás fejlesztésében (és nem utána!) részt vesz azon, hogy az alkalmazás futtatókörnyezetét felépítse. Mert a futtatókörnyezet felépítése nem az alkalmazás fejlesztései utáni, hanem közben történő dolog, az alkalmazáshoz hasonlóan egy folyamatosan változó történet, ahogy az egyes feature-ök igénylik.

"Azért a devops az nem YAML editing meg if a ninja templateben"

vs.

"És szerintem nem a dev feladata Ansible playbookot írnia (pedig fent azt mondod, hogy a playbookot a devek adják át üzemeltetésre.). Nem, ez pont a devops feladata. "

Rossz oldalról közelited meg: függetlenül attól, hogy product vagy toolfejlesztésen dolgozik, fejlesztő.

Ha a DevOps foglalkozik a build (SCM, artifact, code quality), deploy (IaC, packaging, release audit, infra és application monitoring, security hardering) feladatokkal, akkor nagyon nem lesz ideje Ansible modulokat irni.

DevOps kapcsán az egész paradigma alapjában nem hiszek: szigetszerűen, kizárólag a fejlesztőcsapattal együtt kell dolgozniuk.

"Ansible modulokat irni." tipikusan hany ilyen kell egy alkalmazasnak/servicenek, es azok milyen gyakran valtoznak? De en nem azt mondom amugy, hogy o egyedul fejleszt, a tobbiek meg nezik. De felelosseget tekintve az ove. Es abba beletartoznak az ansible modulok is, ha epp arra van szukseg. De aztan lehet csak felhasznalja a ceg egy mar az ops-ok altal megirt moduljat.

Kb. soha, ez nem volt egy életszerű példa, mert mindenre rendelkezésre áll kész modul.
Nem tudnék fejből olyan életszerű példát mondani egy szoftver lifecycle folyamatban, amit ne tudnék lefedni kész modulokkal.

Sokkal gyakoribb, hogy a CI / CD környezethez fejleszt modulokat, mert kellenek a belső testreszabott release folyamatokhoz.

De egy javában Bamboo, vagy Typescriptben Azure DevOps pluginokat fejlesztő pozíció nem DevOps.

Ez a szavazás 2020-ban a HUP-on szerintem offtopic vagy én értem félre a trollkodást/nyelvészkedést/definicioharcot.
Max a belsős recruiter intern pillázhat rá, hogy jé, ilyen ember létezik és van is nekünk belőle minden projekt közelében. 

Olyan, aki azt hiszi hogy mindenhez ért, közben meg semmihez sem igazán, és ezért nagyon veszélyes.

"Sose a gép a hülye."

Szerkesztve: 2020. 07. 22., sze – 12:16

A klasszikus startup devops a kedvencem:

Hetfon szol a devnek, hogy rossz sorting algoritmust hasznal a PHP kodjaban. A dev meg aznap javitja, performance javul.

Kedden elemet cserel az egyik ugyfelszolgalatos Mac-jenek az egereben

Szerdan uj usereket es uj replikakat csinal a MySQL-hez es lenice-olja azokat a lassabb query-ket, amik valoszinubb okai lehettek az aznapi 10 perces leallasnak. Elotte o adta ki az nginx restart es a mysqld restart parancsokat is

Csutortokon probalja elmagyarazni az ugyfelszolgalatosoknak, hogy hogy tudtak ketten egyidoben lefoglalni ugyanazt a termeket ugyanarra az idore, mikor amugy kod szinten ez (nagyjabol) ki van vedve. A nap nagy resze azzal telik, hogy segit az ugyfelszolgalatosoknak megfogalmazni a bocsanatkero levelet

Penteken nem jon be dolgozni, mert masnapos. Delutan 13:03-kor megkerik, hogy kattintson ossze egy uj usert a ceg webes adminjan. 13:32-re megcsinalja egy Chrome ablakban otthon.

Ha felmond, a legnagyobb "tudas score"-ral rendelkezo nemtulajdonos fejleszto lesz az uj devops.

Tudas score keplete: (10 - (sulyos hibak /ev)) * (cegnel eltoltott munkahonapok szama)

Ja. KKV-k viszont szeretik magukat startupnak hivni, az onbevallos verziot mondtam.

Kozigazgatasban meg vagy nincs Mac, vegkepp nincs a Mac-nek elemes egere, vagy van kulon ember aki ritkan csinal nehez feladatot, meg kulon ember, aki surubben konnyut, munkaba csak utobbinak van eselye beleszakadni, mert elobbi sokkal gyorsabban halad, mint barmilyen engedelyeztetesi folyamat.

Szerkesztve: 2020. 07. 22., sze – 16:00

Szerintem benne van a neveben: developer operatori ismeretekkel.

Developer != frontend developer

Tobb nyelvet is ismernie kell ezek kozul: Java, Python, C#, Golang, nodejs

Ismernie kell, hogy melyik hogyan kezeli a memoriat, multithreed/concurency problemakat tc. aktiv backend fejleszto.

De ismeri routerekeket, servereket, docker, kubernetes etc...

Hogy mukodik a TCP/IP...

Ebben nincs junior pozicio... 

"Developer != frontend developer"

he?

Tobb nyelvet is ismernie kell ezek kozul: Java, Python, C#, Golang, nodejs

Ismernie kell, hogy melyik hogyan kezeli a memoriat, multithreed/concurency problemakat tc. aktiv backend fejleszto.

De ismeri routerekeket, servereket, docker, kubernetes etc...

Hogy mukodik a TCP/IP...

Ebben nincs junior pozicio... 

Senki nem akarja megfizetni, hogy valaki SDN-t konfiguráljon és Docker image-eket készitsen, naprakész legyen K8-ban, miközben hatékonyan képes fejleszteni Java-ban és C#-ban és thread dump-okat analizálgat.

Már akkor összeteheted a két kezedet, ha senior Java vagy C# fejlesztőt hosszútávon képes vagy tartani, DevOps oldalon pedig olyat találsz, aki látott már CI/CD környezetet és van némi automation tapasztalata.
 

1. Ha nem ismered az infrat, eleg nehez ugy fejleszteni ra, azan jonnek a meglepetesek (lattam mar sok c# fejlesztot akik pislog amikor kiderul, hogy az kod a vegen linux-ban fut, es az bizony mashogy kezel pl directory-kat.)

2. Ha nem tudod hogy epul fel a program amit uzemeltetsz eleg nehezkes neha uzemeltetni. (operator aki nem tudja hogy nincsenek szalak a nodejs ben es nem erti miert es hol fullad be a nodejs app)

3. Ha program amit irsz, infrat managel, pl. CD/CI system, vagy egyeb infra utomatizalasi rendszer... (Ez a kedvencem)

"1. Ha nem ismered az infrat, eleg nehez ugy fejleszteni ra, azan jonnek a meglepetesek (lattam mar sok c# fejlesztot akik pislog amikor kiderul, hogy az kod a vegen linux-ban fut, es az bizony mashogy kezel pl directory-kat.)"

Nem tudok elképzelni olyan esetet, hogy nem ismered a futtatókörnyezetet (ezt sem teljes értem, de tegyük fel) ÉS ezen nem a project vezetése, hanem egy ops gyakorlattal rendelkező kolléga tud hatékonyan segíteni.

"2. Ha nem tudod hogy epul fel a program amit uzemeltetsz eleg nehezkes neha uzemeltetni. (operator aki nem tudja hogy nincsenek szalak a nodejs ben es nem erti miert es hol fullad be a nodejs app)"

Ehhez nem kellennek azok a skillek, amikről a thread szól.

"3. Ha program amit irsz, infrat managel, pl. CD/CI system, vagy egyeb infra utomatizalasi rendszer... (Ez a kedvencem)"

Akkor fejlesztő vagy azon a területen.

Leirtad a lenyeget: "Nem tudok elképzelni olyan esetet" de attol meg szamtalan ilyen helyzet van. Kubernetesen fut service meshhel a cucc es Helmmel van deployolva, es kell hozza egy mutual operator ami hozzateszi a prometheus metrikakt mindem servicehez. Elvarod a fejlesztotol, hogy ertsen ezekhez? Tudja hogyan kell lokalisan futtatni, bizonyos serviceket kimockolni, hogy elesben milyen security beallítasok vannak, mi mivel beszelgethet, ki hozza letre a certeket, hogyan rotalodnak, hogyan lesz releaselve, rollbackelve, es meg 100 dolog? Ezek tipikusan nem dev feladatok. De megneznem az ops arcat is, mikor odaadod neki a jar-t es megkered, hogy "futtasd teso 8080as a port". Szoval kell valaki aki vagja az appot, tudja, hogy milyen mas servicekhez kapcsolodhat, milyen privilegiumokra van szuksege, hogyan van monitorozva tracelve, stb. Csak ugye ezeket nem lehet az infra pontos ismerete nelkul megoldani. Es korbe is ertunk. Mikor ilyeneket kell osszekalapalni azert jo ha valaki erti is, hogy mit csinal.

lattam mar sok c# fejlesztot akik pislog amikor kiderul, hogy az kod a vegen linux-ban fut, es az bizony mashogy kezel pl directory-kat

Ja, hogy úgy...

Feltételeztem, hogy az "érteni kell hozzá" túlmutat azon, hogy a dev tudja, milyen OS-en fut majd a szoftver. Ha erről a szintről van csak szó ebben, akkor persze, nem vitatkozom. :)

Mindenbe bele lehet kotni persze :) Egy publikus cloud szolgaltatonal vagyok Kubernetes network engineer, es olyan toolokat es kontenerizalt microserviceket meg operatorokat fejlesztunk, amik a halozat kiepiteseert es uzemelteteseert felelosek. Minden fejlesztesunket tesztelve (unit, integration, pvg, functional, e2e, performance, upgrade), dokumentalva, minden compliancenak megfeleloen, automatizaltan adjuk at az sre teamnek, akik kesob felugyelik oket a sajat vagy az ugyfel clustereken. Jah es level2 supportot adunk mindenre. Napi szinten hasznalt technologiak: Go, Javascript, Bash, Ansible, Travis, Jenkins, Docker, ContainerD, Kubernetes, Calico, Operator SDK, Vagrant, Helm, Terraform, Linux, Netfilter, Network LB, Application LB, HAProxy, OpenVPN, Strongswan, Nginx, tcpdump :) Mikor mi eppen a feladat. Nem vagyok ufo, masok is dolgoznak a csapatban.

El ne felejtsem megemliteni, hogy keresunk embert, aki mindehhez ert/szeretne erteni. Meg is fizetjuk esku!

Ez volt a kiinduló setup:

"Tobb nyelvet is ismernie kell ezek kozul: Java, Python, C#, Golang, nodejs"

Amit felvázoltál azok - a Go és JS kivételével - teljesen általános Ops technológiák.
Biztos vagyok abban, hogy nálatok is vannak specializációk (nem mindenki foglalkozik mindennel) és a csapat profilja alapján azt gondolom, hogy nagyjából statikus Go és JS kódbázissal dolgoztok.

Ezek alapján ne általánosítsunk, hogy minden DevOps-nak több nyelvet kell beszélnie.

 

En vegig errol beszeltem, csak valahogy nem megy be a fejedbe. Tervezek, fejlesztek, automatizalok, minosegbiztositok es elerhetove teszem a fejlesztest reprodukalhatoan. Tudom, hogy mi fut es azt is hogy min fut. Az most egy mas kerdes, hogy mindekozben a domain amin dolgozom az Kubernetes SDN. Ez benne a meta. Magyaran nincs utannunk senki fejleszto vagy operator. Ahogy mi odaadjuk azt ugy uzemelteti az sre team. Ezert devops. Security team szokta meg atnezni, de arra is van egy rakat automatizacio beepitve a flowba a.k.a. DevSecOps.

Hat biztos lehetsz benne, hogy van tudasbeli elteres a csapatban, de ket ember visz egy featuret alltalaban, es az egyik tuti erti ezt az egeszet. Vannak implementacios kerdesek, amiket nagyobb kozossegben is megvitatunk, de nem passzolgatunk issuet jobbra-balra, szakertelem hiany miatt.

Szerkesztve: 2020. 07. 23., cs – 18:54

Szóval még midig (2020) senkinek fingja sincs, hogy miap*csa az? 

loooloololoooo

A devops olyan mint az architekt. Széles tudású szaki, aki néhány dologhoz nagyon ért, a többiről meg van annyi fogalma, hogy nem néz hülyén és tudja hol kell utánanézni a részleteknek. És ugyanaz a baj is a definícióval. Mindenkinek más a múltja, más projekteken edződött, más céges kultúrához, folyamatokhoz szokott. Azaz nincs két teljesen csereszabatos ember sem architekt sem devops vonalon.

A definíciót ezért mindenki a saját világképe alapján fogalmazza meg és ez felesleges vitát generál, mert nincs ultimate megoldás.

És mindkét területen az adott cég adott igényét legjobban lefedő embert keresik és jó esetben fizetik is meg a legjobban. Főleg ha át is tudja adni másoknak, vagy vezetni őket, mert akkor multiplikátor hatású a tudása - megvan a ragasztó a siló tudású területekhez (nem pejoratívan - nincs azzal baj, ha egy dologhoz ért az ember, de ahhoz nagyon, azaz lehet rá számítani). Minél szélesebb a tudása, annál könnyebben illeszthető be bárhová, de nem létezik mindenhez is értő ember, a tanulási képesség, és az, hogy ezt akár a napi munkán felül beletegye az ember, abszolút vízválasztó.

Ha az adott környezet korlátai között üzemeltethetetlen egy adott kód, ki a felelős? (A kérdés minden szava fontos)

A tégla gyártó munkásnak nem kell tudnia hogy szalonnasütő vagy felhőkarcoló lesz belőle. De meg kell felelnie a specifikációnak. Aminek valami szabványnak. Amit ismernie kell a tervezőnek és a kőművesnek is. És akkor az egész képes RENDSZERben működni. Ugyanez az IT, csak mivel ehhez mindenki jobban ért, a szabvány, vagy akár csak csapat szintű sztenderd az az, amire mindenki tojik. Az egyik azért, mert nem ismeri, és nem is szán energiát a megismerésére, a másik meg azért, mert ő tud jobbat. És máris születik egy olyan lokális optimumnak tűnő tárgy, ami nem illeszkedik be a nagy egészbe, és hős üzemmódban jó sok szigetelő szalaggal körbedolgozzuk hogy az ügyfél előtt azért működőnek tűnjön élesben is. 

Jó esetben az architekt azért van, hogy elméletileg képes legyen a tervezett cucc illeszkedni a nagy egészhez, miközben megfelel az elvárásoknak legyen az üzleti, üzemeltetési, anyagi, stb. A devops meg azért, hogy a lehető legmagasabb automatizálási szinttel támogassa a "fail fast" működését implementációs és üzemeltetési környezetben is, így gyakorlatilag technikailag kikényszerítve a jól működő definit, reprodukálható állapotok létrehozását és ezek közti gyors váltást. És mindkettő felelős azért, hogy megalapozottan döntsön, vagy támogassa azt, aki dönt, azaz legyen sok jó (!) mérőpont, gyakorlat és eszköz a releváns adatok gyors kimutatására.

Nálam azt jelenti a DevOps nagyjabol:

Felhon automatizalni, pipelineokat irni, ha kell egy Java osztalyt irni mert a developer lusta volt megcsinalni hogy felnyalja a envvarokat,  leforkolni github projecteket majd a Go kodokat atirni, fixalni, kiboviteni ahogy nekunk kell majd beepiteni a pipelineba, Pythonban  PoC projectet kesziteni pl. tesztekre, api tesztekre, vagy csak egy sima frontendet Flaskban, webhookokra hogy triggerlheto legyen ami nem volt, megtanulni hasznalni a felhos managelt szolgaltatasokat, linuxot optimalizalni, Terraformal deployolni amit lehet, git, Kubernetes-t csinjat binjat, manifesteket, algoritmusokat csiszolni  serverless fugvenyekkel osszekotni ami hianyzik es kell, dr-t megvalosirani, monitoringot es alertinget betolni a rendszerek ala,  tudni ezt eloadni, prezentalni es bemutatni masoknak. Nem zavarba jonni egy developer kerdesetol vagy uzemeltetotol A taskokat magadnak managelni. Tervezni es megvalositani onalloan.

Mikor a bt-hez jelentkeztem, ott a solution architect valami megfoghatatlan üzletágak közötti semmihez nem értő, de leginkább  hangsúlyosan nem-technikai ember lett volna ideális, aki hetekig tud ppt-kben süketelni a nagy semmiről (szinergiák), és "érti a cég teljes termékportfólióját". (Külsős jelentkezőként ez nyilván passzolt volna bárkire (nem)! Azaz már rég megvolt a belső jelentkező csak ki kellett írni publikusan is, ez a marha meg jelentkezett a hírdetésre.) De nem kell technikai gyakorlottság mélységeiben! Szerintem meg ilyen ember nem létezik. Rekorsrövid interjú volt. Hálistennek nem oda mentem végül, és az ottani volt melósoktól is azt hallottam vissza h. amúgy az egész egy barátságtalan szrcég.

Üzemeltető, aki nem a kézi hajtányos melóban hisz, hanem automatizál, kódot ír+ tesztel, és a dev/stage környezete nem a production rendszer.

Ahogy ma állunk, ez egy kötelezően beírandó szó, nagyjából függetlenül attól, hogy mit is várnak az illetőtől. (Egyébként is, minden rendes munkaszerződés úgy végződik, hogy 'valamint egyéb feladatok ellátása'.)