För tillfället är detta nästan den dyraste positionen på marknaden. Uppståndelsen kring "DevOps"-ingenjörer är bortom alla tänkbara gränser, och ännu värre med Senior DevOps-ingenjörer.
Jag jobbar som chef för integrations- och automationsavdelningen, gissa den engelska avkodningen - DevOps Manager. Det är osannolikt att det engelska utskriften återspeglar våra dagliga aktiviteter, men den ryska versionen i det här fallet är mer korrekt. På grund av min aktivitets karaktär är det naturligt att jag behöver intervjua framtida medlemmar i mitt team, och under det senaste året har cirka 50 personer passerat mig, och samma antal har stängts av på förhandsskärmen med mina anställda.
Vi söker fortfarande efter kollegor, för bakom DevOps-etiketten gömmer sig ett väldigt stort lager av olika sorters ingenjörer.
Allt som står nedan är min personliga åsikt, du behöver inte hålla med om det, men jag erkänner att det kommer att sätta lite färg på din inställning till ämnet. Trots risken att falla i onåd publicerar jag min åsikt eftersom jag tror att den har en plats att vara.
Företag har olika uppfattningar om vilka DevOps-ingenjörer är och, för att snabbt kunna anställa en resurs, hänger de denna etikett på alla. Situationen är ganska märklig, eftersom företag är beredda att betala orealistiska ersättningar till dessa personer och i de flesta fall får en verktygsadministratör för dem.
Så vilka är DevOps-ingenjörer?
Låt oss börja med historien om dess utseende - Development Operations dök upp som ytterligare ett steg mot att optimera interaktion i små team för att öka hastigheten på produktproduktionen, som en förväntad konsekvens. Tanken var att stärka utvecklingsteamet med kunskap om procedurer och tillvägagångssätt för att hantera produktmiljön. Med andra ord måste utvecklaren förstå och veta hur hans produkt fungerar under vissa förhållanden, måste förstå hur han ska distribuera sin produkt, vilka egenskaper hos miljön som kan justeras för att förbättra prestandan. Så under en tid dök det upp utvecklare med en DevOps-strategi. DevOps-utvecklare skrev bygg- och paketeringsskript för att förenkla deras aktiviteter och prestanda i produktionsmiljön. Komplexiteten i lösningsarkitekturen och den ömsesidiga påverkan av infrastrukturkomponenter började med tiden att försämra miljöernas prestanda; med varje iteration krävdes en allt djupare förståelse av vissa komponenter, vilket minskade utvecklarens produktivitet på grund av den extra kostnader för att förstå komponenterna och inställningssystemen för en specifik uppgift. . Utvecklarens egen kostnad växte, kostnaden för produkten tillsammans med den, kraven på nya utvecklare i teamet steg kraftigt, eftersom de också behövde täcka ansvaret för utvecklings-"stjärnan" och, naturligtvis, "stjärnorna" blev mindre och mindre tillgänglig. Det är också värt att notera att, enligt min erfarenhet, är få utvecklare intresserade av detaljerna i paketbearbetning av operativsystemets kärna, paketdirigeringsregler och värdsäkerhetsaspekter. Det logiska steget var att attrahera en administratör som är bekant med detta och tilldela honom liknande ansvar, vilket tack vare hans erfarenhet gjorde det möjligt att uppnå samma indikatorer till en lägre kostnad jämfört med kostnaden för en "stjärna" utveckling. Sådana administratörer placerades i ett team och hans huvudsakliga uppgift var att hantera test- och produktionsmiljöer, enligt reglerna för ett specifikt team, med resurser tilldelade just detta team. Så här verkade faktiskt DevOps i huvudet på majoriteten.
Helt eller delvis, med tiden började dessa systemadministratörer förstå behoven hos just detta team inom utvecklingsområdet, hur man gör livet lättare för utvecklare och testare, hur man rullar ut en uppdatering och inte behöver övernatta på fredag i kontoret, korrigera distributionsfel. Tiden gick och nu var "stjärnorna" systemadministratörer som förstod vad utvecklarna ville ha. För att minimera effekten började hanteringsverktyg komma upp; alla kom ihåg de gamla och pålitliga metoderna för att isolera OS-nivån, vilket gjorde det möjligt att minimera kraven på säkerhet, hantering av nätverksdelen och värdkonfigurationen som en hela och, som ett resultat, minska kraven på nya "stjärnor".
En "underbar" sak har dykt upp - hamnarbetare. Varför underbart? Ja, bara för att skapa isolering i en chroot eller fängelse, såväl som OpenVZ, krävde icke-trivial kunskap om operativsystemet, däremot låter verktyget dig helt enkelt skapa en isolerad applikationsmiljö på en viss värd med allt som behövs inuti och hand över tyglarna på utvecklingen igen, och systemadministratören kan bara hantera med bara en värd, vilket säkerställer dess säkerhet och höga tillgänglighet - en logisk förenkling. Men framstegen står inte stilla och systemen blir återigen mer och mer komplexa, det finns fler och fler komponenter, en värd uppfyller inte längre systemets behov och det är nödvändigt att bygga kluster, vi återvänder igen till systemadministratörer som är kunna bygga dessa system.
Cykel efter cykel dyker upp olika system som förenklar utveckling och/eller administration, orkestreringssystem dyker upp som tills man behöver avvika från standardprocessen är lätta att använda. Microservice-arkitektur dök också upp med syftet att förenkla allt som beskrivs ovan – färre relationer, lättare att hantera. Enligt min erfarenhet hittade jag inte en helt mikrotjänstarkitektur, jag skulle säga att 50 till 50 - 50 procent av mikrotjänsterna, svarta lådor, kom in, kom ut bearbetade, de andra 50 är en trasig monolit, tjänster som inte kan fungera separat från andra komponenter. Allt detta införde återigen begränsningar för kunskapsnivån hos både utvecklare och administratörer.
Liknande "svängningar" i nivån av expertkunskaper om en viss resurs fortsätter än i dag. Men vi avviker lite, det finns många punkter värda att lyfta fram.
Byggingenjör/Releaseingenjör
Mycket högt specialiserade ingenjörer som växte fram som ett sätt att standardisera processer och releaser av mjukvarubyggen. I processen med att introducera utbredd Agile verkar det som om de upphört att vara efterfrågade, men så är långt ifrån fallet. Denna specialisering framstod som ett medel för att standardisera montering och leverans av mjukvara i industriell skala, d.v.s. med standardteknik för alla företagsprodukter. Med tillkomsten av DevOps förlorade utvecklarna delvis sina funktioner, eftersom det var utvecklarna som började förbereda produkten för leverans, och med tanke på den förändrade infrastrukturen och tillvägagångssättet att leverera så snabbt som möjligt utan hänsyn till kvalitet, blev de med tiden till ett stopp för förändringar, eftersom efterlevnad av kvalitetsstandarder oundvikligen bromsar leveranserna. Så gradvis migrerade en del av funktionaliteten hos Build/Release-ingenjörer till systemadministratörernas axlar.
Ops är så olika
Vi går vidare och igen närvaron av ett stort antal ansvarsområden och bristen på kvalificerad personal driver oss mot strikt specialisering, som svampar efter regn, olika operationer dyker upp:
- TechOps - enikey systemadministratörer aka HelpDesk Engineer
- LiveOps - systemadministratörer primärt ansvariga för produktionsmiljöer
- CloudOps - systemadministratörer specialiserade på offentliga moln Azure, AWS, GCP, etc.
- PlatOps/InfraOps/SysOps - infrastruktursystemadministratörer.
- NetOps - nätverksadministratörer
- SecOps - systemadministratörer specialiserade på informationssäkerhet - PCI-efterlevnad, CIS-efterlevnad, patchning, etc.
DevOps är (i teorin) en person som själv förstår alla processer i utvecklingscykeln - utveckling, testning, förstår produktarkitekturen, kan bedöma säkerhetsrisker, är bekant med tillvägagångssätt och automationsverktyg, åtminstone på hög nivå. nivå, utöver detta, förstår också för- och efterbearbetning.support för produktsläpp. En person som kan agera som förespråkare för både drift och utveckling, vilket möjliggör ett gynnsamt samarbete mellan dessa två pelare. Förstår processerna för att planera arbete i team och hantera kundernas förväntningar.
För att utföra denna typ av arbete och ansvar måste denna person ha medel att hantera inte bara utvecklings- och testprocesserna, utan också hanteringen av produktinfrastrukturen, såväl som resursplanering. DevOps i denna förståelse kan inte lokaliseras vare sig i IT, eller i FoU, eller ens i PMO; de måste ha inflytande inom alla dessa områden - företagets tekniska direktör, Chief Technical Officer.
Stämmer detta i ditt företag? - Jag tvivlar. I de flesta fall är detta antingen IT eller FoU.
Brist på medel och förmåga att påverka åtminstone ett av dessa tre verksamhetsområden kommer att flytta tyngden av problem dit det är lättare att tillämpa dessa förändringar, såsom tillämpning av tekniska restriktioner för utsläpp i samband med "smutsig" kod enligt statisk analysatorsystem. Det vill säga, när PMO sätter en strikt deadline för frisläppandet av funktionalitet, kan FoU inte producera ett högkvalitativt resultat inom dessa tidsfrister och producerar det så gott det kan, och lämnar refactoring för senare, DevOps relaterat till IT blockerar releasen med tekniska medel . Brist på auktoritet för att förändra situationen, när det gäller ansvarsfulla anställda, leder till manifestationen av hyperansvar för det de inte kan påverka, särskilt om dessa anställda förstår och ser misstag och hur man korrigerar dem - "Lycka är okunnighet", och som en konsekvens av utbrändhet och förlust av dessa anställda.
DevOps resursmarknad
Låt oss titta på flera lediga jobb för DevOps-positioner från olika företag.
Vi är redo att träffa dig om du:
- Du äger Zabbix och vet vad Prometheus är;
- Iptables;
- BASH doktorand;
- professor Ansible;
- Linux Guru;
- Vet hur man använder felsökning och hittar applikationsproblem tillsammans med utvecklare (php/java/python);
- Routing gör dig inte hysterisk;
- Var mycket uppmärksam på systemsäkerhet;
- Säkerhetskopiera "allt och vad som helst", och återställ också framgångsrikt detta "allt och allt";
- Du vet hur du konfigurerar systemet på ett sådant sätt att du får ut det maximala ur minimum;
- Ställ in replikering innan du går och lägger dig på Postgres och MySQL;
- Att ställa in och justera CI/CD är lika nödvändigt för dig som frukost/lunch/middag.
- Har erfarenhet av AWS;
- Redo att utvecklas med företaget;
Så:
- från 1 till 6 - systemadministratör
- 7 - lite nätverksadministration, som också passar in i systemadministratören, Mellannivå
- 8 - lite säkerhet, vilket är obligatoriskt för en systemadministratör på medelnivå
- 9-11 – Mellansystemadministratör
- 12 — Beroende på de tilldelade uppgifterna, antingen mellansystemadministratör eller byggingenjör
- 13 - Virtualisering - Mellansystemadministratör, eller den så kallade CloudOps, avancerad kunskap om tjänsterna för en specifik värdsida, för effektiv användning av pengar och minska belastningen på underhåll
Sammanfattningsvis kan vi säga att Mellan/Senior System Administrator räcker för killarna.
Förresten, du bör inte starkt dela upp administratörer på Linux/Windows. Naturligtvis förstår jag att tjänsterna och systemen i dessa två världar är olika, men grunden för alla är densamma och varje administratör med självrespekt är bekant med både den ena och den andra, och även om han inte är bekant, kommer det att inte vara svårt för en kompetent administratör att bli bekant med det.
Låt oss överväga en annan ledig tjänst:
- Erfarenhet av att bygga högbelastningssystem;
- Utmärkt kunskap om Linux OS, generell systemmjukvara och webbstack (Nginx, PHP/Python, HAProxy, MySQL/PostgreSQL, Memcached, Redis, RabbitMQ, ELK);
- Erfarenhet av virtualiseringssystem (KVM, VMWare, LXC/Docker);
- Kunskaper i skriptspråk;
- Förståelse av driftprinciperna för nätverksprotokollnätverk;
- Förståelse av principerna för att bygga feltoleranta system;
- Oberoende och initiativförmåga;
Låt oss titta på:
- 1 – Senior systemadministratör
- 2 - Beroende på betydelsen i denna stack - Mellan-/Senior systemadministratör
- 3 - Arbetslivserfarenhet, inklusive, kan betyda - "Klustret skapade inte, men skapade och hanterade virtuella maskiner, det fanns en Docker-värd, åtkomst till behållare var inte tillgänglig" - Mellansystemadministratör
- 4 - Junior systemadministratör - ja, en administratör som inte vet hur man skriver grundläggande automatiseringsskript, oavsett språk, inte en admin - enikey.
- 5 - Mellansystemadministratör
- 6 – Senior systemadministratör
För att sammanfatta - Mellan/Senior systemadministratör
En till:
- Devoper erfarenhet;
- Erfarenhet av att använda en eller flera produkter för att skapa CI/CD processer. Gitlab CI kommer att vara en fördel;
- Arbeta med containrar och virtualisering; Om du använde docker, bra, men om du använde k8s, bra!
- Erfarenhet av att arbeta i ett agilt team;
- Kunskaper om vilket programmeringsspråk som helst;
Låt oss se:
- 1 - Hmm... Vad menar killarna? =) Troligtvis vet de själva inte vad som döljer sig bakom det
- 2 - Byggingenjör
- 3 - Mellansystemadministratör
- 4 - Mjuk skicklighet, vi kommer inte att överväga det för närvarande, även om Agile är en annan sak som tolkas på ett sätt som är bekvämt.
- 5 - För mångsidigt - det kan vara ett skriptspråk eller ett kompilerat. Jag undrar om att skriva i Pascal och Basic i skolan kommer att passa dem? =)
Jag vill även lämna en lapp angående punkt 3 för att stärka förståelsen för varför denna punkt omfattas av systemadministratören. Kubernetes är bara en orkestrering, ett verktyg som lindar in direkta kommandon till nätverksdrivrutiner och virtualiserings-/isoleringsvärdar i ett par kommandon och låter dig göra kommunikationen med dem abstrakt, det är allt. Låt oss till exempel ta 'bygga ramverk' Make, som jag för övrigt inte betraktar som ett ramverk. Ja, jag känner till modet att knuffa Make var som helst, där det är nödvändigt och inte behövs - att slå in Maven in Make, till exempel på allvar?
I grund och botten är Make bara ett omslag över skalet, vilket förenklar kompilerings-, länknings- och kompileringsmiljökommandona, precis som k8s.
En gång intervjuade jag en kille som använde k8s i sitt arbete ovanpå OpenStack, och han pratade om hur han distribuerade tjänster på den, men när jag frågade om OpenStack visade det sig att den administrerades, samt togs upp av systemet. administratörer. Tror du verkligen att en person som har installerat OpenStack, oavsett vilken plattform han använder bakom sig, inte kan använda k8s? =)
Den här sökanden är faktiskt inte en DevOps, utan en systemadministratör och, för att vara mer exakt, en Kubernetes-administratör.
Låt oss sammanfatta ännu en gång - Mellan/Senior System Administrator kommer att räcka för dem.
Hur mycket man ska väga i gram
Utbudet av föreslagna löner för de angivna vakanserna är 90 200-XNUMX XNUMX
Nu skulle jag vilja dra en parallell mellan de monetära belöningarna för systemadministratörer och DevOps-ingenjörer.
I princip, för att förenkla saker och ting, kan du sprida betygen baserat på arbetslivserfarenhet, även om detta inte kommer att vara exakt, men för artikelns syften kommer det att räcka.
En upplevelse:
- upp till 3 år – Junior
- upp till 6 år – Mellan
- fler än 6 – Senior
Medarbetarsöksidan erbjuder:
Systemadministratörer:
- Junior - 2 år - 50k rub.
- Mellan - 5 år - 70k rub.
- Senior - 11 år - 100k rub.
DevOps-ingenjörer:
- Junior - 2 år - 100k rub.
- Mellan - 3 år - 160k rub.
- Senior - 6 år - 220k rub.
Enligt erfarenheten från "DevOps" användes erfarenheter som åtminstone på något sätt påverkade SDLC.
Av ovanstående följer att företag faktiskt inte behöver DevOps, och även att de skulle kunna spara minst 50 procent av de initialt planerade kostnaderna genom att anlita en administratör; dessutom skulle de tydligare kunna definiera ansvaret för den person de söker efter och fylla behovet snabbare. Vi bör inte heller glömma att en tydlig ansvarsfördelning gör att vi kan minska kraven på personal, samt skapa en mer gynnsam atmosfär i laget, på grund av frånvaron av överlappningar. De allra flesta lediga jobb är fulla av verktyg och DevOps-etiketter, men de är inte baserade på faktiska krav för en DevOps-ingenjör, bara förfrågningar om en verktygsadministratör.
Processen att utbilda DevOps-ingenjörer är också begränsad till en uppsättning specifika verk, verktyg och ger ingen allmän förståelse för processerna och deras beroenden. Det är verkligen bra när en person kan distribuera AWS EKS med Terraform, i kombination med Fluentd sidovagnen i detta kluster och AWS ELK-stacken för loggningssystemet på 10 minuter, med bara ett kommando i konsolen, men om han inte förstår principen om att bearbeta sig själva loggar och vad de behövs för, om du inte vet hur man samlar in mätvärden på dem och spårar försämringen av tjänsten, kommer det fortfarande att vara samma enikey som vet hur man använder vissa verktyg.
Efterfrågan skapar dock utbud och vi ser en extremt överhettad marknad för DevOps-positionen, där kraven inte stämmer överens med den faktiska rollen, utan bara tillåter systemadministratörer att tjäna mer.
Så vilka är de? DevOps eller giriga systemadministratörer? =)
Hur ska man fortsätta leva?
Arbetsgivare bör formulera krav mer exakt och leta efter just de som behövs, och inte slänga runt etiketter. Du vet inte vad DevOps gör – du behöver dem inte i så fall.
Arbetare - Lär dig. Förbättra ständigt dina kunskaper, titta på den övergripande bilden av processer och spåra vägen till ditt mål. Du kan bli vem du vill, du måste bara försöka.
Källa: will.com