Nyligen har sådana annonser strömmat in på Internet. Trots den trevliga lönen kan man inte låta bli att skämmas över att det står vild kätteri inuti. Först antas det att "DevOps" och "ingenjör" på något sätt kan limmas ihop till ett ord, och sedan finns det en slumpmässig lista med krav, av vilka några är tydligt kopierade från den lediga sysadmin.
I det här inlägget skulle jag vilja prata lite om hur vi kom till denna punkt i livet, vad DevOps egentligen är och vad man ska göra med det nu.
Sådana vakanser kan fördömas på alla möjliga sätt, men faktum kvarstår: det finns många av dem, och det är så marknaden fungerar för tillfället. Vi höll en devops-konferens och förklarar öppet: " - inte för DevOps-ingenjörer." Detta kommer att verka konstigt och vilt för många: varför människor som gör ett helt kommersiellt evenemang går emot marknaden. Nu ska vi förklara allt.
Om kultur och processer
Låt oss börja med att DevOps inte är en ingenjörsdisciplin. Allt började med att den historiskt etablerade rollfördelningen inte fungerar för produkternas kvalitet. När programmerare bara programmerar, men inte vill höra något om testning, är programvaran full av buggar. När administratörer inte bryr sig om hur eller varför programvaran skrivs, förvandlas support till ett helvete.
Till exempel att beskriva skillnaden mellan en systemadministratör och en SRE-strategi för tjänstehantering . Intressanta studier har genomförts inom — Det är uppenbart att de bästa utvecklarna på något sätt lyckas implementera nya ändringar i produktionen snabbare än en gång i timmen. De testar med händerna inte mer än 10% (detta kan ses från ). Hur gör de detta? "Excel or die" står det i en av rapportrubrikerna. För en detaljerad diskussion av denna statistik i samband med testning, kan du hänvisa till Baruch Sadogurskys keynote på vår andra konferens, Heisenbug.
"När det inte finns någon överenskommelse mellan kamrater,
Deras verksamhet kommer inte att gå bra,
Och det kommer ingenting ur det, bara mjöl.
Det var en gång en svan, en kräfta och en gädda..."
Vilken del av webbprogrammerare tror du verkligen förstår under vilka förutsättningar deras applikationer används i produktionen? Hur många av dem kommer att gå till administratörerna och försöka lista ut vad som kommer att hända om databasen kraschar? Och vem av dem kommer att gå till testarna och be dem lära dem hur man skriver prov korrekt? Och det finns också säkerhetsvakter, produktchefer och en massa andra människor.
Den övergripande idén med DevOps är att skapa samarbete mellan roller och avdelningar. Först och främst uppnås detta inte av någon smart konfigurerad mjukvara, utan genom praktiken av kommunikation. DevOps handlar om kultur, praxis, metodik och processer. Det finns ingen ingenjörsspecialist som kan svara på dessa frågor.
Ond cirkel
Var kom disciplinen "devops engineering" ifrån då? Vi har en version! DevOps-idéerna var bra – så bra att de blev offer för sin egen framgång. Några skumma rekryterare och människohandlare, som har sin egen atmosfär, började snurra runt hela detta ämne.
Föreställ dig: igår gjorde du shawarma i Khimki, och idag är du redan en stor man, en senior rekryterare. Det finns en hel process att söka och välja ut kandidater, allt är inte lätt, du måste förstå. Låt oss säga att chefen för en avdelning säger: hitta en specialist i X. Vi tilldelar ordet "ingenjör" till X, och vi är klara. Behöver du Linux? Tja, det här är definitivt en Linux-ingenjör, om du vill ha DevOps, då en DevOps-ingenjör. Den lediga tjänsten består inte bara av en titel, utan även en del text ska skrivas in. Det enklaste sättet är att ange en uppsättning sökord från Google, beroende på din fantasi. DevOps består av två ord - "Dev" och "Ops", vilket betyder att vi måste limma ihop nyckelord relaterade till utvecklare och administratörer, allt i en hög. Så här visas lediga jobb om färdigheter i 42 programmeringsspråk och 20 års användning av Kubernetes och Swarm samtidigt. Arbetsdiagram.
Det är så den meningslösa och skoningslösa bilden av en viss "devops" superhjälte har slagit rot i människors sinnen, som kommer att konfigurera alla att distribuera till Jenkins, och lyckan kommer. Åh, om allt bara vore så enkelt. "Och det är också så du kan jaga systemadministratörer", tycker HR, "det är ett modeord, nyckelorden är desamma, de borde ta betet."
Efterfrågan skapar utbud och alla dessa vakanser har fyllts med ett vansinnigt antal systemadministratörer som insett: du kan göra allt på samma sätt som tidigare, men få flera gånger mer genom att kalla dig själv "devops". Precis som du konfigurerade servrar via SSH manuellt en i taget, kommer du att fortsätta att konfigurera dem, men nu är detta förmodligen en devops-praxis. Det här är något slags komplext fenomen, delvis relaterat till underskattningen av klassiska admins och hypen kring DevOps, men i allmänhet hände det som hände.
Så vi har tillgång och efterfrågan. En ond cirkel som livnär sig själv. Det är detta vi kämpar mot (bland annat genom att skapa DevOops-konferensen).
Naturligtvis, förutom systemadministratörer som har döpt om sig själva till "devops", finns det andra deltagare - till exempel professionella SRE:er eller Infrastructure-as-Code-utvecklare.
Vad folk gör i DevOps (egentligen)
Så du vill komma framåt med att lära dig och tillämpa DevOps-praxis. Men hur gör man detta, åt vilket håll ska man titta? Självklart ska du inte blint lita på populära sökord.
Finns det ett jobb borde någon göra det. Vi har redan fått reda på att dessa inte är "devops-ingenjörer", vilka är det då? Det förefaller mer korrekt att formulera detta inte i termer av befattningar, utan i termer av specifika arbetsområden.
Först kan du ta itu med hjärtat av DevOps – processer och kultur. Kultur är en långsam och svår verksamhet, och även om det traditionellt är chefers ansvar är alla involverade på ett eller annat sätt, från programmerare till administratörer. För ett par månader sedan Tim Lister :
"Kultur bestäms av organisationens kärnvärden. Oftast märker inte folk detta, men efter att ha jobbat med konsult i många år är vi vana att märka det. Du kommer in i ett företag och bokstavligen inom några minuter börjar du känna vad som händer. Vi kallar detta "smak". Ibland är denna doft riktigt bra. Ibland orsakar det illamående. (...) Man kan inte förändra en kultur förrän man förstår värderingarna och övertygelserna bakom specifika handlingar. Beteende är lätt att observera, men att söka efter övertygelser är svårt. DevOps är bara ett bra exempel på hur saker och ting blir mer och mer komplexa.”
Det finns också en teknisk del av frågan, förstås. Om din nya kod testas om en månad, men släpps bara ett år senare, och det är fysiskt omöjligt att påskynda allt, kanske du inte lever upp till god praxis. God praxis stöds av bra verktyg. Till exempel, med idén om Infrastructure-as-Code i åtanke, kan du använda allt från AWS CloudFormation och Terraform till Chef-Ansible-Puppet. Du måste veta och kunna allt detta, och det här är redan en ganska teknisk disciplin. Det är viktigt att inte blanda ihop orsak med verkan: först arbetar du enligt principerna för SRE och först därefter implementerar du dessa principer i form av några specifika tekniska lösningar. Samtidigt är SRE en mycket omfattande metod som inte berättar hur man ställer in Jenkins, utan om fem grundläggande principer:
- Förbättrad kommunikation mellan roller och avdelningar
- Att acceptera misstag som en integrerad del av jobbet
- Göra förändringar gradvis
- Använda verktyg och annan automation
- Mäter allt som går att mäta
Detta är inte bara en uppsättning uttalanden, utan en specifik . Till exempel, på vägen till att acceptera fel måste du förstå riskerna, mäta tillgängligheten och otillgängligheten för tjänster med något som SLI () och SLO (), lär dig att skriva obduktioner och göra det inte skrämmande att skriva dem.
Inom SRE-disciplinen är användningen av verktyg bara en del av framgången, även om en viktig sådan. Vi behöver hela tiden utveckla oss tekniskt, titta på vad som händer i världen och hur det kan tillämpas i vårt arbete.
I sin tur har Cloud Native-lösningar nu blivit mycket populära. Enligt definitionen av Cloud Native Computing Foundation idag, gör Cloud Native-teknologier det möjligt för organisationer att utveckla och köra skalbara applikationer i dagens dynamiska miljöer, såsom offentliga, privata och hybridmoln. Exempel inkluderar behållare, servicenät, mikrotjänster, oföränderlig infrastruktur och deklarativa API:er. Alla dessa tekniker tillåter löst kopplade system att förbli elastiska, hanterbara och mycket observerbara. Bra automatisering gör att ingenjörer kan göra stora förändringar ofta och med förutsägbara resultat utan att göra det till en syssla. Allt detta stöds av en bunt välkända verktyg som Docker och Kubernetes.
Denna ganska komplicerade och breda definition beror på att området också är ganska komplext. Å ena sidan menas att nya förändringar i detta system helt enkelt bör läggas till. Å andra sidan, för att ta reda på hur man skapar en slags containeriserad miljö där löst kopplade tjänster lever på en mjukvarudefinierad infrastruktur och levereras där med kontinuerlig CI/CD, och bygga DevOps-praxis kring allt detta - allt detta kräver mer än man äter hunden.
Vad ska man göra med allt detta
Alla löser dessa problem på sitt eget sätt: du kan till exempel publicera vanliga lediga tjänster för att bryta den onda cirkeln. Du kan ta reda på vad ord som DevOps och Cloud Native betyder och använda dem korrekt och rakt på sak. Du kan utvecklas i DevOps och visa de rätta tillvägagångssätten genom ditt exempel.
Vi håller en konferens , vilket ger en möjlighet att fördjupa oss i de saker vi just pratade om. Det finns flera grupper av rapporter för detta:
- Processer och kultur;
- Site Reliability Engineering;
- Cloud Native;
Hur väljer man var man ska åka? Det finns en subtil poäng här. Å ena sidan handlar DevOps om interaktion, och vi vill verkligen att du ska gå på presentationer från olika block. Å andra sidan, om du är en utvecklingsledare som kom till konferensen för att koncentrera dig på en specifik uppgift, så är det ingen som begränsar dig – självklart kommer detta att vara ett block om processer och kultur. Glöm inte att du kommer att ha inspelningar efter konferensen (efter att ha fyllt i feedbackformuläret), så att du alltid kan se mindre viktiga presentationer senare.
Självklart kan man på själva konferensen inte gå på tre spår samtidigt, så vi organiserar programmet på ett sådant sätt att varje tidslucka har ämnen för alla smaker.
Allt som återstår är att förstå vad du ska göra om du är en DevOps-ingenjör! Försök först att avgöra vad du faktiskt gör. Vanligtvis tycker de om att kalla detta ord:
- Utvecklare som arbetar med infrastruktur. Grupperna med rapporter om SRE och Cloud Native är bäst lämpade för dig.
- Systemadministratörer. Det är mer komplicerat här. DevOops handlar inte om systemadministration. Lyckligtvis finns det många utmärkta konferenser, böcker, artiklar, videor på Internet, etc. på ämnet systemadministration. Å andra sidan, om du är intresserad av att utveckla dig själv när det gäller att förstå kultur och processer, lära dig om molnteknologier och detaljerna i livet med Cloud Native, då skulle vi älska att träffa dig! Tänk på det här: du håller på med administration, och vad ska du göra då? För att undvika att plötsligt hamna i en obehaglig situation bör du lära dig nu.
Det finns ett annat alternativ: du envisas och fortsätter att hävda att du är det specifikt en DevOps-ingenjör och inget annat, vad det nu betyder. Då måste vi göra dig besviken, DevOops är ingen konferens för DevOps-ingenjörer!
Skjut från i München
DevOops 2020 Moskva kommer att hållas den 29-30 april i Moskva, biljetter finns redan tillgängliga .
Alternativt kan du till 8 februari. Observera att när du fyller i formuläret måste du välja den målgrupp som kommer att dra mest nytta av din rapport (det finns en överraskning begravd i listan).
Källa: will.com