Nincs gyereke vs 3 gyereke van.

Make things work

Hat, lassan mar en is elgondolkozok a gyerekcsinalason ha ennyi a difi kozte....
Vagy a vallalkozason
Mert hogy a munkaert nem akarnak sok helyen fizetni, az fix...

Volt egy komolyabb, tanacsadoi pozicio kilatasban, hat ott is sokalltak a berigenyt, nemreg kaptam feedbacket... Mondom wtf??? Vazz, sajat bevallasotok szerint munka van rogyasig, kulsos tanacsadot megeri foglalkoztatnod 2x akkora napidijon de munkavallaloi statuszban a kb fele akkora osszegen megrokonyodsz?
Az ilyen cegeket sem ertem soha...

Koss veluk szerzodest kulsoskent es megoldodott.

Az biztos más budget-ből megy

Tanácsadóéknál ilyen idők járnak mostanság :

Nem: Férfi
Kor: 35
Munkakör: szoftver-implementációs konzulens
Tapasztalat : 10 év
Végzettség: Főiskola
Nyelvtudás: Angol felső
Fizetés (bejelentett munkavállalóként,ledolgozott konzulensi napok függvényében)
Bruttó: 1,3-1,6M HUF (nettó : 900k-1,1M)
Egyéb: vállveregetés
Hely: Budapest

Not great, not terrible. Lesz ez még jobb is !

[ Szerkesztve ]

Annak a statisztikának hiszek, amelyet én hamisítottam -Winston Churchill

egyébként ez a mesterség miből áll?

Ha jól emlékszem te magad írtad, hogy a pozid bérsávjanak felső végén van a jelenlegi fizud, ezek után nem tudom miért lep meg, ha nem találsz jobban fizető állást

BlueAthlon: Ahoj májsztró

Eladó/Cserélhető: GERE Kopar faládák, ÓRA:Orient Bambino II Bigsize, Parnis Pilóta, FANTASY könyvek, Garis keskeny MOSOGATÓGÉP, könyvespolcok, MOSÓGÉP

Perpill nem tanacsadoi poziban vagyok, igy magasabb poziba kerules lett volna... egy tanacsadoi ertelemszeruen jobban tejel (es mivel realisan ismerem a tudasom, fejlodesi pontokat, ezert egy hays / piac szerint is a teruletnek realis igenyt adtam meg, meg csak nem is vad szamot dobtam be, pl a pozi tetejet rogton)

Ez akkor nagyon korrekt fizu, gratulálok!

Nekem viszont nem teljesen egyértelmű, hogy egy DevOps engineer milyen munkakört takar. Az én ismereteim szerint - javítsatok, ha tévedek, de egy Donovan Brown előadásból tájékozódtam - a DevOps arról szól, hogy a fejlesztőknek nem ott ér véget a munkájuk, hogy check-in, oszt kalap, a többi a QA és az üzemeltetők problémája, hanem elvárják tőlük, hogy képesek legyenek teljesen programozottan létrehozni az automata deploy és az üzemeltető környezetet (tipikusan cloud), beállítani a monitorozást riasztásokhoz stb. Lényegében hosszútávon nem lesz szükség Ops-ra, az egyre inkább a fejlesztői munka része lesz.

Tehát a Devből lesz a DevOps, nem az Ops-ból.

A titulusodat a fentiek miatt nem nagyon tudom értelmezni. Mit csinál egy DevOps engineer? A fentit?

Köszi

Szerintem egy fejlesztőtől nem elvárható ez a fajta munka, ez egy teljesen elkülönülő infrastruktúra. Attól még, hogy a fejlesztő által írt kódot "kezeli", neki semmi köze hozzá. Ez kb. olyan, mintha egy fejlesztőnek kéne beüzemelnie egy szervert.

A devops attól devops, hogy egy erős dev szemlélet kell hozzá, máshogy nem is nagyon lehetne csinálni. Nem tudom, hogy a dev múlt kötelező-e hozzá, de az biztos, hogy erősen ajánlott.

"a fejlesztőknek nem ott ér véget a munkájuk, hogy check-in, oszt kalap"

Hát, egy jól elkülönült rendszerben márpedig itt véget kéne érjen. Ahhoz már semmi közöd, hogy a másik oldalon mi történik. Kivéve, ha szar kódot toltál be.

[ Szerkesztve ]

Pont az a baj, hogy sok helyen igy gondoljak, ahogy irod. A dev-bol probalnak ops-ot is faragni, ami lehetetlen vallalkozas. Eleve ne vegezze egy ember 2-3 masik munkajat. Az, hogy nem lesz szukseg ops-ra, azt pont a sok olyan sikertelen vallalkozas cafolja meg, ahol a dev-bol csinaltak ops-ot aztan percenkent van outage a rendszerben, a security meg sirva megy a falnak. A devops amugy sem job title, az egy szemlelet, ahol a dev es az ops egyutt dolgozik, nem egymas ellen. Ennyi az egesz. Bele kell latni a masik feladataiba persze, de nem a masik helyett kell dolgozni. A vilag legnagyobb marhasaga felvenni egy devops cimkevel valakit es varni a csodat, hogy o majd mindent is tud egyszerre.

Szerintem meg elvárható. Nyilván több pénzért.

while (!sleep) sheep++;

Mármint milyen formában? Szerintem vagy fejlesztő valaki, vagy egy ilyen infrastruktúrát üzemeltet, a kettő együtt nehezen megy. Kódolsz, aztán valaki leszól az emeletről, hogy elromlott a rendszer?

Meg eleve milyen indokok szólnak amellett, hogy a kettőt együtt csinálja valaki, amikor külön is találsz rá embert? Azon kívül, hogy a spórolós cégek jól járnak azzal, hogy 1 ember végzi 2 munkáját.

Ez a pozi opsos állás inkább, deves szemlélettel - de opsra szükség lesz, ahogy ezen túl vagy it üzemeltetés is kell (ami jellemzően másik állás/külsős cég ami a hw beszerzést, belső hálót, ilyesmiket ellátja , vagy cloud - cloud esetén már lehet devops feladat is, de van ahol ezt már máshogy hívják, pl cloud engineer, site reliability engineer stb. Van ahol simán devopsnak). De ha nincs ops, melyik dev felelős az infráért ? Mindegyik ?

az, hogy devops szemlélet kell deveknek igaz, sőt, ahogy az is, hogy a dev felelősségi köre nem áll meg ott hogy git review s csókolom, hanem ha utána a pipelineban valahol elhal a kódja, akkor az dev feladat, higy javítsa (már ha nem épp valami környezeti baromság miatt halt le persze a folyamat ) nem pedig az vam mint régen h felteszi a kódot, lead lereviewzza elfogadja, majd qa tesz vele amit akar az már őt nem érdekli
gyakori kis patchek, amik le vannak tesztelve s dev által javítva, ha elhasal, de ennek az egésznek a struktúráját biztosítani kell. Egy kubernetes/swarm rendszer, jenkims/tf akármi pipeline, monitoring, logging rendszer, nexus/artifactory, vmware, ansible, puppet, chef, patcher, terraform kialakítása, üzemeltetése nem dev feladat ahogy egy aws vagy azure sem. Alapvetően szerintem a pipelineok kialakítása és optimalizálása is devops feladat, optimalizálni mondjuk már gyalran kellhet dev vagy dba mellé. Apróbb változásokat vihet s vigyen is fel dev, de az alap struktúra kialakítása sztem jobb kezelben van devopsnál. Főleg ha valami közös library alapján dolgpznak, dev jellemzően 1-2 projektel van nagyon képben, míg devopsnak az összessel nagykából képben kell lennie, így ésszerübben tudja felépíteni.

aztán ez cégenként változó ki hogy értelmezi, van ahol inkább deves. Van ahol opsos. Van ahol egy szerencsétlent kijelölnek erre h akkor mától te vagy az
ettől függetlenül projektenként nem árt, sőt hasznos ha van 1 dev aki jobban tisztában van a devopsos dolgokkal, sokak munkáját segíti

[ Szerkesztve ]

Olvassátok el a Google-féle SRE handbookot. Na az az.

Szóval olyan emberek, akik profi fejlesztők (kodminoseg, karbantarthatosag, etc tekintetében), emellett az infrastruktúra nagyrészt szoftveresen definiált, amit ezek az emberek csinálnak.

while (!sleep) sheep++;

+1

"Felesleges szigetelni a nyílászárókat, ha az ereszcsatornán szökik a meleg."

Elméletben :

ha az üzleti sapka van a fejeden :

- üzleti igényfelmérés / egyeztetés az ügyféllel a követelményekről
- a rendszer szállítójával a követelmények átbeszélése, fit / gap pontok megtalálása
- ahol gap, oda megoldási javaslatok kialakítása, amit mindenki elfogad
- fejlesztési specifikáció írása és validálása
- rendszer-paraméterezés és tesztelés

ha technikai sapka van éppen a fejeden

- technikai környezet kialakítása ( adatbázisszerver, appszerver, stb.. )
- alkalmazások telepítése és konfigurálása
- hibakeresés és logolás a szállító felé
- javítások fogadása , telepítése és tesztelése
- integráció konfigurálása

Gyakorlatban :

Mindezek egyszerre és sok esetben egy erős nagy katyvasz közepén a zavarosban halászás és manőverezgetés a résztvevők között, hogy a végén mindenki jól járjon.

Annak a statisztikának hiszek, amelyet én hamisítottam -Winston Churchill

Annak a statisztikának hiszek, amelyet én hamisítottam -Winston Churchill

Jelenleg banki alaprendszer és hozzá való kiegészítő megoldások implementálásával foglalkozom.

Banki alaprendszer ( más néven banki számlavezető rendszer) : minden pénzintézet központi rendszere egy rakás másikkal körülvéve. Feladata - többek között - hogy a a folyó, megtakarítási és hitelszámláitokat vezesse.

Annak a statisztikának hiszek, amelyet én hamisítottam -Winston Churchill

+ FLx

Értem az álláspontotokat, de nekem úgy tűnik, hogy a jövőben olyasmire kell berendezkedni, amit vázoltam (ez persze a Microsoft stratégiáját tükrözi, de ahogy nézem, nem nagyon van ez ellenére más nagyobb cégeknek sem).

Lehet, hogy most az a helyzet, hogy egy átlag dev "azt se tudja mi az a halozat es mi a kulonbseg egy tuzfal es egy load balancer kozott", de én úgy látom, hogy ők 10 éven belül le fognak morzsolódni, ilyen tudással nem fogják őket felvenni komoly helyre, és mehetnek rosszul fizető pincebétékhez.

"Ez kb. olyan, mintha egy fejlesztőnek kéne beüzemelnie egy szervert."

"Szerintem vagy fejlesztő valaki, vagy egy ilyen infrastruktúrát üzemeltet, a kettő együtt nehezen megy. Kódolsz, aztán valaki leszól az emeletről, hogy elromlott a rendszer?"

A trend meglátásom szerint egyre inkább abba az irányba megy, hogy az IT infrastruktúra márpedig egyre inkább szoftveres konfigurálást jelent. Cloud-nál már ma sem kell szervert beüzemelni. Fejlesztőként meg konfigurálsz, automatikusan vagy gombnyomásra vertikálisan skálázol, és scriptet készítesz, hogy másik régióba másold az infrastruktúrát, ha bővül a vevőkör. Ha elromlik valami, az vagy a te (rosszul tervezett infrastruktúra), vagy a szolgáltató hibája.

A környezeteket ettől még el lehet különíteni, nem kell, hogy a fejlesztő piszkálja a prod-ot. Copy/paste hozza létre a prod környezetet, így jó eséllyel ugyanaz a kód fog futni ott is.

Ettől még persze szükség lesz üzemeltetőkre is, hiszen a vasat is karban kell tartani, de az jóval kevesebb és specializáltabb munkát jelent majd. Átlagos Enterprise-nál nem feltétlenül éri majd meg a saját szerverpark fenntartása (már ma sem, csak adatvédelmi, biztonsági, egyéb aggályok miatt nem olyan mértékű a cloud-penetráció, mint azt a szolgáltatók szeretnék, de azért a tendencia biztosan növekedő).

Összegezve: ne a mából induljunk ki. Részemről 10 év múlva is a jobban keresett, jobban fizetett szakemberekhez szeretnék tartozni, így muszáj követni a trendeket.

"De ha nincs ops, melyik dev felelős az infráért ? Mindegyik ?"

Ahogy az előzőekben írtam, a vasért úgyis a cloud-szolgáltató, a többiért pedig a tervezés. Egyre kevésbé van olyan, hogy az ops-nak kell keresgélnie, melyik kábelt rágta el az egér.

De így már világosabb a pozíciód, és igen, nem megkerülhető néhány specializáltabb ops terület, a tiéd pedig nyilvánvalóan ilyen. A fizu szerintem tükrözi is.

Köszönöm

Rosszul latod, hiaba lehet cloud infastrukturat kodbol felepiteni, egy atlag fejleszto most sem es a jovoben sem fog erteni az egyes architektura elemekhez, azok osszessegehez meg foleg nem. Tervezni meg plane nem fog tudni, az egy masik szakma, ugy hivjak, hogy Cloud Infrastructure Architect. Pont ez a legtobb nagy ceg baja, azt gondoltak, amit te is, hiszen kodbol felepitjuk az infrastrukturat, az meg fejlesztoi munka. Most meg ott allnak, ahol a part szakad, a fejlsztok altal tervezett cloud infra romokban hever. Nyilvan nem en talalom ki, ez a valosag most. Eleve nem varhato el egy embertol, hogy profi fejleszto es ops/architect is legyen egyszerre, ilyen ember nem letezik es nem is fog. Olyan lesz es van is, aki mindenhez felig ert, es jon a ganyolas.

De ha van konkret peldad, ahol minden jo es minden fejleszto egyben profi cloud architect es profi ops-os is, en nyitott vagyok meghallgatni ezt is. Csak en meg nem lattam ilyent, pedig megfordultam par 5000+ fos nemzetkozi cegnel.

[ Szerkesztve ]

Szerintem amit írsz az teljesen igaz lehet egy kisvállalatra/startupra, de a multik jelenleg még mindig szeretik a papírtologatós bürokrácialáncokat, valamint ha valaki nem ért mindenhez de a saját dolgához kiemelkedően az nem mindig rossz dolog. Sőt inkább mondja meg hogy nem ért hozzá mielőtt nekiállna "megszakérteni".

Abban hogy az informatikushiány miatt a jövőben jobban el fognak tolódni a dolgok az általad felvázolt irányba abba lehet valami.

Ott az infrát inkább sw infraként értettem (ezért is írtam hogy a hw infráért vagy egy másik pozi/külső cég, vagy pedig cloud esetén a devops a felelős) - az egy dolog, hogy ért hozzá egy dev, hogy módosítson egy pipelinet vagy esetleg hogy állítsa be az aws őt érintő részét, de a pipelinet kezelő sw-t, legyen az pl jenkins, a docker orchestrátort, ami legyen mondjuk kubernetes, a loggolást végző swket ami legyen mondjuk prometheus és grafana, bináris repo ami legyen mondjuk nexus, gitrepohoz mondjuk bitbucket stb stb stb ezeket mind ki kell építeni, karban kell tartani.

Kicsit olyan a feltételezésed, hogy egyszer valaki ezeket a dolgokat deployolta, s onnantól kezdve amíg világ a világ minden ugyanúgy működik és plusz igény se merül fel ezekkel kapcsolatban soha, ahogy alternatíva se kell majd esetleg, sose avulnak el- ez tök jellemző az it légkörre, nem ?

Ahogy pl attól még h a dev érti mi hogy működik, nem feltétlen fog jól skálázható és magas rendelkezésreállású struktúrát kiépíteni, mert nem olyan a szemlélete a munkájának. Plusz ugye az adott dev az adott projektjével van tisztában és azért vállal felelősséget, míg egy központibb devopsos vagy nevezzük bárhogy, az egész cégért, vagy legalábbis egy egy részlegéért, linejáért felelős, így koherensebb is tud lenni az összes folyamat. Az, hogy pl infrastructue as a code nem azt jelenti, hogy akkor mostmár deveknek kell ezt csinálnia, hanem azt, hogy a mezei opsnak meg kell tanulnia alap dolgokat (nyilván nem elég ha yamlök szerkesztéséhez ért, sokkal jobban kell ismernie adott nyelveket is, amikkel a devek dolgoznak)

Plusz a felelősség: ha teszem azt a jenkins összefossa magát, egy grafan frissítés elront dolgokat (eleve ki frissíti) az melyik dev felelőssége? egyiké sem és mindeközben mindenkié?

[ Szerkesztve ]

Na jó, de ez már az a kategória, amikor mindennel szembe mész, mint amit az ITIL képvisel.

Az ITIL sem egy silver bullet, sima opinionated framework.

+ mindenki

(Szerintem ez a téma nem off, mert a szakmában nagyban érinti a jövedelmeket.)

Alapvetően a jövőről beszélgetünk, tehát nem fogok tudni példákat hozni. Próbálom összevetni a ma pozícióit és a mai tapasztalatokat ezzel a jövőképpel.

Amit írtok az alapvetően szerintem nem megy szembe azzal, hogy hosszútávon kevesebb, specializáltabb ops-szakemberre lesz szükség.

Az valóban belátható, hogy átlag dev nem fog infrastruktúrát tervezni, viszont szerintem is kritikus, hogy még ha nem is tervez, pontosan értse, hogy működik, hiszen anélkül egyszerűen nem lehet skálázható kódot írni.

Ezen felül nekem akkor is úgy tűnik, hogy átlag dev-nek meg kell majd oldania olyan problémákat, amelyeket ma az ops csinál. Ahogy olvastam, végül is ebben sincs vita.

Mindenesetre köszönöm mindenkinek, hogy sikerült kicsit árnyalni az eredeti képet.

Sziasztok!

Sajnos úgy alakult, hogy márciusban létszámleépítés miatt próbaidő alatt felmondtak nekünk. Én gyors megoldásként egy munkaközvetítőnél találtam munkát. Sosem dolgoztam közvetítő által és ez a tapasztalatok után több kérdést is felvetett bennem.

A szerződésben bruttó 230.000 forintos alapbér van feltüntetve. A valódi órabér pedig nappal 1.100 forint, délután 1.200 forint és éjszaka 1.300 forint. Az órabér nettó órabért jelent. A kérdésem az lenne, hogy a 30 %-os műszakpótlék jár-e nekem? Ha igen akkor azt is nettóban számolhatom vagy a közvetítő zsebre teheti a nettó órabér miatt?

Köszi!

Szerinted ahol nem jelentenek be teljesen, ott majd műszakpótlékot fognak osztogatni?

Ezt igy nem lehet megmondani, mert ket feltetele is van a muszakpotleknak es nem irtad le, hogy ezeknek megfelelsz-e. Amugy gondolom azert van mas dijazas nappal es ejszaka, mert nem fizetnek semmit ezen felul, ahogy latom ezt is zsebben. Szoval kb. a sok rossz kozul te a legrosszabbat valasztottad, nem bejelentett fizetes es azt is kozvetiton keresztul, aki felet elrakja maganak.

[ Szerkesztve ]

ugye délutáni műszakpótlék nincs. 06-18-ig semmi 18-06-ig 30%, amit te írtál arra rá van számolva valami valahogy

A bejelentésről fogalmam sincs, de rá fogok kérdezni, hogy mennyi az annyi. Plusz amit nem írtam le azaz, hogy a legutolsó fizetésem kpban adta és a bankba nekem kellett befizetnem, hogy legyen a számlákra pénzem.

Az ügyfélkaput megnézve a taj szerint a szerződés óta folyamatos a bejelentésem, összeget nem látok.

Ha ügyfélkapun akarod ellenőrizni az összeget, akkor az eBEV oldalon indulj el.

Aztán Szolgáltatások -> Járulékadat-kivonat. Van némi átfutási idő, de a májusi számoknak már ott kellene lenniük.

[ Szerkesztve ]

Köszi, meg is néztem. Az összeg az a bruttó, ami a papíron van bruttóban (350). Valahogy még így is leszed rólam? Vagy innen már nincs más csak amit a kölcsönzéssel keres?

[ Szerkesztve ]

Ha te megállapodtál valakivel x forintban és azt kapod akkor a többihez kvázni "nincs közöd".

[ Szerkesztve ]

"Ott szimatol a sarkadban vasfogait csattogtatva, minden egyes hétköznapod: kirúzsozott medvecsapda."

Nem: Férfi
Kor: 30
Munkakör: Java autoteszt + kis teszt keretrendszer fejlesztes
Tapasztalat : 3 ev
Végzettség: BME-BSC + BME-MSC mernok info
Nyelvtudás: Angol kozep
Fizetés brutto 450
Hely: Budapest

Szeretnek valtani, realisan mennyit kerhetek ?

Koszi.

Kerni barmennyit lehet. De mivel nem irtad le miben van tapasztalatod es mennyi, meg az is lehet, hogy realis amit most keresel.

650 szerintem reális 3 év tapasztalattal, tekintve, hogy most bruttó 450 a kezdőbér, szerintem még tesztelői vonalon is. Sokkal alább ennél ne adj.

[ Szerkesztve ]

Nem tudom teszteloi vonalon milyen ber realis (szerintem nezd meg a Hays guide-ot, az eleg jo indulopont) de fejlesztokent ennek a duplajat is kerhetned alsohangon.