Vart ska man gå med denna kunskap, vad man ska göra i projektet och hur mycket man ska tjäna, vad man ska säga och fråga vid en intervju - säger Alexander Titov, managing partner för Express 42 och författare .
Hallå! Även om termen DevOps har funnits sedan 2009, finns det fortfarande ingen konsensus i det ryska samhället. Du har säkert märkt att vissa anser att DevOps är en specialitet, andra anser att det är en filosofi och andra anser att termen är en uppsättning teknologier. Jag har redan uppträtt många gånger med om utvecklingen av denna riktning, så jag kommer inte att gå in i detalj i den här artikeln. Låt mig bara säga att på Express 42 inkluderar vi följande i den:
DevOps är en specifik metodik, en kultur för att skapa en digital produkt, när alla specialister i teamet deltar i produktionen.
I klassisk företagsutveckling går allt sekventiellt: programmering, testning och först därefter drift, och hastigheten på denna process från idé till produktion är 3 månader. Detta är ett globalt problem för digitala produkter, eftersom det är omöjligt att snabbt få feedback från kunder.
I DevOps är verktyg och tillvägagångssätt utformade för att säkerställa att utvecklings-, test- och driftprocesser körs samtidigt.
Vad följer av detta tillvägagångssätt?
- Du kan inte anställa någon ”ingenjör” som kommer och löser alla problem med produktionen. Hela laget måste tillämpa tekniken.
- DevOps är INTE nästa form av sysadmin att uppgradera till. "DevOps-ingenjör" låter ungefär som "Agil utvecklare."
- Om ett team använder Kubernetes, Ansible, Prometheus, Mesosphere och Docker betyder det inte att DevOps-praxis har implementerats där.
Livet efter DevOps kommer aldrig att bli detsamma
DevOps-metoden är för det första ett annat sätt att tänka, en uppfattning om utvecklingen som helhet och ens plats i processen. Vi delade upp vår onlinekurs i 2 block:
1. Självbestämmande
Först undersöker vi i detalj kärnan i DevOps-metoden, och eleverna upptäcker nya roller i teamet, ser vilken som svarar mest och avgör själva vilken riktning de ska utveckla.
2. Verktyg och praxis
Studenter behärskar specifika teknologier utifrån DevOps-metoden.
DevOps-verktyg kan användas både i DevOps-metoden och i klassisk utveckling. Det mest uppenbara exemplet skulle vara att använda Ansibles konfigurationshanteringsverktyg. Det skapades och utformades för att implementera DevOps-praxis "Infrastructure as Code", vilket innebär att olika tillstånd i systemet beskrivs, från operativsysteminställningar till applikationsprogramvara. Beskrivningen är uppdelad i lager och låter dig hantera en komplex, ständigt föränderlig konfiguration. Men ingenjörer använder ofta Ansible som ett sätt att köra bash-skript på flera maskiner. Detta är varken dåligt eller bra, men du måste förstå att närvaron av Ansible inte garanterar närvaron av DevOps i företaget.
Vi är i processen Du kommer att fördjupas i processen att utveckla en applikation som liknar den berömda Reddit, med början i dess monolitiska version, steg för steg över till mikrotjänster. Steg för steg kommer vi att bemästra nya verktyg: Git, Ansible, Gitlab och avsluta med Kubernetes och Prometheus.
När det gäller övningar kommer vi att följa taktiken för de tre vägarna som beskrivs i DevOps-handboken - övningar för kontinuerlig leverans, återkopplingspraxis, och kärnan i hela kursen är övningen av kontinuerligt lärande tillsammans med ditt system.
Vad ger denna kunskap till var och en av specialisterna?
För systemadministratörer
Praxis gör att du kan gå bort från administration till att skapa en kontinuerlig leveranspipeline och en infrastrukturplattform för mjukvaruleverans. Poängen är att han skapar en produkt – en infrastrukturplattform för utvecklare som hjälper dem att snabbt driva sina förändringar i produktionen.
Tidigare var systemadministratörer den sista bastionen, varefter allt går i produktion. Och i grund och botten var de engagerade i kontinuerlig brandbekämpning - i ljuset av vilket det är ganska svårt att fördjupa sig i verksamhetens behov, tänka på produkten och fördelarna för användaren.
Tack vare DevOps-metoden förändras tänkandet. Systemadministratören förstår hur man översätter konfigurationen till kod, vilka rutiner som finns för detta.
Detta är viktigt eftersom företagen alltmer inser att de inte bara behöver automatisera allt, d.v.s. i vad gamla skolans systemadministratörer i huvudsak var vana vid att göra, som plus detta kommunicerade lite och inte informerade teamet om alla ändringar som gjorts. Nu letar teamen efter de som ska bli tillverkare av den interna infrastrukturprodukten och hjälpa till att kombinera de separerade processerna till en.
Utvecklare
Utvecklaren slutar bara tänka i algoritmer. Han skaffar sig färdigheten att arbeta med infrastruktur, färdigheten att arkitektonisk medvetenhet om landskapet. En sådan utvecklare förstår hur applikationen fungerar, hur den går genom den kontinuerliga leveranspipelinen, hur man övervakar den, hur man registrerar den så att den gynnar kunden. Som ett resultat låter all denna kunskap dig skriva relevant kod.
För testare
Testning har länge gått över till automatiskt läge, vi säger alla att många tester inte ska göras utan skrivas :) Testning blir en del av hela leveranspipelinen för din produkt. En testare behöver inte bara lära sig hur man skriver kod, utan också förstå hur man integrerar den i kontinuerliga leveranssystem, hur man får feedback från koden i alla led av leveransen och hur man ständigt förbättrar testning för att upptäcka fel som tidigt som möjligt.
Och så visar det sig att alla tre stadierna inträffar samtidigt. Det kan till exempel se ut så här:
Utvecklaren skriver koden, skriver omedelbart tester för den och beskriver en dockningsbehållare för koden som ska köras. Den beskriver också omedelbart övervakningen som kommer att övervaka driften av denna tjänst i produktionen, och åtar sig allt detta.
När kontinuerlig integration startar körs processer samtidigt. Tjänsten startar och konfigureras. Samtidigt startar dockercontainern och det kontrolleras att den är igång. Samtidigt går all information till loggningssystemet. Och så vidare i varje utvecklingsstadium - det visar sig vara ett riktigt lagarbete av systemadministratörer, utvecklare och testare.
Jag studerade DevOps, vad härnäst?
Som ni vet är en i fältet ingen krigare. Om ditt företag inte använder denna metod kommer de förvärvade färdigheterna att ligga overksamma. Och efter att ha bekantat dig med DevOps tillvägagångssätt, kommer du troligen inte att vilja vara en kugge i företagsutveckling. Det kan finnas ett undantag: du är systemadministratör i teamet och kan bygga om alla processer på ett nytt sätt. Det är värt att tillägga här att det finns många företag som använder det här tillvägagångssättet, och de påverkas inte av låsningen och letar efter specialister. Eftersom DevOps handlar om att skapa onlineprodukter.
Och nu om det som är bra: behärskning av DevOps-praxis och verktyg är ungefär +30 % av ditt värde på arbetsmarknaden. Löner startar från 140 tusen rubel, men bestäms naturligtvis av din huvudsakliga specialitet och funktionalitet.
Du kan titta på lediga jobb märkta "infrastrukturorienterade", där det finns testautomatisering, utveckling av mikrotjänstapplikationer med hjälp av molnteknik, lediga jobb för infrastrukturingenjörer och alla möjliga referenser till DevOps. Kom bara ihåg att varje företag menar något annorlunda med denna definition - läs beskrivningen noggrant.
Under lanseringen av vår kurs kom en insikt till mig – många människor efter kursen faller i fällan av en DevOps-ingenjör. De hittar en ledig plats med den ovan nämnda titeln, får ett bra erbjudande och kommer sedan till jobbet och inser att de kommer att behöva behålla ett tresidigt bashmanus i Jenkins. Var finns Kubernetes, ChatOps, kanariefågel och allt det där? Men det finns ingenting, eftersom företaget inte behöver DevOps som metod, utan använder sig av individuella innovationer.
Detta är en anledning att intensivt ta reda på från företaget hur mjukvaruleveransprocessen fungerar, teknikstacken och vilket ansvar du kommer att utföra.
Om arbetsgivaren besvarar dina frågor abstrakt, som från en bok, utan detaljer, så finns det troligen ingen DevOps-process i företaget ännu, men detta är inte en anledning att vägra, studera företaget och dess produkter, oavsett om det finns online tjänster som företaget själv utvecklar, mobila applikationer, produktidéer.
Om ja, förtydliga om du kommer att behöva arbeta direkt med dessa system eller om det finns möjlighet till horisontell förflyttning till teamen av dessa tjänster samtidigt som du visar goda resultat i DevOps-praxis. Om ja, så är det värt att gå och vara aktiv och användbar, och genomför du vår kurs är det garanterat det senare.
Det är viktigt att notera att Devops-utövare får verkligt värde endast med erfarenhet av utveckling/administration/testning. Först då kommer kunskapen inte att vara abstrakt, utan berika specialisten (i alla avseenden). Därför är idén att "lära sig DevOps från grunden" ungefär detsamma som att lära sig att "använda linser från grunden" om du aldrig har haft en kamera i händerna eller regisserat en fotografering. För att hjälpa dig avgöra om kursen är rätt för dig har vi gjort ett antagningstest som kontrollerar din tillräckliga kunskapsnivå.
Jag tror att ett av knepen — att varje elev under utbildningens gång bestämmer själv i vilken riktning han vill utvecklas. Vi ser ofta övergångar när en utvecklare blir infrastrukturingenjör, och en administratör inser att han är intresserad av att skriva kod – då studerar han språket vidare och kompletterar det med de förvärvade DevOps-kunskaperna. Därför välkomnar vi särskilt de som känner att karriären har fastnat vid ett vägskäl. Kursen startar den 28 maj, men du kan gå med 2 veckor efter kursstart. Du kan se programmet och göra provet . Vi ses på OTUS!
Källa: will.com