Çfarë duhet që një kompani IT të jetë e suksesshme në 2019? Lektorët në konferenca dhe takime thonë shumë fjalë me zë të lartë që nuk janë gjithmonë të kuptueshme për njerëzit normalë. Lufta për kohën e vendosjes, mikroshërbimet, braktisja e monolitit, transformimi i DevOps dhe shumë, shumë më tepër. Nëse e hedhim poshtë bukurinë verbale dhe flasim drejtpërdrejt dhe në rusisht, atëherë gjithçka zbret në një tezë të thjeshtë: bëni një produkt me cilësi të lartë dhe bëjeni me rehati për ekipin.
Kjo e fundit është bërë jashtëzakonisht e rëndësishme. Biznesi më në fund ka arritur në përfundimin se një proces i rehatshëm zhvillimi rrit produktivitetin dhe nëse gjithçka korrigjohet dhe funksionon si një orë, ai gjithashtu jep hapësirë për manovrim në situata kritike. Njëherë e një kohë, për hir të kësaj manovre, një person i caktuar i zgjuar doli me kopje rezervë, por industria po zhvillohet, dhe erdhëm te inxhinierët DevOps - njerëz që e kthejnë procesin e ndërveprimit midis zhvillimit dhe infrastrukturës së jashtme në diçka adekuate dhe nuk ka lidhje me shamanizmin.
E gjithë kjo histori "modulare" është e mrekullueshme, por... Ndodhi që disa nga administratorët u quajtën befas DevOps dhe vetë inxhinierëve të DevOps filluan t'u kërkohet të kishin të paktën aftësitë e telepatisë dhe të mprehtësisë.
Përpara se të flasim për problemet moderne të sigurimit të infrastrukturës, le të përcaktojmë se çfarë kuptojmë me këtë term. Në momentin aktual, situata është zhvilluar në atë mënyrë që kemi arritur në dualitetin e këtij koncepti: infrastruktura mund të jetë me kusht e jashtme dhe me kusht e brendshme.
Me infrastrukturë të jashtme nënkuptojmë gjithçka që siguron funksionalitetin e shërbimit ose produktit që ekipi po zhvillon. Këta janë serverë aplikacionesh ose faqe interneti, hosting dhe shërbime të tjera që sigurojnë funksionalitetin e produktit.
Infrastruktura e brendshme përfshin shërbime dhe pajisje që përdoren nga vetë ekipi i zhvillimit dhe punonjës të tjerë, nga të cilët zakonisht ka shumë. Këta janë serverë të brendshëm të sistemeve të ruajtjes së kodit, një menaxher detyrash i vendosur në nivel lokal dhe gjithçka, gjithçka, gjithçka që ekziston brenda intranetit të korporatës.
Çfarë bën një administrator sistemi në një kompani? Përveç punës së administrimit të këtij intraneti shumë të korporatës, ai shpesh mban barrën e shqetësimeve ekonomike për të siguruar funksionimin e pajisjeve të zyrës. Administratori është i njëjti djalë që do të tërheqë shpejt një njësi të re të sistemit ose një laptop rezervë gati për përdorim nga dhoma e pasme, do të japë një tastierë të freskët dhe do të zvarritet me të katër këmbët nëpër zyra, duke shtrirë kabllon Ethernet. Një administrator është një pronar dhe sundimtar lokal jo vetëm i serverëve të brendshëm dhe të jashtëm, por edhe një ekzekutiv biznesi. Po, disa administratorë mund të punojnë vetëm në planin e sistemit, pa pajisje. Ata duhet të ndahen në një nënklasë të veçantë të "administratorëve të sistemit të infrastrukturës". Dhe disa specializohen në servisimin ekskluzivisht të pajisjeve të zyrës; për fat, nëse kompania ka më shumë se njëqind njerëz, puna nuk përfundon kurrë. Por asnjëri prej tyre nuk është devops.
Kush janë DevOps? Devops janë djem që flasin për ndërveprimin e zhvillimit të softuerit me infrastrukturën e jashtme. Më saktësisht, devops-të modernë janë të përfshirë në proceset e zhvillimit dhe vendosjes shumë më thellë sesa ishin përfshirë ndonjëherë administratorët që thjesht ngarkuan përditësime në ftp. Një nga detyrat kryesore të një inxhinieri DevOps tani është të sigurojë një proces të rehatshëm dhe të strukturuar në mënyrë efektive të ndërveprimit midis ekipeve të zhvillimit dhe infrastrukturës së produktit. Janë këta njerëz që janë përgjegjës për vendosjen e sistemeve të rikthimit dhe vendosjes; janë këta njerëz që heqin një pjesë të ngarkesës nga zhvilluesit dhe përqendrohen sa më shumë që të jetë e mundur në detyrën e tyre jashtëzakonisht të rëndësishme. Në të njëjtën kohë, devops nuk do të ekzekutojë kurrë një kabllo të re ose nuk do të lëshojë një laptop të ri nga dhoma e pasme (c) KO
Çfarë është kapja?
Në pyetjen "Kush është DevOps?" gjysma e punëtorëve në terren fillojnë të përgjigjen diçka si "Epo, me pak fjalë, ky është administratori që ..." dhe më tej në tekst. Po, një herë e një kohë, kur profesioni i inxhinierit DevOps sapo po dilte nga administratorët më të talentuar për sa i përket mirëmbajtjes së shërbimit, dallimet mes tyre nuk ishin të dukshme për të gjithë. Por tani, kur funksionet e devops dhe administratorit në ekip janë bërë rrënjësisht të ndryshme, është e papranueshme t'i ngatërrojmë me njëri-tjetrin, madje edhe t'i barazojmë.
Por çfarë do të thotë kjo për biznesin?
Punësimi, gjithçka ka të bëjë me të.
Ju hapni një vend vakant për “Administrator i Sistemit” dhe kërkesat e listuara aty janë “ndërveprimi me zhvillimin dhe klientët”, “sistem shpërndarjeje CI/CD”, “mirëmbajtja e serverëve dhe pajisjeve të kompanisë”, “administrimi i sistemeve të brendshme” etj. më; ju e kuptoni që punëdhënësi po flet marrëzi. Kapja është se në vend të "System Administrator" titulli i vendit vakant duhet të jetë "Inxhinier DevOps", dhe nëse ky titull ndryshohet, atëherë gjithçka bie në vend.
Mirëpo, çfarë përshtypje të krijohet kur lexon një vend të tillë vakant? Se kompania është në kërkim të një operatori me shumë makineri i cili do të vendosë një sistem kontrolli dhe monitorimi të versionit dhe do të shtrydhë rrotulluesin me dhëmbë...
Por, për të mos rritur shkallën e varësisë nga droga në tregun e punës, mjafton të quash vendet e lira me emrat e tyre dhe të kuptojmë qartë se një inxhinier DevOps dhe një 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ë të kërkesave për një kandidat, çon në faktin se administratorët e sistemit "klasik" pushojnë së kuptuari se çfarë po ndodh rreth tyre. Çfarë, profesioni po ndryshon dhe ata janë prapa kohës?
Jo jo dhe nje here jo. Administratorët e infrastrukturës që do të menaxhojnë serverët e brendshëm të kompanisë, ose do të zënë pozicione mbështetëse L2/L3 dhe do të ndihmojnë punonjësit e tjerë, nuk janë larguar dhe nuk do të largohen.
A mund të bëhen këta specialistë inxhinierë DevOps? Sigurisht që munden. Në fakt, ky është një mjedis i lidhur që kërkon aftësi të administrimit të sistemit, por përveç kësaj, shtohet puna me monitorimin, sistemet e shpërndarjes dhe, në përgjithësi, ndërveprimi i ngushtë me ekipin e zhvillimit dhe testimit.
Një problem tjetër i DevOps
Në fakt, gjithçka nuk kufizohet vetëm në punësimin dhe konfuzionin e vazhdueshëm midis administratorëve dhe devops. Në një moment, biznesi u përball me problemin e dhënies së përditësimeve dhe ndërveprimit të ekipit të zhvillimit me infrastrukturën përfundimtare.
Ndoshta ishte kur një xhaxha me sy të shkëlqyeshëm u ngrit në skenën e një konference dhe tha: “Ne e bëjmë këtë dhe e quajmë DevOps. Këta djem do të zgjidhin të gjitha problemet tuaja” - dhe filluan të tregojnë se sa e mirë është jeta në kompani pas zbatimit të praktikave të DevOps.
Sidoqoftë, nuk mjafton të punësosh një inxhinier DevOps për të bërë gjithçka të funksionojë siç duhet. Kompania duhet t'i nënshtrohet një transformimi të plotë të DevOps, domethënë, roli dhe aftësitë e DevOps-ve tanë duhet të kuptohen qartë edhe nga ana e ekipit të zhvillimit dhe testimit të produktit. Ne kemi një histori "të mrekullueshme" për këtë temë që ilustron plotësisht gjithë brutalitetin që po ndodh në disa vende.
Situata. DevOps kërkohet të vendosë një sistem rikthimi të versionit pa u thelluar vërtet në mënyrën se si do të funksionojë. Le të supozojmë se brenda sistemit të Përdoruesve ka fusha të veçanta për emrin, mbiemrin dhe fjalëkalimin. Doli një version i ri i produktit, por për zhvilluesit, një "kthim mbrapa" është thjesht një shkop magjik që do të rregullojë gjithçka, dhe ata as nuk e dinë se si funksionon. Kështu, për shembull, në patch-in tjetër, zhvilluesit kombinuan fushat e emrit dhe mbiemrit, e nxorrën atë në prodhim, por versioni është i ngadaltë për disa arsye. Cfare po ndodh? Menaxhmenti vjen në devops dhe thotë "Tërhiq çelësin!", domethënë, i kërkon atij të kthehet në versionin e mëparshëm. Çfarë bën devops? Ai rikthehet në versionin e mëparshëm, por meqenëse zhvilluesit nuk donin të kuptonin se si u bë ky rikthim, askush nuk i tha ekipit të devops se baza e të dhënave gjithashtu duhej të rikthehej. Si rezultat, gjithçka rrëzohet për ne dhe në vend të një faqe interneti të ngadaltë, përdoruesit shohin një gabim "500", sepse versioni i vjetër nuk funksionon me fushat e bazës së të dhënave të re. Devops nuk di për këtë. Zhvilluesit janë të heshtur. Menaxhmenti fillon të humbasë nervat dhe paratë e tij dhe kujton kopjet rezervë, duke ofruar të largohet prej tyre në mënyrë që "të paktën diçka të funksionojë". Si rezultat, përdoruesit humbasin të gjitha të dhënat e tyre gjatë një periudhe kohore.
Arrat, natyrisht, shkojnë te devops, i cili "nuk krijoi një sistem të duhur rikthimi" dhe askush nuk kujdeset që moose në këtë histori janë zhvillues.
Përfundimi është i thjeshtë: pa një qasje normale ndaj DevOps si të tillë, ai ka pak përdorim.
Gjëja kryesore për të mbajtur mend: një inxhinier DevOps nuk është një magjistar, dhe pa komunikime cilësore dhe ndërveprim të dyanshëm me zhvillimin, ai nuk do të përballojë detyrat e tij. Zhvilluesit nuk mund të lihen vetëm me "problemet" e tyre ose t'u jepet komanda "mos u ndërhy me zhvilluesit, puna e tyre është të kodojnë" dhe më pas shpresojnë që në një moment kritik gjithçka do të funksionojë ashtu siç duhet. Nuk funksionon kështu.
Në thelb, DevOps është një kompetencë në kufirin midis menaxhimit dhe teknologjisë. Për më tepër, nuk është aspak e qartë se duhet të ketë më shumë teknologji sesa menaxhim në këtë koktej. Nëse vërtet dëshironi të ndërtoni procese zhvillimi më të shpejta dhe më efikase, duhet t'i besoni ekipit tuaj devops. Ai njeh mjetet e duhura, ka zbatuar projekte të ngjashme, di ta bëjë këtë. Ndihmojeni, dëgjoni këshillat e tij, mos u përpiqni ta izoloni në një lloj njësie autonome. Nëse administratorët mund të punojnë vetë, atëherë devops janë të padobishëm në këtë rast; ata nuk do të jenë në gjendje t'ju ndihmojnë të bëheni më të mirë nëse ju vetë nuk dëshironi ta pranoni këtë ndihmë.
Dhe diçka e fundit: ndaloni ofendimin e administratorëve të infrastrukturës. Ata kanë frontin e tyre, jashtëzakonisht të rëndësishëm të punës. Po, një administrator mund të bëhet një inxhinier DevOps, por kjo duhet të ndodhë me kërkesën e vetë personit, dhe jo nën presion. Dhe nuk ka asgjë të keqe me faktin që një administrator i sistemit dëshiron të mbetet një administrator i sistemit - ky është profesioni i tij i veçantë dhe e drejta e tij. Nëse dëshironi t'i nënshtroheni një transformimi profesional, atëherë nuk duhet të harroni kurrë se do t'ju duhet të ndërtoni jo vetëm aftësi teknologjike, por edhe menaxhuese. Me shumë mundësi, do të varet nga ju si udhëheqës që t'i bashkoni të gjithë këta njerëz dhe t'i mësoni ata të komunikojnë në të njëjtën gjuhë.
Burimi: www.habr.com