Ob trenutku pisanja tehle članka je iskanje na priljubljeni spletni strani za zaposlovanje z izrazom "Omrežni inženir" prikazovalo okoli tristo prostih delovnih mest po vsej Rusiji. Za primerjavo, iskanje z izrazom "sistemski administrator" prikaže skoraj 2,5 tisočo prostih delovnih mest, medtem ko "DevOps inženir" prikaže skoraj 800.
Ali to pomeni, da omrežni inženirji niso več potrebni v času zmagovalnih oblakov, Dockra, Kubernetesa in vseprisotnega javnega WiFi-ja?
Poglejmo bližje (c)
Naj se predstavim. Moje ime je Aleksej in sem omrežni inženir.
Več kot 10 let se ukvarjam z omrežji in več kot 15 let delam z različnimi *nix sistemi (imel sem priložnost delati tako z Linuxom kot z FreeBSD). Dela sem v telekomunikacijah, velikih podjetjih, ki veljajo za "enterprize", v zadnjem času pa delam v "mladih in drznih" fintech podjetjih, kjer oblak, DevOps, Kubernetes in druge strašne besede, ki nas bodo zagotovo naredile z mene in mojih kolegov nepotrebne. Enkrat. Mogoče.
opomba: "V našem življenju ni vse, vedno in povsod, ampak nekaj, občasno in na mestih" (c) Maksim Dorofejev.
Vse, kar je napisano spodaj, se lahko in mora obravnavati kot osebno mnenje avtorja, ki ne zahteva končne resnice, niti ne celovite raziskave. Vsi liki so izmišljeni, vsa sovpada so naključna.
Dobrodošli v moj svet.
Kje sploh lahko srečamo omrežne inženirje?
1. Telekomunikacijski operaterji, storitvene podjetja in drugi integratorji. Tu je vse preprosto: omrežje je zanje poslovanje. Bodisi neposredno prodajajo povezljivost (operaterji), bodisi nudijo storitve pri zagonu/ vzdrževanju omrežij svojih strank.
Izkušenj je tukaj veliko, denarja pa ne prav dosti (razen če niste direktor ali uspešen prodajni menedžer). Kljub temu, če imate radi omrežja in ste šele na začetku poti, je kariera v podpori pri kakšnem ne preveč velikem ponudniku še vedno idealna izhodiščna točka (v državnih podjetjih je vse zelo natančno določeno in prostora za ustvarjalnost je malo). Zgodbe o tem, da lahko iz dežurnega inženirja v nekaj letih napredujete do C-level menedžerja, so tudi povsem realne, čeprav redke iz understood razlogov. Potreba po kadrih je vedno prisotna, saj obratna zasedenost res obstaja. To je hkrati dobro in slabo - vedno so prosta delovna mesta, po drugi strani pa pogosto najbolj aktivni/delovni kmalu odidejo bodisi na višje položaje bodisi v druge, bolj 'prijetne' oblike zaposlitve.
2. Pogojski 'enterprise'. Ni pomembno je, ali je njegova glavna dejavnost povezana z IT ali ne. Ključno je, da ima svoj IT oddelek, ki skrbi za delovanje notranjih sistemov podjetja, vključno z omrežjem v pisarnah, komunikacijskimi kanali do podružnic itd. Funkcije mrežnega inženirja v takšnih podjetjih lahko 'povezovalno' opravlja sistemski administrator (če je omrežna infrastruktura majhna ali jo upravlja zunanje podjetje), medtem ko lahko mrežni inženir, če sploh obstaja, hkrati skrbi tudi za telefonijo in SAN (ne da bi šli preveč v podrobnosti). Plačila so različna — močno so odvisna od maržnosti poslovanja, velikosti podjetja in strukture. Delal sem s podjetji, kjer so redno 'naložili vse', in s tistimi, kjer so omrežje gradili iz odpadkov, palic in modre izolirne trake, ter kjer strežniki nikoli niso bili posodobljeni (morda ni potrebno omenjati, da tudi rezerve niso bile zagotovljene). Izkušenj je tukaj bistveno manj in skoraj zagotovo so v obliki strogega vendor-locka ali 'kako iz nič narediti nekaj'. Osebno se mi je zdelo tam izjemno dolgočasno, čeprav mnogim ustreza — vse je dovolj umirjeno in predvidljivo (če govorimo o velikih podjetjih), 'zelo veliko' itd. Vsaj enkrat letno kateri koli veliki dobavitelj trdi, da je izumil novo mega-super-vrhunsko sistem, ki bo popolnoma avtomatiziral vse in vse sistemske administratorje in mrežne inženirje bomo lahko odpustili, pri čemer bo ostalo le nekaj za pritiskanje na gumbe v lepem vmesniku. Realnost pa je takšna, da se mrežni inženirji nikamor ne bodo odpravili, tudi če se abstrahiramo od stroškov rešitve. Da, morda bo namesto konzole ponovno spletni vmesnik (a ne konkretne strojne opreme, temveč velikega sistema, ki upravlja z desetinami in stotinami takšnih naprav), vendar bodo znanja 'kako je vse notranje urejeno' še vedno potrebna.
3. Izdelovalna podjetja, katerih dobiček prinaša razvoj (in pogosto tudi obratovanje) nekega programske opreme ali platforme — prav tega proizvoda. Običajno so majhna in hitra, do podjetij z obsežno birokracijo so še daleč. Prav tu se masovno pojavljajo tisti devops, kubermetniki, dokerski in druge strašne besede, ki bodo nujno naredile omrežje in mrežne inženirje za nepotreben relikt.
Kaj razlikuje mrežnega inženirja od sistemskega administratorja?
V razume ljudi, ki niso iz IT, ni nič posebnega. Oba, tako programer kot sistemski administrator, gledata v črn ekran in pišeta nekakšna zaklinjanja, občasno tiho prekletujeta.
V razumevanju programerjev pa se to lahko razume kot predmetno področje. Sistemci upravljajo strežnike, omrežni inženirji pa stikala in usmerjevalnike. Včasih ne upravljajo najbolje, kar pripelje do padca vsega. No, v primeru kakšnih nenavadnosti so krivi tudi omrežni inženirji. Just because fuck you, that’s why.
V resnici je glavna razlika v pristopu k delu. Morda je prav med omrežnimi inženirji največ simpatizerjev pristopa 'Če deluje, ga ne dotikaj!'. Nekaj narediti (v okviru enega ponudnika) običajno pomeni, da to lahko storiš le na en način, celotna konfiguracija naprave je tu, na dlani. Cena napake je visoka, včasih pa tudi zelo visoka (na primer, treba bo iti več sto kilometrov, da ponovno zaženeš usmerjevalnik, medtem ko bo brez povezave sedelo nekaj tisoč ljudi — povsem običajna situacija za ponudnika telekomunikacij).
Zato menim, da so omrežni inženirji z ene strani izjemno motivirani za stabilnost omrežja (spremembe so glavni sovražnik stabilnosti), z druge strani pa so njihova znanja bolj poglobljena kot široka (ni potrebno znati konfigurirati desetine različnih demonov, potrebno je poznati tehnologije in njihovo izvedbo pri določenem proizvajalcu opreme). Zato sistemski administrator, ki je našel, kako na Ciscu nastaviti VLAN, še ni omrežni inženir. In verjetno ne bo mogel učinkovito podpirati (in tako tudi reševati težave) bolj ali manj zapletenega omrežja.
Ampak zakaj sploh potrebujete omrežnega inženirja, če imate ponudnik gostovanja?
Za dodatno denar (ali če ste zelo veliki in priljubljen kupec, morda celo brezplačno, 'po prijateljsko') inženirji podatkovnega centra nastavijo vaša stikala po vaših potrebah in morda celo pomagajo vzpostaviti BGP-peering s ponudniki (če imate svojo podmrežo IP naslovov za oglas).
Osnovni problem je to što je data centar – to nije vaša IT služba, to je zasebna kompanija čiji je cilj ostvarivanje profita. Uključujući i putem vas, kao klijenta. Data centar pruža rackove, obezbeđuje im struju i hladnoću, kao i neku „podrazumevanu“ povezanost sa internetom. Na osnovu ove infrastrukture, data centar može smestiti vašu opremu (kolokacija), iznajmljivati vam server (iznajmljeni server), ili pružiti upravljanu uslugu (na primer, OpenStack ili K8s). Međutim, poslovanje data centra (obično) nije administracija infrastrukture klijenata, jer je taj proces prilično težak, slabo se automatizuje (a u normalnom data centru automatizovano je sve što je moguće), još gore se standardizuje (svaki klijent je jedinstven) i uopšte nosi rizike od pritužbi („naterali ste me da server konfigurišem i sada je pao, vi ste krivi!!!111“). Zato, ako vam ponuđač usluga bude pomagao u nečemu, trudiće se da to bude što jednostavnije i „uvuljivo“. Jer raditi teško – nije isplativo, barem sa stanovišta troškova rada inženjera tog istog ponuđača usluga (ali situacije su različite, vidi odricanje). To ne znači da ponuđač usluga obavezno sve radi loše. Ali nije ni izvesno da će uraditi upravo ono što vam je stvarno potrebno.
Naizgled, stvar je prilično očigledna, ali više puta sam se suočio u praksi sa situacijama kada su kompanije počele da se oslanjaju na svog hosting provajdera malo više nego što bi trebalo, što nikako nije vodilo do dobrih rezultata. Dugo i detaljno sam morao objašnjavati da nijedan SLA ne pokriva gubitke od zastoja (ima izuzetaka, ali obično je to veoma, VEOMA skupo za klijenta) i da hosting provajder generalno nije obavešten o onome što se dešava u infrastrukturi naručioca (osim vrlo opštih pokazatelja). A backupove hostera oni također ne rade umesto vas. Još gore je kada imate više od jednog hostinga. U slučaju nekih problema između njih, sigurno neće razjašnjavati za vas šta je zapravo pošlo po zlu.
Motivi so v tem primeru pravzaprav enaki kot pri izbiri "lastna ekipa skrbnikov vs. zunanje podjetje". Če so tveganja ocenjena, kakovost zadovoljiva in podjetje nima nič proti temu, zakaj ne bi poskusili. Po drugi strani pa je omrežje eden osnovnih slojev infrastrukture, zato ga verjetno ni smiselno prepustiti zunanjim izvajalcem, če že samostojno upravljate vse drugo.
Kdaj potrebujemo omrežnega inženirja?
Tukaj se bomo osredotočili na sodobna podjetja, ki ponujajo izdelke. Z operaterji in podjetji vseh velikosti je vse večinoma jasno — tam se v zadnjih letih ni veliko spremenilo, omrežni inženirji so bili potrebni v preteklosti, so potrebni tudi sedaj. Se pa s tistimi "mladimi in drznimi" zadeva ne zdi tako jasna. Pogosto celotno infrastrukturo postavljajo v oblake, zato sploh ne potrebujejo skrbnikov — razen skrbnikov teh oblakov, seveda. Infrastruktura je s svojega vidika precej preprosta, hkrati pa dobro avtomatizirana (ansible/puppet, terraform, ci/cd... no, verjetno že veste). Vendar pa obstajajo tudi situacije, ko je brez omrežnega inženirja težko.
Primer 1, klasičen
Predpostavimo, da podjetje začne z enim strežnikom s javnim ip naslovom, ki se nahaja v podatkovnem centru. Potem postaneta dva strežnika. Pozneje še več... Rano ali pozno se pojavi potreba po zasebnem omrežju med strežniki. Ker je "zunanji" promet omejen tako po pasovni širini (na primer ne več kot 100 Mbit/s) kot po količini prenesenih podatkov na mesec (različni gostitelji imajo različne cene, toda pasovna širina za zunanji promet je običajno precej dražja od zasebnega omrežja).
Gostitelj dodaja dodatne omrežne kartice v strežnike in jih povezuje s svojimi stikali v ločenem vlan-u. Med strežniki se ustvari "ploščata" lokalna mreža. Enostavno!
Število strežnikov se povečuje, prav tako tudi promet v zasebnem omrežju — varnostne kopije, replikacije itd. Hoster vam ponuja, da se preselite na ločene stikala, da ne bi motili drugih strank, in da oni ne bi motili vas. Hoster namesti nekatera stikala in jih nekako konfigurira — verjetno z enim samim ravnim omrežjem med vsemi vašimi strežniki. Vse deluje dobro, vendar v določenem trenutku začnejo nastajati težave: občasno se povečajo zamude med gostitelji, v dnevnikih so opozorila o prevelikem številu arp-paketov na sekundo, in pentester vam je pri reviziji prevzel celotno lokalno omrežje, ko je pokvaril le en strežnik.
Kaj je treba storiti?
Razdeliti omrežje na segmente — vlan-e. Nastaviti svojo naslovno shemo v vsakem vlan-u, dodeliti prehod, ki bo prenašal promet med omrežji. Na prehodu nastaviti acl za omejitev dostopa med segmenti ali postaviti ločen požarni zid.
Primer 1, nadaljevanje
Strežniki so povezani v lokalno omrežje z enim kablom. Stikala v omaricah so nekako povezana, vendar ob okvari v eni omarici padejo še tri sosednje. Diagrame obstajajo, vendar je njihova aktualnost vprašljiva. Vsak strežnik ima svojo javno naslov, ki ga dodeli hoster in je povezan z omarico. T.j. ob premiku strežnika je treba naslov spremeniti.
Kaj je treba storiti?
Povežite strežnike s pomočjo LAG (Link Aggregation Group) z dvema kabloma do stikal v omarici (tudi ta je treba rezervirati). Povezave med omaricami rezervirajte, preoblikujte v 'zvezdo' (ali moderen CLOS), da izpad ene omarice ne vpliva na druge. Dodelite 'centralne' omarice, v katerih bo nameščeno omrežno jedro, in kamor se bodo vključile druge omarice. Hkrati uredite javno naslovitev, pridobite od hosterja (ali od RIR, če je mogoče) podomrežje, ki ga boste sami (ali preko hosterja) napovedali v svet.
Ali lahko to stori 'navaden' sistemski administrator, ki nima globokega znanja o omrežjih? Nisem prepričan. Ali bo to storil hoster? Morda, a od vas bo zahteval precej podrobne tehnične specifikacije, ki jih bo prav tako treba nekdo sestaviti in nato nadzorovati, da bo vse naredil pravilno.
Primer 2. Oblak
Recimo, da imate VPC v nekem javnem oblaku. Da bi dobili dostop iz pisarne ali on-prem dela infrastrukture do lokalnega omrežja znotraj VPC, morate vzpostaviti povezavo prek IPSec ali namenskega kanala. Po eni strani je IPSec cenejši, saj ni treba kupovati dodatne opreme, lahko nastavite tunel med vašim strežnikom s javnim naslovom in oblakom. Vendar pa so tukaj zamude, omejena zmogljivost (ker je kanal potrebno šifrirati), poleg tega pa ni zagotovljene povezljivosti (ker dostop poteka prek običajnega interneta).
Kaj je treba storiti?
Vzpostavite povezavo prek namenskega kanala (na primer, pri AWS se to imenuje Direct Connect). Za to najdite partnerskega operaterja, ki vas bo povezoval, določite najbližjo točko priključka (tako za vas kot za operaterja v oblaku) in končno vse nastavite. Ali je to mogoče storiti brez mrežnega inženirja? Zelo verjetno, da. Vendar pa, kako to rešiti brez njega v primeru težav — to ni tako jasno.
Lahko se pojavijo tudi težave z dostopnostjo med oblakom (če imate multicloud) ali težave z zamudami med različnimi regijami itd. Nedvomno je sedaj na voljo veliko orodij, ki povečujejo preglednost dogajanja v oblaku (tisto, kar ponuja Thousand Eyes), vendar so to orodja mrežnega inženirja, ne pa njegova zamenjava.
Lahko bi navedel še deset takšnih primerov iz svoje prakse, a mislim, da je jasno, da bi moral biti v ekipi, ko infrastrukturna raven doseže določeno stopnjo razviti, človek (še bolje več kot en), ki ve, kako omrežje deluje, lahko nastavi omrežno opremo in reši težave, če se pojavijo. Verjemite, da bo imel dovolj dela.
Kaj mora znati mrežni inženir?
Nije nujno (in celo včasih škodljivo), da se mrežni inženir ukvarja samo z omrežjem in nič več. Tudi če ne upoštevamo možnosti infrastrukture, ki skoraj v celoti živi v javnem oblaku (kar postaja vse bolj priljubljeno), in se osredotočimo na primer na on-premise ali zasebne oblake, kjer s samimi 'znanji na ravni CCNP' ne bo šlo.
Poleg dejanskih omrežij – kjer je na voljo neskončno področje za raziskovanje, tudi če se osredotočimo le na eno področje (omrežja ponudnikov, podjetja, podatkovni centri, Wi-Fi…)
Seveda, mnogi iz vas se zdaj spomnijo Pythona in druge "avtomatizacije omrežja", vendar je to le potrebna, a ne zadostna pogoj. Da se omrežni inženir "uspešno vklopi v skupino", mora znati komunicirati tako z razvijalci kot s sodelavci administratorji/devops. Kaj to pomeni?
- znati ne le delati v Linuxu kot uporabnik, temveč ga tudi administrirati, vsaj na ravni junior sistemskega administratorja: namestiti potrebno programsko opremo, ponovno zagnati padlo storitev, napisati preprosto enoto systemd.
- Razumeti (vsaj na splošno), kako deluje omrežni sklad v Linuxu, kako je omrežje organizirano v hipervizorjih in kontejnerjih (lxc / docker / kubernetes).
- Seveda, znati delati z ansible/chef/puppet ali katerim koli drugim sistemom za upravljanje konfiguracij.
- Posebej je treba omeniti SDN in omrežja za zasebne oblake (kot je TungstenFabric ali OpenvSwitch). To je še en velik sklop znanja.
Na kratko sem opisal tipičnega T-shape strokovnjaka (kot se zdaj radi govori). Zdi se, da ni nič novega, vendar pa iz izkušenj z razgovori ni vse omrežne inženirje mogoče pohvaliti z znanjem vsaj na dveh temah s seznama zgoraj. V praksi pomanjkanje znanja "na sorodnih področjih" zelo oteži ne samo komunikacijo s sodelavci, ampak tudi razumevanje zahtev, ki jih podjetje postavlja do omrežja kot najnižjega nivoja infrastrukture projekta. Brez tega razumevanja postane težje argumentirano zagovarjati svoj stališče in "prodati" le-tega podjetju.
Po drugi strani pa navada "razumevanja, kako sistem deluje" daje omrežarjem zelo dobro prednost pred različnimi "širokokotnimi strokovnjaki", ki poznajo tehnologije po člankih na Habré/midiju in klepetih v Telegramu, vendar popolnoma ne vedo, na katerih načelih deluje tista ali druga programska oprema. Znanje nekaterih zakonitosti pa znano zlahka nadomesti poznavanje mnogih dejstev.
Zaključki ali preprosto TL;DR
- Mrežni administrator (poput DBA ili VoIP inženjera) je stručnjak prilično uskog profila (za razliku od sistemskih administratora/devopsa/SRE), čija potreba ne nastaje odmah (i može dugo vremena ne postojati, zapravo). No kada se ta potreba pojavi, teško da će je biti moguće zadovoljiti ekspertizom sa strane (outsourcing ili obični administratori širokog profila, „koji se bave i mrežom“). Nažalost, potreba za takvim stručnjacima je mala, i, условно, u firmi sa 800 programera i 30 devopsa/administratora može biti samo dvoje mrežnih stručnjaka koji savršeno obavljaju svoje dužnosti. Odnosno, tržište je bilo i ostalo vrlo, vrlo malo, a posebno kada je reč o dobrim platama — još manje.
- S druge strane, dobar mrežni stručnjak u modernom svetu mora znati ne samo mreže (i kako automatizovati njihovu konfiguraciju), nego i kako sa njima komuniciraju operativni sistemi i softver koji se pokreće preko tih mreža. Bez toga će biti izuzetno teško razumeti šta od tebe traže kolege i opravdano preneti svoje želje/zahtjeve njima.
- Ne postoji oblak, to je samo računar nekog drugog. Treba razumeti da korišćenje javnih/privatnih oblaka ili usluga hosting provajdera „koji sve radi umesto vas“ ne ukida to da vaša aplikacija još uvek koristi mrežu, i problemi sa njom će uticati na rad vaše aplikacije. Vaš izbor je gde će se nalaziti centar kompetencija koji će biti odgovoran za mrežu vašeg projekta.
Izvor: habr.com
