På tidspunktet for skrivning af denne artikel returnerede en søgning på et populært jobsted efter udtrykket "Netværksingeniør" omkring tre hundrede ledige stillinger i hele Rusland. Til sammenligning returnerer en søgning efter udtrykket "systemadministrator" næsten 2.5 tusinde ledige stillinger og "DevOps-ingeniør" - næsten 800.
Betyder det, at der ikke længere er brug for netværksfolk i tider med sejrende skyer, Docker, Kubernetes og allestedsnærværende offentlig Wi-Fi?
Lad os finde ud af det (c)
Lad os lære hinanden at kende. Mit navn er Alexey, og jeg er en netværker.
Jeg har været involveret i netværk i mere end 10 år og har arbejdet med forskellige *nix-systemer i mere end 15 år (jeg havde en chance for at pille ved både Linux og FreeBSD). Jeg arbejdede i teleoperatører, store virksomheder, der anses for at være "enterprise", og for nylig har jeg arbejdet i "ung og dristig" fintech, hvor clouds, devops, kubernetes og andre skræmmende ord, der helt sikkert vil gøre mig og mine kolleger unødvendige . En skønne dag. Måske.
ansvarsfraskrivelse: "I vores liv er alt ikke altid og overalt, men noget, nogle gange nogle steder" (c) Maxim Dorofeev.
Alt skrevet nedenfor kan og bør betragtes som forfatterens personlige mening, som ikke hævder at være den ultimative sandhed, eller endda en fuldgyldig undersøgelse. Alle karakterer er fiktive, alle tilfældigheder er tilfældige.
Velkommen til min verden.
Hvor kan du overhovedet møde netværkere?
1. Teleoperatører, servicevirksomheder og andre integratorer. Alt er enkelt her: netværket for dem er en forretning. De sælger enten direkte forbindelse (operatører) eller leverer tjenester til lancering/vedligeholdelse af deres kunders netværk.
Der er meget erfaring her, men ikke mange penge (medmindre du er direktør eller en succesfuld salgschef). Og alligevel, hvis du kan lide netværk, og du kun er i begyndelsen af din rejse, vil en karriere til støtte for en eller anden ikke særlig stor operatør, selv nu, være et ideelt udgangspunkt (i føderale er alt meget scriptet, og der er lidt plads til kreativitet). Tja, historier om, hvordan du kan vokse fra en ingeniør på vagt på få år til en C-level manager er også ret reelle, selvom sjældne, af indlysende årsager. Der er altid behov for personale, for der sker omsætning. Dette er både godt og dårligt på samme tid - der er altid ledige pladser, til gengæld - ofte tager de mest aktive/kloge hurtigt af sted enten for oprykning eller til andre, "varmere" steder.
2. Betinget "virksomhed". Det er lige meget, om hans hovedaktivitet er relateret til IT eller ej. Hovedsagen er, at den har sin egen it-afdeling, som sikrer driften af virksomhedens interne systemer, herunder netværket på kontorer, kommunikationskanaler til filialer mv. En netværksingeniørs funktioner i sådanne virksomheder kan udføres "deltid" af en systemadministrator (hvis netværksinfrastrukturen er lille eller varetages af en ekstern entreprenør), og en netværksspecialist, hvis der er en, kan ved samtidig passe telefoni og SAN (ikke godt). De betaler forskelligt – det afhænger meget af virksomhedens rentabilitet, virksomhedens størrelse og strukturen. Jeg arbejdede med virksomheder, hvor Cisco-systemerne jævnligt blev "lastet i tønder", og med virksomheder, hvor netværket var bygget af fækalier, sticks og blue tape, og serverne aldrig blev opdateret (det er overflødigt at sige, at der heller ikke blev leveret reserver). Der er meget mindre erfaring her, og det vil næsten helt sikkert være inden for streng leverandørlås eller "hvordan man laver noget ud af ingenting." Personligt fandt jeg det vildt kedeligt, selvom mange mennesker kan lide det - alt er ret afmålt og forudsigeligt (hvis vi taler om store virksomheder), “dorakha-bahato” osv. Mindst en gang om året siger en eller anden stor leverandør, at de er kommet op med et andet mega-super-duper-system, der vil automatisere alt nu, og alle systemadministratorer og netværksfolk kan blive spredt, hvilket efterlader et par til at trykke på knapper i en smuk grænseflade. Virkeligheden er, at selvom vi ignorerer omkostningerne ved løsningen, vil netværksfolk ikke gå nogen steder derfra. Ja, måske vil der i stedet for konsollen igen være en webgrænseflade (men ikke et specifikt stykke hardware, men et stort system, der administrerer titusindvis og hundredvis af sådanne stykker hardware), men viden om "hvordan alt fungerer indeni" vil stadig være nødvendig.
3. Produktvirksomheder, hvis fortjeneste kommer fra udviklingen (og ofte driften) af en eller anden software eller platform - det samme produkt. Normalt er de små og smidige, de er stadig langt fra virksomhedernes omfang og deres bureaukratisering. Det er her, de samme devops, cubers, dockers og andre forfærdelige ord findes i massevis, hvilket helt sikkert vil gøre netværks- og netværksingeniørerne til et unødvendigt rudiment.
Hvordan adskiller en netværker sig fra en systemadministrator?
I forståelsen af mennesker ikke fra IT - ingenting. De ser begge på den sorte skærm og skriver nogle besværgelser, nogle gange med at bande.
I forståelsen af programmører - måske efter fagområde. Systemadministratorer administrerer servere, netværkere administrerer switche og routere. Nogle gange er administrationen dårlig, og alt falder fra hinanden for alle. Nå, i tilfælde af noget mærkeligt, er netværksfolkene også skylden. Bare fordi fuck dig, det er derfor.
Faktisk er den største forskel tilgangen til arbejde. Måske er det blandt netværkere, at der er flest tilhængere af "Hvis det virker, så lad være med at røre det!"-tilgangen. Som regel kan noget gøres (inden for én leverandør) på kun én måde; hele konfigurationen af boksen er lige der i din hule hånd. Omkostningerne ved en fejl er høje og nogle gange meget høje (for eksempel skal du rejse flere hundrede kilometer for at genstarte routeren, og på nuværende tidspunkt vil flere tusinde mennesker være uden kommunikation - en ganske almindelig situation for en teleoperatør) .
Efter min mening er det derfor, netværksingeniører på den ene side er ekstremt højt motiverede for netværksstabilitet (og forandring er stabilitetens hovedfjende), og for det andet går deres viden mere i dybden end i bredden (det gør man ikke skal være i stand til at konfigurere snesevis af forskellige dæmoner, du skal kende teknologierne og deres implementering fra en specifik udstyrsproducent). Det er grunden til, at en systemadministrator, der googlede, hvordan man registrerer en vlan på et Cisco-system, endnu ikke er netværksmand. Og det er usandsynligt, at han effektivt vil være i stand til at understøtte (såvel som fejlfinding) et mere eller mindre komplekst netværk.
Men hvorfor har du brug for en netværker, hvis du har en hoster?
For yderligere penge (og hvis du er en meget stor og elsket klient, måske endda gratis, "som en ven"), vil datacenteringeniører konfigurere dine switches, så de passer til dine behov, og måske endda hjælpe dig med at etablere en BGP-grænseflade med udbydere (hvis du har dit eget undernet af IP-adresser til annonceringen).
Hovedproblemet er, at datacentret ikke er din it-afdeling, det er en separat virksomhed, hvis mål er at skabe overskud. Herunder på bekostning af dig som kunde. Datacentret leverer stativer, forsyner dem med elektricitet og kulde og giver også nogle "standard"-forbindelser til internettet. Baseret på denne infrastruktur kan datacentret hoste dit udstyr (colocation), leje en server ud til dig (dedikeret server) eller levere en administreret service (for eksempel OpenStack eller K8s). Men et datacenters forretning er (normalt) ikke administration af klientinfrastruktur, fordi denne proces er ret arbejdskrævende, dårligt automatiseret (og i et normalt datacenter er alt, hvad der er muligt, automatiseret), forenet endnu værre (hver klient er individuel) og generelt fyldt med klager ("du fortæller mig, at serveren blev sat op, men nu er den gået ned, det er din skyld!!!111"). Derfor, hvis værten hjælper dig med noget, vil han forsøge at gøre det så enkelt og bekvemt som muligt. Fordi det er urentabelt at gøre det vanskeligt, i det mindste set ud fra arbejdsomkostningerne for ingeniørerne på denne samme hoster (men situationer er anderledes, se ansvarsfraskrivelse). Dette betyder ikke, at værten nødvendigvis vil gøre alting dårligt. Men det er slet ikke et faktum, at han vil gøre præcis, hvad du virkelig havde brug for.
Det ser ud til, at sagen er ret indlysende, men flere gange i min praksis er jeg stødt på det faktum, at virksomheder begyndte at stole lidt mere på deres hostingudbyder, end de burde, og det førte ikke til noget godt. Jeg var nødt til at forklare udførligt og detaljeret, at ikke en eneste SLA ville dække tab fra nedetid (der er undtagelser, men normalt er det meget, MEGET dyrt for klienten), og at hosteren slet ikke er klar over, hvad der sker i kundernes infrastruktur (bortset fra meget generelle indikatorer). Og hosteren laver heller ikke sikkerhedskopier til dig. Situationen er endnu værre, hvis du har mere end én vært. I tilfælde af problemer mellem dem, vil de bestemt ikke finde ud af for dig, hvad der gik galt.
Faktisk er motiverne her nøjagtig de samme, som når man vælger "in-house admin team vs outsource". Hvis risikoen er beregnet, kvaliteten er tilfredsstillende, og virksomheden har ikke noget imod det, hvorfor så ikke prøve det. På den anden side er netværket et af de mest basale lag af infrastruktur, og det er næppe værd at overlade det til eksterne fyre, hvis du allerede selv understøtter alt andet.
I hvilke tilfælde er der brug for en netværker?
Dernæst vil vi tale specifikt om moderne fødevarevirksomheder. Med operatører og virksomhed er alt klart, plus eller minus - lidt har ændret sig der i de seneste år, og der var brug for netværkere der før, og de er nødvendige nu. Men med de samme "unge og vovede" er tingene ikke så klare. Ofte placerer de hele deres infrastruktur i skyerne, så de behøver ikke engang administratorer - bortset fra administratorerne af de samme skyer, selvfølgelig. Infrastrukturen er på den ene side ret simpel i sit design, på den anden side er den godt automatiseret (ansible/puppet, terraform, ci/cd... well, you know). Men selv her er der situationer, hvor du ikke kan undvære en netværksingeniør.
Eksempel 1, klassisk
Antag, at en virksomhed starter med én server med en offentlig IP-adresse, som er placeret i et datacenter. Så er der to servere. Så mere... Før eller siden vil der være behov for et privat netværk mellem serverne. Fordi "ekstern" trafik er begrænset både af båndbredde (ikke mere end 100 Mbit/s for eksempel) og af mængden af downloadede/uploadede pr. måned (forskellige hostere har forskellige takster, men båndbredde til omverdenen er normalt meget dyrere end en privat netværk).
Hosteren tilføjer yderligere netværkskort til serverne og inkluderer dem i deres switche i et separat vlan. Et "fladt" lokalområde vises mellem serverne. Komfortabel!
Antallet af servere vokser, og trafikken på det private netværk vokser også - backups, replikationer mv. Hosteren tilbyder at flytte dig ind i separate switches, så du ikke forstyrrer andre klienter, og de ikke forstyrrer dig. Hosteren installerer nogle switche og konfigurerer dem på en eller anden måde - højst sandsynligt ved at efterlade ét fladt netværk mellem alle dine servere. Alt fungerer godt, men på et bestemt tidspunkt begynder problemerne: forsinkelser mellem værter stiger med jævne mellemrum, logfilerne klager over for mange arp-pakker i sekundet, og under en audit kneppede pentesteren hele dit lokale netværk og knækkede kun én server.
Hvad skal jeg gøre?
Opdel netværket i segmenter - vlans. Konfigurer din egen adressering i hvert vlan, vælg en gateway, der overfører trafik mellem netværk. Konfigurer acl på gatewayen for at begrænse adgangen mellem segmenter, eller installer endda en separat firewall i nærheden.
Eksempel 1, fortsat
Serverne er forbundet til LAN med én ledning. Kontakterne i stativerne er på en eller anden måde forbundet med hinanden, men hvis der sker et uheld i det ene stativ, falder yderligere tre tilstødende af. Ordninger findes, men der er tvivl om deres relevans. Hver server har sin egen offentlige adresse, som udstedes af hosteren og er bundet til racket. De der. Ved flytning af en server skal adressen ændres.
Hvad skal jeg gøre?
Tilslut serverne ved hjælp af LAG (Link Aggregation Group) med to ledninger til switchene i racket (de skal også være redundante). Reserver forbindelserne mellem stativerne og konverter dem til en "stjerne" (eller den nu fashionable CLOS), så tabet af et stativ ikke påvirker de andre. Vælg "centrale" racks, hvori netværkskernen skal være placeret, og hvor andre racks skal tilsluttes. Sæt samtidig offentlig adressering i stand, tag fra hosteren (eller fra RIR, hvis det er muligt) et undernet, som du selv (eller gennem hosteren) annoncerer til verden.
Kan alt dette klares af en "almindelig" systemadministrator, som ikke har dybt kendskab til netværk? Ikke sikker. Vil værten gøre dette? Måske vil det, men du skal bruge en ret detaljeret teknisk specifikation, som nogen også skal udarbejde. og derefter kontrollere, at alt er gjort korrekt.
Eksempel 2: Sky
Lad os sige, at du har en VPC i en offentlig sky. For at få adgang fra kontoret eller den lokale del af infrastrukturen til det lokale netværk inde i VPC'en, skal du konfigurere en forbindelse via IPSec eller en dedikeret kanal. På den ene side er IPSec billigere, pga ingen grund til at købe ekstra hardware; du kan oprette en tunnel mellem din server med en offentlig adresse og skyen. Men - forsinkelser, begrænset ydeevne (da kanalen skal krypteres), plus ugaranteret forbindelse (da adgang er via det almindelige internet).
Hvad skal jeg gøre?
Opret en forbindelse gennem en dedikeret kanal (for eksempel kalder AWS det Direct Connect). For at gøre dette skal du finde en partneroperatør, der vil forbinde dig, beslutte dig for det forbindelsespunkt, der er tættest på dig (både dig til operatøren og operatøren til skyen), og til sidst konfigurere alt. Er det muligt at gøre alt dette uden en netværksingeniør? Sikkert ja. Men hvordan man fejlfinder uden ham i tilfælde af problemer er ikke længere så klart.
Der kan også være problemer med tilgængelighed mellem skyer (hvis du har en multicloud) eller problemer med forsinkelser mellem forskellige regioner mv. Selvfølgelig er der nu dukket mange værktøjer op, der øger gennemsigtigheden af, hvad der sker i skyen (de samme Thousand Eyes), men disse er alle værktøjerne fra en netværksingeniør og ikke en erstatning for ham.
Jeg kunne skitsere et dusin flere sådanne eksempler fra min praksis, men jeg synes, det er klart, at teamet, der starter fra et vist niveau af infrastrukturudvikling, skal have en person (helst mere end én), der ved, hvordan netværket fungerer og kan konfigurere netværksudstyr og ordne problemer, hvis de opstår. Tro mig, han vil have noget at lave
Hvad skal en netværker vide?
Det er slet ikke nødvendigt (og endda nogle gange skadeligt) for en netværksingeniør kun at beskæftige sig med netværket og intet andet. Selvom vi ikke overvejer muligheden med en infrastruktur, der næsten udelukkende lever i den offentlige sky (og hvad man end må sige, så bliver den mere og mere populær), og tager for eksempel on-premise eller private clouds, hvor om "kun viden på CCNP-niveau" "Du går ikke.
Ud over, faktisk, netværk - selvom der simpelthen er et uendeligt felt at studere, selvom du kun koncentrerer dig om et område (udbydernetværk, virksomheder, datacentre, Wi-Fi ...)
Selvfølgelig vil mange af jer nu huske Python og anden "netværksautomatisering", men dette er kun en nødvendig, men ikke en tilstrækkelig betingelse. For at en netværksingeniør kan "med succes slutte sig til holdet", skal han være i stand til at tale det samme sprog med både udviklere og andre administratorer/udviklere. Hvad betyder det?
- være i stand til ikke kun at arbejde i Linux som bruger, men også at administrere det, i det mindste på sysadmin-jun-niveau: installer den nødvendige software, genstart en mislykket tjeneste, skriv en simpel systemd-enhed.
- Forstå (i hvert fald i generelle vendinger), hvordan netværksstakken fungerer i Linux, hvordan netværket fungerer i hypervisorer og containere (lxc / docker / kubernetes).
- Selvfølgelig kunne arbejde med ansible/kok/dukke eller et andet SCM system.
- Der skal skrives en separat linje om SDN og netværk til private skyer (for eksempel TungstenFabric eller OpenvSwitch). Dette er endnu et enormt lag af viden.
Kort fortalt beskrev jeg en typisk T-form specialist (som det er moderne at sige nu). Det virker ikke som noget nyt, men baseret på interviewerfaring kan ikke alle netværksingeniører prale af viden om mindst to emner fra listen ovenfor. I praksis gør manglen på viden "på beslægtede områder" det meget vanskeligt ikke kun at kommunikere med kolleger, men også at forstå de krav, som erhvervslivet stiller til netværket, som projektets laveste infrastruktur. Og uden denne forståelse bliver det sværere at forsvare dit synspunkt og "sælge" det til erhvervslivet.
På den anden side giver den samme vane med at "forstå hvordan systemet fungerer" netværkere en meget god fordel i forhold til forskellige "generalister", som kender til teknologier fra artikler på Habré/medium og chats på Telegram, men som absolut ikke har nogen idé om, hvordan principper virker denne eller hin software på? Og viden om visse mønstre erstatter som bekendt med succes viden om mange fakta.
Konklusioner, eller bare TL;DR
- En netværksadministrator (som en DBA eller VoIP-ingeniør) er en specialist med en ret snæver profil (i modsætning til systemadministratorer/devs/SRE), hvis behov ikke opstår med det samme (og måske ikke opstår i lang tid, faktisk) . Men hvis det opstår, er det usandsynligt, at det vil blive erstattet af ekstern ekspertise (outsource eller almindelige generelle administratorer, "som også passer netværket"). Hvad der er noget mere trist er, at behovet for sådanne specialister er lille, og betinget, i en virksomhed med 800 programmører og 30 devops/administratorer, er der måske kun to netværkere, der gør et fremragende stykke arbejde med deres ansvar. De der. markedet var og er meget, meget lille, og med en god løn – endnu mindre.
- På den anden side skal en god netværker i den moderne verden ikke kun kende selve netværkene (og hvordan man automatiserer deres konfiguration), men også hvordan de operativsystemer og software, der kører oven på disse netværk, interagerer med dem. Uden dette vil det være ekstremt svært at forstå, hvad dine kollegaer beder dig om og at formidle (rimeligt) dine ønsker/krav til dem.
- Der er ingen sky, det er bare en andens computer. Du skal forstå, at brug af offentlige/private skyer eller tjenester fra en hostingudbyder "der gør alt for dig på nøglefærdig basis" ikke ændrer på det faktum, at din applikation stadig bruger netværket, og problemer med det vil påvirke driften af din ansøgning. Dit valg er, hvor kompetencecentret skal ligge, som skal stå for netværket af dit projekt.
Kilde: www.habr.com