U vreme pisanja ovog teksta, pretraga na popularnom sajtu za posao za frazom „Inženjer mreže“ dala je oko tri stotine slobodnih radnih mesta širom Rusije. Poređenja radi, pretraga za izrazom "administrator sistema" vraća skoro 2.5 hiljade slobodnih radnih mjesta, a "DevOps inženjer" - skoro 800.
Znači li to da mrežari više nisu potrebni u danima pobjedničkih oblaka, dockera, kubernetisa i sveprisutnog javnog Wi-Fi-ja?
Hajde da shvatimo (s)
Hajde da se upoznamo. Zovem se Aleksej i bavim se mrežom.
Umrežavanjem se bavim više od 10 godina i radim sa raznim *nix sistemima više od 15 godina (imao sam priliku da izaberem i Linux i FreeBSD). Radio sam u telekom operaterima, velikim kompanijama koje se smatraju “preduzećima”, a odnedavno radim i u “mladom i odvažnom” fintech-u, gdje oblaci, devops, kubernete i druge strašne riječi koje će mene i moje kolege definitivno natjerati nepotrebno. Jednog dana. Možda.
odricanje od odgovornosti: „U našem životu, ne sve, uvek i svuda, već nešto, ponekad na mestima“ (c) Maksim Dorofejev.
Sve što je dolje napisano može se i treba smatrati ličnim mišljenjem autora, a ne pretendirati da je konačna istina, pa čak i punopravna studija. Svi likovi su izmišljeni, sve slučajnosti su nasumične.
Dobrodošli u moj svijet.
Gdje možete pronaći mrežne ljude?
1. Telekom operateri, uslužne kompanije i drugi integratori. Sve je jednostavno: mreža je za njih posao. Oni ili direktno prodaju konekciju (operatore) ili pružaju usluge za pokretanje/održavanje mreža svojih korisnika.
Ovdje ima puno iskustva, ali nema puno novca (osim ako ste direktor ili uspješan menadžer prodaje). Pa ipak, ako volite mreže, a tek ste na početku svog puta, karijera podrške nekom ne baš velikom operateru će i sada biti idealna polazna tačka (u federalnim je sve jako skriptirano, a tamo malo je prostora za kreativnost). Pa, priče o tome da je za nekoliko godina moguće izrasti od dežurnog inženjera do C-level menadžera su također sasvim stvarne, iako rijetke, iz očiglednih razloga. Uvijek postoji potreba za kadrovima, jer i dalje ima fluktuacija. To je i dobro i loše u isto vrijeme - s druge strane uvijek ima slobodnih mjesta - često oni najaktivniji/pametniji dovoljno brzo ili napreduju ili odlaze na druga, "toplija" mjesta.
2. Uslovno "poduzeće". Nije bitno da li je njegova glavna djelatnost vezana za IT ili ne. Glavna stvar je da ima svoj IT odjel, koji se bavi osiguravanjem rada internih sistema kompanije, uključujući mreže u uredima, kanale komunikacije prema filijalama itd. Funkcije mrežnog inženjera u ovakvim kompanijama može „na pola radnog vremena“ obavljati sistem administrator (ako je mrežna infrastruktura mala, ili je na njoj angažovan eksterni izvođač), a menadžer mreže, ako još postoji, može pazite na telefoniju i SAN u isto vrijeme (ne nuacho). Plaćaju na različite načine - to uvelike zavisi od marginalnosti poslovanja, veličine kompanije i strukture. Radio sam sa kompanijama u kojima se cisco redovno „krcao u bačve“, i sa firmama gde je mreža građena od fekalija, štapova i plave selotejp, a serveri nisu ažurirani, otprilike, nikada (potrebno je reći da je bilo nema ni rezervi). Ovdje ima mnogo manje iskustva, a gotovo sigurno će biti u području tvrdog zaključavanja dobavljača ili „kako napraviti nešto ni iz čega“. Lično mi je tamo izgledalo divlje dosadno, iako se to mnogima sviđa - sve je prilično odmjereno i predvidljivo (ako govorimo o velikim kompanijama), "dorah-bajato" itd. Barem jednom godišnje, neki veliki dobavljači kažu da su smislili još jedan mega-super-duper sistem koji sada sve automatizuje i svi sistemski administratori i mrežni ljudi mogu biti overklokovani, ostavljajući nekoliko da pritisnu dugmad u prelepom interfejsu. Realnost je da, čak i ako zanemarimo cijenu rješenja, mrežni radnici odatle neće nikuda ići. Da, moguće je da će umesto konzole ponovo postojati web interfejs (ali ne konkretan komad gvožđa, već veliki sistem koji upravlja desetinama i stotinama takvih komada gvožđa), ali znanje „kako sve funkcioniše unutra ” će i dalje biti potreban.
3. Proizvodne kompanije, čiji profit dolazi od razvoja (a često i rada) nekog softvera ili platforme – baš tog proizvoda. Obično su mali i okretni, još su daleko od obima preduzeća i njihove birokratizacije. Ovdje se ti isti devops, cubers, dockers i druge strašne riječi nalaze u velikom broju koje će sigurno učiniti mreže i mrežne inženjere nepotrebnim rudimentom.
Po čemu se menadžer mreže razlikuje od sysadmina?
U shvaćanju ljudi koji nisu iz IT-a - ništa. Obojica gledaju u crni ekran i pišu neke čini, ponekad tiho psujući.
U razumijevanju programera - možda predmetno područje. Sistemski administratori administriraju servere, mrežni administratori svičeve i rutere. Ponekad je administrator loš, i sve padne svima. Pa, u slučaju bilo kakvog čudnog, krivi su i mrežari. Samo zato što se jebi, eto zašto.
Zapravo, glavna razlika je pristup radu. Možda među mrežarima najviše ima pristalica pristupa "Radi - ne diraj!". Obično možete učiniti nešto (unutar jednog dobavljača) na samo jedan način, cijelu konfiguraciju kutije - evo je, na dlanu. Cijena greške je visoka, a ponekad i vrlo visoka (na primjer, morate putovati nekoliko stotina kilometara da biste ponovo pokrenuli ruter, a u ovom trenutku nekoliko hiljada ljudi će ostati bez komunikacije - situacija koja je prilično uobičajena za telekom operatera ).
Po mom mišljenju, zato su mrežni inženjeri, s jedne strane, izuzetno snažno motivirani za stabilnost mreže (a promjene su glavni neprijatelj stabilnosti), a drugo, njihovo znanje ide više u dubinu nego u širinu (ne treba vam da biste mogli konfigurirati desetine različitih demona, morate znati tehnologije i njihovu implementaciju od određenog proizvođača opreme). Zato administrator sistema, koji je guglao kako da registruje vlan na tsiski, još nije mrežni menadžer. I malo je vjerovatno da će on moći efikasno podržati (kao i riješiti probleme) manje ili više složenu mrežu.
Ali zašto vam treba menadžer mreže ako imate hostera?
Za dodatni novac (a ako ste veoma veliki i voljeni klijent, možda čak i besplatno, "kao prijatelj"), inženjeri data centra će konfigurisati vaše prekidače tako da odgovaraju vašim potrebama, a možda čak i pomoći u podizanju BGP interfejsa sa provajderima (ako imate svoju podmrežu ip adresa za najavu).
Glavni problem je što data centar nije vaše IT odjeljenje, to je posebna kompanija čiji je cilj ostvarivanje profita. Uključujući i na račun Vas kao klijenta. Data centar obezbjeđuje rekove, snabdijeva ih strujom i hladnoćom, a također daje i neku "podrazumevanu" konekciju na Internet. Na osnovu ove infrastrukture, data centar može ko-locirati vašu opremu (kolokacija), iznajmiti vam server (namjenski server) ili pružiti upravljanu uslugu (na primjer, OpenStack ili K8s). Ali posao podatkovnog centra (obično) nije administracija korisničke infrastrukture, jer je ovaj proces prilično radno intenzivan, slabo automatiziran (a u normalnom podatkovnom centru je sve automatizirano), objedinjeno još gore (svaki klijent je individualan) i generalno prepun tvrdnji („rečeš mi da je server postavljen, a sada se srušio, za sve si ti kriv!!!111"). Stoga, ako će vam hoster u nečemu pomoći, onda će se potruditi da to bude što jednostavnije i „stambeno“. Jer to je teško izvedivo - neisplativo, barem sa stanovišta troškova rada inženjera upravo ovog hostera (ali situacije su različite, pogledajte odricanje od odgovornosti). To ne znači da će domaćin nužno sve raditi loše. Ali uopće nije činjenica da će on učiniti upravo ono što vam je zaista potrebno.
Čini se da je stvar sasvim očigledna, ali nekoliko puta sam u svojoj praksi naišao na činjenicu da su se kompanije počele oslanjati na svog hosting provajdera malo više nego što bi trebalo, a to nije dovelo do ničega dobrog. Trebalo je dosta vremena da se detaljno objasni da nijedan SLA neće pokriti gubitke zbog prekida rada (postoje izuzeci, ali obično je to vrlo, VEOMA skupo za klijenta) i da hoster uopće nije svjestan šta se dešava u infrastrukturi korisnika (osim vrlo opštih indikatora). A ni hoster ne pravi rezervne kopije za vas. Situacija je još gora ako imate više hostera. U slučaju bilo kakvih problema među njima, oni sigurno neće za vas otkriti šta je pošlo po zlu.
Zapravo, motivi su ovdje potpuno isti kao kod odabira „vlastiti tim admina vs outsourcing“. Ako su rizici proračunati, kvalitet odgovara, a biznisu ne smeta - zašto ne probati. S druge strane, mreža je jedan od najosnovnijih slojeva infrastrukture i teško da je vrijedno poklanjati autsajderima ako već sami podržavate sve ostalo.
Kada vam je potreban networker?
Dalje ćemo se fokusirati na kompanije sa modernim proizvodima. Sa operaterima i preduzećima sve je plus-minus jasno - tu se malo toga promijenilo posljednjih godina, a mrežari su tamo bili potrebni prije, potrebni su sada. Ali sa tim vrlo “mladim i odvažnim” stvari nisu tako jednostavne. Često postavljaju svoju infrastrukturu u potpunosti u oblake, tako da im ni ne trebaju administratori, osim administratora tih istih oblaka, naravno. Infrastruktura je, s jedne strane, prilično jednostavna u svom dizajnu, s druge strane je dobro automatizirana (ansible/puppet, terraform, ci/cd... pa, znate). Ali čak i ovdje postoje situacije kada ne možete bez mrežnog inženjera.
Primjer 1, klasičan
Pretpostavimo da kompanija počinje sa jednim serverom sa javnom IP adresom, koja se nalazi u data centru. Zatim postoje dva servera. Onda više... Prije ili kasnije, postoji potreba za privatnom mrežom između servera. Zato što je „vanjski“ promet ograničen i propusnošću (ne više od 100Mbps, na primjer) i količinom preuzetog/prenesenog mjesečno (različiti hosteri imaju različite tarife, ali je propusnost prema vanjskom svijetu, po pravilu, velika skuplji od privatne mreže).
Domaćin dodaje dodatne mrežne kartice serverima i uključuje ih u svoje prekidače u zasebnom vlan-u. Između servera se pojavljuje „ravni“ LAN. Udobno!
Raste broj servera, raste i promet u privatnoj mreži - sigurnosne kopije, replikacije itd. Domaćin nudi da vas premjesti na odvojene prekidače kako ne biste smetali drugim klijentima, a ni oni vama. Domaćin postavlja neku vrstu prekidača i nekako ih konfiguriše - najvjerovatnije ostavljajući jednu ravnu mrežu između svih vaših servera. Sve radi dobro, ali u određenom trenutku počinju problemi: kašnjenja između hostova povremeno rastu, logovi se kunu na previše arp paketa u sekundi, a pentester je silovao vaše cijelo lokalno područje tokom revizije, razbijajući samo jedan server.
Šta treba učiniti?
Podijelite mrežu na segmente - vlans. Postavite vlastito adresiranje u svakom vlan-u, odaberite gateway koji će prenositi promet između mreža. Na mrežnom prolazu, konfigurirajte acl da ograniči pristup između segmenata, ili čak stavite poseban zaštitni zid pored njega.
Primjer 1, nastavak
Serveri su povezani na lokalno područje jednim kablom. Prekidači u rekovima su nekako međusobno povezani, ali u slučaju nezgode u jednom rek-u, otpadaju još tri susjedna. Šeme postoje, ali postoje sumnje u njihovu relevantnost. Svaki server ima svoju javnu adresu, koju izdaje host i vezanu za stalak. One. prilikom premeštanja servera potrebno je promeniti adresu.
Šta treba učiniti?
Povežite servere koristeći LAG (Link Aggregation Group) sa dva kabla na prekidače u stalak (takođe moraju biti redundantni). Rezervišite veze između regala, prepravite ih sa "zvezdicom" (ili sada modernim CLOS-om) tako da gubitak jednog stalka ne utiče na ostale. Odaberite "centralne" rekove gdje će se nalaziti mrežno jezgro i gdje će biti uključeni i drugi rakovi. Istovremeno dovedite u red javno obraćanje, uzmite od hostera (ili od RIR-a, ako je moguće) podmrežu, koju sami (ili preko hostera) najavljujete svijetu.
Može li "običan" sistem administrator koji nema duboko znanje o mrežama sve ovo? Nisam siguran. Hoće li domaćin to učiniti? Možda i hoće, ali će vam trebati prilično detaljan TOR, koji će također neko morati sastaviti. a zatim provjerite da li je sve urađeno kako treba.
Primjer 2: Oblačno
Pretpostavimo da imate VPC u nekom javnom oblaku. Da biste dobili pristup iz uredskog ili on-prem dijela infrastrukture na lokalnu mrežu unutar VPC-a, trebate postaviti vezu preko IPSec-a ili namjenskog kanala. S jedne strane, IPSec je jeftiniji. nema potrebe za kupovinom dodatnog hardvera, možete postaviti tunel između vašeg servera sa javnom adresom i oblaka. Ali - kašnjenja, ograničene performanse (pošto kanal treba da bude šifrovan), plus nezagarantovana konekcija (pošto pristup ide preko običnog Interneta).
Šta treba učiniti?
Povećajte vezu preko namenskog kanala (na primer, AWS ga naziva Direct Connect). Da biste to učinili, pronađite partnera partnera koji će vas povezati, odlučiti koja vam je najbliža točka povezivanja (i vi u operatera i operater u oblak) i, na kraju, sve podesite. Može li se sve ovo uraditi bez mrežnog inženjera? Sigurno, da. Ali kako riješiti problem bez njega u slučaju problema više nije tako jasno.
Takođe mogu postojati problemi sa dostupnošću između oblaka (ako imate multicloud) ili problemi sa kašnjenjima između različitih regiona, itd. Naravno, sada postoji mnogo alata koji povećavaju transparentnost onoga što se dešava u oblaku (isto Hiljadu očiju), ali sve su to alati mrežnog inženjera, a ne zamjena.
Mogao bih skicirati još desetak takvih primjera iz svoje prakse, ali mislim da je jasno da u timu, počevši od određenog nivoa razvoja infrastrukture, treba biti osoba (ili bolje, više od jedne) koja zna kako se mreža radi, može konfigurirati mrežnu opremu i rješavati probleme ako se pojave. Vjerujte mi, on će imati šta da radi
Šta bi mrežnik trebao znati?
Uopšte nije potrebno (a ponekad čak i štetno) da se mrežni inženjer bavi samo mrežom i ništa više. Čak i ako ne uzmemo u obzir opciju s infrastrukturom koja gotovo u potpunosti živi u javnom oblaku (a, kako god da se kaže, postaje sve popularnija), a uzmemo, na primjer, on premise ili privatne oblake, gdje samo “znanje na nivou CCNP-a “Nećeš otići.
Pored, zapravo, mreža - iako postoji jednostavno beskrajno polje za proučavanje, čak i ako se koncentrišete samo na jedan pravac (mreže provajdera, preduzeća, data centri, Wi-Fi...)
Naravno, mnogi od vas će se sada sjetiti Pythona i druge "mrežne automatizacije", ali to je samo neophodan, ali ne i dovoljan uslov. Da bi se mrežni inženjer „uspješno pridružio timu“, mora biti u stanju da govori istim jezikom i sa programerima i sa kolegama administratorima/devopsima. Šta to znači?
- biti sposoban ne samo da radi u Linuxu kao korisnik, već i da ga administrira, barem na nivou sysadmin-junior: instalirati neophodan softver, restartovati pali servis, napisati jednostavnu systemd-jedinicu.
- Razumjeti (barem općenito) kako mrežni stog radi u Linuxu, kako mreža radi u hipervizorima i kontejnerima (lxc / docker / kubernetes).
- Naravno, moći da radite sa ansible/chef/puppet ili drugim SCM sistemom.
- Poseban red treba napisati o SDN-u i mrežama za privatne oblake (na primjer, TungstenFabric ili OpenvSwitch). Ovo je još jedno ogromno znanje.
Ukratko, opisao sam tipičnog stručnjaka za T-oblik (kako je sada moderno reći). Čini se da nije ništa novo, međutim, prema iskustvu intervjua, ne mogu se svi mrežni inženjeri pohvaliti poznavanjem barem dvije teme sa gornje liste. U praksi, nedostatak znanja „u srodnim oblastima“ veoma otežava ne samo komunikaciju sa kolegama, već i razumevanje zahteva koje biznis nameće mreži kao infrastrukturi najnižeg nivoa projekta. A bez ovog razumijevanja postaje teže razumno braniti svoje gledište i „prodati“ ga biznisu.
S druge strane, sama navika “razumijevanja kako sistem funkcionira” daje mrežnima vrlo dobru prednost u odnosu na razne “generaliste” koji znaju za tehnologije iz članaka na Habré/medium i telegram chatovima, ali nemaju apsolutno pojma koji su principi ovog ili taj softver radi. A poznavanje nekih zakonitosti, kao što znate, uspješno zamjenjuje poznavanje mnogih činjenica.
Zaključci, ili jednostavno TL;DR
- Mrežni administrator (poput DBA ili VoIP inženjera) je specijalista prilično uskog profila (za razliku od sysadmins / devops / SRE), potreba za kojim se ne pojavljuje odmah (a možda se neće pojaviti još dugo, zapravo) . Ali ako se ipak pojavi, malo je vjerovatno da će ga zamijeniti vanjska ekspertiza (outsourcing ili obični generalni administratori, “koji također brinu o mreži”). Ono što je nešto tužnije je da je potreba za ovakvim stručnjacima mala i, uslovno, u kompaniji sa 800 programera i 30 devopova/admina mogu postojati samo dva networkera koji savršeno rade svoj posao. One. tržište je bilo i jeste vrlo, vrlo malo, a još manje sa dobrom platom.
- S druge strane, dobar networker u savremenom svijetu treba znati ne samo same mreže (i kako automatizirati njihovu konfiguraciju), već i način na koji operativni sistemi i softver komuniciraju s njima, koji pokreću ove mreže. Bez toga će biti izuzetno teško razumjeti šta kolege traže od vas i prenijeti im (razumno) vaše želje/zahtjeve.
- Nema oblaka, to je samo nečiji računar. Morate shvatiti da korištenje javnih/privatnih oblaka ili usluga hosting provajdera "koji rade sve za vas" ne negira činjenicu da vaša aplikacija još uvijek koristi mrežu, a problemi s njom će utjecati na rad vaše aplikacije . Vaš izbor je gdje će se nalaziti centar kompetencija, koji će biti odgovoran za mrežu vašeg projekta.
izvor: www.habr.com