DevOps er blevet et meget populært emne i løbet af de sidste par år. Mange mennesker drømmer om at være med, men som praksis viser, ofte kun på grund af lønniveauet.
Nogle mennesker angiver DevOps på deres CV, selvom de ikke altid kender eller forstår essensen af udtrykket. Nogle mennesker tror, at efter at have studeret Ansible, GitLab, Jenkins, Terraform og lignende (listen kan fortsættes efter din smag), vil du straks blive en "devopsist". Dette er naturligvis ikke sandt.
De seneste par år har jeg hovedsageligt været involveret i implementeringen af DevOps i forskellige virksomheder. Før det arbejdede han i mere end 20 år i stillinger lige fra systemadministrator til it-direktør. I øjeblikket DevOps Lead Engineer hos Playgendary.
Hvem er DevOps
Ideen til at skrive en artikel opstod efter et andet spørgsmål: "hvem er DevOps?" Der er stadig ingen fastlagt betegnelse for, hvad eller hvem det er. Nogle af svarene er allerede i dette . Først vil jeg fremhæve hovedpunkterne fra den, og derefter vil jeg dele mine observationer og tanker.
DevOps er ikke en specialist, der kan hyres, ikke et sæt hjælpeprogrammer, og ikke en afdeling af udviklere med ingeniører.
DevOps er en filosofi og metode.
Med andre ord er det et sæt praksisser, der hjælper udviklere med aktivt at interagere med systemadministratorer. Altså at forbinde og integrere arbejdsprocesser i hinanden.
Med fremkomsten af DevOps forblev strukturen og rollerne for specialister de samme (der er udviklere, der er ingeniører), men reglerne for interaktion er ændret. Grænserne mellem afdelingerne er udvisket.
Målene for DevOps kan beskrives i tre punkter:
- Softwaren skal opdateres regelmæssigt.
- Software skal laves hurtigt.
- Softwaren bør implementeres bekvemt og på kort tid.
Der er ikke et enkelt værktøj til DevOps. Opsætning, levering og undersøgelse af flere produkter betyder ikke, at DevOps er dukket op i virksomheden. Der er mange værktøjer, og de bruges alle på forskellige stadier, men tjener ét fælles formål.
Og dette er kun en del af DevOps-værktøjerne
Jeg har interviewet folk til stillingen som DevOps-ingeniør i mere end 2 år nu, og jeg er blevet klar over, hvor vigtigt det er klart at forstå essensen af udtrykket. Jeg har akkumuleret specifikke erfaringer, observationer og tanker, som jeg gerne vil dele.
Fra interviewerfaring ser jeg følgende billede: specialister, der betragter DevOps som en stillingsbetegnelse, har normalt misforståelser med kolleger.
Der var et slående eksempel. En ung mand kom til et interview med en masse smarte ord på sit CV. Ved sine sidste tre job havde han 5-6 måneders erfaring. Jeg forlod to startups, fordi de "ikke tog fart." Men om det tredje firma sagde han, at ingen forstår ham der: udviklerne skriver kode på Windows, og direktøren tvinger denne kode til at blive "pakket ind" i almindelig Docker og indbygget i CI/CD-pipelinen. Fyren sagde en masse negative ting om sin nuværende arbejdsplads og sine kolleger - jeg ville bare svare: "Så du vil ikke sælge en elefant."
Så stillede jeg ham et spørgsmål, der står højt på min liste for hver kandidat.
— Hvad betyder DevOps for dig personligt?
- Generelt eller hvordan opfatter jeg det?
Jeg var interesseret i hans personlige mening. Han kendte teorien og oprindelsen til udtrykket, men han var meget uenig i dem. Han mente, at DevOps var en jobtitel. Det er her roden til hans problemer ligger. Samt andre specialister med samme mening.
Arbejdsgivere, der har hørt meget om "magien ved DevOps", ønsker at finde en person, der vil komme og skabe denne "magi". Og ansøgere fra kategorien "DevOps er et job" forstår ikke, at de med denne tilgang ikke vil være i stand til at leve op til forventningerne. Og generelt skrev de DevOps på deres CV, fordi det er en trend, og de betaler meget for det.
DevOps metodologi og filosofi
Metodikken kan være teoretisk og praktisk. I vores tilfælde er det den anden. Som jeg nævnte ovenfor, er DevOps et sæt af praksisser og strategier, der bruges til at nå erklærede mål. Og i hvert enkelt tilfælde, afhængigt af virksomhedens forretningsprocesser, kan det variere betydeligt. Hvilket hverken gør det bedre eller værre.
DevOps-metoden er kun et middel til at nå mål.
Nu om, hvad DevOps-filosofien er. Og dette er nok det sværeste spørgsmål.
Det er ret svært at formulere et kort og kortfattet svar, for det er endnu ikke formaliseret. Og da tilhængere af DevOps-filosofien er mere engagerede i praksis, er der simpelthen ikke tid til at filosofere. Dette er dog en meget vigtig proces. Desuden er det direkte relateret til ingeniøraktiviteter. Der er endda et specialiseret vidensområde - .
Der var ikke et sådant emne på mit universitet, jeg var nødt til at studere alt på egen hånd ved hjælp af de materialer, jeg kunne finde i 90'erne. Emnet er valgfrit for ingeniøruddannelsen, deraf den manglende formalisering af svaret. Men de mennesker, der for alvor er fordybet i DevOps, begynder at føle en vis "ånd" eller "ubevidst omfattende" af alle virksomhedens processer.
Ved at bruge min egen erfaring forsøgte jeg at formalisere nogle af denne filosofis "postulater". Resultatet er følgende:
- DevOps er ikke noget uafhængigt, der kan adskilles i et separat viden- eller aktivitetsområde.
- Alle virksomhedens medarbejdere bør vejledes af DevOps-metoden, når de planlægger deres aktiviteter.
- DevOps påvirker alle processer i en virksomhed.
- DevOps eksisterer for at reducere tidsomkostningerne for alle processer i en virksomhed for at sikre udviklingen af dens tjenester og maksimal kundekomfort.
- DevOps, i moderne sprog, er den proaktive position for hver medarbejder i virksomheden, rettet mod at reducere tidsomkostninger og forbedre kvaliteten af IT-produkterne omkring os.
Jeg tror, at mine "postulater" er et separat emne til diskussion. Men nu er der noget at bygge videre på.
Hvad DevOps gør
Nøgleordet her er kommunikation. Der er en masse kommunikation, hvis initiativtager burde være præcis den samme DevOps-ingeniør. Hvorfor det? Fordi dette er filosofi og metode, og først derefter ingeniørviden.
Jeg kan ikke tale med 100% tillid om det vestlige arbejdsmarked. Men jeg ved ret meget om DevOps-markedet i Rusland. Ud over hundredvis af interviews har jeg i løbet af det seneste halvandet år deltaget i hundredvis af tekniske presales for "Implementering af DevOps"-tjenesten for store russiske virksomheder og banker.
I Rusland er DevOps stadig et meget ungt, men allerede populært emne. Så vidt jeg ved, var manglen på sådanne specialister i Moskva alene i 2019 mere end 1000 mennesker. Og ordet Kubernetes for arbejdsgivere er næsten som en rød klud for en tyr. Tilhængere af dette værktøj er klar til at bruge det, selv hvor det ikke er nødvendigt og økonomisk rentabelt. Arbejdsgiveren forstår ikke altid, i hvilke tilfælde, hvad der er mere passende at bruge, og med korrekt implementering koster vedligeholdelse af en Kubernetes-klynge 2-3 gange mere end at implementere en applikation ved hjælp af en konventionel klyngeordning. Brug det, hvor du virkelig har brug for det.
Implementering af DevOps er dyrt i form af penge. Og det er kun berettiget, hvor det giver økonomiske fordele på andre områder, og ikke alene.
DevOps ingeniører er i virkeligheden pionerer – det er dem, der burde være de første til at implementere denne metodik i virksomheden og bygge processer. For at dette skal lykkes, skal specialisten konstant interagere med medarbejdere og kolleger på alle niveauer. Som jeg plejer at sige, bør alle virksomhedens ansatte være involveret i DevOps implementeringsprocessen: fra rengøringsdamen til den administrerende direktør. Og dette er en forudsætning. Hvis det mest yngre medlem af teamet ikke ved og forstår, hvad DevOps er, og hvorfor visse organisatoriske handlinger udføres, vil en vellykket implementering ikke fungere.
En DevOps-ingeniør skal også bruge en administrativ ressource fra tid til anden. For eksempel for at overvinde "miljøresistens" - når teamet ikke er klar til at acceptere DevOps-værktøjer og -metoder.
Udvikleren bør kun skrive kode og tests. For at gøre dette har han ikke brug for en superstærk bærbar computer, som han vil installere og lokalt understøtte hele projektets infrastruktur på. For eksempel opbevarer en frontend-udvikler alle elementer i applikationen på sin bærbare computer, inklusive databasen, S3-emulatoren (minio) osv. Det vil sige, at han bruger meget tid på at vedligeholde denne lokale infrastruktur og på egen hånd kæmper med alle problemerne ved en sådan løsning. I stedet for at udvikle kode til fronten. Sådanne mennesker kan være meget modstandsdygtige over for enhver forandring.
Men der er teams, der tværtimod gerne introducerer nye værktøjer og metoder og deltager aktivt i denne proces. Selv i dette tilfælde blev kommunikationen mellem DevOps-ingeniøren og teamet ikke annulleret.
Når DevOps ikke er nødvendig
Der er situationer, hvor DevOps ikke er nødvendig. Dette er et faktum - det skal forstås og accepteres.
Først og fremmest gælder dette for alle virksomheder (især små virksomheder), når deres fortjeneste ikke direkte afhænger af tilstedeværelsen eller fraværet af it-produkter, der leverer informationstjenester til kunderne. Og her taler vi ikke om virksomhedens hjemmeside, det være sig et statisk "visitkort" eller med dynamiske nyhedsblokke osv.
DevOps er påkrævet, når din kundes tilfredshed og hans ønske om at vende tilbage til dig igen afhænger af tilgængeligheden af disse informationstjenester til interaktion med kunden, deres kvalitet og målretning.
Et slående eksempel er en velkendt bank. Virksomheden har ikke traditionelle kundekontorer, dokumentflowet foregår via post eller kurerer, og mange medarbejdere arbejder hjemmefra. Virksomheden er ophørt med kun at være en bank og er efter min mening blevet til en it-virksomhed med udviklede DevOps-teknologier.
Mange andre eksempler og foredrag kan findes i optagelserne af tematiske møder og konferencer. Jeg besøgte nogle af dem personligt - dette er en meget nyttig oplevelse for dem, der ønsker at udvikle sig i denne retning. Her er links til YouTube-kanaler med gode foredrag og materialer om DevOps:
Se nu på din virksomhed og tænk over dette: Hvor meget afhænger din virksomhed og dens overskud af it-produkter for at muliggøre kundeinteraktion?
Hvis din virksomhed sælger fisk i en lille butik, og det eneste it-produkt er to 1C: Enterprise-konfigurationer (Accounting og UNF), så giver det næppe mening at tale om DevOps.
Hvis du arbejder i en stor handels- og produktionsvirksomhed (du producerer for eksempel jagtrifler), så bør du tænke over det. Du kan tage initiativ og formidle til din ledelse mulighederne for implementering af DevOps. Nå, og på samme tid, lede denne proces. En proaktiv position er en af de vigtige principper i DevOps-filosofien.
Størrelsen og volumen af den årlige økonomiske omsætning er ikke hovedkriteriet for at afgøre, om din virksomhed har brug for DevOps.
Lad os forestille os en stor industrivirksomhed, der ikke interagerer direkte med kunderne. For eksempel nogle bilproducenter og bilproducenter. Jeg er ikke sikker nu, men fra min tidligere erfaring foregik al kundeinteraktion i mange år via e-mail og telefon.
Deres kunder er en begrænset liste over bilforhandlere. Og hver enkelt er tildelt en specialist fra producenten. Alt internt dokumentflow foregår gennem SAP ERP. Interne medarbejdere er i det væsentlige kunder i informationssystemet. Men denne IS styres af klassiske midler til styring af klyngesystemer. Hvilket udelukker muligheden for at bruge DevOps-praksis.
Deraf konklusionen: for sådanne virksomheder er implementeringen af DevOps ikke noget kritisk vigtigt, hvis vi husker målene med metodikken fra begyndelsen af artiklen. Men jeg udelukker ikke, at de bruger nogle DevOps-værktøjer i dag.
På den anden side er der mange små virksomheder, der udvikler software ved hjælp af DevOps metodologi, filosofi, praksis og værktøjer. Og de mener, at omkostningerne ved at implementere DevOps er de omkostninger, der giver dem mulighed for at konkurrere effektivt på softwaremarkedet. Eksempler på sådanne virksomheder kan ses .
Hovedkriteriet for at forstå, om DevOps er nødvendig: hvilken værdi dine it-produkter har for virksomheden og kunderne.
Hvis virksomhedens hovedprodukt, der genererer overskud, er software, har du brug for DevOps. Og det er ikke så vigtigt, hvis du tjener rigtige penge ved at bruge andre produkter. Dette omfatter også onlinebutikker eller mobilapplikationer med spil.
Alle spil eksisterer takket være finansiering: direkte eller indirekte fra spillerne. Hos Playgendary udvikler vi gratis mobilspil med over 200 personer direkte involveret i deres skabelse. Hvordan bruger vi DevOps?
Ja, præcis det samme som beskrevet ovenfor. Jeg kommunikerer konstant med udviklere og testere og gennemfører intern træning for medarbejdere i DevOps metodik og værktøjer.
Vi bruger nu aktivt Jenkins som et CI/CD-pipelinesværktøj til at udføre alle montagepipelines med Unity og efterfølgende udrulning til App Store og Play Market. Mere fra det klassiske værktøjssæt:
- Asana - til projektledelse. Integration med Jenkins er blevet konfigureret.
- Google Meet - til videomøder.
- Slack - til kommunikation og forskellige advarsler, herunder meddelelser fra Jenkins.
- Atlassian Confluence - til dokumentation og gruppearbejde.
Vores umiddelbare planer omfatter introduktion af statisk kodeanalyse ved hjælp af SonarQube og udførelse af automatiseret UI-test ved hjælp af selen i den kontinuerlige integrationsfase.
I stedet for en konklusion
Jeg vil gerne slutte af med følgende tanke: for at blive en højt kvalificeret DevOps-ingeniør er det afgørende at lære at kommunikere live med mennesker.
En DevOps-ingeniør er en holdspiller. Og intet andet. Initiativet til at kommunikere med kolleger bør komme fra ham og ikke under indflydelse af nogle omstændigheder. En DevOps-specialist skal se og foreslå den bedste løsning for teamet.
Og ja, implementeringen af enhver løsning vil kræve en masse diskussion, og i sidste ende kan den ændre sig helt. Udvikling uafhængigt, foreslår og implementerer sine ideer, en sådan person er af stigende værdi både for teamet og for arbejdsgiveren. Hvilket i sidste ende afspejles i størrelsen af hans månedlige vederlag eller i form af yderligere bonusser.
Kilde: www.habr.com