Selle artikli kirjutamise ajal otsiti populaarsel töökoha saidil fraasi "võrguinsener" umbes kolmsada vaba töökohta kogu Venemaal. Võrdluseks annab otsing fraasi “süsteemiadministraator” peaaegu 2.5 tuhat vaba töökohta ja “DevOpsi insener” - peaaegu 800.
Kas see tähendab, et võidukate pilvede, Dockeri, Kubernetese ja üldlevinud avaliku WiFi ajal pole võrgutootjaid enam vaja?
Mõtleme selle välja (c)
Saame tuttavaks. Minu nimi on Aleksei ja ma olen võrgumees.
Olen võrkudega tegelenud üle 10 aasta ja erinevate *nix süsteemidega üle 15 aasta (mul oli võimalus nokitseda nii Linuxi kui FreeBSD kallal). Töötasin telekomioperaatorites, suurettevõtetes, mida peetakse "ettevõtteks" ja viimasel ajal olen töötanud "noores ja julges" fintechis, kus pilved, devopid, kubernetes ja muud hirmutavad sõnad, mis muudavad mind ja mu kolleege kindlasti mittevajalikuks. . Mõni päev. Võib olla.
lahtiütlemine: "Meie elus pole kõik alati ja kõikjal, vaid midagi, mõnikord kohtades" (c) Maxim Dorofejev.
Kõike allpool kirjutatut võib ja tuleb pidada autori isiklikuks arvamuseks, mis ei pretendeeri lõplikule tõele, ega isegi mitte täisväärtuslikule uurimusele. Kõik tegelased on fiktiivsed, kõik kokkusattumused on juhuslikud.
Tere tulemast minu maailma.
Kus saate isegi võrgutegijaid kohtuda?
1. Telekommunikatsioonioperaatorid, teenindusettevõtted ja muud integraatorid. Siin on kõik lihtne: võrk on nende jaoks äri. Nad kas müüvad otse ühenduvust (operaatorid) või pakuvad teenuseid oma klientide võrkude käivitamiseks/hooldamiseks.
Siin on palju kogemusi, aga raha vähe (kui just pole direktor või edukas müügijuht). Ja kui teile meeldivad võrgud ja olete alles oma teekonna alguses, on karjäär mõne mitte väga suure operaatori toetamisel isegi praegu ideaalne lähtepunkt (föderaalsetes võrkudes on kõik väga skriptitud ja loovusele on vähe ruumi). Noh, lood sellest, kuidas mõne aastaga valves olevast insenerist C-taseme juhiks kasvada, on samuti üsna reaalsed, kuigi arusaadavatel põhjustel harvad. Personali on alati vaja, sest voolavust tekib küll. See on korraga nii hea kui ka halb - vabu kohti on alati, teisalt - sageli lahkuvad kõige aktiivsemad/targemad kiiresti kas ametikõrgendusele või mujale, “soojematesse” kohtadesse.
2. Tingimuslik „ettevõte”. Pole vahet, kas tema põhitegevus on seotud IT-ga või mitte. Peaasi, et tal on oma IT-osakond, mis tagab ettevõtte sisesüsteemide toimimise, sh kontorivõrgu, sidekanalid filiaalidesse jne. Võrguinseneri ülesandeid saab sellistes ettevõtetes "osalise tööajaga" täita süsteemiadministraator (kui võrguinfrastruktuur on väike või seda haldab väline töövõtja), võrguspetsialist, kui see on olemas, saab samal ajal hoolitsege telefoni ja SAN-i eest (pole hea). Nad maksavad erinevalt – see sõltub suuresti ettevõtte kasumlikkusest, ettevõtte suurusest ja struktuurist. Töötasin ettevõtetega, kus Cisco süsteeme laaditi regulaarselt tünnidesse, ja ettevõtetega, kus võrk ehitati väljaheidetest, pulkadest ja sinisest teibist ning servereid ei uuendatud kunagi (selgelt pole vaja öelda, et ka reserve ei antud). Siin on palju vähem kogemusi ja see on peaaegu kindlasti range müüjaluku või "kuidas mitte millestki teha midagi" valdkonnas. Mulle isiklikult tundus see metsikult igav, kuigi paljudele meeldib - kõik on üsna mõõdetud ja etteaimatav (kui me räägime suurettevõtetest), “dorakha-bahato” jne. Vähemalt kord aastas ütleb mõni suurem müüja, et nad on välja mõelnud järjekordse mega-super-duper-süsteemi, mis nüüd kõik automatiseerib ja kõik süsteemiadministraatorid ja võrgutöötajad saab hajutada, jättes paar nuppu vajutama ilusas liideses. Reaalsus on see, et isegi kui jätame lahenduse maksumuse tähelepanuta, ei lähe võrgutöötajad sealt kuhugi. Jah, võib-olla on konsooli asemel jälle veebiliides (kuid mitte konkreetne riistvara, vaid suur süsteem, mis haldab kümneid ja sadu selliseid riistvarasid), kuid teadmine "kuidas kõik sees töötab" on siiski olemas. olla vaja.
3. Tootefirmad, mille kasum pärineb mõne tarkvara või platvormi – sama toote – arendamisest (ja sageli ka kasutamisest). Tavaliselt on nad väikesed ja väledad, ettevõtete mastaabist ja nende bürokratiseerimisest on nad veel kaugel. Just siit leitakse massiliselt neidsamu devoppe, cubereid, dokkereid ja muid kohutavaid sõnu, mis muudavad võrgu ja võrguinsenerid kindlasti tarbetuks rudimendiks.
Mille poolest võrgumees erineb süsteemiadministraatorist?
Inimeste arusaamises mitte IT-st - mitte midagi. Mõlemad vaatavad musta ekraani ja kirjutavad mingeid loitse, vahel vaikselt vandudes.
Programmeerijate arusaamises – võib-olla ainevaldkonna järgi. Süsteemiadministraatorid haldavad servereid, võrgutöötajad lüliteid ja ruutereid. Mõnikord on haldus halb ja kõik laguneb kõigi jaoks. Noh, kui midagi imelikku on, siis on ka võrgutegijad süüdi. Lihtsalt sellepärast, et persse, sellepärast.
Tegelikult on peamine erinevus lähenemises tööle. Võib-olla on just võrgustikutööliste seas kõige rohkem pooldajaid lähenemisviisile "Kui see töötab, ärge puudutage seda!" Reeglina saab midagi teha (ühe müüja piires) ainult ühel viisil, kogu kasti konfiguratsioon on kohe peopesal. Vea hind on kõrge ja mõnikord väga kõrge (näiteks peate ruuteri taaskäivitamiseks sõitma mitusada kilomeetrit ja sel ajal on mitu tuhat inimest ilma sideta - telekommunikatsioonioperaatori jaoks üsna tavaline olukord) .
Minu arvates on seepärast võrguinsenerid ühelt poolt äärmiselt kõrgelt motiveeritud võrgu stabiilsuse nimel (ja muutus on stabiilsuse peamine vaenlane) ja teiseks, nende teadmised ulatuvad rohkem sügavuti kui laiaulatuslikult (te ei tee seda pead oskama konfigureerida kümneid erinevaid deemoneid , pead teadma konkreetse seadmetootja tehnoloogiaid ja nende rakendamist). Sellepärast pole süsteemiadministraator, kes otsis googlest, kuidas Cisco süsteemis vlan-i registreerida, veel võrgumees. Ja on ebatõenäoline, et ta suudab tõhusalt toetada (nagu ka tõrkeotsingut) enam-vähem keerukat võrku.
Aga milleks vajate võrgumeest, kui teil on hoster?
Lisaraha eest (ja kui olete väga suur ja armastatud klient, võib-olla isegi tasuta, "sõbrana") konfigureerivad andmekeskuse insenerid teie lülitid teie vajadustele vastavaks ja võib-olla isegi aitavad teil luua BGP-liidese teenusepakkujatega. (kui teil on teadaande jaoks oma IP-aadresside alamvõrk).
Põhiprobleem on selles, et andmekeskus ei ole sinu IT-osakond, see on eraldiseisev ettevõte, mille eesmärk on kasumit teenida. Sealhulgas Sinu kui kliendi arvelt. Andmekeskus pakub riiulid, varustab neid elektri ja külmaga ning pakub ka vaikimisi Interneti-ühendust. Selle infrastruktuuri alusel saab andmekeskus majutada teie seadmeid (kolokatsioon), rentida teile serverit (spetsiaalne server) või pakkuda hallatavat teenust (näiteks OpenStack või K8s). Aga andmekeskuse äri (tavaliselt) ei ole klienditaristu haldamine, sest see protsess on üsna töömahukas, halvasti automatiseeritud (ja tavalises andmekeskuses on kõik võimalik automatiseeritud), ühtne veel hullem (iga klient on individuaalne) ja üldiselt tulvil kaebusi ("te ütlete mulle, et server on seadistatud, kuid nüüd on see kokku jooksnud, see on kõik teie süü!!!111"). Seega, kui majutaja sind milleski aitab, püüab ta selle võimalikult lihtsaks ja mugavaks teha. Sest raske tegemine on kahjumlik, vähemalt selle sama hosti inseneride tööjõukulude seisukohalt (aga olukorrad on erinevad, vt lahtiütlemist). See ei tähenda, et majutaja kõike ilmtingimata halvasti teeb. Kuid see pole sugugi tõsi, et ta teeb täpselt seda, mida sa tegelikult vajasid.
Tundub, et asi on üsna ilmne, kuid olen oma praktikas korduvalt kokku puutunud tõsiasjaga, et ettevõtted hakkasid oma hostiteenuse pakkujale lootma veidi rohkem kui peaks ja see ei toonud kaasa midagi head. Pidin pikalt ja üksikasjalikult selgitama, et ükski SLA ei kata seisakutest tekkinud kahjusid (on erandeid, aga tavaliselt on see kliendi jaoks väga-VÄGA kulukas) ja et majutaja ei ole üldse kursis, mis toimub klientide taristu (va väga üldised näitajad). Ja majutaja ei tee ka teie jaoks varukoopiaid. Olukord on veelgi hullem, kui teil on rohkem kui üks majutaja. Nendevaheliste probleemide korral ei saa nad kindlasti teie eest teada, mis valesti läks.
Tegelikult on motiivid siin täpselt samad, mis valides "in-house admin team vs outsource". Kui riskid on kalkuleeritud, on kvaliteet rahuldav ja äri ei pahanda, miks mitte proovida. Teisest küljest on võrk üks infrastruktuuri kõige elementaarsemaid kihte ja vaevalt tasub seda jätta välistele meestele, kui toetate juba kõike muud.
Millistel juhtudel on võrgutegijat vaja?
Järgmisena räägime konkreetselt kaasaegsetest toiduettevõtetest. Operaatorite ja ettevõttega on kõik selge, pluss või miinus - seal on viimastel aastatel vähe muutunud ja võrgutegijaid oli sinna vaja varem ja neid on vaja ka praegu. Kuid nende samade "noorte ja julgete" puhul pole asjad nii selged. Sageli paigutavad nad kogu oma infrastruktuuri pilvedesse, nii et neil pole isegi tegelikult administraatoreid vaja – välja arvatud muidugi nende samade pilvede administraatorid. Infrastruktuur on ühelt poolt oma disainilt üsna lihtne, teisalt hästi automatiseeritud (ansible/puppet, terraform, ci/cd... noh, tead küll). Kuid isegi siin on olukordi, kus te ei saa ilma võrguinsenerita hakkama.
Näide 1, klassika
Oletame, et ettevõte alustab ühest avaliku IP-aadressiga serverist, mis asub andmekeskuses. Siis on kaks serverit. Siis veel... Varem või hiljem tekib vajadus serveritevahelise privaatvõrgu järele. Kuna "välist" liiklust piirab nii ribalaius (näiteks mitte rohkem kui 100 Mbit/s) kui ka allalaaditud/üleslaaditavate teenuste maht kuus (erinevatel hostitel on erinevad tariifid, kuid ribalaius välismaailmale on tavaliselt palju kallim kui privaatvõrk).
Hoster lisab serveritele täiendavaid võrgukaarte ja lisab need oma lülititesse eraldi vlanina. Serverite vahele ilmub "tasane" koht. Mugav!
Serverite arv kasvab, samuti kasvab liiklus privaatvõrgus – varukoopiad, replikatsioonid jne. Hostija pakub teid kolida eraldi lülititesse, et te ei segaks teisi kliente ja nemad teid ei segaks. Hoster installib mõned lülitid ja konfigureerib need kuidagi – tõenäoliselt jättes kõigi teie serverite vahele ühe tasase võrgu. Kõik töötab hästi, kuid teatud hetkel algavad probleemid: hostide vahelised viivitused suurenevad perioodiliselt, logid kurdavad liiga paljude arp-pakettide üle sekundis ja auditi käigus persses pentester kogu teie kohaliku võrgu, rikkudes ainult ühe serveri.
Mida ma peaksin tegema?
Jagage võrk segmentideks - vlanideks. Seadistage igas vlan-is oma aadress, valige lüüs, mis edastab liiklust võrkude vahel. Seadistage lüüsis acl, et piirata juurdepääsu segmentide vahel või isegi installida lähedale eraldi tulemüür.
Näide 1, jätk
Serverid on LAN-iga ühendatud ühe juhtmega. Riiulites olevad lülitid on kuidagi omavahel ühendatud, aga kui ühes riiulis juhtub õnnetus, kukub maha veel kolm kõrvuti olevat. Skeemid on olemas, kuid nende asjakohasuses on kahtlusi. Igal serveril on oma avalik aadress, mille väljastab hoster ja mis on riiuliga seotud. Need. Serveri teisaldamisel tuleb aadressi muuta.
Mida ma peaksin tegema?
Ühendage serverid LAG-i (Link Aggregation Group) abil kahe juhtmega rackis olevate lülititega (ka need peavad olema üleliigsed). Reserveerige riiulitevahelised ühendused ja muutke need "täheks" (või nüüd moes olevaks CLOSiks), et ühe riiuli kadumine ei mõjutaks teisi. Valige "kesksed" riiulid, milles asub võrgu tuum ja kuhu ühendatakse teised riiulid. Samal ajal tee korda avalik pöördumine, võta hosterist (või võimalusel RIR-ist) alamvõrk, mille ise (või hosti kaudu) maailmale kuulutad.
Kas seda kõike saab teha "tavaline" süsteemiadministraator, kes ei tunne võrke põhjalikult? Pole kindel. Kas majutaja teeb seda? Võib-olla läheb, kuid teil on vaja üsna üksikasjalikku tehnilist kirjeldust, mille keegi peab ka koostama. ja seejärel kontrollige, kas kõik on õigesti tehtud.
Näide 2: Pilv
Oletame, et teil on mõnes avalikus pilves VPC. Kontorist või taristu kohapealsest osast VPC-s asuvale kohtvõrgule juurdepääsu saamiseks peate konfigureerima ühenduse IPSeci või spetsiaalse kanali kaudu. Ühest küljest on IPSec odavam, sest pole vaja täiendavat riistvara osta; saate luua tunneli avaliku aadressiga serveri ja pilve vahel. Kuid - viivitused, piiratud jõudlus (kuna kanal tuleb krüpteerida), pluss garanteerimata ühenduvus (kuna juurdepääs toimub tavalise Interneti kaudu).
Mida ma peaksin tegema?
Looge ühendus spetsiaalse kanali kaudu (näiteks AWS nimetab seda otseühenduseks). Selleks leidke partneroperaator, kes teid ühendab, otsustage teile lähim ühenduspunkt (nii operaatorile kui ka operaatorile pilve) ja lõpuks seadistage kõik. Kas seda kõike on võimalik teha ilma võrguinsenerita? Kindlasti jah. Kuid kuidas probleemide korral ilma temata tõrkeotsingut teha, pole enam nii selge.
Samuti võib esineda probleeme pilvedevahelise saadavusega (kui teil on multicloud) või probleeme erinevate piirkondade vahel jne. Muidugi on nüüd ilmunud palju tööriistu, mis suurendavad pilves toimuva läbipaistvust (sama Thousand Eyes), kuid need on kõik võrguinseneri tööriistad, mitte tema asendaja.
Ma võiksin oma praktikast välja tuua veel kümmekond sellist näidet, kuid arvan, et on selge, et meeskonnas peab alates teatud infrastruktuuri arendamise tasemest olema inimene (soovitavalt rohkem kui üks), kes teab, kuidas võrk töötab ja oskab seadistada. võrguseadmed ja nende ilmnemisel probleemid lahendama. Uskuge mind, tal on midagi teha
Mida peaks võrgumees teadma?
Võrguinseneril pole üldse vaja (ja mõnikord isegi kahjulik) tegeleda ainult võrguga ja mitte millegi muuga. Isegi kui me ei kaalu võimalust infrastruktuuriga, mis elab peaaegu täielikult avalikus pilves (ja mis iganes võib öelda, muutub see üha populaarsemaks), ja võtame näiteks eeldus- või privaatpilved, kus teemal "Ainult CCNP-taseme teadmised" "Sa ei lahku.
Lisaks võrkudele - kuigi õppimiseks on lihtsalt lõputu väli, isegi kui keskendute ainult ühele valdkonnale (pakkujate võrgud, ettevõtted, andmekeskused, Wi-Fi ...)
Muidugi mäletavad paljud teist nüüd Pythonit ja muud "võrgu automatiseerimist", kuid see on ainult vajalik, kuid mitte piisav tingimus. Selleks, et võrguinsener saaks "edukalt meeskonnaga liituda", peab ta suutma rääkida sama keelt nii arendajate kui ka kaasadministraatorite/arendajatega. Mida see tähendab?
- saama Linuxis mitte ainult kasutajana töötada, vaid ka seda vähemalt sysadmin-jun tasemel administreerida: installida vajalik tarkvara, taaskäivitada ebaõnnestunud teenus, kirjutada lihtne systemd-unit.
- Mõistke (vähemalt üldiselt), kuidas võrgupinn Linuxis töötab, kuidas võrk töötab hüperviisorites ja konteinerites (lxc / docker / kubernetes).
- Muidugi oskama töötada ansible/chef/nuppet või mõne muu SCM süsteemiga.
- Eraldi rida tuleks kirjutada SDN-i ja privaatpilvede jaoks mõeldud võrkude kohta (näiteks TungstenFabric või OpenvSwitch). See on veel üks tohutu teadmiste kiht.
Ühesõnaga kirjeldasin tüüpilist T-kujulist spetsialisti (nagu praegu on moes öelda). Tundub, et see pole midagi uut, kuid intervjuukogemuse põhjal ei saa kõik võrguinsenerid kiidelda vähemalt kahe ülaltoodud teema teadmistega. Praktikas muudab teadmiste puudumine "seotud valdkondades" väga keeruliseks mitte ainult kolleegidega suhtlemise, vaid ka arusaamise nõuetest, mida äri võrgule kui projekti madalaima taseme infrastruktuurile esitab. Ja ilma selle mõistmiseta on raskem oma seisukohta kaitsta ja seda ärile "müüa".
Teisest küljest annab seesama harjumus "mõista, kuidas süsteem toimib" võrgutöötajatele väga hea eelise erinevate "generalistide" ees, kes teavad tehnoloogiatest Habré/mediumi artiklite ja Telegrami vestluste põhjal, kuid kellel pole aimugi, kuidas seda teha. mis põhimõtetel see või teine tarkvara töötab? Teatud mustrite tundmine asendab teadmised paljudest faktidest edukalt.
Järeldused või lihtsalt TL;DR
- Võrguadministraator (nagu DBA või VoIP insener) on üsna kitsa profiiliga spetsialist (erinevalt süsteemiadministraatoritest/devs/SRE-st), kelle järele vajadus ei teki kohe (ja tegelikult ei pruugi ka kaua tekkida) . Aga kui see siiski ilmneb, siis tõenäoliselt ei asendata seda väliste ekspertiisidega (ostlevad allhanget või tavalised üldadministraatorid, "kes hoolitsevad ka võrgu eest"). Mõnevõrra kurvem on aga see, et vajadus selliste spetsialistide järele on väike ja tinglikult võib 800 programmeerija ja 30 devopi/administraatoriga ettevõttes olla vaid kaks võrgutegijat, kes saavad oma kohustustega suurepäraselt hakkama. Need. turg oli ja on väga-väga väike ja hea palgaga - veel vähem.
- Teisest küljest peab hea võrgumees tänapäeva maailmas teadma mitte ainult võrke endid (ja nende konfiguratsiooni automatiseerimist), vaid ka seda, kuidas nende võrkude peal töötavad operatsioonisüsteemid ja tarkvara nendega suhtlevad. Ilma selleta on äärmiselt raske mõista, mida kolleegid teilt küsivad, ja (mõistlikult) oma soove/nõudeid neile edastada.
- Pilve pole olemas, see on lihtsalt kellegi teise arvuti. Peate mõistma, et avalike/privaatsete pilvede või hostiteenuse pakkuja teenuste kasutamine, mis „teemaks kõik teie eest võtmed kätte“ põhimõttel, ei muuda tõsiasja, et teie rakendus ikka kasutab võrku ja sellega kaasnevad probleemid mõjutavad teie rakendus. Teie valik on see, kus asub kompetentsikeskus, mis vastutab teie projekti võrgustiku eest.
Allikas: www.habr.com