PÄ senare tid har sÄdana annonser fyllt internet. Trots den attraktiva lönen kan man inte undgÄ att notera att det som stÄr skrivet inuti Àr ren galenskap. I början förutsÀtts att "DevOps" och "ingenjör" pÄ nÄgot sÀtt kan sammanfogas till ett enda ord, och sedan följer en slumpmÀssig lista av krav, varav en del tydligt har kopierats frÄn en administratörs jobbannons.
I det hÀr inlÀgget vill jag prata lite om hur vi kommit till denna situation, vad DevOps verkligen Àr och vad som nu ska göras med det.
SĂ„dana jobbannonser kan man kritisera pĂ„ mĂ„nga sĂ€tt, men faktum kvarstĂ„r: de Ă€r mĂ„nga, och sĂ„ ser marknaden ut just nu. Vi har anordnat en DevOps-konferens och sĂ€ger öppet: " â inte för DevOps-ingenjörer." MĂ„nga kommer att tycka att det Ă€r bĂ„de konstigt och galet: varför gĂ„r mĂ€nniskor som arrangerar ett helt kommersiellt evenemang emot marknaden? Nu ska vi förklara allt.
Om kultur och processer
LÄt oss börja med att sÀga att DevOps inte Àr en ingenjörsdiciplin. Det hela började med att den historiskt inarbetade uppdelningen av roller inte fungerar för produktens kvalitet. NÀr programmerare bara programmerar, men inte vill höra nÄgot om testning, blir mjukvaran fylld med buggar. NÀr administratörer inte bryr sig om hur och varför mjukvaran Àr skriven, sÄ blir stödet en mardröm.
Till exempel börjar beskrivningen av skillnaden mellan en administratörs och ett SRE:s tillvĂ€gagĂ„ngssĂ€tt till service management Intressanta studier har genomförts i samband med â det Ă€r tydligt att de bĂ€sta utvecklarna pĂ„ nĂ„got sĂ€tt lyckas fĂ„ ut nya förĂ€ndringar i produktion snabbare Ă€n en gĂ„ng i timmen. De testar dessutom manuellt inte mer Ă€n 10% (det syns i Hur lyckas de med detta? "Excel or die" â sĂ€ger en av rubrikerna i rapporten. För en djupare diskussion kring dessa statistiken i testningsperspektiv kan man hĂ€nvisa till keynoten av Baruch Sadogursky vid vĂ„r andra konferens, Heisenbug.
"NÀr det inte finns nÄgon samstÀmmighet bland kamrater,
DÄ kommer ingenting att gÄ framÄt,
Och det kommer att resultera i inget annat Àn lidande. "
En gĂ„ng var det en Svane, en Krabba och en GĂ€rsâŠ"
Vad tror ni, vilken del av webbprogrammerare verkligen förstÄr under vilka förhÄllanden deras applikationer körs i produktion? Hur mÄnga av dem kommer att gÄ till admin och försöka rÀkna ut vad som hÀnder vid en databasnedgÄng? Och vem av dem kommer att gÄ till testarna och be att fÄ lÀra sig hur man skriver tester pÄ rÀtt sÀtt? Och sÄ finns det sÀkerhetsfolk, produktchefer, en mÀngd andra mÀnniskor.
Den övergripande idén med DevOps Àr att förbÀttra samarbetet mellan roller och avdelningar. Detta uppnÄs i första hand inte genom nÄgon smart konfigurerad mjukvara, utan genom kommunikationspraxis. DevOps handlar om kultur, praktik, metodik och processer. Det finns ingen sÄdan ingenjörsspecialitet som svarar pÄ dessa frÄgor.
En ond cirkel
VarifrÄn kom dÄ disciplinen "DevOps-ingenjör"? Vi har en version! Idéerna bakom DevOps visade sig vara sÄ bra att de blev offer för sin egen framgÄng. Runt hela detta Àmne började det surra av suspekta rekryterare och mÀnniskohandlare, som har sin egen speciella atmosfÀr.
TĂ€nk dig: igĂ„r lagade du shawarma i Khimki, och idag Ă€r du redan en stor person, senior rekryterare. HĂ€r finns en hel process för att hitta och vĂ€lja kandidater, allt Ă€r inte enkelt, man mĂ„ste förstĂ„. Anta att avdelningschefen sĂ€ger: hitta en specialist pĂ„ X. Vi lĂ€gger till ordet "ingenjör" till X, och dĂ€r Ă€r problemet löst. Behövs Linux? Ja, det Ă€r definitivt en Linux-ingenjör, vill du ha DevOps â en DevOps-ingenjör. En jobbannons bestĂ„r inte bara av en rubrik, utan det behövs ocksĂ„ nĂ„gon text inuti. Det enklaste Ă€r att skriva en uppsĂ€ttning nyckelord frĂ„n Google, vad man nu kan tĂ€nka sig. DevOps bestĂ„r av tvĂ„ ord â "Dev" och "Ops", sĂ„ det mĂ„ste klistras ihop nyckelord relaterade till utvecklare och administratörer till en enda hög. SĂ„ hĂ€r uppstĂ„r jobbannonser om att behĂ€rska 42 programmeringssprĂ„k och 20 Ă„rs erfarenhet av att anvĂ€nda Kubernetes och Swarm samtidigt. En fungerande strategi.
SÄdana bilder har rotat sig djupt i mÀnniskors medvetande om en meningslös och hÀnsynslös bild av en superhjÀlte "DevOps", som konfigurerar alla distributioner pÄ Jenkins, och dÄ kommer lyckan. à h, om bara allt var sÄ enkelt. "Och sÄ kan man ocksÄ jaga systemadministratörer, tÀnker HR, ett trendigt ord, samma nyckelord, de borde nappa."
EfterfrĂ„gan skapar utbud, och pĂ„ alla dessa tramsjobb har en galen mĂ€ngd systemadministratörer kommit in, som har insett: man kan göra samma sak som tidigare, men fĂ„ mycket mer betalt, genom att kalla sig 'DevOps'. SĂ„ som du konfigurerade servrar via SSH handgripligen en i taget, fortsĂ€tter du nu att göra det, men nu Ă€r det sĂ„ kallad DevOps-praxis. Detta Ă€r en komplex företeelse, delvis relaterad till undervĂ€rderingen av klassiska admin-personer och hypen kring DevOps, men i stort sett â vad som har hĂ€nt, har hĂ€nt.
SÄ, vi har efterfrÄgan och utbud. En sluten krets som föder sig sjÀlv. Det hÀr kÀmpa vi emot (inklusive genom att skapa konferensen DevOops).
SjĂ€lvklart, förutom systemadministratörer som har omdöpt sig till 'DevOps', finns det andra deltagare â till exempel professionella SRE eller utvecklare av Infrastructure-as-Code.
Vad mÀnniskor faktiskt sysslar med inom DevOps
SÄ, du vill gÄ vidare med att lÀra dig och tillÀmpa DevOps-praktiker. Men hur gör man det, vilken riktning ska man titta mot? Det Àr uppenbart att man inte ska blint följa populÀra nyckelord.
Om det finns arbete, mÄste nÄgon utföra det. Vi har redan kommit fram till att det inte Àr 'DevOps-ingenjörer', sÄ vem Àr det? Det verkar bÀttre att formulera detta inte i termer av positioner, utan i specifika arbetsomrÄden.
För det första kan man syssla med sjĂ€lva kĂ€rnan av DevOps â processer och kultur. Kultur Ă€r ingen snabb eller lĂ€tt sak, och Ă€ven om det traditionellt Ă€r ett ansvar som vilar pĂ„ ledarna, deltar alla pĂ„ nĂ„got sĂ€tt i detta, frĂ„n programmerare till administratörer. För nĂ„gra mĂ„nader sedan sa Tim Lister :
âKultur definieras av de grundlĂ€ggande vĂ€rderingarna i organisationen. Vanligtvis mĂ€rker mĂ€nniskor inte detta, men vi, som har arbetat inom konsultverksamhet i mĂ„nga Ă„r, Ă€r vana vid att notera det. Du gĂ„r in i ett företag och bokstavligen inom nĂ„gra minuter börjar du kĂ€nna vad som pĂ„gĂ„r. Vi kallar det 'doften'. Ibland Ă€r denna doft verkligen trevlig. Ibland orsakar den illamĂ„ende. (âŠ) Du kan inte förĂ€ndra kulturen innan vĂ€rderingarna och övertygelserna bakom specifika handlingar har blivit medvetna. Det Ă€r lĂ€tt att observera beteende, men svĂ„rt att leta efter övertygelser. DevOps Ă€r faktiskt ett utmĂ€rkt exempel pĂ„ hur allt blir mer och mer komplicerat.â
Det finns sĂ„klart en teknisk del av frĂ„gan. Om du fĂ„r ny kod för testning om en mĂ„nad, men den inte slĂ€pps förrĂ€n om ett Ă„r, och det rent fysiskt inte gĂ„r att pĂ„skynda allt detta â dĂ„ kan man missa de bĂ€sta metoderna. Bra metoder understöds av bra verktyg. Till exempel, genom att ha idĂ©en om Infrastructure-as-Code i Ă„tanke kan du anvĂ€nda vad som helst, frĂ„n AWS CloudFormation och Terraform till Chef-Ansible-Puppet. Allt detta mĂ„ste man kĂ€nna till och kunna, och det Ă€r verkligen en ingenjörsdiciplin. Det Ă€r viktigt att inte blanda ihop orsaken och verkan: först arbetar man efter SRE-principerna och sedan förverkligar man dessa principer i form av specifika tekniska lösningar. Samtidigt Ă€r SRE en mycket komplex metodik som handlar om mer Ă€n hur man konfigurerar Jenkins; det handlar om fem grundprinciper:
- FörbÀttra samarbetet mellan roller och avdelningar
- Acceptera misstag som en oundviklig del av arbetet
- Gradvis genomföra förÀndringar
- AnvÀnda verktyg och annan automatisering
- MÀta allt som gÄr att mÀta
Detta Àr inte bara ett antal pÄstÄenden, utan en konkret . Till exempel, pÄ vÀgen mot att acceptera misstag mÄste man hantera risker, mÀta tillgÀngligheten och otillgÀngligheten hos tjÀnster med hjÀlp av nÄgot som SLI () och SLO (), lÀra sig att skriva post-mortem-analyser och se till att det inte kÀnns skrÀmmande.
Inom SRE-disciplinen Àr anvÀndningen av verktyg bara en del av framgÄngen, men dock en viktig del. Vi mÄste stÀndigt utvecklas tekniskt, hÄlla koll pÄ vad som hÀnder i vÀrlden och hur detta kan tillÀmpas i vÄrt arbete.
Cloud Native-lösningar har blivit mycket populÀra nu för tiden. Enligt den moderna definitionen av Cloud Native Computing Foundation möjliggör Cloud Native-teknologier för organisationer att utveckla och köra skalbara applikationer i dagens dynamiska miljöer, sÄsom offentliga, privata och hybridmoln. Exempel pÄ dessa Àr containrar, servicemeshar, mikrotjÀnster, oförÀndlig infrastruktur och deklarativa API:er. Alla dessa tekniker gör det möjligt för löst kopplade system att förbli elastiska, hanterbara och vÀl övervakade. Bra automatisering gör det möjligt för tekniker att genomföra stora förÀndringar ofta och med förutsÀgbara resultat, utan att det blir ett helvete att hantera. Allt detta stöds av ett ekosystem av vÀlkÀnda verktyg som Docker och Kubernetes.
Denna ganska komplexa och omfattande definition beror pÄ att omrÄdet i sig Àr ganska komplicerat. à ena sidan hÀvdas det att nya förÀndringar i detta system ska lÀggas till ganska enkelt. à andra sidan behöver man mycket erfarenhet för att förstÄ hur man skapar en containeriserad miljö dÀr löst kopplade tjÀnster lever pÄ en mjukvarudefinierad infrastruktur och levereras dit genom kontinuerlig CI/CD, och bygga DevOps-praktiker kring allt detta.
Vad ska man göra med allt detta
Var och en hanterar dessa problem pÄ sitt eget sÀtt: man kan till exempel publicera vanliga jobbannonser för att bryta den onda cirkeln. Man kan ocksÄ reda ut vad ord som DevOps och Cloud Native betyder och anvÀnda dem korrekt och i rÀtt kontext. Man kan utvecklas inom DevOps och demonstrera rÀtt tillvÀgagÄngssÀtt genom eget exempel.
Vi anordnar en konferens , som ger möjlighet att djupare förstÄ de saker vi just har diskuterat. Det finns flera grupper av förelÀsningar för detta:
- Processer och kultur;
- Site Reliability Engineering;
- Cloud Native;
Hur vĂ€ljer man vart man ska gĂ„? Det finns en subtil punkt hĂ€r. Ă ena sidan handlar DevOps om samarbete, och vi vill verkligen att du ska gĂ„ pĂ„ förelĂ€sningar frĂ„n olika block. Ă andra sidan, om du Ă€r en utvecklingsledare som kommit till konferensen för att fokusera pĂ„ en specifik uppgift, sĂ„ begrĂ€nsar ingen dig â uppenbarligen blir det blocket om processer och kultur. Glöm inte att efter konferensen fĂ„r du inspelningar (efter att ha fyllt i Ă„terkopplingsformulĂ€ret), sĂ„ du kan alltid se de mindre viktiga förelĂ€sningarna senare.
Det Àr uppenbart att du inte kan delta i tre spÄr samtidigt under konferensen, sÄ vi formar programmet sÄ att det finns Àmnen för alla smaker i varje tidslucka.
Det ÄterstÄr bara att förstÄ vad du ska göra om du Àr DevOps-ingenjör! Först och frÀmst, försök att definiera vad du faktiskt sysslar med. Vanligtvis anvÀnds den hÀr termen för att beskriva:
- Utvecklare som arbetar med infrastruktur. För dig passar bÀst grupper av förelÀsningar om SRE och Cloud Native.
- Systemadministratörer. HÀr blir det svÄrare. DevOps handlar inte om systemadministration. Lyckligtvis finns det massor av fantastiska konferenser, böcker, artiklar, videor och sÄ vidare om systemadministration. à andra sidan, om du Àr intresserad av att utveckla din förstÄelse för kultur och processer, studera molnteknologier och detaljerna kring livet med Cloud Native, sÄ ser vi fram emot att se dig! TÀnk pÄ det hÀr: du arbetar med administration, vad kommer du att göra hÀrnÀst? För att inte plötsligt hamna i en obehaglig situation, bör du börja lÀra dig redan nu.
Det finns ytterligare ett alternativ: du insisterar och fortsÀtter hÀvda att du Àr just en DevOps-ingenjör och inget annat, oavsett vad det betyder. DÄ mÄste vi tyvÀrr meddela att DevOps Àr en konferens som inte riktar sig till DevOps-ingenjörer!
Bild frĂ„n i MĂŒnchen
DevOops 2020 Moskau kommer att Àga rum den 29-30 april i Moskva, biljetter kan redan .
Dessutom kan du senast den 8 februari. Observera att du vid ifyllandet av formulÀret mÄste vÀlja den mÄlgrupp som din förelÀsning kommer att vara mest fördelaktig för (inuti listan döljer sig en överraskning).
KĂ€lla: habr.com
