DevOps har blivit ett mycket populärt ämne under de senaste åren. Många människor drömmer om att gå med, men, som praxis visar, ofta bara på grund av lönenivån.
Vissa människor listar DevOps på sitt CV, även om de inte alltid känner till eller förstår essensen av termen. Vissa tror att efter att ha studerat Ansible, GitLab, Jenkins, Terraform och liknande (listan kan fortsätta enligt din smak) kommer du omedelbart att bli en "devopsist". Detta är naturligtvis inte sant.
De senaste åren har jag främst varit involverad i implementeringen av DevOps i olika företag. Dessförinnan arbetade han i mer än 20 år i positioner från systemadministratör till IT-direktör. För närvarande DevOps Lead Engineer på Playgendary.
Vem är DevOps
Idén att skriva en artikel uppstod efter en annan fråga: "vem är DevOps?" Det finns fortfarande ingen etablerad term för vad eller vem det är. Några av svaren finns redan i detta . Först kommer jag att lyfta fram huvudpunkterna från den, och sedan kommer jag att dela med mig av mina observationer och tankar.
DevOps är inte en specialist som kan anlitas, inte en uppsättning verktyg, och inte en avdelning med utvecklare med ingenjörer.
DevOps är en filosofi och metodik.
Med andra ord är det en uppsättning metoder som hjälper utvecklare att aktivt interagera med systemadministratörer. Det vill säga att koppla ihop och integrera arbetsprocesser i varandra.
Med tillkomsten av DevOps förblev strukturen och rollerna för specialister desamma (det finns utvecklare, det finns ingenjörer), men reglerna för interaktion har förändrats. Gränserna mellan avdelningarna har suddats ut.
Målen för DevOps kan beskrivas i tre punkter:
- Programvaran måste uppdateras regelbundet.
- Programvara måste göras snabbt.
- Programvaran bör distribueras bekvämt och på kort tid.
Det finns inget enskilt verktyg för DevOps. Att konfigurera, leverera och studera flera produkter betyder inte att DevOps har dykt upp i företaget. Det finns många verktyg och de används alla i olika skeden, 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 mer än två år nu, och jag har insett hur viktigt det är att tydligt förstå essensen av termen. Jag har samlat på mig specifika erfarenheter, observationer och tankar som jag vill dela med mig av.
Av intervjuerfarenhet ser jag följande bild: specialister som anser att DevOps är en jobbtitel har vanligtvis missförstånd med kollegor.
Det fanns ett slående exempel. En ung man kom till en intervju med många smarta ord på sitt CV. På sina tre senaste jobb hade han 5-6 månaders erfarenhet. Jag lämnade två startups eftersom de "inte tog fart." Men om det tredje företaget sa han att ingen förstår honom där: utvecklarna skriver kod på Windows, och regissören tvingar denna kod att "lindas in" i vanlig Docker och byggas in i CI/CD-pipelinen. Killen sa många negativa saker om sin nuvarande arbetsplats och sina kollegor - jag ville bara svara: "Så du kommer inte sälja en elefant."
Sedan ställde jag en fråga till honom som står högt på min lista för varje kandidat.
— Vad betyder DevOps för dig personligen?
– Generellt eller hur uppfattar jag det?
Jag var intresserad av hans personliga åsikt. Han kände till teorin och ursprunget till termen, men han höll starkt med dem. Han trodde att DevOps var en jobbtitel. Det är här roten till hans problem ligger. Samt andra specialister med samma åsikt.
Arbetsgivare, som har hört mycket om "magin med DevOps", vill hitta en person som kommer och skapar denna "magi". Och sökande från kategorin "DevOps är ett jobb" förstår inte att de med detta tillvägagångssätt inte kommer att kunna uppfylla förväntningarna. Och i allmänhet skrev de DevOps på sitt CV eftersom det är en trend och de betalar mycket för det.
DevOps metodik och filosofi
Metodiken kan vara teoretisk och praktisk. I vårt fall är det den andra. Som jag nämnde ovan är DevOps en uppsättning metoder och strategier som används för att uppnå uttalade mål. Och i varje enskilt fall, beroende på företagets affärsprocesser, kan det skilja sig betydligt. Vilket inte gör det bättre eller sämre.
DevOps-metoden är bara ett sätt att uppnå mål.
Nu om vad DevOps-filosofin är. Och det här är nog den svåraste frågan.
Det är ganska svårt att formulera ett kort och koncist svar, eftersom det ännu inte har formaliserats. Och eftersom anhängare av DevOps-filosofin är mer engagerade i praktiken finns det helt enkelt ingen tid för filosofering. Detta är dock en mycket viktig process. Dessutom är det direkt relaterat till ingenjörsverksamhet. Det finns till och med ett specialiserat kunskapsområde - .
Det fanns inget sådant ämne på mitt universitet, jag var tvungen att studera allt på egen hand med det material jag kunde hitta på 90-talet. Ämnet är valfritt för ingenjörsutbildning, därav bristen på formalisering av svaret. Men de människor som på allvar är fördjupade i DevOps börjar känna en viss "anda" eller "omedveten helhet" av alla företagets processer.
Med min egen erfarenhet försökte jag formalisera några av "postulaten" i denna filosofi. Resultatet är följande:
- DevOps är inte något oberoende som kan separeras i ett separat område av kunskap eller aktivitet.
- Alla företagsanställda bör vägledas av DevOps-metoden när de planerar sina aktiviteter.
- DevOps påverkar alla processer inom ett företag.
- DevOps finns för att minska tidskostnaderna för alla processer inom ett företag för att säkerställa utvecklingen av dess tjänster och maximal kundkomfort.
- DevOps, på modernt språk, är den proaktiva positionen för varje anställd i företaget, som syftar till att minska tidskostnaderna och förbättra kvaliteten på IT-produkterna runt omkring oss.
Jag tror att mina "postulat" är ett separat ämne för diskussion. Men nu finns det något att bygga vidare på.
Vad DevOps gör
Nyckelordet här är kommunikation. Det finns en hel del kommunikation, vars initiativtagare borde vara exakt samma DevOps-ingenjör. Varför är det så? För det här är filosofi och metodik, och först då ingenjörskunskap.
Jag kan inte tala med 100% tillförsikt om den västerländska arbetsmarknaden. Men jag vet ganska mycket om DevOps-marknaden i Ryssland. Förutom hundratals intervjuer har jag under det senaste och ett halvt året deltagit i hundratals tekniska förköp för tjänsten "Implementation of DevOps" för stora ryska företag och banker.
I Ryssland är DevOps fortfarande ett mycket ungt, men redan trendigt ämne. Så vitt jag vet var bristen på sådana specialister enbart i Moskva 2019 mer än 1000 2 personer. Och ordet Kubernetes för arbetsgivare är nästan som en röd trasa för en tjur. Anhängare av detta verktyg är redo att använda det även där det inte är nödvändigt och ekonomiskt lönsamt. Arbetsgivaren förstår inte alltid i vilka fall vad som är mer lämpligt att använda, och med korrekt distribution kostar underhållet av ett Kubernetes-kluster 3-XNUMX gånger mer än att distribuera en applikation med ett konventionellt klusterschema. Använd den där du verkligen behöver den.
Att implementera DevOps är dyrt i form av pengar. Och det är bara motiverat där det ger ekonomiska fördelar på andra områden, och inte på egen hand.
DevOps-ingenjörer är i själva verket pionjärer – det är de som borde vara först med att implementera denna metodik i företaget och bygga processer. För att detta ska bli framgångsrikt måste specialisten ständigt interagera med medarbetare och kollegor på alla nivåer. Som jag brukar säga bör alla företagsanställda vara involverade i DevOps implementeringsprocessen: från städerskan till VD:n. Och detta är en förutsättning. Om den mest juniora medlemmen i teamet inte vet och förstår vad DevOps är och varför vissa organisatoriska åtgärder utförs, kommer framgångsrik implementering inte att fungera.
En DevOps-ingenjör behöver också använda en administrativ resurs då och då. Till exempel för att övervinna "miljömotstånd" - när teamet inte är redo att acceptera DevOps-verktyg och metodik.
Utvecklaren ska bara skriva kod och tester. För att göra detta behöver han inte en superkraftig bärbar dator på vilken han kommer att distribuera och lokalt stödja hela projektets infrastruktur. Till exempel behåller en frontend-utvecklare alla delar av applikationen på sin bärbara dator, inklusive databasen, S3-emulatorn (minio), etc. Det vill säga att han lägger ner mycket tid på att underhålla den här lokala infrastrukturen och på egen hand kämpar med alla problem med en sådan lösning. Istället för att utveckla kod för fronten. Sådana människor kan vara mycket motståndskraftiga mot alla förändringar.
Men det finns team som tvärtom gärna introducerar nya verktyg och metoder, och som aktivt deltar i denna process. Även i det här fallet avbröts inte kommunikationen mellan DevOps-ingenjören och teamet.
När DevOps inte behövs
Det finns situationer när DevOps inte behövs. Detta är ett faktum - det måste förstås och accepteras.
Först och främst gäller detta alla företag (särskilt småföretag), när deras vinst inte direkt beror på närvaron eller frånvaron av IT-produkter som tillhandahåller informationstjänster till kunder. Och här pratar vi inte om företagets webbplats, vare sig det är ett statiskt "visitkort" eller med dynamiska nyhetsblock etc.
DevOps krävs när din kunds tillfredsställelse och hans önskan att återvända till dig igen beror på tillgången på dessa informationstjänster för interaktion med kunden, deras kvalitet och inriktning.
Ett slående exempel är en välkänd bank. Företaget har inga traditionella kundkontor, dokumentflödet sker via post eller bud och många anställda arbetar hemifrån. Företaget har upphört att bara vara en bank och har enligt min mening förvandlats till ett IT-företag med utvecklade DevOps-teknologier.
Många andra exempel och föreläsningar finns i inspelningar av tematiska möten och konferenser. Jag besökte några av dem personligen - det här är en mycket användbar erfarenhet för dem som vill utvecklas i den här riktningen. Här är länkar till YouTube-kanaler med bra föreläsningar och material om DevOps:
Titta nu på din verksamhet och fundera över detta: Hur mycket beror ditt företag och dess vinster på IT-produkter för att möjliggöra kundinteraktion?
Om ditt företag säljer fisk i en liten butik och den enda IT-produkten är två 1C: Enterprise-konfigurationer (Accounting och UNF), så är det knappast vettigt att prata om DevOps.
Om du arbetar på ett stort handels- och tillverkningsföretag (till exempel producerar du jaktgevär), bör du tänka på det. Du kan ta initiativ och förmedla till din ledning möjligheterna att implementera DevOps. Tja, och samtidigt leda denna process. En proaktiv position är en av de viktiga grundsatserna i DevOps-filosofin.
Storleken och volymen på den årliga finansiella omsättningen är inte huvudkriteriet för att avgöra om ditt företag behöver DevOps.
Låt oss föreställa oss ett stort industriföretag som inte interagerar direkt med kunderna. Till exempel vissa biltillverkare och biltillverkningsföretag. Jag är inte säker nu, men från min tidigare erfarenhet har all kundinteraktion under många år skett via e-post och telefon.
Deras kunder är en begränsad lista över bilhandlare. Och var och en tilldelas en specialist från tillverkaren. Allt internt dokumentflöde sker genom SAP ERP. Interna anställda är i huvudsak kunder till informationssystemet. Men denna IS styrs av klassiska sätt att hantera klustersystem. Vilket utesluter möjligheten att använda DevOps-praxis.
Därav slutsatsen: för sådana företag är implementeringen av DevOps inte något kritiskt viktigt, om vi minns målen för metodiken från början av artikeln. Men jag utesluter inte att de använder vissa DevOps-verktyg idag.
Å andra sidan finns det många små företag som utvecklar mjukvara med hjälp av DevOps metodik, filosofi, praxis och verktyg. Och de tror att kostnaden för att implementera DevOps är kostnaden som gör att de kan konkurrera effektivt på mjukvarumarknaden. Exempel på sådana företag kan ses .
Huvudkriteriet för att förstå om DevOps behövs: vilket värde dina IT-produkter har för företaget och kunderna.
Om företagets huvudprodukt som genererar vinst är mjukvara behöver du DevOps. Och det är inte så viktigt om du tjänar riktiga pengar med andra produkter. Detta inkluderar även nätbutiker eller mobilapplikationer med spel.
Alla spel existerar tack vare finansiering: direkt eller indirekt från spelarna. På Playgendary utvecklar vi gratis mobilspel med över 200 personer direkt involverade i deras skapande. Hur använder vi DevOps?
Ja, exakt samma som beskrivits ovan. Jag kommunicerar ständigt med utvecklare och testare, och genomför intern utbildning för anställda om DevOps metodik och verktyg.
Vi använder nu aktivt Jenkins som ett CI/CD-pipelinesverktyg för att exekvera alla monteringspipelines med Unity och efterföljande distribution till App Store och Play Market. Mer från den klassiska verktygslådan:
- Asana - för projektledning. Integration med Jenkins har konfigurerats.
- Google Meet – för videomöten.
- Slack - för kommunikation och olika varningar, inklusive aviseringar från Jenkins.
- Atlassian Confluence - för dokumentation och grupparbete.
Våra omedelbara planer inkluderar att introducera statisk kodanalys med SonarQube och att utföra automatiserade UI-tester med Selen i det kontinuerliga integrationsstadiet.
I stället för en slutsats
Jag skulle vilja avsluta med följande tanke: för att bli en högt kvalificerad DevOps-ingenjör är det viktigt att lära sig hur man kommunicerar live med människor.
En DevOps-ingenjör är en lagspelare. Och ingenting annat. Initiativet till att kommunicera med kollegor bör komma från honom och inte under påverkan av vissa omständigheter. En DevOps-specialist måste se och föreslå den bästa lösningen för teamet.
Och ja, implementeringen av vilken lösning som helst kommer att kräva mycket diskussion, och i slutet kan den förändras helt. Att utveckla självständigt, föreslå och genomföra sina idéer, en sådan person är av ökande värde både för teamet och för arbetsgivaren. Vilket i slutändan återspeglas i storleken på hans månatliga ersättning eller i form av ytterligare bonusar.
Källa: will.com