DevOps engineerek Szegeden: Vélemények és kedvező árak

DevOps Engineer magánügyfeleknek Szegeden

A DevOps Engineer akkor hasznos, amikor egy weboldal, alkalmazás vagy kisebb online szolgáltatás működése már túl kényes ahhoz, hogy alkalmi beállításokkal menjen tovább. Magánügyfélként ez sokszor nem nagyvállalati projektet jelent, hanem egy konkrét gondot. Lassú szerver. Sikertelen telepítés. Elromló mentés. Zavaros felhőfiók. Vagy egy fejlesztő által félbehagyott rendszer, amelyhez valaki végre nyugodtan hozzányúl.

Szeged környékén sok kisebb vállalkozó, webáruház tulajdonos, oktató, tanácsadó és tartalomkészítő futtat saját rendszert. Nem mindenkinek kell teljes munkaidős mérnök. Gyakran elég egy független szakember néhány órára, majd később havi ellenőrzésre. A Qjob.hu felületén különböző magánszakemberek közül lehet választani, nem egyetlen cég csomagját kell elfogadni. Ez fontos különbség, mert a feladat jellege sokszor személyesebb, mint egy céges szerződés.

Személy szerint azt tartom jó kezdésnek, ha az ügyfél leírja, mi fáj neki most. Nem az összes technikai szót kell tudni. Elég ennyi. Az oldal gyakran leáll. A frissítés után eltűnik valami. Nem világos, hol van a mentés. A jó DevOps mérnök ebből már látja, merre kell indulni.

DevOps feladatok otthoni és kis projektekhez

A DevOps munka nem csak nagy rendszerekhez tartozik. Egy kisebb webáruház, tagsági oldal, online tanfolyami felület vagy privát szerver is igényelhet rendes beállítást. Ide tartozhat a tárhely vagy virtuális gép rendbetétele, a kiadási folyamat egyszerűsítése, a biztonsági mentés ellenőrzése, a naplók átnézése és a jogosultságok tisztítása.

Sokan akkor keresnek segítséget, amikor már baj van. Ez érthető, de nem mindig olcsó. Sokkal jobb egy rövid állapotfelmérés, mielőtt egy frissítés vagy költöztetés elkezdődik. Én azt a megoldást szeretem, amikor a szakember először nem szerel, hanem kérdez. Milyen rendszer fut. Ki fér hozzá. Van-e mentés. Hol van a domain. Mikor volt utoljára frissítés. Ezek unalmas kérdéseknek tűnnek, de sok hibát megelőznek.

A felhő infrastruktúra beállítása is lehet magánügyfél feladata. Ilyen például egy fejlesztői környezet, egy próbaszerver, egy kis alkalmazás automatikus indítása vagy egy konténeres futtatás. Nem kell mindenből a legbonyolultabb megoldás. Sokszor egy tiszta, dokumentált és visszaállítható rendszer többet ér, mint egy divatos, de átláthatatlan felépítés.

CI CD és felhő beállítás

A CI CD lényege egyszerű. A módosítások ne kézzel, kapkodva kerüljenek ki az éles oldalra. Legyen ellenőrzés, ismételhető folyamat és visszalépési lehetőség. Egy privát projektben ez nem feltétlenül jelent nagy csapatot. Jelentheti azt is, hogy a fejlesztő feltölt egy módosítást, a rendszer tesztel, majd biztonságosan telepít.

Volt eset, amikor egy ügyfél minden péntek este kézzel másolt fájlokat a szerverre. Ha valami elromlott, vasárnapig próbálta visszakeresni, melyik fájl volt a régi. A DevOps Engineer nem varázslatot csinált, csak beállított egy egyszerű folyamatot, mentéssel és naplózással. A következő hiba már nem lett dráma. Tíz perc alatt vissza lehetett állni.

A felhő beállításnál sok hiba abból jön, hogy az ügyfél túl nagy csomagot választ, vagy épp túl kicsit. Egy DevOps szakértő átnézi a terhelést, a tárhelyet, a memóriahasználatot és a várható növekedést. Nem mindig a drágább szerver a jobb. Néha egy rossz adatbázis beállítás lassít mindent. Máskor a mentés ugyan fut, de soha senki nem próbálta visszaállítani. Ez veszélyes nyugalom.

DevOps árak és tipikus munkadíjak

Az ár általában a rendszer állapotától és a sürgősségtől függ. Egy tiszta, dokumentált környezetben gyorsabb a munka. Egy régi szerveren, hiányzó jelszavakkal, ismeretlen bővítményekkel és lejárt tanúsítványokkal több idő kell. Szerintem 12.000 forint óradíj alatt ritkán lesz igazán jó eredmény ennél a munkánál, főleg ha éles rendszerhez kell nyúlni.

A táblázat csak tájékoztató. Egy jó ajánlat nem csak összeget tartalmaz, hanem határt is. Mi fér bele. Mi nem. Mennyi ideig érvényes. Mi történik, ha új hiba derül ki. Sok vita abból indul, hogy az ügyfél általános segítséget kér, a szakember pedig közben teljes rendszermentést, frissítést és hibajavítást végez. Ez nem ugyanaz a munka.

Szakember választása DevOps munkához

A szakember választásánál nem a leghosszabb eszközlista a döntő. Fontosabb, hogy érthetően beszéljen a kockázatról. Ha valaki azonnal mindent át akar építeni, kérdés nélkül, az nekem gyanús. Egy működő rendszerhez óvatosan kell nyúlni. Előbb mentés, aztán mérés, utána változtatás.

Érdemes rákérdezni korábbi hasonló munkákra. Nem kell bizalmas ügyfélnevet kérni. Elég, ha el tudja mondani, milyen hibát oldott meg, milyen lépésekben haladt, és mit adott át a végén. Jó jel, ha dokumentációt is készít. Rövidet, de használhatót. Belépési pontok, mentés helye, frissítési lépések, fontos parancsok. Egy DevOps Engineer munkája akkor igazán értékes, ha később nem lesz tőle függő az ügyfél.

Sokan elkövetik azt a hibát, hogy csak óradíjat néznek. Az alacsony ár vonzó, de ha a feladat kétszer annyi ideig tart, vagy utána másnak kell javítani, nem lesz olcsó. A jó infrastruktúra mérnök nem feltétlenül beszél sokat. Viszont pontosan jelzi, ha valami veszélyes, és nem nyúl éles adatbázishoz mentés nélkül.

Helyi munka Szeged városrészeiben

Szeged esetében a helyi jelenlét néha számít, még ha a DevOps munka nagy része távolról is végezhető. Egy belvárosi iroda, újszegedi otthoni vállalkozás, rókusi műhely vagy móravárosi kis cég más helyzetben lehet. Van, ahol a routerhez, helyi NAS eszközhöz vagy belső hálózathoz is hozzá kell férni. Ilyenkor a személyes kiszállás egyszerűbb lehet.

A távoli munka viszont gyorsabb, ha minden hozzáférés rendezett. SSH kulcs, felhőfiók, domain kezelés, tárhely belépés, forráskód tárhely. Ha ezek nincsenek meg, a munka első része nyomozás lesz. Ez nem szégyen. Sok magánprojekt így nő fel. Először csak egy oldal indul, aztán jön fizetés, hírlevél, automatizmus, több látogató. A rendszer közben nem kap rendes alapot.

A környékbeli településekről is lehet szakembert keresni. Algyő, Deszk, Sándorfalva vagy Hódmezővásárhely felől gyakran ugyanaz a logika érvényes. Ha a gond szerveren van, a földrajz kevésbé fontos. Ha helyi eszköz is érintett, akkor a közelség időt spórolhat.

Átadás, biztonság és későbbi karbantartás

A DevOps Engineer feladata nem ér véget azzal, hogy egyszer lefut a rendszer. Át kell adni, mi változott. Jó esetben az ügyfél megkapja a rövid leírást, a fontos hozzáférések listáját és a következő javasolt lépést. Nem kell húsz oldalas anyag. De legyen nyoma annak, hogy mi történt.

Biztonságnál az alapok sokat számítanak. Kétlépcsős belépés. Korlátozott jogosultság. Frissített csomagok. Működő mentés. Figyelmeztetés, ha elfogy a tárhely vagy leáll egy szolgáltatás. Ezek nem látványos dolgok, mégis ezek mentik meg a rendszert egy rossz napon.

Tapasztalatom szerint a havi karbantartás akkor éri meg, ha van bevételt termelő oldal, ügyféladat vagy rendszeres kampány. Egy hobbi oldalnál elég lehet időszakos ellenőrzés. Egy fizetős szolgáltatásnál már más a helyzet. Ott egy nap leállás többe kerülhet, mint több hónap alap felügyelet.

A végén az számít, hogy az ügyfél értse, mit kapott. Nem kell rendszermérnökké válnia. Csak tudja, hol van a mentés, kihez fordulhat, és milyen változtatást nem érdemes egyedül elindítani. Ez a nyugodt működés alapja.