Çfarë nevojitet për suksesin e një kompanie IT në vitin 2019? Folësit në konferenca dhe takime flasin shumë me terma të zhurmshëm dhe jo gjithmonë të kuptueshëm për njerëzit e zakonshëm. Garën për kohën e distribuimit, mikroshërbimet, heqjen dorë nga monoliti, transformimin DevOps dhe shumë, shumë gjëra të tjera. Nëse e heqim këtë bukuri të fjalëve dhe flasim drejtpërdrejt, gjithçka përfundon në një tezë të thjeshtë: bëni një produkt cilësor, dhe bëjeni atë me komoditet për ekipin.
Kjo e fundit është bërë kritike. Biznesi përfundimisht erdhi në mendimin se një proces zhvillimi komod rrit produktivitetin, dhe nëse gjithçka është e rregulluar dhe funksionon siç duhet, ai gjithashtu ofron një hapësirë për manovrime në situata kritike. Disa kohë më parë, për këtë manovrim, një njeri i mençur shpiku backup-et, por industria po zhvillohet, dhe ne kemi arritur te inxhinierët DevOps — njerëz që e kthejnë procesin e bashkëpunimit mes zhvillimit dhe infrastrukturës së jashtme në diçka adekuate dhe të pa lidhur me magjinë.
E gjithë kjo histori e "modulit" është e mrekullueshme, por... Është ndodhur që një pjesë e administratorëve u quajtën papritur DevOps, ndërsa nga inxhinierët e DevOps u kërkua, të paktën, aftësi telepatike dhe parashikimi.
Para se të flasim për problemet moderne të sigurisë së infrastrukturës, le të përcaktojmë se çfarë nënkuptojmë me këtë term. Në këtë moment, situata ka arritur një dyfishësi të këtij termi: infrastruktura mund të jetë условно e jashtme dhe условно e brendshme.
Me infrastrukturen e jashtme nënkuptojmë gjithçka që siguron funksionimin e shërbimit ose produktit, për zhvillimin e të cilit merret ekipi. Këtu përfshihen serverët e aplikacionit ose të faqes, hostim dhe shërbime të tjera që sigurojnë funksionimin e produktit.
Infrastruktura e brendshme përfshin shërbimet dhe pajisjet me të cilat punon vetë ekipi i zhvillimit dhe punonjësit e tjerë, të cilët zakonisht nuk janë pak. Kjo përfshin serverët e brendshëm të sistemeve të ruajtjes së kodit, menaxherin e detyrave të vendosur lokal dhe gjithçka tjetër që ekziston brenda intranetit korporativ.
Çfarë bën pra një administrator sistemi në kompaninë? Përveç administrimin e intranetit korporativ, ai shpesh ka mbi supe barrën e punëve administrative për të siguruar funksionalitetin e pajisjeve të zyrës. Admini është ai djaloshi që përveç një sërë gjërash sjell shpejt një sistem të ri nga dhoma ndihmëse ose një laptop rezervë të gatshëm për punë, jep një tastierë të re dhe shëtit në katër këmbë për në zyre, duke tërhequr kabllin Ethernet. Admini është pronari lokal dhe zotëruesi jo vetëm i të brendshmëve dhe të jashtmëve servera, por edhe administrator i pasurive. Po, disa administratës mund të punojnë vetëm në planin sistematik, pa pajisje. Ata meritojnë të veçohen në një nënklasë të veçantë të «administratorëve sistematikë të infrastrukturës». Disa specializohen vetëm në shërbimin e pajisjeve zyrtare; fatkeqësisht, nëse kompania ka më shumë se njëqind punonjës, puna asnjëherë nuk mbaron. Por asnjëri nga ata, as të tjerët nuk janë devops.
Cilët janë DevOps? DevOps janë ata që merren me ndërveprimin e zhvillimit të softuerit me infrastrukturën ekstern. Më saktë, DevOps modernë janë të angazhuar në proceset e zhvillimit dhe të deployimit shumë më thellë se sa ndonjëherë administratorët që thjesht ngarkonin përditësime në ftp. Një nga detyrat kryesore të inxhinierëve DevOps sot është të sigurojnë një proces komod dhe efikas të ndërveprimit midis ekipeve të zhvillimit dhe infrastrukturës së produktit. Këta njerëz janë përgjegjës për vendosjen e sistemeve të rikthimit dhe të deployimit; ata e marrin një pjesë të ngarkesës nga zhvilluesit dhe përqendrohen maksimalisht në detyrën e tyre jashtëzakonisht të rëndësishme. Megjithatë, DevOps nuk do të shtrijë kurrë një kabllo të re ose të dhurojë një laptop të ri nga depo (c) KO
Çfarë është poshtë?
Kur pyetet "Cili është DevOps?" gjysma e punonjësve të fushës fillojnë të përgjigjen me diçka si "Eh, është, për shkak se, një administrator, i cili..." dhe pastaj vazhdojmë. Po, dikur, kur profesioni i inxhinierit DevOps sapo po krijohej nga administratorët më të talentuar për shërbimin e shërbimeve, diferencat mes tyre nuk ishin të duhura. Por tani, kur funksionet e DevOps-it dhe administratorëve në ekipin kanë filluar të ndryshojnë radikalisht, është e papranueshme t’i ngatërrosh ata, ose madje të vendosësh një shenjë barazimi midis tyre.
Por çfarë ndodh me këtë për biznesin?
Rekrutimi, e gjitha është në të.
Ju hapni një postim për vendin e punës "Administrator sistemi", dhe aty janë të renditura kërkesat si "bashkëpunimi me zhvilluesit dhe klientët", "sistemi i shpërndarjes CI/CD", "mbështetje e serverëve dhe pajisjeve të kompanisë", "administrimi i sistemeve të brendshme" e kështu me radhë; ju e kuptoni se punëdhënësi po thotë diçka pa kuptim. Problemi është se në vend të "Administratorit të sistemit" në titullin e postimit duhet të shkruajë "Inxhinier DevOps", dhe nëse ky titull nxihet, gjithçka vendoset në vend.
Porosi se bën një përshtypje kur lexoni një ofertë të tillë pune? Çfarë kërkon kompania nga një person që do të krijojë dhe do të menaxhojë një sistem versionimi dhe monitorimi, dhe gjithashtu do të kapërcejë vështirësitë me dhëmbët e tij...
Epo, për të mos rritur nivelin e çmendurisë në tregun e punës, është mjaft të quhen ofertat për punë me emrat e tyre dhe të kuptohet qartë se inxhinieri DevOps dhe administrator sistemi janë dy entitete të ndryshme. Por dëshira e pakontrolluar e disa punëdhënësve për të kërkuar një listë sa më të gjerë kërkesash nga kandidati çon në faktin se administratorët klasikë të sistemeve nuk kuptojnë më se çfarë ndodh përreth tyre. A po mutacionohet profesioni dhe ata kanë ngecur në jetë?
Jo, jo dhe përsëri jo. Administratorët e infrastrukturës, të cilët do të menaxhojnë serverët e brendshëm të kompanisë, ose do të qëndrojnë në pozita L2/L3 mbështetje dhe do të ndihmojnë kolegët e tjerë, nuk kanë shkuar askund dhe nuk planifikojnë të largohen.
A mund të bëhen këta specialistë inxhinierë DevOps? Sigurisht që 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 dorëzimit dhe, në përgjithësi, një bashkëpunim të ngushtë me ekipin e zhvillimit dhe testimit.
Një tjetër problem i DevOps
Në të vërtetë, problemi nuk përfundon vetëm me rekrutimin dhe ngatërresat e vazhdueshme midis administratorëve dhe devopëve. Në një moment, biznesi përballet me problemin e dorëzimit të përditësimeve dhe bashkëpunimit të ekipit të zhvillimit me infrastrukturën përfundimtare.
Ndoshta ishte atëherë kur në skenën e një konference u ngjit një djalosh 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ë fliste se sa mirë jeton në kompani pas implementimit të praktikave DevOps.
Megjithatë, mjafton të angazhosh një inxhinier DevOps për ta bërë çdo gjë të funksionojë "siç duhet". Kompania duhet të kalojë një transformim të plotë DevOps, domethënë roli dhe mundësitë e DevOps-it tonë duhet të kuptohen qartë gjithashtu nga ekipi i zhvillimit dhe testimit të produktit. Kemi një histori "fantastike" lidhur me këtë temë që ilustron plotësisht të gjithë këtë gjendje të ndodhur ndonjëherë.
Situata. Një devops-i kërkohet të implementojë një sistem rihapjeje versionesh, pa u shqetësuar shumë për mënyrën se si do të funksionojë. Supozojmë, brenda sistemit Users — ka 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ë magjistar që do të rregullojë gjithçka, dhe ata madje nuk e imagjinojnë se si funksionon. Pra, për shembull, zhvilluesit në një patch të radhës bashkuan fushat e emrit dhe mbiemrit, e nxorrën këtë në prodhim, dhe versioni ngadalësohet për disa arsye. Çfarë ndodh? Menaxhimi i drejtohet devops-it dhe thotë "Të tërheqim kabllin!", domethënë kërkojnë të rikthehet në versionin e mëparshëm. Çfarë bën devops? Ai rikthehet në versionin e mëparshëm, por pasi zhvilluesit nuk donin të merrnin në dorë se si bëhet ky rikthim, askush nuk i tha devops-it që duhej të rikthehej edhe baza. Si rezultat, gjithçka bie, dhe përdoruesit përveç një site të ngadalshëm, shohin gabimin "500", sepse versioni i vjetër nuk punon me fushat e bazës së re. Devops-i nuk është në dijeni për këtë. Zhvilluesit heshtin. Menaxhimi fillon të humbasë nervat dhe para dhe kujton për back-up-et, duke propozuar që të rikthehet nga ato, që "të funksionojë ndonjë gjë". Si rezultat, përdoruesit humbasin të gjithë të dhënat e tyre për një periudhë kohe.
Sigurisht, këto kritika drejtohen ndaj DevOps-it, që "nuk krijoi një sistem të saktë rikthimi", ndërsa askujt nuk i intereson se zhvilluesit janë elkat në këtë histori.
Përfundimi është i thjeshtë: pa një qasje të duhur ndaj DevOps-it, i gjithë ky proces nuk ka shumë vlerë.
E rëndësishme që duhet të mbani mend: inxhinieri DevOps nuk është magjistar, dhe pa komunikim të mirë dhe bashkëpunim dypalësh me zhvillimin, ai nuk do të përballojë detyrat e tij. DevOps-at nuk mund të lihen vetëm me "problemet" e tyre, ose t'u thuhen të "mos i përziejnë zhvilluesit, ata merren me kodimin", dhe pastaj të shpresohet se në një moment kritik gjithçka do të funksionojë siç duhet. Kështu nuk funksionon.
Në thelb, DevOps janë kompetenca që ndodhen në kufijtë midis menaxhimit dhe teknologjisë. Për më tepër, nuk është aspak e qartë se në këtë kokteil teknologjish duhet të ketë më shumë sesa menaxhim. Nëse vërtet dëshironi të ndërtoni procese më të shpejta dhe më efikase të zhvillimit, duhet t'i besoni DevOps-it tuaj. Ai njeh mjetet e nevojshme, ka realizuar projekte të ngjashme, e di si të bëjë. Ndihmojeni atë, dëgjoni këshillat e tij, mos u përpiqni ta izolonit në një njësi autonome. Nëse administratorët mund të punojnë vetë, atëherë DevOps janë në ato raste të padobishëm; ata nuk do të mund t'ju ndihmojnë të bëheni më të mirë nëse ju vetë nuk e dëshironi këtë ndihmë.
Në fund, mjaft të ofendoni adminstratorët e infrastrukturës. Ata kanë një front pune shumë të rëndësishëm. Po, një admin mund të bëhet DevOps inxhinier, por kjo duhet të ndodhë nga dëshira e vetë individit, e jo nga detyrimi. Dhe nuk ka asgjë të keqe që një administrator sistemi dëshiron të mbetet administrator sistemi — kjo është një profesion i veçantë dhe e drejta e tij. Nëse ka dëshirë për t'u transformuar profesionalisht, është e nevojshme të mos harrohet se duhet të zhvillohen jo vetëm aftësi teknologjike, por gjithashtu edhe ato menaxheriale. Të gjithë këta njerëz, duke qenë bashkë, do të duhet t'i mësoni të flasin një gjuhë të përbashkët, ndoshta pikërisht ju si udhëheqës.
Burimi: habr.com
