Hva skal til for at et IT-selskap skal lykkes i 2019? Forelesere på konferanser og meetups sier mange høye ord som ikke alltid er forståelige for vanlige mennesker. Kampen om distribusjonstid, mikrotjenester, forlatelse av monolitten, DevOps-transformasjon og mye, mye mer. Hvis vi forkaster verbal skjønnhet og snakker direkte og på russisk, kommer alt ned til en enkel avhandling: lag et produkt av høy kvalitet, og gjør det med komfort for teamet.
Det siste har blitt kritisk viktig. Næringslivet har endelig kommet til den konklusjonen at en komfortabel utviklingsprosess øker produktiviteten, og hvis alt er feilsøkt og fungerer som en klokke, gir det også et visst handlingsrom i kritiske situasjoner. Det var en gang, for denne manøverens skyld, kom en viss smart person med sikkerhetskopier, men industrien utvikler seg, og vi kom til DevOps-ingeniører - folk som gjør prosessen med samhandling mellom utvikling og ekstern infrastruktur til noe tilstrekkelig og ikke relatert til sjamanisme.
Hele denne "modulære" historien er fantastisk, men... Det hendte at noen av administratorene brått ble kalt DevOps, og DevOps-ingeniørene selv begynte å bli pålagt å ha minst ferdighetene til telepati og klarsyn.
Før vi snakker om moderne problemer med å tilby infrastruktur, la oss definere hva vi mener med dette begrepet. For øyeblikket har situasjonen utviklet seg på en slik måte at vi har nådd dualiteten til dette konseptet: infrastruktur kan være betinget ekstern og betinget intern.
Med ekstern infrastruktur mener vi alt som sikrer funksjonaliteten til tjenesten eller produktet som teamet utvikler. Dette er applikasjons- eller nettsideservere, hosting og andre tjenester som sikrer funksjonaliteten til produktet.
Den interne infrastrukturen omfatter tjenester og utstyr som brukes av utviklingsteamet selv og andre ansatte, som det vanligvis er mange av. Dette er interne servere til kodelagringssystemer, en lokalt utplassert oppgavebehandler og alt, alt, alt som finnes på bedriftens intranett.
Hva gjør en systemadministrator i en bedrift? I tillegg til arbeidet med å administrere nettopp dette bedriftsintranettet, bærer det ofte byrden av økonomiske bekymringer for å sikre driften av kontorutstyr. Administratoren er den samme fyren som raskt vil dra en ny systemenhet eller en ekstra bærbar datamaskin klar til bruk fra bakrommet, gi ut et nytt tastatur og krype på alle fire gjennom kontorene og strekke Ethernet-kabelen. En administrator er en lokal eier og hersker over ikke bare interne og eksterne servere, men også en bedriftsleder. Ja, noen administratorer kan bare jobbe i systemplanet, uten maskinvare. De bør deles inn i en egen underklasse av "infrastruktursystemadministratorer." Og noen spesialiserer seg på å betjene utelukkende kontorutstyr; heldigvis, hvis selskapet har mer enn hundre personer, tar arbeidet aldri slutt. Men ingen av dem er devops.
Hvem er DevOps? Devops er karer som snakker om samspillet mellom programvareutvikling og ekstern infrastruktur. Mer presist er moderne devops involvert i utviklings- og distribusjonsprosessene mye dypere enn administratorer som bare lastet opp oppdateringer til ftp noen gang var involvert. En av nøkkeloppgavene til en DevOps-ingeniør nå er å sikre en komfortabel og effektivt strukturert prosess med interaksjon mellom utviklingsteam og produktinfrastruktur. Det er disse menneskene som er ansvarlige for å distribuere tilbakerulling og distribusjonssystemer; det er disse menneskene som tar litt av belastningen på utviklerne og konsentrerer seg så mye som mulig om deres ekstremt viktige oppgave. Samtidig vil devops aldri kjøre en ny kabel eller utstede en ny bærbar datamaskin fra bakrommet (c) KO
Hva er fangsten?
Til spørsmålet "Hvem er DevOps?" halvparten av arbeiderne i felten begynner å svare noe sånt som "Vel, kort sagt, dette er adminen som ..." og videre i teksten. Ja, en gang i tiden, da profesjonen som DevOps-ingeniør nettopp dukket opp fra de mest talentfulle administratorene når det gjelder vedlikehold av tjenester, var ikke forskjellene mellom dem åpenbare for alle. Men nå, når funksjonene til devops og admin i teamet har blitt radikalt forskjellige, er det uakseptabelt å forveksle dem med hverandre, eller til og med likestille dem.
Men hva betyr dette for næringslivet?
Ansette, det handler om det.
Du åpner en ledig stilling for "Systemadministrator", og kravene som er oppført der er "samhandling med utvikling og kunder", "CI/CD leveringssystem", "vedlikehold av bedriftens servere og utstyr", "administrasjon av interne systemer" og så videre. på; du skjønner at arbeidsgiver snakker tull. Haken er at i stedet for "Systemadministrator" skal stillingstittelen være "DevOps Engineer", og hvis denne tittelen endres, faller alt på plass.
Men hvilket inntrykk får man når man leser en slik stilling? At selskapet leter etter en flermaskinsoperatør som vil ta i bruk både versjonskontroll og overvåkingssystem og vil klemme vrideren med tennene...
Men for ikke å øke graden av rusavhengighet på arbeidsmarkedet, er det nok å kalle ledige stillinger ved deres rette navn og tydelig forstå at en DevOps-ingeniør og en systemadministrator er to forskjellige enheter. Men det ukueligge ønsket fra noen arbeidsgivere om å presentere en bredest mulig liste over krav til en kandidat fører til at "klassiske" systemadministratorer slutter å forstå hva som skjer rundt dem. Hva, yrket muterer og de ligger bak tiden?
Nei nei og en gang til nei. Infrastrukturadministratorer som skal administrere selskapets interne servere, eller besette L2/L3-støttestillinger og hjelpe andre ansatte, har ikke gått bort og kommer ikke til å forsvinne.
Kan disse spesialistene bli DevOps-ingeniører? Selvfølgelig kan de det. Faktisk er dette et relatert miljø som krever systemadministrasjonskompetanse, men i tillegg til dette kommer arbeid med overvåking, leveringssystemer og generelt tett samhandling med utviklings- og testteamet.
Et annet DevOps-problem
Faktisk er alt ikke begrenset til bare ansettelser og konstant forvirring mellom administratorer og devops. På et tidspunkt ble virksomheten møtt med problemet med å levere oppdateringer og samhandling av utviklingsteamet med den endelige infrastrukturen.
Kanskje det var da en onkel med glitrende øyne reiste seg på scenen til en konferanse og sa: «Vi gjør dette og kaller det DevOps. Disse gutta vil løse alle dine problemer» - og begynte å fortelle hvor godt livet er i selskapet etter å ha implementert DevOps-praksis.
Det er imidlertid ikke nok å ansette en DevOps-ingeniør for å få alt til å fungere som det skal. Selskapet må gjennomgå en fullstendig DevOps-transformasjon, det vil si at rollen og evnene til våre DevOps også må forstås tydelig på siden av produktutviklings- og testteamet. Vi har en "fantastisk" historie om dette emnet som fullt ut illustrerer all brutaliteten som skjer noen steder.
Situasjon. DevOps er påkrevd for å distribuere et versjonsrullingssystem uten å fordype seg i hvordan det vil fungere. La oss anta at det i brukersystemet er separate felt for fornavn, etternavn og passord. En ny versjon av produktet kommer ut, men for utviklere er en "rollback" bare en tryllestav som vil fikse alt, og de vet ikke engang hvordan det fungerer. Så, for eksempel, i den neste oppdateringen kombinerte utviklerne for- og etternavnsfeltene, rullet det ut i produksjon, men versjonen er treg av en eller annen grunn. Hva skjer? Ledelsen kommer til devops og sier "Pull the switch!", det vil si ber ham rulle tilbake til forrige versjon. Hva gjør devops? Den ruller tilbake til forrige versjon, men siden utviklerne ikke ønsket å finne ut hvordan denne tilbakeføringen ble gjort, fortalte ingen devops-teamet at databasen også måtte rulles tilbake. Som et resultat krasjer alt for oss, og i stedet for et tregt nettsted, ser brukerne en "500" feil, fordi den gamle versjonen ikke fungerer med feltene til den nye databasen. Devops vet ikke om dette. Utviklerne er tause. Ledelsen begynner å miste nervene og pengene sine og husker sikkerhetskopiene, og tilbyr å rulle tilbake fra dem slik at "i det minste noe vil fungere." Som et resultat mister brukere all data over en periode.
Nøttene går selvfølgelig til devops, som "ikke laget et skikkelig tilbakerullingssystem", og ingen bryr seg om at elgene i denne historien er utviklere.
Konklusjonen er enkel: uten en normal tilnærming til DevOps som sådan, er det til liten nytte.
Det viktigste å huske: en DevOps-ingeniør er ikke en tryllekunstner, og uten kvalitetskommunikasjon og toveis interaksjon med utvikling, vil han ikke takle oppgavene sine. Utviklere kan ikke stå alene med sine "problemer" eller få kommandoen "ikke bland deg med utviklerne, jobben deres er å kode," og så håpe at alt i et kritisk øyeblikk vil fungere som det skal. Det er ikke slik det fungerer.
I hovedsak er DevOps en kompetanse på grensen mellom ledelse og teknologi. Dessuten er det langt fra åpenbart at det skal være mer teknologi enn ledelse i denne cocktailen. Hvis du virkelig ønsker å bygge raskere og mer effektive utviklingsprosesser, må du stole på devops-teamet ditt. Han kjenner de riktige verktøyene, han har gjennomført lignende prosjekter, han vet hvordan det skal gjøres. Hjelp ham, lytt til hans råd, ikke prøv å isolere ham til en slags autonom enhet. Hvis administratorer kan jobbe på egenhånd, så er devops ubrukelige i dette tilfellet; de vil ikke kunne hjelpe deg med å bli bedre hvis du selv ikke vil akseptere denne hjelpen.
Og en siste ting: slutt å fornærme infrastrukturadministratorer. De har sin egen, ekstremt viktige arbeidsfront. Ja, en administrator kan bli DevOps-ingeniør, men dette bør skje på forespørsel fra personen selv, og ikke under press. Og det er ikke noe galt med at en systemadministrator ønsker å forbli systemadministrator - dette er hans separate yrke og hans rett. Hvis du ønsker å gjennomgå en profesjonell transformasjon, må du aldri glemme at du ikke bare må bygge opp teknologiske ferdigheter, men også ledelsesmessige. Mest sannsynlig vil det være opp til deg som leder å bringe alle disse menneskene sammen og lære dem å kommunisere på samme språk.
Kilde: www.habr.com