For øyeblikket er dette nesten den dyreste posisjonen på markedet. Oppstyret rundt "DevOps"-ingeniører er utenfor alle tenkelige grenser, og enda verre med senior DevOps-ingeniører.
Jeg jobber som leder for integrasjons- og automatiseringsavdelingen, gjett engelsk dekoding - DevOps Manager. Det er usannsynlig at den engelske utskriften gjenspeiler våre daglige aktiviteter, men den russiske versjonen i dette tilfellet er mer nøyaktig. På grunn av aktiviteten min er det naturlig at jeg trenger å intervjue fremtidige medlemmer av teamet mitt, og i løpet av det siste året har rundt 50 personer passert meg, og det samme antallet har blitt avskåret på forhåndsskjermen med mine ansatte.
Vi leter fortsatt etter kolleger, for bak DevOps-etiketten skjuler det seg et veldig stort lag av forskjellige typer ingeniører.
Alt som er skrevet under er min personlige mening, du trenger ikke være enig i det, men jeg innrømmer at det vil sette litt farge på din holdning til temaet. Til tross for risikoen for å falle i unåde, publiserer jeg min mening fordi jeg tror at den har et sted å være.
Bedrifter har ulik forståelse av hvem DevOps-ingeniører er, og for å raskt ansette en ressurs, henger de denne etiketten på alle. Situasjonen er ganske merkelig, siden selskaper er klare til å betale urealistiske godtgjørelser til disse menneskene, og mottar i de fleste tilfeller en verktøyadministrator for dem.
Så hvem er DevOps-ingeniører?
La oss starte med historien om utseendet - Development Operations dukket opp som et nytt skritt mot å optimalisere interaksjon i små team for å øke hastigheten på produktproduksjonen, som en forventet konsekvens. Tanken var å styrke utviklingsteamet med kunnskap om prosedyrer og tilnærminger for å administrere produktmiljøet. Med andre ord må utvikleren forstå og vite hvordan produktet hans fungerer under visse forhold, må forstå hvordan produktet skal distribueres, hvilke egenskaper ved miljøet som kan justeres for å forbedre ytelsen. Så i noen tid dukket det opp utviklere med en DevOps-tilnærming. DevOps-utviklere skrev bygge- og pakkeskript for å forenkle deres aktiviteter og ytelsen til produksjonsmiljøet. Imidlertid begynte kompleksiteten til løsningsarkitekturen og den gjensidige påvirkningen av infrastrukturkomponenter over tid å forringe ytelsen til miljøene; med hver iterasjon var det nødvendig med en stadig dypere forståelse av visse komponenter, noe som reduserte produktiviteten til utvikleren på grunn av den ekstra kostnader ved å forstå komponentene og innstillingssystemene for en spesifikk oppgave. Utviklerens egne kostnader vokste, kostnadene for produktet sammen med det, kravene til nye utviklere i teamet hoppet kraftig, fordi de også trengte å dekke ansvaret til utviklings-"stjernen", og naturlig nok ble "stjernene" mindre og mindre tilgjengelig. Det er også verdt å merke seg at etter min erfaring er det få utviklere som er interessert i detaljene ved pakkebehandling av operativsystemkjernen, pakkeroutingsregler og vertssikkerhetsaspekter. Det logiske trinnet var å tiltrekke seg en administrator som er kjent med dette og tildele ham lignende ansvar, som takket være hans erfaring gjorde det mulig å oppnå de samme indikatorene til en lavere kostnad sammenlignet med kostnadene for en "stjerne" utvikling. Slike administratorer ble plassert i et team og hans hovedoppgave var å administrere test- og produksjonsmiljøer, i henhold til reglene til et spesifikt team, med ressurser allokert til dette bestemte teamet. Det var faktisk slik DevOps dukket opp i hodet til flertallet.
Helt eller delvis, over tid, begynte disse systemadministratorene å forstå behovene til dette spesielle teamet innen utvikling, hvordan man kan gjøre livet enklere for utviklere og testere, hvordan man ruller ut en oppdatering og ikke trenger å overnatte på fredag i kontoret, korrigere distribusjonsfeil. Tiden gikk, og nå var "stjernene" systemadministratorer som forsto hva utviklerne ville ha. For å minimere påvirkningen begynte administrasjonsverktøy å komme opp; alle husket de gamle og pålitelige metodene for å isolere OS-nivået, som gjorde det mulig å minimere kravene til sikkerhet, administrasjon av nettverksdelen og vertskonfigurasjonen som en hele og som et resultat redusere kravene til nye "stjerner".
En "fantastisk" ting har dukket opp - docker. Hvorfor fantastisk? Ja, bare fordi å lage isolasjon i en chroot eller fengsel, så vel som OpenVZ, krevde ikke-triviell kunnskap om operativsystemet, i motsetning til dette lar verktøyet deg ganske enkelt lage et isolert applikasjonsmiljø på en bestemt vert med alt nødvendig inne og hånd over tøylene til utviklingen igjen, og systemadministratoren kan bare administrere med bare én vert, noe som sikrer dens sikkerhet og høye tilgjengelighet - en logisk forenkling. Men fremdriften står ikke stille og systemene blir igjen mer og mer komplekse, det er flere og flere komponenter, en vert oppfyller ikke lenger systemets behov og det er nødvendig å bygge klynger, vi kommer igjen tilbake til systemadministratorer som er i stand til å bygge disse systemene.
Syklus etter syklus dukker det opp ulike systemer som forenkler utvikling og/eller administrasjon, det dukker opp orkestreringssystemer som inntil du skal avvike fra standardprosessen er enkle å bruke. Microservice-arkitektur dukket også opp med sikte på å forenkle alt beskrevet ovenfor - færre relasjoner, enklere å administrere. Etter min erfaring fant jeg ikke en fullstendig mikrotjenestearkitektur, jeg vil si at 50 til 50 - 50 prosent av mikrotjenester, svarte bokser, kom inn, kom ut behandlet, de andre 50 er en revet monolitt, tjenester som ikke kan fungere separat fra andre komponenter. Alt dette satte igjen begrensninger på kunnskapsnivået til både utviklere og administratorer.
Lignende "svingninger" i nivået av ekspertkunnskap om en bestemt ressurs fortsetter til i dag. Men vi går litt bort, det er mange punkter det er verdt å trekke frem.
Byggingeniør/Utgivelsesingeniør
Svært høyt spesialiserte ingeniører som dukket opp som et middel for å standardisere programvarebyggingsprosesser og utgivelser. I prosessen med å introdusere utbredt Agile, ser det ut til at de sluttet å være etterspurt, men dette er langt fra tilfelle. Denne spesialiseringen fremsto som et middel for å standardisere montering og levering av programvare i industriell skala, d.v.s. ved bruk av standardteknikker for alle bedriftens produkter. Med bruken av DevOps mistet utviklerne delvis funksjonene sine, siden det var utviklerne som begynte å forberede produktet for levering, og gitt den endrede infrastrukturen og tilnærmingen til å levere så raskt som mulig uten hensyn til kvalitet, ble de over tid til en stopper for endringer, siden overholdelse av kvalitetsstandarder uunngåelig bremser leveransene. Så gradvis migrerte en del av funksjonaliteten til Build/Release-ingeniører til systemadministratorenes skuldre.
Ops er så forskjellige
Vi går videre og igjen tilstedeværelsen av et stort spekter av ansvar og mangelen på kvalifisert personell presser oss mot streng spesialisering, som sopp etter regn, forskjellige operasjoner vises:
- TechOps - enikey systemadministratorer aka HelpDesk Engineer
- LiveOps - systemadministratorer som er hovedansvarlige for produksjonsmiljøer
- CloudOps - systemadministratorer som spesialiserer seg på offentlige skyer Azure, AWS, GCP, etc.
- PlatOps/InfraOps/SysOps - infrastruktursystemadministratorer.
- NetOps - nettverksadministratorer
- SecOps - systemadministratorer som spesialiserer seg på informasjonssikkerhet - PCI-samsvar, CIS-samsvar, patching, etc.
DevOps er (i teorien) en person som selv forstår alle prosessene i utviklingssyklusen - utvikling, testing, forstår produktarkitekturen, er i stand til å vurdere sikkerhetsrisikoer, er kjent med tilnærminger og automatiseringsverktøy, i det minste på et høyt nivå. nivå, i tillegg til dette, forstår også pre- og post-processing. produktutgivelsesstøtte. En person som er i stand til å fungere som talsmann for både drift og utvikling, noe som gir mulighet for gunstig samarbeid mellom disse to pilarene. Forstår prosessene med å planlegge arbeid i team og administrere kundenes forventninger.
For å utføre denne typen arbeid og ansvar, må denne personen ha midler til å administrere ikke bare utviklings- og testprosessene, men også styringen av produktinfrastrukturen, samt ressursplanlegging. DevOps i denne forståelsen kan ikke lokaliseres verken i IT, eller i FoU, eller til og med i PMO; de må ha innflytelse på alle disse områdene - selskapets tekniske direktør, Chief Technical Officer.
Er dette sant i din bedrift? - Jeg tviler. I de fleste tilfeller er dette enten IT eller FoU.
Mangel på midler og mulighet til å påvirke minst ett av disse tre aktivitetsområdene vil flytte vekten av problemer mot der disse endringene er lettere å anvende, for eksempel anvendelse av tekniske restriksjoner på utgivelser i forbindelse med "skitten" kode i henhold til statisk analysator systemer. Det vil si at når PMO setter en streng frist for utgivelse av funksjonalitet, kan ikke FoU produsere et resultat av høy kvalitet innenfor disse tidsfristene og produsere det så godt det kan, og etterlater refactoring til senere, DevOps relatert til IT blokkerer utgivelsen med tekniske midler . Mangel på myndighet til å endre situasjonen, når det gjelder ansvarlige ansatte, fører til manifestasjon av hyperansvar for det de ikke kan påvirke, spesielt hvis disse ansatte forstår og ser feil, og hvordan de kan korrigere dem - "Lykke er uvitenhet", og som en konsekvens av utbrenthet og tap av disse ansatte.
DevOps ressursmarked
La oss se på flere ledige stillinger for DevOps-stillinger fra forskjellige selskaper.
Vi er klare til å møte deg hvis du:
- Du eier Zabbix og vet hva Prometheus er;
- Iptables;
- BASH PhD Student;
- professor Ansible;
- Linux Guru;
- Vet hvordan du bruker feilsøking og finner applikasjonsproblemer sammen med utviklere (php/java/python);
- Ruting gjør deg ikke hysterisk;
- Vær betydelig oppmerksom på systemsikkerhet;
- Sikkerhetskopier "alt og alt", og gjenopprett også dette "alt og alt";
- Du vet hvordan du konfigurerer systemet på en slik måte at du får maksimalt ut av minimum;
- Sett opp replikering før du legger deg på Postgres og MySQL;
- Oppsett og justering av CI/CD er like nødvendig for deg som frokost/lunsj/middag.
- Har erfaring med AWS;
- Klar til å utvikle seg med selskapet;
Så:
- fra 1 til 6 - systemadministrator
- 7 - litt nettverksadministrasjon, som også passer inn i systemadministratoren, mellomnivå
- 8 - litt sikkerhet, som er obligatorisk for en systemadministrator på mellomnivå
- 9-11 – Mellomsystemadministrator
- 12 — Avhengig av de tildelte oppgavene, enten mellomsystemadministrator eller byggingeniør
- 13 - Virtualisering - Middle System Administrator, eller den såkalte CloudOps, avansert kunnskap om tjenestene til en spesifikk vertsside, for effektiv bruk av midler og redusere belastningen på vedlikehold
For å oppsummere denne ledige stillingen kan vi si at mellom-/senior systemadministrator er nok for gutta.
Forresten, du bør ikke sterkt dele administratorer på Linux/Windows. Selvfølgelig forstår jeg at tjenestene og systemene til disse to verdenene er forskjellige, men grunnlaget for alle er det samme og enhver admin med respekt for seg selv er kjent med både den ene og den andre, og selv om han ikke er kjent, vil den ikke være vanskelig for en kompetent administrator å bli kjent med det.
La oss vurdere en annen ledig stilling:
- Erfaring med å bygge høylastsystemer;
- Utmerket kunnskap om Linux OS, generell systemprogramvare og webstack (Nginx, PHP/Python, HAProxy, MySQL/PostgreSQL, Memcached, Redis, RabbitMQ, ELK);
- Erfaring med virtualiseringssystemer (KVM, VMWare, LXC/Docker);
- Ferdigheter i skriptspråk;
- Forståelse av driftsprinsippene for nettverksprotokollnettverk;
- Forståelse av prinsippene for å bygge feiltolerante systemer;
- Uavhengighet og initiativ;
La oss se på:
- 1 – Senior systemadministrator
- 2 - Avhengig av betydningen lagt inn i denne stabelen - Mellom-/senior systemadministrator
- 3 - Arbeidserfaring, inkludert, kan bety - "Klyngen reiste ikke, men opprettet og administrerte virtuelle maskiner, det var én Docker-vert, tilgang til containere var ikke tilgjengelig" - Mellomsystemadministrator
- 4 - Junior systemadministrator - ja, en admin som ikke vet hvordan man skriver grunnleggende automatiseringsskript, uansett språk, ikke en admin - enikey.
- 5 - Mellomsystemadministrator
- 6 – Senior systemadministrator
For å oppsummere - mellom-/senior systemadministrator
En annen:
- Utvikler erfaring;
- Erfaring med å bruke ett eller flere produkter for å lage CI/CD-prosesser. Gitlab CI vil være en fordel;
- Arbeide med containere og virtualisering; Hvis du brukte docker, bra, men hvis du brukte k8s, bra!
- Erfaring med å jobbe i et smidig team;
- Kunnskap om ethvert programmeringsspråk;
La oss se:
- 1 - Hmm... Hva mener gutta? =) Mest sannsynlig vet de ikke selv hva som skjuler seg bak den
- 2 - Byggingeniør
- 3 - Mellomsystemadministrator
- 4 - Myk ferdighet, vi vil ikke vurdere det foreløpig, selv om Agile er en annen ting som tolkes på en måte som er praktisk.
- 5 - For detaljert - det kan være et skriptspråk eller et kompilert språk. Jeg lurer på om det å skrive i Pascal og Basic på skolen vil passe dem? =)
Jeg vil også legge igjen et notat til punkt 3 for å styrke forståelsen av hvorfor dette punktet dekkes av systemansvarlig. Kubernetes er bare en orkestrering, et verktøy som pakker direkte kommandoer til nettverksdrivere og virtualiserings-/isolasjonsverter i et par kommandoer og lar deg gjøre kommunikasjon med dem abstrakt, det er alt. La oss for eksempel ta 'bygg rammeverk' Make, som jeg forresten ikke anser som et rammeverk. Ja, jeg vet om moten med å skyve Make hvor som helst, der det er nødvendig og ikke nødvendig - å pakke Maven inn i Make, for eksempel, seriøst?
I hovedsak er Make bare en innpakning over skallet, og forenkler kompilerings-, koblings- og kompileringsmiljøkommandoer, akkurat som k8s.
En gang intervjuet jeg en fyr som brukte k8s i arbeidet sitt på toppen av OpenStack, og han snakket om hvordan han distribuerte tjenester på den, men da jeg spurte om OpenStack, viste det seg at den ble administrert, så vel som hevet av systemet administratorer. Tror du virkelig at en person som har installert OpenStack, uavhengig av hvilken plattform han bruker bak seg, ikke er i stand til å bruke k8s? =)
Denne søkeren er egentlig ikke en DevOps, men en systemadministrator og for å være mer presis en Kubernetes-administrator.
La oss oppsummere nok en gang - mellom-/senior systemadministrator vil være nok for dem.
Hvor mye du skal veie i gram
Utvalget av foreslåtte lønn for de angitte ledige stillingene er 90k-200k
Nå vil jeg trekke en parallell mellom de økonomiske belønningene til systemadministratorer og DevOps-ingeniører.
I prinsippet, for å forenkle ting, kan du spre karakterene basert på arbeidserfaring, selv om dette ikke vil være nøyaktig, men for artikkelens formål vil det være nok.
En opplevelse:
- inntil 3 år – Junior
- opp til 6 år – Mellom
- mer enn 6 – Senior
Søkesiden for ansatte tilbyr:
Systemadministratorer:
- Junior - 2 år - 50k gni.
- Midt - 5 år - 70k gni.
- Senior - 11 år - 100k rub.
DevOps-ingeniører:
- Junior - 2 år - 100k gni.
- Midt - 3 år - 160k gni.
- Senior - 6 år - 220k rub.
I følge erfaringene fra "DevOps" ble erfaring brukt som i det minste på en eller annen måte påvirket SDLC.
Av ovenstående følger det at bedrifter faktisk ikke trenger DevOps, og også at de kan spare minst 50 prosent av de opprinnelig planlagte kostnadene ved å ansette en administrator; dessuten kan de tydeligere definere ansvaret til personen de leter etter og fylle behovet raskere. Vi bør heller ikke glemme at en klar ansvarsfordeling lar oss redusere kravene til personell, samt skape en mer gunstig atmosfære i teamet, på grunn av fraværet av overlappinger. De aller fleste ledige stillinger er fulle av verktøy og DevOps-etiketter, men de er ikke basert på faktiske krav til en DevOps-ingeniør, kun forespørsler om en verktøyadministrator.
Prosessen med å trene DevOps-ingeniører er også begrenset til et sett med spesifikke arbeider, verktøy og gir ikke en generell forståelse av prosessene og deres avhengigheter. Det er absolutt bra når en person kan distribuere AWS EKS ved hjelp av Terraform, sammen med Fluentd-sidevognen i denne klyngen og AWS ELK-stabelen for loggingssystemet på 10 minutter, med bare én kommando i konsollen, men hvis han ikke forstår prinsippet om å behandle selve logger og hva de er nødvendige for, hvis du ikke vet hvordan du samler inn beregninger på dem og sporer forringelsen av tjenesten, vil det fortsatt være den samme enikey som vet hvordan du bruker noen verktøy.
Etterspørselen skaper imidlertid tilbud, og vi ser et ekstremt overopphetet marked for DevOps-posisjonen, hvor kravene ikke samsvarer med den faktiske rollen, men bare lar systemadministratorer tjene mer.
Så hvem er de? DevOps eller grådige systemadministratorer? =)
Hvordan fortsette å leve?
Arbeidsgivere bør formulere krav mer presist og se etter akkurat de som trengs, og ikke kaste rundt etiketter. Du vet ikke hva DevOps gjør – du trenger dem ikke i så fall.
Arbeidere - Lær. Forbedre kunnskapen din hele tiden, se på helhetsbildet av prosesser og spor veien til målet ditt. Du kan bli hvem du vil, du må bare prøve.
Kilde: www.habr.com