Hvad skal der til, for at en it-virksomhed får succes i 2019? Foredragsholdere til konferencer og meetups siger mange høje ord, som ikke altid er forståelige for normale mennesker. Kampen om implementeringstid, mikrotjenester, opgivelse af monolitten, DevOps-transformation og meget, meget mere. Hvis vi kasserer verbal skønhed og taler direkte og på russisk, kommer det hele til en simpel tese: lav et produkt af høj kvalitet og gør det med komfort for holdet.
Sidstnævnte er blevet kritisk vigtigt. Erhvervslivet er endelig nået til den konklusion, at en behagelig udviklingsproces øger produktiviteten, og hvis alt er debugget og fungerer som et ur, giver det også et vist råderum i kritiske situationer. Engang, for denne manøvre skyld, kom en vis smart person med backups, men industrien udvikler sig, og vi kom til DevOps-ingeniører - folk, der gør processen med interaktion mellem udvikling og ekstern infrastruktur til noget passende og ikke relateret til shamanisme.
Hele denne "modulære" historie er vidunderlig, men... Det skete så, at nogle af administratorerne brat blev døbt DevOps, og DevOps-ingeniører selv begyndte at blive påkrævet i det mindste at have evnerne til telepati og clairvoyance.
Før vi taler om moderne problemer med at levere infrastruktur, lad os definere, hvad vi mener med dette udtryk. På nuværende tidspunkt har situationen udviklet sig på en sådan måde, at vi har nået dualiteten af dette koncept: Infrastruktur kan være betinget ekstern og betinget intern.
Med ekstern infrastruktur mener vi alt, der sikrer funktionaliteten af den service eller det produkt, som teamet udvikler. Disse er applikations- eller webstedsservere, hosting og andre tjenester, der sikrer produktets funktionalitet.
Den interne infrastruktur omfatter tjenester og udstyr, som bruges af udviklingsteamet selv og andre medarbejdere, som der normalt er mange af. Disse er interne servere til kodelagringssystemer, en lokalt installeret task manager og alt, alt, alt, hvad der findes på virksomhedens intranet.
Hvad laver en systemadministrator i en virksomhed? Ud over arbejdet med at administrere netop dette virksomhedsintranet, bærer det ofte byrden af økonomiske bekymringer for at sikre funktionaliteten af kontorudstyr. Administratoren er den samme fyr, som hurtigt vil trække en ny systemenhed eller en ekstra bærbar computer klar til brug fra baglokalet, give et nyt tastatur ud og kravle på alle fire gennem kontorerne og strække Ethernet-kablet. En administrator er en lokal ejer og hersker over ikke kun interne og eksterne servere, men også en virksomhedsleder. Ja, nogle administratorer kan kun arbejde i systemplanet uden hardware. De bør adskilles i en separat underklasse af "infrastruktursystemadministratorer." Og nogle specialiserer sig i udelukkende at servicere kontorudstyr; heldigvis, hvis virksomheden har mere end hundrede mennesker, slutter arbejdet aldrig. Men ingen af dem er devops.
Hvem er DevOps? Devops er fyre, der taler om samspillet mellem softwareudvikling og ekstern infrastruktur. Mere præcist er moderne devops involveret i udviklings- og implementeringsprocesserne meget dybere, end administratorer, der blot uploadede opdateringer til ftp, nogensinde var involveret. En af nøgleopgaverne for en DevOps-ingeniør er nu at sikre en komfortabel og effektivt struktureret proces med interaktion mellem udviklingsteams og produktinfrastruktur. Det er disse mennesker, der er ansvarlige for at implementere rollback og implementeringssystemer; det er disse mennesker, der tager noget af byrden fra udviklerne og koncentrerer sig så meget som muligt om deres ekstremt vigtige opgave. Samtidig vil devops aldrig køre et nyt kabel eller udstede en ny bærbar computer fra baglokalet (c) KO
Hvad er fangsten?
Til spørgsmålet "Hvem er DevOps?" halvdelen af arbejderne i marken begynder at svare noget i stil med "Nå, kort sagt, det er administratoren, der ..." og videre i teksten. Ja, engang, hvor professionen som DevOps-ingeniør lige var ved at dukke op fra de mest talentfulde administratorer med hensyn til servicevedligeholdelse, var forskellene mellem dem ikke indlysende for alle. Men nu, hvor funktionerne for devops og admin i teamet er blevet radikalt anderledes, er det uacceptabelt at forveksle dem med hinanden, eller endda ligestille dem.
Men hvad betyder det for erhvervslivet?
Ansættelse, det handler om det.
Du opretter en ledig stilling som "Systemadministrator", og de krav, der er opstillet der, er "interaktion med udvikling og kunder", "CI/CD leveringssystem", "vedligeholdelse af virksomhedens servere og udstyr", "administration af interne systemer" mv. på; du forstår, at arbejdsgiveren taler sludder. Fangsten er, at i stedet for "Systemadministrator" skal den ledige stilling være "DevOps-ingeniør", og hvis denne titel ændres, falder alt på plads.
Men hvilket indtryk får man, når man læser sådan en stilling? At virksomheden leder efter en multi-maskine operatør, der vil implementere både versionskontrol og overvågningssystem og vil klemme twisteren med tænderne...
Men for ikke at øge graden af stofmisbrug på arbejdsmarkedet er det nok at kalde ledige stillinger ved deres rette navne og klart forstå, at en DevOps-ingeniør og en systemadministrator er to forskellige enheder. Men nogle arbejdsgiveres uimodtagelige ønske om at præsentere den bredest mulige liste af krav til en kandidat fører til, at "klassiske" systemadministratorer holder op med at forstå, hvad der sker omkring dem. Hvad, erhvervet muterer, og de er bagud i tiden?
Nej nej og endnu en gang nej. Infrastrukturadministratorer, der vil administrere virksomhedens interne servere eller besætte L2/L3-supportstillinger og hjælpe andre medarbejdere, er ikke gået væk og vil ikke forsvinde.
Kan disse specialister blive DevOps-ingeniører? Selvfølgelig kan de det. Faktisk er der tale om et relateret miljø, som kræver systemadministrative kompetencer, men derudover kommer arbejde med overvågning, leveringssystemer og i det hele taget tæt samspil med udviklings- og testteamet.
Endnu et DevOps-problem
Faktisk er alt ikke begrænset til kun ansættelse og konstant forvirring mellem administratorer og devops. På et tidspunkt stod virksomheden over for problemet med at levere opdateringer og interaktion mellem udviklingsteamet og den endelige infrastruktur.
Måske var det, da en onkel med funklende øjne rejste sig på scenen til en konference og sagde: "Vi gør det her og kalder det DevOps. Disse fyre vil løse alle dine problemer” - og begyndte at fortælle, hvor godt liv er i virksomheden efter implementering af DevOps-praksis.
Det er dog ikke nok at hyre en DevOps-ingeniør for at få alt til at fungere, som det skal. Virksomheden skal gennemgå en komplet DevOps-transformation, det vil sige, at vores DevOps' rolle og kapacitet også skal forstås tydeligt på siden af produktudviklings- og testteamet. Vi har en "vidunderlig" historie om dette emne, der fuldt ud illustrerer al den brutalitet, der sker nogle steder.
Situation. DevOps er påkrævet for at implementere et version rollback-system uden rigtig at dykke ned i, hvordan det vil fungere. Lad os antage, at der i brugersystemet er separate felter for fornavn, efternavn og adgangskode. En ny version af produktet kommer ud, men for udviklere er en "rollback" bare en tryllestav, der vil ordne alt, og de ved ikke engang, hvordan det virker. Så for eksempel i den næste patch kombinerede udviklerne for- og efternavnsfelterne, rullede det ud i produktion, men versionen er langsom af en eller anden grund. Hvad sker der? Ledelsen kommer til devops og siger "Træk kontakten!", det vil sige beder ham om at rulle tilbage til den tidligere version. Hvad laver devops? Det ruller tilbage til den tidligere version, men da udviklerne ikke ønskede at finde ud af, hvordan denne tilbagerulning blev gjort, fortalte ingen devops-teamet, at databasen også skulle rulles tilbage. Som et resultat går alt ned for os, og i stedet for en langsom hjemmeside ser brugerne en "500" fejl, fordi den gamle version ikke fungerer med felterne i den nye database. Devops ved ikke om dette. Udviklerne er tavse. Ledelsen begynder at miste deres nerver og penge og husker sikkerhedskopierne og tilbyder at rulle tilbage fra dem, så "i det mindste noget vil fungere." Som et resultat mister brugere alle deres data over en periode.
Nødderne går selvfølgelig til devops, som "ikke lavede et ordentligt tilbagerulningssystem", og ingen bekymrer sig om, at elgene i denne historie er udviklere.
Konklusionen er enkel: Uden en normal tilgang til DevOps som sådan, er det til lidt nytte.
Det vigtigste at huske: en DevOps-ingeniør er ikke en tryllekunstner, og uden kvalitetskommunikation og tovejsinteraktion med udvikling, vil han ikke klare sine opgaver. Udviklere kan ikke stå alene med deres "problemer" eller få kommandoen "bland dig ikke i udviklerne, deres job er at kode", og så håbe, at alt på et kritisk tidspunkt vil fungere, som det skal. Sådan fungerer det ikke.
Grundlæggende er DevOps en kompetence på grænsen mellem ledelse og teknologi. Desuden er det langt fra indlysende, at der skal være mere teknologi end ledelse i denne cocktail. Hvis du virkelig ønsker at bygge hurtigere og mere effektive udviklingsprocesser, skal du stole på dit devops-team. Han kender de rigtige værktøjer, han har implementeret lignende projekter, han ved, hvordan man gør det. Hjælp ham, lyt til hans råd, prøv ikke at isolere ham til en slags autonom enhed. Hvis admins kan arbejde på egen hånd, så er devops ubrugelige i dette tilfælde; de vil ikke være i stand til at hjælpe dig med at blive bedre, hvis du ikke selv ønsker at acceptere denne hjælp.
Og en sidste ting: stop med at fornærme infrastrukturadministratorer. De har deres egen ekstremt vigtige front på arbejdet. Ja, en administrator kan blive DevOps-ingeniør, men dette bør ske på opfordring fra personen selv og ikke under pres. Og der er ikke noget galt i, at en systemadministrator ønsker at forblive systemadministrator - det er hans separate erhverv og hans ret. Hvis du ønsker at gennemgå en professionel transformation, så må du aldrig glemme, at du ikke kun skal opbygge teknologiske færdigheder, men også ledelsesmæssige færdigheder. Mest sandsynligt vil det være op til dig som leder at bringe alle disse mennesker sammen og lære dem at kommunikere på samme sprog.
Kilde: www.habr.com