Në momentin e shkrimit të këtij artikulli, kërkimi në një nga faqet e punës më të njohura për shprehjen "Inxhinier rrjeti" jepte rreth treqind vende pune në të gjithë Rusinë. Për krahasim, kërkimi me frazën "administrator sistemi" jep gati 2.5 mijë vende pune, ndërsa "Inxhinier DevOps" — gati 800.
A do të thotë kjo se inxhinierët e rrjetit nuk janë më të nevojshëm në epokën e reve, docker-it, kubernetes-it dhe wifi-t publik që është kudo?
Le të e zbulojmë (c)
Le ta njohim njëri-tjetrin. Emri im është Aleksei, dhe unë jam inxhinier rrjeti.
Kam më shumë se 10 vjet që merrem me rrjetet dhe më shumë se 15 vjet që punoj me sisteme të ndryshme *nix (kam ndjerë përvojën me Linux dhe FreeBSD). Kam punuar në operatorët e komunikacionit, në kompani të mëdha që zakonisht konsiderohen "ndërmarrje", dhe kohët e fundit punoj në një fintech "të ri dhe të guximshëm", ku re, DevOps, kubernetes dhe fjalë të tjera frikësuese që do të na bëjnë mua dhe kolegët e mi të panevojshëm. Diku. Ndoshta.
përjashtim: "Në jetën tonë nuk është gjithçka, gjithmonë dhe kudo, por ndonjëherë dhe në disa vende" (c) Maksim Dorofejev.
E gjithë ajo që është shkruar më sipër mund dhe duhet të konsiderohet si mendim personal i autorit, që nuk pretendon për të qenë e vërteta absolute, dhe as për një kërkim të plotë. Të gjitha personazhet janë imagjinare, të gjitha ngjashmëritë janë rastësore.
Mirë se vini në botën time.
Ku mund të takosh rrjetistë në përgjithësi?
1. Operatorë të komunikimit, kompani shërbimi dhe integratorë të tjerë. Këtu gjithçka është e thjeshtë: rrjeti për ta është biznes. Ata ose e shesin drejtpërdrejt lidhjen (operatorë), ose ofrojnë shërbime për fillimin/mbajtjen e rrjeteve të klientëve të tyre.
Kaç eksperienca këtu ka, para — nuk ka shumë (nëse nuk jeni drejtor ose menaxher i suksesshëm shitjesh). Megjithatë, nëse ju pëlqejnë rrjetet dhe sapo keni filluar, një karrierë në mbështetje tek ndonjë operator jo shumë i madh do të ishte, edhe tani, pika ideale për të nisur (në kompanitë federale gjithçka është shumë e standardizuar, dhe ka pak hapësirë për krijimtari). Po ashtu, historitë për atë se si mund të kalosh nga inxhinier dezhurni në një menaxher C-level brenda disa vjetësh janë gjithashtu të mundshme, ndonëse të ralla, për arsye të njohura. Ka gjithmonë nevojë për personel, sepse turnoveri ndodh. Kjo është e mirë dhe e keqe njëkohësisht — gjithmonë ka vende të lira, nga ana tjetër — shpesh, ata më aktivë/ inteligjentë ikin mjaft shpejt për përmirësim, ose për vende më 'të ngrohta'.
2. Një 'ndërmarrje' e kushtëzuar. Nuk është e rëndësishme nëse aktiviteti i tij kryesor është i lidhur me IT-të 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ë rrjetet në zyrat, kanalet e komunikimit në degë etj. Funksionet e inxhinierit të rrjetit në këto kompani mund të kryhen «në mënyrë të përbashkët» nga një administrator sistemi (nëse infrastruktura e rrjetit është e vogël, ose menaxhohet nga një kontraktues i jashtëm), ndërsa një rrjetar, nëse e ka, mund të mbikëqyrë gjithashtu telefoninë dhe SAN-in (pa dyshim). Pagat ndryshojnë gjithashtu — shumë varen nga margjinaliteti i biznesit, madhësia e kompanisë dhe struktura. Kam punuar me kompani ku Cisco-t ngarkoheshin rregullisht me tonelata dhe me kompani ku rrjeti ndërtohej nga plehra, degë dhe kashta blu, dhe serverët nuk refreshoheshin kurrë (nuk ka nevojë të thuhet se nuk ishin parashikuar as rezervat). Eksperienca këtu është shumë më e vogël, dhe 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ë». Personalish, më dukej jashtëzakonisht e mërzitshme, ndonëse shumë u pëlqen — gjithçka është mjaft e qetë dhe e parashikueshme (nëse flasim për kompani të mëdha), «doraha-bahato» etj. Jo më pak se një herë në vit ndonjë shitës i madh thotë se ka krijuar një sistem mega-super-duper, i cili do të automatizojë gjithçka dhe do të jetë e mundur të shuhen të gjithë administratorët e sistemeve dhe rrjeteve, duke lënë një apo dy për të shtypur butonat në një ndërfaqe të bukur. Realiteti është se, edhe nëse abstrahohemi nga kostoja e zgjidhjes, rrjetarët nuk do të zhduken nga aty. Po, ndoshta, në vend të konsolës do të jetë sërish një ndërfaqe web (por jo e një pajisjeje të caktuar, por e një sistemi të madh që menaxhon dhjetëra dhe qindra të tillë), por njohuritë «si është gjithçka brenda» do të nevojiten gjithsesi.
3. Kompanitë e produkteve, fitimi i së cilës vjen nga zhvillimi (dhe, shpesh, operimi) i ndonjë programi ose platforme — aty ku gjendet ai produkt. Zakonisht janë të vogla dhe të shpejta, ende larg shkallëve të ndërmarrjeve dhe burokracisë së tyre. Pikërisht këtu është vendi ku në masë të madhe operojnë devops-ët, kubernetes-at, docker-at dhe fjalët e tjera të frikshme, që patjetër do të bëjnë që rrjetet dhe inxhinierët e rrjetit të duken si një relikt të panevojshëm.
Si ndryshon një inxhinier rrjeti nga një administrator sistemi?
Në kuptimin e njerëzve jashtë IT-së — asgjë. Të dy shikojnë një ekran të zi dhe shkruajnë disa formula magjike, ndonjëherë duke shfryrë në heshtje.
Në kuptimin e programuesve — ndoshta vetëm në fushën e specializimit. Administratorët e sistemeve menaxhojnë serverët, inxhinierët e rrjetit menaxhojnë switch-et dhe router-at. Ndonjëherë menaxhojnë keq, dhe gjitha bien. Në rast se ndodhin ndonjë çështje të çuditshme, fajin e kanë gjithashtu inxhinierët e rrjetit. Thjesht sepse, edhe ashtu, kjo është arsyeja.
Në të vërtetë, ndryshimi kryesor është qasja ndaj punës. Mendoj se pikërisht midis inxhinierëve të rrjetit ka më shumë mbështetës të qasjes "Funksionon - mos e prek!". Të bësh diçka (brenda një ofruesi) zakonisht mund të realizohet vetëm në një mënyrë, e gjithë konfigurimi i pajisjes është këtu, në pëllëmbë. Çmimi i gabimit është i lartë, dhe ndonjëherë shumë i lartë (për shembull, mund të ndodhë që duhet të udhëtosh disa qindra kilometra për të rinisur router-in, ndërsa në këtë kohë disa mijëra njerëz do të mbesin pa lidhje - një situatë krejt normale për një operator të shërbimit të komunikimit).
Mendimi im është se pikërisht për këtë arsye inxhinierët e rrjetit, nga njëra anë, janë shumë të motivuar për stabilitetin e rrjetit (dhe ndryshimet janë armiku kryesor i stabilitetit), dhe nga ana tjetër, njohuritë e tyre shkojnë më thellë se sa në gjerësi (nuk është e nevojshme të dish të konfigurosh dhjetëra demonë të ndryshëm, por duhet të njohësh teknologjitë dhe implementimin e tyre nga një prodhues specifik të pajisjeve). Pikërisht për këtë arsye, një sistem administrator që ka kërkuar në Google se si të konfigurojë VLAN-in në Cisco - nuk është ende një inxhinier i rrjetit. Dhe është e vështirë që ai të mbështesë effektivisht (po ashtu si dhe të zgjidhë problemet) një rrjet më të ndërlikuar.
Por çfarë do të ju nevojitet një rrjet, nëse keni hostin?
Për një tarifë të vogël (dhe nëse jeni një klient shumë i madh dhe i dashur — ndoshta madje edhe falas, "nga shoqëria") inxhinierët e qendrës së të dhënave do të konfiguruan switchet tuaj sipas nevojave tuaja dhe ndoshta do t'ju ndihmojnë të ngrini BGP-në me ofruesit (nëse keni subnetin tuaj adresat ip për njoftim).
Problemi kryesor është se data center-i nuk është departamenti juaj IT, por një kompani e veçantë, e cila ka si qëllim fitimin. Kjo përfshin edhe ju si klient. Data center-i ofron raftet, siguron energjinë elektrike dhe ftohjen, si dhe ofron një lidhje 'default' me internetin. Bazuar në këtë infrastrukturë, data center-i mund të vendosë pajisjet tuaja (colocation), të marrë me qira një server (dedicated server), ose të ofrojë një shërbim të menaxhuar (p.sh., OpenStack ose K8s). Por, biznesi i data center-it (zakonisht) nuk është administrimi i infrastrukturës së klientëve, sepse ky proces është mjaft i punësuar, i vështirë për t'u automatizuar (dhe në një data center normal, gjithçka që është e mundur është automatizuar), akoma më e vështirë për t'u standardizuar (çdo klient është i veçantë) dhe në përgjithësi i rrezikshëm për pretendime ('e konfiguruat serverin tim, dhe tani ra, ju jeni fajtorët!!!111'). Prandaj, nëse host-i do të ndihmojë në ndonjë çështje, ai do të përpiqet ta bëjë sa më të lehtë dhe 'standard'. Sepse bëja e gjërave të komplikuara është e pafavorshme, të paktën nga pikëpamja e kostove të punës së inxhinierëve të këtij host-i (por situatat mund të ndryshojnë, shih përjashtimin). Kjo nuk do të thotë se host-i do të bëjë gjithmonë punë të keqe. Por, nuk është aspak e garantuar që do të bëjë pikërisht atë që ju nevojitej në të vërtetë.
Duket se është një gjë mjaft e dukshme, por unë kam përjetuar disa herë në praktikën time se kompanitë fillonin të mbështeteshin te ofruesi i tyre i hostimit pak më shumë sesa duhet, dhe kjo nuk çonte në asgjë të mirë. Duhej të shpjegoja për një kohë të gjatë se asnjë SLA nuk do të mbulojë humbjet nga ndalja (ka përjashtime, por zakonisht është shumë, SHUMË e shtrenjtë për klientin) dhe se ofruesi i hostimit nuk është në dijeni të asaj që ndodh në infrastrukturën e klientëve (përveç të dhënave shumë të përgjithshme). Dhe ofruesi gjithashtu nuk bën backup për ju. Më keq është nëse keni më shumë se një ofrues hostimi. Në rast të ndonjë problemi mes tyre, ata me siguri nuk do të hetojnë për ju se çfarë ka shkuar keq.
Motivet këtu janë pikërisht të njëjtat si në zgjedhjen e "ekipit të brendshëm të adminëve vs outsourcing". Nëse rreziqet janë llogaritur, cilësia është e pranueshme dhe biznesi nuk ka problem — pse të mos provohet. Nga njëra anë, rrjeti është një nga shtresat bazike të infrastrukturës, dhe nuk ka shumë kuptim ta dorëzoni në duar të njerëzve të jashtëm, nëse gjithçka tjetër e mbani vetë.
Në cilat raste nevojitet një specialist i rrjetit?
Tani do të flasim për kompanitë moderne të produkteve. Me operatorët dhe ndërmarrjet, gjithçka është më shumë-më pak e qartë — aty shumë gjëra nuk kanë ndryshuar në vitet e fundit, dhe specialistët e rrjetit ishin të nevojshëm më parë, janë të nevojshëm edhe tani. Por me ato të rinjtë dhe guximtarët, gjërat nuk janë kaq të qarta. Shumë herë ata vendosin infrastrukturën e tyre tërësisht në re, kështu që madje as administratorët e sistemit nuk i duhen shumë — përveç administratorëve të atyre vetë reve, sigurisht. Infrastruktura, nga njëra anë, është mjaft e thjeshtë në ndërtimin e saj, nga ana tjetër — mirë e automatizuar (ansible/puppet, terraform, ci/cd… e dini). Por madje edhe këtu ka situata kur nuk mund të shmangni një inxhinier rrjeti.
Shembulli 1, klasik
Supozoni se një kompani fillon me një server me adresë IP publike që ndodhet në një qendër të të dhënave. Më pas, serverët bëhen dy. Pastaj më shumë... Herët apo vonë, shfaqet nevoja për një rrjet privat mes serverëve. Sepse trafiku "jashtë" është i kufizuar si për brez (jo më shumë se 100Mbit/s për shembull), ashtu edhe për sasinë e të dhënave të shkarkuara/ndarë në muaj (të ndryshme sipas ofruesve të shërbimeve, por brezi në botën e jashtme, zakonisht, është shumë më i shtrenjtë se një rrjet privat).
Ofruesi i shërbimit shton karta të tjera rrjeti në serverë dhe i lidh ato në switch-at e tij në një VLAN të veçantë. Ndërmjet serverëve shfaqet një lokal i "planizuar". I përshtatshëm!
Numri i serverëve po rritet, po ashtu edhe trafiku në rrjetin privat — backup-et, replikimet etj. Ofruesi i shërbimit ofron mundësinë për t'ju izoluara në switch-e të veçantë, në mënyrë që të mos e shqetësoni njëri-tjetrin. Ofruesi i shërbimit instalon disa switch-e dhe i konfiguron ato — ndoshta 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 ndodhin vonesa midis hosteve, në log-e ka ankesë për një numër shumë të madh paketash ARP në sekondë, dhe një pëntestues, gjatë auditimit, ka arritur të hyjë në të gjithë rrjetin tuaj lokal, duke prishur vetëm një server.
Çfarë duhet të bëhet?
Të ndahen rrjetet në segmente — VLAN. Të konfigurohet adresimi i veçantë në çdo VLAN, të caktuar një gateway që do të ndihmojë në kalimin e trafikut midis rrjeteve. Në gateway, të konfigurohet ACL për të kufizuar aksesin midis segmenteve, ose madje të vendoset një firewall i veçantë afër.
Shembulli 1, vazhdim
Serverët janë të lidhur në lokal me një kabllo të vetme. Switch-ët në raftet janë të lidhur ndryshe, por në rast të një аварie në një raft, tre të tjerët ndalojnë gjithashtu. Ekzistojnë skema, por ka dyshime për aktualitetin e tyre. Çdo server ka një adresë publike, e cila jepet nga hosteri dhe lidhja me raftin. Nënkupton që, kur serveri të zhvendoset, duhet të ndryshohet adresa.
Çfarë duhet të bëhet?
Përdorni LAG (Link Aggregation Group) për të lidhur serverët me dy kabllo në switch-at në raft (këto gjithashtu duhet të jenë të rezervuara). Lidhjet mes raftëve duhet të rezervohen dhe të ri-rregullohen në formën e "yjesh" (ose CLOS, që është aktualisht në modë), që humbja e një rafti të mos ndikojë në të tjerët. Disa raftë "qendrorë" duhet të përzgjidhen, ku do të vendoset bërthama rrjetërore dhe ku do të lidhen raftet e tjera. Po ashtu, siç duhet bërë një renditje e adresave publike, duhet marrë nga hosteri (ose nga RIR, nëse është e mundur) një subnetwork, e cila do të shpallet në botë vetë (ose përmes hosterit).
A mund të bëjë gjithçka një 'administrator i zakonshëm' pa njohuri të thella në rrjet? Nuk jam i sigurt. A do ta bëjë kjo kompani hostingu? Mund ta bëjë, por do t'ju duhet një specifikim i detajuar, që gjithashtu duhet të krijohet nga dikush tjetër. Pastaj duhet të kontrolloni që gjithçka është bërë siç duhet.
Shembulli 2. Reja
Supozoni se keni një VPC në një nga rethet publike. Për të kaluar aksesin nga zyra ose nga 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ë anë — IPSec është më i lirë, pasi nuk nevojitet blerja e pajisjeve të tjera; mund të krijoni një tunel mes serverit tuaj me adresë publike dhe re. Por — ka vonesa, performancë të kufizuar (pasi kanali duhet të kriptohet), gjithashtu lidhshmëria nuk është e garantuar (pasi aksesi bëhet përmes internetit të zakonshëm).
Çfarë duhet të bëhet?
Ngrijeni lidhjen përmes një kanali të dedikuar (p.sh., për AWS njihet si Direct Connect). Për këtë, gjeni një operator partner që do t'ju lidhe, përcaktoni pikën e lidhjes më të afërt (si te operatori ashtu edhe te operatori në cloud), dhe, për më në fund, konfigurojini të gjitha. A është e mundur të bëhet kjo pa një inxhinier rrjeti? Sigurisht, po. Por, si do ta zgjidhni ndonjë problem që paraqitet pa të, nuk është aq e qartë.
Gjithashtu, mund të ketë probleme me aksesin midis cloud-eve (nëse keni multicloud) ose probleme me vonesat midis rajoneve të ndryshme etj. Sigurisht, tani ka shumë mjete që rrisin transparencën e asaj që po ndodh në cloud (po ashtu si dhe Thousand Eyes), por këto janë mjete të inxhinierëve rrjet, jo zëvendësimi i tyre.
Mund të ofroja edhe dhjetë të tillë si shembuj nga praktika ime, por mendoj se është e qartë se në ekip, duke filluar nga një nivel të caktuar i zhvillimit të infrastrukturës, duhet të ketë një person (e preferueshme më shumë se një), i cili di se si funksionon rrjeti, mund të konfigurojë pajisjet rrjet dhe të merret me problemet nëse ato shfaqen. Besoni, atij do t'i ketë me çfarë të merret.
Çfarë duhet të dijë një inxhinier rrjeti?
Nuk është aspak e nevojshme (dhe madje ndonjëherë dëmton) 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 pothuajse krejtësisht në re publike (dhe, siç e dimë, po bëhet gjithnjë e më e njohur), dhe marim, për shembull, re on-premise ose private, njohuritë vetëm në nivelin CCNP nuk janë të mjaftueshme.
Përveç rrjeteve, ka një terren të pafund për të studiuar, madje edhe nëse përqendrohemi vetëm në një drejtim të caktuar (rrjetet e ofruesve, ndërmarrjeve, qendrat të të dhënave, Wi-Fi…)
Natyrisht, shumë prej jush tani do të kujtojnë për Python dhe automatikën e rrjetit, por kjo është vetëm një kusht i nevojshëm, por jo i mjaftueshëm. Që një inxhinier rrjeti të "inkludhet me sukses në ekip", ai duhet të dijë të flasë në të njëjtën gjuhë me zhvilluesit dhe kolegët administratorë/devops. Çfarë do të thotë kjo?
- të dijë të punojë në Linux si përdorues, por gjithashtu ta administrojë atë, të paktën në nivelin e administratorit junior: të instalojë software të nevojshëm, të rinisë një shërbim të rënë, të shkruaj një njësi të thjeshtë systemd.
- Të kuptoni (edhe për nga aspekti themelor) se si funksionon staku rrjetor në Linux, si është ndërtuar rrjeti në hipervizorë dhe kontejnerë (lxc / docker / kubernetes).
- Natyrisht, të jeni në gjendje të punoni me ansible/chef/puppet ose një sistem tjetër të menaxhimit të konfigurations (SCM).
- Një temë e veçantë ka të bëjë me SDN dhe rrjetet për re private (për shembull, TungstenFabric ose OpenvSwitch). Ky është një fushë e madhe e njohurish.
Në përmbledhje, kam përshkruar një specialist tipik T-shape (siç po flitet tani). Duket se nuk ka asgjë të re, megjithatë nga përvoja e intervistave, shumë inxhinierë rrjeti nuk mund të mburren me njohuri në të paktën dy tema nga lista e mësipërme. Në praktikë, mungesa e njohurive "në fusha të ngjashme" e vështirëson shumë jo vetëm komunikimin me kolegët, por edhe kuptimin e kërkesave që biznesi i paraqet rrjetit, si infrastruktura më e ulët e projektit. Pa këtë kuptim, bëhet më e vështirë të mbrohet me argumente pikëpamja juaj dhe ta "shisni" atë biznesit.
Nga ana tjetër, zakoni i njohur "për të kuptuar se si funksionon sistemi" u jep një avantazh të shkëlqyer profesionistëve të rrjetit përballë "specialistëve të përgjithshëm", të cilët dinë për teknologjitë nga artikuj në Habrë/Medium dhe biseda në Telegram, por nuk kanë të ide se mbi cilat parime funksionon një soft i caktuar. Njohja e disa ligjeve, siç e dimë, shpesh zëvendëson njohjen e shumë fakteve.
Përfundimet, ose thjesht TL;DR
- Administratori i rrjetit (ashtu si DBA ose inxhinieri VoIP) është një specialist me profil të ngushtë (ndryshe nga adminët e sistemit / devops / SRE), kërkesa 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 ndodh, vështirë se mund të zëvendësohet me ekspertizë nga jashtë (outsourcing ose adminë të zakonshëm me profil të gjerë, "të cilët gjithashtu kujdesen për rrjetin"). Ajo që është pak më e trishtueshme - kërkesa për këta specialistë është e vogël, dhe, në mënyrë të kushtëzuar, në një kompani me 800 programues dhe 30 devops/adminë mund të jenë vetëm dy administratërrjetesh, të cilët përmbushin detyrat e tyre në mënyrë të shkëlqyer. Pra, tregu ka qenë dhe është mjaft i vogël, dhe për të pasur një pagë të mirë - akoma më e vogël.
- Nga ana tjetër, një administratërrjeti i mirë në botën moderne duhet të dijë jo vetëm për rrjetet (dhe si t’i automatizojë ato), por edhe si ndërveprojnë sistemet operative dhe softi që ecën mbi këto rrjete. Pa këtë, do të jetë jashtëzakonisht e vështirë të kuptosh se çfarë po kërkojnë kolegët dhe të transmetosh (më me argument) dëshirat / kërkesat e tua tek ata.
- Nuk ka cloud, është thjesht kompjuteri i dikujt tjetër. Duhet të kuptoni se përdorimi i shërbimeve publike/private në cloud ose të ofruesve të shërbimeve të hostimit "që bën gjithçka për ju" nuk e anulon faktin se aplikacioni juaj vazhdon të përdorë rrjetin, dhe problemet me të do të ndikojnë në operimin 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
