Kas yra „DevOps“?

Šiuo metu tai kone brangiausia pozicija rinkoje. Šurmulis apie „DevOps“ inžinierius viršija visas įsivaizduojamas ribas, o dar blogiau – vyresnieji „DevOps“ inžinieriai.
Dirbu integracijos ir automatizavimo skyriaus vedėju, spėju anglišką dekodavimą – DevOps Manager. Vargu ar angliška stenograma atspindi mūsų kasdienę veiklą, tačiau rusiška versija šiuo atveju yra tikslesnė. Dėl mano veiklos pobūdžio natūralu, kad reikia apklausti būsimus savo komandos narius, o per pastaruosius metus per mane praėjo apie 50 žmonių, tiek pat buvo atkirsta išankstiniame ekrane su mano darbuotojais.

Vis dar ieškome kolegų, nes už DevOps etiketės slepiasi labai didelis sluoksnis įvairių inžinierių.

Viskas, kas parašyta žemiau, yra mano asmeninė nuomonė, jūs neprivalote su ja sutikti, bet pripažįstu, kad tai pridės šiek tiek spalvos jūsų požiūriui į temą. Nepaisant rizikos iškristi iš palankumo, skelbiu savo nuomonę, nes tikiu, kad ji turi kur būti.

Įmonės skirtingai supranta, kas yra „DevOps“ inžinieriai, ir, norėdamos greitai pasamdyti išteklius, jos klijuoja šią etiketę ant kiekvieno. Situacija gana keista, nes įmonės yra pasiruošusios šiems žmonėms mokėti nerealius atlygius, dažniausiai gaudamos už juos įrankių administratorių.

Taigi, kas yra „DevOps“ inžinieriai?

Pradėkime nuo jo atsiradimo istorijos – „Development Operations“ pasirodė kaip dar vienas žingsnis optimizuojant sąveiką mažose komandose, siekiant padidinti produkto gamybos greitį, kaip tikėtasi pasekmė. Idėja buvo sustiprinti kūrėjų komandą žinant apie produktų aplinkos valdymo procedūras ir metodus. Kitaip tariant, kūrėjas turi suprasti ir žinoti, kaip jo produktas veikia tam tikromis sąlygomis, turi suprasti, kaip dislokuoti savo produktą, kokias aplinkos charakteristikas galima koreguoti, kad pagerintų našumą. Taigi kurį laiką pasirodė kūrėjai, turintys DevOps metodą. „DevOps“ kūrėjai parašė kūrimo ir pakavimo scenarijus, kad supaprastintų savo veiklą ir gamybinės aplinkos veikimą. Tačiau sprendimo architektūros sudėtingumas ir infrastruktūros komponentų tarpusavio įtaka laikui bėgant ėmė prastinti aplinkų veikimą; su kiekviena iteracija reikėjo vis gilesnio tam tikrų komponentų supratimo, o tai sumažino kūrėjo produktyvumą dėl papildomų išlaidos, susijusios su komponentų ir derinimo sistemų supratimu konkrečiai užduočiai atlikti. Augo paties kūrėjo savikaina, kartu su ja ir produkto savikaina, reikalavimai naujiems kūrėjams komandoje smarkiai šoktelėjo, nes reikėjo padengti ir kūrimo „žvaigždės“ pareigas, natūralu, kad „žvaigždžių“ sumažėjo. ir mažiau prieinama. Taip pat verta paminėti, kad, mano patirtimi, nedaug kūrėjų domisi operacinės sistemos branduolio paketų apdorojimo specifika, paketų nukreipimo taisyklėmis ir pagrindinio kompiuterio saugumo aspektais. Logiškas žingsnis buvo pritraukti su tuo susipažinusį administratorių ir priskirti jam panašias pareigas, o tai, dėka jo patirties, leido pasiekti tuos pačius rodiklius mažesnėmis sąnaudomis, palyginti su „žvaigždės“ plėtros kaina. Tokie administratoriai buvo sudėti į komandą, o pagrindinė jo užduotis buvo valdyti testavimo ir gamybos aplinkas, pagal konkrečios komandos taisykles, išteklius paskirstant būtent šiai komandai. Taip iš tikrųjų „DevOps“ atsirado daugumos galvose.

Iš dalies ar visiškai, laikui bėgant, šie sistemų administratoriai pradėjo suprasti šios konkrečios komandos poreikius kūrimo srityje, kaip palengvinti kūrėjų ir bandytojų gyvenimą, kaip įdiegti naujinimą ir nereikėtų nakvoti penktadienį biure, taisant diegimo klaidas. Laikas bėgo, o dabar „žvaigždės“ buvo sistemos administratoriai, kurie suprato, ko nori kūrėjai. Siekiant sumažinti poveikį, pradėjo atsirasti valdymo paslaugų, visi prisiminė senus ir patikimus OS lygio izoliavimo metodus, kurie leido sumažinti saugumo, tinklo dalies valdymo ir pagrindinio kompiuterio konfigūracijos reikalavimus. visuma ir dėl to sumažėja reikalavimai naujoms „žvaigždėms“.

Atsirado „nuostabus“ dalykas – dokeris. Kodėl nuostabus? Taip, tik todėl, kad norint sukurti izoliaciją „chroot“ ar kalėjime, taip pat „OpenVZ“, reikėjo nereikšmingų žinių apie OS, priešingai, įrankis leidžia tiesiog sukurti izoliuotą programos aplinką tam tikrame pagrindiniame kompiuteryje su viskuo, ko reikia viduje ir rankoje. vėl peržengti plėtros vadeles, o sistemos administratorius gali valdyti tik vieną pagrindinį kompiuterį, užtikrindamas jo saugumą ir aukštą pasiekiamumą – tai logiškas supaprastinimas. Tačiau pažanga nestovi vietoje ir sistemos vėl tampa vis sudėtingesnės, atsiranda vis daugiau komponentų, vienas kompiuteris nebeatitinka sistemos poreikių ir reikia kurti klasterius, vėl grįžtame prie sistemos administratorių, kurie yra gali sukurti šias sistemas.

Ciklas po ciklo atsiranda įvairios sistemos, kurios supaprastina kūrimą ir/ar administravimą, atsiranda orkestravimo sistemos, kuriomis, kol nereikia nukrypti nuo standartinio proceso, paprasta naudotis. „Microservice“ architektūra taip pat atsirado su tikslu supaprastinti viską, kas aprašyta aukščiau – mažiau ryšių, lengviau valdyti. Iš savo patirties aš neradau visiškai mikro paslaugų architektūros, sakyčiau, 50–50 - 50 procentų mikro paslaugų, juodųjų dėžių, atėjo, išėjo apdorotos, kitos 50 yra suplyšęs monolitas, paslaugos negali veikti atskirai nuo kitų. komponentai. Visa tai vėl apribojo tiek kūrėjų, tiek administratorių žinių lygį.

Panašūs konkretaus šaltinio ekspertinių žinių lygio „svyravimai“ tęsiasi iki šiol. Tačiau mes šiek tiek nukrypstame, yra daug dalykų, kuriuos verta pabrėžti.

Konstravimo inžinierius / Išleidimo inžinierius

Labai specializuoti inžinieriai, kurie pasirodė kaip priemonė standartizuoti programinės įrangos kūrimo procesus ir leidimus. Pristatant plačiai paplitusius „Agile“, atrodytų, kad jie nustojo būti paklausūs, tačiau tai toli gražu nėra. Ši specializacija atsirado kaip priemonė standartizuoti programinės įrangos surinkimą ir pristatymą pramoniniu mastu, t.y. naudojant standartinius metodus visiems įmonės produktams. Atsiradus „DevOps“, kūrėjai iš dalies prarado savo funkcijas, nes būtent kūrėjai pradėjo ruošti produktą pristatymui, o atsižvelgiant į besikeičiančią infrastruktūrą ir požiūrį į pristatymą kuo greičiau, neatsižvelgiant į kokybę, laikui bėgant jie tapo pokyčių stabdys, nes kokybės standartų laikymasis neišvengiamai sulėtina pristatymą. Taigi palaipsniui dalis „Build/Release“ inžinierių funkcionalumo perėjo ant sistemos administratorių pečių.

Operacijos yra labai skirtingos

Judame toliau ir vėl didelis pareigų spektras ir kvalifikuoto personalo trūkumas stumia mus griežtos specializacijos link, kaip grybai po lietaus, atsiranda įvairios Operacijos:

• TechOps – enikey sistemos administratoriai, dar žinomi kaip HelpDesk Engineer
• LiveOps – sistemos administratoriai, pirmiausia atsakingi už gamybos aplinkas
• CloudOps – sistemos administratoriai, besispecializuojantys viešuosiuose debesyse Azure, AWS, GCP ir kt.
• PlatOps/InfraOps/SysOps – infrastruktūros sistemų administratoriai.
• NetOps – tinklo administratoriai
• SecOps – sistemos administratoriai, besispecializuojantys informacijos saugumo – PCI atitikties, CIS atitikties, pataisymo ir kt.

DevOps (teoriškai) yra asmuo, kuris iš pirmų lūpų supranta visus kūrimo ciklo procesus – kūrimą, testavimą, supranta produkto architektūrą, geba įvertinti saugumo riziką, yra susipažinęs su metodais ir automatizavimo įrankiais, bent jau aukštu lygiu. lygis, be to, taip pat supranta išankstinį ir po apdorojimo. produkto išleidimo palaikymas. Asmuo, galintis veikti kaip operacijų ir plėtros advokatas, o tai leidžia palankiai bendradarbiauti tarp šių dviejų ramsčių. Suvokia komandų darbo planavimo ir klientų lūkesčių valdymo procesus.

Norint atlikti tokį darbą ir atlikti tokias pareigas, šis asmuo turi turėti priemones valdyti ne tik kūrimo ir testavimo procesus, bet ir produkto infrastruktūros valdymą bei išteklių planavimą. DevOps pagal šį supratimą negali būti nei IT, nei MTEP ar net PMO; jis turi turėti įtakos visose šiose srityse - įmonės techninis direktorius, vyriausiasis techninis pareigūnas.

Ar tai tiesa jūsų įmonėje? - Aš abejoju. Daugeliu atvejų tai yra IT arba MTEP.

Trūkstant lėšų ir galimybės paveikti bent vieną iš šių trijų veiklos sričių, problemų svoris bus nukreiptas ten, kur šiuos pakeitimus lengviau pritaikyti, pavyzdžiui, techninių apribojimų taikymas leidimams, susijusiems su „nešvariu“ kodu pagal statinį analizatorių sistemos. Tai yra, kai PMO nustato griežtą funkcionalumo išleidimo terminą, MTEP negali duoti kokybiško rezultato per šiuos terminus ir sukuria jį kuo geriau, palikdamas pertvarkymą vėlesniam laikui, su IT susijęs DevOps blokuoja išleidimą techninėmis priemonėmis. . Valdžios stoka pakeisti situaciją, kalbant apie atsakingus darbuotojus, pasireiškia hiperatsakomybe už tai, ko jie negali paveikti, ypač jei šie darbuotojai supranta ir mato klaidas ir kaip jas ištaisyti - „Palaima yra nežinojimas“, ir dėl to šių darbuotojų perdegimas ir praradimas.

„DevOps“ išteklių rinka

Pažvelkime į keletą laisvų DevOps pozicijų iš skirtingų įmonių.

Esame pasirengę susitikti su jumis, jei:

1. Jums priklauso Zabbix ir žinote, kas yra Prometėjas;
2. Iptables;
3. BASH doktorantas;
4. profesorius Ansible;
5. Linux Guru;
6. Žinoti, kaip naudoti derinimą ir kartu su kūrėjais rasti programų problemas (php/java/python);
7. Maršrutas nekelia jūsų isterijos;
8. Skirkite daug dėmesio sistemos saugumui;
9. Kurkite atsarginę kopiją „viskas ir viskas“, taip pat sėkmingai atkurkite šį „viską ir viską“;
10. Mokate sistemą sukonfigūruoti taip, kad iš minimumo gautumėte maksimumą;
11. Prieš eidami miegoti nustatykite replikaciją „Postgres“ ir „MySQL“;
12. CI/CD nustatymas ir reguliavimas yra toks pat reikalingas kaip pusryčiai/pietūs/vakarienė.
13. Turi patirties dirbant su AWS;
14. Pasiruošę tobulėti kartu su įmone;

Taigi:

• nuo 1 iki 6 - sistemos administratorius
• 7 - mažas tinklo administravimas, kuris taip pat tinka sistemos administratoriui, vidurinis lygis
• 8 - šiek tiek saugumo, kuris yra privalomas Vidutinio lygio sistemos administratoriui
• 9-11 – Vidurinės sistemos administratorius
• 12 – Priklausomai nuo priskirtų užduočių, vidurinis sistemos administratorius arba statybos inžinierius
• 13 - Virtualizacija - Vidurinis sistemos administratorius arba vadinamasis CloudOps, pažangios žinios apie konkrečios prieglobos svetainės paslaugas, skirtas efektyviai naudoti lėšas ir sumažinti priežiūros apkrovą

Apibendrinant šią laisvą vietą, galima teigti, kad vaikinams užtenka Vidurio/Vyresniojo sistemos administratoriaus.

Beje, neturėtumėte stipriai skirstyti administratorių Linux / Windows. Žinoma, aš suprantu, kad šių dviejų pasaulių paslaugos ir sistemos yra skirtingos, bet pagrindas visiems yra tas pats ir bet kuris save gerbiantis administratorius yra susipažinęs ir su vienu, ir su kitu, ir net jei jis nėra susipažinęs Kompetentingam administratoriui nebus sunku su tuo susipažinti.

Panagrinėkime dar vieną laisvą darbo vietą:

1. Didelės apkrovos sistemų statybos patirtis;
2. Puikus Linux OS, bendrosios sistemos programinės įrangos ir web stack išmanymas (Nginx, PHP/Python, HAProxy, MySQL/PostgreSQL, Memcached, Redis, RabbitMQ, ELK);
3. Patirtis dirbant su virtualizacijos sistemomis (KVM, VMWare, LXC/Docker);
4. Scenarijų kalbų mokėjimas;
5. Tinklo protokolų tinklų veikimo principų supratimas;
6. Gedimams atsparių sistemų kūrimo principų supratimas;
7. Savarankiškumas ir iniciatyvumas;

Pažiūrėkime:

• 1 – vyresnysis sistemos administratorius
• 2 – Priklausomai nuo reikšmės, įdėtos į šį krūvą – vidurinis/vyresnysis sistemos administratorius
• 3 – Darbo patirtis, įskaitant, gali reikšti – „Klasteris nekėlė, o kūrė ir tvarkė virtualias mašinas, buvo vienas „Docker“ kompiuteris, prieiga prie konteinerių nebuvo“ – vidurinės sistemos administratorius
• 4 – Jaunesnysis sistemos administratorius – taip, administratorius, kuris nemoka rašyti pagrindinių automatizavimo scenarijų, nepriklausomai nuo kalbos, o ne administratorius – enikey.
• 5 – vidurinis sistemos administratorius
• 6 – vyresnysis sistemos administratorius

Apibendrinant – vidurinis/vyresnysis sistemos administratorius

Kitas:

1. Devops patirtis;
2. Patirtis naudojant vieną ar daugiau produktų kuriant CI/CD procesus. Gitlab CI būtų privalumas;
3. Darbas su konteineriais ir virtualizacija; Jei naudojote docker, gerai, bet jei naudojote k8s, puiku!
4. Patirtis dirbant judrioje komandoje;
5. Bet kokios programavimo kalbos išmanymas;

Pažiūrėkime:

• 1 - Hmm... Ką reiškia vaikinai? =) Greičiausiai jie patys nežino, kas už to slypi
• 2 – statybos inžinierius
• 3 – vidurinis sistemos administratorius
• 4 - Minkšti įgūdžiai, kol kas to nesvarstysime, nors judrus yra kitas dalykas, kuris interpretuojamas patogiai.
• 5 – Per daug išsami – tai gali būti scenarijų kalba arba kompiliuota kalba. Įdomu, ar jiems tiks rašymas Pascal ir Basic kalbomis mokykloje? =)

Taip pat norėčiau palikti pastabą dėl 3 punkto, kad geriau suprastų, kodėl šį punktą apima sistemos administratorius. „Kubernetes“ yra tik orkestruotė, įrankis, kuris tiesiogines komandas tinklo tvarkyklėms ir virtualizavimo / izoliavimo pagrindiniams kompiuteriams sujungia į keletą komandų ir leidžia jums bendrauti su jais abstrakčiai. Pavyzdžiui, paimkime „build framework“ Make, kurio, beje, aš nelaikau karkasu. Taip, aš žinau apie madą stumdyti Make bet kur, kur reikia ir nereikia - pavyzdžiui, rimtai vynioti Maven į Make?
Iš esmės Make yra tik apvalkalas, supaprastinantis kompiliavimo, susiejimo ir kompiliavimo aplinkos komandas, kaip ir k8s.

Kartą apklausiau vaikiną, kuris naudojo k8s savo darbe OpenStack viršuje, ir jis papasakojo apie tai, kaip jame diegė paslaugas, tačiau kai paklausiau apie OpenStack, paaiškėjo, kad jis buvo administruojamas, taip pat iškeltas sistemos. administratoriai. Ar tikrai manote, kad žmogus, įdiegęs OpenStack, nepriklausomai nuo to, kokią platformą naudoja už savęs, negali naudotis k8s? =)
Šis pareiškėjas iš tikrųjų nėra „DevOps“, o sistemos administratorius ir, tiksliau, „Kubernetes“ administratorius.

Dar kartą apibendrinkime – jiems užteks vidurinio/vyresniojo sistemos administratoriaus.

Kiek sverti gramais

Siūlomų atlyginimų diapazonas nurodytoms laisvoms darbo vietoms yra 90-200 tūkst
Dabar norėčiau atkreipti paralelę tarp sistemos administratorių ir „DevOps“ inžinierių piniginio atlygio.

Iš esmės, norint supaprastinti dalykus, galite išsklaidyti pažymius pagal darbo patirtį, nors tai nebus tikslus, bet straipsnio tikslams to pakaks.

Patirtis:

1. iki 3 metų – Jaunesnysis
2. iki 6 metų – Vidurinis
3. daugiau nei 6 – Vyresnysis

Darbuotojų paieškos svetainė siūlo:
Sistemos administratoriai:

1. Jaunimas - 2 metai - 50 tūkst.
2. Vidutinis - 5 metai - 70 tūkst.
3. Vyresnysis - 11 metų - 100 tūkst.

„DevOps“ inžinieriai:

1. Jaunimas - 2 metai - 100 tūkst.
2. Vidutinis - 3 metai - 160 tūkst.
3. Vyresnysis - 6 metų - 220 tūkst.

Remiantis „DevOps“ patirtimi, buvo panaudota patirtis, kuri bent kažkaip paveikė SDLC.

Iš to, kas išdėstyta aukščiau, darytina išvada, kad iš tikrųjų įmonėms nereikia DevOps, taip pat, kad jos galėtų sutaupyti bent 50 procentų iš pradžių planuotų išlaidų pasamdusios administratorių, be to, jos galėtų aiškiau apibrėžti ieškomo asmens pareigas. ir greičiau užpildykite poreikį. Taip pat nereikėtų pamiršti, kad aiškus pareigų pasiskirstymas leidžia sumažinti reikalavimus personalui, taip pat sukurti palankesnę atmosferą kolektyve, nesant sutapimų. Didžioji dauguma laisvų darbo vietų yra pilnos komunalinių paslaugų ir „DevOps“ etikečių, tačiau jos nėra pagrįstos faktiniais „DevOps“ inžinieriaus reikalavimais, o tik įrankio administratoriaus užklausomis.

DevOps inžinierių rengimo procesas taip pat apsiriboja tik konkrečių darbų, komunalinių paslaugų rinkiniu ir nesuteikia bendro supratimo apie procesus ir jų priklausomybes. Tikrai gerai, kai žmogus gali per 10 minučių įdiegti AWS EKS naudodamas Terraform kartu su Fluentd šonine priekaba ir registravimo sistemos AWS ELK krūva per XNUMX minučių, naudodamas tik vieną komandą konsolėje, bet jei nesupranta Pats žurnalų apdorojimo principas ir kam jie reikalingi, jei nežinai, kaip rinkti juose metriką ir sekti paslaugos blogėjimą, tai vis tiek bus tas pats enikey, kuris moka naudotis kai kuriomis komunalinėmis paslaugomis.

Tačiau paklausa sukuria pasiūlą ir matome itin perkaitusią DevOps pozicijų rinką, kur reikalavimai neatitinka tikrojo vaidmens, o tik leidžia daugiau uždirbti sistemos administratoriams.

Taigi kas jie tokie? DevOps ar godūs sistemos administratoriai? =)

Kaip toliau gyventi?

Darbdaviai turėtų tiksliau suformuluoti reikalavimus ir ieškoti būtent tų, kurių reikia, o ne mėtyti etiketes. Jūs nežinote, ką daro „DevOps“ – tokiu atveju jums jų nereikia.

Darbuotojai – mokykis. Nuolat tobulinkite savo žinias, pažiūrėkite į bendrą procesų vaizdą ir sekite kelią link savo tikslo. Galite tapti kuo tik norite, tereikia pabandyti.

Šaltinis: www.habr.com