Da denne artikkelen ble skrevet, returnerte et søk på en populær jobbside etter uttrykket "Nettverksingeniør" rundt tre hundre ledige stillinger i hele Russland. Til sammenligning gir et søk etter uttrykket "systemadministrator" nesten 2.5 tusen ledige stillinger, og "DevOps-ingeniør" - nesten 800.
Betyr dette at nettverksbrukere ikke lenger er nødvendig i tider med seirende skyer, Docker, Kubernetes og allestedsnærværende offentlig Wi-Fi?
La oss finne ut av det (c)
La oss bli kjent. Jeg heter Alexey, og jeg er en nettverker.
Jeg har vært involvert i nettverk i mer enn 10 år og har jobbet med forskjellige *nix-systemer i mer enn 15 år (jeg hadde en sjanse til å fikle med både Linux og FreeBSD). Jeg jobbet i telekomoperatører, store selskaper som anses å være «enterprise», og nylig har jeg jobbet med «ung og vågal» fintech, der skyer, devops, kubernetes og andre skumle ord som definitivt vil gjøre meg og mine kolleger unødvendige. . En dag. Kan være.
ansvarsfraskrivelse: "I livet vårt er ikke alt alltid og overalt, men noe, noen ganger på steder" (c) Maxim Dorofeev.
Alt skrevet nedenfor kan og bør betraktes som forfatterens personlige mening, som ikke hevder å være den ultimate sannheten, eller til og med en fullverdig studie. Alle karakterer er fiktive, alle tilfeldigheter er tilfeldige.
Velkommen til min verden.
Hvor kan du til og med møte nettverkere?
1. Teleoperatører, tjenesteselskaper og andre integratorer. Alt er enkelt her: nettverket for dem er en bedrift. De selger enten direkte tilkobling (operatører) eller tilbyr tjenester for lansering/vedlikehold av kundenes nettverk.
Det er mye erfaring her, men ikke mye penger (med mindre du er en direktør eller en vellykket salgssjef). Og likevel, hvis du liker nettverk, og du bare er i begynnelsen av reisen din, vil en karriere til støtte for en eller annen ikke veldig stor operatør, selv nå, være et ideelt utgangspunkt (i føderale er alt veldig skriptet, og der er lite rom for kreativitet). Vel, historier om hvordan du kan vokse fra en ingeniør på vakt om noen år til en leder på C-nivå er også ganske ekte, selv om det er sjeldne, av åpenbare grunner. Det er alltid behov for personell, fordi omsetning skjer. Dette er både bra og dårlig på samme tid - det er alltid ledige plasser, derimot - ofte drar de mest aktive/smarte raskt enten for opprykk eller til andre, "varmere" steder.
2. Betinget «bedrift». Det spiller ingen rolle om hovedaktiviteten hans er relatert til IT eller ikke. Hovedsaken er at den har en egen IT-avdeling, som sikrer driften av selskapets interne systemer, inkludert nettverket på kontorer, kommunikasjonskanaler til filialer, etc. Funksjonene til en nettverksingeniør i slike selskaper kan utføres "deltid" av en systemadministrator (hvis nettverksinfrastrukturen er liten eller håndteres av en ekstern entreprenør), og en nettverksspesialist, hvis det er en, kan ved samtidig ta vare på telefoni og SAN (ikke bra). De betaler forskjellig - det avhenger i stor grad av lønnsomheten til virksomheten, størrelsen på selskapet og strukturen. Jeg jobbet med selskaper der Cisco-systemene regelmessig ble "lastet i fat", og med selskaper der nettverket ble bygget av avføring, pinner og blå tape, og serverne aldri ble oppdatert (unødvendig å si at ingen reserver ble gitt heller). Det er mye mindre erfaring her, og det vil nesten helt sikkert være i området streng leverandørlås, eller "hvordan lage noe ut av ingenting." Personlig syntes jeg det var veldig kjedelig, selv om mange liker det - alt er ganske målt og forutsigbart (hvis vi snakker om store selskaper), "dorakha-bahato", etc. Minst en gang i året sier en stor leverandør at de har kommet opp med et annet mega-super-duper-system som vil automatisere alt nå, og alle systemadministratorer og nettverksbrukere kan bli spredt, slik at et par kan trykke på knapper i et vakkert grensesnitt. Realiteten er at selv om vi ser bort fra kostnadene ved løsningen, vil ikke nettverksfolk gå noen vei derfra. Ja, kanskje i stedet for konsollen vil det igjen være et nettgrensesnitt (men ikke en spesifikk maskinvare, men et stort system som administrerer titalls og hundrevis av slike deler), men kunnskap om "hvordan alt fungerer inni" vil fortsatt være nødvendig.
3. Produktselskaper, hvis fortjeneste kommer fra utviklingen (og ofte driften) av programvare eller plattformer - det samme produktet. Vanligvis er de små og kvikke, de er fortsatt langt unna omfanget av foretak og deres byråkratisering. Det er her de samme devops, cubers, dockers og andre forferdelige ord blir funnet i massevis, noe som helt sikkert vil gjøre nettverks- og nettverksingeniørene til et unødvendig rudiment.
Hvordan er en nettverker forskjellig fra en systemadministrator?
I forståelsen av folk ikke fra IT - ingenting. Begge ser på den svarte skjermen og skriver noen trollformler, noen ganger med å banne.
I forståelsen av programmerere - kanskje etter fagområde. Systemadministratorer administrerer servere, nettverkere administrerer svitsjer og rutere. Noen ganger er administrasjonen dårlig, og alt faller sammen for alle. Vel, i tilfelle noe rart, har nettverksbyggerne også skylden. Bare fordi faen deg, det er derfor.
Faktisk er hovedforskjellen tilnærmingen til arbeid. Kanskje er det blant nettverkere at det er flest tilhengere av "Hvis det fungerer, ikke rør det!"-tilnærmingen. Som regel kan noe gjøres (innenfor én leverandør) på bare én måte; hele konfigurasjonen av boksen er rett der i håndflaten din. Kostnaden for en feil er høy, og noen ganger veldig høy (for eksempel må du reise flere hundre kilometer for å starte ruteren på nytt, og på dette tidspunktet vil flere tusen mennesker være uten kommunikasjon - en ganske vanlig situasjon for en teleoperatør) .
Etter min mening er dette grunnen til at nettverksingeniører på den ene siden er ekstremt høyt motiverte for nettverksstabilitet (og endring er stabilitetens hovedfiende), og for det andre går kunnskapen deres mer i dybden enn i bredden (det gjør du ikke trenger å kunne konfigurere dusinvis av forskjellige demoner, du må kjenne til teknologiene og implementeringen av dem fra en bestemt utstyrsprodusent). Det er derfor en systemadministrator som googlet hvordan man registrerer en vlan på et Cisco-system, ikke er en nettverksmann ennå. Og det er usannsynlig at han effektivt vil kunne støtte (samt feilsøke) et mer eller mindre komplekst nettverk.
Men hvorfor trenger du en nettverker hvis du har en hoster?
For ekstra penger (og hvis du er en veldig stor og elsket klient, kanskje til og med gratis, "som en venn"), vil datasenteringeniører konfigurere bryterne dine for å passe dine behov, og kanskje til og med hjelpe deg med å etablere et BGP-grensesnitt med leverandører (hvis du har ditt eget undernett av IP-adresser for kunngjøringen).
Hovedproblemet er at datasenteret ikke er din IT-avdeling, det er et eget selskap som har som mål å tjene penger. Blant annet på bekostning av deg som kunde. Datasenteret tilbyr stativer, gir dem strøm og kulde, og gir også noen "standard" tilkobling til Internett. Basert på denne infrastrukturen kan datasenteret være vert for utstyret ditt (colocation), leie ut en server til deg (dedikert server), eller gi en administrert tjeneste (for eksempel OpenStack eller K8s). Men virksomheten til et datasenter (vanligvis) er ikke administrasjon av klientinfrastruktur, fordi denne prosessen er ganske arbeidskrevende, dårlig automatisert (og i et normalt datasenter er alt mulig automatisert), enda verre enhetlig (hver klient er individuell) og generelt full av klager ("du forteller meg at serveren ble satt opp, men nå har den krasjet, alt er din feil!!!111"). Derfor, hvis vertskapet hjelper deg med noe, vil han prøve å gjøre det så enkelt og praktisk som mulig. Fordi det er ulønnsomt å gjøre det vanskelig, i det minste sett fra lønnskostnadene til ingeniørene til samme vert (men situasjonene er forskjellige, se ansvarsfraskrivelse). Dette betyr ikke at hosteren nødvendigvis vil gjøre alt dårlig. Men det er slett ikke et faktum at han vil gjøre akkurat det du virkelig trengte.
Det ser ut til at saken er ganske åpenbar, men flere ganger i min praksis har jeg støtt på det faktum at selskaper begynte å stole litt mer på sin hostingleverandør enn de burde, og dette førte ikke til noe bra. Jeg måtte forklare utførlig og detaljert at ikke en eneste SLA ville dekke tap fra nedetid (det finnes unntak, men vanligvis er det veldig, VELDIG dyrt for klienten) og at hosteren ikke i det hele tatt er klar over hva som skjer i kundenes infrastruktur (bortsett fra svært generelle indikatorer). Og vertskapet lager heller ikke sikkerhetskopier for deg. Situasjonen er enda verre hvis du har mer enn én vert. I tilfelle problemer mellom dem, vil de absolutt ikke finne ut for deg hva som gikk galt.
Faktisk er motivene her nøyaktig de samme som når du velger "in-house admin team vs outsource". Hvis risikoen er beregnet, kvaliteten er tilfredsstillende, og virksomheten har ikke noe imot, hvorfor ikke prøve det. På den annen side er nettverket et av de mest grunnleggende lagene av infrastruktur, og det er neppe verdt å overlate det til utenforstående karer hvis du allerede støtter alt annet selv.
I hvilke tilfeller trengs en nettverksholder?
Deretter vil vi snakke spesifikt om moderne matvareselskaper. Med operatører og foretak er alt klart, pluss eller minus – lite har endret seg der de siste årene, og det var behov for nettverksarbeidere der før, og de trengs nå. Men med de samme "unge og vågale" er ting ikke så klart. Ofte plasserer de hele infrastrukturen sin i skyene, så de trenger egentlig ikke engang administratorer - bortsett fra administratorene til de samme skyene, selvfølgelig. Infrastrukturen er på den ene siden ganske enkel i utformingen, på den andre siden er den godt automatisert (ansible/puppet, terraform, ci/cd... well, you know). Men selv her er det situasjoner når du ikke kan klare deg uten en nettverksingeniør.
Eksempel 1, klassisk
Anta at et selskap starter med én server med en offentlig IP-adresse, som ligger i et datasenter. Så er det to servere. Så mer... Før eller siden vil det være behov for et privat nettverk mellom servere. Fordi "ekstern" trafikk er begrenset både av båndbredde (ikke mer enn 100 Mbit/s for eksempel) og av volumet nedlastede/lastede opp per måned (ulike hostere har forskjellige tariffer, men båndbredde til omverdenen er vanligvis mye dyrere enn en privat nettverk).
Hosteren legger til flere nettverkskort til serverne og inkluderer dem i svitsjene deres i et eget vlan. Et "flat" lokalområde vises mellom servere. Komfortabel!
Antallet servere vokser, og trafikken på det private nettverket vokser også - sikkerhetskopiering, replikasjoner, etc. Hosteren tilbyr å flytte deg inn i separate brytere slik at du ikke forstyrrer andre klienter, og de ikke forstyrrer deg. Hosteren installerer noen brytere og konfigurerer dem på en eller annen måte - mest sannsynlig, og etterlater ett flatt nettverk mellom alle serverne dine. Alt fungerer bra, men på et bestemt tidspunkt begynner problemer: forsinkelser mellom verter øker med jevne mellomrom, loggene klager over for mange arp-pakker per sekund, og under en revisjon knullet pentesteren hele det lokale nettverket ditt, og knuste bare én server.
Hva skal gjøres?
Del nettverket inn i segmenter - vlans. Konfigurer din egen adressering i hvert vlan, velg en gateway som vil overføre trafikk mellom nettverk. Konfigurer acl på gatewayen for å begrense tilgangen mellom segmenter, eller installer en egen brannmur i nærheten.
Eksempel 1, fortsatt
Serverne er koblet til LAN med én ledning. Bryterne i stativene er på en eller annen måte koblet til hverandre, men hvis det skjer en ulykke i ett stativ, faller tre tilstøtende av. Ordninger eksisterer, men det er tvil om deres relevans. Hver server har sin egen offentlige adresse, som utstedes av hosteren og er knyttet til racket. De. Når du flytter en server, må adressen endres.
Hva skal gjøres?
Koble serverne ved hjelp av LAG (Link Aggregation Group) med to ledninger til bryterne i racket (de må også være overflødige). Reserver forbindelsene mellom stativene, konverter dem til en "stjerne"-type (eller den nå fasjonable CLOS), slik at tapet av ett stativ ikke påvirker de andre. Velg "sentrale" rack der nettverkskjernen skal være plassert og hvor andre rack skal kobles til. Sett samtidig offentlig adressering i orden, ta fra hosteren (eller fra RIR, hvis mulig) et subnett, som du selv (eller gjennom hosteren) annonserer til verden.
Kan alt dette gjøres av en "vanlig" systemadministrator som ikke har dyp kunnskap om nettverk? Ikke sikker. Vil vertskapet gjøre dette? Kanskje det vil det, men du trenger en ganske detaljert teknisk spesifikasjon, som noen også må utarbeide. og deretter kontrollere at alt er gjort riktig.
Eksempel 2: Sky
La oss si at du har en VPC i en offentlig sky. For å få tilgang fra kontoret eller den lokale delen av infrastrukturen til det lokale nettverket inne i VPC-en, må du konfigurere en tilkobling via IPSec eller en dedikert kanal. På den ene siden er IPSec billigere, fordi du trenger ikke å kjøpe ekstra maskinvare; du kan sette opp en tunnel mellom serveren din med en offentlig adresse og skyen. Men - forsinkelser, begrenset ytelse (siden kanalen må krypteres), pluss ugarantert tilkobling (siden tilgang er via vanlig Internett).
Hva skal gjøres?
Opprett en forbindelse gjennom en dedikert kanal (for eksempel kaller AWS det Direct Connect). For å gjøre dette, finn en partneroperatør som vil koble deg til, bestemme tilkoblingspunktet nærmest deg (både du til operatøren og operatøren til skyen), og til slutt, sett opp alt. Er det mulig å gjøre alt dette uten en nettverksingeniør? Sikkert ja. Men hvordan feilsøke uten ham i tilfelle problemer er ikke lenger så klart.
Det kan også være problemer med tilgjengelighet mellom skyer (hvis du har en multisky) eller problemer med forsinkelser mellom ulike regioner osv. Selvfølgelig har det dukket opp mange verktøy som øker åpenheten av hva som skjer i skyen (de samme Thousand Eyes), men disse er alle verktøyene til en nettverksingeniør, og ikke en erstatning for ham.
Jeg kunne skissert et dusin flere slike eksempler fra praksisen min, men jeg tror det er klart at teamet, med utgangspunkt i et visst nivå av infrastrukturutvikling, må ha en person (helst mer enn én) som vet hvordan nettverket fungerer og kan konfigurere nettverksutstyr og ordne opp i problemer hvis de oppstår. Tro meg, han vil ha noe å gjøre
Hva bør en nettverksarbeider vite?
Det er slett ikke nødvendig (og til og med noen ganger skadelig) for en nettverksingeniør å bare forholde seg til nettverket og ingenting annet. Selv om vi ikke vurderer alternativet med en infrastruktur som nesten utelukkende lever i den offentlige skyen (og uansett hva man kan si, den blir mer og mer populær), og tar for eksempel på premisser eller private skyer, der om "kunnskap på CCNP-nivå alene" "Du vil ikke dra.
I tillegg til, faktisk, nettverk - selv om det ganske enkelt er et uendelig felt for studier, selv om du kun konsentrerer deg om ett område (leverandørnettverk, bedrifter, datasentre, Wi-Fi ...)
Selvfølgelig vil mange av dere nå huske Python og annen "nettverksautomatisering", men dette er bare en nødvendig, men ikke en tilstrekkelig betingelse. For at en nettverksingeniør skal "bli med i teamet" må han kunne snakke samme språk med både utviklere og andre administratorer/utviklere. Hva betyr det?
- være i stand til ikke bare å jobbe i Linux som bruker, men også å administrere det, i det minste på sysadmin-jun-nivået: installer nødvendig programvare, start en mislykket tjeneste på nytt, skriv en enkel systemd-enhet.
- Forstå (i alle fall generelt sett) hvordan nettverksstakken fungerer i Linux, hvordan nettverket fungerer i hypervisorer og containere (lxc / docker / kubernetes).
- Selvfølgelig kunne jobbe med ansible/kokk/dukke eller annet SCM system.
- Det bør skrives en egen linje om SDN og nettverk for private skyer (for eksempel TungstenFabric eller OpenvSwitch). Dette er nok et stort kunnskapslag.
Kort fortalt beskrev jeg en typisk T-formspesialist (som det er mote å si nå). Det virker som ikke noe nytt, men basert på intervjuerfaring kan ikke alle nettverksingeniører skryte av kunnskap om minst to emner fra listen ovenfor. I praksis gjør mangelen på kunnskap "på relaterte felt" det svært vanskelig ikke bare å kommunisere med kolleger, men også å forstå kravene som virksomheten stiller til nettverket, som den laveste infrastrukturen i prosjektet. Og uten denne forståelsen blir det vanskeligere å forsvare synspunktet ditt og "selge" det til virksomheten.
På den annen side gir den samme vanen med å «forstå hvordan systemet fungerer» nettverksbrukere en veldig god fordel i forhold til ulike «generalister» som kjenner til teknologier fra artikler på Habré/medium og chatter på Telegram, men som absolutt ikke har peiling på hva prinsipper fungerer denne eller den programvaren etter? Og kunnskap om visse mønstre, som kjent, erstatter med suksess kunnskap om mange fakta.
Konklusjoner, eller bare TL;DR
- En nettverksadministrator (som en DBA- eller VoIP-ingeniør) er en spesialist med en ganske smal profil (i motsetning til systemadministratorer/utviklere/SRE), behovet for det oppstår ikke umiddelbart (og kanskje ikke oppstår på lenge, faktisk) . Men hvis det oppstår, vil det neppe bli erstattet av ekstern ekspertise (outsource eller vanlige generelle administratorer, "som også passer på nettverket"). Det som er noe tristere er at behovet for slike spesialister er lite, og betinget, i et selskap med 800 programmerere og 30 devops/administratorer, kan det bare være to nettverksarbeidere som gjør en utmerket jobb med sitt ansvar. De. markedet var og er veldig, veldig lite, og med god lønn - enda mindre.
- På den annen side må en god nettverksarbeider i den moderne verden ikke bare kjenne til selve nettverkene (og hvordan de kan automatisere konfigurasjonen), men også hvordan operativsystemene og programvaren som kjører på toppen av disse nettverkene samhandler med dem. Uten dette vil det være ekstremt vanskelig å forstå hva dine kollegaer ber deg om og å formidle (rimelig) dine ønsker/krav til dem.
- Det er ingen sky, det er bare en annens datamaskin. Du må forstå at bruk av offentlige/private skyer eller tjenestene til en vertsleverandør "som gjør alt for deg på nøkkelferdig basis" ikke endrer det faktum at applikasjonen din fortsatt bruker nettverket, og problemer med det vil påvirke driften av din søknad. Ditt valg er hvor kompetansesenteret skal ligge, som skal ha ansvaret for nettverket til prosjektet ditt.
Kilde: www.habr.com