I øjeblikket er dette næsten den dyreste stilling på markedet. Balladen omkring "DevOps"-ingeniører er ud over alle tænkelige grænser, og endnu værre med Senior DevOps-ingeniører.
Jeg arbejder som leder af integrations- og automationsafdelingen, gæt den engelske afkodning - DevOps Manager. Det er usandsynligt, at den engelske udskrift afspejler vores daglige aktiviteter, men den russiske version i dette tilfælde er mere nøjagtig. På grund af min aktivitets karakter er det naturligt, at jeg skal interviewe fremtidige medlemmer af mit team, og i løbet af det seneste år har omkring 50 personer været forbi mig, og det samme antal er blevet afskåret på forhåndsskærm med mine medarbejdere.
Vi leder stadig efter kolleger, for bag DevOps-mærket gemmer der sig et meget stort lag af forskellige slags ingeniører.
Alt skrevet nedenfor er min personlige mening, du behøver ikke være enig i det, men jeg indrømmer, at det vil sætte lidt farve på din holdning til emnet. På trods af risikoen for at falde i unåde, offentliggør jeg min mening, fordi jeg mener, at den har et sted at være.
Virksomheder har forskellige forståelser af, hvem DevOps-ingeniører er, og af hensyn til hurtigt at ansætte en ressource, hænger de denne etiket på alle. Situationen er ret mærkelig, da virksomheder er klar til at betale urealistiske vederlag til disse mennesker, og de modtager i de fleste tilfælde en værktøjsadministrator for dem.
Så hvem er DevOps-ingeniører?
Lad os starte med historien om dets udseende - Development Operations fremstod som endnu et skridt i retning af at optimere interaktionen i små teams for at øge hastigheden af produktproduktionen, som en forventet konsekvens. Tanken var at styrke udviklingsteamet med viden om procedurer og tilgange til styring af produktmiljøet. Med andre ord skal udvikleren forstå og vide, hvordan hans produkt fungerer under visse forhold, skal forstå, hvordan han implementerer sit produkt, hvilke egenskaber ved miljøet, der kan justeres for at forbedre ydeevnen. Så i nogen tid dukkede udviklere op med en DevOps-tilgang. DevOps-udviklere skrev bygge- og pakkescripts for at forenkle deres aktiviteter og produktionsmiljøets ydeevne. Imidlertid begyndte kompleksiteten af løsningsarkitekturen og den gensidige påvirkning af infrastrukturkomponenter over tid at forringe miljøernes ydeevne; med hver iteration var der behov for en stadig dybere forståelse af visse komponenter, hvilket reducerede udviklerens produktivitet på grund af den yderligere omkostninger ved at forstå komponenterne og tuningsystemerne til en specifik opgave. . Udviklerens egne omkostninger voksede, prisen på produktet sammen med det, kravene til nye udviklere i teamet sprang kraftigt, fordi de også skulle dække ansvaret for udviklings-"stjernen", og naturligvis blev "stjernerne" mindre og mindre tilgængelig. Det er også værd at bemærke, at efter min erfaring er det kun få udviklere, der er interesserede i detaljerne ved pakkebehandling af operativsystemkernen, regler for pakkerouting og værtssikkerhedsaspekter. Det logiske skridt var at tiltrække en administrator, der er bekendt med dette, og tildele ham lignende ansvar, hvilket takket være hans erfaring gjorde det muligt at opnå de samme indikatorer til en lavere pris sammenlignet med omkostningerne ved en "stjerne"-udvikling. Sådanne administratorer blev placeret i et team, og hans hovedopgave var at styre test- og produktionsmiljøer i henhold til reglerne for et specifikt team, med ressourcer allokeret til netop dette team. Sådan fremstod faktisk DevOps i hovedet på flertallet.
Helt eller delvist begyndte disse systemadministratorer over tid at forstå behovene hos dette særlige team inden for udviklingsområdet, hvordan man gør livet lettere for udviklere og testere, hvordan man udruller en opdatering og ikke behøver at overnatte på fredag i kontoret, korrigere installationsfejl. Tiden gik, og nu var "stjernerne" systemadministratorer, der forstod, hvad udviklerne ville have. For at minimere påvirkningen begyndte administrationsværktøjer at dukke op; alle huskede de gamle og pålidelige metoder til at isolere OS-niveauet, hvilket gjorde det muligt at minimere kravene til sikkerhed, styring af netværksdelen og værtskonfigurationen som en hele og som følge heraf reducere kravene til nye "stjerner".
En "vidunderlig" ting er dukket op - docker. Hvorfor vidunderligt? Ja, kun fordi oprettelse af isolation i en chroot eller fængsel, såvel som OpenVZ, krævede ikke-trivielt kendskab til operativsystemet, i modsætning hertil giver værktøjet dig mulighed for simpelthen at oprette et isoleret applikationsmiljø på en bestemt vært med alt nødvendigt indeni og i hånden over udviklingstøjlerne igen, og systemadministratoren kan kun klare sig med kun én vært, hvilket sikrer dens sikkerhed og høje tilgængelighed - en logisk forenkling. Men fremskridtet står ikke stille, og systemerne bliver igen mere og mere komplekse, der er flere og flere komponenter, én vært opfylder ikke længere systemets behov, og det er nødvendigt at bygge klynger, vi vender igen tilbage til systemadministratorer, der er i stand til at bygge disse systemer.
Cyklus efter cyklus dukker der forskellige systemer op, som forenkler udvikling og/eller administration, der opstår orkestreringssystemer, som, indtil du skal afvige fra standardprocessen, er nemme at bruge. Mikroservicearkitektur dukkede også op med det formål at forenkle alt beskrevet ovenfor - færre relationer, nemmere at administrere. Efter min erfaring fandt jeg ikke en fuldstændig mikroservicearkitektur, jeg vil sige 50 til 50 - 50 procent af mikrotjenester, sorte bokse, kom ind, behandlede ud, de andre 50 er en revet monolit, tjenester ude af stand til at arbejde adskilt fra andre komponenter . Alt dette satte igen begrænsninger på vidensniveauet for både udviklere og administratorer.
Lignende "udsving" i niveauet af ekspertviden om en bestemt ressource fortsætter den dag i dag. Men vi digresserer lidt, der er mange punkter, der er værd at fremhæve.
Bygningsingeniør/Releaseingeniør
Meget højt specialiserede ingeniører, der dukkede op som et middel til at standardisere softwarebyggeprocesser og -udgivelser. I processen med at introducere udbredt Agile, ser det ud til, at de ophørte med at være efterspurgte, men det er langt fra tilfældet. Denne specialisering fremstod som et middel til at standardisere montering og levering af software i industriel skala, dvs. anvender standardteknikker for alle virksomhedens produkter. Med fremkomsten af DevOps mistede udviklere delvist deres funktioner, da det var udviklerne, der begyndte at forberede produktet til levering, og i betragtning af den skiftende infrastruktur og tilgangen til at levere så hurtigt som muligt uden hensyn til kvalitet, blev de over tid til en stop for ændringer, da overholdelse af kvalitetsstandarder uundgåeligt bremser leveringerne. Så gradvist migrerede en del af funktionaliteten hos Build/Release-ingeniører til systemadministratorernes skuldre.
Ops er så forskellige
Vi fortsætter og igen tilstedeværelsen af en lang række ansvarsområder og manglen på kvalificeret personale skubber os i retning af streng specialisering, som svampe efter regn, forskellige operationer vises:
- TechOps - enikey systemadministratorer aka HelpDesk Engineer
- LiveOps - systemadministratorer primært ansvarlige for produktionsmiljøer
- CloudOps - systemadministratorer med speciale i offentlige skyer Azure, AWS, GCP osv.
- PlatOps/InfraOps/SysOps - infrastruktursystemadministratorer.
- NetOps - netværksadministratorer
- SecOps - systemadministratorer med speciale i informationssikkerhed - PCI compliance, CIS compliance, patching mv.
DevOps er (i teorien) en person, der på første hånd forstår alle processerne i udviklingscyklussen - udvikling, test, forstår produktarkitekturen, er i stand til at vurdere sikkerhedsrisici, er fortrolig med tilgange og automatiseringsværktøjer, i det mindste på et højt niveau. niveau, foruden dette, også forstår præ- og efterbehandling, produktudgivelsessupport. En person, der er i stand til at fungere som fortaler for både drift og udvikling, hvilket giver mulighed for et gunstigt samarbejde mellem disse to søjler. Forstår processerne omkring planlægning af teams og styring af kundernes forventninger.
For at udføre denne form for arbejde og ansvar skal denne person have midlerne til at styre ikke kun udviklings- og testprocesserne, men også styringen af produktinfrastrukturen samt ressourceplanlægning. DevOps i denne forståelse kan ikke lokaliseres hverken i IT, eller i R&D eller endda i PMO'en; de skal have indflydelse på alle disse områder - virksomhedens tekniske direktør, Chief Technical Officer.
Er dette sandt i din virksomhed? - Jeg tvivler. I de fleste tilfælde er det enten IT eller R&D.
Mangel på midler og mulighed for at påvirke mindst et af disse tre aktivitetsområder vil flytte vægten af problemer hen imod, hvor disse ændringer er nemmere at anvende, såsom anvendelse af tekniske restriktioner på udgivelser i forbindelse med "beskidt" kode ifølge statisk analysator systemer. Det vil sige, at når PMO'en sætter en streng deadline for frigivelse af funktionalitet, kan R&D ikke producere et resultat af høj kvalitet inden for disse deadlines og producerer det så godt det kan, og efterlader refactoring til senere, DevOps relateret til IT blokerer udgivelsen med tekniske midler . Mangel på autoritet til at ændre situationen, når det drejer sig om ansvarlige medarbejdere, fører til manifestationen af hyperansvar for det, de ikke kan påvirke, især hvis disse medarbejdere forstår og ser fejl, og hvordan man retter dem - "Glæde er uvidenhed", og som en konsekvens af udbrændthed og tab af disse medarbejdere.
DevOps ressourcemarked
Lad os se på flere ledige stillinger til DevOps-stillinger fra forskellige virksomheder.
Vi er klar til at møde dig, hvis du:
- Du ejer Zabbix og ved, hvad Prometheus er;
- Iptables;
- BASH ph.d.-studerende;
- professor Ansible;
- Linux Guru;
- Vide, hvordan man bruger debugging og finder applikationsproblemer sammen med udviklere (php/java/python);
- Routing gør dig ikke hysterisk;
- Vær meget opmærksom på systemsikkerhed;
- Sikkerhedskopier "alt og alt", og gendan også med succes dette "alt og alt";
- Du ved, hvordan du konfigurerer systemet på en sådan måde, at du får det maksimale ud af minimum;
- Indstil replikering inden du går i seng på Postgres og MySQL;
- Opsætning og justering af CI/CD er lige så nødvendigt for dig som morgenmad/frokost/aftensmad.
- Har erfaring med AWS;
- Klar til at udvikle sig med virksomheden;
So:
- fra 1 til 6 - systemadministrator
- 7 - lidt netværksadministration, som også passer ind i systemadministratoren, mellemniveau
- 8 - lidt sikkerhed, som er obligatorisk for en systemadministrator på mellemniveau
- 9-11 – Mellemsystemadministrator
- 12 — Afhængigt af de tildelte opgaver, enten mellemsystemadministrator eller bygningsingeniør
- 13 - Virtualisering - Middle System Administrator, eller den såkaldte CloudOps, avanceret viden om tjenesterne på et specifikt hostingsite, for effektiv brug af midler og reducere belastningen på vedligeholdelse
Sammenfattende denne ledige stilling kan vi sige, at mellem-/senior systemadministrator er nok for fyrene.
Forresten bør du ikke kraftigt opdele administratorer på Linux/Windows. Selvfølgelig forstår jeg, at tjenesterne og systemerne i disse to verdener er forskellige, men grundlaget for alle er det samme, og enhver administrator med respekt for sig selv er bekendt med både den ene og den anden, og selvom han ikke er bekendt, vil den ikke være svært for en kompetent administrator at blive fortrolig med det.
Lad os overveje en anden ledig stilling:
- Erfaring med at bygge højbelastningssystemer;
- Fremragende kendskab til Linux OS, generel systemsoftware og webstack (Nginx, PHP/Python, HAProxy, MySQL/PostgreSQL, Memcached, Redis, RabbitMQ, ELK);
- Erfaring med virtualiseringssystemer (KVM, VMWare, LXC/Docker);
- Færdighed i scriptsprog;
- Forståelse af driftsprincipperne for netværksprotokolnetværk;
- Forståelse af principperne for opbygning af fejltolerante systemer;
- Uafhængighed og initiativ;
Lad os se på:
- 1 – Senior systemadministrator
- 2 - Afhængig af betydningen lagt i denne stak - Mellem/Senior systemadministrator
- 3 - Arbejdserfaring, herunder, kan betyde - "Klyngen rejste ikke, men skabte og administrerede virtuelle maskiner, der var en Docker-vært, adgang til containere var ikke tilgængelig" - Mellemsystemadministrator
- 4 - Junior System Administrator - ja, en administrator, der ikke ved, hvordan man skriver grundlæggende automatiseringsscripts, uanset sproget, ikke en admin - enikey.
- 5 - Mellemsystemadministrator
- 6 – Senior systemadministrator
For at opsummere - mellem-/senior systemadministrator
Endnu en:
- Giver erfaring;
- Erfaring med at bruge et eller flere produkter til at skabe CI/CD processer. Gitlab CI vil være en fordel;
- Arbejde med containere og virtualisering; Hvis du brugte docker, godt, men hvis du brugte k8s, fantastisk!
- Erfaring med at arbejde i et agilt team;
- Kendskab til ethvert programmeringssprog;
Lad os se:
- 1 - Hmm... Hvad mener fyrene? =) Mest sandsynligt ved de ikke selv, hvad der gemmer sig bag det
- 2 - Bygningsingeniør
- 3 - Mellemsystemadministrator
- 4 - Blød færdighed, vi vil ikke overveje det lige nu, selvom Agile er en anden ting, der fortolkes på en måde, der er praktisk.
- 5 - For omfattende - det kunne være et scriptsprog eller et kompileret sprog. Mon ikke det passer dem at skrive i Pascal og Basic i skolen? =)
Jeg vil også gerne efterlade et notat vedrørende punkt 3 for at styrke forståelsen af, hvorfor dette punkt er omfattet af systemadministratoren. Kubernetes er bare en orkestrering, et værktøj, der pakker direkte kommandoer til netværksdrivere og virtualiserings-/isolationsværter i et par kommandoer og giver dig mulighed for at gøre kommunikationen med dem abstrakt, det er alt. Lad os for eksempel tage 'build framework' Make, som jeg i øvrigt ikke betragter som en ramme. Ja, jeg kender til modet med at skubbe Make overalt, hvor det er nødvendigt og ikke nødvendigt - at pakke Maven ind i Make for eksempel seriøst?
I det væsentlige er Make kun en indpakning over skallen, hvilket forenkler kompilerings-, sammenkædnings- og kompileringsmiljøkommandoer, ligesom k8s.
Engang interviewede jeg en fyr, der brugte k8s i sit arbejde oven på OpenStack, og han talte om, hvordan han installerede tjenester på det, men da jeg spurgte om OpenStack, viste det sig, at det blev administreret, såvel som rejst af systemet. administratorer. Tror du virkelig, at en person, der har installeret OpenStack, uanset hvilken platform han bruger bag sig, ikke er i stand til at bruge k8s? =)
Denne ansøger er faktisk ikke en DevOps, men en systemadministrator og for at være mere præcis en Kubernetes-administrator.
Lad os opsummere endnu en gang - mellem-/senior systemadministrator vil være nok for dem.
Hvor meget skal man veje i gram
Udvalget af foreslåede lønninger for de angivne ledige stillinger er 90-200
Nu vil jeg gerne drage en parallel mellem de monetære belønninger fra systemadministratorer og DevOps-ingeniører.
I princippet, for at forenkle tingene, kan du sprede karaktererne baseret på erhvervserfaring, selvom dette ikke vil være nøjagtigt, men til artiklens formål vil det være nok.
En oplevelse:
- op til 3 år – Junior
- op til 6 år – Mellem
- mere end 6 – Senior
Medarbejdersøgningssiden tilbyder:
Systemadministratorer:
- Junior - 2 år - 50k rub.
- Mellem - 5 år - 70k gnid.
- Senior - 11 år - 100 rub.
DevOps-ingeniører:
- Junior - 2 år - 100k rub.
- Mellem - 3 år - 160k gnid.
- Senior - 6 år - 220 rub.
Ifølge erfaringerne fra "DevOps" blev der brugt erfaringer, der i det mindste på en eller anden måde påvirkede SDLC.
Af ovenstående følger det, at virksomheder faktisk ikke har brug for DevOps, og også at de kunne spare mindst 50 procent af de oprindeligt planlagte omkostninger ved at ansætte en administrator; desuden kunne de tydeligere definere ansvaret for den person, de leder efter og udfylde behovet hurtigere. Vi bør heller ikke glemme, at en klar ansvarsfordeling giver os mulighed for at reducere kravene til personale samt skabe en mere gunstig atmosfære i teamet på grund af fraværet af overlapninger. Langt de fleste ledige stillinger er fulde af hjælpeprogrammer og DevOps-etiketter, men de er ikke baseret på faktiske krav til en DevOps-ingeniør, kun anmodninger om en værktøjsadministrator.
Processen med at træne DevOps-ingeniører er også begrænset til et sæt specifikke værker, hjælpeprogrammer og giver ikke en generel forståelse af processerne og deres afhængigheder. Det er bestemt godt, når en person kan implementere AWS EKS ved hjælp af Terraform, sammen med Fluentd sidevognen i denne klynge og AWS ELK-stakken til logningssystemet på 10 minutter, ved kun at bruge én kommando i konsollen, men hvis han ikke forstår princippet om at behandle sig selv logs og hvad de er nødvendige for, hvis du ikke ved, hvordan man indsamler metrikker på dem og sporer forringelsen af tjenesten, så vil det stadig være den samme enikey, der ved, hvordan man bruger nogle værktøjer.
Efterspørgslen skaber dog udbud, og vi ser et ekstremt overophedet marked for DevOps-positionen, hvor kravene ikke svarer til selve rollen, men kun tillader systemadministratorer at tjene mere.
Så hvem er de? DevOps eller grådige systemadministratorer? =)
Hvordan fortsætter man med at leve?
Arbejdsgivere bør formulere krav mere præcist og lede efter præcis dem, der er brug for, og ikke kaste rundt med etiketter. Du ved ikke, hvad DevOps gør – du behøver dem ikke i så fald.
Arbejdere - Lær. Forbedre konstant din viden, se på det overordnede billede af processer og spor vejen til dit mål. Du kan blive hvem du vil, du skal bare prøve.
Kilde: www.habr.com