När den här artikeln skrevs gav en sökning på en populär arbetsplats efter frasen "Nätverksingenjör" cirka trehundra lediga jobb i hela Ryssland. Som jämförelse ger en sökning efter frasen "systemadministratör" nästan 2.5 tusen lediga jobb och "DevOps-ingenjör" - nästan 800.
Betyder detta att nätverkare inte längre behövs i tider av segerrika moln, Docker, Kubernetes och allestädes närvarande offentliga Wi-Fi?
Låt oss ta reda på det (c)
Låt oss lära känna varandra. Jag heter Alexey och jag är en nätverkare.
Jag har varit involverad i nätverk i mer än 10 år och har arbetat med olika *nix-system i mer än 15 år (jag hade en chans att mixtra med både Linux och FreeBSD). Jag jobbade inom telekomoperatörer, stora företag som anses vara ”enterprise”, och nyligen har jag jobbat med ”ung och vågad” fintech, där moln, devops, kubernetes och andra läskiga ord som definitivt kommer göra mig och mina kollegor onödiga . Någon dag. Kanske.
ansvarsfriskrivning: "I vårt liv är inte allt alltid och överallt, utan något, ibland på platser" (c) Maxim Dorofeev.
Allt som skrivs nedan kan och bör betraktas som författarens personliga åsikt, som inte gör anspråk på att vara den ultimata sanningen, eller ens en fullfjädrad studie. Alla karaktärer är fiktiva, alla tillfälligheter är slumpmässiga.
Välkommen till min värld.
Var kan man ens träffa nätverkare?
1. Teleoperatörer, tjänsteföretag och andra integratörer. Allt är enkelt här: nätverket för dem är ett företag. De säljer antingen direkt anslutning (operatörer) eller tillhandahåller tjänster för att lansera/underhålla sina kunders nätverk.
Det finns mycket erfarenhet här, men inte mycket pengar (såvida du inte är en direktör eller en framgångsrik försäljningschef). Och ändå, om du gillar nätverk, och du bara är i början av din resa, kommer en karriär som stöd för någon inte särskilt stor operatör, även nu, att vara en idealisk utgångspunkt (i federala är allt väldigt skriptat, och där är lite utrymme för kreativitet). Jo, berättelser om hur du kan växa från en tjänstgörande ingenjör på några år till en chef på C-nivå är också ganska verkliga, även om det är sällsynta, av uppenbara skäl. Det finns alltid ett behov av personal, eftersom omsättning sker. Detta är både bra och dåligt på samma gång - det finns alltid lediga platser å andra sidan - ofta åker de mest aktiva/smarta snabbt antingen för befordran eller till andra, "varmare" platser.
2. Villkorligt "företag". Det spelar ingen roll om hans huvudsakliga verksamhet är relaterad till IT eller inte. Huvudsaken är att den har en egen IT-avdelning, som säkerställer driften av företagets interna system, inklusive nätverket på kontor, kommunikationskanaler till filialer, etc. En nätverksingenjörs funktioner i sådana företag kan utföras "deltid" av en systemadministratör (om nätverksinfrastrukturen är liten eller hanteras av en extern entreprenör), och en nätverksspecialist, om det finns en, kan vid samtidigt sköta telefoni och SAN (inte bra). De betalar olika – det beror mycket på verksamhetens lönsamhet, företagets storlek och strukturen. Jag arbetade med företag där Cisco-systemen regelbundet "lastades i fat", och med företag där nätverket byggdes av avföring, pinnar och blå tejp, och servrarna aldrig uppdaterades (det behöver inte sägas att det inte heller fanns några reserver). Det finns mycket mindre erfarenhet här, och det kommer nästan säkert att vara inom området strikt leverantörslåsning, eller "hur man gör något av ingenting." Personligen tyckte jag att det var väldigt tråkigt, även om många gillar det - allt är ganska mätt och förutsägbart (om vi pratar om stora företag), "dorakha-bahato", etc. Åtminstone en gång om året säger någon stor leverantör att de har kommit med ett annat mega-super-duper-system som kommer att automatisera allt nu och alla systemadministratörer och nätverkare kan skingras, vilket lämnar ett par att trycka på knappar i ett vackert gränssnitt. Verkligheten är att även om vi bortser från kostnaden för lösningen, kommer nätverkare inte gå någonstans därifrån. Ja, kanske istället för konsolen kommer det återigen att finnas ett webbgränssnitt (men inte en specifik hårdvara, utan ett stort system som hanterar tiotals och hundratals sådana hårdvara), men kunskap om "hur allt fungerar inuti" kommer fortfarande behövas.
3. Produktföretag, vars vinst kommer från utvecklingen (och ofta driften) av någon programvara eller plattform - samma produkt. Vanligtvis är de små och smidiga, de är fortfarande långt från företagens omfattning och deras byråkratisering. Det är här som samma devops, cubers, hamnarbetare och andra hemska ord hittas i massor, vilket säkerligen kommer att göra nätverks- och nätverksingenjörerna till en onödig rudiment.
Hur skiljer sig en nätverkare från en systemadministratör?
I förståelsen för människor inte från IT - ingenting. Båda tittar på den svarta skärmen och skriver några trollformler, ibland tysta svordomar.
I förståelsen för programmerare - kanske efter ämnesområde. Systemadministratörer administrerar servrar, nätverkare administrerar switchar och routrar. Ibland är administrationen dålig, och allt faller samman för alla. Tja, i händelse av något konstigt är det också nätverkarna som bär skulden. Bara för att fan, det är därför.
I själva verket är den största skillnaden arbetssättet. Kanske är det bland nätverkare som det finns flest anhängare av "Om det fungerar, rör det inte!"-metoden. Som regel kan något göras (inom en leverantör) på bara ett sätt; hela konfigurationen av lådan är precis där i din handflata. Kostnaden för ett fel är hög, och ibland mycket hög (till exempel måste du resa flera hundra kilometer för att starta om routern, och vid denna tidpunkt kommer flera tusen människor att vara utan kommunikation - en ganska vanlig situation för en teleoperatör) .
Enligt min åsikt är det därför nätverksingenjörer å ena sidan är extremt motiverade för nätverksstabilitet (och förändring är stabilitetens främsta fiende), och för det andra går deras kunskap mer på djupet än på bredden (det gör man inte måste kunna konfigurera dussintals olika demoner, du måste känna till teknikerna och deras implementering från en specifik utrustningstillverkare). Det är därför en systemadministratör som googlat hur man registrerar ett vlan på ett Cisco-system ännu inte är en nätverkare. Och det är osannolikt att han effektivt kommer att kunna stödja (likväl som felsöka) ett mer eller mindre komplext nätverk.
Men varför behöver du en nätverkare om du har en värd?
För ytterligare pengar (och om du är en mycket stor och älskad kund, kanske till och med gratis, "som en vän"), kommer datacenteringenjörer att konfigurera dina switchar för att passa dina behov och kanske till och med hjälpa dig att upprätta ett BGP-gränssnitt med leverantörer (om du har ett eget subnät av IP-adresser för tillkännagivandet).
Huvudproblemet är att datacentret inte är din IT-avdelning, det är ett separat företag vars mål är att gå med vinst. Bland annat på bekostnad av dig som kund. Datacentret tillhandahåller rack, förser dem med elektricitet och kyla, och tillhandahåller även viss "standard" anslutning till Internet. Baserat på denna infrastruktur kan datacentret vara värd för din utrustning (colocation), hyra ut en server till dig (dedikerad server) eller tillhandahålla en hanterad tjänst (till exempel OpenStack eller K8s). Men verksamheten för ett datacenter är (vanligtvis) inte administration av klientinfrastruktur, eftersom denna process är ganska arbetsintensiv, dåligt automatiserad (och i ett normalt datacenter är allt som är möjligt automatiserat), enhetligt ännu värre (varje klient är individuellt) och i allmänhet fylld av klagomål ("du säger att servern har konfigurerats, men nu har den kraschat, allt är ditt fel!!!111"). Därför, om värden hjälper dig med något, kommer han att försöka göra det så enkelt och bekvämt som möjligt. För att det är olönsamt att göra det svårt, åtminstone med tanke på arbetskostnaderna för ingenjörerna på samma värd (men situationerna är annorlunda, se ansvarsfriskrivning). Detta betyder inte att hostaren nödvändigtvis kommer att göra allting dåligt. Men det är inte alls ett faktum att han kommer att göra exakt vad du verkligen behövde.
Det verkar som att grejen är ganska uppenbar, men flera gånger i min praktik har jag stött på det faktum att företag började lita på sin värdleverantör lite mer än de borde, och detta ledde inte till något bra. Jag var tvungen att förklara utförligt och i detalj att inte en enda SLA skulle täcka förluster från driftstopp (det finns undantag, men vanligtvis är det väldigt, MYCKET dyrt för kunden) och att hostaren inte alls är medveten om vad som händer i kundernas infrastruktur (förutom mycket generella indikatorer). Och värden gör inga säkerhetskopior åt dig heller. Situationen är ännu värre om du har mer än en värd. Om det skulle uppstå problem mellan dem, kommer de säkerligen inte att ta reda på vad som gick fel.
Egentligen är motiven här exakt desamma som när man väljer "inhouse admin team vs outsourca". Om riskerna är beräknade, kvaliteten är tillfredsställande och företaget inte har något emot det, varför inte prova det. Å andra sidan är nätverket ett av de mest grundläggande lagren av infrastruktur, och det är knappast värt att lämna det till utomstående killar om du redan stödjer allt annat själv.
I vilka fall behövs en nätverkare?
Härnäst kommer vi att prata specifikt om moderna livsmedelsföretag. Med operatörer och företagande är allt klart, plus eller minus – lite har förändrats där under de senaste åren, och nätverkare behövdes där tidigare, och de behövs nu. Men med samma "unga och vågade" är saker och ting inte så tydliga. Ofta placerar de hela sin infrastruktur i molnen, så de behöver egentligen inte ens administratörer - förutom administratörerna för samma moln, förstås. Infrastrukturen är å ena sidan ganska enkel i sin design, å andra sidan är den väl automatiserad (ansible/puppet, terraform, ci/cd... ja, du vet). Men även här finns det situationer när du inte klarar dig utan en nätverksingenjör.
Exempel 1, klassisk
Anta att ett företag börjar med en server med en offentlig IP-adress, som finns i ett datacenter. Sedan finns det två servrar. Sen mer... Förr eller senare kommer det att finnas behov av ett privat nätverk mellan servrar. Eftersom "extern" trafik begränsas både av bandbredd (högst 100 Mbit/s till exempel) och av volymen nedladdade/uppladdade per månad (olika värdar har olika tariffer, men bandbredd till omvärlden är vanligtvis mycket dyrare än en privat nätverk).
Värden lägger till ytterligare nätverkskort till servrarna och inkluderar dem i sina switchar i ett separat vlan. Ett "platt" lokalt område visas mellan servrarna. Bekväm!
Antalet servrar växer, och trafiken på det privata nätverket växer också - säkerhetskopieringar, replikeringar osv. Hostern erbjuder att flytta dig till separata switchar så att du inte stör andra klienter, och de inte stör dig. Värden installerar några switchar och konfigurerar dem på något sätt - troligtvis lämnar ett platt nätverk mellan alla dina servrar. Allt fungerar bra, men vid ett visst tillfälle börjar problem: förseningar mellan värdar ökar med jämna mellanrum, loggarna klagar över för många arp-paket per sekund, och under en granskning knullade pentestern hela ditt lokala nätverk och slog bara sönder en server.
Vad ska man göra?
Dela upp nätverket i segment - vlans. Konfigurera din egen adressering i varje vlan, välj en gateway som överför trafik mellan nätverk. Konfigurera acl på gatewayen för att begränsa åtkomst mellan segment, eller installera en separat brandvägg i närheten.
Exempel 1, fortsättning
Servrarna är anslutna till LAN med en sladd. Strömbrytarna i ställen är på något sätt kopplade till varandra, men om det händer en olycka i ett ställ faller ytterligare tre intilliggande av. System finns, men det finns tvivel om deras relevans. Varje server har sin egen offentliga adress, som utfärdas av värden och är knuten till racket. De där. När du flyttar en server måste adressen ändras.
Vad ska man göra?
Anslut servrarna med hjälp av LAG (Link Aggregation Group) med två sladdar till switcharna i racket (de måste också vara redundanta). Reservera anslutningarna mellan stativen och konvertera dem till en "stjärna" (eller den nu fashionabla CLOS) så att förlusten av ett stativ inte påverkar de andra. Välj "centrala" rack där nätverkskärnan ska placeras och där andra rack ska anslutas. Sätt samtidigt ordning på allmän adressering, ta från hostaren (eller från RIR, om möjligt) ett subnät, som du själv (eller genom hostaren) tillkännager för världen.
Kan allt detta göras av en "vanlig" systemadministratör som inte har djup kunskap om nätverk? Vet inte. Kommer värden att göra detta? Kanske kommer det att göra det, men du behöver en ganska detaljerad teknisk specifikation, som någon också kommer att behöva utarbeta. och kontrollera sedan att allt är korrekt gjort.
Exempel 2: Moln
Låt oss säga att du har en VPC i något offentligt moln. För att få åtkomst från kontoret eller den lokala delen av infrastrukturen till det lokala nätverket inuti VPC:n måste du konfigurera en anslutning via IPSec eller en dedikerad kanal. Å ena sidan är IPSec billigare, eftersom inget behov av att köpa ytterligare hårdvara; du kan skapa en tunnel mellan din server med en offentlig adress och molnet. Men - förseningar, begränsad prestanda (eftersom kanalen måste krypteras), plus ogaranterad anslutning (eftersom åtkomst sker via det vanliga Internet).
Vad ska man göra?
Höj en anslutning genom en dedikerad kanal (till exempel, AWS kallar det för Direct Connect). För att göra detta, hitta en partneroperatör som ansluter dig, bestäm vilken anslutningspunkt som är närmast dig (både du till operatören och operatören till molnet), och slutligen, ställ in allt. Är det möjligt att göra allt detta utan en nätverksingenjör? Visst ja. Men hur man felsöker utan honom vid problem är inte längre så klart.
Det kan även vara problem med tillgänglighet mellan moln (om du har ett multimoln) eller problem med förseningar mellan olika regioner osv. Naturligtvis har många verktyg nu dykt upp som ökar transparensen av vad som händer i molnet (samma Thousand Eyes), men dessa är alla verktyg för en nätverksingenjör, och inte en ersättning för honom.
Jag skulle kunna skissa på ett dussin fler sådana exempel från min praktik, men jag tror att det är klart att teamet, med utgångspunkt från en viss nivå av infrastrukturutveckling, måste ha en person (helst fler än en) som vet hur nätverket fungerar och kan konfigurera nätverksutrustning och reda ut problem om de uppstår. Tro mig, han kommer att ha något att göra
Vad bör en nätverkare veta?
Det är inte alls nödvändigt (och till och med ibland skadligt) för en nätverksingenjör att bara hantera nätverket och inget annat. Även om vi inte överväger alternativet med en infrastruktur som nästan helt lever i det offentliga molnet (och vad man än kan säga, det blir mer och mer populärt), och tar till exempel on premiss eller privata moln, där om "kunskap på CCNP-nivå ensam" "Du kommer inte att lämna.
Förutom, faktiskt, nätverk - även om det helt enkelt finns ett oändligt fält för studier, även om du bara koncentrerar dig på ett område (leverantörsnätverk, företag, datacenter, Wi-Fi ...)
Naturligtvis kommer många av er nu att komma ihåg Python och annan "nätverksautomation", men detta är bara ett nödvändigt, men inte ett tillräckligt villkor. För att en nätverksingenjör ska "framgångsrikt gå med i teamet" måste han kunna tala samma språk med både utvecklare och andra administratörer/utvecklare. Vad betyder det?
- kunna inte bara arbeta i Linux som användare, utan också att administrera det, åtminstone på sysadmin-jun-nivån: installera den nödvändiga programvaran, starta om en misslyckad tjänst, skriv en enkel systemd-enhet.
- Förstå (åtminstone i allmänna termer) hur nätverksstacken fungerar i Linux, hur nätverket fungerar i hypervisorer och behållare (lxc / docker / kubernetes).
- Självklart kunna arbeta med ansible/kock/docka eller annat SCM-system.
- En separat rad bör skrivas om SDN och nätverk för privata moln (till exempel TungstenFabric eller OpenvSwitch). Detta är ytterligare ett enormt lager av kunskap.
Kortfattat beskrev jag en typisk T-form specialist (som det är på modet att säga nu). Det verkar som inget nytt, men baserat på intervjuerfarenhet kan inte alla nätverksingenjörer skryta med kunskap om minst två ämnen från listan ovan. I praktiken gör bristen på kunskap "inom relaterade områden" det mycket svårt att inte bara kommunicera med kollegor utan också att förstå de krav som verksamheten ställer på nätverket, som den lägsta infrastrukturen i projektet. Och utan denna förståelse blir det svårare att försvara din åsikt och "sälja" den till företag.
Å andra sidan ger samma vana att "förstå hur systemet fungerar" nätverkare en mycket god fördel gentemot olika "generalister" som känner till teknologier från artiklar på Habré/medium och chattar på Telegram, men har absolut ingen aning om hur principer fungerar den eller den programvaran efter? Och kunskap om vissa mönster, som bekant, ersätter framgångsrikt kunskap om många fakta.
Slutsatser, eller bara TL;DR
- En nätverksadministratör (som en DBA- eller VoIP-ingenjör) är en specialist med en ganska snäv profil (till skillnad från systemadministratörer/devs/SRE), vars behov inte uppstår omedelbart (och kanske inte uppstår på länge, faktiskt) . Men om det uppstår är det osannolikt att det kommer att ersättas av extern expertis (outsourca eller vanliga administratörer för allmänna ändamål, "som också sköter nätverket"). Vad som är något tråkigare är att behovet av sådana specialister är litet, och villkorligt, i ett företag med 800 programmerare och 30 devops/administratörer, kan det bara finnas två nätverkare som gör ett utmärkt jobb med sitt ansvar. De där. marknaden var och är väldigt, väldigt liten, och med en bra lön – ännu mindre.
- Å andra sidan måste en bra nätverkare i den moderna världen inte bara känna till själva nätverken (och hur man automatiserar deras konfiguration), utan också hur operativsystemen och mjukvaran som körs ovanpå dessa nätverk interagerar med dem. Utan detta blir det oerhört svårt att förstå vad dina kollegor begär av dig och att (rimligen) förmedla dina önskemål/krav till dem.
- Det finns inget moln, det är bara någon annans dator. Du måste förstå att användningen av offentliga/privata moln eller tjänster från en värdleverantör "som gör allt för dig på nyckelfärdig basis" inte ändrar det faktum att din applikation fortfarande använder nätverket, och problem med det kommer att påverka driften av din ansökan. Ditt val är var kompetenscentret kommer att ligga, som kommer att ansvara för nätverket i ditt projekt.
Källa: will.com