Tema DevOps ka vitet e fundit është bërë shumë e njohur. Shumë dëshirojnë të bëhen pjesë e saj, por praktikisht, shpesh vetëm për shkak të nivelit të pagave.
Disa e përfshijnë DevOps në CV-të e tyre, ndonëse nuk gjithmonë e dinë dhe kuptojnë natyrën e termit. Disa mendojnë se mjafton të studiojnë Ansible, GitLab, Jenkins, Terraform dhe të ngjashme (lista mund të vazhdojë sipas dëshirës) për t'u bërë menjëherë 'DevOps'. Kjo, sigurisht, nuk është e vërtetë.
Këto disa vitet e fundit kam qenë kryesisht i angazhuar me implementimin e DevOps në kompani të ndryshme. Para kësaj kam punuar për më shumë se 20 vjet në pozita nga administratori i sistemit deri te IT-drejtor. Tani jam DevOps Lead Engineer në Playgendary.
Kush është DevOps
Ideja për të shkruar këtë artikull u lind pas një pyetjeje tjetër: 'Kush është DevOps?'. Ende nuk ka një termin të qëndrueshëm për këtë ose ata. Disa përgjigje tashmë janë të pranishme në këtë . Fillimisht, do të nxjerr përmbledhjet kryesore nga ajo dhe më pas do të ndaj vëzhgimet dhe mendimet e mia.
DevOps nuk është një specialist që mund të angazhohet, as një grup mjete, dhe as një departament zhvilluesish me inxhinierë.
DevOps është një filozofi dhe metodologji.
Në terma të tjerë, kjo është një grup praktikash që ndihmon në bashkëveprimin aktiv të zhvilluesve me administratorët e sistemeve. Kjo do të thotë lidhjen dhe integrimin e proceseve të punës me njëri-tjetrin.
Me shfaqjen e DevOps, struktura dhe rolet e specialistëve mbeten të njëjta (ka zhvillues, ka inxhinierë), por rregullat e ndërveprimit janë ndryshuar. Kufijtë midis departamenteve janë shuar.
Qëllimet e DevOps mund të përshkruhen me tre pika:
- Software-i duhet të përditësohet rregullisht.
- Software-i duhet të zhvillohet shpejt.
- Software-i duhet të implementohet lehtësisht dhe brenda afateve të shkurtra.
DevOps nuk ka një mjet të vetëm. Konfigurimi, instalimi dhe studimi i disa produkteve nuk do të thotë se kompania ka DevOps. Ka shumë mjete që përdoren në etapa të ndryshme, por të gjitha shërbejnë një qëllim të përbashkët.
Dhe kjo është vetëm një pjesë e mjeteve të DevOps.
Prej më shumë se 2 vjetësh, unë intervistoj njerëz për pozitat e inxhinierëve DevOps dhe kam arritur në kuptimin se sa e rëndësishme është të kuptohet qartë themeli i terminologjisë. Kam mbledhur përvojën specifike, vëzhgimet dhe mendimet që dua të ndaj.
Nga përvoja e intervistave, unë shoh një pamje të tillë: specialistët që e konsiderojnë DevOps një pozite, zakonisht kanë keqkuptime me kolegët.
Ishte një shembull i qartë. Në intervistë erdhi një djalë i ri me shumë fjalë të mençura në CV. Në tri vendet e fundit të punës kishte një përvojë prej 5-6 muajsh. Nga dy startup-et u largua, sepse "nuk shpërthyen". Ndërsa për kompaninë e tretë tha se askush atje nuk e kupton: zhvilluesit shkruajnë kod për Windows, ndërsa drejtori e detyron këtë kod ta "mbështjellë" në një Docker normal dhe ta integrojë në CI/CD pipeline. Djali tregoi një sasi negative për vendin e tij aktual të punës dhe për kolegët — do të doja të thoja: "Pra, ti nuk do të shesësh elefantin".
Pastaj i bëra një pyetje, e cila është një nga të parat në listën time për çdo kandidat.
— Çfarë do të thotë për ty DevOps?
— Në përgjithësi apo si e kuptoj unë?
Më interesonte opinioni i tij personal. Ai e dinte teorinë dhe origjinën e termit, por ishte kategorikisht në kundërshtim me të. Ai mendonte se DevOps është një pozite. Këtu fshehet rrënja e problemeve të tij, ashtu si e specialistëve të tjerë me të njëjtin mendim.
Punëdhënësit, të prirur nga «magjia e DevOps», duan të gjejnë një person që të vijë dhe të krijojë këtë «magji». Ndërsa aplikantët prej kategorisë «DevOps është një pozicion» nuk kuptojnë se me këtë qasje ata nuk do të mund t'i plotësojnë pritshmëritë. Dhe, në përgjithësi, e shkruan në CV-në e tij DevOps sepse është një trend dhe paguhet shumë për këtë.
Metodologjia dhe filozofia e DevOps
Metodologjia mund të jetë teorike dhe praktike. Në rasin tonë — e dyta. Siç përmenda më lart, DevOps është një grup praktikash dhe strategjish që aplikohen për arritjen e qëllimeve të deklaruara. Dhe në çdo rast, në varësi të proceseve të biznesit të kompanisë, mund të ndryshojë ndjeshëm. Këto nuk e bëjnë më të mirë apo më të keq.
Metodologjia e DevOps është vetëm një mjet për arritjen e qëllimeve të vendosura.
Tani për atë që është filozofia e DevOps. Dhe kjo, ndoshta, është pyetja më e vështirë.
Formulimi i një përgjigjeje të shkurtër dhe të qartë është mjaft i vështirë, sepse ajo ende nuk është formuluar. Dhe duke qenë se ndjekësit e filozofisë DevOps merret më shumë me praktikën - nuk kanë kohë për filozofim. Megjithatë, ky është një proces shumë i rëndësishëm. Ai lidhet ngushtë me aktivitetin inxhinierik. Ekziston madje një fushë e specializuar e njohurive - .
Në universitetin tim nuk kishte një lëndë të tillë, prandaj duhet ta studioja të gjitha vetë nga materialet që arrita të gjej në vitet '90. Ky temë nuk është e detyrueshme për arsimin inxhinierik, prandaj mungon formalisht një përgjigje. Por ata njerëz që janë thellësisht të angazhuar në DevOps, fillojnë të ndiejnë një 'shpirt' ose 'një gjithëpërfshirje të pakëndshme' të të gjithë proceseve të kompanisë.
Duke u bazuar në përvojën time, kam përpiqur të formuloj disa 'postulate' të kësaj filozofie. Rezultati është si më poshtë:
- DevOps nuk është diçka autonome, që mund të identifikohet si një drejtim të veçantë të njohurive apo aktivitetit.
- Të gjithë punonjësit e kompanisë duhet të udhëhiqen nga metodologjia DevOps gjatë planifikimit të aktiviteteve të tyre.
- DevOps ndikon të gjitha proceset brenda kompanisë.
- DevOps ekziston për të ulur shpenzimet e kohës për çdo process brenda kompanisë për të siguruar zhvillimin e shërbimeve të saj dhe maksimizimin e komoditetit të klientit.
- Në terma modernë, DevOps është një qëndrim proaktiv i çdo punonjësi të kompanisë që fokusohet në uljen e kostove të kohës dhe përmirësimin e cilësisë së produkteve IT që na rrethojnë.
Mendoj se postulatet e mia janë një temë e veçantë për diskutim. Por tani ka nga ku të nisim.
Çfarë bën DevOps
Fjala kyçe këtu është komunikimi. Ka shumë komunikime, nismëtari i të cilave duhet të jetë ndihmës inxhinier DevOps. Pse kështu? Sepse kjo është një filozofi dhe metodologji, dhe pastaj ndjekin njohuritë inxhinierike.
Nuk mund të flas me 100% siguri për tregun perëndimor të punës. Por për tregun DevOps në Rusi di shumë. Përveç qindra intervistave, gjatë 1.5 viteve të fundit kam marrë pjesë në një qindë të presale teknik për shërbimin 'Implementimi i DevOps' për kompani dhe banka të mëdha ruse.
Në Rusi, DevOps është një temë ende shumë e re, por tashmë në trend. Sipas informacioneve që kam, vetëm në Moskë, për vitin 2019, kishte një mungesë prej më shumë se 1000 specialistësh. Dhe fjala Kubernetes është për punëdhënësit gati si një leckë e kuqe për një bull. Adhetarët e këtij instrumenti janë gati ta përdorin edhe atje ku nuk është e nevojshme dhe nuk është ekonomikisht e përshtatshme. Punëdhënësi nuk e kupton gjithmonë se kur është më e vërteta për të përdorur, dhe me një shpërndarje të duhur, përmbajtja e klasterit Kubernetes kushton nga 2-3 herë më shumë se sa shpërndarja e një aplikacioni në një skemë normale të klasterit. Përdoreni atë atje ku është vërtet e nevojshme.
Zbatimi i DevOps nga pikëpamja financiare është i kushtueshëm. Kjo është e arsyeshme vetëm aty ku sjell përfitime ekonomike në fusha të tjera, dhe jo për vetvete.
Inxhinierët DevOps janë në fakt pionierë — ata janë të parët që duhet të zbatojnë këtë metodologji në kompani dhe të ndërtojnë proceset. Për ta bërë këtë me sukses, specialisti duhet të bashkëpunojë vazhdimisht me punonjësit dhe kolegët në të gjitha nivelet. Siç thosha zakonisht, në procesin e zbatimit të DevOps duhet të përfshihen të gjithë punonjësit e kompanisë: nga pastruesja deri te CEO. Dhe kjo është një kusht i domosdoshëm. Nëse anëtari më i ri i ekipit nuk do të dijë dhe të kuptojë se çfarë është DevOps dhe përse realizohen veprime të caktuara organizative, atëherë implementimi i suksesshëm nuk do të arrihet.
Gjithashtu, inxhinierit DevOps i nevojitet herë pas here të përdorë burimin administrativ. Për shembull, për të përballuar "rezistencën e ambientit" — kur ekipi nuk është i gatshëm të pranojë mjetet dhe metodologjinë DevOps.
Një zhvillues duhet të shkruaj vetëm kod dhe teste. Për këtë, ai nuk ka nevojë për një laptop super të fuqishëm, ku do të vendosë dhe mbajë lokalisht të tërë infrastrukturën e projektit. Për shembull, një front-end i ruan të gjitha elementet e aplikacionit në laptopin e tij, duke përfshirë bazën e të dhënave, emuluesin S3 (minio) dhe të tjera. Në këtë mënyrë, ai shpenzon shumë kohë për të mbajtur këtë infrastrukturë lokale dhe përballet vetëm me të gjitha problemet që sjell një zgjidhje e tillë. Në vend që të zhvillojë kod për frontin. Njerëzit e tillë mund të jenë shumë të rezistueshëm ndaj çdo ndryshimi.
Por ka ekipe që, përkundrazi, janë të lumtur për të implementuar mjete dhe metoda të reja dhe të angazhuar aktivisht në këtë proces. Nëse ndodhin ndërkohë, komunikimi midis inxhinierit DevOps dhe ekipit nuk është anuluar.
Kur DevOps nuk nevojitet
Ka situata kur DevOps nuk nevojitet. Ky është një fakt — duhet ta kuptojmë dhe ta pranojmë.
Në radhë të parë, kjo ndërlidhet me çdo kompani (veçanërisht biznesin e vogël), kur fitimi i tyre nuk varet drejtpërdrejt nga praninë ose mungesën e produkteve IT që ofrojnë shërbime informative për klientët. Dhe këtu nuk bëhet fjalë për faqen e kompanisë, qoftë ajo një 'vizitkë' statike ose me blloqe dinamike lajmesh etj.
DevOps është i nevojshëm kur disponueshmëria e këtyre shërbimeve informative për ndërveprimin me klientin, cilësia dhe targetimi i tyre përcaktojnë kënaqësinë e klientit tuaj dhe dëshirën e tij për të rikthyer sërish te ju.
Një shembull i njohur është një bankë e njohur. Kompania nuk ka zyra klientësh të zakonshme, dokumentacioni realizohet përmes postës ose kurierëve, dhe shumë punonjës punojnë nga shtëpia. Kompania nuk është më thjesht një bankë dhe, sipas mendimit tim, ka kaluar në një kompani IT me teknologji të zhvilluar DevOps.
Më shumë shembuj dhe ligjërata mund të gjenden në regjistrimet e mitapeve tematikë dhe konferencave. Një pjesë e tyre e kam vizituar personalisht — kjo është një përvojë shumë e dobishme për ata që duan të zhvillohen në këtë drejtim. Këtu janë lidhjet në kanale YouTube me ligjërata dhe materiale të mira mbi DevOps:
Tani shikoni biznesin tuaj dhe mendoni për këtë: sa shumë varet kompania juaj dhe fitimi i saj nga produktet IT që ofrojnë ndërveprim me klientët?
Nëse kompania juaj tregton peshk në një dyqan të vogël dhe produkti i vetëm IT janë dy konfigurations 1C: Ndërmarrja (Llogaritë dhe UNF), nuk ka kuptim të flasim për DevOps.
Nëse punoni në një ndërmarrje të madhe tregtare dhe prodhuese (për shembull, prodhoni armë gjuetie), atëherë ia vlen të mendoni. Ju mund të tregoni iniciativë dhe t'u transmetoni drejtuesve tuaj perspektivat e zbatimit të DevOps. Dhe gjithashtu, të drejtoni këtë proces. Një pozicion proaktiv është një nga postulatet e rëndësishme të filozofisë DevOps.
Madhësia dhe volumi i xhiros financiare vjetore nuk është kriteri kryesor për të përcaktuar nëse kompania juaj ka nevojë për DevOps.
Imagine a large industrial enterprise that does not interact directly with customers. For example, some automotive manufacturers and car manufacturing companies. I'm not sure now, but from my past experience, for many years all customer interactions were conducted via email and phone.
Their clients consist of a limited list of car dealers, with a manufacturer's specialist assigned to each one. All internal documentation flows through ERP SAP. Internal staff essentially act as clients of the information system. However, the management of this information system is handled using traditional cluster management tools, which excludes the possibility of using DevOps practices.
The conclusion is that for such enterprises, the introduction of DevOps is not critically important, if we recall the methodology's goals mentioned at the beginning of this article. However, I do not rule out that some DevOps tools might be in use today.
Në anën tjetër, ka shumë kompani të vogla që zhvillojnë software duke përdorur metodologjinë, filozofinë, praktikat dhe mjetet e DevOps. Ata besojnë se shpenzimet për implementimin e DevOps janë kostot që u lejojnë të konkurrojnë në mënyrë efektive në tregun e software-it. Shembujt e këtyre kompanive janë të dukshme .
Kriteri kryesor për të kuptuar nëse ju nevojitet DevOps: ç'bukur shprehin produktet tuaja IT vlerën për kompaninë dhe klientët.
Nëse produkti kryesor i kompanisë, që sjell fitim, është software — ju nevojitet DevOps. Dhe nuk ka rëndësi nëse fitoni para reale me produkte të tjera. Këtu më përfshihen gjithashtu dyqanët online ose aplikacionet mobile me lojëra.
Të gjitha lojërat ekzistojnë falë financimit: të drejtpërdrejtë ose tërthor nga lojtarët. Në Playgendary ne zhvillojmë lojëra mobile falas, në krijimin e të cilave janë përfshirë më shumë se 200 njerëz. Si e përdorim DevOps?
Po ashtu siç është përshkruar më sipër. Unë komunikoj vazhdimisht me zhvilluesit dhe testuesit, organizoj trajnime të brendshme për metodologjinë dhe mjetet e DevOps.
Aktualisht, ne po përdorim Jenkins si një mjet për CI/CD pipelines për të ekzekutuar të gjithë konvejersat e ndërtimit me Unity dhe për të bërë depolimin në App Store dhe Play Market. Një tjetër nga instrumentet klasike:
- Asana — për menaxhimin e projekteve. Është konfigurimi i integrimit me Jenkins.
- Google Meet — për mbajtjen e videokonferencave.
- Slack — për komunikime dhe njoftime të ndryshme, duke përfshirë notifikimet nga Jenkins.
- Atlassian Confluence — për dokumentimin dhe punën në grup.
Në planet e afërta, është planifikuar të implementohet një analizë statike e kodit duke përdorur SonarQube dhe të kryhen teste automatike të UI me mjete Selenium në fazën e Integrimit të Vazhdushëm.
Në vend të përfundimit
Dua të përfundoj me këtë mendim: për t'u bërë një inxhinier DevOps me kualifikim të lartë, është thelbësore të mësosh të komunikosh drejtpërdrejt me njerëzit.
Inxhinieri DevOps është një lojtar skuadre. Dhe ashtu ndryshe. Iniciativa në komunikimin me kolegët duhet të vijë nga ai vetë, e jo nën ndikimin e ndonjë rrethane. Specialistët DevOps duhet të shohin dhe të propozojnë zgjidhjen më të mirë për ekipin.
Po, implementimi i çdo zgjidhjeje do të kërkojë shumë diskutime, dhe deri në fund mund të ndryshojë krejtësisht. Duke u zhvilluar vetë, duke ofruar dhe zbatuar idetë e tij — një person i tillë paraqet vlerë gjithnjë e më të madhe si për ekipin ashtu edhe për punëdhënësin. Kjo, në fund të fundit, reflektohet edhe në madhësinë e shpërblimit të tij të muajshëm ose në formën e bonuseve të tjera.
Burimi: habr.com
