Linuxos munkát keresek

Állást keres

24 év linuxos tapasztalattal munkát keresek.

A nem túl fiatalok talán még emlékeznek rám, 99-ben írtam egy Linuxos oktatóanyag című szösszenetet, 2009-ben pedig egy könyvet, https://hup.hu/node/41056 ez volt az egyik thread vele kapcsolatban. https://www.linkedin.com/in/kosaattilalinux a LinkedIn profilom elérhetősége.

Nem fővárosi vagyok, úgyhogy a "minden nap járjon be az irodába" nem annyira működőképes.

Köszönöm, hogy elolvastad.

  • 3612 megtekintés

( KicsiBocs | 2024. 03. 31., v – 16:03 )

Szerkesztve: 2024. 03. 31., v – 16:04

Nagyon sok sikert kívánok Neked a mostani leépítéses időszakban!!! Sokat tanultam- és használtam a jegyzetedből/jegyzetedet!!!

( n.balazs v | 2024. 03. 31., v – 16:22 )

Huuh, nem lesz egyszerű út. De nem is lehetetlen. A jó szakembereket szó szerint lasszóval keresik. Nekem is volt most egy váltásom és 1 héten belül már az új helyen voltam.

Kérdéseim - ez talán neked is segítség lehet, nem feltétlenül kell mindet megválaszolnod nyilvánosan:
- Mennyi HO-t szeretnél? Heti hány napot?
- Készenlét / ügyelet vonz-e téged?
- Idegennyelvekkel (különösen angollal) hogy állsz?
- Van-e preferált lokációd Bp-n belül, ha be kell menni az irodába? Pl: ha Szentendrén laksz, akkor neked a Bp. 11. kerület az nagyon távoli
- Van-e valami elvárásod az új munkahely felé (szervezeti / humán / szakmai oldalról)? Pl: Milyen technológiák érdekelnek? Mivel szeretnél foglalkozni?
- Tipikus HR-s kérdés: Mi az, amihez a Linuxon belül értesz? Össze tudod-e pár mondatban foglalni?
- Mikor tudnál kezdeni?

A távmunka lenne ideális számomra :) Miskolc mellett lakom, sokat kell utazni a fővárosba... Nem zavar a készenlét, szinte mindig jelen volt eddig az életemben. Angolul olvasok, ha kell, akkor írok is, a beszéd nem igazán megy :( Nincs elvárásom szervezeti oldalról, normális emberekkel szeretek együtt dolgozni, akik értenek is ahhoz, amit csinálnak :) Röviden nehéz lenne leírni, hogy mivel foglalkoztam már eddig Linux alatt. A teljesség igénye nélkül: tűzfal (például HA zorp), squid, samba, ldap, bind, dhcp, ntp, vpn, pki, git, ansible, azure, glassfish, tomcat, apache, postgresql, postfix, dovecot, drbd, glusterfs, heartbeat. Sose voltam az, aki azért lecserél egy disztribúciót, mert egy másikkal könnyebb valamit megcsinálni. Mindent meg tudtam oldani Debian alatt, amire szükség volt. Igaz, az utóbbi években inkább Ubuntut adminisztráltam, de az céges adottság volt.

Holnaptól tudok kezdeni :)

Ezek alapján én azt gondolom, hogy te egy klasszikus Linuxos vagy (jó értelemben). Még érted a miérteket, a hogyanokat, nem pedig az "ááá, nem megy, töltsünk le másik Docker konténert" típus vagy.
Ilyen skillsettel kapásból tudnék mondani 2 céget is. Csak egyik se túl távmunka párti. De majd utánuk kérdezek, hátha mégis.

Devops toolokkal volt már dolgod? Csak pár: Prometheus, Grafana, Wazuh, Jira, Gitlab, Github.
Van ismereted Docker, Kubernetes terén?

Ami pozíciókról én tudok, ott angol beszéd nem kell, de doksi írás/olvasás igen.

Normális kollégák: Sajnos ez nagyon relatív. Mindenki más, mindenkinek más a mérce. No meg csak idővel derül ki az emberek negatív oldala.

Köszi, hogy rákérdezel. És a többieknek is köszi, akik magánban küldtek dolgokat!

Jirát használtam vagy 7 évig, a többit láttam már (a wazuh-t még nem is láttam :) )

Van, amit docker-ben futtatok itthon, de munkatapasztalatom nincs benne. Kubernetes-ben futó alkalmazásokkal volt már kapcsolatom, de nem túl mély a tudásom. Viszont képes vagyok tanulni :)

Akik a kollégáim voltak az utóbbi két helyen, azokkal a mai napig tartjuk a kapcsolatot, évente legalább egyszer csinálunk egy találkozót is, hogy ne csak online beszélgessünk :)

Ezek szerint akkor a hálózatok sem állnak olyan távol tőled.  :) (ezt csak azért tartom fontosnak megjegyezni, mert manapság elég sok olyan "fejlesztő" vagy "informatikusnak" nevezett akárki fut be, hogy fingja nincs a címosztályokról, maszkolásról, alhálózatokról, protokollokról, pedig ez még az egésznek a legalja. Nem beszéltünk routingról, (r)stp-ről, vlanokról, qos-ről, biztonságról stb.. ha az alap megvan, a többit egy kis olvasás után már nem nehéz)

- Indítsd újra a gépet! - Az egészet? - Nem, a felét...

( denton | 2024. 03. 31., v – 19:08 )

Biztos kapni fogok hideget, de nekem az a véleményem egy ideje, hogy a klasszikus rendszergazdák ki fognak halni szép lassan. A munkakörök is.

Sokan élnek már felhőben managed servicek között. Ott fent nem nagyon kell már pl postfix-et üzemeltetni, mert használsz egy smtp szolgáltatást helyette. Nem kell már dns service-t telepítgetni mert van felület. Nem kell samba és nfs mert csak felmountolsz egy felületen egy share-t és kész. (mondjuk pont DO alatt nfs-t kellett csinálnom mert se arra se smb-re nincs managed és kellett kuberneteshez, de ez mellékes, azt is többnyire marketplace-sel raktam össze, nem álltam neki nulláról)

VM-eket is sokan kerülik a klasszikus értelemben és helyette docker/kubernetes megy, esetleg app/function service-k.

Rendszergazda még az olyan helyekre kell szerintem, ahol valamiért küzdenek a felhős szolgáltatások ellen, esetleg felhős cégekhez ahol valakinek nyilván üzemeltetni kell azért, hogy nekem a túloldalon egyszerűbb legyen.

Még előfordulnak sima rendszergazdai melók, de érdemes DevOps irányba is fejlődni, váltani.

Ezt más kárán is tapasztaltam már. Volt tipikus SysAdmin kollégám aki alól pár év alatt kicsúszott a talaj amikor Azure-ba költözött a cég. Végül lelépett, nem tudom megtalálta e tutira a jó helyét, nem vagyok benne biztos.

7 évig üzemeltettem rendszereket a felhőben, kellett postfix is, dns is :) Az azure smb-je olyan gyatra teljesítményű volt 2017-ben, hogy saját glusterfs klasztert kellett helyette csinálni (nem akartunk nfs-t). Mindazonáltal kénytelen vagyok egyetérteni veled, azt látom, hogy egyre kevesebb igény van a klasszikus üzemeltetésre. A devops-ról meg az a véleményem, hogy sok cégnél igazából azt se tudják, hogy mit is takar ez a kifejezés, és sok informatikusnál is nagy a zavar ezzel kapcsolatban...

Én kevesebb mint 1 éve léptem le az előző helyről ahol Azure-ba költöztünk onprem-ről. Brutális mennyiségű adatokat mozgattunk és brutális mennyiségű valódi vasat felhősítettünk sima VM-re, kubernetesre, managed servicek-re. 

A storage accountokkal eléggé jó tapasztalataink voltak. Valszeg 2017 óta sokat fejlődött.

Kubernetes megoldásokhoz ha shared kellett, akkor tökéletes volt a storrage acc smb megosztással. Ha nagyobb sebesség kellett és nem volt szükség shared megoldásokra több pod között, akkor meg mehettek a managed disk-ek. Az jobb performanciát adott.

Természetesen sok a vita abban, hogy mi a DevOps. Az én fejemben fejlesztő és rendszergazda keverék.

Nem teljesen értek veled egyet.

Véleményem szerint igen, változik, hogy melyik szakemberből mennyire lesz szükség. Igen, a klasszikus rendszergazdából kevesebbre.
Viszont amíg van onprem, amíg van irodai munkavégzés, addig kell. Pl: onprem MFP nyomtatók nem felhősíthetőek csak úgy - joggal.

De ha már van iroda, akkor kell:
- Vezetékes hálózat - switchek, routerek
- Vezetéknélküli hálózat - ap-k, controller
- Valahogy a hálózati securityt is biztosítani kell - pl: port security, 802.1x
- Gépeket valakinek kiadnia / visszavennie / leltároznia is kell
- Ha bárkinek onsite problémája van, akkor segíteni kell
- Ha megáll a net, akkor fenn kell tudni az üzletmenetet BCP szinten definiálva, amihez szintén kellhet rendszergazda (ISP nyaggatása, átállás tartalék netre stb.)

Amíg van onprem, erre én is utaltam, hogy több esetben is van és persze lesz is még. Viszont egyre kevesebb, ergó ha marad minden rendszergazda ebben a helyzetben, akkor sokkal több ember lesz mint szabad pozició.

Az irodai rendszergazdaság szerintem totál más világ mint a szervereké. Azt kifejezetten nem keverném ide.

Szerinted a "felhőben" minden justworks? Mert azért látom, hogy agilis devopsék mitössze csapatnak, és nem kicsit utánuk "szerelgetni", hogy finoman fogalmazzak... Attól, hogy szép a felület, még nem árt, ha tudják mire klikkelnek.

Hiába van felület, valaki kelleni fog, aki tudja, hogy mit és miért csinálnak, szóval attól hogy sysadmin, még nem feltétlenül kell fekete képernyők előtt hümmögnie.

Nono, senki se mondta, hogy minden megy magától. A felhős megoldásokhoz is érteni kell, de ott nem kell összelapátolnod nulláról. A ti DevOps kollégáitokkal van gond ebben az esetben.

Tudni kell, hogy mit miért csinálsz és mit akarsz, de azt nem kell részletesen tudni, hogy miként van összerakva a backenden. Kit érdekel, hogy 2 virtuális hálózat a háttérben milyen kábeleken tud, miként van megoldva, hogy össze lehessen kapcsolni őket, milyen operációs rendszerű gépen fut egy dns szerver és milyen csomagokat telepítettek fel hozzá? A lényeg, hogy managed esetében ezzel nem neked kell törődni, tudsz fontosabb feladatokkal foglalkozni.

Tudni kell, hogy mit miért csinálsz és mit akarsz, de azt nem kell részletesen tudni, hogy miként van összerakva a backenden.

No offense, de általában ebből szoktak születni az oltárian rossz megoldások.
A kábeleket nem kell tudni, de a rendelkezésre álló sávszélességet, késleltetést illik tudni. Rá lehet cseszni emiatt.
Nem mindegy, hogy IAS, PAS, SAS szolgáltatást vásárolsz. SAS esetben még igazad is lehet 90%-ban.

Hát, az onprem-re visszaköltözéskor (ami a jelek szerint minden cégnél megérik idővel) a rendszergazdából lett tenant admin majd előveszi a régi tudását, és összeköti a gépeket kábelekkel, ismeri a DNS szerver oprendszerét és tudja hogyan jut el az adat egyik gépről a másikra.

Aki meg csak a felhőben szocializálódott, az várja, hogy a Greenfox-hoz hasonló akkori cég átképezze tenant adminból géptermi operátornak, állás garanciával...

Azt mindenkinek meg kellene értenie, ami az élet minden területére igaz, de különösen a műszaki vonalakra, hogy ha nem ismered az alapokat, csak a felette (sokkal felette) lévő rétegeket, akkor abból előbb-utóbb gond lesz...

-1

Majdnem ugyanannyi ora a cloud admin gombjait nyomkodni / parancsait bepotyogni, mint fizikai diskeket cserelgetni.

Aztan ott van egy rakas nemfejleszto: nekik is adni kell laptopot, sot, manage-elni, ha elhagytak a jobb esetben titkositott adattal egyutt, betartatni szabalyokat, stb.

A leheto legnagyobb mertekben nem ertek egyet ezzel a hozzaszolassal. A felho elterjedese sokmindenben segitett, de devops es it support szukseges munkaorainak csokkenteseben biztosan nem segitett kb. semmit, foleg, ahogy a security szakma goditi az ujabb es ujabb akadalyokat.

Majd az idő megmondja kit igazol.

Disket kézzel cserélgetni ugyanannyi munka? Nem szoktam lolozni, de ez megalool tényleg! :D

Végül is, ülök az otthonomban a kis dolgozómban, a lábamat épp géppel maszíroztatom, közben ha kell pár kattintással vagy api hívással rendezem a diskeket. Ha meghibásodik, azt észre se veszem mert redundánsak a jobb helyeken, Azure alatt az ocso disk is legalaláb LRS.

A másik oldalon meg majd mászkálhatsz ki az adatközpontba, ha vidéki vagy (kérdező pl), akkor már kiestél a képből és ott pedig pakolgatod a hardvereket, cimkézed, beszerzed, stb. Nagyon gyengén fogalmazva. <szarkazmus>Tényleg sokkal hatékonyabb..</szarkazmus>.

Fentebb írtam, hogy az irodai dolgok totál más kategóriába esnek. Nem akarom lenézni azt a munkakört se, de igazából diákmunkásként csináltam utoljára hasonlót, totál nem hasonlítgató össze egy szerveres rendszergazdai melóval.

(tudom, vannak szerverek irodában is, nálunk is volt skype meg minden cucc, végül abból is teams lett és ment minden onnan is a felhőbe ami csak tudott.)

De továbbra is mondom hangosan, van és lesz onprem meló, csak SZERINTEM nem lesz olyan jól megfizetve és nem lesz belőle sok pozició. De ne legyen igazam én nem akarok bántani egy klasszikus rendszergazdát se, senki elől nem óhajtom elvenni a munkáját, csak a véleményemet mondom.

Egy kicsit elkanyarodtal remote vs bejaras iranyba. Ott mar vannak reszek, amikben igazad van.

De abban tovabbra sincs, hogy "eleg kevesebb it support" es "eleg kevesebb devops". Esetleg "eleg kevesebb bejaros devops". Amivel gyorsabb bekattintani a felhon plusz 2 redundans disket, annyival lassab kimutatni, hogy nem lehet olcsobban megcsinalni, megcsinalni olcsobban ha megis (akar masik cloudra koltozve), encryption keyeket es (szabalyok miatt egyre komplexebb) permissionoket rendezgetni, approval based rendszereket kezelni, security reportokra reagalni, amibol regen sokkal kevesebb fajta(!) volt, stb.

Szerintem nem írtam olyat, hogy elég kevesebb ember. Azt írtam emlékeim szerint, hogy bizonyos dolgokkal nem kell foglalkozni és tudsz másra időt tölteni. Nem kell pl smtp szervert karbantartanom, ez nem nyereség?

Aremote vs bejárás nem elkanyarodás, hanem egyrészt idő ami == pénz. Ha nem kell kijárogatni szerverterembe, azzal a cég időt és pénzt takarít meg. Ha nincs helyhez kötve az ember, akkor tud alkalmazni olyat aki pl Miskolcon lakik, jobban kinyílik a világ. Több ember közül tud válogatni, ha több ember közül tud válogatni, találhat akár jobbakat is, ha nem csak helyben kell keresni.

A legtobb cegnek nincs sajat adatkozpontja, hanem valahova be van rakva a szerver, ami mar az advanced level, mert sokaknak a vas sem sajat, hanem ugy berlik. A diszkcsere igy a legtobb cegnel annyi, hogy beirod a ticketbe, melyik gepben melyik diszket kell cserelni. Ezt nyugodtan megcsinalhatja OP akar Miskolc mellol is. :)

El fog jönni az az idő, amikor a cégek (a nagyok is) rájönnek, hogy egyébként bazi drága a más gépét* bérelni arra, amire régen a sajátjukat használták.

Vannak feladatok, amiket felhős szolgáltatással lehet a legjobban (vagy egyáltalán) megoldani. De nagyságrendileg annyi ilyen van arányaiban, mint amihez mindenképp C kell, mert olyan alacsony szintű/teljesítmény igényű a feladat. Minden máshoz nem kell felhő, csak használható az is. Annyi a felhő előnye ma, mint anno a Windows Server előnye volt a *NIX-hez képest (amiért olyan gyorsan elterjedt): az üzemeltető lehet képzetlenebb, mert az alapokat össze tudja kattintgatni a GUI-n, a többiről meg jótékonyan megfeledkezünk, elvégre onprem sem volt olyan. Nagyon sokára derül ki, hogy aki csinálja, valójában nem ért hozzá eléggé, mert a rendszerbe épített automatizmusok egy ideig elfedik a hozzá nem értést.

Szóval a legtöbb feladat nem olyan, ami felhővel jobban/olcsóbban oldható meg. Csak most épp még felfutóban van a felhő hype (ez látszik a felhős szolgáltatók pénzügyi számain), és mindenki oda megy, mert van olyan, aki tud olyan diagramot rajzolni, amiben a felhő nem drágább, mint az onprem (a'la KSH átlagkereset...).

Persze sorolhatod, hogy mennyibe kerül a szerver, meg az áram, a hűtés, a hely hozzá, a szaki aki összerakja, a szaki aki üzemelteti, stb. Csak akik ezt sorolják folyton a felhő mellett, azok elfelejtik, hogy ez a felhős cégeknek is ugyan úgy és nagyjából ugyan annyi pénz, és még tesznek a végére (egy szemmel jól látható) hasznot, merthogy nem a világ megsegítése a céljuk, hanem a pénzkeresés... Ergo aki a felhőt bérli, hosszú távon elég valószínűen (sokk) többet fog költeni...

Egy ideig az volt a felhőbe a hívószó, hogy nincs elég onprem szakember, gyere a felhőbe, mi azt a részt megoldjuk. Mikor jutottunk el oldáig, hogy már az a "nincs elég" is túl sok onprem?

Nagyon szép dolog webes GUI-n kattintgatni mindent, de a feladatok csak egy részét lehet így megoldani, nem tud minden IT feladat a felhőbe kerülni. Ráadásul ennek is vége lesz egyszer, mint mindennek, és akkor lehet megint megtanulni a felhő miatt elfelejtett (vagy fiatalabbaknál: amiatt sose tudott) dolgokat.

Ahogy elmegy minden a felhőbe, és jön egy kis recesszió, és leépítik az IT-t, akkor észreveszik majd, hogy mit sem ért a kirúgás, mert a felhő viszi a sok pénzt, nem az onprem szakember. Akkor majd szépen kezdenek visszaköltözni, és csak azt hagyni a felhőben, ami oda való.

Kíváncsi leszek, hogy majd 10 év múlva, mikor szépen megszűnik a "rendszergazda", mert nem kell a felhő miatt, lesz-e olyan GUI gomb, hogy "helyi hálózat tervezés/építés", "helyi nyomtató/telefon/desktop tervezés, beüzemelés, üzemeltetés", "felhő szerver tervezés, beüzemelés, üzemeltetés". Nem kell hozzá Nostradamus-nak lenni: nem lesznek ilyen gombok. Ezekre a feladatokra ugyan úgy "rendszergazdák" kellenek majd, mint most, csak lehet más cég alkalmazásában.

Ráadásul ugyan ezen rendszergazdák kellenek majd oda is, ahol rájönnek, a felhő viszi a pénzt, racionalizálni kell oprem-mel...

30 évnyi tapasztalatom az, hogy IT-ban az tud sokáig sikeres maradni, aki ismeri az alapokat, és arra rátanulva megismerte a felette lévő dolgokat. C programozóból lehet Java vagy JS programozó ha az élet úgy hozza, de 100%, hogy eredendően JS programozóból sose lesz C programozó, mert nem fogja érteni, a nyelv meg nem csinál meg helyette semmit. Ez az analógia igaz arra is, aki a felhős webadmin felületekbe szokik bele, és azt hiszi, hogy annak az alapos ismerete a minden.

Egyébként megfigyeltem, hogy akik elkezdenek 100%-ban csak felhős dolgokkal foglalkozni, azok sokszor úgy gondolják, a szakma egy magasabb szintjén vannak már, a többiek meg lemaradtak, és elsorvadó ágazatban ragadtak. De ez hibás gondolat, elég sok okból. Egyszerűen csak a szakma más területén dolgoznak.

 

*felhő

Akkor el tud menni kérdező , ha akar on-prem kubernetes irányába, oda kell  a linux ismeret, szerezhet néhány google plecsnit is időnként ingyen:

https://www.cloudskillsboost.google/public_profiles/39ae0e65-9d00-4e30-a3d9-c8c9ae1ce444
 

Nagyon szép dolog webes GUI-n kattintgatni mindent, 

Nem kattingat. fájlokat irogat. 

https://blog.claryel.hu

El fog jönni az az idő, amikor a cégek (a nagyok is) rájönnek, hogy egyébként bazi drága a más gépét* bérelni arra, amire régen a sajátjukat használták. Vannak feladatok, amiket felhős szolgáltatással lehet a legjobban (vagy egyáltalán) megoldani.

Vagy ha nem is specifikus workloadokat futtatsz, de legalabb ki tudsz hasznalni valamit a felho sajatossagai kozul. Amikor az volt a cloud strategia, hogy a meglevo VM-eket felmasoljuk egy public cloudba, az sosem volt penzugyileg jo dontes. Ha viszont olyan a biznisz, hogy h-p 9-6 van nagy terheles, mindenkor maskor meg le tudod skalazni 20%-ra az infrat, az eleg jo.

Csak akik ezt sorolják folyton a felhő mellett, azok elfelejtik, hogy ez a felhős cégeknek is ugyan úgy és nagyjából ugyan annyi pénz

Nem, messze nem ugyanannyi. Az uzemeltetesben rengeteg fix koltseg van. Ha ugyeletet akarsz 24/7 fedesben, az minimum 3 ember, de ez akkor is ennyi, ha 1 db szervered van, meg akkor is, ha tobb rack-szekreny.

Ahogy elmegy minden a felhőbe, és jön egy kis recesszió, és leépítik az IT-t, akkor észreveszik majd, hogy mit sem ért a kirúgás, mert a felhő viszi a sok pénzt, nem az onprem szakember. Akkor majd szépen kezdenek visszaköltözni, és csak azt hagyni a felhőben, ami oda való.

+1, lazan kapcsolodik

"Ha ugyeletet akarsz 24/7 fedesben, az minimum 3 ember, de ez akkor is ennyi, ha 1 db szervered van, meg akkor is, ha tobb rack-szekreny." - Az évi 8760 órát, ha normál munkarend+készenlét (nem ügyelet(!)) módon akarod lefedni, akkor az legaább négy, de inkább öt ember. Egy év 1095 nyolc órás műszak, ebből 260 óra rendes munkaidő, 835-öt kell szétosztani úgy, hogy egy főre legfeljebb havi 168 óra essen - miközben egy dolgozót legfeljebb 11 hónappal lehet számolni (~20 nap rendes szabadság kiveszi egy hónapra a dolgozót a készenlétből), azaz a 835 műszakot 11-gyel kell osztani, ergo ~76 műszakot kell megoldani készenléttel, ami havi ~608 óra. Itt jön be a készenlét 168 órás maximuma: 608/168=3.62 -> minimum négy emberre van szükséged úgy, hogy pótszabadaságot, betegséget nem számoltunk, _és_ mindenki átlagosan 152 óra készenlétet ad havonta.

Lehet spórolni azzal, hogy a normál munkarend nem 5*8-at, hanem mondjuk 5*10-et fed le (ez egyébként szokásos is, hiszen a készenlétes utazási ideje alatt is kell hadrafogható kolléga, azaz mondjuk 7-kor leadja a készenlétet, mert beért a "reggeles", bemegy nyolcra, négykor hazaindul, és a "délutános" kolléga (aki 9-re ment) ötig bent van, és ekkortól van készenlét) - de ennél meg a teljes 7*24 valós lefedése (mindig legyen valaki gép előtt) nem biztosítható három fővel, hiszen ha valaki szabadságon van, akkor egy fő készenlét, a másik meg viszi a napi 10 órát...)

A több rackszekrény akkor számít, ha a rendszer kellően összetett. Mert ott, ahol "csak" vas+hálózat+Windows szerver+mssql+exchange van, már ott sem biztos, hogy egy szaki mindenhez _is_ ért olyan szinten, hogy a működés fenntartásához szükséges beavatkozást meg tudja tenni. Ha ennél több/szerteágazóbb komponens van, akkor esélytelen egy fővel megfelelő szintű készenlétet adni.
 

nem sikerult megerteni amit mondani akart. ha van nehany racked, ahhoz kell X ember. ha ketszerannyi racked van, akkor ahhoz nemkell 2*X ember (pl lehet eleg mar 1.3*X), ha 10szer annyi rack akkor ahhoz szinten nemkell 10*X ember, hanem lehet elviszi 3*X, es maris egy csomo embert sporolt a nagy ceg.

A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

Az onprem üzemeltetés magas önköltségében egyetértünk, itt valóban a méretgazdaságosság előnye megmutatkozik.

Viszont a felhőnél a 24/365 üzem a természetéből adódik, amire viszont nagyon sok oda költöző cégnek (pláne a kisebbeknek) semmi szüksége, így kapnak egy olyan (viszonylag drága) bónusz szolgáltatást (magas rendelkezésre állás), ami nekik nem kell, de a felhő működéséből adódóan ezt nem lehet nem kérni és megspórolni. Aki egy sima 9-17 cég, annál az onprem üzemeltetés eléggé könnyen megoldható nagyon sok ember (akár outsource) nélkül szerintem. De persze ez megint egy felmérés eredménye kell legyen a felhőre váltás/onnan visszaköltözés tervezésekor.

Hát az, hogy megáll hétvégére a levelezés, meg az, hogy szombat este lehet 2 óra leállás karbantartás miatt, és nem kell HA cluster a folyamatos üzemre nem ugyan az.

Ráadásul pont a levelezés ami elég jól bírja a rövidebb megállásokat, ráadásul egy H-P dolgozó cégnél valószínű nem számít, hogy szombat délután vagy vasárnap este jön meg egy levél.

Folyamatosan úgy beszélünk itt az egész felhő kérdésről, mintha mindenki non-stop termelő és dolgozó, világméretű, minden időzónában jelen lévő multinak dolgozna, és az ő igényeik alapján kell választani. Vagy a emag webshop-ját üzemeltetné, vagy hasonló.
Közben meg legtöbbünk (szerintem) ennél jóval kisebb méretű és igényű cégnek dolgozik, ráadásul a legtöbben nem is tudjuk olyan mértékben befolyásolni az ilyen technológiai döntéséket, mint amennyire ildomos lenne.

Ebben a pár mondatban azért pár különböző dolog keveredik / van összemosva.
Egyrészt a 24/365 üzem és a high-availability nagyon különböző dolgok.

Másrészt: a "saját on prem" infrastruktúra és a (mondjuk "AWS cloud" között azért van még lehetőség, például a Hetzner hosted server.
Nekem van ott gépem havi 45 EUR, gép, villany, net, minden együtt.

Nyilván nem egy erőgép de simán összehasonlítható egy kkv onprem szerverével, aminek ennyiből a villanyszámlája nem jön ki, nem beszélve a 10 gigabites netkapcsolatról, napon belüli hw cseréről, stb.

Ez az opció valahogy mindig elfelejtődik pedig elég kézenfekvő megoldás egy csomó dologra.
 

Gábriel Ákos

Igen, itt a két végletről beszéltem, mert ezek vannak folyamatosan szembe állítva. Még több lenne a rizsa, ha a köztes eseteket is belevenném, nem tudok tömören fogalmazni így sem.

Én magam is arra viszen az ügyfeleinket, hogy van, ami onprem jó, van ami IaaS és van ami SaaS, stb. Ráadásul üzemeltetési szempontból pl. a levelezés SaaS a legjobb, akár nekem kell csinálni, akár az MS-be, G-be van kiszervezve.

Ismerek olyan céget (nem kicsi) ahol egy időben azt gondolták mekkora jó ötlet az AWS-es dev környezeteket péntek 6-kor lelőni és hétfőn 8-kor fel.
Aztán amikor n-edjére az egész hétfő délelőtt állt a 100 fejlesztő mert megbotlott a terraform akkor rájöttek hogy ez baromság.

Gábriel Ákos

Cloud-os videoconf rendszer Azure-ban, kb. 40 db VM kellett a rengeteg transcode (magyarul: átkódolás/újrakódolás) miatt. Interoperability (magyarul: együttműködés) van Teams, Cisco video telepresence és Zoom között, kb mindenki mindenkivel csak úgy tud kommunikálni h. transcode kell, akár csak a secure RTP miatt is.

VM-ek darabja F16Sv2, (ez elég kb 30 db HD video stream transcode-ra):

16 vCPU, 32 GB RAM

Az Fsv2 sorozat a harmadik generációs Intel® Xeon® Platinum 8370C (Ice Lake), az Intel® Xeon® Platinum 8272CL (Cascade Lake) processzorokon vagy az Intel® Xeon Platinum 8168 (Skylake) processzorokon® fut. Ez egy 3,4 GHz-es teljes magos Turbo órajelet és 3,7 GHz-es maximális egymagos turbófrekvencia-frekvenciát tartalmaz. Az Intel® AVX-512-utasítások újak az Intel skálázható processzorokon. Ezek az utasítások akár 2X teljesítménynövelést is biztosítanak a vektorfeldolgozási számítási feladatokhoz az egy- és dupla pontosságú lebegőpontos műveletekhez. Más szóval nagyon gyorsak bármilyen számítási feladathoz. Az Fsv2 sorozatú virtuális gépek Intel® Hyper-Threading Technológiát használnak.

Ennek darabja elég drága tud lenni még egy nagyon diszkontáras egyedi szerződés esetén is, ha megy 0-24-365. Főleg ha ~40 db fut belőle non-stop. Itt már van értelme a 80-90%-át leállítani hétvégére.

Vagy rezerválod 3 évre és kb 60%-a lesz a költség ha jól rémlik :)

Nekünk mindig úgy magyarázták az Azure-s szakértők, hogy az MS-nek jobban megéri az ha nem kacsolgatod ide-oda a cuccot de fixen befoglalod az erőforrást.

Persze ha pár hónapra kell csak a cucc, akkor nem éri meg foglalni, de akkor kapcsolgatni se biztos.

Nem kell elore kifizetned a 3 evet es az eroforrast sem foglalod le, csak a computingot. Tehat megsemmisitheted a VM-eket es kersz helyette valami mast.

Ha jol.tudom, nemi banatpenzert a foglalt computing is visszamondhato.

Plusz amikor eljottem, akkor meg a rezervalas visszamondasa $0 volt. Tehat semmi kotber nm volt benne.

Mondtak a szagertok, hogy nm marad orokke egy de amig van addig erdemes kihasznalni. Most nmtom hogy van.

Ha a 40-60% kedvezményt arra osztogatják, h. vállalod az elején lekötött erőforrást fogod használni és fizetni a teljes 3 év végéig, akkor a visszamondás (tényleges) költségmentessége mellett azért vajon a 40-60% kedvezményt arányosan visszafizettetik veled a 2. 3.év között történő felmondáskor?

A pontos szamomat nem tudom. Ez engem mar annyira nem erdekelt. Ezt boxolja le a cto meg egyeb it manager a felhos szagertokkel :)

Erdemes esetleg beszelgetnetek eggyel, ezek szerint nem vagytok veluk kapcsolatban.

Viszont kozben azert megneztem. Az F16sv2-es gep pay as you go-ban kb $500. Ha 1 evre foglaljatok mar akkor is 40% kedvezmenyt kaptok.

En ugy gondolom, hogy nagyon apro csoro cegeknel van "ertelme" kikapcsolgatni, erre automatizalni meg minden. Kicsit erosebb cegeknel jobb a penzugyi tervezes. Tehat pl 1 evre illik eloretervezni. Igy egy 1 eves rezervalas mar jobb lehet.

Havi 500 dodo legyen 1 gep. Az egyszeruseg kedveert 30 nap egy honap es legyen 4 hetvege tehat 8 nap amikor lekapcsoljatok.

Az ha jol szamolom akkor 133 dodo sporolas.

Es ha nem kalkulalok benan akkor az kb 26% kedvezmeny.

Ha 1 evig tuti kell, akkor megerheti a foglalas. Meg akkor is ha 12 honapnal hamarabb abbahagyjatok. Lehet jobban jartok akkor is ha mondjuk 10 honap mulva kuka az egesz es idleben fut a cucc 2 honapon at. Vagy tleg masra atviszitek a foglalast. Vagy siman csak a gepek felere foglaltok. Stb. Ezt atgondolni es tervezni kell mind eroforras hasznalat oldalrol, projekt tervezes oldalrol es penzugyi oldalrol is.

Es van az amikor szarik bele mindenki csak odabaxak a szorostalpu rendszergazdanak, h oldd meg. Hat akkor cumi.

 

A kikapcsolgatas meg aze' is veszelyes mert fene tudja, h az IaaS-on mi doglik be tole. Bar gondolom van backup meg image stb...

Sokan élnek már felhőben managed servicek között.

Csak épp a valóságban folyamatosan hanyatlik a piaci részesedésük és a felhőnek jóideje leáldozóban van. Ha nem lenne a mostani MI bullshit hullám, akkor nemcsak lassulna, hanem egyenesen negatívba fordult volna már (a Forbes szerint).

Épeszű cég már egy évtizede nem költözik felhőbe, hanem inkább menekül onnan, mert sosem volt biztonságos, ráadásul kifejezetten veszélyes és átláthatatlan is.

Már vagy 5 éve az az egyértelmű tendencia, hogy felhő helyett egyre inkább visszatérnek a cégek a helyi, saját üzemeltetésű szerverekre. Nemhogy nem halnak ki a rendszergazdik, hanem az utóbbi években egyre nagyobb az igény rájuk (max most már nem Apache-ot kell telepíteniük, hanem Docker-t, na bumm).

Ja, és ha valaki azzal próbálna érvelni, hogy a felhő olcsóbb, pár éve már ez sem feltétlenül igaz, sőt:
https://www.zdnet.com/article/cloud-computing-more-costly-complicated-a…
https://siliconangle.com/2021/11/28/cloud-computing-costs-high-can/
https://www.forbes.com/sites/forbestechcouncil/2022/04/19/cloud-costs-m…

> a klasszikus rendszergazdák ki fognak halni szép lassan. A munkakörök is.

sajnos igazad van. en is keszulok nyugdijba menni...

ma mar minden felho, kontener, automatizalas, stb, nem nagyon van igeny a "regimodi" linux szerverekre es azok adminjaira.

en mondjuk idoben ateveztem halozat iranyaba, de mar az is kezd virtualizalodni a felhok miatt.

Most. Majd amikor mindenki leszokik az üzemeltetésről, olyan ára lesz megvenni szolgáltatásként, hogy fognak kelleni a hozzáértők is a visszaforduláshoz. Szerintem a mostani iránynak rossz vége lesz, de nagyon. Semelyik cég nem él örökké. Hol van ma már a Brit Kelet-Indiai társaság? Idővel minden cégnek vége lesz, csak az a kérdés, hogy ekkor mekkora részesedése lesz  a piacból? 

A felhőben lévő cégek gyanítom nincsenek felkészülve egy azonnali megszűnésre.

Nem kell hirtelen kimennie a divatból. Elég egy jól megtervezett, pár hónapig vagy 1-2 évig előkészített támadás az AWS vagy az Azure ellen, és többezer, több tízezer cég marad IT nélkül (aki ott van), akár csak órákra vagy napokra (ha nem is örökre). Legkésőbb akkor rájönnek, hogy nem annyira tuti másra bízni mindenüket.

Ráadásul a ransomware hamarosan visszaér a kör elejére (e nagyokkal kezdtek, haladtak a kicsik felé, de emiatt a védelmek annyit fejlődtek, hogy ismét a legnagyobbakat éri majd meg több munka árán betalálni), és akkor megjelenhet a kifejezetten felhős szolgáltatásokat/szolgáltatókat támadó cybercriminal.

Véleményem szerint ha a cégek eljutnak oda, hogy érdemi TCO-t számoljanak onprem és felhős infrastruktúrára is, akkor fog eljönni a rossz világ a cloudosoknak (finops). A legtöbb cégnél fogalmuk sincs, hogy mennyibe kerül az IT, "el vannak kenve" a költségek. Szerintem kb. 5 év és borulni fog a mostani helyzet. Ha az AI (LLM) mánia kifullad, akkor pedig hamarabb.

( Vamp | 2024. 03. 31., v – 20:00 )

Szerkesztve: 2024. 03. 31., v – 20:07

Nalunk is lehet lenne hely, de sajnos nincs HO es Miskolctol kb 100 Km...

Magam melle jo lenne egy linuxos arc, mert a sok wines kozott egyedul vagyok :) Viszont nalunk az angol fontos lenne, beszelni is... Infra munkakorben ez akar napi tobb ora meetingezest jelenthet (szoban).

 

Megjegyzes:

 

Amugy nalunk alt. itt vereznek el az emberek... Vagy szakmailag eleg jo tapasztalattal rendelkezo, 40-es rendszergazdak, de 0 beszelt angollal, vagy 20 eves kezdok, egesz jo beszelt angollal, de nulla szakmai kepesseggel... :)

 

A zömeben 30-as, jo angolos, meg jo szakmai kepessegekkel rendelkezoket meg nem lehet elcsabitani... :D

Egyreszt nincs tul sok linux rendszer (kb a teljes ceg 5%-a nagyon max). Masreszt a non-stop meeting kb egy honapja van, egy durva leepites óta. (ellentmondas, de most a leepitesek helyere keresunk embert....) Oszinten? miota ennyivel kevesebben lettunk nagyon senkinek sincs ideje effektive "dolgozni"... :)

Amugy amit mi nyomunk meeting az meg istenes is... Nemet kollegak Teams allapota lenyegeben 8 orabol 7 ben "telefonál"...

Az enyém is ~mindig busy. Mivel a teamsben nincs igazi DND, nem lehet usereket szűrni stb. (legalábbis nálunk nem, nemtom hogy by design, vagy le van-e tiltva), valahogyan védekezni kell a ticketing toolt, jirát, emailt megkerülő, SLA-t kiröhögő, tegnapra-kell-és-top-prio özön ellen. A war room üvölt, a többi meg ¯\_(ツ)_/¯

A calendar ugyanez. Befoglalva napi pár meeting, elkerülve a 2 perc múlva 2 óra hosszára gyere be, just in case meg VIP visit eseteket. Ha telcozni akarsz foglalj időpontot, goto 1 :) Így lehet dolgozni is.

echo crash > /dev/kmem

Akkor összefoglalva a hsz-eitek, a legnagyobb cégek annyira nem tudnak munkát szervezni, hogy a dolgozóknak trükkökhöz kell folyamodniuk, hogy a sok szájtépés helyett legyen idejük a valódi munka elvégzésére.

Nekem ez azt mutatja, hogy sokkal több a dologtalan manager, aki csak beszél a munkáról, mint az, aki valójában elvégzi a melót...

Nálam akkor szakadt el kicsit a cérna amikor a management összeröffentet egy 20+ fős, több mint 2 órás meetinget ami arról szólt, hogy a sok meeting miatt nem halad rendesen a munka.

Csak az az egy meeting 40+ mérnökórába fájt a cégnek, azaz egy ember teljes heti munkája ment a levesbe.

Ez igy van. Manager barmilyen titleben az "bullshit job" jelzoje. Azert leteznek, hogy igazoljak szuksegesseget a letezesuknek.

Eddig ketto ujjamon megtudom szamolni az ertelemes, vagy annak latszo es tenyleg mukodtetni akaro managereket.

Every single person is a fool, insane, a failure, or a bad person to at least ten people.

( arpi_esp v | 2024. 04. 01., h – 09:32 )

Docca-t erdemes megkeresni, van ott ismerosom, folyton be akar engem is szervezni, nagyon keresnek tapasztalt linuxos szakit.

Valóban! Ez jó ötlet! Én is javaslom Őket megkeresni.

Kb. 10 éve dolgoztam nekik, és igen, vidékiként kb. 1-2 alkalommal kellett elmennem valakihez megbeszélésre (a kb. 1-2 év együttműködés alatt), minden meló távolról végezhető volt. Nagyon jó a munkaszervezésük, Linux-osként tényleg nem kaptam másfajta munkát arra hivatkozva, hogy a Windows-os most pont mást csinál.

Azt nem tudom, hogy a pénz most milyen. Akkor a többiek elmondása alapján elfogadható volt főállásnak is, aki csak nekik dolgozott folyamatosan. Én csak "szabadidőben".

Nekünk aztán annyira sok lett a saját helyi ügyfél, hogy el kellett válnunk, de én sajnáltam, mert jó csapat volt és nagyon jól szervezett a működés.

( derWRK | 2024. 04. 01., h – 12:09 )

Azért ez a felhő mellett kihal a klasszikus rendszergazda azért sántít, mert kereslet kínálat is létezik a munkaerőpiacon, és a rendszergazda, hivatalosan is hiányszakma. Az jut eszembe mikor annó ismerősöm tanult pl1-ben programozni, ~2010 és mindenki úgy nézett rá mint egy űrlényre... akkor már kevésbé mikor az átlag IT fizetéshez képest plusz egy 0-t kapott, mert lehet hogy évente csak 2-3 pl1 programozót keresnek a világon, de azt kénytelenek meg is fizetni... hogy a témához is hozzászóljak, pár hónapja pont tudtam volna valamit, de azért nyitvatartom a szemem;

Persze, hogy nem hal ki. A felhő csak annyit segít, hogy nem kell szervert venni, meg szereltetni, csak a szoftveres részével elég foglalkozni, meg könnyű 1-2 kattintásból a felhőben valami salbonszerveres környezetet elindítani, de ha pl. abban valami eltörik, vagy összefossa magát, esetleg nem alapbeállítás kell, hanem spéci igény van, akkor továbbra is kell hozzá érteni. És nem, az AI sem váltja ki, nem csak a programozókat, de a rendszergazdát se. Ezzel maximum ilyen HR-eseket, meg gazdasági-pénzügyi vezetőket hülyítenek, akik a szakmai részéhez nem értenek.

A PL/I-gyel el is hiszem, hogy jól keres, ahhoz kevesen értenek. Egyszer nekirugaszkodtam én is, de nem jutottam vele messze. A szintaxisa elég sajátos, merít a Fortranból és a Cobolból is. Nem a legrosszabb nyelv, de nem az a klasszikusan könnyű, meg jól támogatott mainstream nyelv, amibe könnyű bekerülni. Szerintem simán egy AI-nak is bajos, annyira ritka.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

> A felhő csak annyit segít, hogy nem kell szervert venni, meg szereltetni

halvany gozod sincs a felhorol.  en is ezt hittem addig amig kb 10 eve nem vontak be egy aws-es projektbe. azert van ott eleg sok mas is, VM letrehozason kivul amire epiteni lehet, es helybe nem vagy nagyon nehezen megvalosithato...

+1 Én is igy voltam, de akkor egy rövid on-premis példa, mini tanfolyam:

Van néhány  (on-premis , helyi géped, vm-ed mondjuk helyi kubernetessel) , tehát saját hw . Szeretnél terheléselosztást (layer2 ) gépek között akkor valamelyik gépen lefuttatod és kész vagy.

 

apiVersion: v1
kind: Service
metadata:
  name: ingress
  namespace: ingress
spec:
  selector:
    name: nginx-ingress-microk8s
  type: LoadBalancer
  loadBalancerIP: 123.123.123.123
  ports:
    - name: http
      protocol: TCP
      port: 80
      targetPort: 80
    - name: https
      protocol: TCP
      port: 443
      targetPort: 443

https://blog.claryel.hu

Mármint ez egy hálózati loadbalance. Ehhez mégis mit fog szólni a futó alkalmazás? Az adatbázis mögötte, meg a web front, meg hogy lesz klónozva? Az hogy automagically, hát az nem válasz szerintem. :)

Szóval ehhez nagyon úgy kell mindent is felhúzni, hogy ez tényleg működjön, kezdve azzal, hogy eleve az alkalmazásnak alkalmasnak kell erre lennie, ha meg saját, akkor hát úgy kell fejleszteni.

<OFFTOPIC>

 akkor hát úgy kell fejleszteni.

Igen , nativ cloud alkalmazás az igazi,  beeröltethető  monolitikus alaklmazás is. (wordpress). 
Téglagyár vállalatirányitási rendszeréhez nem ezt kell használni.

 Az adatbázis mögötte, meg a web front, meg hogy lesz klónozva?

Röviden, nem túl szabatosan,  sorok önkényesn elhagyva,  kivonatosan:
PL. webserver az alkalmazással konténerben, 3 példányban 

metadata:   
   replicas: 3
containers:
- name: webalkalmazásom_webszerverrel
  image: docker.io/webalkalmazásom. 
service
     - name: webalkalmazásom_service
       containerPort: 80

Van  3 "pod" -od (konténered)  , benne a webalkalmazással, 3 service-d d (vagyis 1 szolgáltatásod  -  webalkalmazásom_service - 3 példányban)a  webszerberrel ,  a szolgáltatásora az általad megadott névvel tudsz hivatkozni. 
Ha egy webszerver leáll, automatikusan indul egy új (replicas 3). 

A webszerver(eknek) a metallb fog ip címet adni, abból a atrtományból amit megadtál neki, ha a webalkalmazásom_service szolgáltatást összekötöd yaml-ban a load balancer szervizzel.

Hasonló módon hozol légtre sql  szervert, illetve állandó lemezt adattároláshoz.

</OFFTOPIC>

https://blog.claryel.hu

 En meg arra sem mernek fogadni, hogy a "beleeroltetheto" Wordpress az problemamentes lesz.

Sose próbáltam, de van  egy csomó "wordpress helm csomag", de sok alkalmazás nem biztos, hogy megy 1:1 -ben. 
Figyelembe kell venni a tervezéskor az eltéréseket.  Statless felépítéssel könnybb dolgod lesz. 
 Vagy  a sessionkezelés egy HA rendszerben nem ugyanaz mint egy  szervernél, le tudja -e kezelni a load balancer ? 
Állapottartó adatbázis vagy stateless NOSQL ,stb.

Megy kicsiben is.  Látok már 4 GB-os málna pc-n home assistant -ot otthoni kubernetesen.
 

https://blog.claryel.hu

Azért irtam, írtuk, hogy a felhő (pl.kubernetessel) nem csak máshol futó vm, bérelt vas,  a devopsnak  van mit csinálnia. On-prem kubernetes-ben is ugyanazt csinálja a devops mint pl Google Kubernetes Engine-ben . 

SQL szerver pláne nem triviális, hogy piffpuff skálázódjon

Nem az.  Tömören, egy variáció:
Felralsz egy mysql-szerver-konténert, elinditod mondjuk 5 példányban,  használva a mysql replikációs képességét,vagyis szinkronban lesznek. Van 5 podod benne öt mysql-szerver , replikációs, és van mysql  szervized, ami öt példányban fut mysql-szerver azonosító néven.   Felralsz egy mysql router-t, a webes appok ezt a router szervizt fogják használni.  Ha 10 mysql szervert akarsz növeled 10 re a mysql-szerverek  számát, A mysql-router pedig elosztja a forgalmat. 
https://a.storyblok.com/f/153547/1600x1017/95e54170f3/statefulsets-1.png

https://blog.claryel.hu

( n.balazs v | 2024. 04. 03., sze – 20:28 )

Továbbítottam a topic linkjét a cég HR-esének. Remélhetőleg keresni fog téged.

( sandroshu | 2024. 04. 05., p – 20:01 )

Ha esetleg vevő vagy időszakos munkára/tanácsadásra, akkor írj rám nyugodtan. (Leginkább Debian 10-12 és Ceph-el kapcsolatos dolgok vannak.)