Az utóbbi időben ilyen reklámok lepték el az internetet. A kellemes fizetés ellenére nem lehet nem szégyellni, hogy vad eretnekség van odabent írva. Először azt feltételezik, hogy a „DevOps” és a „mérnök” valamilyen módon összeragasztható egy szóban, majd jön egy véletlenszerű követelménylista, amelyek egy része egyértelműen a sysadmin üresedésből másolódik.
Ebben a bejegyzésben szeretnék egy kicsit beszélni arról, hogyan jutottunk el az élet idáig, mi is valójában a DevOps, és mit kezdjünk vele most.
Az ilyen üresedéseket minden lehetséges módon el lehet ítélni, de tény marad: sok van belőlük, és jelenleg így működik a piac. Devops konferenciát tartottunk, és nyíltan kijelentjük: „ - nem a DevOps mérnökök számára." Ez sokak számára furcsának és vadnak tűnik: miért mennek szembe a piaccal azok az emberek, akik egy teljesen kommersz rendezvényt szerveznek. Most mindent megmagyarázunk.
A kultúráról és a folyamatokról
Kezdjük azzal a ténnyel, hogy a DevOps nem mérnöki tudományág. Az egész azzal kezdődött, hogy a történelmileg kialakult szerepmegosztás nem működik a termékek minőségén. Amikor a programozók csak programoznak, de hallani sem akarnak a tesztelésről, a szoftver tele van hibákkal. Amikor az adminisztrátorokat nem érdekli, hogyan vagy miért írják a szoftvert, a támogatás pokollá változik.
Például leírja a különbséget a rendszeradminisztrátor és a szolgáltatásmenedzsment SRE megközelítése között . Érdekes tanulmányok készültek ezen belül - Nyilvánvaló, hogy a legjobb fejlesztőknek valahogy gyorsabban sikerül új változtatásokat bevezetni a termelésbe, mint óránként. A kezükkel legfeljebb 10%-ot tesztelnek (ez látható a ). Hogyan csinálják ezt? „Excel or die” – mondja a jelentés egyik fejléce. A teszteléssel összefüggésben ezeknek a statisztikáknak a részletes tárgyalásához lásd Baruch Sadogursky vitaindítóját. másik konferenciánkon, a Heisenbugban.
„Amikor nincs egyetértés az elvtársak között,
Nem fog jól menni az üzletük,
És nem lesz belőle semmi, csak liszt.
Valamikor egy hattyú, egy rák és egy csuka..."
Ön szerint a webprogramozók melyik része érti igazán, milyen feltételek mellett használják alkalmazásait a termelésben? Hányan fognak bemenni az adminokhoz, és megpróbálják kitalálni, mi történik, ha az adatbázis összeomlik? És melyikük fog elmenni a tesztelőkhöz, és megkérni őket, hogy tanítsák meg őket a tesztek helyes megírására? És vannak még biztonsági őrök, termékmenedzserek és még egy csomó ember.
A DevOps általános ötlete a szerepek és a részlegek közötti együttműködés létrehozása. Először is, ezt nem valami okosan konfigurált szoftverrel, hanem a kommunikáció gyakorlásával érik el. A DevOps a kultúráról, gyakorlatokról, módszertanról és folyamatokról szól. Nincs olyan mérnöki szakterület, amely választ tudna adni ezekre a kérdésekre.
Ördögi kör
Honnan jött akkor a „devops engineering” tudományága? Van egy verziónk! A DevOps ötletek jók voltak – olyan jók, hogy saját sikerük áldozatai lettek. Néhány árnyékos toborzó és embercsempész, akiknek megvan a maga atmoszférája, elkezdtek kavarogni ezen az egész téma körül.
Képzeld el: tegnap shawarmát készítettél Khimkiben, ma pedig már nagy ember vagy, rangidős toborzó. A jelöltek keresésének és kiválasztásának egész folyamata zajlik, nem minden egyszerű, meg kell érteni. Tegyük fel, hogy egy osztályvezető azt mondja: keress egy szakembert X-ben. A „mérnök” szót hozzárendeljük X-hez, és kész. Linux kell? Nos, ez határozottan egy Linux-mérnök, ha DevOps-t akarsz, akkor DevOps-mérnök. Az állás nem csak címből áll, hanem szöveget is be kell írni. A legegyszerűbb módja, ha beír egy kulcsszókészletet a Google-ból, képzeletétől függően. A DevOps két szóból áll – „Dev” és „Ops”, ami azt jelenti, hogy össze kell ragasztanunk a fejlesztőkkel és rendszergazdákkal kapcsolatos kulcsszavakat, mindezt egy kupacba. Így jelennek meg az üresedések a 42 programozási nyelv ismeretéről, valamint a Kubernetes és a Swarm 20 évnyi egyidejű használatáról. Működési diagram.
Így gyökeret vert az emberek fejében egy bizonyos „devops” szuperhős értelmetlen és kíméletlen képe, aki mindenkit beállít Jenkinshez, és jön a boldogság. Ó, ha minden ilyen egyszerű lenne. „És így lehet levadászni a rendszergazdákat is – gondolja a HR-es –, divatos szó, ugyanazok a kulcsszavak, ők kapják meg a csalit.”
A kereslet teremti meg a kínálatot, és ezeket a szemetes állásokat őrülten sok rendszergazdával töltötték be, akik rájöttek: mindent ugyanúgy csinálhatsz, mint korábban, de többször is többet kaphatsz, ha "devops"-nak nevezed magad. Ugyanúgy, ahogy egyenként manuálisan konfiguráltad a szervereket SSH-n keresztül, továbbra is konfigurálod őket, de most ez állítólag egy devops gyakorlat. Ez valamiféle összetett jelenség, részben a klasszikus adminisztrátorok alábecsüléséhez és a DevOps körüli hype-hoz kapcsolódik, de általában ami történt, az megtörtént.
Tehát van kereslet és kínálat. Ördögi kör, amely önmagát táplálja. Ez ellen küzdünk (többek között a DevOops konferencia létrehozásával).
Természetesen a magukat „devops”-nak átnevező rendszergazdákon kívül más résztvevők is vannak – például professzionális SRE-k vagy Infrastructure-as-Code fejlesztők.
Mit csinálnak az emberek a DevOps-ban (tényleg)
Tehát szeretne előrébb jutni a DevOps gyakorlatok tanulásában és alkalmazásában. De hogyan kell ezt megtenni, milyen irányba kell nézni? Nyilvánvalóan nem szabad vakon a népszerű kulcsszavakra hagyatkozni.
Ha van munka, valakinek meg kell csinálnia. Azt már megtudtuk, hogy ezek nem „devops mérnökök”, akkor kik azok? Helyesebbnek tűnik ezt nem pozíciók, hanem konkrét munkaterületek szerint megfogalmazni.
Először is megszólíthatja a DevOps lényegét – a folyamatokat és a kultúrát. A kultúra lassú és nehéz üzlet, és bár ez hagyományosan a menedzserek felelőssége, a programozóktól az adminisztrátorokig mindenki benne van így vagy úgy. Pár hónappal ezelőtt Tim Lister :
„A kultúrát a szervezet alapértékei határozzák meg. Általában ezt nem veszik észre az emberek, de miután hosszú évek óta dolgozunk a tanácsadásban, megszoktuk, hogy ezt észrevesszük. Belépsz egy társaságba, és szó szerint néhány percen belül kezded érezni, mi történik. Ezt "íznek" hívjuk. Néha nagyon jó ez az illat. Néha hányingert okoz. (...) Nem lehet megváltoztatni egy kultúrát, amíg meg nem értik a konkrét tettek mögött rejlő értékeket és hiedelmeket. A viselkedést könnyű megfigyelni, de a hiedelmek után kutatni nehéz. A DevOps csak egy nagyszerű példa arra, hogy a dolgok egyre bonyolultabbá válnak.”
A kérdésnek természetesen van technikai része is. Ha az új kódot egy hónap múlva tesztelik, de csak egy év múlva adják ki, és fizikailag lehetetlen mindezt felgyorsítani, akkor előfordulhat, hogy nem felel meg a bevált gyakorlatoknak. A jó gyakorlatokat jó eszközök támogatják. Például az Infrastructure-as-Code gondolatát szem előtt tartva bármit használhat az AWS CloudFormationtől és a Terraformtól a Chef-Ansible-Puppetig. Mindezt tudni és tudni kell, és ez már eléggé mérnöki tudományág. Fontos, hogy ne keverjük össze az okot az okozattal: először az SRE elvei szerint kell dolgozni, és csak azután valósítja meg ezeket az elveket néhány konkrét műszaki megoldás formájában. Ugyanakkor az SRE egy nagyon átfogó módszertan, amely nem mondja meg, hogyan kell beállítani a Jenkinst, hanem körülbelül öt alapelvet:
- Jobb kommunikáció a szerepkörök és a részlegek között
- A hibák elfogadása a munka szerves részeként
- A változtatások fokozatos végrehajtása
- Szerszámozás és egyéb automatizálás használata
- Mérni mindent, ami mérhető
Ez nem csak néhány kijelentés, hanem egy konkrét . Például a hibák elfogadása felé vezető úton meg kell értenie a kockázatokat, meg kell mérnie a szolgáltatások elérhetőségét és elérhetetlenségét olyasmivel, mint az SLI () és SLO (), tanuljon meg postmortemeket írni, és ne tegye félelmetessé az írást.
Az SRE tudományágban az eszközök használata csak egy része a sikernek, bár fontos. Folyamatosan kell technikailag fejlődnünk, nézni, mi történik a világban, és hogyan lehet ezt a munkánkban alkalmazni.
A Cloud Native megoldások viszont mára nagyon népszerűvé váltak. A Cloud Native Computing Foundation mai meghatározása szerint a Cloud Native technológiák lehetővé teszik a szervezetek számára, hogy méretezhető alkalmazásokat fejlesszenek és futtassanak a mai dinamikus környezetekben, például nyilvános, privát és hibrid felhőkben. Ilyenek például a tárolók, szolgáltatáshálók, mikroszolgáltatások, megváltoztathatatlan infrastruktúra és deklaratív API-k. Mindezek a technikák lehetővé teszik, hogy a lazán csatolt rendszerek rugalmasak, kezelhetők és jól megfigyelhetőek maradjanak. A jó automatizálás lehetővé teszi a mérnökök számára, hogy gyakran és kiszámítható eredménnyel nagy változtatásokat hajtsanak végre anélkül, hogy ez megterhelné. Mindezt egy halom jól ismert eszköz támogatja, mint például a Docker és a Kubernetes.
Ez a meglehetősen bonyolult és tág meghatározás annak köszönhető, hogy a terület is meglehetősen összetett. Egyrészt azzal érvelnek, hogy ehhez a rendszerhez egészen egyszerűen új változtatásokat kell bevinni. Másrészt kitalálni, hogyan lehet egyfajta konténeres környezetet létrehozni, amelyben a lazán összekapcsolt szolgáltatások egy szoftveresen definiált infrastruktúrán élnek, és ott folyamatos CI/CD-vel kerülnek kiszállításra, és mindezek köré DevOps gyakorlatokat építeni - mindez többet igényel. mint egy megenni a kutyát.
Mit kezdjen ezzel az egésszel
Mindenki a maga módján oldja meg ezeket a problémákat: például közzétehet normál üresedéseket, hogy megtörje az ördögi kört. Kitalálhatja, mit jelentenek az olyan szavak, mint a DevOps és a Cloud Native, és helyesen és célszerűen használhatja őket. Fejleszthet a DevOps-ban, és példáján keresztül bemutathatja a megfelelő megközelítéseket.
Konferenciát tartunk , amely lehetőséget ad arra, hogy mélyebben elmélyüljünk az imént beszélt dolgokban. Ehhez több jelentéscsoport létezik:
- Folyamatok és kultúra;
- Telephely-megbízhatósági tervezés;
- Cloud Native;
Hogyan válasszunk hova menjünk? Van itt egy finom pont. Egyrészt a DevOps az interakcióról szól, és nagyon szeretnénk, hogy különböző blokkokból vegyen részt előadásokon. Másrészt, ha Ön egy fejlesztési vezető, aki azért jött el a konferenciára, hogy egy konkrét feladatra koncentráljon, akkor senki nem korlátozza – ez nyilván a folyamatok és a kultúra blokkja lesz. Ne felejtsd el, hogy a konferencia után (a visszajelzési űrlap kitöltése után) lesznek felvételeid, így később mindig megtekintheted a kevésbé fontos előadásokat.
Magán a konferencián természetesen nem lehet egyszerre három pályán haladni, ezért úgy szervezzük a programot, hogy minden idősávban minden ízlésnek megfelelő téma legyen.
Nincs más hátra, mint megérteni, mit kell tennie, ha Ön DevOps mérnök! Először is próbálja meghatározni, hogy mit csinál valójában. Általában szeretik ezt a szót hívni:
- Az infrastruktúrán dolgozó fejlesztők. Az SRE-ről és a Cloud Native-ről szóló jelentéscsoportok a legalkalmasabbak az Ön számára.
- Rendszergazdák. Itt bonyolultabb a helyzet. A DevOops nem a rendszeradminisztrációról szól. Szerencsére rengeteg kiváló konferencia, könyv, cikk, videó található az interneten a rendszeradminisztráció témájában. Másrészt, ha érdekel a kultúra és folyamatok megértése, a felhőtechnológiák és az élet részleteinek megismerése a Cloud Native segítségével, akkor szívesen látunk! Gondoljon erre: Ön adminisztrációt végez, és akkor mit fog tenni? Annak elkerülése érdekében, hogy hirtelen kellemetlen helyzetbe kerüljön, most tanulnia kell.
Van egy másik lehetőség: kitartasz, és továbbra is azt állítod, hogy az vagy konkrétan egy DevOps mérnök és semmi más, bármit is jelentsen ez. Akkor csalódást kell okoznunk, a DevOops nem a DevOps mérnökök konferenciája!
Csúszás innen Münchenben
A DevOops 2020 Moszkva április 29-30-án kerül megrendezésre Moszkvában, jegyek már kaphatók .
Alternatív megoldásként megteheti február 8-ig. Felhívjuk figyelmét, hogy az űrlap kitöltésekor ki kell választania azt a célközönséget, amely a legtöbb hasznot húzza jelentéséből (van egy meglepetés eltemetve a listán).
Forrás: will.com