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 — Опыт работы, в том числе, может означать — «Кластер не подымал, но создавал и управлял виртуалками, был один Docker хост, доступ к контейнерам натил» — Middle System Administrator
- 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
