Aktualisht, kjo është ndoshta pozita më e shtrenjtë në treg. Zhurma rreth inxhinierëve 'DevOps' tejkalon çdo kufi të imagjinueshëm, dhe akoma më keq është me inxhinierët e Senior DevOps.
UnĂ« punoj si drejtor i departamentit tĂ« integrimit dhe automatizimit, dhe merrni njĂ« herĂ« me mend shkurtesĂ«n nĂ« anglisht â DevOps Manager. A reflekton shkurtesa angleze aktivitetet tona tĂ« pĂ«rditshme? Ndoshta jo, ndĂ«rsa varianti rus nĂ« kĂ«tĂ« rast Ă«shtĂ« mĂ« i saktĂ«. Duke qenĂ« nĂ« kĂ«tĂ« rol, Ă«shtĂ« e natyrshme qĂ« tĂ« intervistoj anĂ«tarĂ«t e rinj tĂ« ekipit tim dhe, gjatĂ« vitit tĂ« kaluar, mĂ« kanĂ« kaluar rreth 50 persona, dhe po aq Ă«shtĂ« eliminuar nĂ« preskrinin me punonjĂ«sit e mi.
Ne ende jemi në kërkim të kolegëve, sepse nën emrin DevOps fshihet një shtresë shumë e madhe inxhinierësh të ndryshëm.
Ădo gjĂ« e shkruar mĂ« poshtĂ« Ă«shtĂ« opinioni im personal; nuk keni obligim tĂ« bieni dakord me tĂ«, megjithatĂ« lejohem tĂ« mendoj se do tĂ« sjellĂ« nuanca nĂ« qĂ«ndrimin tuaj ndaj temĂ«s. PavarĂ«sisht rrezikut pĂ«r tĂ« rĂ«nĂ« nĂ« kundĂ«rshtim, po publikoj mendimin tim, pasi e konsideroj se ka vend pĂ«r tĂ«.
Kompani e kuptojnë ndryshe se kush janë inxhinierët DevOps dhe për shkak të nevojës për të punësuar shpejt, u vënë këtë etiketë të gjithëve. Situata është mjaft e çuditshme, pasi kompanitë janë të gatshme të paguajnë shpërblime të pandershme këtyre njerëzve, duke marrë në shumicën e rasteve një administrator të pajisjeve.
Pra, kush janë inxhinierët DevOps?
Le tregonim se fillon historia e shfaqjes së DevOps - DevOps u shfaq si një hap tjetër drejt optimizimit të bashkëpunimit në grupe të vogla për të rritur shpejtësinë e prodhimit të produktit, si një rezultat i pritur. Ideja ishte të forcohej ekipi i zhvillimit me njohuri mbi procedurat dhe qasjet në menaxhimin e ambientit të produktit. Në fjalë të tjera, zhvilluesi duhet të kuptojë dhe të dijë si funksionon produkti i tij në kushte të ndryshme, duhet të kuptojë si të bëjë deploy produktin e tij, çfarë karakteristikash të ambientit duhet të rregullojë për të përmirësuar performancën. Kështu, për një periudhë, u shfaqën zhvillues me qasjen DevOps. Zhvilluesit DevOps shkruanin skripta ndërtimi dhe paketimi për të thjeshtuar aktivitetet e tyre dhe funksionimin e ambientit produktiv. Megjithatë, kompleksiteti i arkitekturës së zgjidhjeve dhe ndikimi i ndërsjellë i komponenteve të infrastrukturës me kalimin e kohës filluan të përkeqësojnë performancat e ambienteve, me çdo iteracion kërkoheshin njohuri gjithnjë e më të thella mbi komponentët, duke ulur produktivitetin e vetë zhvilluesve për shkak të kostove shtesë për të kuptuar komponentët dhe për optimizimin e sistemeve sipas detyrës specifike. Kostoja e zhvilluesve po rritej, kostoja e produktit së bashku me të, kërkesat për zhvillues të rinj në ekip u rritën ndjeshëm, pasi ishte e nevojshme që ata gjithashtu të përballonin detyrat e "yjeve" të zhvillimit dhe, natyrisht, "yjet" bëheshin gjithnjë e më pak të aksesueshëm. Gjithashtu, është e rëndësishme të theksohet se, sipas përvojës time, pak zhvilluesish janë të interesuar për specifikën e përpunimit të pakove nga bërthama e sistemit operativ, rregullat e ruterizimit të pakove, aspektet e sigurisë të hostit. Hapi logjik ishte të tërhiqej një administrator, i cili është i njohur me këtë dhe t'i ngarkohej atij detyrat e tilla, të cilat, falë përvojës së tij, lejuan të arrijë të njëjtin rezultat me kosto më të ulët në krahasim me koston e "yjeve" të zhvillimit. Këta administratorë u vendosën në ekip dhe detyra e tij kryesore ishte menaxhimi i ambienteve testuese dhe produktive, sipas rregullave të ekipit të caktuar, me burimet e dedikuara saktësisht për këtë ekip. Kështu, në fakt, DevOps u shfaq në përceptimin e shumicës.
Me rrethin pak ose shumë, me kalimin e kohës, administratorët e sistemeve filluan të kuptojnë nevojat e kësaj ekipi të veçantë në zhvillim, si të thjeshtojnë jetën për zhvilluesit dhe testerët, si të nxjerrin përditësime dhe të mos qëndrojnë të fjetur në zyrë të premten, duke rregulluar gabimet e depolimit. Koha kaloi, tani "yjet" ishin administratorët e sistemeve, të cilët kuptonin çfarë donin zhvilluesit. Me qëllimin e minimizimit të impaktit, filluan të shfaqen utilitarët e menaxhimit, të gjithë përkujtuan metodat e vjetra dhe të besueshme të izolimit në nivelin e OS-së, që lejonin të minimizoheshin kërkesat për siguri, menaxhimin e pjesës rrjet dhe gjithashtu konfigurimin e hostit në përgjithësi dhe, si pasojë, të reduktoheshin kërkesat për "yjet" e rinj.
PĂ«r njĂ« kohĂ« tĂ« gjatĂ«, u shfaq njĂ« gjĂ« "e mrekullueshme" â docker. Pse mrekullueshme? Sepse krijimi i izolimit nĂ« chroot ose jail, ashtu si OpenVZ, kĂ«rkonte njohuri tĂ« konsiderueshme mbi OS-nĂ«. Me kĂ«tĂ« utilitar qĂ« lejon krijimin e njĂ« ambienti tĂ« izoluar pĂ«r aplikacionin nĂ« njĂ« host, me gjithçka tĂ« nevojshme brenda, dhe pĂ«r t'ia dorĂ«zuar pĂ«rsĂ«ri zhvilluesve, ndĂ«rsa administratori i sistemit menaxhon vetĂ«m njĂ« host, duke siguruar sigurinĂ« dhe disponueshmĂ«rinĂ« e lartĂ« â njĂ« thjeshtim logjik. Por progresi nuk ndalet dhe sistemet bĂ«hen pĂ«rsĂ«ri gjithnjĂ« e mĂ« tĂ« komplikuara, komponentĂ«t rriten vazhdimisht, njĂ« host nuk pĂ«rmbush mĂ« nevojat e sistemit dhe Ă«shtĂ« e nevojshme tĂ« ndĂ«rtohen klasterĂ«, ne kthehemi sĂ«rish te administratorĂ«t e sistemeve, qĂ« janĂ« nĂ« gjendje tĂ« ndĂ«rtojnĂ« kĂ«to sisteme.
CikĂ«l pas cikli, sistemet e ndryshme qĂ« thjeshtojnĂ« zhvillimin dhe/ose administrimin po shfaqen, gjithashtu lindin sistemet e orkestrimit, tĂ« cilat, deri sa tĂ« kĂ«rkohet tĂ« largohemi nga procesi standard, janĂ« tĂ« lehta pĂ«r t'u pĂ«rdorur. Arkitektura mikro-shĂ«rbimore gjithashtu u shfaq me qĂ«llimin pĂ«r tĂ« thjeshtuar gjithĂ« atĂ« qĂ« u pĂ«rmend mĂ« sipĂ«r â mĂ« pak ndĂ«rvarĂ«si, mĂ« e lehtĂ« pĂ«r menaxhim. NĂ« pĂ«rvojĂ«n time, nuk kam pĂ«rjetuar njĂ« arkitekturĂ« plotĂ«sisht mikro-shĂ«rbimore, do tĂ« thosha 50 me 50 â 50 pĂ«rqind mikro-shĂ«rbuj, kutitĂ« e zezĂ«, hynte, del e pĂ«rpunuar, pjesa tjetĂ«r 50 â njĂ« monolit i copĂ«tuar, shĂ«rbime qĂ« nuk ishin nĂ« gjendje tĂ« funksiononin veçmas nga komponentĂ«t e tjerĂ«. TĂ« gjitha kĂ«to pĂ«rsĂ«ri vendosĂ«n kufizime mbi nivelin e njohurive si tĂ« zhvilluesve, ashtu edhe tĂ« administratorĂ«ve.
Të tilla "luhatje" të nivelit të ekspertizës për një ose tjetër burim vazhdojnë edhe sot. Por ne u shpëtuam pak, ka mjaft momente që meritojnë të ndriçohet.
Inxhinier i Ndërtimit/Inxhinier i Lëshimit
Inxhinierët shumë të specializuar, të cilët shfaqen si një mënyrë për të standardizuar proceset e ndërtimit të softuerit dhe lëshimeve të tij. Gjatë hyrjes së pandalshme të Agile, ata dukeshin sikur humbën rëndësinë, megjithatë kjo nuk është aspak e vërtetë. Kjo specializim u shfaq si një mjet për standardizimin e ndërtimit dhe shpërndarjes së softuerit në shkallë industriale, pra duke përdorur teknika standarde për të gjitha produktet e kompanisë. Me shfaqjen e DevOps, zhvilluesit pjesërisht humbën funksionet e tyre, sepse ata filluan të përgatisin produktin për shpërndarje, dhe duke marrë parasysh ndryshimin e infrastrukturës dhe qasjen në shpërndarjen e shpejtë pa hezitim për cilësinë, me kalimin e kohës ata u shndërruan në pengesa për ndryshime, pasi ndjekja e standardeve të cilësisë patjetër ngadalëson shpërndarjet. Kështu, gradualisht, një pjesë e funksionaliteteve të inxhinierëve të Build/Release kaluan në supet e administratorëve të sistemeve.
Ops't janë kaq të ndryshëm
Ne po e çojmë përpara dhe përsëri, prania e një gamë të gjerë detyrash dhe mungesa e stafit të kualifikuar na shtyn drejt specializimit të ashpër, si kërpudhat pas shiut, shfaqen operacione të ndryshme:
- TechOps â知çć, qĂ« janĂ« tĂ« specializuar nĂ« mbĂ«shtetje dhe ndihmĂ« pĂ«r pĂ«rdoruesit
- LiveOps â administratorĂ« sistemesh qĂ« kryesisht pĂ«rgjigjen pĂ«r ambientet produktive
- CloudOps â administratorĂ« sistemesh tĂ« specializuar nĂ« «shkallĂ«t» publike, si Azure, AWS, GCP, etj.
- PlatOps/InfraOps/SysOps â administratorĂ« sistemesh pĂ«r infrastrukturĂ«n.
- NetOps â administratorĂ« rrjetesh
- SecOps â administratorĂ« sistemesh qĂ« specializohen nĂ« sigurinĂ« informacionit â pĂ«rputhja PCI, pĂ«rputhja CIS, patching, etj.
DevOps â (nĂ« teori) njĂ« person qĂ« jo vetĂ«m kupton tĂ« gjitha proceset e ciklit tĂ« zhvillimit â zhvillimin, testimin, arkitekturĂ«n e produktit, i cili Ă«shtĂ« nĂ« gjendje tĂ« vlerĂ«sojĂ« rreziqet e sigurisĂ«, i njohur me qasjet dhe mjetet e automatizimit, edhe nĂ« njĂ« nivel tĂ« lartĂ«, pĂ«rveç kĂ«saj, gjithashtu kupton mbĂ«shtetje paraprake dhe pas-lĂ«shimi tĂ« produktit. NjĂ« person qĂ« mund tĂ« veprojĂ« si avokat pĂ«r Operacionet dhe Zhvillimin, qĂ« lejon krijimin e njĂ« bashkĂ«punimi tĂ« favorshĂ«m mes kĂ«tyre dy kolonave. I njohur me proceset e planifikimit tĂ« punĂ«s nga ekipet dhe menaxhimin e pritshmĂ«rive tĂ« pĂ«rdoruesve.
PĂ«r tĂ« kryer njĂ« punĂ« dhe detyra tĂ« tilla, kjo personĂ« duhet tĂ« ketĂ« mjete pĂ«r tĂ« menaxhuar jo vetĂ«m proceset e zhvillimit dhe tĂ« testimit, por gjithashtu tĂ« menaxhojĂ« infrastrukturĂ«n e produktit dhe tĂ« planifikojĂ« burimet. DevOps nĂ« kĂ«tĂ« kuptim nuk mund tĂ« jetĂ« ndonjĂ«herĂ« nĂ« IT, as nĂ« R&D, as edhe nĂ« PMO; ai duhet tĂ« ketĂ« ndikim nĂ« tĂ« gjitha kĂ«to fusha â drejtor teknik i kompanisĂ«, Chief Technical Officer.
A Ă«shtĂ« kĂ«shtu nĂ« kompaninĂ« tuaj? â Kam dyshime. NĂ« shumicĂ«n e rasteve, ose Ă«shtĂ« IT, ose R&D.
Mungesa e mjeteve dhe mundĂ«sia pĂ«r tĂ« ndikuar edhe nĂ« njĂ« nga kĂ«to tre drejtime do tĂ« shkaktojĂ« njĂ« zhvendosje tĂ« peshĂ«s sĂ« problemeve nĂ« anĂ«n ku kĂ«to ndryshime janĂ« mĂ« tĂ« lehta pĂ«r t'u aplikuar, siç Ă«shtĂ«, pĂ«r shembull, aplikimi i kufizimeve teknike nĂ« lĂ«shimet nĂ« lidhje me "kodin e ndotur" sipas tĂ« dhĂ«nave tĂ« sistemeve tĂ« analizĂ«s statike. KĂ«shtu, kur PMO vendos njĂ« afat tĂ« fortĂ« pĂ«r lĂ«shimin e funksionalitetit, R&D nuk mund tĂ« japĂ« rezultat cilĂ«sor brenda kĂ«tyre afateve dhe e jep atĂ« ashtu si mundet, duke e lĂ«nĂ« rrefaktorimin pĂ«r mĂ« vonĂ«, DevOps, qĂ« lidhet me IT, me mjete teknike blokon lĂ«shimin. Mungesa e kompetencĂ«s pĂ«r tĂ« ndryshuar situatĂ«n, nĂ« rastin e punonjĂ«sve tĂ« pĂ«rgjegjshĂ«m, çon nĂ« manifestimin e hiper pĂ«rgjegjĂ«sisĂ« pĂ«r atĂ« qĂ« ata nuk mund tĂ« ndikojnĂ«, sidomos nĂ«se kĂ«ta punonjĂ«s e kuptojnĂ« dhe shohin gabimet, si dhe se si t'i korrektojnĂ« ato â "FatkeqĂ«sia nĂ« injorancĂ«", dhe si pasojĂ« tĂ« djegies dhe humbjes sĂ« kĂ«tyre punonjĂ«sve.
Tregu i burimeve DevOps
Le të shqyrtojmë disa vende pune për pozitat DevOps nga kompani të ndryshme.
Ne jemi të gatshëm të takohemi me ju, nëse ju:
- Keni njohuri mbi Zabbix dhe e dini se çfarë është Prometheus;
- Iptables;
- Asistent BASH;
- Profesor Ansible;
- Guru Linux;
- A keni aftësi për të përdorur debug dhe për të gjetur probleme në aplikacionet (php/java/python) në bashkëpunim me zhvilluesit;
- Routimi nuk ju shkakton panik;
- I kushtoni vëmendje të madhe sigurisë së sistemit;
- Bëni backup të "gjithçkaje", si dhe i riktheni me sukses "gjithçka";
- E keni aftësinë të konfiguroheni sistemin për të nxjerrë maksimumin nga minimumi;
- Konfiguroni replikimet përpara se të flini në Postgres dhe MySQL;
- Konfigurimi dhe rregullimi i CI/CD për ju është një domosdoshmëri si mëngjesi/dreka/darkë.
- Keni përvojë me AWS;
- Jeni të gatshëm të zhvilloheni së bashku me kompaninë;
Pra:
- nga 1 deri nĂ« 6 â administrator sistemi
- 7 â pak administrim rrjeti, qĂ« gjithashtu bĂ«n pjesĂ« nĂ« sistemin e adminit, nĂ« nivelin Middle
- 8 â pak siguri, qĂ« Ă«shtĂ« e domosdoshme pĂ«r administratorin e nivelit Middle
- 9-11 â Administratori Sistem Middle
- 12 â NĂ« varĂ«si tĂ« detyrave tĂ« caktuara ose Administrator Sistemi Middle, ose Build Engineer
- 13 â Virtualizimi â Administrator Sistemi Middle, ose ashtuquajtur CloudOps, njohuri tĂ« pĂ«rparuara pikĂ«risht mbi shĂ«rbimet e caktuara hosting platforma, pĂ«r pĂ«rdorimin efektiv tĂ« fondeve dhe reduktimin e ngarkesĂ«s nĂ« menaxhim
Përmbledhje për këtë pozitë, mund të thuhet se djemtë mjaftojnë si Administratore Sistemi të Nivelit Mesatar/Dhe të Lartë.
Në fakt, nuk duhet të ndahen shumë administratorët në Linux dhe Windows. Natyrisht, e kuptoj se shërbimet dhe sistemet e këtyre dy botëve ndryshojnë, por baza e të gjithave është një dhe çdo administrator që e respekton veten është i njohur si me njëra, ashtu edhe me tjetrën; madje, edhe nëse nuk është i njohur, për një administrator të aftë nuk do të jetë e vështirë të njohë këtë.
Le të shqyrtojmë një pozitat tjetër:
- Përvoja në ndërtimin e sistemeve të ngarkesës së lartë;
- Njohuri tĂ« shkĂ«lqyera tĂ« Sistemit Operativ LinuŃ , programeve tĂ« pĂ«rgjithshme dhe grumbullit web (Nginx, PHP/Python, HAProxy, MySQL/PostgreSQL, Memcached, Redis, RabbitMQ, ELK);
- Përvojë në punën me sisteme virtualizimi (KVM, VMWare, LXC/Docker);
- Aftësi në gjuhët e skriptimit;
- Kuptimi i principeve të punës së rrjeteve dhe protokolleve të rrjetit;
- Kuputimi i principeve të ndërtimit të sistemeve të qëndrueshme;
- Pavarësia dhe iniciativa;
Po shqyrtojmë:
- 1 â Administrator Sistemi i LartĂ«
- 2 â NĂ« varĂ«si tĂ« kuptimit qĂ« i jepet kĂ«tij stĂ«rvitje â Administrator Sistemi i Nivelit Mesatar/Dhe tĂ« LartĂ«
- 3 â Experienca, gjithashtu, mund tĂ« nĂ«nkuptojĂ« â "Nuk kam ngritur klaster, por kam krijuar dhe menaxhuar virtualka, kam pasur njĂ« host Docker, kam instaluar qasjet nĂ« kontejnerĂ«" â Administrator Sistemi i Nivelit Mesatar
- 4 â Administrator i Ri Junior â po, admini qĂ« nuk di tĂ« shkruajĂ« skripte elementare automatizimi, pavarĂ«sisht nga gjuha, nuk Ă«shtĂ« admin â Ă«shtĂ« njĂ« e thjesht.
- 5 â Administrator i Ri nĂ« Mes
- 6 â Administrator i LartĂ«
PĂ«rmbledhje â Administrator i MesĂ«m/Administrator i LartĂ«
Një tjetër:
- Eksperiencë në devops;
- Eksperiencë në përdorimin e një ose më shumë produkteve për formimin e proceseve CI/CD. Gitlab CI do të jetë një avantazh;
- Puna me kontejnerĂ« dhe virtualizim; NĂ«se keni pĂ«rdorur docker â mirĂ«, por nĂ«se k8s â shkĂ«lqyer!
- Eksperiencë në një ekip agile;
- Njohja e ndonjë gjuhe programimi;
Le të shohim:
- 1 â Hmm⊠ĂfarĂ« kanĂ« parasysh djemtĂ«? =) MĂ« shumĂ« se kaq, ndoshta ata vetĂ« nuk e dinĂ« se çfarĂ« fshihet pas kĂ«saj.
- 2 â Inxhinier i NdĂ«rtimit
- 3 â Administrator i Ri nĂ« Mes
- 4 â AftĂ«si tĂ« buta, pĂ«r momentin nuk do t'i shqyrtojmĂ«, megjithatĂ« Agile Ă«shtĂ« njĂ« gjĂ« tjetĂ«r qĂ« interpretohet ndryshe, sipas nevojĂ«s.
- 5 â ShumĂ« hapĂ«sirĂ« â mund tĂ« jetĂ« njĂ« gjuhĂ« skripti, ose njĂ« e kompilueshme. ĂshtĂ« interesante, a do tĂ« mjaftonte qĂ« kam shkruar nĂ« shkollĂ« nĂ« Pascal dhe Basic? =)
DĂ«shiroja gjithashtu tĂ« lija njĂ« vĂ«rejtje nĂ« lidhje me pikĂ«n 3, pĂ«r tĂ« forcuar kuptimin se pse kjo pikĂ« mbulohet nga administratorĂ«t e sistemeve. Kubernetes Ă«shtĂ« thjesht njĂ« orkestrim, njĂ« mjet qĂ« mbĂ«shtjell komandat direkte pĂ«r shoferĂ«t e rrjetit dhe hostĂ«t e virtualizimit/izolimit nĂ« disa komanda dhe lejon qĂ« komunikimi me ta tĂ« jetĂ« abstrakt, ky Ă«shtĂ« gjithçka. PĂ«r shembull, le tĂ« marrim 'framework' Make, tĂ« cilin unĂ«, pĂ«r fjalĂ«n, nuk e konsideroj si njĂ« framework. Po, e di pĂ«r modĂ«n pĂ«r ta futur Make kudo qĂ« duhet dhe nuk duhet â ta mbĂ«shtjellĂ«sh Maven nĂ« Make, pĂ«r shembull, seriozisht?
Në thelb, Make është thjesht një mbështjellës mbi shell, që thjeshton komandat e kompilimit, lidhjes, mjedisit të kompilimit, ashtu si i bën edhe k8s.
Një herë, intervistova një djalë që përdorte k8s në punën e tij mbi OpenStack, dhe ai tregonte se si vendoste shërbime mbi të, megjithatë, kur e pashë për OpenStack, doli se ajo administrontej, ashtu si dhe ngritej nga administratorët e sistemeve. A mendoni vërtet se ndonjë person që ngriti OpenStack, pavarësisht nga platforma që përdor prapa tij, është i paaftë të përdorë k8s? =)
Ky kyçës nuk është në të vërtetë një DevOps, por një Administrator Sistemi po ashtu dhe, për të qenë më të saktë, një Administrator Kubernetes.
TĂ« pĂ«rmbledhim pĂ«rsĂ«ri â njĂ« Administrator Sistemi Mesatar/Senior do t'i mjaftonte.
Sa gramësh duhet të peshojë.
Shkalla e pagave për pozitat e përmendura është 90k-200k.
Tani, do të doja të bëja një krahasim midis shpërblimeve monetare të Administratorëve të Sistemit dhe Inxhinierëve DevOps.
Në parim, për thjeshtim mund të përhapim gradat sipas përvojës, edhe pse kjo nuk do të jetë e saktë, për qëllimet e artikullit mjafton.
PĂ«rvoja:
- deri nĂ« 3 vjet â Junior
- deri nĂ« 6 vjet â Middle
- mĂ« shumĂ« se 6 vjet â Senior
Website-i për kërkimin e punonjësve ofron:
Administratorët e Sistemit:
- Junior â 2 vite â 50k lekĂ«
- Middle â 5 vite â 70k lekĂ«
- Senior â 11 vite â 100k lekĂ«
Inxhinierët DevOps:
- Junior â 2 vite â 100k lekĂ«
- Middle â 3 vite â 160k lekĂ«
- Senior â 6 vite â 220k lekĂ«
Për eksperiencën e 'DevOps' ka pasur përvoja, madje e cila prek SDLC ndonjëherë.
Nga e sa më sipër, del në përfundim se në të vërtetë kompanitë nuk kanë nevojë për DevOps, si dhe se ato do të kishin kursyer të paktën 50 përqind të shpenzimeve fillestare duke punësuar një Administratori. Mënyra se si ata mund të përcaktonin më qartë detyrat e personit që kërkojnë dhe të përmbushnin nevojat më shpejt. Nuk duhet harruar as që ndarja e qartë e përgjegjësive lejon të reduktohen kushtet për personelin dhe të krijohet një atmosferë më e favorshme në ekip, për shkak të mungesës së mbivendosjeve. Në shumicën dërrmuese, pozitat janë të mbushura me mjete dhe etiketa DevOps, megjithatë ato nuk kanë si bazë kërkesat e vërteta për DevOps Engineer, por kërkesa për një administrator të mjeteve.
Procesi i trajnimit të inxhinierëve DevOps është gjithashtu i kufizuar në një grup specifik punësh dhe utilitarëve, dhe nuk ofron një kuptim të përgjithshëm të proceseve dhe varësive të tyre. Natyrisht, është mirë që dikush mund të shfrytëzojë Terraform për të vendosur AWS EKS, në lidhje me Fluentd si sidecar në këtë klaster dhe me stakun AWS ELK për sistemin e logimeve brenda 10 minutash, duke përdorur vetëm një komandë në konsolë, por nëse ai nuk e kupton parimin e trajtimit të logeve dhe përse ato janë të nevojshme, nuk di të mbledhë metrika dhe të monitorojë degradimin e shërbimeve, atëherë ai do të jetë po ai enikey që di të përdorë disa utilitarë.
Megjithatë, kërkesa krijon ofertën dhe ne shikojmë një treg shumë të nxehtë për pozitat DevOps, ku kërkesat nuk përputhen me rolin real, por lejojnë adminstratorë sistemesh të fitojnë më shumë.
Pra, kush janë ata? DevOps-a apo administratori të mençur? =)
Si të vazhdojmë më tej?
Punëdhënësit - të formulojnë më qartë kërkesat dhe të kërkojnë pikërisht ata që janë të nevojshëm, e jo të shpërndajnë etiketa. Nëse nuk e dini se çfarë bëjnë DevOps-të, ata nuk ju nevojiten në këtë rast.
PunonjĂ«sit â TĂ« mĂ«sojnĂ«. TĂ« pĂ«rsosin vazhdimisht njohuritĂ« e tyre, tĂ« shikojnĂ« figurĂ«n e pĂ«rgjithshme tĂ« proceseve dhe tĂ« ndjekin rrugĂ«n drejt objektivave tĂ« vendosura. Mund tĂ« bĂ«hesh çfarĂ«do qĂ« dĂ«shiron, mjafton tĂ« pĂ«rpiqesh.
Burimi: habr.com
