La momentul scrierii acestui articol, căutarea pe un site de muncă popular cu expresia „Inginer de rețea” returna aproximativ trei sute de locuri de muncă în toată Rusia. Ca și comparație, căutarea cu fraza „administrator de sistem” afișa aproape 2.5 mii de locuri de muncă, iar „Inginer DevOps” — aproape 800.
Înseamnă asta că rețelele nu mai sunt necesare în vremurile norilor, Docker, Kubernetes și a publicului wifi omniprezent?
Hai să ne lămurim (c)
Hai să ne cunoaștem. Mă numesc Alexei, și sunt specialist în rețele.
Am lucrat mai mult de 10 ani în rețele și mai mult de 15 ani cu diverse sisteme *nix (m-am ocupat de Linux și FreeBSD). Am lucrat pentru operatori de telecomunicații, mari companii considerate „enterprise”, iar în ultima vreme lucrez într-un fintech „tânăr și îndrăzneț”, unde norii, devops, kubernetes și alte cuvinte înfricoșătoare care cu siguranță mă vor face pe mine și colegii mei să devenim inutili. Cândva. Poate.
disclaimer: „În viața noastră, nu totul, întotdeauna și pretutindeni, iar unele lucruri, uneori și pe alocuri” (c) Maxim Dorofeev.
Tot ce este scris mai jos poate și trebuie considerat opinia personală a autorului, care nu își pretinde adevărul absolut, și chiar nu se pretinde a fi o cercetare completă. Toate personajele sunt fictive, toate coincidențele sunt întâmplătoare.
Bine ai venit în lumea mea.
Unde pot fi întâlniți de fapt specialiștii în rețele?
1. Operatorii de telecomunicații, companiile de servicii și alți integratori. Aici este simplu: rețeaua pentru ei este afacerea. Ei vând fie conectivitate direct (operatorii), fie oferă servicii de lansare/întreținere a rețelelor clienților lor.
Există multe experiențe aici, dar nu prea mulți bani (dacă nu ești director sau un manager de vânzări de succes). Cu toate acestea, dacă îți plac rețelele și ești doar la început de drum, o carieră în suportul unui operator nu foarte mare va fi, chiar și acum, un punct ideal de plecare (la operatorii mari, totul este foarte scriptat și există puțin spațiu pentru creativitate). De asemenea, poveștile despre cum poți ajunge de la inginer de suport la manager C-level în câțiva ani sunt de asemenea foarte reale, deși rare, din motive evidente. Cererea de personal există întotdeauna, deoarece, într-adevăr, există fluctuații de personal. Acest lucru este atât bun, cât și rău în același timp — există întotdeauna locuri de muncă disponibile, dar, pe de altă parte, cei mai activi/inteligenti pleacă destul de repede, fie pentru o promovare, fie către alte locuri de muncă mai „câștigătoare”.
2. Condițional „enterprise”. Indiferent dacă activitatea principală este legată de IT sau nu. Cheia este că există un departament IT care se ocupă de funcționarea sistemelor interne ale companiei, inclusiv rețelele din birouri, canalele de comunicație către filiale etc. Funcțiile inginerului de rețea în astfel de companii pot fi îndeplinite „în paralel” de un administrator de sistem (dacă infrastructura rețelei este mică sau este gestionată de un contractor extern), iar inginerul de rețea, dacă este prezent, poate supraveghea de asemenea telefonia și SAN (fără prea multe detalii). Salariile variază considerabil — depind mult de marja de profit a afacerii, de dimensiunea companiei și de structură. Am lucrat atât cu companii care au „încărcat” echipamente Cisco, cât și cu companii care au construit rețele din resturi, bețe și bandă izolatoare albastră, iar serverele nu au fost actualizate niciodată (nu trebuie să spun că nu existau rezerve planificate). Experiența în acest domeniu este mult mai mică și, în mod aproape sigur, va fi în domeniul unei rigidități severe a vendor-lock-ului 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 ritmic și previzibil (dacă vorbim despre companii mari), „totul în ordine” etc. Nu mai puțin de o dată pe an, un mare furnizor anunță că a inventat un nou sistem mega-super-puțin care va automatiza tot și toți administratorii de sistem și inginerii de rețea vor putea fi concediați, lăsând câțiva pentru a apăsa pe butoane în interfața frumoasă. Realitatea este că, chiar dacă ignorăm costul soluției, inginerii de rețea nu vor dispărea. Da, este posibil ca în loc de consolă să avem din nou o interfață web (dar nu pentru un echipament specific, ci pentru un sistem mare care gestionează zeci sau sute de astfel de echipamente), dar cunoștințele despre „cum funcționează totul în interior” vor fi totuși necesare.
3. Companii de produse, a cărei profitabilitate provine din dezvoltarea (și, adesea, din exploatarea) unui software sau platformă — acel produs. De obicei, sunt mici și agile, având încă mult de parcurs până la dimensiunea întreprinderilor și birocrația acestora. Anume aici își găsesc loc acei devops, kubernetes, docker și alte cuvinte înfricoșătoare care vor face rețelele și inginerii de rețea un relicvar inutil.
Cum se deosebește un inginer de rețea de un administrator de sistem?
În înțelegerea oamenilor din afara IT-ului — nu este nimic. Atât unul, cât și celălalt se uită la un ecran întunecat și tastează diverse vrăji, uneori înjurând în șoaptă.
În opinia programatorilor — poate, doar în ceea ce privește domeniul de aplicare. Adminii de sistem administrează servere, rețelistii administrează comutatoare și routere. Uneori, o fac prost și totul cade. În cazul unor probleme, rețelistii sunt și ei răspunzători. Doar pentru că, de ce nu, asta e motivul.
De fapt, principalul diferențator este abordarea față de muncă. Probabil că printre rețeliști există cei mai mulți susținători ai principiului „Dacă funcționează, nu atinge!”. O anumită sarcină (în cadrul unui singur furnizor) poate fi realizată, de obicei, doar într-un singur mod, întreaga configurație a echipamentului — iată-o, la îndemână. Prețul unei erori — ridicat, uneori chiar foarte ridicat (de exemplu, va trebui să călătoriți câteva sute de kilometri pentru a reporni un router, iar în acest timp câteva mii de oameni vor rămâne fără conexiune — o situație obișnuită pentru un operator de telecomunicații).
Din punctul meu de vedere, acesta este motivul pentru care inginerii de rețea, pe de o parte, sunt extrem de motivați să mențină stabilitatea rețelei (iar schimbările sunt principalul dușman al stabilității), iar pe de altă parte, cunoștințele lor merg mai adânc decât lățimea (nu trebuie să știi cum să configurezi zeci de demoni diferiți, trebuie să cunoști tehnologiile și implementarea acestora de către producătorul de echipamente specific). De aceea, un admin de sistem care a căutat pe Google cum să configureze un VLAN pe Cisco — nu este neapărat un rețelist. Și cu greu va putea susține eficient (și, de asemenea, rezolva problemele) o rețea relativ complexă.
Dar de ce ai nevoie de un rețelist, dacă ai hoster?
Pentru o sumă suplimentară (iar dacă ești un client foarte mare și apreciat — poate chiar gratuit, „pe prietenie”) inginerii centrului de date îți vor configura comutatoarele conform necesităților tale și, poate, chiar te vor ajuta să ridici un peering BGP cu furnizorii (dacă ai o subrețea de adrese IP pentru anunț).
Problema principală este că centrul de date nu este departamentul dumneavoastră IT, ci o companie separată, ale cărei scopuri sunt să genereze profit. Acest lucru include și profitul de la dumneavoastră, ca și client. Centrul de date oferă rack-uri, le asigură cu electricitate și răcire, precum și furnizează o anumită „conectivitate default” la internet. Pe baza acestei infrastructuri, centrul de date poate găzdui echipamentul dumneavoastră (colocation), să vă închirieze un server (dedicated server) sau să ofere un serviciu gestionat (de exemplu, OpenStack sau K8s). Însă, administrarea infrastructurii clienților nu este, de obicei, activitatea principală a centrului de date, deoarece acest proces este destul de consumator de resurse, greu de automatizat (iar într-un centru de date normal, tot ce poate fi automatizat este automatizat), mai puțin standardizat (fiecare client este unic) și în general duce la reclamații („mi-ați configurat serverul, iar acum a căzut, voi sunteți vinovați!!!111”). Așadar, dacă providerul de hosting va ajuta cu ceva, se va strădui să facă acest lucru cât mai simplu și „basic”. Pentru că a face lucrurile complicate nu este rentabil, cel puțin din perspectiva eforturilor inginerilor acelui provider de hosting (dar situațiile pot varia, vezi disclaimer). Aceasta nu înseamnă că providerul de hosting va face neapărat totul prost. Dar nu este deloc sigur că va face exact ce ați avut nevoie cu adevărat.
Ar părea că este un lucru destul de evident, dar de mai multe ori am întâlnit în practica mea situații în care firmele au început să se bazeze pe providerul lor de hosting puțin mai mult decât ar fi trebuit, și asta nu a dus la nimic bun. A trebuit să explic de lungă durată și în detaliu că niciun SLA nu va acoperi pierderile din cauza timpului de nefuncționare (există excepții, dar de obicei sunt foarte, FOARTE scumpe pentru client) și că providerul de hosting nu este deloc la curent cu ce se întâmplă în infrastructura clienților (cu excepția unor indicatori foarte generali). Și nici backup-urile nu sunt realizate de providerul de hosting în locul dumneavoastră. Cu atât mai rău este cazul, dacă aveți mai mult de un provider de hosting. În caz de probleme între ei, cu siguranță nu vor încerca să afle ce anume a mers greșit pentru dumneavoastră.
Motivurile aici sunt exact aceleași ca la alegerea între „echipa proprie de administratori vs externalizare”. Dacă riscurile sunt calculate, calitatea este satisfăcătoare, iar business-ul nu se împotrivește – de ce să nu încerci? Pe de altă parte, rețeaua este unul dintre cele mai fundamentale straturi ale infrastructurii, iar probabil nu merită să fie încredințată unor persoane externe, dacă tot cealaltă parte a infrastructurii este deja gestionată de tine.
În ce cazuri este nevoie de un inginer de rețea?
Mai departe, discutăm exact despre companiile de produse moderne. Cu operatorii și sectorul enterprise totul este mai mult sau mai puțin clar – acolo nu s-au schimbat multe în ultimii ani, iar inginerii de rețea erau necesari înainte, sunt necesari și acum. Însă cu acele „tinere și îndrăznețe” lucrurile nu sunt atât de simple. De multe ori, își plasează întreaga infrastructură în cloud-uri, așa că nici măcar administratori nu le sunt foarte necesari – cu excepția administratorilor cloud-urilor, desigur. Infrastructura, pe de o parte, este destul de simplă în ceea ce privește structura sa, pe de altă parte – bine automatizată (ansible/puppet, terraform, ci/cd… știi tu). Dar chiar și aici există situații în care nu te poți descurca fără un inginer de rețea.
Exemplu 1, clasic
Să presupunem că o companie începe cu un singur server cu o adresă IP publică, care se află într-un centru de date. Apoi serverele devin două. Apoi mai multe... Mai devreme sau mai târziu, apare necesitatea unei rețele private între servere. Deoarece traficul „extern” este limitat atât în lățime (nu mai mult de 100 Mbit/s, de exemplu), cât și în volumul descărcat/trimis pe lună (la diferiți furnizori de hosting sunt diferite tarife, dar lățimea către lumea exterioară este, de obicei, mult mai scumpă decât rețeaua privată).
Furnizorul de hosting adaugă plăci de rețea suplimentare în servere și le conectează în comutatoarele sale într-un VLAN separat. Între servere apare o rețea internă „plată”. Convenabil!
Numărul de servere crește, traficul din rețeaua privată de asemenea — backup-uri, replicări și așa mai departe. Furnizorul de hosting oferă să vă separe în comutatoare separate, astfel încât să nu deranjați alți clienți, iar ei să nu vă deranjeze pe dumneavoastră. Furnizorul instalează unele comutatoare și le configurează într-un fel — cel mai probabil, lăsând între toate serverele dumneavoastră o rețea plată. Totul funcționează bine, dar la un moment dat apar probleme: întârzierile între gazde cresc periodic, în jurnale apar erori din cauza numărului prea mare de pachete ARP pe secundă, iar un tester de penetrare în timpul auditului a avut acces la întreaga dumneavoastră rețea locală, având ca rezultat doar un server compromis.
Ce trebuie să faceți?
Să împărțiți rețeaua în segmente — VLAN-uri. Să configurați în fiecare VLAN adresarea proprie, alocând un gateway care va redirecționa traficul între rețele. Pe gateway să configurați ACL pentru a limita accesul între segmente, sau să plasați un firewall separat.
Exemplul 1, continuare
Serverele sunt conectate la rețeaua locală cu un singur cablu. Comutatoarele din rack-uri sunt conectate între ele, dar în cazul unei defecțiuni într-un rack, alte trei racking-uri învecinate se deconectează. Schemele există, dar există îndoieli cu privire la relevanța lor. Fiecare server are propria adresă IP publică, oferită de furnizorul de hosting, și legată de rack. Asta înseamnă că, la relocarea serverului, trebuie să schimbați adresa.
Ce trebuie să faceți?
Conectați serverele prin LAG (Link Aggregation Group) cu două cabluri la comutatoarele din rack (acestea trebuie de asemenea rezervate). Conexiunile între rack-uri trebuie rezervate, reproiectate în modelul „stea” (sau popularul CLOS) pentru a nu afecta celelalte rack-uri în cazul căderii unui rack. Alocați rack-uri „centrale” în care va fi situat nucleul rețelei, și la care se vor conecta celelalte rack-uri. De asemenea, aranjați adresa publică, obținând de la furnizorul de internet (sau de la RIR, dacă este posibil) un subnet pe care să-l anunțați singuri (sau prin furnizorul de hosting) în lume.
Poate un „administrator obișnuit” să facă toate acestea, fără cunoștințe profunde în rețele? Nu sunt sigur. Va face furnizorul de hosting asta? Poate, dar va fi nevoie de un caiet de sarcini destul de detaliat, care trebuie, de asemenea, redactat de cineva. Apoi, trebuie să verificați că totul a fost realizat corect.
Exemplul 2. Cloud
Să presupunem că aveți un VPC în vreun nor public. Pentru a accesa rețeaua locală din birou sau din partea on-prem a infrastructurii către rețeaua internă a VPC-ului, trebuie să configurați o conexiune prin IPSec sau un canal dedicat. Pe de o parte, IPSec este mai ieftin, deoarece nu trebuie să cumpărați hardware suplimentar, puteți configura un tunel între serverul dvs. cu adresă publică și nor. Dar apar întârzieri, performanță limitată (deoarece canalul trebuie criptat), plus conectivitate nesigură (deoarece accesul se face prin internetul obișnuit).
Ce trebuie să faceți?
Stabiliți o conexiune prin canal dedicat (de exemplu, la AWS se numește Direct Connect). Pentru aceasta, găsiți un partener operator care să vă conecteze, decideți asupra celui mai apropiat punct de intrare pentru dvs. (atât operatorului față de dvs., cât și operatorului față de nor), și, în cele din urmă, configurați totul. Este posibil să faceți totul asta fără un inginer de rețea? Cu siguranță, da. Dar cum să rezolvați problemele fără el, nu este la fel de clar.
În plus, pot apărea probleme cu disponibilitatea între nori (dacă aveți multicloud) sau probleme cu întârzierile între diferite regiuni etc. Fără îndoială, acum există multe unelte care sporește transparența a ceea ce se întâmplă în nor (precum Thousand Eyes), dar toate acestea sunt unelte pentru inginerii de rețea, nu un substitut pentru ei.
Aș putea adăuga încă o duzină de astfel de exemple din practica mea, dar cred că este clar că în echipă, începând cu un anumit nivel de dezvoltare a infrastructurii, trebuie să existe o persoană (sau mai bine, mai multe) care știe cum funcționează rețeaua, poate configura echipamentele de rețea și să rezolve problemele dacă acestea apar. Credeți-mă, va avea destul de lucru.
Ce trebuie să știe un inginer de rețea?
Nu este deloc necesar (și uneori, chiar dăunător), ca un inginer de rețea să se ocupe doar de rețea și de nimic altceva. Chiar și fără a lua în considerare varianta cu infrastructura care trăiește aproape în întregime în norul public (ceea ce devine tot mai popular), să luăm de exemplu soluțiile on-premise sau norii privați, unde cunoștințele de bază la nivel CCNP nu sunt suficiente.
Pe lângă rețele, există un câmp nesfârșit de studiu, chiar dacă ne concentrăm doar pe un singur domeniu (rețelele de furnizor, întreprindere, centre de date, wifi...)
Desigur, mulți dintre voi vă veți aminti acum de Python și de alte soluții de „automare a rețelei”, dar aceasta este doar o condiție necesară, dar nu suficientă. Pentru ca un inginer de rețea să „se integreze cu succes în echipă”, trebuie să fie capabil să comunice pe aceeași lungime de undă atât cu dezvoltatorii, cât și cu colegii administratori/devops. Ce înseamnă asta?
- să știe nu doar să lucreze în Linux ca utilizator, ci și să-l administreze, cel puțin la nivel de administrator junior: să instaleze software-ul necesar, să repornească un serviciu căzut, să scrie un unit systemd simplu.
- să înțeleagă (cel puțin în linii mari) cum funcționează stiva de rețea în Linux, cum este organizată rețeaua în hypervizori și containere (lxc / docker / kubernetes).
- Desigur, trebuie să fie capabil să lucreze cu ansible/chef/puppet sau cu un alt sistem SCM.
- Un aspect aparte trebuie menționat despre SDN și rețelele pentru clouduri private (de exemplu, TungstenFabric sau OpenvSwitch). Aceasta este o altă vastă arie de cunoștințe.
Într-o formulare concisă, am descris specialistul tipic T-shape (așa cum se spune acum). Nu pare nimic nou, totuși, din experiența interviurilor, nu toți inginerii de rețea pot să se laude că au cunoștințe în cel puțin două dintre temele enumerate mai sus. În practică, lipsa cunoștințelor „în domenii adiacente” îngreunează foarte mult nu doar comunicarea cu colegii, ci și înțelegerea cerințelor pe care afacerea le are față de rețea, ca cea mai de bază infrastructură a proiectului. Fără această înțelegere, devine mai dificil să-ți susții argumentat punctul de vedere și să-l „vinzi” afacerii.
Pe de altă parte, obiceiul de a „înțelege cum funcționează sistemul” le oferă rețeliștilor un avantaj considerabil față de diferiți „specialiști cu profil larg”, care știu despre tehnologii din articole de pe Habr/Medium și grupuri de discuții în Telegram, dar nu au nicio idee despre principiile de funcționare ale unui anumit software. Și cunoașterea anumitor regularități, cum se știe, poate înlocui cu succes cunoașterea unui număr mare de fapte.
Concluzii sau pur și simplu TL;DR
- Un administrator de rețea (la fel ca și un DBA sau inginer VoIP) este un specialist destul de specific (spre deosebire de sysadmini/devops/SRE), a cărui nevoie nu apare imediat (și poate să nu apară mult timp, de fapt). Dar, atunci când apare, este puțin probabil să poți înlocui expertiza externă (outsourcing sau administratori obișnuiți care „își supraveghează și rețeaua”). Ce este un pic mai trist - nevoia de astfel de specialiști este mică, iar, în termenii relativi, într-o companie cu 800 de programatori și 30 de devops/admini, ar putea exista doar doi rețelari care fac foarte bine treaba lor. Asta înseamnă că piața a fost și este extrem de mică, iar pentru salarii bune - chiar mai mică.
- Pe de altă parte, un bun rețelar în lumea modernă trebuie să știe nu doar despre rețele (și cum să automatizeze configurarea acestora), ci și cum interacționează cu ele sistemele de operare și software-ul care rulează pe acele rețele. Fără aceste cunoștințe, va fi extrem de dificil să înțelegi ce îți cer colegii și să transmiți (justificat) dorințele/cerințele tale către ei.
- Nu există cloud, este doar un computer al cuiva. Trebuie să înțelegi că utilizarea cloud-urilor publice/private sau a serviciilor furnizorilor de hosting „care îți fac totul la cheie” nu anulează faptul că aplicația ta folosește încă rețeaua, iar problemele legate de aceasta vor influența funcționarea aplicației tale. Alegerile tale - unde va fi centrul de competență care va răspunde de rețeaua proiectului tău.
Sursa: habr.com
