DevOps mérnök

 ( profession | 2017. június 23., péntek - 16:19 )

Az NXLog Kft magyar tulajdonú startup vállalkozás. Elsősorban információbiztonsággal kapcsolatos szoftverfejlesztéssel és szolgáltatással foglalkozunk.

https://nxlog.co

Nemzetközi csapatunkba keresünk

DevOps mérnök

munkakörbe agilis munkatársat.

Főbb feladatok, munkák:
◾A munkakörbe tartozna a szoftverfejlesztés támogatása, integráció különféle megoldásokkal, tesztelés és hibakeresés, ügyfél támogatás.

Az álláshoz tartozó elvárások:
◾Linux/Unix környezetben szerzett üzemeltetői gyakorlat mellett a vállalati Windows rendszerek ismerete.
◾Valamely szkript nyelv (shell, perl, python, powershell, stb) ismerete.
◾Informatikai biztonsági alapismeretek.
◾Szakmai angol nyelvtudás

Az állás betöltéséhez előnyt jelent:
◾Virtualizációs és konténer megoldások (VMWare, KVM, Docker, LXC, stb) ismerete.
◾SIEM, naplózás és log menedzsmenttel kapcsolatos tapasztalat.
◾Verziókezelok (SVN, Git, stb.) használata.
◾Csomagkezelő rendszerekkel szerzett fejlesztési tapasztalat (deb, rpm, msi, stb telepítő csomagok készítése).
◾CI eszközök (buildbot, jenkins, stb.) ismerete.
◾Konfiguráció menedzsment eszközök (Chef, Ansible, Puppet, stb) ismerete.
◾Unix (AIX, Solaris, HP-UX, BSD) rendszereken szerzett tapasztalat.
◾Open Source projektben való részvétel vagy közösségi munka.
◾Jó dokumentálási készség (rendszer-, felhasználói dokumentáció).
◾Önállóság, rugalmasság és jó problémamegoldó készség.

Amit kínálunk:
◾Rugalmas munkaidő, otthoni munkavégzés.

Munkavégzés helye:

Országosan bárhonnan végezhető, Külföld

Jelentkezés módja: a profession.hu oldalon keresztül.

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

Ha bárkinek kérdése van ne kíméljen. Egyelőre még a DevOps=superhero flame sem ért el ide, legalább ennyit tegyetek meg. ;)

Figyi kezdem a sort :) ez a hirdetes dev-et csak nyomokban tartalmaz. Bocs a kotozkodesert, nektek akarok jot. Egy dev nem fogja a fejet felkapni erre a hirdetesre, hacsak nem szeretne szakteruletet valtani. A "a szoftverfejlesztés támogatása" (ismeretlen nyelveken) a leg dev kozelibb dolog, amit csinalni kell, a tobbi az QA, Ops ill. support. A DevOps azert devops, mert reszt vesz a fejlesztesben (is), tudja, hogy mit kell uzemeltetni, vagy forditva: tudja, hogy hogyan kell megirni uzemeltethetore.

-
Go konkurencia kezelés gyorstalpaló

Van nálunk bőven dev munka (C, C++, Java, Perl, Python) de most az elvárás (nem pedig követelmény!) csak annyi, hogy az illető képes legyen megérteni a kódot, egyszerűbb hibákat esetleg meg tudjon találni és esetleg még adhat rá javítást is (merge request formájában). Természetesen ha ennél több fejlesztői tapasztalata van az illetőnek az nem hátrány, de ez általában az "Ops" rovására szokott menni.
A másik véglet amivel találkozni lehet, az amikor adott egy egyszerű "dev" feladat, pl. rövid shell szkript írása valami automatizálására, és erre az válasz, hogy "nem vagyok fejlszető". Szerencsére az ilyen már az interjú során kiderül és akkor szépen elköszönünk egymástól.

s/szoftverfejlesztés támogatása/aktiv reszvetel a szoftver fejlesztesebe es szerintem ez mar rendben is van ;)

Szerintem ott van a kutya elasva, hogy ti azt varjatok egy devopstol, hogy ops legyen, de kozben "egyszerűbb hibákat" tudjon javitani, mig a devops nem hibakat javit ki vagy rovidebb scripteket ir, hanem magasabb szinten akar architekturalis donteseket is hoz a szoftverrel kapcsolatban vagy technologiakat hataroz meg. Nem ugyanaz a szint, ezert elengedhetetlen, hogy sok-sok ev dev tapaztalat legyen az alanynak, hogy legyen architect/vez. fejl. gyakorlata, mert maskulonben nem tud tervezni, nincs tisztaban a praktikakkal, patternekkel, stb.. Es emelett szuksege van legalabb annyi uzemeltetesi tapasztalatra, mert az infra tervezesebe is aktivan reszt kell vegyen, hogy tudjon technologiai donteseket hozni/javasolni. Nem annyi a dolga, hogy kedves ops team, matol Dockert hasznalunk, hanem tudja, hogy azt hogyan kell uzemeltetni, hogyan kell logokat gyujteni, mik a bevett modszerek, hogyan lehet monitorozni, stb.

"rövid shell szkript írása valami automatizálására" ezzel barmelyik opsnak meg kell tudni birkozni, ha nem, akkor viszont latasra, ahogy ti is csinaljatok.

-
Go konkurencia kezelés gyorstalpaló

Itt abszolút jól definiáltad az ideális jelöltet. Azonban ezzel az a baj, hogy én a 20 éves karrierem alatt elég kevés ilyen emberrel találkoztam. Tehát nem várható el, hogy ilyen kvalitású emberek fognak tolongani (főleg most uborkaszezonban). Másrészt itt ismét eljutottunk a Superhero fogalmához, ami a többi devops-os topikban rendszeres flame.

Te lehet, hogy átmennél a szűrőn (a blog-odon látszólag van értemes tartalom) és megfelelsz a fenti kritériumoknak, de nyílván Te is csak fórumozgatni vagy itt, nem azért mert új állás érdekel. Az amcsik tömnek pénzzel, szép az irodátok (http://www.azevirodaja.hu/nevezok/627) ahova remélhetőleg alig kell bejárni és ezért eszed ágában sincs CV-t küldeni. ;-)

Szerintem nincs igazad.
Az a leiras amit te itt prezentaltal hogy a devops architekturalis donteseket hoz szoftverszinten az egy architect vagy CTO.
A devops altalaban vagy egy jo dev aki ert az ops-hoz, vagy egy jo ops aki ert a dev-hez.

"CTO typically reports directly to the chief information officer (CIO) and is primarily concerned with long-term and \"big picture\" issues" - Wikipedia

Nem egeszen ertek veled egyet, a CTO az iranyt/iranyokat mutatja meg az egesz vallalatot tekintve (tipikusan 1 van belole per ceg), de egyaltalan nem feladata meghatarozni, hogy egy adott problemat a feature/microservice teamben hogyan oldanak meg, melyik technologia a legalkalmasabb az adott feladatra. A devops feladata a teamen belul az, hogy uzemeltetheto legyen a kod, hogy tudja hogyan kell uzemeltetni a kodot,es automatizalja a pipelinet nagyon leegyszerusitve.

-
Go konkurencia kezelés gyorstalpaló

Azon gondolkoztatok, hogy ok ketten egyutt kollaboralva dolgoznak?:D

A CTO-m 10000 km-re van innen, talan 2x lattam valami summiton, es meg sosem kerte ki a velemenyemet, ahogy en sem kerdeztem ot semmirol.

-
Go konkurencia kezelés gyorstalpaló

So what?

Az, h nalatok igy mukodik nem jelenti, hogy az igy mukodik (jol) es kesz.
Raadasul ahogy irtam, a devops nem egy szerepkor. Az is bizonyitja, h itt a hup-on is allandoan feljon, h ki a devops. A devops egy buzzword, amit rahuznak tobbfele szerepkorre, amikben annyi kozos van, hogy azok a szemelyeknek van vmennyi dev es ops tudasa vmint feladata is.

A devops egy buzzword, a devops egy kultura, de itt most devops mernok poziciorol beszelunk. A topic cime is az. A devops mernoknek viszont jol korul irhato szerepkore van a csapaton belul.

-
Go konkurencia kezelés gyorstalpaló

OK, ebben nem ertunk egyet.
Sot, konkretan ebben a topic-ban is azt irta lenyegeben b0ti, hogy nem az. Van egy rakas terulet, amit le kene fedni es a cel az, hogy abbol egy ember minel tobbet be tudjon vallalni.

"azt irta lenyegeben b0ti" azt is irta, hogy az idealis jelolt az akit leirtam, csak olyan nem jelentkezik, ezert lentebb adtak a kovetelmenyekbol, es arra jutottak, hogy inkabb jobb ops legyen mint dev. A leiras tokeletesen megfelel egy ops munkakornek, es semmi dev nincs benne. Es ezuton is bocsi kedves opsok szerintem elvarhato, hogy egy uzemelteto tudjon az uzemeltetessel kapcsolatos scripteket irni, mert az bujjon vissza a barlangjaba, aki nem kepes egy perl/python/bash scriptet osszekalapalni. Es remelem a devek sem koveznek meg, de a "egyszerűbb hibákat esetleg meg tudjon találni és esetleg még adhat rá javítást is" nem a dev csucsa. A hirdetes alapjan ok egy kepzett opst keresnek dev ismeretekkel/ambiciokkal, de az nem devops mernok.

"DevOps (a clipped compound of "development" and "operations") is a software development and delivery process that emphasizes communication and collaboration between product management, software development, and operations professionals. It seeks to automate the process of software integration, testing, deployment, and infrastructure changes by establishing a culture and environment where building, testing, and releasing software can happen rapidly, frequently, and more reliably."

"key aspects of the development and delivery process:

Code — code development and review, source code management tools, code merging
Build — continuous integration tools, build status
Test — continuous testing tools that provide feedback on business risks
Package — artifact repository, application pre-deployment staging
Release — change management, release approvals, release automation
Configure — infrastructure configuration and management, Infrastructure as Code tools
Monitor — applications performance monitoring, end–user experience"

Ne mondjatok mar nekem, hogy a ezen feladatokat el lehet latni feluletes ismeretekkel akarmelyik szakteruleten.

-
Go konkurencia kezelés gyorstalpaló

Loopba kerultunk.
A devops mindenkinek mast jelent.

Majd rakeresek a googlen neked mit jelent mert meg nem fejtetted ki ;)

-
Go konkurencia kezelés gyorstalpaló

Talan kerdezted? Semmi jele nem volt, h erdekel:)

A devops szerintem jo arra, hogy beirja az ember a cv-jebe es jelezze, hogy devops attituddel rendelkezik.
Allashirdetesbe nem igazan valo, bar hasznalhato, ha a celja az, mint ebben a hirdetesben, hogy keresnek vmilyen embert, aki amgy devops attituddel rendelkezik.

A devops attitude pedig azt jelenti szamomra, hogy nem kuloniti el az ops es a dev feladatokat, nem huz eles hatarokat a feladatok koze.
Koze nincs ahhoz, hogy epp a leges-legkezdobb tojashejjal a seggen, vagy a szakmajanak az istencsaszara.

Jellemzoen devops attituddel rendelkeznek:

- sysadminok akik automatizaljak a munkajukat (nem az a resz, h beallitja a cron-t ahelyett, h ejszaka felkelne a backup miatt, hanem az, aki megirja a cron nevu alkalmazast, h ne kelljen felkelni)
- builder
- releaser
- sre
- cloud
+ meg kitudja, talan jelenleg nem is letezo feladatokat betolto szemelyek

Na majd beleirom az alairasomba, hogy nem csak magamban kiabalni jarok ide, es batran fejlsetek ki a velemenyeteket, hiszen utkoztetni csak ugy lehet ;)

Beszeltunk mar devops:
- kulturarol
- attituderol
- buzzwordrol
- mernokrol

Ezek mind mas dolgot takarnak, ebben total egyet ertunk. En a mernokrol beszeltem, te pedig az attituderol. De az attitudetol nem valik mernokke az ember, hanem mernokke kovacsolja az attitude. Igen ebben a hirdetesben egy devops attitudedel rendelkezo szemelyt keresnek, aki jobb ops mint dev. A te logikaddal a devops mernok nem letezik, de akkor a logikad szerint milyen titulust adnal annak a szemelynek, aki az attitudenek hala es a sok eves tapasztalatnak mesterien vegzi a munkajat, es mernok, azaz meg tud mernokolni egy devops problemat?

-
Go konkurencia kezelés gyorstalpaló

Szerintem a problematol, azaz a feladatkoretol fugg, h mi a neve az emberkenek.
Valassz az altalam irt listarol vagy rakj hozza masikat (en pl. lehagytam rola a testert).

Bizonyos vallalati strukturaban, ahol szerepkorok szerint vannak a reszlegek szetbontva, ott valoszinuleg ez a helyzet, amit irsz, hogy van ilyen csapat meg olyan csapat, es tok jol jon a sysadmin csapatban, ha van aki ert valamennyit a devhez is, vagy forditva.
De mas vallalati strukturaban meg nem ez a helyzet, hanem pl vannak a feature/service csapatok, es a csapaton belul kell valaki, aki tudja, hogy mit kell uzemeltetni (dev) es tudja, hogy hogyan kell uzemeltetni (ops). Nincs minden csapatban egy sysadmin, meg egy builder, meg egy releaser, meg a tobbi dedikaltan. Van a ..... (mar le sem merem irni :D), akinek az a feladata, hogy az elkeszult alkalmazas lehetoleg automatikusan eljusson uzemeltetheto formaban az uzemeltetesre, es ott ne szarja ossze magat, amikor az uzemeltetes terheles alapjan skalazza.

Ez az egesz devops amugy a microservizekkel parhuzamosan notte ki magat, es azota is karoltve jarnak, mert micro servicet nem lehet ugy fejleszteni, hogy ide-oda dobjak a reszlegek kozott a melot, hogy blokkolnak folyamatok, mert a masik reszlegre varnak. Es a vegtermek sem nem egy artifact/jar/binary, hanem a service az egy egyseg az osszes fuggosegevel egyutt. Ehhez kellenek azok, a ......, akik kepesek egy ilyen csomagot mint vegtermeket leszallitani.

-
Go konkurencia kezelés gyorstalpaló

> Nincs minden csapatban egy sysadmin, meg egy builder, meg egy releaser, meg a tobbi dedikaltan.

Ahogy irod, nincsenek dedikaltan, de attol meg a szerepkorok megvannak. Vagy inkabb ugy mondanam, h adottak.

Igen, csak egy teamben meretetol fuggoen egy/ket valaki csinalja az osszes szerepkort, meg o szokta csinalni a CD-t, aminek resze a QA, es lassan majd el kell neveznunkn valahogy ezt a munkakort. A csapat fejleszti a cuccot, es mivel a fejlesztok fejleszteni szeretnek, lesz valaki(k), aki a "halatlan" szerepkoroket megcsinalja, mert nem lehet mindenre folyton berangatni valaki kulsost, hogy megcsinaljon valamit pl a release processben, vagy beallitson egy adatbazist. Hazon belul valaki ellat tobb szerepkort is.

-
Go konkurencia kezelés gyorstalpaló

Mi ebben a de?

Hat attol lesz dev, hogy/ha ugyanez az ember fejleszt is, epp ez a lenyeg, hogy az alkalmazast is ismeri/tervezi/fejleszti/teszteli/hasznalja meg az infrat is. Ebbol indultunk ki, hogy az ops nem fejleszt a dev nem opsol. Ez problema, tehat kell valaki, aki igen.

-
Go konkurencia kezelés gyorstalpaló

OK, de ebben nem volt egyet nem ertes:)

az egyet nem ertes ott van, hogy en azt a "kell valaki, aki igen", azt devops mernoknek hivom, es onallo szakteruletnek tekintem, te pedig nem: "jo arra, hogy beirja az ember a cv-jebe".

-
Go konkurencia kezelés gyorstalpaló

OK. Pentek este van, en mar elengedtem, ugysem valtoztat semmin:)

Fenntartom, hogy szerintem a "DevOps" alapvetően nem egy személy jelzője; nem fejlesztő és üzemeltető egyben, hanem képzett és konstruktív hozzáállású specialisták modern eszközökkel és szemlélettel végzett közös munkája egyazon cél érdekében. (Természetesen tévedhetek.)
-----------------------
{0} ok boto
boto ?

Korábbi helyemen dedikált devopsok voltak, a termék kódjához nem nyúltak, a ci-deploy-monitoring résszel foglalkoztak.

Aztán egy csomó helyen már válik is szét. A nagy csapatásban a devel vonal annyira erős, hogy utána napokba telik kibogozni, hogy mit is sikerült ops vonalon összeollózni és valszin minden aknát nem is sikerül megtalálni. Devel vonalon pedig ha ismert a környezet amire fejleszteni kell, akkor azt miért kéne állandóan változtatni?

Ezek a szerepkörök soha nem válnak el ennyire élesen egymástól, még a legnémetebb überprecíz agyonszabályozott cégnél sem.

Ezek a szerepkorok elvalnak egymastol. CTO-bol egy van per ceg, devops engineerbol meg 1-3 per team. Vallalat meretetol fuggoen tolodhat el a dolog. pl egyszemelyes vallakozasban az az egy valaki a mindenki de a 10 fos kis cegben altalaban a vezeto fejleszto az architeckt is egyben ... ... ... a devops mernok az aki ert annyira az uzemelteteshez, hogy az ops teammel karoltve meg tudja tervezni az eles/qa/test/dev infrat, es ert annyira a programozashoz, hogy a megtervezett infran az alkalmazas jol skalazhato meg hibaturo lesz. A devops a hid a ket vilag kozott, az az ember, aki mindket vilagban otthonosan mozog, akinek a szavara adnak mindket vilagban. Nyilvan nem lehet egy paprikajancsi, aki kisebb hibakat ki tud javitani a kodban, vagy el tud inditani egy docker kontenert a gepen. Annak a szemelynek kell lennie, akit komolyan vesznek a hardcore opsok meg devek is. Na ehhez kell a tapasztalat.

-
Go konkurencia kezelés gyorstalpaló

Akkor ki a kezdo devops-os?:)
Egyszeruen arrol van szo, h a devops nem egy szerepkor.

A kezdo devops az aki, senior dev, senior ops, intermediet qa, es kezdo a szerepkorben.

-
Go konkurencia kezelés gyorstalpaló

Rendben. Nem ertunk egyet:)

Nem letezik olyan hogy senior dev es senior ops egyben es akkor o a devops. Egy profi rendszergazda sosem lesz profi fejleszto mert ahhoz minimum 4-5 evet el kell toltenie foallasu fejlesztokent es vica versa.
Aki ilyen ember az minimum architektkent dolgozik, vagy valami komoly team lead, CTO, stb.

Egy Senior Devops vagy egy jo rendszergazda aki ert a devhez vagy egy jo developer aki ert az opshoz.
Sajnalatos modon az utobbiak vannak tobben, pedig a jo devops inkabb az elso.

"minimum 4-5 evet el kell toltenie foallasu fejlesztokent es vica versa." ebben egyetertunk
"Aki ilyen ember az minimum architektkent dolgozik, vagy valami komoly team lead, CTO, stb." ezek kozul egyik sem vagyok, es akkor lehet en vagyok eltevedve, azzal kapcsoaltban amit csinalok (meg a masik 10) a csapatban:
- egy olyan szoftvert fejlesztunk Java (~147212 sor), Go, Javascript, Bash, alapon
- amely kepes 6 fele cloudba
- webes es command line eszkozokkon keresztul
- felhuzni a teljes infrastrukturat nullarol (vpc, network, diskek, sec. groupok, stb)
- az infran a sajat elore salttal elkeszitett imageket elinditani
- a gepekre bekonfiguralni egy salt stacket, azon keresztul felhuzni egy Ambari clustert
- az Ambari segitsegel telepiteni es konfiguralni egy Hadoop clustert
- bekonfiguralja a monitorozast
- majd bizonyos peremfeltetelek menten kepes skalazni es javitani a clustert
- mindenzt teszi ugy, hogy minden commit egy release automatikusan az osszes szukseges image sutessel, distribucioval, kod ellenorzessel, tesztek futtatasaval, stb
- es minden release vegul egy single binary, ami egy 'cbd start' paranccsal felepiti a sajat infrastrukturajat docker alapon

Szerintem ebben a projektben van devops boven (fejlesztunk valamit, ami operal magatol, mi ez ha nem az?), es egy kezdo devops kepes egy ilyen rendszert tovabbfejleszteni (mert ert a fejleszteshez, uzemelteteshez, es automatizaciohoz). Nem csak egy reszet a rendszernek, mert egyes valtozasok az osszes retegen atmennek. A halado devops pedig kepes megtervezni es lefejleszteni. Azt sem gondolom, hogy superherokra van szukseg, mert tizen valahany mezei srac vagyunk, es egyikunk sem architect vagy CTO es team lead is csak 1 van.

Aztan lehet azt se tudom mit csinalok, es lenne egy jobb cimke a munkakoromre, de en nem talaltam, ezert maradt a devops, es biztos ezert van ilyen sarkos elkepzelesem is az egeszrol.

-
Go konkurencia kezelés gyorstalpaló

*vice versa

avagy a legújabb költeményem: Vica verse :D

Szerintem nem hozzaertes, hanem hozzaallas kerdese.

Engem pl. ki* nem erdekel(ne), hogy peldaul kerul az altalam irt szoftver production-be (vagy barmilyen mas environmentbe). Szamomra az lenne az idealis, ha a rendszeren lenne egy zold gomb, amit csak meg kellene nyomni...

Ehhez kepest most is eppen docker-t cseszegetek, meg Chef szkripteket hegesztek, mert muszaj. Nem erdekel, de megcsinalom, mert meg kell csinalni.

En nem tartom magam devops-nak, es ha ilyet latok hirdetesben, sikitva rohanok a masik iranyba. Nem azert, mert nem tudom megcsinalni, hanem mert untat, vagy ha nem mukodik valami, akkor a hajamat tepem, hogy miert en szivok ezzel, es miert ezzel szivok, nem valami jo kis szaftos buggal mondjuk, amit en helyeztem el izlesesen a rendszerben :)

Mert te egy dev vagy, es a hatad kozepere se kivanod ezt a munkat. Vannak opsok, akik meg a hatuk kozepere se kivanjak, hogy az alkalmazas skalazhato legyen. Ez a problema gyokere, hogy kulon vannak ezek a szerepkorok, nehezen talalnak ossze az erdekek, masok a preferenciaik, stb. Pl. a dev szereti a fancy uj cuccokat, az ops meg azt szereti ha konnyu a rendelkezesreallast biztositani. Aztan kepbejott a rapid development, a microseervice, mar minden porog, valtozik. Annyira lerovidultek a fejlesztesi ciklusok, nem fel evente van release, nehol percekben merik. Es ezzel egyutt jott a problema. A dev nem szeretett fuggni az opson, az ops meg nem szerette, hogy 30 team bombazza a napi infra changekkel. Es ez megszulte a devops fogalmat kereslet-kinalat alapon. Vannak emberek, akik szeretnek kodolni, es szeretik futtatni is a kodot. Egyik sem untatja oket, sot oromuket lelik benne, hogy az alkalmazast, amit fejlesztenek, azt egy egysegben tudjak atadni uzemeltetesre, vagy, hogy barmelyik projektet konnyu szerrel tudnak reprodukalni a fejlesztoi gepeken. Es mivel igeny lett ilyen emberekre, es voltak emberek, akiket ez erdekelt, letrejott ez a szerepkor. Van olyan ceg, ahol a team kapja az alertet, ha tonkremegy a service, es erdekeltek abban, hogy ilyen ne tortenjen.

-
Go konkurencia kezelés gyorstalpaló

akik szeretnek kodolni, es szeretik futtatni is a kodot [...] az alkalmazast, amit fejlesztenek, azt egy egysegben tudjak atadni uzemeltetesre

erdekes koncepcio mindenesetre :-)

btw. szerintem a devops kb. olyan munkakor, amit atya igy festett le: http://andrews.hu/wp-content/uploads/2015/10/devops_v2.2.pdf

--
Allitsuk meg Andorrat!

"erdekes koncepcio mindenesetre" nem en talaltam ki elhiheted :)

a "A DevOps eszközkészlet" slide tetszik

-
Go konkurencia kezelés gyorstalpaló

Én ezt is megértem. Viszont amikor a magát rendszergazdának tartó ember azzal dobja el a shell szkripteléses feladatot, hogy ő nem programozó akkor a két oldal csak egymásra mutogat. Vannak tipikusan olyan területek (pl a hadoop téma Richárd kollégánál, meg nálunk a naplógyűjtés/feldolgozás) ahol ilyen mentalitással nem lehet jó terméket/szolgáltatást csinálni.
Ha neked nem fekszik az üzemeltetési része, akkor rossz szerepkörbe dugtak be.

Egyszeruen kicsi a ceg, nincs mindenre kulon ember. Illetve vannak "devops" kollegak, de ha en csinalom a feladatot, akkor holnapra biztosan kesz, ha rajuk kell varni, akkor hetek/honapok kerdese...

Szerencsere a business erdekes, pedig tulajdonkeppen mi is logokat gyujtunk/dolgozunk fel, csak GPS koordinatakkal :)

Hogy mi a DevOps: https://www.youtube.com/watch?v=_I94-tJlovg
--
A legértékesebb idő a pillanat amelyben élsz.
https://sites.google.com/site/jupiter2005ster/

Szerintem meséljél a cégről kicsit többet, mert a weboldal látványosan hiányos ezen a téren - már-már olyan szinten, ami az embert elgondolkodtatja: ha egy cég oldalán nem látom a cégközlönybeli fontosabb hivatalos adatait (a becsületes neve, adószáma, székhelye, ilyesmik), az nálam pl. egy webshopnál már azonnali vészcsengő.

Meg ha jól értem, akkor az iroda fogalma nem létezik - ez azért szerintem annyira nem egyértelmű a hirdetésből.

A weboldal illetve a marketingünk tényleg hagy némi kívánni valót maga után. (Ha van akit érdekel ilyen jellegű munka, szívesen vesszük a jelentkezését!). Lesz egyébként egy ráncfelvarrás hamarosan a weboldalon ami a fenti hiányosságokat is hivatott majd korrigálni, ez folyamatban van.
Az cég egyébként az NXLog Kft, de ez úgy gondolom az álláshirdetésben is meg lett jelölve, illetve némi google elég hamar kidobja. Az ügyfeleink egy része azért utána néz kivel szerződik, máskülönben nem lenne ügyfél pl. a SpaceX, a US Navy, több kormányszerv (titkosszolgálatok is) és mások.

Az iroda fogalma nem létezik. Igy legalább nem is lehet hova bejárni. Ez nem azért van mert nem futja rá, hanem egyszerűen nem akarjuk sz*atni a kollégákat. Aki BP és vonzáskörzetében él az tudja miről van szó. A távmunkava mellett nagyrészt csak arra kellene az iroda, hogy heti 1-2 alkalommal megbeszélést tartsunk (meg sörözzünk), amiről várhatóan egyébként is mindig elkésne a dugó miatt valaki. Másrészt a csapat egy része külföldi, nekik egyébként is nehéz lenne a megjelenés.

Csak egy apró megjegyzés, itt https://nxlog.co/about-us van egy szép bizalomgerjesztő kép egy irodaépületről (némi google kereséssel a fotó egyébként innen van: http://magyarorszagfotoblog.blogspot.hu/2012/01/budapest-hungaria-megdicsoulese.html ) akkor ez gondolom csak az ellenség megtévesztése miatt került ide ? :)

Azóta már eltelt pár év és ez már valóban nem a jelenlegi állapotot tükrözi. Mint említettem a weboldal átalakítás alatt van, remélem ez is lekerül.

Eladtatok az irodahazakat?:)

Az ingatlan piac helyett jobb választás az informatikával foglalkozni. ;)

Az oldalatokon nem talalni egyetlen nevet, cimet, telefonszamot sem, ez igy nagyon komolytalan, gyakorlatilag ez a ceg (mi a neve?) nem letezik.

szerk: http://ceginformacio.creditreform.hu/cr9310161390

Igy mar oke.

A fenti thread kb. erről szólt, ezt ott megválaszoltam.

A devops az mint a yetti.
Sokan hallottak rola, de igazan meg senki sem latott, csak azt hitte es megsem.

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