Në momentin e shkrimit të këtij artikulli, kërkimi në një nga faqet më të njohura për punë për frazën "Inxhinier rrjeti" jepte rreth triqind vende pune në të gjithë Rusinë. Krahasimisht, kërkimi për frazën "administratori i sistemit" jep pothuajse 2.5 mijë vende pune, ndërsa "Inxhinier DevOps" - pothuajse 800.
A do të thotë kjo se inxhinierët e rrjetit nuk nevojiten më në kohën e skajshme të mjeteve të reja si reja, docker, kubernetes dhe wifi i gjithanshëm publik?
Le të sqarojmë (c)
Le të njihemi. Unë quhem Aleksei dhe jam inxhinier rrjeti.
Kam më shumë se 10 vjet që merrem me rrjete dhe mbi 15 vjet që punoj me sisteme të ndryshme *nix (kam pasur mundësinë të punoj me Linux dhe FreeBSD). Kam punuar në operatorë të komunikacionit dhe në kompani të mëdha që zakonisht konsiderohen "enterprise", dhe kohët e fundit kam punuar në një fintech "të ri dhe të guximshëm", ku reja, devops, kubernetes dhe terma të tjerë të frikshëm që patjetër do të bëjnë që unë dhe kolegët e mi të bëhemi të panevojshëm. Ndonjëherë. Ndoshta.
disclaimer: "Në jetën tonë, jo gjithçka është gjithmonë dhe kudo, dhe disa gjëra ndodhin herë pas here dhe në disa vende" (c) Maksim Dorofejev.
Gjithçka e shkruar më poshtë mund dhe duhet të merret si opinion personal i autorit, që nuk pretendon të jetë e vërteta finale, dhe madje as një studim të plotë. Të gjithë karakteret janë fiktivë, të gjitha përputhjet janë rastësi.
Mirë se vini në botën time.
Ku mund të takoni inxhinierët e rrjetit?
1. Operatorët e komunikacionit, kompanitë e shërbimeve dhe integratorë të tjerë. Këtu gjithçka është e thjeshtë: rrjeti për ta është biznes. Ata ose shesin direkt lidhjen (operatorët), ose ofrojnë shërbime për nisjen/mbajtjen e rrjeteve të klientëve të tyre.
Ka shumë përvojë këtu, para nuk ka shumë (nëse nuk jeni drejtor ose menaxher i suksesshëm i shitjeve). Megjithatë, nëse ju pëlqejnë rrjetet dhe jeni vetëm në fillim të rrugës, një karrierë në suport te ndonjë operator jo shumë të madh do të ishte, madje tani, pika ideale për t'u nisur (në operatorët federalë gjithçka është shumë e strukturuar dhe ka pak hapësirë për krijimtarinë). Po ashtu, tregimet për atë se si mund të rritesh nga inxhinier dezhurn me kalimin e disa viteve në menaxher C-level janë gjithashtu të vërteta, megjithëse të rralla, për arsye të kuptueshme. Nevoja për staf është gjithmonë, sepse rotacioni është një realitet. Kjo është e mirë dhe e keqe njëkohësisht – gjithmonë ka vende të lira, nga ana tjetër – shpesh, ata më aktivë/dinë shkëmbejnë të shpejtë ose përparojnë, ose shkojnë në vende më "të ngrohta".
2. "Enterpraiz" i kushtuarNuk është e rëndësishme nëse aktiviteti kryesor është i lidhur me IT-në apo jo. E rëndësishme është që ka një departament IT, i cili merret me funksionimin e sistemeve të brendshme të kompanisë, përfshirë rrjetin në zyrat, kanalet e komunikimit në degë, etj. Funksionet e inxhinierit të rrjetit në këto kompani mund të kryhen "përkrahje" nga një administrator sistemi (nëse infrastruktura e rrjetit është e vogël, ose merret nga një kontraktues i jashtëm), ndërsa inxhinierët e rrjetit, nëse ata ekzistojnë, mund të mbikëqyrin gjithashtu telefoninë dhe SAN (nuk është e thjeshtë). Pagesat ndryshojnë – varen shumë nga marxhinaliteti i biznesit, përmasat e kompanisë dhe struktura. Kam punuar me kompani ku rrjetet Cisco ngarkoheshin rregullisht me ton, dhe me kompani ku rrjeti ndërrminej nga plehra, shkopinj dhe ngjitës i bluar, ndërsa serverët nuk përditësoheshin pothuajse kurrë (nuk duhet të përmendim se nuk ishin parashikuar as redaktorët). Eksperienca këtu është shumë më e vogël, dhe ajo, pothuajse me siguri do të jetë në fushën e bllokimit të fortë nga shitësit, ose "si të bësh diçka nga asgjë". Personal, më është dukur shumë e mërzitshme, megjithatë shumë i pëlqen – gjithçka është mjaft e ngadaltë dhe e parashikueshme (nëse flasim për kompanitë e mëdha), "do rahat-bahato" etj. Jo më pak se një herë në vit, ndonjë furnizues i madh thotë se ka shpikur një sistem mega-super-puper, i cili tani automatikisht bën gjithçka dhe të gjithë administratorët dhe inxhinierët e rrjetit mund të shpërndahen, duke lënë disa për të shtypur butonat në një ndërfaqe të bukur. Realiteti është se, edhe nëse abstrahohemi nga kostoja e zgjidhjes, inxhinierët e rrjetit nuk do të ngelen diku tjetër. Po, ndoshta, në vend të konsolës do të ketë përsëri një ndërfaqe uebesh (por nuk do të jetë më një pajisje e caktuar, por një sistem i madh, i cili menaxhon dhjetra dhe qindra të tillë), por njohuritë "si është gjithçka brenda" do të jenë gjithsesi të nevojshme.
3. Kompanitë produktive, fitimi i të cilave vjen nga zhvillimi (dhe, shpesh, operimi) i ndonjë programi ose platforme – nga ai produkt. Zakonisht ato janë të vogla dhe të shpejta, akoma larg shkallës së ndërmarrjeve dhe burokracisë së tyre. Pikërisht këtu janë të pranishme ato DevOps, kuber, docker dhe fjalët e tjera të frikshme, të cilat patjetër do t'i bëjnë rrjetet dhe inxhinierët e rrjetit një relikt të padëshiruar.
Çfarë e ndan inxhinierin e rrjetit nga administratori i sistemit?
Në kuptimin e njerëzve që nuk janë në IT — asgjë. Të dyshuarit shikojnë në një ekran të zi dhe shkruajnë ndonjë zakone, ndonjëherë duke mallkuar në heshtje.
Në kuptimin e programuesve — ndoshta vetëm si një fushë veprimi. Administratoret e sistemeve menaxhojnë serverët, specialistët në rrjet menaxhojnë switch-et dhe router-at. Ndonjëherë menaxhojnë keq dhe gjithçka bie. Në rastin e çdo gjëje të çuditshme, janë gjithashtu të fajësuar specialistët e rrjetit. Thjesht, sepse të falë, kështu është.
Në të vërtetë, dallimi kryesor është qasja ndaj punës. Ndoshta, pikërisht mes specialistëve të rrjetit ndodhen më shumë mbështetës të qasjes "Funksionon — mos e prek!". Zgjidhja e ndonjë problemi (brenda një ofruesi) zakonisht mund të bëhet vetëm në një mënyrë, e gjithë konfigurimi i pajisjes — ja ku është, në duar. Çmimi i gabimit është i lartë, ndonjëherë edhe shumë i lartë (p.sh., do të duhet të udhëtosh për disa qindra kilometra për të ribërë router-in, ndërsa në të njëjtën kohë disa mijëra njerëz do të rrinë pa lidhje — një situatë krejt normale për një operator komunikimesh).
Në mendimin tim, pikërisht për këtë arsye inxhinierët e rrjetit, nga njëra anë, janë jashtëzakonisht të motivuar për stabilitetin e rrjetit (dhe ndryshimet janë armiku kryesor i stabilitetit), dhe nga ana tjetër, njohuritë e tyre shkojnë më shumë thellë se sa gjerë (nuk është e nevojshme të dish si të konfigurosh dhjetëra demonë të ndryshëm, është e nevojshme të njohësh teknologjitë dhe realizimin e tyre te një prodhues i caktuar pajisjeje). Kjo është arsyeja pse një administrator sistemi, që ka gjetur në Google se si të vendosë VLAN-in në Cisco — nuk është akoma një specialist rrjeti. Dhe vështirë se mund të mbështesë (dhe gjithashtu të zgjidhë problemet) një rrjet të ndërlikuar nga më shumë se pak.
Por përse është e nevojshme një specialist rrjeti, nëse keni hosti?
Për një pagesë shtesë (dhe nëse jeni një klient shumë i madh dhe i dashur — ndoshta edhe falas, "për miqësi") inxhinierët e qendrës së të dhënave do të konfigurojnë switch-et tuaj sipas nevojave tuaja, dhe ndoshta edhe do të ndihmojnë në ngritjen e lidhjes BGP me ofruesit (nëse keni një subnet tuaj të vetin adresa IP për njoftimin).
Problemi kryesor është se qendrat e të dhënave nuk janë departamenti juaj IT, por një kompani e veçantë, qëllimi i së cilës është të përfitojë. Po ashtu, duke përfituar nga ju si klient. Qendra e të dhënave ofron rafte, siguron energji elektrike dhe ajër të freskët, si dhe ofron një lidhje "default" me internetin. Në bazë të kësaj infrastrukture, qendra e të dhënave mund të vendosë pajisjet tuaja (colocation), t'ju japë një server me qira (dedicated server), ose ofrojë shërbime të menaxhuara (p.sh., OpenStack apo K8s). Por biznesi i qendrës së të dhënave (zakonisht) nuk është administrimi i infrastrukturës së klientëve, pasi ky proces është mjaft i lodhshëm, keq automatizohet (dhe në një qendër të mirë të të dhënave, çdo gjë që është e mundur është automatizuar), dhe akoma më keq unifikohet (çdo klient është i veçantë) dhe gjithashtu është i rrezikshëm për pretendime ("ju konfiguroni serverin tim dhe tani ka rënë, ju jeni fajtor për gjithçka!!!111"). Prandaj, nëse ofruesi i strehimit do t'ju ndihmojë ndonjëherë, do të përpiqet ta bëjë këtë sa më të thjeshtë dhe "të drejtpërdrejtë". Sepse të bësh gjëra të nd complicated - është joefikase, të paktën nga perspektiva e cost-it të inxhinierëve të atij ofruesi strehimi (por ndodhin situata të ndryshme, shih udhëzuesin). Kjo nuk do të thotë që ofruesi i strehimit do të bëjë gjithmonë keq. Por nuk është aspak e sigurt se ai do të bëjë atë që ju nevojitej vërtet.
Duket e qartë, por ndonjëherë kam hasur në praktikën time që kompanitë filluan të mbështeten te ofruesi i tyre i shërbimeve të strehimit më shumë se sa duhet, dhe kjo nuk çoi në asgjë të mirë. Duhej të shpjegoja për një kohë të gjatë dhe në detaje se asnjë SLA nuk do të mbulojë humbjet nga ndalesat (ka përjashtime, por zakonisht është shumë, SHUMË e shtrenjtë për klientin) dhe se ofruesi i strehimit nuk është në dijeni se çfarë po ndodh në infrastrukturën e klientëve (përveç të dhënave shumë të përgjithshme). Dhe ofruesi i strehimit nuk bën asnjë backup për ju. Edhe më keq është situata, nëse keni më shumë se një ofrues strehimi. Në rast të ndonjë problemi mes tyre, ata sigurisht që nuk do të zgjidhin për ju se çfarë po ndodhte.
Motivet janë pikërisht të njëjta si kur zgjidhni "ekipin tuaj të administratorëve vs outsourcing". Nëse rreziqet janë vlerësuar, cilësia është e kënaqshme, dhe biznesi nuk ka ndonjë problem — pse të mos e provoni? Nga ana tjetër, rrjeti është një nga nivelet më bazike të infrastrukturës, dhe nuk ka kuptim të dorëzohet në duar të tjerëve, nëse gjithçka tjetër e mbani vetë.
Në cilat raste nevojitet një inxhinier rrjeti?
Më poshtë do të flasim përshtatshëm për kompanitë moderne të produkteve. Me operatorët dhe enterprise-n gjithçka është më ose më pak e qartë — atje nuk ka pasur shumë ndryshime në vitet e fundit dhe inxhinierët e rrjetit kanë qenë të nevojshëm më parë, janë të nevojshëm dhe tani. Por me ata të quajtur "të rinjtë dhe guximtarët", situata nuk është aq e qartë. Shpesh ata vendosin infrastrukturën e tyre krejtësisht në облака, kështu që madje as administratorët zakonisht nuk u duhen — përveç administratorëve të këtyre облакëve, sigurisht. Infrastruktura, nga njëra anë, është mjaft e thjeshtë në ndërtimin e saj, dhe nga ana tjetër — është mirë të automatizuar (ansible/puppet, terraform, ci/cd... e dini tashmë). Por edhe këtu ka situata kur nuk mund të kaloni pa një inxhinier rrjeti.
Shembulli 1, klasik
Supozoni se kompania fillon me një server me një IP publike, i cili ndodhet në një data center. Pastaj numri i serverëve bëhet dy. Më pas më shumë... Herët a vonë, shfaqet nevoja për një rrjet privat midis serverëve. Sepse trafiku "jashtë" është i limituar si në gjerësi (në maksimum 100Mbit/s, për shembull) ashtu edhe në volum të shkarkuar/transferuar në muaj (çmime të ndryshme nga të ndryshmit hoster, por gjerësia për në botën jashtë, zakonisht është shumë më e shtrenjtë se një rrjet privat).
Hosteri shton karta të tjera rrjeti në serverat e tij dhe i lidh ato në switchet e tij në një vlan të veçantë. Midis serverëve shfaqet një rrjet lokal "i sheshtë". E përshtatshme!
Numri i serverëve po rritet, ashtu si edhe trafiku në rrjetin privat — kopjet rezervë, replikimet etj. Hosti ofron të ju ndajë në switch-e të veçantë, në mënyrë që të mos pengoni njëri-tjetrin. Hosti instalon disa switch-e dhe i konfiguron në një mënyrë — shumë gjasa, duke lënë një rrjet të sheshtë midis të gjithë serverëve tuaj. Gjithçka funksionon mirë, por në një moment fillojnë problemet: herë pas here ka rritje të vonesave midis hosteve, në log-et ka probleme për numrin e tepërt të paketave arp për sekondë, dhe pëntesti gjatë auditit ka goditur të gjithë rrjetin tuaj lokal, duke thyer vetëm një server.
Çfarë duhet bërë?
Të ndahen rrjetet në segmente — vlan. Të konfigurohet adresimi i vetë çdo vlani, të caktohet gateway-i që do të transferojë trafikun midis rrjeteve. Në gateway-n të konfigurohet acl për të kufizuar qasjen midis segmenteve, ose të vendoset një firewall i veçantë për të.
Shembulli 1, vazhdim
Serverët janë të lidhur me rrjetin lokal me një kabllo. Switch-et në raft janë të lidhura ndërlidhëse, por në rast avarie në një raft, edhe tri të tjera fqinjë bien. Ekzistojnë skema, por ka dyshime mbi aktualitetin e tyre. Çdo server ka një adresë publike të vet, e cila jepet nga hosti dhe është e lidhur me raftin. Kështu që, duke lëvizur serverin, adresa duhet të ndryshohet.
Çfarë duhet bërë?
Të lidhni serverët me LAG (Grupi i Agregatës së Lidhjes) me dy kabllo në switch-et në raft (ato gjithashtu duhen rezerva). Lidhjet midis raftave duhen rezervuar, dhe të rikonfigurohen në ‘yll’ (ose moda e fundit CLOS), në mënyrë që një humbje e një rafti të mos ndikojë në të tjerët. Të caktohen rafteve ‘qendrore’, ku do të vendoset thelbi rrjetor dhe ku do të lidhen raftet e tjera. Njëkohësisht, të rregullohet adresimi publik, të merret nga hosti (ose nga RIR, nëse ka mundësi) një nëndegë që do të shpallet në botë nga ju vetë (ose përmes hostit).
A mund ta bëjë gjithçka kjo një ‘administrator i zakonshëm’ pa njohuri të thella në rrjeta? Nuk jam i sigurt. A do ta bëjë hosti? Ndoshta, por do t'ju kërkohet një detaj i hollësishëm që gjithashtu duhen përgatitur. Pastaj do të kontrolloni që çdo gjë është bërë siç duhet.
Shembulli 2. Objekti
Supozoni se keni një VPC në ndonjë cloud publik. Për të marrë qasje nga zyra ose pjesa on-prem e infrastrukturës në rrjetin lokal brenda VPC, duhet të konfiguroni një lidhje përmes IPSec ose një kanali të dedikuar. Nga njëra anë, IPSec është më i lirë, pasi nuk keni nevojë të blini pajisje shtesë, mund të konfiguroni një tunel midis serverit tuaj me adresë publike dhe cloud-it. Por, ka vonesa, performancë të kufizuar (pasi kanali kërkon enkriptim), plus lidhje të papërcaktuar (sepse qasja bëhet përmes internetit të zakonshëm).
Çfarë duhet bërë?
Të ngrini lidhjen përmes një kanali të dedikuar (për shembull, në AWS kjo quhet Direct Connect). Për këtë, gjeni një operator-partner që do t'ju lidhë, përcaktoni pikën më të afërt të lidhjes me ju si te operatori, ashtu edhe te operatori në cloud, dhe në fund, konfiguroni gjithçka. A mund ta bëni këtë pa një inxhinier rrjeti? Sigurisht, po. Por si të trajtoni problemet pa të, nuk është aq e qartë.
Gjithashtu mund të lindin probleme me disponueshmërinë midis cloud-eve (nëse keni multi-cloud) ose probleme me vonesat midis rajoneve të ndryshme dhe kështu me radhë. Sigurisht, tani janë shfaqur shumë mjete që rrisin transparencën e asaj që ndodh në cloud (siç është edhe Thousand Eyes), por këto janë mjete për inxhinierët e rrjetit dhe jo zëvendësimi i tyre.
Mund të sjell edhe një dhjetë kësi shembujsh nga praktika ime, por mendoj se është e qartë se në një ekip, duke filluar nga një nivel i caktuar zhvillimi të infrastrukturës, duhet të ketë një njeri (ose më mirë më shumë se një), që di si funksionon rrjeti, që mund të konfiguronte pajisjet rrjetësore dhe të trajtonte problemet nëse ato shfaqen. Besoni, ai do të ketë punë për të bërë.
Çfarë duhet të dijë një inxhinier rrjeti?
Aspak nuk është e nevojshme (dhe madje ndonjëherë, dëmshme), që një inxhinier rrjeti të merret vetëm me rrjetin dhe asgjë tjetër. Edhe nëse nuk e marrim parasysh opsionin e infrastrukturës që jeton gati tërësisht në cloud publik (dhe ai, sado të doni, po bëhet gjithnjë e më popullor), dhe marrim, për shembull, on premise ose cloud privat, ku vetëm me "dijen në nivelin CCNP" nuk do të shkoni shume larg.
Përveç rrjeteve, ndonëse këtu ka një fushë të pafund për t'u studiuar, madje edhe nëse koncentroheni vetëm në një drejtim të vetëm (rrjetet e ofruesve, ndërmarrjet, qendrat të dhënash, wifi…)
Sigurisht, shumë prej jush tani do të kujtohen për Python dhe çdo lloj "automatizimi të rrjetit", por kjo është vetëm një kusht i nevojshëm, por jo i mjaftueshëm. Për të qenë një inxhinier rrjeti që "integron në ekip" me sukses, ai duhet të dijë të flasë me një gjuhë të përbashkët me programuesit dhe kolegët adminë/devopsa. Çfarë do të thotë kjo?
- të dijë jo vetëm si të punojë në Linux si përdorues, por edhe si ta administrojë atë, së paku në nivelin e një admini junior: të instalojë softin e nevojshëm, të riaktivizojë shërbimin që ka rënë, të shkruajë një njësi të thjeshtë systemd.
- të kuptojë (së paku në mënyrë të përgjithshme) si funksionon steka rrjetore në Linux, si është ndërtuar rrjeti në hipervizorët dhe kontejnerët (lxc / docker / kubernetes).
- Sigurisht, duhet të dijë si të punojë me ansible/chef/puppet ose ndonjë sistem tjetër SCM.
- Një pikë e veçantë duhet të shkruhet për SDN dhe rrjetet për re të privatizuara (p.sh., TungstenFabric ose OpenvSwitch). Ky është edhe një nivel tjetër i gjerë i njohurive.
Në mënyrë të shkurtër, unë përshkrova tipin e specialistit T-shape (siç është tani në modë). Dukej si asgjë e re, megjithatë, nga përvoja e intervistave, shumë inxhinierë rrjeti nuk mund të mburren me njohuri për të paktën dy tema nga lista e lartpërmendur. Në praktikë, mungesa e njohurive "në fusha të lidhura" e vështirëson shumë jo vetëm komunikimin me kolegët, por edhe kuptimin e kërkesave që biznesi i parashtron rrjetit, si infrastrukturës më të ulët të projektit. Dhe pa këtë kuptim, bëhet më e vështirë të mbrohet me argumente opinioni i tij dhe "ta shesë" atë në biznes.
Nga ana tjetër, ajo zakon që "të kuptohet si funksionon sistemi" u jep rrjetarëve një përparësi shumë të mirë përballë "specialistëve me profil të gjerë", të cilët dinë për teknologjitë nga artikujt në Habrë/medium dhe bisedat në telegram, por nuk kanë asnjë ide mbi parimet mbi të cilat funksionon ndonjë software. Siç dihet, njohja e disa rregullave zëvendëson me sukses njohjen e shumë faktëve.
Konkluzionet, ose thjesht TL;DR
- Administratori rrjeteve (si DBA ose inxhinier VoIP) është një specialist me profil të ngushtë (ndryshe nga administatorët e sistemeve/devops/SRE), nevoja për të cilin nuk lind menjëherë (dhe mund të mos lindë për një kohë të gjatë, në të vërtetë). Por kur lind, është e vështirë të zëvendësohet me ekspertizë të jashtme (outsourcing ose administatorë të zakonshëm me profil të gjerë, "të cilët gjithashtu mbikëqyrin rrjetin"). Çfarë është edhe më shqetësuese — nevoja për këta specialistë është e vogël, dhe, më saktë, në një kompani me 800 programues dhe 30 devops/administaatorë mund të ketë vetëm dy rrjetikë, të cilët përballen shkëlqyeshëm me detyrat e tyre. Pra, tregu ka qenë dhe është shumë i vogël, dhe për më shumë, për një pagë të mirë — edhe më i vogël.
- Nga ana tjetër, një rrjetik i mirë në botën moderne duhet të dijë jo vetëm për rrjetet (dhe se si t'i automatizojë ato), por edhe se si ndërveprojnë sistemet operuese dhe softi, të cilat të gjithë ata që ndodhen mbi këto rrjete. Pa këtë do të jetë shumë e vështirë të kuptohet se çfarë po kërkojnë kolegët dhe të komunikosh (me arsyetim) dëshirat/të kërkuarat tuaja atyre.
- Nuk ka re, është thjesht një kompjuter i dikujt tjetër. Është e rëndësishme të kuptohet se përdorimi i reve publike/private ose shërbimeve të ofruesve të hostimit "i cili ju bën gjithçka nga fillimi" nuk e heq atë që aplikacioni juaj akoma përdor rrjetin, dhe problemet me të do të ndikojnë në funksionimin e aplikacionit tuaj. Zgjedhja juaj është se ku do të jetë qendra e kompetencës që do të jetë përgjegjëse për rrjetin e projektit tuaj.
Burimi: habr.com
