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.
Опыта здесь много, денег — не очень (если вы не директор или успешный менеджер-продажник). И тем не менее, если вам нравятся сети, и вы только в начале пути, карьера в саппорте какого-нибудь не очень крупного оператора будет, даже сейчас, идеальной точкой для старта (в федеральных всё очень скриптовано, и простора для творчества мало). Ну и истории про то, что можно из дежурного инженера дорасти за несколько лет до C-level manager тоже вполне реальны, хотя и редки, по понятным причинам. Потребность в кадрах есть всегда, потому что текучка таки имеет место быть. Это и хорошо, и плохо одновременно — всегда есть вакансии, с другой стороны — зачастую, самые активные/умные достаточно быстро уходят либо на повышение, либо в другие, более «тёплые» места.
2. Условный «энтерпрайз». Не важно, связана ли его основная деятельность с ИТ, или нет. Главное — что в нём есть свой IT отдел, который занимается обеспечением работы внутренних систем компании, в том числе сети в офисах, каналов связи в филиалы и т.д. Функции сетевого инженера в таких компаниях может «по совместительству» выполнять системный администратор (если сетевая инфраструктура небольшая, или ей занимается внешний подрядчик), а сетевик, если он всё-таки есть, может присматривать заодно за телефонией и SAN (ненуачо). Платят по-разному — сильно зависит от маржинальности бизнеса, размеров компании и структуры. Я работал и с компаниями, где циски регулярно «грузили бочками», и с компаниями, где сеть строили из фекалий, палок и синей изоленты, а серверы не обновляли, примерно, никогда (надо ли говорить, что никаких резервов тоже предусмотрено не было). Опыта здесь сильно меньше, и он, почти наверняка будет в области жёсткого vendor-lock, либо «как из ничего сделать кое-что». Лично мне там показалось дико скучно, хотя многим нравится — всё достаточно размеренно и предсказуемо (если мы говорим о крупных компаниях), «дораха-бахато» и т.д. Не реже раза в год какой-нибудь крупный вендор говорит, что придумал очередную мега-супер-пупер-систему, которая вот вообще всё сейчас автоматизирует и всех сисадминов и сетевиков можно будет разогнать, оставив парочку для нажимания на кнопки в красивом интерфейсе. Реальность же такова, что, даже если абстрагироваться от стоимости решения, никуда сетевики оттуда не денутся. Да, возможно, вместо консоли снова будет веб-интерфейс (но уже не конкретной железки, а большой системы, которая управляет десятками и сотнями таких железок), но знания «как всё внутри устроено» всё равно понадобятся.
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
- 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.
- 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.
- 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
