Šio rašymo metu populiarioje darbo svetainėje ieškant frazės „Tinklo inžinierius“ visoje Rusijoje buvo paskelbta apie tris šimtus laisvų darbo vietų. Palyginimui, paieškoje pagal frazę „sistemos administratorius“ pateikiama beveik 2.5 tūkstančio laisvų darbo vietų, o „DevOps inžinierius“ – beveik 800.
Ar tai reiškia, kad tinklų kūrėjai nebereikalingi debesų, dokerių, kubernečių ir visur esančio viešojo Wi-Fi laikais?
Išsiaiškinkime (-ai)
Susipažinkime. Mano vardas Aleksejus, aš esu tinklo darbuotojas.
Tinklo kūrimu užsiimu daugiau nei 10 metų ir daugiau nei 15 metų dirbu su įvairiomis *nix sistemomis (turėjau galimybę pasirinkti ir Linux, ir FreeBSD). Dirbau telekomunikacijų operatoriuose, didelėse įmonėse, kurios laikomos „įmonėmis“, o pastaruoju metu dirbu „jaunų ir drąsių“ fintech srityje, kur debesys, devops, kubernetes ir kiti baisūs žodžiai, kurie tikrai privers mane ir mano kolegas. nereikalingas. Kažkada. Gal būt.
atsisakymas: „Mūsų gyvenime ne viskas, visada ir visur, bet kažkas, kartais vietomis“ (c) Maksimas Dorofejevas.
Viskas, kas parašyta žemiau, gali ir turi būti laikoma asmenine autoriaus nuomone, nepretenduojančia į galutinę tiesą ir net visaverčiu tyrimu. Visi veikėjai fiktyvūs, visi sutapimai atsitiktiniai.
Sveiki atvykę į mano pasaulį.
Kur galima rasti tinklų kūrėjų?
1. Telekomunikacijų operatoriai, paslaugų įmonės ir kiti integratoriai. Viskas paprasta: tinklas jiems yra verslas. Jie arba tiesiogiai parduoda ryšį (operatorius) arba teikia paslaugas, skirtas savo klientų tinklams paleisti / palaikyti.
Patirties čia daug, bet pinigų nedaug (nebent esi direktorius ar sėkmingas pardavimų vadovas). Ir vis dėlto, jei jums patinka tinklai ir esate tik savo kelionės pradžioje, karjera, remiant kokį nors nelabai didelį operatorių, net ir dabar bus idealus atspirties taškas (federaliniuose tinkluose viskas labai surašyta, o ten yra mažai vietos kūrybai). Na, o istorijos apie tai, kad iš budinčio inžinieriaus per kelerius metus galima išaugti iki C lygio vadovo, irgi gana tikros, nors ir retos, dėl suprantamų priežasčių. Visada reikia personalo, nes vis tiek yra kaita. Tai ir gerai, ir blogai vienu metu - laisvų vietų visada yra, kita vertus - dažnai patys aktyviausi/protingiausi pakankamai greitai arba paaukštinami, arba iškeliauja į kitas, "šiltesnes" vietas.
2. Sąlyginė „įmonė“. Nesvarbu, ar jo pagrindinė veikla susijusi su IT, ar ne. Svarbiausia, kad ji turi savo IT skyrių, kuris užsiima įmonės vidinių sistemų veikimo užtikrinimu, įskaitant tinklus biuruose, ryšių kanalus su filialais ir kt. Tinklo inžinieriaus funkcijas tokiose įmonėse „ne visą darbo dieną“ gali atlikti sistemos administratorius (jei tinklo infrastruktūra nedidelė, arba ja užsiima išorinis rangovas), o tinklo valdytojas, jei jis dar egzistuoja, gali. vienu metu prižiūrėti telefoniją ir SAN (ne nuacho). Jie moka įvairiai – tai stipriai priklauso nuo verslo maržos, įmonės dydžio ir struktūros. Dirbau ir su įmonėmis, kur ciscos buvo reguliariai „kraunamos į statines“, ir su įmonėmis, kuriose tinklas buvo kuriamas iš fekalijų, pagaliukų ir mėlynos elektros juostos, o serveriai nebuvo atnaujinti, maždaug, niekada (reikia pasakyti, kad ten rezervų taip pat nebuvo). Patirties čia daug mažiau, ir tai beveik neabejotinai bus „kietojo pardavėjo užrakto“ arba „kaip iš nieko padaryti ką nors“ srityje. Asmeniškai man ten atrodė beprotiškai nuobodu, nors daugeliui tai patinka - viskas gana pamatuota ir nuspėjama (jei kalbame apie dideles įmones), „dorah-bajato“ ir pan. Bent kartą per metus koks nors stambus pardavėjas sako, kad sugalvojo dar vieną super-duper sistemą, kuri dabar viską automatizuoja, o visus sistemos administratorius ir tinklų darbuotojus galima peršokti, o pora paspaudžia mygtukus gražioje sąsajoje. Tikrovė tokia, kad net jei neatsižvelgsime į sprendimo kainą, tinklų kūrėjai iš ten niekur nedings. Taip, gali būti, kad vietoj konsolės vėl bus internetinė sąsaja (bet ne konkreti geležies gabalėlis, o didelė sistema, valdanti dešimtis ir šimtus tokių geležies gabalų), bet žinios „kaip viskas veikia viduje “ vis tiek reikės.
3. Gaminių įmonės, kurios pelnas gaunamas kuriant (ir dažnai eksploatuojant) kokią nors programinę įrangą ar platformą – tą patį produktą. Paprastai jie yra maži ir veržlūs, jie dar toli nuo įmonių ir jų biurokratizavimo masto. Būtent čia randama daug tų pačių devopų, kuberių, dokerių ir kitų baisių žodžių, dėl kurių tinklas ir tinklo inžinieriai tikrai taps nereikalingu užuomazga.
Kuo tinklo valdytojas skiriasi nuo sistemos administratoriaus?
Žmonių supratimu ne iš IT – nieko. Abu žiūri į juodą ekraną ir rašo kokius nors burtus, kartais tyliai keikiasi.
Programuotojų supratimu – galbūt dalykinė sritis. Sistemos administratoriai administruoja serverius, tinklų operatoriai – jungiklius ir maršrutizatorius. Kartais blogas adminas, ir visiems viskas nukrenta. Na, o jei kas keista, kalti ir tinklininkai. Tiesiog todėl, kad velniok tave, štai kodėl.
Tiesą sakant, pagrindinis skirtumas yra požiūris į darbą. Galbūt tarp tinklų kūrėjų labiausiai palaikomas požiūris „Tai veikia – neliesk! Paprastai ką nors (vieno pardavėjo viduje) galite padaryti tik vienu būdu, visą dėžutės konfigūraciją – štai, jūsų delne. Klaidos kaina yra didelė, o kartais ir labai didelė (pavyzdžiui, norėdami iš naujo paleisti maršrutizatorių turite nuvažiuoti kelis šimtus kilometrų, o šiuo metu keli tūkstančiai žmonių bus be ryšio - tokia situacija yra gana įprasta telekomunikacijų operatoriui ).
Mano nuomone, dėl to tinklų inžinieriai, viena vertus, yra labai stipriai motyvuoti tinklo stabilumui (o pokyčiai yra pagrindinis stabilumo priešas), antra, jų žinios yra labiau gilios nei plačios (nereikia). Kad galėtumėte sukonfigūruoti daugybę skirtingų demonų, turite žinoti konkretaus įrangos gamintojo technologijas ir jų įgyvendinimą). Štai kodėl sistemos administratorius, kuris „Google“ ieškojo, kaip užregistruoti vlan tsiska, dar nėra tinklo valdytojas. Ir mažai tikėtina, kad jis galės veiksmingai palaikyti (taip pat ir šalinti) daugiau ar mažiau sudėtingą tinklą.
Bet kam jums reikalingas tinklo valdytojas, jei turite prieglobą?
Už papildomus pinigus (o jei esate labai didelis ir mylimas klientas, gal net nemokamai, „kaip draugas“) duomenų centro inžinieriai sukonfigūruos jūsų jungiklius, kad atitiktų jūsų poreikius, o galbūt net padės sukurti BGP sąsają. su teikėjais (jei turite savo IP adresų potinklį, kurį norite paskelbti).
Pagrindinė problema yra ta, kad duomenų centras nėra jūsų IT skyrius, tai yra atskira įmonė, kurios tikslas – gauti pelną. Įskaitant jūsų, kaip kliento, sąskaita. Duomenų centras aprūpina stelažus, aprūpina juos elektra ir šalčiu, taip pat suteikia tam tikrą „numatytąjį“ ryšį su internetu. Remdamasis šia infrastruktūra, duomenų centras gali nustatyti jūsų įrangą (kolokacija), išsinuomoti jums serverį (specialųjį serverį) arba teikti valdomą paslaugą (pavyzdžiui, „OpenStack“ arba „K8s“). Bet duomenų centro verslas (dažniausiai) nėra klientų infrastruktūros administravimas, nes šis procesas yra gana daug darbo jėgos, menkai automatizuotas (o įprastame duomenų centre viskas automatizuota), unifikuotas dar blogiau (kiekvienas klientas individualus) ir apskritai kupinas pretenzijų („pasakyk man, kad serveris buvo nustatytas, o dabar jis sudužo, dėl to tu kaltas!!!111“). Todėl, jei šeimininkas jums kažkuo padės, jis stengsis tai padaryti kuo paprastesnį ir „butą“. Nes tai padaryti sunku - nepelninga, bent jau šio šeimininko inžinierių darbo sąnaudų požiūriu (tačiau situacijos yra skirtingos, žr. atsakomybės atsisakymą). Tai nereiškia, kad šeimininkas būtinai viską padarys blogai. Bet tai visai ne faktas, kad jis padarys būtent tai, ko jums iš tikrųjų reikėjo.
Atrodytų, dalykas yra gana akivaizdus, tačiau keletą kartų savo praktikoje susidūriau su tuo, kad įmonės pradėjo pasitikėti savo prieglobos paslaugų teikėju šiek tiek labiau nei turėtų, ir tai nieko gero neprivedė. Teko ilgai smulkiai aiškinti, kad jokia SLA nepadengs prastovų nuostolių (yra išimčių, bet dažniausiai tai klientui yra labai labai brangu) ir prieglobos paslaugų teikėjas visiškai nežino, kas vyksta klientų infrastruktūroje. (išskyrus labai bendrus rodiklius). Ir prieglobos serveris taip pat nedaro jums atsarginių kopijų. Situacija dar blogesnė, jei turite daugiau nei vieną šeimininką. Iškilus problemoms tarp jų, jie tikrai nesužinos už jus, kas nutiko.
Tiesą sakant, motyvai čia yra lygiai tokie patys, kaip ir renkantis „sava administratorių komanda prieš užsakomąsias paslaugas“. Jei rizika paskaičiuota, kokybė tinka, o verslas neprieštarauja – kodėl gi nepabandžius. Kita vertus, tinklas yra vienas elementariausių infrastruktūros sluoksnių ir vargu ar verta jį atiduoti pašaliniams, jei visa kita jau palaikote pats.
Kada jums reikia tinklo specialisto?
Toliau orientuosimės į modernių produktų įmones. Su operatoriais ir įmonėmis viskas plius minus aišku – pastaraisiais metais ten mažai kas pasikeitė, o tinklininkų ten reikėjo anksčiau, jų reikia ir dabar. Tačiau su tais labai „jaunais ir drąsiais“ viskas nėra taip paprasta. Dažnai jie visą savo infrastruktūrą deda į debesis, todėl jiems net nereikia administratorių, išskyrus, žinoma, tų pačių debesų administratorius. Viena vertus, infrastruktūra yra gana paprasta savo dizainu, kita vertus, ji yra gerai automatizuota (ansible / marionet, terraform, ci / cd ... na, žinote). Tačiau net ir čia yra situacijų, kai negalite išsiversti be tinklo inžinieriaus.
1 pavyzdys, klasika
Tarkime, kad įmonė pradeda nuo vieno serverio su viešu IP adresu, kuris yra duomenų centre. Tada yra du serveriai. Tada daugiau... Anksčiau ar vėliau tarp serverių prireiks privataus tinklo. Kadangi „išorinį“ srautą riboja tiek pralaidumas (pavyzdžiui, ne daugiau kaip 100 Mbps), ir atsisiunčiamų / įkeltų per mėnesį kiekis (skirtingi prieglobos serveriai turi skirtingus tarifus, tačiau pralaidumas išoriniam pasauliui, kaip taisyklė, yra didelis brangesnis nei privatus tinklas).
Prieglobos kompiuteris prideda papildomų tinklo plokščių prie serverių ir įtraukia jas į savo jungiklius atskirame vlan. Tarp serverių atsiranda „plokščias“ LAN. Patogus!
Auga serverių skaičius, auga ir srautas privačiame tinkle – atsarginės kopijos, replikacijos ir t.t. Prieglobos vedėjas siūlo perkelti į atskirus jungiklius, kad netrukdytumėte kitiems klientams, o jie netrukdytų jums. Prieglobos serveris įdeda kažkokius jungiklius ir kažkaip juos sukonfigūruoja – greičiausiai palieka vieną plokščią tinklą tarp visų jūsų serverių. Viskas veikia gerai, bet tam tikru momentu prasideda problemos: periodiškai didėja vėlavimai tarp hostų, žurnalai prisiekia per daug arp paketų per sekundę, o pentesteris audito metu išprievartavo visą jūsų vietinę sritį, sulaužydamas tik vieną serverį.
Ką reikėtų daryti?
Padalinkite tinklą į segmentus - vlans. Kiekviename vlan nustatykite savo adresą, pasirinkite šliuzą, kuris perduos srautą tarp tinklų. Šliuze sukonfigūruokite ACL, kad apribotumėte prieigą tarp segmentų arba net šalia jo pastatykite atskirą užkardą.
1 pavyzdys, tęsinys
Serveriai yra prijungti prie vietinės zonos vienu laidu. Jungikliai stelažuose yra kažkaip tarpusavyje sujungti, tačiau įvykus avarijai viename stove, nukrenta dar trys kaimyniniai. Schemos egzistuoja, tačiau kyla abejonių dėl jų tinkamumo. Kiekvienas serveris turi savo viešąjį adresą, kurį išduoda pagrindinis kompiuteris ir susietas su stovu. Tie. perkeliant serverį reikia pakeisti adresą.
Ką reikėtų daryti?
Prijunkite serverius naudodami VVG (Link Aggregation Group) su dviem laidais prie stove esančių jungiklių (jie taip pat turi būti pertekliniai). Rezervuokite jungtis tarp stelažų, perdarykite jas su „žvaigždute“ (arba dabar madingu CLOS), kad vienos stelažo praradimas nepakenktų kitiems. Pasirinkite „centrinius“ stovus, kuriuose bus tinklo šerdis ir kur bus įtrauktos kitos stelažai. Tuo pačiu sutvarkykite viešąjį kreipimąsi, paimkite iš prieglobos serverio (arba iš RIR, jei įmanoma) potinklį, kurį jūs pats (arba per prieglobą) pranešate pasauliui.
Ar gali visa tai padaryti „paprastas“ sistemos administratorius, neturintis gilių žinių apie tinklus? Nesu tikras. Ar šeimininkas tai padarys? Gal ir bus, bet reikės gana detalaus TOR, kurį taip pat reikės kažkam sukompiliuoti. ir tada patikrinkite, ar viskas padaryta teisingai.
2 pavyzdys: Debesuota
Tarkime, kad turite VPC viešajame debesyje. Norėdami gauti prieigą iš biuro ar infrastruktūros vietos prie vietinio tinklo VPC viduje, turite nustatyti ryšį per IPSec arba tam skirtą kanalą. Viena vertus, IPSec yra pigesnis. nereikia pirkti papildomos techninės įrangos, galite sukurti tunelį tarp savo serverio su viešuoju adresu ir debesies. Bet - vėlavimai, ribotas našumas (nes kanalą reikia šifruoti), plius negarantuotas ryšys (nes prieiga eina per įprastą internetą).
Ką reikėtų daryti?
Padidinkite ryšį per tam skirtą kanalą (pavyzdžiui, AWS tai vadina tiesioginiu ryšiu). Norėdami tai padaryti, susiraskite partnerį operatorių, kuris jus sujungs, nustatykite arčiausiai jūsų esantį prisijungimo tašką (tiek jūs į operatorių, tiek operatorius į debesį) ir galiausiai viską nustatykite. Ar visa tai galima padaryti be tinklo inžinieriaus? Tikrai taip. Tačiau kaip pašalinti gedimus be jo iškilus problemoms, nebėra taip aišku.
Taip pat gali kilti problemų dėl pasiekiamumo tarp debesų (jei turite kelių debesų) arba problemų dėl vėlavimų tarp skirtingų regionų ir pan. Žinoma, dabar yra daug įrankių, kurie padidina debesyje vykstančių įvykių skaidrumą (tos pačios Tūkstantis akių), tačiau tai visi tinklo inžinierių įrankiai, o ne pakaitalai.
Galėčiau pavaizduoti dar keliolika tokių pavyzdžių iš savo praktikos, bet, manau, aišku, kad komandoje, pradedant nuo tam tikro infrastruktūros išsivystymo lygio, turi būti žmogus (o geriau – daugiau nei vienas), išmanantis, kaip veikia tinklas. veikia, gali konfigūruoti tinklo įrangą ir spręsti problemas, jei jos iškyla. Patikėk, jis turės ką veikti
Ką turėtų žinoti tinklo kūrėjas?
Tinklo inžinieriui visai nebūtina (ir kartais net žalinga) užsiimti tik tinklu ir nieko daugiau. Net jei nesvarstome varianto su infrastruktūra, kuri beveik visa gyvena viešajame debesyje (ir, kad ir kaip būtų galima sakyti, ji tampa vis populiaresnė), o paimkime, pavyzdžiui, į patalpas arba privačius debesis, kur tik „Žinios CCNP lygiu „Jūs nepaliksite.
Be, tiesą sakant, tinklų - nors yra tiesiog begalinis studijų laukas, net jei koncentruojatės tik į vieną kryptį (tiekėjų tinklai, įmonės, duomenų centrai, Wi-Fi ...)
Žinoma, daugelis iš jūsų dabar prisimins Python ir kitą „tinklo automatizavimą“, tačiau tai tik būtina, bet nepakankama sąlyga. Kad tinklo inžinierius galėtų „sėkmingai prisijungti prie komandos“, jis turi mokėti kalbėti ta pačia kalba tiek su kūrėjais, tiek su kolegomis administratoriais / devopais. Ką tai reiškia?
- mokėti ne tik dirbti Linux kaip vartotojas, bet ir jį administruoti, bent jau sysadmin-junior lygiu: įdiegti reikiamą programinę įrangą, paleisti iš naujo nukritusią paslaugą, parašyti paprastą systemd-unit.
- Supraskite (bent jau bendrais bruožais), kaip tinklo dėklas veikia Linux sistemoje, kaip tinklas veikia hipervizoriuose ir konteineriuose (lxc / docker / kubernetes).
- Žinoma, mokėti dirbti su ansible/chef/puppet ar kita SCM sistema.
- Apie SDN ir privačių debesų tinklus (pavyzdžiui, TungstenFabric arba OpenvSwitch) reikėtų parašyti atskirą eilutę. Tai dar viena didžiulė žinių dalis.
Trumpai aprašiau tipišką T formos specialistę (kaip dabar madinga sakyti). Panašu, kad tai nieko naujo, tačiau, remiantis interviu patirtimi, ne visi tinklų inžinieriai gali pasigirti žiniomis bent dviejose aukščiau esančio sąrašo temose. Praktiškai žinių trūkumas „susijusiose srityse“ labai apsunkina ne tik bendravimą su kolegomis, bet ir verslo keliamų reikalavimų tinklo, kaip žemiausio projekto infrastruktūros, supratimą. O be šio supratimo tampa sunkiau pagrįstai apginti savo požiūrį ir jį „parduoti“ verslui.
Kita vertus, pats įprotis „suprasti, kaip veikia sistema“ suteikia tinklų kūrėjams labai gerą pranašumą prieš įvairius „generalistus“, kurie apie technologijas žino iš straipsnių apie Habré/medium ir telegramų pokalbius, bet visiškai neįsivaizduoja, kokiais principais tai ar kad programinė įranga veikia. O kai kurių dėsningumų žinojimas, kaip žinia, sėkmingai pakeičia daugelio faktų žinojimą.
Išvados, arba tiesiog TL;DR
- Tinklo administratorius (kaip DBA ar VoIP inžinierius) yra gana siauro profilio specialistas (skirtingai nei sysadmins / devops / SRE), kurio poreikis iškyla ne iš karto (ir, tiesą sakant, gali kilti ilgai) . Tačiau jei taip atsitiks, vargu ar jį pakeis išorės ekspertai (užsakomųjų paslaugų teikėjai arba įprasti administratoriai, „kurie taip pat prižiūri tinklą“). Kiek liūdniau yra tai, kad tokių specialistų poreikis mažas, o sąlyginai įmonėje, kurioje dirba 800 programuotojų ir 30 devop/adminų, gali būti tik du tinklininkai, kurie puikiai atlieka savo darbą. Tie. rinka buvo ir yra labai labai maža, o dar mažiau su geru atlyginimu.
- Kita vertus, geras tinklų kūrėjas šiuolaikiniame pasaulyje turėtų žinoti ne tik pačius tinklus (ir kaip automatizuoti jų konfigūraciją), bet ir kaip su jais sąveikauja operacinės sistemos ir programinė įranga, kuri veikia šiuos tinklus. Be to bus labai sunku suprasti, ko kolegos iš jūsų prašo, ir (pagrįstai) perteikti jiems jūsų pageidavimus / reikalavimus.
- Debesų nėra, tai tik kažkieno kompiuteris. Turite suprasti, kad naudojimasis viešaisiais / privačiais debesimis ar prieglobos paslaugų teikėjų paslaugomis, „kurie viską daro už jus“, nepaneigia fakto, kad jūsų programa vis dar naudoja tinklą, o su juo susijusios problemos turės įtakos jūsų programos veikimui. . Jūs pasirenkate, kur įsikurs kompetencijų centras, kuris bus atsakingas už jūsų projekto tinklą.
Šaltinis: www.habr.com