Hová menjen ezzel a tudással, mit tegyen a projektben és mennyit keressen, mit mondjon és kérdezzen egy interjún - mondja Alexander Titov, az Express 42 ügyvezető partnere és a szerző .
Helló! Bár a DevOps kifejezés 2009 óta létezik, az orosz közösségben még mindig nincs konszenzus. Valószínűleg észrevetted, hogy egyesek a DevOps-t különlegességnek, mások filozófiának, mások pedig technológiák halmazának tartják a kifejezést. Már sokszor felléptem vele ennek az iránynak a fejlődéséről, ezért ebben a cikkben nem részletezem. Hadd mondjam el, hogy az Express 42-ben a következőket tartalmazza:
A DevOps egy sajátos módszertan, egy digitális termék létrehozásának kultúrája, amikor a csapat minden szakembere részt vesz a gyártásban.
A klasszikus vállalati fejlesztésben minden szekvenciálisan megy: programozás, tesztelés és csak utána üzemeltetés, ennek a folyamatnak a sebessége az ötlettől a gyártásig 3 hónap. Ez a digitális termékek globális problémája, mivel lehetetlen gyorsan visszajelzést kapni az ügyfelektől.
A DevOps eszközei és megközelítései úgy vannak kialakítva, hogy biztosítsák a fejlesztési, tesztelési és üzemeltetési folyamatok egyidejű futtatását.
Mi következik ebből a megközelítésből?
- Nem lehet olyan „mérnököt” felvenni, aki eljön és megoldja a termelés minden problémáját. Az egész csapatnak alkalmaznia kell a technikát.
- A DevOps NEM a rendszergazda következő formája, amelyre frissíteni kell. A „DevOps mérnök” nagyjából ugyanúgy hangzik, mint az „Agilis fejlesztő”.
- Ha egy csapat Kubernetes-t, Ansible-t, Prometheust, Mesosphere-t és Dockert használ, ez nem jelenti azt, hogy a DevOps gyakorlatokat implementálták ott.
Az élet a DevOps után soha nem lesz a régi
A DevOps megközelítés mindenekelőtt egy másfajta gondolkodásmód, a fejlődés egészének és a folyamatban betöltött helyének felfogása. Online tanfolyamunkat 2 blokkra osztottuk:
1. Önrendelkezés
Először is részletesen megvizsgáljuk a DevOps megközelítés lényegét, és a hallgatók új szerepeket fedeznek fel a csapatban, megnézik, melyik reagál jobban, és maguk határozzák meg, melyik irányba fejlődjenek.
2. Eszközök és gyakorlatok
A hallgatók konkrét technológiákat sajátítanak el a DevOps módszer szemszögéből.
A DevOps eszközök a DevOps megközelítésben és a klasszikus fejlesztésben egyaránt használhatók. A legkézenfekvőbb példa az Ansible konfigurációkezelő eszköz használata. A DevOps „Infrastructure as Code” gyakorlat megvalósítására hozták létre és alkották meg, ami azt jelenti, hogy a rendszer különböző állapotait írják le, az operációs rendszer beállításaitól az alkalmazásszoftverekig. A leírás rétegekre van osztva, és lehetővé teszi egy összetett, folyamatosan változó konfiguráció kezelését. A mérnökök azonban gyakran használják az Ansible-t bash szkriptek futtatására több gépen. Ez se nem rossz, se nem jó, de meg kell értened, hogy az Ansible jelenléte nem garantálja a DevOps jelenlétét a cégben.
Folyamatban vagyunk Elmerülhet a híres Reddithez hasonló alkalmazás fejlesztési folyamatában, kezdve annak monolitikus verziójával, lépésről lépésre haladva a mikroszolgáltatások felé. Lépésről lépésre elsajátítjuk az új eszközöket: Git, Ansible, Gitlab, és befejezzük a Kubernetes és a Prometheus.
A gyakorlatok tekintetében a DevOps Kézikönyvben leírt három út taktikáját követjük - folyamatos szállítási gyakorlatok, visszacsatolási gyakorlatok, és a teljes tanfolyam lényege a folyamatos tanulás gyakorlata a rendszerrel együtt.
Mit ad ez a tudás az egyes szakembereknek?
Rendszergazdáknak
A gyakorlatok lehetővé teszik, hogy elmozduljon az adminisztrációtól a folyamatos szállítási folyamat és a szoftverszállítás infrastrukturális platformja felé. A lényeg az, hogy létrehoz egy terméket – egy infrastruktúra-platformot a fejlesztők számára, amely segíti őket, hogy a változtatásokat gyorsan áttegyék a termelésbe.
Korábban a rendszergazdák jelentették az utolsó bástyát, utána megy minden a termelésbe. És alapvetően folyamatos tűzoltással foglalkoztak - ennek tükrében elég nehéz elmélyülni a vállalkozás igényeiben, gondolkodni a termékről és a felhasználó előnyeiről.
A DevOps módszernek köszönhetően megváltozik a gondolkodás. A rendszergazda tudja, hogyan kell a konfigurációt kódba fordítani, milyen gyakorlatok léteznek erre.
Ez azért fontos, mert a cégek egyre inkább belátják, hogy nemcsak automatizálniuk kell mindent, pl. amit a régi iskola rendszergazdái szoktak megtenni, akik ráadásul keveset kommunikáltak, és nem tájékoztatták a csapatot minden változtatásról. Most azokat keresik a csapatok, akik a belső infrastruktúra-termék gyártójává válnak, és segítik a szétválasztott folyamatok egybefűzését.
A fejlesztőknek
A fejlesztő abbahagyja az algoritmusokban való gondolkodást. Elsajátítja az infrastruktúrával való munkavégzés, a táj építészeti tudatosságának készségét. Az ilyen fejlesztő tisztában van az alkalmazás működésével, hogyan megy keresztül a folyamatos szállítási folyamaton, hogyan kell figyelemmel kísérni, hogyan kell regisztrálni, hogy az az ügyfél számára előnyös legyen. Ennek eredményeként mindezen ismeretek lehetővé teszik a releváns kód írását.
Tesztelőknek
A tesztelés már régóta átáll az automatikus módba, mindannyian azt mondjuk, hogy sok tesztet nem kell elvégezni, hanem írni :) A tesztelés a termék teljes szállítási folyamatának részévé válik. A tesztelőnek nemcsak meg kell tanulnia kódot írni, hanem azt is meg kell értenie, hogyan integrálhatja azt folyamatos kézbesítési rendszerekbe, hogyan kaphat visszajelzést a kódtól a kézbesítés minden szakaszában, és hogyan fejlesztheti folyamatosan a tesztelést a hibák észlelése érdekében. lehető legkorábban.
És hát az is kiderül mind a három szakasz egyszerre megy végbe. Például így nézhet ki:
A fejlesztő megírja a kódot, azonnal teszteket ír hozzá, és leír egy docker-tárolót a futtatandó kódhoz. Azonnal leírja azt a monitorozást is, amely ennek a szolgáltatásnak a működését fogja figyelni a termelésben, és mindezt leköti.
A folyamatos integráció megkezdésekor a folyamatok egyidejűleg futnak. A szolgáltatás elindul és konfigurálva van. Ezzel egyidejűleg elindul a dokkolótároló, és ellenőrzi, hogy fut-e. Ugyanakkor minden információ a naplózó rendszerbe kerül. És így tovább a fejlesztés minden szakaszában – kiderül, hogy rendszergazdák, fejlesztők és tesztelők igazi csapatmunkája.
Tanulmányoztam a DevOps-ot, mi lesz ezután?
Tudniillik az ember a mezőn nem harcos. Ha cége nem alkalmazza ezt a módszert, akkor a megszerzett készségek tétlenül fognak heverni. És miután megismerkedtél a DevOps-megközelítésekkel, valószínűleg nem akarsz fogaskerék lenni a vállalati fejlesztésben. Egyetlen kivétel lehet: Ön rendszergazda a csapatban, és minden folyamatot új módon építhet újra. Itt érdemes hozzátenni, hogy nagyon sok cég alkalmazza ezt a megközelítést, őket nem érinti a lezárás, és szakembereket keresnek. Mert a DevOps az online termékek létrehozásáról szól.
És most a jó dolgokról: a DevOps gyakorlatok és eszközök elsajátítása hozzávetőlegesen +30%-a a munkaerőpiaci értékének. A fizetések 140 ezer rubeltől indulnak, de természetesen az Ön fő szakterülete és funkcionalitása határozza meg.
Meg lehet nézni az „infrastruktúra-orientált” megjelöléssel ellátott állásokat, ahol van tesztautomatizálás, mikroszolgáltatási alkalmazások fejlesztése felhőtechnológiát használva, infrastruktúramérnöki állások és mindenféle DevOps hivatkozás. Ne feledje, hogy minden vállalat mást jelent ezzel a meghatározással – olvassa el figyelmesen a leírást.
Tanfolyamunk elindítása során egy meglátásom támadt – a tanfolyam után sokan beleesnek egy DevOps mérnök csapdájába. Találnak egy üresedést a fent említett címmel, kapnak egy jó ajánlatot, majd munkába állva rájönnek, hogy egy háromoldalas bash scriptet kell fenntartaniuk a Jenkinsben. Hol vannak a Kubernetes, a ChatOps, a kanári kiadások és minden? De nincs semmi, mert a cégnek nem DevOps kell mint módszertan, hanem egyedi innovációkat alkalmaz.
Ez ok arra, hogy intenzíven tájékozódjon a cégtől, hogyan működik a szoftverszállítási folyamat, a technológiai halom és milyen feladatokat fog ellátni.
Ha a munkáltató absztraktan, mintha könyvből, részletek nélkül válaszol a kérdéseire, akkor nagy valószínűséggel még nincs DevOps folyamat a cégben, de ez nem ok a visszautasításra, tanulmányozza át a céget és termékeit, van-e online szolgáltatások, amelyeket a cég saját maga fejleszt, mobil alkalmazások, termékötletek.
Ha igen, akkor tisztázza, hogy közvetlenül ezekkel a rendszerekkel kell-e dolgoznia, vagy van-e lehetőség vízszintes mozgásra ezen szolgáltatások csapatai felé, miközben jó eredményeket mutat be a DevOps gyakorlatokban. Ha igen, akkor érdemes elmenni, aktívnak és hasznosnak lenni, és ha elvégzi a tanfolyamunkat, ez utóbbi garantált.
Fontos megjegyezni, hogy a Devops gyakorlói csak fejlesztési/adminisztrációs/tesztelési tapasztalattal szerezhetnek valódi értéket. Csak akkor a tudás nem lesz elvont, hanem gazdagítja a szakembert (minden értelemben). Ezért a DevOps elsajátításának gondolata nagyjából ugyanaz, mint az objektívek „a nulláról való használatának” elsajátítása, ha még soha nem tartottál fényképezőgépet a kezedben, vagy nem irányítottál felvételt. Annak érdekében, hogy eldönthesse, megfelelő-e a tanfolyam az Ön számára, felvételi tesztet készítettünk, amely ellenőrzi az Ön megfelelő szintű tudását.
Szerintem az egyik trükk – hogy a képzés során minden hallgató maga határozza meg, hogy milyen irányba kíván fejlődni. Gyakran látunk átmeneteket, amikor egy fejlesztő infrastruktúra mérnök lesz, és az adminisztrátor rájön, hogy érdekli a kód írása - ezután továbbtanulja a nyelvet, és kiegészíti a megszerzett DevOps készségekkel. Ezért különösen azokat várjuk, akik úgy érzik, hogy karrierjük válaszút előtt áll. A tanfolyam május 28-án indul, de csatlakozni 2 héttel az órák kezdete után lehet. Megtekintheti a programot és leteheti a tesztet . Találkozunk az OTUS-ban!
Forrás: will.com