Në kohën e shkrimit të këtij artikulli, një kërkim në një vend pune të njohur për shprehjen "Inxhinier i Rrjetit" ktheu rreth treqind vende të lira pune në të gjithë Rusinë. Për krahasim, një kërkim për shprehjen "administrator i sistemit" kthen pothuajse 2.5 mijë vende të lira, dhe "Inxhinier DevOps" - pothuajse 800.
A do të thotë kjo se rrjetet nuk janë më të nevojshëm në kohët e reve fitimtare, Docker, Kubernetes dhe Wi-Fi publik kudo?
Le ta kuptojmë (c)
Le të njihemi. Emri im është Alexey, dhe unë jam një rrjetor.
Unë kam qenë i përfshirë në rrjete për më shumë se 10 vjet dhe kam punuar me sisteme të ndryshme *nix për më shumë se 15 vjet (pata një shans për të ndërlidhur me Linux dhe FreeBSD). Kam punuar në operatorë telekomunikacioni, kompani të mëdha që konsiderohen si "ndërmarrje", dhe së fundmi kam punuar në fintech "të rinj dhe të guximshëm", ku retë, devops, kubernetes dhe fjalë të tjera të frikshme që patjetër do të më bëjnë mua dhe kolegët e mi të panevojshëm. . Një ditë. Ndoshta.
mohim: "Në jetën tonë, jo gjithçka është gjithmonë dhe kudo, por diçka, ndonjëherë në vende" (c) Maxim Dorofeev.
Gjithçka e shkruar më poshtë mund dhe duhet të konsiderohet si mendim personal i autorit, i cili nuk pretendon të jetë e vërteta përfundimtare, madje as një studim i plotë. Të gjithë personazhet janë fiktive, të gjitha rastësitë janë të rastësishme.
Mirë se vini në botën time.
Ku mund të takoni edhe rrjete?
1. Operatorët e telekomit, kompanitë e shërbimeve dhe integrues të tjerë. Gjithçka është e thjeshtë këtu: rrjeti për ta është një biznes. Ata ose shesin drejtpërdrejt lidhjen (operatorët) ose ofrojnë shërbime për nisjen/mirëmbajtjen e rrjeteve të klientëve të tyre.
Këtu ka shumë përvojë, por jo shumë para (përveç nëse jeni drejtor ose menaxher i suksesshëm i shitjeve). E megjithatë, nëse ju pëlqejnë rrjetet dhe jeni vetëm në fillim të rrugëtimit tuaj, një karrierë në mbështetje të një operatori jo shumë të madh do të jetë, edhe tani, një pikënisje ideale (në ato federale gjithçka është shumë e shkruar, dhe atje ka pak vend për kreativitet). Epo, historitë se si mund të rritesh nga një inxhinier në detyrë në pak vite në një menaxher të nivelit C janë gjithashtu mjaft reale, megjithëse të rralla, për arsye të dukshme. Gjithmonë ka nevojë për personel, sepse ka qarkullim. Kjo është edhe e mirë edhe e keqe në të njëjtën kohë - ka gjithmonë vende të lira, nga ana tjetër - shpesh më aktivët/të zgjuarit largohen shpejt ose për promovim ose në vende të tjera "më të ngrohta".
2. “Ndërmarrje” e kushtëzuar. Nuk ka rëndësi nëse aktiviteti i tij kryesor lidhet me IT apo jo. Gjëja kryesore është se ajo ka departamentin e vet të IT, i cili siguron funksionimin e sistemeve të brendshme të kompanisë, duke përfshirë rrjetin në zyra, kanalet e komunikimit me degët, etj. Funksionet e një inxhinieri rrjeti në kompani të tilla mund të kryhen "me kohë të pjesshme" nga një administrator sistemi (nëse infrastruktura e rrjetit është e vogël ose trajtohet nga një kontraktues i jashtëm), dhe një specialist i rrjetit, nëse ka një të tillë, mundet në në të njëjtën kohë kujdesuni për telefoninë dhe SAN (nuk është mirë). Ata paguajnë ndryshe - kjo varet shumë nga përfitimi i biznesit, madhësia e kompanisë dhe struktura. Kam punuar me kompani ku sistemet Cisco ishin rregullisht "ngarkuar në fuçi" dhe me kompani ku rrjeti ishte ndërtuar nga feces, shkopinj dhe shirit blu, dhe serverët nuk u përditësuan kurrë (e panevojshme të thuhet se as rezerva nuk u siguruan). Këtu ka shumë më pak përvojë dhe pothuajse me siguri do të jetë në fushën e bllokimit të rreptë të shitësve, ose "si të bëni diçka nga asgjëja". Personalisht, më dukej jashtëzakonisht i mërzitshëm, megjithëse shumë njerëz e pëlqejnë atë - gjithçka është mjaft e matur dhe e parashikueshme (nëse po flasim për kompani të mëdha), "dorakha-bahato", etj. Të paktën një herë në vit, disa shitës të mëdhenj thonë se kanë dalë me një sistem tjetër mega-super-duper që do të automatizojë gjithçka tani dhe të gjithë administratorët e sistemit dhe rrjetet mund të shpërndahen, duke lënë një çift të shtypë butonat në një ndërfaqe të bukur. Realiteti është se, edhe nëse injorojmë koston e zgjidhjes, rrjetëzuesit nuk do të shkojnë askund prej andej. Po, ndoshta në vend të tastierës do të ketë përsëri një ndërfaqe në internet (por jo një pjesë specifike e harduerit, por një sistem i madh që menaxhon dhjetëra e qindra pjesë të tilla të pajisjeve), por njohuria se "si funksionon gjithçka brenda" do të vazhdojë të të jetë e nevojshme.
3. Kompanitë e produkteve, fitimi i të cilit vjen nga zhvillimi (dhe, shpesh, funksionimi) i disa softuerëve ose platformave - i njëjti produkt. Zakonisht janë të vegjël dhe të shkathët, janë ende larg shkallës së sipërmarrjeve dhe burokratizimit të tyre. Pikërisht këtu gjenden masivisht të njëjtat devops, cubers, dockers dhe fjalë të tjera të tmerrshme, të cilat sigurisht do t'i bëjnë inxhinierët e rrjetit dhe rrjetit një element të panevojshëm.
Si ndryshon një rrjetor nga një administrator i sistemit?
Në kuptimin e njerëzve jo nga IT - asgjë. Të dy shikojnë ekranin e zi dhe shkruajnë disa magji, ndonjëherë duke sharë në heshtje.
Në kuptimin e programuesve - ndoshta sipas fushës lëndore. Administratorët e sistemit administrojnë serverët, rrjetet administrojnë çelësat dhe ruterat. Ndonjëherë administrata është e keqe, dhe gjithçka bie për të gjithë. Epo, në rast të ndonjë gjëje të çuditshme, fajin e kanë edhe rrjetorët. Thjesht sepse dreqin ty, prandaj.
Në fakt, ndryshimi kryesor është qasja ndaj punës. Ndoshta, është në mesin e rrjeteve që ka më shumë mbështetës të qasjes "Nëse funksionon, mos e prek!". Si rregull, diçka mund të bëhet (brenda një shitësi) vetëm në një mënyrë; i gjithë konfigurimi i kutisë është pikërisht aty në pëllëmbën e dorës. Kostoja e një gabimi është e lartë, dhe nganjëherë shumë e lartë (për shembull, do t'ju duhet të udhëtoni disa qindra kilometra për të rindezur ruterin, dhe në këtë kohë disa mijëra njerëz do të jenë pa komunikim - një situatë mjaft e zakonshme për një operator telekomi) .
Sipas mendimit tim, kjo është arsyeja pse inxhinierët e rrjetit, nga njëra anë, janë jashtëzakonisht shumë të motivuar për stabilitetin e rrjetit (dhe ndryshimi është armiku kryesor i stabilitetit), dhe së dyti, njohuritë e tyre shkojnë më shumë në thellësi sesa në gjerësi (ju nuk bëni duhet të jeni në gjendje të konfiguroni dhjetëra demonë të ndryshëm, duhet të njihni teknologjitë dhe zbatimin e tyre nga një prodhues specifik pajisjesh). Kjo është arsyeja pse një administrator i sistemit që kërkoi në google se si të regjistrojë një vlan në një sistem Cisco nuk është ende një rrjetëzues. Dhe nuk ka gjasa që ai të jetë në gjendje të mbështesë në mënyrë efektive (si dhe të zgjidhë problemet) një rrjet pak a shumë kompleks.
Por pse keni nevojë për një rrjetor nëse keni një host?
Për para shtesë (dhe nëse jeni një klient shumë i madh dhe i dashur, ndoshta edhe falas, "si mik"), inxhinierët e qendrës së të dhënave do të konfigurojnë çelësat tuaj për t'iu përshtatur nevojave tuaja dhe ndoshta edhe do t'ju ndihmojnë të krijoni një ndërfaqe BGP me ofruesit (nëse keni nënrrjetin tuaj të adresave IP për njoftimin).
Problemi kryesor është se qendra e të dhënave nuk është departamenti juaj i IT-së, është një kompani më vete, qëllimi i së cilës është të fitojë. Përfshirë në kurriz të juve si klient. Qendra e të dhënave ofron rafte, u siguron atyre energji elektrike dhe të ftohtë, dhe gjithashtu siguron një lidhje "të parazgjedhur" me internetin. Bazuar në këtë infrastrukturë, qendra e të dhënave mund të presë pajisjet tuaja (kolokacion), t'ju japë me qira një server (server i dedikuar) ose të ofrojë një shërbim të menaxhuar (për shembull, OpenStack ose K8s). Por biznesi i një qendre të dhënash (zakonisht) nuk është administrimi i infrastrukturës së klientit, sepse ky proces është mjaft intensiv i punës, i automatizuar dobët (dhe në një qendër normale të dhënash gjithçka që është e mundur është e automatizuar), e unifikuar edhe më keq (çdo klient është individuale) dhe përgjithësisht i mbushur me ankesa (“ju më thoni se serveri ishte i konfiguruar, por tani ka dështuar, faji është i gjithë ju!!!111”). Prandaj, nëse hosti ju ndihmon me diçka, ai do të përpiqet ta bëjë atë sa më të thjeshtë dhe të përshtatshëm. Sepse ta bësh atë të vështirë është joprofitabile, të paktën nga pikëpamja e kostove të punës së inxhinierëve të të njëjtit host (por situatat janë të ndryshme, shih mohimin). Kjo nuk do të thotë që pritësi do të bëjë gjithçka keq. Por nuk është aspak një fakt që ai do të bëjë pikërisht atë që ju nevojitet vërtet.
Duket se gjëja është mjaft e qartë, por disa herë në praktikën time kam hasur në faktin që kompanitë filluan të mbështeteshin në ofruesin e tyre të pritjes pak më shumë sesa duhej, dhe kjo nuk çoi në asgjë të mirë. Më duhej të shpjegoja gjatë dhe në detaje se asnjë SLA e vetme nuk do të mbulonte humbjet nga ndërprerja (ka përjashtime, por zakonisht është shumë, SHUME e shtrenjtë për klientin) dhe se hosti nuk është aspak i vetëdijshëm për atë që po ndodh në infrastruktura e klientëve (me përjashtim të treguesve shumë të përgjithshëm). Dhe hosti nuk bën as kopje rezervë për ju. Situata është edhe më e keqe nëse keni më shumë se një host. Në rast të ndonjë problemi mes tyre, ata me siguri nuk do ta zbulojnë për ju se çfarë shkoi keq.
Në fakt, motivet këtu janë saktësisht të njëjta si kur zgjidhni "ekipin e administratorit të brendshëm kundër kontraktimit". Nëse llogariten rreziqet, cilësia është e kënaqshme dhe biznesi nuk e ka problem, pse të mos e provoni. Nga ana tjetër, rrjeti është një nga shtresat më themelore të infrastrukturës dhe vështirë se ia vlen t'ia lini atë djemve të jashtëm nëse tashmë e mbështetni gjithçka tjetër vetë.
Në cilat raste nevojitet një rrjetor?
Më pas do të flasim konkretisht për kompanitë moderne të ushqimit. Me operatorët dhe ndërmarrjet, gjithçka është e qartë, plus ose minus - pak ka ndryshuar atje vitet e fundit, dhe rrjetëzuesit ishin të nevojshëm atje më parë, dhe ata nevojiten tani. Por me të njëjtat "të rinj dhe të guximshëm" gjërat nuk janë aq të qarta. Shpesh ata e vendosin të gjithë infrastrukturën e tyre në retë, kështu që ata nuk kanë vërtet nevojë për administratorë - përveç administratorëve të të njëjtave re, natyrisht. Infrastruktura, nga njëra anë, është mjaft e thjeshtë në dizajn, nga ana tjetër, është e automatizuar mirë (ansible/kukull, terraform, ci/cd... mirë, ju e dini). Por edhe këtu ka situata kur nuk mund të bëni pa një inxhinier rrjeti.
Shembulli 1, klasik
Supozoni se një kompani fillon me një server me një adresë IP publike, e cila ndodhet në një qendër të dhënash. Pastaj ka dy serverë. Pastaj më shumë... Herët a vonë, do të ketë nevojë për një rrjet privat midis serverëve. Për shkak se trafiku "i jashtëm" është i kufizuar si nga gjerësia e brezit (jo më shumë se 100 Mbit/s për shembull) dhe nga vëllimi i shkarkimeve/ngarkuara në muaj (hosterët e ndryshëm kanë tarifa të ndryshme, por gjerësia e brezit në botën e jashtme është zakonisht shumë më e shtrenjtë se një rrjet privat).
Pritësi shton kartat shtesë të rrjetit në serverë dhe i përfshin ato në ndërprerësit e tyre në një vlan të veçantë. Një zonë lokale "e sheshtë" shfaqet midis serverëve. Të rehatshme!
Numri i serverëve po rritet, dhe trafiku në rrjetin privat po rritet gjithashtu - kopje rezervë, replikime, etj. Pritësi ofron t'ju zhvendosë në ndërprerës të veçantë në mënyrë që të mos ndërhyni me klientët e tjerë dhe ata të mos ndërhyjnë me ju. Pritësi instalon disa ndërprerës dhe disi i konfiguron - ka shumë të ngjarë, duke lënë një rrjet të sheshtë midis të gjithë serverëve tuaj. Gjithçka funksionon mirë, por në një moment të caktuar fillojnë problemet: vonesat midis hosteve rriten periodikisht, regjistrat ankohen për shumë paketa arp në sekondë dhe gjatë një kontrolli pentester qiti të gjithë rrjetin tuaj lokal, duke thyer vetëm një server.
Needsfarë duhet të bëhet?
Ndani rrjetin në segmente - vlans. Konfiguro adresimin tuaj në çdo vlan, zgjidhni një portë që do të transferojë trafikun midis rrjeteve. Konfiguro acl në portë për të kufizuar aksesin midis segmenteve, ose madje instaloni një mur zjarri të veçantë afër.
Shembulli 1, vazhdim
Serverët janë të lidhur me LAN me një kabllo. Çelësat në raftet janë disi të lidhur me njëri-tjetrin, por nëse ka një aksident në një raft, tre të tjerë ngjitur bien. Skemat ekzistojnë, por ka dyshime për rëndësinë e tyre. Çdo server ka adresën e vet publike, e cila lëshohet nga hosti dhe është e lidhur me raftin. Ato. Kur lëvizni një server, adresa duhet të ndryshohet.
Needsfarë duhet të bëhet?
Lidhni serverët duke përdorur LAG (Link Aggregation Group) me dy kordona me çelësat në raft (ato gjithashtu duhet të jenë të tepërt). Rezervoni lidhjet midis rafteve, kthejini ato në një lloj "ylli" (ose CLOS tani në modë), në mënyrë që humbja e një rafti të mos ndikojë tek të tjerët. Zgjidhni raftet "qendrore" në të cilat do të vendoset bërthama e rrjetit dhe ku do të lidhen raftet e tjera. Në të njëjtën kohë, vendosni në rregull adresimin publik, merrni nga hosti (ose nga RIR, nëse është e mundur) një nënrrjet, të cilin ju vetë (ose përmes hostit) ia shpallni botës.
A mund të bëhet e gjithë kjo nga një administrator sistemi "i zakonshëm" që nuk ka njohuri të thella për rrjetet? Nuk jam i sigurt. A do ta bëjë hosti këtë? Ndoshta do, por do t'ju duhet një specifikim teknik mjaft i detajuar, të cilin dikush do t'i duhet gjithashtu ta hartojë. dhe më pas kontrolloni nëse gjithçka është bërë si duhet.
Shembulli 2: Reja
Le të themi se keni një VPC në një re publike. Për të fituar akses nga zyra ose pjesë prem e infrastrukturës në rrjetin lokal brenda VPC, duhet të konfiguroni një lidhje nëpërmjet IPSec ose një kanali të dedikuar. Nga njëra anë, IPSec është më i lirë, sepse nuk ka nevojë të blini pajisje shtesë; mund të vendosni një tunel midis serverit tuaj me një adresë publike dhe cloud. Por - vonesa, performancë e kufizuar (pasi kanali duhet të kodohet), plus lidhje të pagarantuar (pasi aksesi bëhet përmes Internetit të rregullt).
Needsfarë duhet të bëhet?
Ngritni një lidhje përmes një kanali të dedikuar (për shembull, AWS e quan atë Direct Connect). Për ta bërë këtë, gjeni një operator partner i cili do t'ju lidhë, do të vendosni për pikën e lidhjes më të afërt me ju (si ju me operatorin ashtu edhe operatorin me renë kompjuterike) dhe, së fundi, vendosni gjithçka. A është e mundur të bëhet e gjithë kjo pa një inxhinier rrjeti? Me siguri po. Por si të zgjidhni problemet pa të në rast të problemeve nuk është më aq e qartë.
Mund të ketë gjithashtu probleme me disponueshmërinë midis reve (nëse keni një multicloud) ose probleme me vonesa midis rajoneve të ndryshme, etj. Sigurisht, tani janë shfaqur shumë mjete që rrisin transparencën e asaj që po ndodh në re (të njëjtit Mijë sy), por të gjitha këto janë mjete të një inxhinieri rrjeti dhe jo një zëvendësim për të.
Mund të skicoja një duzinë shembuj të tjerë të tillë nga praktika ime, por mendoj se është e qartë se ekipi, duke filluar nga një nivel i caktuar zhvillimi i infrastrukturës, duhet të ketë një person (mundësisht më shumë se një) i cili e di se si funksionon rrjeti dhe mund të konfigurojë pajisjet e rrjetit dhe zgjidhni problemet nëse ato lindin. Më besoni, ai do të ketë diçka për të bërë
Çfarë duhet të dijë një rrjetor?
Nuk është aspak e nevojshme (dhe madje, ndonjëherë, e dëmshme) që një inxhinier rrjeti të merret vetëm me rrjetin dhe asgjë tjetër. Edhe nëse nuk e konsiderojmë opsionin me një infrastrukturë që jeton pothuajse tërësisht në renë publike (dhe, çfarëdo që mund të thuhet, po bëhet gjithnjë e më popullore), dhe të marrim, për shembull, në retë lokale ose private, ku mbi “Vetëm njohuri në nivel CCNP” “Nuk do të largohesh.
Përveç, në fakt, rrjeteve - megjithëse ka thjesht një fushë të pafund studimi, edhe nëse përqendroheni vetëm në një zonë (rrjetet e ofruesve, ndërmarrjet, qendrat e të dhënave, Wi-Fi ...)
Sigurisht, shumë prej jush tani do të kujtojnë Python dhe "automatizimin e rrjetit" të tjerë, por ky është vetëm një kusht i domosdoshëm, por jo i mjaftueshëm. Në mënyrë që një inxhinier rrjeti të "bashkohet me sukses në ekip", ai duhet të jetë në gjendje të flasë të njëjtën gjuhë si me zhvilluesit ashtu edhe me administratorët / zhvilluesit e tjerë. Çfarë do të thotë?
- të jetë në gjendje jo vetëm të punojë në Linux si përdorues, por edhe ta administrojë atë, të paktën në nivelin sysadmin-jun: instaloni softuerin e nevojshëm, rinisni një shërbim të dështuar, shkruani një njësi të thjeshtë systemd.
- Kuptoni (të paktën në terma të përgjithshëm) se si funksionon grupi i rrjetit në Linux, si funksionon rrjeti në hipervizorë dhe kontejnerë (lxc / docker / kubernetes).
- Sigurisht, të jeni në gjendje të punoni me ansible/chef/kukull ose një sistem tjetër SCM.
- Duhet të shkruhet një rresht i veçantë për SDN dhe rrjetet për retë private (për shembull, TungstenFabric ose OpenvSwitch). Kjo është një shtresë tjetër e madhe e njohurive.
Me pak fjalë, përshkrova një specialist tipik të formës T (siç është në modë të thuhet tani). Duket si asgjë e re, por bazuar në përvojën e intervistës, jo të gjithë inxhinierët e rrjetit mund të mburren me njohuri për të paktën dy tema nga lista e mësipërme. Në praktikë, mungesa e njohurive “në fusha të lidhura” e bën shumë të vështirë jo vetëm komunikimin me kolegët, por edhe kuptimin e kërkesave që biznesi vendos në rrjet, si infrastruktura e nivelit më të ulët të projektit. Dhe pa këtë kuptim, bëhet më e vështirë të mbroni këndvështrimin tuaj dhe t'ia "shisni" atë biznesit.
Nga ana tjetër, i njëjti zakon i "të kuptuarit se si funksionon sistemi" u jep rrjeteve një avantazh shumë të mirë ndaj "gjeneralistëve" të ndryshëm që dinë për teknologjitë nga artikujt në Habré/medium dhe bisedat në Telegram, por nuk kanë absolutisht asnjë ide se si të bëjnë. mbi parimet funksionon ky apo ai softuer? Dhe njohja e modeleve të caktuara, siç dihet, zëvendëson me sukses njohjen e shumë fakteve.
Konkluzione, ose thjesht TL;DR
- Një administrator rrjeti (si një inxhinier DBA ose VoIP) është një specialist me një profil mjaft të ngushtë (ndryshe nga administratorët e sistemit/devs/SRE), nevoja për të cilën nuk lind menjëherë (dhe mund të mos lindë për një kohë të gjatë, në fakt) . Por nëse lind, nuk ka gjasa të zëvendësohet nga ekspertizë e jashtme (të jashtëm ose administratorë të zakonshëm me qëllime të përgjithshme, "të cilët gjithashtu kujdesen për rrjetin"). Ajo që është disi më e trishtueshme është se nevoja për specialistë të tillë është e vogël dhe, me kusht, në një kompani me 800 programues dhe 30 devops/administratorë, mund të ketë vetëm dy rrjete që bëjnë një punë të shkëlqyer me përgjegjësitë e tyre. Ato. tregu ishte dhe është shumë, shumë i vogël, dhe me një rrogë të mirë - edhe më pak.
- Nga ana tjetër, një rrjetëzues i mirë në botën moderne duhet të dijë jo vetëm vetë rrjetet (dhe si të automatizojë konfigurimin e tyre), por edhe mënyrën se si sistemet operative dhe softueri që funksionojnë në krye të këtyre rrjeteve ndërveprojnë me to. Pa këtë, do të jetë jashtëzakonisht e vështirë të kuptosh se çfarë kërkojnë kolegët nga ju dhe t'u përcillni (në mënyrë të arsyeshme) dëshirat/kërkesat tuaja.
- Nuk ka re, është thjesht kompjuteri i dikujt tjetër. Ju duhet të kuptoni se përdorimi i reve publike/private ose shërbimet e një ofruesi pritës "që bën gjithçka për ju në bazë të çelësit në dorë" nuk ndryshon faktin që aplikacioni juaj ende përdor rrjetin dhe problemet me të do të ndikojnë në funksionimin e aplikimin tuaj. Zgjedhja juaj është se ku do të vendoset qendra e kompetencës, e cila do të jetë përgjegjëse për rrjetin e projektit tuaj.
Burimi: www.habr.com