Vad är DevOps?

För tillfället är detta nästan den dyraste positionen på marknaden. Hysterin kring "DevOps"-ingenjörer överstiger alla föreställningar, och det värre med Senior DevOps-ingenjörer.
Jag arbetar som chef för integrations- och automatiseringsavdelningen, gissa den engelska förkortningen — DevOps Manager. Speglar den engelska förkortningen verkligen vår vardagliga verksamhet — knappast, men den ryska varianten är i detta fall mer exakt. I min roll är det naturligtvis nödvändigt för mig att intervjua framtida medlemmar av mitt team, och under det gångna året har jag mött cirka 50 personer, och lika många har sorterat bort under prescreening med mina anställda.

Vi är fortfarande på jakt efter kollegor, eftersom det bakom etiketten DevOps döljer sig en mycket stor grupp av olika typer av ingenjörer.

Allt som står nedan är min personliga åsikt, ni behöver inte hålla med, men jag tillåter mig att tro att det kan färga er uppfattning om ämnet. Trots risken att hamna i ogynnsam dager publicerar jag min åsikt, eftersom jag anser att den har sin plats.

Företag har olika uppfattningar om vem DevOps-ingenjörer är och för att snabbt rekrytera resurser sätter de den etiketten på alla. Situationen är ganska märklig, eftersom företagen är villiga att betala osannolika belöningar till dessa personer, men i de flesta fall får de en administratör-verktygsspecialist.

Så vem är egentligen DevOps-ingenjörer?

Låt oss börja med historien om utvecklingen av Development Operations — det kom som ett steg mot att optimera samarbetet i små team för att öka produktionshastigheten, som en förväntad följd. Idén var att förstärka utvecklingsteamet med kunskap om procedurer och metoder för att hantera produktmiljöer. Med andra ord borde en utvecklare förstå och veta hur deras produkt fungerar under olika förhållanden, förstå hur man distribuerar sin produkt, vilka egenskaper i miljön som ska justeras för att öka prestandan. Så, under en tid, dök det upp utvecklare med DevOps-ansats. DevOps-utvecklare skrev skript för byggande och paketering för att förenkla sitt arbete och funktionaliteten i produktionsmiljön. Men med tiden började komplexiteten i lösningarnas arkitektur och det ömsesidiga inflytandet av infrastrukturkomponenter försämra arbetsresultaten; med varje iteration krävdes en djupare förståelse av olika komponenter, vilket minskade utvecklarens produktivitet på grund av den extra tiden som behövdes för att förstå komponenterna och finjustera systemen för specifika uppgifter. Utvecklarens egen kostnad ökade, kostnaden för produkten steg också, och kraven på nya utvecklare i teamet sköt i höjden, eftersom de också behövde täcka ansvaret för "stjärnorna" i utvecklingen, och naturligtvis blev "stjärnorna" allt mindre tillgängliga. Det är också värt att notera att, enligt min erfarenhet, är få utvecklare intresserade av specifikationer för hur paket behandlas av operativsystemets kärna, regler för paket-routing, och aspekter av värd-säkerhet. Det logiska steget blev att involvera en administratör, som är bekant med dessa frågor, och ålägga ansvar av det här formatet på honom; tack vare hans erfarenhet kunde samma resultat uppnås till en lägre kostnad jämfört med "stjärnans" kostnad i utvecklingen. Dessa administratörer placerades i teamet, och deras huvudsakliga uppgift var att hantera test- och produktionsmiljöer, baserat på reglerna för just det teamet, med resurser avdelade för just detta team. Så, i grund och botten, kom DevOps till de flestas uppfattning.

Delvis eller helt, med tiden har dessa systemadministratörer börjat förstå behoven hos just detta specifika team inom utveckling, hur man underlättar livet för utvecklare och testare, hur man rullar ut en uppdatering utan att behöva spendera natten på kontoret på fredag för att åtgärda deploy-fel. Tiden gick, nu blev systemadministratörerna "stjärnor" som förstod vad utvecklarna ville ha. För att minimera effekten började verktyg för hantering dyka upp, alla kom ihåg gamla och pålitliga metoder för OS-isolering som kunde minimera säkerhetskraven, hanteringen av nätverksdelen och även konfigurationen av värden i stort, vilket i sin tur minskade kraven på de nya "stjärnorna".

En "fantastisk" sak dök upp - docker. Varför fantastisk? Endast för att skapa isolering i chroot eller jail, liksom OpenVZ, krävde icke-triviala kunskaper om OS, medan det i kontrast med verktyget, som enkelt möjliggör skapandet av en isolerad applikationsmiljö på en värd med allt nödvändigt inuti, och åter överlämna styrningen till utvecklingen, medan systemadministratören bara behövde hantera en värd och säkerställa dess säkerhet och höga tillgänglighet - en logisk förenkling. Men framsteg står inte still, och systemen blir återigen allt mer komplexa, komponenterna ökar i antal, en enda värd räcker inte längre för systemets behov och det är nödvändigt att bygga kluster, vi återvänder till systemadministratörerna som är kapabla att bygga dessa system.

Cykel efter cykel dyker olika system upp som förenklar utveckling och/eller administration, det dyker upp orkestreringssystem som, tills det behövs avvika från standardprocessen, är enkla att använda. Mikrotjänstarkitektur har också dykt upp med syftet att förenkla allt ovanstående - färre relationer, lättare att hantera. I min erfarenhet har jag inte sett en helt mikrotjänstarkitektur, jag skulle säga 50-50 - 50 procent mikrotjänster, svarta lådor, vad som kom in, kom ut bearbetat, andra 50 - en sönderdelad monolit, tjänster oförmögna att fungera oberoende av andra komponenter. Allt detta har återigen infört begränsningar på kunskapsnivån både hos utvecklarna och administratörerna.

Liknande expertkunskaper på olika resurser fortsätter än idag. Men vi har kommit lite off-topic, det finns flera aspekter som förtjänar att belysas.

Byggingenjör/Release Engineer

Dessa mycket specialiserade ingenjörer uppstod som ett sätt att standardisera processerna för mjukvarubyggnation och dess releaser. I och med införandet av den allmäldiga Agile-metodiken tycktes de ha förlorat sin relevans, men så är verkligen inte fallet. Detta yrke har blivit till för att standardisera just byggnation och leverans av mjukvara i stor skala, det vill säga att använda standardiserade tekniker för alla företagets produkter. Med införandet av DevOps har utvecklarna delvis tagit över funktionerna, eftersom det just är utvecklarna som förbereder produkten för leverans, och med den föränderliga infrastrukturen och tillvägagångssättet för att leverera så snabbt som möjligt utan att tänka på kvalitet, har de över tid blivit ett hinder för förändringar, eftersom att följa kvalitetsstandarder ofrånkomligen saktar ner leveranserna. Således har gradvis delar av Build/Release-ingenjörernas funktioner övergått till systemadministratörer.

Ops: så olika

Vi går vidare och återigen driver en stor uppsättning ansvarsområden och bristen på kvalificerad personal oss mot en sträng specialisering. Som svampar efter regn dyker det upp olika Operations:

• TechOps — systemadministratörer som servicepersonal aka HelpDesk Engineer
• LiveOps — systemadministratörer, som huvudsakligen ansvarar för produktionsmiljöer
• CloudOps — systemadministratörer som specialiserar sig på offentliga "moln" som Azure, AWS, GCP, etc.
• PlatOps/InfraOps/SysOps — systemadministratörer för infrastruktur.
• NetOps — nätverksadministratörer
• SecOps — systemadministratörer som specialiserar sig på informationssäkerhet — PCI compliance, CIS compliance, patchning, etc.

DevOps — en (teori) person som verkligen förstår hela utvecklingscykeln — utveckling, testning, som förstår produktens arkitektur, kan bedöma säkerhetsrisker, och som är bekant med metoder och verktyg för automatisering, åtminstone på en hög nivå, samt som även förstår både pre- och post-release support av produkten. En person som kan agera som advokat för både Operations och Development, vilket möjliggör ett fördelaktigt samarbete mellan dessa två pelare. Förstår processerna för arbetsplanering av team och hantering av kundförväntningar.

För att utföra sådana typer av arbete och skyldigheter bör denna person ha verktyg för att hantera inte bara utvecklings- och testprocesser, utan även produkternas infrastruktur och planering av resurser. DevOps i denna mening kan inte hänföras till IT, R&D eller ens PMO, han bör ha inflytande inom alla dessa områden — teknisk direktör för företaget, Chief Technical Officer.

Är det så i ert företag? — Jag tvivlar. I de flesta fall är det antingen IT eller R&D.

Brist på resurser och möjlighet till inflytande över åtminstone ett av dessa tre verksamhetsområden kommer att förskjuta tyngdpunkten av problemen mot den sida där det är enklare att genomföra dessa förändringar, som exempelvis att införa tekniska begränsningar för utgivningar på grund av "smutsig" kod enligt data från de statiska analysystemen. Det vill säga, när PMO sätter en strikt deadline för lanseringen av funktionalitet, kan R&D inte leverera ett kvalitetsresultat inom dessa tidsramar och ger det som de kan, vilket sparar refaktorering till senare, DevOps som rör sig inom IT, blockerar lanseringen med tekniska medel. Brist på befogenhet att förändra situationen leder hos ansvariga medarbetare till en överdriven ansvarskänsla för sådant de inte kan påverka, särskilt om dessa medarbetare förstår och ser felen, och hur man rättar till dem — "Lycka är i okunnighet", och som följd blir det utbrändhet och förlust av dessa medarbetare.

Marknaden för DevOps-resurser

Låt oss titta på några lediga tjänster för DevOps från olika företag.

Vi är redo att träffa dig om du:

1. Behärskar Zabbix och vet vad Prometheus är;
2. Iptables;
3. Aspirant i BASH;
4. Professor i Ansible;
5. Guru i Linux;
6. Kan du använda debuggern och tillsammans med utvecklarna hitta problem i applikationerna (php/java/python);
7. Routing ger dig inga tårar;
8. Du lägger stor vikt vid systemets säkerhet;
9. Du backar upp "allt och alla" och återställer detta "allt och alla" framgångsrikt;
10. Du kan ställa in systemet för att maximera värdet från minimi;
11. Du ställer in replikeringar innan du går till sängs på Postgres och MySQL;
12. Att ställa in och justera CI/CD är för dig en nödvändighet som frukost/lunch/middag.
13. Du har erfarenhet av att arbeta med AWS;
14. Du är redo att utvecklas tillsammans med företaget;

Så:

• från 1 till 6 — systemadministratör
• 7 — lite nätverksadministration, vilket också faller inom systemadministratörens ansvar på mellan-nivå
• 8 — lite säkerhet, vilket är nödvändigt för en systemadministratör på mellan-nivå
• 9-11 — Middle System Administrator
• 12 — Beroende på de uppgifter som ställs antingen Middle System Administrator eller Build Engineer
• 13 — Virtualisering — Middle System Administrator, eller så kallad CloudOps, avancerad kunskap om specifika tjänster hosting på plattformen för effektiv användning av medel och minskning av belastningen på drift

Sammanfattningsvis om denna tjänst kan man säga att pojkarna har tillräckligt med erfarenhet som Middle/Senior System Administrator.

Förresten, man bör inte dela upp administratörer för mycket i Linux/Windows. Jag förstår visserligen att tjänsterna och systemen i dessa två världar skiljer sig, men grunden är densamma och varje respektabel administratör är bekant med både och, och även om man inte är bekant, är det för en kompetent administratör ingen svårighet att bekanta sig med detta.

Låt oss överväga en annan tjänst:

1. Erfarenhet av att bygga högbelastade system;
2. Utmärkta kunskaper i operativsystemet Linux, allmän programvara och webbstacken (Nginx, PHP/Python, HAProxy, MySQL/PostgreSQL, Memcached, Redis, RabbitMQ, ELK);
3. Erfarenhet av att arbeta med virtualiseringssystem (KVM, VMWare, LXC/Docker);
4. Kunskap om skriptspråk;
5. Förståelse för hur nätverksprotokoll fungerar;
6. Förståelse för hur man bygger redundanta system;
7. Självständighet och initiativ;

Vi går igenom:

• 1 — Senior System Administrator
• 2 — Beroende på innebörden av detta stack — Middle/Senior System Administrator
• 3 — Arbetslivserfarenhet kan också betyda — "Kluster har jag inte satt upp, men har skapat och hanterat virtuella maskiner, hade en Docker-värd, skötta åtkomst till containerna" — Middle System Administrator
• 4 — Junior System Administrator — ja, en administratör som inte kan skriva grundläggande automatiseringsskript, oavsett språk, är inte en administratör — en nybörjare.
• 5 — Middle System Administrator
• 6 — Senior System Administrator

Sammanfattningsvis — Middle/Senior System Administrator

Ytterligare en:

1. Arbetslivserfarenhet inom devops;
2. Erfarenhet av att använda en eller flera produkter för att skapa CI/CD-processer. GitLab CI är en fördel;
3. Arbete med containrar och virtualisering; Om du har använt Docker – bra, och om du har använt k8s – utmärkt!
4. Erfarenhet av att arbeta i ett agilt team;
5. Kunskap om något programmeringsspråk;

Vi får se:

• 1 — Hmm... Vad menar killarna? =) Troligen vet de inte själva vad som döljer sig bakom detta.
• 2 — Build Engineer
• 3 — Middle System Administrator
• 4 — Soft skills, vi kommer inte att beakta detta för tillfället, även om Agile är en annan sak som tolkas som det passar.
• 5 — För vag — detta kan vara ett skriptspråk eller ett kompilerat språk. Intressant, skulle de vara nöjda om jag skrev i Pascal och Basic i skolan? =)

Jag vill också lämna en kommentar angående punkt 3, för att förtydliga förståelsen av varför den punkten täcks av systemadministratören. Kubernetes är bara orkestrering, ett verktyg som kapslar in direkta kommandon till nätverksdrivrutiner och värdar för virtualisering/isolering i ett par kommandon och gör kommunikationen abstrakt, det är allt. Som exempel kan vi ta ‘build framework’ Make, vilket jag för övrigt inte anser vara ett ramverk. Ja, jag känner till trenden att peta in Make överallt där det behövs och inte behövs — att kapsla in Maven i Make till exempel, seriöst?
I grund och botten är Make bara ett skalmellanslag som förenklar just kommandon för kompilering, länkning och kompileringens miljö, precis som k8s.

En gång intervjuade jag en kille som använde k8s i sitt arbete ovanpå OpenStack, och han berättade hur han distribuerade tjänster på det, men när jag frågade specifikt om OpenStack visade det sig att det administreras och startas av systemadministratörer. Tror ni verkligen att en person som har startat OpenStack, oavsett vilken plattform han använder bakom sig, inte kan använda k8s?=)
Denna sökande är faktiskt inte DevOps, utan en vanlig systemadministratör och, för att vara exakt, Kubernetes-administratör.

Låt oss sammanfatta igen — Middle/Senior System Administrator är tillräckligt för dem.

Hur mycket att väga i gram

Spannet av erbjudna löner för de angivna tjänsterna — 90k-200k
Nu skulle jag vilja dra en parallell mellan lönerna för systemadministratörer och DevOps-ingenjörer.

I princip kan man förenkla genom att dela in nivåer efter arbetslivserfarenhet, även om det inte blir exakt, räcker det för artikelns syften.

Erfarenhet:

1. upp till 3 år — Junior
2. upp till 6 år — Middle
3. mer än 6 år — Senior

Jobbsajten erbjuder:
Systemadministratörer:

1. Junior — 2 år — 50k rubel.
2. Middle — 5 år — 70k rubel.
3. Senior — 11 år — 100k rubel.

DevOps-ingenjörer:

1. Junior — 2 år — 100k rubel.
2. Middle — 3 år — 160k rubel.
3. Senior — 6 år — 220k rubel.

För DevOps har erfarenheten använts som berör SDLC.

Av det ovanstående följer att företagen egentligen inte behöver DevOps, och att de skulle kunna spara minst 50 procent av de ursprungligen planerade kostnaderna genom att anställa just en administratör. Dessutom skulle de kunna definiera den sökande personens uppgifter tydligare och snabbare tillfredsställa behovet. Man får inte glömma att ett klart ansvarsfördelning gör att kraven på personalen kan sänkas och att det skapar en mer gynnsam atmosfär i teamet, tack vare avsaknaden av överlappningar. I en överväldigande majoritet av annonserna florerar verktyg och DevOps-etiketter, men har egentligen inte något krav på en DevOps-ingenjör, utan bara önskemål om en verktygsadministrator.

Utbildningen av DevOps-ingenjörer begränsas dessutom till en uppsättning specifika uppgifter och verktyg, och ger inte en allmän förståelse för processerna och deras beroenden. Det är förstås bra när en person kan använda Terraform för att deployera AWS EKS, i samband med Fluentd sidecar i den här klustret och AWS ELK-stacken för logghantering på 10 minuter med bara ett kommando i konsolen, men om han eller hon inte förstår själva principen för logghantering och vad de är bra för, inte vet hur man samlar in metrik om dem och följer serviceförsämringar, då är det fortfarande samma typ av person som bara kan använda vissa verktyg.

Efterfrågan föder dock utbud, och vi ser en oerhört upphettad marknad för DevOps-positioner, där kraven inte stämmer överens med den verkliga rollen, utan bara gör att systemadministratörer kan tjäna mer.

Så vem är de? DevOps eller giriga systemadministratörer? =)

Hur går vi vidare?

För arbetsgivare — att noggrant formulera krav och söka efter de som verkligen behövs, istället för att sprida omkring sig etiketter. Om du inte vet vad DevOps gör — så behöver du dem inte i så fall.

För arbetstagare — att lära sig. Ständigt förbättra sina kunskaper, se den övergripande bilden av processerna och följa vägen mot det uppsatta målet. Man kan bli vad man vill, man måste bara anstränga sig.

Källa: habr.com