Võrgutöötajad (ei) ole vajalikud

Käesoleva artikli kirjutamise ajal andis populaarne tööhõive veebileht otsing fraasi "Võrgutehnika insener" all umbes kolm sada töökohta kogu Venemaal. Võrdluseks: otsing fraasi "süsteemiadministraator" all toob välja peaaegu 2.5 tuhat töökohta ja "DevOps insener" – peaaegu 800.

Kas see tähendab, et võrguinseneride tööjõud on muutunud vähem vajalikuks uute pilvede, dockerite, kubernetese ja kõikjaloleva avaliku WiFi ajastul?
Hakkame välja selgitama (c)

Tere tulemast, mina olen Aleksei ja ma olen võrguinsener.

Olen viimase 10 aasta jooksul tegelenud võrkudega ja töötanud rohkem kui 15 aastat erinevate *nix süsteemidega (olen katsetanud nii Linuxit kui ka FreeBSD). Olen töötanud sideoperaatorites, suurtes ettevõtetes, mida tavaliselt peetakse "ettevõtete" kategooriaks, ning viimasel ajal töötan "noores ja julges" fintechis, kus pilved, devops'id, kubernetese ja muud hirmutavad sõnad, mis kindlasti muudavad mind ja mu kolleegid ühel päeval üleliigseks. Võib-olla.

Eemaldamine: "Meie elus ei ole kõik alati ja igal pool, vaid mõni asi mõnikord ja teatud kohtades" (c) Maksim Dorofeev.

Kõike, mis allpool on kirjutatud, võib ja tuleb pidada autori isiklikuks arvamuseks, mis ei pretendeeri viimase instantsi tõele ja isegi mitte põhjalikule uurimistööle. Kõik tegelased on väljamõeldud, kõik kokkusattumised on juhuslikud.

Tere tulemast minu maailma.

Kus saab võrguinseneridega üldse kokku puutuda?

1. Sideoperaatorid, teenusepakkujad ja teised integreerijad. Siin on kõik lihtne: võrgu ehitamine on nende jaoks äri. Nad müüvad kas otse ühendust (operaatorid) või pakuvad teenuseid oma tellijate võrkude käivitamiseks/hooldamiseks.

Siin on palju kogemusi, aga mitte eriti palju raha (kui te ei ole juht või edukas müügijuht). Sellegipoolest, kui teile meeldivad võrgud ja olete alles oma teekonna alguses, siis karjäär mingis mitte väga suuri operaatorit toetavas osakonnas oleks isegi praegu ideaalne koht alguseks (föderaalses on kõik väga skriptitud ja loominguliseks väljundiks on vähe ruumi). Ja lood selle kohta, et austusväärsest insenerist võib mõne aastaga areneda C-taseme juhiks, on samuti täiesti reaalsed, kuigi need on haruldased, arusaadavatel põhjustel. Tööjõu vajadus on alati olemas, sest ringkäive tõepoolest esineb. See on samaaegselt nii hea kui halb – alati on töökohti, kuid tihti lahkuvad kõige aktiivsemad/ägedamad üsna kiiresti kas ametikõrgenduseks või mujale, soojematesse kohtadesse.

2. Tinglik "ettevõte". Oluline ei ole, kas ettevõtte peamine tegevus on seotud IT-ga või mitte. Peamine on, et seal on oma IT-osakond, mis tegeleb ettevõtte siseste süsteemide toimimise tagamisega, sealhulgas kontorite võrkude, filiaalide sidekanalite jne. Funktsioone nagu võrgutehnik võib sellistes ettevõtetes täita „kõrvaltegevusena“ süsteemiadministraator (kui võrgu infrastruktuur on väike või sellega tegeleb väline alltöövõtja), samas kui kui on olemas võrgutehnik, võib ta samal ajal jälgida ka telefonivooge ja SAN-i (noh, selline asi). Palgad on erinevad — see sõltub palju ettevõtte kasumlikkusest, suurusest ja struktuurist. Olen töötanud nii ettevõtetes, kus Cisco seadmeid tõsiselt „koormati”, kui ka ettevõtetes, kus võrk ehitati välja prahi, pulkade ja sinise isolatsiooniteibi abil, ning servereid ei uuendatud, ütleme, kunagi (kas on vaja öelda, et mingisuguseid reserve ka ei olnud). Kogemusi on seal palju vähem ja need on tõenäoliselt keskendunud tugevale vendor-lockile või „kuidas teha midagi täiesti tühjast”. Isiklikult tundus see mulle väga igav, kuigi paljudele meeldib - kõik on piisavalt rahulik ja etteennustatav (kui räägime suurtest ettevõtetest), „rahaga on kergelt ja nii edasi”. Mitte harvemini kui kord aastas ütleb mõni suur tarnija, et on leidnud välja uue mega-super-sensatsiooni süsteemi, mis nüüd automaatikaliselt kõik automatiseerib ja kõiki süsteemiadministraatoreid ja võrgutehnikuid saab vallandada, jättes paar inimest kaunisse liidese nuppe vajutama. Reaalsus on aga see, et isegi kui rahalistest lahendustest kõrvale jätta, ei kao võrgutehnikud sinna kuhugi. Jah, võib-olla on veebi liides jälle olemas (kuid mitte konkreetse riistvara, vaid suure süsteemi, mis haldab kümneid ja sadu selliseid seadmeid), kuid teadmised „kuidas kõik seestpoolt töötab” on ikkagi vajalikud.

3. Tooteettevõtted, mille kasum tuleb mingisuguse tarkvara või platvormi arendamisest (ja sageli ka kasutamisest) – just sellest tootest. Tüüpiliselt on need väikesed ja kiirete muudatustega, nendeni on veel kaugel ja ettevõtete bürokraatiast. Just siin elavad massiliselt need arendajate, konteinerite ja muid hirmutavaid sõnu, mis kindlasti muudavad võrgu ja võrgutehnikud mittevajalikeks rümpadeks.

Kuidas erineb võrgutehnik süsteemiadministraatorist?

In the understanding of people outside IT — nothing. Both look at a black screen and type some spells, sometimes muttering under their breath.

In the understanding of programmers — perhaps as a subject area. System administrators manage servers, network engineers manage switches and routers. Sometimes they do it poorly, and everything crashes. In cases of strange issues, it's also the network engineers to blame. Just because, screw you, that’s why.

In reality, the main difference is the approach to work. Perhaps it's among network engineers that supporters of the "If it works, don’t touch it!" approach are most frequently found. Typically, a certain task (within a single vendor) can usually only be done in one way, the entire configuration of the box — here it is, right in front of you. The cost of a mistake is high, and sometimes very high (for example, you might have to travel hundreds of kilometers to reboot a router, while several thousand people are left without connectivity — a completely common situation for a telecom operator).

In my opinion, that’s precisely why network engineers, on one hand, are extremely motivated for network stability (and changes are the main enemy of stability), and on the other hand, their knowledge goes deeper rather than broader (there’s no need to configure dozens of different daemons; it's necessary to understand the technologies and their implementation by a specific equipment manufacturer). That’s why a system administrator who Googles how to configure VLANs on Cisco is not yet a network engineer. And it’s unlikely that he can support (and troubleshoot) a somewhat complex network effectively.

But why do you need a network engineer if you have hostija?

For an additional fee (or if you are a very large and favored client — maybe even for free, "out of friendship"), the data center engineers will configure your switches according to your needs, and perhaps even help set up BGP peering with providers (if you have your own subnet of IP addresses for announcement).

Peamine probleem on see, et andmekeskus ei ole teie IT-osakond, vaid eraldi ettevõte, mille eesmärk on teenida kasumit. Ka teie, kui kliendi arvelt. Andmekeskus pakub riiuleid, tagab nende elektriga varustamise ja jahutuse ning loob teatud "vaikse" ühenduse internetiga. Selle infrastruktuuri põhjal võib andmekeskus paigutada teie seadme (colocation), rentida teile serveri (dedicated server) või pakkuda haldusteenust (näiteks OpenStack või K8s). Kuid andmekeskuse äriks ei ole (tavaliselt) klientide infrastruktuuri haldamine, kuna see protsess on üsna töömahukas, halvasti automatiseeritav (ja normaalses andmekeskuses on automatiseeritud kõik, mis võimalik) ning veel hullem, et sellele on raske ühtlustada (iga klient on ainulaadne) ja see võib olla kannatuste allikas („te seadistate mulle serveri, aga nüüd see langes, see on teie süü!!!111"). Seetõttu, kui hostija aitab teid mingil moel, siis püüab ta seda teha võimalikult lihtsalt ja "konditsioneeritud". Sest keeruline tegemine — ei ole kasulik, vähemalt selle hostija inseneride tööjõu kulude seisukohast (aga olukorrad võivad varieeruda, vt vabastus). See ei tähenda, et hostija teeb kindlasti kõik halvasti. Kuid pole sugugi kindel, et ta teeb just seda, mida te tegelikult vajate.

Näiliselt on see asi piisavalt ilmne, aga olen oma praktikas korduvalt kokku puutunud sellega, et ettevõtted hakkasid toetuma oma hosting-teenuse pakkujatele veidi rohkem, kui oli vajalik, ja see ei ole viinud millegi heani. Oli vaja kaua ja põhjalikult selgitada, et ükski SLA ei kata kahjusid seiskamisest (on erandeid, kuid tavaliselt on see kliendile väga, VÄGA kallis) ja et hostija ei tea üldse, mis toimub kohalike infrastruktuuride juures (välja arvatud väga üldised näitajad). Ja hostija ei tee teie eest ka varukoopiaid. Veel hullem on asi, kui teil on rohkem kui üks hostija. Kui tekivad mingi probleem, siis nad kindlasti ei hakka teie eest selgitama, mis läks valesti.

Tegelikult on motiivid siin täpselt samasugused nagu valides "oma adminnide tiim vs allhange". Kui riskid on hinnatud, kvaliteet rahuldav ja äri ei ole vastu, miks mitte proovida. Teisest küljest on võrk üks kõige põhilisemaid infrastruktuuri kihte ja harva tasub see usaldada külalistele, kui kõik muu on ise hooldatud.

Millal on vajalik võrgutöötaja?

Edasi räägime just kaasaegsetest tooteettevõtetest. Operaatorite ja ettevõtete osas on kõik enam-vähem selge – seal ei ole viimastel aastatel palju muutunud ja võrgutöötajad on seal olnud vajalikud juba varem, nad on vajalikud ka nüüd. Kuid nende "noorte ja julgete" puhul ei ole see nii üheselt mõistetav. Tihti paigutavad nad oma infrastruktuuri täielikult pilve, nii et isegi administraatorid pole neile eriti vajalikud – välja arvatud nende pilvede administraatorid, muidugi. Infrastruktuur on ühel poolt üsna lihtne oma ülesehituses, teisalt aga hästi automatiseeritud (ansible/puppet, terraform, ci/cd... noh, te teate). Kuid isegi siin on olukordi, kus ilma võrgutehnikuta ei saa läbi.

Näide 1, klassikaline

Oletame, et ettevõte alustab ühe serveriga avaliku IP-aadressiga, mis asub andmekeskuses. Siis serverite arv suureneb kahele. Siis veel rohkem... Varsti tekib vajadus serverite vahelisteks privaatseteks võrkudeks. Sest "välised" andmeliiklus on piiratud nii ribalaiuse (noh, näiteks mitte rohkem kui 100 Mbit/s) kui ka igakuiste allalaadimiste ja edastamiste mahuga (erinevate hostide korral erinevad hinnapakettid, kuid välismaailmale suunatud ribalaius on tavaliselt oluliselt kallim kui privaatne võrk).

Hostija paigaldab serveritele täiendavad võrgukaardid ja ühendab need oma lülititega eraldi vlan-is. Serverite vahel tekib "lihtne" kohalik võrk. Mugav!

Serverite arv kasvab, nagu ka liiklus privaatvõrgus - varukoopiad, replikatsioonid jne. Host pakub võimalust viia teid eraldi lülititesse, et te ei segaks teisi kliente ja nemad ei segaks teid. Host paigaldab mingid lülitid ja seab need paika - tõenäoliselt jättes kõikide teie serverite vahel ühe tasase võrgu. Kõik töötab hästi, kuid teatud hetkel tekivad probleemid: aeg-ajalt kasvavad viivitused hostide vahel, logides tekib probleem liiga suurte arp-pakettide arvu tõttu sekundis, ja pen-testija auditi käigus omandas kogu teie lokaalse võrgu, katkestades vaid ühe serveri.

Mida peaks tegema?

Jagada võrk segmentideks - vlad. Seada igas vladis oma adresseerimine, eraldada värav, mis suunab liiklust erinevate võrkude vahel. Väravas seadistada ACL juurdepääsu piiramise jaoks segmentide vahel, või paigaldada kõrvale eraldi tulemüür.

Näide 1, jätkub

Serverid on kohalikku võrku ühendatud ühe kaabli abil. Lülitid riiulites on omavahel millegipärast ühendatud, kuid avarii korral ühes riiulis kukub veel kolm külgnevat välja. Skeeme on olemas, kuid nende kehtivuses on kahtlusi. Igal serveril on oma avalik aadress, mille väljastab host ja mis on seotud riiuliga. See tähendab, et kui serverit liigutada, tuleb aadressi muuta.

Mida peaks tegema?

Ühendage serverid LAG (Link Aggregation Group) abil kahe kaabliga lülititesse riiulis (neid tuleb samuti varundada). Ühendused riiulite vahel varundada, ümber teha „tärniga“ (või moes oleva CLOS), et ühe riiuli väljalangemine ei mõjutaks teisi. Eraldage „keskset“ riiulit, kus asub võrgu süda, ja kuhu ühendatakse teised riiulid. Samuti viige avalik adresseerimine korda, võtke hostilt (või RIR-ilt, kui võimalik) alamvõrk, mida iseseisvalt (või hosti kaudu) maailmale välja kuulutada.

Kas kõike seda saab teha „tavaline“ süsteemiadministraator, kellel pole sügavaid teadmisi võrkudest? Ei ole kindel. Kas host teeb seda? Võib-olla, kuid teilt nõutakse üsna detailset tehnilist dokumentatsiooni, mille peate samuti kellelegi koostama, ja seejärel kontrollima, et kõik oleks õigesti tehtud.

Näide 2. Pilv

Oletame, et teil on VPC mõnes avalikus pilves. Kui soovite pääseda kontorist või kohalikust infrastruktuuri osast teie VPC-s asuvasse kohaliku võrku, peate seadistama ühenduse IPSeci või erakanali kaudu. Ühelt poolt — IPSec on odavam, kuna ei pea ostma lisasüsteeme, saate seadistada tunneli oma avaliku aadressiga serveri ja pilve vahel. Kuid — latentsus, piiratud jõudlus (sest kanalit peab krüpteerima) ning lisaks ei ole garantii ühenduvuse osas (sest juurdepääs toimub tavalisest internetist).

Mida peaks tegema?

Seadistage ühendus erakanali kaudu (näiteks AWS-is nimetatakse seda Direct Connectiks). Selleks leidke partneroperaator, kes teid ühendab, määrake lähim sissetuleku punkti (nii teie kui ka operaatori jaoks pilves) ning lõpuks seadistage kõik. Kas on võimalik seda kõik ära teha ilma võrgutehnika insenerita? Kindlasti on. Kuidas seda seejärel probleemide korral lahendada — see on juba vähem selge.

Samuti võivad tekkida probleeme kättesaadavusega erinevate pilvede vahel (kui teil on mitme pilve lahendus) või probleemid latentsusega erinevate piirkondade vahel jne. Ilmselgelt on nüüd olemas palju tööriistu, mis suurendavad läbipaistvust selle suhtes, mis pilves toimub (näiteks Thousand Eyes), kuid need on kõik võrguinseneri tööriistad, mitte tema asendused.

Ma võiks tuua veel tosin sarnast näidet oma praktikast, kuid ma arvan, et selge on, et meeskonnas peaks alates teatud taseme saavutamisest olema inimene (veel parem, rohkem kui üks), kes teab, kuidas võrk töötab, suudab seadistada võrguvarustust ja lahendada probleeme, kui need tekivad. Usuge mind, tal on piisavalt tegevust.

Mida peaks võrgutehnika insener teadma?

Kaugelki ei ole kindlasti vajalik (ja mõnikord isegi kahjulik), et võrgutehnika insener tegeleks ainult võrgu ja mitte millegagi muuga. Isegi kui mitte arvestada variantidega, kus infrastruktuur elab peaaegu täielikult avalikus pilves (ja see, olgu kuidas on, muutub üha populaarsemaks), ja võtta näiteks kohapealsed või privaatsed pilved, kus pelgalt «CCNP taseme teadmisest» ei piisa.

Lisaks, võrku — kuigi see on lihtsalt lõputu õppimisala, isegi kui keskenduda vaid ühele suunale (teenusepakkujate võrgud, ettevõtted, andmecentrumid, wifi...)

Muidugi, paljud teist meenutavad praegu Pythonit ja muud "võrguhalduse automatiseerimist", kuid see on vaid vajalik, kuid mitte piisav tingimus. Et võrguhalduse insener "edukalt meeskonda sobituda", peab ta oskama rääkida nii arendajate kui ka kolleegide administraatoritega/devopsidega ühes keeles. Mida see tähendab?

• Peab oskama mitte ainult töötada Linuxis kasutajana, vaid ka seda administreerida, vähemalt tasemel algaja süsteemiadministraator: vajalik tarkvara paigaldamine, kukkunud teenuse taaskäivitamine, lihtsa systemd-unit kirjutamine.
• Peab arusaama (vähemalt üldiselt), kuidas Linuxis võrgustikustek toimib, kuidas on võrk hüpervisorites ja konteinerites (lxc / docker / kubernetes) üles ehitatud.
• Muidugi peab oskama töötada ansible/chef/puppet või muu SCM süsteemiga.
• Eraldi tuleb märkida SDN ja võrgud privaatses pilves (näiteks TungstenFabric või OpenvSwitch). See on veel üks tohutu teadmiste valdkond.

Kokkuvõttes olen kirjeldanud tüüpilist T-kujulist spetsialisti (nagu nüüd moes öeldakse). Tundub, et midagi uut ei ole, kuid intervjuude kogemuse põhjal ei saa kaugeltki kõik võrguhalduse insenerid kiidelda teadlikkusega vähemalt kahest ülaltoodud teemast. Praktikas raskendab „seotud valdkondade“ teadmatuse puudumine oluliselt mitte ainult kolleegidega suhtlemist, vaid ka arusaamist nõuetest, mida äri võrku, kui madalaima taseme infrastruktuuri projekti, esitab. Ilma selle arusaamiseta on keerulisem oma seisukohta põhjendada ja "müüd" seda äri.

Teisest küljest annab see harjumus "aru saada, kuidas süsteem töötab" võrguhalduse spetsialistidele väga hea eelise erinevate „laia profiiliga spetsialistide“ ees, kes teavad tehnoloogiatest ainult artiklite põhjal Habrast/Mediumist ja Telegrami vestlustest, kuid ei kujuta üldse ette, millistel printsiipidel see või teine tarkvara töötab. Ja teatavate seaduspärasuste teadmine asendab edukalt paljude faktide teadmist.

Kokkuvõtted või lihtsalt TL;DR

1. Võrguhaldur (nagu ka andmebaasi administraator või VoIP insener) on üsna kitsas spetsialist (erinevalt süsteemihalduritest/devopsidest/SRE-st), kelle peale on vajadus harva, ja see võib kaua kaduda (tõepoolest). Kuid kui see vajadus tekib, siis on tõenäoliselt raske asendada spetsiifilist oskusteavet väliste inimeste (nagu allhanke või tavalised laiemat profiili haldajad, „kes ka võrgu eest hoolitsevad”) poolt. Veelgi kurvem on see, et selliste spetsialistide vajadus on väike, ja tinglikult ettevõttes, kus on 800 programmeerijat ja 30 devopsi/haldurit, võib olla ainult kaks võrguinseneri, kes täidavad oma kohustusi suurepäraselt. See tähendab, et turg oli ja on ikka veel väga väike ning head palgad on veelgi haruldasemad.
2. Teisest küljest peaks hea võrguinsener tänapäeva maailmas teadma mitte ainult võrke (ja kuidas nende seadistamist automatiseerida), vaid ka, kuidas nendega suhtlevad operatsioonisüsteemid ja tarkvara, mis nende võrkude peal töötavad. Ilma selleta on äärmiselt keeruline mõista, mida kolleegid sinult soovivad, ja edastada (põhjendatult) oma soove/nõudmisi neile.
3. Pilved ei eksisteeri, need on lihtsalt kellegi teise arvutid. Tuleb mõista, et avalike/privaatsuse pilvede või hostimisproviiderite teenuste kasutamine, "mis teeb kõik teie eest valmis" ei tähenda, et teie rakendus ei kasuta võrku ning võrguga seotud probleemid mõjutavad endiselt teie rakenduse toimimist. Teie valik on, kus asub kompetentsikeskus, mis vastutab teie projekti võrgu eest.

Allikas: habr.com