{"id":97373,"date":"2020-10-17T14:42:32","date_gmt":"2020-10-17T12:42:32","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/seteviki-ne-nuzhny"},"modified":"2020-10-17T14:42:32","modified_gmt":"2020-10-17T12:42:32","slug":"seteviki-ne-nuzhny","status":"publish","type":"post","link":"https:\/\/prohoster.info\/ro\/blog\/administrirovanie\/seteviki-ne-nuzhny","title":{"rendered":"Re\u021belele (nu) sunt necesare","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

La momentul scrierii acestui articol, c\u0103utarea pe un site de munc\u0103 popular cu expresia \u201eInginer de re\u021bea\u201d returna aproximativ trei sute de locuri de munc\u0103 \u00een toat\u0103 Rusia. Ca \u0219i compara\u021bie, c\u0103utarea cu fraza \u201eadministrator de sistem\u201d afi\u0219a aproape 2.5 mii de locuri de munc\u0103, iar \u201eInginer DevOps\u201d \u2014 aproape 800.<\/p>\n

\u00censeamn\u0103 asta c\u0103 re\u021belele nu mai sunt necesare \u00een vremurile norilor, Docker, Kubernetes \u0219i a publicului wifi omniprezent?
\nHai s\u0103 ne l\u0103murim (c)<\/p>\n

\"Re\u021belele
\n<\/a><\/noindex>
\nHai s\u0103 ne cunoa\u0219tem. M\u0103 numesc Alexei, \u0219i sunt specialist \u00een re\u021bele. <\/p>\n

Am lucrat mai mult de 10 ani \u00een re\u021bele \u0219i mai mult de 15 ani cu diverse sisteme *nix (m-am ocupat de Linux \u0219i FreeBSD). Am lucrat pentru operatori de telecomunica\u021bii, mari companii considerate \u201eenterprise\u201d, iar \u00een ultima vreme lucrez \u00eentr-un fintech \u201et\u00e2n\u0103r \u0219i \u00eendr\u0103zne\u021b\u201d, unde norii, devops, kubernetes \u0219i alte cuvinte \u00eenfrico\u0219\u0103toare care cu siguran\u021b\u0103 m\u0103 vor face pe mine \u0219i colegii mei s\u0103 devenim inutili. C\u00e2ndva. Poate.<\/p>\n

disclaimer: \u201e\u00cen via\u021ba noastr\u0103, nu totul, \u00eentotdeauna \u0219i pretutindeni, iar unele lucruri, uneori \u0219i pe alocuri\u201d (c) Maxim Dorofeev.<\/p>\n

Tot ce este scris mai jos poate \u0219i trebuie considerat opinia personal\u0103 a autorului, care nu \u00ee\u0219i pretinde adev\u0103rul absolut, \u0219i chiar nu se pretinde a fi o cercetare complet\u0103. Toate personajele sunt fictive, toate coinciden\u021bele sunt \u00eent\u00e2mpl\u0103toare.<\/p><\/blockquote>\n

Bine ai venit \u00een lumea mea.<\/p>\n

Unde pot fi \u00eent\u00e2lni\u021bi de fapt speciali\u0219tii \u00een re\u021bele?<\/h3>\n

\n1. Operatorii de telecomunica\u021bii, companiile de servicii \u0219i al\u021bi integratori<\/b>. Aici este simplu: re\u021beaua pentru ei este afacerea. Ei v\u00e2nd fie conectivitate direct (operatorii), fie ofer\u0103 servicii de lansare\/\u00eentre\u021binere a re\u021belelor clien\u021bilor lor. <\/p>\n

Exist\u0103 multe experien\u021be aici, dar nu prea mul\u021bi bani (dac\u0103 nu e\u0219ti director sau un manager de v\u00e2nz\u0103ri de succes). Cu toate acestea, dac\u0103 \u00ee\u021bi plac re\u021belele \u0219i e\u0219ti doar la \u00eenceput de drum, o carier\u0103 \u00een suportul unui operator nu foarte mare va fi, chiar \u0219i acum, un punct ideal de plecare (la operatorii mari, totul este foarte scriptat \u0219i exist\u0103 pu\u021bin spa\u021biu pentru creativitate). De asemenea, pove\u0219tile despre cum po\u021bi ajunge de la inginer de suport la manager C-level \u00een c\u00e2\u021biva ani sunt de asemenea foarte reale, de\u0219i rare, din motive evidente. Cererea de personal exist\u0103 \u00eentotdeauna, deoarece, \u00eentr-adev\u0103r, exist\u0103 fluctua\u021bii de personal. Acest lucru este at\u00e2t bun, c\u00e2t \u0219i r\u0103u \u00een acela\u0219i timp \u2014 exist\u0103 \u00eentotdeauna locuri de munc\u0103 disponibile, dar, pe de alt\u0103 parte, cei mai activi\/inteligenti pleac\u0103 destul de repede, fie pentru o promovare, fie c\u0103tre alte locuri de munc\u0103 mai \u201ec\u00e2\u0219tig\u0103toare\u201d.<\/p>\n

2. Condi\u021bional \u201eenterprise\u201d<\/b>. Indiferent dac\u0103 activitatea principal\u0103 este legat\u0103 de IT sau nu. Cheia este c\u0103 exist\u0103 un departament IT care se ocup\u0103 de func\u021bionarea sistemelor interne ale companiei, inclusiv re\u021belele din birouri, canalele de comunica\u021bie c\u0103tre filiale etc. Func\u021biile inginerului de re\u021bea \u00een astfel de companii pot fi \u00eendeplinite \u201e\u00een paralel\u201d de un administrator de sistem (dac\u0103 infrastructura re\u021belei este mic\u0103 sau este gestionat\u0103 de un contractor extern), iar inginerul de re\u021bea, dac\u0103 este prezent, poate supraveghea de asemenea telefonia \u0219i SAN (f\u0103r\u0103 prea multe detalii). Salariile variaz\u0103 considerabil \u2014 depind mult de marja de profit a afacerii, de dimensiunea companiei \u0219i de structur\u0103. Am lucrat at\u00e2t cu companii care au \u201e\u00eenc\u0103rcat\u201d echipamente Cisco, c\u00e2t \u0219i cu companii care au construit re\u021bele din resturi, be\u021be \u0219i band\u0103 izolatoare albastr\u0103, iar serverele nu au fost actualizate niciodat\u0103 (nu trebuie s\u0103 spun c\u0103 nu existau rezerve planificate). Experien\u021ba \u00een acest domeniu este mult mai mic\u0103 \u0219i, \u00een mod aproape sigur, va fi \u00een domeniul unei rigidit\u0103\u021bi severe a vendor-lock-ului sau \u201ecum s\u0103 faci ceva din nimic\u201d. Personal, mi s-a p\u0103rut extrem de plictisitor, de\u0219i multora le place \u2014 totul este destul de ritmic \u0219i previzibil (dac\u0103 vorbim despre companii mari), \u201etotul \u00een ordine\u201d etc. Nu mai pu\u021bin de o dat\u0103 pe an, un mare furnizor anun\u021b\u0103 c\u0103 a inventat un nou sistem mega-super-pu\u021bin care va automatiza tot \u0219i to\u021bi administratorii de sistem \u0219i inginerii de re\u021bea vor putea fi concedia\u021bi, l\u0103s\u00e2nd c\u00e2\u021biva pentru a ap\u0103sa pe butoane \u00een interfa\u021ba frumoas\u0103. Realitatea este c\u0103, chiar dac\u0103 ignor\u0103m costul solu\u021biei, inginerii de re\u021bea nu vor disp\u0103rea. Da, este posibil ca \u00een loc de consol\u0103 s\u0103 avem din nou o interfa\u021b\u0103 web (dar nu pentru un echipament specific, ci pentru un sistem mare care gestioneaz\u0103 zeci sau sute de astfel de echipamente), dar cuno\u0219tin\u021bele despre \u201ecum func\u021bioneaz\u0103 totul \u00een interior\u201d vor fi totu\u0219i necesare.<\/p>\n

3. Companii de produse<\/b>, a c\u0103rei profitabilitate provine din dezvoltarea (\u0219i, adesea, din exploatarea) unui software sau platform\u0103 \u2014 acel produs. De obicei, sunt mici \u0219i agile, av\u00e2nd \u00eenc\u0103 mult de parcurs p\u00e2n\u0103 la dimensiunea \u00eentreprinderilor \u0219i birocra\u021bia acestora. Anume aici \u00ee\u0219i g\u0103sesc loc acei devops, kubernetes, docker \u0219i alte cuvinte \u00eenfrico\u0219\u0103toare care vor face re\u021belele \u0219i inginerii de re\u021bea un relicvar inutil. <\/p>\n

Cum se deosebe\u0219te un inginer de re\u021bea de un administrator de sistem?<\/h3>\n

\n\u00cen \u00een\u021belegerea oamenilor din afara IT-ului \u2014 nu este nimic. At\u00e2t unul, c\u00e2t \u0219i cel\u0103lalt se uit\u0103 la un ecran \u00eentunecat \u0219i tasteaz\u0103 diverse vr\u0103ji, uneori \u00eenjur\u00e2nd \u00een \u0219oapt\u0103. <\/p>\n

\u00cen viziunea programatorilor, este mai mult o problem\u0103 de domeniu. Administratorii de sistem administreaz\u0103 serverele, iar cei de re\u021bea administreaz\u0103 switch-urile \u0219i routerele. Uneori, o fac prost \u0219i totul se pr\u0103bu\u0219e\u0219te. \u00cen cazul \u00een care se \u00eent\u00e2mpl\u0103 ceva ciudat, re\u021beli\u0219tii sunt \u0219i ei pe list\u0103. Just because fuck you, that\u2019s why.<\/p>\n

De fapt, principalul diferen\u021bator este abordarea fa\u021b\u0103 de munc\u0103. Probabil c\u0103 printre re\u021beli\u0219ti exist\u0103 cei mai mul\u021bi sus\u021bin\u0103tori ai principiului \u201eDac\u0103 func\u021bioneaz\u0103, nu atinge!\u201d. O anumit\u0103 sarcin\u0103 (\u00een cadrul unui singur furnizor) poate fi realizat\u0103, de obicei, doar \u00eentr-un singur mod, \u00eentreaga configura\u021bie a echipamentului \u2014 iat\u0103-o, la \u00eendem\u00e2n\u0103. Pre\u021bul unei erori \u2014 ridicat, uneori chiar foarte ridicat (de exemplu, va trebui s\u0103 c\u0103l\u0103tori\u021bi c\u00e2teva sute de kilometri pentru a reporni un router, iar \u00een acest timp c\u00e2teva mii de oameni vor r\u0103m\u00e2ne f\u0103r\u0103 conexiune \u2014 o situa\u021bie obi\u0219nuit\u0103 pentru un operator de telecomunica\u021bii).<\/p>\n

Din punctul meu de vedere, acesta este motivul pentru care inginerii de re\u021bea, pe de o parte, sunt extrem de motiva\u021bi s\u0103 men\u021bin\u0103 stabilitatea re\u021belei (iar schimb\u0103rile sunt principalul du\u0219man al stabilit\u0103\u021bii), iar pe de alt\u0103 parte, cuno\u0219tin\u021bele lor merg mai ad\u00e2nc dec\u00e2t l\u0103\u021bimea (nu trebuie s\u0103 \u0219tii cum s\u0103 configurezi zeci de demoni diferi\u021bi, trebuie s\u0103 cuno\u0219ti tehnologiile \u0219i implementarea acestora de c\u0103tre produc\u0103torul de echipamente specific). De aceea, un admin de sistem care a c\u0103utat pe Google cum s\u0103 configureze un VLAN pe Cisco \u2014 nu este neap\u0103rat un re\u021belist. \u0218i cu greu va putea sus\u021bine eficient (\u0219i, de asemenea, rezolva problemele) o re\u021bea relativ complex\u0103. <\/p>\n

Dar de ce ai nevoie de un re\u021belist, dac\u0103 ai hoster<\/a>?<\/b><\/p>\n

Pentru o sum\u0103 suplimentar\u0103 (iar dac\u0103 e\u0219ti un client foarte mare \u0219i apreciat \u2014 poate chiar gratuit, \u201epe prietenie\u201d) inginerii centrului de date \u00ee\u021bi vor configura comutatoarele conform necesit\u0103\u021bilor tale \u0219i, poate, chiar te vor ajuta s\u0103 ridici un peering BGP cu furnizorii (dac\u0103 ai o subre\u021bea de adrese IP<\/a> pentru anun\u021b).<\/p>\n

Problema principal\u0103 este c\u0103 centrul de date nu este departamentul dumneavoastr\u0103 IT, ci o companie separat\u0103, ale c\u0103rei scopuri sunt s\u0103 genereze profit. Acest lucru include \u0219i profitul de la dumneavoastr\u0103, ca \u0219i client. Centrul de date ofer\u0103 rack-uri, le asigur\u0103 cu electricitate \u0219i r\u0103cire, precum \u0219i furnizeaz\u0103 o anumit\u0103 \u201econectivitate default\u201d la internet. Pe baza acestei infrastructuri, centrul de date poate g\u0103zdui echipamentul dumneavoastr\u0103 (colocation), s\u0103 v\u0103 \u00eenchirieze un server (dedicated server) sau s\u0103 ofere un serviciu gestionat (de exemplu, OpenStack sau K8s). \u00cens\u0103, administrarea infrastructurii clien\u021bilor nu este, de obicei, activitatea principal\u0103 a centrului de date, deoarece acest proces este destul de consumator de resurse, greu de automatizat (iar \u00eentr-un centru de date normal, tot ce poate fi automatizat este automatizat), mai pu\u021bin standardizat (fiecare client este unic) \u0219i \u00een general duce la reclama\u021bii (\u201emi-a\u021bi configurat serverul, iar acum a c\u0103zut, voi sunte\u021bi vinova\u021bi!!!111\u201d). A\u0219adar, dac\u0103 providerul de hosting va ajuta cu ceva, se va str\u0103dui s\u0103 fac\u0103 acest lucru c\u00e2t mai simplu \u0219i \u201ebasic\u201d. Pentru c\u0103 a face lucrurile complicate nu este rentabil, cel pu\u021bin din perspectiva eforturilor inginerilor acelui provider de hosting (dar situa\u021biile pot varia, vezi disclaimer). Aceasta nu \u00eenseamn\u0103 c\u0103 providerul de hosting va face neap\u0103rat totul prost. Dar nu este deloc sigur c\u0103 va face exact ce a\u021bi avut nevoie cu adev\u0103rat.<\/p>\n

Ar p\u0103rea c\u0103 este un lucru destul de evident, dar de mai multe ori am \u00eent\u00e2lnit \u00een practica mea situa\u021bii \u00een care firmele au \u00eenceput s\u0103 se bazeze pe providerul lor de hosting pu\u021bin mai mult dec\u00e2t ar fi trebuit, \u0219i asta nu a dus la nimic bun. A trebuit s\u0103 explic de lung\u0103 durat\u0103 \u0219i \u00een detaliu c\u0103 niciun SLA nu va acoperi pierderile din cauza timpului de nefunc\u021bionare (exist\u0103 excep\u021bii, dar de obicei sunt foarte, FOARTE scumpe pentru client) \u0219i c\u0103 providerul de hosting nu este deloc la curent cu ce se \u00eent\u00e2mpl\u0103 \u00een infrastructura clien\u021bilor (cu excep\u021bia unor indicatori foarte generali). \u0218i nici backup-urile nu sunt realizate de providerul de hosting \u00een locul dumneavoastr\u0103. Cu at\u00e2t mai r\u0103u este cazul, dac\u0103 ave\u021bi mai mult de un provider de hosting. \u00cen caz de probleme \u00eentre ei, cu siguran\u021b\u0103 nu vor \u00eencerca s\u0103 afle ce anume a mers gre\u0219it pentru dumneavoastr\u0103.<\/p>\n

Motivurile aici sunt exact acelea\u0219i ca la alegerea \u00eentre \u201eechipa proprie de administratori vs externalizare\u201d. Dac\u0103 riscurile sunt calculate, calitatea este satisf\u0103c\u0103toare, iar business-ul nu se \u00eempotrive\u0219te \u2013 de ce s\u0103 nu \u00eencerci? Pe de alt\u0103 parte, re\u021beaua este unul dintre cele mai fundamentale straturi ale infrastructurii, iar probabil nu merit\u0103 s\u0103 fie \u00eencredin\u021bat\u0103 unor persoane externe, dac\u0103 tot cealalt\u0103 parte a infrastructurii este deja gestionat\u0103 de tine.<\/p>\n

\u00cen ce cazuri este nevoie de un inginer de re\u021bea?<\/b><\/p>\n

Mai departe, discut\u0103m exact despre companiile de produse moderne. Cu operatorii \u0219i sectorul enterprise totul este mai mult sau mai pu\u021bin clar \u2013 acolo nu s-au schimbat multe \u00een ultimii ani, iar inginerii de re\u021bea erau necesari \u00eenainte, sunt necesari \u0219i acum. \u00cens\u0103 cu acele \u201etinere \u0219i \u00eendr\u0103zne\u021be\u201d lucrurile nu sunt at\u00e2t de simple. De multe ori, \u00ee\u0219i plaseaz\u0103 \u00eentreaga infrastructur\u0103 \u00een cloud-uri, a\u0219a c\u0103 nici m\u0103car administratori nu le sunt foarte necesari \u2013 cu excep\u021bia administratorilor cloud-urilor, desigur. Infrastructura, pe de o parte, este destul de simpl\u0103 \u00een ceea ce prive\u0219te structura sa, pe de alt\u0103 parte \u2013 bine automatizat\u0103 (ansible\/puppet, terraform, ci\/cd\u2026 \u0219tii tu). Dar chiar \u0219i aici exist\u0103 situa\u021bii \u00een care nu te po\u021bi descurca f\u0103r\u0103 un inginer de re\u021bea.<\/p>\n

Exemplu 1, clasic<\/b><\/p>\n

S\u0103 presupunem c\u0103 o companie \u00eencepe cu un singur server cu o adres\u0103 IP public\u0103, care se afl\u0103 \u00eentr-un centru de date. Apoi serverele devin dou\u0103. Apoi mai multe... Mai devreme sau mai t\u00e2rziu, apare necesitatea unei re\u021bele private \u00eentre servere. Deoarece traficul \u201eextern\u201d este limitat at\u00e2t \u00een l\u0103\u021bime (nu mai mult de 100 Mbit\/s, de exemplu), c\u00e2t \u0219i \u00een volumul desc\u0103rcat\/trimis pe lun\u0103 (la diferi\u021bi furnizori de hosting sunt diferite tarife, dar l\u0103\u021bimea c\u0103tre lumea exterioar\u0103 este, de obicei, mult mai scump\u0103 dec\u00e2t re\u021beaua privat\u0103).<\/p>\n

Furnizorul de hosting adaug\u0103 pl\u0103ci de re\u021bea suplimentare \u00een servere \u0219i le conecteaz\u0103 \u00een comutatoarele sale \u00eentr-un VLAN separat. \u00centre servere apare o re\u021bea intern\u0103 \u201eplat\u0103\u201d. Convenabil!<\/p>\n

Num\u0103rul de servere cre\u0219te, traficul din re\u021beaua privat\u0103 de asemenea \u2014 backup-uri, replic\u0103ri \u0219i a\u0219a mai departe. Furnizorul de hosting ofer\u0103 s\u0103 v\u0103 separe \u00een comutatoare separate, astfel \u00eenc\u00e2t s\u0103 nu deranja\u021bi al\u021bi clien\u021bi, iar ei s\u0103 nu v\u0103 deranjeze pe dumneavoastr\u0103. Furnizorul instaleaz\u0103 unele comutatoare \u0219i le configureaz\u0103 \u00eentr-un fel \u2014 cel mai probabil, l\u0103s\u00e2nd \u00eentre toate serverele dumneavoastr\u0103 o re\u021bea plat\u0103. Totul func\u021bioneaz\u0103 bine, dar la un moment dat apar probleme: \u00eent\u00e2rzierile \u00eentre gazde cresc periodic, \u00een jurnale apar erori din cauza num\u0103rului prea mare de pachete ARP pe secund\u0103, iar un tester de penetrare \u00een timpul auditului a avut acces la \u00eentreaga dumneavoastr\u0103 re\u021bea local\u0103, av\u00e2nd ca rezultat doar un server compromis.<\/p>\n

Ce trebuie s\u0103 face\u021bi?<\/i><\/p>\n

\u00cemp\u0103r\u021birea re\u021belei \u00een segmente \u2014 VLAN-uri. Seta\u021bi \u00een fiecare VLAN propria adresare, aloca\u021bi un gateway care va redirec\u021biona traficul \u00eentre re\u021bele. Configura\u021bi o ACL pe gateway pentru a limita accesul \u00eentre segmente sau plasa\u021bi un firewall separat.<\/p>\n

Exemplul 1, continuare<\/b><\/p>\n

Serverele sunt conectate la re\u021beaua local\u0103 cu un singur cablu. Comutatoarele din rack-uri sunt conectate \u00eentre ele, dar \u00een cazul unei defec\u021biuni \u00eentr-un rack, alte trei racking-uri \u00eenvecinate se deconecteaz\u0103. Schemele exist\u0103, dar exist\u0103 \u00eendoieli cu privire la relevan\u021ba lor. Fiecare server are propria adres\u0103 IP public\u0103, oferit\u0103 de furnizorul de hosting, \u0219i legat\u0103 de rack. Asta \u00eenseamn\u0103 c\u0103, la relocarea serverului, trebuie s\u0103 schimba\u021bi adresa.<\/p>\n

Ce trebuie s\u0103 face\u021bi?<\/i><\/p>\n

Conecta\u021bi serverele prin LAG (Link Aggregation Group) cu dou\u0103 cabluri la comutatoarele din rack (acestea trebuie de asemenea rezervate). Conexiunile \u00eentre rack-uri trebuie rezervate, reproiectate \u00een modelul \u201estea\u201d (sau popularul CLOS) pentru a nu afecta celelalte rack-uri \u00een cazul c\u0103derii unui rack. Aloca\u021bi rack-uri \u201ecentrale\u201d \u00een care va fi situat nucleul re\u021belei, \u0219i la care se vor conecta celelalte rack-uri. De asemenea, aranja\u021bi adresa public\u0103, ob\u021bin\u00e2nd de la furnizorul de internet (sau de la RIR, dac\u0103 este posibil) un subnet pe care s\u0103-l anun\u021ba\u021bi singuri (sau prin furnizorul de hosting) \u00een lume.<\/p>\n

Poate un \u201eadministrator obi\u0219nuit\u201d s\u0103 fac\u0103 toate acestea, f\u0103r\u0103 cuno\u0219tin\u021be profunde \u00een re\u021bele? 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\u0103 verifica\u021bi c\u0103 totul a fost realizat corect.<\/p>\n

Exemplul 2. Cloud<\/b><\/p>\n

S\u0103 presupunem c\u0103 ave\u021bi un VPC \u00een vreun nor public. Pentru a accesa re\u021beaua local\u0103 din birou sau din partea on-prem a infrastructurii c\u0103tre re\u021beaua intern\u0103 a VPC-ului, trebuie s\u0103 configura\u021bi o conexiune prin IPSec sau un canal dedicat. Pe de o parte, IPSec este mai ieftin, deoarece nu trebuie s\u0103 cump\u0103ra\u021bi hardware suplimentar, pute\u021bi configura un tunel \u00eentre serverul dvs. cu adres\u0103 public\u0103 \u0219i nor. Dar apar \u00eent\u00e2rzieri, performan\u021b\u0103 limitat\u0103 (deoarece canalul trebuie criptat), plus conectivitate nesigur\u0103 (deoarece accesul se face prin internetul obi\u0219nuit). <\/p>\n

Ce trebuie s\u0103 face\u021bi?<\/i><\/p>\n

Stabili\u021bi o conexiune prin canal dedicat (de exemplu, la AWS se nume\u0219te Direct Connect). Pentru aceasta, g\u0103si\u021bi un partener operator care s\u0103 v\u0103 conecteze, decide\u021bi asupra celui mai apropiat punct de intrare pentru dvs. (at\u00e2t operatorului fa\u021b\u0103 de dvs., c\u00e2t \u0219i operatorului fa\u021b\u0103 de nor), \u0219i, \u00een cele din urm\u0103, configura\u021bi totul. Este posibil s\u0103 face\u021bi totul asta f\u0103r\u0103 un inginer de re\u021bea? Cu siguran\u021b\u0103, da. Dar cum s\u0103 rezolva\u021bi problemele f\u0103r\u0103 el, nu este la fel de clar. <\/p>\n

\u00cen plus, pot ap\u0103rea probleme cu disponibilitatea \u00eentre nori (dac\u0103 ave\u021bi multicloud) sau probleme cu \u00eent\u00e2rzierile \u00eentre diferite regiuni etc. F\u0103r\u0103 \u00eendoial\u0103, acum exist\u0103 multe unelte care spore\u0219te transparen\u021ba a ceea ce se \u00eent\u00e2mpl\u0103 \u00een nor (precum Thousand Eyes), dar toate acestea sunt unelte pentru inginerii de re\u021bea, nu un substitut pentru ei.<\/p>\n

A\u0219 putea ad\u0103uga \u00eenc\u0103 o duzin\u0103 de astfel de exemple din practica mea, dar cred c\u0103 este clar c\u0103 \u00een echip\u0103, \u00eencep\u00e2nd cu un anumit nivel de dezvoltare a infrastructurii, trebuie s\u0103 existe o persoan\u0103 (sau mai bine, mai multe) care \u0219tie cum func\u021bioneaz\u0103 re\u021beaua, poate configura echipamentele de re\u021bea \u0219i s\u0103 rezolve problemele dac\u0103 acestea apar. Crede\u021bi-m\u0103, va avea destul de lucru. <\/p>\n

Ce trebuie s\u0103 \u0219tie un inginer de re\u021bea?<\/b><\/p>\n

Nu este deloc necesar (\u0219i uneori, chiar d\u0103un\u0103tor), ca un inginer de re\u021bea s\u0103 se ocupe doar de re\u021bea \u0219i de nimic altceva. Chiar \u0219i f\u0103r\u0103 a lua \u00een considerare varianta cu infrastructura care tr\u0103ie\u0219te aproape \u00een \u00eentregime \u00een norul public (ceea ce devine tot mai popular), s\u0103 lu\u0103m de exemplu solu\u021biile on-premise sau norii priva\u021bi, unde cuno\u0219tin\u021bele de baz\u0103 la nivel CCNP nu sunt suficiente. <\/p>\n

Pe l\u00e2ng\u0103 re\u021belele \u00een sine \u2014 de\u0219i aici exist\u0103 un c\u00e2mp vast de studiu, chiar \u0219i dac\u0103 ne concentr\u0103m doar pe o singur\u0103 direc\u021bie (re\u021bele de furnizor, \u00eentreprinderi, centre de date, Wi-Fi...)<\/p>\n

Desigur, mul\u021bi dintre voi v\u0103 ve\u021bi aminti acum de Python \u0219i de alte solu\u021bii de \u201eautomare a re\u021belei\u201d, dar aceasta este doar o condi\u021bie necesar\u0103, dar nu suficient\u0103. Pentru ca un inginer de re\u021bea s\u0103 \u201ese integreze cu succes \u00een echip\u0103\u201d, trebuie s\u0103 fie capabil s\u0103 comunice pe aceea\u0219i lungime de und\u0103 at\u00e2t cu dezvoltatorii, c\u00e2t \u0219i cu colegii administratori\/devops. Ce \u00eenseamn\u0103 asta?<\/p>\n