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;
- Guru Linux;
- 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ó — Középső rendszergazda, vagy úgynevezett CloudOps, egy adott rendszer szolgáltatásainak haladó szintű ismerete hosting helyszínek, a hatékony forrásfelhasználás és a szolgáltatási terhek 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 kellene túlságosan felosztani az adminokat... Linux/WindowsÉrtem persze, hogy e két világ szolgáltatásai és rendszerei különböznek, de az alap ugyanaz, és minden önmagát tisztelő adminisztrátor ismeri mindkettőt, sőt, ha nem is, egy hozzáértő adminisztrátor könnyen megismerkedhet velük.
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 kapcsolatos tapasztalat (KVM, VMWare, LXC/Docker);
- 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
