Hetkel on see peaaegu kõige kallim positsioon turul. Sebimine „DevOpsi” inseneride ümber ületab kõik mõeldavad piirid ja veelgi hullem DevOpsi vaneminseneride puhul.
Töötan integratsiooni- ja automatiseerimisosakonna juhatajana, arvan, et ingliskeelne dekodeerimine - DevOps Manager. Vaevalt, et ingliskeelne ärakiri kajastab meie igapäevaseid tegevusi, kuid venekeelne versioon on antud juhul täpsem. Minu tegevuse iseloomust tulenevalt on loomulik, et pean küsitlema tulevasi oma meeskonna liikmeid ning viimase aasta jooksul on minust läbi käinud umbes 50 inimest ning sama palju on minu töötajatega eelsõelalt ära lõigatud.
Otsime endiselt kolleege, sest DevOps sildi taga on peidus väga suur kiht erinevat sorti insenere.
Kõik allpool kirjutatu on minu isiklik arvamus, sellega ei pea nõustuma, aga möönan, et see annab su suhtumisele teemasse veidi värvi juurde. Vaatamata soosingust väljalangemise ohule avaldan oma arvamuse, sest usun, et sellel on koht, kus olla.
Ettevõtetel on erinev arusaam DevOpsi inseneridest ja ressursi kiireks palkamiseks riputavad nad selle sildi kõigile külge. Olukord on üsna kummaline, kuna ettevõtted on valmis neile inimestele maksma ebareaalseid tasusid, saades enamasti nende eest tööriistahalduri.
Kes on DevOpsi insenerid?
Alustame selle ilmumise ajaloost – arendusoperatsioonid ilmusid ootuspärase tagajärjena järjekordse sammuna väikestes meeskondades suhtlemise optimeerimise suunas, et suurendada toote tootmise kiirust. Idee oli tugevdada arendusmeeskonda teadmistega protseduuridest ja lähenemisviisidest tootekeskkonna haldamisel. Teisisõnu, arendaja peab mõistma ja teadma, kuidas tema toode teatud tingimustes töötab, peab mõistma, kuidas oma toodet kasutusele võtta, milliseid keskkonna omadusi saab toimivuse parandamiseks kohandada. Nii ilmusid mõnda aega DevOpsi lähenemisviisiga arendajad. DevOpsi arendajad kirjutasid ehitus- ja pakkimisskripte, et lihtsustada nende tegevust ja tootmiskeskkonna toimimist. Lahenduse arhitektuuri keerukus ja infrastruktuuri komponentide vastastikune mõju aja jooksul hakkas aga keskkondade jõudlust halvendama, iga iteratsiooniga oli vaja teatud komponente üha sügavamalt mõista, mis vähendas arendaja tootlikkust täiendavate lisaseadmete tõttu. konkreetse ülesande jaoks komponentide ja häälestussüsteemide mõistmise kulud. Arendaja enda kulu kasvas, koos sellega ka toote maksumus, järsult hüppasid nõudmised uutele arendajatele meeskonnas, sest neil oli vaja katta ka arendus "staari" kohustused ja loomulikult jäi "staare" vähemaks. ja vähem saadaval. Samuti väärib märkimist, et minu kogemuse põhjal tunnevad vähesed arendajad huvi operatsioonisüsteemi tuuma pakettide töötlemise eripärade, pakettide marsruutimise reeglite ja hosti turvaaspektide vastu. Loogiline samm oli sellega kursis oleva administraatori kaasamine ja talle sarnaste kohustuste määramine, mis võimaldas tänu tema kogemusele saavutada samad näitajad „staar“ arenduse maksumusega võrreldes väiksema kuluga. Sellised administraatorid paigutati meeskonda ja tema peamiseks ülesandeks oli testimis- ja tootmiskeskkondade haldamine vastavalt konkreetse meeskonna reeglitele, sellele konkreetsele meeskonnale eraldatud ressurssidega. Nii ilmusidki DevOps enamuse teadvusesse.
Osaliselt või täielikult hakkasid need süsteemiadministraatorid aja jooksul mõistma selle konkreetse meeskonna vajadusi arendusvaldkonnas, kuidas arendajate ja testijate elu lihtsamaks teha, kuidas värskendust välja saata ja mitte reedel ööbida. büroos, juurutusvigade parandamine. Aeg möödus ja nüüd olid "staarid" süsteemiadministraatorid, kes said aru, mida arendajad tahavad. Mõju minimeerimiseks hakkasid esile kerkima haldusutiliidid; kõik mäletasid vanu ja usaldusväärseid OS-i taseme isoleerimise meetodeid, mis võimaldasid minimeerida turvanõudeid, võrguosa haldamist ja hosti konfiguratsiooni. tervik ja selle tulemusena vähenevad nõuded uutele "staaridele".
Ilmunud on "imeline" asi - dokk. Miks imeline? Jah, ainult sellepärast, et isolatsiooni loomine chrootis või vanglas, aga ka OpenVZ-is nõudis OS-i mittetriviaalseid teadmisi, seevastu võimaldab utiliit luua teatud hostis lihtsalt isoleeritud rakenduskeskkonna, kus on kõik vajalik sees ja käes. arenduse ohjad jälle üle ning süsteemiadministraator saab hakkama vaid ühe hostiga, tagades selle turvalisuse ja kõrge kättesaadavuse – loogiline lihtsus. Kuid edusammud ei seisa paigal ja süsteemid muutuvad jälle üha keerukamaks, komponente on aina rohkem, üks host ei vasta enam süsteemi vajadustele ja on vaja ehitada klastreid, pöördume taas tagasi süsteemiadministraatorite juurde, kes on suudab neid süsteeme ehitada.
Tsükkel tsükli järel ilmuvad erinevad süsteemid, mis lihtsustavad arendust ja/või haldust, ilmuvad orkestreerimissüsteemid, mida on lihtne kasutada seni, kuni pole vaja tavaprotsessist kõrvale kalduda. Ilmus ka mikroteenuste arhitektuur eesmärgiga lihtsustada kõike ülalkirjeldatut – vähem suhteid, lihtsam hallata. Oma kogemuse põhjal ei leidnud ma täielikult mikroteenuse arhitektuuri, ma ütleks, et 50–50–50 protsenti mikroteenustest, mustad kastid, tulid sisse, tulid välja töödeldud, ülejäänud 50 on rebenenud monoliit, teenused ei saa teistest eraldi töötada. komponendid. Kõik see seadis taas piiranguid nii arendajate kui ka administraatorite teadmiste tasemele.
Sarnased "kõikumised" konkreetse ressursi ekspertteadmiste tasemes jätkuvad tänapäevani. Kuid kaldume veidi kõrvale, esiletõstmist väärib palju punkte.
Ehitusinsener / vabastamise insener
Väga kõrgelt spetsialiseerunud insenerid, kes tekkisid tarkvara koostamise protsesside ja väljalasete standardimise vahendina. Laialt levinud Agile'i kasutuselevõtu käigus näib, et nende järele ei ole enam nõudlust, kuid see pole kaugeltki nii. See spetsialiseerumine ilmnes vahendina tarkvara kokkupanemise ja tarnimise standardiseerimiseks tööstuslikus mastaabis, s.o. kasutades standardtehnikaid kõigi ettevõtte toodete jaoks. DevOpsi tulekuga kaotasid arendajad osaliselt oma funktsioonid, kuna just arendajad hakkasid toodet tarnimiseks ette valmistama ning arvestades muutuvat infrastruktuuri ja lähenemist võimalikult kiirele tarnimisele, sõltumata kvaliteedist, muutusid need aja jooksul muutuste peataja, kuna kvaliteedistandarditest kinnipidamine aeglustab paratamatult tarneid. Järk-järgult liikus osa ehituse/väljastamise inseneride funktsioonidest süsteemiadministraatorite õlule.
Opid on nii erinevad
Liigume edasi ja jälle suur vastutusala olemasolu ja kvalifitseeritud personali puudumine sunnib meid range spetsialiseerumise poole, nagu seeni pärast vihma, ilmuvad erinevad operatsioonid:
- TechOps – enikey süsteemiadministraatorid ehk HelpDesk Engineer
- LiveOps – süsteemiadministraatorid, kes vastutavad peamiselt tootmiskeskkondade eest
- CloudOps – süsteemiadministraatorid, kes on spetsialiseerunud avalikele pilvedele Azure, AWS, GCP jne.
- PlatOps/InfraOps/SysOps – infrastruktuuri süsteemiadministraatorid.
- NetOps – võrguadministraatorid
- SecOps – infoturbele spetsialiseerunud süsteemiadministraatorid – PCI vastavus, CIS vastavus, lappimine jne.
DevOps on (teoreetiliselt) inimene, kes mõistab vahetult kõiki arendustsükli protsesse – arendust, testimist, saab aru tootearhitektuurist, oskab hinnata turvariske, tunneb lähenemisi ja automatiseerimisvahendeid, vähemalt kõrgel tasemel. tasemel mõistab lisaks sellele ka eel- ja järeltöötlust.toote väljalaske tugi. Isik, kes on võimeline tegutsema nii operatsioonide kui ka arendustegevuse eestkõnelejana, mis võimaldab nende kahe samba vahel soodsat koostööd. Saab aru meeskondade töö planeerimise ja klientide ootuste juhtimise protsessidest.
Sellise töö ja kohustuste täitmiseks peavad sellel isikul olema vahendid mitte ainult arendus- ja testimisprotsesside juhtimiseks, vaid ka toote infrastruktuuri haldamiseks ja ressursside planeerimiseks. DevOps selles arusaamas ei saa asuda ei IT-s, teadus- ja arendustegevuses ega isegi PMO-s; tal peab olema mõju kõigis neis valdkondades – ettevõtte tehniline direktor, tehniline juht.
Kas see on teie ettevõttes tõsi? - Ma kahtlen. Enamasti on selleks kas IT või teadus- ja arendustegevus.
Rahapuudus ja võime mõjutada vähemalt ühte neist kolmest tegevusvaldkonnast nihutavad probleemide kaalu sinnapoole, kus neid muudatusi on lihtsam rakendada, näiteks tehniliste piirangute rakendamine väljaannetele seoses "määrdunud" koodiga vastavalt staatilisele süsteemile. analüsaatorisüsteemid. See tähendab, et kui PMO määrab funktsioonide väljalaskmiseks range tähtaja, ei saa teadus- ja arendustegevus nende tähtaegade jooksul kvaliteetset tulemust anda ja annab selle nii hästi kui suudab, jättes ümbertöötluse hilisemaks, IT-ga seotud DevOps blokeerib tehniliste vahenditega väljastamise. . Volituste puudumine olukorra muutmiseks põhjustab vastutustundlike töötajate puhul hüpervastutuse avaldumist selle eest, mida nad ei saa mõjutada, eriti kui need töötajad mõistavad ja näevad vigu ning kuidas neid parandada - "Õndsus on teadmatus", ning selle tagajärjel nende töötajate läbipõlemine ja kaotus.
DevOpsi ressursiturg
Vaatame mitmeid vabu töökohti DevOpsi ametikohtadele erinevatest ettevõtetest.
Oleme valmis teiega kohtuma, kui:
- Teile kuulub Zabbix ja teate, mis on Prometheus;
- Iptables;
- BASH doktorant;
- professor Ansible;
- Linuxi guru;
- Oskab kasutada silumist ja leida koos arendajatega rakendusprobleeme (php/java/python);
- Marsruutimine ei muuda sind hüsteeriliseks;
- Pöörake suurt tähelepanu süsteemi turvalisusele;
- Varundage "kõik ja kõik" ning taastage edukalt ka see "kõik ja kõik";
- Oskad seadistada süsteemi nii, et miinimumist maksimum välja võtta;
- Seadistage replikatsioon enne magamaminekut Postgres ja MySQL-is;
- CI/CD seadistamine ja reguleerimine on teie jaoks sama vajalik kui hommiku-/lõuna-/õhtusöök.
- Oman kogemust AWS-iga;
- Valmisolek areneda koos ettevõttega;
Nii et:
- 1 kuni 6 - süsteemiadministraator
- 7 - väike võrguhaldus, mis sobib ka süsteemiadministraatoriga, keskmine tase
- 8 - väike turvalisus, mis on kesktaseme süsteemiadministraatorile kohustuslik
- 9-11 – keskmine süsteemiadministraator
- 12 – olenevalt määratud ülesannetest kas kesksüsteemiadministraator või ehitusinsener
- 13 – Virtualiseerimine – keskmine süsteemiadministraator ehk nn CloudOps, täpsemad teadmised konkreetse hostimissaidi teenustest raha tõhusaks kasutamiseks ja hoolduskoormuse vähendamiseks
Selle vaba koha kokkuvõtteks võib öelda, et kuttidele piisab keskmisest/vanem süsteemiadministraatorist.
Muide, te ei tohiks Linuxi/Windowsi administraatoreid tugevalt jagada. Muidugi ma saan aru, et nende kahe maailma teenused ja süsteemid on erinevad, kuid alus on kõigil sama ja iga endast lugupidav administraator on tuttav nii ühe kui ka teisega ja isegi kui ta pole tuttav, siis pädeval administraatoril ei tohiks olla raske sellega tuttavaks saada.
Mõelgem veel ühele vabale ametikohale:
- Kogemus suure koormusega süsteemide ehitamisel;
- Suurepärased teadmised Linux OS-ist, üldisest süsteemitarkvarast ja veebipinust (Nginx, PHP/Python, HAProxy, MySQL/PostgreSQL, Memcached, Redis, RabbitMQ, ELK);
- Kogemus virtualiseerimissüsteemidega (KVM, VMWare, LXC/Docker);
- skriptikeelte valdamine;
- Võrguprotokolli võrkude tööpõhimõtete mõistmine;
- Rikketaluvate süsteemide ehitamise põhimõtete mõistmine;
- Iseseisvus ja algatusvõime;
Vaatame:
- 1 – vanemsüsteemiadministraator
- 2 – Olenevalt sellesse virna pandud tähendusest – keskmine/vanem süsteemiadministraator
- 3 - Töökogemus, sealhulgas võib tähendada - "Klaster ei kasvatanud, vaid lõi ja haldas virtuaalmasinaid, oli üks Dockeri host, juurdepääs konteineritele ei olnud saadaval" - Keskmine süsteemiadministraator
- 4 - Junior System Administrator - jah, administraator, kes ei tea, kuidas kirjutada põhilisi automatiseerimisskripte, olenemata keelest, mitte administraator - enikey.
- 5 – keskmine süsteemiadministraator
- 6 – vanemsüsteemiadministraator
Kokkuvõtteks – keskmine/vanem süsteemiadministraator
Veel üks:
- Devopsi kogemus;
- Kogemus ühe või mitme toote kasutamisel CI/CD protsesside loomiseks. Kasuks tuleb Gitlab CI;
- Töö konteinerite ja virtualiseerimisega; Kui kasutasite dokkerit, on hea, aga kui kasutasite k8-sid, siis suurepärane!
- Agiilses meeskonnas töötamise kogemust;
- mis tahes programmeerimiskeele tundmine;
Vaatame:
- 1 - Hmm... Mida need poisid mõtlevad? =) Tõenäoliselt nad ise ei tea, mis selle taga on
- 2 – ehitusinsener
- 3 – keskmine süsteemiadministraator
- 4 - Pehme oskus, me seda praegu ei käsitle, kuigi Agile on teine asi, mida tõlgendatakse mugavalt.
- 5 – Liiga paljusõnaline – see võib olla skriptikeel või kompileeritud keel. Huvitav, kas neile sobib koolis Pascalis ja Basicus kirjutamine? =)
Samuti tahaksin jätta märkuse punkti 3 kohta, et tugevdada arusaamist, miks süsteemiadministraator seda punkti katab. Kubernetes on lihtsalt orkestratsioon, tööriist, mis mähib võrgudraiverite ja virtualiseerimis-/isolatsioonihostide otsesed käsud paari käsuga ning võimaldab teil nendega suhtlemise abstraktseks muuta. Näiteks võtame 'build framework' Make, mida ma muide raamistikuks ei pea. Jah, ma tean seda moodi, et sokutada Make suvalisele poole, kus on vaja ja pole vaja - näiteks Mavenit Make’i mähkida tõsiselt?
Põhimõtteliselt on Make vaid kesta ümbris, mis lihtsustab kompileerimis-, linkimis- ja kompileerimiskeskkonna käske, nagu ka k8s.
Kord intervjueerisin üht meest, kes kasutas OpenStacki peal töös k8-sid, ja ta rääkis, kuidas ta sellel teenuseid juurutas, kuid kui küsisin OpenStacki kohta, selgus, et seda haldas ja tõstis süsteem administraatorid. Kas sa tõesti arvad, et OpenStacki installinud inimene, olenemata sellest, millist platvormi ta enda taga kasutab, ei saa k8s kasutada? =)
See taotleja ei ole tegelikult DevOps, vaid süsteemiadministraator ja täpsemalt Kubernetese administraator.
Teeme veel kord kokkuvõtte – neile piisab keskmisest/vanemast süsteemiadministraatorist.
Kui palju grammides kaaluda
Näidatud vabade ametikohtade pakutavate töötasude vahemik on 90 200-XNUMX XNUMX
Nüüd tahaksin tõmmata paralleeli süsteemiadministraatorite ja DevOpsi inseneride rahaliste preemiate vahel.
Põhimõtteliselt võite asjade lihtsustamiseks hinded hajutada töökogemuse põhjal, kuigi see pole täpne, kuid artikli jaoks sellest piisab.
Kogemus:
- kuni 3 aastat – juunior
- kuni 6 aastat vana – keskmine
- rohkem kui 6 – seenior
Töötajate otsingusait pakub:
Süsteemiadministraatorid:
- Juunior - 2 aastat - 50 XNUMX hõõruda.
- Keskmine - 5 aastat - 70 XNUMX hõõruda.
- Vanem - 11 aastat - 100 XNUMX hõõruda.
DevOpsi insenerid:
- Juunior - 2 aastat - 100 XNUMX hõõruda.
- Keskmine - 3 aastat - 160 XNUMX hõõruda.
- Vanem - 6 aastat - 220 XNUMX hõõruda.
“DevOpsi” kogemuse kohaselt kasutati kogemust, mis vähemalt kuidagi mõjutas SDLC-d.
Eelnevast järeldub, et tegelikult ettevõtted DevOpsi ei vaja ja ka see, et nad saaksid administraatori palkamisega säästa vähemalt 50 protsenti algselt planeeritud kuludest, lisaks võiksid nad täpsemalt määratleda otsitava isiku kohustused. ja täidab vajaduse kiiremini. Samuti ei tasu unustada, et selge vastutusalade jaotus võimaldab meil kattumiste puudumise tõttu vähendada nõudeid personalile, samuti luua meeskonnas soodsama õhkkonna. Valdav enamus vabadest töökohtadest on täis utiliite ja DevOpsi silte, kuid need ei põhine tegelikel DevOpsi insenerile esitatavatel nõuetel, vaid ainult tööriistaadministraatori taotlustel.
Ka DevOpsi inseneride koolitamise protsess piirdub ainult konkreetsete tööde, utiliitide komplektiga ega anna üldist arusaama protsessidest ja nende sõltuvustest. Kindlasti on hea, kui inimene saab 10 minutiga juurutada AWS EKS-i kasutades Terraformi koos selle klastris oleva Fluentdi külgkorviga ja logisüsteemi AWS ELK-virnaga XNUMX minutiga, kasutades konsoolis vaid ühte käsku, kuid kui ta ei saa aru logide enda töötlemise põhimõte ja milleks neid vaja on, kui te ei tea, kuidas nende kohta mõõdikuid koguda ja teenuse halvenemist jälgida, siis on ikkagi see sama enikey, kes teab, kuidas mõnda utiliiti kasutada.
Nõudlus aga tekitab pakkumist ning DevOps positsioonil näeme äärmiselt ülekuumenenud turgu, kus nõuded ei vasta tegelikule rollile, vaid võimaldavad ainult süsteemiadministraatoritel rohkem teenida.
Kes nad siis on? DevOps või ahned süsteemiadministraatorid? =)
Kuidas edasi elada?
Tööandjad peaksid nõudeid täpsemalt sõnastama ja otsima just neid, keda vaja, mitte loopima silte. Te ei tea, mida DevOps teevad – sel juhul pole teil neid vaja.
Töötajad – õppige. Täiendage pidevalt oma teadmisi, vaadake protsesside üldpilti ja jälgige teed oma eesmärgini. Sa võid saada kelleks tahad, sa pead lihtsalt proovima.
Allikas: www.habr.com