Hogyan nevezik ezt a pozíciót?

Közösségi kerekasztal

Keresek egy jó nevet egy rendszergazda-közeli fejlesztői pozíciónak, ami igazából a következő feladatkört takarja:

- van egy csomó rendszer (képzeljetek ide különféle storage-okat, szervereket, adatbáziskezelőket, virtualizációs rétegeket, custom alkalmazásokat, monitoring rendszert, deployment rendszert stb. - a lényeg hogy sok és diverz rendszerről van szó), amelyek valamilyen módon, valamilyen API-n keresztül megközelíthetőek és róluk információ nyerhető ki/számukra utasítás adható
- ezeket a rendszereket, API-kat, valamint a rendszerekhez tartozó munkafolyamatokat meg kell ismerni és a rendszerek frissítéseivel együtt járó változásokat követni kell
- fejleszteni kell egy weboldalt, ahol az igényeknek megfelelő módokon vizualizálhatóakká válnak a rendszerekből kinyerhető adatok és egyetlen egységes felületen utasítások is adhatóak a változatos rendszereknek

A lényeg, hogy egy halom olyat kell összereszelni, hogy pl. a weboldalon megkattintom, hogy "legyen még egy virtuális gép ezekkel a paraméterekkel", ami alapján a rendszer a VMware perl vagy PowerShell API-ján keresztül ezt megcsináltatja a rendszerrel. Vagy ha ugyanezen a weboldalon megkattintom, hogy "másold le az éles adatbázist egy teszthez", akkor csináljon dumpot a PostgreSQL-ből, majd csináljon restore-t valahova máshova. Ilyesmi jellegű munkafolyamatból van vagy százféle - ezeket kell megvalósítani.

Hogy hívják az ilyen embert?

Nem igazán rendszergazda (ahhoz túl sokat kell programozni és túl keveset tökölni rendszerekkel), nem igazán fejlesztő (ahhoz túl sokat kell rendszergazdálkodni és túl keveset programozni), nem igazán folyamatszervező (annak se programozni, se rendszergazdálkodni nem kell). De nem is igazán a manapság népszerű devops engineer az illető, nem feladata a jellegzetes "konfig menedzsment" témakör. Angol nyelven betippelnék egy "orchestration engineer" nevet a pozíciónak, de magyarul elég rosszul hangzik az "orkesztrációs mérnök" - az emberek azt hinnék, hogy valami gyanús, végbélkörnyéki orvosi dolgokkal foglalkozik az emberke.

Szóval minek nevezzelek?

( traktor | 2014. 07. 28., h – 17:57 )

Szerintem ez "rendszerintegrátor" munkakor (System-integrator). Legalabbis a leiras nagy reszere ez igaz. Az emlitett "keszitsen weboldalt..." resznel viszont elbizonytalanodtam. Ha tenyleg nullarol meg kell irni egy csili-villi weboldalt akkor ez a csavo rendszerintegrator-webfejleszto lesz. ;) De ha kesz elemekbol kell osszerakni es az osszerakas kozben kicsit scriptelni, akkor az tisztan rendszerintegratori munka.

Viszont az kerdeses, hogy ha kiirsz igy egy poziciot, akkor a megfelelo emberek ra fognak-e ismerni, hogy mi ez. Ugyanugy ahogy te se tudod megnevezni ok is bizonytalanok lesznek akarhogy is nevezed. Es rossz esetben nem kattintanak, nem olvassak el a reszleteket majd....

En is voltam hasonlo bajban, mi egykor "fejleszto-rendszergazdanak" hivtunk egy hasonlo poziciot (csak hasonlo volt!) egy allashirdetesben ha jol emlekszem, ami nem jelent semmit. :)

Igen, nulláról kellene írni weboldalt. Léteznek kész keretrendszerek, amelyek használhatóak lennének (pl. a HP Operations Orchestration vagy minek hívják), de megnézegetve őket a konkrét esetben olcsóbb lenne embereket (igen, többet, úgy hármat) felvenni, mint az eszközt használni és testreszabni. Ennek az az oka, hogy a kész eszközök egy halom olyan dologra vannak kihegyezve, ami nekünk nem kell, és egy csomó mindent nem tudnak, ami viszont kéne. Meg lehetne valósítani velük mindent, de túl sok megkötéssel és nyűggel járna.

Létezik ilyen emberke, bár nem teljesen értem a dolgot: ilyen melót általában projektalapon, külső vállalkozóval szokás csináltatni, aztán ő oldja meg, hogy hány emberből rakja össze.
És aki a fentieket egy személyben, séróból megcsinálja, az nem is lesz olcsó alkalmazottként. Vagy lehet olcsójánoskodni, és felvenni valami lelkes ifjú titánt, aztán örülni vagy szomorkodni.

A külsős azért nem jó megoldás, mert mindezt folyamatosan karban kell tartani (pl. ha lecserélem a VMware verziót 4.1-ről 5.1-re, akkor változik, hogy hogyan kell beállítani, hogy egy multipath device-nál hány IO műveletenként váltson path-t - ezt le kell követni, jól), valamint mindig lesznek új dolgok, amiket még bele kell vezetni stb.

Az egyáltalán nem fontos, hogy séróból megcsinálja az emberke ezeket, nyilván nem is lehet elvárás, hogy ismerje 30-40 rendszer API-ját (főként, hogy van közöttük egy halom belső fejlesztés), az elvárás az, hogy ezeket meg tudja tanulni záros határidőn belül. Az sem fontos igazán, hogy miben kódol, nem a perl nyelvi rejtelmeinek mély átlátása a feladat, hanem tök alapszintű perl, python, "ssh-n át elérhető custom cli expect-tel" stb. használatára való hajlam.

En a komplett, 0-rol megirt web alkalmazast meg az integracio tobbi reszet akkor is szetvalasztanam. A webalkalmazast kicsit ugy kezelnem mint egy termekfejlesztest, az legyen megtervezve, stb. Bizonyos szinten a rugalmassagot is bele lehet tervezni. Ha valaki nem szaki all ennek neki, abbol nagy kokanyolas lesz es akkor persze tenyleg olyan lesz a kod amit muszaj nap mint nap modositgatni... Meg amugy is nyilvan nem ugyanannyi munka lesz ezzel az elso 6 honapban mint utana. Lehetne esetleg egy fel evre alkalmazni kulsos ceget vagy szakit (kulsos cegtol is lehet forraskodot, meg dokumentaciot kovetelni, ugyhogy en ebben nem latok nagy kulonbseget).

( Zsugabubus | 2014. 07. 28., h – 18:35 )

Százféle ilyen folyamat? Egy ember, mire mindezt lefejleszti, kezdheti elöről az egészet :)

( XMI | 2014. 07. 28., h – 18:41 )

Pedig szerintem devops eleg jo kozelites.

BTW: amugy olyasmit akarsz kifejlesztetni az illetovel, amire vannak kesz toolok? Ingyenes opensource es fizetos is. Amit leirtal elegge ugy hangzik, mint egy IaaS cloud + valami alkalmazas management reteg (puppet, chef, ansible whatever).
---
Régóta vágyok én, az androidok mezonkincsére már!

Szerintem ez pont nem devops, mert a devops azt jelenti, hogy a fejlesztő üzemelteti a saját cuccát. Itt pedig az üzemeltetők keze alá kellene fejleszteni rendszereket.

Frappáns elnevezést én se találtam rá, mindenféle szörnyszülött elnevezések jutnak csak eszembe. Szóval én simán csak fejlesztőnek nevezném a pozíciót, vagy pl. java fejlesztőnek, ha java alapú webservice-t kellene tákolni. Aztán a szövegben kifejteném, hogy mi is itt a feladat.

Ok, en kicsit forditva kozelitettem meg.
Nem azt, hogy mi lenne ennek a pozicionak a neve (teljesen jol illeszkedo neve ugysem lesz), hanem hogy mit kene kiirnom egy allashirdetesbe, hogy olyan embert talaljak, aki kepes lesz mindezt megcsinalni.
---
Régóta vágyok én, az androidok mezonkincsére már!

Nem egészen.

Az összes ilyen tool mindenféle "modern" infrastruktúrákra van kihegyezve, aminél szempont volt, hogy jól menedzselhető legyen. Nem (csak) ilyesmikkel kell foglalkozni, hanem rengeteg olyasmivel, ami pl.:

- ssh-n at386-os terminált emulál neked egy program, amiben egy menürendszer érhető el, meg kell nyomni sorban az 1, 2, 4, 3 gombokat, oldd meg (pl. expect-tel meg lehet csinálni)
- VMware-ben keresd meg az orphan .vmdk-kat, tessék itt van hozzá egy Powershell forrás, nézd meg hogy kell, oldd meg
- a belső fejlesztésű rendszerről csinálj úgy mentést, hogy egy webservice-t meghívsz (miközben kliensoldali certtel authentikálod magadat), ezzel szólsz az alkalmazásnak, hogy "mindjárt elmentelek", csinálj LVM snapshotot, majd egy másik webservice hívással szólj, hogy "akkor el vagy mentve", majd a snapshotot tartalmának felét másold át a backup storage-ra és a custom backup storage adatbázisba regisztráld fel, hogy ott van a cucc

Ha az illető ezekhez mindhez ansible playbook-ot akar csinálni, akkor ám legyen - de egészen biztos vagyok benne, hogy nincs egyetlen tool, ami mindezeket összefogná szépen.

(És igen, ezeket mindet meg lehet csinálni, és létezik olyan ember, aki mindegyiket meg tudja oldani.)

Ok. A leirasbol (postgres pelda) azert nem teljesen erre asszocialtam. :)
Egyebkent fenntartom, hogy ez tobbe-kevesbe cloud management rendszernek valo feladat, csak nem olyannak, amiket felsoroltam. (Hanem olyannak aminek a fejlesztese a munkam :) - igen, tudom, hogy ez mind lehetseges, mert pont ilyen problemas alkalmazasok integralasaval foglalkozunk). Application Integration Engineer esetleg lehet egy jo elnevezes.
---
Régóta vágyok én, az androidok mezonkincsére már!

Ez nekem developer poiznak tűnik (mondjuk Java dev), akiknek mint domain szakértők ott vagytok ti. Főleg, mivel ti vagytok a "megrendelők", vagyis azok a munkatársak, akik ehhez értenek. Ti tudjátok megfogalmazni azt, hogy mire van szükségetek, ő meg le tudja fejleszteni a megadottak alapján. DDD, mint Domain Driven Design (inkább kódszervezés, de elég jól leírja azt is, hogy a domain-expertek és a fejlesztők mennyire együtt kell dolgozzanak) tanulmányozását tudom ajánlani.

De szvsz gyakorlatilag bármalyik komolyabb Java dev emberke hasonlókat csinál (csináltam én is, de még nem merem magam "komolyabb Java dev embernek" hívni :)), csak esetleg nem terminál emulációval, hanem webservice-kel. De a protokoll egy szint után ugye mellékes.

Pedig nagyon hálátlan feladat ilyen integrációs munka. Ugyan nem infrastruktúrát integrálgatok, de borzasztó fárasztó munka. (ERP rendszereink, webshopjaink közötti kommunikáció, hol különféle SOAP, hol meg kell kerülni, két a,gyari csatoló kevés, hol partnerekkel kell a legkülönfélébb módon adatot cserélni, stb.)

Megvan a maga szépsége is és, ha az ember megcsinálja a maga kis keretrendszeret, vagy talál megfelelőt, akkor egész rutinszerűen lehet csinálni, ameddig nem jön valami vicceskedes.

Viszont ez meg mindig sima szoftverfejlesztoi munka. Nem ertem, hogy miert akarjak egyesek olyan "hu, de" dolognak beállítani, mert több kutatómunkával jár, mint egy n+1. blog oldal létrehozása.

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

Talán épp azért "hu, de" dolog egyesek szemében, mert jobban szeretik a kutatómunkát, mint a fejlesztés egyéb feladatait.
Én is csak addig élveztem a programozgatást, amíg valami újat tanulhattam. Ha már használni kellett (pontosabban újra használni), az már unalmas volt.

Sima programozónak azért nem nagyon tudnám odaadni ezt, mert nem "szép" SOAP kommunikáció van a legtöbb helyen, hanem igenis tákolni kell, mert a kezelendő rendszer csak valami archaikus módon érhető el. Ha egy programozónak azt mondod, hogy rsh-n kell belépni a gépre, többnyire kiröhög és követeli a SOAP interface-t... :-)

Szvsz nem megy segélyre, hanem olyan munkát vállal, amihez jobban van kedve / lát benne értelmet. Egyáltalán nem hátrány, hogy nem kell bármit elvállalni, mert találni helyette jobb ajánlatot. Ha más szakmában is válogatósabbak lehetnének / lennének a munkavállalók, akkor ott is jobban megfizetnék őket.

Ha más szakmában is válogatósabbak lehetnének / lennének a munkavállalók, akkor ott is jobban megfizetnék őket.

Amikor egy álláshelyre legalább 10-15 fő jelentkezik? Sajnos nem a munkavállalóknak van lehetőségük válogatni, tehát a feltételeket se ők szabják. Persze lehet választani: (viszonylag) kevés bérért munka, vagy pedig három hónapig segély, utána meg... Aki meg válogatós, ne csodálkozzon, ha nem válogatják be :)

Nekem is volt ilyen időszakom. Egy ideig megvolt a fun faktor. De amikor néhány helyen bedőlt valami és azonnal csodát kellett tenni, ott már túl stresszes volt. Főleg, miután rájöttem mennyi helyen lehet még probléma és nem egy ember, hanem 5+ ember is simán el tudná tölteni a megoldandó feladatokkal az időt hónapokon - éveken át. Inkább elköszöntem, mert nem hiányzott, hogy lassan rám boruljon a vár. Igaz ebben az is benne volt, hogy főállás mellett, nem pénzért végzett munka volt, ellenben mindenki elvárta, hogy mindig azonnal megoldódjon minden. Ilyen a kollégiumi mindenes rendszergazda élete. Csak hw/sw, kliens/szerver, vezetékes/wifi hálózat, dolgozók/hallgatók minden baja tartozik hozzá a szoftverfejlesztés mellett :D Ott aztán volt sokféle egyedi fejlesztésű szoftver, amik így vagy úgy, de együttműködtek.

Ennek semmi köze az "ops" részhez önmagában. Nem ő üzemelteti a rendszereket, csak egy toolt készít hozzá.

Ha mondjuk iskolaadminisztrációs rendszert fejlesztek, akkor szoftverfejlesztő-tanár lesz belőlem? Nyilván nem, de attól még vannak dolgok, amiket meg kell ismernem ahhoz, hogy el tudjam végezni a munkám.

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

( ncc1701 | 2014. 07. 28., h – 18:54 )

Mindenes.

Vagy bölcsész mérnök. :)

Szerintem tudástól függően olyan 300-600e Ft bruttó fizetés között lehet ezért elkérni. Duplázd meg, ha az is feladata az illetőnek, hogy kitalálja, hogy mit kell csinálni, és nemcsak végrehajt.

Nálunk egyébként nincs ilyen pozíció jelenleg, és fogalmam sincs, hogy lesz-e, azt meg pláne nem tudom, hogy mennyit fizetne ezért a cég.

Szerintem 300-600k bruttó között nem találtok olyat, aki tapasztalt és meg is tudja ezt csinálni. A duplájáért már valószínűleg igen. Egyébként "hogy kitalálja, hogy mit kell csinálni", ennek nincs sok értelme, ugyanis aki ezt a részét nem tudja megcsinálni, az igazából nem alkalmas a feladatnak a kódolási részére se. Szerintem.

( uid_20269 | 2014. 07. 28., h – 21:01 )

Amikor utoljára találkoztam ilyen munkával, akkor még Két Munkakört Egy Fizetésért volt a neve..

God bless you, Captain Hindsight..

( seferbt v | 2014. 07. 28., h – 21:06 )

"Fedettpályás távolbalátó" esetleg IT-s mindenes, egyébként szerintem a rendszerintegrációs mérnök lenne talán a leginkább találó, de google translate után szabadon a hangszerelő mérnük is szóba jöhet. :)

( uid_7086 | 2014. 07. 28., h – 21:22 )

Güzü esetleg? :)
(a dehonesztáló jelzőket, ha mindezt egyszemélyben bevállalja... azokat inkább megtartom magamnak. ;)) )

Arra próbáltam célozni, amire a többiek is: szerintem ez sok egy embernek. Túl szerteágazónak tűnik.

Újra átfutva a leíráson: minimum egy vezető, aki összefogja az emberek munkáját, egy szervező - aki mellesleg designerként is képes működni -, egy programtervező, programozó és egy üzemeltetésben jártas ember kellene, ha profi munkát szeretnél.

Egy emberrel is meg lehet oldani, csak sokáig tart és később ki fognak derülni komoly hiányosságok. Szerintem.

Azt hiszem, hogy az a dolog titka, hogy nem profi munkát szeretnék. Pl. semmi szükség arra, hogy szépen skálázódjon egy webes alkalmazás, ha egyszerre 2 ember nyomkodja csak. Nem kell csillivilli dizájn, ha a célközönség pár, kevés szépérzékkel megáldott személy.

Pedig ez nem jó hozzáállás.

Ha az Amazon fő designere vagy, akkor nyilván érts hozzá nagyon, legyen az életed az, ha 3 pixellel elcsúszik a design. De ha egy belső használatú rendszert tervezel csak IT-sok számára, akkor bőven sok, ha egyszer elolvastad a "Don't make me think!" című könyvet. Az utóbbi pedig pár óra alatt teljesíthető :-)

Az a baj, hogy ez pont az a munka, amit nem lehet nem profin csinálni, vagyis lehet, de nem éri meg. Mert ha az elején rosszul tervezed meg akkor később iszonyat nehéz lesz egyben tartani az egészet. A feladatnak az a nehézsége, hogy nagyon sokféle dolgot kell nagyon sokféle protokollon csinálni, nehezen húzható rá egy standard réteg. Ha viszont nincs egységesítés, akkor mind a logikában, mind a megjelenítésben tele kell rakni elágazásokkal, kivételekkel. Én mindenképp kétfelé szedném a feladatot, a különböző protokollokat, és funkciókat egy ember fejlesztené, egy másik, meg a felületet, és az adatmodellt, tárolást stb. Az a baj, hogy ha te szeretnéd házon belül csinálni, akkor nem tudsz annyit fizetni, hogy jó szakembert találj. Fejleszd le külsősökkel, vegyél tőlük supportot,amiben van x óra követés, fejlesztés van, és hosszú távon olcsóbb, és jobb minőségű dolgot fogsz kapni, mint ha magad csinálnád.

( agoston | 2014. 07. 28., h – 22:10 )

Csoda. Vagy "ilyen nincs"
Aki mind ezekhez ért és össze tudja rakni, tuti hogy nem fog 8 órában elmenni dolgozni sehova. Bár ha az említett pénz duplája környéket nettóban megajanlod, akkor kezdenek egy picit nőni az eselyeid

Szerinted lenne a piaca a sokszorosába kerülő kész megoldásoknak, ha mindezt egy ember - a kívánalmaknak megfelelően (stabilitás, ergonómia, skálázhatóság, support..stb.) - össze tudná rakni?
Akkor lenne 100 ilyen, töredékébe kerülő megoldás, amik közül választhatnál.

Ne vedd sértésnek, de már maga a topic-indító hozzászólás (az, hogy a névválasztáson megy a polémia) sem túl biztató a projekt jövőjére nézve.

fentebb azt irtak, hogy a kivanalmak nem annyira erosek. Masreszt a kesz megoldasok egyik hatranya pont az, amit irtal: sokszorosaba kerul. Ugy latszik, hogy zizieknel ez (is) szempont. Persze, van ahol siman kicsengetik a suskat egy kulcsra kesz megoldasra, bar naluk tul sok legacy hack lehet...

--
"A politikat, gazdasagot es a tobbi felsorolt faszsagot leszarom, amig engem nem erint (nem erint)" (bviktor)

Amit szeretnék, arra egyszerűen nincs kész termék, éppen a sok legacy megoldás miatt. De igazából a modernebb cuccokra sincs jó kész termék, pl. a VMware és a PostgreSQL menedzsmentjére egyszerre alkalmas eszközt nem nagyon találtam fizetőset sem, pedig nálunk van VMware is és PostgreSQL is (meg még úgy 100 másik technológia).

Szerintem bőven van alkalmazott mentalitással is. Én pl. alkalmazottként is csináltam rengeteg, önmagában viszonylag egyszerű kis célszerszámot, vagy a saját munkám megkönnyítésére, vagy a mások munkáját segítendő. Vagy épp először magamnak csináltam aztán mások is rákaptak, és egy szükség hozta tákolásból lett egy sokak által használt szerszám.

Az említett összeg tényleg vicces kissé, bár a teteje környékén már kezd reális lenni. Ugyanis ez bőven nem junior munka, több területen több éves tapasztalat kell hozzá, és a dolgozó hozzáállásának is olyannak kell lennie, hogy ezt meg tudja csinálni. És szerintem az se árt, ha a saját bőrén tapasztalta már meg a "kétszer mér, egyszer vág" elvet...

Amúgy egyik haver munkahelyén is keresnek hasonló embert, a pozíció nevét nem tudom.

Miert van olyan érzésem, hogy a legtöbb informatikusnak szimplán büdös a munka es egy lusta dög ahhoz, hogy az osszekuporgatott minimal tudásán kívül egy picit is tanuljon új dolgokat?

Kurvara semmi extra nincs ebben a feladatban: adott rengeteg különféle tool, amit egy felületre ki kell vezetni. Ez advanked feladat egy átlagos szoftvermernoknek? Könyörgöm, hagyja ott a szakmát es húzzon el kapálni.

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

Abból, amit Zizi írt, ez nem (egy)embernek való munka.
Lásd minapi siránkozásod SOAP témában! Ha jól értettem, ott is a szabványok, azok betartásának hiánya volt a fő problémád. :)

A leírás alapján: adott egy évek óta gányolt, esetleg rosszul dokumentált szoftverhalmaz. Ebben kellene rendet csinálni és közös GUI-t illeszteni hozzá.
Csak mondjuk az egyik linuxos és C-ben írt, saját API-t használ, a másik windows-os C#, valamilyen szabvány interface-szel, a harmadikhoz neked kell kitalálni valami viszonylag biztonságos megoldást, mert csak parancssor van, itt meg egy webes felületről kellene rajta matatni.
És mindezt nem csak leprogramozni kellene, hanem meg is kell tervezni.

És itt nem arról van szó, hogy meg tudja-e csinálni valaki, hanem, hogy milyen minőségű lesz a produktum.
Mert gányolás szintjén én is el tudnám végezni fél-egy év alatt, ha jól sejtem. Csak hát...

Attól, hogy csak belső használatra, még nem kell összebaszottnak lennie, viszont vannak olyan szempontok, amiket valószínűleg nem kell figyelembe venni.

"Kösz, de nem szeretnék már fél évvel később sem ilyenhez hozzányúlni."

Itt meg arról van szó, hogy fél év múlva (is) ugyanazon a projekten dolgozik, csak maximum mást integrál hozzá. Ez egy folyamatos meló(nak tűnik). Nem tudom, hogy ebben mi a nagy wasistdas. Itt csupán arról van szó, hogy a jelenlévők nagy része irreálisan sokat gondol bele a feladatba és/vagy valami nagy multinál piszlicsáré feladatokért szakítja a nagy lét.

Vagy csak szimplán - mint ahogy az már itt több álláshirdetésnél kiderült - funkcionálisan analfabéta és képtelen elolvasni a hirdetés szövegét, ugyanis nem arról volt szó, hogy mindhez érteni kell, hanem arról, hogy valamit meg kell csinálni, amihez API-kat kell használni, amiknek utána kell nézni.

Legtöbb (magát) programozó(nak valló egyén) már kivágja a hisztit, ha két programozási nyelvet lát egy hirdetésben. Mégis mi a faszomért? Jelenlegi munkahelyemen főleg két nyelvet használok 3 féle adatbáziskezelő rendszerrel és sorolhatnám, hogy hány partner egyéb rendszerével van összekötve a mi szoftverhalmunk. Nem tudom, hogy akkor egyesek szerint ezt hány emberre kellene szétosztani, nálunk kettő fejlesztő van, illetve egy külsős IT üzemeltetés.

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

Attól, hogy csak belső használatra, még ugyanúgy nem szabad "összebaszottnak lennie". Szerintem. Nagyon másképp látjuk a dolgokat. Belső rendszernél az egyetlen, amiben hajlamos lennék engedményeket tenni, az a user interface és ha belefér az adott rendszer életébe, a rendelkezésre állás.
Minden egyéb téren épp olyan szigorú feltételeknek kellene megfelelnie, mintha külső userek felé lenne megnyitva.
(de ez messzire vezet)

Fél évet arra mondtam, hogy ha a saját, nulla tudással összekapált kódomhoz kellene fél év múlva hozzányúlni... (függetlenül a feladattól)

Én használtam elég sok nyelvet, önmagában a felhasznált programnyelvek számát ebben az esetben nem tartanám problémásnak, de a hirdetésből úgy tűnt, itt nem csak programozásról van szó, hanem a mögöttes rendszerek (esetleg rosszul dokumentált, gányolt rendszerek is képbe kerülnek) felderítéséről, megismeréséről, némi szervezői munkáról, kevés üzemeltetésről, programtervezésről stb.

Mert igen, először csak annyi az elvárás, hogy adj össze két számot egy weblapon és tárold adatbázisban az eredményt. De a tapasztalat azt mondja, ebből előbb-utóbb egy sokgépes clusteren működő raktári és számlavezető, munkaidő nyilvántartó és HR rendszer lenne, némi helpdeskes beütéssel. :D
(Ha emlékszel a Fekete macska c. filmben Major Tamásra: "... rád húzzák, ismerem őket!" ;) )

"Attól, hogy csak belső használatra, még ugyanúgy nem szabad "összebaszottnak lennie"."

Olvasd már el, hogy mit írtam: "Attól, hogy csak belső használatra, még nem kell összebaszottnak lennie, viszont vannak olyan szempontok, amiket valószínűleg nem kell figyelembe venni. "

Egy belsőleg fejlesztett rendszernél valószínűleg nem igény a könnyű tömeges deploy, hisz egyszer rakod fel. Vagy pl. elhagyható egy komolyabb konfiguráló felület/zeroconf (mert mondjuk az összes konkurenciád tudja), mert úgy is csak egyszer állítasz be valamit a konfig fájlba. Stb. Ettől még nem lesz összebaszott. Vagy, amit te is írtál: nem kell olyan túlzásba vinni az UI-t (ami egyébként egy piacra szánt terméknél fontos tényező.)

Másrészt, mivel jóval fixebbek a követelmények, megengedhető, hogy csak az itteni konfigurációval működjön. Attól még nem lesz valami összebaszott, hogy nem készíted fel olyanra, ami neked nem igény. Mittudomén, pl. AD integráció. Sok helyen kb. alapvető igénynek számít, hogy menjen LDAP-ből/AD-ből, neked mondjuk nem igény. Vagy fordítva, nem érdekel, hogy menjen önmagában is, mert AD-ből autholsz mindent.

"Fél évet arra mondtam, hogy ha a saját, nulla tudással összekapált kódomhoz kellene fél év múlva hozzányúlni... (függetlenül a feladattól)"

"mögöttes rendszerek (esetleg rosszul dokumentált, gányolt rendszerek is képbe kerülnek) felderítéséről, megismeréséről, némi szervezői munkáról, kevés üzemeltetésről, programtervezésről stb."

És? Komolyan és? Mindenki azon picsog, hogy jaj, de hát ez egy mérnökszakma meg blabla. Akkor tessék végre mérnökként viselkedni és felmérni, megismerni, stb., hogy miről van szó.

Dolgoztam már középiskolának fejlesztett rendszeren, e-learning rendszeren, webshopon, meg mindenféle backoffice dolgon. Hogy-hogy nem, utána kellett járnom bizonyos dolgoknak, hogy hogyan működnek ahhoz, hogy el tudjam végezni a feladatom.

"De a tapasztalat azt mondja, ebből előbb-utóbb egy sokgépes clusteren működő raktári és számlavezető, munkaidő nyilvántartó és HR rendszer lenne, némi helpdeskes beütéssel. :D"

És? Ebből melyik az, amit nem képes megfelelő információk birtokában egy ember elegendő idő rendelkezésre állása esetén lefejleszteni?

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

En akkor szegyelnem magam, ha azt gondolnam, hogy mindent meg kell csinalnom, amit talan meg tudok csinalni. Rendes munka csak olyanbol lesz ahol szakik dolgoznak. Persze menet kozben is lehet szakertove valni, azzal sincs baj, csak az eddigi hozzaszolasaidbol en azt latom, hogy nalatok erre nincs igeny. Ebbol pedig baj lesz. Nem feltetlenul ugy hogy osszeomlik minden. Talan inkabb csak ugy, hogy valahogy irdatlan mennyisegu maintenance feladat lesz nap mint nap. Az aprobb valtoztatasokhoz is a rendszer legmelyeig kell majd leturni, es persze addigra tenyleg csak az a par ember fogja tudni ezt karbantartani akik evek ota csinaljak. Lehet paran majd elgondolkodnak rajta, hogy vajon ez normails-e, de lehet, hogy nem fog feltunni senkinek es megeszi a management, hogy ez ennyibe kerul.

( AiRLAC v | 2014. 07. 29., k – 09:31 )

Senior Infrastructure Operations Engineer, nálunk így hívják :)

( uid_7086 | 2014. 07. 29., k – 12:22 )

Off: az első pontról valamiért az SNMP jutott eszembe... :)

( bzs v | 2014. 07. 29., k – 17:03 )

off

"egyetlen egységes felületen utasítások is adhatóak a változatos rendszereknek"

"Hogy hívják az ilyen embert?"

Dennis Nedry, és a Jurassic Park első részében tevékenykedett.

Szóval az ilyen embert meg kell fizetni. Univerzális embert univerzálisan

---
--- A gond akkor van, ha látszólag minden működik. ---
---

( uzsolt v | 2014. 07. 29., k – 18:42 )

A topik címe alapján rögtön RTFM, de utána elolvastam a pontos specifikációt, és rájöttem, hogy nem a megfelelő szakirodalmat ajánlanám.

( derWRK | 2014. 07. 30., sze – 02:02 )

off:

Ilyenkor azt nem szoktam érteni, hogy alakulnak ki ezek a kezelhetetlen rendszerhalmazok? A cég megvárja a kritikus pontot amikor az adminisztráció már elviselhetetlen? Egyébként szerintem is praktikusabb lenne két ember, egyszerűen azért mert egy embernek valakinek végig fognia kéne a kezét a cégtől az adminisztrációs szokásokkal, és az üzemeltetés jelenével kapcsolatos kérdésekben (tippre nincs minden jól dokumentálva és szabályozva, különben már amikor csak 5 külön rendszer volt felmerült volna egy egységes api igénye) , és gondolom nem azért akartok embert felvenni, mert olyan sok a ráérő szakember a cégnél...

Nekem viszont a feladatleirasbol ugy tunik, hogy van ilyen "masodik ember", akar tobb is, hiszen valakik csak uzemeltetik most a rendszereket. A feladat arrol szolna, hogy ezt az uzemeltetest kellene egyszerubbe, "egykattintasossa" tenni.

A kezelhetetlen rendszerhalmazok meg gondolom ugy keletkeztek, hogy gondolom eddig is kezelhetoek voltak, csak szeretnek egyszerubben kezelhetove tenni. Ld. mondjuk egy CLI-s LVM tool vs egy grafikus. Elobbinel lehet, hogy ismerni kell 10 fele parancsot, utobbinal csak kattintani es mondjuk egy csuszkat huzigalni.

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

Ez tényleg off, de...

Ha egy céghez új ember kerül, akkor nyilván nincs tisztában a céges filozófiával, politikával, szabályzatokkal, sem a hivatalos, sem a nemhivatalos értelemben véve. Ilyenkor jó esetben kap egy halom olvasnivalót (szervezeti felépítéses ábra, IT biztonsági szabályzat, ilyesmik), hogy ezeknek a hivatalos oldalát megismerje. A valódi, nemhivatalos viszonyokat viszont úgyis csak idővel fogja átlátni az ember, miután sokakkal beszélgetett mindenkivel.

Tapasztalatom szerint a "mentoros" megoldás csak akkor hasznos, ha a mentorra hasonlító embert akarsz nevelni az új kollégából. A nemhivatalos "erőviszonyokról" ugyanis mindenkinek más és más képe van a cégnél és ha csak egyféle nézetet kap erről az ember, akkor nincs lehetősége saját, informált véleményt alkotni.

Persze hosszabb távon úgyis saját véleménye lesz, de szerintem nem jó az elején (meg később se) torzítani az emberek önálló nézeteit.

Mindegy, tényleg off...

Vagy hatan megkerestek magánban, hogy akkor jelentkeznének - nekik is mondanám, hogy ez nem egy állásajánlat, ahol én dolgozom, ott tudtommal nincs kiírva ilyen állásajánlat és fogalmam sincs, hogy akár nálunk, akár máshol lesz-e ilyen pozíció. A topic arról szól, hogy hogyan neveznétek el egy ilyesmikkel foglalkozó ember számára kiírt pozíciót...

Lehet hogy automation engineer-t keresel? (Ha egyáltalán van ilyen). Kötelező olvasmány a témában: http://www.redhat.com/f/pdf/summit/mstahnke_1_managing_infrastructure.p… Esetleg megkérdezheted a szerzőtől mit gondol erről :) https://twitter.com/stahnma

Annak idején ha nézted a faliújságunkat innen elég sok idézet volt ;-)

Szerintem is.
Magyarul (bár nem értem az erőltetését, mert így nem találnak rá akik tudják hogy bizonyos IT dolgokat magyarul is angol nevén hívunk): üzemeltetés-automatizációs mérnök.

Amúgy lehet félreértem a feladatot, de ha már a HP SA árát sokallja a topik indító, akkor miért nem chef/puppet? Ha meg kattingatós weboldal kell, akkor crowbar (chef nyakában). Így leegyszerűsödne, hogy egy olyan devops-ot keresünk, aki inkább dev, mert csak cookbook gyártás lenne a feladata, viszont nem árt ha átlátja az infrára gyakorolt hatást.