Võrgu spetsialistid (ei) ole vajalikud

Artikli kirjutamise hetkel andis populaarse tööportaali otsing fraasi „Võrguinsener” järgi Venemaal umbes kolm sada töökohta. Võrdluseks: fraasi „süsteemihaldur” otsing annab peaaegu 2,5 tuhat töökohta, samas kui „DevOps insener” — peaaegu 800.

Kas see tähendab, et võrguinsenerid pole enam vajalikud, kui pilv, Docker, Kubernetes ja igal pool leviv avalik WiFi on võimust võtnud?
Hakkame uurima (c)

Tere, olen Alexei, ja ma olen võrguinsener.

Olen enam kui 10 aastat tegelenud võrkudega ja üle 15 aasta töötanud erinevate *nix süsteemidega (olen puutunud kokku nii Linuxi kui ka FreeBSD-ga). Olen töötanud sideettevõtetes, suurtes ettevõtetes, mida peetakse „ettevõtete” hulka, ja viimastel aegadel tööl „noores ja julges” fintechis, kus pilved, DevOps, Kubernetes ja muud hirmuäratavad sõnad, mis kindlasti muudavad mind ja mu kolleege kunagi üleliigseks. Võib-olla.

Käesolev teade: „Elus pole kõik alati ja igal pool, aga mõne asja puhul, vahel ja teatud kohtades” (c) Maxim Dorofeev.

Kogu alljärgnev on autori isiklik arvamus, mis ei pretendeeri absoluutsele tõele ega ka täielikele teadusuuringutele. Kõik tegelased on väljamõeldud, kõik kokkusattumised on juhuslikud.

Tere tulemast minu maailma.

Kus võib üldse võrguinimesi kohata?

1. Sideoperaatorid, teenindusettevõtted ja muud integreerijad. Siin on kõik lihtne: nende jaoks on võrgustik äri. Nad kas müüvad otseühendust (operaatorid) või pakuvad oma klientide võrkude käivitamise/hooldamise teenuseid.

Siin on palju kogemusi, aga raha — mitte nii palju (kui te ei ole direktor või edukas müügihaldur). Sellegipoolest, kui teile meeldib võrgu- ja IT-tehnoloogia ning olete alles algusjärgus, siis karjäär mingis väiksemas teeninduses oleks isegi praegu ideaalne koht alustamiseks (kuberneetses on kõik väga scriptitud ning loovuse jaoks on vähe ruumi). Ja lood selle kohta, et saate dežuurinsenerist paari aastaga C-tasandi juhiks tõusta, on samuti päris reaalsed, kuigi haruldased, arusaadavatel põhjustel. Tööjõu vajadus on alati olemas, sest töötajate voolavus on tõepoolest olemas. See on samal ajal nii hea kui halb — alati on vabu kohti, aga teisest küljest, kõige aktiivsemad/ nutikamad kipuvad kiiresti edasi liikuma või otsima soojemaid kohti.

2. Tingimuslik "ettevõte". Pole see, kas tema peamine tegevus on seotud IT-ga või mitte. Oluline on, et tal on oma IT-osakond, mis hoolitseb ettevõtte sisemiste süsteemide korralduse eest, sealhulgas kontorite võrkude ja harude kommunikatsioonikanalite eest jne. Sellistes ettevõtetes võib võrguinseneri funktsioone „korraga“ täita süsteemiadministraator (kui võrguinfrastruktuur on väike või sellega tegeleb väline alltöövõtja), ning kui võrguinsener siiski on, võib ta samas ka telefoniteenuseid ja SAN-i (pikka juttu) jälgida. Palgad varieeruvad — see sõltub tugevalt äri marginaalsusest, ettevõtte suurusest ja struktuurist. Olen töötanud nii ettevõtetes, kus Cisco seadmeid sageli „koormati”, kui ka ettevõtetes, kus võrk rajati peamiselt vanadest materjalidest ja lintidest, ning servereid ei uuendatud kunagi (kas on vajalik öelda, et reserve polnud ka olemas). Kogemust on siin oluliselt vähem ja see jääb peamiselt rangesse vendor-lock'i või „kuidas luua midagi tühjast”. Isiklikult leidsin selle keskkonna äärmiselt igavaks, kuigi paljudele meeldib — kõik on piisavalt mõõdukas ja ettearvatav (kui räägime suurtest ettevõtetest), „oratoort ja palju muud” jne. Mitte harvem kui kord aastas ütleb mõni suur edasimüüja, et on välja mõelnud järgmise mega-super-duper süsteemi, mis nüüd automaatiseerib kõik ning lõpetab kõik süsteemiadministraatorid ja võrguinsenerid, jättes paar inimest, kes vajutavad nuppudele ilusas liideses. Reaalsus on aga selline, et isegi kui ignoreerida lahenduse maksumust, ei kao võrguinsenerid sealt kuhugi. Jah, tõenäoliselt on konsooli asemel taas veebiliides (aga mitte ühe konkreetse seadme, vaid suure süsteemi jaoks, mis haldab kümneid ja sadu selliseid seadmeid), kuid teadmised „kuidas kõik seestpoolt toimib“ on ikkagi vajalikud.

3. Tootmisettevõtted, mille kasum tuleb mingi tarkvara või platvormi arendamisest (ja sageli ka kasutamisest) – just see toode. Need on tavaliselt väikesed ja kiirete tegijatega, nad on veel kaugel ettevõtete suurusest ja bürokraatiast. Just siin leidub massiliselt neid kurikuulsaid devops'e, küberite, dokkerite ja muid hirmuäratavaid sõnu, mis muudavad võrgu- ja võrguinsenerid soovimatuks jäänukiks.

Kuidas erineb võrguinsener süsteemiadministraatorist?

Inimeste jaoks, kes ei tööta IT-s — ei erinegi. Mõlemad vaatavad musta ekraani ja kirjutavad mingisuguseid loitse, vahel sosinal vandudes.

Programmeerijate arusaamas — võib-olla teemavaldkonna osas. Süsteemiadministraatorid haldavad servereid, võrguinsenerid haldavad lüliteid ja marsruutereid. Mõnikord teevad nad halba tööd ja kõik kukub kokku. Igaks juhuks on süüdi samuti võrguinsenerid. Just because fuck you, that’s why.

Tegelikult on peamine erinevus tööprotsessis. Tõenäoliselt on just võrguinseneride seas kõige rohkem esindajaid, kes toetavad lähenemist "Nagu töötab — ärge puudutage!". Teatud asja (ühe tootja raames) saab teha tavaliselt vaid ühel viisil, kogu seadistamine on käeulatuses. Vigade hind on kõrge, ja mõnikord isegi väga kõrge (näiteks tuleb sõita mitusada kilomeetrit, et ruuterit taaskäivitada, samal ajal kui mitu tuhat inimest jääb ühenduseta — see on telekommunikatsiooniteenuse pakkuja jaoks üsna tavaline olukord).

Minu arvates on just seetõttu võrguinsenerid, esiteks, äärmiselt motiveeritud võrgu stabiilsuse nimel (muudatused on stabiilsuse peamine vaenlane) ning teiseks, nende teadmised on sügavamad, mitte laiemad (ei pea suutma konfigureerida kümneid erinevaid daemon'e, vaid tuleb tunda tehnoloogiaid ja nende teostust konkreetse seadme tootja juures). Seepärast ei ole süsteemiadministraator, kes Google'ist otsib, kuidas Cisco'is VLAN'i konfigureerida, veel võrguinsener. Ja tõenäoliselt ei suuda ta tõhusalt toetada (ning tõrkeotsingut teostada) enam-vähem keerulist võrku.

Aga miks on vaja võrku, kui sul on hoster?

Lisaraha eest (ja kui oled väga suur ja armastatud klient — võib-olla isegi tasuta, "sõpruse nimel") seadistavad andmekeskuse insenerid sinu lülitid vastavalt sinu vajadustele ning võivad isegi aidata BGP-sid ühiselt pakkujate vahel püstitada (kui sul on oma alamvõrk IP-aadresse aste).

Peamine probleem on see, et andmekeskus ei ole teie IT-osakond, vaid eraldi ettevõte, mille eesmärk on kasumiteenimine. Sealhulgas teie, kui kliendi, arvelt. Andmekeskus pakub riiuleid, tagab nende elektri ja jahutuse, samuti võimaldab teatud "vaikest" ühendust internetiga. Selle infrastruktuuri baasil võib andmekeskus paigutada teie varustuse (kolokatsioon), rendile anda teile serveri (dedicated server) või pakkuda hallatud teenust (nt OpenStack või K8s). Kuid andmekeskuse äri (tavaliselt) ei ole klientide infrastruktuuri haldamine, kuna see protsess on üsna ajakulukas, halvasti automatiseeritav (ja korralikus andmekeskuses automatiseeritakse kõik, mis üldse võimalik on), veel halvemini ühtlustatav (iga klient on ainulaadne) ja see on tegelikult riskantne ("te configuurasite mulle serveri, aga nüüd see kukkus, see on teie süü!!!111"). Seetõttu, kui hostija aitab teid mingil viisil, siis püüab ta seda teha võimalikult lihtsalt ja "põhjalikult". Sest keerulise tegemine pole kasulik, vähemalt inseneride töömahule toomise seisukohalt (aga olukorrad võivad olla erinevad, vt mitte vastuta). See ei tähenda, et hostija teeb seda kindlasti halvasti. Kuid ei ole üldse kindel, et ta teeb just seda, mida tegelikult vajasite.

Tundub, et see on piisavalt selge asi, kuid olen oma praktikas korduvalt kokku puutunud juhtumitega, kus ettevõtted hakkasid lootes oma hostimisteenuse pakkujale rohkem, kui oleks pidanud, ja see ei toonud midagi head. Pidi pikka ja detailselt selgitama, et ükski SLA ei kata seisaku tõttu tekkinud kahjusid (olemas on erandeid, kuid tavaliselt on see kliendile väga, väga kallis) ja et hostija ei ole üldse teadlik sellest, mis toimub tellijate infrastruktuuris (välja arvatud väga üldised näitajad). Ja hostija ei tee ka varukoopiaid teie eest. Veel halvem on asi, kui teil on rohkem kui üks hostija. Kui tekivad mingid probleemid, ei hakka nad kindlasti teie eest selgitama, mis ikkagi valesti läks.

Motivatsioonid on siin täpselt sellised nagu valides 'oma adminnime vs välishallamine'. Kui riskid on kalkuleeritud, kvaliteet sobib ja äri ei ole vastu — miks mitte proovida. Teiselt poolt, võrk on üks kõige põhjalikumaid infrastruktuuri kihte, ja tõenäoliselt ei ole mõtet usaldada seda inimestele, keda te ei tunne, kui kõik muu on teil juba enda kätes.

Millal on võrgutöötaja vajalik?

Edasi räägime just modernsetest tooteettevõtetest. O operadorid ja äriklientide puhul on kõik enam-vähem selge – seal pole viimastel aastatel palju muutunud, ja võrgu spetsialiste on varemgi tarvitatud, vajatakse neid ka nüüd. Kuid noorte ja julgete ettevõtetega ei ole asi nii selge. Tihti majutavad nad kogu oma infrastruktuuri pilvedes, nii et isegi administraatoreid neile eriti ei vajata – välja arvatud nende pilvedes töötavad administraatorid, muidugi. Infrastruktuur on oma loomult üsna lihtne, kuid samas hästi automatiseeritud (ansible/puppet, terraform, ci/cd… noh, teate küll). Kuid isegi siin on olukordi, kus ilma võrguinsenerita ei saa hakkama.

Näide 1, klassikaline

Oletame, et ettevõte alustab ühe serveriga, millel on avalik IP-aadress ja mis asub andmekeskuses. Siis lisandub serverite arv ja see kasvab ... Varsti tekib vajadus serverite vahelise privaatsõrve järele. Sest 'välis' liiklust piiravad nii ribalaius (näiteks mitte üle 100 Mbit/s) kui ka kuus alla- ja üleslaaditud mahud (erinevatel hostidel on erinevad hinnakujundused, kuid välismaailma ribalaius on tavaliselt palju kallim kui privaatvõrku).

Haldaja lisab serveritesse täiendavaid võrgukaarte ja ühendab need oma lülitite kaudu eraldi VLANi. Serverite vahel tekib 'tasane' kohalik võrk. Mugav!

Serverite arv kasvab, samuti kasvab liiklus privaatse võrgu sees — varundused, replikatsioonid jne. Haldur pakub võimalust eraldada teid eraldi lülititesse, et te ei segaks teisi kliente ja nemad ei segaks teid. Haldur seab üles teatud lülitid ja seadistab need mingil viisil — tõenäoliselt jättes kõikide teie serverite vahel ühe tasase võrgu. Kõik töötab hästi, kuid mingil hetkel tekivad probleemid: aeg-ajalt kasvavad viivitused hostide vahel, logides on muresid liiga suure arvu arp-pakettide kohta sekundis, ja pen-tester auditeerimise käigus on saanud teie kohaliku võrgu kätte, purustades vaid ühe serveri.

Mida on vaja teha?

Jagada võrk segmentideks — vlani'ks. Iga vlani jaoks seadistada oma aadressimine, eraldada värav, mis suunab liiklust võrkude vahel. Väravas seadistada ACL, et piirata juurdepääsu segmentide vahel, või isegi asetada kõrvale eraldi tulemüür.

Näide 1, jätk

Serverid on ühendatud kohaliku võrgu ühe kaabli abil. Lülitid on riiulites omavahel ühendatud, kuid ühe riiuli rikke korral võivad kõik naabrid laguneda. Skeemid on olemas, kuid nende ajakohasuses on kahtlusi. Igal serveril on oma avalik aadress, mille annab välja hostija ja mis on seotud riiuliga. See tähendab, et serveri liigutamisel tuleb aadressi muuta.

Mida on vaja teha?

Serverite ühendamine LAG (Link Aggregation Group) abil kahe kaabli kaudu riiuli lülititesse (need tuleb samuti varundada). Ühendused riiulite vahel tuleb varundada, muuta „täheks” (või populaarseks CLOS-iks), et ühe riiuli langemine ei mõjutaks teisi. Eraldada „kesk-rack'id”, kuhu paigutatakse võrgutuum ja kuhu ühendatakse teised riiulid. Samuti korrastada avalik adresseerimine, võtta hostijalt (või RIR-ilt, kui on võimalus) alamvõrk, mida iseseisvalt (või läbi hostija) maailmas kuulutada.

Kas kõige seda suudab teha tavaline süsteemiadministraator, kellel pole sügavaid teadmisi võrkudest? Kahtlen. Kas teeb seda hostiteenuse pakkuja? Võib-olla, kuid teil on vaja esitada piisavalt detailne tehniline ülesanne, mille koostamiseks on samuti keegi vajalik. Ja siis tuleb kontrollida, et kõik oleks õigesti tehtud.

Näide 2. Pilv

Kujutage ette, et teil on VPC mõnes avalikus pilves. Et saada juurdepääs kontorist või on-prem osa infrastruktuurist VPC sees asuvale lokaalsele võrgule, peate seadistama ühenduse IPSeci või erakanali kaudu. Ühelt poolt — IPSec on odavam, kuna ei pea ostma lisaraha, saate seadistada tunneli teie avaliku IP-aadressiga serveri ja pilve vahele. Kuid — viivitused, piiratud jõudlus (sest kanal tuleb krüpteerida), pluss tagatud ühenduvuse puudumine (sest juurdepääs toimub tavalisest internetist).

Mida on vaja teha?

Tõsta ühendusdedikaatkanali kaudu (näiteks AWS-is nimetatakse seda Direct Connectiks). Selleks leia partner-teenusepakkuja, kes sind ühendab, otsusta, milline on sulle lähim liitumiskoht (nii sulle teenusepakkuja kui ka teenusepakkujat pilve) ja lõpuks, seadista kõik. Kas seda saab teha ka ilma võrguinsenerita? Kindlasti jah. Kuidas aga sellega probleemide korral tõrkeotsingut teha, ei ole enam nii selge.

Samuti võivad tekkida probleemid juurdepääsuga erinevate pilvede vahel (kui sul on mitme pilve lahendus) või viivitustega erinevates piirkondades jne. Loomulikult on nüüd palju tööriistu, mis suurendavad läbi nähtavust, mis pilves toimub (näiteks Thousand Eyes), kuid need kõik on võrguinseneri tööriistad, mitte tema asendajad.

Ma võiksin veel tosin sellist näidet oma praktikast tuua, kuid arvan, et on selge, et alates teatud infrastruktuuri arengu tasemest peab meeskonnas olema inimene (veelgi parem, rohkem kui üks), kes teab, kuidas võrk töötab, suudab seadistada võrgu seadmeid ja lahendada probleeme, kui need tekivad. Usuge, tal on piisavalt tegemist.

Mida peaks teadma võrguspetsialist?

Võrguspetsialist ei pea kindlasti tegelema ainult võrguga, mõnikord võib see isegi kahjulik olla. Isegi kui vaadata varianti infrastruktuurist, mis elab peamiselt avalikes pilvedes (mis muutub järjest populaarsemaks), ja võtta näiteks kohalikud teenused või erasüsteemid, ei piisa ainult "CCNP tasemel teadmistest".

Lisaks, iseenesest, võrkudele — kuigi õppimisvõimalused on siin lõputud, isegi kui keskenduda ainult ühele suunale (teenusepakkujate võrgud, ettevõtted, andmekeskused, WiFi ...)

Muidugi meenutab paljusid teist Python ja muud "võrgu automatiseerimise" tööriistad, kuid see on vaid vajalik, kuid mitte piisav tingimus. Et võrguspetsialist "edukalt meeskonda sulanduda", peab ta suutma rääkida ühte keelt nii arendajate kui ka administraatorite/devops'idega. Mida see tähendab?

• oskama mitte ainult Linuxit kasutajana kasutada, vaid ka seda hallata, vähemalt algaja süsteemiadministraatori tasemel: vajalik tarkvara paigaldada, tõrkunud teenust taastada, kirjutada lihtne systemd-unit.
• Mõista (vähemalt üldiselt), kuidas Linuxi võrgustikustakk töötab, kuidas on korraldatud võrgu hüperviisorites ja konteinerites (lxc / docker / kubernetes).
• Muidugi, osata töötada ansible'i / chef'i / puppet'i või mõne muu SCM süsteemiga.
• Erakordselt tuleb mainida ka SDN-i ja üksikasjalikke võrke privaatsete pilvede jaoks (näiteks TungstenFabric või OpenvSwitch). See on veel üks suur teadmiste valdkond.

Kokkuvõttes kirjeldasin tüüpilist T-kujulist spetsialisti (nagu praegu moes on). Tundub, et pole midagi uut, kuid intervjuudest lähtuvalt ei saa kõik võrguinsenerid uhkustada teadmistega vähemalt kahe ülaltoodud teema kohta. Praktikas raskendab teadmiste puudumine "kõrvutavates valdkondades" oluliselt mitte ainult suhtlemist kolleegidega, vaid ka arusaamist nõuetest, mida ettevõte võrgu, kui madalaim infrastruktuuri osa, esitab. Ilma selliste arusaamadeta on keerulisem oma seisukohti õigustada ja neid ettevõttele "müüa".

Teisest küljest annab harjumus " mõista, kuidas süsteem töötab" võrkturundajatele suurepärase eelise erinevate "laiade spetsialistide" ees, kes teavad tehnoloogiat ainult Habr'st / Mediumist ja Telegrami vestlustest, kuid ei tea üldse, millistel printsiipidel töötab see või teine tarkvara. Ning teatavate seaduspärasuste tundmine, nagu teada, asendab edukalt paljude faktide teadmist.

Järeldused või lihtsalt TL;DR

1. Võrguhaldur (nagu DBA või VoIP-insener) on üsna kitsas spetsialiteet (erinevalt süsteemihalduritest/devopsidest/SRE-st), mille järele vajadus ei teki kohe (ja võib tõepoolest kaua aega mitte tekkida). Kuid kui vajadus tekib, siis on keeruline asendada seda teadmistega väljaspoolt (välismaa teenuseid või tavapäraseid laialdase profiiliga administraatoreid, „kes jälgivad ka võrke”). Mis on veelgi kurvem — selliste spetsialistide vajadus on väike, ja tinglikult võib 800 arendajaga ja 30 devopsi/adminiga ettevõttes olla vaid kaks võrguspetsialisti, kes oma ülesannetega kenasti toime tulevad. See tähendab, et turg on olnud ja on endiselt väga väike, ning et hea palgaga — veelgi vähem.
2. Teiselt poolt peab hea võrguspetsialist tänapäeva maailmas teadma mitte ainult võrke (ja kuidas nende seadistust automatiseerida), vaid ka seda, kuidas nendega suhtlevad operatsioonisüsteemid ja tarkvara, mis nende üle töötab. Ilma selleta on äärmiselt keeruline mõista, mida kolleegid sinult soovivad, ja õigustatult edastada neile oma soove/nõudeid.
3. Pilvi ei ole midagi muud kui kellegi teise arvuti. Tuleb mõista, et avalike/privaatselte pilvede või teenusepakkujate kasutamine, „kes teeb teile kõik valmis“, ei tühista seda, et teie rakendus kasutab endiselt võrku, ja selle probleemid mõjutavad teie rakenduse tööd. Teie valik on, kus asub kompetentsikeskus, mis vastutab teie projekti võrgu eest.

Allikas: habr.com