Az utóbbi néhány évben a DevOps téma nagyon népszerűvé vált. Sokan álmodoznak arról, hogy beleolvadjanak, de a tapasztalat azt mutatja, hogy gyakran csak a fizetések szintje miatt.
Néhányan a CV-jükben DevOps-t tüntetnek fel, bár nem mindig tudják és értik a kifejezés lényegét. Van, aki azt gondolja, hogy ha megtanulja az Ansible-t, GitLab-ot, Jenkins-t, Terraform-ot és hasonlókat (a lista folytatható), akkor azonnal "devops"-sá válik. Ez természetesen nem igaz.
Az utolsó néhány évben főleg DevOps bevezetésével foglalkozom különböző cégeknél. Ezelőtt több mint 20 évet dolgoztam rendszeradminisztrátorból IT igazgatóvá különböző pozíciókban. Jelenleg DevOps Lead Engineer vagyok a Playgendary-nál.
Ki az a DevOps?
Az ötlet, hogy írjak egy cikket, azután merült fel, hogy ismét megkérdezték tőlem: "ki a DevOps?". Még mindig nincs megállapodott kifejezés arra vonatkozóan, hogy mi vagy ki ez. Egyes válaszok már megtalálhatók ebben . Először kiemelem a főbb téziseket belőle, majd megosztom megfigyeléseimet és gondolataimat.
A DevOps nem egy szakember, akit fel lehet venni, nem szerszámok összessége, és nem egy fejlesztőkből és mérnökökből álló osztály.
A DevOps egy filozófia és módszertan.
Más szavakkal, ez egy gyakorlatok összessége, amely segít aktívan együttműködni a fejlesztőknek a rendszeradminisztrátorokkal. Vagyis a munkafolyamatok összekapcsolása és integrálása egymásba.
A DevOps megjelenésével a struktúra és a szakemberek szerepei változatlanok maradtak (vannak fejlesztők, vannak mérnökök), de a kölcsönhatás szabályai megváltoztak. Az osztályok közötti határok elmosódtak.
A DevOps céljait három pontban lehet leírni:
- A szoftvernek rendszeresen frissülnie kell.
- A szoftvernek gyorsan kell készülnie.
- A szoftvernek kényelmesen és rövid időn belül kell telepíthetőnek lennie.
A DevOps-nak nincs egyetlen eszköze. Beállítani, telepíteni és megtanulni néhány terméket nem jelenti azt, hogy a cégnél DevOps van. Nagyon sok eszköz létezik, és mindegyiket különböző szakaszokban használják, de egy közös célt szolgálnak.
És ez csak a DevOps eszközeinek egy része.
Már több mint 2 éve interjúztatom az embereket DevOps mérnöki pozícióra, és rájöttem, mennyire fontos pontosan érteni a kifejezés lényegét. Specifikus tapasztalat, megfigyelések és gondolatok gyűltek össze, amelyeket szeretnék megosztani.
Az interjúk tapasztalataim alapján ezt a képet látom: azoknál a szakembereknél, akik DevOps-t pozícióként kezelnek, általában félreértések merülnek fel a kollégáikkal..
Volt egy élénk példa. Egy fiatalember érkezett az interjúra, akinek a önéletrajzában rengeteg okos szó szerepelt. Az utolsó három munkahelyén 5-6 hónapos tapasztalattal rendelkezett. Két startupból távozott, mert azok "nem indultak be". A harmadik cégről pedig azt mondta, hogy ott senki sem érti őt: a fejlesztők Windows alatt írják a kódot, a vezető pedig arra kényszeríti, hogy a kódot "csomagolja" be sima Dockerbe és integrálja a CI/CD pipeline-ba. A srác rengeteg negatív véleményt mondott a jelenlegi munkahelyéről és kollégáiról — úgy éreztem, hogy válaszolni szeretnék: "Így nem fogsz eladni egy elefántot".
Aztán feltettem neki egy kérdést, ami az én listám szerint az elsők között szerepel minden jelölt esetében.
— Mit jelent számodra személyesen a DevOps?
— Általánosságban vagy ahogyan ezt én érzékelem?
Az ő személyes véleményére voltam kíváncsi. Tudta a teorikus hátteret és a kifejezés eredetét, de határozottan nem értett egyet vele. Úgy vélte, hogy a DevOps — egy pozíció. Itt rejlik a problémái gyökere, akárcsak más szakemberek esetében, akik hasonló véleményen vannak.
A munkáltatók, akik hallottak a „DevOps varázslatáról”, olyan embert keresnek, aki eljön és megteremti ezt a „varázslatot”. Azok a pályázók, akik abban a hitben vannak, hogy a DevOps egy pozíció, nem értik, hogy ezzel a megközelítéssel nem tudják majd teljesíteni az elvárásokat. Ráadásul az önéletrajzukban a DevOps szerepel, mert ez divatos, és ezért sokat fizetnek.
A DevOps metodológia és filozófia
A metodológia lehet elméleti és gyakorlati. A mi esetünkben — az utóbbi. Ahogy fentebb említettem, a DevOps egy praktika- és stratégiakészlet, amelyet a kitűzött célok elérésére alkalmaznak. És minden esetben, a vállalat üzleti folyamataitól függően, jelentősen eltérhet. Ami nem teszi jobbná vagy rosszabbá.
A DevOps metodológia csupán egy eszköz a kitűzött célok eléréséhez.
Most pedig beszéljünk arról, hogy mi is a DevOps filozófia. És valószínűleg ez a legnehezebb kérdés.
Rövid és tömör válasz megfogalmazása meglehetősen nehéz, mert ez még nem lett formálisan lefektetve. És mivel a DevOps filozófiájának hívei inkább a gyakorlattal foglalkoznak — nincs idő a filozofálásra. Mindazonáltal ez egy nagyon fontos folyamat. Ráadásul közvetlenül kapcsolódik a mérnöki tevékenységhez. Van is egy specializált tudományterület — .
Az én egyetemen nem volt ilyen tantárgy, mindent magam kellett tanulmányoznom az 90-es években talált anyagok alapján. A téma nem kötelező az mérnöki oktatásban, innen ered a válasz formalizálásának hiánya. De azok az emberek, akik komolyan belemerültek a DevOps-ba, kezdenek érzékelni egyfajta 'szellemet' vagy 'tudattalan mindenséget' a vállalat folyamatainak összességében.
Saját tapasztalataim alapján megpróbáltam formalizálni néhány 'posztulát' erről a filozófiáról. Az eredmény a következő:
- A DevOps nem egy önálló dolog, amit külön tudományágként vagy tevékenységként lehetne kiemelni.
- A DevOps módszertanát a vállalat minden dolgozójának követnie kell, tervezve tevékenységüket.
- A DevOps minden folyamatot érint a vállalaton belül.
- A DevOps azért létezik, hogy csökkentse az időráfordítást a vállalaton belüli bármilyen folyamatban, biztosítva ezzel a szolgáltatások fejlődését és a kliens maximális kényelmét.
- A DevOps, modern nyelven, minden munkavállaló proaktív hozzáállását jelenti, amely a időbeli költségek csökkentésére és a minket körülvevő IT-termékek minőségének javítására irányul.
Úgy gondolom, hogy az én 'posztulátjaim' egy külön témát jelentenek a vitára. De most van, amiből kiindulhatunk.
Mit csinál a DevOps?
A kulcsfontosságú szó itt a kommunikációk. Nagyon sok kommunikáció van, amelyek kezdeményezője éppen a DevOps mérnöknek kell legyen. Miért? Mert ez egy filozófia és módszertan, és csak utána következnek a mérnöki ismeretek.
A nyugati munkaerőpiacról 100%-os bizonyossággal nem tudok beszélni. De a DevOps piacáról Oroszországban elég sokat tudok. Az elmúlt másfél évben több száz állásinterjún vettem részt, emellett részt vettem körülbelül száz technikai presale-en a 'DevOps bevezetés' szolgáltatás terén nagy orosz cégek és bankok számára.
Oroszországban a DevOps még mindig nagyon fiatal, de már trendi téma. Tudomásom szerint csak Moszkvában 2019-ben több mint 1000 ilyen szakember hiányzott. A Kubernetes szó pedig a munkáltatók számára szinte olyan, mint a vörös posztó a bikának. Ezen eszköz hívei hajlandóak használni azt még ott is, ahol az nem szükséges és gazdaságilag nem kifizetődő. A munkáltató nem mindig érti, hogy mikor mit érdemes használni, és a Kubernetes klaszter megfelelő telepítése 2-3-szor többe kerül, mint a hagyományos klaszteres alkalmazás telepítése. Használja ott, ahol valóban szükséges.
A DevOps bevezetése szempontjából anyagilag — drága. Csak ott indokolt, ahol gazdasági előnyöket hoz más területeken, nem önmagában.
A DevOps mérnökök valójában úttörők — ők azok, akiknek először kell bevezetniük a cégnél ezt a módszertant és kiépíteniük a folyamatokat. Ehhez a siker érdekében a szakember folyamatosan interakcióban kell álljon a munkatársakkal és kollégákkal minden szinten. Ahogy általában mondom, a DevOps bevezetésébe a cég minden alkalmazottának be kell vonódnia: a takarítónőtől a vezérigazgatóig. Ez kötelező feltétel. Ha a csapat legfiatalabb tagja nem tudja és nem érti, mi az a DevOps és miért hajtanak végre bizonyos szervezeti intézkedéseket, akkor a sikeres bevezetés nem fog megvalósulni.
A DevOps mérnöknek időnként adminisztratív eszközöket is használnia kell. Például a 'környezet ellenállásának' legyőzésére — amikor a csapat nem készült fel a DevOps eszközök és módszertan elfogadására.
A fejlesztőnek csak kódot és teszteket kell írnia. Ehhez nem szükséges neki egy szuper erőteljes laptop, amin a projekt teljes infrastruktúráját helyben telepíti és fenntartja. Például a frontend fejlesztő a laptopján tartja az alkalmazás összes elemét, beleértve az adatbázist, az S3 emulátort (minio) és egyebeket. Tehát sok időt pazarol a helyi infrastruktúra fenntartására, és egyedül küzd az ilyen megoldás összes problémájával. Ahelyett, hogy a frontend kódját fejlesztené. Az ilyen emberek erősen ellenállhatnak bármilyen változásnak.
Vannak azonban olyan csapatok, akik éppen ellenkezőleg, örömmel fogadják az új eszközök és módszerek bevezetését, és aktívan részt vesznek ebben a folyamatban. Még ilyen esetben is senki sem törli el a DevOps mérnök és a csapat közötti kommunikációt.
Mikor nincs szükség DevOps-ra
Vannak olyan helyzetek, amikor nincs szükség DevOps-ra. Ez tény — ezt meg kell érteni és el kell fogadni.
Elsősorban ez minden olyan cégre vonatkozik (különösen a kisvállalkozásokra), ahol a nyereségük nem függ közvetlenül az IT-termékek meglététől vagy hiányától, amelyek információs szolgáltatásokat nyújtanak az ügyfeleknek. Itt nem a vállalat weboldaláról van szó, legyen az statikus "névjegykártya" vagy dinamikus hírszekciókkal ellátott, stb.
DevOps-ra van szükség, amikor az információs szolgáltatások megléte, minősége és célzottsága kulcsfontosságú a vásárló elégedettségének és annak megőrzésének szempontjából, hogy visszatérjen hozzánk.
Kiemelkedő példa egy ismert bank. A cégnél nincsenek hagyományos ügyfélirodák, az ügyintézés levélben vagy futárral történik, sok alkalmazott pedig otthonról dolgozik. A cég már nem csupán bank, hanem véleményem szerint IT-céggé alakult ki fejlett DevOps technológiákkal.
Sok más példa és előadás található a témához kapcsolódó meet-upok és konferenciák felvételeiben. Néhányat személyesen is látogattam — ez nagyon hasznos tapasztalat azok számára, akik ezen a területen szeretnének fejlődni. Íme néhány link jól sikerült DevOps előadásokkal és anyagokkal rendelkező YouTube csatornákra:
Most nézze meg a vállalkozását, és gondolkodjon el ezen: mennyire függ a cége és nyeresége az IT-termékektől, amelyek az ügyfélkapcsolatokat biztosítják?
Ha a cége halat árul egy kis boltban, és az egyetlen IT-termék két konfiguráció az 1C: Vállalat (Könyvelés és UNF), valószínűleg nincs értelme DevOps-ról beszélni.
Ha azonban egy nagykereskedelmi és gyártó cégnél dolgozik (például vadászfegyvereket gyárt), érdemes elgondolkodnia. Ön kezdeményezheti a DevOps bevezetésének kilátásait a vezetése felé. No, és mellette vezetheti ezt a folyamatot is. A proaktív hozzáállás — a DevOps filozófiájának egyik fontos alapelve.
A pénzügyi forgalom nagysága és volumene nem alapvető szempont annak megítélésében, hogy szüksége van-e a cégnek DevOps-ra.
Képzeljünk el egy nagy ipari vállalkozást, amely nem lép közvetlen kapcsolatba az ügyfelekkel. Például néhány autógyártó cég és autóipari vállalat. Jelenleg nem vagyok benne biztos, de múltbeli tapasztalataim alapján éveken keresztül minden ügyfélkapcsolat elektronikus leveleken és telefonon keresztül zajlott.
Az ügyfeleik egy korlátozott lista autós kereskedők. Minden egyes kereskedőhöz hozzárendelt egy szakember a gyártótól. Az összes belső dokumentáció ERP SAP rendszeren keresztül zajlik. A belső munkatársak lényegében az információs rendszer ügyfelei. De e rendszer menedzselése klasszikus klaszterirányítási eszközökkel történik, ami kizárja a DevOps gyakorlatok használatát.
Így a következtetés: az ilyen típusú vállalatok számára a DevOps bevezetése nem kritikus fontosságú, ha visszaemlékezünk a módszertan céljaira a cikk elején. De nem zárkózom el attól, hogy lehet, hogy ma már használnak néhány DevOps eszközt.
Másrészről, sok kis vállalat létezik, amelyek szoftverfejlesztéssel foglalkoznak a DevOps módszertana, filozófiája, gyakorlatai és eszközei felhasználásával. És úgy vélik, hogy a DevOps bevezetésére fordított költségek olyan kiadások, amelyek lehetővé teszik számukra a hatékony versenyt a szoftverpiacon. Az ilyen vállalatok példáit láthatjuk. .
A fő szempont, hogy megértsük, szükség van-e DevOps-ra: milyen jelentőséggel bírnak az IT termékeid a cég és az ügyfelek számára.
Ha a cég fő jövedelmező terméke a szoftver — akkor szükséged van DevOps-ra. És nem olyan fontos, ha más termékekkel valós jövedelmet szerzel. Ide sorolhatóak az online boltok vagy a játékokat kínáló mobilalkalmazások is.
Bármely játék a játékosoktól kapott közvetlen vagy közvetett finanszírozás révén létezik. A Playgendary-nél ingyenes mobil játékokat fejlesztünk, amelyek közvetlen létrehozásában több mint 200 ember vesz részt. Hogyan használjuk a DevOps-ot?
Ugyanúgy, ahogy fentebb leírtam. Folyamatosan kommunikálok a fejlesztőkkel és tesztelőkkel, illetve belső képzéseket tartok az alkalmazottak számára a DevOps módszertanról és eszközeiről.
Jelenleg aktívan használjuk a Jenkins-t mint CI/CD pipeline eszközt, amelyet az összes Unity build folyamat végrehajtására és a kiadására az App Store-ba és a Play Marketbe. A klasszikus eszközkészletből még:
- Asana – a projektek kezelésére. Integráció van beállítva a Jenkins-szel.
- Google Meet – videókonferenciák lebonyolítására.
- Slack – kommunikációra és különböző értesítésekre, beleértve a Jenkins-ből érkező értesítéseket is.
- Atlassian Confluence – dokumentálásra és csoportos munkára.
A közeljövő tervek között szerepel a statikus kód-elemzés megvalósítása a SonarQube segítségével, valamint automatizált UI-tesztelés végrehajtása Selenium eszközökkel a Continuous Integration fázisban.
Összegzésként
Szeretném befejezni a következő gondolattal: ahhoz, hogy magasan képzett DevOps mérnök legyen, létfontosságú, hogy megtanuljon élőben kommunikálni az emberekkel.
A DevOps mérnök csapatjátékos. És kész. A kezdeményezés a kollégákkal való kommunikációban önállóan kell, hogy induljon, nem valamilyen körülmény hatására. A DevOps szakembernek észre kell vennie és javasolnia a legjobb megoldást a csapat számára.
Igen, bármely megoldás bevezetése rengeteg megbeszélést igényel, és a végén akár meg is változhat. Ha önállóan fejlődik, ötleteket kínál és valósít meg – ez a személy egyre nagyobb értéket képvisel a csapat és a munkáltató számára. Ami végső soron tükröződik havi jutalmának nagyságában vagy további prémiumok formájában.
Forrás: habr.com
