Mi szükséges az IT-cég sikeréhez 2019-ben? Az előadók a konferenciákon és meet-upokon sok hangzatos és nem mindig érthető szót mondanak a normális emberek számára. A telepítési időért folytatott harc, a mikroszolgáltatások, a monolit elhagyása, a DevOps átalakulás és még sok minden más. Ha elhagyjuk a szószéki szépséget és közvetlenül fogalmazunk, akkor minden egyszerű tételre redukálódik: készítsetek minőségi terméket, és ami a legfontosabb, kényelmesen a csapat számára.
Ez utóbbi kritikus fontosságúvá vált. Az üzlet végre rájött, hogy a kényelmes fejlesztési folyamat növeli a termelékenységet, és ha minden be van állítva és úgy működik, mint a karóra, akkor még egy kis mozgásteret is ad a kritikus helyzetekben. Valaha a mozgástér érdekében egy okos ember kitalálta a biztonsági mentéseket, de az ipar fejlődik, és eljutottunk a DevOps mérnökökhöz – olyan emberekhez, akik a fejlesztés és a külső infrastruktúra kölcsönhatásának folyamatát valami elfogadható és a sámánizmustól mentes dologgá alakítják.
Ez az egész 'moduláris' történet szép, de... Így alakult, hogy a néhány adminisztrátort hirtelen DevOps-nak nevezték, és a DevOps mérnököktől legalább telepatikus és jövendőmondó képességeket vártak el.
Mielőtt a modern infrastruktúra biztosítási problémáiról beszélnénk, határozzuk meg, mit értünk ezen a kifejezésen. Jelenleg a helyzet úgy alakult, hogy eljutottunk ennek a fogalomnak a kettősségéhez: az infrastruktúra lényegében lehet külső és belső.
A külső infrastruktúra alatt mindazt értjük, ami biztosítja a szolgáltatás vagy termék működését, amelyet a csapat fejleszt. Ide tartoznak az alkalmazás vagy weboldal szerverei, hosztolást és egyéb szolgáltatások, amelyek biztosítják a termék működését.
A belső infrastruktúra magában foglalja azokat a szolgáltatásokat és berendezéseket, amelyeket maga a fejlesztőcsapat és más dolgozók használnak, akiket általában szintén nem kevesen van. Ide tartoznak a kód tárolására szolgáló belső szerverek, a helyben telepített feladatkezelő és minden, ami a vállalati intraneten belül létezik.
Mit mivel foglalkozik a rendszergazda a cégnél? A vállalati intranet üzemeltetése mellett gyakran őt terheli az irodai berendezések működőképességének fenntartása is. Az admin az a fickó, aki gyorsan hoz egy új rendszert vagy egy működő tartalék laptopot a raktárból, átad egy új billentyűzetet, és négykézláb mászik az irodákban, miközben Ethernet-kábelt húz. Az admin a helyi úr, aki uralja nemcsak a belső, hanem a külső. szerverek, de ő még a gazdasági feladatokért is felelős. Igen, egyes adminisztrátorok csak rendszerszinten dolgozhatnak, anélkül, hogy hardverrel foglalkoznának. Azokat külön kategóriába sorolhatjuk, mint "infrastruktúra rendszergazdák". Vannak, akik kizárólag irodai berendezések karbantartására specializálódtak, és ha a cég több mint száz főt foglalkoztat, a munka soha nem ér véget. De sem ők, sem a másik csoport nem devops-ok.
De kik is azok a DevOps-ok? A devops-ok olyan srácok, akik a szoftverfejlesztés és a külső infrastruktúra közötti interakcióval foglalkoznak. Pontosabban, a modern devops-ok sokkal mélyebben bevonnak a fejlesztési és telepítési folyamatokba, mint valaha a rendszergazdák, akik egyszerűen csak frissítéseket töltöttek fel ftp-n. Az egyik kulcsfeladat a DevOps mérnökök számára az, hogy biztosítsák a fejlesztőcsapatok és a termék infrastruktúra közötti interakció kényelmes és hatékony folyamatát. Ezek az emberek felelősek a visszagörgető és telepítési rendszerek kiépítéséért, ők veszik le a terhet a fejlesztőkről, és maximálisan a rendkívül fontos feladatukra koncentrálnak. Eközben a devops sosem fog új kábelt húzni vagy új laptopot átadni a raktárból (c) K.O.
Mi a buktató?
A kérdésre, hogy „Ki az a DevOps?”, a szakma felének válasza valami ilyesmi: „Nos, ő egy admin, aki…”, és folytatja a mondandóját. Igen, réges-régen, amikor a DevOps mérnöki szakma éppen csak kifejlődött a legtehetségesebb szolgáltatáshoz értő adminisztrátorok közül, a köztük lévő különbségek nem voltak mindenki számára nyilvánvalóak. De ma, amikor a devops és az adminisztrátor szerepei a csapatban radikálisan eltérnek, együtt emlegetni őket, sőt, egyenlőségjelet tenni közéjük – elfogadhatatlan.
De mi sül ki ebből az üzlet számára?
A toborzásról van itt szó.
Megnyitsz egy „Rendszergazda” álláshirdetést, ahol a következő követelmények szerepelnek: „együttműködés a fejlesztőkkel és az ügyfelekkel”, „CI/CD rendszer kiépítése”, „a vállalat szervereinek és berendezéseinek karbantartása”, „belső rendszerek adminisztrálása”, és így tovább; megérted, hogy a munkaadó valami őrültséget mond. A csavar az, hogy a „Rendszergazda” helyett az álláshirdetés címében „DevOps mérnök” kellene, hogy szerepeljen, és ha ezt a címet megváltoztatnád, minden a helyére kerülne.
De milyen hatást kelt egy ilyen álláshirdetés olvasása során? Hogy a cég keres egy igáslovat, aki a verziókezelő rendszert és a monitorozást is alkalmazni tudja, és a vitrinről is megeszi a sorokat…
Pedig ahhoz, hogy ne emeljük a munkaerőpiaci zűrzavart, elegendő lenne, ha a hirdetéseket a nevükön neveznénk, és pontosan megértenénk, hogy a DevOps mérnök és a rendszergazda – ez két külön entitás. Csak éppen néhány munkáltató akaratereje, hogy a jelölttel szemben minél szélesebb követelménylistát támasztson, oda vezet, hogy a "klasszikus" rendszergazdák már nem értik, mi történik körülöttük. Miért, a szakma mutálódik, és ők lemaradtak?
Nem, nem és még egyszer nem. Az infrastruktúra-adminisztrátorok, akik a vállalat belső szervereit irányítják, vagy L2/L3-as támogatási pozíciókat töltenek be, és segítenek a többi munkatársnak, nem tűntek el, és nem is szándékoznak eltűnni.
Lehetnek ezek a szakemberek DevOps mérnökök? Természetesen lehetnek. A valóságban ez egy rokon terület, amely rendszerszintű adminisztrációs készségeket igényel, de emellett hozzáadódik a monitorozás, a szállítási rendszerek kezelése, és általában a fejlesztési és tesztelő csapattal való szoros együttműködés.
Egy másik DevOps probléma
Valójában a probléma nem csupán a rendszergazdák és DevOps szakemberek közötti állandó zűrzavarral és munkaerő-felvétellel zárul le. Egy idő után a vállalkozások szembesültek azzal a problémával, hogy nehezen tudják szállítani a frissítéseket és a fejlesztő csapat nem tud megfelelően együttműködni a végső infrastruktúrával.
Lehet, hogy ez akkor történt, amikor egy konferencia színpadán valaki felállt, fénylő szemekkel, és azt mondta: „Mi így csináljuk, és ezt DevOps-nak hívjuk. Ezek a srácok minden problémádat megoldják” — majd elkezdett mesélni arról, hogyan élvezik a cégnél a DevOps gyakorlatok bevezetését.
De nem elég DevOps mérnököt felvenni ahhoz, hogy minden „úgy működjön, ahogyan kellene”. A cégnek teljes egészében végig kell mennie a DevOps átalakuláson, azaz a DevOps szerepét és lehetőségeit a termék fejlesztési és tesztelő csapata számára is világosan meg kell érteniük. Ezzel kapcsolatban van egy „gyönyörű” történetünk, amely teljes egészében illusztrálja a helyenként bekövetkező káoszt.
Helyzet. A devops csapatot megkérik, hogy állítsa vissza a verziókat anélkül, hogy tisztában lennének azzal, hogyan fog ez működni. Tegyük fel, hogy a rendszerben a Felhasználók — külön mezők név, vezetéknév és jelszó számára. Megjelenik egy új termékváltozat, de a fejlesztők számára a „visszaállítás” csak egy varázspálca, ami mindent megjavít, és még csak nem is tudják, hogyan működik. Nos, például a fejlesztők az új patban összekapcsolták a név és vezetéknév mezőket, kiadták ezt a termékbe, és a verzió valamilyen okból lelassul. Mi történik? A vezetőség odamegy a devops-hoz, és azt mondja: „Kapcsold ki!”, vagyis azt kérik, hogy állítson vissza a korábbi verzióra. Mit tesz a devops? Visszaáll a korábbi verzióra, de mivel a fejlesztők nem akarták megérteni, hogyan történik ez a visszaállítás, senki sem mondta el neki, hogy a bázist is vissza kell állítani. Végül pedig minden leáll, és a felhasználók a lassuló webhely helyett egy „500” hibát látnak, mert a régi verzió nem működik az új bázis mezőivel. A devops erről nem tud. A fejlesztők hallgatnak. A vezetőség kezd ideges lenni és pénzt veszíteni, és eszükbe jutnak a biztonsági mentések, javasolva, hogy onnan álljanak vissza, hogy „legalább valami működjön”. Ennek eredményeképpen a felhasználók elveszítik az adataikat egy bizonyos időintervallumban.
Természetesen a devops kapja a kritikát, aki „nem készítette el a megfelelő visszaállítási rendszert”, míg az, hogy a fejlesztők a hibások ebben a történetben, senkit sem érdekel.
A következtetés egyszerű: normális megközelítés nélkül a DevOps-hoz nem sok haszna van.
A legfontosabb, amit szem előtt kell tartani: a DevOps mérnök nem varázsló, és minőségi kommunikáció és kétoldalú kapcsolattartás nélkül a fejlesztéssel nem tudja elvégezni a feladatait. A devops-okat nem lehet magukra hagyni a „problémáikkal”, vagy utasítást adni, hogy „ne nyúlj a fejlesztőkhöz, az ő dolguk a kódolás”, majd remélni, hogy kritikus pillanatban minden úgy működik, ahogy kell. Így nem működik.
A lényegében a DevOps a menedzsment és a technológia határvonalán lévő készségeket takar. Ráadásul nem nyilvánvaló, hogy a technológiai koktélban többnek kell lennie, mint menedzsmentnek. Ha valóban szeretne gyorsabb és hatékonyabb fejlesztési folyamatokat létrehozni, meg kell bízni a DevOps szakemberében. Ő tudja, milyen eszközökre van szükség, hasonló projekteket valósított meg, és tudja, hogyan kell csinálni. Segítsen neki, hallgasson az ő tanácsaira, ne próbálja meg elszigetelni egy autonóm egységbe. Míg az adminisztrátorok önállóan dolgozhatnak, addig a DevOps szakemberek haszontalanok lesznek abban az esetben, ha ön nem akarja elfogadni a segítségüket.
És végül: elég az infrastruktúra-adminisztrátorok bántalmazásából. Őknek saját, rendkívül fontos munkájuk van. Igen, az adminisztrátor DevOps mérnökké válhat, de ennek önszántából kell megtörténnie, nem kényszerből. Nincs semmi rossz abban, ha a rendszergazda szeretne rendszergazda maradni — ez az ő külön szakmája és joga. Ha viszont van késztetése a szakmai átalakulásra, nem szabad elfelejteni, hogy nemcsak technológiai készségeket, hanem menedzsmentet is fejleszteni kell. Valószínűleg pontosan Önnek, mint vezetőnek, kell összehoznia ezeket az embereket, és meg kell tanítania őket, hogyan kommunikáljanak egy nyelven.
Forrás: habr.com
