Új hozzászólás Aktív témák
-
CyberPunk666
senior tag
"Most beszéltem az egyik bank devops vezetőjével, ők bárkit felvennének jó pénzért, ha látják benne az affinitást, annyira nincs ember. Úgy vannak vele, hogy majd beletanul, úgyis minden cégnél más a konkrét stack."
Igen, mindenki azt mondja, hogy bárkit felvenne már és betanítanak, annyira kellene az ember, de amikor senior dev jelentkezik, hogy hát oké, én szeretném, akkor már igazából oda sem jutunk el, hogy ki vagyok egyáltalán.
[ Szerkesztve ]
-
addikt
Értem én, hogy ez tök jó, csak átlag helyen nem elvárható egy átlag devopsostól. Senioritásnak, jó fizunak pedig semmiképp sem feltétele. Gyakorlati haszna is minimális, a cicd kialakítása úgyis a konkrét helyen lévő lead devek közreműködésével zajlik.
Erről beszéltem, ez nem fejlesztői, hanem üzemeltetői pozíció. A "bárki" alatt is azt kell érteni, hogy azt felvennék, akinek van üzemeltetői (Linux admin) tapasztalata, a devops toolokat pedig majd megtanulja. Lehetsz te akármilyen senior fejlesztő, azzal itt semmire sem mész.
[ Szerkesztve ]
-
Jhonny06
veterán
-
addikt
válasz Jhonny06 #22703 üzenetére
Kérdés, hogy átlagos hazai helyre kell-e nagyon erős szakember? Mármint globális értelemben erős. Vannak-e itthon akkora infrák, amik ezt igénylik?
Valószínűleg a dev tudás az egyik, amitól nem csak átlagos, hanem jó devops-os leszel.
Ezek számomra mindig megfoghatatlan buzzwordok voltak. Madwe leírt pár dolgot, amit egy tehetséges üzemeltető pár hét alatt megtanul. Tényleg nem látom be, hogy miért kéne bárkinek is komoly fejlesztői háttér kubernetes, openshift, meg úgy összességében cicd összelegózáshoz. -
Lortech
addikt
válasz section9 #22688 üzenetére
Ez azért van, mert jópár cég és "devops pozícióban lévő" kolléga is félreértelmezi a devopsot és átnevezett opsot ért alatta, aki modern toolokkal dolgozik és ez az értelmezés válik sztenderdé, negligálva a problémát, amire a devops válaszként kialakult. Ez a topik is jól szemlélteti ezt.
A devops nem fancy cloud infrastruktúra, automatizálás, microservices, CI/CD és egyéb gyakorlatok és toolok.
Valójában nincs ilyen, hogy devops csapat és benne devops pozíció, ezek antipatternek, mert ugyanahhoz a throw it over the wall és kommunikációs siló problémához vezetnek, a devops egy paradigma, egy módszer, amit egy fejlesztő csapat gyakorolhat, de ez a gyakorlat fejlesztői csapaton belül történik vagy legalább azonos fókuszú kollégák között, nem két/több csapat között. Az hogy van egy vagy több devopsnak csúfolt ops csapat aki a cloud platformot és azok szolgáltatásait biztosítja a feature teameknek, akik meg annyira devopsok, hogy legfeljebb a CI toolt nyomogathatják, annak nem sok köze a devopshoz.Valahol szánalmas, hogy a job descriptionbe már nem lehet lassan beleírni a devopsot kultúrát semmilyen formában egy mert ops / cloud emberek jelentkeznek, és csak magyarázkodni kell miatta.
[ Szerkesztve ]
Thank you to god for making me an atheist
-
Madwe
nagyúr
válasz Lortech #22705 üzenetére
Igen. De ettől függetlenül is kell központi sre engi, hiába van teamenként dedikált devopsos/sre. Egy központi team kell, aki fejleszti a céges toolingot, összefogja megtervezi az infrát stb, s szorosan eggyütműködik a devteamek devopsosaival. Olyan céget még nem láttam ahol központi sre team nélkül ez normálisan menne. Annak nincs sok értelme ha minden egyes devteam devopsosa egyedi dolgokat visz, s a light ownership jó dolog, de valamennyire ezeket össze kell fogni, vinni, s erre kell egy központi team.
a teambe dedikált devopsos pozi pedig aztán tényleg olyan ahol elengedhetetlen a dev előélet, szerintem.[ Szerkesztve ]
-
Lortech
addikt
Ezzel részben egyet tudok érteni, ott van lényeges véleménykülönbség, hogy én ezt a központi teamet alapvetően nem devops teamként kezelem, kivéve ha ez a közös "platformfejlesztés" olyan szintű önálló hozzáadott fejlesztői tevékenységgel bír, ami önmagában is devopsszá teszi, de inkább olyan példákat látok, amikben ez egy devops enablement teamként értelmezhető, de ő maga nem devops.
Ideális esetben devops szemléletben dolgozó feature teamek számára nyújt ops szolgáltatásokat, kevésbé ideális esetben ugyanolyan silóként jelenik meg, mint a klasszikus dev vs ops felállásban, pl. ha túl kicsi mozgástér marad a dev(ops) teamnek, ha túl nagy a bürokrácia, túl magas a fal. Ilyen esetben én egyik oldalt sem tekintem devops szemléletben dolgozó teamnak, dolgozzon az a legkurrensebb technológiai stackkel is.[ Szerkesztve ]
Thank you to god for making me an atheist
-
section9
őstag
En Tapsival ertek egyet, szerintem total nem kell dev mult ahhoz, hogy ertse az ember a fejlesztoi folyamatokat, kihivasokat, stb-t, eleg ha erdekli a szoftverfejlesztes annyira, hogy utanajarjon, megnezzen talkokat vagy olvasson engineering blogokat. En pl. suttyo garazscegben voltam dev egy evig, de csak annak koszonhetoen tudom, hogy mi fan terem az SDLC, hogy magamtol utananeztem es olvastam a temaban, mert erdekelt.
SRE/DevOps vonalon a tul eros dev hatter szerintem sok esetben kifejezetten hatrany tud lenni, ha mindenre csuklobol az a reakcio, hogy hosunk majd lefejleszt valamit gyorsan, ha az nem felel meg 100%-ig az elvarasoknak. Jo esetben nagyobb teamben ilyenkor az orrara koppintanak a kolleganak, rossz esetben az egesz csapat szopik mert hosszu tavon maintainelni is kell a kodot, nem csak megirni.
-
Madwe
nagyúr
válasz Lortech #22707 üzenetére
Igen, ezzel is egyetértek, sok helyen ez félremegy. Sőt, a legtöbb helyen. Bár sok helyen eleve integrált devopsos sincs teamenként...
Talán ott is meg lehet fogni a dolgot, hogy scrum-szerűen tud e dolgozni az adott csapat, esetleg kanplan de az már gyanús. Ahol csak kanban jöhet szóba az jó eséllyel átcímkézett silós ops. (ez persze nem 100% mindenhol így van, de kb ezt vettem észre mint kicsit közvetett következmény)Ennek egyébként az lehet az oka hogy sok helyen megvolt a tipikus dev + ops felállás, buzzword lett a devops, átnevezték az ops csapatot devopsra, elkezdtek újabb toolokat használni, elkezdtek buzzwordöket mantrázni mint gitops meg iac stb, s onnantól kezdve letudottnak tudták a transzformációt. Sok cég itt meg is ragad egész sokáig.
Szerintem, s ezt továbbra is tartom, az általad is devopsnak nevezett devopsos pozikhoz, legyen az központi vagy beágyazott, kell deves múlt - a beágyazotthoz sokkal több. Az átímkézett opshoz ami gyakori itthon nem kell. Magyar tulajdonú cégeknél kb csak ilyenekbe futottam bele amúgy...
#22708 ysengrin
Az hogy deves háttér, nem feltétlen jelenti azt hogy mindent maga akar megépíteni Azt mérlegelni hogy valamit hasznosabb e internal kifejleszteni vagy megvenni szerintem ettől független, bár lehet deves háttérrel vki gyakrabban akar internal fejleszteni... Azt a mentalitást meg hamar ki kell verni belőle. De ha más nem is, pár év maintainelése a házi szaroknak biztosan megteszi majd vele[ Szerkesztve ]
-
addikt
válasz Lortech #22707 üzenetére
Bizonyos méret felett nem tudod elkerülni a silósodást. Egy ügynökségnél szép és jó a tankönyvi devops, de egy nagy cégnél ezt nem lehet megcsinálni. Legalábbis én még nem láttam rá példát.
Arról nem beszélve, hogy sok helyen nincs is házon belül fejlesztői kompetencia, hanem mondjuk 30-40 beszállítóval dolgoznak együtt, akik folyamatosan szállítanak.
[ Szerkesztve ]
-
Drizzt
nagyúr
válasz section9 #22708 üzenetére
"SRE/DevOps vonalon a tul eros dev hatter szerintem sok esetben kifejezetten hatrany tud lenni, ha mindenre csuklobol az a reakcio, hogy hosunk majd lefejleszt valamit gyorsan, ha az nem felel meg 100%-ig az elvarasoknak."
Jó dev is csak akkor ír kódot, ha muszáj.I am having fun staying poor.
-
Madwe
nagyúr
Biztosítókra nem láttam még rá, de a bankok pont még a mammut óriások között is az igazán lassan mozgó s változó, csigatempóval újuló cégek (nyilván jó okkal), ahol nyilván egy ilyen transzformáció sokkal tovább tart (ha egyáltalán valaha végbemehet).
attól még hogy valami multi nem kéne predesztinálja azt hogy silosodik, szerintem?
-
vzozo
senior tag
Talán mégsem offtopik ez.
Azt sajnos én is látom h jelentősen hígul a piac s már seniornak vesznek fel olyan embert akit szívem szerint juniornak se vennék fel… mert hiány van…
Hasonló tendenciát látok én is, és azt nem értem, hogy HOL vannak a szakemberek. Én a (cégen belüli) teljes EMEA hiringre rálátok, és nem az, hogy Magyarországon, Kelet-EU-ban, de NY-EU-ban sincs ember. Hol vannak? Ennyi volt, elfogytunk az IT-ban?
Közben meg ugye jönnek a managgák, hogy akkor "gyorsítsuk a felvételi utáni képzési programot", de azt már nem értik meg, hogy 9 nő nem tud egy hónap alatt egy gyreeket megszülni...
[ Szerkesztve ]
-
inferno88
őstag
válasz CyberPunk666 #22701 üzenetére
A probléma szerintem sok esetben a HR lesz. Igazából fingja sincs semmiről, de ő az előszűrő. Ilyenkor kb. akkor lehet szerencséd, ha mégis van rálátása vagy be van vonva egy technikai személy is már a folyamat elejébe, aki rácsap a kezére, mikor hülyülne.
Semper fi!
-
Lortech
addikt
Hogyne lehetne megcsinálni, de legtöbb középszerű (és középszerű emberekkel dolgozó) cég csak cargo cultig jut el, átcímkéz, átnevez, mímel, megvásárolja a polcról a dobozos "agilis" metodológiát, pl. SAFe, átnevezi az opsot devopsra, összedobálja a jól hangzó technológiákból a stacket mint egy receptet, aztán reméli, hogy majd jönnek az eredmények, közben pedig csak a dolgok lényege veszik el. Aztán időnként cserélődik a középmenedzsment kezdődik egy újabb iteráció és csodavárás.
Nem tankönyvi devopsról beszélek, a devops lényegi eleme a dev és ops közötti kommunikációs siló problematikájának orvoslása, ha meghagyjük egy külön fókusszal rendelkező, külön csapatként az opsot, nevezhetjük akárhogy, akadályozó tényezőként jelenik meg a szervezetben.
[ Szerkesztve ]
Thank you to god for making me an atheist
-
CyberPunk666
senior tag
válasz bandus #22718 üzenetére
Nem spammeltem körbe a fél világot, szóval a minta elég kicsi, csak megemlítettem, hogy amúgy van ez a mindenkit felvennénk típusú mantra, amit divatból nyom minden cég, "csak tudjon gondolkodni".
De ha jön valaki, aki nem az adott stacken van több éve, akkor egyszerűen félnek. Nem merik felvállalni, hogy esetleg pár hétig/hónapig lassabban halad. Inkább fél évig betöltetlen a pozíció.De ezer ilyen terület van, a félig bevezetett agilitás is ilyen, mindenki tudja, hogy félig csinálni sokkal rosszabb, mint semennyire se, de a legnehezebb lépéseket nem merik meglépni.
Mindenki tudja, de nem merik. Mindenki felvenne bárkit, de senki sem mer. -
CyberPunk666
senior tag
válasz Lortech #22719 üzenetére
A változtatás állami és nagyvállalati módja, hogy először bevezetjük, amit könnyű, például a ki hova ül, ki kinek reportol és mi lesz a titulusa.
Utána azt, ami nehéz vagy drága kihagyjuk, és nem vesszük meg ami kell, nem alakítjuk át, ami már kész, csak nem alkalmas, és nem adunk át hatalmat annak, akinek az adott dolgot vinnie kellene.
standard nagy szervezeti dolog. -
veterán
válasz CyberPunk666 #22721 üzenetére
nekem ne mondd, én két éve próbálok váltani és még nem sikerült jobb feltételekkel helyet találnom, pedig azért nem vagyok halálra fizetve bár én nem it-ban dolgozom.
"a jövötsajnos nemlehet tudni csakhamárotvagy deakormegmár azajelen"
-
Lortech
addikt
De ez hogy néz ki a gyakorlatban? Ki üzemelteti, ki alakítja ki a cicd-t házon belül, ha nem egy devops csapat?
Gyakorlatban egy hatékony, ütőképes, minőségi emberekből álló, devops modellben dolgozó cross-functional fejlesztő csapat rendelkezik többek között azzal a képességgel, hogy a saját maga által választott toolokkal kialakítsa a saját CI/CD megoldását, továbbmegyek menedzselje a buildjeit és releaseit, megtervezze, kialakítsa, üzemeltesse és monitorozza az infráját. A fejlesztői csapatban a mozgástér és autonómia az alapja mindennek, akkor lesz (lehet) agilitás, ha a fejlesztő csapat meg tudja választani az eszközeit, önállóan tud dönteni, és önállóan el tudja végezni a feladatai nagy részét, és nem kell más csapatoktól függnie vagy azokhoz igazodnia. Nyilván szükséges mértékben kell igazodni és kell együttműködni más csapatokkal, de ezt is könnyíteni és elősegíteni kell, processzekkel és adminisztrációval való körbebástyázás helyett (pl. nyiss ticketet minden szarra).
Lehet azt mondani, hogy ehhez a működéshez a feltételek nem adottak sok szervezetben, pl. nem tudják elengedni a kontrollt, vagy nem elég rugalmas a szervezet, hogy megfelelően rugalmasan kezelje a csapatok összeállítását, nincs minőségi emberanyag és emiatt nincs teljesítmény, így bizalom és autonómia - mindenesetre az átcímkézés aligha old meg bármit.[ Szerkesztve ]
Thank you to god for making me an atheist
-
Madwe
nagyúr
válasz skristof #22724 üzenetére
Pontosan. Emelett elfér egy központi sre egység is, akik a toolingot, főbb irányvonalat csinálják, alapok, templateek, poc-okkal, a közös igények lefedésére. De ez jobb esetben scrumként működő, kb dev-es saas egység, nem pedig ops. Support se az ő feladatuk, csak az új featureök alapjainak bevezetése. Vmi hasonló egység azért legtöbb helyre nem árt, h ne kelljen 60 féle megoldást találni azonos problémára. Ettől persze el lehet térni, más toolokat választani, de egyfajta koherenciát teremt.
Ugyanúgy pl vm provisioninghez az alapokat ők teszik le, de ez is nyíltan kontributált tud lenni.
ebből ami szinte mindig kilóg legtöbb helyen s opsos marad az a db csapat sajnos, ami gyakran kilóg az a monitoring/observability infra üzemeltetése aki szintén kicsit opsosabb s silosabb, de jobb esetben ott sincs már nagyon silo…[ Szerkesztve ]
-
Drizzt
nagyúr
válasz CyberPunk666 #22721 üzenetére
Azért stack és stack között is van különbség. Például ha embedded developer vagy, akkor esélyes, hogy:
- Adatbázisokhoz nincs különösebb tapasztalatod.
- Enterprise frameworkok nincs sok tapasztalatod.
- OO-ban lehet van erős tapasztalatod, lehet, hogy nincs.
- Skálázható alkalmazások fejesztésében és tervezésében valószínű, hogy nincs tapasztalatod.
- Elterjed cloud technológiákban is kevesebb esélyed van erős tapasztalatra(, de vannak olyan beágyazott területek, ahol meg nagyon pro lehet ebből az ember!).Ezek most mind minde egyszerű prekoncepciók voltak, amik szerintem egy interjúztató fejében simán megfordulhatnak, ha azt látják, hogy beágyos tapasztalattal jönnél. De ilyen biassal sok interjúztató rendelkezhet.
Akkor sokkal könnyebben belemennek ebbe a váltásba, hogyha más a nyelv, meg más a framework, de alapvetően mégis hasonló problémákat old meg az ember az idő nagy részében.
Legegyszerűbb, hogyha úgyis úgy látod, hogy pár hét alatt át tudnál állni, akkor ezt tedd meg előre a szabadidődben. Kezdj valami hobbi projektet valamelyik célul kitűzött nyelven/frameworkon, s hangsúlyozd ezt ki az önéletrajzodban, meg azt, hogy erre szeretnél haladni. Ha bármit fel tudsz mutatni, hogy mit csináltál, milyen anyagokból dolgoztál, hogy terveznéd folytatni, az az interjúztatók nagy részének tetszeni fog, s ha jó a HR, akkor az ő kapuikat is meg fogja nyitni. Ha van valami ingyenes VOD oktató platformhoz hozzáférés a munkahelyeden, akkor dögivel fogsz találni tök jó anyagokat(, meg szarokat is, de ha jó programozó vagy, gyorsan le fog esni, hogy az oktató tényleg ért-e az adott dologhoz).
I am having fun staying poor.
-
GeeForGolf
junior tag
válasz Lortech #22725 üzenetére
ne köntörfalazzunk: úgy gondolod, h egy fejlesztő legyen fejlesztő is, meg üzemeltető is nem kell ezt túlmisztifikálni, rövid úton elértünk oda, h mindenhez is értsen a kedves delikvens, még akkor is ha ez két külön szakma, természetesen a fizu nem duplázódik. látom én egyébként ezt a trendet már évek óta, nem tudom otthon h megy, itt már nem nagyon találsz olyan fejlesztői pozit, ami ne listázna DevOps cuccokat. kb pont így alakult ki anno a full-stack pozíció is, ne fizessünk má' két embert hiszen hát kód kód, azé' vesszük fel az embert h megcsinálja, most az ilyen huncutságok h front-end meg back-end, hát mi ehhez nem értünk, ő meg ezért kapja a fizetését, dolgozzon
az én szerény véleményem az, h ez a 2 szakma elválasztható egymástól, és a fejlesztő feladata a PR/merge után kb véget is kéne, h érjen (dolgoztam ilyen helyen, és egyáltalán senkit nem zavart, h nem nekünk kellett mondjuk a release/deploy vonalon szarakodni). a jelenlegi cégemnél proper CI/CD van, azaz neked kell kinyomni a cuccot a szerverre is, rengeteg van belőlük, folyamatosan akadoznak, szinte már több időt töltünk a folyamatos javításokkal, mint a kódolással magával. emellett van egy dedikált DevOps team-ünk, ők leginkább azért felelősek, h létrehozzanak/megsemmisítsenek környezeteket, de úgy kb ennyi, szóval mondom, a deploy már a mi felelősségünk. mit mondjak, a legtöbben utáljuk. meg hát nem is pontosan értjük, h miért nekünk kell ezekkel szarakodni - én sem megyek oda a kedves üzemeltető kollegához, h írja már meg a kódot helyettem
-
skristof
tag
azt nem lattam, bocs. szerintem egyebkent ki lehetne adni. de ahogy elottem is irtak, vannak olyan esetek, ahol nincs ra lehetoseg es/vagy kello akarat, igy nem lesz devops kultura sem.
szerintem nincs ezzel baj, lasd GeeForGolf kollegat, o pl latszolag ilyen helyen szeret(ne) dolgozni. en nem.
szerk: termeszetesen hatalmas kulonbseg van termek es projektfejlesztes kozott. az altalad emlitett domainben ezert van az, hogy a fintech-ek megeszik reggelire sebessegben a bankokat.
[ Szerkesztve ]
-
Madwe
nagyúr
válasz GeeForGolf #22730 üzenetére
Ez a devops alapvetése, igen, e2e felelősség, nem csak a működik a gépemen mentalitás. Az hogy ez neked nem tetszik, sajnálatos, az irány attól még ez. Te ragaszkodnál a régi silokhoz, üzemeltesse az üzemeltető, ha meg vmi törik mondjuk prodon, menjen a pingpong h most az infra e a szar, a skálázás vagy a kód... miközben az issue ha egy deployyal jött az esetek 99.99999% kódból vagy max skálázásból ered, te okoztad, de téged nem érdekel.
[ Szerkesztve ]
-
Lortech
addikt
válasz GeeForGolf #22730 üzenetére
Nem kell mindenhez is érteni mindenkinek.
Cross-functional fejlesztő csapatról írtam. Ez nem azt jelenti, hogy egy-egy csapattag külön-külön is rendelkezik minden tudással. Egy fejlesztő csapatban elférnek ops, network, cloud stb fókusszal rendelkező fejlesztők, ugyanúgy mint mondjuk egy test automation engineer is. És attól lesz ez hatékony, hogy mindenkinek van egy közös értése arról, hogy mit kell megcsinálni és mindenki a saját feladatát meg tudja csinálni, míg ha kiszervezed a képességek nagy részét másik csapatokba, akkor nekik át kelladni, hogy mit kell csinálni, aminek egy része fog csak átmenni, mivel nincs ugyanaz az értésük, aztán erre commitmentet kérni, ütemezni, koordinálni, bevasalni rajtuk, aztán ha félremegy, kezdődik elölről és megy az egymásra mutogatás és seggvédés.
Azt értem, hogy nálatok szarul mennek a dolgok, de az egy komoly félreértése a fejlesztői szakmának, hogy devnek csak a kódot kell valahogy összekrampácsolni, utána meg próbálja meg életre kelteni az üzemeltetés, ahogy tudja.[ Szerkesztve ]
Thank you to god for making me an atheist
-
GeeForGolf
junior tag
na jó, de amíg mi eljutunk a prodig, van két szerverünk, mindkettő 100% identical proddal, mindkettőre fel kell tolni a cuccot tesztelni, szóval a probléma sokkal előbb kijön, ha van. de ez egyébként még nem tenné kötelezővé azt, h ezzel a fejlesztő maga szívjon, azért ezt simán csinálhatná az üzemeltetés (szerintem). ja, értem, h szted meg nem, és azt is értem, h a világ errefelé halad, de ennek az egyetlen oka a már fent is leírt fillérbaszó mentalitás, ie vegyünk fel olyan kollegákat, akik mindenhez is értenek, így kevesebb ember kell, fizetést meg nem emelünk arányosan. ha te ennek tapsolsz, az a te dolgod, nem tudom, te h éreznéd magad, ha rád pakolnák a fejlesztői feladatokat is az üzemeltetés mellett
(btw mi az a silo? minden 2. kommentben látom itt, de fogalmam sincs, mire céloztok vele)
-
GeeForGolf
junior tag
válasz Lortech #22733 üzenetére
Azt értem, hogy nálatok szarul mennek a dolgok, de az egy komoly félreértése a fejlesztői szakmának, hogy devnek csak a kódot kell valahogy összekrampácsolni, utána meg próbálja meg életre kelteni az üzemeltetés, ahogy tudja.
nekem nem az a problémám h a kódom ne adj isten szar, és ez kiderül, és ezért visszaküldik, nekem az a problémám, h nekünk, fejlesztőknek kell olyanokkal szarakodni, ami nem a mi felelősségünk kéne, h legyen sztem - ahogy írtam fentebb is, relesae/deployment/szerverek rugdosása, ha vmi nem működik. nyilván ha szar a kódom, így is, úgy is nekem kell megcsinálnom, nem az üzemeltetésért felelős embernek. -
Madwe
nagyúr
válasz GeeForGolf #22734 üzenetére
Nem üzemeltetek hanem fejlesztek, tervezek, poc-olok.
Nem a költségcsökkentés az elsődleges ok arra, amiért a devops mentalitás létrejött (persze lehet ilyen szemmel is nézni s a csúnya cégek csúnya költségcsökkentési terveit látni csak ebbe, szegény alkalmazottak káráa)
Arról szól hogy megszűnnek a silok - a falak a különböző egységek között, nem falakon dobálod át a dolgokat s vársz, egyeztetsz, meetingelsz naphosszat, hanem önálló önjáró egység egy team, ami e2e minden el tud látni (nem egy ember hanem egy csapat személyében) ami sokkal hatékonyabb, sokkal kevesebb egyeztetés, prioritizálás, pingpongozás van, gyorsabb gördülékenyebb lesz az egész. Mellesleg a devek is megtanulják h az h stabil kódot írjanak az ő érdekük, mert ha folyamat törik az infra miattuk, folyamat csippan a pager akkor az nekik fog fájni...ajánlom ezeket az ingyenes könyveket jobbról balra haladva elolvasni...
[ Szerkesztve ]
-
Madwe
nagyúr
válasz GeeForGolf #22735 üzenetére
"h nekünk, fejlesztőknek kell olyanokkal szarakodni, ami nem a mi felelősségünk kéne, h legyen sztem - ahogy írtam fentebb is, relesae/deployment/szerverek rugdosása, ha vmi nem működik"
ahol ilyen alapvető instabilitási gondok vannak, ott szar az architektúra, az infra, minden, elég súlyos az ilyen gond, normál esetben ennek nem kéne jelen lennie...
"nyilván ha szar a kódom, így is, úgy is nekem kell megcsinálnom, nem az üzemeltetésért felelős embernek."
a gond ezzel az, ha elválasztod silokra a devet s opsot, mire oda eljutsz h ok, az én kódom szar s nekem kell kijavítanom azt rengeteg pingponggal tudtad le az opsossal, mind a te midn az ő idejét rabolva, miközben lényegi előrelépés nem történt. Nem mindig van ez így, de iszonyat gyakori ott, ahol falak vannak, megy a mutogatás, várás, deves váltig állítja h szar az infra nem nyúl hozzá, opsos meg váltig állítja h szar a kód, minden más jól működik, napok telnek el s effektív nyomozást senki nem csinál.
Ezzel szemben ha lenne egy devopsos devetek, aki pontosan tudná mi az infrátok, tudná mi a kódotok, tudná mi a business logic sokkal hatékonyabban s gyorsabban emgoldaná... egy sima dev teamnek silokban fogalma se lesz az infráról, egy sima opsosnak fogalma se lesz az általa támogatott kismillió team kódjáról...[ Szerkesztve ]
-
GeeForGolf
junior tag
figyelj, maradjunk abban, h én nem kétlem, h ez tud jól is működni, és csak én fogtam ki éppen egy olyan céget, ahol nem annyira, de az tény, h itt mi sokat szívunk ezzel, és ez nyilván alapvetően meghatározza azt, h én mit gondolok a "kinek a feladata/felelőssége" témakörről. jelen pillanatban úgy látom, ahogy leírtam, de ez nem jelenti azt, h ez így van jól, csak azt, h én ezt tapasztalom.
a könyveket kösz, majd egyszer beillesztem őket a táncrendembe...
-
CyberPunk666
senior tag
válasz Drizzt #22729 üzenetére
Végül úgy döntöttem, hogy nem dobom ki teljesen az eddigi tapasztalatomat és a safety-critical, real-time, szenzorok, autoipar/orvostechnikai részt és az önvezető autó sensor fusion, computer vision, machine learning irányba megyek, meg csinálok egy alkmat msct.
Amúgy ezeket meg is lehetne kérdezni.Ha már ekkora hiány van.
Látom alább például a bootcampes példát.
A szabadidőmben bootcampeseknek szoktam segíteni, tudom mit tanulnak és mennyire. Azt is tudom, hogy a legnagyobb ilyen iskolában milyen mentorok tanítanak. Én a mentorokat nem venném fel egy munkahelyre.
A tanítványaimra a "sose láttak még ilyet' szintű jelzők hangoznak el (dicséretként), és a mentorokat szétszedik szakmailag.
Sajnos ez főleg a mentorokat árazza. Velük mégis szóba állnak a cégek.
De nem érdekel, már kitaláltam az utamat, csak megjegyeztem, hogy ez a bárkit felvennénk csak egy frázis. -
gration
friss újonc
válasz gration #22684 üzenetére
Köszi mindenkinek az eddigi válaszokat!
@Sztenly
Igen, jól érted. Egy közepesen sikeres multis business karriert adtam fel a programozás miatt. Az utolsó évekre középvezetői szintig jutottam, pénzben a mostani fölött voltam, a munkamennyiség elenyésző volt, de utáltam már a semmittevést és az álcából kitalált feladatokat.
A legismertebbet végeztem el, 4 hónapos volt a képzés.
Nagyjából két tucat ember, akikre rálátok, kb. az egyharmaduk 1M+ szinten van (többen már 2 év után elérték ezt), magyar alkalmazotti státuszban. Másik egyharmad, akik különböző okokból szarabb pozikban/cégeknél vannak. Kb. 20% külföldre ment vagy külföldi cégnek contractorkodik itthonról, néhányan vállalkozni kezdtek (mármint ténylegesen, nem a KATA-zásra gondolok), páran lemorzsolódtak vagy más szakmában dolgoznak.
Lehet, hogy régebben még a bootcampekben is volt anyag. :) Tény, hogy minket még elég profi szakemberek tanítottak, nem az egy kurzussal korábban végzett diákok.@Madwe
Na ja, és offert hallottam ennél magasabbat is, durva, hogy mennyire forró most a DevOps mindenhol. Ezek a számok amúgy SSC jellegű fejlesztőközpontokból jönnek.
A datás infót köszi, lehet, hogy a jelenlegi helyemen is el tudok menni egy kicsit data irányba a váltás előtt, és akkor nem leszek teljesen új a területen (bár ennyi pénzért túl sokáig nem szeretnék maradni). Majd beszámolok róla, hogy sikerült a váltásom.@JoinR
Köszi! Szerinted ez miért lehet? Azért, mert a nagy employee brandek így is be tudnak vonzani elég embert, viszont a másodvonalbeli, noname, de nagy cégek kénytelenek pénzben jobban odatenni magukat?@CyberPunk666
Szerintem a bootcamp nem igazán tudást ad, ebben igazat adok az ellenzőknek, hiszen pár hónap alatt nyilvánvalóan nem lehet megtanulni programozni. Valamennyire felhoznak sebességre, ellenőrzik, hogy tudsz-e tanulni és elhitetik veled, hogy van keresnivalód a szakmában, aztán belöknek egy céghez. Olyan, mint amikor a kezelő a gokart orrán állva, az útnak háttal vezetve az arcodba üvölti, hogy - Jobb a gáz, bal a fék, gyerünk! és már ott is vagy a versenyben.
Onnantól meg már úgyis az illetőn múlik, hogy mennyit tesz bele, megelégszik-e azzal, hogy új mezőket vesz fel valami fos webapp obsolate formjaira egy rohadás KKV-ben vagy beletesz még párezer órát a fejlődésbe és nem nyugszik meg, amíg Senior ML Engineer nem lesz a Valleyben.
A bootcampes arcoknál a mindset az egyik versenyelőny szerintem, talán több közöttük a motivált, agilis, fejlődni akaró ember, míg az egyetemet(IT) végzettek között gyakrabban találkoztam azzal a sértődött és kényelmes hozzáállással, miszerint ha már 5+ évet szívott a műegyetemen, túlélte az aberrált, megkeseredett öregemberek csuklóztatásait áramkörtervezési gyakorlaton, akkor ő elkészült, mindent tud a szakmáról, nehogy már tanulnia kelljen, mint egy iskolásnak.HR gatekeeperek: nekem az a tapasztalatom a bootcampes háttérrel, hogy (legalábbis a nagy, nemzetközi cégeknél) nem kizáró ok, simán behívnak interjúra, a tech körön viszont a bootcampes tudás, meg a code monkey gyakorlat már egyértelműen kevés az üdvösséghez.
disclaimer:
Mielőtt valaki sértve érzi magát és nekem esik, az ellenkezőjét is láttam mindkettőnek. Bootcampesből is bőven van olyan, aki pincérből betanított kódmunkás lett, és elég neki, hogy széken ülhet és légkondicionált az iroda. Nem véletlen, hogy romlik a megítélése ezeknek a képzéseknek, gondolom egyre több a szerencsevadász és a trendet meglovagló ember, akinek nincsen különösebb szakmai célja, csak egy relatíve kényelmes és jól fizető melót keres.
És természetesen dolgoztam már zseni/esőember kaliberű architectekkel is, és gondolom annak idején ők is átszaladtak a formális képzésen, de általában nem ők szokták mantrázni a klasszikus BME katonatörténeteket.[ Szerkesztve ]
-
Jhonny06
veterán
válasz CyberPunk666 #22740 üzenetére
A tesztelőknek sose fizettek sokat. Azt mondjuk nem tudom, hogy mi a különbség az embedded és a C++ között, mert beágyazott területen is C++-ban fejlesztesz
[ Szerkesztve ]
-
addikt
válasz skristof #22731 üzenetére
szerintem egyebkent ki lehetne adni.
Hogy a vérbe lehetne kiadni? Egy pénzintézet cicd folyamatát külsős beszállítóknak? Szerintem Pekingig hallatszana a risk management sikítása ennek láttán. A praktikus okokról már nem is beszélve, mármint hogy 20 beszállító 20 különböző cicd folyamata mennyi idő után borítaná be az egész release folyamatot. Tippre pár hét alatt. Olyan apróságokról nem beszélve, hogy hozzáférést akarsz adni beszállítók számára pénzintézeti produktív rendszerekhez. Nem jó ötlet. -
kovsol
titán
Lassan a topicot át lehetne nevezni valami Fejlsztők beszélgetnek egymás köztre, vagy a Ti mit hívtok devopsnak topicra.
[ Szerkesztve ]
May the Force be with you!
-
JoinR
senior tag
válasz skristof #22724 üzenetére
Ez működik egy 100 fős cégnél, afelett csak akkora overheaddel lehetne betarttatni a céges security compliance-t (meg sok mást, hogy ne találja fel mindenki a kereket pl.), hogy nem hiába nincs ilyen a gyakorlatban.
#22741 gration:
Igen, valszeg valamivel könnyebben találnak embert, illetve az egyéb juttatás, előrelépési lehetőség akár jobb lehet, amiért esetleg megérheti kevesebbet kapni.[ Szerkesztve ]