La momentul scrierii acestui articol, o căutare pe un site de locuri de muncă popular pentru expresia „inginer de rețea” a returnat aproximativ trei sute de posturi vacante în toată Rusia. Pentru comparație, o căutare a expresiei „administrator de sistem” returnează aproape 2.5 mii de posturi vacante, iar „inginer DevOps” - aproape 800.
Înseamnă asta că nu mai sunt necesari rețelei în vremuri de nori victorioși, Docker, Kubernetes și Wi-Fi public omniprezent?
Să ne dăm seama (c)
Sa ne cunoastem. Numele meu este Alexey și sunt un networker.
Sunt implicat în rețele de mai bine de 10 ani și lucrez cu diverse sisteme *nix de mai bine de 15 ani (am avut șansa de a lucra atât cu Linux, cât și cu FreeBSD). Am lucrat în operatori de telecomunicații, companii mari care sunt considerate „întreprinderi”, iar recent am lucrat în fintech „tânăr și îndrăzneț”, unde cloud-uri, devops, kubernetes și alte cuvinte înfricoșătoare care cu siguranță ne vor face pe mine și pe colegii mei inutil . Într-o zi. Pot fi.
declinare a răspunderii: „În viața noastră, nu totul este întotdeauna și peste tot, ci ceva, uneori pe alocuri” (c) Maxim Dorofeev.
Tot ceea ce scrie mai jos poate și ar trebui să fie considerat părerea personală a autorului, care nu pretinde a fi adevărul suprem, sau chiar un studiu cu drepturi depline. Toate personajele sunt fictive, toate coincidențele sunt aleatorii.
Bun venit in lumea mea.
Unde poți întâlni măcar oameni de rețea?
1. Operatori telecom, companii de servicii și alți integratori. Totul este simplu aici: rețeaua pentru ei este o afacere. Fie vând direct conectivitate (operatori), fie oferă servicii pentru lansarea/menținerea rețelelor clienților lor.
Există multă experiență aici, dar nu mulți bani (cu excepția cazului în care ești director sau manager de vânzări de succes). Și totuși, dacă îți plac rețelele și ești abia la începutul călătoriei tale, o carieră în sprijinul unui operator nu foarte mare va fi, chiar și acum, un punct de plecare ideal (în cele federale totul este foarte scriptat, și acolo este puțin loc pentru creativitate). Ei bine, poveștile despre cum poți trece de la un inginer de serviciu în câțiva ani la un manager de nivel C sunt, de asemenea, destul de reale, deși rare, din motive evidente. Întotdeauna este nevoie de personal, deoarece se produce schimbarea de afaceri. Acest lucru este și bine și rău în același timp - mereu sunt locuri vacante, pe de altă parte - de multe ori cei mai activi/inteligenti pleacă rapid fie pentru promovare, fie în alte locuri, „mai calde”.
2. „întreprindere” condiționată. Nu contează dacă activitatea lui principală este sau nu legată de IT. Principalul lucru este că are propriul departament IT, care asigură funcționarea sistemelor interne ale companiei, inclusiv rețeaua în birouri, canale de comunicare către sucursale etc. Funcțiile unui inginer de rețea în astfel de companii pot fi îndeplinite „part-time” de către un administrator de sistem (dacă infrastructura de rețea este mică sau este gestionată de un contractor extern), iar un specialist în rețea, dacă există, poate la În același timp, aveți grijă de telefonie și SAN (nu este bine). Ei plătesc diferit - depinde foarte mult de profitabilitatea afacerii, de dimensiunea companiei și de structură. Am lucrat cu companii în care sistemele Cisco erau în mod regulat „încărcate în butoaie”, și cu companii în care rețeaua a fost construită din fecale, bețe și bandă albastră, iar serverele nu au fost niciodată actualizate (inutil să spun că nici nu au fost furnizate rezerve) . Există mult mai puțină experiență aici și aproape sigur va fi în domeniul blocării stricte a vânzătorului sau „cum să faci ceva din nimic”. Personal, mi s-a părut extrem de plictisitor, deși multora le place - totul este destul de măsurat și previzibil (dacă vorbim de companii mari), „dorakha-bahato”, etc. Cel puțin o dată pe an, un furnizor important spune că au venit cu un alt sistem mega-super-duper care va automatiza totul acum și toți administratorii de sistem și rețelei pot fi dispersați, lăsând câteva butoane pentru a apăsa într-o interfață frumoasă. Realitatea este că, chiar dacă ignorăm costul soluției, rețelei nu vor merge nicăieri de acolo. Da, poate că în locul consolei va exista din nou o interfață web (dar nu o anumită piesă hardware, ci un sistem mare care gestionează zeci și sute de astfel de piese hardware), dar cunoștințele despre „cum funcționează totul în interior” vor încă fi nevoie.
3. Firme de produse, al cărui profit provine din dezvoltarea (și, adesea, funcționarea) a unui software sau platformă - același produs. De obicei sunt mici și agile, sunt încă departe de amploarea întreprinderilor și de birocratizarea lor. Aici se găsesc în masă aceleași devop-uri, cuberi, dockeri și alte cuvinte groaznice, ceea ce cu siguranță va face din inginerii de rețea și de rețea un rudiment inutil.
Cum este diferit un networker de un administrator de sistem?
În înțelegerea oamenilor nu din IT - nimic. Amândoi se uită la ecranul negru și scriu niște vrăji, uneori înjurând în liniște.
În înțelegerea programatorilor - poate pe domeniu. Administratorii de sistem administrează serverele, rețelei administrează comutatoarele și routerele. Uneori administrația este proastă și totul se destramă pentru toată lumea. Ei bine, în caz de ceva ciudat, rețelei sunt și ei de vină. Doar pentru că la naiba, de aceea.
De fapt, principala diferență este abordarea muncii. Poate că printre membrii rețelelor există cei mai mulți susținători ai abordării „Dacă funcționează, nu-l atingeți!”. De regulă, ceva se poate face (în cadrul unui singur furnizor) într-un singur mod; întreaga configurație a cutiei este chiar acolo, în palma mâinii tale. Costul unei erori este mare și uneori foarte mare (de exemplu, va trebui să călătoriți câteva sute de kilometri pentru a reporni routerul, iar în acest moment câteva mii de oameni vor rămâne fără comunicare - o situație destul de comună pentru un operator de telecomunicații) .
În opinia mea, acesta este motivul pentru care inginerii de rețea, pe de o parte, sunt extrem de motivați pentru stabilitatea rețelei (iar schimbarea este principalul inamic al stabilității), iar în al doilea rând, cunoștințele lor merg mai mult în profunzime decât în lățime (nu trebuie să puteți configura zeci de demoni diferiți, trebuie să cunoașteți tehnologiile și implementarea lor de la un anumit producător de echipamente). De aceea, un administrator de sistem care a căutat pe google cum să înregistreze un vlan pe un sistem Cisco nu este încă un operator de rețea. Și este puțin probabil ca el să poată susține eficient (și depana) o rețea mai mult sau mai puțin complexă.
Dar de ce ai nevoie de un networker dacă ai un hoster?
Pentru bani suplimentari (și dacă sunteți un client foarte mare și iubit, poate chiar gratuit, „ca prieten”), inginerii centrelor de date vă vor configura comutatoarele pentru a se potrivi nevoilor dvs. și poate chiar vă vor ajuta să stabiliți o interfață BGP cu furnizorii (dacă aveți propria dvs. subrețea de adrese IP pentru anunț).
Problema principală este că centrul de date nu este departamentul tău IT, este o companie separată al cărei scop este să obțină profit. Inclusiv pe cheltuiala dvs. ca client. Centrul de date oferă rafturi, le asigură electricitate și frig și oferă, de asemenea, o conexiune „implicit” la Internet. Pe baza acestei infrastructuri, centrul de date vă poate găzdui echipamentul (localizare), vă poate închiria un server (server dedicat) sau vă poate oferi un serviciu gestionat (de exemplu, OpenStack sau K8s). Dar afacerea unui centru de date (de obicei) nu este administrarea infrastructurii clientului, deoarece acest proces este destul de laborios, slab automatizat (și într-un centru de date normal tot ce este posibil este automatizat), unificat și mai rău (fiecare client). este individuală) și, în general, plină de plângeri („îmi spuneți că serverul a fost configurat, dar acum s-a prăbușit, totul este vina ta!!!111”). Prin urmare, dacă hosterul vă ajută cu ceva, va încerca să fie cât mai simplu și convenabil. Pentru că a-l face greu este neprofitabil, cel puțin din punctul de vedere al costurilor cu forța de muncă ale inginerilor aceluiași hoster (dar situațiile sunt diferite, vezi disclaimer). Acest lucru nu înseamnă că hosterul va face neapărat totul rău. Dar nu este deloc un fapt că el va face exact ceea ce ai nevoie cu adevărat.
S-ar părea că treaba este destul de evidentă, dar de câteva ori în practica mea am întâlnit faptul că companiile au început să se bazeze pe furnizorul lor de găzduire puțin mai mult decât ar trebui, iar acest lucru nu a dus la nimic bun. A trebuit să explic pe larg și în detaliu că nici un singur SLA nu ar acoperi pierderile din timpul nefuncționării (există excepții, dar de obicei este foarte, FOARTE scump pentru client) și că hosterul nu este deloc conștient de ceea ce se întâmplă în infrastructura clienților (cu excepția indicatorilor foarte generali). Și hosterul nu face copii de rezervă nici pentru tine. Situația este și mai gravă dacă ai mai mult de un hoster. În cazul oricăror probleme între ei, cu siguranță nu vor afla pentru tine ce a mers prost.
De fapt, motivele aici sunt exact aceleași ca atunci când alegeți „echipă de administrare internă vs externalizare”. Dacă riscurile sunt calculate, calitatea este satisfăcătoare și afacerea nu se deranjează, de ce să nu încerci. Pe de altă parte, rețeaua este unul dintre cele mai elementare niveluri de infrastructură și nu merită să-l lăsați pe seama unor oameni din afară, dacă susțineți deja totul.
În ce cazuri este nevoie de un networker?
În continuare vom vorbi în special despre companiile alimentare moderne. Cu operatori și întreprindere, totul este clar, plus sau minus - puține s-au schimbat acolo în ultimii ani, iar oamenii de rețea erau necesari acolo înainte și sunt necesari acum. Dar cu aceleași „tineri și îndrăznețe” lucrurile nu sunt atât de clare. Adesea își plasează întreaga infrastructură în cloud, așa că nici măcar nu au nevoie de administratori - cu excepția administratorilor acelor nori, desigur. Infrastructura, pe de o parte, este destul de simplă în design, pe de altă parte, este bine automatizată (ansible/puppet, terraform, ci/cd... ei bine, știi). Dar chiar și aici există situații în care nu te poți descurca fără un inginer de rețea.
Exemplul 1, clasic
Să presupunem că o companie începe cu un server cu o adresă IP publică, care se află într-un centru de date. Apoi sunt două servere. Apoi mai mult... Mai devreme sau mai târziu, va fi nevoie de o rețea privată între servere. Deoarece traficul „extern” este limitat atât de lățimea de bandă (nu mai mult de 100 Mbit/s de exemplu), cât și de volumul de descărcat/încărcat pe lună (diferiți hosteri au tarife diferite, dar lățimea de bandă către lumea exterioară este de obicei mult mai scumpă decât un rețea privată).
Hosterul adaugă carduri de rețea suplimentare la servere și le include în comutatoarele lor într-un vlan separat. Între servere apare o zonă locală „plată”. Confortabil!
Numărul de servere este în creștere, iar traficul în rețeaua privată crește și el - backup-uri, replicări etc. Găzduitorul se oferă să te mute în comutatoare separate, astfel încât să nu interferezi cu alți clienți, iar ei să nu interfereze cu tine. Hosterul instalează niște comutatoare și le configurează cumva - cel mai probabil, lăsând o rețea plată între toate serverele tale. Totul funcționează bine, dar la un moment dat încep problemele: întârzierile între gazde cresc periodic, jurnalele se plâng de prea multe pachete arp pe secundă, iar în timpul unui audit pentesterul ți-a dispărut întreaga rețea locală, spărgând un singur server.
Ce ar trebui să fac?
Împărțiți rețeaua în segmente - vlan-uri. Configurați-vă propria adresare în fiecare vlan, selectați un gateway care va transfera trafic între rețele. Configurați acl pe gateway pentru a limita accesul între segmente sau chiar instalați un firewall separat în apropiere.
Exemplul 1, continuare
Serverele sunt conectate la LAN cu un singur cablu. Comutatoarele din rafturi sunt cumva conectate între ele, dar dacă există un accident într-un rafturi, alte trei adiacente cad. Schemele există, dar există îndoieli cu privire la relevanța lor. Fiecare server are propria sa adresă publică, care este emisă de hoster și este legată de rack. Acestea. Când mutați un server, adresa trebuie schimbată.
Ce ar trebui să fac?
Conectați serverele folosind LAG (Link Aggregation Group) cu două cabluri la comutatoarele din rack (de asemenea, trebuie să fie redundante). Rezervați conexiunile dintre rafturi și transformați-le într-o „stea” (sau CLOS-ul acum la modă), astfel încât pierderea unui rafturi să nu le afecteze pe celelalte. Selectați rafturile „centrale” în care va fi amplasat nucleul rețelei și unde vor fi conectate alte rafturi. În același timp, pune în ordine adresarea publică, ia de la hoster (sau de la RIR, dacă se poate) o subrețea, pe care tu însuți (sau prin intermediul hosterului) o anunți lumii.
Toate acestea pot fi făcute de un administrator de sistem „obișnuit” care nu are cunoștințe profunde despre rețele? Nu sunt sigur. Va face gazda asta? Poate că va fi, dar veți avea nevoie de o specificație tehnică destul de detaliată, pe care cineva va trebui să o întocmească și el. și apoi verificați dacă totul este făcut corect.
Exemplul 2: nor
Să presupunem că aveți un VPC într-un cloud public. Pentru a obține acces de la birou sau partea locală a infrastructurii la rețeaua locală din interiorul VPC-ului, trebuie să configurați o conexiune prin IPSec sau un canal dedicat. Pe de o parte, IPSec este mai ieftin, pentru că nu este nevoie să cumpărați hardware suplimentar; puteți configura un tunel între serverul dvs. cu o adresă publică și cloud. Dar - întârzieri, performanță limitată (deoarece canalul trebuie criptat), plus conectivitate negarantată (deoarece accesul se face prin internetul obișnuit).
Ce ar trebui să fac?
Creșteți o conexiune printr-un canal dedicat (de exemplu, AWS îl numește Direct Connect). Pentru a face acest lucru, găsiți un operator partener care vă va conecta, decideți asupra punctului de conectare cel mai apropiat de dvs. (atât dvs. de operator, cât și operatorul de cloud) și, în final, configurați totul. Este posibil să faci toate acestea fără un inginer de rețea? Sigur că da. Dar cum să depanezi fără el în caz de probleme nu mai este atât de clar.
Pot exista și probleme cu disponibilitatea între nori (dacă aveți un multicloud) sau probleme cu întârzieri între diferite regiuni etc. Desigur, acum au apărut multe instrumente care măresc transparența a ceea ce se întâmplă în cloud (aceeași Mii de Ochi), dar acestea sunt toate instrumentele unui inginer de rețea, și nu un înlocuitor pentru el.
Aș putea schița încă o duzină de astfel de exemple din practica mea, dar cred că este clar că echipa, pornind de la un anumit nivel de dezvoltare a infrastructurii, trebuie să aibă o persoană (de preferință mai mult de una) care să știe cum funcționează rețeaua și să se poată configura. echipamentele de rețea și rezolvați problemele dacă apar. Crede-mă, va avea ceva de făcut
Ce ar trebui să știe un networker?
Nu este deloc necesar (și chiar, uneori, dăunător) ca un inginer de rețea să se ocupe doar de rețea și nimic altceva. Chiar dacă nu luăm în considerare opțiunea cu o infrastructură care trăiește aproape în întregime în cloud-ul public (și, orice s-ar spune, devine din ce în ce mai popular), și luăm, de exemplu, cloud-urile on-premise sau private, unde pe „Cunoștințe la nivel CCNP singur” „Nu vei pleca.
Pe lângă, de fapt, rețele - deși pur și simplu există un domeniu nesfârșit de studiu, chiar dacă vă concentrați doar pe o singură zonă (rețele de furnizori, întreprinderi, centre de date, Wi-Fi ...)
Desigur, mulți dintre voi își vor aminti acum Python și alte „automatizări ale rețelei”, dar aceasta este doar o condiție necesară, dar nu suficientă. Pentru ca un inginer de rețea să se „alăture cu succes echipei”, el trebuie să fie capabil să vorbească aceeași limbă atât cu dezvoltatorii, cât și cu colegii administratori/dezvoltatori. Ce înseamnă?
- să fie capabil nu numai să lucreze în Linux ca utilizator, ci și să-l administreze, cel puțin la nivel sysadmin-jun: instalați software-ul necesar, reporniți un serviciu eșuat, scrieți o unitate de sistem simplă.
- Înțelegeți (cel puțin în termeni generali) cum funcționează stiva de rețea în Linux, cum funcționează rețeaua în hipervizoare și containere (lxc / docker / kubernetes).
- Desigur, să poți lucra cu ansible/chef/puppet sau alt sistem SCM.
- Ar trebui scrisă o linie separată despre SDN și rețele pentru cloud-uri private (de exemplu, TungstenFabric sau OpenvSwitch). Acesta este un alt strat imens de cunoștințe.
Pe scurt, am descris un specialist tipic în formă de T (cum este la modă să spun acum). Pare a fi nimic nou, dar pe baza experienței la interviuri, nu toți inginerii de rețea se pot lăuda cu cunoașterea a cel puțin două subiecte din lista de mai sus. În practică, lipsa de cunoștințe „în domenii conexe” face foarte dificilă nu doar comunicarea cu colegii, ci și înțelegerea cerințelor pe care afacerile le plasează în rețea, ca infrastructură de cel mai jos nivel a proiectului. Și fără această înțelegere, devine mai dificil să-ți aperi punctul de vedere și să-l „vinzi” afacerilor.
Pe de altă parte, același obicei de a „înțelege cum funcționează sistemul” oferă utilizatorilor de rețea un avantaj foarte bun față de diverși „generaliști” care știu despre tehnologii din articolele de pe Habré/mediu și chat-urile de pe Telegram, dar nu au absolut nicio idee cum să facă. principii pe care funcționează cutare sau cutare software? Și cunoașterea anumitor modele, după cum se știe, înlocuiește cu succes cunoașterea multor fapte.
Concluzii, sau doar TL;DR
- Un administrator de rețea (cum ar fi un inginer DBA sau VoIP) este un specialist cu un profil destul de îngust (spre deosebire de administratorii de sistem/devs/SRE), a cărui nevoie nu apare imediat (și poate să nu apară pentru o lungă perioadă de timp, de fapt) . Dar, dacă apare, este puțin probabil să fie înlocuit de expertiză externă (externalizați sau administratori obișnuiți cu scop general, „care au grijă și de rețea”). Ceea ce este oarecum mai trist este că nevoia de astfel de specialiști este mică și, condiționat, într-o companie cu 800 de programatori și 30 de devopi/administratori, pot fi doar doi networkeri care fac o treabă excelentă cu responsabilitățile lor. Acestea. piata era si este foarte, foarte mica, si cu un salariu bun – cu atat mai putin.
- Pe de altă parte, un bun networker în lumea modernă trebuie să cunoască nu numai rețelele în sine (și cum să le automatizeze configurația), ci și modul în care sistemele de operare și software-ul care rulează deasupra acestor rețele interacționează cu ele. Fără aceasta, va fi extrem de dificil să înțelegeți ce vă cer colegii și să le transmiteți (în mod rezonabil) dorințele/cerințele dumneavoastră.
- Nu există cloud, este doar computerul altcuiva. Trebuie să înțelegeți că utilizarea cloud-urilor publice/private sau a serviciilor unui furnizor de găzduire „care face totul pentru dvs. la cheie” nu schimbă faptul că aplicația dvs. încă folosește rețeaua, iar problemele cu aceasta vor afecta funcționarea aplicatia ta. Alegerea dvs. este locul unde va fi amplasat centrul de competențe, care va fi responsabil pentru rețeaua proiectului dumneavoastră.
Sursa: www.habr.com