DevOps kollégát keresünk! (x)

Hirdetés

Szeretnél üzemeltetésben és egy fejlesztő csapat Ops jellegű támogatásában részt venni? Keresünk egy tehetséges, legalább medior szintű, tapasztalt DevOps kollégát, aki nem csak saját rutinjait követi, hanem alkalmazkodó képességei segítségével a mi infrastruktúránk adottságaihoz is rugalmasan tud igazodni, és nyitott az új ismeretek megszerzésére.

Fontos, hogy olyan szabadúszó ember legyél, akinek nincs teljes állása, mert tapasztalatunk szerint ahhoz túl sok a tennivaló. Az utolsó két szeretett kolléga is azért ment el, mert teljes állás mellett túlterheli ez a munka. Maximum másik részmunkaidő mellé ajánlott!

A csapatunkról:

Jelenleg három termék fejlesztésén dolgozunk, amelyek a magyar kulturális és zenei élethez kapcsolódnak. A csapatunk 12 szabadúszó fejlesztőből és üzemeltetőből áll, akik főleg remote módon dolgoznak. Alkalmanként összejövünk retrokra, tervezésre és csapatépítésre az A38 állóhajón, amelyet a brigád otthonának tekint.

Feladatok, Stack:

Néhány dolog, amivel biztosan dolgod lesz:

  • Kubernetes, helm és helmfile használata
  • Rendszertervezés és -üzemeltetés Linux (Debian) operációs rendszeren, fizikai szervereken, és virtualizált környezetben is
  • Docker, docker-compose és Dockerfile használata
  • Routing, switching, linux tűzfalak, terheléselosztók
  • Ansible használata
  • Python programozás
  • Gitlab és pipeline-ok használata
  • Consul K/V
  • Prometheus és grafana
  • MariaDB / Percona XtraDB
  • OpenVPN
  • minio
  • redis
  • certificates, Let'sEncrypt
  • Makefile
  • Backup rendszerek (pl. borg, rsync, rclone)

Előny ha vannak ismereteid ezekben a technológiákban is:

  • Nomad
  • XCP-NG, Xen Orchestra, Terraform
  • ZFS, FreeNAS
  • traefik
  • Rundeck
  • Graylog
  • PHP/Symfony/Laravel/NextJS (fejlesztők támogatása Ops oldalról)

Ami az emberi részét illeti, fontos nekünk:

  • Rugalmas hozzáállás az infrastruktúránkhoz
  • Kiváló problémamegoldó képesség
  • Képesség a csapatmunkára és a projektek hatékony kezelésére
  • Nagyfokú önállóság
  • Jó kommunikációs készség

Cserébe mi is érett hozzáállást tanúsítunk veled szemben, “minimális bürokrácia maximális átláthatóság” elvén, bizalom alapú viszony építésével.

Juttatások:

  • 9.000-10.500 forint/óra (+Áfa) vállalkozói szerződéssel

Egyéb tudnivalók:

  • Rugalmas munkaidő, akár részmunkaidőben is végezhető tevékenység.
  • Nincs ügyelet vagy on-call support.

Minimum 80 (maximum 120 óra) rendelkezésre állás havonta, amit szeretnénk kérni.

CV Küldés, jelentkezés, további infó:

  • szilagyi.akos@a38.hu

[Az A38 Hajó megbízásából készített, fizetett anyag.] 

( Sixday v | 2023. 03. 29., sze – 12:11 )

A feladatokbol leforditva: ez egy teljes munkaidos allas, de csak fel honapot akarnak erte fizetni.

Én nem igazán tudom hová tenni ezt a hirdetést.

Ha kerek 10eFt/órával számolunk, akkor ez 800e Ft per hó. Alanyi adómentesként.
ÁFA körösként +ÁFA. De ez nem lényeges, kivéve, ha valaki ÁFA-val tud/akar trükközni.

Na most ha a 800-ból leadózik (optimalizál), akkor nagyon jó esetben maradjon neki kb. 500e Ft. Havonta. IT alkalmazottként rendben lehet, IT vállalkozóként ez nagyon rossz üzlet. Szerintem.
Ráadásul aki ennyi féle technológiához ért, az nem 500e Ft-t akar keresni.

Nem csodálom, ha az elődök ezt csak mellékállásként tudták csinálni.

Időben félállás, valóban, csak nem mindegy, hogy a kapcsolódó egyéb költségeket ki viseli? Mert ha félállás, akkor a munkaviszonyhoz kapcsolódó közterheket, a fizetett szabadságra eső bért, a táppénzt a munkáltató viseli, ha viszont óradíjas vállalkozó, akkor ezeket neki kell kigazdálkodni a szerződéses összegből. (Részmunkaidő esetén is jár a minimum 20 munkanap alapszabadság, illetve az életkor/gyerekek/stb alapján számítandó plusz szabadság. Azaz a havi kb. 20*4 órából kb. 18.5*4 órát lehet munkavégzésre számolni, a többit fizetett szabadságként kapja a dolgozó - azaz a 20*4 órás részmunkaidős dolgozó valójában havi ~74 órában végez munkát. Lehet persze egy 80 órás kontraktori megállapodás esetén is úgy csavarni az elszámolást, hogy a ~74 az legyen a 80, de ez csak az egyik szelete annak, amit a bérhez képest a kontraktornak viselnie kell.)

Mondjuk az is kérdés, hogy az órákat hogyan számolhatja el az, aki szerződik erre a feladatra? Minden megkezdett óra egész órának számít? Az éjjel/szabadnapon/munkaszüneti napon végzett munka milyen szorzóval számít?

 

Nem azzal van probléma hogy tornyosulnak a melók, hanem hogy ennél drágább a vállalkozóként az időd - megbízóként te nem a te feladatod elvégzését fizeted meg, hanem a megbízott idejét.

Én a helyetekben átpriorizálnám a feladatokat és azokat adnám ki, ahol nem szorít az idő - mert az elvárt havi 80 - 120 óra lesz sok ebben a történetben, egyébként én is eljátszanék a hajón.

Ez nem tudom micsoda, de gyanús, hogy mindenféle építésügyi törvényre hivatkozik, meg a díjkalkulátorban a Docker és a Python helyett olyanok vannak, hogy közlekedési, meg bányászati építmények, úgyhogy nem hiszem, hogy túl releváns a témában. :)

Ezt talaltam meg csak, alapvetoen a magyar mernoki kamara ajanlasa egy atlag mernokre. Regen volt ablazat mindenfele szakterulettel, de valahogy nincs meg most. Az IT a dragabb kategoriak kozott volt mindig.

Amugy ja, eleg gaz a honlap. Eros kepzeloero kell hozza.

--szerk--

A online MEDI-ben ott van pl egy villanymernoki doksi a kulonbozo munkafolyamatok szorzoival. Ez van a legkozelebb az IThez.

Es mekkora a szorzo a melos fizetese es a rezsioradij kozott? Persze, Domby huptars hozzaszolasaibol is az latszik, hogy kisse osszemosodik a ketto.

A "megoldom a konyvelest, ugyvedet, biztositast es minden mast okosba (azt se tudom, mirol beszelsz), mint egy katas pizzafutar" valahogy nem igazan jo hozzaallas egy bizonyos szint folott.

Szerintem dolgozó bekerülési költség x2 árazás még csődveszély. Alá semmiképpen nem mennék. 

Bekerülési költségben benne van a rá jutó minden költség, nem csak a fizetés. 

Ps.: X2 alá csak munkaerőkölcsönzők tudnak menni 

Nyilván a megadott sáv alatt és fölött is bőven lehet "munkát" ÉS "munkást" találni, de ennyit bír el a pozíció ár/érték arányban. A bérsáv valamennyire nyitott felfelé, de a leírt technólógiák által elvárt tudás-szint kb ezt az órabért tükrözi.

Nem akarunk super-talented k8s admint aki GO-ban 4 óra alatt megír egy CNI-t, napi 400e-ért. Nem, nem rá van szükségünk :)

Az hogy nektek ennyi penzetek van ra nagyon nem egyenlo azzal hogy a tudas szint ezt az orabert tukrozi szerinted. Marpedig itt az elso ervenyes sajnos es nem a masodik.

Ez itt minimum 10 ev senior devops+sysops tapasztalat.

- eros kubernetes, helm, docker
- fizikai es virtualis szervermanagement ismerete, hardware, xen, vmware vagy eppen ki tudja mi van nalatok
- teljeskoru halozati tapasztalat, routing, tuzfalak, switchconfig, VPN stb.
- CI/CD teljes koru ismerete a vonatkozo gyakorlattal
- eros adatbazis uzemeltetesi gyakorlat, a percona xtradb nem amatoroknek valo jatek, persze amig nincs vele gond addig mindenki aztmondja hogy egyszeru, mondjuk kerdes hogy mennyire mission critical a rendszeretek, vegul is ha raer 3-4 orat allni mire a backupbol ujraepiti valaki akkor nem muszaj profira bizni :)

Es ez csak a fo lista volt. A "jo ha van" listat nagyon joindulatuan ignoraltam. Meg azt is hogy ha nektek olyan valaki kell aki minderre behazudja hogy ert hozza, aztan kozben meg max. hallott rola.

Ez szerintem jelenleg Budapesten jo netto 1.5 milla havonta foallasban, leadozva. Ti ennek a felet akarjatok fizetni, de netto helyett bruttoban, contractorkent, nulla juttatassal vagy barmilyen munkahelyi biztonsaggal, nincs szabi, betegszabi, stb. Arrol nem beszelve hogy az ilyen kaliberu contractor ugyfelek ritkak mint a feher hollo, szoval egy ilyen szakember vagy szar munkaval tolti fel a maradek idejet olcson (ami nem fog megtortenni), vagy ahogy te is tapasztaltad mellettetek foallasa van, de ahhoz meg tulsagosan demanding-ok vagytok.

Egy 80 órás kontraktori megbízás teljesen más tészta mint egy 8 órában bejelentett munkahely, ahol fixen kell dolgozni. A kontraktor nálunk akkor dolgozik amikor ideje/kedve tartja, és feleannyit mint amennyit egy 8 órás alkalmazott. Nyilván nem fog annyit kapni :) A 1.5millával egyetértek amugy, legalább annyit érdemel egy bejelentett állásban dolgozó IT szakember mostanság, aki rendelkezik a fenti tudás java részével.

 

Percona xtraDB-nél 3-4 órát állni elég nonszensz dolog, hisz egy xtrabackup8-al készült restoreból 4 perc alatt feláll az cluster első node-ja, ami az appokat azonnal ki tudja szolgálni. A 2-3(-4-5.) node nyilván még 5-5 perc amíg SST-vel átsyncel, de nem 3-4 óra. Nyilván megvannak az xtraDB korlátjai, pl az online DDL még mindig trehányul van megoldva, már bocs a kifejezésért, de szerintem egy egész kiforrott, stabil megoldás ezt leszámítva. Nyilván lehet akkora gond, hogy 3-4 órát áll a rendszer, de pont azért van HA megoldás, hogy lehetőség szerint megpróbáljuk ezeket elkerülni, és az ops-nak ne legyen álmatlan éjszakája.

A kontraktor nem munkabért kap, hanem óradíjat. A kettő nagyon nem ugyanaz. A 80 óra az kontraktornak és a félállásban felvett munkavállalónak is 80, munkával igazoltan eltöltött óra - csak az egyiknek minden költségét magának kell fizetnie abból, amit kap érte, a másiknál a mukaeszköztől kezdve a TB-n meg egyéb közterheken át a fizetett szabadságig a munkáltatót terheli a költség.

Egy 80 órás kontraktori megbízás teljesen más tészta mint egy 8 órában bejelentett munkahely, ahol fixen kell dolgozni.

Ez igy igaz.

A kontraktor nálunk akkor dolgozik amikor ideje/kedve tartja

Ez a ti dontesetek. Ha a feladat es a szervezet ezt megengedi, hajra. A foallasu munkavallalok is dolgozhatnanak kotetlen munkaidovel, ha ez epp mukodik a cegnek.

és feleannyit mint amennyit egy 8 órás alkalmazott.

Kb igen. Egy alkalmazottat kb 1600 produktiv/projekt oraval szamolhatunk Magyarorszagon. Kb 250 munkanap - betegallomany, szabadsag, tovabbkepzes stb. ugyebar.

Nyilván nem fog annyit kapni

Mit?

Brutto fizest? - Lehet, hogy nem. Ehhez azert kb. koze nincs a cegeteknek (gondolom meg nem vagyok akkorak, hogy mindenfele etikus normakat kenyszeritsetek ra a partnerekre), ha egyszer vallalkozoi szerzodest kottok vele.

Vallalkozoi rezsioradijat? - Hat, ez azert lehet, hogy tobb lesz, mit egy foallasu alkalmazott havi bruttoja. Cserebe nem kell szorakoznotok a betegallomanyaval, szabadsagaval, HR nyugjeivel, nem kell tovabbkepzesre kuldenetek, konnyen megszabadultok, ha leepites jon stb.

A 1.5millával egyetértek amugy, legalább annyit érdemel egy bejelentett állásban dolgozó IT szakember mostanság, aki rendelkezik a fenti tudás java részével.

Jó, akkor számoljunk ezzel, évente ~250 munkanap van, ebből lejön ~30-35 nap szabadság, ~5-10 nap betegszabadság, pár nap egyéb fizetett távollét, általában marad tisztán ~200 munkanap, 1600 óra. Nettó 1,5 millió a cégnek kerül évente ~32 millió forintba, plusz iroda, eszköz egyebek, de az ehhez képest már elenyésző, szóval 20 ezer forint per óra a munka. Szóval a contractor ennyit kell számlázzon, hogy neki kijöjjön a matek, mert neki nincs fizetett szabadság, betegszabadság, egyéb juttatás, munkavállalót megillető jog.

Ehhez képest ti akartok adni fele ennyit. Fele ennyi pénzből egy nettó 750 ezres főállás jön ki, azért meg nem kapod meg mindazt, amit kérsz cserébe.

https://iotguru.cloud

A hirdetésben nincs meghatározva tudásszint, technológiák vannak felsorolva, amit egy magyar KKV az on-prem alapú infrastruktúrájában használ.
Nem fognak találni olyan jelentkezőt, akinek az összes felsorolt technológiában releváns tapasztalata van, viszont az elsajátitása nem okoz problémát egy senior számára.

Ok, ha valaki olyat akar felvenni mint az indiaiak akik ha olvastak egy blogposztot valamirol a neten mar beirjak a cv-jukbe hogy ok ebben expertek akkor hagyjuk is :)

Tapasztalatom szerint egy cegnel az az elvaras ha valami bele van irva a cv-dbe akkor abbol a prod rendszert rad lehet bizni es nem lesz belole leallas, meg egy 1 oras feladaton nem fogsz 1 hetig dolgozni azert mert meg a budos eletben nem lattal meg ilyet kozelrol elesben. Ha itt nem ez a helyzet akkor reszemrol tema lezarva :)

Leteznek olyan emberek akiknek van relevans tapasztalta a teljes felsorolt stackben, csak ok minimum annyit kernenek amit mondtam, de a legtobb esetben nem kernek mert reg kulfoldon/kulfoldre dolgoznak.

Vajon hány olyan IT-s lehet, aki expert Python-ban, OpenVPN-ben, fizikai routing-ban, kisujában van a Kubernetes architektura, álmában Docker fájlokat írogat és SQL szervereket optimalizál?
Esetleg még NodeJS-t hegeszt, ZFS-t csuklóból ismeri hogy egy összeomlott storage-ot meg tudjon menteni ÉS ezt egy magyar nem IT főprofillal rendelkező KKV-nál akarja kamatoztatni,
ahol az operáció jelentős része éjszaka történik.

Lehetséges output: 1.) fejlődni képes emberünknek a tanulásra forditott idejét kifizetik 2.) soha nem lesz betöltve a pozició 3.) rájönnek, hogy a megálmodott pozició ebben a formában nem is igazán fontos számukra (szerintem lassan itt tart a dolog)

Nem kell expertnek lenni (nyilván), de ne most lásson először python-t, legyen fogalma a felsorolt dolgokról, és ne most üzemeljen be először SQL szervert. Nem tartom nagy mágusnak magam, de elmúlt 20 év alatt mindennel találkoztam a fentebbi dolgok közül. Eddig is voltak devops pozik nálunk, és mindenki értett minimálisan a fentebbi dolgokhoz, szóval nem légből kapott a stack.

De, ez pontosan az.

Ha találnak is embert aki ezzel mind hosszútávon hajlandó is foglalkozni, folyamatosan kockázatot fog jelenteni a kiesése, valamint egészen biztosan nem fog tudni ezekben mind hatékonyan dolgozni, minőségi munkát végezni.

Mindezt a tetejébe alulfizetett részmunkaidős alvállalkozóként, akinek nyilván akkor fognak szólni, ha tényleges munkavégzésre van szükség, a tanulásra fordított idejét tehát a saját zsebéből kell fizetnie.

Elég, ha váltogatni kell ezek közt, ma dockerfilet írsz, holnap kubernetest buzerálsz, harmadnap meg az openvpn-t reszeled, negyedik nap a routereket meg a switcheket programozod, leolvadna az agyam egy hét után.

Eleve aki IaaS-t használ, még a fizikai infrát is csinálja meg hozzá? Minek az IaaS akkor...

Az biztos, de aztán az se jó, ha valamihez meg hónapokig nem kell hozzányúlni, mert akkor meg lehet mindig újratanulni. Lehet, hogy öreg vagyok, de én ezt a feladatot kettébontanám infra felépítésére, majd a mindenféle ...aaS használatára. Pl. összerakom a k8s-t, de a mindenféle yaml-t a mikroszervízehez írja meg a fejlesztője (vagy a devopsos). Úgyis a fejlesztők szokat sírni, hogy nekik k8s kell, mert mindehez API-t akarnak.

Azért nem minden annyira szar, hogy nem megy el pár hónapot valami kritikus sebezhetőség nélkül :) Főleg az infra alacsonyabb szintjein, ahova már amúgy is csak egy-két privilégizált user jut be (remélhetőleg nem olyanok, mint a LastPassnál).

Most az, hogy a host kernel nincs frissítve minden lokális CVE miatt, és nincs hetente rebootolva a gép, nem biztos, hogy igénytelenség.

Az, hogy a trendi konténerekben meg 2015-ös CVE-k vannak, mert ezek olyanok, mint a Windows installerek, hogy minden függőség egybe van csomagolva, ja, azzal szívjon a DevOpsos.

Most az, hogy a host kernel nincs frissítve minden lokális CVE miatt, és nincs hetente rebootolva a gép, nem biztos, hogy igénytelenség.

De, legyen frissítve, legyen reboot, legyen olyan az infra, hogy ne legyen ebből baj.

Az, hogy a trendi konténerekben meg 2015-ös CVE-k vannak, mert ezek olyanok, mint a Windows installerek, hogy minden függőség egybe van csomagolva, ja, azzal szívjon a DevOpsos.

Az ugyanúgy igénytelenség, de más igénytelensége ne legyen más kifogás.

https://iotguru.cloud

Ezt valahol meg lehet tenni, valahol nem.

Nem lehet megtenni? Hopp, ott egy megoldandó feladat.

Ha nem fontos annyira, hogy kiesés nélkül menjen, akkor a kiesés elviselhető. Ha nem viselhető el a kiesés, mert fontos, akkor legyen megoldva, hogy ne okozzon gondot a kiesés. Ez sokszor csak álkifogás, hogy nem lehet kiesés, mert jaj, mi lesz, megáll a cég, felrobban, világvége... mert akkor nem egy darab van belőle.

https://iotguru.cloud

De az épp aktív session-ok meg mennek a levesbe. Reboot előtt van még teendő, hogy ne legyen rajta aktív folyamat.

Hopp, ez is feladat... előbb-utóbb eljutunk oda, hogy meglesz a gyökere a problémának. :)

Olvasnivaló: https://en.wikipedia.org/wiki/Five_whys

DevOps szemléletet nem lehet csak úgy bevezetni.

https://iotguru.cloud

Webes session, de az adott munkamenethez tartozó adatok csak azon az appszerveren állnak rendelkezésre, amelyiken a munkamenet a bejelentkezéssel elindult - nagyjából az alapokig le kéne ásni, és ott elkezdeni az újragondolását az egésznek ahhoz, hogy a munkamenetek adatai valamennyi node számára hozzáférhetőek legyenek...

Ha lehet tudni, hogy adott node-on hány aktív session van, az még a jobbik eset. Van, ahol gyakorlatilag ez sem deríthető ki...

Hopp, egy feladat: legyen kiderítve. Ha erre nincs idő, akkor nem fontos a szolgáltatás és a rendelkezésre állása se fontos, tehát újra lehet indítani.

https://iotguru.cloud

Az van, hogy amivel húzod a népet, azt értjük, és nem az alsó, hanem a menedzsment szinten szokott hiányozni az igény erre. Értsd, nincs rá pénz, idő, vagy egyik sem, hogy legyen aki ezzel mélységben foglalkozzon. A fantasztikus felületesség mindent átitat manapság. Megint azt tudom mondani, hogy masszív forgalmú és nyereségű cégek a méretükhöz képest láthatatlan összeget költenek ájtira, amikor baj van, akkor 1 hétig érdekes, látják, hogy azért nem 500ft a megoldás, és el is hal az "érdeklődés".

Biztos vannak olyan helyek, ahol ezekre ott az idő, meg a minden, de valahogy nem érzem általánosnak.

Ha kivesszük a képből azokat a mikrovállalkozásokat, ahol konkrétan el kell dönteni, hogy az adott pénzből IT fejlesztés legyen, vagy bérfejlesztés, vagy a tulajdonos autójának fejlesztése, akkor azért a fennmaradó vállalkozások körében lehet ilyesmiről beszélni.

Általában ott szokott félrecsúszni a dolog, hogy a kockázatkezelés is egy szakma, amit valamennyire az IT-nak és a pénzügyi döntéshozónak is ismernie kellene, hogy legyen egy közös nyelvük.

Az van, hogy amivel húzod a népet, azt értjük, és nem az alsó, hanem a menedzsment szinten szokott hiányozni az igény erre.

A menedzsment meg ezzel egy időben azzal jön, hogy az alsó szinten nincs igény erre.

Biztos vannak olyan helyek, ahol ezekre ott az idő, meg a minden, de valahogy nem érzem általánosnak.

A legtöbb probléma azzal van, hogy nem tudnak értelmesen kockázatokat se felmérni, se megelőzni, se kezelni. Mert azzal munka van, meg különben is érteni kellene hozzá.

https://iotguru.cloud

Vagy igeny az volna ra, mert jo kis kihivas, de egyszeruen nem eri meg. Persze, hogy ezt lassak, mar fel kellett merni az igenyeket (beleertve a munkatarsak igenyet/ehseget a kihivasra),  kockazatokat es a ceg rendelkezesere allo eroforrasokat (beleertve a rendszertervezoi, programozot kompetenciakat, es azok fenntarthatosagat) stb.

Egy in-service upgrade/rollback egy-egy bonyolultabb logika eseten nem trivialis. Siman rakoltheted a fejlesztesre es karbantartasra szant penzed 10-20%-at ilyesmire. Es akkor is csak bizonyos feltetek teljesulese eseten megy majd jopar megszoritassal. Ezt szembeallitod egy tervezett es kommunikalt karbantartasi idoszakkal, amikor esetleg teljesen all a rendszer.

Vagy igeny az volna ra, mert jo kis kihivas, de egyszeruen nem eri meg.

Ha nem éri meg, akkor nem fontos, újra lehet indítani.

Egy in-service upgrade/rollback egy-egy bonyolultabb logika eseten nem trivialis.

Ha félsz tőle, csináld gyakrabban. Ha gyakran kell csinálni, automatizáld.

Siman rakoltheted a fejlesztesre es karbantartasra szant penzed 10-20%-at ilyesmire.

Kell is. Ha az IT költségvetés ~20-25 százaléka nem refactor és infra fejlesztés, akkor ott a szőnyeg alá söprődnek a problémák és idővel a cég egy hatalmas szargalacsint görget maga előtt.

Ezt szembeallitod egy tervezett es kommunikalt karbantartasi idoszakkal, amikor esetleg teljesen all a rendszer.

Nem, nem állítom szembe. Azt kérdőjelezem meg, hogy ha valami szolgálatásnál kieséssel jár a infra frissítése, akkor az nem fontos annyira, hogy ne lehetne leállítani.

Ahogy írtam már: 

1, Ha fontos a rendelkezésre állása a szolgáltatásnak, akkor redundáns és egy-egy node leállhat.

2, Ha nem fontos a rendelkezésre állása a szolgáltatásnak, akkor szintén leállhat.

Nincs más opció.

https://iotguru.cloud

Van ex kolléga, aki FAM vizsgával naponta dolgozik úgy, hogy az adott berendezés feszültség alatt van. És köszöni szépen, ő is él, a kollégái sem hullanak, mint az őszi legyek - be kell tartani az előírásokat, a munkautasításokat, és persze alaposan átgondolni hogy mit és hogyan fog csinálni, mielőtt bármihez is kezdene.

Dolgozott nálam már úgy (amúgy rendes, vizsgákkal stb. rendelkező) villanyszerelő, hogy kifejezett kérésem ellenére nem kapcsolta le a kismegszakítót, a "ó, én itt-meg ott távvezetékeken dolgoztam feszültség alatt, meg ipari környezetben, ahol nem lehet csak úgy lekapcsolgatni - meg különben is a jó villanyszerelő nem vezető" felkiáltás után félórával úgy megb***ta az áram (Józsi, nem is mondtad, hogy a bejövőt már rákötötted!), hogy ugrott a létráról és félóráig káromkodott. 

Nem is engedtem be többet a lakásba. Az én lelkemen ne száradjon egy idiótának a halála sem.

Ez nem jó ötlet. Minden egyes alkalommal a szumma megúszás esélye csökken.

Autóba se ülsz, mert minden egyes alkalommal a szumma megúszás esélye csökken? A FAM egy szakma, gyakorolni kell, ugyanúgy igaz rá, hogy ha félsz tőle, csináld gyakrabban.

https://iotguru.cloud

Nem munka van, hanem áttolják a népet a szuperfontos új projektre, meg a régiek patkolására. Amíg valami elketyeg valahogy, addig lehet próbálkozni azzal, hogy hát cserélni kéne, legalább valami karbantartás félét előadni, de nem hagyják jóvá. A részemről ameddig el lehet jutni a munkaidő, szerződés keretében addig eljutok, de ha az N darab ajánlat közül megveszi a legolcsóbbat, úgy hogy pontosan tudja miért kevés neki valójában, akkor ez van.

Olyan eset is volt, hogy már annyira tolták a szuperúj projektet, hogy veszekednem kellett, hogy térjenek már észre, mert ha nincs befejezve semmi, abból ordas pofára esés lesz. Szerencsére legalább valami foganatja volt. Ezzel szemben tényleg rendre azt látom, hogy óriási összeborulás jön (hiszen a win10 jólesz szervernek valahol VM-ként), aztán amikor a rendes megoldás "sokba" kerül, akkor hirtelen hát valahogy elsőre csak "még értékeljük a lehetőségeket" duma van, aztán semmi. Eközben pedig látjuk, hogy ugyanazt használják tovább.

Azt tényleg nem tudják felmérni, hogy mekkora aknamezőket hagynak, illetve hozzá vannak szokva, hogy ohát ezt majd nekik itt az ájtis gyorsban megoldja. Természetesen ő sem lesz csodatevő és "megoldja" valójában, ami valahogy jó lesz. Ebben benne van az, hogy Windows 7-en vannak még egy csomóan, nem frissül a Win10, zéró mentést készítenek bármiről és még sorolhatnánk, ebben még hol van egy cluster vagy bármi. E mellett ott járunk, hogy tényleg nincs ember arra a mennyiségű feladatra, amire valójában szükség lenne KKV és felette szinten.

:) Nem értik ezt úgysem. Ha leáll/meghal/végelesz, akkor ájti a hibás, oldja meg, huha, és hogy fordulhatott elő. Tényleg nagyon nagyon kevés helyen teljesül a zen állapot, hogy akkor aztán húde megcsinálják.

Újabb valós példát tudok felhozni, hogy amikor a túlképzett bölcsész bedobta egy tóba (nem vicc, szó szerinti) a notiját, akkor utána kollégával üvöltözött, hogy miaz hogy nem tud adatot visszahozni, és őt ne várassa. A céges policy az volt, hogy mindennek a hálózati meghajtókon kell lennie, ami azon kívül van, az kvázi nincs, arról nincs mentés. Nemcsak leírva volt, de többször el lett szóban is mondva a népnek. Végül kisírta, hogy egy profi adatvisszahozó cég számláját azért felerészt a cég fizesse.

Nekem amúgy nem kell magyaráznod, csak próbálom jelezni, hogy milyen messze a valóság attól, ami egyébként nemcsak ideális, de fontos is lenne.

Nem értik ezt úgysem. Ha leáll/meghal/végelesz, akkor ájti a hibás, oldja meg, huha, és hogy fordulhatott elő.

1, Szépen el kell magyarázni, hogy miből választhat kettőt. 

2, Hagyni kell őket a faszba, hogy majd Ifj. Vér István megoldja. Ha te vagy Ifj. Vér István, akkor pedig megtalálta a zsák a foltját.

https://iotguru.cloud

Vannak, akik szeretik a kihívásokat.

Főleg Ifj. Vér Istvánok szeretik az ilyen kevés pénzes kihívásokat.

Ja, úgy könnyű, hogy mindenre is van pénz! Úgy mindenki meg tudja csinálni! Úgy a nehéz, ha semmire sincs!

Most kezdted bizonygatni, hogy nem lehet jól megcsinálni, csak szarul lehet megcsinálni, mert a valóság nem elmélet.

https://iotguru.cloud

Hát nem a közszféra és nem is érett régi nagy cégek, hanem tipikusan zöldmezős startup projektek ezek, némelyik már meghalt üzleti okból, némelyik meghalt technikai okokból, kettőn épp dolgozok, viszont NDA tipikusan van.

Amúgy mit akarsz ebből a terelésből kihozni? Hogy csak szar projekt van?

https://iotguru.cloud

ahol ne a pénz lett volna a tender súlyozásánál az első két helyen.

Melyik pénz? Az upfront investment, vagy a TCO? Ja, olyat én is láttam, ahol a pontozásnál 80% volt az induló költség, 20% a maintenance, be is húzta előlünk egy másik cég a pályázatot, aztán kiderült, hogy a győztes pályázatban X forint volt az első éves költség, 1.2*X az éves (!) maintenance. 

Egyébként nem kell minden munkát elvállalni, a nektek túlságosan kispénzű ügyfeleket egy szinttel lejjebb kell delegálni. Ebben semmi szégyellnivaló nincs egyik félnek sem. Nálunk is volt olyan ajánlatkérés, ahol az ügyfél teljesen el volt tévedve, tízszer akkora árat mondtunk, mint ami a büdzséje volt a projektre, továbbküldtük egy partnerünkhöz. Azóta is jóban vagyok az ottani vezetővel, ő meg azt a szolgáltatást kapta, ami ár-érték arányban nekik a legjobb volt.

Egyébként is, ha jól rémlik, Franko freelancerként tolja az ipart, teljesen megértem, ha a véges mennyiségű szabadidejében megválogatja, milyen munkát vállal el.

Mondasz?

Nem. Dolgoztam könyvvizsgáló cégnél az IT előtt, de sok fejfájást okozna nekem ilyenekről beszélni nyilvánosan.

Mert szemmel láthatóan vagy lövésed nincs - ahogy mások is rámutattak -, hogy mi a valóság, vagy csak szimplán trollkodsz. Ha te csak korlátlan büdzsével rendelkező projektet látsz, akkor más nem is létezik, miközben amiról te beszélsz, az lehet, hogy létezik, de hogy nem az a jellemző, az holtbiztos. Mégis, szajkózod, hogy úgy kéne mindenhol csinálni, ahogy te csinálod.

trey @ gépház

Mert szemmel láthatóan vagy lövésed nincs - ahogy mások is rámutattak -, hogy mi a valóság, vagy csak szimplán trollkodsz.

Az egész dolog ugye onnan indul, hogy a DevOps szemlélet van megbaszva sok helyen, lásd https://hup.hu/comment/2903999#comment-2903999

Igen, tudom, hogy van sok szar hely, ahol a közelében nincsenek a DevOps szemléletnek vagy kineveztek valakit, aki a "devops": https://hup.hu/comment/2904022#comment-2904022

Ezeket mind leírtam, csak gondolom nem olvastad el.

Ha te csak korlátlan büdzsével rendelkező projektet látsz, akkor más nem is létezik, miközben amiról te beszélsz, az lehet, hogy létezik, de hogy nem az a jellemző, az holtbiztos.

Nem, ez nem korlátan büdzsé kérdése, hanem szemlélet kérdése, ami segít abban, hogy olcsóbb legyen végül a projekt. Azon múlik, hogy az ott dolgozók valami régi bútordarabok, akik ~10-15-20 éve nem tudtak lépést tartani az IT fejlődésével vagy pedig olyanok, akik például tudják, hogy mi a DevOps.

Mégis, szajkózod, hogy úgy kéne mindenhol csinálni, ahogy te csinálod.

Így van. Mert látom, hogy működik és látom, hogy mások mivel szopnak és mivel magyarázkodnak, amikor szopnak. És hozod igazolásképp, hogy szopsz a projekteken: Q. E. D.

https://iotguru.cloud

Hova kellene megérkezni? Jössz azzal, hogy mennyire más a valóság és bizonygatod, hogy 20+ éve szar projekteket láttál, közelébe nem jártál olyannak, amiről írtam és próbálsz erényt kovácsolni a pénzszegény projektekből, kihívásnak élve meg... ennek egyszerűen annyi oka van, hogy nem ugyanabban a ligában játszunk.

https://iotguru.cloud

Az a helyzet, hogy a cég - ahol dolgozol - erősen predesztinál bizonyos munkákra, mert az ügyfélkör olyan-amilyen, te pedig alapból úgy működsz az élet minden egyéb területén is, hogy szerinted az van mindenhol is, amit látsz, függetlenül attól, hogy milyen széles a rálátásod az adott területre.

Szóval újra: ha nem látsz jó projektet 20+ éve, akkor nem egy ligában focizunk, pláne, hogy saját bevallásod szerint kihívásnak tartod a szar körülményeket én pedig messze elkerülöm ezeket.

Egyébként eddig például hány Kubernetes cluster-t raktál össze?

https://iotguru.cloud

Az a helyzet, hogy a cég - ahol dolgozol - erősen predesztinál bizonyos munkákra

Az biztos!

mert az ügyfélkör olyan-amilyen

Végül is, Magyarország legnagyobb szervezetei és vállalatai tényleg olyanok, amilyenek. Még több ilyen bölcsességet :D

hogy saját bevallásod szerint kihívásnak tartod a szar körülményeket én pedig messze elkerülöm ezeket.

Ezt te nevezed szar körülménynek.

Egyébként eddig például hány Kubernetes cluster-t raktál össze?

Egyet sem raktam össze, tök más területen dolgozom. Gyakori hiba, hogy akik ilyen területen dolgoznak, azt hiszik, hogy csak az létezik.

trey @ gépház

Végül is, Magyarország legnagyobb szervezetei és vállalatai tényleg olyanok, amilyenek.

Így van, ez az IT világ egy szűk és belterjes szelete. Nem csodálom, hogy nem láttál még jó példát. Azt se csodálom, hogy ebből általánosítasz, mert ez az alapműködésed.

Egyet sem raktam össze, tök más területen dolgozom.

Na, ez is mutatja, hogy más pályán focizunk.

Gyakori hiba, hogy akik ilyen területen dolgoznak, azt hiszik, hogy csak az létezik.

Nem, nem hiszem azt, hogy csak az létezik, ez csak egy kérdés volt, hogy egy DevOps álláshirdetés kapcsán kialakult DevOps jellegű vitába a faszé' szállsz be, ha nulla tapasztalatod van a témakörben...

https://iotguru.cloud

Ó, nem, a vita már rég nem a DevOps-ról szólt, hanem arról, hogy mindenki hülye, aki nem úgy vagy olyanban dolgozik, mint te. Szokás szerint.

Az egész téma DevOps és ezen belül ez a szál a DevOps szemléletről és annak céges kultúrába ágyazottságáról szól, maximum te terelted máshova vagy próbáltad áthúzni. Szokás szerint.

És továbbra is azt mondom, hogy 

1, A cégnél van DevOps szemlélet, el lehet magyarázni a problémát.

2, Hagyni kell őket a faszba, hogy majd Ifj. Vér István megoldja. Ha te vagy Ifj. Vér István, akkor pedig megtalálta a zsák a foltját.

https://iotguru.cloud

Sajnos ez, így, ebben a formában nem igaz. Szerintem többen is láttunk olyat, hogy a "van pénz lóvéra" tökéletesen lefedte, a helyzetet, mégis gányolás lett a vége - mert a "mindenkI"-ből egy Vér Pistike szintű vagy az alatti egyed/beszállító lett kiválasztva, aki nem tudta megcsinálni  rendesen...
A pénz az szükséges, de nem elégséges feltétel. Hogy sok kell belőle, vagy még több, vagy kevesebb is elég - ezt részben a szakmai tudás és tapasztalat (főleg ez utóbbi!) ki tudja váltani.

Sajnos ahogy halad előre az idő, egyre többször látok VP vagy az alatti szintű beszállítókat... És van, ahol lehet tolni azt, amit apám szokott mondani, hogy "nem mindig az olcsó az olcsó", és kellően alátámasztva a technikai megvalósítás illetve a minőség fontosabbá válik az árnál (vagy legalább egy szintre kerül a kettő), és van, ahol ez nem működik...

Ha sz@r a projekt, akkor ott az is lehet, hogy bár a benne dolgozók nem hülyék, de a projekt vezetése, a kommunikáció khm. problémás - ilyenkor aztán jönnek a határidő közelében azok a rögtönzések, amik később vérpistikés gányolásnak fognak kinézni, és jobb esetben ki lesznek javítva, rosszabbesetben szekrényben lévő csontvázként ott maradnak a nagy IT hw/sw infrastruktúrában arra várva, hogy a legrosszabb pillanatban ráboruljanak az egész csapatra...

Ez azert nem egy olyan nagy varazslat :) Kiveszed a gepet az elotte levo loadbalancerbol vagy barmilyen mas metodusbol ami rairanyitja a forgalmat, utana rakuldod a sigtermet az alkalmazasra es mar mehet is a reboot. Amelyik app pedig nem kezeli a sigtermet ott jol picsan kell rugni a fejlesztot.

K8S-nel ez ugye cordon, drain, a tobbit intezi a rendszer magatol (kimegy a sigterm, kiveszi a servicebol, stb.). 

Ha ez amit leirtam nem megoldhato ott nagyon sulyos gondok vannak a cegben.

Az app kezeli, szépen le is áll, csak épp az adott munkamenet "másik végén" ülő dolgozó/ügyfél/fizető néző/akárki fog anyázni, mert amit épp csinált, az kuka, GOTO 10: lehet újra user/pass/2FA bejelentkezni... És előfordulhat, hogy az a node is ki lesz rángatva alóla később, amire visszajelentkezett...

Ez szép, de én, mint az infra üzemeltetője, nem fogom tudni megoldani, hogy valamilyen real-time folyamat kiesés nélkül elviseljen egy rebootot.

Akkor visszatértünk oda, hogy a DevOps szemlélet meg van baszva a szervezet által, ez egy olyan cég, ahol van egy ember, akinek a munkakör az, hogy "devops". Olyan, mintha lenne egy ember, akinek az a munkaköre, hogy "agilis" és ezért a cég agilis, pedig lófaszt.

Hozzátenném, hogy ha az az egy gép a real-time folyamattal együtt hanyatt esik, akkor a van-e akkora kárösszeg, ami elég lenne arra, hogy rendesen meg legyen oldva. Ilyenkor derül ki, hogy csak papíron van milliós kiesés percenként.

https://iotguru.cloud

Én 8 órás meló mellett (alatt) csinálom a melót nekik kontraktorként, de kényelmesen elfér.

Nem mindenkinek az az életcélja, hogy egy laza 8 órás főállás mellett még vállaljon plusz 4-6 óra melót, mert neki épp elfér és/vagy van annyi üresjárata a főállásban, ha meg nincs, akkor megy a zsonglőrködés a feladatokkal és a határidőkkel.

Nem számolgatok szabikat ilyeneket, kellemes kis kiegészítés, jó a csapat, széles a stack.

Én például összesen szeretnék csak annyit dolgozni, amennyit te meló mellett még bevállalsz.

https://iotguru.cloud

Lehet meg fiatal, nincs csalad, stb. Akkor nekem se volt gond napi 10+ orat dolgozni mert a melon kivul csak kocsmazni jartunk a haverokkal, meg porgott a Counter-strike/Eve online.

Igy lassan 20 evvel kesobb mar a napi 8 orat is sokallom, van nekem egyeb dolgom is a munkan kivul :)))

4x, családos, 2 gyerkőc, többet vagyok a két gyerkőcömmel mint egy átlag apa 1 év alatt :) az hogy 8 órás melóm van, nem jelenti, hogy 8 órát kell dolgoznom. Homeoffice, rendelkezésre állás van, ha kell, írnak, hívnak, és kész. De devops/sre-ként elég gáz lenne ha 8 órát nonstop végig kéne tolni, hisz akkor állandóan gond lenne a rendszerrel. Kényelmesen elvagyok napi 4 óra nettó melóval, ami néha 1-2óra, néha 6-8 óra, de sosem 10+ óra. Ennyire hülye nem vagyok :)

Akkor ha az eddigieket jól értem, Nálad ez úgy működik, hogy van egy főállást biztosító munkaadód, aki csak negyed-fél állásban vesz igénybe az egész állásnyi pénzért cserébe, és így anyagilag végül is "besegít" a másik, félállást kínáló munkáltatódnak, ahol vállalkozóként számlázol, jóval kevesebbet a munka és a tudás értékénél, de végülis Neked ez így is talált pénz, mert más által fizetett munkaidőben keresed meg...

Tehát olyan ember kell ebbe a team-be, aki ugyan ilyen jófej munkaadós főállással rendelkezik, ahol nem kell 8 órát dolgozni a 8 órányi pénzért, és a fennmaradó időben be tud ide dolgozni egy kis mellékesért.

Így is lehet értelmezni természetesen, de a magam szempontjából nézve a 8 órás munkaadómnál nincs fejlődési lehetőség, viszont a mellékállásaimban adott a tanulási/fejlődési lehetőség, így nyilván olcsóbban bevállalom őket, hisz pluszpénz is amellett hogy fejlődök.

A teambe olyan embert keresünk aki ár/érték arányban befelér (most már nyitottak vagyunk a 10+ felett is, majd lesz uj kiírás :), és neki is belefér az idejébe a munka. Ha Ő is szerencsés, akkor 8 órás meló közben megoldja ezt, akkor duplán jól jár :) Egyébként devops/sre körben elég elterjedt az "overemployed", több ismerős is dolgozik egy időben több melón, pl ugy hogy senior melot visz főmunkaként, de mellette kisebb junior melókat is.

Nem ördögtől való ez, és igazából a cégeknek is egész jó megoldás, hiszen nem minden KKV-nak fér bele, hogy kifizesse a külföldi remote melóba menekülő IT-sok órabéreit. 

Nem is gondoltam megszólni ezt a rendszert. Csak itt a "vita" végig azon ment, hogy erre a feladatra kevés ez a pénz. De ha az elején valami szép szavakkal (nem ahogy én leírtam) ilyen kontextusba helyezitek, akkor lehet teljesen más célközönséget szólít meg (és teljesen máson veszekednek aztán ezek a másik célközönség... :-).

Ahhoz azért persze kell a szerencse, hogy (elmondásod alapján) két munkáltató összesen átlag fél munkaidőnyit vesznek igénybe az idődből, összesen másfél munkaidőnyi pénzért. Nem sokaknak van azért ez meg szerintem.

A "kevés a pénz" -re rájöttünk már közben, de mivel utoljára kb 6-12 hónapja kerestünk embert, akkor még más szelek jártak, és viszonylag sok ember jelentkezett 9k/óraval is: https://hup.hu/node/179301 . Látható hogy itt kedvezőbb díjon találtunk embert.

Ehhez képest fél év alatt közel a duplájára emelkedtek a bérigények (órabér, akárminek hívjuk), miközben a mi igényeink pár dologgal bővültek "csak". Újragondoljuk, refaktoráljuk a hirdetést, vagy szétszedjük a pozíciót, aztán meglátjuk.

80 óra munkát VAGY rendelkezésre állást vártok el. Ebben az van benne, hogy a 80 órát akkor is számlázza az ipse, ha épp 77,35 órában a haját fonta, mert nem volt feladat, de nektek fontos, hogy valaki értelmes idő alatt elérhetően megoldja a dolgot, ezért kvázi várta a feladatot. Többekkel volt már erről vitám, hogy ha bazihektikusak a feladatok, de nincs lefektetve, hogy kell a valós rendelkezésre állás, akkor az lesz, hogy 1-2 hét múlva majd sorra kerül a dolog. Az nem rendelkezésre állás, hogy ha valaki 10db ilyen havi 80 órás szerződést köt, és bukdácsol mindenhol...

Nu ezt nem teljesen értem ;)

Mi elvárunk valakitól 80 órányi munkát minimum, de ha csak 40-et kap, mert nincs feladat, akkor is megkapja a 80 órányi fizut. A munka beosztásáról ugyan nem esett szó, de nyilván senkinek sem jó, ha 1 hetet kell várni egy devops-ra kiosztott ticketre.

Én úgy dolgozom konkraktorként, hogy mindennap foglalkozok 1-2 órát 1-1 ügyféllel, és így nincs gond, nincs torlódás sem. Nyilván ha van nagyobb feladat, és van időm, akkor akár 8 órát is rászánok egy nap, de ez teljesen változó.

Korábban írtad, hogy elvárjátok a rendelkezésre állást, ha nincs meló. Jellemzően sysadmin vonalon mozgok melókkal, és bizony vannak üresjáratok, viszont rendelkezésre kell állni, hogy amikor 2-3 nap múlva a dolgom jön, akkor puff ott legyek. Ha van biztosan 80 óra munka, ami jól beosztható csinálható, akkor az megint más, de vajon biztosan mindíg lesz?

Nem azzal van a baj, amikor 1-2 órát foglalkozni kell 1-1 ügyféllel, hanem amikor egyszercsak hirtelen előkerülnek, hogy húha holnaptól irány a holdprogram, mert ekkkkora projekt van. Namármost rendkívül elszomorodnak amikor megtudják, hogy 1-2 hétre előre minden idő be van táblázva, és majd akkor. Amit te mondasz, az a folyó ügyek vitele, persze akkor ha van folyamátaban mindíg valami. Nem utolsó sorban helyszini melók is vannak, és ott akár 1, max 2 ügyfélre dedikálódik az a nap, mert így jön ki. Mindenki más következő nap, vagy utána, ahogy kiadja. Na az szokott a probléma lenni, hogy valami onsite dolog van, és hirtelen hívnak, hogy húde meg kéne eztazt csinálni, mert úgy gondolták. Hangsúlyozottan nem hibaelhárításról beszélünk, hanem amúgy előre jól egyeztethető, és egyébként is tervezni való (leállás lesz mégiscsak) melóról.

Azt többeknél látom, hogy nem napos, hanem hetes válaszidők vannak (néha nálam is...), mert vagy túlvállalja magát, vagy hirtelen odaszórják elé a szatyorból ami eszükbe jut.

Több cégnek dolgozok, sehol sem fér bele, hogy 2-3 napot kelljen várni 1-1 kisebb taskra. Itt sem férne bele, így számodra nem megfelelő a pozíció, ennyi az egész :)

Amugy a 'holnaptól irány a holdprogram' szeru projekteket nem hinném hogy havi 80 órát vállaló ember nyakába aggatják. Ha meg igen, hát magukra vessenek azok a cégek :/

A több hetes válaszidő az meg számomra felfoghatatlan, de lehet én szoktam meg másik fajta munka-ritmust (vagy mi a jó kifejezés erre)

Mondom, rendre egy csomóan túlvállalják magukat. Én igyekszem kerülni, de sokszor nem is rajtam múlik. Épp volt egy egyszerű projekt, és csak kevésbé voltam érintett, azért csak néhány másik dolgot hátra kellett sorolni, mert a túloldalról finoman szólva se a kompetencia szele fújt. Azért a folyamatos együttdolgozás titka, hogy kialakul egy ritmus, amiben jól tud haladni az adott projekt. Ez szokott sok helyen hiányozni, és "ébrednek" hirtelen.

Egyébként gondolkodom még hogy írok, de van több olyan dolog amivel nem foglalkoztam még, vagy akkor foglalkoztam, amikor nem volt trendi (pl. ZFS 15 éve). :)

Csak arra meg megy a szomorkodas hogy draga.

Szerintuk legyen inkabb hazon belul self-hosted minden, az osszes CI/CD tool-tol kezdve a confluence+jira-n at a gitlabon keresztul a db-k, az elasticsearch, kutyafasza, es majd ralocsoljuk mindet a devopsra, mert az masik cost bucket, a vas meg mar megvan, es akkor szerintuk "ingyen" van minden.

Persze amikor a devops beadja a felmondasat es kiderul hogy masik meg minimum 50%-al tobb penzert van, de csak ugy hogy a meglevo cuccok felet nem hajlando uzemeltetni hanem kozli hogy vidd a felhobe es hagyjal vele beken akkor meg pislogas van :)

lehet házon kívül is SaaS pl a mysql db HA, aminek kell 32 cpu meg 256 giga ram, csak drágább lesz az AWS RDS mint a devops/sre egész havi fizuja :/ és akkor nem beszéltünk még az infra többi részéről.

De nyilván az SaaS-t is kell valakinek toszogatnia, akinek szintén van egy brutál órabére, szóval nemtom hogy mekkora segítség az SaaS ebben a szituban.

A SaaS, meg a felhő, egy rendkívül jó hatékonyság növelő történet ha jól és ésszel használják. Gyakorlatilag egy szinttel feljebb tudsz melózni, és foglalkozni olyan dolgokkal, amikre nem, vagy kevesebb idő volt eddig, esetleg adott cégnek végső soron kevesebbe kerül, gördülkényebb az élete.

A szervernél azért egy 32 CPU 256GB RAM-os szervernek van áramfogyasztása, vagy hostingdíja, egy valami sysadminja, valami gari  hw-re, valaki foglalkozik vele stb. Ha nem is egy RDS VM rögtön, de lehet, hogy megéri bérelni a gépet. Majd aki benne van a hw, esetleg virtualizációs ügyekben, az karbantartja, és tudtok a fejlesztői résszel foglalkozni.

Egyrészt "drága" (lásd másik topik, az X6 nem drága), másrészt arra sincs ember, hogy egyáltalán áttekintse, mire van szükségük, és hogy megcsinálja a felhőmigrációt, vagy a bármit. Egyébként a felhővel, desktopokkal ugyanúgy foglalkozni kell majd, mindent nem tudsz áttolni máshova (tehát megvenni a megoldását). Azt is elmondanám, hogy hiába mindenható a felhő, azért valami helyi NAS -ra nem árt menteni, rossz esetben is valami USB diszkre. Ha van egy 10-20-30 gépes helyi hálózat, akkor valami mini domain sem biztos, hogy ártalmas.

Szó szerint szinte naponta olyan problémák, igények dőlnek ki mindenféle cégeknél csontvázként a szekrényből, hogy simán 1-2 hét a gatyába rázás. Természetesen ezek nem úgy derülnek ki, hogy valaki rendesen átnézte, és kidobta az audit, hanem "gond van a szerverrel rá kéne néznie már valakinek", persze a szervert senem telepítettük (volt eset, hogy azért, mert másnapra! aszondtuk, hogy azért ne vicceljen), senem adminoltuk. Amikor 1-2 hét múlva eljutunk a ránézésre, akkor meg kiderül, hogy egy igen régen nem frissülő Debian vagy Ubuntu, eleve elég kósza gondolatok alapján szórták rá fel a dolgokat, a fejlesztők pedig hajtogatják, hogy rossz a szerver, mint erőforrásilag. Valóság meg az, hogy a default értékkel futó mysql, az indexelés nélkül adatbázis finoman szólva is szuboptimális, és swappelés van veszettül. A példa kiragadadott, de mindenféle dolgok vannak pepitában, akár webhosting szerveren lévő MX-ről az onmicrosoft-os címre továbbított emaillel, de egy kolléga privát gmailre... Olyan szintű belső adósság halmozódott fel egy csomó helyen, és végső soron lépett az ájtisok jelentős része külföldre, amiért most csodálkoznak, hogy nincs ember, meg drága, hogy hihetetlen.

Na abbahagyom. :)

( _ventura_ v | 2023. 03. 29., sze – 13:56 )

Jó látni, hogy máshol is használnak XCP-ng + Xen Orhcestra-t.

Fedora 41, Thinkpad x280

A ddelnano-s packer + XO megoldásnak van egy egész aktív community-ja Slacken, amit szoktam nézni, mert én is küzdöttem a packer.io+XO párossal. Ősszel próbáltam utoljára, akkor valamiért nem bootolt be az elkészült image, de mikor feldobtam a kérdést slack-en, akkor mindenki jelezte, hogy nála semmi gond. Nem tudom azóta javították-e.

Tőled és a hirdetőtől is kérdezem: Mi az előnye manapság egy Xen alapú megoldásnak a KVM + crosvm irányhoz képest?

Note: A KVM+Qemu-t most felejtsük el, tény hogy sokan használják (mi is futtattuk sok évig), de az egy "mindent is" emulálni képes eszköz, ennek minden következményével, nem egy Virtio köré épített paravirtualizált VM-ekhez optimalizált megoldás, amire a konkrét use case-nél jó eséllyel szükség van.

2006 óta virtualizálok. A Xen mindig is nagyvállalati enterprise benyomását keltette, éljen a Type-1. A KVM meg mint a virtualbox és hasonló type-2 es társai dekstopos vonal. 

Annó azt tanították, hogy a hypervisor lehetőleg csak a virtualizálással foglalkozzon, nah most a hátam is borsózik, mikor jönnek hogy proxmox + ZFS ... 

Alap xen + linux distrol ról Xenserver 5.5 re váltottunk és azóta is maradtunk, csak közbe xcp-ng lett. Ráadásul xen-orchestra val kapott egy nagyon jó management felületet, és szerintem az esetek 98% bőven lefedi a tudása.

Az xcp-ng azért van 1-2 hátránya, de dolgoznak a ledolgozásán ...

Fedora 41, Thinkpad x280

Igazából elvi kérdés. Mint írtam szerintem  hypervisor dolga a VM-ek  és a minimális management kezelése. Értelemszerűen minnél több feladatot aggatunk a nyakába, annál több erőforrást veszünk el aVM-ektől.

Ráadásul a ZFS pont hogy szereti a CPU/RAM ha ki akarjuk aknázni a képességeit, pont azokat amikre a VM-eknek is szüksége van, ahol szintén kell valami FS akár ZFS mondjuk ...

Fedora 41, Thinkpad x280

Xen esetén mi kezeli a storage-et? Hacsak nem valamilyen dedikált doboz, vagy hardware raid lokálisan, akkor már a ZFS nem sokkal több*. A ZFS-nek lehetnek olyan előnyei, ami pont virtualizációnál jöhet jól.

Egy partnernél az lett a Xen-nel a bajunk, hogy az újabb CentOS-ek, illetve AlmaLinux-ok már nem támogatják. Ha pedig már Linux, akkor inkább PVH, mint HVM mód. Szóval eljött a KVM + hardware raid megoldás minden fronton. Ebből van egy Proxmox-os vonal, és egy AlmaLinux-os KVM hostos.

*: Tudom tudom, a ZFS "kissé" erőforrás zabálda lehet, viszont manapság se a RAM, se a CPU nem olyan vészesen drága. Ha full SSD van a ZFS alatt, akkor L2ARC nem biztos, hogy mindenképp kell, hacsak nem valami brutál NVMe-re van mód.

Xen esetén mi kezeli a storage-et?

Az xcp-ng nél alapértelmezettem local LVM, vagy ha ez nem tetszik akkor local ext meg file alapú. Ha külső doboz akkor NFS + iscsi vagy HBA, ezek a supported dolgok. Persze lehet csatolni, cephet, moosefs, gluster akinek van kedve játszadozni. 

 A ZFS-nek lehetnek olyan előnyei, ami pont virtualizációnál jöhet jól.

Mint például ?

hogy az újabb CentOS-ek, illetve AlmaLinux-ok már nem támogatjákhogy az újabb CentOS-ek, illetve AlmaLinux-ok már nem támogatják

Mit jelent a nem támogat ? Mivel a legtöbb distróban a kernel része a Xen driverek, így CentOS5 ami már nem fut alapból :D CentOS 6 tól Rocky /rhel stb legújabbakig nincsen gond. Esetleg a management daermonra gonolsz ? xe-guest-utilites ? Mert ott simán lehet, hogy az installer.sh nem fut le, de rpm -i vagy dpkg -i vel simán felrakható a file és működik is. Nekem speciel fut openwrt alatt is, van freebsd is stb.

 Ha pedig már Linux, akkor inkább PVH, mint HVM mód.

Látom le vagy évekkel maradva, kb 10 :D Ugyanis régóta PVHVM mód ajánlott a linuxoknak és eleve ebben is futnak. HVM már csak akkro van ha olyan dolgot teszel fel amihez nincsen xen driver ... (megjegyzem mikrotikben is van, még guest tools is )

viszont manapság se a RAM, se a CPU nem olyan vészesen drága.

Erőforrás pazarlásnak érzem. Akármilyen olcsó is a cpu/ram, ráadásul mint mondtam hypervisor törődjön a virtualizációval. Fázik a hátam attól, hogy a cpu VPS kiszolgálása helyett mondjuk helyreállítja a helyi FS-t és ahhoz számolja a dolgokat ... Erre a storagek valóak ...

Persze tudom, hogy a olcsóhosting meg 1000Ft os VPS-ekbe nem nagyon fér bele külső storage, meg hasonló dolgok ...

 

Van egy VPS-em olcsó helyen ott pl állandóan ezt kapom:

[50021977.205406] sh (2065399): drop_caches: 3
[50025577.346553] sh (2074346): drop_caches: 3
[50029177.246295] sh (2081616): drop_caches: 3

Lehet a RAM ittis a ZFS-nek kell, ezért nem engedik, hogy az fs-cachet én is a ramban tartsam :D

Fedora 41, Thinkpad x280

Azért az egy kicsit sántít nekem, hogy ne vegyünk fillérekért plusz erőforrást a szerverbe a "pocsékoló" hypervisor és FS alá, hanem vegyünk csilliárdért megbízható storage-et, mert az úgy sokkal inkább nagykönyv szerinti...

Azért az, hogy a ZFS elfogyaszt mondjuk egy magot meg mondjuk 4-8 GB memóriát egy kisebb rendszeren, szerintem nem a világ vége.

Ellenben az LVM meg az extX milyen kis erőforrás igényű... Jaja, de csináljunk már egy snapshot-ot mentéshez gyorsan... :-D

Nagyon jó a Xen, szerintem nagyon jó a Proxmox és a maga drága módján nagyon jó a VMware is. A baj azzal van, amikor valakinek kalapácsa van, és onnantól minden szög, csak egy eszköz jöhet szóba.

, hanem vegyünk csilliárdért megbízható storage-et,

Ki beszélt itt csillió storage-ről? Akár régebbi E5 xeonok + truenas + linux stb ki mit akar. 

Ellenben az LVM meg az extX milyen kis erőforrás igényű.

Hát nem tudom, nekem van orange Pi valami arm board 512 rammal, ext4 van rajta, nem tudom ZFS mennyire komálná ...

Jaja, de csináljunk már egy snapshot-ot mentéshez gyorsan

Mert szerinted csak ZFS-en lehet snapshot  ... 

Fedora 41, Thinkpad x280

Ha cluster kell, akkor én a Hyper-V és dedikált storage-re hajlok. Remekül bevált több helyen, már 2008R2 korában, az sem tegnap volt.

Xen ügyben lehet le vagyok marad, pláne XCP-ng ügyben, mert amikor 10 éve XenServer meg dedikált storage volt, a kutyának nem kellett, nem értették mitől lehet jó. Mondjuk az akkor XenServer 6.1 nem volt egy túlságosan finom cucc, az igaz. Azóta marad a Xensource-ből fordított Xen, és inkább mellékszervereken használjuk.

A Xen-t egészen Centos6-ig szereti, utána jönnek a gondok, de van olyan rendszer, ami konkrétan besértődik, ha Xen-en fut. Teljesen őrültek, nekik marhára közük se kéne hogy legyen hozzá.

A ZFS-nél sokan szeretik a snapshotos mentős opciót például. Nekem a ZFS-ből a FreeBSD 5.x körül elég volt, akkor még nagyon gyerekcipő volt abban az éppen átportolt változat. Gondolom azóta sokat fejlődött minden fronton. A storage miben véd meg téged egy FS helyreállítástól vagy rossz esetben fsck-tól?

Egyébként a drop_cache-t pont azért csinálják, amiért én speciel nem vagyok KVM fan. KVM esetén minden VM egy qemu-kvm process, ennek minden bajával együtt. Eleve van egy KVM-es overhead, és ha szeretnének overbookolni, akkor legalább próbálják szűken tartani.

Ha cluster kell, akkor én a Hyper-V és dedikált storage-re hajlok.

Nálunk meg xenserver xcp-ng, sajna még mindig van olyan VPS ami akkoriban készült és azóta csak költözött  ... Storagerol storage-ra hypervisorrol hypervisorra ...

 Xen-t egészen Centos6-ig szereti, utána jönnek a gondok,

Miféle gondok ? 1x éve alatt ha xen-el voltak gondjaim az csak ubuntut érintette, komolyan mondom. Jelenleg is van minden, CentOS 7, OL8, Rocky 8, 9 , Almalinux, CloudLinux, Opensuse, openwrt, mikrotik CHR-ek, és természetesen windwos-ok, nincsen velük gond, talánmegy minden aminek mennie kell. Kíváncsi lennék, neked miféle tapasztalataid vannak, mely szerint azt mondod, hogy nem szeretik, sőt besértődik ...

A storage miben véd meg téged egy FS helyreállítástól vagy rossz esetben fsck-tól?

Mondjuk ezt így nem értem. A storage nem véd semmitől, a storage-t arra használom, hogy legyen a VPS-nek diskje.

Mitől kell megvédeni ? Ha gond van és olyan, akkor backupból (teljes vm backup) megy vissza, és jónapot.

Fedora 41, Thinkpad x280

Te írtad a ZFS-nél, hogy "fázik a hátad, hogy helyreállítja az FS-t", ehhez képest most már puff mentésből rakod vissza. Ha mentésből rakod vissza akkor minek az erőforrásait használod...

Nem a Xen-nel vannak a gondok, hanem a VM-ben futó OS, illetve esetünkben az azon használt adott app nem komálja, vagy unsupported, és hisztizik.

 ehhez képest most már puff mentésből rakod vissza.

Én arra értettem ha a storage-ból kiesik egy disk, aztán kicseréled a resilvering, rebuild, ki minek hívja ne hypervisortol vigye a CPU-t. Nemhiába a nagyok alapból sose foglalkoztak sw raiddel. XCP-ng telepítőjéba már berakták a raid1 lehetőséget. Szóval a storage problémákkal foglalkozzon a storage layer ...

Nem a Xen-nel vannak a gondok, hanem a VM-ben futó OS,

Igen én is így értettem, ezért lennék kíváncsi, hogy milyen OS-ekkel van/volt gond meg miféle. Főleg milyen app nem szerette ha az OS hypervisora xen ?

Fedora 41, Thinkpad x280

Ez teljesen változó. Mivel 1 hypervisoron sok VM futhat, változatos vCPU -val pl 2 től akár 16 ig. Attól hogy a hypervisor, mondjuk csak 50% on pörög, nem jelenti azt, hogy a következő pillanatban valamelyik nagyobb VPS-nek nem kell a többi.

Ezért is tartom fontosnak, hogy amennyire csak lehet a hypervisor VPS-ekkel foglalkozzon.

Fedora 41, Thinkpad x280

Tény, hogy elég rég nem néztem mi újság a Xen felé, anno volt olyan projektünk, ahol az ügyfél XenServer 5.5-öt használt, de a projekt után nem éreztem úgy, hogy ez kell nekünk is, maradt a KVM a saját rendszereken, ezért is kérdeztem.

Egyébként a "state of the art" KVM-ből valahol itt kezdődne ma (tl;dr: pKVM = a host nem lát bele a guest memóriájába) : https://source.android.com/docs/core/virtualization/architecture

Persze ez még csak Androidon van meg, egy alap Ubuntu-ba talán a 24.04-re beér majd...

 

xen+debiannal kezdtem, aztán xenserver, majd xcp-ng+xo. Kb 10 éve nincs vele gond productionben, és amikor kerestem alternítvát, egyik sem tetszett amiket találtam. Mostanság, hogy a terraform+xcp-ng+xo trió csinál 'érdekességeket', emiatt nyitottabb vagyok az alternatív, meg is nézem amiket ajánlottál. Só

Ha már így nézelődsz, akkor még ezt is bedobnám ide: https://katacontainers.io/

Ha saját bare-metal infrát futtattok, akkor akár a Kubernetes is mehetne bare-metalon, a konténerek meg MicroVM-ben Kataval (persze nem Qemuval, hanem pl. Cloud Hypervisorral: https://www.cloudhypervisor.org/).

PS: 1x év után én nemrég nyugdíjaztam az OpenVPN-t, és WireGuardra váltottunk. Ég és föld a WireGuard javára.

igazából sok dolog fut vm-en még (db pl), így kiesett a bare metal-on közvetlenül futó k8s megoldás, de köszi a tippet.

ps: az openvpn-t tippet kösz, azt majd a devops-os ember megoldja, én a k8s ember vagyok "csak". 

ps2: openvpn helyett tailscale-t használok más cégeknél, egészen bevált, k8s clusteren belülre is belát elég egyszerűen

( uid_10547 | 2023. 03. 29., sze – 13:57 )

Kérdezni itt is lehet, szívesen válaszolunk ;)

( Áki38 | 2023. 03. 30., cs – 16:36 )

Kedves Emberek! Én írtam össze a hirdetést, ezért érdeklődéssel olvastam a kommentjeiteket. Az, hogy a DevOps szakértelem, az élelmiszerhez hasonlóan drágult az elmúlt 6-12 hónapban már láttom. Ez ügyben köszi, vettük az adást. Próbálunk ár-érték arányt tekintve olyan dealt kötni majd, ahol semelyik fél nem érzi kihasználva magát. Akit komolyan érdekel az ajánlat, nosza írjon nekem, mi is komolyan fogjuk venni az ő igényeit.  Az időkeretet tekintve is voltak félreértések. Nem teljes állásra keresünk fél fizetésnyi embert, hanem azért és annyit fizetünk ahogy és amennyit dolgozol. Nincs törzsidő, nincs szabadságkeret, és még biztos sokminden nincs.. van viszont szabadság, együttműködés, fasza közös célok. Továbbá van törekvés az Remote-Aszinkron működés kifaszazására is, és ehhez adott a bizalom is alapból, amit le és fel is lehet építeni a közös munkával. Akiknek ezek a keretek megfelelnek azok érdeklődését szeretettel várjuk! Az egyéb kérdések megvitatásához a kommentekben, pedig jó szórakozást kívánok! - Ákos

Hogy ne vegyem el senkinek a kedvét attól, hogy itt hirdessen, leírom, hogy én hogyan látom ezt a kérdés.

Alapvetően két féle típus jelez vissza a hirdetésekkel kapcsolatban:

- Akit érdekel  a pozíció, az általában jelentkezni szokott.
- Aki messziről kibickedve próbálja megmondani, hogy hogyan kellene nektek hirdetni/IT-t üzemeltetni/üzleti döntéseket hozni.

Gondolom rájöttetek, hogy melyik kategóriával érdemes foglalkozni. :)

Persze, ha nincs egy darab épkézláb jelentkező sem, akkor érdemes átgondolni, hogy minden passzol-e a kiírásban.

Kívánom, hogy találjátok meg a megfelelő embert. Sokan elfelejtik, hogy egy munka nem csak pénzt tud adni. Kezdőként ingyen dolgoztam a tapasztalatért, és vállalkozóként most is van, hogy bizonyos munkákból a tudás az, amit ki tudok venni.

Ősszel jelentkeztem egy céghez "kezdő" kubernetes üzemeltetőnek, ahol a HR-es megkérdezte, hogy milyen összegben gondolkodom. Aztán csodálkozott, hogy a tudást is a "juttatások" közé soroltam, mert sajnos nem ez jellemző a szakmára. Mindenhol azt lehet hallani, hogy milyen jól keresnek az IT-ben dolgozók és örülök, akinek ez sikerült. Mi (a maradék) pedig örülünk, ha életben tudjuk tartani a vállalkozást.