U vrijeme pisanja ovog članka, pretraga na popularnom mjestu za zapošljavanje za frazu "Inženjer mreže" vratila je oko tri stotine slobodnih radnih mjesta diljem Rusije. Za usporedbu, pretraživanje izraza "administrator sustava" vraća gotovo 2.5 tisuća slobodnih radnih mjesta, a "DevOps inženjer" - gotovo 800.
Znači li to da umrežači više nisu potrebni u vremenima pobjedničkih oblaka, Dockera, Kubernetesa i sveprisutnog javnog Wi-Fi-ja?
Hajde da shvatimo (c)
Idemo se upoznati. Zovem se Alexey i umrežavam se.
Mrežama se bavim više od 10 godina i radim s raznim *nix sustavima više od 15 godina (imao sam priliku petljati i s Linuxom i s FreeBSD-om). Radio sam u telekom operaterima, velikim tvrtkama koje se smatraju “enterprise”, a odnedavno radim u “mladom i odvažnom” fintechu, gdje su cloudovi, devops, kubernetes i ostale strašne riječi koje će mene i moje kolege definitivno učiniti nepotrebnim . Jednog dana. Može biti.
odricanje od odgovornosti: "U našem životu nije sve uvijek i svugdje, ali nešto, ponekad na mjestima" (c) Maxim Dorofeev.
Sve dolje napisano može se i treba smatrati osobnim mišljenjem autora, koje ne tvrdi da je konačna istina, pa čak ni potpuna studija. Svi likovi su izmišljeni, sve slučajnosti su slučajne.
Dobrodošli u moj svijet.
Gdje uopće možete sresti networkere?
1. Telekom operateri, uslužne tvrtke i drugi integratori. Ovdje je sve jednostavno: mreža je za njih posao. Oni ili izravno prodaju povezanost (operatori) ili pružaju usluge za pokretanje/održavanje mreža svojih klijenata.
Ovdje ima puno iskustva, ali malo novca (osim ako niste direktor ili uspješan voditelj prodaje). Pa ipak, ako volite mreže, a tek ste na početku svog puta, karijera u podršci nekog ne baš velikog operatera već sada će biti idealna početna točka (u federalnim je sve vrlo skriptirano, a tamo ima malo prostora za kreativnost). Pa, priče o tome kako se od dežurnog inženjera za nekoliko godina može izrasti u C-level managera također su sasvim stvarne, iako rijetke, iz očitih razloga. Uvijek postoji potreba za kadrovima, jer dolazi do fluktuacije. To je i dobro i loše u isto vrijeme - slobodnih mjesta uvijek ima, s druge strane - često oni najaktivniji/pametniji brzo odu ili radi napredovanja ili na druga, "toplija" mjesta.
2. Uvjetno "poduzeće". Nije važno je li njegova glavna djelatnost vezana uz IT ili ne. Glavna stvar je da ima vlastiti IT odjel koji osigurava rad internih sustava tvrtke, uključujući mrežu u uredima, komunikacijske kanale s podružnicama itd. Funkcije mrežnog inženjera u takvim tvrtkama može obavljati „povremeno“ administrator sustava (ako je mrežna infrastruktura mala ili se njome bavi vanjski izvođač), a mrežni stručnjak, ako postoji, može na u isto vrijeme paziti na telefoniju i SAN (ne valja). Plaćaju različito - uvelike ovisi o isplativosti poslovanja, veličini poduzeća i strukturi. Radio sam s tvrtkama u kojima su Cisco sustavi redovito bili “natovareni u bačve”, te s tvrtkama u kojima je mreža građena od fekalija, štapića i plave trake, a serveri nikad nisu ažurirani (malo je potrebno reći, niti rezerve nisu bile predviđene). Ovdje ima mnogo manje iskustva, a gotovo sigurno će biti u području stroge blokade dobavljača, ili “kako napraviti nešto ni iz čega”. Osobno, smatrao sam ga strašno dosadnim, iako se mnogima sviđa - sve je prilično odmjereno i predvidljivo (ako govorimo o velikim tvrtkama), "dorakha-bahato" itd. Barem jednom godišnje neki veliki dobavljač kaže da su smislili još jedan mega-super-duper sustav koji će sada sve automatizirati i svi sistemski administratori i umrežači se mogu raspršiti, ostavljajući par da pritiskaju gumbe u prekrasnom sučelju. Realnost je da, čak i ako zanemarimo cijenu rješenja, umrežači odatle neće nikamo otići. Da, možda će umjesto konzole opet biti web sučelje (ali ne određeni hardver, već veliki sustav koji upravlja desecima i stotinama takvih hardvera), ali znanje o tome “kako sve unutra radi” će i dalje biti potreban.
3. Proizvodne tvrtke, čiji profit dolazi od razvoja (i, često, rada) nekog softvera ili platforme - tog istog proizvoda. Obično su mala i spretna, još su daleko od razmjera poduzeća i njihove birokratizacije. Tu se masovno nalaze ti isti devopi, cuberi, dockeri i ostale strašne riječi koje će sigurno mrežu i mrežne inženjere učiniti nepotrebnim rudimentom.
Kako se umrežavač razlikuje od administratora sustava?
U razumijevanju ljudi koji nisu iz IT-a - ništa. Obojica gledaju u crni ekran i pišu neke čarolije, ponekad tiho psuju.
U razumijevanju programera - možda po predmetnom području. Administratori sustava administriraju poslužitelje, umrežači administriraju preklopnike i usmjerivače. Ponekad je uprava loša, pa svima sve propadne. Pa, u slučaju nečeg čudnog, krivi su i mrežari. Samo zato što se jebi, eto zašto.
Zapravo, glavna razlika je pristup poslu. Možda je među umrežačima najviše pristalica pristupa "Ako radi, ne diraj ga!". U pravilu, nešto se (unutar jednog dobavljača) može napraviti na samo jedan način, cijela konfiguracija kutije je tu na dlanu. Cijena pogreške je visoka, a ponekad i vrlo visoka (na primjer, morat ćete prijeći nekoliko stotina kilometara da ponovno pokrenete router, au ovom trenutku nekoliko tisuća ljudi bit će bez komunikacije - sasvim uobičajena situacija za telekom operatera) .
Po mom mišljenju, to je razlog zašto su mrežni inženjeri, s jedne strane, izuzetno visoko motivirani za stabilnost mreže (a promjena je glavni neprijatelj stabilnosti), a drugo, njihovo znanje ide više u dubinu nego u širinu (ne morate biti u mogućnosti konfigurirati desetke različitih demona, trebate poznavati tehnologije i njihovu implementaciju od određenog proizvođača opreme). Zato administrator sustava koji je guglao kako registrirati vlan na Cisco sustavu još nije umrežač. I malo je vjerojatno da će moći učinkovito podržati (kao i riješiti probleme) više ili manje složenu mrežu.
Ali zašto vam je potreban networker ako imate hoster?
Za dodatni novac (i ako ste jako veliki i voljeni klijent, možda čak i besplatno, "kao prijatelj"), inženjeri podatkovnog centra konfigurirat će vaše preklopnike prema vašim potrebama, a možda vam čak pomoći da uspostavite BGP sučelje s pružateljima usluga (ako imate svoju podmrežu IP adresa za objavu).
Glavni problem je što podatkovni centar nije vaš IT odjel, to je zasebna tvrtka čiji je cilj ostvarivanje profita. Uključujući i na račun vas kao klijenta. Podatkovni centar nudi regale, opskrbljuje ih električnom energijom i hladnoćom, a također pruža i neke "zadane" veze s Internetom. Na temelju ove infrastrukture, podatkovni centar može ugostiti vašu opremu (kolokacija), iznajmiti vam poslužitelj (namjenski poslužitelj) ili pružiti upravljanu uslugu (na primjer, OpenStack ili K8s). Ali posao podatkovnog centra (obično) nije administracija klijentske infrastrukture, jer je taj proces dosta radno intenzivan, slabo automatiziran (a u normalnom podatkovnom centru sve je moguće automatizirano), unificiran još gore (svaki klijent je individualno) i općenito prepuno pritužbi ("kažete mi da je poslužitelj postavljen, ali sada se srušio, za sve ste vi krivi!!!111"). Stoga, ako vam hoster u nečemu pomogne, pokušat će to učiniti što jednostavnijim i praktičnijim. Zato što je teško raditi neisplativo, barem sa stajališta troškova rada inženjera tog istog hostera (ali situacije su različite, vidi odricanje od odgovornosti). To ne znači da će hoster nužno sve napraviti loše. Ali uopće nije činjenica da će on učiniti upravo ono što vam je stvarno potrebno.
Čini se da je stvar sasvim očita, ali nekoliko puta sam se u svojoj praksi susreo s činjenicom da su se tvrtke počele oslanjati na svog hosting providera malo više nego što bi trebale, a to nije dovelo ni do čega dobrog. Morao sam nadugačko i detaljno objašnjavati da niti jedan SLA ne bi pokrio gubitke od zastoja (ima iznimaka, ali obično je to jako, JAKO skupo za klijenta) i da hoster uopće nije svjestan što se događa u infrastruktura kupaca (osim vrlo općih pokazatelja). A ni hoster ne radi sigurnosne kopije za vas. Situacija je još gora ako imate više od jednog hostera. U slučaju bilo kakvih problema među njima, oni sigurno neće otkriti umjesto vas što je pošlo po zlu.
Zapravo, motivi su ovdje potpuno isti kao i kod odabira "in-house admin team vs outsource". Ako su rizici proračunati, kvaliteta zadovoljavajuća, a posao nema ništa protiv, zašto ne probati. S druge strane, mreža je jedan od najosnovnijih slojeva infrastrukture i teško da je vrijedi prepustiti vanjskim momcima ako već sami podržavate sve ostalo.
U kojim slučajevima je potreban networker?
Zatim ćemo posebno govoriti o modernim prehrambenim tvrtkama. S operaterima i poduzećem sve je jasno, plus ili minus - malo se toga promijenilo posljednjih godina, a umrežači su bili potrebni prije, a potrebni su i sada. Ali s tim istim “mladim i odvažnim” stvari nisu tako jasne. Često cijelu svoju infrastrukturu smjeste u oblake, tako da im zapravo niti ne trebaju administratori - osim administratora tih istih oblaka, naravno. Infrastruktura je, s jedne strane, prilično jednostavna u svom dizajnu, s druge strane, dobro je 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 tvrtka počinje s jednim poslužiteljem s javnom IP adresom, koji se nalazi u podatkovnom centru. Zatim postoje dva poslužitelja. Zatim više... Prije ili kasnije, pojavit će se potreba za privatnom mrežom između poslužitelja. Budući da je "vanjski" promet ograničen i propusnošću (ne više od 100 Mbit/s na primjer) i količinom preuzimanja/uploada mjesečno (različiti hosteri imaju različite tarife, ali propusnost prema vanjskom svijetu obično je puno skuplja od privatna mreža).
Domaćin dodaje dodatne mrežne kartice poslužiteljima i uključuje ih u svoje preklopnike u zasebnom vlan-u. Između poslužitelja pojavljuje se "ravno" lokalno područje. Udobno!
Broj poslužitelja raste, a raste i promet na privatnoj mreži - sigurnosne kopije, replikacije itd. Hoster nudi da vas premjesti u zasebne preklopnike kako ne biste smetali drugim klijentima, a oni ne smetaju vama. Domaćin instalira neke preklopnike i nekako ih konfigurira - najvjerojatnije ostavljajući jednu ravnu mrežu između svih vaših poslužitelja. Sve radi dobro, ali u određenom trenutku počinju problemi: kašnjenja između hostova povremeno se povećavaju, dnevnici se žale na previše arp paketa u sekundi, a tijekom revizije pentester je sjebao cijelu vašu lokalnu mrežu, razbivši samo jedan poslužitelj.
Što treba učiniti?
Podijelite mrežu na segmente - vlanove. Konfigurirajte vlastito adresiranje u svakom vlan-u, odaberite pristupnik koji će prenositi promet između mreža. Konfigurirajte acl na pristupniku da ograničite pristup između segmenata ili čak instalirajte zasebni vatrozid u blizini.
Primjer 1, nastavak
Serveri su spojeni na LAN jednim kabelom. Prekidači u regalima su nekako međusobno povezani, ali ako dođe do nezgode u jednom raku, otpadnu još tri susjedna. Sheme postoje, ali postoje sumnje u njihovu relevantnost. Svaki server ima svoju javnu adresu koju izdaje hoster i vezana je za rack. Oni. Prilikom premještanja poslužitelja potrebno je promijeniti adresu.
Što treba učiniti?
Povežite poslužitelje koristeći LAG (Link Aggregation Group) s dva kabela na prekidače u stalku (također moraju biti redundantni). Rezervirajte spojeve između regala i pretvorite ih u "zvijezdu" (ili sada moderni CLOS) tako da gubitak jednog regala ne utječe na ostale. Odaberite “centralne” police u kojima će se nalaziti mrežna jezgra i gdje će se povezivati ostali police. Istovremeno, dovedite u red javno adresiranje, uzmite od hostera (ili od RIR-a, ako je moguće) podmrežu, koju sami (ili preko hostera) obznanite svijetu.
Može li sve ovo napraviti “običan” administrator sustava koji nema dubokog znanja o mrežama? Nisam siguran. Hoće li hoster to učiniti? Možda i hoće, ali trebat će vam prilično detaljna tehnička specifikacija koju će također netko morati izraditi. a zatim provjerite je li sve ispravno napravljeno.
Primjer 2: Oblak
Recimo da imate VPC u nekom javnom oblaku. Za pristup lokalnoj mreži unutar VPC-a iz ureda ili on-prem dijela infrastrukture morate konfigurirati vezu putem IPSec-a ili namjenskog kanala. S jedne strane, IPSec je jeftiniji, jer nema potrebe za kupnjom dodatnog hardvera; možete postaviti tunel između vašeg poslužitelja s javnom adresom i oblaka. Ali - kašnjenja, ograničene performanse (budući da kanal mora biti šifriran), plus nezajamčena povezanost (budući da je pristup putem običnog Interneta).
Što treba učiniti?
Uspostavite vezu putem namjenskog kanala (na primjer, AWS to naziva Direct Connect). Da biste to učinili, pronađite partnerskog operatera koji će vas spojiti, odredite mjesto spajanja koje vam je najbliže (i vi s operaterom i operater s oblakom) i na kraju sve postavite. Je li moguće sve to učiniti bez mrežnog inženjera? sigurno da. Ali kako riješiti problem bez njega u slučaju problema više nije tako jasno.
Također može biti problema s dostupnošću između oblaka (ako imate multicloud) ili problema s kašnjenjima između različitih regija, itd. Naravno, sada su se pojavili mnogi alati koji povećavaju transparentnost onoga što se događa u oblaku (isti Thousand Eyes), ali to su svi alati mrežnog inženjera, a ne zamjena za njega.
Mogao bih nabrojati još desetak takvih primjera iz svoje prakse, ali mislim da je jasno da tim, počevši od određene razine razvijenosti infrastrukture, mora imati osobu (po mogućnosti više od jedne) koja zna kako mreža funkcionira i može konfigurirati mrežnu opremu i riješiti probleme ako se pojave. Vjerujte mi, imat će što raditi
Što bi umrežač trebao znati?
Uopće nije nužno (a ponekad čak i štetno) da se mrežni inženjer bavi samo mrežom i ničim drugim. Čak i ako ne razmatramo opciju s infrastrukturom koja gotovo u cijelosti živi u javnom oblaku (i, što god se moglo reći, postaje sve popularnija), i uzmemo, na primjer, on premise ili privatne oblake, gdje o „samo znanju na razini CCNP-a” „Nećeš otići.
Osim, zapravo, mreža - iako postoji jednostavno beskrajno polje za proučavanje, čak i ako se koncentrirate samo na jedno područje (mreže provajdera, poduzeća, podatkovni centri, Wi-Fi...)
Naravno, mnogi od vas će se sada sjetiti Pythona i ostalih “mrežnih automata”, ali to je samo nužan, ali ne i dovoljan uvjet. Kako bi se mrežni inženjer "uspješno pridružio timu", mora moći govoriti istim jezikom i s programerima i s kolegama administratorima/programerima. Što to znači?
- moći ne samo raditi u Linuxu kao korisnik, već i administrirati ga, barem na razini sysadmin-jun: instalirati potreban softver, ponovno pokrenuti neuspjeli servis, napisati jednostavnu systemd-jedinicu.
- Razumjeti (barem općenito) kako mrežni stog radi u Linuxu, kako mreža radi u hipervizorima i spremnicima (lxc / docker / kubernetes).
- Naravno, moći raditi s ansible/chef/puppet ili drugim SCM sustavom.
- Poseban red treba napisati o SDN-u i mrežama za privatne oblake (na primjer, TungstenFabric ili OpenvSwitch). Ovo je još jedan ogroman sloj znanja.
Ukratko, opisao sam tipičnog stručnjaka za T-oblik (kako je sada moderno reći). Čini se kao ništa novo, ali na temelju iskustva s intervjua, ne mogu se svi mrežni inženjeri pohvaliti poznavanjem barem dvije teme s gornjeg popisa. U praksi nedostatak znanja “u srodnim područjima” uvelike otežava ne samo komunikaciju s kolegama, već i razumijevanje zahtjeva koje poslovanje postavlja pred mrežu, kao infrastrukturu najniže razine projekta. A bez tog razumijevanja, postaje teže braniti svoje stajalište i "prodati" ga poslu.
S druge strane, ista navika “razumijevanja kako sustav funkcionira” daje mrežnicima vrlo dobru prednost pred raznim “generalistima” koji o tehnologijama znaju iz članaka na Habré/mediumu i chatova na Telegramu, ali nemaju pojma kako što načela na kojima radi ovaj ili onaj softver? A znanje o određenim obrascima, kao što je poznato, uspješno zamjenjuje znanje o mnogim činjenicama.
Zaključci, ili samo TL;DR
- Mrežni administrator (poput DBA ili VoIP inženjera) stručnjak je prilično uskog profila (za razliku od sistemskih administratora/devs/SRE), čija se potreba ne javlja odmah (i možda se neće pojaviti dugo vremena, zapravo) . Ali ako se pojavi, malo je vjerojatno da će biti zamijenjeno vanjskim stručnjacima (outsource ili obični administratori opće namjene, "koji također brinu o mreži"). Ono što je nešto tužnije je da je potreba za ovakvim stručnjacima mala, a, uvjetno, u tvrtki s 800 programera i 30 devops/administratora, mogu postojati samo dva networkera koji odlično obavljaju svoje obveze. Oni. tržište je bilo i jest jako, jako malo, a uz dobru plaću - još manje.
- S druge strane, dobar umrežavač u modernom svijetu mora poznavati ne samo same mreže (i kako automatizirati njihovu konfiguraciju), već i kako operativni sustavi i softver koji rade na tim mrežama komuniciraju s njima. Bez toga će biti izuzetno teško razumjeti što kolege od vas traže i prenijeti im (razumno) svoje želje/zahtjeve.
- Nema oblaka, to je samo tuđe računalo. Morate razumjeti da korištenje javnih/privatnih oblaka ili usluga pružatelja usluga hostinga "koji sve radi za vas po principu ključ u ruke" ne mijenja činjenicu da vaša aplikacija i dalje koristi mrežu, a problemi s njom utjecat će na rad tvoja prijava. Vaš je izbor gdje će se nalaziti centar kompetencija koji će biti odgovoran za mrežu vašeg projekta.
Izvor: www.habr.com