I øjeblikket er dette næsten den dyreste position på markedet. Der er en helt usædvanlig opskrift på «DevOps» ingenører, mens forholdene for Senior DevOps ingenører er endnu mere udfordrende.
Jeg arbejder som leder af integrations- og automatiseringsafdelingen, så gæt den engelske forkortelse — DevOps Manager. Reflekterer den engelske version præcist vores daglige arbejde? Næppe, men den russiske betegnelse er mere præcis i dette tilfælde. I mit job er det naturligvis nødvendigt for mig at interviewe potentielle nye medlemmer af mit team, og i løbet af det seneste år har jeg haft omkring 50 ansøgere igennem, og lige så mange er blevet sorteret fra efter mine medarbejderes præscreening.
Vi er stadig på udkig efter kolleger, da der under betegnelsen DevOps gemmer sig en stor og varieret gruppe ingeniører.
Alt, hvad der står nedenfor, er min personlige mening; du er ikke forpligtet til at være enig, men jeg tillader mig at tro, at det kan give et nuanceret perspektiv på emnet. På trods af risikoen for at træde forkert offentliggør jeg mit synspunkt, fordi jeg mener, der er plads til det.
Virksomheder har forskellige opfattelser af, hvem DevOps ingeniører er, og for hurtigt at ansætte arbejdskraft hænger de denne etikette på alle. Situationen er ret mærkelig, da virksomheder er villige til at betale uhørte beløb til disse mennesker, mens de ofte kun får en administrator-mulighed i stedet.
Så hvem er DevOps ingeniører egentlig?
Lad os starte med historien om udviklingen – Development Operations opstod som et endnu et skridt hen imod at optimere samarbejdet i små teams for at øge hastigheden i produktionsprocessen som en forventet konsekvens. Ideen var at styrke udviklingsteamet med viden om processer og metoder i produktmiljøstyring. Med andre ord skal en udvikler forstå, hvordan hans produkt fungerer under forskellige forhold, forstå hvordan man deployer sit produkt, og hvilke miljøkarakteristika der skal justeres for at forbedre ydeevnen. På den måde opstod der over tid udviklere med en DevOps tilgang. DevOps udviklere skrev build- og pakkescripts for at forenkle deres opgaver og funktionaliteten i det produktive miljø. Men kompleksiteten i arkitekturen af løsninger og interaktionen mellem infrastrukturkomponenter begyndte med tiden at forværre arbejdseffektiviteten i miljøerne; med hver iteration krævedes der dybere forståelse af diverse komponenter, hvilket sænkede selve udviklerens produktivitet på grund af de ekstra omkostninger ved at forstå komponenterne og tilpasse systemer til specifikke opgaver. Den reelle omkostning for udvikleren voksede, ligesom produktets omkostning, og kravene til nye udviklere i teamet steg markant, da de også skulle dække de opgaver, som "stjernen" i udviklingen havde. Og naturligvis blev "stjernerne" mindre tilgængelige. Det er også værd at nævne, at efter min erfaring er der ikke mange udviklere, der er interesseret i detaljerne omkring pakkehåndtering i operativsystemets kerne, regler for pakketrafik og aspekter af værtssikkerhed. Det logiske skridt var at involvere en administrator, som netop har erfaring med dette, og pålægge sådanne opgaver til ham, hvilket, takket være hans erfaring, muliggør at nå de samme målsætninger til en lavere omkostning sammenlignet med omkostningerne ved en "stjerne" i udviklingen. Disse administratorer blev integreret i teamet med det primære mål at styre test- og produktionsmiljøer, baseret på reglerne for det specifikke team, med ressourcer tildelt netop dette team. På den måde opstod DevOps som de fleste kender dem.
Over time, partially or completely, system administrators began to understand the needs of this specific development team—how to simplify the lives of developers and testers, how to roll out updates without staying overnight in the office on a Friday to fix deployment errors. As time went by, system administrators became the 'stars,' understanding what developers wanted. To minimize impact, management utilities started to emerge, and everyone remembered the old and reliable OS-level isolation methods that minimized security, network management requirements, and overall host configuration, consequently reducing demands on the new 'stars.'
A 'wonderful' thing emerged—Docker. Why is it wonderful? Simply because creating isolation in chroot or jail, just like OpenVZ, required non-trivial OS knowledge, while the utility allows you to easily create an isolated application environment on a host with everything you need inside, handing control back to developers while the system administrator only has to manage one host, ensuring its security and high availability—logical simplification. But progress does not stand still, and systems are becoming increasingly complex, with more and more components; one host no longer meets system needs, and it is necessary to build clusters, bringing us back to system administrators who can construct these systems.
Cycle after cycle, various systems emerge to simplify development and/or administration, along with orchestration systems that remain easy to use—up until the point where there is a deviation from the standard process. Microservice architecture also emerged to simplify all of the above—fewer interconnections, easier management. In my experience, I have not encountered a fully microservice architecture; I would say it's 50/50—50 percent microservices, black boxes that take input and return processed output, and 50 percent a fragmented monolith, where services cannot function independently of other components. All of this again placed limitations on the knowledge levels required of both developers and administrators.
De samme "gynger" af ekspertviden om en eller anden ressource fortsætter den dag i dag. Men vi blev lidt distraheret, der er mange aspekter, som det er værd at belyse.
Build Engineer/Release Engineer
Meget specialiserede ingeniører, der opstod som et middel til at standardisere processerne for softwarebygning og udgivelser. I takt med indførelsen af den udbredte Agile metode syntes de at være blevet irrelevante, men det er langt fra tilfældet. Denne specialisering blev skabt som en måde at standardisere netop bygning og levering af software i industriel skala, dvs. ved at bruge standardteknikker for alle virksomhedens produkter. Med fremkomsten af DevOps har udviklerne delvist mistet funktioner, da det netop er udviklerne, der er kommet til at forberede produktet til levering, og med den ændrede infrastruktur og tilgang til hurtig levering uden hensyntagen til kvalitet er de over tid blevet en hindring for ændringer, da overholdelse af kvalitetsstandarder uundgåeligt bremser leveringen. Således er en del af funktionaliteten fra Build/Release ingeniørerne gradvist flyttet til systemadministratorerne.
Ops’erne er så forskellige
Vi bevæger os videre, og atter en gang presser mange opgaver og mangel på kvalificeret arbejdskraft os til stærk specialisering; som svampe efter regn dukker forskellige operations-specialiseringer op:
- TechOps — systemadministratorer af en art aka HelpDesk Engineer
- LiveOps — systemadministratorer, primært ansvarlige for produktionsmiljøer
- CloudOps — systemadministratorer, der specialiserer sig i offentlige "skyer" som Azure, AWS, GCP osv.
- PlatOps/InfraOps/SysOps — systemadministratorer inden for infrastruktur.
- NetOps — netværksadministratorer
- SecOps — systemadministratorer, der specialiserer sig i informationssikkerhed — PCI compliance, CIS compliance, patching osv.
DevOps — en person, der i teorien forstår alle processer i udviklingscyklussen — udvikling, test, forstår produktets arkitektur, er i stand til at vurdere sikkerhedsrisici, bekendt med tilgange og automatiseringsmidler, om end på et højt niveau, samt forstå også for- og efter-udgivelsesstøtte af produktet. En person, der kan fungere som advokat både for Operations og Development, hvilket muliggør et frugtbart samarbejde mellem disse to søjler. Forstår arbejdsplanlægningsprocessen i teamet og håndteringen af kundernes forventninger.
For at udføre denne slags arbejde og opgaver bør denne person have evner til at styre ikke kun udviklings- og testprocesserne, men også infrastrukturen for produktet samt ressourcestyring. DevOps i denne forståelse kan ikke være begrænset til IT, R&D eller endda PMO; han skal have indflydelse på alle disse områder — teknisk direktør i virksomheden, Chief Technical Officer.
Er det sådan i din virksomhed? — Jeg tvivler. I de fleste tilfælde er det enten IT eller R&D.
Mangel på ressourcer og mulighed for at påvirke mindst én af disse tre aktivitetsretninger vil flytte vægten af problemerne mod de steder, hvor disse ændringer er lettere at anvende, som for eksempel ved at pålægge tekniske begrænsninger på udgivelser på grund af «besmudset» kode ifølge data fra statiske analyseværktøjer. Det vil sige, når PMO sætter en streng deadline for udgivelsen af funktionalitet, kan R&D ikke levere et kvalitetsresultat inden for denne tidsramme og udleverer det, som de kan, og efterlader refaktorering til senere. DevOps, der tilhører IT, blokerer udgivelsen med tekniske midler. Mangel på beføjelser til at ændre situationen, når ansvarlige medarbejdere er involveret, fører til hyperansvarlighed for det, de ikke kan påvirke, især hvis disse medarbejdere forstår og kan se fejlene samt hvordan de skal rettes — «lykke i uvidenhed», og som konsekvens heraf til udbrændthed og tab af disse medarbejdere.
Markedsplads for DevOps-ressourcer
Lad os se på nogle jobopslag til DevOps-stillinger fra forskellige virksomheder.
Vi er klar til at mødes med dig, hvis du:
- Har kendskab til Zabbix og ved, hvad Prometheus er;
- Iptables;
- Stipendiat i BASH;
- Professor i Ansible;
- Guru i Linux;
- Kan du bruge debugging og sammen med udviklerne finde problemer i applikationer (php/java/python);
- Routing giver dig ikke hysteriske anfald;
- Du lægger stor vægt på systemets sikkerhed;
- Du laver backup af "alt og enhver", og du gendanner succesfuldt dette "alt og enhver";
- Du ved, hvordan du kan optimere systemet til at få det maksimale ud af det minimale;
- Du opsætter replikationer inden sengetid på Postgres og MySQL;
- Opsætning og justering af CI/CD er for dig en nødvendighed som morgenmad/frokost/aftensmad.
- Du har erfaring med AWS;
- Du er klar til at udvikle dig sammen med virksomheden;
Så:
- fra 1 til 6 - systemadministrator
- 7 - lidt netværksadministration, hvilket også falder ind under systemadministratorniveauet Middle
- 8 - lidt sikkerhed, som er obligatorisk for en systemadministrator på Middle niveau
- 9-11 - Middle System Administrator
- 12 - Afhængigt af de opgaver, der stilles, enten Middle System Administrator eller Build Engineer
- 13 - Virtualisering - Middle System Administrator, eller såkaldt CloudOps, udvidede kendskab til de specifikke tjenester hosting for effektiv brug af penge og reduktion af belastningen på vedligeholdelsen
Sammenfattende om denne stilling kan man sige, at drengene blot behøver en Middle/Senior System Administrator.
Forresten, man bør ikke skille administratorer alt for meget op i Linux/Windows. Jeg forstår godt, at tjenesterne og systemerne i disse to verdener adskiller sig, men fundamentet er det samme, og enhver respektabel administrator kender til både det ene og det andet. Og selvom man ikke er bekendt med begge, vil det ikke være et problem for en dygtig administrator at sætte sig ind i det.
Lad os overveje en anden stilling:
- Erfaring med opbygning af højbelastede systemer;
- Fremragende viden om OS Linux, systemsoftware og webstack (Nginx, PHP/Python, HAProxy, MySQL/PostgreSQL, Memcached, Redis, RabbitMQ, ELK);
- Erfaring med virtualiseringssystemer (KVM, VMWare, LXC/Docker);
- Begribelse af scripting-sprog;
- Forståelse af netværksprotokollers principper;
- Forståelse af principperne for at bygge fejltolerante systemer;
- Selvstændighed og initiativ;
Vi analyserer:
- 1 - Senior System Administrator
- 2 - Afhænger af den mening, vi lægger i denne stak - Middle/Senior System Administrator
- 3 - Erfaring kan også betyde - "Jeg har ikke oprettet klynger, men har oprettet og styret virtuelle maskiner, der var en Docker-vært, adgang til containere var konfigureret" - Middle System Administrator
- 4 — Junior System Administrator — ja, en administrator der ikke kan skrive elementære automatiseringsscripts, uanset sprog, er ikke en administrator — bare en tekniker.
- 5 — Middle System Administrator
- 6 — Senior System Administrator
Sammenfattende — Middle/Senior System Administrator
Én ting mere:
- Erfaring med devops;
- Erfaring med brug af et eller flere produkter til at etablere CI/CD-processer. Gitlab CI vil være en fordel;
- Arbejdet med containere og virtualisering; Hvis du har brugt docker – godt, og hvis k8s – fremragende!
- Erfaring med at arbejde i et agile team;
- Kendskab til et hvilket som helst programmeringssprog;
Lad os se:
- 1 — Hmm… Hvad mener de? =) Sandsynligvis ved de heller ikke, hvad der ligger bag dette
- 2 — Build Engineer
- 3 — Middle System Administrator
- 4 — Soft skills, lad os ikke diskutere det endnu, selvom Agile er endnu en ting, som tolkes, som det passer.
- 5 — For vag — det kan være et scriptsprog eller et kompileret sprog. Jeg undrer mig, vil det være okay, hvis jeg skrev i skolen på Pascal og Basic? =)
Jeg vil også gerne bemærke noget vedrørende punkt 3, for at styrke forståelsen af, hvorfor dette punkt dækkes af systemadministratoren. Kubernetes er blot orkestrering, et værktøj der indkapsler direkte kommandoer til netværksdrivere og virtualiserings-/isolationsværter i et par kommandoer og gør kommunikationen med dem abstrakt, det er alt. For eksempel lad os tage 'build framework' Make, som jeg for øvrigt ikke anser for en framework. Ja, jeg ved, at der er en mode at putte Make alle vegne, hvor det er nødvendigt og unødvendigt — at indkapsle Maven i Make for eksempel, seriøst?
I bund og grund er Make blot en indpakning af shell, der forenkler præcist kommanderne for kompilering, linking og kompilationsmiljø, ligesom k8s.
Engang interviewede jeg en fyr, der brugte k8s i sit arbejde ovenpå OpenStack, og han fortalte, hvordan han deployede tjenester på det, men da jeg spurgte ham specifikt om OpenStack, viste det sig, at det administreres, ligesom det startes af systemadministratorer. Tror du virkelig, at en person der kan starte OpenStack uanset hvilken platform han bruger bagved, ikke er i stand til at bruge k8s? =)
Denne kandidat er faktisk ikke DevOps, men en almindelig System Administrator og, for at være mere præcis, Kubernetes Administrator.
Lad os sammenfatte igen — Middle/Senior System Administrator vil være tilstrækkeligt for dem.
Hvor meget vejer 100 gram
Spændet af de foreslåede lønninger for de nævnte stillinger — 90k-200k
Nu vil jeg gerne trække en parallel mellem lønningerne for systemadministratorer og DevOps-ingeniører.
For enkelthedens skyld kan vi fordele grader baseret på erfaring, selvom det ikke vil være præcist, vil det være tilstrækkeligt til artikelens formål.
Erfaring:
- op til 3 år — Junior
- op til 6 år — Middle
- mere end 6 år — Senior
Jobportalen tilbyder:
Systemadministratorer:
- Junior — 2 år — 50k rub.
- Middle — 5 år — 70k rub.
- Senior — 11 år — 100k rub.
DevOps-ingeniører:
- Junior — 2 år — 100k rub.
- Middle — 3 år — 160k rub.
- Senior — 6 år — 220k rub.
For erfaringen med 'DevOps' blev der taget hensyn til erfaring, der på en eller anden måde berører SDLC.
Af det foregående følger det, at virksomhederne faktisk ikke har brug for DevOps, og de kunne have sparet mindst 50 procent af de oprindeligt planlagte omkostninger ved at ansætte en administrator. Desuden kunne de have defineret de ønskede opgaver mere klart og hurtigere lukket behovet. Man må heller ikke glemme, at klart adskilte ansvarsområder kan reducere kravene til personalet og skabe en mere gunstig atmosfære i teamet på grund af fraværet af overlap. I langt de fleste jobannoncer svømmer det i værktøjer og DevOps-labels, men de indeholder ikke reelle krav til en DevOps-ingeniør, men blot krav til en værktøjsadministrator.
Uddannelsesprocessen for DevOps-ingeniører er også begrænset til et sæt specifikke opgaver og værktøjer, der ikke giver en generel forståelse af processerne og deres afhængigheder. Det er selvfølgelig godt, når en person kan bruge Terraform til at deployere AWS EKS i sammenhæng med en Fluentd sidecar i dette cluster og AWS ELK-stakken til logningssystemet på 10 minutter ved blot at bruge én kommando i konsollen, men hvis han ikke forstår selve principperne for logbehandling og hvad de er til, ikke ved hvordan man indsamler metrics fra dem og sporer serviceafmatningen, så vil det stadig være en enikey, der kan bruge nogle værktøjer.
Efterspørgslen skaber dog udbud, og vi ser et ekstremt overophedet marked for DevOps-positioner, hvor kravene ikke svarer til den reelle rolle, men blot tillader systemadministratorer at tjene mere.
Så hvem er de? DevOps eller grådige systemadministratorer? =)
Hvordan skal man så leve fremover?
Arbejdsgivere – at formulere kravene mere præcist og finde præcis de personer, der er nødvendige, og ikke blot kaste om sig med etiketter. Hvis du ikke ved, hvad DevOps laver, så har du ikke brug for dem.
Arbejdstagere – at lære. Kontinuerligt forbedre sine færdigheder, få et overblik over processerne og følge vejen til det satte mål. Man kan blive hvad som helst, man skal blot gøre en indsats.
Kilde: habr.com
