DevOps mint karrier

Fórumok

Üdv,

a kérdés röviden az, hogy ki hogyan látja a DevOps karrier jövőjét, mondjuk néhány éves távlatban? Létezik senior DevOps? Vagy DevOps Architect? Vagy mi lesz egy DevOpsossal ha kiég? Elmegy tesztelni?
Nem dolgozom DevOps környezetben ezért csak arra hagyatkozom amit ismerősöktől megtudtam ill. a neten találtam.
Jelenleg egy eléggé felkapott kifejezés ami ugyanakkor nem igazán határolható körül. Cégenként változik, hogy milyen elvárások vannak. Van ahol kell 0-24 supportot adni, van ahol nem. Van ahol az AWS/Azure elvárás, van ahol hallani sem akarnak róla. Ugyanígy az elvárt toolok, keretrendszerek, adatbázisok, programnyelvek stb. cégenként változnak. Már-már annyira megfoghatatlan valami mint az ha azt mondjuk valakire, hogy informatikus.
Persze long life learning meg hasonlók, de minden munkahely váltással az addig megszerzett tapasztalat egy részét kukázni, mert ott más eszközöket "szeretnek"? Persze, a DevOps gondolkodás mód ettől még lehet ugyanaz...
Hogyan látjátok ezt a témakört? Milyen jövőt jósoltok?

Hozzászólások

Klasszikus rendszergazda egyre kevésbé fog kelleni, áttevődik a hangsúly a devopsra, ha valaki nem programozó akkor ebben van a jövő.
Abszolút létezik belőle senior és architect szint, rengeteget lehet (és kell) folyamatosan tanulni.

Ha kiég akkor még mindig simán lehet tanácsadó, tanár, menedzser, akármi.
--
Gábriel Ákos

A klasszikus rendszergazda terület pedig tényleg múlik el. Az ott végzett emberi munka egy része feleslegessé vált (megbízhatóbbak a számítógépek, mint korábban), egy másik része kreatív problémamegoldásból betanított munkává vált, egy harmadik része pedig automatizálásra került. Evvan.

Legtobb ceg osszemossa a (senior) sysadmin, site reliability engineer es a devops megnevezeseket/munkakoroket. (Illetve nehanyan szandekosan csinaljak, merthogy trendi.)

Ha most kizarolagosan* nezzuk a munkakoroket, a devopsnak mindenkepp "fenyes" jovoje van, az SRE az mar mas kerdes (lasd pl Amazon Lambda), a sysadmin keresettsege pedig szerintem is fakulni fog. Mas kerdes, hogy a felhoben is kell azert uzemeltetni (meg ha maskepp is), tehat akar egy nem senior sysadm is eleg sok melot le tud(na) venni a devops vallarol.

* szvsz a jo sysadmin regen is 'tudta', hogy milyen kodot uzemeltet; aztan pl ha megborult a kod, tudott segiteni, hogy merre induljon el a fejleszto (esetleg meg o maga is kijavitotta azt a ket sort). Nem tartom igazan indokoltnak tehat ezeknek a munkakoroknek a szigoru szeparaciojat, mert olyan visszas dolgokhoz tud vezetni, hogy pl sok ceg szo szerint csak devops-ot akar felvenni, holott egy ertelmes sysadmin/SRE kellene nekik inkabb.

http://karikasostor.hu - Az autentikus zajforrás.

++1 Ezt irtam le egyszerusitve.

Amikor tetszett a fonoknek es kiirtak a poziciot es mint kiderult mogotte devops kell a kollegaknak laptopot telepiteni es remote helpdesket nyujtani meg weboldalt frissiteni.
Plusz amit a fonok ker.

Fejleszto kollegak idonkent neztek is, amikor elkuldtem nekik egy egyszeru javitasi javaslatot es nem ertettek, hogy miert vagyok "csak" rendszergazda. Tudni valamit es alkalmazni, vagy szeretni csinalni az nem ugyan az.

http://karikasostor.hu - Az autentikus zajforrás.

Elvileg alairaskent szerepel, de miert teszi elso sorba hozzaszolas iraskor az kerdes ami kulonosebben nem is erdekel.
Majd a fejleszto megoldja, hogy alairas, az alairas legyen es nem fole.

En turelmes vagyok es kivarom.

Nektek meg baromi sivar es ingerszegeny eletetek lehet, hogy ha ez a legidegesitobb problematok. wink wink

Érdekes, hogy nekem végig az alján van. Szóval talán neked kellene megoldanod. Nem baromi sivár és ingerszegény az életünk, hanem tök zavaró, amit csinálsz.

-----
„Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben.”
rand() a lelke mindennek! :)
Szerinted…

Személyeskedésen kívül témához valami? Én is tudnék személyeskedni, hogy az meg egy szegénységi bizonyítvány, hogy képtelen vagy megérteni, hogy hogy működik egy textbox és a drupal aláírás "rendszere".

Kurva idegesítő, hogy azt várom egy hozzászólás esetén, hogy a tartalom jön (mint ahogy a kommentek 99,9%-a kezdődik) és helyette egy irreleváns spamet kapok. Mondom ezt úgy, hogy egyébként megnéztem már az oldalt, mert érdekelt. De ez nem jelenti azt, hogy minden egyes alkalommal azon akarok gondolkodni, hogy most ez tartalom-e vagy csak spam.

Harmadrészt, én se teszek be minden hozzászólásomba egy pásztorfurulyás gyűjtés linkjét, bármennyire is érdekel a téma.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Must:
• 4-5 years of hands on experience within the ALM lifecycle
• Familiarity with Java/.NET – must
• Familiarity with cloud technologies(Azure/AWS/GCE) – must
• Familiarity with SQL server and NoSQL – must
• Familiarity with Linux and Windows server management
• CEP knowledge - must
• Strong experience Docker – must
• A working understanding of code and bash scripting – must
• Experience with Jenkins

Advantages:
• Experience with JavaScript
• Experience working with Puppet/Chef or similar
• Military technology units alumni
• ELK stack – advantage
• Experience with Container Orchestration (Kubernetes, Swarm).

Dehogy senior developer. "Familiarity with Java/.NET" vagy "Familiarity with SQL server and NoSQL" a kontextusban (es a "familiarity" szo miatt onmagaban is) nem azt jelenti, hogy melyen ismeri a Java/.net ecosystemet es be lehet fogni fejlesztokent a termek csiszolgatasaba, hanem van komoly ralatasa ilyen alkalmazasok uzemeltetesebe. Hasonloan, nem ot fogjak megbizni SQL queryk tuningolasaval, de latott mar mukodo RDBMS-t es NoSQL db-t, erti, hogy altalaban miben mas a ketto, milyen feladatokra melyik jobb, stb. Ugyancsak a fentieket tamasztja ala a "working understanding of code", azaz, kurvara nem ot fogjak odarakni Java-ban bugot fixelni...

----------------------
"ONE OF THESE DAYS I'M GOING TO CUT YOU INTO LITTLE PIECES!!!$E$%#$#%^*^"
--> YouTube csatornám

Igazából azon szoktam meglepődni, hogy miért lepődnek meg emberek, hogy - főleg egy senior pozinál - igény van arra, hogy a szűk kis környezetén túl legyen már rálátása legalább alapszinten a környezetére, a stackra amin dolgozik. Számomra tök evidens, hogy ahhoz, hogy jól végezhessem a dolgom, ahhoz az is kell, hogy ne toljak ki a szomszéd területekkel.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

ugyugy.... business transparency, legalabb lassam a rovid- es kozeptavu terveket, melyik team min dolgozik, mik a requirementek, prioritasok - business szinetn - ... and so on, and so on...

hogy amikor a dev elkeffent valamit, akkor ne engem verjen fel a monitoring meg az L1/L2 hanem fejlesztot...

"az SRE az mar mas kerdes" en azt hittem, hogy ez most van feltorekvoben, mert nem eleg evente 2x meghatarozni a goalokat, kiszamolni a szerver kapacitast, aztan betolni meg 2 vasat, ha megsem eleg, hanem napi szinten valtozik a release az uzleti modell, a felhasznaloszam, es ugy minden. Ezert mar nem csak az oriasok alkalmaznak SRE-t, hanem egyre kissebb es kissebb szervezetek is raulnek a hullamvasutra, es kenyszerulnek felvenni valakit, aki felugyeli, hogy az alkalmazas hozza a szamokat, es segitsen minimalizalni a kockazatot meg a karokat.

"(lasd pl Amazon Lambda)" na ezt meg a vilag egyik atveresenek tartom :D Gyere hasznalj Lambdat, csak azert fizetsz, amikor fut, csak kuldj be egy marek scriptet. Aztan meg jon a "jah ezt nem lehet megoldani Lambdaval, vagy csak ver izzadas aran, meg kakast is kell aldozni" resz. Akkor maradunk a lambdaknal, mert az olcso ugye, de ezt a bizonyos rest kiszervezzuk... de hova is lenne erdemes, hat nyilvan a Lambdahoz legkozelebb, meg mar amugy is S3-at hasznalunk :D :D Es maris azon kapja magat az ember, hogy telepitgeti a gepeket, vagy irja a alkalmazas/container leirot. A lambda a kapudrog a vendor lockinghoz

-
Advanced testing of Golang applications

http://karikasostor.hu - Az autentikus zajforrás.

Elsokent tisztazni es standardizalni kellene, hogy ezen a fancy kifejezesen mit ertunk...

Jelenleg 5 helyen 8 felet ertenek alatta.

Leszögezném, hogy ebben a témában kívülálló vagyok, szóval távolról nézem a dolgokat és a következőket látom.
Régi sysadmin kb azt jelentette a cégeknél, hogy van pár server azt kell üzemeltetni, beállítani a webservert, levelezést...stb. Aztán ez elkezdett bővülni. Jó sysadminok írogattak scripteket, hogy megkönyítsék a saját életüket...stb. Bejött az, hogy felhőbe is lehet kiszervezni a feladatokat, sok adattal kell dolgozni, nagy lett a terhelés, párhuzamosítás, clusterben való gondolkozás, saját cuccok kellettek amikkel ezeket lehetett kezelni, mert még nem volt kiforrott dolog. Gondolom itt jött az, hogy kellett olyan ember aki ezt megírta, akinek kellettek fejlesztői és sysadmin skillek is. Ennek adtak egy nevet. Azért van annyi tool meg minden, mert ez teljesen adhoc, hogy adott cégnél mit csinálnak. Olyannak tűnik a probléma mint a "fejlesztő", amit sokmindent takarhat. Szerintem ha architektúra irányából közelítesz és nem a toolok irányából akkor beljebb leszel. Ha tudod mit kell csinálni akkor új szintaktikát nem nehéz tanulni, ezért nem fogod kukázni a teljes tudásodat, inkább csak hozzátanulsz. Persze lehet teljesen rosszúl látom a dolgot, de nekem ez jön le a dolgokból. Majd a többiek szépen kijavítanak, és összeáll majd az amit szeretnél.

Igazából ez a devops irány szerintem érdekes irányba fog elmenni, ahol BigData, Machine Learning és üzemeltetési dolgok lesznek jópár év múlva. Erről ti mit gondoltók?

Persze ehhez a látásmódhoz hozzátartozik az alapigazság, hogy asztalosnak minden kalapács effektus, én mivel matematikával és alkalmazásaival foglakozok az informatikán belül, nekem minden matek alapú, de azért próbáltam elvonatkoztatni, inkább kevesebb mint több sikerrel. :D

Teljesen jol latod a dolgokat.

DevOps gy IT uzemeltetesi strategia, amelyhez szukseg van:
* megfelelo mennyisegu eroforrasokra - altalaban itt jon kepbe a cloud
* vilagos uzleti celokra - amit vegso soron tamogatni kell es hogy a vallalati projektekbe a legelejen be legyenek vonva
* core business/iparag megertese - tudja, hogy mit es hogyan kell szolgaltatni, tudja hogy az adott iparag ahol piacra lep az hogy mukodik
* jol kepzett szakemberekre - akar es kepes is fejlodni, tudasat megosztja (dokumental es mentoral)
* olyan vallalati kulturara - amely biztositja a folyamatos kepzest, gyarkorlast, kutatast
* megfelelo infrastrukturara - amely kiszolgalja az uzleti celokat illetve lathatova teszi a benne zajlo folyamatokat (monitorozas, naplozas, metrikak gyujtese, pro-aktiv hibajelzes, stb)
* vezetoi elkotelezettsegre - ertik mit es miert csinalnak az uzemelteto kollegak, eloteremtik a penzt, paripat es fegyvereket

Minden vallalatnak (kivetel a monopoliumoknak) vannak versenytarsai, es ahhoz, hogy legalabb az IT versenyben fel tudja venni a versenyt konkurenciaval, esetleg meg nyerje, vagy akar maga tudja diktalni a versenyt, ahhoz kell a DevOps, mert mindezeket automatizalva nyujtja, illetve a budzsebol es a vallalati celokbol a leheto legnagyobb controlt biztositja az altala menedzselt eroforrasok felett.

Summazva a dolgokat DevOps a HA, QA es security integralasa az automatizalt folyamatokba (CI/CD pipelines). Az hogy mibol mennyi kerul bele azt szinten az uzleti celok hatarozzak meg. Szoval ez automatizalt adaptacio es integracio.

Igazából ez a devops irány szerintem érdekes irányba fog elmenni, ahol BigData, Machine Learning és üzemeltetési dolgok lesznek jópár év múlva.

Nagy es gyorsan valtozo infrastrukturakban rengeteg az uzemelteteshez kapcsolodo adat (monitorozas, naplozas, metrikak) keletkezik, elobb vagy utobb ezekkel kell valamit kezdeni, illetve egyre gyorsabban kell majd feldolgozni illetve elemezni, ezert van es lesz szukseg AI, Machine Learning, Big Data hasznalatara.
DevOps vagy egyebb magas foku automatizalast biztosito uzemeletetes nelkul nincs esely ezek hasznalatara.

Nagy es gyorsan valtozo infrastrukturakban rengeteg az uzemelteteshez kapcsolodo adat (monitorozas, naplozas, metrikak) keletkezik, elobb vagy utobb ezekkel kell valamit kezdeni, illetve egyre gyorsabban kell majd feldolgozni illetve elemezni, ezert van es lesz szukseg AI, Machine Learning, Big Data hasznalatara.
DevOps vagy egyebb magas foku automatizalast biztosito uzemeletetes nelkul nincs esely ezek hasznalatara.

Ilyesmire gondoltam. Mondjuk olyanra, hogy azokat a paramétereket amiket figyelnek, bedobnak egy CMDS algoritmusba, ami távolság arány tartók, ezért a sokdimenziós adatokból könnyű vizualizálni akár 3d-ben, hogy az esetek mihez vannak közel. Mondjuk meg van határozva egy kör, ami jó, meg az ami probléma. Ha azt látja, hogy elkezd a rendszere menni a rossz irányba akkor be tud időben avatkozni. Ennek a megvalósítása kb 10 sor R-ben vagy Julia-ban. Vagy akár lehetne valami paraméter állítgatást rábízni valami machine learning cuccra. Vagy akár egyébb adaptív szabályozót használni. Ehhez kell egy nem gyenge matematikai tudás, valamint egy nagyon jó rendszerismeret, mind hardware mind software oldalon, de ez már messze vezet.

"Devops engineer" pozícióban dolgozom 3 éve. Előző munkámban "software engineer" néven futottam, mint fejlesztő.

A személyes véleményem az, hogy a "devops" egy buzzword, amit cége válogatja, hogy éppen milyen pozícióra aggatnak rá. Projektenként változik, hogy éppen felhőben futó backend alkalmazáson és az alatta lévő cloud infrastruktúrán dolgozom, vagy éppen jelenleg egy nagy látogatottságú website AWS infrastruktúráján, a hozzá tartozó toolingon, kisebb backend szolgáltatásokon és a fejlesztők támogatásán.

Nem tudom, hogy ebből mi a tanulság, vagy egyáltalán van-e. Szeretem csinálni.

Én így látom most

Egy devops
Tisztában van a CI/CD assembly line elemeivel. Mindenről tudja mire való. Van amiben jobb de képes bármely elemeket összeintegrálni.

Képben van Cloud (Privát és public cloud) technológiákkal. Hasonlóképpen az előzőekhez van egy preferáltabb megoldása (Pl AWS) de elboldogul a többiben is.

Sztem egy devops inkább gyors script nyelvekben legyen jó pl Python vagy Ruby.

Nagy jövőt látok a contract (vándor devops) dologban. Kb 1 év alatt minden cégnél össze lehet lőni a CI/CD-t és a Cloud környezetet. Kitanitani egy embert aki maintaineli és utána max órabéres vagy projekt alapú supportot nyújtani

Kicsit kiegeszitenem a dolgot, ugyanis nem eleg az alkalmazast uzemeltetni, es az automatizacion vegigvezetve kitenni a szerverre. Az alkalmazasnak is uzemeltethetonek kell lennie. Itt jon a kepbe, amit sokan kifelejtenek, hogy nem eleg valami script nyelvben kalapalni, vagy infrastructure as a code buveszkedni. Tamogani kell a szoftverfejleszto csapatot, hogy legyen HA, meg self healing, failure detection, meg elosztott mukodes, meg ertelmes loging, tracing, audit, netan authentikacio/authorizacio, monitoring, stb.
Ezeket nem lehet utolag hozzatenni vagy legalabbis rohadt nagy szivas. Ezert kell ismerni azt a platformot, amiben az alkalmazas keszul, es magat az alkalmazast is (kod szinten). Ezert tori meg a hagyomanyos mi fejlesztunk ti uzemeltettek a vegen meg mutogatunk egymasra modellt. Mert reszt vesz a projekt fejleszteseben, tervezeseben, birtokol bizonyos reszeket az alkalmazason belul, tehat nem a committol kiseri vegig az appot az eletciklusan, hanem mar a terezestol. Egy fejlesztonek lovese sincs, hogy milyen metrikakat kell latni a dashboardon ahhoz, hogy megjosoljuk, hogy az alkalmazas varhatoan 20 percen belul osszeomlik. Tapasztalatom szerint arrol sincs lovesuk, hogy mit hogyan kell loggolni, mert mig az uzemelteto 0 error ratettel szeret dolgozni, addig a fejleszto betolja error szinten a user input validaciot. Esnagyon-nagyon hosszu a lista.

-
Advanced testing of Golang applications

Inkább azon múlik, hogy hol logolod a hibát. Ha van egy backend, ami kap egy hibás kérést, akkor nem hanyattvágja magát és errorozik a logban, hanem egy rendes hibakódot küld vissza, majd a hívó vagy logolja, hogy baj van, vagy még visszább passzolja a labdát. Ha a júzer valamit rosszul írt be, akkor a böngészőben kell egy piros üzenetet renderelni, szerveren még warningot se írnék ki, business as usual. Egy hibát kár ott kiírni, ahol nem actionable. Ez RPC rétegen át is ugyanúgy igaz, mint processzen belül.

Ha a júzer valamit rosszul írt be, akkor a böngészőben kell egy piros üzenetet renderelni, szerveren még warningot se írnék ki, business as usual.

-1. Egy csomo fejfajast meg lehet elozni, ha az ember latja szerveroldalon, hogy mit cseszett el a user...

--
"dolgozni mar reg nem akarok" - HZuid_7086 'iddqd' zoli berserk mode-ba kapcsol

Meg jobb, ha nem is zaklatjuk a szervert veletlen hibakkal, hanem mar a kliens oldal lefedi a legtobb PEBKAC esetet...
Persze ettol meg ott van a mindenfele egyeb, akar szandekos probalkozas, amelyeket a szervernek le kell kezelnie. Ezeket mondjuk tipikusan beirnam valami logba. A nagyon gyanus esemenyekrol akar meg alarmot (plusz ugye megfelelo operating instrucion) is tolnek az operator arcaba.

Most megint sokan fel fognak hördülni, de tapasztalatom szerint a nagyobb cégeknél a DevOps azt jelenti, hogy a fejlesztő az üzemeltető és tesztelő is egy személyben, amit csinál, azt kitolják 1,2,n környezeten át az éles szerverekig és a fejlesztő az ügyeletes, ha valami basz van, akkor őt keltik fel. És a DevOps munkakörben nem azt látják, hogy a csapatban van cross-competency, hanem azt, hogy felvesznek egy szerencsétlen ördögöt és ki tudnak rúgni három másikat.

Más cégeknél a DevOps keveredik a full-stack developer munkakörrel, amikor olyan szerencsétlen ördögöt keresnek, aki nemhogy üzemeltet, tesztel és fejleszt, hanem emellett mindenhez is ért. Mindezt persze nem túl sok fizetésért, mert pénz az nincs sok. Legalábbis a munkabérre.

Szerintem meg a DevOps nem egy munkakör, hanem egy csapatfilozófia, amikor a fejlesztő, a tesztelő és az üzemeltető nem kizárólagosan csak a saját érdekeit nézi, hanem képes megérteni, hogy minden területnek vannak szopásai és vannak problémái, amit egymásnak okoznak.

A fejlesztő, ha valamit lefejleszt, akkor az nem úgy megy, hogy
- pénteken átadja a csomagot az üzemeltetésnek, hogy tegyék élesbe, aztán telefont kikapcsolva elmegy két hét szabadságra.
- majd aláteszik a világ minden vasát, aztán ha úgy sem megy, akkor megnézi jobban, hogy mit lehetne jobban csinálni.
- ha valami nem működik, akkor majd az üzemeltető megoldja és akkor foglalkozik a problémával, ha szépen körülírt ticket van róla.
- szó nélkül átadja tesztelésre a félkész szart, hogy időt nyerjen kávézni, amíg a tesztelő szív.

A tesztelő, ha valamit tesztel, akkor az nem úgy megy, hogy
- szó nélkül visszadobja, hogy nem jó a feature.
- van egy kódminőség mérő szoftver, aminél 80 pontot kell elérnie minden csomagnak.
- a tesztkörnyezet több terhelést bír, mint az éles környezet.

Az üzemeltető, ha valamit csinál, akkor
- arról érdemes szólnia a fejlesztőknek és a tesztelőknek is, meg a többi üzemeltetőnek.
- ha valahol szűk keresztmetszetet lát, akkor ezt beszélje meg a fejlesztőkkel is.
- ismernie kell az üzemeltetett szoftvert, nem elég az, hogy Certified Reboot Engineer.
- a terhelt és forgalmas rendszer a jó rendszer, ha nincs terhelés, nincs bevétel se.

Ez a DevOps kultúra remekül működik ott, ahol egy szobában van a fejlesztő, a tesztelő és az üzemeltető és látják, hogy a másiknál mennyi a pillanatnyi WTF/óra. És amint valakinél ez jelentősen növekszik, akkor van annyi kompetenciájuk a másik területét tekintve, hogy megpróbálnak segíteni... és amikor dolgoznak, akkor van annyi kompetenciájuk a másik területet tekintve, hogy nem szopatják meg direkt a többieket... nem az a kultúra, hogy "had szopjon, köcsög üzemeltető, múltkor is megszopatott, most törlesztek", hanem egy a csapat.

"
Ez a DevOps kultúra remekül működik ott, ahol egy szobában van a fejlesztő, a tesztelő és az üzemeltető és látják, hogy a másiknál mennyi a pillanatnyi WTF/óra. És amint valakinél ez jelentősen növekszik, akkor van annyi kompetenciájuk a másik területét tekintve, hogy megpróbálnak segíteni... és amikor dolgoznak, akkor van annyi kompetenciájuk a másik területet tekintve, hogy nem szopatják meg direkt a többieket... nem az a kultúra, hogy "had szopjon, köcsög üzemeltető, múltkor is megszopatott, most törlesztek", hanem egy a csapat.
"
+1

Ott a pont. Felveheted a világ legjobb devops engineer-jét, ha a csapatkultúra nem kompatibilis ezzel a szemlélettel. Persze kell(het) aki nevesített devops szaki és a tooling integrációért felel, de azért jobb, ha ez mint elosztott tudás ott van a csapatban, akik mind az adott szolgáltatás külső vagy belső minőségéért, egy irányban húznak. Egy jó devops tipikus példája az "együtt sírunk, együtt nevetünk"-nek.

"Persze kell(het) aki nevesített devops szaki és a tooling integrációért felel"

Ó, el is felejtettem... ez is a halálom, amikor a DevOps azt jelenti a cégnél, hogy eteti és ganézza a lusta fejlesztőket.

Bocsánat, de lófaszt, ez is közös feladat kellene legyen, hogy éppen mi a konkrét divatos eszközkészlet a "Continuous *" buzzword-ök mögött, és persze tanulja meg mindegyik fejlesztő, hogy mennyi munka kiganézni naponta azt a környezetet, amin dolgozik. A világ legegyszerűbb dolga hátradőlni, hogy "ó, nem tudok most dolgozni, mert nincs környezetem". Ha odamegy egy "DevOps" ilyen munkakörrel, akkor még jobban elkényelmesednek a fejlesztők és az üzemeltetők.

Ideális világban igazad lenne, de ezek eltérő munkakörök, más múltat igényelnek. Vannak baromi jó infrás tudású fejlesztők, de mint a fehér holló. Aki meg csak műkedvelő, arra nem bíznám a produktív környezet tervezését, arra jobb az üzemeltetésen felnőtt devops mérnök. Kettejük érdemi szakmai vitája adja a végeredményt,amiért mindketten felelnek.

Ez a DevOps kultúra remekül működik ott, ahol egy szobában van a fejlesztő, a tesztelő és az üzemeltető és látják, hogy a másiknál mennyi a pillanatnyi WTF/óra.

Tehát egy kis (garázs) cégnél akár működhet is?
Amint ebből a méretből kinőnek, kezd majd kialakulni, hogy a fejlesztők külön irodában -> épületben -> országban dolgoznak majd...

Aztán ahogy nő az üzemeltetés, kialakul majd hogy elkerülhetetlen a level 1, 2, 3 support különválasztása is. Mert a 10+ év tapasztalattal rednelkező üzemeltető vagy (devops) nem fog tudni/akarni 7x24-ben folyamatos felügyeletet biztosítani a szerverekre. A cég meg inkább kifizeti ugyan azt a bért 3-4 kezdőnek inkább: win-win.

De kell majd olyan is, aki a kezdőket betanítja, mert bizony egy új ember legalább 2 már ott dolgozó tapasztalt kollega idejét fogja igényelni (minimum) a betanulás idejére...

Aztán kell majd külön tesztelő is, mert a fejlesztő szerint kész, az üzemeltető szerint meg nem megy fel a szar az éles szerverre, és a security csapat is beleszőlt ebbe-abba. És még nem említettük a szabványok miatti "segregation of duty" megfelelőségeket sem...

Aztán kell majd olyan emberekből álló csapat is, aki érti a fejlesztők nyelvét is, meg az üzemeltetőket is, sőt a managerekkel is tud beszélni, és talán még a security csapathoz sem fél bemenni néha, és össze tudja koordinálni ezen csapatok munkáját a managerek (az ügyfelek) elvárásaival.

Ezek "fölé" kell majd architect is, aki komplett új projekteket tervez meg nagyvonalakban, és kiadja a megvalósítandó feladatot a "jómunkásemberek" (csapatok) számára...

Szóval szerintem a devosp az egy jó kezdő irányzat, amiből aztán a tapasztalat növekedésével mindneki megtalálhatja a neki valóban tetsző "szakirányt".

--
zrubi.hu

Ehhez adalék, hogy ez akkor tud jól működni, ha a fejlesztők a production rendszerhez minél jobban hasonlító rendszert használnak, tehát nem az a process, hogy a fejlesztő "apt-get install mysql php" módban nyomja, és a "DevOps Engineer" majd csinál belőle valahogy élesben használható rendszert.

Hanem az egyes komponensek (adatbázis, alkalmazásfuttató környezet ... stb.) az lehetőleg ugyanazok minden környezetben, csak éppen a developer környezetében mondjuk a debug mód be van kapcsolva, a productionben meg nem.

Ennek folyománya, hogy ha a fejlesztőnek rá kell néznie valami miatt az éles rendszerre, akkor nem csak kamillázni fog, hogy mi micsoda, hanem érdemben tud segíteni. Az üzemeltető meg egyszerűbb módosításokat meg tud ha szükséges csinálni a fejlesztő helyett (ami persze utána végigmegy a code reviewn, mint minden más módosítás ... :) )

Hozzaszolasod igen nagyszeru, viszont annyit hozzatennek hogy egy tenyleg kompetens devops szakember, aki uzemelteto es fejleszto is egy szemelyben, annak jelenleg (ismerek jopar ilyet szemelyesen) netto 600 fontrol indul a napi fizuja Londonban.
Ebbol a megfelelo adooptimalizacioval netto 7-8ezer fontot siman ki lehet hozni havi fizetesnek, ugy meg mar nem is olyan szornyu ez a munkakor :)

Azt, hogy informatikus sose mondtuk senkire. Aki azt mondja, az nem ért hozzá. Ez egy ilyen mágikus összefoglaló név, de ilyen ember sose volt, és sose lesz. Olyan, mint az orvos.
Egyébként, én ezt az egész megnevezést nem szeretem, és csak egy felkapott buzzword. Jó devops-ot még nem láttam, és valszeg nem is fogok. Mert vagy értelmesen fejleszteni nem tud, csak kókányol, vagy üzemeltetni. És itt most nem arról beszélek, hogy meg tud írni egy valamit php-ban, vagy fel tud tenni egy apache-ot php-val. Hanem arra, hogy egy a lehetőségekhez képest biztonságos, karbantartható, fejleszthető, szép és átlátható rendszert csináljon, kódban és infrastruktúrában egyaránt. Tök más szemlélet és hozzáállás kell, ami szerintem sose fog összeférni.
--
"Sose a gép a hülye."

"erre van a code review" sajnos az nem a szent gral :( A gyakorlatban azt latom, hogy a code review olyan 20-30 szazalekban teljesul. Dolgozom egy szepen osszeszedett checklisten, amit code review alkalmaval meg kell nezni, kb 70%-on all, es mar most tovabb tart rajta vegigmenni mint megirni a kodot. Akkor mar inkabb a pair programming lehet a megoldas.

-
Advanced testing of Golang applications

Code review során nem lehet rendszert építeni. Bármilyen komolyabb fejlesztés során kellene design document és review (és ezt fejlesztői, üzemeltetői és security szempontból is vizsgálni kell). A code review nagy részét automatizálni lehet statikus kód analízissel, a mérnöknek már csak annyi a dolga, hogy megnézze, hogy az elfogadott irányban haladnak-e a dolgok, be vannak-e tartva a magasabb szintű konvenciók, megfelelő módszer lett-e választva a tesztelésre, stb. Általánosságban a code review legfontosabb célja, hogy a kód jól olvasható legyen, ezért muszáj hozzá 1-nél több ember. Sokkal fontosabb elsőre jól olvasható kódot írni, mint tökéleteset, mert akkor még mindig lehet rajta könnyen reszelni.

Erre pont ott vannak az integrációs és unit tesztek. Ha funkcióváltozással jár, akkor buknia kell a tesztnek is (lévén, máshogy működik a rendszer) egy funkció meg eleve nincs kész, ha nincs rá teszt. Bár utóbbira kell ember, aki ellenőrzi, mert a statikus kódanalízist túl könnyű átvágni.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

A code review nagy részét automatizálni lehet statikus kód analízissel, a mérnöknek már csak annyi a dolga, hogy megnézze, hogy az elfogadott irányban haladnak-e a dolgok,

szerintem a statikus kod ellenorzes az a beugro, anelkul -2. De ez csak a jeghegy csucsa, mert a review oroszlan reszet a tarsaid vegzik, akiknek massziv agymunkaval kell meggyozodniuk az adott commit hasznarol...

--
"dolgozni mar reg nem akarok" - HZuid_7086 'iddqd' zoli berserk mode-ba kapcsol

"automatizálni lehet statikus kód analízissel" bar mar leirtak, de az a belepo. Ha a kod elbukik a CI-on meg sem nyitom. A code review ott kezdodik, amikor a kod fordul.
"kellene design document és review (és ezt fejlesztői, üzemeltetői és security szempontból is vizsgálni kell)" persze de atztan ellenorizni kell, hogy a kod megfelel-e neki, szoval megint a design document es a tarsai semmire sem garanciak, amig valaki le nem ellenorzi, hogy tenyleg megfelel-e neki a kod. Szoval megint a code review-nak kell teljeskorunek lennie.
"a magasabb szintű konvenciók" pontosan. csak ilyenbol van 100 fele szabaly
"megfelelő módszer lett-e választva a tesztelésre" es megfeleloek-e a tesztek, meg a ... lentebb postoltam egy felkesz listat
"a code review legfontosabb célja, hogy a kód jól olvasható legyen, ezért muszáj hozzá 1-nél több ember" a masodik lepes a "fordul a kod" utan, hogy at kell futni, hogy egyaltalan olvashato-e a kod. Aztan at kell futni, hogy ... ismet a listat idezne, hogy mi mindent erdemes megnezni review soran. Mert ha nem nezzuk meg, akkor bemegy a kod anelkul, hogy meggyozodtunk volna rola, hogy koveti a specifikaciot, hogy nem tori el a biztonsagot, stb. A code review az utolso vedvar, aztan mar megy elesbe a cucc!!!!!

-
Advanced testing of Golang applications

> "automatizálni lehet statikus kód analízissel" bar mar leirtak, de az a belepo

Valóban belépő, de szerintem sokan alulbecsülik, mennyi mindenre jó lehet.

> de atztan ellenorizni kell, hogy a kod megfelel-e neki, szoval megint a design document es a tarsai semmire sem garanciak, amig valaki le nem ellenorzi, hogy tenyleg megfelel-e neki a kod. Szoval megint a code review-nak kell teljeskorunek lennie.

De az a lényeg, hogy ha megvan a design, akkor már kb. az interface-ekre ránézve látod, hogy megfelel-e, tehát önmagában ez miatt nem kell alapos review. Ha design nélkül állsz neki, és a review-n az az első komment, hogy teljesen szar az egész és írd újra emígy-amúgy, az egy nagyon rossz módszer.

Illetve ha a csapat jól bevált framework-öket használ, az egyrészt csökkentheti a kód bonyolultságát (pl. dependency injection áldásos hatása a tesztelhetőségre), másrészt ha mindenki elsajátítja és tudjuk is egymásról, akkor a code review még egyszerűbbé válik, mert a legalapvetőbb dolgokat alig kell néznem, épp csak átfutok rajta.

Nekem az a tapasztalatom, hogy egy code review során már kevés dolog szokott kibukni. De ebben biztos vastagon benne van az is, hogy sok az okos kolléga nálunk.

"De az a lényeg, hogy ha megvan a design, akkor már kb. az interface-ekre ránézve látod, hogy megfelel-e, tehát önmagában ez miatt nem kell alapos review."

Mivan?! Van egy interfaced:

public interface ICalculator
{
  int Add(int a, int b);
}

Kérlek, mond meg erről, hogy a mögöttes implementáció is jól működik-e. Csak az interfacera ránézve. Meg azt is, hogy olvasható-e a kód, nem kell-e indokolatlanul sok gondolkodás a megértéséhez, stb.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

nyilvan nem ved atomtamadas ellen is, de a code review egy plusz lepes a hibak kiszurasara a FIFO mintajara SISO jelleggel (shit in shit out). Helye valogatja, de az is lehet, hogy a review 1. lepese az, hogy megnezed, van-e bizonyitek arra (pl. csatolt teszt eredmenye), hogy a modositas korrekt modon mukodik...

--
"dolgozni mar reg nem akarok" - HZuid_7086 'iddqd' zoli berserk mode-ba kapcsol

Hat van benne nemi redundancia, de:

Design:
How does the change looks like?
How does the new code fit with the overall architecture?
Does the code follow S.O.L.I.D. principles, Domain Driven Design and/or other design paradigms the team favors?
What design patterns are used in the new code? Are these appropriate?
Does it follow the example of older code that is due to be phased out?
Is the code in the right place? For example, if the code is related to Orders, is it in the Order Service?
Could the new code have reused something in the existing code?
Does the new code provide something we can reuse in the existing code?
Does it build for reusability that isn’t required now?
Does the new code introduce duplication?
Is the code over-engineered?

Readability and Maintainability
Do the names (of fields, variables, parameters, methods and classes) actually reflect the things they represent?
Can I understand what the code does by reading it?
Can I understand what the tests do?
Do the tests cover a good subset of cases?
Do they cover happy paths and exceptional cases?
Are there cases that haven’t been considered?
Does the test catch the right exception?
Are the exception error messages understandable?
Are confusing sections of code documented, commented, or covered by understandable tests

Functionality
Does the code actually do what it was supposed to do?
If there are automated tests to ensure correctness of the code, do the tests really test that the code meets the agreed requirements?
Does the code look like it contains subtle bugs, such as using the wrong variable for a check, or accidentally using an and instead of an or?
All the existing callers are prepared for the new functionality?

Error handling
Does the code handle all of the errors?
Is there any missing null pointer check?
All the existing callers are prepared for the new/changed error handling?

Have you thought about…?
Are there regulatory requirements that need to be met?
Does the author need to create public documentation, or change existing help files?
Have user-facing messages been checked for correctness?
Are there obvious errors that will stop this working in production?

Correctness
Is the code using the correct data structure for a multithreaded environment?
Is the code susceptible to race conditions?
Is the code using locks correctly?
Are caches evicted where needed?
Are timeouts configured and handled everywhere?
Does the code use multiple threads to perform a simple operation?
Does the code fetch only required data or fetches N+1?

Code-level optimizations
Does the code use synchronization/locks when they’re not required?
Is the code using locks or synchronization when it could use atomic variables instead?
Is the code using a thread-safe data structure where it’s not required?
Is the code using a data structure with poor performance for the common operations?
Could the code benefit from lazy loading?
Can if statements or other logic be short-circuited by placing the fastest evaluation first?
Are cheaper conditions before expensive ones?
Is there a lot of string formatting? Could this be more efficient?
Are the logging statements using string formatting with right number of arguments?

Es van nehany ki nem dolgozott resz, ilyen aprosagok, mint:
API `n database changes
Security
Logging
Performance

-
Advanced testing of Golang applications

Mindenhova képzeld oda, hogy IMHO és saját tapasztalataim szerint. YMMV.

> How does the new code fit with the overall architecture?

Nálunk még junior se követ el olyan hibát, hogy ez miatt kéne visszadobni.

> Does the code follow S.O.L.I.D. principles, Domain Driven Design and/or other design paradigms the team favors?
> What design patterns are used in the new code? Are these appropriate?

Ennek inkább design review-n kellene kiderülnie, nem code review-n.

> Do the tests cover a good subset of cases?
> Do they cover happy paths and exceptional cases?
> Are there cases that haven’t been considered?
> Does the test catch the right exception?

Ezeket automatizáltan kellene nézni.

> Are confusing sections of code documented, commented, or covered by understandable tests

Az érthetetlen kódra nem a komment, hanem az újraírás a megoldás :).

> Does the code look like it contains subtle bugs, such as using the wrong variable for a check, or accidentally using an and instead of an or?

A subtle bugs attól subtle, hogy simán átmegy code review-n, ritkán láttam olyat, hogy direkt ilyet keresne és találna is valaki. Ha a tesztek se vették észre, akkor kimegy integration testre, még akár prodba is, és majd ha valaki észreveszi, akkor kijavítjuk később.

> Does the code handle all of the errors?
> Is there any missing null pointer check?

Kód analízis.

> Are there regulatory requirements that need to be met?
> Does the author need to create public documentation, or change existing help files?
> Have user-facing messages been checked for correctness?

Ezt szintén nem code review-n kell megvitatni.

> Is the code using the correct data structure for a multithreaded environment?
> Is the code susceptible to race conditions?
> Is the code using locks correctly?

Eléggé masszívan skálázható rendszereken dolgozom, de mégis nagyon ritkán kell alacsony szintű lockolással foglalkozni. Egyrészt van sok jó keretrendszer, ami jól (!) megoldja ezeket, másrészt ebben is tud segíteni a kód analízis. De igaz, hogy ha a kolléga mégis ilyen kódot ír, azt alaposan át kell nézni.

> Is the code using a data structure with poor performance for the common operations?

Ez is olyan, hogy még a juniorok se szokták elrontani nálunk. Nagyon erős algoritmikus tudás kell már az interjún is.

> Is there a lot of string formatting? Could this be more efficient?
> Are the logging statements using string formatting with right number of arguments?

Kód analízis.

> API `n database changes

Design review.

> Security

Design review (security engineer által), kód analízis, jó keretrendszer. Nálunk pl. statikus kód analízis van arra, hogy user inputot se véletlen, se direkt nem tudsz escape nélkül SQL querybe tenni.

> Performance

Design review (SRE-k által), illetve kitolod integration testbe, ráeresztesz egy jó kis terhelést, és nézed a grafikonokat.

Amikor azt írom, hogy design review, nem azt jelenti, hogy nem kell nézni code review-n. Azt jelenti, hogy a problémás dolgok már előre meg lettek beszélve, nem kell checklist alapján keresgélni, hogy mire figyeljünk, és egy gyors átfutással meg tudsz győződni róla, hogy be lett tartva.

"Nálunk még junior se követ el olyan hibát, hogy ez miatt kéne visszadobni." es akkor meg sem kell nezni?

"Ennek inkább design review-n kellene kiderülnie, nem code review-n."tervezesnel kell meghatarozni, hogy milyen lesz, es code/design review kell ellenorizni, hogy olyan lett-e. Nevezheted akarminek, nekem code review, mert a kodot nezem, hogy megfelel-e a terveknek

"Az érthetetlen kódra nem a komment, hanem az újraírás a megoldás :)." ez nem mindig lehetseges, lehet a ronda kod egy workaround egy masik mondjuk 3rd party lib hibajara

"még akár prodba is" ennek a kockazatat kene csokkenteni a code review soran, tehat meg kell nezni. "Ha a tesztek se vették észre" mint mondtam van redundancia, mert pl azt is meg kell nezni, hogy van-e teszt

"Kód analízis." nem letet 100% kod analizist vegezni, mer a kod analizis nem tudja, hogy mi egy hiba helyes kezelese, valamint a null checket sem tudja, csak akkor ha defenzive programozas van, es minden mindenhol ellenorizve van.

"Ezt szintén nem code review-n kell megvitatni." lehet sokfelekeppen nevezni, de valamikor valakinek le kell ulni es meg kell nezni, hogy megfeleloek-e. Persze szetszedhetjuk 23 fele review-ra, de nem valtoztat a lenyegen, hogy nem lehet mellettuk elmenni

"Egyrészt van sok jó keretrendszer, ami jól (!) megoldja ezeket, másrészt ebben is tud segíteni a kód analízis. De igaz, hogy ha a kolléga mégis ilyen kódot ír, azt alaposan át kell nézni." Es a jo frameworkkel mar nem is lehet hulyeseget csinalni :D es igen meg kell nezni, ha ilyen van. En nem allitottam, hogy ez egy arany lista es minden projekten mindent meg kell nezni. De ha van, akkor meg kell nezni, ahogy te is mondtad. Ha az egy magasabb szintu FW, annak hasznalatat kell ellenorizni, ha low level, akkor meg azt.

"Ez is olyan, hogy még a juniorok se szokták elrontani nálunk." Tehat ha nem szoktak, akkor nem is fogjak a jovoben sem soha, ezert meg csak nem is erdemes elgondolkozni azon, hogy vajon helyes lett e hasznalva....ertem....nem :)

"Azt jelenti, hogy a problémás dolgok már előre meg lettek beszélve" ne keverjuk ossze a design tervezest a design reviewval, ugyanis elobbi a kodolas elotti tervezes, az utobbi meg kodolas utanni ellenorzes, ahol konkretan a kodot nezed, hogy megfelel-e a designak, tehat code review, csak mashogy hivod.

"nem kell checklist alapján keresgélni" Egyszeru, ha van deign terv, akkor arrol kell checklist point, hogy meg kell nezni, hogy megfelel-e neki, ha meg nincs, akkor meg arra kell pont, hogy meg kell nezni. De tok mindegy, a lenyeg, hogy nem mehet elesbe ugy a rendszer, hogy valaki meg nem nezte volna kod szinten, hogy megvalosultak-e az elvarasok

-
Advanced testing of Golang applications

"valamint a null checket sem tudja"

Pedig elég jól lehet azt tudni: https://checkerframework.org/

Szerintem nagyjából egyet értek veled, hogy ezeknek a dolgoknak teljesülnie kell, de szerintem túl nagy hangsúlyt helyezel a code review-ra. Mondok pár példát.

Design documentben már lebokszoljuk, hogy a protobuf-nak hogy kell kinéznie. Ez leírja az adatosztályokat (mint a DDD, ez lehet RPC interfész része vagy éppen adatbázis oszlop) és az RPC metódus interfészeket. Ezen megy sok vita, és ha megvan, ebből már egy csomó minden adódik magától. Ha a fejlesztő kolléga csak simán átülteti a protobuf leírást a doksiból a kódba, akkor nem fogom karakterenként megnézni, hogy tényleg abban egyeztünk-e meg. Ha eltért tőle, szól magától. És nem kell azt nézni, hogy véletlen a kolléga a GetImage implementációjában törlést implementál, mert sose fordul elő, de ha mégis, külön keresgélés nélkül is azonnal észrevesszük.

Tegyük fel, hogy a kolléga olyan kódot írt, aminek performance problémája van. Pl. egy O(N) metódus hív (nagyon közvetetten) egy másik O(N) metódust, és ezért az egész cucc O(N^2) lesz (valós eset). Mivel olyan mély stack strace-ről van szó, ember nem vette volna észre soha. De amint kiment tesztkörnyezetbe, a grafikonokon azonnal látszott, hogy súlyos gond van. Hosszas code review helyett percek alatt észre lehet venni. Melyikkel jársz jobban? Vagy tegyük fel, hogy N<10. Akkor még az O(N^2) sem lesz látványosan szar. Ha a 99pct latency grafikonon se jelenik meg szemmel láthatóan, akkor simán lehet, hogy örökre ott marad a kódban. De van evvel probléma?

Tegyük fel, hogy addig már eljutottunk, hogy a kód olvasható és az API megfelel a speckónak. Rengeteg olyan dolog van, amit kód szinten többféleképpen is meg lehet oldani. Mennyi értelme van vitázni ezeken? Sajnos volt ilyenben részem, nagyon kontraproduktív volt, elment rá sok idő és a kód mondjuk 3%-kal szebb és 0%-kal korrektebb lett. Egy csomó dolgot jobb elengedni, és hasznosabban kell tölteni az időt.

Azokra a dolgokra, amit még junior se követ el, azt tudom mondani, hogy nem fogom azokat a hibákat direkt keresni. Nagy az esélye, hogy eleve nem lesz olyan hiba elkövetve, vagy ha mégis, akkor keresés nélkül ki fogom szúrni egy egyszeri átolvasás során. Ha két ember is átsiklott felette, akkor az nem egy tipikus hiba.

Úgy általában nem tetszik az a véleményed, hogy a code review egy utolsó mentsvár. Nagyon fontos az utána történő tesztelés integrációs környezetben, és a productionben fellépő hibák észrevétele és gyors javítása. Mondok egy tippet: productionból érkező kéréseket tükrözöd a dev környezetre. Hirtelen olyan jól meg lesz tesztelve minden kód, hogy rögtön kevésbé fontos a hosszas és alapos review.

"checkerframework" meg fogom nezni, pont ezt nem ismerem

En is nagyjabol egyet ertek veled, es name art tudnik mikre kell/lehet figyelni. Nem szoktam minden alkalommal elovenni a listat. Egy resze nyilvan fejben van, plusz nem minden resze alkalmazhato minden projektre/csapatra.

Azt is tudom magamrol, hogy kod fetisiszta vagyok :) de tapasztalatom szerint van ertelme megallni es atgondolni a dolgokat. Mert az ordog a reszletekben lakozik, es en nem az azonnal kimutathato hibaktol vagy csunyasagoktol tartok altalban. Sokkal inkabb attol, amikor elszaporodnak azok a franya kis 3%ok, vagy a kis sunyi joinolunk meg ket tablat feleslgesen tortenetek. Ezeket utolag megtalalni es kikalapalni nem tul elvezetes dolog.

"a code review egy utolsó mentsvár" azert tekintek ra ugy, mert az utolso pont, ahol meg ember inteligencia foglalkozik a koddal. Ami az utan jon, azt lelektelen gepek vegzik.

"productionból érkező kéréseket tükrözöd a dev környezetre" ez egy eleg jo modszer lenne, ha a userek 80%a nem a szoftver 20%at hasznlnak.

Sajna nincs tokeletes teszt lefedettseg, es amig ez fennall, addig nem art, ha legalabb ket mernok atgondolja a leheto legszelesebb spektrumban, hogy az adott change megfeleloen let-e implementalva. Vagy akkor legyen pair programming.

-
Advanced testing of Golang applications

Épp most revieweztem egy ilyet:


foreach (var x in list)
{
+  if (x is Foo foo)
+  { 
+    DoSomething();
+    WithFoo(foo);
+    continue;
+  }
+

   if (!(x is Bar))
   {
     throw new SomeException("blabla");
   }

   var bar = x as Bar;

   DoOther();
   AndUse(bar);
}

Logikailag teljesen jó a kód, azt is csinálja, ami a taskban le volt írva, működött is, teszten is átment, stb. Mégis rádobtam egy sárgát, hogy írja már át kolléga a switch-cases pattern matchingra, mert szerintem érthetőbb kódot eredményez. Ilyet hogy szűrsz ki automatizáltan? Hogy fogsz kiszűrni előre a design reviewban? Hogy fogja neked kiszűrni az automatizált analízis, ha mégsem annyira kézenfekvő ide a pattern matching?

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Aki nem ugy gondol a code revira, mint az elesbe allas elotti utolso mindent lefedo ellenorzes, az nyitva hagyja a kaput mindenfele randa nyavajaknak. Nem lehet mindent analizalni, meg tesztekre fogni. Ha hibas az impl hibas a teszt is. Ami atmegy revien az megy elesbe, es nincs pardon :)

-
Advanced testing of Golang applications

Nem trollkodok. A code review a vegso allomas mielott elesbe megy a rendszer, ahol ellenorizni kell, hogy a kod megfelel-e a terveknek, illeszked-e az alkalmazas tobbi reszebe, hogy van-e benne hibas adatkezeles, n+1 query, meg a tobbiek, hogy a nem specifikalt reszek hogyan lettek implementalva, stb. Es itt akkor ismet, nekem minden code review, ami kodszintu human ellenorzes, ami tortenhet tobb lepesben, nevezhetjuk 100 felekeppen. A fejlesztes egy bizonyos szakaszaban a szerzotol eltero human entitas a kodot nezni mielott elesbe megy a cucc :)

-
Advanced testing of Golang applications

Ketfele fejleszto van. Az egyik alapbol, ilyen lista nelkul is erdekes kihivasnak tekinti, hogy mas munkajaban szakmailag kifogasolhatot talaljon (amikor erre exlpicite megkerik). A masik meg egy ilyen listaval is lezarja a review-t par perc mulva egy "looking good"-al.

Nem praktikus ennyire reszletezni, es naiv dolog elvarni egy "human entitas"-tol, hogy ezen a listan minden altott review soran precizen vegigmenjen, de mar te is rajottel, hogy ez tul idoigenyes, mar csak a pontok vegigolvasasa is.

----------------------
"ONE OF THESE DAYS I'M GOING TO CUT YOU INTO LITTLE PIECES!!!$E$%#$#%^*^"
--> YouTube csatornám

A_Franko_ által leírt DevOps kultúrával teljes egyetértek és alkalmazom, de sohasem váltanék DevOps munkakörre, mert egy fizetésért kell el végezni több ember munkáját.

Talalgatasokat elkerulendo, ezekben a konyvekben minden benne van amit a DevOps es az SRE temaban tudni erdemes:

* The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win
* The DevOps Handbook: How to Create World-Class Agility, Reliability, and Security in Technology Organizations
* Site Reliability Engineering: How Google Runs Production Systems

Nem tudom Magyarorszagon hogy kezelik ezt most, mit ertenek Devops alatt. Angliaban sajat tapasztalatbol a devops contractor most az egyik legmenobb - mindekinek aws, kubernetes, jenkins, ansible, terraform kell. Lasszoval keresik az embereket - ha tapasztalatod van ezekben es erted is ezeket a technologiakat akkor contractorkent az £550 napidij csak az alja...
Igen tudom - ez csak azt jelenti epits egy infrastructurat code-bol AWS-ban, fejeld megy egy CI/CD vel es integrald rakat 3rd party-val. A kormanytol a fintech-en at, retail lancok es a sky/bbc mediaszolgaltatokig mindenki tolja a cuccat a felhobe - nem tudom mennyi ideje lattam mar hagyomanyos ertelemben vett datacentert sajat uzemeltetessel de azok is azon tekernek hogy atmigraljanak a felhobe.
Itt a devops mernok az aki kepest ezt megcsinalni - egy reszunk DEV mas reszunk uzemelteto oldalrol erkezik. Egy csomo permanens devopsost is keresnek de sok esteben ezeket siman kikozvetitik egy-egy projektre.
Hogy van-e jovoje ? Igen, nagyon is es bar lehet hogy buzzword de igazabol itt mindenki tudja hogy mit takar es mik az elvarasok. Es ahogy egyre inkabb tolodik el a cloud fele az uzemeltetes ez csak tobb igenyt jelent.
Pl most is keresunk contractor DevOpsost. Nem egyet - inkabb 5-ot a fenti technologiakra de ahogy vettem eszre eleg sokan nem tudnak minimalis szintet sem megugrani az interjun... Es igen van senior Devops es architect is - az AWS nem meg certificate-je is van ra es piszok sokat fizetnek ertuk.

kb. 5-6 évvel ezelőttig kevés volt az olyan opsos, aki írt volna kódot, kifejezetten sokan voltak, akik talán össze tudtak hákolni valami bash szkriptet, de azt is bár ne tették volna (viszont általában vastagon lenézték a fejlesztőket, mert azok nem tudtak apacsot konfigolni), úgyhogy amikor megjelentek azok az eszközök az üzemeltetési oldalon, amihez már kellett képesség/ismeretség/tehetség a kódolásra, akkor megjelent a "dev" is az ops mellett...

Ott hogy mindezt kodbol csinalod. A fenti technologiak mindenike kod - nincs tobbe kolbaszolas a konzolban, mindent kodbol kell megcsinalnod. Nem Java/C kod attol meg a szabalyok es a kodolas best practices ervenyesek ra. Kodbol epul a frontend, backend, db serverek, automatikus skalazodas, automatikus monitoring/backup enrollment, load balancing, routing, security groups, VPN, minden. Es ez csak az infra resze... Erre rantsd fel a kube klustert, vagy Java, tomcat, nginx, websphere, ldap, konfigurald be oket environmentek alapjan (PRD, TEST, DEV stb) es akkor meg ismert a hazon beluli appokat is es tudj ertelmesen komunikalni a JAVA fejlesztokkel hogy elmagyarazd miert nem fog az a dolog amit eppen implementalt ertelmesen skalazodni stb... Kodbol es template-bol epited az integraciot.
Nem hagyomanyos ertelemben vett C vagy java, php kod, de ez is fejlesztes es ugyanugy meg kell tervezni. Tekinthetjuk ugy hogy a Te kododnak az eredmenye a mukodo termek (infra+software+integracio) egyuttese.

"Infrastructure as a code" en ertem, de azert egy yaml osszeollozasat par jinja/go template "if" statementtel ne tekintsunk mar kodolasnak. Kb semmit nem tervezel a kodban. Az ifrat tervezed meg, amit leirsz egy kutya kozonseges yaml fajlban, aminek bizonyos reszeit ki-be kapcsolgatod bizonyos perem feltetelek menten. A legkomolyabb fejlesztes az egeszben a for ciklus, ha tobb user is kell vagy egy substring hivas :) Raadasul az osszes cuccnak salt, ansible, helm megvan a sajat strukturaja, meg cask a projektet sem kell megtervezni. Fogod a yamlt beteszed a helyere, fogod a valtozokat beteszed a helyere, es egy templattel hivatkozol a valtozokra. Szerintem semmi dev nincs ebben, ezek template nyelvek a maguk 3-5-8 funkcijaval. Lehet, hogy azoknak, akik eddig beleptek a szerverre es kiadtak a parancsokat kezzel ez most valami magia, de egy automatizalo bash script osszekalapalasahoz tobb programozas szukseges. Ott legalabb kell hibat kezelni, meg valtozokat deklaralni, adatot konvertalni :)

-
Advanced testing of Golang applications

Ennel azert kicsit tobbrol van szo es pl az AWS lambda-ba kell am rendesen javascript / python kodot is tolni ha hasznalni akarod. Amit leirtam az csak az alap, a legtobbet alkalmazott resze a szemleletnek.
Erdekes hogy a hagyomanyos fejlesztok meg azt a kis _dev_ prefixet is sajnaljak tolunk tekintettel arra hogy nem "igazi" kodot irunk. Azert "sysops on steroids"-nak megsem nevezhetjuk magunkat nemde ? :D

En nem mondtam, hogy egy rendszer uzemelteto nem tud kodolni. Eddig bash, perl, python volt a fo volnal, abban is kellett programozni, joreszt scripteket. En azt mondtam, hogy amit ma devopskent hirdetnek tanfolyam/allas az joreszt modern sysops-ot takar magaban.

-
Advanced testing of Golang applications

Nekem is ez a tapasztalatom itt a UK-ban. Sokkal tobb a contract megkereses, illetve nagyon nepszeru a consulting - itt alkalmazott vagy - ahol mar eleve megmondjak, hogy 1-2 evre egy nagy ugyfelhez (peldaul: bank) leszel kikozvetitve. Ezerrel duborog a digital transformation.

A DevOpsnak biztos, hogy van jovoje, mert eleve:
* automatizalas: end-to-end megoldasok, skalazhatosag, self-healing megoldasok (nalam ez mar az SRE fele mutato kategoria)
* integracio: kulonbozo szolgaltatasok, illetve a QA, CI/CD, InfoSec egybegyurasa, majd ezt kovetoen a Machine Learning, AI.
* adaptacio: elsosorban a software engineering temakorbe tartozo dolgoknak az atemelese, masfelol az infrastruktura uzemeltetessel kapcsolatos temakorok alkamazasa (pl.: Chaos engineering)
* folyamatos fejlodes/fejlesztes: incrementalis valtozasok (jol definialt, apro valtoztatasok)
* vizualizacio: folyamatok minel jobb megertese, a metrikak megfelelo megjelenitese, ertelmezese

Cege valogatja, hogy ezekbol mit es milyen szinten szeretnek, illetve figyelembe kell venni, hogy az egyes teruletek kozotti fuggosegeket, hogy epulnek egymasra.

Es meg rengeteg dolog. Eppen ezert kell automatizalni a meglevo dolgokat, hogy legyen ido tovabbi dolgokkal is foglalkozni.
Az infrastruktura automatizalas utan jon az uzleti folyamatok digitalizalasa/automatizalasa, hogy az adott ceg igazan kepes legyen reagalni a piaci valtozasokra, esetleg o maga tudja diktalni/alakitani a jovot.

"Some people think football is a matter of life and death. I assure you, it's much more serious than that." - Billy Shankly

Billy Shankly utan szabadon: Vannak, akik azt gondoljak, hogy a DevOps az csak automatizalas, vallalati kultura, felho, CI/CD. Bizton allitom, hogy attol sokkal, de sokkal komolyabb.

Lehet, de ez nem baj, mindketto (DevOps es informatikus) gyujtofogalom. :D

Inkabb a szakmanak es a HR-nek kellene elgondolkodnia azon, hogy megfelelo karrier utakat irjon le az uzemelteto kollegak szamara.
Az IT is szenved, hogy nem kapnak megfelelo mennyisegu es kepzettsegu embert illetve a szakemberek (kezdok, palyamodositok es szeniorok) egyarant.
Szerintem az mar kezd korvonalazodni, hogy merre tartunk, a kerdes, hogy hogyan lehetne optimalizalni/leroviditeni ezeket az utvonalakat.
Milyen munkakorok, tapasztalat es tudas kell, hogy ezt el lehessen erni es mindezt fenntarthato modon.

Nagyvallalati kornyezetben sokkal tobb a lehetoseg a specializalodasra, szerintem itt kellene kezdeni.

Sziasztok,

 

ér kicsit felfrissíteni a topicot?

Van mostanság valami ajánlott DevOps/SRE roadmap amit érdemes követni, ha kicsit up-to-datebb szeretnék lenni? AWS-nél milyen vizsgáknak érdemes nekifutni?