Op die oomblik is dit amper die duurste posisie op die mark. Die ophef rondom “DevOps”-ingenieurs is buite alle denkbare perke, en nog erger met Senior DevOps-ingenieurs.
Ek werk as die hoof van die integrasie- en outomatiseringsafdeling, raai die Engelse dekodering - DevOps Manager. Dit is onwaarskynlik dat die Engelse transkripsie ons daaglikse aktiwiteite weerspieël, maar die Russiese weergawe in hierdie geval is meer akkuraat. Weens die aard van my aktiwiteit is dit natuurlik dat ek met toekomstige lede van my span onderhoude moet voer, en oor die afgelope jaar het ongeveer 50 mense deur my gegaan, en dieselfde getal is op voorafskerm met my werknemers afgesny.
Ons soek steeds kollegas, want agter die DevOps-etiket skuil daar 'n baie groot laag verskillende soorte ingenieurs.
Alles wat hieronder geskryf word is my persoonlike opinie, jy hoef nie daarmee saam te stem nie, maar ek gee toe dat dit bietjie kleur sal gee aan jou houding oor die onderwerp. Ten spyte van die risiko om in onguns te val, publiseer ek my mening omdat ek glo dat dit 'n plek het om te wees.
Maatskappye het verskillende begrippe van wie DevOps-ingenieurs is en, ter wille van vinnige huur van 'n hulpbron, hang hulle hierdie etiket aan almal. Die situasie is nogal vreemd, aangesien maatskappye gereed is om onrealistiese vergoeding aan hierdie mense te betaal, en in die meeste gevalle 'n gereedskapadministrateur vir hulle ontvang.
So wie is DevOps-ingenieurs?
Kom ons begin met die geskiedenis van sy voorkoms - Ontwikkelingsbedrywighede het verskyn as nog 'n stap in die rigting van die optimalisering van interaksie in klein spanne om die spoed van produkproduksie te verhoog, as 'n verwagte gevolg. Die idee was om die ontwikkelingspan te versterk met kennis van prosedures en benaderings in die bestuur van die produkomgewing. Met ander woorde, die ontwikkelaar moet verstaan en weet hoe sy produk in sekere omstandighede werk, moet verstaan hoe om sy produk te ontplooi, watter eienskappe van die omgewing aangepas kan word om prestasie te verbeter. So, vir 'n geruime tyd, het ontwikkelaars met 'n DevOps-benadering verskyn. DevOps-ontwikkelaars het bou- en verpakkingsskrifte geskryf om hul aktiwiteite en die werkverrigting van die produksie-omgewing te vereenvoudig. Die kompleksiteit van die oplossingsargitektuur en die wedersydse invloed van infrastruktuurkomponente het egter mettertyd die werkverrigting van die omgewings begin verswak; met elke iterasie is 'n toenemend dieper begrip van sekere komponente vereis, wat die produktiwiteit van die ontwikkelaar verminder het as gevolg van die bykomende koste om die komponente en instelstelsels vir 'n spesifieke taak te verstaan. . Die ontwikkelaar se eie koste het gegroei, die koste van die produk daarmee saam, die vereistes vir nuwe ontwikkelaars in die span het skerp gespring, want hulle moes ook die verantwoordelikhede van die ontwikkeling "ster" dek en natuurlik het die "sterre" minder geword en minder beskikbaar. Dit is ook opmerklik dat, volgens my ervaring, min ontwikkelaars belangstel in die besonderhede van pakketverwerking deur die bedryfstelselkern, pakketroeteerreëls en gasheersekuriteitsaspekte. Die logiese stap was om 'n administrateur te lok wat hiermee vertroud is en soortgelyke verantwoordelikhede aan hom toewys, wat, danksy sy ervaring, dit moontlik gemaak het om dieselfde aanwysers teen 'n laer koste te bereik in vergelyking met die koste van 'n "ster"-ontwikkeling. Sulke administrateurs is in 'n span geplaas en sy hooftaak was om toets- en produksieomgewings te bestuur, volgens die reëls van 'n spesifieke span, met hulpbronne wat aan hierdie spesifieke span toegeken is. Dit is hoe DevOps in werklikheid in die gedagtes van die meerderheid verskyn het.
Gedeeltelik of heeltemal, met verloop van tyd, het hierdie stelseladministrateurs die behoeftes van hierdie spesifieke span op die gebied van ontwikkeling begin verstaan, hoe om die lewe vir ontwikkelaars en toetsers makliker te maak, hoe om 'n opdatering uit te voer en nie Vrydag in te hoef te oornag in die kantoor, regstelling van ontplooiingsfoute. Die tyd het verbygegaan, en nou was die "sterre" stelseladministrateurs wat verstaan het wat ontwikkelaars wou hê. Om die impak te verminder, het bestuurshulpmiddels begin opduik; almal het die ou en betroubare metodes onthou om die OS-vlak te isoleer, wat dit moontlik gemaak het om die vereistes vir sekuriteit, bestuur van die netwerkdeel en die gasheerkonfigurasie as 'n minimum te beperk. geheel en gevolglik die vereistes vir nuwe “sterre” verminder.
'n "Wonderlike" ding het verskyn - docker. Hoekom wonderlik? Ja, net omdat die skep van isolasie in 'n chroot of tronk, sowel as OpenVZ, nie-triviale kennis van die bedryfstelsel vereis het, in teenstelling hiermee laat die hulpprogram jou toe om eenvoudig 'n geïsoleerde toepassingsomgewing op 'n sekere gasheer te skep met alles wat nodig is binne en hand. weer oor die leisels van ontwikkeling, en die stelseladministrateur kan net met net een gasheer bestuur, wat die sekuriteit en hoë beskikbaarheid daarvan verseker - 'n logiese vereenvoudiging. Maar vordering staan nie stil nie en stelsels word weer meer en meer kompleks, daar is al hoe meer komponente, een gasheer voldoen nie meer aan die behoeftes van die stelsel nie en dit is nodig om clusters te bou, ons keer weer terug na stelsel administrateurs wat in staat is om hierdie stelsels te bou.
Siklus na siklus verskyn verskeie stelsels wat ontwikkeling en/of administrasie vereenvoudig, orkestrasiestelsels verskyn wat, totdat jy van die standaardproses moet afwyk, maklik is om te gebruik. Mikrodiensargitektuur het ook verskyn met die doel om alles wat hierbo beskryf is te vereenvoudig - minder verhoudings, makliker om te bestuur. In my ervaring het ek nie 'n heeltemal mikrodiensargitektuur gevind nie, ek sou sê 50 tot 50 - 50 persent van mikrodienste, swart bokse, het ingekom, verwerk uitgekom, die ander 50 is 'n geskeurde monoliet, dienste wat nie apart van ander kan werk nie komponente. Dit alles het weer beperkings op die kennisvlak van beide ontwikkelaars en administrateurs opgelê.
Soortgelyke "swaaie" in die vlak van kundige kennis van 'n bepaalde hulpbron duur tot vandag toe. Maar ons dwaal 'n bietjie af, daar is baie punte wat die moeite werd is om uit te lig.
Bouingenieur/Vrystellingsingenieur
Baie hoogs gespesialiseerde ingenieurs wat na vore gekom het as 'n manier om sagtewarebouprosesse en vrystellings te standaardiseer. In die proses om wydverspreide Agile bekend te stel, wil dit voorkom asof hulle opgehou het om in aanvraag te wees, maar dit is ver van die geval. Hierdie spesialisasie het verskyn as 'n manier om die samestelling en aflewering van sagteware op 'n industriële skaal te standaardiseer, m.a.w. gebruik standaardtegnieke vir alle maatskappyprodukte. Met die koms van DevOps het ontwikkelaars hul funksies gedeeltelik verloor, aangesien dit die ontwikkelaars was wat die produk vir aflewering begin voorberei het, en gegewe die veranderende infrastruktuur en die benadering om so vinnig as moontlik te lewer sonder inagneming van kwaliteit, het dit mettertyd verander in 'n stop van veranderinge, aangesien die nakoming van kwaliteitstandaarde aflewerings onvermydelik vertraag. So, geleidelik, het 'n deel van die funksionaliteit van Bou/Vrystelling-ingenieurs na die skouers van stelseladministrateurs migreer.
Ops is so anders
Ons gaan voort en weer die teenwoordigheid van 'n groot verskeidenheid verantwoordelikhede en die gebrek aan gekwalifiseerde personeel dryf ons na streng spesialisasie, soos sampioene na reën, verskeie Operasies verskyn:
- TechOps - enikey stelsel administrateurs aka HelpDesk Engineer
- LiveOps - stelseladministrateurs wat hoofsaaklik verantwoordelik is vir produksie-omgewings
- CloudOps - stelseladministrateurs wat spesialiseer in openbare wolke Azure, AWS, GCP, ens.
- PlatOps/InfraOps/SysOps - infrastruktuurstelseladministrateurs.
- NetOps - netwerk administrateurs
- SecOps - stelseladministrateurs wat spesialiseer in inligtingsekuriteit - PCI-nakoming, CIS-nakoming, pleister, ens.
DevOps is (in teorie) 'n persoon wat eerstehands al die prosesse van die ontwikkelingsiklus verstaan - ontwikkeling, toetsing, die produkargitektuur verstaan, in staat is om sekuriteitsrisiko's te assesseer, vertroud is met benaderings en outomatiseringsinstrumente, ten minste op 'n hoë vlak, benewens hierdie, verstaan ook voor- en na-verwerking produk vrystelling ondersteuning. 'n Persoon wat in staat is om op te tree as 'n voorstander vir beide Bedryf en Ontwikkeling, wat gunstige samewerking tussen hierdie twee pilare moontlik maak. Verstaan die prosesse van die beplanning van werk deur spanne en die bestuur van klante se verwagtinge.
Om hierdie soort werk en verantwoordelikhede uit te voer, moet hierdie persoon die middele hê om nie net die ontwikkeling- en toetsprosesse te bestuur nie, maar ook die bestuur van die produkinfrastruktuur, sowel as hulpbronbeplanning. DevOps in hierdie begrip kan nie in IT, of in R&D, of selfs in die PMO geleë wees nie; dit moet invloed hê op al hierdie areas - die maatskappy se tegniese direkteur, Hoof Tegniese Beampte.
Is dit waar in jou maatskappy? - Ek twyfel. In die meeste gevalle is dit óf IT óf R&D.
Gebrek aan fondse en vermoë om ten minste een van hierdie drie areas van aktiwiteit te beïnvloed, sal die gewig van probleme verskuif na waar hierdie veranderinge makliker toegepas kan word, soos die toepassing van tegniese beperkings op vrystellings in verband met "vuil" kode volgens statiese ontleder stelsels. Dit wil sê, wanneer die PMO 'n streng sperdatum vir die vrystelling van funksionaliteit stel, kan R&D nie 'n hoë gehalte resultaat binne hierdie spertye lewer nie en lewer dit so goed dit kan, en laat herfaktorering vir later, DevOps wat met IT verband hou, blokkeer die vrystelling met behulp van tegniese middele . Gebrek aan gesag om die situasie te verander, in die geval van verantwoordelike werknemers, lei tot die manifestasie van hiper-verantwoordelikheid vir wat hulle nie kan beïnvloed nie, veral as hierdie werknemers foute verstaan en sien, en hoe om dit reg te stel - "Bliss is onkunde", en as gevolg van uitbranding en verlies van hierdie werknemers.
DevOps-hulpbronmark
Kom ons kyk na verskeie vakatures vir DevOps-posisies van verskillende maatskappye.
Ons is gereed om jou te ontmoet as jy:
- Jy besit Zabbix en weet wat Prometheus is;
- Iptables;
- BASH PhD Student;
- Professor Ansible;
- Linux Guru;
- Weet hoe om ontfouting te gebruik en toepassingsprobleme te vind saam met ontwikkelaars (php/java/python);
- Roetering maak jou nie histeries nie;
- Gee aansienlike aandag aan stelselsekuriteit;
- Rugsteun "enigiets en alles", en herstel ook hierdie "enigiets en alles" suksesvol;
- Jy weet hoe om die stelsel op so 'n manier te konfigureer om die maksimum uit die minimum te kry;
- Stel replikasie op voordat jy gaan slaap op Postgres en MySQL;
- Die opstel en aanpassing van CI/CD is vir jou so nodig soos ontbyt/middagete/aandete.
- Het ondervinding met AWS;
- Gereed om saam met die maatskappy te ontwikkel;
Dus:
- van 1 tot 6 - stelseladministrateur
- 7 - 'n bietjie netwerkadministrasie, wat ook inpas by die stelseladministrateur, Middelvlak
- 8 - 'n bietjie sekuriteit, wat verpligtend is vir 'n middelvlak-stelseladministrateur
- 9-11 – Middelstelseladministrateur
- 12 — Afhangende van die toegewysde take, óf middelstelseladministrateur óf bouingenieur
- 13 - Virtualisering - Middelstelseladministrateur, of die sogenaamde CloudOps, gevorderde kennis van die dienste van 'n spesifieke gasheerwebwerf, vir die doeltreffende gebruik van fondse en om die las op instandhouding te verminder
As ons hierdie vakature opsom, kan ons sê dat Middel/Senior Stelseladministrateur genoeg is vir die ouens.
Terloops, jy moet nie administrateurs op Linux/Windows sterk verdeel nie. Natuurlik verstaan ek dat die dienste en stelsels van hierdie twee wêrelde verskil, maar die basis vir almal is dieselfde en enige selfrespekende admin is vertroud met beide die een en die ander, en selfs al is hy nie bekend nie, sal dit nie moeilik wees vir 'n bevoegde admin om daarmee vertroud te raak nie.
Kom ons kyk na 'n ander vakature:
- Ondervinding in die bou van hoëladingstelsels;
- Uitstekende kennis van Linux-bedryfstelsel, algemene stelselsagteware en webstapel (Nginx, PHP/Python, HAProxy, MySQL/PostgreSQL, Memcached, Redis, RabbitMQ, ELK);
- Ondervinding met virtualisasiestelsels (KVM, VMWare, LXC/Docker);
- Vaardigheid in skriftale;
- Begrip van die bedryfsbeginsels van netwerkprotokolnetwerke;
- Begrip van die beginsels van die bou van foutverdraagsame stelsels;
- Onafhanklikheid en inisiatief;
Kom ons kyk na:
- 1 – Senior Stelseladministrateur
- 2 - Afhangende van die betekenis wat in hierdie stapel geplaas word - Middel/Senior Stelseladministrateur
- 3 - Werkservaring, insluitend, kan beteken - "Die groep het nie geskep nie, maar virtuele masjiene geskep en bestuur, daar was een Docker-gasheer, toegang tot houers was nie beskikbaar nie" - Middelstelseladministrateur
- 4 - Junior Stelseladministrateur - ja, 'n admin wat nie weet hoe om basiese outomatiseringsskrifte te skryf nie, ongeag die taal, nie 'n admin nie - enikey.
- 5 - Middelstelseladministrateur
- 6 – Senior Stelseladministrateur
Om op te som - Middel/Senior Stelseladministrateur
Nog een:
- Ontwikkel ondervinding;
- Ervaring in die gebruik van een of meer produkte om CI/CD-prosesse te skep. Gitlab CI sal 'n voordeel wees;
- Werk met houers en virtualisasie; As jy docker gebruik het, goed, maar as jy k8s gebruik het, wonderlik!
- Ervaring om in 'n ratse span te werk;
- Kennis van enige programmeertaal;
Kom ons kyk:
- 1 - Hmm... Wat bedoel die ouens? =) Heel waarskynlik weet hulle self nie wat daaragter skuil nie
- 2 - Bou-ingenieur
- 3 - Middelstelseladministrateur
- 4 - Sagte vaardigheid, ons sal dit nie vir nou oorweeg nie, hoewel Agile nog 'n ding is wat op 'n manier geïnterpreteer word wat gerieflik is.
- 5 - Te breedvoerig - dit kan 'n skriftaal of 'n saamgestelde een wees. Ek wonder of skryf in Pascal en Basic op skool hulle sal pas? =)
Ek wil ook graag 'n nota los oor punt 3 om die begrip te versterk waarom hierdie punt deur die stelseladministrateur gedek word. Kubernetes is net 'n orkestrasie, 'n instrument wat direkte opdragte na netwerkbestuurders en virtualisasie-/isolasiegashere toevou in 'n paar opdragte en jou in staat stel om kommunikasie met hulle abstrak te maak, dit is al. Kom ons neem byvoorbeeld 'bou raamwerk' Maak, wat ek terloops nie as 'n raamwerk beskou nie. Ja, ek weet van die mode om Make op enige plek te stoot, waar dit nodig is en nie nodig is nie – om Maven in Make byvoorbeeld ernstig toe te draai?
In wese is Make net 'n omhulsel oor die dop, wat die samestelling, koppeling en samestelling omgewingsbevele vereenvoudig, net soos k8s.
Ek het eenkeer 'n onderhoud met 'n ou gevoer wat k8's in sy werk bo-op OpenStack gebruik het, en hy het gepraat oor hoe hy dienste daarop ontplooi het, maar toe ek oor OpenStack gevra het, het dit geblyk dat dit geadministreer is, sowel as opgewek deur die stelsel administrateurs. Dink jy regtig dat 'n persoon wat OpenStack geïnstalleer het, ongeag watter platform hy agter hom gebruik, nie k8s kan gebruik nie? =)
Hierdie aansoeker is nie eintlik 'n DevOps nie, maar 'n stelseladministrateur en, om meer presies te wees, 'n Kubernetes Administrateur.
Kom ons vat weer 'n opsomming - Middel/Senior Stelseladministrateur sal genoeg wees vir hulle.
Hoeveel om te weeg in gram
Die reeks voorgestelde salarisse vir die aangeduide vakatures is 90k-200k
Nou wil ek 'n parallel trek tussen die geldelike belonings van Stelseladministrateurs en DevOps-ingenieurs.
In beginsel, om dinge te vereenvoudig, kan jy die grade op grond van werkservaring versprei, hoewel dit nie presies sal wees nie, maar vir die doeleindes van die artikel sal dit genoeg wees.
N ervaring:
- tot 3 jaar – Junior
- tot 6 jaar oud – Middel
- meer as 6 – Senior
Die werknemersoekwebwerf bied:
Stelseladministrateurs:
- Junior - 2 jaar - 50k vryf.
- Middel - 5 jaar - 70k vryf.
- Senior - 11 jaar - 100k vryf.
DevOps Ingenieurs:
- Junior - 2 jaar - 100k vryf.
- Middel - 3 jaar - 160k vryf.
- Senior - 6 jaar - 220k vryf.
Volgens die ervaring van “DevOps” is ervaring gebruik wat die SDLC op een of ander manier beïnvloed het.
Uit bogenoemde volg dit dat maatskappye in werklikheid nie DevOps nodig het nie, en ook dat hulle ten minste 50 persent van die aanvanklik beplande koste kan bespaar deur 'n Administrateur aan te stel; bowendien kan hulle die verantwoordelikhede van die persoon waarna hulle soek, duideliker definieer en vul die behoefte vinniger. Ons moet ook nie vergeet dat 'n duidelike verdeling van verantwoordelikhede ons in staat stel om die vereistes vir personeel te verminder, asook om 'n gunstiger atmosfeer in die span te skep, as gevolg van die afwesigheid van oorvleuelings. Die oorgrote meerderheid vakatures is vol nutsdienste en DevOps-etikette, maar dit is nie gebaseer op werklike vereistes vir 'n DevOps-ingenieur nie, slegs versoeke vir 'n nutsding-administrateur.
Die proses om DevOps-ingenieurs op te lei is ook net beperk tot 'n stel spesifieke werke, nutsprogramme en bied nie 'n algemene begrip van die prosesse en hul afhanklikhede nie. Dit is beslis goed as 'n persoon binne 10 minute AWS EKS kan ontplooi met behulp van Terraform, in samewerking met die Fluentd-syspan in hierdie groep en die AWS ELK-stapel vir die aantekenstelsel, deur slegs een opdrag in die konsole te gebruik, maar as hy nie die beginsel van die verwerking van selflogboeke en waarvoor dit nodig is, as jy nie weet hoe om statistieke daaroor in te samel en die agteruitgang van die diens op te spoor nie, dan sal dit steeds dieselfde enikey wees wat weet hoe om sommige nutsprogramme te gebruik.
Vraag skep egter aanbod, en ons sien 'n uiters oorverhitte mark vir die DevOps-posisie, waar die vereistes nie ooreenstem met die werklike rol nie, maar net stelseladministrateurs toelaat om meer te verdien.
So wie is hulle? DevOps of gierige stelseladministrateurs? =)
Hoe om voort te gaan om te lewe?
Werkgewers moet vereistes meer presies formuleer en soek na presies diegene wat nodig is, en nie etikette rondgooi nie. Jy weet nie wat DevOps doen nie - jy het hulle nie nodig in daardie geval nie.
Werkers - Leer. Verbeter jou kennis voortdurend, kyk na die algehele prentjie van prosesse en volg die pad na jou doelwit. Jy kan word wie jy wil, jy moet net probeer.
Bron: will.com