Për momentin, ky është pothuajse pozicioni më i shtrenjtë në treg. Bujë rreth inxhinierëve "DevOps" është përtej çdo kufiri të imagjinueshëm, dhe akoma më keq me inxhinierët e lartë DevOps.
Unë punoj si shef i departamentit të integrimit dhe automatizimit, me mend deshifrimin në anglisht - DevOps Manager. Nuk ka gjasa që transkripti në anglisht të pasqyrojë aktivitetet tona të përditshme, por versioni rus në këtë rast është më i saktë. Për shkak të natyrës së aktivitetit tim, është e natyrshme që më duhet të intervistoj anëtarët e ardhshëm të ekipit tim, dhe gjatë vitit të kaluar, rreth 50 persona kanë kaluar përmes meje dhe po kaq janë ndërprerë në paraekran me punonjësit e mi.
Ne jemi ende në kërkim të kolegëve, sepse pas etiketës DevOps fshihet një shtresë shumë e madhe e llojeve të ndryshme inxhinierësh.
Gjithçka e shkruar më poshtë është mendimi im personal, ju nuk duhet të pajtoheni me të, por e pranoj se do t'i japë pak ngjyrë qëndrimit tuaj ndaj temës. Pavarësisht rrezikut për të rënë në favor, publikoj mendimin tim sepse besoj se ka ku të jetë.
Kompanitë kanë kuptime të ndryshme se cilët janë inxhinierët DevOps dhe, për hir të punësimit të shpejtë të një burimi, ata ia varin këtë etiketë të gjithëve. Situata është mjaft e çuditshme, pasi kompanitë janë gati të paguajnë shpërblime joreale për këta persona, duke marrë në shumicën e rasteve një administrator mjetesh për ta.
Pra, kush janë inxhinierët DevOps?
Le të fillojmë me historinë e shfaqjes së tij - Operacionet e Zhvillimit u shfaqën si një hap tjetër drejt optimizimit të ndërveprimit në ekipe të vogla për të rritur shpejtësinë e prodhimit të produktit, si pasojë e pritshme. Ideja ishte të forcohej ekipi i zhvillimit me njohuri për procedurat dhe qasjet në menaxhimin e mjedisit të produktit. Me fjalë të tjera, zhvilluesi duhet të kuptojë dhe të dijë se si funksionon produkti i tij në kushte të caktuara, duhet të kuptojë se si të vendosë produktin e tij, cilat karakteristika të mjedisit mund të rregullohen për të përmirësuar performancën. Pra, për ca kohë, u shfaqën zhvilluesit me një qasje DevOps. Zhvilluesit e DevOps shkruan skriptet e ndërtimit dhe paketimit për të thjeshtuar aktivitetet e tyre dhe performancën e mjedisit të prodhimit. Megjithatë, kompleksiteti i arkitekturës së zgjidhjes dhe ndikimi i ndërsjellë i komponentëve të infrastrukturës me kalimin e kohës filluan të përkeqësojnë performancën e mjediseve; me çdo përsëritje, kërkohej një kuptim gjithnjë e më i thellë i disa komponentëve, duke ulur produktivitetin e zhvilluesit për shkak të shtesës. kostot e të kuptuarit të komponentëve dhe sistemeve të akordimit për një detyrë specifike. Kostoja e vetë zhvilluesit u rrit, kostoja e produktit së bashku me të, kërkesat për zhvilluesit e rinj në ekip u hodhën ndjeshëm, sepse ata gjithashtu duhej të mbulonin përgjegjësitë e "yllit" të zhvillimit dhe, natyrisht, "yjet" u bënë më pak. dhe më pak në dispozicion. Vlen gjithashtu të theksohet se, në përvojën time, pak zhvillues janë të interesuar për specifikat e përpunimit të paketave nga kerneli i sistemit operativ, rregullat e kursimit të paketave dhe aspektet e sigurisë së hostit. Hapi logjik ishte tërheqja e një administratori të njohur me këtë dhe caktimi i përgjegjësive të ngjashme me të, gjë që, falë përvojës së tij, bëri të mundur arritjen e të njëjtëve tregues me një kosto më të ulët në krahasim me koston e një zhvillimi "yll". Administratorë të tillë u vendosën në një ekip dhe detyra e tij kryesore ishte të menaxhonte mjediset e testimit dhe prodhimit, sipas rregullave të një ekipi specifik, me burime të alokuara për këtë ekip të veçantë. Kështu u shfaq, në fakt, DevOps në mendjet e shumicës.
Pjesërisht ose plotësisht, me kalimin e kohës, këta administratorë të sistemit filluan të kuptojnë nevojat e këtij ekipi të veçantë në fushën e zhvillimit, si ta bëjnë jetën më të lehtë për zhvilluesit dhe testuesit, si të nxjerrin një përditësim dhe të mos qëndrojnë natën të premten në zyra, duke korrigjuar gabimet e vendosjes. Koha kaloi dhe tani "yjet" ishin administratorët e sistemit që e kuptonin atë që dëshironin zhvilluesit. Për të minimizuar ndikimin, filluan të shfaqen shërbimet e menaxhimit; të gjithë kujtuan metodat e vjetra dhe të besueshme të izolimit të nivelit të OS, të cilat bënë të mundur minimizimin e kërkesave për sigurinë, menaxhimin e pjesës së rrjetit dhe konfigurimin e hostit si një tërësi dhe, si rezultat, zvogëlojnë kërkesat për "yje" të rinj.
Është shfaqur një gjë "e mrekullueshme" - doker. Pse e mrekullueshme? Po, vetëm sepse krijimi i izolimit në një chroot ose burg, si dhe OpenVZ, kërkonte njohuri jo të parëndësishme të OS, në të kundërt, mjeti ju lejon të krijoni thjesht një mjedis të izoluar aplikacioni në një host të caktuar me gjithçka të nevojshme brenda dhe dorën përsëri mbi frenat e zhvillimit, dhe administratori i sistemit mund të menaxhojë vetëm me një host, duke siguruar sigurinë e tij dhe disponueshmërinë e lartë - një thjeshtim logjik. Por progresi nuk qëndron ende dhe sistemet përsëri po bëhen gjithnjë e më komplekse, ka gjithnjë e më shumë komponentë, një host nuk i plotëson më nevojat e sistemit dhe është e nevojshme të ndërtohen grupe, ne po kthehemi përsëri te administratorët e sistemit të cilët janë në gjendje të ndërtojë këto sisteme.
Cikli pas cikli shfaqen sisteme të ndryshme që thjeshtojnë zhvillimin dhe/ose administrimin, shfaqen sisteme orkestrimi, të cilat, derisa të keni nevojë të devijoni nga procesi standard, janë të lehta për t'u përdorur. Arkitektura e mikroshërbimit u shfaq gjithashtu me qëllim të thjeshtimit të gjithçkaje të përshkruar më sipër - më pak marrëdhënie, më të lehta për t'u menaxhuar. Në përvojën time, nuk gjeta një arkitekturë plotësisht mikroservice, do të thosha 50 deri në 50 - 50 për qind e mikroshërbimeve, kuti të zeza, hynë, dolën të përpunuara, 50 të tjerat janë një monolit i grisur, shërbime të paaftë për të punuar veçmas nga të tjerët. komponentët. E gjithë kjo përsëri vendosi kufizime në nivelin e njohurive si të zhvilluesve ashtu edhe të administratorëve.
"Lëkundje" të ngjashme në nivelin e njohurive të ekspertëve të një burimi të caktuar vazhdojnë edhe sot e kësaj dite. Por ne largohemi pak, ka shumë pika që ia vlen të theksohen.
Inxhinier ndërtimi/Inxhinier lëshimi
Inxhinierë shumë të specializuar që u shfaqën si një mjet për standardizimin e proceseve të ndërtimit dhe lëshimeve të softuerit. Në procesin e prezantimit të Agile të përhapur, duket se ato pushuan së kërkuari, por kjo është larg nga rasti. Ky specializim u shfaq si një mjet për standardizimin e montimit dhe dërgimit të softuerit në shkallë industriale, d.m.th. duke përdorur teknika standarde për të gjitha produktet e kompanisë. Me ardhjen e DevOps, zhvilluesit humbën pjesërisht funksionet e tyre, pasi ishin zhvilluesit ata që filluan të përgatisin produktin për dorëzim, dhe duke pasur parasysh ndryshimin e infrastrukturës dhe qasjen për të ofruar sa më shpejt të jetë e mundur pa marrë parasysh cilësinë, me kalimin e kohës ata u shndërruan në një ndalues i ndryshimeve, pasi respektimi i standardeve të cilësisë në mënyrë të pashmangshme ngadalëson dërgesat. Pra, gradualisht, një pjesë e funksionalitetit të inxhinierëve Build/Release migroi në supet e administratorëve të sistemit.
Operacionet janë kaq të ndryshme
Vazhdojmë dhe përsëri prania e një game të madhe përgjegjësish dhe mungesa e personelit të kualifikuar na shtyn drejt specializimit të rreptë, si kërpudhat pas shiut, shfaqen Operacione të ndryshme:
- TechOps - administratorët e sistemit enikey i njohur si HelpDesk Engineer
- LiveOps - administratorët e sistemit janë kryesisht përgjegjës për mjediset e prodhimit
- CloudOps - administratorë të sistemit të specializuar në retë publike Azure, AWS, GCP, etj.
- PlatOps/InfraOps/SysOps - administratorë të sistemit të infrastrukturës.
- NetOps - administratorët e rrjetit
- SecOps - administratorë të sistemit të specializuar në sigurinë e informacionit - pajtueshmëria me PCI, pajtueshmëria me CIS, korrigjimi, etj.
DevOps është (teorikisht) një person që kupton nga dora e parë të gjitha proceset e ciklit të zhvillimit - zhvillimi, testimi, kupton arkitekturën e produktit, është në gjendje të vlerësojë rreziqet e sigurisë, është i njohur me qasjet dhe mjetet e automatizimit, të paktën në një nivel të lartë. niveli, përveç kësaj, kupton edhe mbështetjen e përpunimit para dhe pas përpunimit. Një person i aftë për të vepruar si avokat si për Operacionet ashtu edhe për Zhvillimin, gjë që lejon një bashkëpunim të favorshëm midis këtyre dy shtyllave. Kupton proceset e planifikimit të punës nga ekipet dhe menaxhimin e pritjeve të klientëve.
Për të kryer këtë lloj pune dhe përgjegjësish, ky person duhet të ketë mjetet për të menaxhuar jo vetëm proceset e zhvillimit dhe testimit, por edhe menaxhimin e infrastrukturës së produktit, si dhe planifikimin e burimeve. DevOps në këtë kuptim nuk mund të gjendet as në IT, as në R&D, apo edhe në PMO; ai duhet të ketë ndikim në të gjitha këto fusha - drejtori teknik i kompanisë, Shefi Teknik.
A është e vërtetë kjo në kompaninë tuaj? - Dyshoj. Në shumicën e rasteve, kjo është ose IT ose R&D.
Mungesa e fondeve dhe aftësia për të ndikuar të paktën një nga këto tre fusha të aktivitetit do të zhvendosë peshën e problemeve drejt vendeve ku këto ndryshime janë më të lehta për t'u zbatuar, si p.sh. aplikimi i kufizimeve teknike për lëshimet në lidhje me kodin "të pistë" sipas statikës. sistemet e analizuesve. Kjo do të thotë, kur PMO vendos një afat të rreptë për lëshimin e funksionalitetit, R&D nuk mund të prodhojë një rezultat me cilësi të lartë brenda këtyre afateve dhe e prodhon atë sa më mirë që mundet, duke e lënë rifaktorimin për më vonë, DevOps që lidhen me IT bllokojnë lëshimin me mjete teknike . Mungesa e autoritetit për të ndryshuar situatën, në rastin e punonjësve të përgjegjshëm, çon në shfaqjen e hiperpërgjegjësisë për atë që ata nuk mund të ndikojnë, veçanërisht nëse këta punonjës i kuptojnë dhe shohin gabimet dhe si t'i korrigjojnë ato - "Lumturia është injoranca". dhe si pasojë e djegies dhe humbjes së këtyre punonjësve.
Tregu i burimeve DevOps
Le të shohim disa vende të lira pune për pozicione DevOps nga kompani të ndryshme.
Ne jemi të gatshëm të takohemi me ju nëse:
- Ju zotëroni Zabbix dhe e dini se çfarë është Prometeu;
- Iptables;
- Student i doktoraturës BASH;
- Profesor Ansible;
- Linux Guru;
- Të dijë të përdorë korrigjimin dhe të gjejë problemet e aplikacionit së bashku me zhvilluesit (php/java/python);
- Rruga nuk ju bën histerikë;
- Kushtojini vëmendje të madhe sigurisë së sistemit;
- Rezervoni "çdo gjë dhe gjithçka" dhe gjithashtu rivendosni me sukses këtë "çdo gjë dhe gjithçka";
- Ju e dini se si ta konfiguroni sistemin në mënyrë të tillë që të merrni maksimumin nga minimumi;
- Vendosni replikimin përpara se të shkoni në shtrat në Postgres dhe MySQL;
- Vendosja dhe rregullimi i CI/CD është po aq i nevojshëm për ju sa mëngjesi/dreka/darka.
- Të ketë përvojë me AWS;
- Gati për t'u zhvilluar me kompaninë;
Pra:
- nga 1 në 6 - administratori i sistemit
- 7 - një administrim i vogël i rrjetit, i cili gjithashtu përshtatet në administratorin e sistemit, niveli i mesëm
- 8 - pak siguri, e cila është e detyrueshme për një administrator të sistemit të nivelit të mesëm
- 9-11 – Administratori i Sistemit të Mesëm
- 12 — Në varësi të detyrave të caktuara, ose Administratori i Sistemit të Mesëm ose Inxhinieri i Ndërtimit
- 13 - Virtualizimi - Administratori i Sistemit të Mesëm, ose i ashtuquajturi CloudOps, njohuri të avancuara të shërbimeve të një siti specifik pritës, për përdorimin efikas të fondeve dhe uljen e ngarkesës në mirëmbajtje
Duke përmbledhur këtë vend vakant, mund të themi se administratori i mesëm/i lartë i sistemit është i mjaftueshëm për djemtë.
Nga rruga, nuk duhet t'i ndani fort administratorët në Linux/Windows. Sigurisht, e kuptoj që shërbimet dhe sistemet e këtyre dy botëve janë të ndryshme, por baza për të gjithë është e njëjtë dhe çdo administrator që respekton veten është i njohur si me njërin ashtu edhe me tjetrin, dhe edhe nëse nuk është i njohur, do nuk është e vështirë për një administrator kompetent të njihet me të.
Le të shqyrtojmë një vend tjetër vakant:
- Përvojë në ndërtimin e sistemeve me ngarkesë të lartë;
- Njohuri të shkëlqyera të Linux OS, softuerit të përgjithshëm të sistemit dhe web stack (Nginx, PHP/Python, HAProxy, MySQL/PostgreSQL, Memcached, Redis, RabbitMQ, ELK);
- Eksperiencë me sistemet e virtualizimit (KVM, VMWare, LXC/Docker);
- Aftësi në gjuhët e shkrimit;
- Kuptimi i parimeve të funksionimit të rrjeteve të protokolleve të rrjetit;
- Kuptimi i parimeve të ndërtimit të sistemeve tolerante ndaj gabimeve;
- Pavarësia dhe iniciativa;
Le të shohim:
- 1 – Administrator i lartë i sistemit
- 2 - Në varësi të kuptimit të vendosur në këtë pirg - Administratori i mesëm/i lartë i sistemit
- 3 - Përvoja e punës, duke përfshirë, mund të nënkuptojë - "Klasteri nuk ngriti, por krijoi dhe menaxhoi makina virtuale, kishte një host Docker, qasja në kontejnerë nuk ishte e disponueshme" - Administratori i Sistemit të Mesëm
- 4 - Administrator i ri i sistemit - po, një administrator që nuk di të shkruajë skriptet bazë të automatizimit, pavarësisht nga gjuha, jo një administrator - enikey.
- 5 - Administrator i sistemit të mesëm
- 6 – Administrator i lartë i sistemit
Për ta përmbledhur - Administrator i mesëm/i lartë i sistemit
Nje tjeter:
- Përvoja e zhvillimit;
- Përvojë në përdorimin e një ose më shumë produkteve për të krijuar procese CI/CD. Gitlab CI do të jetë një avantazh;
- Puna me kontejnerë dhe virtualizimi; Nëse keni përdorur docker, mirë, por nëse keni përdorur k8s, shkëlqyeshëm!
- Përvojë pune në një ekip të shkathët;
- Njohuri të çdo gjuhe programimi;
Le të shohim:
- 1 - Hmm... Çfarë duan të thonë djemtë? =) Me shumë mundësi ata vetë nuk e dinë se çfarë fshihet pas saj
- 2 - Inxhinier ndërtimi
- 3 - Administrator i sistemit të mesëm
- 4 - Shkathtësi e butë, nuk do ta konsiderojmë tani për tani, megjithëse Agile është një tjetër gjë që interpretohet në një mënyrë të përshtatshme.
- 5 - Shumë e folur - mund të jetë një gjuhë shkrimi ose e përpiluar. Pyes veten nëse shkrimi në Pascal dhe Basic në shkollë do t'u përshtatet atyre? =)
Gjithashtu do të doja të lë një shënim në lidhje me pikën 3 për të forcuar të kuptuarit se pse kjo pikë mbulohet nga administratori i sistemit. Kubernetes është thjesht një orkestrim, një mjet që mbështjell komandat e drejtpërdrejta me drejtuesit e rrjetit dhe hostet e virtualizimit/izolimit në disa komanda dhe ju lejon të bëni komunikimin me ta abstrakt, kjo është e gjitha. Për shembull, le të marrim "ndërtimin e kornizës" Make, të cilën, meqë ra fjala, nuk e konsideroj kornizë. Po, unë e di për modën e shtytjes së Make kudo, ku është e nevojshme dhe jo e nevojshme - duke e mbështjellë Maven në Make, për shembull, seriozisht?
Në thelb, Make është vetëm një mbështjellës mbi guaskën, duke thjeshtuar komandat e përpilimit, lidhjes dhe mjedisit të përpilimit, ashtu si k8s.
Një herë, intervistova një djalë që përdorte k8 në punën e tij në krye të OpenStack, dhe ai foli për mënyrën sesi vendosi shërbimet në të, megjithatë, kur pyeta për OpenStack, doli që ai ishte administruar, si dhe u ngrit nga sistemi administratorët. A mendoni vërtet se një person që ka instaluar OpenStack, pavarësisht se çfarë platforme përdor pas tij, nuk është në gjendje të përdorë k8s? =)
Ky aplikant nuk është në fakt një DevOps, por një Administrator i Sistemit dhe, për të qenë më i saktë, një Administrator Kubernetes.
Le të përmbledhim edhe një herë - Administratori i mesëm/i lartë i sistemit do të jetë i mjaftueshëm për ta.
Sa të peshoni në gram
Gama e pagave të propozuara për vendet e lira të treguara është 90k-200k
Tani do të doja të bëja një paralele midis shpërblimeve monetare të Administratorëve të Sistemit dhe Inxhinierëve DevOps.
Në parim, për të thjeshtuar gjërat, mund të shpërndani notat në bazë të përvojës së punës, megjithëse kjo nuk do të jetë e saktë, por për qëllimet e artikullit do të mjaftojë.
Një eksperiencë:
- deri në 3 vjet - Junior
- deri në 6 vjeç – e mesme
- më shumë se 6 – Senior
Faqja e kërkimit të punonjësve ofron:
Administratorët e sistemit:
- Junior - 2 vjet - 50k fshij.
- E mesme - 5 vjet - 70 mijë fshij.
- I moshuar - 11 vjeç - 100 mijë fshij.
Inxhinierët DevOps:
- Junior - 2 vjet - 100k fshij.
- E mesme - 3 vjet - 160 mijë fshij.
- I moshuar - 6 vjeç - 220 mijë fshij.
Sipas përvojës së "DevOps", u përdor përvoja që të paktën ndikoi disi në SDLC.
Nga sa më sipër rezulton se në fakt kompanitë nuk kanë nevojë për DevOps dhe gjithashtu se mund të kursejnë të paktën 50 për qind të kostove të planifikuara fillimisht duke punësuar një Administrator; për më tepër, ato mund të përcaktojnë më qartë përgjegjësitë e personit që kërkojnë. dhe plotësoni nevojën më shpejt. Gjithashtu nuk duhet të harrojmë se një ndarje e qartë e përgjegjësive na lejon të reduktojmë kërkesat për personel, si dhe të krijojmë një atmosferë më të favorshme në ekip, për shkak të mungesës së mbivendosjeve. Shumica dërrmuese e vendeve të lira janë plot me shërbime komunale dhe etiketa DevOps, por ato nuk bazohen në kërkesat aktuale për një Inxhinier DevOps, por vetëm në kërkesat për një administrator mjeti.
Procesi i trajnimit të inxhinierëve DevOps është gjithashtu i kufizuar vetëm në një sërë punimesh, shërbimesh specifike dhe nuk ofron një kuptim të përgjithshëm të proceseve dhe varësive të tyre. Është padyshim mirë kur një person mund të vendosë AWS EKS duke përdorur Terraform, në lidhje me kartën anësore Fluentd në këtë grup dhe pirgun AWS ELK për sistemin e regjistrimit në 10 minuta, duke përdorur vetëm një komandë në tastierë, por nëse ai nuk e kupton parimi i përpunimit të vetë regjistrave dhe për çfarë nevojiten ato, nëse nuk dini si të grumbulloni metrikë mbi to dhe të gjurmoni degradimin e shërbimit, atëherë do të jetë ende i njëjti enikey që di të përdorë disa shërbime.
Kërkesa, megjithatë, krijon ofertë dhe ne shohim një treg jashtëzakonisht të mbinxehur për pozicionin DevOps, ku kërkesat nuk korrespondojnë me rolin aktual, por vetëm lejojnë administratorët e sistemit të fitojnë më shumë.
Pra kush janë ata? DevOps apo administratorë të pangopur të sistemit? =)
Si të vazhdoni të jetoni?
Punëdhënësit duhet të formulojnë kërkesat më saktë dhe të kërkojnë pikërisht ata që nevojiten, dhe jo të hedhin etiketa. Ju nuk e dini se çfarë bëjnë DevOps - nuk keni nevojë për to në atë rast.
Punëtorët - Mësoni. Përmirësoni vazhdimisht njohuritë tuaja, shikoni pamjen e përgjithshme të proceseve dhe ndiqni rrugën drejt qëllimit tuaj. Mund të bëhesh kush të duash, thjesht duhet të provosh.
Burimi: www.habr.com