Hvor skal man gå hen med denne viden, hvad man skal gøre i projektet og hvor meget man skal tjene, hvad man skal sige og spørge til et interview - siger Alexander Titov, managing partner for Express 42 og forfatter .
Hej! Selvom udtrykket DevOps har eksisteret siden 2009, er der stadig ingen konsensus i det russiske samfund. Du har sikkert lagt mærke til, at nogle betragter DevOps som en specialitet, andre betragter det som en filosofi, og andre betragter udtrykket som et sæt teknologier. Jeg har allerede optrådt mange gange med om udviklingen af denne retning, så jeg vil ikke gå i detaljer i denne artikel. Lad mig bare sige, at på Express 42 inkluderer vi følgende:
DevOps er en specifik metode, en kultur for at skabe et digitalt produkt, hvor alle specialister i teamet deltager i produktionen.
I klassisk virksomhedsudvikling foregår alt sekventielt: programmering, test og først derefter drift, og hastigheden på denne proces fra idé til produktion er 3 måneder. Dette er et globalt problem for digitale produkter, fordi det er umuligt hurtigt at modtage feedback fra kunder.
I DevOps er værktøjer og tilgange designet til at sikre, at udviklings-, test- og driftsprocesser kører samtidigt.
Hvad følger af denne tilgang?
- Man kan ikke hyre en eller anden "ingeniør", som kommer og løser alle problemerne med produktionen. Hele holdet skal anvende teknikken.
- DevOps er IKKE den næste form for sysadmin at opgradere til. "DevOps-ingeniør" lyder omtrent det samme som "Agil udvikler."
- Hvis et team bruger Kubernetes, Ansible, Prometheus, Mesosphere og Docker, betyder det ikke, at DevOps-praksis er blevet implementeret der.
Livet efter DevOps bliver aldrig det samme
DevOps-tilgangen er først og fremmest en anderledes måde at tænke på, en opfattelse af udviklingen som helhed og ens plads i processen. Vi opdelte vores online kursus i 2 blokke:
1. Selvbestemmelse
Først undersøger vi i detaljer essensen af DevOps-tilgangen, og eleverne opdager nye roller i teamet, ser hvilken der reagerer mere og bestemmer selv, hvilken retning de skal udvikle.
2. Værktøjer og praksis
Studerende mestrer specifikke teknologier ud fra DevOps-metoden.
DevOps-værktøjer kan bruges både i DevOps-tilgangen og i klassisk udvikling. Det mest oplagte eksempel ville være at bruge Ansible-konfigurationsstyringsværktøjet. Det blev skabt og udtænkt til at implementere DevOps-praksisen "Infrastructure as Code", hvilket betyder, at forskellige tilstande af systemet er beskrevet, fra operativsystemindstillinger til applikationssoftware. Beskrivelsen er opdelt i lag og giver dig mulighed for at administrere en kompleks, konstant skiftende konfiguration. Men ingeniører bruger ofte Ansible som en måde at køre bash-scripts på flere maskiner. Dette er hverken dårligt eller godt, men du skal forstå, at tilstedeværelsen af Ansible ikke garanterer tilstedeværelsen af DevOps i virksomheden.
Vi er i gang Du vil blive fordybet i processen med at udvikle en applikation, der ligner den berømte Reddit, begyndende med dens monolitiske version, der trin for trin flytter til mikrotjenester. Trin for trin vil vi mestre nye værktøjer: Git, Ansible, Gitlab og afslutte med Kubernetes og Prometheus.
Med hensyn til praksis, vil vi følge taktikken på de tre veje, der er beskrevet i DevOps-håndbogen - kontinuerlig leveringspraksis, feedback-praksis, og essensen af hele kurset er praksis med kontinuerlig læring sammen med dit system.
Hvad giver denne viden til hver af specialisterne?
Til systemadministratorer
Praksis vil give dig mulighed for at bevæge dig væk fra administration til at skabe en kontinuerlig leveringspipeline og en infrastrukturplatform til softwarelevering. Pointen er, at han skaber et produkt – en infrastrukturplatform for udviklere, der hjælper dem med hurtigt at skubbe deres ændringer til produktionen.
Tidligere var systemadministratorer den sidste bastion, hvorefter alt går i produktion. Og dybest set var de engageret i kontinuerlig brandslukning - i lyset af hvilket det er ret svært at dykke ned i virksomhedens behov, tænke på produktet og fordelene for brugeren.
Takket være DevOps-metoden ændres tankegangen. Systemadministratoren forstår, hvordan man oversætter konfigurationen til kode, hvilken praksis der findes for dette.
Dette er vigtigt, fordi virksomheder i stigende grad indser, at de ikke bare skal automatisere alt, dvs. i hvad old-school systemadministratorer i det væsentlige var vant til at gøre, som plus dette kommunikerede lidt og ikke informerede teamet om alle de foretagne ændringer. Nu leder teamene efter dem, der vil blive producenten af det interne infrastrukturprodukt og hjælpe med at kombinere de adskilte processer til én.
Udviklere
Udvikleren holder op med kun at tænke i algoritmer. Han tilegner sig evnen til at arbejde med infrastruktur, evnen til arkitektonisk bevidsthed om landskabet. En sådan udvikler forstår, hvordan applikationen fungerer, hvordan den går gennem den kontinuerlige leveringspipeline, hvordan man overvåger den, hvordan man registrerer den, så den kommer kunden til gode. Som et resultat giver al denne viden dig mulighed for at skrive relevant kode.
Til testere
Test har længe bevæget sig over i automatisk tilstand, vi siger alle, at mange test ikke skal laves, men skrives :) Test bliver en del af hele leveringspipelinen af dit produkt. En tester skal ikke kun lære at skrive kode, men også at forstå hvordan man integrerer den i kontinuerlige leveringssystemer, hvordan man modtager feedback fra koden på alle stadier af leveringen, og hvordan man konstant forbedrer testning for at opdage fejl som tidligt som muligt.
Så det viser sig at alle tre stadier forekommer samtidigt. For eksempel kan det se sådan ud:
Udvikleren skriver koden, skriver straks tests for den og beskriver en docker-container for den kode, der skal køres. Det beskriver også umiddelbart den overvågning, der vil overvåge driften af denne service i produktionen, og forpligter alt dette.
Når kontinuerlig integration starter, kører processer samtidigt. Tjenesten starter og er konfigureret. Samtidig starter docker-containeren og det kontrolleres at den kører. Samtidig går alle informationer til logningssystemet. Og så videre på alle udviklingstrin - det viser sig at være et ægte teamwork af systemadministratorer, udviklere og testere.
Jeg studerede DevOps, hvad så?
Som du ved, er en i feltet ikke en kriger. Hvis din virksomhed ikke bruger denne metode, vil de erhvervede færdigheder ligge stille. Og efter at have stiftet bekendtskab med DevOps-tilgange, vil du højst sandsynligt ikke være et tandhjul i virksomhedsudvikling. Der kan være én undtagelse: du er systemadministrator på holdet og kan genopbygge alle processer på en ny måde. Det er værd at tilføje her, at der er mange virksomheder, der bruger denne tilgang, og de er ikke påvirket af nedlukningen og leder efter specialister. Fordi DevOps handler om at skabe online produkter.
Og nu om de gode ting: beherskelse af DevOps-praksis og værktøjer er cirka +30 % til din værdi på arbejdsmarkedet. Løn starter fra 140 tusind rubler, men bestemmes naturligvis af din vigtigste specialitet og funktionalitet.
Du kan se på ledige stillinger mærket ”infrastruktur-orienteret”, hvor der er testautomatisering, udvikling af mikroserviceapplikationer ved brug af cloud-teknologier, ledige stillinger til infrastrukturingeniører og alverdens referencer til DevOps. Bare husk, at hver virksomhed mener noget forskelligt med denne definition - læs beskrivelsen omhyggeligt.
Under lanceringen af vores kursus kom en indsigt til mig – mange mennesker efter kurset falder i fælden af en DevOps-ingeniør. De finder en ledig stilling med ovennævnte titel, modtager et godt tilbud og kommer så på arbejde og indser, at de bliver nødt til at opretholde et tre-siders bash-manuskript i Jenkins. Hvor er Kubernetes, ChatOps, canary-udgivelser og alt det der? Men der er intet, for virksomheden har ikke brug for DevOps som metodik, men bruger individuelle innovationer.
Dette er en grund til intensivt at finde ud af fra virksomheden, hvordan softwareleveringsprocessen fungerer, teknologistakken og hvilket ansvar du vil udføre.
Hvis arbejdsgiveren besvarer dine spørgsmål abstrakt, som fra en bog, uden detaljer, så er der højst sandsynligt ingen DevOps-proces i virksomheden endnu, men dette er ikke en grund til at afvise, studere virksomheden og dens produkter, om der er online tjenester, som virksomheden selv udvikler, mobile applikationer, produktideer.
Hvis ja, så afklar, om du bliver nødt til at arbejde direkte med disse systemer, eller om der er mulighed for horisontal bevægelse til teamene af disse tjenester, mens du viser gode resultater i DevOps-praksis. Hvis ja, så er det værd at gå og være aktiv og brugbar, og gennemfører du vores kursus, er det sidste garanteret.
Det er vigtigt at bemærke, at Devops-udøvere kun opnår ægte værdi med erfaring i udvikling/administration/test. Kun da vil viden ikke være abstrakt, men berige specialisten (i enhver forstand). Derfor er ideen om at "lære DevOps fra bunden" omtrent det samme som at lære at "bruge linser fra bunden", hvis du aldrig har holdt et kamera i hænderne eller instrueret et billede. For at hjælpe dig med at beslutte, om kurset er det rigtige for dig, har vi lavet en optagelsestest, som vil kontrollere dit tilstrækkelige vidensniveau.
Jeg synes et af trickene — at hver elev i løbet af uddannelsen selv bestemmer, i hvilken retning han vil udvikle sig. Vi ser ofte overgange, når en udvikler bliver infrastrukturingeniør, og en administrator indser, at han er interesseret i at skrive kode – så studerer han sproget videre og supplerer det med de tilegnede DevOps-færdigheder. Derfor byder vi især velkommen til dem, der føler, at deres karriere sidder fast ved en skillevej. Kurset starter den 28. maj, men du kan tilmelde dig 2 uger efter undervisningsstart. Du kan se programmet og tage testen . Vi ses på OTUS!
Kilde: www.habr.com