Mi kell ahhoz, hogy egy IT-cég sikeres legyen 2019-ben? A konferenciákon és összejöveteleken az előadók sok hangos szót mondanak, amelyek nem mindig érthetők a normális emberek számára. Küzdelem a telepítési időért, a mikroszolgáltatásokért, a monolit elhagyásáért, a DevOps átalakításért és még sok minden másért. Ha elvetjük a verbális szépséget, és közvetlenül és oroszul beszélünk, akkor minden egy egyszerű tézisből áll: készíts egy jó minőségű terméket, és tedd ezt kényelemmel a csapatnak.
Ez utóbbi kritikus fontosságúvá vált. A vállalkozások végre arra a következtetésre jutottak, hogy a kényelmes fejlesztési folyamat növeli a termelékenységet, és ha minden hibakeresésre kerül, és úgy működik, mint egy óra, az a kritikus helyzetekben is ad némi mozgásteret. Valamikor ennek a manővernek a kedvéért egy bizonyos okos ember biztonsági mentésekkel állt elő, de az ipar fejlődik, és elérkeztünk a DevOps mérnökeihez - olyan emberekhez, akik a fejlesztés és a külső infrastruktúra interakcióját megfelelővé alakítják. nem kapcsolódik a sámánizmushoz.
Ez az egész „moduláris” sztori csodálatos, de... Történt, hogy néhány adminisztrátort hirtelen DevOps-nak neveztek el, és maguktól a DevOps mérnököktől is megkövetelték, hogy rendelkezzenek legalább a telepátia és a tisztánlátás képességeivel.
Mielőtt az infrastruktúra biztosításának modern problémáiról beszélnénk, határozzuk meg, mit értünk ezen a kifejezésen. Jelen pillanatban úgy alakult a helyzet, hogy elérkeztünk ennek a fogalomnak a kettősségéhez: az infrastruktúra lehet feltételesen külső és feltételesen belső.
Külső infrastruktúra alatt mindent értünk, ami biztosítja a csapat által fejlesztett szolgáltatás vagy termék működőképességét. Ezek alkalmazás- vagy webhelyszerverek, tárhely és egyéb szolgáltatások, amelyek biztosítják a termék működőképességét.
A belső infrastruktúra magában foglalja a szolgáltatásokat és berendezéseket, amelyeket maga a fejlesztőcsapat és más alkalmazottak használnak, akikből általában sok van. Ezek a kódtároló rendszerek belső szerverei, egy helyileg telepített feladatkezelő és minden, minden, minden, ami a vállalati intraneten belül létezik.
Mit csinál egy rendszergazda egy cégnél? A vállalati intranet adminisztrációs munkája mellett gyakran a gazdasági gondok terhe is az irodai berendezések működőképességének biztosítása. Az adminisztrátor ugyanaz a fickó, aki gyorsan kirángat egy új rendszeregységet vagy egy használatra kész tartalék laptopot a háztartási helyiségből, kiad egy friss billentyűzetet, és négykézláb mászkál az irodákon, az Ethernet kábelt feszítve. Az adminisztrátor nem csak a belső és külső szerverek helyi tulajdonosa és irányítója, hanem egy vállalatvezető is. Igen, egyes adminisztrátorok csak a rendszersíkon dolgozhatnak, hardver nélkül. Ezeket az „infrastruktúra-rendszergazdák” külön alosztályába kell különíteni. Néhányan pedig kizárólag irodai berendezések szervizelésére specializálódtak, szerencsére, ha a cégnek több mint száz fője van, a munka soha nem ér véget. De egyikük sem devop.
Kik azok a DevOps-ok? A Devops olyan srácok, akik a szoftverfejlesztés és a külső infrastruktúra kölcsönhatásáról beszélnek. Pontosabban, a modern devopok sokkal mélyebben vesznek részt a fejlesztési és telepítési folyamatokban, mint azok a rendszergazdák, akik egyszerűen csak feltöltötték az ftp-re frissítéseket. A DevOps mérnökök egyik legfontosabb feladata most az, hogy kényelmes és hatékonyan strukturált interakciót biztosítson a fejlesztőcsapatok és a termékinfrastruktúra között. Ezek az emberek felelősek a visszaállítási és üzembe helyezési rendszerek üzembe helyezéséért, ők azok, akik leveszik a fejlesztők terheit, és amennyire csak lehetséges, a rendkívül fontos feladatukra koncentrálnak. Ugyanakkor a devopok soha nem fognak új kábelt vezetni vagy új laptopot adni a hátsó helyiségből (c) KO
Mi a fogás?
Arra a kérdésre, hogy „Ki az a DevOps?” a területen dolgozók fele valami olyasmit kezd válaszolni, hogy „Nos, röviden, ez az admin, aki…” és még tovább a szövegben. Igen, réges-régen, amikor a DevOps mérnöki szakma még csak a legtehetségesebb adminisztrátorok közül került ki a szervizkarbantartás terén, nem mindenki számára voltak nyilvánvalóak a köztük lévő különbségek. De most, amikor a devop és az admin funkciója gyökeresen eltér a csapatban, elfogadhatatlan, hogy összekeverjük őket, sőt egyenlőségjelet is tegyünk.
De mit jelent ez az üzleti életben?
Bérbeadás, minden erről szól.
Ön „Rendszeradminisztrátor” állást nyit meg, és az ott felsorolt követelmények a következők: „interakció a fejlesztéssel és az ügyfelekkel”, „CI/CD kézbesítő rendszer”, „a cég szervereinek és berendezéseinek karbantartása”, „belső rendszerek adminisztrációja” stb. tovább; érted, hogy a munkáltató hülyeségeket beszél. A bökkenő az, hogy a „Rendszeradminisztrátor” helyett az üresedés címe „DevOps Engineer” legyen, és ha ez a cím megváltozik, akkor minden a helyére kerül.
De milyen benyomást kelt az ember, ha egy ilyen üresedést olvas? Hogy a cég olyan többgépes kezelőt keres, aki verzióellenőrző és felügyeleti rendszert is bevet, és foggal-körömmel szorítja a twistert...
De ahhoz, hogy ne nőjön a kábítószer-függőség mértéke a munkaerőpiacon, elég, ha az üresedéseket a megfelelő nevén nevezzük, és világosan megértjük, hogy a DevOps mérnök és a rendszergazda két különböző entitás. De egyes munkaadók elfojthatatlan vágya, hogy a lehető legszélesebb követelménylistát mutassák be egy jelöltnek, ahhoz a tényhez vezet, hogy a „klasszikus” rendszergazdák már nem értik, mi történik körülöttük. Mi van, a szakma mutálódik, és le vannak maradva a korral?
Nem nem és még egyszer nem. Az infrastruktúra-adminisztrátorok, akik a vállalat belső szervereit kezelik, vagy L2/L3 támogatói pozíciókat töltenek be és segítik a többi alkalmazottat, nem mentek el és nem is fognak elmenni.
Lehetnek ezek a szakemberek DevOps mérnökök? Természetesen megtehetik. Valójában ez egy kapcsolódó környezet, amely rendszeradminisztrációs készségeket igényel, de ezen felül a monitorozási, kézbesítési rendszerekkel végzett munka és általában a fejlesztői és tesztelői csapattal való szoros együttműködés is hozzáadódik.
Újabb DevOps probléma
Valójában minden nem korlátozódik csupán a felvételre és az adminisztrátorok és a devopok közötti folyamatos összetévesztésre. Egy bizonyos ponton a vállalkozás szembesült azzal a problémával, hogy frissítéseket szállítson, és a fejlesztőcsapat kölcsönhatásba lépjen a végső infrastruktúrával.
Talán akkor történt, amikor egy csillogó szemű bácsi felállt egy konferencia színpadán, és azt mondta: „Mi ezt csináljuk, és DevOps-nak hívjuk. Ezek a srácok minden problémádat megoldják” – és mesélni kezdett, milyen jó az élet a cégben a DevOps gyakorlatok bevezetése után.
Nem elég azonban felvenni egy DevOps mérnököt, hogy minden úgy működjön, ahogy kell. A vállalatnak teljes DevOps átalakuláson kell átesnie, vagyis a termékfejlesztő és tesztelő csapat részéről is világosan meg kell érteni a DevOps szerepét és képességeit. Van egy „csodálatos” történetünk ebben a témában, amely teljes mértékben szemlélteti mindazt a brutalitást, ami néhol történik.
Helyzet. A DevOps-nak szüksége van egy verzió-visszaállítási rendszer üzembe helyezésére anélkül, hogy alaposan belemerülne annak működésébe. Tegyük fel, hogy a Users rendszeren belül külön mezők vannak a keresztnév, vezetéknév és jelszó számára. Megjelenik a termék új verziója, de a fejlesztők számára a „visszaállítás” csak egy varázspálca, ami mindent megold, és azt sem tudják, hogyan működik. Így például a következő patch-ben a fejlesztők egyesítették az utó- és vezetéknévmezőket, bevezették a termelésbe, de a verzió valamiért lassú. Mi történik? A vezetőség odajön a devopshoz, és azt mondja: „Húzza meg a kapcsolót!”, vagyis arra kéri, hogy térjen vissza az előző verzióra. Mit csinál a devops? Visszagörget az előző verzióra, de mivel a fejlesztők nem akartak rájönni, hogy ez a visszaállítás hogyan történt, senki nem szólt a devops csapatának, hogy az adatbázist is vissza kell görgetni. Emiatt nálunk minden összeomlik, és a lassú weboldal helyett „500-as” hibát látnak a felhasználók, ugyanis a régi verzió nem működik az új adatbázis mezőivel. Devops nem tud erről. A fejlesztők hallgatnak. A vezetőség kezdi elveszíteni az idegeit és a pénzét, és emlékszik a biztonsági másolatokra, felajánlva, hogy visszalép tőlük, hogy „legalább működjön valami”. Ennek eredményeként a felhasználók egy idő után elveszítik minden adatukat.
A dió természetesen a devops-ra megy, ami „nem csinált megfelelő rollback rendszert”, és senkit sem érdekel, hogy ebben a történetben a jávorszarvas fejlesztők.
A következtetés egyszerű: a DevOps szokásos megközelítése nélkül nem sok haszna van.
A legfontosabb dolog, amit emlékezni kell: a DevOps mérnök nem bűvész, és minőségi kommunikáció és a fejlesztéssel való kétirányú interakció nélkül nem fog megbirkózni a feladataival. A fejlesztőket nem lehet egyedül hagyni a „problémáikkal”, vagy nem lehet kiadni a parancsot, hogy „ne avatkozz bele a fejlesztőkbe, az ő dolguk a kódolás”, majd reménykedni abban, hogy egy kritikus pillanatban minden úgy fog működni, ahogy kell. Ez nem így működik.
A DevOps lényegében a menedzsment és a technológia határán fekvő kompetencia. Ráadásul korántsem nyilvánvaló, hogy ebben a koktélban több technológia kellene, mint menedzsment. Ha valóban gyorsabb és hatékonyabb fejlesztési folyamatokat szeretne felépíteni, akkor bíznia kell a devops csapatában. Ismeri a megfelelő eszközöket, valósított meg hasonló projekteket, tudja, hogyan kell csinálni. Segíts neki, hallgass a tanácsaira, ne próbáld valamiféle autonóm egységbe elszigetelni. Ha az adminisztrátorok tudnak önállóan dolgozni, akkor a devopok ebben az esetben haszontalanok, nem tudnak segíteni abban, hogy jobbá válj, ha te magad nem akarod elfogadni ezt a segítséget.
És egy utolsó dolog: ne sértsd meg az infrastruktúra-adminisztrátorokat. Megvan a maguk, rendkívül fontos munkafrontjuk. Igen, egy rendszergazda válhat DevOps mérnökké, de ennek az adott személy kérésére kell megtörténnie, nem nyomás alatt. Azzal pedig nincs semmi baj, hogy egy rendszergazda rendszergazda akar maradni – ez az ő külön szakmája és joga. Ha szakmai átalakuláson szeretne átesni, soha nem szabad elfelejtenie, hogy nemcsak technológiai, hanem vezetési képességeit is fel kell építenie. Valószínűleg Ön, mint vezető feladata, hogy összehozza ezeket az embereket, és megtanítsa őket arra, hogy ugyanazon a nyelven kommunikáljanak.
Forrás: will.com