DevOps har blitt et veldig populært tema de siste årene. Mange drømmer om å bli med, men som praksis viser, ofte bare på grunn av lønnsnivået.
Noen mennesker viser DevOps på CV-en, selv om de ikke alltid kjenner eller forstår essensen av begrepet. Noen tror at etter å ha studert Ansible, GitLab, Jenkins, Terraform og lignende (listen kan fortsettes etter din smak), vil du umiddelbart bli en "devopsist". Dette er selvfølgelig ikke sant.
De siste årene har jeg hovedsakelig vært involvert i implementering av DevOps i ulike selskaper. Før det jobbet han i mer enn 20 år i stillinger som spenner fra systemadministrator til IT-direktør. For tiden DevOps Lead Engineer hos Playgendary.
Hvem er DevOps
Ideen om å skrive en artikkel oppsto etter et annet spørsmål: "hvem er DevOps?" Det er fortsatt ingen etablert betegnelse for hva eller hvem det er. Noen av svarene ligger allerede i dette . Først vil jeg fremheve hovedpunktene fra den, og deretter dele mine observasjoner og tanker.
DevOps er ikke en spesialist som kan leies, ikke et sett med verktøy, og ikke en avdeling med utviklere med ingeniører.
DevOps er en filosofi og metodikk.
Med andre ord er det et sett med praksis som hjelper utviklere til å aktivt samhandle med systemadministratorer. Det vil si å koble sammen og integrere arbeidsprosesser i hverandre.
Med bruken av DevOps forble strukturen og rollene til spesialister de samme (det er utviklere, det er ingeniører), men reglene for samhandling har endret seg. Grensene mellom avdelingene har visket ut.
Målene til DevOps kan beskrives i tre punkter:
- Programvaren må oppdateres jevnlig.
- Programvare må gjøres raskt.
- Programvaren bør distribueres praktisk og på kort tid.
Det finnes ikke et enkelt verktøy for DevOps. Å konfigurere, levere og studere flere produkter betyr ikke at DevOps har dukket opp i selskapet. Det er mange verktøy og de brukes alle på forskjellige stadier, men tjener ett felles formål.
Og dette er bare en del av DevOps-verktøyene
Jeg har intervjuet folk for stillingen som DevOps-ingeniør i mer enn 2 år nå, og jeg har innsett hvor viktig det er å tydelig forstå essensen av begrepet. Jeg har samlet spesifikke erfaringer, observasjoner og tanker som jeg ønsker å dele.
Fra intervjuerfaring ser jeg følgende bilde: spesialister som anser DevOps som en stillingstittel, har vanligvis misforståelser med kolleger.
Det var et slående eksempel. En ung mann kom til et intervju med mange smarte ord på CV-en. På sine tre siste jobber hadde han 5-6 måneders erfaring. Jeg forlot to startups fordi de "ikke tok av." Men om det tredje selskapet sa han at ingen forstår ham der: Utviklerne skriver kode på Windows, og direktøren tvinger denne koden til å "pakkes inn" i vanlig Docker og bygges inn i CI/CD-rørledningen. Fyren sa mange negative ting om sin nåværende arbeidsplass og kollegene hans - jeg ville bare svare: "Så du vil ikke selge en elefant."
Så stilte jeg ham et spørsmål som står høyt på listen min for hver kandidat.
— Hva betyr DevOps for deg personlig?
– Generelt eller hvordan oppfatter jeg det?
Jeg var interessert i hans personlige mening. Han kjente til teorien og opprinnelsen til begrepet, men han var sterkt uenig i dem. Han mente DevOps var en stillingstittel. Det er her roten til problemene hans ligger. Samt andre spesialister med samme oppfatning.
Arbeidsgivere, som har hørt mye om "magien til DevOps", ønsker å finne en person som vil komme og skape denne "magien". Og søkere fra «DevOps er en jobb»-kategorien forstår ikke at med denne tilnærmingen vil de ikke kunne innfri forventningene. Og generelt skrev de DevOps på CV-en fordi det er en trend og de betaler mye for det.
DevOps metodikk og filosofi
Metodikken kan være teoretisk og praktisk. I vårt tilfelle er det den andre. Som jeg nevnte ovenfor, er DevOps et sett med praksiser og strategier som brukes for å oppnå uttalte mål. Og i hvert tilfelle, avhengig av selskapets forretningsprosesser, kan det variere betydelig. Noe som ikke gjør det bedre eller verre.
DevOps-metodikken er bare et middel for å nå mål.
Nå om hva DevOps-filosofien er. Og dette er nok det vanskeligste spørsmålet.
Det er ganske vanskelig å formulere et kort og konsist svar, fordi det ennå ikke er formalisert. Og siden tilhengere av DevOps-filosofien er mer engasjert i praksis, er det rett og slett ikke tid til å filosofere. Dette er imidlertid en svært viktig prosess. Dessuten er det direkte relatert til ingeniøraktiviteter. Det er til og med et spesialisert kunnskapsområde - .
Det fantes ikke noe slikt emne på universitetet mitt, jeg måtte studere alt på egenhånd ved å bruke materialene jeg fant på 90-tallet. Emnet er valgfritt for ingeniørutdanning, derav mangelen på formalisering av svaret. Men de menneskene som er seriøst fordypet i DevOps begynner å føle en viss "ånd" eller "ubevisst helhet" av alle selskapets prosesser.
Ved å bruke min egen erfaring prøvde jeg å formalisere noen av "postulatene" til denne filosofien. Resultatet er følgende:
- DevOps er ikke noe uavhengig som kan deles inn i et eget område med kunnskap eller aktivitet.
- Alle ansatte i selskapet bør veiledes av DevOps-metodikken når de planlegger sine aktiviteter.
- DevOps påvirker alle prosesser i en bedrift.
- DevOps eksisterer for å redusere tidskostnadene for alle prosesser i et selskap for å sikre utvikling av tjenestene og maksimal kundekomfort.
- DevOps, i moderne språk, er den proaktive posisjonen til hver ansatt i selskapet, rettet mot å redusere tidskostnader og forbedre kvaliteten på IT-produktene rundt oss.
Jeg tror at mine "postulater" er et eget tema for diskusjon. Men nå er det noe å bygge videre på.
Hva DevOps gjør
Nøkkelordet her er kommunikasjon. Det er mye kommunikasjon, og initiativtakeren til dette burde være akkurat den samme DevOps-ingeniøren. Hvorfor det? Fordi dette er filosofi og metodikk, og først da ingeniørkunnskap.
Jeg kan ikke snakke med 100% tillit om det vestlige arbeidsmarkedet. Men jeg vet ganske mye om DevOps-markedet i Russland. I tillegg til hundrevis av intervjuer, har jeg det siste og et halvt året deltatt i hundrevis av tekniske forhåndssalg for «Implementering av DevOps»-tjenesten for store russiske selskaper og banker.
I Russland er DevOps fortsatt et veldig ungt, men allerede populært tema. Så vidt jeg vet, var mangelen på slike spesialister i Moskva alene i 2019 mer enn 1000 mennesker. Og ordet Kubernetes for arbeidsgivere er nesten som en rød fille for en okse. Tilhengere av dette verktøyet er klare til å bruke det selv der det ikke er nødvendig og økonomisk lønnsomt. Arbeidsgiveren forstår ikke alltid i hvilke tilfeller hva som er mer hensiktsmessig å bruke, og med riktig utrulling koster vedlikehold av en Kubernetes-klynge 2-3 ganger mer enn å distribuere en applikasjon ved bruk av en konvensjonell klyngeordning. Bruk den der du virkelig trenger den.
Implementering av DevOps er dyrt i form av penger. Og det er bare rettferdiggjort der det gir økonomiske fordeler på andre områder, og ikke alene.
DevOps-ingeniører er faktisk pionerer – det er de som bør være de første til å implementere denne metodikken i selskapet og bygge prosesser. For at dette skal lykkes, må spesialisten hele tiden samhandle med ansatte og kolleger på alle nivåer. Som jeg pleier å si, bør alle ansatte i selskapet være involvert i DevOps-implementeringsprosessen: fra rengjøringsdame til administrerende direktør. Og dette er en forutsetning. Hvis det mest juniormedlemmet i teamet ikke vet og forstår hva DevOps er og hvorfor visse organisatoriske handlinger utføres, vil vellykket implementering ikke fungere.
En DevOps-ingeniør må også bruke en administrativ ressurs fra tid til annen. For eksempel for å overvinne "miljømotstand" - når teamet ikke er klar til å akseptere DevOps-verktøy og -metodikk.
Utvikleren skal bare skrive kode og tester. For å gjøre dette trenger han ikke en superkraftig bærbar PC som han vil distribuere og lokalt støtte hele prosjektets infrastruktur. For eksempel beholder en front-end-utvikler alle elementene i applikasjonen på den bærbare datamaskinen, inkludert databasen, S3-emulatoren (minio), etc. Det vil si at han bruker mye tid på å vedlikeholde denne lokale infrastrukturen og sliter på egenhånd med alle problemene ved en slik løsning. I stedet for å utvikle kode for fronten. Slike mennesker kan være svært motstandsdyktige mot enhver endring.
Men det er team som tvert imot gjerne introduserer nye verktøy og metoder, og deltar aktivt i denne prosessen. Selv i dette tilfellet ble kommunikasjonen mellom DevOps-ingeniøren og teamet ikke kansellert.
Når DevOps ikke er nødvendig
Det er situasjoner der DevOps ikke er nødvendig. Dette er et faktum - det må forstås og aksepteres.
For det første gjelder dette alle selskaper (spesielt små bedrifter), når deres fortjeneste ikke er direkte avhengig av tilstedeværelse eller fravær av IT-produkter som gir informasjonstjenester til klienter. Og her snakker vi ikke om selskapets nettside, det være seg et statisk "visitkort" eller med dynamiske nyhetsblokker osv.
DevOps er nødvendig når tilfredsheten til kunden din og hans ønske om å returnere til deg igjen avhenger av tilgjengeligheten til disse informasjonstjenestene for interaksjon med kunden, deres kvalitet og målretting.
Et slående eksempel er en velkjent bank. Bedriften har ikke tradisjonelle kundekontorer, dokumentflyt utføres via post eller bud, og mange ansatte jobber hjemmefra. Selskapet har sluttet å være bare en bank og har etter min mening blitt et IT-selskap med utviklede DevOps-teknologier.
Mange andre eksempler og foredrag finnes i opptakene av tematiske møter og konferanser. Jeg besøkte noen av dem personlig - dette er en veldig nyttig erfaring for de som ønsker å utvikle seg i denne retningen. Her er lenker til YouTube-kanaler med gode forelesninger og materiell på DevOps:
Se nå på virksomheten din og tenk på dette: Hvor mye avhenger din bedrift og dens fortjeneste av IT-produkter for å muliggjøre kundeinteraksjon?
Hvis bedriften din selger fisk i en liten butikk og det eneste IT-produktet er to 1C: Enterprise-konfigurasjoner (Accounting og UNF), så gir det neppe mening å snakke om DevOps.
Hvis du jobber i en stor handels- og produksjonsbedrift (du produserer for eksempel jaktrifler), bør du tenke på det. Du kan ta initiativet og formidle til din ledelse mulighetene for implementering av DevOps. Vel, og samtidig lede denne prosessen. En proaktiv stilling er en av de viktige prinsippene i DevOps-filosofien.
Størrelsen og volumet på årlig finansomsetning er ikke hovedkriteriet for å avgjøre om din bedrift trenger DevOps.
La oss forestille oss en stor industribedrift som ikke samhandler direkte med kunder. For eksempel noen bilprodusenter og bilprodusenter. Jeg er ikke sikker nå, men fra min tidligere erfaring ble all kundeinteraksjon i mange år gjort via e-post og telefon.
Kundene deres er en begrenset liste over bilforhandlere. Og hver og en er tildelt en spesialist fra produsenten. All intern dokumentflyt skjer gjennom SAP ERP. Interne ansatte er i hovedsak kunder av informasjonssystemet. Men denne IS kontrolleres av klassiske metoder for å administrere klyngesystemer. Noe som utelukker muligheten for å bruke DevOps-praksis.
Derav konklusjonen: for slike virksomheter er ikke implementeringen av DevOps noe kritisk viktig, hvis vi husker målene med metodikken fra begynnelsen av artikkelen. Men jeg utelukker ikke at de bruker noen DevOps-verktøy i dag.
På den annen side er det mange små selskaper som utvikler programvare ved hjelp av DevOps metodikk, filosofi, praksis og verktøy. Og de mener at kostnadene ved å implementere DevOps er kostnadene som gjør at de kan konkurrere effektivt på programvaremarkedet. Eksempler på slike selskaper kan sees .
Hovedkriteriet for å forstå om DevOps er nødvendig: hvilken verdi dine IT-produkter har for bedriften og kundene.
Hvis selskapets hovedprodukt som genererer overskudd er programvare, trenger du DevOps. Og det er ikke så viktig om du tjener ekte penger ved å bruke andre produkter. Dette inkluderer også nettbutikker eller mobilapplikasjoner med spill.
Alle spill eksisterer takket være finansiering: direkte eller indirekte fra spillerne. Hos Playgendary utvikler vi gratis mobilspill med over 200 personer direkte involvert i skapelsen deres. Hvordan bruker vi DevOps?
Ja, akkurat det samme som beskrevet ovenfor. Jeg kommuniserer hele tiden med utviklere og testere, og gjennomfører intern opplæring for ansatte om DevOps metodikk og verktøy.
Vi bruker nå aktivt Jenkins som et CI/CD-rørledningsverktøy for å utføre alle monteringsrørledninger med Unity og påfølgende distribusjon til App Store og Play Market. Mer fra det klassiske verktøysettet:
- Asana - for prosjektledelse. Integrasjon med Jenkins er konfigurert.
- Google Meet – for videomøter.
- Slack - for kommunikasjon og ulike varsler, inkludert varsler fra Jenkins.
- Atlassian Confluence - for dokumentasjon og gruppearbeid.
Våre umiddelbare planer inkluderer introduksjon av statisk kodeanalyse ved bruk av SonarQube og gjennomføring av automatisert brukergrensesnitttesting ved bruk av selen på stadiet med kontinuerlig integrasjon.
I stedet for en konklusjon
Jeg vil avslutte med følgende tanke: for å bli en høyt kvalifisert DevOps-ingeniør er det viktig å lære hvordan man kommuniserer live med mennesker.
En DevOps-ingeniør er en lagspiller. Og ingenting annet. Initiativet til å kommunisere med kolleger bør komme fra ham, og ikke under påvirkning av noen omstendigheter. En DevOps-spesialist må se og foreslå den beste løsningen for teamet.
Og ja, implementeringen av en hvilken som helst løsning vil kreve mye diskusjon, og til slutt kan det endre seg totalt. En slik person utvikler seg selvstendig, foreslår og implementerer ideene sine, og er av økende verdi både for teamet og for arbeidsgiveren. Noe som til syvende og sist gjenspeiles i beløpet på hans månedlige godtgjørelse eller i form av tilleggsbonuser.
Kilde: www.habr.com