Op het moment dat dit artikel werd geschreven, leverde een zoekopdracht op een populaire vacaturesite naar de uitdrukking ‘Netwerkingenieur’ ongeveer driehonderd vacatures op in heel Rusland. Ter vergelijking: een zoekopdracht naar de term “systeembeheerder” levert bijna 2.5 duizend vacatures op, en “DevOps engineer” - bijna 800.
Betekent dit dat netwerkers niet langer nodig zijn in tijden van zegevierende clouds, Docker, Kubernetes en alomtegenwoordige openbare wifi?
Laten we het uitzoeken (c)
Laten we kennis maken. Mijn naam is Alexey en ik ben een netwerker.
Ik ben al meer dan 10 jaar betrokken bij netwerken en werk al meer dan 15 jaar met verschillende *nix-systemen (ik heb de kans gehad om aan zowel Linux als FreeBSD te sleutelen). Ik heb gewerkt bij telecomoperatoren, grote bedrijven die als ‘enterprise’ worden beschouwd, en de laatste tijd heb ik gewerkt in ‘jonge en gedurfde’ fintech, waar clouds, devops, kubernetes en andere enge woorden die mij en mijn collega’s zeker overbodig zullen maken . Op een dag. Misschien.
disclaimer: "In ons leven is niet alles altijd en overal, maar iets, soms op plaatsen" (c) Maxim Dorofeev.
Alles wat hieronder wordt geschreven, kan en moet worden beschouwd als de persoonlijke mening van de auteur, die niet beweert de ultieme waarheid te zijn, of zelfs maar een volwaardige studie. Alle personages zijn fictief, alle toevalligheden zijn willekeurig.
Welkom in mijn wereld.
Waar kun je überhaupt netwerkers ontmoeten?
1. Telecomoperatoren, dienstverlenende bedrijven en andere integrators. Alles is hier eenvoudig: het netwerk voor hen is een bedrijf. Ze verkopen rechtstreeks connectiviteit (operatoren) of leveren diensten voor het lanceren/onderhouden van de netwerken van hun klanten.
Er is hier veel ervaring, maar niet veel geld (tenzij je directeur of een succesvolle verkoopmanager bent). En toch, als je van netwerken houdt, en je staat nog maar aan het begin van je reis, zal een carrière ter ondersteuning van een niet erg grote operator, zelfs nu nog, een ideaal startpunt zijn (in federale netwerken is alles erg scripted, en daar is weinig ruimte voor creativiteit). Nou ja, verhalen over hoe je in een paar jaar kunt uitgroeien van een dienstdoende ingenieur tot een C-level manager zijn ook behoorlijk reëel, hoewel zeldzaam, om voor de hand liggende redenen. Er is altijd behoefte aan personeel, want er is verloop. Dit is zowel goed als slecht - aan de andere kant zijn er altijd vacatures - vaak vertrekken de meest actieve/slimme mensen snel, hetzij voor promotie, hetzij naar andere, "warmere" oorden.
2. Voorwaardelijke ‘onderneming’. Het maakt niet uit of zijn hoofdactiviteit IT-gerelateerd is of niet. Het belangrijkste is dat het een eigen IT-afdeling heeft, die zorgt voor de werking van de interne systemen van het bedrijf, inclusief het netwerk in kantoren, communicatiekanalen naar filialen, enz. De functies van een netwerkingenieur in dergelijke bedrijven kunnen “parttime” worden uitgevoerd door een systeembeheerder (als de netwerkinfrastructuur klein is of wordt beheerd door een externe contractant), en een netwerkspecialist, als die er is, kan ter plaatse zorg tegelijkertijd voor telefonie en SAN (niet goed). Ze betalen anders - het hangt sterk af van de winstgevendheid van het bedrijf, de grootte van het bedrijf en de structuur. Ik heb gewerkt met bedrijven waar de Cisco-systemen regelmatig “in vaten werden geladen”, en met bedrijven waar het netwerk was opgebouwd uit uitwerpselen, sticks en blue tape, en de servers nooit werden bijgewerkt (onnodig te zeggen dat er ook geen reserves werden voorzien). Er is hier veel minder ervaring, en het zal vrijwel zeker op het gebied van strikte ‘vendor-lock’ zijn, oftewel ‘hoe je van niets iets kunt maken’. Persoonlijk vond ik het enorm saai, hoewel veel mensen het leuk vinden - alles is behoorlijk afgemeten en voorspelbaar (als we het over grote bedrijven hebben), "dorakha-bahato", enz. Minstens één keer per jaar zegt een grote leverancier dat ze een ander mega-super-duper-systeem hebben bedacht dat alles nu zal automatiseren en dat alle systeembeheerders en netwerkers verspreid kunnen worden, zodat er een paar overblijven om op knoppen te drukken in een prachtige interface. De realiteit is dat, zelfs als we de kosten van de oplossing negeren, netwerkers vanaf daar nergens heen zullen gaan. Ja, misschien zal er in plaats van de console weer een webinterface zijn (maar niet een specifiek stuk hardware, maar een groot systeem dat tientallen en honderden van dergelijke hardware beheert), maar kennis van "hoe alles binnenin werkt" zal nog steeds nodig zijn.
3. Productbedrijven, waarvan de winst voortkomt uit de ontwikkeling (en vaak ook de exploitatie) van een bepaalde software of platform – datzelfde product. Meestal zijn ze klein en wendbaar, ze zijn nog ver verwijderd van de schaal van ondernemingen en hun bureaucratisering. Het is hier dat diezelfde devops, cubers, dockers en andere vreselijke woorden massaal worden gevonden, wat het netwerk en de netwerkingenieurs zeker tot een onnodig rudiment zal maken.
Waarin verschilt een netwerker van een systeembeheerder?
In het begrip van mensen, niet van IT - niets. Ze kijken allebei naar het zwarte scherm en schrijven een paar spreuken, soms zachtjes vloekend.
In het begrip van programmeurs - misschien per vakgebied. Systeembeheerders beheren servers, netwerkers beheren switches en routers. Soms is de administratie slecht en valt alles voor iedereen in duigen. Als er iets vreemds gebeurt, zijn de netwerkers ook de schuldige. Gewoon omdat fuck you, daarom.
Het belangrijkste verschil is eigenlijk de aanpak van het werk. Misschien zijn het onder de netwerkers de meeste voorstanders van de ‘Als het werkt, raak het dan niet aan!’-benadering. In de regel kan iets (binnen één leverancier) maar op één manier worden gedaan; de volledige configuratie van de box ligt in de palm van uw hand. De kosten van een fout zijn hoog, en soms erg hoog (u zult bijvoorbeeld enkele honderden kilometers moeten reizen om de router opnieuw op te starten, en op dit moment zullen enkele duizenden mensen zonder communicatie zitten - een vrij gebruikelijke situatie voor een telecomoperator) .
Naar mijn mening is dit de reden waarom netwerkingenieurs aan de ene kant extreem gemotiveerd zijn voor netwerkstabiliteit (en verandering is de belangrijkste vijand van stabiliteit), en aan de andere kant gaat hun kennis meer diep dan breed (je hoeft niet je moet tientallen verschillende daemons kunnen configureren, je moet de technologieën en hun implementatie kennen van een specifieke fabrikant van apparatuur). Daarom is een systeembeheerder die heeft gegoogled hoe je een vlan op een Cisco-systeem registreert, nog geen netwerker. En het is onwaarschijnlijk dat hij een min of meer complex netwerk effectief kan ondersteunen (en ook problemen kan oplossen).
Maar waarom heb je een netwerker nodig als je een hoster hebt?
Voor extra geld (en als u een zeer grote en geliefde klant bent, misschien zelfs gratis, “als vriend”), zullen datacenteringenieurs uw switches configureren om aan uw behoeften te voldoen, en u misschien zelfs helpen een BGP-interface met providers op te zetten (als u een eigen subnet met IP-adressen heeft voor de aankondiging).
Het grootste probleem is dat het datacenter niet uw IT-afdeling is, maar een afzonderlijk bedrijf met als doel winst te maken. Ook ten koste van u als opdrachtgever. Het datacenter levert racks, voorziet ze van elektriciteit en koude, en biedt ook een aantal “standaard” connectiviteit met internet. Op basis van deze infrastructuur kan het datacenter uw apparatuur hosten (colocatie), een server aan u verhuren (dedicated server) of een managed service leveren (bijvoorbeeld OpenStack of K8s). Maar de business van een datacenter is (meestal) niet het beheer van de klantinfrastructuur, omdat dit proces behoorlijk arbeidsintensief is, slecht geautomatiseerd (en in een normaal datacenter is alles wat mogelijk is geautomatiseerd), uniform, nog erger (elke klant is individueel) en over het algemeen beladen met klachten (“je vertelt me dat de server is ingesteld, maar nu deze is gecrasht, het is allemaal jouw schuld!!!111”). Daarom, als de host je ergens mee helpt, zal hij proberen het zo eenvoudig en gemakkelijk mogelijk te maken. Omdat moeilijk doen niet rendabel is, althans vanuit het oogpunt van de arbeidskosten van de engineers van dezelfde hoster (maar de situaties zijn anders, zie disclaimer). Dit betekent niet dat de host noodzakelijkerwijs alles slecht zal doen. Maar het is helemaal geen feit dat hij precies zal doen wat je echt nodig had.
Het lijkt erop dat de zaak vrij voor de hand ligt, maar in mijn praktijk ben ik verschillende keren tegengekomen dat bedrijven iets meer op hun hostingprovider begonnen te vertrouwen dan zou moeten, en dit leidde niet tot iets goeds. Ik moest uitgebreid en gedetailleerd uitleggen dat geen enkele SLA de verliezen als gevolg van downtime zou dekken (er zijn uitzonderingen, maar meestal is het heel erg duur voor de klant) en dat de hoster helemaal niet op de hoogte is van wat er gebeurt in de infrastructuur van de klanten (behalve voor zeer algemene indicatoren). En de hoster maakt ook geen back-ups voor je. De situatie is nog erger als u meer dan één hoster heeft. Mochten er tussen hen problemen optreden, dan zullen zij zeker niet voor u uitzoeken wat er mis is gegaan.
Eigenlijk zijn de motieven hier precies dezelfde als bij de keuze voor “in-house admin team versus uitbesteden”. Als de risico's zijn berekend, de kwaliteit bevredigend is en het bedrijf het niet erg vindt, waarom probeer je het dan niet? Aan de andere kant is het netwerk een van de meest basale infrastructuurlagen, en het is nauwelijks de moeite waard om het aan externen over te laten als je al het andere zelf al ondersteunt.
In welke gevallen is een netwerker nodig?
Vervolgens zullen we het specifiek hebben over moderne voedingsbedrijven. Bij operators en ondernemingen is alles duidelijk, plus of min: daar is de afgelopen jaren weinig veranderd, en netwerkers waren daar eerder nodig, en ze zijn nu nodig. Maar met diezelfde ‘jonge en gedurfde’ dingen zijn de zaken niet zo duidelijk. Vaak plaatsen ze hun hele infrastructuur in de cloud, waardoor ze niet eens echt beheerders nodig hebben – behalve de beheerders van diezelfde clouds natuurlijk. De infrastructuur is enerzijds vrij eenvoudig van opzet, anderzijds is ze goed geautomatiseerd (weersibel/puppet, terraform, ci/cd... nou ja, weet je). Maar zelfs hier zijn er situaties waarin u niet zonder een netwerkingenieur kunt.
Voorbeeld 1, klassiek
Stel dat een bedrijf begint met één server met een openbaar IP-adres, die zich in een datacenter bevindt. Dan zijn er twee servers. Dan meer... Vroeg of laat zal er behoefte zijn aan een privénetwerk tussen servers. Omdat “extern” verkeer wordt beperkt door zowel de bandbreedte (niet meer dan 100Mbit/s bijvoorbeeld) als door het volume van gedownload/geüpload per maand (verschillende hosters hebben verschillende tarieven, maar bandbreedte naar de buitenwereld is meestal veel duurder dan een prive netwerk).
De host voegt extra netwerkkaarten toe aan de servers en neemt deze op in hun switches in een aparte vlan. Er verschijnt een “plat” lokaal gebied tussen servers. Comfortabel!
Het aantal servers groeit en het verkeer op het privénetwerk groeit ook: back-ups, replicaties, enz. De host biedt aan om u naar aparte schakelaars te verplaatsen, zodat u andere clients niet hindert, en zij ook niet. De host installeert enkele switches en configureert ze op de een of andere manier - hoogstwaarschijnlijk laat hij één plat netwerk achter tussen al uw servers. Alles werkt goed, maar op een gegeven moment beginnen de problemen: vertragingen tussen hosts nemen periodiek toe, de logs klagen over te veel arp-pakketten per seconde, en tijdens een audit heeft de pentester je hele lokale netwerk verpest, waarbij slechts één server kapot ging.
Wat moet er gedaan worden?
Verdeel het netwerk in segmenten - vlans. Configureer uw eigen adressering in elke vlan, selecteer een gateway die verkeer tussen netwerken overdraagt. Configureer acl op de gateway om de toegang tussen segmenten te beperken, of installeer zelfs een aparte firewall in de buurt.
Voorbeeld 1, vervolg
De servers zijn met één snoer verbonden met het LAN. De schakelaars in de racks zijn op de een of andere manier met elkaar verbonden, maar als er een ongeluk gebeurt in één rack, vallen er nog drie aangrenzende racks af. Er bestaan regelingen, maar er bestaan twijfels over de relevantie ervan. Elke server heeft zijn eigen openbare adres, dat wordt uitgegeven door de host en is gekoppeld aan het rack. Die. Bij het verhuizen van een server moet het adres gewijzigd worden.
Wat moet er gedaan worden?
Sluit de servers middels LAG (Link Aggregation Group) met twee snoeren aan op de switches in het rack (deze moeten tevens redundant zijn). Reserveer de verbindingen tussen de racks, bouw ze om naar een “ster”-type (of het inmiddels modieuze CLOS), zodat het wegvallen van het ene rack geen gevolgen heeft voor de andere. Selecteer “centrale” racks waarin de netwerkkern komt te staan en waar andere racks op worden aangesloten. Breng tegelijkertijd de openbare adressering op orde, neem van de hoster (of van RIR, indien mogelijk) een subnet, dat u zelf (of via de hoster) aan de wereld aankondigt.
Kan dit allemaal worden gedaan door een “gewone” systeembeheerder die geen diepgaande kennis van netwerken heeft? Niet zeker. Zal de hoster dit doen? Misschien wel, maar je hebt een vrij gedetailleerde technische specificatie nodig, die iemand ook moet opstellen. en controleer vervolgens of alles correct is uitgevoerd.
Voorbeeld 2: Wolk
Stel dat u een VPC in een openbare cloud heeft. Om vanaf het kantoor of een deel van de infrastructuur op locatie toegang te krijgen tot het lokale netwerk binnen de VPC, moet u een verbinding configureren via IPSec of een speciaal kanaal. Aan de ene kant is IPSec goedkoper, omdat U hoeft geen extra hardware aan te schaffen; u kunt een tunnel opzetten tussen uw server met een openbaar adres en de cloud. Maar - vertragingen, beperkte prestaties (aangezien het kanaal gecodeerd moet worden), plus ongegarandeerde connectiviteit (aangezien de toegang via het reguliere internet verloopt).
Wat moet er gedaan worden?
Breng een verbinding tot stand via een speciaal kanaal (AWS noemt dit bijvoorbeeld Direct Connect). Om dit te doen, zoekt u een partneroperator die u zal verbinden, bepaalt u het dichtstbijzijnde aansluitpunt (zowel u bij de operator als de operator bij de cloud) en stelt u ten slotte alles in. Is het mogelijk om dit allemaal te doen zonder een netwerkingenieur? Zeker wel. Maar hoe je zonder hem problemen kunt oplossen in geval van problemen is niet meer zo duidelijk.
Er kunnen ook problemen zijn met de beschikbaarheid tussen clouds (als je een multicloud hebt) of problemen met vertragingen tussen verschillende regio’s, enz. Natuurlijk zijn er nu veel tools verschenen die de transparantie vergroten van wat er in de cloud gebeurt (dezelfde Thousand Eyes), maar dit zijn allemaal tools van een netwerkingenieur en geen vervanging voor hem.
Ik zou nog een tiental van dergelijke voorbeelden uit mijn praktijk kunnen schetsen, maar ik denk dat het duidelijk is dat het team, beginnend vanaf een bepaald niveau van infrastructuurontwikkeling, een persoon moet hebben (bij voorkeur meer dan één) die weet hoe het netwerk werkt en deze kan configureren. netwerkapparatuur en lost problemen op als deze zich voordoen. Geloof me, hij zal iets te doen hebben
Wat moet een netwerker weten?
Het is helemaal niet nodig (en soms zelfs schadelijk) dat een netwerkingenieur zich alleen met het netwerk bezighoudt en met niets anders. Zelfs als we de optie niet overwegen met een infrastructuur die bijna volledig in de publieke cloud leeft (en wat je ook zegt, deze wordt steeds populairder), en bijvoorbeeld on-premise of private clouds nemen, waar over “Alleen kennis op CCNP-niveau” "Je gaat niet weg.
Naast in feite netwerken - hoewel er simpelweg een eindeloos studiegebied is, zelfs als je je slechts op één gebied concentreert (providernetwerken, ondernemingen, datacenters, wifi ...)
Natuurlijk zullen velen van jullie zich nu Python en andere “netwerkautomatisering” herinneren, maar dit is slechts een noodzakelijke, maar geen voldoende voorwaarde. Om een netwerkingenieur ‘succesvol bij het team te laten komen’, moet hij dezelfde taal kunnen spreken met zowel ontwikkelaars als collega-beheerders/ontwikkelaars. Wat betekent het?
- niet alleen als gebruiker in Linux kunnen werken, maar het ook kunnen beheren, tenminste op sysadmin-jun-niveau: de benodigde software installeren, een mislukte service opnieuw opstarten, een eenvoudige systemd-unit schrijven.
- Begrijp (althans in algemene termen) hoe de netwerkstack werkt in Linux, hoe het netwerk werkt in hypervisors en containers (lxc / docker / kubernetes).
- Uiteraard kunnen werken met ansible/chef/puppet of een ander SCM-systeem.
- Er moet een aparte regel worden geschreven over SDN en netwerken voor private clouds (bijvoorbeeld TungstenFabric of OpenvSwitch). Dit is weer een enorme kennislaag.
Kortom, ik beschreef een typische T-shape specialist (zoals dat nu in de mode is). Het lijkt niets nieuws, maar op basis van interviewervaring kunnen niet alle netwerkingenieurs bogen op kennis van ten minste twee onderwerpen uit de bovenstaande lijst. In de praktijk maakt het gebrek aan kennis “op aanverwante gebieden” het erg moeilijk om niet alleen met collega's te communiceren, maar ook om de eisen te begrijpen die het bedrijfsleven stelt aan het netwerk, als infrastructuur op het laagste niveau van het project. En zonder dit begrip wordt het moeilijker om uw standpunt te verdedigen en aan het bedrijfsleven te ‘verkopen’.
Aan de andere kant geeft dezelfde gewoonte om “te begrijpen hoe het systeem werkt” netwerkers een zeer goed voordeel ten opzichte van verschillende “generalisten” die kennis hebben van technologieën uit artikelen op Habré/medium en chats op Telegram, maar absoluut geen idee hebben hoe ze wat moeten doen. principes werkt deze of gene software? En kennis van bepaalde patronen vervangt, zoals bekend, met succes de kennis van veel feiten.
Conclusies, of gewoon TL;DR
- Een netwerkbeheerder (zoals een DBA- of VoIP-ingenieur) is een specialist met een vrij smal profiel (in tegenstelling tot systeembeheerders/ontwikkelaars/SRE), waarvan de behoefte niet onmiddellijk ontstaat (en misschien zelfs pas over langere tijd). . Maar als het zich toch voordoet, is het onwaarschijnlijk dat het vervangen zal worden door expertise van buitenaf (uitbestede of gewone beheerders voor algemene doeleinden, “die ook voor het netwerk zorgen”). Wat enigszins treuriger is, is dat de behoefte aan dergelijke specialisten klein is, en dat er, voorwaardelijk, in een bedrijf met 800 programmeurs en 30 devops/beheerders slechts twee netwerkers kunnen zijn die uitstekend werk leveren met hun verantwoordelijkheden. Die. de markt was en is heel, heel klein, en met een goed salaris – zelfs minder.
- Aan de andere kant moet een goede netwerker in de moderne wereld niet alleen de netwerken zelf kennen (en hoe de configuratie ervan te automatiseren), maar ook hoe de besturingssystemen en software die bovenop deze netwerken draaien ermee omgaan. Zonder dit zal het uiterst moeilijk zijn om te begrijpen wat uw collega's van u vragen en uw wensen/eisen (redelijkerwijs) aan hen over te brengen.
- Er is geen cloud, het is gewoon de computer van iemand anders. U moet begrijpen dat het gebruik van publieke/private clouds of de diensten van een hostingprovider “die alles op een kant-en-klare basis voor u doet” niets verandert aan het feit dat uw applicatie nog steeds gebruik maakt van het netwerk, en dat problemen daarmee de werking van uw applicatie zullen beïnvloeden. jouw toepassing. U kiest zelf waar het competentiecentrum wordt gevestigd, dat verantwoordelijk is voor het netwerk van uw project.
Bron: www.habr.com