Foglalkozásomat tekintve ....

HUP

Nem a végzettséged érdekel (kb. a kutyát se, azt a családi asztalánál a rokonoknak mutogasd :), hanem az, hogy miből élsz ...

( trey | 2024. 09. 08., v – 10:36 )

Szerkesztve: 2024. 09. 08., v – 10:36

Itt a szeptember, a felmérések írásának ideje! Írjátok!

(beugratós opciók nyomokban lehetnek a szavazásban)

trey @ gépház

Én ezért választottam az egyebet, mert 20+ év alatt voltam rendszergazda, tesztelő, fejlesztő (C#), hálózatos, tűzfalas, storage konfigtól, ESX cluster telepítésen át belső intranet webfejlesztésig mindent is csináltam.

Hmm. DBA sosem voltam, ez fehér folt a térképemen.

( arpi_esp v | 2024. 09. 08., v – 12:25 )

Szerkesztve: 2024. 09. 08., v – 12:29

> IT devops vagyok 20+ éve

hat a devops fogalom a mai ertelmeben nem letezett meg 20 eve, vagy legalabbis egesz mast jelentett.

en 20 eve is azt mondtam hogy csak abbol lesz jo rendszergazda aki tud programozni is, mert nem fog ketsegbeesni ha nem fordul le valami forrasbol, vagy at kell irni egy scriptet, patchelni pl. egy pppd-t, irni egy kis plugint valamihez stb.

de manapsag a docker/kubernetes babzsakfejlesztoket szoktak devopsnak csufolni...

en 20 eve is azt mondtam hogy csak abbol lesz jo rendszergazda aki tud programozni is, mert nem fog ketsegbeesni ha nem fordul le valami forrasbol, vagy at kell irni egy scriptet, patchelni pl. egy pppd-t, irni egy kis plugint valamihez stb.

^^^ erre nagy +1 ! Szerintem (is) nagyon igaz!

Ha így értelmezem, akkor nem üzemeltető vagyok 20+ éve, hanem devops... De jó nekem az üzemeltető besolorás.

Azért akarják kiszervezni, mert a felhőmulti kiszúrja a szemüket az olcsó diszkontárakkal, amiket az átállás után többel emel meg, mint amennyibe az üzemeltető macik kerültek korábban. Csak akkor már a visszaállás lenne túl drága. A mottó: csőbehúzni, csüngetni, lógatni, függővé tenni.

Van ebben igazság, de más oldalról egy pár fős, pár e-mail fiókos kis cégnek nem éri meg saját szervert meg miegyebet venni, fenntartani. Kapásból embert sem talál hozzá, mert egyszerűen nincs, se drágán, pláne olcsón. De ha előfizetnek, azonnal van levelezés, csoportmunka, akár fájl szintű megosztás, azon egyidőben dolgozás, stb. Vannak azért előnyei a felhős szolgáltatásoknak annak ellenére, hogy a multik a saját gazdagodásukra üzemeltetik, nem a cégek IT-jóléte a fő cél.

Ezen felül a mai világban semennyivel sem kevesebb függőség és kockázat egy olcsó IT emberre rábízni, hogy csinálja, aki aztán emelgeti a díjat ahogy akarja, mert vagy kifizeted, vagy lelép, és akkor ott maradsz egy rendszerrel, amihez senki sem ért, senkinek nincs hozzáférése, stb. Mert ez a valóság, nem a jól dokumentált rendszer és a tulaj páncéljában örzőtt mesterkulcs mindenhez. Ha meg kis szolgáltatónál fizetsz elő, akkor majdnem ugyan olyan vendor lock-in lesz, csak jóval nagyobb eséllyel múlik el egyik napról a másikra az egész szolgáltatás.

Van olyan kifejezés, hogy méretgazdaságosság - szerintem kezd el ismerkedni vele. A visszaállás kapcsán meg azzal, hogy a visszaállásra nagyon sok esetben kell legyen végrehajtható és működő folyamat (mentés, lokálisan x időn belül elérhető infrastruktúra, stb.)
 

A vizet is magad asott kutrol hozod, es a villanyt is estenkent te tekered dinamos biciklivel? Sakat ISP-d van, magad keszitetted a mobilodat egy maroknyi alkatreszbol amibe te magad novesztetted a felvezetot, es magad irtad ra a szoftvert? Te is fuggesben vagy vagy fel tucat multicegtol.

Magad szemeben a gerendat  masok szemeben a szalkat effektus. A meretgazdasag fontos, ez az amiert te sen allsz neki telefont gyartani, hanem megveszed egy multiceg termeket.

Masoknal mashol van a hatar, mas kitettsegeket vallalnak be. Mindenki bearazza a sajat szabadsagat, a sajat biztonsagat.

Gyerekkent sosem masztal fara, sosem kellett dontest hoznod, hogy az egyre vekonyabb agakon elmesz-e azert a tul kint levo cseresznyeert, vagy nem? Ma is ez van, mindenki tudja, hogy mit kockaztat, csak eppen vagy gyava, vagy bator, vagy idiota. Ugy beszelsz a multikrol mintha maguk az ordogok lennenek  pedig csak a termeszetes entropia megtestesitoi. A gravitacioba is bele szokas halni, meg a haborukba is. Amig az emberiseg a termeszet resze, addig az emberi mohosag es idiotasag szinten teljesen termeszetes ok a halalra.

A vizet is magad asott kutrol hozod, es a villanyt is estenkent te tekered dinamos biciklivel?

100% magyar tulajdonú vízművektől jön a vezetékes víz, nem multitól.

Sakat ISP-d van, magad keszitetted a mobilodat egy maroknyi alkatreszbol amibe te magad novesztetted a felvezetot, es magad irtad ra a szoftvert?

Olyan multitól vettem a telefonomat, amelyik akkor még nem volt túl milliárdos ahhoz, hogy ne Németországban, Finnországban, Nagy-Britanniában, vagy akár Magyarországon gyártson mobiltelefonokat. A hangsúly az akkoron van. A multi arroganciája, etikussága általában az életszakaszától függ.

Te is fuggesben vagy vagy fel tucat multicegtol.

Nem mindegy, hogy mennyire és nem mindegy, hogy önszántamból vagy kényszerből.

Gyerekkent sosem masztal fara, sosem kellett dontest hoznod, hogy az egyre vekonyabb agakon elmesz-e azert a tul kint levo cseresznyeert, vagy nem?

Amit leírtam, az Zeller Mérnök Úr folyamatos, multik felé hajló érvelésére, elfogultságára volt kritika, nem magukra a multikra.

Ugy beszelsz a multikrol mintha maguk az ordogok lennenek

Mert azok. A véges erőforrások mellett végtelenbe növekedni akaró (de már így is túl nagyra nőtt) multik legalább is.

az emberi mohosag es idiotasag szinten teljesen termeszetes ok a halalra.

Csak ugye kordában is lehet tartani. Ahogy a multikat is kordában lehet és kordában is kell.

Csak egy mellékszál:

Engem nem érdekel ki a vízmű tulajdonosa. Az érdekel, hogy a hatóság tegye a dolgát, rendszeresen vegyen mintát, hogy megbízhassak a víz minőségében. Ez a bizalom jelenleg részemről hiányzik.

A magyar tulaj ugyanúgy profitéhes, azért kell a szabályozás, hogy ne tudjanak mindent megtenni.

Engem pedig érdekel, hogy ki a vízmű tulajdonosa. Olyannyira, mint a mintavétel és a vízminőség.

A magyar tulaj ugyanúgy profitéhes, azért kell a szabályozás, hogy ne tudjanak mindent megtenni.

Nem ugyanúgy, mert nem nőtt akkorára, mint egy multi, amelyik fél Európa vízkészletén élősködik.

Szerintem bőven van 100%-ban hazai cég, ami outsource-ban üzemeltet, akár csak humán erőforrást adva, de akár úgy is, hogy a teljes infrastruktúra nála van... Egy KKV, aminél nem at IT a fő tevékenység, nagyon ritka esetben fogja tudni kitermelni 3-5 főállású IT-szakember költségét, azaz a cég méretében nem gazdaságos a szükséges szakértelmet belső erőforrásból megoldani.

Ez pontosan így van! Éppen ezért nem alkalmazottként csinálom túlhajtott mindenesként a legalsó IT bérsávban, hanem ezt nyújtjuk mint szolgáltatást, cégesen, mások (főleg mikro- és kisvállakozások) részére. Ha ki akarják szervezni, csak rajta, hozzánk jöhet. :-)

De el fogok gondolkodni, hogyan lehetne devops-nak eladni ugyan ezt, ennyivel többért. :-D

Ráadásul kezdik páran megérteni, hogy a kis cégeknél is (nagyobbaknál meg pláne) a "nagy" multis felhőbe költőzés után is kell IT, üzemeltetés, szervezés, miegyéb, helyben lesznek ugyan úgy PC-k, nyomtatók, kell mentés a felhőről is, stb., mert az sem csak úgy "működik" és kész. Persze a felhős szolgáltatások menedzseléséért még nem annyira könnyű pénzt kérni (sok cégvezető azt hiszi, az benne van a felhős előfizetés árában, azzal letudott mindent), de ez is változni fog valószínűleg.

en 10 eves korom ota fejleszto vagyok, eredetileg abban is akartam elhelyezkedni, ki is probaltam de par honap utan feladtam. az nem nekem valo, hogy masok altal kitalalt orbitalis faszsagokat kell leprogramozni hataridore, es ha elmondom hogy ez miert nem fog mukodni igy, akkor meg en vagyok lehulyezve (aztan a vegen kiderult hogy igazam volt) - persze mashol (pl gyorben!:)) kellett volna dolgozni, tudom...  vagy vallalkozokent csinalni egyedul, aztan ha van melo van penz, ha nincs akkor koplalas van.

az uzemeltetes ennyibol jobb, az havi fix bevetel, jobban tervezheto, utemezheto, kevesbe kell faszsagokat csinalni, tobb az "alkotoi szabadsag", lenyeg hogy mukodjon. mellette meg lehet hobbibol fejlesztgetni, ahogy teszem is. 

azert vicces volt mikor egyik ugyfelnel megkerdeztek nem tudok-e ajanlani egy java programozot mert lenne egy feladat, en meg mondtam hogy itt vagyok...

Próbálom elképzelni, milyen kódot kell írnom egy műszer firmware-ébe, ami sokat segít a céges svn szerver üzemeltetésén. Pointerre mutató pointer azért lehet még benne? :)

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Alapvetően indirekt módon nem ír hülyeséget, csak túlságosan szűk az értelmezés...
Nem tudsz jó műszert csinálni, ha nem tudod, hogyan kell(ene) jól működnie.

...vagy pl. nem gondolsz bele, hogy kézi műszer energiafelhasználása adott energiahordozóval (akkumulátor / elem) mekkora üzemidőt eredményez, és folyamatos működésű eszközben napi kétszeri elemcserét sikerül összehozni.

Pointerre mutató pointer kapcsán emlékeim szerint itt már ment a harc korábban. :)

Mindenki a saját területére asszociál, és ezért születnek IT-s megállapítások nem IT területre vonatkozóan is.
...és innen jönnek azok a gondolatok is, hogy, ha valaki firmware-t programoz, az következésképpen egyből IT-s lesz.

Ha a firmware-ed kommunikál az svn szerverrel, akkor nem mindegy milyen kódot írsz. :)

Nem erre gondolok, hanem pl. nem árt tudni, hogy mondjuk a cuccod egy linux fog futni apache-on, php-fpm-mel, mert lehet egy problémára több megoldás is, csak az egyik tök egyszerű és kézenfekvő, egyszerű setupolni és üzembiztosabb lesz, a másik meg szopás. Vagy ott van pl. azon fejlesztőkókler esete, akinek az az első, hogy chmod 777... Hogy windows-on nem fosunk mindent a C:\Windows\Temp-be (vagy linuxon a /tmp-be). Fájlokat nem az alkalmazás könyvtárába mentünk/írunk, hanem külön. Hogy miért nem jó az, ha rootként/systemként fut a programod. Hogy miért nem jó 7200s timeout a webes php-ra, hogy a cronból meghívott url menjen.

De már valahol tárgyaltuk ezeket.

"Sose a gép a hülye."

Persze, valójában értem, ott volt a siley a végén. :) Pusztán arra utaltam, vannak olyan fejlesztések, amelyek nem kapcsolódnak az üzemeltetéshez, legfeljebb annyiban, hogy a szerveren ven a forráskódjuk, és ezzel nagyjából leírtam a project és az üzemeltetés közti kapcsolatot teljes egészében. Ilyen esetben kb. mindegy, hogy a fejlesztő nem ért az üzemeltetéshez, még lehet jó fejlesztő.

Persze, világos, hogy amennyiben webfejlesztésről, vagy valami adatbázisos dologról beszélünk, akkor látni kell a másik oldal felől is a kérdést, ha valami jót szeretnénk csinálni.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Nem bármi, mert épp arra hoztam példát, amikor a szerveren a forráskód tárolódik, de ott sohasem fog futni, mert esetleg nem is arra az architektúrára íródik, hanem valami egészen más hardware-re. Azért hoztam fel, mert az én munkám épp ilyen.

Szerk.: Tehát az én munkámat hardware és firmware fejlesztőként sehogyan sem minősíti az, hogy értek-e szerver üzemeltetéshez, vagy sem. Ha a fejlesztett kód szerveren futna, akkor igen, de nem ott fut.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Tehát az én munkámat hardware és firmware fejlesztőként sehogyan sem minősíti az, hogy értek-e szerver üzemeltetéshez, vagy sem.

 

https://hup.hu/node/186269

^^

Ha (jobban) értenêl az üzemeltetéshez, akkor jó eséllyel gyorsabban megoldottad volna a fenti problémádat, több időd maradt volna a firmware fejlesztésre :)

Ez pontosa így van.

Írtunk már egy csomó olyan szoftvert (ketten dolgoztunk a témán), amikor a néhány oldalas speckó helyett a menedzserünk megismertette velünk az egyébként szigorúan titkos cégek közti szerződéseket is. Bejött a sompolygás, a megoldás sokkal jobb lett.

De volt olyan, amikor kemény tárgyalásra ült le az IBM. Az ellenfél - hogy megerősítse a pozícióját - két hw szakértőt is delegált. Az IBM pedig három jogászt. ;)

Ezt ne felejtsd a hw reszelgetése közben! ;)

Mindkettő kód, csak míg én az MCU regisztereinek bitjeit nézegetem a katalóguslapon napokig, addig a klasszikus software-esek a különféle függvénykönyvtárak API dokumentációjával csinálják pepitában ugyanezt. :) Alattam nincs oprendszer 32 biten sem, 8 biten ez meg esélytelen is volna. Az operációs rendszer bizonyos szinten az élet megrontója. Például akkor, ha ki vagy feszítve futásidőben bizonyos körülmények között. Engem nem zavar, már megszoktam. Néha hiányzik a malloc(), realloc(), free(), akár kedvem is lenne implementálni, csak aztán rájövök, hogy ezekhez a játékokhoz sok RAM kellene ám, mert fragmentálódik, nyilván kell tartani, a lyukakat felszámolva sok memcpy() lesz belőle, mert RAM-ot itt a piros, hol a piros szerűen nem tudok lapozgatni, mert ez annál egyszerűbb szerkezet. PIC32 amúgy, MIPS a lelkem. :)

Meg ugye mind a digitális, mind az analóg elektronika megtervezése is a feladatom, elvi kapcsolási rajz, majd PCB. Ez nem az a klasszikus IT-s terület, szerintem amikor valaki azt állítja magáról, hogy IT-s, egészen másra gondol a többség.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Minden firmware fejlesztőt zavarni szokott az OS, de attól még hogy ott van az OS, pont ugyanaz a kód pont ugyanúgy fut a processzoron. Az OS nem fogja átrendezni az utasításokat. Mindössze kapsz egy infrastruktúrát, amire építhetsz.

Teszem hozzá, én sem használtam eddig még egy freeRTOS-t sem, de ha kellene, nem idegenkednék tőle. Dinamikus memóriakezelést még az avr-gcc is "tud", ami nem OS funkció, hanem libc funkció.

Persze aki dinamikusan allokálgat egy MCU-n az a szememben pont akkora láma, mint aki lebegőpontos műveleteket használ.

Lényeg a lényeg, azért nem véletlen létezik a Real-Time linux is. Sajnos még mindig nem mainline.

Viszont még a normál linuxra is azt szoktam mondani, hogy mitől félünk? Ha egy embedded linux képes egy szoftveres ethernet bridge-et kihajtani 100 megán, meg egy pingre válaszolni ms alatt...

Jó dolog tud lenni az az RTOS, különösen egy gyors MCU-n, de azért nem pont ugyanúgy fog futni az a kód, és ez nem minden esetben jó.
Amúgy de, az OS át fogja rendezni az utasításokat - no nem blokkon belül, de időbeli lefutásban biztosan.

A lebegőpontos műveletek használata is az MCU-tól függ, hardveresen mit támogat, és mi a cél az adatokkal, emiatt ez sem egyértelmű.

OFF

"Minden firmware fejlesztőt zavarni szokott az OS"

Mert mind elmaradott. Manapság már nem nagyon fut bele az ember olyan 32-bites MCU-ba, amelyiken hátrányt jelentene az OS. Azt mondanám, hogy kb. a bootloader az a szint, és a nagyjából 4kB RAM, ahol még nem használunk OS-t. Minden ennél nagyobb projektnél megéri a kezdeti befektetést. Ráadásul az MCU gyártók fejlesztő környezetei manapság pár kattintással csinálnak egy hello world projektet, amelyikben van OS, meg interruptok, meg timer, meg UART.

Persze, csak amikor a DMA-val behozott adathalmazodon azért mész végig minden második mintát feldolgozva, mert nem fér bele az, hogy minden mintát feldolgozzál, akkor nem az lesz a legnagyobb problémád, hogy mit fog írni az UART-ra meg I2C-re, hanem az, hogy nem lehet általános a DMA IT handler, amelyben struktúrából kiveszi a tényleges handler címét, aztán meghívja azt, vagy jó, esetleg ezt még benne hagyod, de eldobod, azt, hogy bármit átadj neki, mert nem kell, ne vigye az időt.

Egyáltalán nem az a probléma, hogy hogyan nézne ki egy printf("Hello world!\n");. És ahogy mondod, a bootloader-t is meg kell írni olyanra, amilyet helyesnek gondolsz.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Nem egyszerű, mert MCU kell, nem CPU. A 200 MHz az olyan, hogy elég bizonyos megkötésekkel, nyilván a végtelen sebesség jobb lenne. :) Sima CPU-hoz akkor már RAM-ot kell illeszteni, perifériákkal kell körülbástyázni. Ami a legalkalmasabb MCU, az meg nem elég gyors. Vagy esetleg nem elég olcsó. Vagy BGA, ami csak a selejt gyártásának bölcsője, de nem is terveznék túl nagy lelkesedéssel PCB-t hozzá.

Az meg lényegtelen, hogy bithack, vagy sem, ettől független a fizetésem. Vagy írjam fel egy papírra, hogy mától két héten át bithack-elek, ezért extra fizetést kérek, majd ezt tegyem ki az asztalomra? :)

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Az világos, hogy libc és nem OS, meg az is, hogy tudja, de azt a tudást inkább engedjük el. :) Ami a double-t illeti, nagyon ritkán, nem futásidő-kritikus helyen használom, de nincs lelkiismeret-furdalásom, mert az MCU-ban van hardware FPU, szóval gyors lesz az.

Ami a nem blokkolós programozást illeti, igyekszem így megoldani az egészet, a folyamataim futtatását és azok közötti váltogatást megírtam, egyfajta interprocess kommunikációt is írtam, így aztán semmi szükségem az OS-re.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Abból neked hogy jött le, hogy IT-s vagy/vagyunk?
Az FPGA programozás biztosan nem IT. Aztán ha bedurrantottam az FPGA-t, és a benne levő procira fejlesztek, az már határeset. Mivel ez utóbbit csinálom az idő nagyobb részében, beírtam magam az IT szoftverfejlesztőkhöz.

Egyébként pillanatnyilag Azure DevOps-ban dolgozunk. Akkor én most devops vagyok? :)

Már mitől nem IT?

Ha a szoftverfejlesztő IT, akkor az FPGA is az. Egy másik szabályrendszer, más logika, de attól még ugyanolyan szoftver (hiszen módosítható), bár ebben a definícióban már volt hitvitám :)

Ha viszont a programozási nyelvek körül szétnézel, azért ott is elég széles a spektrum (assembly-től a funkcionális nyelveken át mondjuk a megboldogult flash-ig), én nem látom hogy a HDL ne férne ebbe bele. Még ha név szerint "hardware descriptor"-t is jelent.

Attol fugg, hogy mit ertesz a hardver design alatt. Ha a legujabb iPhone szappantarto sarokkerekitesi sugarat, vagy a rozsaarany muanyag szinkodjat, akkor az nem IT, hanem kepzomuveszet illetve iparmuveszet, vagyis nem rendes szakma. :-P

Ha viszont ugy hardver design, mint a NYAK tervezes, akkor mar majdnem IT, mert annak van egy ilyen vasas szakterulete, ahol a jomunkasemberek olyanokat mormolnak maguk ele, hogy "ezen a frekin mar lenyeges a skin hatas, ugyhogy ez a vezetosav igy nem lesz jo..." mert ok tenyleg tudjak, hogy mi hajtja a villanymotort. :-)

Bevetettem a "trey módszert", megkérdeztem a chatGPT-t.

Szóval minden emberi tudás forrása szerint:

Is hardware design considered an IT job?

Hardware design is generally not considered an IT (Information Technology) job in the traditional sense, though it does overlap with the broader field of technology. [...]

Ellenben:

Is software development considered an IT job?

Software development is often considered part of the broader tech industry, but it isn't traditionally categorized as an IT job. [...]

Ha a kérdés így lett volna feltéve, akkor én is egyértelműen tudok válaszolni, mert az IT nekem is kb. inkább ezt jelenti:

IT Jobs: Information Technology typically focuses on managing, maintaining, and supporting technology infrastructure (like networks, databases, and servers), as well as providing end-user support. IT roles include system administrators, network engineers, IT support technicians, and database administrators. [...]

 

Viszont mivel itt a HUP-on a szoftverfejlesztő is bele lett véve az IT-be, én csak azt mondtam hogy a hardveres is IT-s (is) ha firmware-t ír, addig biztosan. Hogy a core hardverfejlesztés IT-e, az már inkább kérdés. Nyilván egy tápegység tervezés nem az.

Viszont mivel itt a HUP-on a szoftverfejlesztő is bele lett véve az IT-be, én csak azt mondtam hogy a hardveres is IT-s (is) ha firmware-t ír, addig biztosan. Hogy a core hardverfejlesztés IT-e, az már inkább kérdés. Nyilván egy tápegység tervezés nem az.

...és, ha a tápegység része egy mikrokontroller is, amivel be lehet állítani a kimeneti feszültséget, áramkorlát értékét?

Esetleg a hardver nem tápegység, hanem egy műterhelés, ami képes konstans árammal terhelni, konstans feszültséget tartani (ennek megfelelően terhelni), teljesítményre szabályozni, mindezek során pl. Ah vagy Wh adatgyűjtést végezni, esetleg soros vonalon (pl. RS232/RS485) beállítható / monitorozható, az vajon IT projekt?

...mert firmware abban is van és szoftvert kell fejleszteni rá...

Ennek arányában a magyar IT-s témájú újságokban, közvélemény kutatóknál, fejvadászoknál, álláshirdetőknél az IT-s = szoftverfejlesztő.

Aztán írnak olyant, hogy "ha az IT-t kibővítjük a lazán kapcsolódó területekkel, mint adatelemzés, devops, ITsec, akkor" ez meg az.

És még mindig nem került náluk bele az IT lényege, az üzemeltetés, a kibővítés után sem...

Közben meg van IT (üzemeltetés), van szoftverfejlesztés, van adatfeldolgozás (bányászat, elemzés), fejlesztés-támogatás (devops), stb. stb.

( Caro | 2024. 09. 08., v – 15:03 )

A korfa mindenesetre nem túl bíztató. Ezek a fiatalok tényleg a tiktokon lógnak egész nap?

Nekem már 17-18 évesen is a hup meg az sg jelentette a világot. Sajnos azóta mindkettő színvonala sokat zuhant, főleg ami a komment szekciót illeti.

Viszont ennél CSAK lejjebb van kb.

( joco01 v | 2024. 09. 08., v – 15:40 )

SWE-t jelöltem, de kezdem azt hinni, hogy mindig is devops (is) voltam.

( golgota | 2024. 09. 08., v – 17:44 )

Szerkesztve: 2024. 09. 08., v – 17:44

IT Operations-t csinaltam 16 evig, kozben elkezdtuk a DevOps-ot, aztan az SRE-t, es mindekozben Architect lettem. Mindezt Cloud es BigData teruleten IS. Kicsit szuknek erzem az opciokat, ennel azert sokkal de sokkal szinesebb a vilag :D

( trey | 2024. 09. 08., v – 19:14 )

Úgy látszik, ebben is igazam lesz 😊

trey @ gépház

Igen, pénteken beszélgettem PestiSráccal, akkor került szóba. Eleve, a szavazás is a beszélgetésből jött létre. Állítottam, hogy hiedelmekkel ellentétben a HUP 80-90%-a NEM üzemeltető.

Akkor mondtam neki, hogy kiteszek erre egy felmérést. A "hány éve" opciók pedig az ő ötletei voltak hozzá.

trey @ gépház

Ja, hogy nem forradalom lesz, csak tőzsdére megy a HUP!

Értem már, mitől lengett be az NVIDIA árfolyama.

Amúgy elkezdtem gyűjteni azokat a szakkifejezéseket, amiket itt a HUP-on hallottam először. "Bukkake", "Jaszkari", "Düddő", most meg ez a "Vakjolán". Fantasztikus.

És ezek baszogattak engem évekig a magbetyár miatt, amit nem is én találtam ki. :-D

Science for fun...

( n.balazs v | 2024. 09. 08., v – 20:13 )

Igaz, hogy alapvetően üzemeltetői vonalon mozogtam / mozgok, de elég gyakran kell fejlesztőket támogatni, automatizálni, architecteskedni (infra / security), devops, presales. Sőt, még vállalkozóként is űztem / űzöm az ipart.
Szoftverfejlesztő az, ami tuti nem vagyok. Nem vagyok hajlandó azt a dzsumbujt elviselni, ami szoftverfejlesztés címszóval fut. Forog tőle a gyomrom.
Így maradtam az egyéb IT-s 20+ éve.

( beatnull | 2024. 09. 09., h – 08:09 )

Tizen-x éve nem vagyok IT-s de azon meglepődtem, hogy 106 fórumozóval egyetemben. Az érdeklődés megmarad még ha nem is vagyok piacképes, úgy tűnik.

[insert line here]
B.C. 3500 - DIY Vehicle / A.D. 30 - DIY Religion / A.D. 1991 - DIY OS

( zrubi v | 2024. 09. 09., h – 09:35 )

Egyéb IT-s vagyok 20+ éve

De, nyilván a 20+ év alatt voltam még:

- üzemeltető

- kicsit devops / devsecops' is ;)

- végül: Consultant - aki már leginkább 'csak' megmondja a tutit, ügyfelekkel konzultál, oktat, megoldást tervez, mentorál

zrubi.hu

( KoGa v | 2024. 09. 09., h – 09:36 )

Hát én végigjártam a ranglétrát. Először web fejlesztő, majd üzemeltető, végül volt egy 5 évnyi eltévelyedésem DevOps irányba, de soha többet :D

( vilmos.nagy | 2024. 09. 09., h – 13:32 )

[x] IT devops vagyok < 5 éve

cloud dolgokat, meg k8s dolgokat, meg egyebeket pöcögtetek jópár éve, kis ilyen-olyan integrációkkal, illesztésekkel.

Előtte fejlesztettem ~3-4-5 évig, főképp Spring & Java. A mai napig beleverem az orrom, ha productionben kijön valami hiba, meg pöckölöm a hobbiprojektjeimet.

( lcsaszar v | 2024. 09. 09., h – 17:26 )

Kellene egy olyan felmérés is, hogy: adsz-e level 1, level 2 supportot, csak munkaidőben, munkaidőn kívül is bármikor, ügyeleti beosztás szerint, vagy mindeki hozzám fordul ha valami nyűgje van.

( zolij | 2024. 09. 09., h – 18:08 )

Aki azt választotta, hogy "IT devops vagyok 20+ éve", az időutazó? 

Ismerősöm mondja mindig, hogy olyan poziciónak, hogy DevOps Engineer nem szabadna léteznie, mert a DevOps egy szemlélet, nem egy pozíció :)

Az én értelmezésem szerint a DevOps alapvető célja, hogy a fejlesztés és az üzemeltetés közös felelősséget (angolban ez ownership, nem tudok rá ideillő fordítást) vállaljon a fejlesztési és deploy folyamatokért. Ezt támogatja a sok különböző szoftver ami egy megfelelően tervezett és kialakított rendszerben valóban közelebb tud vinni ehhez a célhoz. Ennek része az is, hogy a két terület közti kommunikáció és együttműködés növekszik, bizonyos átfedések is létrejönnek, de az határozottan nem célja, hogy fullstack jelleggel akkor most mindenki értsen mindenhez is. Persze ezt aztán a gyakorlatban elrontották az említett DevOps Engineer pozicióval, majd jött az Enterprise világ, jól összeizélte a központosítási és szabályozási mániájával és megszületett a Platform Engineer.

Ezt egyszer Franko egész jól leírta (https://hup.hu/comment/2883143#comment-2883143):

a, a DevOps olyan fejlesztő, aki tud üzemeltetni

b, a DevOps olyan üzemeltető, aki tud fejleszteni

c, a DevOps az alkalmazásokat üzemelteti

d, a DevOps a fejlesztői infrastruktúrát üzemelteti

e, a DevOps a felhős infrastruktúrát üzemelteti

És igen. Teljesen mindegy, hogy mit ír a könyv. A cégek számára 90%-ban a fentiek valamelyikét / mindegyikét jelenti a devops.

Ha meg kapsz egy olyan munkaköri leírást, ami szándékosan annyira fondorlatos nyakatekerten van megfogalmazva hogy abba mindent bele lehet magyarázni, azaz a főnököd erre hivatkozva kb. bármi szart a nyakadba akaszthat, akkor előbb-utóbb leszarod h. mégis minek hívnak munkahelyen, és szimplán csak megcsinálsz mindent amit kapsz.

Nem, csak tükröt tartottam.

Ha nem tudtátok, mennyit kínálnak, hogy lehetett olyan oltári faszságokat mondani, hogy egy pénzért több állást kell betölteni? Honnan tudhattad, hogy csak az van, hogy kiemelkedő lóvé? Úgyhogy, de. Beleállok. Mert megint faszságon kaptalak titeket.

Jaaaa, megint ... :D

megértük

Kik vagytok?

trey @ gépház

Nem, csak tükröt tartottam.

Nekem feleslegesen, mert én a fent említett dologhoz hasonlót sem kommenteltem.

Kik vagytok?

Én én vagyok (a profilomon még a becsületes nevemet is megtalálhatod). Az meg, hogy "ezt is megértük ..." egy elég elterjedt fordulat, de igen, igazad van, úgy lenne helyes, hogy ezt is megértem.

Mert megint faszságon kaptalak titeket.

De úgy látom mindjárt inkább rögtön Te mondod meg.

Mire volt akkor a többesszám?

Erre már szerintem válaszoltam. Ez egy fordulat, amit általában ebben a formájában használok, ha használok.

Kérdésre lesz válasz?

Ahogy említettem, az általad felsoroltakhoz hasonlót sem kommenteltem. Azt szeretnéd, hogy mások helyében válaszoljak a fenti kérdésekre?

Ha megnézed a devops munkakör (tudom, a devops az szemlélet igazából) értelmezését, akkor ezeket a feladatokat, ezeket a toolokat régen is használták. Vagy egy üzemeltetőre (infra / alkalmazás) szakadt rá ez a meló vagy egy fejlesztőre - 20 évvel ezelőtti megnevezéseket nézve.

Volt ahol ezt korábban operability-nek hívták. (nem, nem kell hozzá énekelni tudni...)

Logolás, monitorozás, konfig management, installer, upgrade, HA, ilyesmik tartoztak ebbe felelősségi körbe. Effektíve nem üzemeltet élesben, de kb mindennel foglalkozik, ami ahhoz kell, hogy a szoftver üzemeltethető legyen. Nyilván nem teljesen azonos a mai devops fogalommal, de elég nagy átfedésben van.

Mellesleg, amíg ez volt a titulusom, a tesztkörnyezetet hardver szinten is elég sokáig én csináltam, szóval ennyi erővel rám lehet mondani, hogy devops-os voltam mielőtt ezt annak hívták volna. (Amúgy én is csak 10 évet írtam be.)

Régóta vágyok én, az androidok mezonkincsére már!

A DevOps nem munkakör, amelyik cégnél devopsos kolléga  van, nincs DevOps. 

Az Atlassian szerint: "DevOps is a set of practices, tools, and a cultural philosophy that automate and integrate the processes between software development and IT teams. It emphasizes team empowerment, cross-team communication and collaboration, and technology automation."

Pl. konténerek, felhő, kubernetes, Fn/Lambda, NoSQL, soa, mq, event driven architecture, git, ci/cd, secops, software defined infra, microservices, több milliós nagyságrendű felhasználó percenként, és agile (hirtelen ennyi jut csak eszembe), meg természetesen a javascript istencsapás csak a netscape-ben volt. ;D

( miq | 2024. 09. 10., k – 13:06 )

1994-2021 között főállásban üzemeltettem, mellékállásban fejlesztettem,
2021 óta főállásban fejlesztek, és mellékállásban üzemeltetek.

Ezzel mit jelöljek? :)

( sly007 v | 2024. 09. 12., cs – 00:00 )

Lehet hogy érdemes lenne több programozási témát felhozni?