U trenutku pisanja ovog članka, pretraga na popularnoj web stranici za poslove za izraz "Mrežni inženjer" davala je oko tri stotine oglasa za posao širom Rusije. U usporedbi, pretraga za izraz "sistemski administrator" daje gotovo 2.5 tisuća oglasa, dok "DevOps inženjer" ima gotovo 800.
Znači li to da mrežni inženjeri više nisu potrebni u eri osvojene obrade u oblaku, Dockera, Kubernetesa i svuda prisutnog javnog Wi-Fi-ja?
Hajde da to istražimo (c)
Hajde da se upoznamo. Zovem se Aleksej i ja sam mrežni inženjer.
Više od 10 godina se bavim mrežama i više od 15 godina radim s različitim *nix sustavima (imao sam priliku raditi i s Linuxom i s FreeBSD-om). Radio sam za telekomunikacijske operatere, velike kompanije koje se smatraju "enterprize", a posljednjih godina radim u "mladom i odvažnom" fintechu gdje su oblak, devops, kubernetesi i drugi zastrašujući termini koji će me i moje kolege učiniti suvišnima. Jednog dana. Možda.
disclaimer: "U našem životu nije sve, uvijek i svugdje, a ponekad i na mjestima" (c) Maksim Dorofejev.
Sve što je napisano u nastavku može i treba se smatrati osobnim mišljenjem autora, koje ne pretendira na istinu u posljednjoj instanci, pa čak ni na potpunu studiju. Svi likovi su izmišljeni, sve podudarnosti su slučajne.
Dobrodošli u moj svijet.
Gdje se uopće mogu susresti mrežni inženjeri?
1. Telefonski operateri, servisne tvrtke i drugi integratori.. Ovdje je sve jednostavno: mreža za njih je posao. Ili direktno prodaju vezu (operateri), ili pružaju usluge pokretanja/održavanja mreža svojih klijenata.
Ovdje ima puno iskustva, ali novca — ne baš mnogo (ako niste direktor ili uspješni menadžer prodaje). Ipak, ako volite mreže i tek ste na početku, karijera u podršci nekog manje poznatog operatera bit će, čak i sada, idealna točka za početak (u velikim kompanijama sve je prilično isplanirano, a prostora za kreativnost je malo). Također postoje priče o tome kako se od dežurnog inženjera može napredovati do C-level menadžera za nekoliko godina, iako su one rijetke, iz razumljivih razloga. Potražnja za radnicima uvijek postoji, jer fluktuacija kadrova itekako postoji. To je i dobro i loše u isto vrijeme — uvijek ima slobodnih radnih mjesta, s druge strane — najaktivniji/najsposobniji obično brzo odlaze ili na napredovanje ili u neka, prijatnija, radna okruženja.
2. Uvjetni "enterprise". Nevažno je je li njegova osnovna djelatnost vezana uz IT ili nije. Važno je da ima svoj IT odjel koji se bavi radom internih sustava tvrtke, uključujući mrežu u uredima, komunikacijske kanale u podružnicama itd. Funkcije mrežnog inženjera u takvim tvrtkama može "u zamjeni" obavljati sistemski administrator (ako je mrežna infrastruktura mala ili njome upravlja vanjski izvođač), a mrežni inženjer, ako ga ima, može istovremeno nadgledati telefoniju i SAN (malo nezgodno). Plaće su različite — jako ovise o marži poslovanja, veličini tvrtke i strukturi. Radio sam s tvrtkama gdje su ciskici redovito bili "opterećeni", i s tvrtkama gdje je mreža građena od smeća, štapova i plave izolir trake, a serveri nikada nisu ažurirani (trebam li reći da nisu postojale nikakve rezervne opcije). Iskustva ovdje ima znatno manje, a gotovo će sigurno biti u području tvrdog vendor-locka ili "kako iz ničega napraviti nešto". Osobno mi se činilo jako dosadno, iako mnogima to odgovara — sve je dovoljno mirno i predvidljivo (ako govorimo o velikim tvrtkama), "dora-ha-bahato" itd. Ne rjeđe nego jednom godišnje, neki veliki dobavljač izjavi da je izmislio novu mega-super-puper-sustav koji će sada automatski sve obaviti, i sve sistemske administratore i mrežne inženjere će moći otpustiti, ostavljajući nekoliko njih za klikove u lijepom sučelju. No stvarnost je takva da se, čak i ako apstrahiramo cijenu rješenja, mrežni inženjeri odande neće maknuti. Da, možda će umjesto konzole opet biti web sučelje (ali ne više za konkretnu opremu, već za veliki sustav koji upravlja desecima i stotinama takvih uređaja), no znanje "kako sve unutra funkcionira" i dalje će biti potrebno.
3. Proizvodne tvrtke, čiji je profit rezultat razvoja (i često, eksploatacije) nekog softvera ili platforme — tog istog proizvoda. Obično su to male i brze tvrtke, još daleko od razmjera korporacija i njihove birokratizacije. Upravo ovdje se masovno nalaze oni dejopsi, kuberi, dokers i druge strašne riječi, koje će sigurno učiniti mrežu i mrežne inženjere suvišnim reliktom.
Čime se mrežni inženjer razlikuje od sistemskog administratora?
U shvatanju ljudi koji nisu iz IT-a — ništa. I jedan i drugi gledaju u crni ekran i kucaju neka čarobna slova, ponekad se tiho psujući.
U shvatanju programera — možda kao predmetna područja. Sistemci administriraju servere, mrežni administratori o uređajima i ruterima. Ponekad administriraju loše, i svima sve pada. U slučaju svake čudne situacije, krivi su također mrežni administratori. Samo zato što, jebi se, to je zašto.
U stvarnosti, glavna razlika — pristup radu. Vjerojatno se među mrežnim administratorima najviše može naći onih koji stoje iza pristupa ‘Radi — ne diraj!’. Neki zadatak (unutar jednog dobavljača) obično se može učiniti samo jednim načinom, a cijela konfiguracija uređaja — tu je, na dlanu. Cijena greške je visoka, a ponekad čak i vrlo visoka (na primjer, morat ćete putovati nekoliko stotina kilometara da restartate ruter, dok će nekoliko tisuća ljudi biti bez veze — sasvim uobičajena situacija za operatere telekomunikacija).
Po mom mišljenju, upravo zato su mrežni inženjeri, s jedne strane, izuzetno motivirani na stabilnost mreže (a promjene su najveći neprijatelj stabilnosti), a s druge strane, njihovo znanje ide više u dubinu nego u širinu (nije potrebno znati konfigurirati desetine različitih demona, potrebno je poznavati tehnologije i njihovu realizaciju kod konkretne opreme). Upravo zbog toga, sistemac koji je na internetu našao kako se na Cisco uređaju postavlja VLAN — to još uvijek nije mrežni inženjer. I teško da će moći učinkovito podržavati (a također i rješavati probleme) nešto složeniju mrežu.
Ali zašto je potreban mrežni inženjer, ako imate hosting?
Uz dodatnu naknadu (a ako ste jako veliki i omiljeni klijent — možda čak i besplatno, 'iz prijateljstva') inženjeri data centra će prilagoditi vaše switcheve prema vašim potrebama, i, možda, čak pomoći podići BGP vezu s davateljima usluga (ako imate svoju podmrežu ip-adresa za najavu).
Glavni problem je u tome što je datacentar – to nije vaš IT odjel, to je posebna kompanija čiji je cilj ostvarivanje profita. Uključujući vas kao klijenta. Datacentar pruža rackove, osigurava im struju i hladnoću, a također daje neku "default" povezanost s internetom. Na temelju te infrastrukture, datacentar može smjestiti vašu opremu (colocation), iznajmiti vam server (dedicated server), ili pružiti uslugu upravljanja (primjerice, OpenStack ili K8s). No, posao datacentra (obično) nije administracija infrastrukture klijenata jer je taj proces prilično radno intenzivan, slabo se automatizira (dok je u normalnom datacentru automatizirano sve što je moguće), još teže se standardizira (svaki klijent je jedinstven) i uopće nosi rizike od pritužbi ("ti si mi podesio server, a sad je pao, ti si kriv!!!111"). Stoga, ako će vam hoster bilo kako pomoći, pokušaće to učiniti što jednostavnije i "desetkasto". Jer raditi složeno - nije isplativo, najmanje s gledišta troškova rada inženjera tog istog hostera (ali situacije su različite, vidi odricanje). To ne znači da će hoster sve obaviti loše. No, nije uopće sigurno da će učiniti baš ono što vam je zapravo bilo potrebno.
Naizgled, stvar je prilično očita, ali nekoliko puta sam se u svojoj praksi sukobio s tim da su kompanije počele previše se oslanjati na svog hosting provajdera, više nego što bi trebalo, i to nije vodilo do ničega dobrog. Moralo se dugo i detaljno objašnjavati da nijedan SLA ne pokriva gubitke zbog zastoja (ima iznimaka, ali obično je to jako, JAKO skupo za klijenta) i da hoster uopće nije informiran o tome što se događa u infrastrukturi naručitelja (osim vrlo općih podataka). I backupe hoster također ne radi za vas. Još je gore ukoliko imate više od jednog hostera. U slučaju bilo kakvih problema među njima, sigurno se neće truditi da otkriju za vas što je zapravo pošlo po zlu.
Motivi su ovdje potpuno isti kao i kada se odlučujete između 'vlastitog tima administratora vs outsourcinga'. Ako su rizici procijenjeni, kvaliteta odgovara, a biznis se slaže — zašto ne probati? S druge strane, mreža je jedan od najosnovnijih slojeva infrastrukture, i teško da bi trebalo prepustiti je vanjskim timovima, ako već sve ostalo podržavate sami.
Kada vam treba mrežni inženjer?
U nastavku će se govoriti o modernim proizvodnim kompanijama. O operaterima i enterprise rješenjima sve je manje više jasno — tu se nije mnogo promijenilo u posljednjih nekoliko godina, a mrežni inženjeri su bili potrebni prije, potrebni su i sada. Međutim, s onim 'mladim i hrabrim' stvar nije tako jednostavna. Često svoju infrastrukturu koriste u potpunosti u oblaku, tako da im čak i administratori nisu posebno potrebni — osim za administratore tih istih oblaka, naravno. Infrastruktura je, s jedne strane, prilično jednostavna za implementaciju, dok je s druge strane dobro automatizirana (ansible/puppet, terraform, ci/cd… znate već). No, čak i ovdje postoje situacije kada ne možete bez mrežnog inženjera.
Primjer 1, klasični
Pretpostavimo da kompanija započinje s jednim serverom s javnom IP adresom koji se nalazi u data centru. Kasnije postaju dva servera. Zatim više… Rano ili kasno, javlja se potreba za privatnom mrežom između servera. Jer 'spoljašnji' promet je ograničen kako po propusnosti (ne više od 100 Mbit/s, na primjer), tako i po količini preuzimanja/otpreme mjesečno (različiti hosteri imaju različite tarife, ali vanjska propusnost je obično mnogo skuplja od privatne mreže).
Hoster dodaje dodatne mrežne kartice u servere i priključuje ih u svoje switcheve u odvojenom vlan-u. Između servera se pojavljuje 'ravna' lokalna mreža. Praktično!
Broj servera raste, a promet u privatnoj mreži također - backupi, replikacije i slično. Hosting provider nudi preseljenje u odvojene switcheve kako ne biste ometali druge klijente, a ni oni vas. Hosting provider postavlja određene switcheve i nekako ih konfigurira - najvjerojatnije ostavljajući jednu ravnu mrežu između svih vaših servera. Sve funkcionira dobro, ali u određenom trenutku počinju problemi: povremeno se povećavaju latencije između hostova, u logovima su pritužbe na prevelik broj arp paketa u sekundi, a pentester tijekom audita je dobio pristup vašoj lokalnoj mreži, srušivši samo jedan server.
Što treba učiniti?
Podijeliti mrežu na segmente - vlan-ove. Konfigurirati vlastitu adresaciju u svakom VLAN-u, dodijeliti gateway koji će prebacivati promet između mreža. Na gatewayu postaviti ACL za ograničavanje pristupa između segmenata, ili čak postaviti odvojeni firewall uz njega.
Primjer 1, nastavak
Serveri su povezani s lokalnom mrežom jednim kabelom. Switchevi u ormaru su nekako povezani, ali ako dođe do kvara u jednom ormaru, ispadaju još tri susjedna. Postoje sheme, ali postoji sumnja u njihovu aktualnost. Svakom serveru dodijeljen je javni IP koji dodjeljuje hosting provider i vezan je za ormar. Dakle, prilikom premještanja servera, IP adresa se mora mijenjati.
Što treba učiniti?
Povezati servere putem LAG (Link Aggregation Group) s dva kabla na switcheve u ormaru (njih također treba rezervirati). Povezivanja između ormara rezervirati, preoblikovati u "zvijezdu" (ili moderni CLOS), kako bi ispad jednog ormara ne utjecao na druge. Izdvojiti "centralne" ormare u kojima će se nalaziti mrežno jezgro i u koje će se priključivati drugi ormari. Uz to, urediti javnu adresaciju, dobiti od hosting providera (ili od RIR-a, ako je moguće) podmrežu koju će se samostalno (ili putem hosting providera) najaviti u svijet.
Može li sve ovo učiniti "obični" sistem administrator, koji nema duboko znanje o mrežama? Nisam siguran. Hoće li to učiniti hosting provider? Možda hoće, ali od vas će biti potrebna prilično detaljna tehnička specifikacija, koju također netko treba sastaviti, a zatim provjeriti da li je sve točno napravljeno.
Primjer 2. Oblak
Pretpostavimo da imate VPC u nekoj javnoj oblaku. Da biste dobili pristup iz ureda ili on-prem dijela infrastrukture do lokalne mreže unutar VPC-a, potrebno je postaviti vezu putem IPSec-a ili namjenskog kanala. S jedne strane, IPSec je jeftiniji, budući da ne morate kupovati dodatni hardver, možete postaviti tunel između vašeg poslužitelja s javnom adresom i oblaka. Međutim, tu su i kašnjenja, ograničena propusnost (jer je potrebno šifrirati vezu), kao i ne garantirana povezanost (jer se pristup odvija putem običnog interneta).
Što treba učiniti?
Postaviti vezu putem namjenskog kanala (na primjer, kod AWS-a to se zove Direct Connect). Za to pronaći partnera-operatora koji će vas povezati, odrediti najbližu točku ulaska (bilo vas do operatora, bilo operatora do oblaka) i konačno sve postaviti. Može li se to učiniti bez mrežnog inženjera? Zasigurno, da. A kako se sve to rješava u slučaju problema, to već nije tako jasno.
Osim toga, mogu se javiti problemi s dostupnošću između oblaka (ako imate multi-cloud) ili problemi s kašnjenjem između različitih regija itd. Bez sumnje, sada postoji mnogo alata koji povećavaju transparentnost onoga što se događa u oblaku (poput Thousand Eyes), ali to su alati mrežnog inženjera, a ne njegovo zamjena.
Mogao bih još desetak takvih primjera iz svoje prakse navesti, ali mislim da je jasno da u timu, počevši od određenog nivoa razvoja infrastrukture, mora postojati osoba (a najbolje više njih) koja zna kako mreža funkcionira, može postaviti mrežnu opremu i riješiti probleme ako se oni jave. Vjerujte, imat će čime da se bavi.
Što bi mrežni inženjer trebao znati?
Nije nužno (i ponekad čak i štetno) da se mrežni inženjer bavi isključivo mrežom i ni čim drugim. Čak i ne uzimajući u obzir infrastrukturu koja skoro potpuno živi u javnom oblaku (koja postaje sve popularnija), ako uzmemo, na primjer, on-premise ili privatne oblake, s „znanjem na razini CCNP-a“ nećete daleko dogurati.
Osim samih mreža — ovdje se otvara beskrajno polje za učenje, čak i ako se koncentrirate samo na jedno određeno područje (mreže pružatelja usluga, enterprise, data centri, wifi…)
Naravno, mnogi od vas će se sada sjetiti Pythona i ostale „mrežne automatizacije“, ali to je samo nužna, ali ne i dovoljna pretpostavka. Da bi se mrežni inženjer „uspješno uklopio u tim“, mora znati razgovarati istim jezikom s programerima, kolegama administratorima/devops inženjerima. Što to znači?
- Mora znati ne samo raditi u Linuxu kao korisnik, već i administrirati ga, barem na razini junior sistemskog administratora: instalirati potreban softver, ponovno pokrenuti srušenu uslugu, napisati jednostavnu systemd jedinicu.
- Treba razumjeti (barem u općim crtama) kako radi mrežni stog u Linuxu, kako je mreža organizirana u hipervizorima i kontejnerima (lxc / docker / kubernetes).
- Naravno, treba znati raditi s ansible/chef/puppet ili nekim drugim SCM sustavom.
- Ono što se posebno treba istaknuti su SDN i mreže za privatne oblake (na primjer, TungstenFabric ili OpenvSwitch). To je još jedan ogroman sloj znanja.
Ukratko, opisao sam tipičnog T-shape stručnjaka (kako se sada moderno kaže). Čini se da nije ništa novo, ali prema iskustvu sa sučeljima, daleko od toga da svi mrežni inženjeri mogu pohvaliti znanjem barem dvije teme s gornjeg popisa. U praksi, nedostatak znanja „u susjednim područjima“ jako otežava ne samo komunikaciju s kolegama, već i razumijevanje zahtjeva koje posao postavlja mreži kao najniže razine infrastrukture projekta. A bez tog razumijevanja postaje teže argumentirano braniti svoje stajalište i „prodati“ ga poslu.
S druge strane, ta navika „razumjeti kako sustav radi“ daje mrežnim stručnjacima vrlo dobru prednost nad raznim „širokoprofesionalnim stručnjacima“, koji znaju o tehnologijama iz članaka na Habré/Mediumu i chatovima na Telegramu, ali nemaju pojma na kojim principima radi određeni softver. A poznavanje nekih obrazaca, kao što je poznato, uspješno zamjenjuje znanje mnoštva činjenica.
Zaključci, ili jednostavno TL;DR
- Mrežni administrator (kao i DBA ili VoIP inženjer) je stručnjak prilično uskog profila (za razliku od sistemskih administratora/devops/a/SRE-a), čija se potreba ne javlja odmah (i ne mora se javiti dugo vremena, zapravo). No, kada se jednom javi, teško je zamijeniti to znanje vanjskom podrškom (outsourcing ili obični administratori širokog spektra, „koji se još brinu i o mreži”). Nažalost, potreba za takvim stručnjacima je mala, i, uvjetno rečeno, u kompaniji sa 800 programera i 30 devops/a/admina može biti samo dva mrežna inženjera koja odlično obavljaju svoje dužnosti. Odnosno, tržište je bilo i ostalo prilično malo, a kada je riječ o dobroj plaći — još manje.
- S druge strane, dobar mrežni inženjer u modernom svijetu mora znati ne samo mreže (i kako automatizirati njihovu konfiguraciju), nego i kako s njima komuniciraju operativni sustavi i softver koji radi na tim mrežama. Bez toga će biti iznimno teško razumjeti što kolege traže od tebe i obavijestiti (razmjerno) o svojim željama/zahtjevima prema njima.
- Nema oblaka, to je samo tuđi računalni sustav. Treba razumjeti da korištenje javnih/privatnih oblaka ili usluga hosting provajdera „koji sve odrađuje za vas” ne ukida činjenicu da vaša aplikacija i dalje koristi mrežu, a problemi s njom će utjecati na rad vaše aplikacije. Vaš izbor — gdje će se nalaziti centar kompetencija koji će biti odgovoran za mrežu vašeg projekta.
Izvor: habr.com
