Kihalnak-e a hagyományos üzemeltetők?

HUP

Az üzemeltetői szakmát számos nagyon erős hatás érte az elmúlt években. A történet pedig messze nem csak a cloudról szól, hiszen az on-prem világ is megváltozott.

A hazai hagyományos üzemeltetői közösség elöregedőben van, a méretgazdaságossági és automatizációs kényszer miatt az elvárások is nagyon megváltoztak. Egyre több réteg jön be az üzemeltetésbe, és ahogy távolodunk a hardvertől és az operációs rendszertől, egyre inkább fejlesztők veszik át az újabb feladatokat. Kollár Lacival (SMP) és Zámbó Marcellel (Andrews IT) beszélgettünk a 43. adásban.

Az adásban elhangzott hivatkozások a Discord csatornánkon érhetők el, ahol még beszélgetni is tudsz velünk, és a többi hallgatóval. Adásainkat megtaláljátok a SoundCloudon, a Spotify-on, az Apple Podcasten, a YouTube csatornánkon, és immár a YouTube Music-on is.

( nagyjoco | 2024. 10. 25., p – 15:18 )

Szerkesztve: 2024. 10. 25., p – 15:22

"Az üzemeltető egy olyan világban él, ami egy súlyosan torzult világ". 

Ezért a mondatért már megérte bekapcsolni.

Ha tartós rendszert építesz és okos csapatot nevelsz, akkor száz kiadásban sem érheti baj; ha csak a gépekre hagyatkozol, akkor egyszer jól jársz, máskor rosszul; de ha sem a rendszer nem bírja a terhet, sem a csapat nem tanul a hibákból, akkor minden egyes kiadás kockázat.

( Elbandi v | 2024. 10. 25., p – 19:01 )

atveszi a helyuket az AI! de csak ha nem led-et kell nezegetni :D

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

A hwsw úgynevezett újságíróinak a helyét is átvehetné az AI. Olyan az a portál mintha Frei Tamás álneveken átnyergelt volna informatikai témákra a moszkvai maffiózós interjúja után. 

A jelenlegi színvonalhoz képest egy AI újságíró hatalmas előrelépés lenne. 

“Az ellenség keze betette a lábát”

( ggallo | 2024. 10. 25., p – 19:31 )

A feléig üzemeltetőként hallgatva idegesítő volt, mert mintha arra ment volna ki a téma, hogy az üzemeltetés azért hal ki, mert a cloud szükségtelenné teszi (és a cloud-ban csak betanított droidok kellenek diszk és szerver cserére, nem klasszikus üzemeltetők), aztán a beszélgetés második felére előkerült, hogy valójában azért mennek aránylag sokan cloud irányba (ami drága ha nem oda való a feladat) mert nem találnak rendes üzemeltetést...

Az meg, hogy a startup-oknak nem kell üzemeltető, mert mind cloud natívban gondolkodik, azért érdekes és egyben szomorú, mert a legtöbb ilyen a végén megszűnik, mert maga az ötlet lehet jó, de megvalósítva nem rentábilis a cloud költségek miatt, és az elején nem is gondoltak arra, hogy lehet kisebben kellene gondolkodni, majd megnőni, ami már a cloud méretgazdaságosságát kívánja.

Azt is érdekes volt hallani, hogy a cloud vonal többször abba is belehal, hogy a csak cloud-hoz (nagyon) értő ember már olyan drága (a popularitása miatt), hogy az egész üzleti modellt felborítja, és nem éri meg csinálni miatta, vissza kell skálázni vagy on-prembe hozni olcsóbb emberek közé, hogy pénzt lehessen vele keresni.

Pont a minap egy magánegészségügyi befektető/vezető interjújában olvastam, hogy a magánegészségügy kezd azzal a problémával küzdeni, hogy egy orvos egy 60-70 perces műtétért annyi pénzt kér, amennyi a közszférás főállásban a havi fizetése, és így 9 számjegyű fizetések jönnek ebből össze neki, de ezt már nem éri meg szolgáltatni a magán egészségügynek, mert nincs rá fizetőképes kereslet, nem lehet az egészer annyiért eladni.

Nekem fájó, hogy csak közepes és nagy szervezetek sejlettek ki a beszélgetésből, a KKV szint és annak igényei, lehetőségei nem. De pl. itthon a GDP 55%-át KKV-k állítják elő, szóval jelentős tényezők. Itt, Nógrád megye keleti felében azt hiszem ismerem a kisebb-nagyobb vállalkozások, hivatalok java részét IT téren, ha nem is dolgozunk a többségüknek. Oké, ez egy szegény régió, de itt nincs felhős rendszer, nincs on-prem privát cloud, nincs Kubernetes szóló gépen sem, Docker-ben is max. csak elszigetelt dolgok futnak "véletlenül", vastag kliens van mindenre, on-prem fizikai szerverek, stb. Szóval a valóság az, hogy van mit üzemeltetni, és lesz is még jó darabig. Persze az igaz, hogy az üzemeltetők jelentős része semennyire sem tud haladni a korral (vagy inkább beragadtak 20 évvel ezelőttbe...), és tényleg technológia (felhőre) váltásra kényszeríti a cégeket, ha nem találnak jobb üzemeltetőt, aki modernebb rendszert működtet helyben. Az pedig igaz, hogy egyre kevesebb kompetens, technológiát követni képes és akaró üzemeltető van. Ez a váltás pedig jellemzően sokkal drágábbá teszi az Ő méretükben az IT-t, de a nincs IT és a drága IT között még mindig a drága a jobb, ha menni kell a cégnek.

Az pedig, hogy a fiatalok között még fehér holló gyakorisággal sincs üzemeltető szerintem annak köszönhető, hogy mindenhonnan a cloud folyik, meg a devops. Azt senki sem mondja, hogy az IT is olyan, mint minden más, periodikusan visszatérnek és eltűnnek dolgok. Majd ha elkezdenek sokan lejönni a felhőből (ez már szerintem el is indult), akkor ugyan az lesz az üzemeltetőkkel (csillagászati pénzért fognak dolgozni, mert kevesen vannak), mint amikor a felhőbe menéskor volt a felhős szakemberekkel (csillagászati pénzt kértek, mert kevesen voltak).

Szerintem az IT-nak soha semelyik ága nem szűnik meg, csak hol itt, hol ott van több emberre igény. És minden ágnak az marad meg a kevés igény idején, aki a legmagasabb szinten ért a területhez. Szóval inkább azt kellene minden IT-ban indulónak mondani, hogy a terület majdnem mindegy, de ne középszerű legyen egy most népszerű területen (mert sírás lesz a legközelebbi váltásnál), hanem profi bármelyik területen (mert a profik mindig kellenek).

Nagyreszt egyetertek, de van egy fontos dolog, amit mindenkepp kihangsulyoznek: a modern "DevOpsos" toolok szinte mindegyike opensource, teljesen ingyenes szoftverek (git, linux, ansible, prometheus, grafana, elasticsearch, kibana, logstash/fluentd, jaeger, nginx, docker, postgresql, redis, mongodb, es meg hosszan sorolhatnam). Tehat ha vki csak on-prem uzemeltet (kis penz-kis foci alapon), attol meg ugyanugy alkalmazhatja a devopsos praktikakat.

Peldaul ha az elet ugy hozna, hogy nullarol kellene osszerakni IT-t egy kis cegnek (mondjuk sajat vallalkozas eseten), akkor az alabbi koncepciokat alkalmaznam (vs. regimodi rendszergazda):

  • virtualizacio hasznalata free ESXi vagy proxmox alapon (vs. baremetalra telepitett Windows/Linux)
  • VM-eken belul is szinte csakis kontenerizalva futtatas mondjuk docker compose/swarm alapon (vs. apt install xyz)
  • centralizalt log management ELK/EFK alapon (vs. nincs log management vagy vmi penzes megoldas (VMware Log Insight es tarsai))
  • centralizalt perf. managemet Node(+sok mas) exporterek, Prometheus, Grafana alapon (vs. nincs perf. management vagy vmi penzes megoldas (VMware vROps es tarsai))
  • alerting/notification AlertManager alapon (vs. minek az)
  • VM-eken beluli OS konfigja ansible alapon (vs. SSH/RDP-n osszekattintgatva)
  • IaC szemlelet, minden legyen git repoban tarolva (vs. minek az)
  • Jenkins/GitLab pipeline-ok a deployolgatashoz (vs. SSH/RDP-n osszekattintgatva)
  • Rendes secret management (vs. kockasfuzet)

A fenti szoftverek konkretan 0 Ft-ba kerulnek. Nyilvan az elejen maceras/melos osszerakni (az elso alkalommal), de sokkal letisztultabb lesz a vegen minden.

Pontosan! Erre írtam alább, hogy "Az persze tény, hogy a klasszik szakbarbár üzemeltetők (akiket az adásban iskolai rendszergazdának hívnak, sajnos nagyrész jogosan) akik csak egy dologhoz értenek (az is jellemzően elavult), és nem is akarnak tanulni, azok eltűnnek a piacról."

Mi pl. az általad felsorolt módon üzemeltetjük jó ideje még a kis egyszerveres, pár gépes kisvállalkozásokat is, valójában (így végig olvasva) minden pontot teljesítve. De nagyon sokszor futunk bele abba egy-egy kétségbeesett hívás során ismeretlen cégnél ami a zárójelek közé van írva. Ezeknél vagy megkapjuk az üzemeltetést és átalakítjuk, vagy marad a mostani ember szó szerint fillérekért. Amikor összedől, akkor együtt zokognak, hogy dehát ezt nem lehet máshogy/jobban, a másik (mi) is ugyanezt csinálta volna, csak drágábban... Na az ilyenek szépen kikopnak (ez felénk is jól megfigyelhető, gyűlnek az új ügyfelek apránként úgy, hogy nem mi ajánlkozunk nekik).

Nem vagyok jartas KKV korokben, de el tudom kepzelni, hogy rengeteg ceg nagyon "el-Microsoft-osodott" az idok folyaman: on-prem DC-k, exchange, file share-ek, SharePoint, MSSQL-ek, .net-ben fejlesztett appok, ilyesmik. Ha esetleg eljutottak a virtualizacioig, akkor az HyperV ugye. Nyilvan ezeket osszekattintgatjak a rendszergazdak es hagyomanyos modon kell uzemeltetni (e.g. clickops :) ).

Ez igy van, viszont megindult egy migráció a microsoft cloud irányába, mert a cloud ajánlatuk nagyon erős: egy beszállítótól megkapsz kb. mindent ami a backoffice működéshez kell: levelezés, szövegszerkesztés/táblázatkezelés, calendar, címtár/SSO, üzenetküldés, vírusvédelem, AI/LLM, automatizálás, stb. 

SharePointon verziozottak a file-ok, tehat a veletlen beletorles/modositas ellen van mas vedelem.

Fugg az adat mennyisegetol. Lehet elegseges ha a fonok neha letoltni a laptopjara/kulso SSD-re ami fontos. Nagyobb mennyiseg eseten on-prem NAS, vagy S3 Glacier, de van szaz masik cloud backup megoldas is.

Jah, csak a szomorú valóság az, hogy ha mondjuk a OneDrive kliens tart egy példányt az adatból a gélpeden, meg egyet a felhőben, akkor az adat pont kétszer annyi példányban van meg, mint egy átlag cégnél.

Hiába mondod, hogy ez nem backup, szakmailag igazad van, de amíg az átlag cégnél pl. a teljes könyvelés egy példányban van meg, a könyvelő laptopján, addig tökmindegy, már ez is előrelépés.

Áááá, már sem router, sem nyomtató nem kell. Mindent okostelóról és okosóráról fognak csinálni, nyomtatás pedig a felhőbe. A nyomtatott papírt pedig majd valami Uber-féle közösségi "aki közelebb van az elviszi" alapú startup szállítja ki. Az O365-tel sem kell bajlódni, majd az AI megírja a dokumentációkat és a marketinget is. De akár irodát sem kell fizikailag bérelni, azt is lehetne felhőből igényelni.

Bocs, tudom, hogy már öreg vagyok, de minden maradiságom ellenére is szerintem az egyetlen valódi és hamisítatlan felhó alapú szolgáltatást a légi közlekedés biztosít: megveszed a jegyed, beszálsz, felszállsz, és már ott is leszel a felhőben.

Áááá, már sem router, sem nyomtató nem kell.

Egyetértek. (Tudom, hogy szakarsztikusnak szántad.)

nyomtatás pedig a felhőbe

Van olyan szolgáltatás, ahol telepítesz egy virtuális nyomtatót a gépedre, és amit ráküldesz, az megy egyből a postára. Szerintem nyomtatni már csak magáncélra szoktam, a gyereknek színezőt, meg ilyenek. Bár így is valszeg olcsóbb lenne rányomtatni a hibridlevél printerre, és két nap múlva kihozza a postás. :D

De akár irodát sem kell fizikailag bérelni

Egyetértek.

sem nyomtató nem kell.

Értem a szarkazmust. Ezért +1.

Viszont picit komolyabban: egy kitűnő piaci rés a Posta számára. Elküldjük a kinyomtatandó dokumentumot a Posta nyomtatójára, a postás pedig aznap/másnap kihozza házhoz. Akár laminálva, színesben stb. Akár úgy is, hogy a furgonba betesznek egy szgp-t, nyomtatót, ami házhoz megy. A biztonsági kód / jelszó / OAUTH stb. megadása után jön ki a dokumentum a nyomtatóból ott helyben. Így a dokumentum tartalmát se ismeri meg más.
Bár a Magyar Posta kreatív szakemberei (haha, vannak ott egyáltalán ilyenek?) biztosan megugranák ezt a fejlesztést. (erős szarkazmus részemről)

Van egy hobbi/startup jellegű témám amin dolgozom és pontosan így van összerakva. Az hogy git-ben tároljunk dolgokat, legyen valamilyen CI (és esetleg CD), használjunk docker image-eket igazából nem hogy nehezíti, hanem könnyíti a munkát, nincs is igazából értelme máshogy csinálni. 

Feltesznek egy Windows szerver OS-t fizikai hardverre, és azon kattintgatják GUI-n amit muszáj. Ezen van a fájlmegosztás, szigorúan workgroup módban mindenkinek teljes hozzáféréssel (mert a felhasználónak és a rendszergazdának is gondot okoz a hozzáférés-menedzsment meg a jelszavak használata). Valamelyik IT vénájú kolléga, mert külön ember vagy külsős nincs. Vagy olyan, akit rendszergazdának vettek fel, de aztán minden más lett a dolga, mert "ő ért a gépekhez", ami alatt az e-mail-től a cégkapu kezelésén át az ABEV-es feladásig mindent kell érteni, nem csak az OS support-ot, hanem ténylegesen PC-n végzett felhasználói feladatokat.

Desktop-on mindenkinek Windows desktop OS, általában Win10 vagy régebbi, mert a gép nem alkalmas Win11-re (pénz sincs másik gépre, OS-re). Felhasználók adatainak jó része a desktop-on, mert elfelejti a szerverre tenni, és a megosztás helyett levélben küldik egymásnak (szigorúan a magán @gmail.com fiókon keresztül) azt, amin többen dolgoznak. Mentés ezekről a gépekről egyáltalán nincs.

Mentés max. külső HDD-re kézzel, eseti jelleggel. Ha van NAS, az jellemzően tele van másolva valakinek a maszek nyaralási fotóival, mert az otthoni gépére nem fért. Ez mentve máshová nincs.

Vírusvédelem vagy a Windows beépített felügyelet nélkül, vagy valamely gyártó ingyenes verziója (Panda és Avast népszerű).

Összes gép (szerver is) tele privát fájlokkal, ezek általában több helyet foglalnak, mint a céges munka adatok.

Levelezik a komplett cég egy ingyenes cégnév@gmail.com fiókkal.

Satöbbi.

Na, ez a hagyományos üzemeltetés, ami sajnos ma is jellemző a hazai KKV szektorra, és nem csak az 1-2 fős mikrovállalkozásokra, hanem az akár 50 fős, milliárdot is elérű éves forgalmú cégekre.

Tükéletes!!! :D És sajnos igaz. Amikbe bele szoktam futni:

- állami közszférákat kerülöm: totál hülyék vannak ezeken a helyeken, kicsitől a nagyig. Hiába magyarázod ezeket a hibákat és hogy mit kellene tenni, mert az nekik fárasztó. Ezeket hagyni kell, omoljon rájuk az egész. Csak egy példa: amikor kezdett megjelenni (bő 20 évvek ezelőtt) a pendrive, azzal az indokkal nem voltak egy főiskola titkárságán azt használni floppy helyett, mert nem kaptak Pendrive Kezelői Tanfolyamot.

- esetenként belefutok olyan fillérbaszó cégbe/vállalkozóba, hogy a normális és biztonséágos mentés megvalósítását is szabotálja a sóhersággal. Semmi gond, megoldom ahogy akarja: egyazon NAS-on, másik HDD-re. Azonban a felelősség az övé, erről munkalap kiállítva és alá is írva.

- az, hogy mindent emailen küldözgetne át egymásnak és a fájlszervert is csak a privát anyagok tárolására használják, a leg tipikusabb.

 

De írok jobbat is:

  • - hiba van a géppel/szoftverrel, vagy csak valamit elbaszott
  • - mobillal befotózza a képernyőt
  • - a képet berakja egy word doksiba, ami eleve még csökkenti is a tényleges képméretet. Majd elküldi emailen nekem.

De még ezt is tudták valahol fokozni: a word soksiba helyezett képernyőről készül mobilos fotót kinyomtatták, rárajzolták a problémájukat, beszkennelték és elküldték mailen.

zanzásítva:

- Az aws pénzt csinált az elastic stackből, ez elkezdte zavarni az elastic mögött álló céget.

- Nem sikerült megegyezniük, az elastic új licence-re vált. A forráskód ugyan elérhető maradt, de azt már nem teheted meg, hogy IT cégként elkezdesz szolgáltatni ügyfeleknek pénzért. (Lehet, de egyedi megállapodást kell kötnöd velük.)

- Megjelenik az opensearch.

- 2024 aug: Az elastic észbe kap, visszavált egy szabadabb licence-re. Kérdés ezek után ki fog bízni bennük.

Akinek esze van, mintenből egyet üzemeltet és havi díjért adja, mint szolgáltatás. Szerintem ahol ehhez értő szaki van, teljesen logikus, hogy a 30 partnernek ne 30 külön ELK stack legyen feltéve és minddel kelljen mapetkedni rendszeresen, hanem csak egy. Ráadásul az ügyfél is könnyebben ad havi fix pénzt, mint vegyen alá vasat, fizesse ki a bevezetési projektet, aztán fizessen havi díjat az üzemeltetésért. Pláne a kicsiknél ez nem valósítható meg. Vagy bérlik mint "felhős" szolgáltatást, vagy nem lesz nekik ilyen.

( Sixday v | 2024. 10. 25., p – 19:33 )

Már 10 éve is egyértelmű volt hogy ki fognak halni, csak mostmár egyre gyorsul a folyamat.

Szinte minden IT jellegű feladatra van jó áron külsős (legtöbbször felhős) megoldás.

És ha egy vezetőnek választania kell a "Pista tologatja a 10 szervert ami kerül havi 1-1.5 millába a cégnek de tulajdonképpen senki nem tudja mit csinál" megoldás vagy aközött hogy megveszi az összes funkciót külsős szolgáltatóktól, rendelkezésre állással, rendes supporttal, bővíthetőséggel, stb. ugyanannyiért akkor nem kérdés hogy mit fog választani.

Innen született meg ugye a DevOps, aki gyakorlatilag egy dev skillekkel rendelkező ops személy, tehát nem fakad sírva ha terraformban van az egész infra és nem kezd el keresztet vetni ha valaki aztmondja hogy semver meg branching strategy.

Aki erről lemaradt, nem váltott és nem képezte magát tovább az bizony előbb-utóbb megnézheti magát mert vészes gyorsasággal fogynak az ssh-n keresztül szervert csesztetős pozíciók.

Tehát nem halnak ki, sőt az üzemeltetők kereslete sem csökken, csak máshol lesz rájuk igény, némiképp más skillset-tel...

Amit Trey is mindig mond, és igaz, hogy a felhő csak másvalaki szervere, nem valami földöntúli dolog. Abba is be kell lépni valakinek SSH-n és meg kell csinálni ami félrement. Plusz a felhő rendszereket sem a babzsák startup fejlesztők rakják össze a DC-kben (és nem is betanított diszk cserélő operátorok), amin aztán lehet akármit futtatni IaC.

Az persze tény, hogy a klasszik szakbarbár üzemeltetők (akiket az adásban iskolai rendszergazdának hívnak, sajnos nagyrész jogosan) akik csak egy dologhoz értenek (az is jellemzően elavult), és nem is akarnak tanulni, azok eltűnnek a piacról. De nem úgy általában az üzemeltetők. Viszont ez igaz az IT összes ágára, pl. a fejlesztők között sincs arra kereslet, aki csak valami lefutott, valaha populáris, de nem túl specializált technológiához ért.

A felhő csak másvalaki szervere... ezt jellemzően azok állítják, akik nem dolgoztak clouddal, és nem is akarják megérteni a koncepciót. Igen sokrétű és összetett szolgáltatási modell a cloud, nem pusztán vasak egy másik DC-ben.

Ha tartós rendszert építesz és okos csapatot nevelsz, akkor száz kiadásban sem érheti baj; ha csak a gépekre hagyatkozol, akkor egyszer jól jársz, máskor rosszul; de ha sem a rendszer nem bírja a terhet, sem a csapat nem tanul a hibákból, akkor minden egyes kiadás kockázat.

Pedig de. A felhő csak másvalaki szervere. Csak az a másvalaki elsősorban ebből él, sokan van, nagyon ért hozzá, és már kész, bevált megoldásai vannak arra is, amire még nem is gondoltál. Meg lehet csinálni mindent on-prem, ami a felhőben van? Persze. De mire mindent összeraksz, drága lesz, és az is csak hónapok/ évek múlva, és közben rájössz mit felejtettél ki vagy mi az ami mellett közben elment a világ. Mondom ezt úgy, hogy az on-prem-et baromi jó lehetőségnek látom költség csökkentésnek, de már nem úgy, mint régen. Régen on-prem first, és peak menjen ki a cloud-ba, ma cloud first és ami stabilizálódott architektúra/workload, az jöhet földre. Van ami persze csak földön jó, ilyen pl. a fejlesztők homokozója, mert ott végtelen pénzt el lehet felhőben égetni, miközben a jó része értékteremtés nélküli elfelejtett kupi. De akkor az legyen egy felhő konform módon összerakott k8s, hogy onnan már könnyen lehessen tovább menni bárhova. 

A felhő csak másvalaki szervere...

Az internet szolgáltatás csak másvalaki rútere.

A vezetékes hálózat csak másvalaki vezetéke.

A mobilszolgáltaás csak másvalaki antennája.

 

Ahgy mutatod is a hozzászólásodban, a tudáson alapuló sok-sok extra szolgáltatás  képezi itt az igazi értéket. 

Ha tartós rendszert építesz és okos csapatot nevelsz, akkor száz kiadásban sem érheti baj; ha csak a gépekre hagyatkozol, akkor egyszer jól jársz, máskor rosszul; de ha sem a rendszer nem bírja a terhet, sem a csapat nem tanul a hibákból, akkor minden egyes kiadás kockázat.

Pedig de. A felhő csak másvalaki szervere.

Polgárjogi szempontból igazad van, de a felhő (hozzáértők kezében) nem arról szól, hogy ami eddig az irodai szerveren volt VM, az innentől a felhőben legyen VM.

Meg lehet csinálni mindent on-prem, ami a felhőben van? Persze. De mire mindent összeraksz [...]

Ez egy hatalmas, nagyon-nagyon szignifikáns "de". Konkrét projekt, belekerült X pénzbe, ahol X nagyságrendileg pár százmillió forint volt, majd az ügyfél kitalálta, hogy le kéne hozni onprem. Az árajánlat kb. 1,2*X volt, mire minden felhős workloadnak lett volna onprem megfelelője.

Van ami persze csak földön jó, ilyen pl. a fejlesztők homokozója

Eeeeeh, igen, sokszor így van, két nagyobb kivétel jut eszembe:

  1. nincs onprem megfelelője annak, amire fejleszt a cégetek, lásd az előző pontot
  2. nagyon erőforrásigényes a dev környezet (is), akkor érdemes lehet felhőben gondolkodni

Amit említesz, hogy bent marad a kupi, és drága lesz, az kezelhető automatizmusokkal, nálunk is van, anélkül tényleg drága lenne.

Ott az egymás mellett elbeszélés, hogy Te a felhőről mint emelt szintű szolgáltatásról beszélsz, én meg felhőről mint szerverek sokaságáról, amiken ugyan úgy OS meg köztes rétegek futnak, amit valakinek tutujgatni kell.

Az, hogy felhőben már nem szervereket és VM-eket telepítenek, hanem pl. Kubernetes alapon Yaml kóddal pod-okat indítanak és dobnak ki sűrű egymásutánban, nem érdekes az én mondandómban. Mert én csak azt állítom, mikor azt írom, hogy "a felhő csak másvalaki szervere", hogy az üzemeltetők majd ott csinálják a dolgukat, a felhős cégnél, ott üzemeltetik a rendszer, teszik rá a Kubernetes dolgait, meg minden mást, hogy aztán a felhőt magas szinten igénybe vevő már csak Yaml állományokat kell írjon. Attól, hogy azt a szervert a gyártó leszállítja a DC-be, még nem alkamas a webes felhő admin API-n érkező kérések kiszolgálására. Aki meg a felhőt, mint szolgáltatást hatékonyan igénybe tudja venni, jellemzően nem tudná az alatta futó rendszert beüzemelni, bármennyire ért a használatához.

Mert ugye itt arról beszélünk, hogy az on-prem üzemeltetésre most épp (állítólag) csökkenő igény van. Nem arról, hogy a felhőbe költözve mennyivel egyszerűbb és másabb bizonyos feladatokat megoldani.

+0,7

A felhő / felhőbe költözésnek is van evolúciója. Ha valaki leragad a 0. lépésnél ("VM-ek a cloudban", IaaS) koncepciónál, akkor általában súlyosan drágábbra jön ki, mint onprem vasakkal megvalósítva ugyanazt az infrát.
A cloud natívra átállni idő, energia és piszok sok pénzbe kerül. Hogy ez mikor térül meg, nagyon nem egyszerű kiszámolni.

DevOps, aki gyakorlatilag egy dev skillekkel rendelkező ops személy

 

Pont nem, a DevOps a metodika ami alapján a Dev és az Ops együtt dolgozik. Még mindig, 2007 óta. Persze a nagyvállalatok próbálják újradefiniálni mit is jelent, mert azért az mégis milyen már hogy két külön részleg együtt dolgozik? Ki hallott már ilyenről? Így nem lehet birodalmat építeni cégen belül.
Majd szépen felveszünk egy DevOps embert vagy csapatot akik összedevopskodják a dolgokat és már kész is.

Igen, a DevOps egy metodika. Viszont a gyakorlatban egy DevOpsosnak annyira sok mindent kell(ene) tudnia, hogy egy elet nem eleg ra, hogy az ember kitanuljon mindent is: profi szoftverfejlesztest tobb nyelven, halozatos dolgok, cloud adminsag (+terraform), szazfele AWS/Azure/GCP szolgaltatas, linux skillek, docker, kubernetes, security minden terulete, automatizacio/pipeline-ok, monitoringozas, sokfele adatbazisok, stb. Tehat a gyakorlatban megicsak szet szokott valni a backendes, halozatos, adatbazishoz jobban erto emberek, es mindegyikojuket osszefogja par devopsos. De nyilvan ez meret es cegfuggo.

Pontosan ezért, a gyakorlatban a legtöbb DevOps platformüzemeltetőként dolgozik, egy erre kialakított csapatban - nem szigetszerűen a fejlesztők mellett. Utóbbit senki nem tudná kifizetni, annyira kevés ember van aki a teljes spektrumot le tudná fedni.

Innen született meg ugye a DevOps, aki gyakorlatilag egy dev skillekkel rendelkező ops személy

Lófaszt, nehogymár... :D

A DevOps egy módszertan, mint az Agile vagy a Scrum vagy sok egyéb, a lényege az, hogy egy búra alá kerül a dev és az ops terület, mert sokkal nehezebb kibaszni a másikkal, ha egy csapat vagytok egy felelősségi körrel: "DevOps is the combination of cultural philosophies, practices, and tools that increases an organization’s ability to deliver applications and services at high velocity: evolving and improving products at a faster pace than organizations using traditional software development and infrastructure management processes."

Sok-sok cégnél voltam, az alábbi hat definícióra tudom felosztani, hogy ki mit ért DevOps alatt, akár ezek részleges kombinációját:

  1. olyan fejlesztő, aki tud üzemeltetni is (bullshit)
  2. olyan üzemeltető, aki tud fejleszteni is (bullshit)
  3. a fejlesztői infrastruktúrát üzemelteti (platform engineer)
  4. a felhős infrastruktúrát üzemelteti (cloud engineer)
  5. az alkalmazásüzemeltő (application operations engineer)
  6. DevOps is the combination of cultural philosophies... (ez!)

https://iotguru.cloud

Ez így leírva tele van tárgyi tévedésekkel.

Külsős megoldás: a külső fél árat emel. Durván. A vezető meg csak pislog. Olcsóbb - csak látszólag.
rendelkezésre állással, rendes supporttal, bővíthetőséggel: Hát itt sokszor több a marketing bullshit, mint az igazság. Meg "indiaival" birkózni nem egyszerű.

A devops nem innen született meg. Hanem szimplán költségcsökkentési okokból. A cégek nem akartak 10 banánt fizetni, csak 5-t. Meg rájöttek, hogy az IT környezet gyors reprodukálhatósága, a dokumentáltság fontos üzleti előnyök.
Minden cég mást ért devops alatt. Franko ezt tökéletesen leírta már korábban is.

Mind a mai napig tömegével találkozom olyan magukat "devops szakembernek" hívó személyekkel, akik még az IT alapokkal sincsenek tisztában. Akkor miről beszélünk?

( uid_17626 | 2024. 10. 25., p – 20:23 )

Egyszerűsített def. Üzemeltető az, aki a LED-et figyeli! ;)

( arpi_esp v | 2024. 10. 25., p – 22:35 )

Szerkesztve: 2024. 10. 25., p – 22:37

akkor gyorsan nyugdijba megyek mielott en is kihalok! az AI szerint mar ugysem elek :)

a hagyomanyos mosoport uzemeltetot otthonaban, munka kozben erte a halal...

akkor gyorsan nyugdijba megyek

Mire odaérsz, az AI generál helyetted egy olcsóbban fenntartható nyugdíjast :D

my @chars = ("I","O");
while(defined $arpi_esp){
    does_nothing();
    print $chars[rand @chars]."tt faj.\n";
    print "Régen minden jobb volt, bezzeg a mi időnkben!\n";
}

( chx | 2024. 10. 26., szo – 11:20 )

Persze hogy kihalunk. Mint a mainframe, meg a C úgy 20 éve, és azóta is folyamatosan :)
Aztán a devops által odahányt "infrát" is rendbe kell tennie valakinek, hogy működjön is. Nem lehet mindenki webshop/facebo/tapichat/babzsák hős.

*ásít*

echo crash > /dev/kmem

így van. A hazai cégek 60%-a mikrovállalkozás (max 10 fő foglalkoztatott). Árszabásban kevés olyan cloud szolgáltatás van amit ki tudnának vagy ki akarnának fizetni az ilyen kis cégek. De még a kisvállalkozások (max 50 fő) is megfontolják ezek alkalmazását.

Továbbá azzal is tisztában kéne lenni, hogy a jellemzően Budapesten és aglomerációjában veszik igénybe a legnagyobb arányban ezen szolgáltatásokat. Az ún. vidék -- az informatikai ágazatok kisebb jelenléte miatt -- az arányokat tekintve köszöni, jól el van az on-prem megoldásokkal.

Ezen cégek nagy része jobban szeretik ha az adatok ott vannak helyben a kezük alatt: ha akarják kihúzzák, elrejtik, kalapáccsal szétverhetik, elvihetik, akár bele is hugyozhatnak. Ezen cégeket jellenzően 40-50 éves vagy afölötti korosztály vezeti, a klasszikus és jól bevált  megoldásokhoz való ragaszkodás többet nyom a latba mint a DevOps-os blabla. Volt hogy kaptak ajánlatot cloud megoldásokra, de elhajtoták őket: nem bíznak senkiben, így aztán főleg nem bíznak egy felhős cég tök ismeretlen tulajában és gárdájában.

Jó észtevétel. Amíg a Kürt él és virul, addig lesz on-prem is. Valamint a kihalásra ítélt őskövületnek számító üzemeltetők is itt fognak még mászkálni, köztük én is.

Sajnos mára minden rendszer annyira és feleslegesen túl lett bonyolítva, hogy hiába DevOps valaki, valódi DevOps soha nem lesz belőle: nem fogja a teljes spektrumot sem átlátni, sem felfogni. Csak egy szeletét. Nincs ezzel baj, csak ne lennének maguktól annyira elájulva.

15-30 évvel ezelőtt még átláthatóak voltak a rendszerek és a fejlesztések, de már akkoriban sem volt olyan, hogy teljes szélességében és magasságában mindent értett volna akár a legprofibb szaki is.

Nagyon nem jó sem az irány, sem a tempó.

Sajnos mára minden rendszer annyira és feleslegesen túl lett bonyolítva

Nezopont kerdese. Public cloudban serverless technologiakat hasznalva rendkivul szeles tartomanyban skalazodo (Dev/Test -> QA -> Staging -> Prod) alkalmazas hosting "infrat" tudunk osszerakni a globalis piac szamara. Ez 15-30 eve elkepzelhetetlen volt (olyan aron, amibol megoldhato mindez manapsag).

Nagyon nem jó sem az irány, sem a tempó.

Ezt majd az ido eldonti. De lehet hogy mar eldontotte.

Public cloudban serverless technologiakat hasznalva rendkivul szeles tartomanyban skalazodo (Dev/Test -> QA -> Staging -> Prod) alkalmazas hosting "infrat" tudunk osszerakni a globalis piac szamara. Ez 15-30 eve elkepzelhetetlen volt (olyan aron, amibol megoldhato mindez manapsag).

Ok, ez igaz. De erre hol van szüksége a legtöbb, nem IT-ből, pláne nem szoftver fejlesztésből élő cégnek? És ők vannak többen...

Szerintem az a fő gond, hogy sokan azt hiszik mára (köszönhetően a marketingnek, a képzeltlen embereknek és a kényelemnek/lustaságnak, stb.), hogy lehet mindent egyszerűen, "... as a service" csinálni, használni, és minek ismerni ami alatta van, az ósdi, elavult. Ha meg nem kell ezért nem ismerjük, akkor nem kell on-prem, így hozzá értő szaki sem. De jó, tiszta spórolás. De ezek a dolgok nem csak úgy lesznek "alatta", hanem valaki azt megcsinálja.

Az adatok on-prem tárolásához meg nem csak a begyepesedett öreg cégtulajok ragaszkodnak. Sok többi topikban mindenki arról beszél, hogy alternatív megoldás kell a gmail, facebook, stb. helyett mert ezek elszívják és monetizálják mindenki minden adatát. Céges vonalon meg mindenki fújja, hogy tegyék ugyan oda a cégek az értékes üzleti adataikat, mert az lesz a jó, nem az on-prem. Akkor ez most hogy van? A hülye fotóimat ne tegyen Google-ba mert hajjajj, de az értékes üzleti adataimat tartsam mindenképp az MS felhőjébe mert az on-prem szerver laggard?

Van, amikor és amire jó vagy legjobb a felhős szolgáltatás akár nagyon kicsi, akár nagyon nagy cégnél. De van, amire ugyan olyan jó, vagy jobb az on-prem.

Árszabásban kevés olyan cloud szolgáltatás van amit ki tudnának vagy ki akarnának fizetni az ilyen kis cégek.

Havonta, fejenként 6 USD nettóért kapsz olyan SaaS szolgáltatást, amiben van levelezés, irodai csomag, videokonferencia, identitáskezelés, file share, meg minden bizbasz, amire egy átlagos, nem-IT mikrovállalkozásnak szüksége van. Ennél nem tudom, hogy lehet olcsóbban megcsinálni.

Az ún. vidék -- az informatikai ágazatok kisebb jelenléte miatt -- az arányokat tekintve köszöni, jól el van az on-prem megoldásokkal.

És ezeket ki üzemelteti? Mondjuk van egy vidéki megyeszékhelyen egy szobafestő-vállalkozásom, vagyok benne én, mint tulajdonos, meg két segédem, meg a könyvelő beszámláz havi pár órát. Tudod, milyen IT lesz nálam? Egy gmail cím ("felhő"), egy Facebook oldal ("felhő"), meg ha nagyon ügyes a szomszéd gyerek, akkor csinál nekem egy Tiktok profilt is. :)

+1

És szerintem nem kihalnak, hanem elfogynak, nincs utánpótlás. Egyszerűen nincs ember üzemeltetésre, a fiatalok közül alig tud valaki hagyományos üzemeltetési feladatokat elvégezni. A régi motorosok meg nyilván válogatnak, többet kérnek, nem akarnak foglalkoznak kicsikkel, meg user-supporttal.

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

És szerintem nem kihalnak, hanem elfogynak, nincs utánpótlás. Egyszerűen nincs ember üzemeltetésre, a fiatalok közül alig tud valaki hagyományos üzemeltetési feladatokat elvégezni.

Az a trend, hogy nem is kellenek, tipikusan nyugdíj előtt vannak 10-20 évvel, aki tanul, annak lesz munkája, aki nem, az kihullik és/vagy marad neki a melók maradéka, szopással és pénzszűkével. Kisebb rájuk az kereslet, mint a kínálat és ez csak gyorsul, ahogy egyre több helyen állnak át "cattle" metodológiára a "pet" helyett.

Amikor itt látod, hogy valaki legacy ops melót keres vagy legacy ops melója van és nyíg azért, mert mondjuk 300-500 ezer nettója van, az ezért van. Ha tanult volna, akkor 1,2-2 millió nettóról beszélnénk többnyire remote melóval és akár 3 millió fölé is megy ez, ha UK vagy US remote melót talál.

https://iotguru.cloud

Aki tanul, annak lesz munkája

Mivel jómagam is a 10-20 évvel nyugdíj előtt álló üzemeltetők halmazába tartozom, kezdem azzal, hogy amikor a pályámat kezdtem, ígéretes progtamozó voltam  (c/c++). Képzések akkoriban semmi nem volt ('90-es évek). Azonban mivel minden érdekelt, szép folyamatosan bekebelezett az "üzemeltetési" terület is, amiben mindenféle IT munka benne volt.

A 2000-es években kezdtek megjelenni Bp-en (és csak ott) olyan oktató cégek, akiknél lehetett egy szűk tartományból választva képzéseket választani. Egy bökkenő volt: CSAK céges zártkörű képzéseket adtak, tehát ha én az utcáról beestem volna, nem kapok semmit. Szerencsére egy olyan főnököm volt aki kihajtotta a dolgot és jelentkeztem Linux tanfolyamokra, aminek a nem kis költségét a munkáltatóm bevállalta.

Teltek az évek, én az O'Reilly szakkönyvekből, Linuxvilág magazinból, valamint a netes fórumokon szedtem össze a tudást, valamint terepen dolgozva. Google még gyerekcipőben csak volt.

Három probléma van:

1) a képzések és egyben az állások (legyen ez DevOps vagy akár C# dev. vagy bármi más IT terület) szinte kizárólagosan Budapesten koncentrálódnak. Egyszóval hiába lesz valaki jól képzett pl. Nagykanizsán vagy Tapolcán, semmit nem tud kezdeni amíg fel nem költözik a fővárosba, Addig viszont neki is marad az üzemeltetési "aljamunka".

2) sajnos az informatikai piacra is jellemző az ami minden más területen is: ha már őszülsz, mész a kukába. Tök mindegy milyen képzések, milyen tapasztalatok vagy tudás van az illető mögött.

3) túl van hype-olva, túl van értékelve és feleslegesen túlzottan fel van duzzasztva a fejlesztői és DevOps terület: indokolatlanul sok ember indokolatlanul nagy fizetésekkel.

De nem baj, szarérhugyér mai napig is takarítjuk a fiatal kicsirigók által odahányt mocskot sok helyen. És vállaljuk be azokat a melókat amiket bár nekik kellene elvégezni, de agyuk már nincs hozzá. Aztán hogy valamit felmutasson a melóhelyen, kibérelnek magunkfajta "alvállalkozót" és megcsináljuk nekik titokban. Majd az értekezleten csoport meetingen pedig verik a mellüket, hogy milyen fasza munkát végeztek és így sem lettek kialvatlanok.

1, a képzések és állások jelentős része remote mehet és van bőven vidéken is olyan, ahol már nem a legacy-ops megy.

2, ha tanulsz, lesz állásod, mindegy, hogy hány éves vagy. A fő probléméba abból van, ha nem tanulsz és a 10-20 évvel ezelőtti ismeretekkel akarsz boldogulni.

3, nincs hype, kurva nagy szakemberhiány van a DevOps területen.

De nem baj, szarérhugyér mai napig is takarítjuk a fiatal kicsirigók által odahányt mocskot sok helyen.

Szerintem te nem találkoztál még "DevOps" jellegű üzemeltetéssel, hanem az Ifj. Veér István - aka vérpistike - rendszerekkel és azokat kevered ide. Kevéssé hiszem, hogy egy összerakott Kubernetes cluster után odahívnak, hogy szét kell szedni és visszatenni legacy üzemeltetési környezetbe.

Másik érdekesség, hogy a DevOps területen dolgozók átlagéletkora 40-45 év, alig-alig van 30 év alatti, szóval pláne nem tudom, hogy kikkel szoktál találkozni.

És vállaljuk be azokat a melókat amiket bár nekik kellene elvégezni, de agyuk már nincs hozzá. Aztán hogy valamit felmutasson a melóhelyen, kibérelnek magunkfajta "alvállalkozót" és megcsináljuk nekik titokban.

Mondj valami konkrét példát, hogy mit raktok rendbe alvállalkozóként titokban.

https://iotguru.cloud

Érzek némi ellentmondást abban, hogy mások fizetését indokolatlanul nagynak tartod, de közben szaréhugyé dolgozol hasonló területen. Lehet nem bennük van a hiba.

Ami itthon valójában probléma (ez kb passzol az első pontodhoz, de bővebb probléma): míg 99% cég csóró, addig nem futja nekik normális üzemeltetési körülményekre. Amíg nem dől be az egész, addig még verik is a mellüket, hogy ugyehogy 100% rendelkezésre állás volt két rakás szarral. Ha meg bedől, akkor a cég is bedől, ha tényleg fontos dolgokra használták. 
Ezzel együtt, itthon nehéz tapasztalatot szerezni olyan területen, ami otthoni játéknak túl drága. Meg persze idő is kell rá, ha valami mégis elérhető. Kevés helyen játszanak komolyabb eszközökkel a cégek is. Kis pénz kis foci. Kis cég, kis és elavult infrastruktúra és technológia. Kis ország, 30 év lemaradás - mert nem méretgazdaságos, mert nincs aki meg tudná fizetni a modern dolgokat.
Ja meg persze, amíg olcsóbb valakinek fizetést adni, mint megoldani a technikai problémát, addig inkább fizetik a szaréhugyé fizetést valakinek, hogy tartsa a támfalat, hogy még ne dőljön ki.

Amúgy nem csak üzemeltetés terén probléma, hogy gyenge a gazdaság itt. Feljesztők közül is tudok több példát, akik azért mentek külföldre, mert több nyugati országban is tárt karokkal várták nagy cégek őket, itthon meg nincs rájuk kereslet, mert nincs jelen a technolóia. De a biológus és más természettudományos területeken is megvan, hogy itthon lehet könyvtáros vagy árulfeltöltő lesz belőlük, miközben fejletteb gazdaságú országokban simán találnának képzettségüknek megfelelő munkát.

Aztán a devops által odahányt "infrát" is rendbe kell tennie valakinek, hogy működjön is. Nem lehet mindenki webshop/facebo/tapichat/babzsák hős.

Tapasztalatom szerint a DevOps metodológia teszi rendbe az Ops által odahányt infrát. A nézőpont különbség abból adódik, hogy az Ops ezt tipikusan nem érti, túl komplex számára, tehát szerinte ez baj.

A fő különbség amúgy az, hogy:

- a legacy infra az "pet" típusú, vagyis a szervereknek és szolgáltatásoknak neve van, története van, ha beteg, akkor gyógyítják, cserélnek ezt-azt, klasszikus upgrade van, gazdája van, aki fejben tartja a dokumentáció helyett azt, hogy mi hol van és mi hogy működik.

- a "DevOps" infra az "cattle" típusú, vagyis a szervereknek és szolgáltatásoknak száma van, ha köhög egyet, terminálódik az instance vagy a vas, szinte minden immutable, vagyis nincs upgrade, nincs átírok ezt-azt, és minden le van írva valamilyen leíró fájban, amivel különféle tool-ok szinkronban tartják a futó rendszert.

Ehhez hozzájön, hogy a "DevOps" jellegű infra esetén a legacy Ops feladat nélkül marad, mert a high level feladatait átveszi a SRE (Site Reliability Engineer), a low level feladatok pedig technikusi feladatok, a hibás vasat ki kell húzni, helyére betenni új vasat és network boot kapja meg az aktuális OS image-et, aztán meg kell nézni, hogy a vas gyógyítható-e vagy selejt és a dobozból ki kell venni egy újat. Ez már KKV szint közepétől is nagyjából így megy jobb helyeken, KKV alatt értve az 10-250 fős cégeket, kb. 1 és 20 milliárd közötti éves nettó bevétellel, tehát mondjuk 50 fő 5 milliárd forint már elég nagy ahhoz, hogy saját infrája legyen, a kisebbek olcsóbban elvannak felhővel.

Amúgy ez utóbbi pár éve talán overkill lehetett kis rendszereknél, de kiderült, hogy nem overkill, egyszerűen csak nincs hozzá elég szakértelem, akik meg nem értenek hozzá és nem is akarják megtanulni, azok szerint szar az egész, de ez már jó ideje így van, hogy az új technológia mindig szar.

https://iotguru.cloud

Én "ops"-ként teljesen egyet értek azzal amit itt írtál. A fenti terminológia szerint aki ops, annak sre felé kell tovább képezni magát, vagy marad egy szűkülő piacon. Az igazán hozzáértő és nyitott ops-ok meg mindenképp felfelé fognak váltani, mert a kis cégek hiába nem akarnak felhőbe menni, ha nem lesz pénzük az on-prem üzemeltetést kifizetni az ügyetlenebb és olcsóbb ops-ok kihullása után...

De ez a piac itthon bazi lassan szűkül, mert a legtöbb cég az ops-ra támaszkodik, aki a saját szűkös ismeretén belül csinál nekik valamit. Ultra ritkán adódik valami alkalom, amikor a cég kilát az ops mögül a nagyvilágra. Ha "szerencséjük van", akkor történik valami baj, amit nem a saját ops-uk old meg, és az új reménység, akit bevonnak, az nyitottabb, ügyesebb, fiatalosabb, stb. és előrébb viszi a céget ezen ideális állapot felé.

Ultra ritkán adódik valami alkalom, amikor a cég kilát az ops mögül a nagyvilágra.

Nekem amúgy az egyik fő bevételi forrásom az, hogy a KKV aljának segítek a migrációban, legyen az felhős és/vagy on-prem infra, ahol DevOps metodológia szerint újraépítjük a teljes infrát, minden egyes szolgáltatást átnézve, hogy hova illik jobban és ki lehet-e váltani valami meglévő szolgáltatással. Nagyon sok kis cég be van ragadva oda, hogy az IT rendszerei 10-20 éves történelmet húznak maguk után és már szó szerint nem mernek hozzányúlni, mert nem tudják, hogy miért van épp az úgy, ahogy. És sok esetben már rég elmúlt az a történelmi ok, ami miatt úgy maradt.

A fő elvem itt az, hogy az Ops egységesen kell ezt akarja, az Ops ellenében nem lehet ezt meglépni, mert ott akadályozzák, ahol csak tudják, szóval ilyen esetben nem vállalom a melót. Tipikusan volt régebben olyan, hogy betettük fájlba az infrát, és például mutattam, hogy itt át kell írni és akkor az ott újraindul, erre az egy Ops: "ezt akkor meg tudja csinálni a help-desk is, akkor rá mi szükség lesz?" és nem akart tanulni, ő éveken át azt csinálta, hogy ha jött egy HD ticket, hogy X rendszer beteg, akkor újraindította és ez volt a fő tevékenysége azon kívül, hogy OS-t upgradelt a százvalahány szerveren ciklikusan, amit szintén automatizáltunk a többi Ops örömére, mert ők akartak tanulni. A tanulni nem akaró certified reboot engineer meg keresett más állást magának pár hónap múlva.

https://iotguru.cloud

Amit leírtál itt a devops-ról, abban mi az dev?

Az, hogy a Dev és az Ops terület együtt dolgozik, lásd "DevOps is the combination of cultural philosophies, practices, and tools that increases an organization’s ability to deliver applications and services at high velocity: evolving and improving products at a faster pace than organizations using traditional software development and infrastructure management processes."

Mert ez sima ops az én szememben, az hogy használ toolokat mint kubernetes vagy ansible, attól még ops.

Igen. Viszont öncélúan saját maga szórakoztatására az Ops nem szokott ilyen eszközöket használni, csak akkor, ha nagyon sok változás megy keresztül a rendszeren üzemszerűen, ahhoz meg kell a Dev terület is.

https://iotguru.cloud

Szerintem nem.

Egyszerűen ha rendesen akarsz üzemeltetni, akkor kellenek tool-ok, amivel gyorsan és garantáltan jól és egységesen tudsz valamit csinálni. Lehet ez akár olyan kutyaközönséges dologról szó, mint egy ntp config kiküldése. Vagy nem is feltétlen módosítás, csak valami infó begyűjtése minden gépről. Ebben semmi dev nincs. Ugyanazt csinálom, amit mondjuk ssh-n csinálnék, csak nem direktben SSH-n.

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

Szerintem nem.

Hát pedig de... :D

Egyszerűen ha rendesen akarsz üzemeltetni, akkor kellenek tool-ok, amivel gyorsan és garantáltan jól és egységesen tudsz valamit csinálni.

Mi a célod ezzel a rendes üzemeltetéssel? Ha elkezded felfejteni, hogy mi a driver, akkor eljutsz oda, hogy a change a driver.

Ebben semmi dev nincs. Ugyanazt csinálom, amit mondjuk ssh-n csinálnék, csak nem direktben SSH-n.

Az még nem DevOps alapvetően, az még csak CMDB és Ops automatizálás, de ismét az a kérdés, hogy miért csinálod, mi a driver. Ha nincs change, akkor ezek nem fontosak. Ha van change, akkor az honnan jön?

https://iotguru.cloud

"Ha van change, akkor az honnan jön?"

Bárhonnan. Lehet hogy csak mi akarjuk, mint pl. az említett NTP váltás. Lehet más szoftverének üzemeltető vagy fejlesztő oldaláról van kérés, hogy mondjuk megadott php82-es modulok kerüljenek fel minden gépre...

Azért csinálom, mert gyorsabb, egyszerűbb vele, és garantáltan mindig az lesz az eredmény, amit szeretnék. Volt hogy pl. telefonáltak és kértek egy új local usert a szervereikre, mire letettük a telefont már kész volt. Kb. 15 gép volt, szóval nem sok, de így 1 perc alatt megvolt, amúgy meg min. 30 perc, mire bessh-zok mindenhova és kézzel megcsinálom a majommunkát. De ugye ennek az ereje, hogy ha 1500 gép lenne, akkor is 1 perc lenne így, egyébként meg gépenként 2 perc... 3000 perc.

De fontos akkor is, ha nincs sűrűn change, mert így máskor is tudok egy ugyanolyat csinálni, ugyanúgy. Legyen akár csak egy httpd telepítés és alap beállítás (ssl, cipherek, vhostok és webroot-ok előkészítése, stb). Egyszer megcsinálom, akkor mondjuk 2x annyi idő mintha csak simán "kézzel" megcsinálnám, de utána minimális módosítással, utóigazítással bármikor használható, és 0,1x annyi idő alatt megvagyok vele.

"Mi a célod ezzel a rendes üzemeltetéssel?"

A fent leírtak. Hogy gyorsan, hatékonyan és reprodukálhatóan tudjam ugyanazt elvégezni, ne tippelésből amire emlékszek, meg amit a másik gép bash historyra alapján ki tudok túrni. Ha kérnek két gépet/service-t akármit, hogy legyen "ugyanolyan", akkor így biztosan ugyanolyan lesz.

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

Még mindig az van, hogy nem írod le, ki és mi a driver, csak onnan követed a folyamatot, hogy hozzád eljut a feladat és azt hogy oldod meg. Amint rájössz, hogy a driver a Dev terület (a change onnan jön, akkor is, ha az egy  infra update), akkor megérted, hogy ezt miért hívják DevOps-nak akkor is, ha nem látod a Dev részét vagy nem érdekel a Dev része.

Lásd ezt példuál: https://content.wepik.com/statics/204949472/preview-page0.jpg

Nálatok ki a Plan-Code-Build-Test terület?

https://iotguru.cloud

Próbáld meg ezt a fejlesztő részt elengedni.

"magatok örömére üzemeltettek?"

Részben igen :)

Az ügyfél fizet azért, hogy a rendszert üzemeltessük, karbantartsuk. Ő azt kéri, hogy a rendszer működjön úgy, ahogy neki jó. Vagy azt kéri, hogy szeretne egy új szoftver használni, teremtsük meg ennek a működési feltételeit. Vagy upgradelné az ügyviteli rendszert, amihez kell +X GB RAM. Ehhez megkapjuk vagy leegyeztetjük a harmadik féllel az elvárásokat, meg hogy hogyan tovább.

Azt soha nem kéri, hogy lécci cseréljétek már le az NTP szervert, mert ez a mostani gyakran nem elérhető. Meg azt se, hogy tegyétek már rendbe az apache konfigokat, mert a mostani olyan átláthatatlan.

De mi is kérünk, amikor mondjuk 6 éve megy egy szerver és az OS is közeledik mondjuk az EOL-hez, hogy javasoljuk és tervezzenek be egy új szervert. Vagy cseréljünk switchet, mert sok éves és instabil kezd lenni.

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

Részben igen :)

Ha nem fizetne senki érte, akkor is? Kétlem.

Az ügyfél fizet azért, hogy a rendszert üzemeltessük, karbantartsuk.

Akkor megvan, hogy ki a Plan-Code-Build-Test.

Azt soha nem kéri, hogy lécci cseréljétek már le az NTP szervert, mert ez a mostani gyakran nem elérhető.

Nyilván magasabb szintű elvárásai vannak, de mégiscsak azért fizet.

és tervezzenek be egy új szervert

Látod? Ott a plan. Össze fogod tudni tenni, ha elkezded végiggondolni.

https://iotguru.cloud

De most akkor tisztázzuk már, hogy mit értesz dev alatt? Mert én azt hogy valaki programoz, kódol. Te meg szerintem ezek alapján infrastruktúra fejlesztést.

Dev az, ahol a plan - code - build - test közül valamelyik/mind van; Ops az, ahol a release - deploy - operate - monitoring közül valamelyik/mind van.

https://iotguru.cloud

Tehát akkor mégegyszer: mire érted a plan - code - build - test funkciókat

Tehát akkor mégegyszer: mindenre értendő, ami változást okoz, benne van az infrastruktúra változása is, lásd például ITIL-t ez ügyben.

Mert ha infrastruktúrára, akkor "devops" azóta létezik, amióta számítástechnika, csak nem volt rá ez a buzzword.

Akkor az agile is azóta létezik, amióta számítástechnika, csak nem volt rá ez a buzzword... jajj, dehogy létezik azóta, alapvetően az a helyzet, hogy ezek a dolgok jól definiáltak, ez és így nem volt korábban, akkor se, ha az egészből te 5-10 százaléknyi valamit használsz, főleg a rendszerszintű toolset-et önmagában, mert annyit sikerült az egészből megragadni és a lifecycle egészét nem látod és nem is akarod látni, nem beszélve az egészet keretbe foglaló metodológiáról...

https://iotguru.cloud

Egy applikacio akkor uzemeltetheto ertelmesen K8s kornyezetben, ha be vannak tartva a fejlesztes soran a cloud-native principle-ok (logolas, monitoringozhatosag, tracing, profiling, secret kezeles, skalazhatosag, caching, adatbazisok, resource limitek, stb.). Ezek mind Dev hataskor, mert az applikaciot ugy kell lefejleszteni vagy atirni.

( gelei v | 2024. 10. 31., cs – 11:35 )

Szerkesztve: 2024. 10. 31., cs – 11:36

Itt egész jól lehetne tippelni a kommentek alapján, hogy ki az, aki meg sem hallgatta, csak beírta, hogy "nem is halnak ki, ez hülyeség", viszont akkor már bedobnám ezt, lazán kapcsolódik: https://itkorkep2024.alerant.hu/devops-eredmenyek

A válaszolók harmada nem használ IaC eszközt, a fele nem használ konténerizációt, kétharmada nem csinál monitoring dashboardot, majdnem háromnegyedük nem futtat komplexebb teszteket a menedzselt infratruktúrán, a fele nem használ VCS (nincs semmi saját script, amit be lehetne dobni?), a fele nem vesz részt automatizálásban*, stb.

Azt nem tudom, hogy az ops, mint feladatkör ki fog-e halni, szerintem a belátható időn belül nem,

* szerk: közben a döntéshozók szerint mi a #1 prioritás? Az automatizálás. :)

Van aki abban látja biztos munkáját és pozícióját, hogy ezt csinálja.... De szerintem az automatizálás nem csak a döntéshozók körében prioritás, hanem minden normális ember esetében, aki nem akarja minden nap ugyanazokat a droid munkákat elvégezni.

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

az automatizalasban nem az a nagy dolog, hogy helyettem elvegzi a munkat, hanem hogy _hibamentesen_ tortennek a beallitasok: nemlesz az hogy valahol elszuszik egy netmask/ipcimben egy pont/kimarad egy karaketer/stbstb.

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

Az, hogy az infrastruktúra nincs automatizálva, az normális dolog, nem kell mindenáron konténerbe tenni, ami még nincs ott; az, hogy nincs értelmes monitoring és tesztelés, az sajnálatos, de valóban ez a helyzet.

Ami fő probléma, hogy itt DevOps alatt vélhetően platform engineer-t és/vagy cloud engineer-t értenek, de ennek fényében is különösen problémás, hogy a fejlesztők és üzemeltetők kevesebb mint 15 százaléka van bevonva a DevOps folyamatokba, holott a DevOps - mint olyan - arról szólna, hogy a Dev és az Ops szorosan együtt dolgozik (ahogy Agile esetén a Dev és a Business együtt dolgozik), ehelyett sok cégnél behoztak a két siló közé még egy silót, elnevezték úgy, hogy "DevOps" és csak rosszabb lett minden, mert a Dev és az Ops még annyit se beszél egymással, mint korábban...

https://iotguru.cloud

Az, hogy az infrastruktúra nincs automatizálva, az normális dolog

Nem azt mondtam, hogy az infrastruktúra miért nincs automatizálva, hanem hogy az üzemeltetők fele egyáltalán nem vesz részt automatizálásban.

nem kell mindenáron konténerbe tenni, ami még nincs ott

Még csak gondolat szintjén sem merült ez fel bennem. Automatizáció != konténerizáció.

itt DevOps alatt vélhetően platform engineer-t és/vagy cloud engineer-t értenek

Lehet, nem egyre gondolunk, de itt a DevOps az csak a kérdések egy adott csoportja, az eredmények ezen belül le vannak osztva háromfelé, szerepkörök szerint. Ebből az egyik az "infrastruktúra üzemeltető".

Nem azt mondtam, hogy az infrastruktúra miért nincs automatizálva, hanem hogy az üzemeltetők fele egyáltalán nem vesz részt automatizálásban.

Ez a kettő együtt jár tapasztalataim szerint.

Még csak gondolat szintjén sem merült ez fel bennem. Automatizáció != konténerizáció.

Sehol nem is írtam, hogy ez azonos lenne, csak reagáltam arra, amit írtál: "harmada nem használ IaC eszközt, a fele nem használ konténerizációt, kétharmada nem csinál monitoring dashboardot, majdnem háromnegyedük nem futtat komplexebb teszteket a menedzselt infratruktúrán, a fele nem használ VCS".

Lehet, nem egyre gondolunk, de itt a DevOps az csak a kérdések egy adott csoportja, az eredmények ezen belül le vannak osztva háromfelé, szerepkörök szerint. Ebből az egyik az "infrastruktúra üzemeltető".

Nem a kérdések csoporja, hanem három csoportot képeztek a válaszadók szerint: "DevOps mérnök", "infrastruktúra üzemeltető", "fejlesztő". És rögtön az első grafikon meg az, hogy a három terület hogyan van bevonva a DevOps tevékenységekbe... ez olyan, mintha a cégnél lenne egy "Agile" nevű csoport és az agilis működésbe nem lenne bevonva a fejlesztő és az üzlet.

https://iotguru.cloud

( n.balazs v | 2024. 11. 01., p – 16:05 )

Szerkesztve: 2024. 11. 01., p – 16:06

Nem hallgattam meg. A kommentek alapján sejtem, hogy mi lehetett a tartalma. Röviden: nettó butaság már maga a cím is.

1. Akinek / aminek a halálhírét keltik, az / ő általában sokáig fog élni.

2. Cégek tömegei panaszkodnak nekem, hogy nem találnak üzemeltetőt. Többnyire IT generalista szemléletű üzemeltetőt keresnek. Nincs. Aki meg van, ő elkéri a pénzét.

3. Az üzemeltetőknek fejlődniük kell, haladniuk kell a korral. Nincs ezzel semmi gond. Persze a megfelelő támogatás is kell az üzlet / tulajdonosok oldaláról. Ha ez nincs, akkor hiába a kitűzött cél. A mindennapi problémák megoldásán túl fókuszt kell helyezni a modernizációra. IaC, loggyűjtés és elemzés, application footprint csökkentése, automatizáció, IDM/IAM, security policy és hardening stb.

4. Bizonyos infra méret alatt teljesen felesleges csillagrombolót építeni. On-prem és cloud is. Nagyon sok kis cég / ügyfél teljesen jól elvan a már bevált megoldásokkal.

5. Ha nincs a cégben fejlesztő (dev), akkor nem nagyon beszélhetünk devops szisztémáról. Ott az üzemeltetés (ops) dominál. Persze ezt is lehet picit devopsosítani.

6. A céges IT csak költséghely vagy közvetlen bevételt generál? Teljesen másképp néz ki az IT működése.

"6. A céges IT csak költséghely vagy közvetlen bevételt generál? Teljesen másképp néz ki az IT működése."

Ez zöldség, hiába csak költséghely az IT, az első olyan leállás után amikor a bevételgeneráló részlegek nem tudnak munkát végezni (nincs email, eltűnik a központi fájlelérés, nem megy a számlázó vagy a raktárrendszer, stb.) onnantól kezdve rájön a vezetőség hogy az IT soha nem csak költséghely :)

Akkor is költséghely, ha nem az IT a cég fő tevékenysége, akkor az IT költség, ami akár kiszervezhető a cégből teljes egészében és akkor is költség marad. Amiről beszélsz, az teljesen más dimenzió.

Ha egy bolt nem tud kinyitni, mert elromlott a rács zárja, akkor a vezetőség rájön, hogy a rácsot karbantartó (cég) nem csak költség? Hanem mi?

https://iotguru.cloud