DevOps-temaen er blevet meget populær i de seneste år. Mange drømmer om at komme ind i den, men som erfaringen viser, er det ofte kun på grund af lønniveauet.
Nogle angiver DevOps i deres CV, selvom de ikke altid forstår essensen af termen. Nogen mener, at hvis man lærer Ansible, GitLab, Jenkins, Terraform og lignende (listen kan fortsætte efter ens smag), så bliver man straks en 'DevOps'. Det er selvfølgelig ikke tilfældet.
I de seneste par år har jeg primært arbejdet med implementering af DevOps i forskellige virksomheder. Forud for dette har jeg arbejdet i over 20 år i positioner fra systemadministrator til IT-direktør. Nu er jeg DevOps Lead Engineer hos Playgendary.
Hvem er en DevOps?
Ideen om at skrive en artikel opstod efter endnu et spørgsmål: 'Hvem er DevOps?'. Der er stadig ikke et fast begreb for hvad eller hvem det er. Nogle svar kan allerede findes i denne . Først vil jeg fremhæve de vigtigste punkter fra det, og derefter dele mine observationer og tanker.
DevOps er ikke en specialist, man kan ansætte, ikke et værktøjssæt og ikke en afdeling af udviklere med ingeniører.
DevOps er en filosofi og en metode.
Med andre ord er det et sæt praksisser, der hjælper udviklere med at samarbejde aktivt med systemadministratorer. Det vil sige, at det forbinder og integrerer arbejdsgange med hinanden.
Med indførelsen af DevOps forblev strukturen og rollerne for specialister de samme (der er udviklere, der er ingeniører), men reglerne for interaktion ændrede sig. Grænserne mellem afdelingerne blev udvisket.
Målene med DevOps kan beskrives i tre punkter:
- Softwaren skal opdateres regelmæssigt.
- Softwaren skal udvikles hurtigt.
- Softwaren skal implementeres nemt og inden for kort tid.
Der er ikke et enkelt værktøj til DevOps. At configure, installere og studere flere produkter betyder ikke, at der er kommet DevOps til virksomheden. Der er mange værktøjer, og de bruges i forskellige faser, men tjener ét fælles mål.
Og det er kun en del af DevOps-værktøjerne.
I mere end 2 år har jeg interviewet folk til stillingen som DevOps-ingeniør, og jeg har indset, hvor vigtigt det er at forstå essensen af termen klart. Der er samlet specifik erfaring, observationer og tanker, som jeg ønsker at dele.
Fra mine interviewerfaringer ser jeg et sådant billede: specialister, der betragter DevOps som en stilling, har ofte misforståelser med deres kolleger..
Der var et klart eksempel. En ung mand kom til samtalen med en masse smarte ord i sit CV. I de sidste tre jobs havde han en ansættelsestid på 5-6 måneder. Han forlod to startups, fordi de "ikke lykkedes". Og i forhold til det tredje firma sagde han, at ingen forstod ham: udviklerne skrev kode til Windows, og direktøren tvang ham til at "pakke" denne kode ind i almindelig Docker og integrere den i CI/CD-pipelinen. Drengen fortalte en del negativt om sit nuværende job og sine kolleger - man havde lyst til at svare: "Så kan du ikke sælge elefanten."
Derefter stillede jeg ham et spørgsmål, som er et af de første på min liste for hver kandidat.
— Hvad betyder DevOps personligt for dig?
— Generelt eller som jeg opfatter det?
Jeg var interesseret i hans personlige mening. Han kendte teorien og oprindelsen af termen, men var kategorisk uenig. Han mente, at DevOps er en stilling. Heri ligger kernen af hans problemer. Ligesom for andre specialister med samme opfattelse.
Arbejdsgivere, der har hørt om "magien ved DevOps", ønsker at finde en person, der kommer og skaber denne "magi". Og ansøgere i kategorien "DevOps er en stilling" forstår ikke, at de med denne tilgang ikke vil kunne leve op til forventningerne. Og generelt skrev de "DevOps" i deres CV, fordi det er en trend, og man får meget for det.
Metodologi og filosofi i DevOps
Metodologien kan være teoretisk og praktisk. I vores tilfælde er det det sidste. Som jeg nævnte tidligere, er DevOps et sæt af praktikker og strategier anvendt til at opnå de angivne mål. Og i hvert tilfælde, afhængig af virksomhedens forretningsprocesser, kan det variere betydeligt. Hvilket ikke gør det bedre eller dårligere.
DevOps-metodologi er blot et middel til at nå de fastsatte mål.
Nu til, hvad filosofien bag DevOps er. Og det er måske det sværeste spørgsmål.
At formulere et kort og præcist svar er ret svært, fordi det endnu ikke er formaliseret. Og eftersom tilhængerne af DevOps-filosofien arbejder mere med praksis - er der simpelthen ikke tid til filosofi. Alligevel er det en meget vigtig proces. Og den relaterer sig direkte til ingeniørarbejde. Der er endda et specialiseret område inden for viden - .
På mit universitet fandtes der ikke et sådant fag, så jeg var nødt til at studere det hele selvstændigt ud fra de materialer, jeg kunne finde i 90'erne. Emnet er ikke obligatorisk for ingeniøruddannelsen, hvilket forklarer manglen på en formel svar. Men de personer, der seriøst har dykket ned i DevOps, begynder at mærke en slags "ånd" eller "ubevidst altomfavnende" karakter ved alle virksomhedens processer.
På baggrund af mine erfaringer har jeg forsøgt at formulere nogle "postulater" for denne filosofi. Her er resultatet:
- DevOps er ikke noget selvstændigt, der kan fremhæves som en separat videns- eller aktivitetsretning.
- Alle virksomhedens medarbejdere skal følge DevOps-metodologien, når de planlægger deres aktiviteter.
- DevOps berører alle processer i virksomheden.
- DevOps eksisterer for at reducere tidsforbruget på enhver proces i virksomheden for at sikre udviklingen af dens tjenester og maksimere kundens komfort.
- DevOps, på moderne sprog, er en proaktiv tilgang fra hver medarbejder i virksomheden, rettet mod at reducere tidsomkostningerne og forbedre kvaliteten af de IT-produkter, der omgiver os.
Jeg mener, at mine "postulater" er et separat emne til diskussion. Men nu er der noget at bygge videre på.
Hvad gør DevOps?
Det nøgleord her er kommunikation. Der er mange kommunikationer, hvor initiativtageren netop bør være den samme DevOps-ingeniør. Hvorfor? Fordi det er en filosofi og en metodologi, og først derefter ingeniørviden.
Jeg kan ikke tale med 100% sikkerhed om arbejdsmarkedet i Vesten. Men jeg ved en hel del om DevOps-markedet i Rusland. Ud over hundrede jobsamtaler har jeg i løbet af de sidste halvandet år deltaget i et hundrede tekniske presales for tjenesten "Implementering af DevOps" for store russiske virksomheder og banker.
I Danmark er DevOps stadig et ungt, men allerede trendy emne. Så vidt jeg ved, var der kun i København et mangel på sådanne specialister i 2019 på over 1000 personer. Og ordet Kubernetes er for arbejdsgiverne næsten som en rød klud for en tyr. Tilhængere af dette værktøj er klar til at bruge det, selv når det ikke er nødvendigt og økonomisk ikke rentabelt. Arbejdsgiveren forstår ikke altid, hvornår det er mest passende at bruge det, og ved korrekt implementering koster indholdet af Kubernetes-klyngen 2-3 gange mere end installationen af applikationen efter en almindelig klyngeordning. Brug det, hvor det virkelig er nødvendigt.
Implementeringen af DevOps set fra et økonomisk perspektiv er dyr. Og det er kun berettiget, hvor det giver økonomisk gevinst i andre områder, ikke for sin egen skyld.
DevOps-ingeniører er faktisk pionerer — det er dem, der først skal implementere denne metodologi i virksomheden og opbygge processerne. For at dette skal lykkes, skal specialisten konstant interagere med medarbejdere og kolleger på alle niveauer. Som jeg plejer at sige, skal alle medarbejdere i virksomheden involveres i DevOps-implementeringen: fra rengøringsassistenter til CEO. Dette er en forudsætning. Hvis det yngste medlem af teamet ikke ved og forstår, hvad DevOps er, og hvorfor visse organisatoriske handlinger udføres, så vil der ikke være nogen succesfuld implementering.
Desuden skal DevOps-ingeniøren fra tid til anden bruge administrativt ressourcer. For eksempel for at overvinde "modstanden fra miljøet" — når teamet ikke er parat til at acceptere værktøjerne og metodologien i DevOps.
Udvikleren skal kun skrive kode og tests. Til dette har han ikke brug for en superkraftig bærbar computer, som han vil bruge til at installere og vedligeholde hele projektets infrastruktur lokalt. For eksempel har front-end udvikleren alle applikationens elementer på sin bærbare computer, inklusiv databasen, emulatoren S3 (minio) og så videre. Det vil sige, at han bruger meget tid på at vedligeholde denne lokale infrastruktur og kæmper alene med alle problemerne ved en sådan løsning. I stedet for at udvikle kode til front-end. Sådanne personer kan være meget modstandsdygtige over for enhver ændring.
Men der er teams, som derimod er glade for at implementere nye værktøjer og metoder og aktivt deltager i denne proces. Selvom selv i sådanne tilfælde er kommunikationen mellem DevOps-ingeniøren og teamet stadig vigtig.
Når DevOps ikke er nødvendigt
Der findes situationer, hvor DevOps ikke er nødvendigt. Det er en kendsgerning — det skal man forstå og acceptere.
Først og fremmest gælder dette for alle virksomheder (især små erhverv), når deres indtægt ikke direkte afhænger af tilstedeværelsen eller fraværet af IT-produkter, der leverer informationsservices til kunderne. Og her handler det ikke om virksomhedens hjemmeside, uanset om den er en statisk "visitkort" eller med dynamiske nyhedssektioner osv.
DevOps er nødvendigt, når tilstedeværelsen af disse informationsservices til kundeinteraktion, deres kvalitet og målretning påvirker tilfredsheden hos dine kunder og deres vilje til at vende tilbage til netop dig.
Et tydeligt eksempel er en kendt bank. Virksomheden har ikke traditionelle kundekontorer, dokumentbehandling foregår gennem post eller bud, og mange medarbejdere arbejder hjemmefra. Virksomheden er ikke længere bare en bank, men er efter min mening blevet en IT-virksomhed med avancerede DevOps-teknologier.
Mange andre eksempler og oplæg kan findes i optagelserne fra tematiserede meetups og konferencer. Nogle af dem har jeg deltaget i personligt — det er en meget nyttig erfaring for dem, der ønsker at udvikle sig inden for dette område. Her er links til YouTube-kanaler med gode oplæg og materialer om DevOps:
Se nu på din virksomhed og tænk over dette: hvor meget afhænger din virksomhed og dens profit af IT-produkter, der muliggør interaktion med kunderne?
Hvis din virksomhed sælger fisk i en lille butik, og de eneste IT-produkter er to konfigurationer af 1C: Enterprise (Regnskab og UNF), så er det næppe meningsfuldt at tale om DevOps.
Men hvis du arbejder i en stor handels- og produktionsvirksomhed (for eksempel producerer jagtgeværer), så er det værd at overveje. Du kan tage initiativet og informere din ledelse om fordelene ved at implementere DevOps. Og samtidig, lede denne proces. En proaktiv tilgang er en af de vigtige postulater i DevOps-filosofien.
Størrelse og volumen af den årlige finansielle omsætning er ikke det primære kriterium 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 bilfabrikanter. Jeg er ikke sikker nu, men fra min tidligere erfaring blev al interaktion med kunderne i mange år håndteret via e-mail og telefon.
Deres kunder er en begrænset liste af bilforhandlere. Og der er knyttet en specialist fra producenten til hver enkelt. Hele den interne dokumentation foregår gennem ERP SAP. Interne medarbejdere er i bund og grund kunder af informationssystemet. Men styringen af dette IS udføres med klassiske metoder til styring af klynge systemer. Hvilket udelukker muligheden for at anvende DevOps-praksis.
Konklusionen her er, at for sådanne virksomheder er implementeringen af DevOps ikke kritisk vigtig, hvis vi husker målene for metodologien fra begyndelsen af artiklen. Men jeg udelukker ikke, at nogle DevOps-værktøjer anvendes af dem i dag.
På den anden side er der mange små virksomheder, der udvikler software ved hjælp af metodologi, filosofi, praksis og værktøjer fra DevOps. Og de mener, at omkostningerne ved implementering af DevOps er omkostninger, der giver dem mulighed for at konkurrere effektivt på softwaremarkedet. Eksempler på sådanne virksomheder kan ses .
Det primære kriterium for at forstå, om DevOps er nødvendigt, er: hvilken betydning har dine IT-produkter for virksomheden og kunderne.
Hvis virksomhedens hovedprodukt, der genererer indtægter, er software - så har du brug for DevOps. Og det er ikke så vigtigt, om du tjener penge på andre varer. Dette inkluderer også online butikker eller mobilapplikationer med spil.
Enhver spil eksisterer takket være finansiering: direkte eller indirekte fra spillerne. Hos Playgendary udvikler vi gratis mobile spil, som involverer mere end 200 personer i den direkte skabelse. Hvordan bruger vi DevOps?
På præcis samme måde som beskrevet ovenfor. Jeg kommunikerer konstant med udviklere og testere, og jeg gennemfører intern træning af medarbejdere i metodologi og værktøjer til DevOps.
I øjeblikket bruger vi aktivt Jenkins som værktøj til CI/CD pipelines til at udføre alle byggeprocesser med Unity og efterfølgende deployment til App Store og Play Market. Derudover anvender vi et klassisk sæt værktøjer:
- Asana — til projektledelse. Integration med Jenkins er opsat.
- Google Meet — til videomøder.
- Slack — til kommunikation og forskellige notifikationer, inklusive notifikationer fra Jenkins.
- Atlassian Confluence — til dokumentation og gruppesamarbejde.
Vi planlægger snart at implementere statisk kodeanalyse ved hjælp af SonarQube og udføre automatiserede UI-tests med Selenium i forbindelse med Continuous Integration.
Afslutning
Jeg vil afslutte med denne tanke: for at blive en højt kvalificeret DevOps-ingeniør er det bydende nødvendigt at lære at kommunikere effektivt med folk.
DevOps-ingeniøren er en holdspiller. Intet mindre. Initiativet til at kommunikere med kolleger skal komme fra ham selv og ikke som følge af omstændigheder. DevOps-specialisten skal se og foreslå den bedste løsning for teamet.
Og ja, implementeringen af enhver løsning vil kræve mange diskussioner, og i slutningen kan det endda ændre sig helt. Ved at udvikle sig selv, foreslå og gennemføre sine ideer — repræsenterer en sådan person en stadig større værdi for både teamet og arbejdsgiveren. Dette afspejles i sidste ende også i størrelsen af hans månedlige belønning eller som ekstra bonusser.
Kilde: habr.com
