Nylig har slike annonser oversvømmet Internett. Til tross for den hyggelige lønnen, kan man ikke unngå å være flau over at det er skrevet vill kjetteri på innsiden. Først antas det at "DevOps" og "ingeniør" på en eller annen måte kan limes sammen til ett ord, og så er det en tilfeldig liste med krav, hvorav noen er tydelig kopiert fra sysadmin-vikariatet.
I dette innlegget vil jeg gjerne snakke litt om hvordan vi kom til dette punktet i livet, hva DevOps egentlig er og hva vi skal gjøre med det nå.
Slike ledige stillinger kan fordømmes på alle mulige måter, men faktum gjenstår: det er mange av dem, og det er slik markedet fungerer for øyeblikket. Vi holdt en devops-konferanse og erklærer åpent: " - ikke for DevOps-ingeniører." Dette vil virke rart og vilt for mange: hvorfor folk som holder på med et helt kommersielt arrangement går mot markedet. Nå skal vi forklare alt.
Om kultur og prosesser
La oss starte med det faktum at DevOps ikke er en ingeniørdisiplin. Det hele startet med at den historisk etablerte rollefordelingen ikke fungerer for kvaliteten på produktene. Når programmerere bare programmerer, men ikke vil høre noe om testing, er programvaren full av feil. Når administratorer ikke bryr seg om hvordan eller hvorfor programvaren er skrevet, blir støtte til et helvete.
For eksempel å beskrive forskjellen mellom en systemadministrator og en SRE-tilnærming til tjenesteadministrasjon . Interessante studier er utført innenfor — Det er tydelig at de beste utviklerne på en eller annen måte klarer å implementere nye endringer i produksjonen raskere enn én gang i timen. De tester med hendene ikke mer enn 10% (dette kan sees fra ). Hvordan gjør de dette? «Excel or die» sier en av rapportoverskriftene. For en detaljert diskusjon av denne statistikken i sammenheng med testing, kan du referere til hovedinnlegget til Baruch Sadogursky på vår andre konferanse, Heisenbug.
«Når det ikke er enighet mellom kamerater,
Ting vil ikke gå bra for dem,
Og ingenting vil komme ut av det, bare pine.
Det var en gang en svane, en kreps og en gjedde..."
Hvilken del av nettprogrammerere tror du virkelig forstår forholdene applikasjonene deres brukes under i produksjonen? Hvor mange av dem vil gå til administratorene og prøve å finne ut hva som vil skje hvis databasen krasjer? Og hvem av dem vil gå til testerne og be dem lære dem hvordan de skal skrive tester riktig? Og det er også sikkerhetsvakter, produktsjefer og en haug med andre mennesker.
Den overordnede ideen med DevOps er å skape samarbeid mellom roller og avdelinger. Først av alt oppnås dette ikke av noen smart konfigurert programvare, men ved å bruke kommunikasjon. DevOps handler om kultur, praksis, metodikk og prosesser. Det er ingen ingeniørspesialist som kan svare på disse spørsmålene.
Ond sirkel
Hvor kom disiplinen "devops engineering" fra da? Vi har en versjon! DevOps-ideene var gode – så gode at de ble ofre for sin egen suksess. Noen lyssky rekrutterere og menneskesmuglere, som har sin egen atmosfære, begynte å virvle rundt hele dette temaet.
Tenk deg: i går laget du shawarma i Khimki, og i dag er du allerede en stor mann, en senior rekrutterer. Det er en hel prosess med å søke og velge kandidater, alt er ikke lett, du må forstå. La oss si at lederen for en avdeling sier: finn en spesialist i X. Vi tildeler ordet «ingeniør» til X, og vi er ferdige. Trenger du Linux? Vel, dette er definitivt en Linux-ingeniør, hvis du vil ha DevOps, så en DevOps-ingeniør. Stillingen består ikke bare av en tittel, men også en del tekst må skrives inn. Den enkleste måten er å legge inn et sett med søkeord fra Google, avhengig av fantasien din. DevOps består av to ord - "Dev" og "Ops", som betyr at vi må lime sammen nøkkelord relatert til utviklere og administratorer, alt i én haug. Slik vises ledige stillinger om ferdigheter i 42 programmeringsspråk og 20 års bruk av Kubernetes og Swarm samtidig. Arbeidsdiagram.
Dette er hvordan det meningsløse og nådeløse bildet av en viss "devops" superhelt har slått rot i folks sinn, som vil konfigurere alle til å distribuere til Jenkins, og lykke vil komme. Å, hvis bare alt var så enkelt. "Og dette er også hvordan du kan jakte på systemadministratorer," mener HR, "det er et moteriktig ord, nøkkelordene er de samme, de bør ta agnet."
Etterspørselen skaper tilbud, og alle disse ledige søppelstillingene har blitt fylt opp med et vanvittig antall systemadministratorer som innså: du kan gjøre alt på samme måte som før, men få flere ganger mer ved å kalle deg selv «devops». Akkurat som du konfigurerte servere via SSH manuelt én om gangen, vil du fortsette å konfigurere dem, men nå er dette visstnok en devops-praksis. Dette er en slags komplekst fenomen, delvis relatert til undervurderingen av klassiske admins og hypen rundt DevOps, men generelt skjedde det som skjedde.
Så vi har tilbud og etterspørsel. En ond sirkel som nærer seg selv. Det er dette vi kjemper mot (inkludert ved å lage DevOops-konferansen).
Selvfølgelig, i tillegg til systemadministratorene som har omdøpt seg selv til "devops", er det andre deltakere - for eksempel profesjonelle SRE-er eller Infrastructure-as-Code-utviklere.
Hva folk gjør i DevOps (egentlig)
Så du ønsker å komme videre med å lære og bruke DevOps-praksis. Men hvordan gjør man dette, i hvilken retning skal man se? Selvfølgelig bør du ikke stole blindt på populære søkeord.
Hvis det er en jobb, bør noen gjøre det. Vi har allerede funnet ut at disse ikke er "devops-ingeniører", hvem er det da? Det virker mer riktig å formulere dette ikke ut fra stillinger, men ut fra spesifikke arbeidsområder.
Først kan du ta for deg hjertet av DevOps – prosesser og kultur. Kultur er en treg og vanskelig virksomhet, og selv om det tradisjonelt er ledernes ansvar, er alle involvert på en eller annen måte, fra programmerere til administratorer. For et par måneder siden Tim Lister :
"Kultur bestemmes av organisasjonens kjerneverdier. Vanligvis legger ikke folk merke til dette, men etter å ha jobbet med rådgivning i mange år, er vi vant til å legge merke til det. Du går inn i et selskap og bokstavelig talt i løpet av få minutter begynner du å føle hva som skjer. Vi kaller dette "smak". Noen ganger er denne duften veldig god. Noen ganger forårsaker det kvalme. (...) Du kan ikke endre en kultur før verdiene og troen bak spesifikke handlinger er forstått. Atferd er lett å observere, men å søke etter tro er vanskelig. DevOps er bare et godt eksempel på hvordan ting blir mer og mer komplekse.»
Det er også en teknisk del av saken, selvfølgelig. Hvis den nye koden din blir testet om en måned, men utgis bare et år senere, og det er fysisk umulig å få fart på alt, kan det hende du ikke lever opp til god praksis. God praksis støttes av gode verktøy. For eksempel, med ideen om Infrastructure-as-Code i tankene, kan du bruke alt fra AWS CloudFormation og Terraform til Chef-Ansible-Puppet. Du må vite og kunne alt dette, og dette er allerede en ganske ingeniørdisiplin. Det er viktig å ikke forveksle årsak med virkning: først jobber du etter prinsippene til SRE og først deretter implementerer du disse prinsippene i form av noen spesifikke tekniske løsninger. Samtidig er SRE en svært omfattende metodikk som ikke forteller deg hvordan du setter opp Jenkins, men om fem grunnleggende prinsipper:
- Forbedret kommunikasjon mellom roller og avdelinger
- Å akseptere feil som en integrert del av jobben
- Gjør endringer gradvis
- Bruk av verktøy og annen automatisering
- Måler alt som kan måles
Dette er ikke bare et sett med utsagn, men et spesifikt . For eksempel, på veien til å akseptere feil, må du forstå risikoen, måle tilgjengeligheten og utilgjengeligheten til tjenester ved å bruke noe som SLI () og SLO (), lær å skrive postmortems og gjør det ikke skummelt å skrive dem.
I SRE-disiplinen er bruk av verktøy bare en del av suksessen, selv om det er en viktig del. Vi må hele tiden utvikle oss teknisk, se på hva som skjer i verden og hvordan det kan brukes i vårt arbeid.
På sin side har Cloud Native-løsninger nå blitt veldig populære. Som definert av Cloud Native Computing Foundation i dag, gjør Cloud Native-teknologier det mulig for organisasjoner å utvikle og kjøre skalerbare applikasjoner i dagens dynamiske miljøer, som offentlige, private og hybride skyer. Eksempler inkluderer containere, tjenestenettverk, mikrotjenester, uforanderlig infrastruktur og deklarative APIer. Alle disse teknikkene lar løst koblede systemer forbli elastiske, håndterbare og svært observerbare. God automatisering lar ingeniører gjøre store endringer ofte og med forutsigbare resultater uten å gjøre det til et ork. Alt dette støttes av en stabel med kjente verktøy som Docker og Kubernetes.
Denne ganske kompliserte og brede definisjonen skyldes at området også er ganske komplekst. På den ene siden argumenteres det for at nye endringer i dette systemet ganske enkelt bør legges til. På den annen side, for å finne ut hvordan man kan lage et slags containerisert miljø der løst koblede tjenester lever på en programvaredefinert infrastruktur og leveres der ved bruk av kontinuerlig CI/CD, og bygge DevOps-praksis rundt alt dette - alt dette krever mer enn en spiser hunden.
Hva skal man gjøre med alt dette
Alle løser disse problemene på sin egen måte: for eksempel kan du publisere vanlige ledige stillinger for å bryte den onde sirkelen. Du kan finne ut hva ord som DevOps og Cloud Native betyr og bruke dem riktig og til poenget. Du kan utvikle deg i DevOps og demonstrere de riktige tilnærmingene ved ditt eksempel.
Vi holder en konferanse , som gir en mulighet til å gå dypere inn i tingene vi nettopp har snakket om. Det er flere grupper med rapporter for dette:
- Prosesser og kultur;
- Site Reliability Engineering;
- Cloud Native;
Hvordan velge hvor du skal dra? Det er et subtilt poeng her. På den ene siden handler DevOps om interaksjon, og vi ønsker virkelig at du skal delta på presentasjoner fra forskjellige blokker. På den annen side, hvis du er en utviklingsleder som kom til konferansen for å konsentrere deg om én spesifikk oppgave, så er det ingen som begrenser deg – selvsagt vil dette være en blokkering for prosesser og kultur. Ikke glem at du vil ha opptak etter konferansen (etter å ha fylt ut tilbakemeldingsskjemaet), slik at du alltid kan se mindre viktige presentasjoner senere.
På selve konferansen kan du selvsagt ikke gå på tre spor samtidig, så vi organiserer programmet på en slik måte at hver tidsluke har temaer for enhver smak.
Alt som gjenstår er å forstå hva du skal gjøre hvis du er DevOps-ingeniør! Prøv først å finne ut hva du faktisk gjør. Vanligvis liker de å kalle dette ordet:
- Utviklere som jobber med infrastruktur. Rapportgruppene om SRE og Cloud Native passer best for deg.
- Systemadministratorer. Det er mer komplisert her. DevOops handler ikke om systemadministrasjon. Heldigvis finnes det mange gode konferanser, bøker, artikler, videoer på internett osv. om temaet systemadministrasjon. På den annen side, hvis du er interessert i å utvikle deg selv når det gjelder å forstå kultur og prosesser, lære om skyteknologier og detaljene i livet med Cloud Native, så vil vi gjerne se deg! Tenk på dette: du driver med administrasjon, og hva vil du gjøre? For å unngå å plutselig havne i en ubehagelig situasjon, bør du lære det nå.
Det er et annet alternativ: du vedvarer og fortsetter å hevde at du er det spesifikt en DevOps-ingeniør og ingenting annet, uansett hva det betyr. Da må vi skuffe deg, DevOops er ikke en konferanse for DevOps-ingeniører!
Skyv fra i München
DevOops 2020 Moskva arrangeres 29.-30. april i Moskva, billetter er allerede tilgjengelig .
Alternativt kan du til 8. februar. Vær oppmerksom på at når du fyller ut skjemaet, må du velge målgruppen som vil ha mest nytte av rapporten din (det er en overraskelse begravd i listen).
Kilde: www.habr.com