Az utóbbi időben ilyen hirdetésekkel telítődött az internet. A kellemes fizetés ellenére zavaró, hogy belül olyan abszurd dolgokat írnak, hogy először azt feltételezik, a „DevOps” és az „mérnök” valahogy összevonható. Ezt követi egy véletlenszerű követelménylista, amelyből egyes részek nyilvánvalóan a rendszergazda állásajánlásából származnak.
Ebben a bejegyzésben szeretnék egy kicsit beszélni arról, hogy jutottunk el idáig, mi is a DevOps valójában, és most mit kezdjünk ezzel.
Ilyen álláshirdetéseket sokáig lehetne kritizálni, de a tény az tény: sokan vannak, és a piac most így működik. Rendezettünk egy DevOps konferenciát, és nyíltan kijelentjük: „ — nem DevOps mérnökök számára”. Sokan furcsának és abszurdnak találják majd: miért mennek szembe a piachoz kötődő profitorientált rendezvény szervezői. Most mindent elmagyarázunk.
Kulturáról és folyamatokról
Kezdjük azzal, hogy a DevOps nem mérnöki diszciplína. Minden akkor kezdődött, amikor a szerepek történelmi felosztása nem járult hozzá a termékek minőségéhez. Amikor a programozók csak programoznak, de semmit sem akarnak hallani a tesztelésről — a szoftver tele lesz hibákkal. Amikor az adminisztrátorokat nem érdekli, hogyan és miért készült el a szoftver — a támogatás pokollá válik.
Például a rendszergazdai és SRE megközelítések közötti különbség leírása . Érdekes kutatásokat végeztek a — látható, hogy a legjobb fejlesztők valahogyan gyorsabban képesek új változtatásokat telepíteni a termelésbe, mint óránként egyszer. Ők kézzel legfeljebb a tesztelési feladatok 10%-át végzik el (ez a ). Hogy csinálják ezt? „Excel vagy halál” – mondja egy jelentés címe. A tesztelés szempontjából a statisztika részletes megvitatásához Baruch Sadogursky keynote-jára lehet hivatkozni, a másik konferenciánkon, a Heisenbug-on.
„Amikor a társak között nincs egyetértés,
Nincs előrelépés,
S csak kínlódás marad, ami abból fakad.
Egyszer egy hattyú, rák és csuka…"
Mit gondolsz, a webprogramozók hány százaléka érti valójában, milyen körülmények között futnak az alkalmazásaik a termelésben? Hányan mennek el az adminisztrátorokhoz, hogy megtudják, mi fog történni, ha meghibásodik az adatbázis? És ki az, aki elmegy a tesztelőkhöz, hogy megtanulja, hogyan kell helyesen írni a teszteket? És ott vannak még a biztonsági szakemberek, a termékmenedzserek, meg még sok más ember.
A DevOps általános ötlete a szerepek és osztályok közötti együttműködés elősegítése. Ezt elsősorban nem valamilyen bonyolultan megszabott szoftverrel, hanem a kommunikáció gyakorlatával érik el. A DevOps a kultúra, a gyakorlat, a metodológia és a folyamatok szól. Nincs olyan mérnöki szakma, amely válaszolna ezekre a kérdésekre.
Bezárt kör
Akkor honnan jött a "devops mérnöki" diszciplína? Van egy elméletünk! A DevOps ötletei olyan jók voltak — annyira, hogy a sikerük áldozatai lettek. Az egész téma körül furcsa toborzók és emberek kereskedése kezdett el gyülekezni, akiknek sajátos légkörük van.
Képzeld el: tegnap még Himmkieben kebabot árultál, ma pedig már nagy ember vagy, senior toborzó. Itt egy egész folyamat van a jelöltek keresésére és kiválasztására, nem egyszerű, érteni kell. Tegyük fel, a részlegvezető azt mondja: találj egy szakembert X-területen. Hozzáfűzzük az X-hez a szót "mérnök", és már meg is van. Kell Linux? Akkor biztosan Linux-mérnök, ha DevOps — DevOps-mérnök. A hirdetés nem csak a címről szól, hanem belül is kell írni valamilyen szöveget. A legegyszerűbb, ha egy kész kulcsszóhalmazt írunk be a Google-ból, akinek van elég fantáziája. A DevOps két szóból áll — "Dev" és "Ops", így kulcsszavakat kell összekapcsolni a fejlesztők és az adminisztrátorok területéről, mindent egy kupacba. Így jönnek létre az álláshirdetések, amelyek 42 programozási nyelv ismeretét és 20 év Kubernetes és Swarm párhuzamos használatát követelik meg. Ez a munka folyamat.
Ilyen módon az emberek tudatában megerősödött a tartalmatlan és kíméletlen kép a különféle szuperhős "devopsról", aki mindenkinek beállítja a deploy-t a Jenkinsre, és elérkezik a boldogság. Ó, bárcsak minden olyan egyszerű lenne. "És így toborozhatunk rendszergazdákat is — gondolja a HR-es, — ez egy divatos szó, a kulcsszavak ugyanazok, biztosan rá fognak kattanni."
A kereslet kínálatot teremt, és ezekre a szörnyű álláshirdetésekre őrült mennyiségű rendszergazda vetődött, akik rájöttek: mindazt, amit régen csináltak, megtehetik most is, de sokkal több pénzt kapnak, ha DevOps-osnak hívják magukat. Ahogyan korábban SSH-n keresztül egyesével állítottad be a szervereket, úgy fogod továbbra is csinálni, de most ezt állítólag DevOps-praktikának hívják. Ez egy bonyolult jelenség, ami részben a klasszikus adminisztrátorok alábecsülésével és a DevOps körüli hype-pal is összefügg, de végső soron — ami lett, az lett.
Tehát van kereslet és kínálat. Ez egy önfenntartó ördögi kör. Ezzel küzdünk (többek között a DevOops konferencia létrehozásával).
Természetesen a «devops» néven átkonvertált rendszergazdák mellett más résztvevők is vannak — például szakmai SRE-k vagy Infrastructure-as-Code fejlesztők.
Valójában mivel foglalkoznak az emberek a DevOpsban
Tehát szeretnél előrelépni a DevOps gyakorlatok megismerésében és alkalmazásában. De hogyan lehet ezt megtenni, melyik irányba érdemes nézni? Nyilvánvaló, hogy nem szabad vakon követni a népszerű kulcsszavakat.
Ha van munka, valakinek foglalkoznia kell vele. Már megállapítottuk, hogy ez nem «devops mérnök», akkor ki az? Talán helyesebb lenne ezt nem a pozíciók kifejezésében, hanem a konkrét munkaterületek szerint megfogalmazni.
Először is foglalkozhatsz a DevOps szívével — a folyamatokkal és a kultúrával. A kultúra nem gyors és nem könnyű dolog, és bár ez hagyományosan a vezetők felelőssége, valamilyen módon mindenki részt vesz benne, a programozóktól az adminisztrátorokig. Néhány hónapja Tim Lister :
«A kultúrára az alapvető értékek határozzák meg. Az emberek általában nem veszik észre, de mi, akik több éve dolgozunk a tanácsadói szektorban, hozzászoktunk ezt észrevenni. Belépsz egy cégbe, és szó szerint néhány percen belül elkezded érezni, hogy mi történik. Ezt nevezzük «illatnak». Néha ez az illat valóban jó. Néha hányingert kelt. (…) Nem tudod megváltoztatni a kultúrát, amíg nem tudatosították az értékeket és meggyőződéseket, amelyek a konkrét cselekedetek mögött állnak. A viselkedést könnyű megfigyelni, de a meggyőződéseket nehéz keresni. A DevOps tökéletes példa arra, hogy minden egyre bonyolultabbá válik.»
Természetesen van a kérdésnek egy technikai oldala is. Ha egy új kódot egy hónap múlva tesztelésre küldenek, de a kiadás csak egy év múlva valósul meg, és fizikailag nem lehet felgyorsítani a folyamatot — nem biztos, hogy elérjük a jó gyakorlatokat. A jó gyakorlatokat jó eszközök támogatják. Például az Infrastructure-as-Code elvét szem előtt tartva használhatunk bármit az AWS CloudFormation és Terraform-tól kezdve a Chef-Ansible-Puppet-ig. Ezt mind tudni és érteni kell, és ez már egy valódi mérnöki tudományág. Fontos, hogy ne keverjük össze az okot és a következményeket: először az SRE elveit alkalmazzuk, és csak utána valósítjuk meg ezeket a konkrét technikai megoldások formájában. Az SRE egy nagyon összetett módszertan, amely nem arról szól, hogyan állítsuk be a Jenkinst, hanem öt alapelvről szól:
- A szerepek és osztályok közötti együttműködés javítása
- A hibák elfogadása, mint a munka elválaszthatatlan része
- A változások fokozatos végrehajtása
- Eszközök és egyéb automatizálás használata
- Minden mérhető dolog mérésének szükségessége
Ez nem csupán egy állítások gyűjteménye, hanem egy konkrét . Például a hibák elfogadásának útján meg kell értenünk a kockázatokat, és mérni kell a szolgáltatások elérhetőségét és elérhetetlenségét valami olyan eszközzel, mint az SLI () és SLO (), meg kell tanulni posztmortem jelentéseket írni, és biztosítani kell, hogy a megírásuk ne okozzon félelmet.
Az SRE diszciplínában az eszközök használata csak a siker egy része, de nem elhanyagolható tényező. Folyamatosan fejlődnünk kell technikai szempontból, figyelnünk kell, hogy mi történik a világban és hogyan alkalmazhatjuk mindezt a munkánkban.
Jelenleg a Cloud Native megoldások rendkívül népszerűvé váltak. A Cloud Native Computing Foundation modern értelmezése szerint a Cloud Native technológiák lehetővé teszik a szervezetek számára, hogy skálázható alkalmazásokat fejlesszenek és indítsanak el a mai dinamikus környezetekben, mint például nyilvános, magán és hibrid felhők. Példaként említhetők a konténerek, szolgáltatás-mesh-ek, mikroszolgáltatások, változatlan infrastruktúra és deklaratív API-k. Mindezek a technikák lehetővé teszik a gyenge kapcsolódású rendszerek számára, hogy rugalmasak, kezelhetőek és jól megfigyelhetőek maradjanak. A jó automatizálás lehetővé teszi a mérnökök számára, hogy nagy változtatásokat végezzenek gyakran és előre megjósolható eredményekkel, anélkül, hogy ez borzalmas munkává válna. Mindezt olyan közismert eszközök szettje támogatja, mint a Docker és a Kubernetes.
Ez meglehetősen összetett és kiterjedt meghatározás, amely azért van, mert a terület is meglehetősen bonyolult. Egyrészt azt állítják, hogy az új változásokat ennek a rendszernek viszonylag egyszerűen kellene hozzáadni. Másrészt ahhoz, hogy megértsük, hogyan hozhatunk létre egy konténerizált környezetet, ahol a gyenge kapcsolódású szolgáltatások szoftver-vezérelt infrastruktúrában élnek és folyamatos CI/CD segítségével kerülnek oda, és hogy DevOps gyakorlatokat építsünk mindez köré – ahhoz sok tapasztalat szükséges.
Mit kezdjünk mindezzel?
Mindenki a saját módján oldja meg ezeket a problémákat: például normális álláshirdetések közzétételével lehet szakítani a zárt körforgással. Meg lehet érteni, mit jelentenek olyan szavak, mint a DevOps és a Cloud Native, és helyesen, a megfelelő kontextusban lehet használni őket. Fejlődhetünk a DevOps területén, és saját példánkkal mutathatjuk a helyes megközelítéseket.
Mi konferenciát szervezünk. , amely lehetőséget biztosít arra, hogy mélyebben megérthessük azokat a dolgokat, amelyeket éppen most vitattunk meg. Erre több előadáscsoport is létezik:
- Folyamatok és kultúra;
- Site Reliability Engineering;
- Cloud Native;
Hogyan válasszunk, hova menjünk? Van itt egy finom pont. Egyrészt a DevOps a kapcsolatról szól, és nagyon szeretnénk, ha különböző blokkokból hallgatnátok előadásokat. Másrészt, ha te egy fejlesztési vezető vagy, aki azért jött a konferenciára, hogy egy konkrét feladatra összpontosítson, akkor senki sem korlátoz téged - nyilvánvalóan ez a folyamatok és kultúra blokk lesz. Ne feledd, hogy a konferencia után megmaradnak a felvételek (a visszajelző űrlap kitöltése után), így mindig megnézheted a kevésbé fontos előadásokat később.
Nyilvánvaló, hogy a konferencián nem tudod egyszerre három szekcióra is elmenni, ezért így alakítjuk a programot, hogy minden időpontra legyen téma bármilyen ízlésnek.
Csak meg kell értened, mit tegyél, ha DevOps mérnök vagy! Először is, próbáld meg meghatározni, mivel is foglalkozol valójában. Ezt a szót általában a következőkre használják:
- Azokra a fejlesztőkre, akik az infrastruktúrával foglalkoznak. Számotokra a leginkább a SRE és Cloud Native előadások sorozatai fognak megfelelni.
- Rendszergazdákra. Itt nehezebb a helyzet. A DevOops nem a rendszergazdaságról szól. Szerencsére a rendszergazdálkodásról sok csodás konferencia, könyv, cikk, videó található az interneten, stb. Másrészt, ha érdekel a kultúra és folyamatok megértése, a felhős technológiák tanulmányozása és a Cloud Native életének részletei, örömmel látunk! Gondolkodjatok el ezen: ti a rendszergazdasággal foglalkoztok, és utána mi lesz a következő lépés? Hogy elkerüljétek a kellemetlen helyzeteket, érdemes most tanulni.
Van még egy lehetőség: ragaszkodtok hozzá, hogy ti pontosan DevOps mérnökök vagytok és semmi más, akármennyire is jelent ez valamit. Akkor sajnálattal kell közölnöm, hogy a DevOops nem DevOps mérnököknek szól!
Dia a Münchenben
A DevOops 2020 Moszkva április 29-30-án Moszkvában kerül megrendezésre, a jegyek már megvásárolhatók .
Ezen kívül lehetőséged van február 8-ig. Ne feledd, hogy az űrlap kitöltésekor választanod kell a célcsoportot, amelynek az előadásod a legnagyobb hasznot hozza (a listában meglepetés rejtőzik).
Forrás: habr.com
