Jelenleg ez szinte a legdrágább pozíció a piacon. A „DevOps” mérnökök körüli felhajtás minden elképzelhető határon túl van, és még rosszabb a Senior DevOps mérnököknél.
Az integrációs és automatizálási osztály vezetőjeként dolgozom, gondolom az angol dekódolást - DevOps Manager. Nem valószínű, hogy az angol átirat tükrözi napi tevékenységünket, de az orosz változat ebben az esetben pontosabb. Tevékenységem jellegéből adódóan természetes, hogy meg kell interjúztatnom a csapatom leendő tagjait, és az elmúlt egy évben mintegy 50-en mentek át rajtam, és ugyanennyien kerültek le az előszűrésből a munkatársaimmal.
Továbbra is keresünk kollégákat, mert a DevOps címke mögött nagyon nagy réteg rejtőzik különféle mérnökökből.
Az alábbiakban leírtak az én személyes véleményem, nem kell vele egyet érteni, de elismerem, hogy némi színt visz a témához való hozzáállásodba. A kegyvesztés veszélye ellenére közzéteszem a véleményemet, mert úgy gondolom, hogy ennek van helye.
A vállalatok eltérően értik, kik a DevOps mérnökei, és az erőforrás gyors felvétele érdekében mindenkire felragasztják ezt a címkét. A helyzet meglehetősen furcsa, hiszen a cégek készek irreális díjakat fizetni ezeknek az embereknek, és a legtöbb esetben eszközadminisztrátort kapnak helyettük.
Kik tehát a DevOps mérnökei?
Kezdjük megjelenésének történetével – a fejlesztési műveletek egy újabb lépésként jelentek meg a kis csapatokban zajló interakció optimalizálása felé, a termékgyártás sebességének növelése érdekében, ennek várható következményeként. Az ötlet az volt, hogy a fejlesztőcsapatot megerősítsük a termékkörnyezet kezelésében alkalmazott eljárások és megközelítések ismeretével. Más szóval, a fejlesztőnek meg kell értenie és tudnia kell, hogyan működik a terméke bizonyos körülmények között, meg kell értenie, hogyan telepítse termékét, milyen környezeti jellemzőket lehet beállítani a teljesítmény javítása érdekében. Így egy ideig megjelentek a DevOps megközelítést alkalmazó fejlesztők. A DevOps fejlesztői összeállítási és csomagolási szkripteket írtak, hogy egyszerűsítsék tevékenységeiket és az éles környezet teljesítményét. A megoldás architektúrájának összetettsége és az infrastrukturális összetevők idővel kölcsönösen befolyásoló hatása azonban elkezdte rontani a környezetek teljesítményét, minden iterációval egyre mélyebb megértésre volt szükség egyes összetevőkről, ami csökkentette a fejlesztő termelékenységét a további kiegészítők miatt. az alkatrészek és a hangolási rendszerek megértésének költségei egy adott feladathoz. A fejlesztő saját költsége nőtt, ezzel együtt a termék ára, a csapatban új fejlesztőkkel szemben támasztott igények meredeken megugrottak, mert a fejlesztői „sztár” felelősségét is fedezni kellett, és természetesen a „sztárok” is csökkentek. és kevésbé elérhető. Azt is érdemes megjegyezni, hogy tapasztalataim szerint kevés fejlesztőt érdekelnek az operációs rendszer kernelének csomagfeldolgozásának sajátosságai, a csomagok útválasztási szabályai és a gazdagép biztonsági szempontjai. A logikus lépés az ebben jártas adminisztrátor bevonása és hasonló feladatkörök kijelölése volt, amivel tapasztalatának köszönhetően egy „sztár” fejlesztés költségéhez képest alacsonyabb költséggel lehetett elérni ugyanazokat a mutatókat. Az ilyen adminisztrátorokat egy csapatba helyezték, és az ő fő feladata a teszt- és éles környezetek menedzselése volt, egy adott csapat szabályai szerint, ehhez a csapathoz hozzárendelt erőforrásokkal. Valójában így jelent meg a többség fejében a DevOps.
Az idő múlásával ezek a rendszergazdák részben vagy teljesen megértették ennek a csapatnak a fejlesztési szükségleteit, hogyan könnyíthetik meg a fejlesztők és tesztelők életét, hogyan lehet frissítést kiadni, és nem kell pénteken éjszakázni. az iroda, a telepítési hibák kijavítása. Telt-múlt az idő, és most a „sztárok” a rendszergazdák voltak, akik megértették, mit akarnak a fejlesztők. A hatás minimalizálása érdekében megjelentek a felügyeleti segédprogramok; mindenki emlékezett az operációs rendszer szint elkülönítésének régi és megbízható módszereire, amelyek lehetővé tették a biztonsági követelmények, a hálózati rész kezelésének és a gazdagép konfigurációjának minimalizálását. egészében, és ennek eredményeként csökkenti az új „sztárokkal” szemben támasztott követelményeket.
Megjelent egy „csodálatos” dolog - dokkoló. Miért csodálatos? Igen, csak azért, mert az elszigeteltség létrehozása chroot-ban vagy börtönben, valamint az OpenVZ-ben az operációs rendszer nem triviális ismeretét igényelte, ezzel szemben a segédprogram lehetővé teszi, hogy egyszerűen hozzon létre egy elszigetelt alkalmazáskörnyezetet egy bizonyos gazdagépen, minden szükséges eszközzel és kézzel. újra a fejlesztés gyeplői fölött, és a rendszergazda csak egyetlen gazdagéppel tud gazdálkodni, biztosítva annak biztonságát és magas rendelkezésre állását – ez logikus leegyszerűsítés. De a fejlődés nem áll meg, és a rendszerek ismét egyre bonyolultabbá válnak, egyre több a komponens, egy gép már nem felel meg a rendszer igényeinek, és klasztereket kell építeni, ismét visszatérünk a rendszergazdákhoz, akik képes ezeket a rendszereket felépíteni.
Ciklusról ciklusra megjelennek a különféle fejlesztést és/vagy adminisztrációt leegyszerűsítő rendszerek, hangszerelési rendszerek, amelyek használata mindaddig egyszerű, amíg el nem kell térni a szokásos folyamattól. A mikroszolgáltatási architektúra is megjelent azzal a céllal, hogy a fent leírtakat leegyszerűsítse – kevesebb kapcsolat, könnyebben kezelhető. Tapasztalataim szerint nem találtam teljesen mikroszolgáltatásos architektúrát, mondjuk a mikroszolgáltatások 50-50-50 százaléka, fekete dobozok, feldolgozva jöttek be, jöttek ki, a többi 50 egy szakadt monolit, a szolgáltatások nem működnek külön a többitől. alkatrészek. Mindez ismét korlátokat támasztott mind a fejlesztők, mind a rendszergazdák tudásszintjében.
Egy-egy erőforrás szakértői tudásának szintjében a mai napig tartanak hasonló „lengések”. De elkalandozunk egy kicsit, sok pontot érdemes kiemelni.
Építőmérnök/Release Engineer
Nagyon speciális mérnökök, akik a szoftverkészítési folyamatok és kiadások szabványosításának eszközeként jelentek meg. A széles körben elterjedt Agile bevezetése során úgy tűnik, hogy megszűnt a kereslet, de ez messze nem így van. Ez a specializáció a szoftverek ipari méretekben történő összeállításának és szállításának szabványosításának eszközeként jelent meg, i.e. szabványos technikákat alkalmazva minden vállalati termékhez. A DevOps megjelenésével a fejlesztők részben elveszítették funkciójukat, mivel a fejlesztők kezdték el előkészíteni a terméket a szállításra, és tekintettel a változó infrastruktúrára és a minőségre való tekintet nélkül a lehető leggyorsabb szállításra, idővel a változások gátja, mivel a minőségi előírások betartása elkerülhetetlenül lelassítja a szállításokat. Így fokozatosan a Build/Release mérnökök funkcióinak egy része átkerült a rendszergazdák vállára.
A műveletek nagyon különbözőek
Folyamatosan haladunk, és újra a felelősségek széles körének jelenléte és a szakképzett munkaerő hiánya a szigorú specializáció felé taszít bennünket, mint gomba az eső után, megjelennek a különféle műveletek:
- TechOps – enikey rendszergazdák, más néven HelpDesk Engineer
- LiveOps – elsősorban az éles környezetekért felelős rendszergazdák
- CloudOps – nyilvános felhőkre szakosodott rendszergazdák Azure, AWS, GCP stb.
- PlatOps/InfraOps/SysOps – infrastruktúra-rendszergazdák.
- NetOps – hálózati rendszergazdák
- SecOps - információbiztonságra szakosodott rendszergazdák - PCI megfelelőség, CIS megfelelőség, javítás stb.
A DevOps (elméletileg) egy olyan személy, aki első kézből érti a fejlesztési ciklus összes folyamatát - fejlesztés, tesztelés, érti a termék architektúráját, képes felmérni a biztonsági kockázatokat, ismeri a megközelítéseket és az automatizálási eszközöket, legalább magas szinten. szinten ezen felül érti az elő- és utófeldolgozást is.termékkibocsátási támogatás. Olyan személy, aki képes mind a műveletek, mind a fejlesztések szószólójaként fellépni, ami lehetővé teszi a két pillér közötti kedvező együttműködést. Megérti a csapatmunka tervezésének és a vevői elvárások kezelésének folyamatait.
Az ilyen jellegű munkák és felelősségek elvégzéséhez ennek a személynek olyan eszközökkel kell rendelkeznie, amelyek nemcsak a fejlesztési és tesztelési folyamatokat, hanem a termékinfrastruktúra menedzselését, valamint az erőforrás-tervezést is irányíthatják. A DevOps ebben a felfogásban nem található sem az IT-ben, sem a K+F-ben, de még a PMO-ban sem; ezeken a területeken befolyással kell rendelkeznie – a vállalat műszaki igazgatója, műszaki igazgatója.
Ez igaz a cégedben? - Kétlem. A legtöbb esetben ez IT vagy K+F.
A pénzhiány és a három tevékenységi terület közül legalább az egyik befolyásolási képesség hiánya a problémák súlyát oda tolja el, ahol ezek a változtatások könnyebben alkalmazhatók, mint például a „piszkos” kóddal kapcsolatos kiadásokra vonatkozó technikai korlátozások alkalmazása a statikus értékek szerint. elemző rendszerek. Azaz amikor a PMO szigorú határidőt szab a funkcionalitás kiadására, a K+F ezen határidőn belül nem tud minőségi eredményt produkálni, és azt a lehető legjobban produkálja, az átalakítást későbbre hagyva, az informatikához kapcsolódó DevOps technikai eszközökkel blokkolja a kiadást. . A helyzet megváltoztatására való felhatalmazás hiánya a felelős alkalmazottak esetében a túlzott felelősség megnyilvánulásához vezet azért, amit nem tudnak befolyásolni, különösen, ha ezek az alkalmazottak megértik és látják a hibákat, és hogyan javítsák ki őket - „A boldogság a tudatlanság”, és ennek következményeként ezen alkalmazottak kiégése és elvesztése.
DevOps erőforráspiac
Tekintsünk meg több DevOps pozíció betöltésére kínált állást különböző cégeknél.
Készek vagyunk találkozni Önnel, ha:
- Ön a Zabbix tulajdonosa, és tudja, mi az a Prometheus;
- Iptables;
- BASH PhD hallgató;
- Ansible professzor;
- Linux Guru;
- Tudja, hogyan kell használni a hibakeresést, és megtalálja az alkalmazási problémákat a fejlesztőkkel együtt (php/java/python);
- Az útválasztás nem tesz hisztérikussá;
- Fordítson jelentős figyelmet a rendszerbiztonságra;
- Mentse a „bármit és mindent”, és sikeresen állítsa vissza ezt a „bármit és mindent”;
- Tudja, hogyan kell a rendszert úgy beállítani, hogy a minimumból a maximumot hozza ki;
- Lefekvés előtt állítsa be a replikációt a Postgres és a MySQL rendszeren;
- A CI/CD beállítása és beállítása ugyanolyan szükséges, mint a reggeli/ebéd/vacsora.
- Van tapasztalata az AWS-ben;
- Készen áll a vállalattal való együttműködésre;
Tehát:
- 1-től 6-ig - rendszergazda
- 7 - egy kis hálózati adminisztráció, ami a rendszeradminisztrátorba is belefér, Középszint
- 8 - egy kis biztonság, ami egy középszintű rendszergazda számára kötelező
- 9-11 – Középső rendszergazda
- 12 — A hozzárendelt feladatoktól függően középső rendszergazda vagy építtetőmérnök
- 13 - Virtualizáció - Middle System Administrator, vagy az úgynevezett CloudOps, egy adott tárhely szolgáltatásainak fejlett ismerete, a pénzeszközök hatékony felhasználása és a karbantartási terhelés csökkentése érdekében
Összegezve ezt az üresedést, azt mondhatjuk, hogy a középső/vezető rendszergazda bőven elég a srácoknak.
Egyébként nem szabad erősen megosztani a rendszergazdákat Linuxon/Windowson. Természetesen megértem, hogy ennek a két világnak a szolgáltatásai és rendszerei különböznek, de az alap mindennek ugyanaz, és minden önmagát tisztelő rendszergazda ismeri az egyiket és a másikat is, és ha nem is ismeri, akkor is. egy hozzáértő adminisztrátornak nem lehet nehéz megismerni.
Nézzünk egy másik üresedést:
- Nagy terhelésű rendszerek építésében szerzett tapasztalat;
- Linux operációs rendszer, általános rendszerszoftver és webverem (Nginx, PHP/Python, HAProxy, MySQL/PostgreSQL, Memcached, Redis, RabbitMQ, ELK) kiváló ismerete;
- Virtualizációs rendszerekkel (KVM, VMWare, LXC/Docker) szerzett tapasztalat;
- Szkriptnyelvek ismerete;
- A hálózati protokoll hálózatok működési elveinek megértése;
- A hibatűrő rendszerek kiépítésének elveinek ismerete;
- Függetlenség és kezdeményezőkészség;
Nézzük:
- 1 – Vezető rendszergazda
- 2 - Attól függően, hogy mit jelent ez a verem - Középső/Rendszergazda
- 3 - A munkatapasztalat, beleértve azt jelentheti, hogy - "A fürt nem emelt, hanem virtuális gépeket hozott létre és kezelt, egy Docker-gazda volt, a konténerekhez nem volt hozzáférés" - Középső rendszergazda
- 4 - Junior System Administrator - igen, egy adminisztrátor, aki nem tudja, hogyan kell alapvető automatizálási szkripteket írni, nyelvtől függetlenül, nem adminisztrátor - enikey.
- 5 - Középső rendszergazda
- 6 – Vezető rendszergazda
Összefoglalva - Középső/Rendszergazda
Másik:
- Devops tapasztalat;
- Tapasztalat egy vagy több termék használatában CI/CD folyamatok létrehozásához. Gitlab CI előnyt jelent;
- Konténerekkel és virtualizációval végzett munka; Ha dockert használtál, jó, de ha k8-at, akkor nagyszerű!
- Agilis csapatban végzett munkatapasztalat;
- Bármilyen programozási nyelv ismerete;
Lássuk:
- 1 - Hmm... Mit jelentenek a srácok? =) Valószínűleg ők maguk sem tudják, mi van mögötte
- 2 - Építőmérnök
- 3 - Középső rendszergazda
- 4 - Soft skill, egyelőre nem vesszük figyelembe, bár az agilis egy másik dolog, amelyet kényelmesen értelmeznek.
- 5 - Túl bőbeszédű – lehet egy szkriptnyelv vagy egy lefordított nyelv. Kíváncsi vagyok, hogy az iskolában Pascal és Basic nyelven írnak, megfelelnek-e nekik? =)
A 3. ponttal kapcsolatban is szeretnék egy megjegyzést hagyni, hogy jobban megértsük, miért vonatkozik erre a pontra a rendszergazda. A Kubernetes csak egy hangszerelés, egy olyan eszköz, amely néhány parancsba csomagolja a közvetlen parancsokat a hálózati illesztőprogramokhoz és a virtualizációs/izolációs gazdagépekhez, és lehetővé teszi, hogy absztrakttá tegye a velük folytatott kommunikációt. Vegyük például a „build framework” Make-ot, amit egyébként én nem tekintek keretrendszernek. Igen, ismerem azt a divatot, hogy a Make-t bárhová tolják, ahol kell és nem kell - például a Maven-t Make-ba csomagolni komolyan?
Lényegében a Make csak egy burkoló a shell felett, leegyszerűsíti a fordítási, linkelési és fordítási környezeti parancsokat, akárcsak a k8s.
Egyszer interjút készítettem egy sráccal, aki k8s-t használt a munkájában az OpenStack tetején, és beszélt arról, hogyan telepített rá szolgáltatásokat, de amikor az OpenStackről kérdeztem, kiderült, hogy az adminisztrált, és a rendszer hozta létre. rendszergazdák. Tényleg azt hiszed, hogy aki telepítette az OpenStack-et, függetlenül attól, hogy milyen platformot használ mögötte, az nem tudja használni a k8s-t? =)
Ez a jelentkező valójában nem DevOps, hanem rendszeradminisztrátor, pontosabban Kubernetes rendszergazda.
Összegezzük még egyszer - a középső/vezető rendszergazda elég lesz nekik.
Mennyit kell mérni grammban
A megjelölt álláshelyekre javasolt fizetések tartománya 90-200 ezer
Most párhuzamot szeretnék vonni a rendszeradminisztrátorok és a DevOps mérnökök pénzbeli jutalma között.
Elvileg leegyszerűsítve lehet szórni az osztályzatokat munkatapasztalat alapján, bár ez nem lesz pontos, de a cikk céljaira ez is elég lesz.
Egy élmény:
- 3 éves korig – Junior
- 6 éves korig – Középső
- több mint 6 – Senior
Az alkalmazottkereső oldal a következőket kínálja:
Rendszergazdák:
- Junior - 2 éves - 50 ezer dörzsölje.
- Közép - 5 év - 70 ezer dörzsölje.
- Senior - 11 éves - 100 ezer dörzsölje.
DevOps mérnökök:
- Junior - 2 éves - 100 ezer dörzsölje.
- Közép - 3 év - 160 ezer dörzsölje.
- Senior - 6 éves - 220 ezer dörzsölje.
A „DevOps” tapasztalata szerint olyan tapasztalatokat használtak fel, amelyek legalább valamilyen módon befolyásolták az SDLC-t.
A fentiekből az következik, hogy a cégeknek valójában nincs szükségük DevOps-ra, és az is, hogy az eredetileg tervezett költségek legalább 50 százalékát megspórolhatnák egy Adminisztrátor felvételével, sőt pontosabban meghatározhatnák a keresett személy felelősségét. és gyorsabban tölti be a szükségletet. Nem szabad megfeledkeznünk arról sem, hogy a felelősségek egyértelmű megosztása az átfedések hiánya miatt csökkenti a személyi szükségleteket, valamint kedvezőbb légkört teremt a csapatban. A megüresedett állások túlnyomó többsége tele van segédprogramokkal és DevOps címkékkel, de ezek nem a DevOps Engineer tényleges követelményein alapulnak, csak az eszközadminisztrátor kérésein.
A DevOps mérnökök képzési folyamata is csak meghatározott munkákra, segédprogramokra korlátozódik, és nem ad általános megértést a folyamatokról és azok függőségeiről. Kétségtelenül jó, ha valaki 10 perc alatt telepítheti az AWS EKS-t a Terraform segítségével, a fürt Fluentd oldalkocsijával és a naplózási rendszer AWS ELK veremével együtt, egyetlen paranccsal a konzolban, de ha nem érti a A naplók feldolgozásának elve és mire van szükségük, ha nem tudod, hogyan kell mérőszámokat gyűjteni rajtuk és nyomon követni a szolgáltatás leromlását, akkor továbbra is ugyanaz az enikey lesz, aki tudja, hogyan kell néhány segédprogramot használni.
A kereslet viszont kínálatot teremt, a DevOps pozícióban pedig rendkívül túlfűtött piacot látunk, ahol a követelmények nem felelnek meg a tényleges szerepkörnek, csak a rendszergazdák számára teszik lehetővé, hogy többet kereshessenek.
Szóval kik ők? DevOps vagy mohó rendszergazdák? =)
Hogyan lehet tovább élni?
A munkaadóknak pontosabban kell megfogalmazniuk a követelményeket, és pontosan azt kell keresniük, akire szükség van, és nem dobálni a címkéket. Nem tudod, mit csinálnak a DevOps - ebben az esetben nincs rájuk szükséged.
Dolgozók – Tanulj. Folyamatosan bővítse tudását, tekintse meg a folyamatok összképét, és kövesse nyomon a célhoz vezető utat. Azzá válhatsz, aki akarsz, csak meg kell próbálnod.
Forrás: will.com