MOTD #1

Linux

( dotnetlinux | 2025. 05. 25., v – 10:10 )

Szerkesztve: 2025. 05. 25., v – 10:10

Please learn Programming before Desing plans

( dotnetlinux | 2025. 05. 25., v – 10:10 )

Please learn K8S before microservices

( ricsip v | 2025. 05. 25., v – 16:47 )

Mintha nem a DevSecOps lenne mostanság már az elvárt munkakör 1 fizetésért a nagyvíz túloldalán.

Erről egy-két álláshirdetés jut eszembe, amikor mindezt még junior állásnak is hirdetik. "Junior FullstackDevSecAiOpsQAScrumMasterProductOwner-t keresünk 10 év penetration tesztelés tapasztalattal, felhő környezetben, három nyelvvel, és rendszeres külföldi utazásra hajlandósággal." :)

( crypton | 2025. 05. 27., k – 06:15 )

Szerkesztve: 2025. 05. 27., k – 06:17

Idejében szólok a CV miatt: Dev*Ops már kiment a divatból. Platform Engineer az új irány ... :) :) ... Vagy MLOps. Vagy AIOps.

Régóta láttam már Site Reliability Engineer álláskiírásokat, csak a bullshit-eufémizmusdetektorom blokkolta. Ez a janitor modern megfelelője akarna lenni (gyk. karbantartós állás)? Komolyan kérdezem, mi a lótúrót takar egy SRE munkakör egy budapesti irodában?

Ez a janitor modern megfelelője akarna lenni (gyk. karbantartós állás)?

Nem, az kb. a rendszergazda vagy technikus munkakör.

Komolyan kérdezem, mi a lótúrót takar egy SRE munkakör egy budapesti irodában?

Az SRE az kb. a teteje az üzemeltető munkaköröknek, onnan már csak főnök lehetsz, tisztán remote meló, nem megy a szerverek közelébe, arra vannak droidok. Az SRE dolga, hogy egy nagy terhelésű rendszer megfelelően skálázódjon, megfelelő teljesítménye legyen, SLA szerint elérhető legyen, és a többi, leginkább folyamatautomatizálás a munka.

https://iotguru.cloud

Megkérdeztem ma erről MI barátunkat (ChatGPT):

Mi a különbség egy "platform engineer" és egy "site reliability engineer" között? Mit csinál az egyik és mit a másik? Mondj konkrét példákat is kérlek.

A Platform Engineer és a Site Reliability Engineer (SRE) szerepkörei gyakran átfednek, különösen modern DevOps-kultúrában, de a fókuszuk és céljaik eltérőek.

🔧 Platform Engineer

🎯 Fő cél:

Olyan belső fejlesztői platformot hoz létre és tart fenn, amely megkönnyíti az alkalmazásfejlesztők munkáját. Ők az „enablement” mérnökök: az infrastruktúrát, CI/CD-t, belső toolingot szabványosítják és automatizálják.

🧩 Tipikus feladatok:

  • Belső fejlesztői platform kialakítása (pl. Backstage, Internal Developer Portal)

  • CI/CD pipeline-ek létrehozása és karbantartása (pl. GitHub Actions, GitLab, ArgoCD)

  • Kubernetes platform építése (multi-tenant, namespace policy, admission controller-ek)

  • Infrastructure-as-Code eszközök használata (pl. Terraform, Pulumi)

  • Közös sablonok készítése mikroszolgáltatásokhoz (Dockerfile, Helm chart stb.)

✅ Példák:

  • Létrehoz egy automatizált Terraform pipeline-t, amivel a fejlesztők self-service módon deploy-olhatnak új környezeteket.

  • Bevezet egy belső dashboardot, ahol a fejlesztők egy gombnyomással deploy-olhatnak staging környezetbe.

🛡️ Site Reliability Engineer (SRE)

🎯 Fő cél:

Üzemeltethetőség, megbízhatóság, teljesítmény és skálázhatóság biztosítása. Az SRE a fejlesztés és üzemeltetés között helyezkedik el, erősen mérőszám-alapú.

🧩 Tipikus feladatok:

  • SLI/SLO/SLA-k bevezetése és monitorozása

  • Incidenskezelés és root cause analysis (RCA) végzése

  • Monitoring és alerting (pl. Prometheus, Grafana, Datadog)

  • Készenléti ügyelet (on-call) és operációs automatizálás

  • Chaos engineering, stressztesztelés

✅ Példák:

  • Beállít egy alertet, ami figyelmeztet, ha az API átlagos válaszideje 2 másodperc fölé nő 5 percen belül.

  • Automatizálja a rollback folyamatot, ha a deployment hibákat okoz a production környezetben.

  • Megvizsgálja egy rendszerösszeomlás okait (RCA), majd elkészíti az utólagos jelentést, és bevezet megelőző intézkedéseket.

🆚 Összehasonlító táblázat

Jellemző Platform Engineer Site Reliability Engineer (SRE)
Fókusz Eszközök és platform fejlesztőknek Rendszer megbízhatóság és üzemelés
Kulcsterület Automatizált infrastruktúra Monitorozás, üzemeltethetőség
Metrika Developer velocity, deployment time Availability, error rate, latency
Eszközök Terraform, Helm, Jenkins, ArgoCD Prometheus, Grafana, PagerDuty
Stakeholder Fejlesztők Üzemeltetés, üzleti szolgáltatások
Példa Self-service deployment rendszer Automatikus alerting és incident flow

🤝 Kapcsolatuk

  • A Platform Engineer gyakran építi ki azt az eszköz- és szolgáltatáskészletet, amivel az SRE később megbízhatóan tudja monitorozni, skálázni és működtetni az alkalmazásokat.

  • Együtt dolgoznak azon, hogy a deploymentek megbízhatóak, gyorsak és biztonságosak legyenek.

Nem új irány, csak a cégek időnként mást értenek DevOps alatt, van, ahol Platform Engineer-t, van, ahol Site Reliability Engineer-t, van, ahol ún. Developer Experience Engineer-t.

A DevOps alapvetően egy filozófia, mint az Agile, most kezdünk visszatérni ide, hogy ezt felismerték és azt is, hogy a PE, a SRE és a DEE nem cserélhető fel egymással.

https://iotguru.cloud

Jobb kesobb mint soha. Lassan 25 ev tapasztalattal mondom h marhara tele volt a hocipom ezzel a devops szakember cimu dumaval. 
Hosszasan lehetne ertekezni ennek a jelensegnek a miertjerol stb, de alapvetoen jo az az irany h kezd egy kicsit visszamenni mindenki a maga helyere. Hogy ezt milyen bullshit title-okkel jelezzuk, az mar mindegy is. 

Ahol így keresnek hogy "devops" ott általában a kiíró nem ért hozzá és/vagy nem érdekli. 
Ha van hozzá türelmed ki lehet szépen szedni belőlük hogy nagyjából miről van szó.
Már persze ha az egyebek miatt érdekes "a hely". 

Ha nem érdekes akkor úgy járnak hogy jelentkező sincs, és akkor (az ignoráns managernek) úgy tűnik hogy "elfogytak a szakemberek".
Valójában a szakember nem fogyott el, csak a türelem a hülyékhez. :)

zászló, zászló, szív

Hosszasan lehetne ertekezni ennek a jelensegnek a miertjerol stb, de alapvetoen jo az az irany h kezd egy kicsit visszamenni mindenki a maga helyere.

Az a rossz irány, hogy "mindenki megy vissza a helyére". A DevOps alapvetően arról szól, hogy a fejlesztés és üzemeltetés nem két külön cég a cégen belül, amelyek között egy issue tracker és email a kapcsolat, hanem szomszédos asztalnál ülnek és közös felelősségük van abban, hogy az adott rendszer értéket teremt a felhasználóinak.

https://iotguru.cloud

Félreértesz. Arra gondolok a "mindenki a maga helyére" h. kezdi végre nem feltételezni a business oldal, hogy a DevOps egy szakember és meg lehet spórolni a fejlesztő és üzemeltető emberek alkalmazását. Mint filozófia tudok azonosulni vele, mert teljesen valid hogy a környezet és maga az alkalmazás egymás nélkül semmit sem érnek, plusz a szakembergárda minél integráltabb, annál jobb lesz a termék. De az, hogy DevOps szakembernek hívjuk a Kubernetes szakértőtől a Java fejlesztőig aki látott már Compose fájlt, lassan a takarítónőig az összes embert aki "modern" IT környezetben tevékenykedik, na az butaság.

Így kifejtve talán érted és talán kb. egy platformon vagyunk. Én pl. sosem leszek olyan jó fejlesztő, mint aki 20 éve csinálja, de valszeg egy Java-s (Go-s, whatever) szaki se lesz olyan üzemeltető, mint az aki 20+ éve foglalkozik ezzel. Viszont az is tök valid h. nagyon nem a 20+ éve felszedett tudást használom, csak olykor jól jön (igen, még Kubernetes mellett is :) )

Mindannyian lassulunk, ezt te sem tagadhatod :)

Ugyanakkor a lassulas nalam inkabb azt jelenti ha kicsit megprobalom tavolabbrol nezni, hogy meg mindig nyitott vagyok az ujra, de sokkal jobban, sokkal tobb aspektus alapjan meggondolom az alkalmazasat. 
 

Azzal a fajta gondolkodasmoddal viszont meg mindig tudok azonosulni h dontsunk, menjunk valamerre. Max korrigalunk ha nem jo iranyba dontottunk. Az egy helyben toporgas, a valtozastol valo felelem a problema. Az alapossag, a tapasztalatbol talan egyszer kihajto “bolcsesseg” meg senkinek sem valt karara. 

Aztán miért? Mert most éppen nem apt-get install-lal, hanem egy docker-compose-zal telepítek fel egy kibaszott app-ot, akkor már menő vagyok?

Ja, éppen azzal telepítettem fel a múlt héten, kérek is gyorsan egy devops névjegykártyát. Igaz, hogy a devops-ok (LOL) nagy része 10-ed annyit nem ért a Linuxhoz (se), mint én, de sebaj :D :D :D

trey @ gépház

Devops szakember mindig is volt, akkor is, amikor nem volt ilyen neve. Nem tudom, hogy programozással vagy üzemeltetéssel foglalkoztok, de aki programozással, az tudja, hogy szépen meg kellett ugyanugy csinálni mindent régen is, amit most "devops"-os sapkában megnyertél, mint feladatot. Most van olyan, hogy a "devops"-os, régen a random fejlesztő váltogatta a sapkákat, attól függ, hogy mi volt a feladat éppen. Sőt a mai nap is, egy bizonyos szint felett, mint fejlesztő teljesen tisztában kell lenned a devops feladatokról, eszközeiről, stb...