Temat DevOps har blivit vÀldigt populÀr under de senaste Ären. MÄnga drömmer om att bli en del av det, men som erfarenheten visar, Àr det ofta bara pÄ grund av lönenivÄerna.
Vissa anger DevOps i sina CV:n, Àven om de inte alltid vet och förstÄr vad termen innebÀr. NÄgon anser att genom att lÀra sig Ansible, GitLab, Jenkins, Terraform och liknande (listan kan fortsÀtta efter eget tycke), sÄ blir man automatiskt en "DevOps-ingenjör". Det Àr sjÀlvklart inte sÄ.
De senaste Ären har jag frÀmst arbetat med att införa DevOps i olika företag. Tidigare har jag arbetat i över 20 Är pÄ positioner frÄn systemadministratör till IT-chef. Nu Àr jag DevOps Lead Engineer pÄ Playgendary.
Vem Àr DevOps?
Idén att skriva en artikel uppkom efter Ànnu en frÄga: "Vem Àr DevOps?". Det finns fortfarande ingen etablerad term för vad eller vem detta Àr. En del svar finns redan i detta. . Först kommer jag att framhÀva huvudpunkterna frÄn den, och sedan dela mina egna observationer och tankar.
DevOps Àr inte en specialist som du kan anstÀlla, inte en uppsÀttning verktyg, och inte en avdelning med utvecklare och ingenjörer.
DevOps Àr en filosofi och metodologi.
Med andra ord, det Àr en uppsÀttning metoder som hjÀlper utvecklare att aktivt interagera med systemadministratörer. Det vill sÀga att knyta ihop och integrera arbetsflöden med varandra.
Med framvÀxten av DevOps förblev strukturen och rollerna för specialister de samma (det finns utvecklare, det finns ingenjörer), men reglerna för interaktion förÀndrades. GrÀnserna mellan avdelningarna suddades ut.
MÄlen för DevOps kan beskrivas med tre punkter:
- Mjukvaran bör uppdateras regelbundet.
- Mjukvaran bör utvecklas snabbt.
- Mjukvaran bör kunna implementeras bekvÀmt och snabbt.
DevOps har inget ensamt verktyg. Att installera, konfigurera och lÀra sig flera produkter betyder inte att företaget har en DevOps. Det finns mÄnga verktyg och de anvÀnds i olika stadier, men tjÀnar ett gemensamt syfte.
Och detta Àr bara en del av DevOps-verktygen.
Jag har intervjuat mÀnniskor för positionen som DevOps-ingenjör i över 2 Är och jag har kommit till insikten om hur viktigt det Àr att tydligt förstÄ innebörden av termen. Specifik erfarenhet, observationer och tankar har samlats, som jag vill dela med mig av.
UtifrÄn mina erfarenheter av intervjuer ser jag följande bild: den som anser att DevOps Àr en tjÀnst har vanligtvis missförstÄnd med kollegor..
Det var ett tydligt exempel. En ung man kom till intervjun med en massa kloka ord i sitt CV. Vid de senaste tre arbetsplatserna hade han en anstĂ€llning pĂ„ 5-6 mĂ„nader. Han lĂ€mnade tvĂ„ startups eftersom de "inte lyfte". Och nĂ€r det gĂ€llde det tredje företaget sa han att ingen förstod honom: utvecklarna skrev kod i Windows, och chefen tvingade honom att "slĂ„ in" den koden i vanlig Docker och integrera den i CI/CD-pipelinen. Killen berĂ€ttade mycket negativt om sin nuvarande arbetsplats och sina kollegor â man ville nĂ€stan svara: "SĂ„ du kan inte sĂ€lja elefanten".
Sen stÀllde jag honom en frÄga som Àr en av de första pÄ min lista för varje kandidat.
â Vad betyder DevOps för dig personligen?
â AllmĂ€nt eller hur uppfattar jag det?
Jag var intresserad av hans personliga Äsikt. Han kÀnde till teorin och ursprunget till termen, men han var kategoriskt oenig med dem. Han ansÄg att DevOps Àr en tjÀnst. HÀr ligger roten till hans problem. Som hos andra specialister med samma Äsikt.
Arbetsgivare, som har lyssnat pÄ "DevOps-magi", vill hitta en person som kommer och skapar denna "magi". Och sökande som tillhör kategorin "DevOps Àr en tjÀnst" förstÄr inte att de med det tillvÀgagÄngssÀttet inte kommer kunna leva upp till förvÀntningarna. Och överhuvudtaget skrev de i sitt CV att de Àr DevOps, eftersom det Àr en trend och de betalar bra för det.
Metodologi och filosofi för DevOps
Metodologin kan vara teoretisk eller praktisk. I vÄrt fall Àr det det andra. Som jag nÀmnde tidigare Àr DevOps en uppsÀttning praktiker och strategier som tillÀmpas för att nÄ angivna mÄl. Och i varje fall, beroende pÄ företagets affÀrsprocesser, kan det skilja sig avsevÀrt. Vilket inte gör det bÀttre eller sÀmre.
DevOps-metodologin Àr bara ett verktyg för att uppnÄ de uppsatta mÄlen.
Nu till vad filosofin för DevOps innebÀr. Och det hÀr Àr nog den svÄraste frÄgan.
Att formulera ett kort och koncist svar Ă€r ganska svĂ„rt eftersom det Ă€nnu inte Ă€r formaliserat. Eftersom anhĂ€ngare av DevOps-filosofin mer sysslar med praktiken â finns det helt enkelt ingen tid för filosofiska diskussioner. ĂndĂ„ Ă€r det en mycket viktig process. Dessutom direkt relaterad till ingenjörsarbete. Det finns till och med ett specialiserat kunskapsomrĂ„de â .
PĂ„ mitt universitet fanns det inte ett sĂ„dant Ă€mne, sĂ„ jag fick studera allt sjĂ€lv med de material jag kunde hitta pĂ„ 90-talet. Ămnet Ă€r inte obligatoriskt för ingenjörsutbildningar, vilket förklarar bristen pĂ„ en formaliserad respons. Men de mĂ€nniskor som pĂ„ allvar har fördjupat sig i DevOps börjar kĂ€nna en viss "ande" eller "omedveten allomfattandehet" av alla processer inom företaget.
UtifrÄn min erfarenhet har jag försökt att formaliserar vissa "postulat" av denna filosofi. Resultatet Àr följande:
- DevOps Àr inte nÄgot sjÀlvstÀndigt som kan sÀrskiljas som ett eget kunskapsomrÄde eller verksamhet.
- Alla anstÀllda i företaget bör följa DevOps-metodologin nÀr de planerar sin verksamhet.
- DevOps berör alla processer inom företaget.
- DevOps finns för att minska tidskostnaderna för alla processer inom företaget för att sÀkerstÀlla utvecklingen av dess tjÀnster och maximalt kundnöjdhet.
- DevOps, pÄ modernt sprÄk, handlar om en proaktiv hÄllning frÄn varje anstÀlld i företaget som syftar till att minska tidsförluster och förbÀttra kvaliteten pÄ de IT-produkter som omger oss.
Jag tror att mina "postulat" Àr ett eget Àmne för diskussion. Men nu finns det nÄgot att utgÄ ifrÄn.
Vad gör DevOps
Nyckelordet hÀr Àr kommunikation. Det finns mycket kommunikation dÀr initiativtagaren just ska vara den specifika DevOps-ingenjören. Varför Àr det sÄ? DÀrför att det handlar om en filosofi och metodologi, och först dÀrefter teknisk kunskap.
Jag kan inte tala med 100% sÀkerhet om den vÀsterlÀndska arbetsmarknaden. Men jag vet ganska mycket om DevOps-marknaden i Ryssland. Förutom hundratals intervjuer har jag under de senaste 1,5 Ären deltagit i hundra tekniska presales inom tjÀnsten "Implementering av DevOps" för stora ryska företag och banker.
I Sverige Àr DevOps fortfarande ett ungt men snabbt vÀxande Àmne. Enligt vad jag vet har bristen pÄ sÄdana specialister i Stockholm under 2019 överstigit 1000 personer. Ordet Kubernetes Àr nÀstan som en röd duk för arbetsgivare. AnhÀngare av detta verktyg Àr redo att anvÀnda det Àven dÀr det inte behövs och inte Àr ekonomiskt lönsamt. Arbetsgivaren förstÄr inte alltid i vilka fall det Àr mer lÀmpligt att anvÀnda det, och med rÀtt implementering kan kostnaden för en Kubernetes-klusterinstallation vara 2-3 gÄnger högre Àn för att distribuera en applikation enligt en vanlig klustermodell. AnvÀnd det dÀr det verkligen behövs.
Implementeringen av DevOps sett ur ekonomiskt perspektiv Àr dyrt. Det Àr berÀttigat endast dÀr det ger ekonomiska fördelar i andra omrÄden, snarare Àn för sin egen skull.
DevOps-ingenjörer Ă€r faktiskt pionjĂ€rer â det Ă€r de som först bör implementera denna metodik i företaget och bygga upp processerna. För att detta ska vara framgĂ„ngsrikt mĂ„ste specialisten stĂ€ndigt interagera med anstĂ€llda och kollegor pĂ„ alla nivĂ„er. Som jag brukar sĂ€ga, alla anstĂ€llda i företaget mĂ„ste involveras i DevOps-implementeringen: frĂ„n stĂ€derskan till CEO. Det Ă€r ett absolut krav. Om den yngsta medlemmen i teamet inte vet och förstĂ„r vad DevOps Ă€r och varför vissa organisatoriska Ă„tgĂ€rder vidtas, kommer en framgĂ„ngsrik implementering inte att vara möjlig.
Dessutom mĂ„ste DevOps-ingenjören dĂ„ och dĂ„ anvĂ€nda administrativt stöd. Till exempel för att övervinna "omgivningens motstĂ„nd" â nĂ€r teamet inte Ă€r redo att acceptera DevOps-verktyg och metodik.
Utvecklaren ska bara skriva kod och tester. För detta behöver han ingen superkraftig laptop som han ska anvÀnda för att distribuera och underhÄlla hela projektets infrastruktur lokalt. Till exempel har frontend-utvecklaren alla applikationens komponenter pÄ sin laptop, inklusive databasen, S3-emulatorn (minio) och mer. Det innebÀr att han lÀgger mycket tid pÄ att underhÄlla denna lokala infrastruktur och kÀmpar ensam med alla problem som detta medför. IstÀllet för att utveckla kod för framsidan. SÄdana personer kan motstÄ alla förÀndringar kraftigt.
Men det finns team som istĂ€llet Ă€r glada över att införliva nya verktyg och metoder, och aktivt deltar i denna process. Ăven i sĂ„dana fall Ă€r kommunikationen mellan DevOps-ingenjören och teamet oavbruten.
NÀr DevOps inte behövs
Det finns situationer nĂ€r DevOps inte behövs. Detta Ă€r ett faktum â det Ă€r nĂ„got som mĂ„ste förstĂ„s och accepteras.
Först och frÀmst handlar detta om alla företag (sÀrskilt smÄföretag) vars intÀkter inte direkt beror pÄ förekomsten eller frÄnvaron av IT-produkter som tillhandahÄller informationsservice till kunder.
DevOps Àr nödvÀndigt nÀr tillgÄngen till dessa informationsservicer för interaktion med kunden, deras kvalitet och mÄlinriktning pÄverkar kundnöjdheten och viljan att ÄtervÀnda.
Ett tydligt exempel Àr en vÀlkÀnd bank. Företaget har inga traditionella kundkontor, dokumenthanteringen sker via post eller bud, och mÄnga anstÀllda arbetar hemifrÄn. Företaget har slutat vara en vanlig bank och har, enligt min mening, blivit ett IT-företag med avancerad DevOps-teknologi.
MĂ„nga andra exempel och förelĂ€sningar kan hittas i inspelningar av tematiska meetups och konferenser. Jag har personligen besökt nĂ„gra av dem â det Ă€r en mycket nyttig erfarenhet för dem som vill utvecklas inom detta omrĂ„de. HĂ€r Ă€r lĂ€nkar till YouTube-kanaler med bra förelĂ€sningar och material om DevOps:
Titta nu pÄ ditt företag och fundera pÄ följande: hur mycket beror ditt företag och dess intÀkter pÄ IT-produkter som möjliggör kundinteraktion?
Om ditt företag handlar med fisk i en liten butik och den enda IT-produkten Àr tvÄ konfigurationer av 1C: Enterprise (Bokföring och UNF), sÄ Àr det knappt meningsfullt att tala om DevOps.
Om du dÀremot arbetar pÄ ett stort handels- och tillverkningsföretag (till exempel tillverkar jaktriflar), sÄ bör du fundera. Du kan ta initiativet och förmedla till din ledning perspektiven för att införa DevOps. Och samtidigt leda denna process. En proaktiv attityd Àr en av de viktiga postulaten i DevOps-filosofin.
Storleken och volymen av den Ärliga finansiella omsÀttningen Àr inte det primÀra kriteriet för att avgöra om ditt företag behöver DevOps.
TÀnk dig ett stort industriföretag som inte direkt interagerar med kunder. Till exempel, vissa biltillverkare och bilproduktionsföretag. Jag Àr inte sÀker nu, men utifrÄn min tidigare erfarenhet skedde all kundinteraktion under mÄnga Är via e-post och telefon.
Deras kunder Àr en begrÀnsad lista av bilÄterförsÀljare. Och till varje ÄterförsÀljare Àr en specialist frÄn tillverkaren kopplad. All intern dokumenthantering sker genom ERP SAP. De interna anstÀllda Àr i sjÀlva verket kunder av informationssystemet. Men hanteringen av detta system sker med klassiska verktyg för att hantera klustersystem. Vilket utesluter möjligheten att anvÀnda DevOps-praktiker.
DÀrför drar vi slutsatsen: för sÄdana företag Àr införandet av DevOps inte kritiskt viktigt, om vi minns metodologins mÄl frÄn början av artikeln. Men jag utesluter inte att vissa verktyg för DevOps anvÀnds av dem idag.
à andra sidan finns det mÄnga smÄ företag som utvecklar programvara med hjÀlp av metodiken, filosofin, praktikerna och verktygen för DevOps. Och de anser att kostnaderna för att implementera DevOps Àr utgifter som gör att de kan konkurrera effektivt pÄ mjukvarumarknaden. Exempel pÄ sÄdana företag kan ses. .
Det viktigaste kriteriet för att förstÄ om DevOps behövs: vilken betydelse har dina IT-produkter för företaget och kunderna.
Om företagets huvudsakliga produkt, som genererar intĂ€kter, Ă€r programvara â dĂ„ behöver du DevOps. Och det spelar ingen roll om du tjĂ€nar pengar genom andra produkter. Detta gĂ€ller Ă€ven e-handelsbutiker eller mobilapplikationer med spel.
Alla spel existerar tack vare finansiering: direkt eller indirekt frÄn spelarna. PÄ Playgendary utvecklar vi gratis mobilspel, dÀr mer Àn 200 personer Àr direkt involverade i skapandet. Hur anvÀnder vi DevOps?
Precis som beskrivits ovan. Jag kommunicerar stÀndigt med utvecklare och testare, och genomför intern utbildning av anstÀllda i metodologi och verktyg för DevOps.
Just nu anvĂ€nder vi Jenkins aktivt som ett verktyg för CI/CD pipelines för att utföra alla byggkonfigurationer med Unity och för att sedan distribuera till App Store och Play Market. Ăven i den klassiska verktygssatsen:
- Asana â för projektledning. Integration med Jenkins Ă€r instĂ€lld.
- Google Meet â för videomöten.
- Slack â för kommunikation och olika aviseringar, inklusive meddelanden frĂ„n Jenkins.
- Atlassian Confluence â för dokumentation och samarbete.
De kommande planerna innefattar att införa statisk kodanalys med SonarQube och att genomföra automatiserad UI-testning med hjÀlp av Selenium i steget för Continuous Integration.
Avslutande
Jag vill avsluta med denna tanke: för att bli en högkvalificerad DevOps-ingenjör Àr det avgörande att lÀra sig att kommunicera effektivt med mÀnniskor.
DevOps-ingenjören Àr en lagspelare. Inget annat. Initiativet i kommunikationen med kollegor bör komma frÄn honom eller henne sjÀlv, snarare Àn som en följd av omstÀndigheterna. DevOps-specialisten mÄste se och föreslÄ den bÀsta lösningen för teamet.
Och ja, införandet av vilken lösning som helst kommer att krĂ€va mĂ„nga diskussioner, och till slut kan det förĂ€ndras helt. Genom att sjĂ€lvstĂ€ndigt utvecklas, föreslĂ„ och genomföra sina idĂ©er â sĂ„ blir en sĂ„dan person allt mer vĂ€rdefull för bĂ„de teamet och arbetsgivaren. Detta Ă„terspeglas i slutĂ€ndan ocksĂ„ i storleken pĂ„ den mĂ„natliga ersĂ€ttningen eller i form av ytterligare bonusar.
KĂ€lla: habr.com
