Devops álláslehetőség Budapesten

Fórumok

Több mint 10 éve működő, stabil pénzügyi háttérrel rendelkező, folyamatosan fejlődő fejlesztő cég - Blueray Digital Kft. - keres budapesti irodájába a következő infrastruktúra üzemeltetésére teljes munkaidős kollégát:

  • 9 Debian VPS + két Amazon AWS-en futó nagyobb rendszer
  • kb. 150-200 alkalmazás PHP-MySQL-Apache/Nginx alapokon

A feladat a meglévő infrastruktúra karbantartása, fejlesztése, deploy folyamatok automatizálásának koordinálása a fejlesztőkkel együttműködve.

Hosszú távra keresünk megbízható, proaktív munkatársat 10 fős csapatunkba.

Elvárások:

  • Legalább 3 év hasonló munkakörben szerzett tapasztalat
  • Amazon AWS vagy más cloud szolgáltatás ismerete előny, de nem követelmény
  • Bármilyen fejlesztői tapasztalat előny

Juttatások:

  • Magán egészségbiztosítás
  • Cafetéria (SZÉP kártya, étkezési utalvány)
  • Heti gyümölcsrendelés, korlátlan kávé
  • Belvárosi iroda a Kálvin tér közelében

Jelentkezés fizetési igény megjelölésével és szakmai önéletrajzzal az info@blueray.hu címen.

(A hirdetés a HUP-Profession szabadkártya felhasználásával került kihelyezésre)

Hozzászólások

Ööö... izé... ez mitól DevOps munkakör? :)

Értem én, de ettől még nem lesz "DevOps" se a keresett ember, se a csapat... a DevOps ember olyan üzemeltető, fejlesztő és tesztelő egy személyben, akinek legalább az egyik területen kiemelkedő tudása van, a maradék területeken pedig legalább egyikben átlagos.

Mindenre rá lehet mondani, hogy bullshit... függetlenül attól, hogy az tényleg bullshit-e vagy csak szimplán nem értjük a lényegét... de felőlem lehetnek a fekete billentyűk hangosabbak és mondhatjuk egy szimpla üzemeltetői állásra, hogy DevOps állás.

Szerintem normális üzemeltető programozási ismeretek nélkül nem nagyon tudsz lenni, mindig van valami amit a fejlesztők elcsesznek, vagy nem úgy működik bele kell nyúlni a kódba.

Példa legutóbb az ÁNYK nyomtatványtervezője telepítés, próba, nincs JAVA telepítve (közben az 1.8-as JRE telepítve), visszafejteni ugye nem lehet azaz lehet csak lecsuknak érte, process monitorral sikerül belőle kihámozni, hogy csak 1.5-ös és 1.6-os reg kulcsokba keresgél. (bár lehet nem devopsok írták :))

Mert valamilyen szinten kell (itt nem feltétlen programozási ismeret max szemlélet), hogy megtaláld miért nem megy.
A fenti első körben el se indult a Program Fileson belül mezei felhasználóként mert végtelen ciklusra futott (amikor megláttam miért majdnem elsírtam magam ...)

De van olyan eset ahol forráskódot kell olvasgatni, hogy kiderüljön, mert egyszerűen a logokból nem derül ki.

> Mindenre rá lehet mondani, hogy bullshit... függetlenül attól, hogy az tényleg bullshit-e vagy csak szimplán nem értjük a lényegét...

Nem erted? Szubjektiv.
Mindenkinek mas a bullshit, mas a jelentese. Mindenkinek mas a devops.
Epp ezert nalunk egy devops interju sokszor azzal kezdodik, h mit jelent szamodra a devops.

Én azt, hogy egyre nagyobb az igény olyan IT-ra, ami a fejlesztőktől kézközelben van és nem csak egy eszkalációs csatorna közbeiktatásával érhető el, lassú reagálási idővel.
Ez lehetőséget biztosít, hogy a teljes developer és deploy folyamatban ottlegyen. Az, hogy ez csak klasszikus üzemeltetést jelent, scriptelést vagy adott esetben a kódba belenyulast is, cég és feladatfüggő. De nem ettől lesz DevOps a pozíció, vagyishát nem ez miatt aggatják rá.
Több helyen láttam, hogy már a megrendelő kéri ezeket a kollégákat.
Valamint, hogy a helyi infrastruktúra üzemeltetés elől veszi el a munkát, ami elég komoly érdekellentéteket szül.

Ha az uzemelteto/devops reagalasi ideje lassu, akkor ott a ceg szervezesevel van a baj, es egeszen biztosan vannak mas gondok is.

Sajnos sokszor a fejlesztok tudasa baromira nem talalkozik azzal az elmeleti minimummal, ami alapjan kepesek lennenek akar csak egy szimpla fejlesztoi kornyezetet is eluzemeltetni (ertsd: letrehozni egy vhostot, vagy jogosultsagokat fixalni).

Egyebkent a DevOps pozicio tenyleg mindenkinek mast jelent. Nem is biztos, hogy csak medialnia kell az uzemelteto es a fejlesztoi csapat kozott, nem biztos, hogy kizarolag csak eszkalacios pont lehet. Lattam mar olyat is, ahol a devopsos egyebkent teljes erteku uzemelteto volt, es egy csomo dolgot o is meg tudott oldani. Es ez nem, hogy lassitotta, de meg gyorsitotta is a problemamegoldasokat, mert a fejlesztoknek nem kellett hosszasan magyarazniuk az igenyeiket, hanem egy olyan uzemeltetovel tudtak beszelgetni, aki az o szintjukon, az o ismereteik alapjan tudott kommunikalni.

A legfontosabb a DevOps pozicional: erteni kell a fejlesztok gondolkodasmodjat, szemleletet. Es igazabol ez az egyetlen dolog, ami szamit.
--
Blog | @hron84
Üzemeltető macik

Elég fura vélemény. Egy univerzális, bárhol, bármire bevethető DevOps szerintem sokkal magasabb szakmai értéket képvisel, mint pl. egy dedikált SAN vagy DBA vagy egy Cicso üzemeltető. Erős problémamegoldóképesség, intelligencia, gyors tanulási képesség biztosan szükséges a DevOpsnak, ami az utóbbiakról nem feltétlenül mondható el.
Sajnos a munkaerőpiacon amit látok, az alapján a fizetések pont nem támasztják alá a véleményem. :( Hát ez van, mindenki hülye csak én vagyok helikopter. Vállalom.
Amúgy olvasgasd ezt végig, ha még van kérdésed. http://hup.hu/node/147515#comment-1989087

Sok helyen hozza jon a fejlesztett szolgaltatas _teljes_ tesztelese is, nem csak az infrastruktura kezelese.
https://en.wikipedia.org/wiki/DevOps
(igy ha nyugodt ejszakakat akar a dev, akkor tobb motivacioja van robusztus kodot irni/megoldasokat kitalalni)
egy jo eloadas egy valtasrol: https://www.youtube.com/watch?v=1aQPdwuky0k

> A devops az a fejleszto, aki nem csak kommitolja a kodot, hanem deploy folyamatokat is atlatja, tudja birizgalni.

A fentebb linkelt szálból nekem az jön le, hogy nem. Hanem egy olyan üzemeltető, aki nem két emelettel lejjebb ül, hanem mellettem.

Pedig egy olyan csapatban szívesen dolgoznék, ahol kb. mindenki átlátja a deploy folyamatokat, s rá lehet bízni a prod. rendszer birizgálását, ha szükséges.
--
blogom

Cross-functional team: egy kupacba ülteted azokat a különböző munkakörű embereket, akik egy terméken dolgoznak.
DevOps: ideális esetben egy személyben felelős a termék egy részéért, annak teljes életciklusa alatt: fejleszti, teszteli és üzemelteti is; kevésbé ideális esetben ebből egyet elvégez és a másik kettőhöz jól ért.

de pont ezaz. a fentebb linkelt szálon ( http://hup.hu/node/147515#comment-1989087 ) azt kérdeztem, hogy:

a devops nem fejleszt, legalább egy kicsit?

és erre jött egy ilyen:

Devops az aki nagyon kozel dolgozik a fejlesztokkel - jol "olvassa" a kodot, ismeri az alkalmazast es gondoskodik, hogy mukodjon a "continuous deployment" automatikus build-ok, automatikus deployment, konfiguracio management, tobb kornyezet automatikus uzemeltetese (test, pre, performance, prod stb)) Ehhez kulonbozo automatizalo eszkozoket es konfig managementet alkalmaz. Jenkins, ansible, puppet/chef es tarsai. Van benne egy rakat integracios feladat is... Vagyis nem ir hagyomanyos java/c stb kodot, de ismeri es tudja kezelni, de azert valamennyit kell tudni kodolnia is - ha mas nem az automatizalos resz miatt de az inkabb bash,python,kinekmitetszik sripteles. igen gyakran a devops a felelos a prod uzemeltetesert is... O latja jobban a prod gondokat - skalazhatosagi igenyek, security stb, de ugyanakkkor tudnia kell mik a kihivasok fejlesztoi oldalrol. Egy csomo devopsos szakember rendszergazda vagy uzemeltetoi oldalrol erkezik inkabb es a kulonbseg inkabb az automatizalasban, "infrastructure as a code" szemleleten latszik.

és, ha jól látom, itt feljebb is az a konszenzus, hogy ez a portálon eddigi legjobb definíció rá...
--
blogom

Igen, ez a "kevésbé ideális esetben ebből egyet elvégez és a másik kettőhöz jól ért" esete... és a választott "szakterülete" attól függ, hogy eredetileg az üzemeltetés felől jött, a fejlesztés felől jött vagy QA felől jött... bármelyikből lehet DevOps, nem csak üzemeltetőből. :)

Igen, ez a "kevésbé ideális esetben ebből egyet elvégez és a másik kettőhöz jól ért" esete... és a választott "szakterülete" attól függ, hogy eredetileg az üzemeltetés felől jött, a fejlesztés felől jött vagy QA felől jött... bármelyikből lehet DevOps, nem csak üzemeltetőből. :)

Szerintem a devops az, aki a szoftver business oldalaval nem foglalkozik, csak az informatikaival.

Vagyis nem o fogja az uj utvonaloptimalizalo algoritmust irni, sem a weboldalon futo szkripteket, sem a reportokat generalo sql lekerdezeseket.

A bejelentkezo weboldalt sem o csinalja, de az mar lehet az o felelossege, hogy milyen authentikaciot hasznal a szoftver, az hova es hogyan van telepitve, vagy mondjuk az ssl certificate mikor jar le es hogyan kell frissiteni.

Szerintem a devops uzemeltetheti a belso nexus repot, a jenkins build szervert, a docker repot, stb. A build szkript nem biztos, hogy hozza tartozik, ellenben a deployment mar igen.

Ezen tulmenoen a masik iranyban az uzemeltetes fele elnyulhat valameddig (ahhoz mar nem ertek), viszont nagy butasag lenne egy jo devopsot arra pazarolni, hogy a logokat vagy a nagiost nezegesse, amikor azt a feleannyiba kerulo operator is el tudja vegezni. Persze ha altalanos megoldas kell a loganalizalasra, amire egy off the shelf megoldas nem eleg jo, akkor azt a devops tudja megcsinalni.

Ezen tulmenoen lehet felelos a dev, qa vagy a prod environmentert, de tesztelesert nem (hacsak nem folyik bele a nem businesshez kapcsolodo tesztelesbe: teljesitmeny, megbizhatosag stb).

Nalunk a DevOps tervezne azokat a dolgokat, amikre nincs idejuk az adminoknak es/vagy az automatizalast segiti elo.
Nem mondom, hogy mindig elfogadjuk a terveiket, de volt mar ra pelda, mert mint fentebb is irtak, az adminok is szep lassan azza valtak, ha azt nezzuk, hogy tervezni, automatizalni kell. Ezzel egyutt fejleszteni is kellene, legalabb bash scripteket. :)

sziasztok, megkérdezhetem mi a cég profilotok?