Çfarë duhet për suksesin e një kompanie IT në vitin 2019? Lecterët në konferenca dhe takime flasin shumë fjalë të zhurmshme dhe jo gjithmonë të kuptueshme për njerëzit e zakonshëm. Lufta për kohën e deploy-it, mikroshërbimet, heqja e monolitit, transformimi DevOps dhe shumë e shumë gjëra të tjera. Nëse e heqim nga goja bukurinë fjalore dhe flasim direkt dhe në shqip, gjithçka përmbledh në një tezë të thjeshtë: krijoni një produkt të cilësisë së lartë, dhe atë me komoditet për ekipin.
Kjo e fundit është bërë kritikisht e rëndësishme. Biznesi përfundimisht ka arritur në mendimin se procesi i komoditetit të zhvillimit rrit produktivitetin dhe nëse gjithçka është e rregullt dhe funksionon si orë, atëherë përsëri ofron një hapësirë të caktuar për manovrim në situata kritike. Një herë, për këtë manovrim, një person i zgjuar shpikoi backup-et, por industria po evoluon, dhe ne arritëm tek inxhinierët DevOps - njerëz që e shndërrojnë procesin e bashkëpunimit mes zhvillimit dhe infrastrukturës për të kaluar në diçka të arsyeshme dhe që nuk lidhet me magjinë.
E gjithë kjo histori e 'për modulin' është e bukur, por... ndodhi që disa administrues u shpallën menjëherë si DevOps, ndërsa nga vetë inxhinierët DevOps kërkoheshin, të paktën, aftësi telepatike dhe parashikuese.
Para se të flasim për problemet moderne të sigurimit të infrastrukturës, le të përcaktojmë se çfarë nënkuptojmë me këtë termin. Deri në këtë moment, situata është zhvilluar në mënyrë që ne dolëm në dyfishësinë e këtij koncepti: infrastruktura mund të jetë në mënyrë relative e jashtme dhe në mënyrë relative e brendshme.
Infrastruktura e jashtme nënkupton gjithçka që siguron funksionimin e shërbimit ose produktit, për zhvillimin e të cilit merret ekipi. Këto janë serverët e aplikacioneve ose faqeve të internetit, hosting dhe shërbime të tjera që sigurojnë funksionimin e produktit.
Infrastruktura e brendshme përfshin shërbime dhe pajisje që përdor vetë ekipi i zhvillimit dhe punonjës të tjerë, të cilët zakonisht janë gjithashtu të shumtë. Këto janë serverët e brendshëm të sistemeve për ruajtjen e kodit, menaxherët e detyrave të instaluar lokal dhe gjithçka, gjithçka që ekziston brenda intranetit korporativ.
Çfarë bën një administrator sistemesh në kompani? Përveç menaxhimit të intranetit të korporatës, shpesh ka përgjegjësi për sigurinë e pajisjeve zyrtare. Admini është ai djalë që shpejt sjell një sistem të ri nga depoja ose një laptop të gatshëm për përdorim, jep një tastierë të re dhe zvarritet nëpër zyra duke tërhequr kabllon Ethernet. Admini është zotëruesi lokal dhe mbikëqyrësi i brendshëm dhe të jashtëm. serverësh, por edhe menaxher i burimeve. Po, disa administrues mund të punojnë vetëm në aspektin sistematik, pa harduer. Ata duhet të veçohen në një nënklasë të quajtur "administratorë sistemesh infrastrukturore". Disa specializohen në shërbimin e pajisjeve zyrtare, sidomos nëse kompania ka më shumë se njëqind punonjës; puna asnjëherë nuk përfundon. Por as këta, as ata nuk janë DevOps.
Kush janë DevOps? DevOps janë ata djem që merren me ndërveprimin e zhvillimit të software-it me infrastrukturën e jashtme. Në fakt, DevOps-të moderne janë shumë më të përfshirë në proceset e zhvillimit dhe shpërndarjes se sa ishin ndonjëherë administruesit, të cilët thjesht ngarkonin përditësime në ftp. Një nga detyrat kryesore të inxhinierit DevOps tani është të sigurojë një proces efektiv dhe komod ndërveprimi midis ekipeve të zhvillimit dhe infrastrukturës së produktit. Këta njerëz janë përgjegjës për implementimin e sistemeve të rikthimit dhe shpërndarjes, dhe ato marrin mbi vete një pjesë të ngarkesës nga zhvilluesit dhe përqendrohen maksimalisht në detyrën e tyre shumë të rëndësishme. Megjithatë, një DevOps kurrë nuk do të tërheqë një kabllo të re ose do të japë një laptop të ri nga depoja.
Cili është hileja?
Në pyetjen «Kush është DevOps?» gjysma e punonjësve të fushës fillojnë të përgjigjen me diçka si «No, është një admin që…» dhe më pas vazhdojnë. Po, dikur, kur profesioni i inxhinierit DevOps sapo kishte dalë nga adminët më të talentuar në shërbimin e shërbimeve, dallimet midis tyre nuk ishin të qarta për të gjithë. Por tani, kur funksionet e devopsit dhe adminit në ekip kanë filluar të ndryshojnë radikalisht, të ngatërrosh ato midis tyre, apo për më tepër, të vendosësh një shenjë barazimi mes tyre — është e papranueshme.
Por çfarë rezultati ka kjo për biznesin?
Rekrutimi, kjo është e gjitha.
Ju hapni një vakancë «Sistem Administrator» dhe atje janë të renditura kërkesat «bashkëpunimi me zhvilluesit dhe klientët», «sistemi i dorëzimit CI/CD», «mbajtja e serverëve dhe pajisjeve të kompanisë», «administrimi i sistemeve të brendshme» dhe kështu me radhë; ju kuptoni se punëdhënësi po thotë diçka të çmendur. Rreziku është se në vend të «Sistem Administrator» në titullin e vakancës duhet të jetë «Inxhinier DevOps», dhe nëse ky titull ndërron, gjithçka kthehet në vend.
Megjithatë, çfarë përshtypjeje krijohet kur lexoni një vakancë të tillë? Se kompania po kërkon një njeri të shumëanshëm, i cili do të vendosë sistemin e kontrollit të versioneve dhe monitorimin, dhe do të mbajë një vitrinë me dhëmbë…
Por për të mos e rritur temperaturën e narkomanisë në tregun e punës, mjafton të quhen vakancat me emrat e tyre dhe të kuptohet qartë se inxhinieri DevOps dhe administrator sistemi janë dy entitete të ndryshme. Por dëshira e papërmbajtshme e disa punëdhënësve për të paraqitur një listë sa më të gjerë kërkesash për kandidatin çon në faktin se administratorët «klasikë» të sistemeve nuk e dinë çfarë po ndodh rreth tyre. Çfarë, profesioni po mutacionohet dhe ata kanë ngecur pas?
Jo, jo dhe përsëri jo. Administratoret e infrastrukturës, të cilët do të menaxhojnë serverët e brendshëm të kompanisë, ose do të kenë pozita L2/L3 të mbështetjes dhe do të ndihmojnë punonjësit e tjerë, nuk kanë zhdukur dhe nuk kanë ndërmend të ikin.
A mund të bëhen këta specialistë inxhinierë DevOps? Sigurisht, mund të bëhen. Në fakt, kjo është një mjedis i ngjashëm që kërkon aftësi në administrimin e sistemeve, por përveç kësaj, përfshin punën me monitorimin, sistemet e dërgesave dhe, në përgjithësi, një bashkëpunim të ngushtë me ekipin e zhvillimit dhe testimit.
Një problem tjetër i DevOps
Në fakt, angazhimi dhe konfuzioni i vazhdueshëm midis administratorëve dhe devops-ëve nuk është çështja e vetme. Në një moment të caktuar, biznesi u përball me problemin e dërgimit të azhurnimeve dhe bashkëpunimit të ekipit të zhvillimit me infrastrukturën përfundimtare.
Ndoshta, kjo ndodhi kur në skenën e ndonjë konference u ngjit një zotëri me sytë që shkëlqenin dhe tha: "Ne e bëjmë kështu dhe e quajmë DevOps. Këta djem do të zgjidhin të gjitha problemet tuaja" — dhe filloi të tregonte se sa mirë jeton në kompani pas zbatimit të praktikave DevOps.
Megjithatë, nuk mjafton të angazhosh një inxhinier DevOps që gjithçka të fillojë të funksionojë "siç duhet". Kompania duhet të kalojë plotësisht nëpër transformimin DevOps, domethënë roli dhe mundësitë e devops-it tonë duhet të kuptohen qartësisht edhe nga ana e ekipit të zhvillimit dhe testimit të produktit. Për këtë temë kemi një histori "të shkëlqyer" që ilustron plotësisht të gjitha këto situata tejet të çuditshme.
Shtet. DevOps-i kërkohet të zhvillojë një sistem rikthimi të versioneve, pa u thelluar shumë se si do të funksionojë. Le të supozojmë se brenda sistemit përdoruesit janë fusha të veçanta për emrin, mbiemrin dhe fjalëkalimin. Del një version i ri i produktit, por për zhvilluesit «rikthimi» është thjesht një magji që gjithçka do të rregullojë, dhe ata as që e imagjinojnë se si funksionon. Pra, për shembull, zhvilluesit në një patch të radhës ndanë fushat e emrit dhe mbiemrit, e lëshuan këtë në prodhim, dhe versioni ngec për disa arsye. Çfarë ndodh? Drejtoria shkon tek DevOps-i dhe thotë «Tërheqi ndërprerësin!», domethënë i kërkon atij të kthehet në versionin e mëparshëm. Çfarë bën DevOps-i? Ai kthehet në versionin e mëparshëm, por pasi zhvilluesit nuk donin të merreshin me mënyrën se si bëhet ky rikthim, askush nga ata nuk i tha DevOps-it që duhej të kthente edhe bazën. Si rezultat, gjithçka bie, dhe përdoruesit ndajnë një gabim «500» në vend të një siti të ngadalshëm, sepse versioni i vjetër nuk funksionon me fushat e bazës së re. DevOps-i nuk është në dijeni për këtë. Zhvilluesit janë të heshtur. Drejtoria fillon të humbasë nervat dhe para dhe kujton backupet, duke ofruar rikthimin nga ato për «qoftë çfarëdo që funksionon». Si rezultat, përdoruesit humbasin të gjitha të dhënat e tyre për një periudhë kohe.
Sigurisht, DevOps-i merr kritika, përveç se që nuk e bëri sistemin e duhur të rikthimit, ndërsa zhvilluesit në këtë histori nuk i intereson askujt.
Përfundimi është i thjeshtë: pa një qasje të arsyeshme ndaj DevOps-it, nuk ka shumë përfitim nga ai.
Gjëja kryesore që duhet të mbani mend: inxhinieri DevOps nuk është magjistar, dhe pa komunikime të cilësisë dhe bashkëpunim të dyanshëm me zhvillimin ai nuk do të jetë në gjendje të përballojë detyrat e tij. DevOps-at nuk mund të lihen vetëm me «problemet» e tyre ose të ulin një urdhër «mos u shqetësoni me zhvilluesit, ata e kanë punën të kodojnë», dhe pastaj të shpresojnë se në momentin kritik gjithçka do të funksionojë siç duhet. Kështu nuk funksionon.
Në thelb, DevOps është një kompetencë në kufi mes menaxhimit dhe teknologjisë. Madje, nuk është e qartë se sa nga ky koktej teknologjish duhet të ketë më shumë sesa menaxhim. Nëse vërtet doni të ndihmoni në ndërtimin e proceseve më të shpejta dhe efikase të zhvillimit, duhet t'i besoni DevOps-it tuaj. Ai di mjetet e nevojshme, ka realizuar projekte të ngjashme dhe di si të veprojë. Ndihmoni atë, dëgjoni këshillat e tij, mos përpiquni ta izolonit në një njësi autonome. Nëse administratorët mund të punojnë vetë, atëherë DevOps-at në këtë rast janë të padobishëm; ata nuk do të mund t'ju ndihmojnë të bëheni më të mirë nëse ju nuk e dëshironi këtë ndihmë.
Dhe e fundit: mjaft me fyerjet ndaj administratorëve të infrastrukturës. Ata kanë një front të rëndësishëm pune. Po, një admin mund të bëhet inxhinier DevOps, por kjo duhet të ndodhë nga dëshira e vetë individit, dhe jo me forcë. Dhe nuk ka asgjë të keqe që një administrator sistemi do të dëshironjë të mbetet administrator sistemi — kjo është një profesion i veçantë dhe e drejta e tij. Nëse ka dëshirë për një transformim profesional, nuk duhet të harrohet se duhet të zhvillohen jo vetëm aftësi teknologjike, por edhe menaxheriale. Të gjithë këta njerëz do të duhet të mblidhen së bashku dhe të mësohen të komunikojnë në një gjuhë, dhe kjo do të duhet ta bëni ju si lider.
Burimi: habr.com
