På tidspunktet for denne artikels skrivning gav en søgning på en populær jobsøgningsside med de søgeord "Netværksingeniør" omkring tre hundrede jobopslag i hele Rusland. Til sammenligning giver en søgning på frasen "systemadministrator" næsten 2,5 tusinde jobopslag, mens "DevOps-ingeniør" næsten giver 800.
Betyr det, at netværkere ikke længere er nødvendige i en tid med dominerende cloud-teknologier, Docker, Kubernetes og alomfattende offentlig Wi-Fi?
Lad os dykke ind (c)
Lad os lære hinanden at kende. Mit navn er Alexey, og jeg er netværker.
Jeg har arbejdet med netværk i over 10 år og har over 15 års erfaring med forskellige *nix-systemer (jeg har haft mulighed for at arbejde med både Linux og FreeBSD). Jeg har arbejdet hos telekommunikationsoperatører, i store virksomheder, der betragtes som "enterprise", og for tiden arbejder jeg i en "ung og dristig" fintech, hvor cloud-løsninger, DevOps, Kubernetes og andre skræmmende ord, der helt sikkert vil gøre mig og mine kolleger overflødige. Engang. Måske.
disclaimer: "I vores liv er ikke alt, altid og overalt, og nogle ting, nogle gange og nogle steder" (c) Maxim Dorofeev.
Alt det følgende kan og bør betragtes som forfatterens personlige mening, der ikke gør krav på at være den endegyldige sandhed, og ikke engang som en fuldgyldig undersøgelse. Alle karakterer er fiktive, alle ligheder er tilfældige.
Velkommen til min verden.
Hvor kan man egentlig møde netværkere?
1. Telekommunikationsoperatører, servicevirksomheder og andre integratorer. Her er det enkelt: netværk er for dem en forretning. De sælger enten direkte forbindelsen (operatører) eller tilbyder tjenester til opstart/vedligeholdelse af deres kunders netværk.
Der er meget erfaring her, men ikke særlig mange penge (medmindre du er direktør eller en succesfuld salgsleder). Alligevel, hvis du kan lide netværk, og du er kun i starten af din karriere, vil en karriere i supporten hos en mindre operatør faktisk være en ideel startpunkt (i de store virksomheder er alt meget skemalagt, og der er lidt plads til kreativitet). Og historierne om, at man kan rykke fra at være en weekendingeniør til C-level manager på få år, er også reelle, selvom de er sjældne af åbenlyse grunde. Behovet for medarbejdere er altid til stede, fordi personaleomsætningen faktisk sker. Det er både godt og skidt på samme tid — der er altid ledige stillinger, men ofte forsvinder de mest aktive/kloge forholdsvis hurtigt til højere stillinger eller til andre, mere 'behagelige' steder.
2. Betinget 'enterprise'. Uanset om virksomhedens primære aktivitet er relateret til IT eller ej, er den vigtigste ting, at den har en IT-afdeling, der håndterer driften af virksomhedens interne systemer, herunder netværket på kontorerne, kommunikationskanaler til filialer osv. Funktionen som netværkstekniker i sådanne virksomheder kan 'fungerende' udføres af en systemadministrator (hvis netværksinfrastrukturen er lille, eller det håndteres af en ekstern leverandør), mens netværksteknikeren, hvis han findes, også kan tage sig af telefoni og SAN (bare lige for at nævne det). Lønningerne varierer - det afhænger i høj grad af virksomhedens margin, størrelse og struktur. Jeg har arbejdet med virksomheder, hvor Cisco var overrendt, og virksomheder hvor netværket var bygget af affald, pinde og blå isoleringstejp, og hvor serverne sjældent blev opdateret (skal jeg nævne, at der heller ikke var nogen reserver?). Erfaringen her er betydeligt mindre, og den vil næsten helt sikkert være præget af stram vendor-lock, eller 'hvordan man får noget ud af ingenting'. Personligt fandt jeg det ekstremt kedeligt, selvom mange kan lide det - alt er ret roligt og forudsigeligt (hvis vi taler om store virksomheder), 'do-re mis-myndigt', osv. Mindst en gang om året siger en stor leverandør, at de har opfundet et nyt mega-super-duper-system, der automatisk håndterer alt, så alle systemadministratorer og netværksteknikere kan fyres, og kun et par kan blive tilbage til at klikke på knapperne i et flot interface. Virkeligheden er dog, at selvom man abstraherer fra omkostningerne ved løsningen, så vil netværksteknikerne ikke forsvinde. Ja, måske vil der i stedet være et webinterface (men ikke længere for et bestemt stykke hardware, men for et stort system, der styrer dusinvis og hundreder af sådanne enheder), men man vil stadig have brug for viden om 'hvordan alt indeni er opbygget'.
3. Produktvirksomheder, hvis indtægt kommer fra udvikling (og ofte drift) af et eller andet software eller platform - netop det produkt. Normalt er de små og agile, de er langt fra at have størrelsen og bureaukratiet i store virksomheder. Det er her, de såkaldte DevOps, Kubernetes, Docker og andre skræmmende ord er massivt til stede, og som i høj grad vil gøre netværket og netværksteknikere til en unødvendig relikt.
Hvordan adskiller en netværkstekniker sig fra en systemadministrator?
I folks uden IT-forståelse ser det som intet. Både den ene og den anden kigger ind i en sort skærm og skriver nogle formularer, nogle gange mumlende bandeord.
For programmørerne er det måske kun et emneområde. Systemadministratorer administrerer servere, netværksteknikere administrerer switches og routere. Nogle gange administreres de dårligt, og alt falder ned. I tilfælde af noget mærkeligt er netværksteknikerne også skyldige. Just because fuck you, that’s why.
I virkeligheden er den vigtigste forskel tilgang til arbejdet. Måske er det blandt netværksteknikerne, at tilgangen "Den virker — lad være med at røre ved den!" er mest udbredt. At gøre en given opgave (inden for én leverandør) kan som regel kun gøres på én måde, hele konfigurationen af apparatet — den ligger lige foran dig. Fejlen koster meget, og nogle gange rigtig meget (for eksempel at man skal køre flere hundrede kilometer for at genstarte routeren, mens flere tusinde mennesker sidder uden forbindelse — en helt almindelig situation for en teleserviceudbyder).
Jeg mener, det er grunden til, at netværksteknikere på den ene side er ekstremt motiverede for netværksstabilitet (og ændringer er den største fjende af stabilitet), og på den anden side deres viden går dybere snarere end bredere (man behøver ikke vide, hvordan man konfigurerer dusinvis af forskellige dæmoner, man skal kende teknologierne og deres implementering hos den specifikke hardwareleverandør). Derfor er en systemadministrator, der har googlet, hvordan man konfigurerer VLAN på en Cisco — stadig ikke en netværkstekniker. Og det er tvivlsomt, at han effektivt kan vedligeholde (og fejlsøge) et mere eller mindre komplekst netværk.
Men hvorfor er en netværkstekniker nødvendig, hvis du har en hoster?
For ekstra penge (og hvis du er en meget stor og værdsat kunde — måske endda gratis, 'for venskabets skyld') vil datacenteringeniører konfigurere dine switches efter dine behov, og måske endda hjælpe med at etablere BGP-forbindelsen med udbydere (hvis du har dit eget subnet ip-adresser til annoncering).
Det primære problem er, at datacentret ikke er din IT-afdeling; det er en separat virksomhed, hvis mål er at opnå profit. Inklusive fra dig som klient. Datacentret leverer racks, sikrer elektricitet og køling, samt giver en vis "default" forbindelse til internettet. Baseret på denne infrastruktur kan datacentret placere dit udstyr (colocation), leje en server til dig (dedicated server) eller tilbyde managed services (f.eks. OpenStack eller K8s). Men datacentrets forretning (normalt) omfatter ikke administration af kunders infrastruktur, fordi denne proces er ret arbejdskrævende, dårligt automatiseret (og i et ordentligt datacenter er alt, hvad der kan automatiseres, automatiseret), endnu sværere at standardisere (hver kunde er unik) og i det hele taget kan føre til krav ("I satte mig en server op, men nu er den gået ned, det er jeres skyld!!!111"). Derfor, hvis hoster vil hjælpe dig med noget, vil de forsøge at gøre det så simpelt og "standardiseret" som muligt. At gøre det kompliceret er nemlig ikke økonomisk fordelagtigt, i det mindste set fra ingeniørernes arbejdsbyrde i den pågældende hoster (men situationer kan variere, se disclaimer). Det betyder ikke, at hosteren nødvendigvis vil gøre alt dårligt. Men det er slet ikke sikkert, at de vil gøre præcis det, du har brug for.
Det virker måske indlysende, men jeg har flere gange oplevet i min praksis, at virksomheder begyndte at stole på deres hostingudbyder lidt mere, end de burde, og det førte ikke til noget godt. Jeg måtte i lang tid forklare, at ingen SLA dækker tab fra nedetid (der er undtagelser, men normalt er det meget, MEGET dyrt for klienten), og at hosteren slet ikke er informeret om, hvad der sker i kundernes infrastruktur (bortset fra meget generelle oplysninger). Og hosteren laver heller ikke backups for dig. Det bliver endnu værre, hvis du har mere end én hoster. I tilfælde af problemer mellem dem vil de bestemt ikke finde ud af, hvad der gik galt for dig.
Motiverne her er præcis de samme som ved valget mellem "eget adminteam vs outsourcing". Hvis risiciene er vurderet, kvaliteten er tilfredsstillende, og virksomheden er åben for det — hvorfor ikke give det et forsøg? På den anden side er netværket et af de mest grundlæggende lag i infrastrukturen, og det vil næppe være klogt at overlade det til eksterne folk, når alt andet allerede støttes af jer selv.
Hvornår har man brug for en netværkstekniker?
I det følgende vil vi fokusere på moderne produktbaserede virksomheder. Med operatører og enterprise-sektoren er det mere eller mindre klart — der har ikke været mange ændringer de seneste år, og netværksteknikere har altid været nødvendige. Men med de "unge og dristige" er tingene ikke så entydige. Oftest placerer de hele deres infrastruktur i skyen, så de har ikke rigtig brug for administratorer — bortset fra administratorerne af selve skyen, selvfølgelig. Infrastrukturen er, på den ene side, relativt simpel i sin opbygning, men på den anden side godt automatiseret (ansible/puppet, terraform, ci/cd... ja, I kender det). Men selv her er der situationer, hvor man ikke kan undvære en netværkstekniker.
Eksempel 1, klassisk
Antag, at virksomheden starter med én server med en offentlig IP-adresse, som står i datacenteret. Så kommer der en server mere. Så flere... Rigtigt eller forkert, der opstår et behov for et privat netværk mellem serverne. Fordi "ekstern" trafik er begrænset både i båndbredde (højst 100 Mbit/s for eksempel) og i den mængde data, der downloades/overføres per måned (forskellige udbydere har forskellige takster, men båndbredden til den eksterne verden er generelt dyrere end et privat netværk).
Udbyderen tilføjer ekstra netværkskort til serverne og tilslutter dem til deres switches i et separat VLAN. Der opstår en "flad" lokalnetværk mellem serverne. Det er praktisk!
Antallet af servere vokser, og trafikken i det private netværk stiger også — backups, replikationer osv. Hostingudbyderen tilbyder at adskille jer i separate switche, så I ikke forstyrrer hinanden. Hostingudbyderen installererer nogle switche og konfigurerer dem på en eller anden måde — sandsynligvis med én flad netværk imellem alle jeres servere. Alt fungerer godt, men på et tidspunkt opstår der problemer: der opstår periodiske forsinkelser mellem værterne, der er klager i logfilerne over for mange arp-pakker pr. sekund, og en pentester fik adgang til hele jeres lokale netværk under en audit ved kun at kompromittere én server.
Hvad skal der gøres?
Opdel netværket i segmenter — vlan'er. Opsæt forskellige adresser i hver vlan, og dediker en gateway, som vil videresende trafik mellem netværkene. Konfigurer ACL på gatewayen for at begrænse adgangen mellem segmenterne, eller sæt en separat firewall ved siden af.
Eksempel 1, fortsat
Serverne er forbundet til det lokale netværk med et enkelt kabel. Switche i rackene er på en eller anden måde forbundet til hinanden, men ved en fejl i et rack falder yderligere tre nærliggende fra. Der findes diagrammer, men deres aktualitet er tvivlsom. Hver server har sin egen offentlige adresse, som udleveres af hostingudbyderen og er knyttet til racken. Det vil sige, at adressen skal ændres, når serveren flyttes.
Hvad skal der gøres?
Forbind serverne med LAG (Link Aggregation Group) med to kabler til switche i rackene (disse skal også være redundant). Forbindelserne mellem rackene skal være redundant og gøres til en "stjerne" (eller den aktuelle CLOS), så uheld i ét rack ikke påvirker de andre. Dediker "centrale" racks, som vil rumme det netværksmæssige kerne og tilkobles andre racks. Samtidig bringe den offentlige adressering i orden, tage et subnet fra hostingudbyderen (eller fra RIR, hvis muligt), som selvstændigt (eller gennem hostingudbyderen) kan annonceres til verden.
Kan alt dette gøres af en "almindelig" systemadministrator uden dybe netværkskendskaber? Ikke sikker. Vil hostingudbyderen gøre det? Måske, men der kræves en ret detaljeret specifikation fra jer, som også skal skrives af nogen. Og derefter skal det kontrolleres, at alt er gjort korrekt.
Eksempel 2. Cloud
Lad os sige, at du har et VPC i en offentlig cloud. For at få adgang fra kontoret eller on-prem-delen af infrastrukturen til det lokale netværk inden for VPC, skal du konfigurere en forbindelse via IPSec eller en dedikeret linje. På den ene side er IPSec billigere, da du ikke behøver at købe ekstra hardware; du kan konfigurere en tunnel mellem din server med offentlig adresse og cloud’en. Men – der er forsinkelser, begrænsede ydelser (da linjen skal krypteres), plus en ikke-garanteret forbindelsesmulighed (da adgangen sker via almindeligt internet).
Hvad skal der gøres?
Opret forbindelse via en dedikeret linje (for eksempel kaldes det hos AWS Direct Connect). For at gøre dette skal du finde en partneroperatør, der kan forbinde dig, bestemme den nærmeste tilslutningspunkt (både for dig til operatøren og operatøren til cloud’en), og endelig konfigurere alt. Kan dette gøres uden en netværksingeniør? Sikkert ja. Men hvordan man fejlsøger det uden ham i tilfælde af problemer - det er ikke så klart.
Der kan også opstå problemer med tilgængeligheden mellem clouds (hvis du har multi-cloud) eller problemer med forsinkelser mellem forskellige regioner osv. Uden tvivl er der kommet mange værktøjer, der øger gennemsigtigheden af, hvad der sker i cloud’en (det samme Thousand Eyes), men det er alle værktøjer til netværksingeniøren, ikke hans erstatning.
Jeg kunne finde på ti sådanne eksempler fra min praksis, men jeg tror, det er klart, at i et team, når infrastrukturen når et bestemt udviklingsniveau, skal der være en person (eller helst flere), der ved, hvordan netværket fungerer, kan konfigurere netværksudstyr og håndtere problemer, hvis de opstår. Tro mig, han vil have nok at lave.
Hvad skal en netværksingeniør vide?
Det er slet ikke nødvendigt (og endda, nogle gange, skadelig), for en netværksingeniør kun at beskæftige sig med netværket og intet andet. Selv hvis man ikke betragter scenariet med en infrastruktur, der næsten udelukkende lever i en offentlig cloud (som uundgåeligt bliver mere og mere populær), og tager for eksempel on premise eller private clouds, hvor alene 'viden på CCNP-niveau' ikke er tilstrækkelig.
Udover selve netværkene – selvom her er et uendeligt felt til at lære, selv hvis man kun koncentrerer sig om en bestemt retning (udbydernetværk, enterprise, datacentre, wifi…)
Selvfølgelig vil mange af jer nu tænke på Python og anden "netværksautomatisering", men det er kun en nødvendig, men ikke tilstrækkelig betingelse. For at en netværksingeniør kan "integrere sig vellykket i teams", skal han kunne kommunikere med både udviklere og kollegaer som administratorer/devops. Hvad betyder det?
- At kunne arbejde i Linux ikke blot som bruger, men også administrere det, i det mindste på niveau med en junior sysadmin: installere den nødvendige software, genstarte en afbrudt tjeneste, skrive en simpel systemd-enhed.
- At forstå (i det mindste groft), hvordan netværksstakken fungerer i Linux, og hvordan netværket er konstrueret i hypervisorer og containere (lxc / docker / kubernetes).
- Selvfølgelig skal man kunne arbejde med ansible/chef/puppet eller et andet SCM-system.
- Der bør også nævnes SDN og netværk for private skyer (f.eks. TungstenFabric eller OpenvSwitch). Dette er endnu et enormt vidensområde.
Kort sagt har jeg beskrevet en typisk T-formet specialist (som det nu er på mode at sige). Tilsyneladende er der ikke noget nyt, men erfaringen fra interviews viser, at ikke alle netværksingeniører kan prale med kendskab til mindst to emner fra listen ovenfor. I praksis gør manglen på viden i "relaterede områder" kommunikationen med kolleger meget vanskeligere, samt forståelsen af de krav, som forretningen stiller til netværket som den lavtliggende infrastruktur i projektet. Uden denne forståelse bliver det sværere at argumentere for sit synspunkt og "sælge" det til forretningen.
På den anden side giver den samme vane med "at finde ud af, hvordan systemet fungerer" netværksfolk en meget stor fordel i forhold til forskellige "specialister med bred viden", der kun kender til teknologierne gennem artikler på Habr/Medium og chats i Telegram, men som slet ikke har nogen anelse om, hvilke principper der ligger til grund for denne eller hin software. At kende visse regler kan som bekendt ofte erstatte viden om mange faktiske forhold.
Konklusioner, eller blot TL;DR
- Netværksadministratorer (ligesom DBA'er eller VoIP-ingeniører) er specialister med et ret snævert fokus (i modsætning til systemadministratorer/devops/SRE), og behovet for dem opstår ikke nødvendigvis straks (og kan i realiteten tage lang tid at materialisere sig). Men når behovet så opstår, vil det næppe kunne dækkes af eksterne specialister (outsourcing eller almindelige administratorer med bredere kompetencer, "som også holder øje med netværket"). Desværre er efterspørgslen efter sådanne specialister lille, og i en virksomhed med 800 programmører og 30 devops/administrationsfolk kan der være kun to netværksfolk, der klarer sine opgaver til perfektion. Det vil sige, at markedet har været og stadig er ret lille, og det så at sige med en god løn - endnu mindre.
- Omvendt skal en god netværksadministrator i den moderne verden ikke kun vide noget om netværk (og hvordan man automatiserer deres konfiguration), men også forstå, hvordan operativsystemer og software, der kører oven på disse netværk, interagerer med dem. Uden denne viden vil det være ekstremt vanskeligt at forstå, hvad dine kolleger beder om, og retfærdiggøre dine ønsker/krav over for dem.
- Der er ikke noget cloud, det er bare en andens computer. Det er vigtigt at forstå, at brugen af offentlige/private clouds eller tjenester fra hostingudbydere, "der gør alt for dig", ikke fjerner det faktum, at din applikation stadig bruger netværket, og problemer med det vil påvirke din applikations funktionalitet. Dit valg er, hvor kompetencecentret, der skal være ansvarligt for dit projekts netværk, skal ligge.
Kilde: habr.com
