Hvor du skal gå med denne kunnskapen, hva du skal gjøre i prosjektet og hvor mye du skal tjene, hva du skal si og spørre på et intervju - sier Alexander Titov, administrerende partner for Express 42 og forfatter .
Hallo! Selv om begrepet DevOps har eksistert siden 2009, er det fortsatt ingen konsensus i det russiske samfunnet. Du har sikkert lagt merke til at noen anser DevOps som en spesialitet, andre anser det som en filosofi, og andre anser begrepet som et sett med teknologier. Jeg har allerede opptrådt mange ganger med om utviklingen av denne retningen, så jeg vil ikke gå i detalj i denne artikkelen. La meg bare si at på Express 42 inkluderer vi følgende i den:
DevOps er en spesifikk metodikk, en kultur for å lage et digitalt produkt, når alle spesialister i teamet deltar i produksjonen.
I klassisk bedriftsutvikling går alt sekvensielt: programmering, testing og først deretter drift, og hastigheten på denne prosessen fra idé til produksjon er 3 måneder. Dette er et globalt problem for digitale produkter, fordi det er umulig å raskt få tilbakemeldinger fra kunder.
I DevOps er verktøy og tilnærminger designet for å sikre at utviklings-, test- og driftsprosesser kjøres samtidig.
Hva følger av denne tilnærmingen?
- Du kan ikke ansette en "ingeniør" som kommer og løser alle problemene med produksjonen. Hele laget må bruke teknikken.
- DevOps er IKKE den neste formen for systemadministrator å oppgradere til. "DevOps-ingeniør" høres omtrent det samme ut som "Agil utvikler."
- Hvis et team bruker Kubernetes, Ansible, Prometheus, Mesosphere og Docker, betyr ikke dette at DevOps-praksis er implementert der.
Livet etter DevOps vil aldri bli det samme
DevOps-tilnærmingen er for det første en annen måte å tenke på, en oppfatning av utviklingen som helhet og ens plass i prosessen. Vi delte opp nettkurset vårt i 2 blokker:
1. Selvbestemmelse
Først undersøker vi i detalj essensen av DevOps-tilnærmingen, og elevene oppdager nye roller i teamet, ser hvilken som reagerer mest, og bestemmer selv hvilken retning de skal utvikle.
2. Verktøy og praksis
Studentene mestrer spesifikke teknologier fra synspunktet til DevOps-metoden.
DevOps-verktøy kan brukes både i DevOps-tilnærmingen og i klassisk utvikling. Det mest åpenbare eksemplet vil være å bruke Ansible-konfigurasjonsadministrasjonsverktøyet. Den ble opprettet og utviklet for å implementere DevOps-praksisen "Infrastructure as Code", som betyr at forskjellige tilstander av systemet er beskrevet, fra operativsysteminnstillinger til applikasjonsprogramvare. Beskrivelsen er delt inn i lag og lar deg administrere en kompleks konfigurasjon i stadig endring. Men ingeniører bruker ofte Ansible som en måte å kjøre bash-skript på flere maskiner. Dette er verken dårlig eller bra, men du må forstå at tilstedeværelsen av Ansible ikke garanterer tilstedeværelsen av DevOps i selskapet.
Vi er i gang Du vil bli fordypet i prosessen med å utvikle en applikasjon som ligner på den berømte Reddit, som starter med dens monolitiske versjon, og går steg for steg til mikrotjenester. Steg for steg vil vi mestre nye verktøy: Git, Ansible, Gitlab og avslutte med Kubernetes og Prometheus.
Når det gjelder praksis, vil vi følge taktikken til de tre banene som er beskrevet i DevOps-håndboken - kontinuerlig leveringspraksis, tilbakemeldingspraksis, og essensen av hele kurset er praksisen med kontinuerlig læring sammen med systemet ditt.
Hva gir denne kunnskapen til hver av spesialistene?
For systemadministratorer
Praksis vil tillate deg å gå bort fra administrasjon til å lage en kontinuerlig leveringspipeline og en infrastrukturplattform for programvarelevering. Poenget er at han lager et produkt – en infrastrukturplattform for utviklere som hjelper dem raskt å presse endringene sine til produksjon.
Tidligere var systemadministratorer den siste bastionen, hvoretter alt går i produksjon. Og i utgangspunktet var de engasjert i kontinuerlig brannslukking - i lys av dette er det ganske vanskelig å fordype seg i virksomhetens behov, tenke på produktet og fordelene for brukeren.
Takket være DevOps-metoden endres tenkningen. Systemadministratoren forstår hvordan man oversetter konfigurasjonen til kode, hvilke praksiser som finnes for dette.
Dette er viktig fordi bedrifter i økende grad innser at de ikke bare trenger å automatisere alt, dvs. i det gamle skolesystemadministratorer i hovedsak var vant til å gjøre, som pluss dette kommuniserte lite og ikke informerte teamet om alle endringene som ble gjort. Nå leter teamene etter de som skal bli produsent av det interne infrastrukturproduktet og bidra til å kombinere de separerte prosessene til én.
Utviklere
Utvikleren slutter å tenke bare i algoritmer. Han tilegner seg ferdigheten til å jobbe med infrastruktur, ferdigheten til arkitektonisk bevissthet om landskapet. En slik utvikler forstår hvordan applikasjonen fungerer, hvordan den går gjennom den kontinuerlige leveringspipelinen, hvordan man overvåker den, hvordan man registrerer den slik at den kommer kunden til gode. Som et resultat lar all denne kunnskapen deg skrive relevant kode.
For testere
Testing har lenge gått over i automatisk modus; vi sier alle at mange tester ikke bør gjøres, men skrives :) Testing blir en del av hele leveringspipelinen til produktet ditt. En tester trenger ikke bare å lære hvordan man skriver kode, men også å forstå hvordan man integrerer den i kontinuerlige leveringssystemer, hvordan man mottar tilbakemelding fra koden på alle stadier av leveringen, og hvordan man kontinuerlig forbedrer testing for å oppdage feil som tidlig som mulig.
Så det viser seg at alle tre stadier skjer samtidig. For eksempel kan det se slik ut:
Utvikleren skriver koden, skriver umiddelbart tester for den, og beskriver en docker-beholder for koden som skal kjøres. Den beskriver også umiddelbart overvåkingen som skal overvåke driften av denne tjenesten i produksjon, og forplikter alt dette.
Når kontinuerlig integrasjon starter, kjører prosessene samtidig. Tjenesten starter og er konfigurert. Samtidig starter docker-containeren og det sjekkes at den kjører. Samtidig går all informasjon til loggsystemet. Og så videre på hvert utviklingsstadium - det viser seg å være et ekte teamarbeid av systemadministratorer, utviklere og testere.
Jeg studerte DevOps, hva neste?
Som du vet, er en i felten ikke en kriger. Hvis din bedrift ikke bruker denne metoden, vil de ervervede ferdighetene ligge stille. Og etter å ha blitt kjent med DevOps-tilnærminger, vil du sannsynligvis ikke være et tannhjul i bedriftsutvikling. Det kan være ett unntak: du er systemadministrator i teamet og kan gjenoppbygge alle prosesser på en ny måte. Det er verdt å legge til her at det er mange selskaper som bruker denne tilnærmingen, og de er ikke berørt av nedstengningen og leter etter spesialister. Fordi DevOps handler om å lage nettprodukter.
Og nå om de gode tingene: mestring av DevOps-praksis og verktøy er omtrent +30 % til din verdi på arbeidsmarkedet. Lønn starter fra 140 tusen rubler, men bestemmes naturligvis av din hovedspesialitet og funksjonalitet.
Du kan se på ledige stillinger merket «infrastruktur-orientert», hvor det er testautomatisering, utvikling av mikrotjenesteapplikasjoner ved bruk av skyteknologier, ledige stillinger for infrastrukturingeniører og alle mulige referanser til DevOps. Bare husk at hvert selskap mener noe forskjellig med denne definisjonen - les beskrivelsen nøye.
Under lanseringen av kurset vårt kom en innsikt til meg – mange mennesker etter kurset går i fellen til en DevOps-ingeniør. De finner en ledig stilling med den ovennevnte tittelen, får et godt tilbud, og kommer så på jobb og innser at de må opprettholde et tre-siders bash-manus i Jenkins. Hvor er Kubernetes, ChatOps, canary-utgivelser og alt det der? Men det er ingenting, for selskapet trenger ikke DevOps som metodikk, men bruker individuelle innovasjoner.
Dette er en grunn til å intensivt finne ut fra selskapet hvordan programvareleveringsprosessen fungerer, teknologistabelen og hvilket ansvar du vil utføre.
Hvis arbeidsgiveren svarer abstrakt på spørsmålene dine, som fra en bok, uten detaljer, så er det mest sannsynlig ingen DevOps-prosess i selskapet ennå, men dette er ikke en grunn til å nekte, studere selskapet og dets produkter, om det er online tjenester som selskapet utvikler selv, mobilapplikasjoner, produktideer.
Hvis ja, avklar om du må jobbe direkte med disse systemene eller om det er mulighet for horisontal bevegelse til teamene til disse tjenestene samtidig som du viser gode resultater i DevOps-praksis. Hvis ja, så er det verdt å gå og være aktiv og nyttig, og fullfører du kurset vårt er det siste garantert.
Det er viktig å merke seg at Devops-utøvere oppnår sann verdi kun med erfaring innen utvikling/administrasjon/testing. Først da vil kunnskapen ikke være abstrakt, men berike spesialisten (i enhver forstand). Derfor er ideen om å "lære DevOps fra bunnen av" omtrent det samme som å lære å "bruke linser fra bunnen av" hvis du aldri har holdt et kamera i hendene eller regissert en fotografering. For å hjelpe deg med å avgjøre om kurset passer for deg, har vi laget en opptaksprøve som skal sjekke ditt tilstrekkelige kunnskapsnivå.
Jeg tror et av triksene — at i løpet av opplæringen bestemmer hver elev selv i hvilken retning han vil utvikle seg. Vi ser ofte overganger når en utvikler blir infrastrukturingeniør, og en administrator innser at han er interessert i å skrive kode – så studerer han språket videre og supplerer det med de tilegnete DevOps-ferdighetene. Derfor ønsker vi spesielt velkommen til de som føler at karrieren står fast ved et veiskille. Kurset starter 28. mai, men du kan være med 2 uker etter klassestart. Du kan se programmet og ta testen . Vi sees på OTUS!
Kilde: www.habr.com