Aktualisht, kjo Ă«shtĂ« ndoshta pozita mĂ« e shtrenjtĂ« nĂ« treg. Zhurma rreth inxhinierĂ«ve âDevOpsâ tejkalon çdo limit tĂ« imagjinueshĂ«m, veçanĂ«risht pĂ«r inxhinierĂ«t Senior DevOps.
UnĂ« punoj si drejtues i departamentit tĂ« integrimit dhe automatizimit, e dini pĂ«rkthimin nĂ« anglisht â DevOps Manager. A e pasqyron pĂ«rkthimi anglisht atĂ« qĂ« bĂ«jmĂ« çdo ditĂ«? Ka shumĂ« tĂ« ngjarĂ« qĂ« jo, ndĂ«rsa versioni nĂ« rusisht Ă«shtĂ« mĂ« i saktĂ« nĂ« kĂ«tĂ« rast. PĂ«r shkak tĂ« punĂ«s sime, Ă«shtĂ« e natyrshme qĂ« tĂ« intervistoj anĂ«tarĂ«t e ardhshĂ«m tĂ« ekipit tim, dhe gjatĂ« vitit tĂ« kaluar, rreth 50 persona kanĂ« kaluar pĂ«rmes meje, ndĂ«rsa njĂ« numĂ«r i ngjashĂ«m Ă«shtĂ« pĂ«rjashtuar gjatĂ« intervistave me punonjĂ«sit e mi.
Ne akoma jemi duke kërkuar kolegë, sepse mbrapa etiketës DevOps fshihet një përbërje shumë e madhe e inxhinierëve të ndryshëm.
Ădo gjĂ« e shkruar mĂ« poshtĂ« Ă«shtĂ« mendimi im personal, ju nuk jeni tĂ« detyruar tĂ« pajtoheni me tĂ«, por pranoj se mund tĂ« sjellĂ« njĂ« nuancĂ« nĂ« qĂ«ndrim tuajin ndaj temĂ«s. PavarĂ«sisht rrezikut pĂ«r t'u gjendur nĂ« njĂ« situatĂ« tĂ« pakĂ«ndshme, unĂ« publikoj mendimin tim, pasi besoj se ka vend pĂ«r tĂ«.
Kompani të ndryshme e kuptojnë ndryshe se kush janë inxhinierët DevOps dhe për të punësuar shpejt një burim, ata vendosin këtë etiketë për të gjithë. Situata është mjaft e çuditshme, pasi kompanitë janë të gatshme të paguajnë shpërblime të pabesueshme për këta njerëz, duke marrë në shumicën e rasteve vetëm një administrator-inxhinier.
Pra, kush janë inxhinierët DevOps?
Le tĂ« fillojmĂ« me historinĂ« e shfaqjes â Development Operations u shfaq si njĂ« hap tjetĂ«r drejt optimizimit tĂ« bashkĂ«punimit nĂ« ekipet e vogla pĂ«r tĂ« rritur shpejtĂ«sinĂ« e prodhimit tĂ« produktit, si njĂ« pasojĂ« e pritur. Ideja ishte tĂ« forcohej ekipi i zhvillimit me njohuritĂ« mbi procedurat dhe qasjet nĂ« menaxhimin e mjedisit tĂ« produktit. NĂ« other fjalĂ«, njĂ« zhvillues duhet tĂ« kuptojĂ« dhe tĂ« dijĂ« se si funksionon produkti i tij nĂ« kushte tĂ« caktuara, duhet tĂ« dijĂ« si ta deploje atĂ«, cilat karakteristika tĂ« mjedisit tĂ« rregullojĂ« pĂ«r tĂ« rritur performancĂ«n. KĂ«shtu, brenda njĂ« periudhe, u shfaqĂ«n zhvillues tĂ« qasjes DevOps. Zhvilluesit DevOps shkruanin skenarĂ« pĂ«r ndĂ«rtimin dhe paketimin pĂ«r tĂ« lehtĂ«suar aktivitetet e tyre dhe funksionimin e mjedisit produktiv. MegjithatĂ«, kompleksiteti i arkitekturĂ«s sĂ« zgjidhjeve dhe ndikimi i ndĂ«rsjellĂ« i komponenteve tĂ« infrastrukturĂ«s me kalimin e kohĂ«s filloi tĂ« pĂ«rkeqĂ«sojĂ« treguesit e punĂ«s, dhe me çdo iteracion kĂ«rkoheshin kuptime gjithnjĂ« e mĂ« tĂ« thella tĂ« disa komponentĂ«ve, duke zvogĂ«luar produktivitetin e zhvilluesve pĂ«r shkak tĂ« shpenzimeve shtesĂ« pĂ«r tĂ« kuptuar komponentĂ«t dhe pĂ«r tĂ« rregulluar sistemet pĂ«r njĂ« detyrĂ« tĂ« caktuar. Kostoja e zhvilluesit po rritej, kostoja e produktit po rritej me tĂ«, kĂ«rkesat pĂ«r zhvillues tĂ« rinj nĂ« ekip po rriteshin ndjeshĂ«m, sepse ata duhej gjithashtu tĂ« mbulonin detyrat e "yjeve" tĂ« zhvillimit dhe natyrisht, "yjet" po bĂ«heshin gjithnjĂ« e mĂ« pak tĂ« arritshĂ«m. Gjithashtu, duhet tĂ« theksohet se, sipas pĂ«rvojĂ«s sime, pak nga zhvilluesit janĂ« tĂ« interesuar pĂ«r specifikat e trajtimit tĂ« pakove nga bĂ«rthama e sistemit operativ, rregullat e rrugĂ«timit tĂ« pakove, aspektet e sigurisĂ« sĂ« hostit. Hapi logjik ishte tĂ« tĂ«rhiqej njĂ« administrator, i cili ishte i njohur me kĂ«tĂ« dhe tâi ngarkohej atij detyra tĂ« tilla, qĂ«, falĂ« pĂ«rvojĂ«s sĂ« tij, ndihmoi nĂ« arritjen e tĂ« njĂ«jtave tregues me kosto mĂ« tĂ« ulĂ«t nĂ« krahasim me koston e "yjeve" tĂ« zhvillimit. KĂ«ta administratores vendoseshin nĂ« ekip dhe detyra kryesore e tij ishte menaxhimi i mjediseve testuese dhe produktive, sipas rregullave tĂ« ekipit tĂ« caktuar, me burimet e dedikuara pĂ«r kĂ«tĂ« ekip. KĂ«shtu, nĂ« thelb, u shfaqĂ«n DevOps nĂ« perceptimin e shumicĂ«s.
Pjesërisht ose plotësisht, me kalimin e kohës, këta administrues sistemesh filluan të kuptojnë nevojat e kësaj skuadre specifike në fushën e zhvillimit, si t'u lehtësojnë jetën zhvilluesve dhe testuesve, si të nxjerrin një përditësim dhe të mos mbesin natën të premten në zyrë duke rregulluar gabimet e shpërndarjes. Koha kaloi, tani "yjet" ishin administruesit e sistemeve që kuptonin se çfarë donin zhvilluesit. Me qëllim minimizimin e ndikimeve filluan të ndihmoheshin nga utilitetet e menaxhimit, të gjithë kujtuan metodat e vjetra dhe të besueshme të izolimit në nivelin e OS, të cilat lejonin të minimizoheshin kërkesat për siguri, menaxhimin e pjesës rrjet dhe, në përgjithësi, konfigurimin e hostit dhe, si rezultat, të ulnin kërkesat për "yjet" e rinj.
U shfaq njĂ« "gjĂ« e bukur" â docker. Pse e bukur? Sepse krijimi i izolimit nĂ« chroot ose jail, ashtu si OpenVZ, kĂ«rkonte njohuri tĂ« ndĂ«rlikuara mbi OS-nĂ«, ndĂ«rsa utiliteti nĂ« kontur lejonte tĂ« krijohej lehtĂ«sisht njĂ« ambient i izoluar aplikacionesh nĂ« njĂ« host me gjithçka tĂ« nevojshme brenda dhe tĂ« rikthehej autoriteti nĂ« zhvillim pĂ«rsĂ«ri, ndĂ«rsa administruesi i sistemit menaxhonte vetĂ«m njĂ« host, duke siguruar sigurinĂ« dhe disponueshmĂ«rinĂ« e lartĂ« â njĂ« thjeshtim logjik. Por pĂ«rparimi nuk ndalet dhe sistemet pĂ«rsĂ«ri bĂ«hen gjithnjĂ« e mĂ« tĂ« komplikuara, komponentĂ«t gjithnjĂ« e mĂ« tĂ« shumtĂ«, njĂ« host tashmĂ« nuk i pĂ«rmbush nevojat e sistemit dhe Ă«shtĂ« e nevojshme tĂ« ndĂ«rtohen klasterĂ«, ne kthehemi pĂ«rsĂ«ri te administruesit e sistemeve qĂ« janĂ« tĂ« aftĂ« tĂ« ndĂ«rtojnĂ« kĂ«to sisteme.
Cikli pas cikli, shfaqen sisteme tĂ« ndryshme qĂ« lehtĂ«sojnĂ« zhvillimin dhe/ose administrimin, shfaqen sisteme orkestrimi, tĂ« cilat, deri nĂ« momentin kur kĂ«rkohet tĂ« largohemi nga procesi standard, janĂ« tĂ« lehta pĂ«r t'u pĂ«rdorur. Arkitektura mikroshĂ«rbimeve gjithashtu u shfaq me qĂ«llimin e thjeshtimit tĂ« gjithçkaje tĂ« pĂ«rmendur mĂ« sipĂ«r â mĂ« pak lidhje, mĂ« e thjeshtĂ« pĂ«r menaxhim. NĂ« pĂ«rvojĂ«n time nuk kam pĂ«rjetuar plotĂ«sisht arkitekturĂ«n mikroshĂ«rbimeve, do ta quaja 50 me 50 â 50 pĂ«r qind mikroshĂ«rbime, kutitĂ« e zeza, erdhĂ«n tĂ« dhĂ«na, dolĂ«n tĂ« pĂ«rpunuara, 50 tĂ« tjerĂ« â njĂ« monolit i shkatĂ«rruar, shĂ«rbime qĂ« nuk ishin nĂ« gjendje tĂ« punonin tĂ« ndara nga komponentĂ«t e tjerĂ«. TĂ« gjitha kĂ«to pĂ«rsĂ«ri ka vĂ«nĂ« kufizime nĂ« nivelin e njohurive si tĂ« zhvilluesve ashtu dhe tĂ« administratorĂ«ve.
Të ngjashmet "lëvizia" të nivelit të njohurive ekspertëve për një burim të caktuar vazhdojnë edhe sot. Por ne u shpërndamë pak, ka shumë aspekte që meritojnë të shqyrtohen.
Inxhinier Ndërtimi/Inxhinier Shpërndarjeje
Inxhinierët e specializuar shumë ngushtë, që u shfaqën si një mjet për standardizimin e proceseve të ndërtimit të softuerit dhe shpërndarjeve të tij. Në procesin e futjes së Agile-it në masë, ata duken se humbën rëndësinë, megjithatë, kjo nuk është aspak e vërtetë. Kjo specializim u shfaq si mjet për standardizimin e ndërtimit dhe shpërndarjes së softuerit në shkallë industriale, domethënë, duke përdorur teknika standarde për të gjitha produktet e kompanisë. Me shfaqjen e DevOps, zhvilluesit humbën pjesërisht funksionet, pasi që ata filluan të përgatisnin produktin për shpërndarje, dhe duke marrë parasysh infrastrukturën e ndryshueshme dhe qasjen për shpërndarje sa më të shpejtë pa u marrë parasysh cilësia, me kalimin e kohës ata u kthyen në bllokues të ndryshimeve, pasi ndjekja e standardeve të cilësisë pa dyshim ngadalëson shpërndarjet. Kështu, gradualisht, një pjesë e funksionalitetit të inxhinierëve të Ndërtimit/Spërndarjes kaloi në duar të administruesve të sistemeve.
Ops-të kaq të ndryshme
Ne po e vazhdojmë rrugën dhe përsëri prania e një diapazoni të gjerë detyrash dhe mungesa e kuadrove të kualifikuara na shtyjnë në një specializim të fortë, ashtu si kërpudhat pas shiut, po shfaqen operacione të ndryshme:
- TechOps â administrues sistemesh, e njohur si Inxhinier i NdihmĂ«s
- LiveOps â administrues sistemesh, kryesisht pĂ«rgjegjĂ«s pĂ«r ambientet produktive
- CloudOps â administrues sistemesh qĂ« specializohen nĂ« âretĂ«â publike Azure, AWS, GCP, etj.
- PlatOps/InfraOps/SysOps â administrues tĂ« infrastrukturĂ«s.
- NetOps â administrues rrjetesh
- SecOps â administrues sistemesh qĂ« specializohen nĂ« sigurinĂ« e informacionit â pĂ«rputhshmĂ«ria PCI, pĂ«rputhshmĂ«ria CIS, patching, etj.
DevOps â (nĂ« teori) Ă«shtĂ« njĂ« person qĂ« e kupton thellĂ«sisht tĂ« gjitha proceset e ciklit tĂ« zhvillimit â zhvillimin, testimin, e kupton arkitekturĂ«n e produktit, Ă«shtĂ« nĂ« gjendje tĂ« vlerĂ«sojĂ« rreziqet e sigurisĂ« dhe Ă«shtĂ« njohĂ«s i qasjeve dhe mjeteve tĂ« automatizimit, tĂ« paktĂ«n nĂ« njĂ« nivel tĂ« lartĂ«, pĂ«rveç kĂ«saj, kupton gjithashtu mbĂ«shtetje para dhe pas lançimit tĂ« produktit. ĂshtĂ« njĂ« person qĂ« mund tĂ« veprojĂ« si avokat i tĂ« dyja grupeve, Operations dhe Development, qĂ« lejon ndĂ«rtimin e njĂ« bashkĂ«punimi tĂ« favorshĂ«m midis kĂ«tyre dy pilarĂ«ve. E kupton proceset e planifikimit tĂ« punĂ«ve nga ekipet dhe menaxhimin e pritshmĂ«rive tĂ« klientĂ«ve.
PĂ«r tĂ« kryer kĂ«tĂ« lloj pune dhe detyrash, ky person duhet tĂ« ketĂ« mjete pĂ«r menaxhimin jo vetĂ«m tĂ« proceseve tĂ« zhvillimit dhe testimit, por edhe tĂ« menaxhimit tĂ« infrastrukturĂ«s sĂ« produktit dhe planifikimit tĂ« burimeve. DevOps nĂ« kĂ«tĂ« kuptim nuk mund tĂ« jetĂ« as nĂ« IT, as nĂ« R&D, as 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, kjo Ă«shtĂ« ose IT ose R&D.
Mungesa e mjeteve dhe mundĂ«sisĂ« sĂ« ndikimit nĂ« tĂ« paktĂ«n njĂ« nga kĂ«to tri drejtime tĂ« veprimit do tĂ« prodhojĂ« njĂ« zhvendosje tĂ« peshĂ«s sĂ« problemeve nĂ« ato vende ku kĂ«to ndryshime janĂ« mĂ« tĂ« thjeshta pĂ«r t'u aplikuar, si pĂ«r shembull, aplikimi i kufizimeve teknike nĂ« lansime nĂ« lidhje me "kodin e papastĂ«r" sipas tĂ« dhĂ«nave tĂ« sistemeve tĂ« analizĂ«s statike. Kjo do tĂ« thotĂ« se kur PMO vendos njĂ« afat tĂ« ngushtĂ« pĂ«r publikimin e funksionalitetit, R&D nuk mund tĂ« ofrojĂ« njĂ« rezultat tĂ« kualitetit brenda kĂ«tyre afateve dhe e dorĂ«zon atĂ« si mundet, duke lĂ«nĂ« refaktorizimin pĂ«r mĂ« vonĂ«, DevOps qĂ« i pĂ«rket IT, me anĂ« tĂ« mjeteve teknike e bllokon lançimin. Mungesa e autoriteteve pĂ«r tĂ« ndryshuar situatĂ«n, nĂ« rastin e punonjĂ«sve tĂ« pĂ«rgjegjshĂ«m, çon nĂ« manifestimin e hiper-ndĂ«rgjegjĂ«simit pĂ«r atĂ« qĂ« ata nuk mund tĂ« ndikojnĂ«, veçanĂ«risht nĂ«se kĂ«ta punonjĂ«s kuptojnĂ« dhe shohin gabimet dhe si t'i korrigjojnĂ« ato â "Liria Ă«shtĂ« nĂ« paditur", dhe si pasojĂ« e kĂ«saj Ă«shtĂ« djegia dhe humbja e kĂ«tyre punonjĂ«sve.
Tregu i burimeve DevOps
Le të shqyrtojmë disa mundësi punësimi për pozita DevOps nga kompani të ndryshme.
Ne jemi të gatshëm të takojmë me ju, nëse ju:
- Dini Zabbix dhe e dini se çfarë është Prometheus;
- Iptables;
- Aspirant BASH;
- Profesor Ansible;
- Guru Linux;
- Aftoni në debug dhe bashkë me zhvilluesit të gjeni problemet e aplikacioneve (php/java/python);
- Routingu nuk ju shkakton panik;
- I kushtoni rëndësi të madhe sigurisë së sistemit;
- Bëni kopje rezervë të "gjithçkaje", si dhe rikuperoni me sukses "gjithçkaje";
- Dini ta konfiguroni sistemin në mënyrë që të shkarkoni maksimumin nga minimumi;
- Konfiguroni replikimet para se të flini në Postgres dhe MySQL;
- Konfigurimi dhe rregullimi i CI/CD është një nevojë për ju si mëngjes/drekë/darkë.
- Keni përvojë pune me AWS;
- Jeni të gatshëm të zhvilloheni së bashku me kompaninë;
Pra:
- nga 1 deri nĂ« 6 â administrator sistemi
- 7 â pak menaxhim rrjetesh, qĂ« gjithashtu pĂ«rfshihet nĂ« rolin e administratorit, nivelit tĂ« mesĂ«m
- 8 â pak siguri, qĂ« Ă«shtĂ« e domosdoshme pĂ«r administratorin e nivelit tĂ« mesĂ«m
- 9-11 â Administrator Sistemi i Nivelit tĂ« MesĂ«m
- 12 â NĂ« varĂ«si tĂ« detyrave tĂ« vendosura, ose Administrator Sistemi i Nivelit tĂ« MesĂ«m, ose Inxhinier ndĂ«rtimi
- 13 â Virtualizimi â Administrator Sistemi i Nivelit tĂ« MesĂ«m, ose atĂ« qĂ« njihet si CloudOps, me njohuri tĂ« avancuara tĂ« shĂ«rbimeve specifike hosting platformĂ«, pĂ«r tĂ« pĂ«rdorur nĂ« mĂ«nyrĂ« efikase fondet dhe pĂ«r tĂ« zvogĂ«luar ngarkesĂ«n nĂ« shĂ«rbim
Për të përmbledhur këtë pozinë mund të thuhet se djemtë mjaftojnë Administratorë të Nivelit të Mesëm/Senior.
Përveç kësaj, nuk duhet të ndahen shumë administratorët në Linux/Windows. Natyrisht e kuptoj se shërbimet dhe sistemet e këtyre dy botëve janë të ndryshme, por baza e të gjitha është e njëjtë dhe çdo administrator i respektueshëm është i njohur me të dyja, madje edhe nëse nuk është i njohur, nuk do të ketë vështirësi për t'u informuar për këtë.
Le të shohim një tjetër pozita:
- Përvoja në ndërtimin e sistemeve me ngarkesë të lartë;
- Njohuri të shk excellentlë për OS Linux, softueri sistemor dhe steka web (Nginx, PHP/Python, HAProxy, MySQL/PostgreSQL, Memcached, Redis, RabbitMQ, ELK);
- Përvoja në punë me sisteme virtualizimi (, VMWare, LXC/Docker);KVMAftësi në gjuhët e skriptimit;
- Kuptimi i parimeve të funksionimit të rrjeteve dhe protokolleve të rrjetit;
- Kuptimi i parimeve për ndërtimin e sistemeve me qëndrueshmëri të lartë;
- Pavarësia dhe iniciativa;
- Të shqyrtojmë:
1 â Administrator Sistemi Senior
- 2 â NĂ« varĂ«si tĂ« kuptimit qĂ« i jepet kĂ«tij staku â Administrator Sistemi i Nivelit tĂ« MesĂ«m/Senior
- 3 â PĂ«rvoja nĂ« punĂ«, gjithashtu mund tĂ« nĂ«nkuptojĂ« â "Klusterit nuk ia kam bĂ«rĂ«, por kam krijuar dhe menaxhuar virtualizime, pata njĂ« host Docker, ruajta qasjen nĂ« kontejnerĂ«" â Administrator Sistemi i Nivelit tĂ« MesĂ«m
- 3 â Eksperienca e punĂ«s, pĂ«rfshirĂ«, mund tĂ« nĂ«nkuptojĂ« - "Klusteri nuk u ngrit, por krijova dhe menaxhova virtualka, kisha njĂ« host Docker, aksesi nĂ« kontejnerĂ« ishte konfigurues" â Administratori i Sistemit tĂ« MesĂ«m
- 4 â Junior System Administrator â po, njĂ« administrator qĂ« nuk di tĂ« shkruajĂ« skenarĂ« elementarĂ« automatizimi, pa marrĂ« parasysh gjuhĂ«n, nuk Ă«shtĂ« administrator â Ă«shtĂ« njĂ« teknik.
- 5 â Middle System Administrator
- 6 â Senior System Administrator
NĂ« pĂ«rfundim â Middle/Senior System Administrator
Një tjetër:
- Përvoja në punë devops;
- Përvoja në përdorimin e një ose më shumë produkteve për formimin e proceseve CI/CD. Gitlab CI do të ishte një përparësi;
- Puna me kontejnerĂ« dhe virtualizim; NĂ«se keni pĂ«rdorur docker â mirĂ«, por nĂ«se k8s â shkĂ«lqyer!
- Përvoja në një ekip agile;
- Njohuri të çdo gjuhe programimi;
Le të shohim:
- 1 â Hmm⊠ĂfarĂ« kanĂ« parasysh djemtĂ«? =) Ndoshta ata vetĂ« nuk e dinĂ« atĂ« qĂ« fshihet pas kĂ«saj
- 2 â Build Engineer
- 3 â Middle System Administrator
- 4 â Soft-skills, nuk do t'i shqyrtojmĂ« tani, ndonĂ«se Agile Ă«shtĂ« njĂ« tjetĂ«r gjĂ« qĂ« interpretohet siç Ă«shtĂ« e pĂ«rshtatshme.
- 5 â MĂ« shumĂ« hapĂ«sirĂ« â mund tĂ« jetĂ« njĂ« gjuhĂ« skriptuese, ose njĂ« gjuhĂ« qĂ« kompilon. ĂuditĂ«risht, a do t'i pĂ«lqente atyre qĂ« kam shkruar nĂ« Pascal dhe Basic nĂ« shkollĂ«? =)
DĂ«shiroj gjithashtu tĂ« lĂ« njĂ« shĂ«nim nĂ« lidhje me pikĂ«n 3, pĂ«r tĂ« forcuar kuptimin pse kjo pikĂ« mbCoverohet nga administratorĂ«t e sistemit. Kubernetes Ă«shtĂ« thjesht orkestrimi, njĂ« mjet qĂ« mbĂ«shtjell komandat e drejtpĂ«rdrejta pĂ«r drejtorĂ«t e rrjetit dhe hostet e virtualizimit/izolimit nĂ« disa komanda dhe lejon qĂ« komunikimi me ta tĂ« jetĂ« abstrakt, kjo Ă«shtĂ« gjithçka. PĂ«r shembull, ta marrim âbuild frameworkâ Make, tĂ« cilin unĂ«, pĂ«r fjalĂ«, nuk e konsideroj si njĂ« kornizĂ«. Po, di pĂ«r modĂ«n e vendosjes sĂ« Make kudo, ku Ă«shtĂ« e nevojshme dhe e panevojshme â pĂ«r shembull, ta mbĂ«shtesĂ«sh Maven nĂ« Make, a Ă«shtĂ« serioze?
Në thelb, Make është thjesht një mbështjellës mbi shell, që thjeshton pikërisht komandat e kompilimit, lidhjes, ambientit të kompilimit, ashtu si edhe k8s.
Një herë, intervistova një djalë që përdorte k8s në punën e tij mbi OpenStack, dhe ai tregonte se si i zhvillonte shërbimet mbi të, megjithatë, kur e putha pyetje saktësisht për OpenStack, doli se ai administrohej, ashtu siç ngriteshin nga administratorët sistemorë. A e mendoni vërtet se personi që e ngriti OpenStack, pa marrë parasysh se çfarë platforme ka pas tij, nuk është i aftë të përdorë k8s?=)
Ky aplikant në të vërtetë nuk është DevOps, por po njësoj një Administrator i Sistemit dhe, për të qenë më të saktë, Administrator i Kubernetes.
PĂ«r tĂ« pĂ«rfunduar pĂ«rsĂ«ri â Middle/Senior System Administrator do t'i mjaftonte atyre.
Sa gram duhet të vendoset
PĂ«rhapja e pagave tĂ« propozuara pĂ«r pozitat e shtuara Ă«shtĂ« â 90k-200k
Tani, do të doja të bëj një krahasim midis shpërblimeve monetare të Administratorëve të Sistemit dhe Inxhinierëve DevOps.
Në princip, për të thjeshtuar, mund të ndajmë gradat sipas përvojës, megjithëse 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 vjet â 50k rub.
- Middle â 5 vjet â 70k rub.
- Senior â 11 vjet â 100k rub.
Inxhinierët DevOps:
- Junior â 2 vjet â 100k rub.
- Middle â 3 vjet â 160k rub.
- Senior â 6 vjet â 220k rub.
Për përvojën e 'DevOps'-eve, është përdorur një përvojë që ndikon ndonjëherë në SDLC.
Nga e gjithë kjo, del se në të vërtetë kompanitë nuk kanë nevojë për DevOps, përveç se mund të kursejnë të paktën 50 për qind të kostove fillestare duke punësuar një Administrator, më shumë se kaq, ata do të ishin në gjendje të përcaktonin më qartë detyrat e personit të kërkuar dhe do të zgjidhnin më shpejt nevojën. Po ashtu, nuk duhet të harrohet se ndarja e qartë e përgjegjësive lejon të ulë kërkesat për personelin dhe të krijojë një atmosferë më të favorshme në ekip, për shkak të mungesës së ndërprerjeve. Në shumicën dërrmuese të vendeve të punës ka një fluks të etiketave dhe strukturave të DevOps, megjithatë, nuk kanë në themel kërkesa të vërteta për një Inxhinier DevOps, përveç se kërkesa për një administrator utilitar.
Procesi i trajnimit të inxhinierëve DevOps është gjithashtu i kufizuar vetëm në një grup punësh specifike, utilitarëve, dhe nuk ofron një kuptim të përgjithshëm të proceseve dhe varfërive të tyre. Sigurisht, është mirë kur një person mund të përdorë Terraform për të deploy-uar AWS EKS, në lidhje me një sidecar Fluentd në këtë klaster dhe me një AWS ELK stack për sistemin e logimit brenda 10 minutash, duke përdorur vetëm një komandë në konsol, por nëse ai nuk do të kuptojë parimin e përpunimit të logëve dhe për çfarë janë të nevojshme, nuk di të mbledhë metrikat për to dhe të ndjekë degradimin e shërbimit, atëherë do të jetë gjithmonë e njëjta situatë me një person që di të përdorë disa utilitarë.
Megjithatë, kërkesa krijon ofertën, dhe ne shohim një treg shumë të ngrohtë për pozitat DevOps, ku kërkesat nuk përputhen me rolin real, por lejojnë administratorëve të sistemeve të fitojnë më shumë.
Atëherë, kush janë ata? DevOps apo administratorë të etur për para? =)
Si të jetojmë më tej?
Punëdhënësit duhet të formulojnë më saktë kërkesat dhe të kërkojnë pikërisht ata që janë të nevojshëm, në vend që të hedhin etiketat. Nëse nuk e dini se çfarë bëjnë DevOps, nuk ju duhen në këtë rast.
Punonjësit duhet të mësojnë. Të përmirësojnë vazhdimisht njohuritë e tyre, të shohin pamjen e përgjithshme të proceseve dhe të ndjekin rrugën drejt qëllimit të vendosur. Mund të bëheni çfarë të dëshironi, mjafton të përpiqeni.
Burimi: habr.com
