V času pisanja tega članka je iskanje na priljubljenem spletnem mestu za zaposlovanje besedne zveze »omrežni inženir« vrnilo približno tristo prostih delovnih mest po vsej Rusiji. Za primerjavo, iskanje besedne zveze "sistemski skrbnik" vrne skoraj 2.5 tisoč prostih delovnih mest in "inženir DevOps" - skoraj 800.
Ali to pomeni, da omrežniki v času zmagovitih oblakov, Dockerja, Kubernetesa in vseprisotnega javnega Wi-Fi-ja niso več potrebni?
Ugotovimo (c)
Seznamimo se. Moje ime je Alexey in sem mrežnik.
Z omrežji se ukvarjam že več kot 10 let in več kot 15 let delam z različnimi *nix sistemi (imel sem priložnost poigravati se z Linuxom in FreeBSD). Delala sem v telekomunikacijskih operaterjih, velikih podjetjih, ki veljajo za “enterprise”, zadnje čase pa delam v “mladem in drznem” fintechu, kjer so oblaki, devops, kubernetes in druge strašne besede, ki bodo mene in moje sodelavce zagotovo naredile nepotrebne. . Nekega dne. Mogoče.
omejitev odgovornosti: "V našem življenju ni vse vedno in povsod, ampak nekaj, včasih na mestih" (c) Maxim Dorofeev.
Vse, kar je napisano spodaj, se lahko in mora obravnavati kot osebno mnenje avtorja, ki ne trdi, da je končna resnica, ali celo popolna študija. Vsi znaki so izmišljeni, vsa naključja so naključna.
Dobrodošli v moj svet.
Kje sploh lahko srečaš mrežerje?
1. Telekom operaterji, storitvena podjetja in drugi integratorji. Tukaj je vse preprosto: omrežje za njih je posel. Neposredno prodajajo povezljivost (operaterji) ali zagotavljajo storitve za zagon/vzdrževanje omrežij svojih strank.
Izkušenj je tukaj veliko, denarja pa malo (razen če si direktor ali uspešen vodja prodaje). In vendar, če imate radi omrežja in ste šele na začetku svoje poti, bo kariera v podporniku kakšnega manj velikega operaterja že zdaj idealno izhodišče (v zveznih je vse zelo skriptirano in tam je malo prostora za ustvarjalnost). No, zgodbe o tem, kako lahko iz dežurnega inženirja v nekaj letih zrasteš v C-level managerja, so tudi povsem resnične, čeprav redke, iz očitnih razlogov. Kadri so vedno potrebni, saj prihaja do fluktuacije. To je hkrati dobro in slabo - prosta delovna mesta so vedno, po drugi strani pa pogosto najbolj aktivni/pametni hitro odidejo bodisi zaradi napredovanja bodisi v druge, "toplejše" kraje.
2. Pogojno "podjetje". Ni pomembno, ali je njegova glavna dejavnost povezana z IT ali ne. Glavna stvar je, da ima lasten IT oddelek, ki zagotavlja delovanje notranjih sistemov podjetja, vključno z omrežjem v pisarnah, komunikacijskimi kanali do podružnic itd. Funkcije omrežnega inženirja v takšnih podjetjih lahko »honorarno« opravlja sistemski skrbnik (če je omrežna infrastruktura majhna ali jo skrbi zunanji izvajalec), omrežni specialist, če obstaja, pa lahko pri hkrati skrbi za telefonijo in SAN (ni dobro). Plačajo različno – v veliki meri je odvisno od donosnosti posla, velikosti podjetja in strukture. Delal sem s podjetji, kjer so bili sistemi Cisco redno »tovorjeni v sodih«, in s podjetji, kjer je bilo omrežje zgrajeno iz iztrebkov, palic in modrega traku, strežniki pa niso bili nikoli posodobljeni (ni treba posebej poudarjati, da tudi rezerv ni bilo). Tu je veliko manj izkušenj in skoraj zagotovo bo na področju strogega zaklepanja prodajalca ali »kako narediti nekaj iz nič«. Osebno se mi je zdelo zelo dolgočasno, čeprav je mnogim všeč - vse je precej odmerjeno in predvidljivo (če govorimo o velikih podjetjih), "dorakha-bahato" itd. Vsaj enkrat na leto kakšen večji prodajalec reče, da so si izmislili še en mega-super-duper sistem, ki bo zdaj vse avtomatiziral in se bodo vsi sistemski administratorji in omrežniki lahko razpršili, par pa jih bo pustilo pritiskati na gumbe v lepem vmesniku. Resničnost je taka, da omrežniki od tam ne bodo nikamor odšli, tudi če zanemarimo stroške rešitve. Ja, morda bo namesto konzole spet spletni vmesnik (vendar ne določen kos strojne opreme, ampak velik sistem, ki upravlja desetine in stotine takšnih kosov strojne opreme), a znanje o tem, "kako vse deluje notri" še vedno biti potreben.
3. Produktna podjetja, katerega dobiček izhaja iz razvoja (in pogosto delovanja) neke programske opreme ali platforme – tega istega izdelka. Ponavadi so majhna in spretna, še daleč od obsega podjetij in njihove birokratizacije. Tu se množično najdejo tisti isti devopi, kuberji, dokerji in ostale strašne besede, zaradi katerih bodo omrežje in omrežni inženirji zagotovo postali nepotreben rudiment.
Kako se omrežnik razlikuje od sistemskega skrbnika?
V razumevanju ljudi, ki niso iz IT - nič. Oba gledata v črni zaslon in pišeta nekaj urokov, včasih tiho preklinjata.
V razumevanju programerjev - morda po predmetnem področju. Sistemski skrbniki upravljajo strežnike, omrežniki upravljajo stikala in usmerjevalnike. Včasih je administracija slaba, pa se vsem vse podre. No, če je kaj čudnega, so krivi tudi omrežniki. Samo zato, ker se jebi, zato.
Pravzaprav je glavna razlika pristop k delu. Morda je prav med mrežniki največ zagovornikov pristopa »Če deluje, se ga ne dotikaj!«. Praviloma se lahko nekaj naredi (znotraj enega ponudnika) samo na en način, celotna konfiguracija škatle je na dlani. Cena napake je visoka in včasih zelo visoka (na primer, za ponovni zagon usmerjevalnika boste morali prevoziti več sto kilometrov in v tem času bo več tisoč ljudi brez komunikacije - precej pogosta situacija za telekomunikacijskega operaterja) .
Po mojem mnenju so zato omrežni inženirji po eni strani izredno visoko motivirani za stabilnost omrežja (in spremembe so glavni sovražnik stabilnosti), po drugi strani pa gre njihovo znanje bolj v globino kot v širino (ne znati morate konfigurirati na desetine različnih demonov, poznati morate tehnologije in njihovo implementacijo določenega proizvajalca opreme). Zato sistemski administrator, ki je googlal, kako registrirati vlan na sistemu Cisco, še ni omreževalec. In malo verjetno je, da bo lahko učinkovito podpiral (pa tudi odpravljal težave) bolj ali manj zapleteno omrežje.
Toda zakaj potrebujete omrežnika, če imate gostitelja?
Za dodaten denar (in če ste zelo velika in ljubljena stranka, morda celo brezplačno, »kot prijatelj«), bodo inženirji podatkovnega centra konfigurirali vaša stikala, da bodo ustrezala vašim potrebam, in vam morda celo pomagali vzpostaviti vmesnik BGP s ponudniki (če imate lastno podomrežje IP naslovov za objavo).
Glavna težava je, da podatkovni center ni vaš IT oddelek, je ločeno podjetje, katerega cilj je ustvarjanje dobička. Tudi na račun vas kot stranke. Podatkovni center zagotavlja stojala, jim zagotavlja elektriko in mraz ter omogoča tudi nekaj »privzete« povezave z internetom. Na podlagi te infrastrukture lahko podatkovni center gosti vašo opremo (kolokacija), vam odda strežnik (namenski strežnik) ali zagotovi upravljano storitev (na primer OpenStack ali K8s). A posel podatkovnega centra (običajno) ni administracija odjemalske infrastrukture, ker je ta proces precej delovno intenziven, slabo avtomatiziran (in v običajnem podatkovnem centru je vse mogoče avtomatizirano), še slabše poenoten (vsaka stranka je posamezen) in na splošno poln pritožb (»rečete mi, da je bil strežnik nastavljen, zdaj pa se je zrušil, za vse ste krivi vi!!!111«). Torej, če vam gostitelj pri nečem pomaga, bo poskušal narediti čim bolj preprosto in priročno. Ker je težko delati nedonosno, vsaj z vidika stroškov dela inženirjev tega istega gostitelja (vendar so situacije drugačne, glej izjavo o omejitvi odgovornosti). To ne pomeni, da bo gostitelj nujno naredil vse slabo. Vendar sploh ni dejstvo, da bo naredil točno tisto, kar resnično potrebujete.
Zdi se, da je stvar povsem očitna, vendar sem se v svoji praksi večkrat srečal s tem, da so se podjetja začela nekoliko bolj zanašati na svojega ponudnika gostovanja, kot bi se morala, kar pa ni vodilo v nič dobrega. Moral sem na dolgo in podrobno pojasnjevati, da niti en SLA ne bi pokril izgub zaradi izpadov (so izjeme, a običajno je to za stranko zelo, ZELO drago) in da se gostitelj sploh ne zaveda, kaj se dogaja v infrastruktura strank (razen zelo splošnih kazalnikov). In tudi gostitelj ne dela varnostnih kopij namesto vas. Situacija je še slabša, če imate več kot enega gostitelja. V primeru težav med njima zagotovo ne bosta ugotovila namesto vas, kaj je šlo narobe.
Pravzaprav so motivi tukaj popolnoma enaki kot pri izbiri "in-house admin team vs outsource". Če so tveganja izračunana, kakovost zadovoljiva in podjetja nimajo nič proti, zakaj ne bi poskusili. Po drugi strani pa je omrežje ena najosnovnejših plasti infrastrukture in komajda se ga splača prepustiti zunanjim fantom, če že vse ostalo podpiraš sam.
V katerih primerih je potreben mrežnik?
V nadaljevanju bomo govorili posebej o sodobnih živilskih podjetjih. Z operaterji in podjetji je vse jasno, plus ali minus - v zadnjih letih se je malo spremenilo in omrežniki so bili tam potrebni prej in so potrebni zdaj. Toda s temi istimi "mladimi in drznimi" stvari niso tako jasne. Pogosto svojo celotno infrastrukturo postavijo v oblake, tako da sploh ne potrebujejo skrbnikov – razen skrbnikov teh istih oblakov, seveda. Infrastruktura je po eni strani precej enostavna zasnova, po drugi strani pa dobro avtomatizirana (ansible/lutka, terraform, ci/cd... no, saj veste). Toda tudi tukaj obstajajo situacije, ko brez omrežnega inženirja ne morete.
Primer 1, klasičen
Recimo, da podjetje začne z enim strežnikom z javnim naslovom IP, ki se nahaja v podatkovnem centru. Potem sta tu dva strežnika. Potem pa več ... Prej ali slej bo potreba po zasebnem omrežju med strežniki. Ker je »zunanji« promet omejen s pasovno širino (na primer ne več kot 100 Mbit/s) in količino prenesenega/naloženega na mesec (različni gostitelji imajo različne tarife, vendar je pasovna širina v zunanji svet običajno veliko dražja od zasebno omrežje).
Gostitelj strežnikom doda dodatne omrežne kartice in jih vključi v svoja stikala v ločeni vlan. Med strežniki se prikaže "ravno" lokalno območje. Udobno!
Število strežnikov narašča, raste pa tudi promet na zasebnem omrežju - varnostne kopije, replikacije itd. Gostitelj vam ponudi, da vas premakne v ločena stikala, tako da ne motite drugih strank in oni ne motijo vas. Gostitelj namesti nekaj stikal in jih nekako konfigurira - najverjetneje pusti eno ravno omrežje med vsemi vašimi strežniki. Vse deluje dobro, vendar se v določenem trenutku začnejo težave: zamude med gostitelji se občasno povečajo, dnevniki se pritožujejo zaradi preveč paketov arp na sekundo, med revizijo pa je pentester zajebal vaše celotno lokalno omrežje in zlomil samo en strežnik.
Kaj naj storim?
Razdelite omrežje na segmente - vlane. Konfigurirajte svoje naslavljanje v vsakem vlan, izberite prehod, ki bo prenašal promet med omrežji. Konfigurirajte acl na prehodu, da omejite dostop med segmenti, ali celo namestite ločen požarni zid v bližini.
Primer 1, nadaljevanje
Strežnika sta v LAN povezana z enim kablom. Stikala v regalih so nekako povezana med seboj, če pa pride do nesreče v enem regalu, odpadejo še tri sosednja. Sheme obstajajo, vendar obstajajo dvomi o njihovi ustreznosti. Vsak strežnik ima svoj javni naslov, ki ga izda gostitelj in je vezan na stojalo. Tisti. Pri premikanju strežnika je treba spremeniti naslov.
Kaj naj storim?
Povežite strežnike s pomočjo LAG (Link Aggregation Group) z dvema kabloma na stikala v omari (tudi ti morajo biti redundantni). Rezervirajte povezave med regali in jih pretvorite v "zvezdo" (ali zdaj modni CLOS), tako da izguba enega regala ne vpliva na druge. Izberite “centralne” regale, v katerih bo locirano jedro omrežja in kamor bodo povezani drugi regali. Hkrati uredite javno naslavljanje, vzemite hosterju (ali RIR-u, če je možno) subnet, ki ga sami (ali preko hosterja) naznanite svetu.
Ali lahko vse to naredi "navaden" sistemski administrator, ki nima poglobljenega znanja o omrežjih? Nisem prepričan. Bo gostitelj to storil? Mogoče bo, vendar boste potrebovali precej natančno tehnično specifikacijo, ki jo bo moral nekdo tudi sestaviti. in nato preverite, ali je vse opravljeno pravilno.
Primer 2: Oblak
Recimo, da imate VPC v nekem javnem oblaku. Če želite pridobiti dostop iz pisarne ali lokalnega dela infrastrukture do lokalnega omrežja znotraj VPC, morate konfigurirati povezavo prek IPSec ali namenskega kanala. Po eni strani je IPSec cenejši, ker ni potrebe po nakupu dodatne strojne opreme, lahko nastavite tunel med strežnikom z javnim naslovom in oblakom. Toda - zamude, omejena zmogljivost (ker mora biti kanal šifriran), plus nezajamčena povezljivost (ker je dostop prek običajnega interneta).
Kaj naj storim?
Vzpostavite povezavo prek namenskega kanala (AWS na primer to imenuje Direct Connect). Za to poiščite partnerskega operaterja, ki vas bo povezal, se odločite za točko povezave, ki vam je najbližja (tako vi do operaterja kot operater do oblaka) in na koncu vse nastavite. Je vse to mogoče narediti brez omrežnega inženirja? Zagotovo da. Toda kako brez njega odpraviti težave v primeru težav, ni več tako jasno.
Lahko pride tudi do težav z razpoložljivostjo med oblaki (če imate multicloud) ali težave z zamudami med različnimi regijami itd. Seveda se je zdaj pojavilo veliko orodij, ki povečujejo preglednost dogajanja v oblaku (isti Tisoč oči), vendar so to vsa orodja omrežnega inženirja in ne njegova zamenjava.
Lahko bi naštel še ducat takšnih primerov iz svoje prakse, vendar mislim, da je jasno, da mora ekipa, začenši z določeno stopnjo razvoja infrastrukture, imeti osebo (po možnosti več kot eno), ki pozna delovanje omrežja in lahko konfigurira omrežno opremo in odpravite težave, če se pojavijo. Verjemite, imel bo kaj početi
Kaj mora vedeti mrežni sodelavec?
Sploh ni nujno (in celo včasih škodljivo), da se omrežni inženir ukvarja samo z omrežjem in nič drugega. Tudi če ne razmišljamo o možnosti z infrastrukturo, ki skoraj v celoti živi v javnem oblaku (in kakor koli že govorimo, postaja vse bolj priljubljena), in vzamemo na primer lokalne ali zasebne oblake, kjer o »samo znanju na ravni CCNP« »Ne boste odšli.
Poleg pravzaprav omrežij – čeprav je polja za študij preprosto neskončno, tudi če se osredotočite samo na eno področje (omrežja ponudnikov, podjetja, podatkovni centri, Wi-Fi ...)
Seveda se boste zdaj mnogi spomnili na Python in ostale “omrežne avtomatike”, vendar je to le nujen, ne pa tudi zadosten pogoj. Da bi se omrežni inženir »uspešno pridružil ekipi«, mora biti sposoben govoriti isti jezik tako z razvijalci kot s kolegi skrbniki/razvijalci. Kaj to pomeni?
- biti sposoben ne le delati v Linuxu kot uporabnik, ampak ga tudi upravljati, vsaj na ravni sysadmin-jun: namestiti potrebno programsko opremo, znova zagnati neuspešno storitev, napisati preprosto sistemsko enoto.
- Razumeti (vsaj na splošno), kako deluje omrežni sklad v Linuxu, kako deluje omrežje v hipervizorjih in vsebnikih (lxc / docker / kubernetes).
- Seveda lahko delate z ansible/chef/lutko ali drugim sistemom SCM.
- O SDN in omrežjih za zasebne oblake (na primer TungstenFabric ali OpenvSwitch) je treba napisati posebno vrstico. To je še en velik sloj znanja.
Na kratko sem opisal tipičnega specialista za obliko T (kot je zdaj moderno reči). Zdi se, kot da ni nič novega, a glede na izkušnje z intervjujev se vsi omrežni inženirji ne morejo pohvaliti s poznavanjem vsaj dveh tem z zgornjega seznama. V praksi pomanjkanje znanja »s sorodnih področij« močno oteži ne le komunikacijo s sodelavci, ampak tudi razumevanje zahtev, ki jih podjetje postavlja omrežju, kot najnižji ravni infrastrukture projekta. In brez tega razumevanja postane težje braniti svoje stališče in ga »prodati« podjetju.
Po drugi strani pa ista navada »razumevanja delovanja sistema« daje omrežnikom zelo dobro prednost pred raznimi »generalisti«, ki o tehnologijah vedo iz člankov na Habré/medium in klepetov na Telegramu, nimajo pa prav nič pojma, kako kaj po katerih načelih deluje ta ali ona programska oprema? In poznavanje določenih vzorcev, kot je znano, uspešno nadomešča poznavanje številnih dejstev.
Zaključki, ali samo TL;DR
- Omrežni skrbnik (kot je DBA ali VoIP inženir) je strokovnjak s precej ozkim profilom (za razliko od sistemskih skrbnikov/razvijalcev/SRE), potreba po katerem se ne pojavi takoj (in se morda ne pojavi dolgo časa). . Če pa se pojavi, ga verjetno ne bodo nadomestili zunanji strokovnjaki (zunanji izvajalci ali navadni splošni skrbniki, »ki skrbijo tudi za omrežje«). Bolj žalostno je to, da je potreba po takšnih strokovnjakih majhna, pogojno pa sta v podjetju z 800 programerji in 30 devops/administratorji lahko samo dva mrežniška, ki odlično opravljata svoje obveznosti. Tisti. trg je bil in je zelo, zelo majhen, z dobro plačo pa še manj.
- Po drugi strani pa mora dober omrežnik v sodobnem svetu poznati ne samo omrežja sama (in kako avtomatizirati njihovo konfiguracijo), temveč tudi, kako operacijski sistemi in programska oprema, ki delujejo na vrhu teh omrežij, sodelujejo z njimi. Brez tega bo izjemno težko razumeti, kaj vaši sodelavci zahtevajo od vas, in jim (razumno) posredovati svoje želje/zahteve.
- Oblaka ni, je samo računalnik nekoga drugega. Zavedati se morate, da uporaba javnih/zasebnih oblakov ali storitev ponudnika gostovanja, »ki namesto vas naredi vse na ključ«, ne spremeni dejstva, da vaša aplikacija še vedno uporablja omrežje, težave z njim pa bodo vplivale na delovanje vašo prijavo. Vaša izbira je, kje bo lociran kompetenčni center, ki bo odgovoren za mrežo vašega projekta.
Vir: www.habr.com