Ki az a DevOps?

Jelenleg ez a piacon talán a legdrágább pozíció. A "DevOps" mérnökök körüli mozgalom minden képzeletet felülmúl, és még rosszabb a helyzet a Senior DevOps mérnökök esetében.
Integrációs és automatizálási osztályvezetőként dolgozom, találjátok ki az angol rövidítést – DevOps Manager. Tényleg tükrözi az angol rövidítés a mindennapi tevékenységünket? Valószínűleg nem, viszont a magyar változat sokkal pontosabb ebben az esetben. A munkám természeténél fogva elkerülhetetlen, hogy jövőbeni csapattagokat interjúztassak, és az elmúlt évben körülbelül 50 ember ment át rajtam, és még annyian estek ki a szűrés során a kollégáimmal.

Még mindig keressük a kollégákat, mert a DevOps címke mögött nagyon nagy különféle mérnöki réteg bújik meg.

Minden, amit alább írok, személyes véleményem, nem kell egyetértenetek vele, de azt feltételezem, hogy árnyalatot adhat a témához való hozzáállásotokhoz. A bármi lehetősége ellenére, megosztom a véleményemet, mivel úgy érzem, hogy van helye.

A cégek különbözően értelmezik, hogy kik is a DevOps mérnökök, és a gyors toborzás érdekében ezt a címkét mindenkire rákattintják. A helyzet elég furcsa, mivel a cégek hajlandók irreális juttatásokat adni ezeknek az embereknek, akikért a legtöbb esetben csak egy adminisztrátort kapnak.

Tehát kik is a DevOps mérnökök?

Kezdjük a történelem bemutatásával – A Development Operations megjelent mint egy új lépés a kis csapatok közötti együttműködés optimalizálásában a termékgyártás sebességének növelése érdekében, mint az elvárt következmény. Az ötlet az volt, hogy a fejlesztő csapatot felkészítsék a termékkörnyezet kezelésével kapcsolatos eljárások és megközelítések ismereteivel. Más szóval, a fejlesztőnek tudnia kell, hogy a terméke hogyan működik bizonyos körülmények között, tudnia kell, hogyan telepítse a termékét, és mely környezeti jellemzőket kell optimalizálni a teljesítmény fokozása érdekében. Így egy idő után megjelentek a DevOps megközelítéssel rendelkező fejlesztők. A DevOps fejlesztők összeállítási és csomagolási szkripteket írtak, hogy megkönnyítsék saját feladataikat és a produktív környezet működését. Azonban az architektúrák megoldásainak bonyolultsága és az infrastruktúra komponenseinek kölcsönhatása idővel rontotta a környezetek munkateljesítményét, és minden iterációval egyre mélyebb megértés volt szükséges a különféle komponensekről, csökkentve a fejlesztő saját produktivitását a komponensek megértésére és a rendszerek egyedi feladatokra történő optimalizálására fordított pluszköltségek miatt. A fejlesztők költsége nőtt, a termék költsége is ezzel együtt, a csapatba új fejlesztők iránti kereslet drámaian megugrott, hiszen nekik is be kellett tölteniük a „csillag” fejlesztő feladatait, és természetesen a „csillagok” egyre nehezebben voltak elérhetők. Szintén említést érdemel, hogy tapasztalataim szerint a fejlesztők közül kevesen érdeklődnek az operációs rendszer magjának csomagkezelési sajátosságai, a csomagok vertikális irányítása és a gazdagép biztonsági aspektusai iránt. Logikus lépés volt egy olyan adminisztrátor bevonása, aki pontosan ezekkel ismerkedett meg, és a feladatokat a számára kiszabni, ami az ő tapasztalata alapján lehetővé tette, hogy ugyanazokat az eredményeket elérjük alacsonyabb költségek mellett, mint a „csillag” fejlesztő költsége. Az ilyen adminisztrátorokat a csapatba illesztették, és fő feladatuk a teszt- és produktív környezetek kezelése volt az éppen kiválasztott csapat szabályai szerint, a csapat számára elkülönített erőforrásokkal. Így valójában megjelentek a DevOps a többség szemében.

Részben vagy teljesen, idővel a rendszergazdák kezdték megérteni ennek a konkrét fejlesztőcsapatnak az igényeit arról, hogyan lehetne egyszerűbbé tenni a fejlesztők és tesztelők életét, hogyan lehetne frissítéseket telepíteni anélkül, hogy pénteken éjszakát kellene tölteniük az irodában a telepítési hibák javításával. Az idő telt, a rendszergazdák váltak a „csillagokká”, akik tudták, mit akarnak a fejlesztők. A hatás minimalizálása érdekében elkezdtek felbukkanni a kezelőprogramok, mindenki emlékezett a régi és megbízható operációs rendszer szintű izolációs módszerekre, amelyek lehetővé tették a biztonság, a hálózati kezelés, és a gazda konfigurációjának követelményeinek minimalizálását, aminek következtében csökkent az új „csillagokra” vonatkozó igény.

Megjelent egy „csodás” dolog — a docker. Miért csodás? Csak azért, mert a chroot vagy jail izolálása, akárcsak az OpenVZ, nem triviális operációs rendszertudást igényelt, míg egy olyan eszköz, amely lehetővé teszi egy egyszerű izolált alkalmazási környezet létrehozását egy hoszton, mindennel együtt, és lehetővé teszi, hogy a fejlesztés irányítása újból a fejlesztő kezébe kerüljön, míg a rendszergazda csak egy hosztot kell irányítania, biztosítva annak biztonságát és magas rendelkezésre állását — logikus egyszerűsítés. De a fejlődés nem áll meg, és a rendszerek ismét egyre bonyolultabbá válnak, a komponensek száma egyre nő, egy hoszt már nem elégíti ki a rendszer igényeit, és klasztereket kell építeni, ismét visszatérünk a rendszergazdákhoz, akik képesek felépíteni ezeket a rendszereket.

Ciklusok sorozataként különböző rendszerek jelennek meg, amelyek megkönnyítik a fejlesztést és/vagy az adminisztrálást, megjelennek az orkestrációs rendszerek, amelyek egészen addig könnyen használhatók, amíg nem szükséges eltérni a szabványos folyamattól. A mikroszolgáltatás architektúra szintén azért bukkant fel, hogy egyszerűsítse mindazt, amiről fent szó volt — kevesebb összefonódás, könnyebb kezelés. Tapasztalatom szerint soha nem találkoztam teljesen mikroszolgáltatás-architektúrával, azt mondanám, 50-50 arányban — 50 százalék mikroszolgáltatás, fekete doboz, ami bejött, feldolgozva jött ki, a másik 50 — szétszabdalt monolit, a szolgáltatások nem képesek más komponensektől függetlenül működni. Mindez újra korlátokat állított fel a tudásszintre, mind a fejlesztők, mind az adminisztrátorok számára.

Az ilyen tudásszintű „hintázások” a különböző források között még ma is folytatódnak. De egy kicsit eltértünk a témától, rengeteg olyan dolog van, amit érdemes megvilágítani.

Build Engineer/Release Engineer

Nagyon speciális mérnökök, akik a szoftverek összeállítási és kiadási folyamatait szabványosító eszközökként jelentek meg. Az Agile bevezetésével úgy tűnt, hogy eltűntek a színről, de ez közel sem így van. Ez a specializáció a szoftverek ipari méretű összeszerelésének és szállításának sematikus kidolgozása érdekében jött létre, vagyis a vállalat összes termékére vonatkozó szabványos technikák alkalmazásával. A DevOps megjelenésével a fejlesztők elvesztették egy részét a feladatoknak, mivel ők kezdték el az elkészült termék előkészítését a kiadásra, ugyanakkor a folyamatosan változó infrastruktúra és az a megközelítés, hogy a lehető leggyorsabban kell szállítani a minőség figyelembevétele nélkül, idővel a változások megállításához vezetett, mivel a minőségi szabványoknak való megfelelés elkerülhetetlenül lassítja a szállítást. Így a Build/Release mérnökök egy része fokozatosan a rendszergazdák feladatai közé került.

Olyan különböző Ops-ok

Tovább haladunk, és újra a széles körű felelősségek és a szakképzett munkaerő hiánya arra kényszerít minket, hogy szigorú specializációra törekedjünk, mint az eső utáni gombák, különböző műveletek jelennek meg:

• TechOps — rendszergazdák, azaz HelpDesk mérnökök
• LiveOps — rendszergazdák, akik elsősorban produktív környezetekért felelősek
• CloudOps — rendszergazdák, akik a nyilvános „felhőkre” specializálódtak, mint az Azure, AWS, GCP, stb.
• PlatOps/InfraOps/SysOps — infrastruktúra rendszergazdák.
• NetOps — hálózati rendszergazdák.
• SecOps — rendszergazdák, akik az információbiztonságra specializálódtak — PCI megfelelőség, CIS megfelelőség, javítások, stb.

A DevOps professional is someone who thoroughly understands all processes of the development cycle — development, testing, understands product architecture, can assess security risks, is familiar with automation approaches and tools, at least at a high level, and also understands pre and post-release product support. This person can advocate for both Operations and Development, fostering favorable collaboration between these two pillars. They comprehend the work planning processes of teams and manage customer expectations.

To perform such tasks and responsibilities, this individual must have management tools not only for development and testing processes but also for product infrastructure management and resource planning. In this understanding, DevOps cannot be solely in IT, R&D, or even in PMO; they must have influence across all these areas — a company's technical director or Chief Technical Officer.

Is this the case in your company? — I doubt it. In most cases, it's either IT or R&D.

A lack of resources and the ability to influence at least one of these three areas of activity will shift the burden of problems to where it is easier to implement these changes, such as the application of technical constraints on releases due to 'dirty' code, according to static analysis system data. That is, when the PMO sets a tight deadline for delivering functionality, and R&D cannot produce quality results within that timeframe, they deliver what they can, leaving refactoring for later, while DevOps related to IT blocks the release with technical means. The lack of authority to change the situation leads to employees taking excessive responsibility for things they cannot influence, especially if these employees understand and see the mistakes and how to fix them — 'Happiness in Ignorance,' leading to burnout and loss of these employees.

The DevOps resources market

Let's look at some DevOps job vacancies from different companies.

We are ready to meet with you if you:

1. Are proficient in Zabbix and know what Prometheus is;
2. Understand Iptables;
3. Are a BASH aspirant;
4. Are an Ansible professor;
5. Are a Linux guru;
6. Tud debuggolni és együtt dolgozni a fejlesztőkkel az alkalmazások (php/java/python) problémáinak megtalálásában;
7. A routing nem okoz Önnek pánikrohamot;
8. Jelentős figyelmet fordít a rendszer biztonságára;
9. Backupolja "mindig mindent", és sikeresen helyreállítja ezt a "mindent";
10. Tudja a rendszert úgy beállítani, hogy a minimálisból a maximumot hozza ki;
11. Éjjel Postgres és MySQL replikációkat állít be;
12. A CI/CD beállítása és korrekciója Önnek olyan szükségszerű, mint a reggeli/ebéd/vacsora.
13. Tapasztalattal rendelkezik az AWS-szel;
14. Készen áll arra, hogy a céggel fejlődjön;

Tehát:

• 1-től 6-ig - rendszergazda
• 7 - egy kis hálózati adminisztráció, ami szintén belefér a középszintű rendszergazda kategóriába
• 8 - egy kis biztonság, ami elengedhetetlen a középszintű rendszergazdához
• 9-11 - Középszintű Rendszergazda
• 12 - A feladatok függvényében lehet Középszintű Rendszergazda, vagy Build Engineer
• 13 - Virtualizáció - Középszintű Rendszergazda, vagy úgynevezett CloudOps, kiterjedt ismeretek a konkrét szolgáltatásokról hosztolást az adott platform hatékony pénzfelhasználása és a karbantartásra nehezedő terhek csökkentése érdekében

Összefoglalva a hirdetéssel kapcsolatban elmondható, hogy a srácoknak elegendő egy Középszintű/Seniorként Rendszergazda.

Egyébként nem érdemes túlságosan megkülönböztetni az adminokat Linuxra/Windowsra. Persze értem, hogy ezek a világok különbözőek, de az alapmindig ugyanaz, és minden magát tisztelő admin ismeri mindkettőt, sőt, ha nem ismeri, egy értelmes adminnak nem okoz nehézséget megismerkedni vele.

Nézzünk meg egy másik állást:

1. Tapasztalat magas terhelésű rendszerek kialakításában;
2. Kiváló ismeretek a Linux operációs rendszerről, általános szoftverekről és a webstack-ről (Nginx, PHP/Python, HAProxy, MySQL/PostgreSQL, Memcached, Redis, RabbitMQ, ELK);
3. Tapasztalat virtualizációs rendszerekkel (KVM, VMWare, LXC/Docker);
4. Ismeretek script nyelvekről;
5. Hálózati protokollok működésének megértése;
6. Megértése a megbízható rendszerek kiépítésének alapelveit;
7. Önállóság és kezdeményezőkészség;

Tekintsük át:

• 1 - Senior Rendszergazda
• 2 - A megcélzott értelem függvényében - Középszintű/Senior Rendszergazda
• 3 - A tapasztalat, beleértve, jelentheti azt is, hogy "Nem emelt fel klasztert, de virtuális gépeket létrehozott és kezelt, volt egy Docker host, a konténerekhez való hozzáférést NAT-olta" - Középszintű Rendszergazda
• 4 — Junior System Administrator — igen, egy admin, aki nem tud alapvető automatizálási szkripteket írni, függetlenül a nyelvtől, nem admin — szerviztechnikus.
• 5 — Middle System Administrator
• 6 — Senior System Administrator

Összefoglalva — Middle/Senior System Administrator

Még egy:

1. DevOps tapasztalat;
2. Tapasztalat egy vagy több CI/CD folyamatot támogatószoftver használatában. A Gitlab CI előny lesz;
3. Munka konténerekkel és virtualizációval; Ha használtál dockert – jó, de ha k8s-t – kiváló!
4. Tapasztalat agilis csapatban;
5. Bármely programozási nyelv ismerete;

Nézzük meg:

• 1 — Hmm… Mit értenek ez alatt a srácok? =) Valószínű, hogy ők sem tudják, mi rejlik mögötte.
• 2 — Build Engineer
• 3 — Middle System Administrator
• 4 — Soft-skillek, ezeket egyelőre nem fogjuk figyelembe venni, bár az Agile egy másik dolog, amit úgy értelmeznek, ahogy kedvük tartja.
• 5 — Túl tág — ez lehet szkriptnyelv vagy fordított nyelv. Érdekes, vajon ha a suliban Pascal-ban és Basic-ben írt, az rendben lenne? =)

Szeretnék megjegyzést fűzni a 3. ponthoz, hogy alátámasszam a megértést, miért fedi le ezt a rendszergazda. A Kubernetes csak egy orkestráció, egy eszköz, ami közvetlen parancsokat csomagol be a hálózati meghajtóknak és a virtualizációs/izolációs hosztoknak néhány parancsba, és lehetővé teszi, hogy az interakciójuk absztrakt legyen, ennyi az egész. Például vegyük a 'build framework'-öt, a Make-et, amit nem tekintetek valóban framenwork-nek. Igen, tudok a Make mindenhová való berakásának divatjáról, ahol szükség van rá és ahol nem — például a Maven Make-be csomagolása, komolyan?
Alapvetően a Make csak egy shell köré csomagolt egyszerűsített parancs, ami pontosan a fordítási, linkenési, fordítási környezeti parancsokat egyszerűsíti, akárcsak a k8s.

Egyszer interjúztattam egy fiút, aki a munkájában k8s-t használt OpenStack fölött, és ő mesélte, hogyan telepített szolgáltatásokat rá, azonban, amikor az OpenStack-ről kérdeztem, kiderült, hogy azt rendszergazdák üzemeltetik és indítják. Valóban azt gondoljátok, hogy az a személy, aki felemeli az OpenStack-et, függetlenül attól, hogy milyen platformot használ mögötte, nem képes használni a k8s-t? =)
Ez a pályázó valójában nem DevOps, hanem ugyanaz a Rendszergazda, és pontosabban Kubernetes Administrator.

Összefoglalva még egyszer — a Middle/Senior System Administrator nekik elegendő lesz.

Mennyit érdemes grammban mérni?

A megadott álláshirdetésekhez kínált bérszóródás — 90k-200k.
Most szeretném párhuzamot vonni a Rendszergazdák és a DevOps Mérnökök pénzbeli juttatásai között.

Alapvetően, a munkatapasztalat alapján egyszerűsíthetjük a kategóriákat, bár ez nem lesz pontos; a cikk céljaihoz elegendő.

Tapasztalat:

1. 3 évig — Junior
2. 6 évig — Middle
3. 6 év felett — Senior

A munkavállalók keresésére szolgáló webhely kínálja:
Rendszergazdák:

1. Junior — 2 év — 50k rubel.
2. Middle — 5 év — 70k rubel.
3. Senior — 11 év — 100k rubel.

DevOps Mérnökök:

1. Junior — 2 év — 100k rubel.
2. Middle — 3 év — 160k rubel.
3. Senior — 6 év — 220k rubel.

A «DevOps» szakemberek esetében a tapasztalatot figyelembe vették, amely valamilyen formában érinti az SDLC-t.

A fenti megállapítások alapján arra lehet következtetni, hogy a cégeknek valójában nincs szükségük DevOps szakemberekre, és hogy akár 50%-ot is megtakaríthatnának az eredetileg tervezett költségekből, ha Rendszergazdát alkalmaznának. Sőt, világosabban meghatározhatnák a keresett személy feladatait, és gyorsabban betölthetnék a szükséget. Ne feledjük, hogy a világos felelősségmegosztás csökkenti a személyzet iránti követelményeket, és kedvezőbb légkört teremt a csapaton belül a átfedések hiánya miatt. A legtöbb álláshirdetés tele van eszközökkel és DevOps címkékkel, de valójában nem támasztanak valódi igényeket a DevOps Mérnökökkel szemben, csupán kérdéseket tesznek fel a segédadminisztrátorok iránt.

A DevOps mérnökök képzésének folyamata is csupán egy specifikus munkák, eszközök halmazára korlátozódik, és nem ad átfogó képet a folyamatokról és azok összefüggéseiről. Ez természetesen jó, ha valaki képes Terraformot használva 10 perc alatt, egyetlen konzolparanccsal telepíteni az AWS EKS-t a Fluentd side-car használatával ebben a klaszterben, és az AWS ELK-t a naplózási rendszerhez, de ha nem érti a naplók feldolgozásának elvét és hogy mire van szükségük, és nem tudja, hogyan lehet a metrikákat összegyűjteni és nyomon követni a szolgáltatás romlását, akkor ez csak egy újabb segédadminisztrátor marad, aki egyes eszközöket használ.

A kereslet azonban kínálatot teremt, és azt látjuk, hogy a DevOps pozíciók piaca rendkívül túlmelegedett, ahol a követelmények nem felelnek meg a valós szerepnek, hanem csak lehetővé teszik a rendszergazdák számára, hogy többet keressenek.

Tehát kik ők? DevOps szakemberek vagy kapzsi rendszergazdák? =)

Hogyan tovább?

A munkaadóknak pontosabban kell megfogalmazniuk az elvárásaikat, és éppen azokat keresniük, akikre szükségük van, nem pedig címkéket osztogatniuk. Ha nem tudja, mivel foglalkoznak a DevOps szakemberek, akkor nincs szüksége rájuk.

A munkavállalóknak tanulniuk kell. Folyamatosan fejleszteniük kell a tudásukat, átfogó képet kell kapniuk a folyamatokról és nyomon kell követniük a kitűzött cél felé vezető utat. Bárkivé válhatnak, csak erőfeszítést kell tenniük.

Forrás: habr.com