Artikulu hau idazteko garaian, "Sareko ingeniaria" esaldiaren lan-gune ezagun batean bilaketak Errusia osoan hirurehun lanpostu huts itzuli zituen. Konparazio baterako, "sistema administratzailea" esaldiaren bilaketak ia 2.5 mila lanpostu huts itzultzen ditu eta "DevOps ingeniaria" - ia 800.
Horrek esan nahi al du saregileak ez direla beharrezkoak garaile hodeien, Dockerren, Kubernetesen eta nonahiko Wi-Fi publikoen garaietan?
Azter dezagun (c)
Ezagutzen gaitezen. Nire izena Alexey da, eta saregilea naiz.
10 urte baino gehiago daramatzat sareetan parte hartzen eta 15 urte baino gehiago daramatzat *nix sistema ezberdinekin lanean (Linux zein FreeBSDrekin txukuntzeko aukera izan nuen). Telekomunikazio-operadoreetan lan egin nuen, "enpresatzat" jotzen diren enpresa handietan, eta azkenaldian fintech "gazte eta ausartetan" lan egiten ari naiz, non hodeiak, devops, kubernetes eta ni eta nire lankideek behin betiko alferrikako bihurtuko dituzten beste hitz beldurgarriak. . Egunen batean. Agian.
oharra: "Gure bizitzan, dena ez da beti eta nonahi, baina zerbait, batzuetan lekuetan" (c) Maxim Dorofeev.
Jarraian idatzitako guztia egilearen iritzi pertsonaltzat har daiteke eta hartu behar da, eta horrek ez du aldarrikatzen azken egia denik, ezta azterketa oso bat ere. Pertsonaia guztiak fikziozkoak dira, kasualitate guztiak ausazkoak dira.
Ongi etorri nire mundura.
Non ezagutu ditzakezu sareko arduradunak?
1. Telekomunikazio-operadoreak, zerbitzu-enpresak eta bestelako integratzaileak. Hemen dena erraza da: haientzat sarea negozio bat da. Konektibitatea (operadoreak) zuzenean saltzen dute edo bezeroen sareak abiarazteko/mantentzeko zerbitzuak eskaintzen dituzte.
Esperientzia handia dago hemen, baina ez diru asko (zuzendaria edo salmenta-zuzendari arrakastatsua izan ezean). Eta, hala ere, sareak gustatzen bazaizkizu, eta zure bidaiaren hasieran besterik ez bazara, oso handi ez diren operadore batzuen aldeko karrera bat izango da, orain ere, abiapuntu aproposa (federaletan dena oso gidoia da, eta hor sormenerako leku gutxi dago). Beno, urte gutxitan zerbitzuan dagoen ingeniari izatetik C-mailako kudeatzaile izatera nola haz zaitezkeen istorioak ere nahiko errealak dira, arraroak badira ere, arrazoi argiengatik. Beti dago langileen beharra, fakturazioa gertatzen baita. Hau ona eta txarra da aldi berean -beti daude lanpostu hutsak, bestalde-, askotan aktibo/adimentsuenak azkar irteten dira promoziora edo beste leku “beroagoetara”.
2. Baldintzapeko "enpresa". Berdin du bere jarduera nagusia informatikarekin lotuta dagoen ala ez. Garrantzitsua da bere informatika saila duela, eta horrek enpresaren barne sistemen funtzionamendua bermatzen du, bulegoetako sarea barne, bulegoetarako komunikazio bideak, etab. Horrelako enpresetan sare-ingeniari baten funtzioak "lanaldi partzialean" egin ditzake sistema-administratzaile batek (sare-azpiegitura txikia bada edo kanpoko kontratatzaile batek kudeatzen badu), eta sareko espezialista batek, baldin badago, egin dezake. aldi berean telefonia eta SAN zaindu (ez da ona). Ezberdin ordaintzen dute - negozioaren errentagarritasunaren, enpresaren tamainaren eta egituraren araberakoa da. Cisco sistemak aldizka "upeletan kargatuta" zeuden enpresekin lan egin nuen, eta sarea gorotz, makila eta zinta urdinez eraikitzen zen enpresekin, eta zerbitzariak ez ziren inoiz eguneratzen (esan beharrik ez zegoen erreserbarik ere ez zela ematen). Askoz esperientzia gutxiago dago hemen, eta ia ziur saltzaileen blokeo zorrotzaren arloan izango da, edo "zerbait ezerezetik nola egin". Pertsonalki, oso aspergarria iruditu zait, jende askori gustatzen zaion arren - dena nahiko neurtua eta aurreikusgarria da (enpresa handiez ari bagara), "dorakha-bahato", etab. Gutxienez urtean behin, saltzaile garrantzitsu batzuek dio beste mega-super-duper sistema bat sortu dutela orain dena automatizatuko duena eta sistemaren administratzaile eta sareko arduradun guztiak sakabanatu daitezkeela, pare bat botoiak sakatu behar direla interfaze eder batean. Errealitatea da, nahiz eta konponbidearen kostua alde batera utzi, saregileak ez direla hortik inora joango. Bai, beharbada kontsolaren ordez berriro web interfaze bat egongo da (baina ez hardware zehatz bat, halako hamarnaka eta ehunka hardware kudeatzen dituen sistema handi bat baizik), baina "barruan dena nola funtzionatzen duen" jakitea izango da oraindik. behar izan.
3. Produktu enpresak, zeinaren irabazia software edo plataforma batzuen garapenetik (eta, sarritan, funtzionamendutik) - produktu hori bera. Normalean txikiak eta arinak dira, oraindik urrun daude enpresen eskalatik eta haien burokratizaziotik. Hemen aurkitzen dira devops, cubers, dockers eta beste hitz ikaragarri horiek masiboki, eta horrek, zalantzarik gabe, sare eta sareko ingeniariak alferrikako rudiment bihurtuko ditu.
Zertan desberdintzen da sareko arduraduna sistema-administratzaile batekin?
Jendearen ulermenean ez ITtik - ezer ez. Biek pantaila beltzari begiratu eta sorginkeria batzuk idazten dituzte, batzuetan isil-isilik zin eginez.
Programatzaileen ulermenean, agian gaiaren arabera. Sistema-administratzaileek zerbitzariak administratzen dituzte, sareko arduradunek etengailuak eta bideratzaileak administratzen dituzte. Batzuetan administrazioa txarra da, eta dena erortzen da guztiontzat. Bada, ezer arrarorik balego, saregileak ere errudunak dira. Izorratu zaituztelako, horregatik.
Izan ere, desberdintasun nagusia lanaren ikuspegia da. Beharbada, saregileen artean daude “funtzionatzen badu, ez ukitu!” planteamenduaren aldeko gehien. Oro har, zerbait egin daiteke (saltzaile baten barruan) modu bakarrean; kutxaren konfigurazio osoa zure esku-ahurrean dago. Errore baten kostua altua da, eta batzuetan oso altua (adibidez, ehunka kilometro egin beharko dituzu bideratzailea berrabiarazteko, eta une honetan hainbat mila pertsona egongo dira komunikaziorik gabe - telekomunikazio-operadore baten egoera nahiko ohikoa da) .
Nire ustez, horregatik sareko ingeniariak, alde batetik, sarearen egonkortasunerako oso motibatuta daude (eta aldaketa da egonkortasunaren etsai nagusia), eta, bestetik, haien ezagutza zabalera baino sakonago doa (ez duzu dozenaka deabru ezberdin konfiguratu ahal izan behar dituzu, teknologiak eta horien ezarpena ekipo-fabrikatzaile zehatz batetik ezagutu behar dituzu). Horregatik, Cisco sisteman vlan bat nola erregistratu Googlen bilatu zuen sistema-administratzaile bat ez da oraindik saregilea. Eta zaila da sare konplexuago edo gutxiago bati modu eraginkorrean laguntzeko (baita arazoak konpontzeko ere).
Baina zergatik behar duzu networker bat ostalari bat baduzu?
Diru gehigarri baten truke (eta bezero oso handia eta maitea bazara, agian doan ere, "lagun gisa"), datu-zentroko ingeniariek zure etengailuak konfiguratuko dituzte zure beharretara egokitzeko, eta agian hornitzaileekin BGP interfaze bat ezartzen lagunduko dizute. (iragarpenerako zure IP helbideen azpisarea baduzu).
Arazo nagusia da datu-zentroa ez dela zure IT saila, enpresa bereizi bat da eta bere helburua irabaziak lortzea da. Bezero gisa zure kontura barne. Datu-zentroak bastidoreak eskaintzen ditu, elektrizitatea eta hotza eskaintzen die eta Interneterako konexio "lehenetsia" ere eskaintzen du. Azpiegitura horretan oinarrituta, datu-zentroak zure ekipoak (kokapena) osta ditzake, zerbitzari bat alokatu (zerbitzari dedikatua) edo kudeatutako zerbitzu bat eskain dezake (adibidez, OpenStack edo K8s). Baina datu-zentro baten negozioa (normalean) ez da bezeroaren azpiegituraren administrazioa, prozesu hau nahiko lan-eskaintza delako, gaizki automatizatua (eta datu-zentro normal batean posible dena automatizatuta dago), are okerrago bateratua (bezero bakoitza). banakakoa da) eta, oro har, kexaz beteta ("zerbitzaria konfiguratuta zegoela esaten didazu, baina orain huts egin du, zure errua da!!!111"). Hori dela eta, ostalariak zerbaitetan laguntzen badizu, ahalik eta errazena eta erosoena izaten saiatuko da. Zaila egitea ez delako errentagarria, ostalari bereko ingeniarien lan-kostuen ikuspuntutik behintzat (baina egoerak desberdinak dira, ikus oharra). Horrek ez du esan nahi ostalariak nahitaez dena gaizki egingo duenik. Baina ez da batere egia benetan behar duzuna egingo duenik.
Badirudi gauza nahiko begi-bistakoa dela, baina nire praktikan hainbat aldiz topatu dut konpainiak behar baino apur bat gehiago fidatzen hasi zirela beren hosting hornitzailean, eta horrek ez zuela ezer onik ekarri. Luze eta zehatz-mehatz azaldu behar izan nuen SLA bakar batek ere ez zituela etenaldietako galerak estaliko (salbuespenak daude, baina normalean oso-OSO garestia da bezeroarentzat) eta ostalaria ez dela batere jakitun gertatzen denaz. bezeroen azpiegiturak (oso adierazle orokorrak izan ezik). Eta ostalariak ere ez dizu babeskopiak egiten. Egoera are okerragoa da ostalari bat baino gehiago badituzu. Haien artean arazoren bat izanez gero, zalantzarik gabe, ez dizute jakingo zer gertatu den gaizki.
Egia esan, hemen arrazoiak "barneko administrazio taldea vs azpikontratazioa" aukeratzerakoan berdinak dira. Arriskuak kalkulatzen badira, kalitatea asegarria da, eta negozioak ez dio axola, zergatik ez probatu. Bestalde, sarea azpiegitura geruza oinarrizkoenetakoa da, eta nekez merezi du kanpoko mutilen esku uzteak beste guztia zuk zeuk onartzen baduzu.
Zein kasutan behar da saregile bat?
Jarraian, zehazki, elikagaien enpresei buruz hitz egingo dugu. Operadoreekin eta enpresekin, dena argi dago, gehi edo ken; ezer gutxi aldatu da bertan azken urteotan, eta saregileak behar ziren bertan, eta orain beharrezkoak dira. Baina “gazte eta ausart” horiekin gauzak ez daude hain argi. Sarritan azpiegitura osoa hodeietan jartzen dute, beraz, ez dute administratzailerik ere behar, hodei horietako administratzaileak izan ezik, noski. Azpiegitura, alde batetik, nahiko sinplea da bere diseinuan, bestetik, ondo automatizatuta dago (ansible/puppet, terraform, ci/cd... bueno, badakizu). Baina hemen ere sare ingeniaririk gabe egin ezin duzun egoerak daude.
1. adibidea, klasikoa
Demagun enpresa bat IP helbide publikoa duen zerbitzari batekin hasten dela, datu-zentro batean dagoena. Ondoren, bi zerbitzari daude. Gero gehiago... Lehenago edo beranduago, zerbitzarien arteko sare pribatu baten beharra izango da. “Kanpoko” trafikoa mugatuta dagoelako bai banda zabaleraren arabera (ez 100 Mbit/s baino gehiago, adibidez) bai hilean deskargatu/kargatutako bolumenaren arabera (ostalari ezberdinek tarifa desberdinak dituzte, baina kanpoko mundurako banda zabalera normalean askoz garestiagoa da. sare pribatua).
Ostalariak sare-txartel gehigarriak gehitzen dizkie zerbitzariei eta haien etengailuetan sartzen ditu vlan bereizi batean. Zerbitzarien artean tokiko eremu "laua" agertzen da. Eroso!
Zerbitzari kopurua hazten ari da, eta sare pribatuko trafikoa ere hazten ari da - kopiak, erreplikak, etab. Ostalariak etengailu bereizietara eramatea eskaintzen dizu, beste bezeroekin oztopatu ez dezazun, eta haiek zurekin ez oztopatzeko. Ostalariak etengailu batzuk instalatzen ditu eta nolabait konfiguratzen ditu - ziurrenik, zure zerbitzari guztien artean sare lau bat utziz. Dena ondo funtzionatzen du, baina momentu jakin batean arazoak hasten dira: ostalarien arteko atzerapenak aldian-aldian handitzen dira, erregistroak segunduko arp pakete gehiegi kexatzen dira eta auditoria batean pentester-ak zure sare lokal osoa izorratu zuen, zerbitzari bakarra hautsiz.
Zer egin beharko litzateke?
Banatu sarea segmentuetan - vlan. Konfiguratu zure helbidea vlan bakoitzean, hautatu sareen arteko trafikoa transferituko duen atebide bat. Konfiguratu acl atebidean segmentuen arteko sarbidea mugatzeko, edo gertuko suebaki bat ere instalatu.
1. adibidea, jarraitu
Zerbitzariak LANera konektatuta daude kable batekin. Rack-etako etengailuak elkarren artean konektaturik daude nolabait, baina rack batean istripu bat gertatzen bada, aldameneko beste hiru erortzen dira. Eskemak badaude, baina zalantzak daude haien garrantziari buruz. Zerbitzari bakoitzak bere helbide publikoa du, ostalariak igorritakoa eta rack-era lotuta dagoena. Horiek. Zerbitzari bat mugitzean, helbidea aldatu behar da.
Zer egin beharko litzateke?
Konektatu zerbitzariak LAG (Link Aggregation Group) erabiliz bi kablerekin rack-eko etengailuetara (erredundanteak izan behar dute). Erreserbatu bastidoreen arteko konexioak eta bihurtu "izar" (edo orain modan dagoen CLOS), rack bat galtzeak besteei eragin ez diezaion. Hautatu sareko nukleoa kokatuko den eta beste bastidore batzuk konektatuko diren "zentral" bastidoreak. Aldi berean, jarri zuzenketa publikoa, hartu ostalaritik (edo RIRetik, ahal bada) azpisare bat, zuk zeuk (edo ostalariaren bitartez) munduari iragartzen diona.
Hau guztia sareen ezagutza sakona ez duen sistema-administratzaile “arrunt” batek egin al dezake? Ez ziur. Ostalariak hau egingo al du? Agian hala izango da, baina zehaztapen tekniko nahiko zehatza beharko duzu, norbaitek ere egin beharko duena. eta gero egiaztatu dena ondo eginda dagoela.
2. adibidea: Hodeia
Demagun hodei publiko batean VPC bat duzula. Bulegotik edo azpiegituraren zati lokaletik VPC barruko sare lokalera sarbidea lortzeko, konexio bat konfiguratu behar duzu IPSec edo kanal dedikatu baten bidez. Alde batetik, IPSec merkeagoa da, zeren ez da hardware gehigarririk erosi behar; zure zerbitzariaren artean tunel bat konfigura dezakezu helbide publiko batekin eta hodeiarekin. Baina - atzerapenak, errendimendu mugatua (kanala enkriptatu behar baita), eta bermatu gabeko konexioa (sarbidea Internet arruntaren bidez egiten baita).
Zer egin beharko litzateke?
Sortu konexio bat kanal dedikatu baten bidez (adibidez, AWS-k Direct Connect deitzen dio). Horretarako, bilatu konektatuko zaituen operadore bazkide bat, zuregandik gertuen dagoen konexio-puntua erabaki (bai operadorea eta operadorea hodeiarekiko) eta, azkenik, konfiguratu dena. Posible al da hori guztia sare ingeniaririk gabe egitea? Seguru bai. Baina arazoen kasuan bera gabe nola konpondu, ez dago hain argi.
Hodeien arteko erabilgarritasunarekin ere arazoak egon daitezke (hodei anitzeko bat baduzu) edo eskualde ezberdinen arteko atzerapenekin arazoak, etab. Noski, orain hodeian gertatzen ari denaren gardentasuna areagotzen duten tresna asko agertu dira (Mila begi bera), baina horiek guztiak sare ingeniari baten tresnak dira, eta ez haren ordezkoak.
Nire praktikatik horrelako dozena bat adibide gehiago zirriborra nezake, baina uste dut argi dagoela taldeak, azpiegituren garapen maila jakin batetik abiatuta, sarea nola funtzionatzen duen eta konfiguratu dezakeen pertsona bat (ahal bada bat baino gehiago) izan behar duela. sareko ekipoak eta arazoak konpontzea sortzen badira. Sinets iezadazu, zer eginik izango du
Zer jakin behar du saregile batek?
Ez da batere beharrezkoa (eta baita ere, batzuetan, kaltegarria) sareko ingeniari batek sarearekin soilik jorratzea eta kito. Nahiz eta ia osorik hodei publikoan bizi den azpiegitura baten aukera kontuan hartzen ez badugu (eta, esan daitekeena, gero eta ezagunagoa dena), eta hartu, adibidez, hodei lokaletan edo pribatuetan, non. "CCNP mailako ezagutza bakarrik" "Ez zara utziko.
Sareez gain, hain zuzen ere, aztertzeko eremu amaigabea den arren, eremu batean bakarrik zentratu arren (hornitzaileen sareak, enpresak, datu-zentroak, Wi-Fi...)
Jakina, zuetako askok Python eta beste "sare-automatizazioa" gogoratuko dituzue, baina hau baldintza beharrezkoa baino ez da, baina ez nahikoa. Sare-ingeniari batek "taldera arrakastaz sartzeko", hizkuntza bera hitz egin behar du garatzaileekin eta administratzaile/garatzaileekin. Zer esan nahi du?
- Linux-en erabiltzaile gisa lan egiteko ez ezik, administratzeko ere gai izan, gutxienez sysadmin-jun mailan: instalatu beharrezko softwarea, huts egin duen zerbitzu bat berrabiarazi, sistema-unitate sinple bat idatzi.
- Ulertu (termino orokorrean behintzat) nola funtzionatzen duen sare pila Linux-en, nola funtzionatzen duen sareak hipervisoreetan eta edukiontzietan (lxc / docker / kubernetes).
- Jakina, ansible/chef/puppet edo beste SCM sistema batekin lan egin ahal izatea.
- Aparteko lerro bat idatzi behar da SDNri eta hodei pribatuetarako sareei buruz (adibidez, TungstenFabric edo OpenvSwitch). Hau beste ezagutza geruza handi bat da.
Laburbilduz, T-formako espezialista tipiko bat deskribatu nuen (orain esatea modan dagoen bezala). Ezer berria dirudi, baina elkarrizketa-esperientzian oinarrituta, sareko ingeniari guztiek ezin dute goiko zerrendako gutxienez bi gairen ezagutzaz harro. Praktikan, "lotutako eremuetan" ezagutza faltak oso zaila egiten du lankideekin komunikatzea ez ezik, negozioak sarean jartzen dituen eskakizunak ulertzea ere, proiektuaren maila baxueneko azpiegitura gisa. Eta ulertu gabe, zailagoa egiten da zure ikuspuntua defendatzea eta negozioei "saltzea".
Bestalde, "sistemak nola funtzionatzen duen ulertzeko" ohitura berberak abantaila handia ematen die sareko arduradunei, Habré/medium-eko artikuluetatik eta Telegram-eko txatetatik teknologien berri duten hainbat "generalisten" aldean, baina zertan den ideiarik ez dakiten. printzipioetan funtzionatzen du software honek edo besteek? Eta eredu jakin batzuen ezagutzak, jakina denez, arrakastaz ordezkatzen du gertakari askoren ezagutza.
Ondorioak, edo besterik gabe TL;DR
- Sare-administratzailea (DBA edo VoIP ingeniari bat bezala) profil nahiko estua duen espezialista bat da (sistema administratzaileak/garatzaileak/SRE ez bezala), eta horren beharra ez da berehala sortzen (eta baliteke denbora luzez ez egotea, hain zuzen ere) . Baina sortzen bada, nekez ordezkatuko dute kanpoko adituek (subkontratatu edo erabilera orokorreko administratzaile arruntek, “sarea ere zaintzen dutenak”). Zertxobait tristeagoa da horrelako espezialisten beharra txikia dela, eta, baldintzatuta, 800 programatzaile eta 30 devop/administratzaile dituen enpresa batean, baliteke bi saregile baino ez izatea beren ardurak lan bikaina egiten dutenak. Horiek. merkatua oso-oso txikia zen eta da, eta soldata onarekin —are gutxiago—.
- Bestalde, mundu modernoko saregile on batek sareak berak ez ezik (eta haien konfigurazioa nola automatizatu), sare horien gainean exekutatzen diren sistema eragileak eta softwareak haiekin nola elkarreragiten ere ezagutu behar du. Hori gabe, oso zaila izango da zure lankideek zuri eskatzen dizutena ulertzea eta zure nahiak/eskakizunak transmititzea (zentzuz).
- Ez dago hodeirik, beste norbaiten ordenagailua da. Ulertu behar duzu hodei publiko/pribatuak edo ostalaritza-hornitzaile baten zerbitzuak erabiltzeak "giltza eskuan dena egiten dizuna" ez duela aldatzen zure aplikazioak sarea oraindik erabiltzen duela, eta arazoek funtzionamenduan eragina izango dute. zure aplikazioa. Zure aukera da konpetentzia zentroa non kokatuko den, zure proiektuaren sareaz arduratuko dena.
Iturria: www.habr.com