Kven er DevOps og når er det ikkje naudsynt

DevOps-tema har blitt svært populær de siste årene. Mange drømmer om å bli en del av den, men som praksisen viser, er det ofte bare på grunn av lønnsnivåene.

Noen oppgir DevOps i CV-en sin, selv om de ikke alltid vet og forstår essensen av termen. Noen mener at ved å lære Ansible, GitLab, Jenkins, Terraform og lignende (listen kan fortsette etter ens egen smak), vil de umiddelbart bli en «devops». Dette er selvfølgelig ikke riktig.

De siste årene har jeg stort sett jobbet med å implementere DevOps i ulike selskaper. Før dette jobbet jeg over 20 år i stillinger fra systemadministrator til IT-direktør. Nå er jeg DevOps Lead Engineer i Playgendary.

Hvem er DevOps

Ideen om å skrive en artikkel oppstod etter et nytt spørsmål: «hvem er DevOps?». Det finnes fortsatt ingen etablert definisjon av hva eller hvem dette er. Noe av svaret finnes allerede i denne video. Først vil jeg trekke frem de viktigste punktene fra den, og deretter dele mine observasjoner og tanker.

DevOps er ikke en spesialist som du kan ansette, ikke et verktøysett, og ikke en avdeling med utviklere og ingeniører.

DevOps er en filosofi og metodikk.

Med andre ord, det er et sett med praksiser som hjelper til med å aktivt samhandle mellom utviklere og systemadministratorer. Det vil si å knytte og integrere arbeidsprosessene med hverandre.

Med fremveksten av DevOps har strukturen og rollene til spesialister forblitt de samme (det er utviklere, det er ingeniører), men reglene for samhandling har endret seg. Grensene mellom avdelingene har blitt uklare.

Målene for DevOps kan beskrives i tre punkter:

• Programvaren må oppdateres regelmessig.
• Programvaren må utvikles raskt.
• Programvaren må distribueres enkelt og på kort tid.

DevOps har ikke ett enkelt verktøy. Å konfigurere, installere og lære seg flere produkter betyr ikke at selskapet har fått DevOps. Det finnes mange verktøy som brukes på ulike stadier, men de tjener ett felles mål.

Og dette er bare en del av DevOps-verktøyene

I over to år har jeg intervjuet folk til stillingen som DevOps-ingeniør, og jeg har innsett hvor viktig det er å forstå essensen av termen klart. Jeg har opparbeidet meg spesifikk erfaring, observasjoner og tanker som jeg ønsker å dele.

Fra min erfaring med intervjuer ser jeg et slikt bilde: spesialister som anser DevOps som en stilling, har vanligvis misforståelser med kollegene..

Det var et klart eksempel. En ung mann kom til intervjuet med en haug av smarte ord i CV-en. På de tre siste arbeidsplassene hadde han erfaring på 5-6 måneder. Han forlot to oppstartsselskaper fordi de «ikke lyktes». Når det gjaldt det tredje selskapet, sa han at ingen forstod ham: utviklerne skriver kode for Windows, mens direktøren tvinger ham til å «pakkere» denne koden i vanlig Docker og integrere den i CI/CD-pipelinen. Gutten delte mye negativt om sin nåværende arbeidsplass og kollegene sine — man skulle nesten ønske å svare: «Så du kan ikke selge elefanten».

Deretter stilte jeg ham et spørsmål, som er en av de første i min liste for hver kandidat.

— Hva betyr DevOps for deg personlig?
— Generelt eller hvordan oppfatter jeg det?

Jeg var interessert i hans personlige mening. Han visste teorien og opprinnelsen til begrepet, men var kategorisk uenig med dem. Han mente at DevOps er en stilling. Her ligger roten til problemene hans. Som hos andre spesialister med samme mening.

Arbeidsgivere, etter å ha hørt om «magien til DevOps», ønsker å finne en person som kan komme og skape denne «magien». Og søkere med holdningen «DevOps er en stilling» forstår ikke at med en slik tilnærming vil de ikke kunne innfri forventningene. Generelt sett skrev de DevOps i sin CV fordi det er en trend og fordi man får godt betalt for det.

Metodologi og filosofi for DevOps

Metodologien kan være teoretisk eller praktisk. I vårt tilfelle er det det andre. Som jeg nevnte tidligere, er DevOps en samling av praksiser og strategier brukt for å oppnå de angitte målene. Og i hvert tilfelle, avhengig av forretningsprosessene i selskapet, kan den variere betydelig. Dette gjør den ikke bedre eller dårligere.

DevOps-metodologi er bare et verktøy for å oppnå de satte målene.

Nå om hva DevOps-filosofien er. Og dette er kanskje det vanskeligste spørsmålet.

Å formulere et kort og presist svar er ganske vanskelig, fordi det ikke er blitt formalisert ennå. Og siden tilhengerne av DevOps-filosofien ofte er opptatt med praktisk arbeid — er det rett og slett ikke tid for filosofiske diskusjoner. Likevel er dette en veldig viktig prosess. Dessuten er det direkte relatert til ingeniørvirksomhet. Det finnes til og med et spesialisert kunnskapsfelt — filosofi for teknologi.

I did not have such a subject in my university, so I had to study everything independently based on the materials I could find in the 90s. The topic is not mandatory for engineering education, hence the lack of a formalized answer. However, those who have seriously immersed themselves in DevOps begin to sense a certain 'spirit' or 'unconscious comprehensiveness' of all company processes.

From my experience, I have tried to formalize some 'postulates' of this philosophy. The result is as follows:

• DevOps is not something independent that can be singled out as a separate field of knowledge or activity.
• All company employees should be guided by DevOps methodology when planning their activities.
• DevOps touches upon all processes within the company.
• DevOps exists to reduce time costs on any processes within the company to ensure the development of its services and maximum client comfort.
• DevOps, in modern terms, is a proactive stance of each company employee aimed at reducing time expenses and improving the quality of the IT products around us.

I believe that my 'postulates' are a separate topic for discussion. But now there is something to build upon.

What DevOps Does

The key word here is communication. There is a lot of communication, initiated by the very DevOps engineer. Why is that? Because it is a philosophy and methodology, and only then does it involve engineering knowledge.

I can't speak about the Western labor market with 100% certainty. But I know quite a bit about the DevOps market in Russia. In addition to hundreds of interviews, over the past year and a half, I have participated in a hundred technical presales for the 'DevOps Implementation' service for large Russian companies and banks.

I Russland er DevOps fortsatt et meget ungt, men allerede trendy tema. Så langt jeg vet, var det mer enn 1000 spesialister i slik mangel bare i Moskva i 2019. Ordet Kubernetes er for arbeidsgivere nesten som et rødt klut for en okse. Tilhengerne av dette verktøyet er klare til å bruke det selv der det ikke er nødvendig og ikke økonomisk gunstig. Arbeidsgivere forstår ikke alltid i hvilke tilfeller det er mer hensiktsmessig å bruke hva, og med riktig distribusjon kan innholdet i Kubernetes-klyngen koste 2-3 ganger mer enn distribusjonen av en applikasjon etter et vanlig klyngeskjema. Bruk det der det faktisk er nødvendig.

Implementering av DevOps, sett fra et økonomisk perspektiv, er dyrt. Det er bare berettiget der det gir økonomisk gevinst i andre områder, ikke bare i seg selv.

DevOps-ingeniører er faktisk pionerer - det er de som først må implementere denne metodikken i selskapet og bygge prosessene. For at dette skal være vellykket, må spesialisten hele tiden samhandle med ansatte og kolleger på alle nivåer. Som jeg pleier å si, må alle ansatte i selskapet involveres i prosessen med å implementere DevOps: fra rengjøringspersonen til CEO. Og dette er en nødvendig betingelse. Hvis det yngste medlemmet av teamet ikke vet og forstår hva DevOps er og hvorfor ulike organisatoriske handlinger utføres, vil det ikke bli noen vellykket implementering.

I tillegg må DevOps-ingeniøren av og til bruke administrativt ressurser. For eksempel for å overvinne "motstand fra miljøet" - når teamet ikke er klart til å ta imot verktøyene og metodikken til DevOps.

Utvikleren skal bare skrive kode og tester. For dette trenger han ikke en superkraftig bærbar datamaskin hvor han skal distribuere og støtte hele prosjektets infrastruktur lokalt. For eksempel har frontend-utvikleren alle appens elementer på sin bærbare datamaskin, inkludert databasen, S3-emulator (minio) og mer. Med andre ord bruker han mye tid på å opprettholde denne lokale infrastrukturen og kjemper alene med alle problemene som følger med denne løsningen, i stedet for å utvikle kode for fronten. Slike personer kan være sterkt motvillige til enhver endring.

Men er det lag som omvendt er glade for å implementere nye verktøy og metoder, og som aktivt deltar i denne prosessen. Selv i slike tilfeller er kommunikasjonen mellom DevOps-ingeniøren og gruppen fortsatt viktig.

Når DevOps ikke er nødvendig

Det finnes situasjoner der DevOps ikke er nødvendig. Dette er et faktum som må forstås og aksepteres.

Først og fremst gjelder dette enhver bedrift (spesielt småbedrifter) der inntjeningen ikke er direkte avhengig av tilstedeværelse eller fravær av IT-produkter som tilbyr informasjonstjenester til kundene. Dette handler ikke om selskapets nettsted, enten det er en statisk «visittkort» eller har dynamiske nyhetsblokker osv.

DevOps er nødvendig når tilfredsheten til kunden din og hans vilje til å komme tilbake til deg igjen er avhengig av kvaliteten, relevante tjenester og måten informasjonstjenester interagerer med kunden.

Et tydelig eksempel er en kjent bank. Selskapet har ingen tradisjonelle kundekontorer, dokumentbehandlingen skjer via post eller budfirma, 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.

Det finnes mange andre eksempler og forelesninger tilgjengelig fra tematiske meetups og konferanser. Flere av dem besøkte jeg personlig — det er en veldig nyttig erfaring for de som ønsker å utvikle seg innen dette feltet. Her er linker til YouTube-kanaler med gode forelesninger og materiale om DevOps:

• DevOops
• DevOpsConf
• HighLoad++
• Flant
• MailRu Cloud Solution

Se nå på bedriften din og tenk på dette: hvor mye er selskapet ditt og inntjeningen avhengig av IT-produkter som muliggjør interaksjon med kunden?

Hvis selskapet ditt selger fisk i en liten butikk og det eneste IT-produktet er to konfigurasjoner av 1С: Enterprise (Regnskap og UNF), er det neppe noe poeng i å snakke om DevOps.

Men hvis du jobber i en stor handels- og produksjonsbedrift (for eksempel produserer jaktgevær), så bør du vurdere det. Du kan ta initiativet og formidle til ledelsen mulighetene for implementering av DevOps. Og samtidig lede denne prosessen. En proaktiv holdning er en av de viktigste postulater i DevOps-filosofien.

Størrelse og volumen av årlig finansiell omsetning er ikke det viktigste kriteriet for å avgjøre om virksomheten din trenger DevOps.

La oss forestille oss en stor industriell bedrift som ikke interagerer direkte med kundene. For eksempel, noen bilprodusenter og bilfabrikker. Nå er jeg ikke sikker, men fra min tidligere erfaring har alt interaksjon med kunder blitt utført via e-post og telefon i mange år.

Kundene deres er en begrenset liste av bilforhandlere. Og hver av dem har en spesialist fra produsenten tilknyttet. All intern dokumentflyt skjer gjennom ERP SAP. Interne ansatte er i prinsippet kunder av informasjonssystemet. Men styringen av dette systemet skjer med klassiske metoder for styring av klyngesystemer. Dette utelukker muligheten for å bruke DevOps-praksiser.

Derfor konkluderer vi med at for slike virksomheter er implementering av DevOps ikke kritisk viktig, hvis vi husker målene til metodologien fra begynnelsen av artikkelen. Men jeg utelukker ikke at noen DevOps-verktøy blir brukt av dem i dag.

På den annen side finnes det mange små selskaper som utvikler programvare ved å bruke metodologi, filosofi, praksiser og verktøy fra DevOps. De mener at kostnadene ved å implementere DevOps er utgifter som gjør dem i stand til å konkurrere effektivt på programvaremarkedet. Eksempler på slike selskaper kan sees. her.

Hovedkriteriet for å forstå om man trenger DevOps: hvilken betydning har IT-produktene deres for selskapet og kundene.

Hvis det primære produktet til selskapet, som genererer inntekt, er programvare — trenger du DevOps. Og det er ikke så viktig om du tjener ekte penger gjennom andre varer. Dette inkluderer også nettbutikker eller mobile applikasjoner med spill.

Alle spill eksisterer gjennom finansiering: direkte eller indirekte fra spillerne. I Playgendary utvikler vi gratis mobilspill, som involverer mer enn 200 personer i den direkte utviklingen. Hvordan bruker vi DevOps?

Akkurat på samme måte som beskrevet ovenfor. Jeg kommuniserer hele tiden med utviklere og testere, og holder interne opplæringer for ansatte om metodologi og verktøy fra DevOps.

Nå har vi aktivt tatt i bruk Jenkins som verktøy for CI/CD-pipelines for å utføre alle byggingskonveyor med Unity og påfølgende distribusjon til App Store og Play Market. I tillegg til det klassiske settet av verktøy:

• Asana – for prosjektledelse. Integrasjonen med Jenkins er konfigurert.
• Google Meet – for videomøter.
• Slack – for kommunikasjon og ulike varsler, inkludert notifikasjoner fra Jenkins.
• Atlassian Confluence – for dokumentasjon og gruppearbeid.

I nærmeste framtid planlegger vi å implementere statisk kodeanalyse med SonarQube og gjennomføre automatisert UI-testing ved hjelp av Selenium i løpet av Continuous Integration.

In conclusion

Jeg vil avslutte med denne tanken: for å bli en høyt kvalifisert DevOps-ingeniør, er det livsviktig å lære seg å kommunisere med mennesker.

DevOps-ingeniøren er en lagspiller. Og på ingen annen måte. Initiativet i kommunikasjonen med kolleger må komme fra ham selv, og ikke være påtvunget av omstendigheter. En DevOps-spesialist må være i stand til å se og foreslå den beste løsningen for teamet.

Og ja, implementering av enhver løsning vil kreve mange diskusjoner, og til slutt kan det endre seg helt. Gjennom å utvikle seg selv, tilby og gjennomføre sine ideer – slik en person blir stadig mer verdifull både for teamet og for arbeidsgiveren. Dette reflekteres til slutt også i størrelsen på hans månedlige belønning eller i form av ekstra bonuser.

Kilde: habr.com