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? :)
Gondolom hasonlóan mint nálunk, a kolléga kialakítja magának.
--
Gábriel Ákos
http://ixenit.com
Ettol meg nem lesz semmi devops.
--
Blog | @hron84
Üzemeltető macik
Manapsag minden devops, es semmi sem az. ;)
Amugy meg nem mind1 hogy hivjak a poziciot. A lenyeg hogy mit kell csinalni.
Kíváncsi lennék létezik-e egyáltalán széles körben elfogadott definíció :)
--
Gábriel Ákos
http://ixenit.com
Szerintem a DevOps egy szemlélet és nem munkakör.
deploy folyamatok automatizálásának koordinálása a fejlesztőkkel együttműködve
Lassan gépelj, mert nem tud olvasni! :)
Amúgy thumbs up, tömör, korrekt hirdetés. Igazán szép egy fizetési sávval lenne.
--
„Spiró ótvar, Konrád átok, Nádastól meg mindjárt hányok!”
Meg mondjuk egy munkavegzes helyevel. Igen, olvastam, hogy budapesti ceg. A 17. kerulet is Budapest, meg a Lanchid kozepe is az.
--
Blog | @hron84
Üzemeltető macik
Sőt, lehet, hogy a cég budapesti, de... :-D
Fuszenecker Róbert
É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.
Nincs egzakt meghatározás rá. Alapvetően figyelemfelkeltő hívószóként használják olyan pozíciókra, ahol a feladatok gyakran változnak.
Ez elég jól definiálja: https://en.wikipedia.org/wiki/DevOps#/media/File:Devops.svg
... és én inkább azt látom, hogy mostanában minden klasszikus üzemeltetői álláshoz odaírják, hátha akad valami balfasz, aki így is horogra akad, aztán meg szerencsétlen büszke is rá, hogy DevOps, pedig dehogy... :/
Ez jobb:
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 :))
Ehhez miért kell programozási ismeret?
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
+1
Egyébként de rohadt nagy uborkaszezon van, hogy még mindig ezt az ősrégi posztot csócsáljátok :D
Egyfelol unatkozom (mert meg mindig nincs melom), masreszt meg az a poszt, amire reagaltam, nekem meg ujkent volt megjelolve, egy ideje nem latogatom olyan surun az oldalt.
--
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
Ebben a threadben volt a legjobb megfogalmazása lmarton-tól: http://hup.hu/node/147515#comment-1989209
Ez a devops. Magyarán egy rakat üzemeltető úgy lett devops, hogy észre se vette. :)
A devops az a fejleszto, aki nem csak kommitolja a kodot, hanem deploy folyamatokat is atlatja, tudja birizgalni.
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
Nem para az, ha az embernek hagynak eleg idot automata tesztek irasara :)
Jópofa az előadás.
Tanulság, hogy szarból nem lehet várat építeni. Ha lusta vagy testing frameworköt fejleszteni, ne is akarj automatizált tesztelést.
> 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
"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."
Azt úgy hívják, hogy vertikális csapat vagy cross-functional team...
> vertikális csapat vagy cross-functional team
mármint mit? a szanaszétülő, sosemlátom az üzemeltetés felállást, vagy ha napi kapcsolatban vagyok azzal, aki üzemlteti azt, amit én írok?
ah, el vagyok tévedve ezekkel a megnevezésekkel...
--
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:
és erre jött egy ilyen:
é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?