Ten tyde van hierdie skrywe het 'n soektog op 'n gewilde werkswerf vir die frase "Netwerkingenieur" ongeveer driehonderd vakante poste regoor Rusland opgelewer. Ter vergelyking, 'n soektog na die frase "stelseladministrateur" lewer byna 2.5 duisend vakatures op, en "DevOps-ingenieur" - byna 800.
Beteken dit dat netwerkers nie meer nodig is in die dae van die wenwolke, docker, kubernetis en die alomteenwoordige openbare Wi-Fi nie?
Kom ons vind dit uit (s)
Kom ons leer mekaar ken. My naam is Alexey, en ek is 'n netwerker.
Ek doen al meer as 10 jaar netwerkwerk en werk al meer as 15 jaar met verskeie *nix-stelsels (ek het 'n kans gehad om beide Linux en FreeBSD te kies). Ek het in telekommunikasie-operateurs, groot maatskappye, wat as “ondernemings” beskou word, gewerk en ek het onlangs in “jonk en waaghalsige” fintech gewerk, waar wolke, devops, kubernetes en ander eng woorde wat my en my kollegas beslis sal maak onnodig. Een of ander dag. Kan wees.
vrywaring: "In ons lewe, nie alles, altyd en oral nie, maar iets, soms op plekke" (c) Maxim Dorofeev.
Alles wat hieronder geskryf word, kan en moet beskou word as die persoonlike mening van die skrywer, sonder om te beweer dat dit die uiteindelike waarheid is, en selfs 'n volwaardige studie. Alle karakters is fiktief, alle toevallighede is lukraak.
Welkom in my wêreld.
Waar kan jy netwerkers vind?
1. Telekommunikasie-operateurs, diensmaatskappye en ander integreerders. Alles is eenvoudig: die netwerk vir hulle is 'n besigheid. Hulle verkoop óf direk konnektiwiteit (operateurs) óf verskaf dienste vir die bekendstelling/onderhoud van hul kliënte se netwerke.
Hier is baie ondervinding, maar nie veel geld nie (tensy jy 'n direkteur of 'n suksesvolle verkoopsbestuurder is). En tog, as jy van netwerke hou, en jy is net aan die begin van jou reis, sal 'n loopbaan ter ondersteuning van een of ander nie baie groot operateur, selfs nou, 'n ideale beginpunt wees (alles is baie geskryf in federale, en daar is min ruimte vir kreatiwiteit). Wel, stories oor die feit dat dit moontlik is om oor 'n paar jaar van 'n ingenieur aan diens tot 'n C-vlakbestuurder te groei, is ook redelik eg, hoewel skaars, om ooglopende redes. Daar is altyd 'n behoefte aan personeel, want daar is steeds 'n omset. Dit is beide goed en sleg op dieselfde tyd - daar is altyd vakante poste, aan die ander kant - dikwels kry die mees aktiewe/slimmense vinnig genoeg óf bevorder óf gaan na ander, "warmer" plekke.
2. Voorwaardelike "onderneming". Dit maak nie saak of sy hoofaktiwiteit met IT verband hou of nie. Die belangrikste ding is dat dit sy eie IT-afdeling het, wat besig is om die werking van die maatskappy se interne stelsels te verseker, insluitend netwerke in kantore, kommunikasiekanale na takke, ens. Die funksies van 'n netwerkingenieur in sulke maatskappye kan "deeltyds" deur 'n stelseladministrateur verrig word (as die netwerkinfrastruktuur klein is, of 'n eksterne kontrakteur daarby betrokke is), en die netwerkbestuurder, indien hy nog bestaan, kan kyk terselfdertyd na telefonie en SAN (nie nuacho nie). Hulle betaal op verskillende maniere – dit hang sterk af van die marge van die besigheid, die grootte van die maatskappy en die struktuur. Ek het beide met maatskappye gewerk waar cisco's gereeld "in vate gelaai" is, en met maatskappye waar die netwerk uit ontlasting, stokke en blou elektriese band gebou is, en die bedieners nie ongeveer ooit opgedateer is nie (dit is nodig om te sê dat daar was ook geen reserwes nie). Daar is baie minder ervaring hier, en dit sal byna seker in die omgewing van 'n harde verkoperslot wees, of "hoe om iets uit niks te maak". Persoonlik het dit vir my baie vervelig gelyk daar, alhoewel baie mense daarvan hou - alles is redelik afgemete en voorspelbaar (as ons van groot maatskappye praat), "dorah-bajato", ens. Ten minste een keer per jaar sê 'n groot verkoper dat hulle met 'n ander mega-super-duper-stelsel vorendag gekom het wat alles nou outomatiseer en alle stelseladministrateurs en netwerkers kan oorklok word, wat 'n paar laat om knoppies in 'n pragtige koppelvlak te druk. Die realiteit is dat, selfs al ignoreer ons die koste van die oplossing, netwerkers nêrens van daar af sal gaan nie. Ja, dit is moontlik dat daar in plaas van die konsole weer 'n webkoppelvlak sal wees (maar nie 'n spesifieke stuk yster nie, maar 'n groot stelsel wat tiene en honderde sulke stukke yster bestuur), maar kennis van "hoe alles binne werk ” nog nodig sal wees.
3. Produk maatskappye, wie se wins uit die ontwikkeling (en, dikwels, bedryf) van een of ander sagteware of platform kom - daardie einste produk. Gewoonlik is hulle klein en flink, hulle is nog ver van die skaal van ondernemings en hul burokratisering. Dit is hier waar daardie selfde devops, cubers, dockers en ander verskriklike woorde in groot getalle gevind word wat sekerlik die netwerk- en netwerkingenieurs 'n onnodige element sal maak.
Hoe verskil 'n netwerkbestuurder van 'n stelselbeheerder?
In die begrip van mense nie van IT - niks. Beide van hulle kyk na die swart skerm en skryf 'n paar towerspreuke, soms vloek sag.
In die begrip van programmeerders - miskien die vakgebied. Sysadmins administreer bedieners, netwerkers administreer skakelaars en routers. Soms is die admin sleg, en alles val vir almal neer. Wel, in die geval van enige vreemde, netwerkers is ook te blameer. Net omdat fok jou, dis hoekom.
Trouens, die belangrikste verskil is die benadering tot werk. Miskien is dit onder netwerkers dat daar veral ondersteuners is van die benadering "Dit werk - moenie daaraan raak nie!". Jy kan gewoonlik iets (binne een verkoper) op net een manier doen, die hele konfigurasie van die boks - hier is dit, in die palm van jou hand. Die koste van 'n fout is hoog, en soms baie hoog (jy moet byvoorbeeld 'n paar honderd kilometer reis om die router te herlaai, en op hierdie tydstip sal 'n paar duisend mense sonder kommunikasie wees - 'n situasie wat redelik algemeen is vir 'n telekommunikasie-operateur ).
Dit is myns insiens hoekom netwerkingenieurs aan die een kant uiters sterk gemotiveer is vir netwerkstabiliteit (en veranderinge is die grootste vyand van stabiliteit), en tweedens gaan hul kennis meer in diepte as in breedte (jy hoef nie om dosyne verskillende demone te kan konfigureer, moet jy die tegnologieë en hul implementering van 'n spesifieke toerustingvervaardiger ken). Dit is hoekom die stelseladministrateur, wat gegoogle het hoe om 'n vlan op 'n tsiska te registreer, nog nie 'n netwerkbestuurder is nie. En dit is onwaarskynlik dat hy 'n min of meer komplekse netwerk effektief sal kan ondersteun (sowel as probleemoplossing).
Maar hoekom het jy 'n netwerkbestuurder nodig as jy 'n gasheer het?
Vir 'n ekstra geld (en as jy 'n baie groot en geliefde kliënt is, miskien selfs gratis, "as 'n vriend"), sal datasentrumingenieurs jou skakelaars opstel om by jou behoeftes te pas, en miskien selfs help om 'n BGP-koppelvlak te skep met verskaffers (as jy jou eie subnet van IP-adresse het om aan te kondig).
Die grootste probleem is dat die datasentrum nie jou IT-afdeling is nie, dit is 'n aparte maatskappy wie se doel is om wins te maak. Insluitend ten koste van jou as kliënt. Die datasentrum verskaf rakke, voorsien hulle van elektrisiteit en koue, en gee ook 'n mate van "verstek" konneksie aan die internet. Op grond van hierdie infrastruktuur kan die datasentrum jou toerusting (colocation) opspoor, vir jou 'n bediener (toegewyde bediener) huur of 'n bestuurde diens lewer (byvoorbeeld OpenStack of K8s). Maar die besigheid van die datasentrum is (gewoonlik) nie die administrasie van klante-infrastruktuur nie, want hierdie proses is taamlik arbeidsintensief, swak outomaties (en in 'n normale datasentrum is alles outomaties), selfs erger verenig (elke kliënt is individueel) en oor die algemeen belaai met eise ("jy sê vir my die bediener is opgestel, en nou het dit neergestort, dit is alles jou skuld!!!111"). Daarom, as die gasheer jou met iets sal help, sal hy probeer om dit so eenvoudig en "woonstel" as moontlik te maak. Want dit is moeilik om te doen - onwinsgewend, ten minste vanuit die oogpunt van die arbeidskoste van die ingenieurs van hierdie einste gasheer (maar die situasies is anders, sien die vrywaring). Dit beteken nie dat die gasheer noodwendig alles sleg sal doen nie. Maar dit is glad nie 'n feit dat hy presies sal doen wat jy regtig nodig gehad het nie.
Dit wil voorkom asof die ding redelik voor die hand liggend is, maar ek het verskeie kere in my praktyk afgekom op die feit dat maatskappye 'n bietjie meer op hul gasheerverskaffer begin staatmaak het as wat hulle moet, en dit het niks goeds gelei nie. Dit het lank geneem om in detail te verduidelik dat geen SLA stilstandtydverliese sal dek nie (daar is uitsonderings, maar gewoonlik is dit baie, BAIE duur vir die kliënt) en dat die gasheer glad nie bewus is van wat in die kliënte se infrastruktuur gebeur nie. (behalwe vir baie algemene aanwysers). En die gasheer maak ook nie rugsteun vir jou nie. Die situasie is selfs erger as jy meer as een gasheer het. In die geval van enige probleme tussen hulle, sal hulle beslis nie vir jou uitvind wat verkeerd geloop het nie.
Eintlik is die motiewe hier presies dieselfde as wanneer jy "eie span administrateurs vs uitkontraktering" kies. As die risiko's bereken word, die kwaliteit pas, en die besigheid gee nie om nie - hoekom probeer dit nie. Aan die ander kant is die netwerk een van die mees basiese lae van infrastruktuur, en dit is beswaarlik die moeite werd om dit aan buitestanders weg te gee as jy reeds alles anders self ondersteun.
Wanneer het jy 'n netwerker nodig?
Verder sal ons fokus op moderne produkmaatskappye. Met operateurs en ondernemings is alles plus of minus duidelik - min het die afgelope jare daar verander, en netwerkers was voorheen daar nodig, hulle is nou nodig. Maar met daardie baie "jonk en waaghalsig" is dinge nie so eenvoudig nie. Dikwels plaas hulle hul infrastruktuur heeltemal in die wolke, so hulle het nie eers admins nodig nie, behalwe vir die admins van daardie selfde wolke, natuurlik. Die infrastruktuur, aan die een kant, is redelik eenvoudig in sy ontwerp, aan die ander kant is dit goed geoutomatiseerd (ansible / marionet, terraform, ci / cd ... wel, jy weet). Maar selfs hier is daar situasies wanneer jy nie sonder 'n netwerkingenieur kan klaarkom nie.
Voorbeeld 1, klassiek
Gestel 'n maatskappy begin met een bediener met 'n publieke IP-adres, wat in die datasentrum geleë is. Dan is daar twee bedieners. Dan meer ... Vroeër of later is daar 'n behoefte aan 'n privaat netwerk tussen bedieners. Omdat "eksterne" verkeer beperk word deur beide bandwydte (nie meer as 100 Mbps, byvoorbeeld) en deur die hoeveelheid afgelaai / opgelaai per maand (verskillende gashere het verskillende tariewe, maar die bandwydte na die buitewêreld, as 'n reël, is baie duurder as 'n private netwerk).
Die gasheer voeg bykomende netwerkkaarte by die bedieners en sluit dit by hul skakelaars in 'n aparte vlan in. 'n "Plat" LAN verskyn tussen bedieners. Gerieflik!
Die aantal bedieners groei, die verkeer in die privaat netwerk groei ook - rugsteun, replikasies, ens. Die gasheer bied aan om jou na aparte skakelaars te skuif sodat jy nie met ander kliënte inmeng nie, en hulle nie met jou inmeng nie. Die gasheer plaas 'n soort skakelaars en konfigureer hulle op een of ander manier - heel waarskynlik, laat een plat netwerk tussen al jou bedieners. Alles werk goed, maar op 'n sekere punt begin probleme: vertragings tussen gashere groei periodiek, logs vloek te veel arp-pakkies per sekonde, en die pentester het jou hele plaaslike area tydens die oudit verkrag en net een bediener gebreek.
Wat om te doen?
Verdeel die netwerk in segmente - vlans. Stel u eie adressering in elke vlan op, kies 'n poort wat verkeer tussen netwerke sal oordra. Stel acl op die poort in om toegang tussen segmente te beperk, of plaas selfs 'n aparte firewall langsaan.
Voorbeeld 1, vervolg
Bedieners is met een koord aan die plaaslike area gekoppel. Die skakelaars in die rakke is op een of ander manier met mekaar verbind, maar in die geval van 'n ongeluk in een rak val nog drie naburiges af. Skemas bestaan, maar daar is twyfel oor die relevansie daarvan. Elke bediener het sy eie publieke adres, wat deur die gasheer uitgereik en aan die rek gekoppel word. Dié. wanneer die bediener verskuif word, moet die adres verander word.
Wat om te doen?
Koppel bedieners met behulp van LAG (Link Aggregation Group) met twee koorde aan skakelaars in die rek (hulle moet ook oorbodig wees). Behou die verbindings tussen die rakke, maak dit weer met 'n "ster" (of die nou modieuse CLOS) sodat die verlies van een rek nie die ander raak nie. Kies "sentrale" rakke waar die netwerkkern geleë sal wees en waar ander rakke ingesluit sal word. Stel terselfdertyd openbare adressering in orde, neem van die gasheer (of van die RIR, indien moontlik) 'n subnet, wat jy self (of deur die gasheer) aan die wêreld aankondig.
Kan 'n "gewone" stelseladministrateur wat nie diep kennis van netwerke het nie dit alles doen? Nie seker nie. Sal die gasheer dit doen? Miskien sal dit, maar jy sal 'n taamlik gedetailleerde TOR nodig hê, wat ook deur iemand saamgestel moet word. en maak dan seker dat alles reg gedoen is.
Voorbeeld 2: Bewolk
Gestel jy het 'n VPC in een of ander publieke wolk. Om toegang vanaf die kantoor of die plaaslike deel van die infrastruktuur tot die plaaslike netwerk binne die VPC te kry, moet jy 'n verbinding opstel via IPSec of 'n toegewyde kanaal. Aan die een kant is IPSec goedkoper. nie nodig om bykomende hardeware te koop nie, jy kan 'n tonnel tussen jou bediener met 'n publieke adres en die wolk opstel. Maar - vertragings, beperkte werkverrigting (aangesien die kanaal geënkripteer moet word), plus nie-gewaarborgde konneksie (aangesien toegang deur die gewone internet gaan).
Wat om te doen?
Verhoog die verbinding deur 'n toegewyde kanaal (byvoorbeeld, AWS noem dit Direct Connect). Om dit te doen, vind 'n vennootoperateur wat jou sal verbind, besluit op die verbindingspunt naaste aan jou (beide jy in die operateur en die operateur in die wolk), en uiteindelik alles opstel. Kan dit alles gedoen word sonder 'n netwerkingenieur? Vir seker, ja. Maar hoe om probleme daarsonder op te los in geval van probleme, is nie meer so duidelik nie.
En daar kan ook probleme wees met beskikbaarheid tussen wolke (as jy 'n multiwolk het) of probleme met vertragings tussen verskillende streke, ens. Natuurlik is daar nou baie instrumente wat die deursigtigheid van wat in die wolk gebeur (dieselfde Duisend oë) verhoog, maar dit is almal netwerkingenieursinstrumente, en nie 'n plaasvervanger nie.
Ek kan nog 'n dosyn sulke voorbeelde uit my praktyk skets, maar ek dink dit is duidelik dat daar in 'n span, vanaf 'n sekere vlak van infrastruktuurontwikkeling, 'n persoon (of beter, meer as een) moet wees wat weet hoe die netwerk werk, kan netwerktoerusting instel en probleme hanteer as dit opduik. Glo my, hy sal iets hê om te doen
Wat moet 'n netwerker weet?
Dit is glad nie nodig (en selfs soms skadelik) vir 'n netwerkingenieur om net met die netwerk te handel en niks anders nie. Selfs al oorweeg ons nie die opsie met 'n infrastruktuur wat feitlik geheel en al in 'n publieke wolk leef nie (en, wat mens ook al mag sê, dit word al hoe meer gewild), en neem byvoorbeeld op perseel of private wolke, waar slegs "kennis op die CCNP-vlak "Jy sal nie weggaan nie.
Benewens, in werklikheid, netwerke - hoewel daar bloot 'n eindelose studieveld is, selfs al konsentreer jy net op een rigting (verskaffernetwerke, ondernemings, datasentrums, Wi-Fi ...)
Natuurlik sal baie van julle nou Python en ander "netwerkoutomatisering" onthou, maar dit is slegs 'n noodsaaklike, maar nie voldoende voorwaarde nie. Vir 'n netwerkingenieur om "suksesvol by die span aan te sluit", moet hy dieselfde taal kan praat met beide ontwikkelaars en mede-admins / devops. Wat beteken dit?
- in staat wees om nie net in Linux as 'n gebruiker te werk nie, maar dit ook te administreer, ten minste op die vlak van 'n sysadmin-junior: installeer die nodige sagteware, herbegin 'n gevalle diens, skryf 'n eenvoudige systemd-eenheid.
- Verstaan (ten minste in algemene terme) hoe die netwerkstapel in Linux werk, hoe die netwerk in hipervisors en houers werk (lxc / docker / kubernetes).
- Natuurlik in staat wees om met ansible/sjef/pop of 'n ander SCM-stelsel te werk.
- 'n Aparte reël moet geskryf word oor SDN en netwerke vir private wolke (byvoorbeeld TungstenFabric of OpenvSwitch). Dit is nog 'n groot stuk kennis.
Kortom, ek het 'n tipiese T-vorm spesialis beskryf (soos dit nou mode is om te sê). Dit blyk niks nuuts te wees nie, maar volgens die ervaring van onderhoude kan nie alle netwerkingenieurs spog met kennis van ten minste twee onderwerpe uit die lys hierbo nie. In die praktyk maak die gebrek aan kennis "in verwante gebiede" dit baie moeilik om nie net met kollegas te kommunikeer nie, maar ook om die vereistes te verstaan wat die onderneming aan die netwerk stel as die laagstevlak-infrastruktuur van die projek. En sonder hierdie begrip word dit moeiliker om jou standpunt redelikerwys te verdedig en dit aan besigheid te "verkoop".
Aan die ander kant gee die gewoonte om te "verstaan hoe die stelsel werk" netwerkers 'n baie goeie voordeel bo verskeie "generaals" wat weet van tegnologie uit artikels oor Habré/medium en telegram-kletse, maar absoluut geen idee het watter beginsels hierdie of daardie sagteware werk. En die kennis van sommige reëlmatighede, soos u weet, vervang die kennis van baie feite suksesvol.
Gevolgtrekkings, of bloot TL;DR
- 'n Netwerkadministrateur (soos 'n DBA of 'n VoIP-ingenieur) is 'n spesialis met 'n taamlik smal profiel (anders as sysadmins / devops / SRE), waarvoor die behoefte nie onmiddellik ontstaan nie (en dalk nie vir 'n lang tyd sal ontstaan nie). . Maar as dit wel opduik, is dit onwaarskynlik dat dit vervang sal word deur kundigheid van buite (uitkontraktering of gewone algemene administrateurs, "wat ook na die netwerk omsien"). Wat ietwat hartseerder is, is dat die behoefte aan sulke spesialiste klein is, en voorwaardelik, in 'n maatskappy met 800 programmeerders en 30 devops / admins, kan daar net twee netwerkers wees wat hul werk perfek doen. Dié. die mark was en is baie, baie klein, en nog minder met 'n goeie salaris.
- Aan die ander kant behoort 'n goeie netwerker in die moderne wêreld nie net die netwerke self te ken nie (en hoe om hul konfigurasie te outomatiseer), maar ook hoe bedryfstelsels en sagteware met hulle in wisselwerking tree, wat oor hierdie netwerke loop. Daarsonder sal dit uiters moeilik wees om te verstaan wat kollegas van jou vra en jou wense/vereistes (redelik) aan hulle oor te dra.
- Daar is geen wolk nie, dit is net iemand anders se rekenaar. U moet verstaan dat die gebruik van publieke / private wolke of die dienste van gasheerverskaffers "wat alles vir u doen" nie die feit ontken dat u toepassing steeds die netwerk gebruik nie, en probleme daarmee die werking van u toepassing sal beïnvloed . Jou keuse is waar die bevoegdheidsentrum geleë sal wees, wat verantwoordelik sal wees vir die netwerk van jou projek.
Bron: will.com