Om administratorer, DevOps, endeløs forvirring og DevOps-transformasjon inne i selskapet

Hva trengs for å lykkes som IT-selskap i 2019? Forelesere på konferanser og meetups snakker mye om storslåtte og ikke alltid forståelige begreper for vanlige mennesker. Kampen om deploytid, mikrotjenester, avvik fra monolitter, DevOps-transformasjon og mye, mye mer. Hvis vi ser bort fra den språklige skjønnheten og snakker direkte og på norsk, kan alt sammen oppsummeres med en enkel tese: lag et kvalitetsprodukt, og gjør det på en måte som er komfortabel for teamet.

Det siste har blitt kritisk viktig. Bedrifter har endelig innsett at en komfortabel utviklingsprosess øker produktiviteten, og hvis alt er innstilt og fungerer som det skal, gir det også rom for manøvrering i kritiske situasjoner. Tidligere ble det manøvrer av en klok person funnet opp backup-løsninger, men industrien har utviklet seg, og vi har kommet til DevOps-ingene – folk som forvandler prosessen med interaksjon mellom utvikling og ekstern infrastruktur til noe fornuftig og ikke beslektet med sjamanisme.

Hele denne historien om "modulbasert" er vakker, men… Det har seg slik at enkelte administratorer brått har blitt omtalt som DevOps, og fra selve DevOps-ingeniørene blir det stilt krav til minst telepatisk og klarsynt ferdigheter.

Før vi snakker om moderne utfordringer innen infrastruktur, la oss definere hva vi mener med dette begrepet. På nåværende tidspunkt har situasjonen utviklet seg til at vi har fått en dualitet i dette begrepet: infrastruktur kan betraktes som både ekstern og intern.

Ved ekstern infrastruktur mener vi alt som sikrer at tjenesten eller produktet som teamet arbeider med, fungerer. Dette inkluderer servere for applikasjoner eller nettsteder, hosting og andre tjenester som sørger for at produktet fungerer.

Intern infrastruktur omfatter tjenester og utstyr som brukes av selve utviklingsteamet og andre ansatte, som vanligvis også er ganske mange. Dette inkluderer interne servere for kodelagringssystemer, lokalt distribuerte oppgavebehandlere og alt, alt, alt som eksisterer innenfor det bedriftsinterne intranettet.

Hva driv personen med i selskapet som systemadministrator? I tillegg til å administrere det interne intranettet, ligger det ofte et ansvar for å sikre at kontorutstyret fungerer. Administratoren er den typen fyr som raskt henter en ny datamaskin eller et klart arbeidsreserve-laptop fra lageret, utdeler et nytt tastatur og krabber rundt i rommene og trekker Ethernet-kabler. Administratoren er den lokale herren og mesteren av ikke bare interne, men også eksterne servere, men også av drift. Ja, noen administratorer kan jobbe kun innenfor systemets rammer, uten maskinvare. De fortjener å bli fremhevet som en egen underklasse «infrastruktur-systemadministratorer». Andre spesialiserer seg på å vedlikeholde utelukkende kontorutstyr, noe som alltid er nødvendig hvis selskapet har mer enn hundre ansatte. Men verken de eller de andre er DevOps.

Hvem er så DevOps? DevOps er folk som jobber med samspillet mellom programvareutvikling og ekstern infrastruktur. Mer presist, moderne DevOps er dypt involvert i utviklings- og distribusjonsprosessene mye mer enn administratorer noen gang har vært, i tillegg til å bare laste opp oppdateringer til en FTP-server. En av hovedoppgavene til en DevOps-ingeniør i dag er å sikre en komfortabel og effektiv prosess for samhandling mellom utviklingsteamene og produktinfrastrukturen. Det er nettopp disse menneskene som er ansvarlige for implementeringen av tilbakeførings- og distribusjonssystemer, disse menneskene avlaster deler av belastningen fra utviklerne og fokuserer mest mulig på sin ekstremt viktige oppgave. DevOps vil uansett aldri trekke en ny kabel eller utdelle en ny laptop fra lageret (c) KO

Hvor er fellen?

Når man stiller spørsmålet «Hvem er DevOps?», begynner halvparten av folk i bransjen å svare noe sånt som «Nå, det er kort sagt en administrator som…» og så videre. Ja, en gang for lenge siden, da yrket DevOps-ingeniør så vidt begynte å ta form fra de mest talentfulle administratorene som jobbet med service, var forskjellene mellom dem ikke så åpenbare. Men nå, når funksjonene til DevOps og administratorer i et team har blitt radikalt forskjellige, er det uakseptabelt å forveksle dem, eller til og med sette dem som like.

Men hva betyr dette for virksomheten?

Rekruttering, det er det det handler om.

Du legger ut en stillingsannonse for «Systemadministrator», og der står det krav som «samarbeid med utvikling og kunder», «CI/CD distribusjonssystem», «vedlikehold av selskapets servere og utstyr», «administrasjon av interne systemer» og så videre; du forstår at arbeidsgiveren snakker tull. Problemet er at i overskriften burde det stått «DevOps-ingeniør», og hvis overskriften endres, faller alt på plass.

Men hvilket inntrykk skapes ved å lese en slik stillingsannonse? At selskapet leter etter en altmuligmann som både kan sette opp versjonskontrollsystemet og overvåkingssystemet, og som for eksempel kan klemme ut en spesifikasjon med tennene…

For å unngå å heve graden av forvirring på arbeidsmarkedet, er det nok å kalle stillinger med deres riktige navn og ha en klar forståelse av at DevOps-ingeniør og systemadministrator er to forskjellige enheter. Men det uopphørlige ønsket fra noen arbeidsgivere om å stille krav til kandidater som er så brede som mulig, fører til at «klassiske» systemadministratorer slutter å forstå hva som skjer rundt dem. Hva, har yrket mutert og de har hengt etter?

Nei, nei og atter nei. Infrastrukturadministratorer som vil administrere selskapets interne servere, eller som vil innta L2/L3-støtteposisjoner og hjelpe andre ansatte, er ikke borte og har ikke forsvunnet.

Kan disse spesialistene bli DevOps-ingeniører? Selvfølgelig kan de det. Faktisk er dette nært beslektede miljøer som krever ferdigheter innen systemadministrasjon, men i tillegg til dette kreves det også arbeid med overvåking, distribusjonssystemer og, generelt, tett samarbeid med utviklings- og testteamet.

En annen utfordring innen DevOps

Faktisk stopper det ikke bare med ansettelser og vedvarende forvirring mellom administratorer og DevOps-ere. På et tidspunkt sto bedriften overfor problemet med å levere oppdateringer og samarbeidet mellom utviklingsteamet og den endelige infrastrukturen.

Kanskje var det da en kar med glitrende øyne kom opp på scenen på en konferanse og sa: «Og vi gjør det slik, og kaller det DevOps. Disse gutta vil løse alle problemene deres» — og begynte å fortelle hvordan livet er bra i selskapet etter implementeringen av DevOps-praksis.

Men det er ikke nok å ansette en DevOps-ingeniør for at alt skal fungere «som det skal». Selskapet må gjennomgå en fullstendig DevOps-transformasjon, det vil si at rollen og mulighetene til vår DevOps-er også må være tydelig forstått på siden av utviklings- og testteamet. På dette området har vi en «fantastisk» historie som fullt ut illustrerer den av og til vanskelige situasjonen.

Situasjonen. DevOps blir bedt om å sette opp et versjonsrulleringssystem uten å bli nærmere informert om hvordan det skal fungere. La oss anta at i systemet 'Users' er det separate felt for navn, etternavn og passord. En ny versjon av produktet blir lansert, men for utviklerne er 'rulling tilbake' bare en tryllestav som fikser alt, og de har ingen anelse om hvordan det fungerer. Så, for eksempel, i en ny patch har utviklerne samlet felt for navn og etternavn, de ruller dette ut i produksjon, og versjonen henger av ukjente grunner. Hva skjer? Ledelsen kommer til DevOps og sier 'Dra i bryteren!', det vil si de ber ham rulle tilbake til den forrige versjonen. Hva gjør DevOps? Han ruller tilbake til den forrige versjonen, men ettersom utviklerne ikke ønsket å sette seg inn i hvordan denne tilbakeføringen gjøres, sa ingen til DevOps at det også trengs å rulle tilbake databasen. Resultatet blir at alt faller sammen, og brukerne ser i stedet for en treg nettside feilmeldingen '500', fordi den gamle versjonen ikke fungerer med feltene i den nye databasen. DevOps er ikke klar over dette. Utviklerne forblir tause. Ledelsen begynner å miste besinnelsen og penger, og husker backupene, og foreslår å rulle tilbake fra dem slik at 'i det minste noe skal fungere'. Som et resultat mister brukerne alle sine data for en viss tidsperiode.

Det er selvsagt DevOps som får skylden for at han 'ikke laget et korrekt rullingssystem', mens de som er idioter i denne historien – utviklerne – ikke får noen omtale.

Konklusjonen er enkel: uten en ordentlig tilnærming til DevOps, er det ikke mye nytte å hente.
Det viktigste å huske på: En DevOps-ingeniør er ikke en trollmann, og uten kvalitetskommunikasjon og toveis interaksjon med utviklingsteamet, vil han ikke klare oppgavene sine. DevOps kan ikke overlates til seg selv med sine 'problemer' eller få beskjed om 'ikke involvere deg i utviklerne, deres jobb er å kode', og så håpe at alt vil fungere som det skal i kritiske øyeblikk. Slik fungerer det ikke.

I bunn og grunn er DevOps kompetanser som ligger i skjæringspunktet mellom ledelse og teknologi. Det er heller ikke åpenbart at det i denne teknologiske cocktailen må være mer av teknologien enn av ledelse. Hvis du virkelig ønsker å bygge raskere og mer effektive utviklingsprosesser, må du stole på DevOps-eren din. Han vet hvilke verktøy som trengs, har implementert lignende prosjekter, og vet hvordan ting gjøres. Hjelp ham, hør på rådene hans, og prøv ikke å isolere ham i en autonom avdeling. Hvis administratorer kan jobbe på egen hånd, vil DevOps-ere i slike tilfeller være unyttige; de kan ikke hjelpe deg med å bli bedre hvis du ikke ønsker å ta imot den hjelpen.

Og til slutt: slutt å fornærme infrastrukturadministratorene. De har sin egen, ekstremt viktige arbeidsfront. Ja, en administrator kan bli DevOps-ingeniør, men dette må skje etter eget ønske, ikke under tvang. Det er ingenting galt med at en systemadministrator ønsker å forbli systemadministrator — det er hans separate yrke og hans rett. Hvis det er et ønske om å gjennomgå en profesjonell transformasjon, må man ikke glemme at man må bygge opp både teknologiske ferdigheter og lederegenskaper. Alle disse menneskene må sannsynligvis settes sammen og læres opp til å kommunisere på ett språk av deg som leder.

Kilde: habr.com