Mi lesz ha keresztezünk egy hálózatos és egy devops szakembert?

HUP

A multitenant, következő generációs adatközponti hálózatok orchestrációs megoldásai részben vagy egészben alkalmazásvezérelt megoldások lesznek. Ez új humán interfészt teremt a hálózatos és a devops szakemberek között. A témát Füstös Balázs (Invitech Solutions) járja körül a jövő heti meetupunkon. Gyere, jó lesz! További részletek »

( KoGa v | 2017. 06. 15., cs – 10:09 )

"Mi lesz ha keresztezünk egy hálózatos és egy devops szakembert?"
Mekk mester :)

( kiskacsa | 2017. 06. 15., cs – 10:23 )

Az angol szavak magyaros átírásának látványától egy kiadós hányás emléke bugyborékol elő az agyamban. Ha meg három helyen háromféleképpen teszik ezt, akkor az jut eszembe, hogy haha.

In the big data space, industry is effectively calibrating its value-added clouds. Efficiencies will come from ethically offshoring our alignments. So we can hit the ground running, we will be conservatively facilitating every dot-bomb in our space. Competitive standpoints are becoming customer-focused milestone experts.
We aim to reliably offshore our prince2 practitioner by effectively revolutionizing our best-in-class immersive stakeholders. It's critical that we give 110% when iteratively investing team players. Senior deliverables proactively enable end-to-end best practices for our bandwidths. Unparalleled diversities are becoming next-generation platform experts.

#buzzwordfelhő2017

--
GPLv3-as hozzászólás.

( bucko | 2017. 06. 15., cs – 10:37 )

Énisakarokorkesztrálni! (Mr. Karajan)

( gemnon v | 2017. 06. 15., cs – 10:46 )

:D

Szerintem egy kis "manager"-t is bele kellene keverni,hogy tutira semmire se legyen alkalmas az illető.:)

( uid_395 v | 2017. 06. 15., cs – 17:02 )

Erről valahogy beugrott az Alien 4 Ripley "Kill me" jelenet :D sajnos normális GIF-et nem találtam hozzá :))

( hnsz2002 v | 2017. 06. 16., p – 08:29 )

Egy selejt.
--
"Sose a gép a hülye."

( saabi v | 2017. 06. 16., p – 08:54 )

Ha az egyik fiú a másik meg lány, akkor abból akár egy kisbaba is lehet. Aki felnőve vagy ilyen hülyeségekkel fog foglalkozni, vagy sem.

Ave, Saabi.

( Oregon | 2017. 06. 16., p – 10:28 )

Nem az van, hogy ahogyan fejlődik a tudomány úgy szaporodnak (osztódással) a szakterületek?

// Értem én, hogy az evolúcióval ellenben jó lenne kefélni egy baktériummal, nade mégis! :)

( kariThe1 | 2017. 06. 19., h – 21:05 )

A helyes válasz: Network DevOps Engineer

A magyarítás tényleg nem túl "jóhangzású".
Az orvosok is latinul mondják, amit latinul kell mondani. Szerintem a mi szakmánkban maradjunk az angolnál! Az a szakmai nyelv. Van, amit nem kell lefordítani!

A flame-elők 1-essel leülhatnek!
És ezt most halál komolyan!

Software-defined networking (SDN): https://en.wikipedia.org/wiki/Software-defined_networking
OpenFlow: https://www.opennetworking.org/sdn-resources/openflow/
OpenDaylight: https://www.opendaylight.org/
OPNFV: https://www.opnfv.org/
DOCKER AND CISCO LAUNCH CISCO VALIDATED DESIGNS FOR CISCO UCS AND FLEXPOD INFRASTRUCTURES ON DOCKER ENTERPRISE EDITION: https://blog.docker.com/2017/03/docker-cisco-launch-cisco-validated-des…
Arista: DevOps for Network Engineers: https://www.slideshare.net/PhilipDiLeo/arista-devops-for-network-engine…

... hogy csak néhányat említsek.

Ahelyett, hogy "MekkMesterezel", "bullshit manager-ezel" meg "flame-elsz" olvass, tanulj és képezd magad, hogy a jövő technológiája ne érjen hidegzuhanyként!

#NetworkDevOpsEngineer

Nem!

Balázson kívül vagyunk még jónéhányan, akik nyomon követik az iparági trendeket és fejlesztéseket.
Erről a témáról volt szó például a VDay-en.
https://vday.hu/2016/ ->
9:30 - 10:00 DevOps for Networking - Kulin Shah @ Arista
Gondolom a flame-elők nem voltak ott.

Akit tényleg komolyan érdekel a téma a megadott linkek adnak egy kiindulási alapot...

Persze legjobb védekezés a támadás!
A továbbiakban nem kívánok ebben a thread-ben vitatkozni!

„Bazinga!”

Én még nem láttam olyan embert, aki két területtel foglalkozik, és mindkettőt jól csinálja. Tök más gondolkodásmód kell a fejlesztéshez, és más az üzemeltetéshez, és ilyen szempontból teljesen mindegy, hogy hálózatot vagy szervereket üzemeltetsz.
Csak olyannal találkoztam, aki az egyiket elhanyagolva, másodlagos dologként, teherként csinálta, amire ha ránéz az adott terület szakértője, akkor elhányja magát, vagy a fejét fogja. A devops is létezett eddig is, csak nem volt neve, nem akart senki ilyen droidokat gyártani, nem volt ekkora a hype körülötte, és aki csinált is ilyet, az az egyik feladatát úgy kapta, hogy nesze sánta itt van még egy púp, aztán csináld ahogy akarod.
A dolgok egyre komplexebbek, az üzemeltetés és a programozás is, így szerintem nem összevonni kéne őket, hanem inkább a meglévőt is szétbontani valamilyen logika vagy irány szerint, és egy adott részben nagyon mélyében tanulni, ha valakit ez érdekel, nem pedig ilyen felületes összemosott tudással, mélyére nem látó és rendszerben gondolkodni nem tudó emberekre van szükség.
--
"Sose a gép a hülye."

Majd küldök egy fényképet. ;)

Igaz, mióta megjelent az informatika, egyre több "mindenhez nemértő" szakember jelent meg a piacon. A java, php, sql stb. termeli a pongyola szakembereket. Persze a Windows alapú technológia sem jár az utolsó helyen. :)

Ugyan, ki oktatná a komplex rendszerek felépítéséhez szükséges ismereteket, amikor ahhoz gyakorlat is kellene? A megrendelők sem értenek hozzá, így nem tudják megfogalmazni az igényekiet. Persze láttam már szakmai specifikációt: Az awk és C tilos, legyen minden java-ban, mert az biztonságos!

Ha szerinted nem kellene összevonni a komplex rendszerismeretet, akkor mi lehet a megoldás? Egy rendszer egyes elemeit darabonként "tökéletesre" elkészítve, majd azokat összerakva - már kis bonyolultság esetén is - könnyedén eredményezhet működésképtelen végeredményt. Ekkor jönnek a további csúsztatások...
Jobb esetben, ha valaki mégis átlátja az egészet, kezdődhet az iteráció. Az addig tökéletesnek vélt elemeket újra meg újra át kell alakítani, hogy a folyamatot is támogassák. No, ekkor jön a következő probléma. Az egyes elemek nem olyan elvekkel készültek, hogy bármit is tudjanak támogatni a primitív specifikáción kívül. Ekkor jönnek a további csúsztatások... (Ezt mintha már írtam volna.)

És már megint igazad van! A felületes összemosott tudás alkalmatlan egy rendszer megfogalmazásához. Ezt egy okos ember így fogalmazta meg: Tanulhatsz ilyen szervezési módszer, amolyan technikát, de ha nem találod meg azt az embert aki meg is tudja csinálni, akkor b.hatod!
Ha valakiből hiányzik a precizitás, az affinitás, akkor tanulhatja, de soha nem fog jól működő rendszert megálmodni. Sem megvalósítani.

Az is igaz, hogy a fejlesztés teljesen más, mint az üzemeltetés. De vajon ki írja az üzemeltetési dokumentációt? A takarítónő, vagy aki a rendszert tervezte. Természetesen egy nem kellő alapossággal tervezett rendszernél a kérdés költői. ;)

Attól függ, mit értünk rendszer alatt. Legyen a példa egy ügyviteli rendszer. Ennek a fejlesztői nyilván tudják, hogy mit kell a programmal csinálni. Milyen futtatókörnyezet kell, milyen adatbázis kell alá, mit kell a konfigba módosítani, ha más verziód van, hogyan kell backupolni, stb. Ez a szoftvernek az üzemeltetési része, ezt nyilván a fejlesztők készítik. De egy összetett rendszernek ez egyetlen komponense. Az üzemeltető dolga az, hogy ennek megfelelően stabil, gyors működési körülményeket biztosítson, hogy összekapcsolja más rendszerekkel (pl. email), és egyáltalán, az egészet valahogy betenni a meglévő infrastruktúrába. Egy üzemeltetőnek egyben kell látni a dolgokat, a rendszer egészét tekintve, mind működésileg, mind biztonságilag, mind erőforrásilag.
Nagyon jó példák erre szerintem:
A szoftverfejlesztő úgy képzeli el, hogy a programjáé a db, ott megkapja a root/sa/sysdba-t, és azt csinál amit akar. Majd ő évenként vagy cégenként csinál új adatbázist, akár más sémával, vagy majd programon belül lesz egy backup gomb, és csinál a szoftver egy komplett mentést a db-ről.
A szoftverfejlesztő úgy képzeli el, hogy a gépen csak az ő programja lesz, így olyan komponenseket vagy beállításokat telepít rendszer szinten, ami neki jó, nem gondol arra, hogy ezzel bármi mást elcseszhet.
A szoftverfejlesztő úgy képzeli el, hogy a programja teljes jogosultsággal fog futni, és nem érti miért van azzal probléma, hogy ha ki van kapcsolva az UAC, ha a program files-ba írja a logot, és a c: gyökérbe készítené a tábla exportot, mert hát úgyis csak ideiglenesen kell.
A fejlesztő nem érti, hogy miért nem nyithat a program akármilyen portot localhoston, és miért nem konnektálhat ki akármikor, akármilyen portra.
A fejlesztő nem érti, hogy miért nem jó az, ha a program saját magát frissíti le a beépített frissítés gombbal.

Stb..

És sajnos a felsorolt dolgok nem csak a kiváló magyar szoftverekre jellemző, de sokszor komoly háttérrel rendelkező, nagynevű szoftverekre is.

Többek között ezért is van örök harc a programozó és a rendszergazda között. Ha valaki e kettő egyben, valamelyik irányba el fog húzni a szíve, következésképp a másik oldal eszméletlen szar lesz.
--
"Sose a gép a hülye."

"Többek között ezért is van örök harc a programozó és a rendszergazda között. Ha valaki e kettő egyben, valamelyik irányba el fog húzni a szíve, következésképp a másik oldal eszméletlen szar lesz."

Amennyire én érteni vélem, a devops egyfajta megoldási keret erre a macska-egér kapcsolatra, nevezetesen:
-fejlesztési időben legyenek kezelve az üzemeltetési szempontok és követelmények
-az üzemelő rendszerről a fejlesztő releváns információkkal rendelkezzen, a tapasztalt problémák pedig jól dokumentált, megoldandó feladatként jelentkezzenek a számára.

Rosszul látom?

Üdv,
Marci

Két olyan területről van szó szerintem, amelyiknek egyikét sem lehet semmilyen órán, tanfolyamon megtanulni.
A matektanárunk mondta középiskolában mindig, hogy deriválni egy lovat is meg lehet tanítani. Igen, azt egyszer megtanulod, azt mindig úgy kell csinálni.
De ezeknél, ha nincs meg a megfelelő hozzáállásod, szemléleted és gondolkodásmódod, hiába tanulsz meg bármit is. Mert gyakorlatilag nincs két teljesen egyforma probléma, mindegyik más. Gondolkozni kell.
--
"Sose a gép a hülye."

Jó, jó, de ott volt a szmájli. Sokaknak van jogosítványa, de kevés a F1 pilóta.
Valójában a szemléletet és a gondolkodásmódot, sőt a problémamegoldást is meg lehet tanulni. Aztán lesz olyan, akinek van oklevele, meg olyan is, aki meg is tudja csinálni. Esetleg oklevél nélkül is. Talán ézért volt jó 30 éve minden számítóközpont vezetője gépészmérnök. :)

A gondolkozást eleinte nem lehet megúszni. Aztán - egy adott körben - minden probléma kezd egyformává válni. Persze csak annak, akinek elegendő gyakorlata van.

A matektanárbácsi állítása nettó marhaság, mert csak a primitív függvényekre igaz. Ha ezt lefordítod az IT környezetre, akkor mindig igaz az, hogy bármely problémát a számítógép bekapcsolásával és egy dobozos szoftver felrakásával meg lehet oldani. Aztán mégse. ;)

A rendszer kérdése nem olyan bonyolult. Pontosan az, amit átveszel üzemeltetésre és működteted.
(Az "ügyviteli rendszer" az csak egy program.)
A leírt szép vindózos példák csak a trehány, (és a trehány) operációs rendszerhez nem illeszkedő programokat jellemzik. Bár Windows alatt nem üzemeltettem még, de ott is tudnám mi a teendő.
Én is írok egy példát - itt én voltam néhány alrendszer fejlesztője és a teljes rendszer üzemeltetője is. Jött az ifjú titán:
- Elkészült a program, leteszteltem 50.000 rekordra. Hibátlanul működik.
- Gratulálok! Jót programoztál a pécéden. Sajnos nekem időre kell futtatnom, mind a 10.000.000 rekordon.
Ebből annyi a tanulság, hogy az a bizonyos "unit test" az ilyen programozókat támogatja. A példa néhány szarvashibát mutat, hiszen a feladat adott:
- A teljes adatmennyiségre el kell végezni a feldolgozást. Itt ugye előfordulhatnak az 50.000-es mintában elő nem forduló adatok is.
- A programnak adott időn belül kell lefutnia.
- A fenti időérték a többi alrendszer terhelése mellett is követelmény, tehát azt valós üzemi körülmények mellett is teljesíteni kell.
- Ezért az éles rendszeren végzett teszt nélkül még nem tudunk semmit.
Ennek a fejlesztői nyilván tudják, hogy mit kell a programmal csinálni. Milyen futtatókörnyezet kell, milyen adatbázis kell alá, mit kell a konfigba módosítani, ha más verziód van, hogyan kell backupolni, stb.
Hát nem. Az "... adatbázis kezelő rendszer" csak egy szoftver. Ha megfogalmazol benne egy feladatot, még akkor is jobbára csak szoftver. De amikor az adott (virtuális) gépre kerül, akkor már rendszer lesz belőle. Ha nincs megadva, akkor itt lehet kialakítani a mentési rendet, a rendelkezésre állást, a kívánt performace-hoz szükséges hangolást. Hogy mondjak egy hasonló példát, a mentés nagyon sok esetben kiválóan működik. Viszont láttam már több esetben, hogy a visszatöltés már komoly agytornát okozott, hiszen ennek a kivitelezésére még senki sem gondolt. :-D
Az üzemeltető dolga az, ... hogy összekapcsolja más rendszerekkel (pl. email)
Ha van ilyen tulajdonsága az adott rendszernek, akkor igen. Az "egyszerű üzemeltető" soha nem tehet ilyet.
Az ilyen eseteket úgy szoktam kiküszöbölni, hogy mindig a valós körülmények között (saját rendszeren) tesztelt alkalmazást helyeztem üzembe. (Rendszer leírással és üzemeltetési dokumentációval.) Ha módosítani, esetleg javítani kellett valamit, akkor ugyanez volt a path. Az üzemeltetőnek nincs lehetősége a leszállított rendszert módosítani, még akkor sem, ha a programok java része script.

A programozó ÉS rendszergazda szíve csak egy irányba húzhat: A feladat optimális megoldása. Az a baj, ha csak az egyikhez ért és közben minkettőt csinálja.

A bonyolult kérdésre csak egy megoldás létezik: az alkohol. A történéseknek nem lehet olyan kostellációja, hogy a piámat ott kelljen hagynom! Sem azért, mert fejreállt a rendszer, sem azért, mert nem jól működik. (Ez csak fiatalabb koromban volt így. A megbízható működés maradt, a pia meg már elmaradt. :))

Én, mint rendszergazda, az ilyen rendszert sem szeretem, mert nem látok bele, nem tudom hogy működik, továbbá a fentebb felsorolt dolgokat feltételezem, ennél fogva maximálisan bizalmatlan vagyok vele, lehetőleg agyontűzfalazom, kiteszem egy külön subnetbe, és mindent megteszek, hogy a lehető legkevesebb köze legyen ahhoz a részhez, amiért én felelek. :)
Ha pedig bevezetés előtt kérdezik ki a véleményem egy ilyen csomagról, akkor inkább azt mondom, hogy nem.
--
"Sose a gép a hülye."

Mármint az alkohollal hajtott rendszerre gondolsz? ;)

Vagy arra, hogy a teljes rendszerleírással, üzemeltetési dokumentációval (és forráskóddal) szállított, beüzemelt rendszer, (amely mondjuk csak az ssh porton keresztül dolgozik, de ez csak példa) számodra megbízhatatlan?
És legszívesebben össze-vissza állítgatnád, átírnád, de nem olvasod el a dokumentációt, amely minden esetre leírja mit kell tenned?

És hogyan "tűzfalazod agyon" és "teszed ki subnetbe" a meglévő tűzfalakon belül 16 routert tartalmazó hálózatot, meg a 10 szervert a 4 telephelyen? (Amiket a hozzáértők megterveztek és üzembe helyeztek.)

Talán most fog leesni a "rendszergazda" és az üzemeltető, illetve a "csomag" és a rendszer közti különbség?

Arra, hogy te mint fejlesztő, az egyszerű windows-os példánál maradva, ha úgy terjeszted a rendszert, hogy adsz mondjuk egy virtuális gép imaget, ami kész van, be van állítva, működik, és nekem nincs hozzáférésem, csak annyit tudok róla, hogy mi az ip-je, melyik portot kell a kliensbe beállítani, akkor nekem rögtön a felsorolt dolgok fognak eszembe jutni. Azaz:
- jó eséllyel egy régi, nem updatelt rendszer
- valószínűleg soha nem is lesz updatelve, max. akkor ha mondjuk a programodnak kell valamiből frissebb (db backend, .net, akarmi)
- tűzfal, uac, frissítések letiltva
- a db, a szoftver backendje vagy ütemezett feladatai legalább Rendszergazdaként, de inkább SYSTEM-ként fut, mert úgy a biztos
- a db-nek default jelszava van, vagy ha nem, akkor is be van égetve a binárisba, szóval esélytelen cserélni
- a megosztáshoz mindenkinek full joggal van kiadva, mégjobb esetben a C$ is ki van publikálva

A szeparációt nyilván a lehetőségekhez képest oldom meg. Ezt hol jobban, hol kevésbé lehet megcsinálni.

Más: ha az általad leírt rendszert, az általad adott dokumentáció alapján az üzemeltető üzemelteti, akkor mit csinál a rendszergazda? Szóval ezt a logikát nem értem.

Csomag és rendszer: kinek a szemszögéből? A te szemszögödből a te általad adott szoftver a szükséges környezettel és komponensekkel a rendszer, az én szemszögömből meg az az egész infrastruktúra, ami az én felelősségem.

Vagy most nagyon elbeszélünk egymás mellett?

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

Igen, nagyon elbeszélünk. :)
adsz mondjuk egy virtuális gép imaget, ami kész van, be van állítva, működik, és nekem nincs hozzáférésem
Ezt csak gondoltad, de semmi ilyesmit nem írtam.
Most meg jön a magánvéleményem, ami elfogult, meggyőzni nem lehet. :-D
Windows szervert nem igazán tudok elképzelni. Ha kénytelen lennék, akkor is IBM leírásokból dolgoznék, mert azok a legpontosabbak. Tökéletes kivitelezéshez és közben egy-egy probléma megoldásához a végeláthatatlan KB láncon végigrágva magam eljuthatnák az esetleg/talán/hátha megoldáshoz. Az ilyen nem üzemeltethető. Tehát windows környezetben nem üzemeltetnék, nem vállalnék érte felelősséget.

A (windows ??? - nem) rendszergazda - junikszul system administrator ;) - az operációs rendszer kezelését és testreszabását, az alkalmazások installálását, az erőforrások kiosztását és hangolást végzi. Az üzemeltetőnek soha nincsen jogosultsága programot felrakni.

Az üzemeltető az üzemeltetett rendszer (azért írok rendszert, mert a rendszeradminisztrátor kialakította az operációs rendszer, az üzemeltetett rendszer, az erőforrások és a biztonság összhangját) kezelését végzi. Úgy mint a dokumentáció szerinti paraméterezés, naplók, erőforrások monitorozása. Péladként: Tartja a kapcsolatot a rendszergazdával, jelzi pl. az esetleges erőforrás igényt.

A jogosultságok és feladatok ilyen szétválasztása mellett külön fejezetet érdemelhetne a sudo parancs, ami szerintem azért alakult ki, mert a linuxon még nem volt/gyerekcipőben járt az acl. Ugyanakkor a windows jogosultságok más elvek szerint készültek. Biztosan jó, de bonyolult rendszer, mert több szakembert láttam, akinek beletörött a bicskája.

Szóval ezt a logikát - amit nem értesz - nagy cégek egyértelműen így írják elő. Bármilyen ötletszerű szeparáció felesleges, mert azt már a rendszer biztonságának tervezésekor megadják.

Csomag és rendszer: kinek a szemszögéből? A te szemszögödből a te általad adott szoftver a szükséges környezettel és komponensekkel a rendszer, az én szemszögömből meg az az egész infrastruktúra, ami az én felelősségem.
Így is igaz. De! Ha csak egy szoftver csomagot adok át üzemeltetésre, akkor sem sérthetem meg a teljes rendszer biztonsági vagy erőforrás gazdálkodási elveit. Tehát hiába én vagyok a rendszergazda, és én üzemeltetem, és én írtam a szoftvert is - nem engedhetek a szabályokból. Tehát a szoftvercsomagnak pont úgy kell felkerülnie, mintha egy idegen szállította volna.

Szoftvert mindig úgy szállítottam, hogy az install csomagot a rendszergazda - leírás alapján - felrakta. Adott esetben voltak benne olyan szerver komponensek, amik magasabb jogosultságot igényeltek. Ha ehhez az üzemeltetőknek is hozzá kellett férni, akkor egyeztetés után kaptak hozzá jogot. A (biztonsági) frissítés/nem frissítés kérdését külön megtárgyaltuk, írásba foglaltuk. (fejlesztő==üzemeltetői szint <-> rendszergazda)