Kes on DevOps?

Praegu on see tõenäoliselt turul üks kallimaid positsioone. Ümber „DevOps“ inseneride kõrvalekallet ületab kõik mõeldavad piirid, eriti veel Senior DevOps inseneride osas.
Töötan integreerimise ja automatiseerimise osakonna juhina, arva ära ingliskeelne lühend — DevOps Manager. Kas see ingliskeelne lühend peegeldab meie igapäevaseid tegevusi — kahtlemata mitte, kuid venekeelne variant on antud juhul täpsem. Minu töö iseloomust tulenevalt on loomulik, et pean küsitlema oma tulevasi meeskonnaliikmeid, ja viimase aasta jooksul on mul olnud umbes 50 kandidaati, lisaks nendele, kes tehti elimineerituks mu töötajate eelintervjuudel.

Otsime endiselt kolleege, kuna DevOps sildi all peitub väga suur erinevate inseneride kiht.

Allpool esitatud on minu isiklik arvamus, te ei pea sellega nõustuma, kuid ma arvan, et see võib mõjutada teie suhtumist teemasse. Hoolimata riskist kaotada populaarsus, avaldan oma arvamuse, kuna usun, et sellel on väärtus.

Ettevõtted mõistavad DevOps insenere erinevalt ning kiireks värbamiseks nimetavad nad neid kõiki niimoodi. Situatsioon on üsna kummaline, sest ettevõtted on valmis nendele inimestele maksma uskumatuid tasusid, saades enamikul juhtudel administreerijat või tööriistade spetsialisti.

Aga kes need DevOps insenerid siis on?

Alustame ajaloost – Development Operations sündis järgmiseks sammuks väikeste meeskondade koostöö optimeerimisel, et suurendada toote tootmiskiirus, mis oli oodatav tulemus. Idee oli tugevdada arendustiimi teadmisi tootevõimekuse ja -keskkonna haldamise protseduuridest ja lähenemistest. Teisisõnu, arendajal peab olema arusaam oma toote toimimisest erinevates tingimustes, ta peab teadma, kuidas oma toodet juurutada ning milliseid keskkonna omadusi reguleerida, et tõsta jõudlust. Nii hakkasid aja jooksul tekkima DevOps lähenemisega arendajad. DevOps arendajad kirjutasid ehitus- ja pakkimiskäsud, et lihtsustada oma tööd ja tootmisrežiimis töötamist. Siiski, lahenduste arhitektuuri keerukus ja infrastruktuurikomponentide vastastikune mõju hakkas aja jooksul töösooritust halvendama, iga iteratsioon nõudis sügavamate arusaamade hankimist erinevatest komponentidest, alandades arendaja tootlikkust lisakulude tõttu osade mõistmiseks ja süsteemide kohandamiseks konkreetse ülesande jaoks. Arendaja enda tööjõuhind kasvas, koos tootega, tõusis ka nõudlus uute arendajate järele meeskonnas, kuna nende ülesannete katmiseks oli vaja ka „staar“ arendaja tööülesandeid, ning loomulikult muutusid „staarid“ järjest vähem kättesaadavaks. Samuti tasub mainida, et minu kogemuse järgi on vähesed arendajad huvitatud operatsioonisüsteemi tuuma pakettide töötlemise spetsiifikast, pakettide marsruutimise reeglitest, hosti turvalisuse aspektidest. Loogiline samm oli kaasata administraator, kes tunneb neid aspekte, ja panna sellised kohustused tema õlgadele, mis tema kogemuse tõttu võimaldas saavutada samu näitajaid madalama hinnaga võrreldes „staar“ arendajaga. Sellised administraatorid viidati meeskonda ja nende peamine ülesanne oli hallata testimis- ja tootmiskeskkondi konkreetse meeskonna reeglite kohaselt, ressurssidega, mis olid sellele meeskonnale eraldatud. Nii saidki DevOps’id paljude arusaamisse.

Aja jooksul hakkasid süsteemiadministraatorid osaliselt või täielikult mõistma selle konkreetse arendusmeeskonna vajadusi, muutes arendajate ja testijate elu lihtsamaks. Kuidas teha uuendusi nii, et ei peaks reede õhtul kontoris veetma, parandades juurutamisvigu? Aeg möödus ja nüüd tõusid tähtedeks süsteemiadministraatorid, kes mõistsid, mida arendajad soovivad. Mõjude minimiseerimise eesmärgil hakati tutvustama juhtimistööriistu, kõik meenutasid vanu ja usaldusväärseid operatsioonisüsteemi taseme isolatsiooni meetodeid, mis vähendasid turvanõudeid, võrguhalduse ja hosti konfiguratsiooni laiemalt, ning seetõttu vähenesid ka uutele „tähtedele” esitatavad nõudmised.

Ilmus «ime» — docker. Miks ime? Sest ühelt poolt nõudis isolatsiooni loomine chroot või jail, samuti OpenVZ, märkimisväärseid teadmisi opsüsteemist; teiselt poolt on meil nüüd tööriist, mis võimaldab lihtsalt luua isoleeritud rakenduskeskkonda ühe hosti sees, kus kõik vajalik on olemas, ja anda samuti arendajatele juhtimisõigus tagasi, samas kui süsteemiadministraator peab haldama ainult ühte hosti, tagades selle turvalisuse ja kõrge kättesaadavuse — loogiline lihtsustus. Kuid progress ei seisa paigal ning süsteemid muutuvad järjest keerulisemaks, komponente tuleb üha rohkem ja rohkem, üks host ei rahulda enam süsteemi vajadusi ning on vajalik klastrite ehitamine. Me naaseme taas süsteemiadministraatorite juurde, kes suudavad neid süsteeme ehitada.

Aasta aastalt tekivad erinevad süsteemid, mis lihtsustavad arendust ja/või haldamist, ilmuvad orkestreerimissüsteemid, mis on kasutajasõbralikud kuni hetkeni, mil on vaja standardprotsessist kõrvale kalduda. Mikroteenuste arhitektuur ilmus samuti eesmärgiga lihtsustada kõike eelmainitut — vähem seoseid, lihtsam haldamine. Oma kogemuses ei ole ma täielikult mikroteenuste arhitektuuri kogenud, ütleksin, et see on 50–50 — 50 protsenti mikroteenuseid, mustad kastid, sisend tuli, töötlemine välja, teised 50 — purustatud monoliit, teenused ei suuda teiste komponentidega eraldi töötada. See kõik seab taas piirangud nii arendajate kui ka administraatorite teadmistasemele.

Sellised „kiiged“ ekspertteadmiste tasemes sellele või sellele ressursile jätkuvad siiani. Kuid me oleme veidi kõrvale kaldunud, on palju aspekte, mida tasub arutada.

Build Engineer/Release Engineer

Väga kitsalt spetsialiseeritud insenerid, kes on tekkinud tarkvara ja selle väljaannete koostamise protsesside standardiseerimise vahendina. Tundus, et nende nõudlus langes pärast laialdaselt rakendatud Agile'i meetodite tulekut, kuid see ei vasta tõele. See spetsialiseerumine tekkis eesmärgiga standardiseerida tarkvara koostamine ja tarnimine tööstuslikus mastaabis, kasutades kõigi ettevõtte toodete jaoks standardseid tehnikaid. DevOps’i arendajate tulekuga kaotasid nad osaliselt oma ülesanded, kuna just arendajad hakkasid toodet tarnimiseks ette valmistama. Arvestades muutuvaid infrastruktuuri ja lähenemisviise kiirele tarnimisele, mis sageli ei arvesta kvaliteeti, on nad ajaga muutunud tõkkeks muutustele, kuna kvaliteedistandardite järgimine aeglustab paratamatult tarnet. Nii on järk-järgult osa Build/Release inseneride funktsionaalsusest üle läinud süsteemiadministraatorite õlgadele.

Ops’id on nii erinevad

Liigume edasi ja jälle suur hulk kohustusi ning kvalifitseeritud töötajate puudus sunnib meid ranget spetsialiseerumist otsima; nagu seened pärast vihma, ilmuvad erinevad Operations:

• TechOps — süsteemihaldurid, tuntud ka kui HelpDesk insenerid
• LiveOps — süsteemihaldurid, kes peamiselt vastutavad tootmiskeskkondade eest
• CloudOps — süsteemihaldurid, kes on spetsialiseerunud avalikele pilvedele nagu Azure, AWS, GCP jne.
• PlatOps/InfraOps/SysOps — infrastruktuuri süsteemihaldurid.
• NetOps — võrguadministraatorid
• SecOps — süsteemihaldurid, kes on spetsialiseerunud infosüsteemide turvalisusele — PCI vastavus, CIS vastavus, patšimise jne.

DevOps — (teoorias) isik, kes mõistab põhjalikult kõiki arendusprotsessi etappe — arendust, testimist, toote arhitektuuri, suudab hinnata turvariske, tunneb automatiseerimise meetodeid ja vahendeid vähemalt kõrgemal tasemel, lisaks sellele mõistab ka toote eelnõu ja järelnõu toetust. Isik, kes suudab tegutseda nii Operations'i kui ka Development'i huvides, mis võimaldab luua head koostööd nende kahe sammaste vahel. Mõistab, kuidas meeskondade tööplaane koostada ja kliendi ootusi juhtida.

Sarnaste tööde ja kohustuste täitmiseks peab isikul olema oskused mitte ainult arendus- ja testimisprotsesside, vaid ka toote infrastruktuuri haldamise ja ressursside planeerimise alal. DevOps ei saa olla piiratud ei IT, ei R&D ega isegi PMO-ga; tal peab olema mõju kõigis nendes valdkondades — ettevõtte tehniline direktor, Chief Technical Officer.

Kas see kehtib teie ettevõtte kohta? — Kahtlen. Enamasti on see kas IT või R&D.

Raha ja võimaluste puudumine mõjutada vähemalt ühte neist kolmest tegevusvaldkonnast muudab probleemide tasakaalu suunas, kus neid muudatusi on lihtsam rakendada, näiteks tehniliste piirangute kohaldamine väljaannetele "mustade" koodide korral vastavalt staatilise analüüsi süsteemide andmetele. See tähendab, et kui PMO seab rangelt ajakava funktsionaalsuse vabastamiseks, ei suuda R&D selle ajakava raames kvaliteetset tulemust esitada ja teeb seda, mis on võimalik, jättes refaktoreerimise hilisemaks. IT-sse kuuluv DevOps blokeerib väljaande tehniliste vahenditega. Puudulikkus õigustes olukorda muuta, juhul, kui vastutavad töötajad, toob kaasa ülemäärase vastutustunde selle eest, millele nad ei saa mõjutada, eriti kui need töötajad mõistavad ja näevad vigu ning kuidas neid parandada — "Õnn on teadmatuses", mis omakorda viib töötajate läbipõlemiseni ja kaotamiseni.

DevOps ressursside turg

Vaadakem mitmeid DevOps ametikohti erinevatest ettevõtetest.

Oleme valmis Teiega kohtuma, kui Te:

1. Valdate Zabbixit ja tead, mis on Prometheus;
2. Iptables;
3. BASH aspirant;
4. Ansible professor;
5. Linux guru;
6. Kas oskate kasutada debug'it ja leida koos arendajatega rakenduste (php/java/python) probleeme;
7. Routing ei tekita teile paanikat;
8. Pöörate suurt tähelepanu süsteemi turvalisusele;
9. Teete varukoopiaid "kõigest ja kõigest", samuti taastate selle "kõige ja kõigest" edukalt;
10. Oska seadistada süsteemi maksimaalse väljundi saavutamiseks minimaalse kasutamise korral;
11. Seadistate replikatsioonid enne magamaminekut Postgresi ja MySQL jaoks;
12. CI/CD seadistamine ja kohandamine on teie jaoks sama vajalik kui hommiku-/lõuna-/õhtusöök.
13. Teil on kogemus AWS-iga;
14. Olete valmis koos ettevõttega arenema;

Nii et:

• 1 kuni 6 — süsteemiadministraator
• 7 — veidi võrgu haldamist, mis ka kuulub süsteemiadministraatori, keskmise taseme alla
• 8 — veidi turvalisust, mis on kindlasti vajalik keskmise taseme süsteemiadministraatori jaoks
• 9-11 — Keskmine süsteemiadministraator
• 12 — sõltuvalt ülesannetest kas keskmine süsteemiadministraator või Build Engineer
• 13 — virtualiseerimine — keskmine süsteemiadministraator või CloudOps, laiendatud teadmised konkreetse teenuse kasutamisest hõbustamise. rahade tõhusaks kasutamiseks ja hoolduse koormuse vähendamiseks

Kokkuvõtteks selle vaba töökoha kohta võib öelda, et kandidaat peab olema vähemalt keskastme/seniorklassi süsteemiadministraator.

Muide, ei tohiks administreerimist liiga palju jagada Linuxi ja Windowsi vahel. Ma mõistan, et nende kahe maailma teenused ja süsteemid erinevad, kuid alus on kõigil sama ja iga endast lugupidav admin on tuttav mõlema süsteemiga. Isegi kui pole tuttav, ei tohiks kogenud administraatoril olla raskusi selle valdkonnaga tutvuda.

Vaatame teist tööpakkumist:

1. Kogemus kõrge koormusega süsteemide loomisel;
2. Suurepärased teadmised operatsioonisüsteemist Linux, süsteemitehnoloogiast ja veebist (Nginx, PHP/Python, HAProxy, MySQL/PostgreSQL, Memcached, Redis, RabbitMQ, ELK);
3. Kogemus virtualiseerimistehnoloogiatega (KVM, VMWare, LXC/Docker);
4. Oskus skriptimiskeeltega;
5. Arusaamine võrguprotokollide toimimisest;
6. Arusaamine talitlushäirete eest kaitstud süsteemide ehitamise põhimõtetest;
7. Iseseisvus ja algatusvõime;

Analüüsime:

• 1 — Senior System Administrator
• 2 — Sõltuvalt mõistest, mis sellele virnale pannakse — Middle/Senior System Administrator
• 3 — Töö kogemus võib tähendada ka — 'Kluster ei olnud tõstetud, kuid loomise ja virtuaalmasinate haldamisega tegeles, oli üks Docker host, konteinerite juurde pääsemine oli seadistatud' — Middle System Administrator
• 4 — Noorem süsteemiadministraator — jah, admin, kes ei oska kirjutada elementaarseid automatiseerimisskripte, olenemata keelest, ei ole admin — lihtsalt tehnik.
• 5 — Keskmine süsteemiadministraator
• 6 — Vanem süsteemiadministraator

Kokkuvõttes — Keskmine/Vanem süsteemiadministraator

Veel üks:

1. DevOps-i kogemus;
2. Kogemus ühe või mitme toote kasutamisel CI/CD protsesside kujundamiseks. Gitlab CI on eelis;
3. Töötamine konteinerite ja virtualiseerimisega; Kui olete kasutanud Dockerit – tore, aga kui ka Kuberneteset – suurepärane!
4. Kogemus agiilmeeskonnas;
5. Mingisuguse programmeerimiskeele tundmine;

Vaadake:

• 1 — Hmm… Mida poisid silmas peavad? =) Tõenäoliselt ei tea nad isegi, mis selle taga peidus on
• 2 — Ehitusinsener
• 3 — Keskmine süsteemiadministraator
• 4 — Pehmed oskused, sellega seni ei tegeleme, kuigi agiil on veel üks asi, mida tõlgendatakse vastavalt mugavusele.
• 5 — Liialt laialivalguv — see võib olla skriptikeel või kompileeritav. Huvi, kas Pascal ja Basic, millega koolis kirjutati, sobivad neile? =)

Sooviksin ka märkida 3. punkti osas, et tugevdada arusaamist, miks seda punkti katab süsteemiadministraator. Kubernetes on vaid orkestreerimise tööriist, mis ümbritseb otse käske võrgukaartidele ja virtualiseerimise/se isolatsiooni hostidele paariks käskuks ning võimaldab suhtlemise nendega abstraktseks teha, ja ongi kõik. Näiteks võtame ehitusraamistiku Make, mida ma muide raamistiks ei pea. Jah, ma tean, et on hirmus populaarsed neid panna Make'isse, kus on vaja ja kus ei ole — näiteks Maven'i ümber Make'i panna, tõsiselt?
Tegelikult on Make lihtsalt ümbritseja shell'i kohal, mis lihtsustab just kompileerimise, lingimise ja kompileerimise keskkonnakäske, täpselt nagu k8s.

Kord intervjueerisin poissi, kes kasutas k8s oma töös OpenStack'i peal, ja ta rääkis, kuidas ta teenuseid seal rakendas, kuid kui küsisin just OpenStack'i kohta, selgus, et seda haldavad süsteemiadministraatorid. Kas te tõesti arvate, et inimene, kes on OpenStack'i üles seadnud, olenemata sellest, millist platvormi ta taga kasutab, ei suuda kasutada k8s?=)
See kandidaat ei ole tegelikult DevOps, vaid hoopis Süsteemi Administraator ja, et olla täpsem, Kubernetes Administrator.

Kokkuvõttes on Middle/Seniori Süsteemi Administratiivne positsioon talle piisav.

Kui palju grammi peaks kaaluma.

Pakutavate palkade hajumine sellel positsioonil on 90k-200k.
Nüüd tahaksin tuua paralleeli Süsteemi Administratiivsete ja DevOps Engineeride rahalistest hüvedest.

Põhimõtteliselt võib kogemuste põhjal gradi jagada, ehkki see ei ole täpne, aga artikli eesmärkide jaoks piisab.

Kogemus:

1. kuni 3 aastat — Junior
2. kuni 6 aastat — Middle
3. üle 6 aasta — Senior

Töötajate otsimise sait pakub:
Süsteemi administraatorid:

1. Junior — 2 aastat — 50k rubla.
2. Middle — 5 aastat — 70k rubla.
3. Senior — 11 aastat — 100k rubla.

DevOps Engineerid:

1. Junior — 2 aastat — 100k rubla.
2. Middle — 3 aastat — 160k rubla.
3. Senior — 6 aastat — 220k rubla.

DevOps'i kogemuse puhul kasutati staaži, mis mingil moel puudutas SDLC-d.

Ülaltoodust tuleneb, et ettevõtted ei vajagi tegelikult DevOps'i ning nad võiksid säästa vähemalt 50% algselt planeeritud kuludest, kui palkaksid hoopis administraatori. Veelgi enam, nad võiksid selgemini määratleda soovitud isiku kohustused ja kiiremini rahuldada vajaduse. Samuti ei tohiks unustada, et kohustuste selge jaotus vähendab personali nõudmisi ning loob kollektiivis soodsama õhkkonna, tänu segaduse puudumisele. Enamiku töökuulutuste puhul on täidetud utiliitide ja DevOps'i siltidega, kuigi need ei põhine tõeliselt DevOps Engineer'i nõudmisel, vaid hoopis tööriista administraatori soovidel.

DevOps insenerite koolitusprotsess on samuti piiratud vaid spetsiifiliste tööde ja utiliitide komplektiga, mis ei anna üldist arusaama protsessidest ja nende seostest. See on kindlasti hea, kui inimene suudab kasutada Terraformi, et 10 minutiga AWS EKS-i välja tuua koos Fluentd külgkariga selles klastris ja AWS ELK stiilis logimisüsteemiga, kasutades vaid ühte käsku konsoolis. Kuid kui ta ei saa aru logide töötlemise põhimõttest ja nende vajalikkusest, ei tea, kuidas neid metoodikaid koguda ning teenuse degradatsiooni jälgida, jääb ta lihtsalt utiliite kasutavaks tehnikuks.

Küll aga toob nõudlus endaga kaasa pakkumise ning näeme äärmiselt ülekuumenenud DevOps positsioonide turgu, kus nõudmised ei vasta tegelikele rollidele ja võimaldavad süsteemi administreerijatel rohkem teenida.

Nii kes need siis on? DevOps’id või ahned süsteemi administreerijad? =)

Kuidas edasi elada?

Tööandjatele — täpsustage nõudmisi ja otsige just neid, kellel on tegelikult vajalikud oskused, mitte ärge pillake silte. Kui te ei tea, millega DevOps tegeleb, ei ole nad teile siis vajalikud.

Töötajad — Õppige. Jätkuvalt täiustage oma teadmisi, vaadake protsesside üldpilti ja jälgige teed seatud eesmärgini. Võite saada kelleks iganes, tuleb vaid pingutada.

Allikas: habr.com