Осы мақаланы жазу кезінде танымал жұмыс сайтында «Желі инженері» деген тіркесті іздеу бүкіл Ресей бойынша үш жүзге жуық бос жұмыс орнын қайтарды. Салыстыру үшін, «жүйелік әкімші» тіркесін іздеу 2.5 мыңға жуық бос орынды, ал «DevOps инженері» - 800-ге жуық бос орынды береді.
Бұл жеңіске жеткен бұлттар, Docker, Kubernetes және жалпыға ортақ Wi-Fi кезінде желі қолданушылары енді қажет емес дегенді білдіре ме?
Оны анықтайық (c)
Танысайық. Менің атым Алексей, мен нетворкингпін.
Мен желілерде 10 жылдан астам уақыт бойы айналыстым және 15 жылдан астам әртүрлі *nix жүйелерімен жұмыс істеп келемін (мен Linux және FreeBSD екеуімен де айналысуға мүмкіндік алдым). Мен байланыс операторларында, «кәсіпорын» деп саналатын ірі компанияларда жұмыс істедім, ал жақында мен «жас және батыл» финтехте жұмыс істеймін, мұнда бұлттар, девоптер, кубернеттер және мені және менің әріптестерімді қажетсіз ететін басқа қорқынышты сөздер. . Бір күні. Мүмкін.
Жауапкершіліктен бас тарту: «Біздің өмірімізде бәрі әрқашан және барлық жерде емес, бірақ бірдеңе, кейде орындарда» (c) Максим Дорофеев.
Төменде жазылғандардың бәрі автордың түпкі ақиқат, тіпті толыққанды зерттеу деп санамайтын жеке пікірі деп санауға болады және қарастырылуы керек. Барлық кейіпкерлер ойдан шығарылған, барлық сәйкестіктер кездейсоқ.
Менің әлеміме қош келдіңіз.
Сіз тіпті сетевиктерді қай жерде кездестіре аласыз?
1. Байланыс операторлары, сервистік компаниялар және басқа да интеграторлар. Мұнда бәрі қарапайым: олар үшін желі бизнес. Олар қосылымды (операторларды) тікелей сатады немесе тұтынушыларының желілерін іске қосу/қолдау қызметтерін ұсынады.
Мұнда тәжірибе көп, бірақ ақша көп емес (егер сіз директор немесе табысты сату менеджері болмасаңыз). Дегенмен, егер сіз желілерді ұнатсаңыз және сіз саяхатыңыздың басында болсаңыз, кейбір өте үлкен емес операторды қолдаудағы мансап, тіпті қазірдің өзінде тамаша бастау нүктесі болады (федералдық желілерде бәрі өте сценарийленген және бар. шығармашылық үшін аз орын). Бірнеше жылдан кейін кезекші инженерден С деңгейлі менеджерге дейін қалай өсуге болатыны туралы әңгімелер де анық, сирек болса да, анық себептермен. Кадрларға деген қажеттілік әрқашан болады, өйткені ауыс-түйіс орын алады. Бұл бір уақытта жақсы және жаман - әрқашан бос орындар болады, екінші жағынан - көбінесе ең белсенді/ақылдылар көтерілуге немесе басқа «жылырақ» жерлерге тез кетеді.
2. Шартты «кәсіпорын». Оның негізгі қызметі IT саласына қатысты ма, жоқ па маңызды емес. Ең бастысы, оның компанияның ішкі жүйелерінің жұмысын, соның ішінде кеңселердегі желіні, филиалдарға байланыс арналарын және т.б. жұмысын қамтамасыз ететін өзінің IT бөлімі бар. Мұндай компаниялардағы желілік инженердің функцияларын жүйелік әкімші (егер желілік инфрақұрылым шағын болса немесе сыртқы мердігер басқаратын болса) «толық емес» жұмыс күнімен, ал егер бар болса, желі маманы орындай алады. бір уақытта телефония мен SAN жүйесіне назар аударыңыз (жақсы емес). Олар басқаша төлейді - бұл бизнестің табыстылығына, компанияның көлеміне және құрылымға байланысты. Мен Cisco жүйелері үнемі «бөшкелерге жүктелетін» компаниялармен және желі нәжістен, таяқшалардан және көк таспадан салынған және серверлері ешқашан жаңартылмайтын компаниялармен жұмыс істедім (айта кетудің қажеті жоқ, резервтер де қамтамасыз етілмеген). Мұнда тәжірибе әлдеқайда аз, және ол, әрине, қатаң сатушы-құлып немесе «жоқтан бір нәрсені қалай жасауға болады» аймағында болады. Жеке өзім оны өте қызық көрдім, бірақ бұл көптеген адамдарға ұнайды - бәрі өлшенетін және болжауға болатын (егер біз ірі компаниялар туралы айтатын болсақ), «дораха-бахато» және т.б. Жылына кем дегенде бір рет кейбір ірі жеткізушілер қазір барлығын автоматтандыратын және барлық жүйелік әкімшілер мен желішілерді таратып, әдемі интерфейсте түймелерді басуға ерлі-зайыптыларды қалдыратын тағы бір мега-супер-дупер жүйе ойлап тапқанын айтады. Шындығында, шешімнің құнын ескермесек те, сетевойшылар ешқайда кетпейді. Иә, мүмкін консольдің орнына қайтадан веб-интерфейс пайда болады (бірақ белгілі бір аппараттық құрал емес, аппараттық құралдың ондаған және жүздеген бөліктерін басқаратын үлкен жүйе), бірақ «ішінде бәрі қалай жұмыс істейтінін» білу әлі де болады. қажет болуы.
3. Өнім компаниялары, оның пайдасы қандай да бір бағдарламалық жасақтаманы немесе платформаны әзірлеуден (және, көбінесе, пайдаланудан) келеді - дәл сол өнімді. Әдетте олар шағын және епті, олар әлі де кәсіпорындардың ауқымынан және олардың бюрократизациясынан алшақ. Дәл осы жерде сол девоптер, куберлер, докерлер және басқа да қорқынышты сөздер жаппай кездеседі, бұл желі мен желі инженерлерін қажетсіз рудиментке айналдырады.
Жүйелік администратордан сетевойдың айырмашылығы неде?
Адамдардың түсінігінде IT емес - ештеңе. Екеуі де қара экранға қарап, небір сиқырларды жазады, кейде үнсіз балағат сөздер айтады.
Бағдарламашылардың түсінігінде - мүмкін пәндік сала бойынша. Жүйелік әкімшілер серверлерді басқарады, желішілер коммутаторлар мен маршрутизаторларды басқарады. Кейде әкімшілік нашар болады және барлығы үшін бәрі бұзылады. Біртүрлі болып қалса, желідегілер де кінәлі. Тек сені ренжіткенім үшін, сондықтан.
Шын мәнінде, басты айырмашылық - жұмысқа деген көзқарас. Мүмкін, сетевойшылардың арасында «Егер ол жұмыс істесе, оған қол тигізбе!» әдісін қолдаушылардың көпшілігі бар шығар. Әдетте, бір нәрсені (бір сатушыда) тек бір жолмен жасауға болады; қораптың барлық конфигурациясы алақанда болады. Қатенің құны жоғары, ал кейде өте жоғары (мысалы, маршрутизаторды қайта қосу үшін бірнеше жүз шақырым жол жүруге тура келеді, ал осы уақытта бірнеше мың адам байланыссыз қалады - байланыс операторы үшін өте қарапайым жағдай) .
Менің ойымша, сондықтан желілік инженерлер, бір жағынан, желі тұрақтылығына өте жоғары ынталы (және өзгеріс - тұрақтылықтың басты жауы), екіншіден, олардың білімдері кеңдігінен гөрі тереңірек (сіз емес) ондаған түрлі демондарды конфигурациялай білу қажет , сіз белгілі бір жабдық өндірушісінен технологияларды және оларды енгізуді білуіңіз керек). Сондықтан Cisco жүйесінде vlan қалай тіркеуге болатынын Google іздеген жүйелік әкімші әлі желі қолданушысы емес. Және оның азды-көпті күрделі желіге тиімді қолдау көрсетуі (сонымен қатар ақауларды жою) екіталай.
Бірақ хостинг болса, нетворка не үшін керек?
Қосымша ақша үшін (және егер сіз өте үлкен және сүйікті клиент болсаңыз, мүмкін тіпті тегін, «дос ретінде»), деректер орталығының инженерлері сіздің қажеттіліктеріңізге сәйкес коммутаторларды конфигурациялайды және тіпті провайдерлермен BGP интерфейсін орнатуға көмектесуі мүмкін. (хабарландыруға арналған IP мекенжайларының жеке ішкі желісі болса).
Басты мәселе, дата-орталық сіздің IT бөліміңіз емес, ол пайда табуды көздейтін жеке компания. Оның ішінде клиент ретінде сіздің есебінен. Деректер орталығы сөрелерді қамтамасыз етеді, оларды электрмен және суықпен қамтамасыз етеді, сонымен қатар Интернетке кейбір «әдепкі» қосылымды қамтамасыз етеді. Осы инфрақұрылымның негізінде деректер орталығы жабдықты орналастыра алады (колокация), сізге серверді жалға бере алады (арнайы сервер) немесе басқарылатын қызметті (мысалы, OpenStack немесе K8s) ұсына алады. Бірақ деректер орталығының бизнесі (әдетте) клиенттік инфрақұрылымды әкімшілендіру емес, өйткені бұл процесс айтарлықтай еңбекті қажет етеді, нашар автоматтандырылған (және қалыпты деректер орталығында мүмкін болатынның бәрі автоматтандырылған), одан да нашар (әрбір клиент) біріктірілген. жеке болып табылады) және әдетте шағымдарға толы («сіз маған сервер орнатылғанын айтасыз, бірақ қазір ол істен шықты, барлығына сіз кінәлісіз!!!111»). Сондықтан, егер үй иесі сізге бірдеңе көмектессе, ол оны мүмкіндігінше қарапайым және ыңғайлы етуге тырысады. Өйткені оны жасау қиын, кем дегенде, дәл сол хосттердің инженерлерінің еңбек шығындары тұрғысынан тиімсіз (бірақ жағдайлар басқаша, бас тартуды қараңыз). Бұл қожайын міндетті түрде бәрін нашар жасайды дегенді білдірмейді. Бірақ ол сізге шынымен қажет нәрсені жасайтыны мүлдем факт емес.
Бұл анық көрінетін сияқты, бірақ мен өз тәжірибемде бірнеше рет компаниялар өздерінің хостинг провайдерлеріне қажет болғаннан гөрі көбірек сене бастағанын кездестірдім және бұл жақсы ештеңе әкелмеді. Мен ұзақ және егжей-тегжейлі түсіндіруге тура келді, бірде-бір SLA тоқтап қалудан болатын шығындарды өтей алмайды (ерекшеліктер бар, бірақ әдетте бұл клиент үшін өте, өте қымбат) және хостинг бұл жерде не болып жатқанын мүлде білмейді. тұтынушылардың инфрақұрылымы (өте жалпы көрсеткіштерді қоспағанда). Хостер де сіз үшін сақтық көшірме жасамайды. Егер сізде бірнеше хосттар болса, жағдай одан да нашар. Олардың арасында қандай да бір проблемалар туындаған жағдайда, олар сізге ненің дұрыс емес екенін анықтай алмайды.
Шын мәнінде, мұндағы мотивтер «ішкі әкімші тобына қарсы аутсорсингті» таңдаумен бірдей. Тәуекелдер есептелсе, сапасы қанағаттанарлық болса және бизнес қарсы болмаса, неге оны байқамасқа. Екінші жағынан, желі инфрақұрылымның ең негізгі қабаттарының бірі болып табылады және егер сіз бәрін өзіңіз қолдасаңыз, оны сырттағы жігіттерге қалдырудың қажеті жоқ.
Сетевойнер қандай жағдайларда қажет?
Әрі қарай біз заманауи азық-түлік компаниялары туралы нақты айтатын боламыз. Операторлар мен кәсіпорында бәрі түсінікті, плюс немесе минус - соңғы жылдары ол жерде аз өзгерді, ал сетевойлар бұрын қажет болды, қазір де қажет. Бірақ сол «жас және батыл» нәрселер соншалықты анық емес. Көбінесе олар өздерінің барлық инфрақұрылымын бұлттарға орналастырады, сондықтан оларға әкімшілер шынымен де қажет емес - әрине, сол бұлттардың әкімшілерінен басқа. Инфрақұрылым, бір жағынан, дизайнында өте қарапайым, екінші жағынан, ол жақсы автоматтандырылған (ansible/puppet, terraform, ci/cd... жақсы, сіз білесіз). Бірақ мұнда да желі инженерінсіз жасай алмайтын жағдайлар бар.
1-мысал, классикалық
Компания деректер орталығында орналасқан жалпыға ортақ IP мекенжайы бар бір серверден басталды делік. Содан кейін екі сервер бар. Содан кейін көбірек... Ерте ме, кеш пе, серверлер арасында жеке желі қажет болады. Өйткені «сыртқы» трафик өткізу қабілеттілігімен де (мысалы, 100 Мбит/с аспайды) және айына жүктеп алынатын/жүктелетін көлемі бойынша да шектелгендіктен (әртүрлі хосттердің тарифтері әртүрлі, бірақ сыртқы әлемге өткізу қабілеті әдетте трафиктен әлдеқайда қымбат. жеке желі).
Хостер серверлерге қосымша желілік карталарды қосады және оларды бөлек вландағы коммутаторларына қосады. Серверлер арасында «жалпақ» жергілікті аймақ пайда болады. Ыңғайлы!
Серверлер саны өсуде, жеке желідегі трафик те өсуде - резервтік көшірмелер, репликациялар және т.б. Хостер сіз басқа клиенттерге және олар сізге кедергі жасамау үшін сізді бөлек қосқыштарға ауыстыруды ұсынады. Хостер кейбір қосқыштарды орнатады және қандай да бір жолмен оларды конфигурациялайды - ең алдымен, барлық серверлер арасында бір тегіс желі қалдырады. Барлығы жақсы жұмыс істейді, бірақ белгілі бір сәтте проблемалар басталады: хосттар арасындағы кідіріс мезгіл-мезгіл артады, журналдар секундына тым көп arp пакеттері туралы шағымданады және аудит кезінде пентестер бүкіл жергілікті желіңізді бұзып, тек бір серверді бұзды.
Не істеу керек?
Желіні сегменттерге бөліңіз - vlans. Әрбір vlan жүйесінде өзіңіздің адресіңізді конфигурациялаңыз, желілер арасында трафикті тасымалдайтын шлюзді таңдаңыз. Сегменттер арасындағы қатынасты шектеу үшін шлюздегі acl параметрін конфигурациялаңыз немесе тіпті жақын жерде бөлек брандмауэр орнатыңыз.
1-мысал, жалғасы
Серверлер жергілікті желіге бір сым арқылы қосылған. Тіректердегі ажыратқыштар бір-бірімен қандай да бір түрде қосылған, бірақ бір сөреде апат болса, тағы үш көршілес құлап кетеді. Схемалар бар, бірақ олардың өзектілігіне күмән бар. Әрбір серверде хосттер шығаратын және сөреге байланған жеке жалпы мекенжайы бар. Анау. Серверді жылжытқанда мекенжайды өзгерту керек.
Не істеу керек?
Серверлерді LAG (Link Aggregation Group) арқылы екі сым арқылы тіректегі ажыратқыштарға қосыңыз (олар да артық болуы керек). Бір тартпаның жоғалуы басқаларға әсер етпеуі үшін тіректер арасындағы қосылымдарды сақтап, оларды «жұлдызға» (немесе қазіргі сәнді CLOS) түрлендіріңіз. Желі өзегі орналасатын және басқа тіректер қосылатын «орталық» тіректерді таңдаңыз. Сонымен бірге, жалпыға ортақ адрестеуді ретке келтіріңіз, хосттерден (немесе мүмкін болса, RIR-ден) өзіңіз (немесе хост арқылы) әлемге жариялайтын ішкі желіні алыңыз.
Мұның бәрін желілерді терең білмейтін «қарапайым» жүйелік әкімші жасай ала ма? Сенімді емеспін. Үй иесі мұны істей ме? Мүмкін болады, бірақ сізге жеткілікті егжей-тегжейлі техникалық сипаттама қажет болады, оны біреу жасау керек. содан кейін бәрі дұрыс жасалғанын тексеріңіз.
2-мысал: Бұлт
Кейбір қоғамдық бұлтта VPC бар делік. Кеңседен немесе инфрақұрылымның жергілікті бөлігінен VPC ішіндегі жергілікті желіге қол жеткізу үшін IPSec немесе арнайы арна арқылы қосылымды конфигурациялау қажет. Бір жағынан, IPSec арзанырақ, өйткені қосымша жабдықты сатып алудың қажеті жоқ; жалпы мекенжайы бар сервер мен бұлт арасында туннель орнатуға болады. Бірақ - кешігулер, шектеулі өнімділік (арнаны шифрлау қажет болғандықтан), сонымен қатар кепілдіксіз қосылым (қолжетімділік кәдімгі Интернет арқылы болғандықтан).
Не істеу керек?
Қосылымды арнайы арна арқылы көтеріңіз (мысалы, AWS оны Direct Connect деп атайды). Мұны істеу үшін сізді байланыстыратын серіктес операторды табыңыз, сізге ең жақын қосылу нүктесін (операторға да, операторға да бұлтқа) шешіңіз және соңында бәрін реттеңіз. Осының бәрін желі инженерінсіз жасауға бола ма? Әрине иә. Бірақ проблемалар туындаған жағдайда онсыз ақауларды қалай жоюға болатыны соншалықты анық емес.
Сондай-ақ, бұлттар арасындағы қолжетімділікке қатысты мәселелер (егер сізде көп бұлтты болса) немесе әртүрлі аймақтар арасындағы кідірістерге қатысты мәселелер және т.б. болуы мүмкін. Әрине, қазір бұлтта болып жатқан нәрселердің мөлдірлігін арттыратын көптеген құралдар пайда болды (сол Мың көз), бірақ мұның бәрі оны алмастыратын емес, желілік инженердің құралдары.
Мен өз тәжірибемнен тағы оншақты мысал келтіре аламын, бірақ менің ойымша, командада инфрақұрылымды дамытудың белгілі бір деңгейінен бастап, желінің қалай жұмыс істейтінін білетін және конфигурациялай алатын адам (дұрысы біреу) болуы керек. желілік жабдықты орнатыңыз және олар туындаған жағдайда ақауларды реттеңіз. Маған сеніңіз, оның жұмысы болады
Желілік маман нені білуі керек?
Желілік инженерге тек желімен және басқа ештеңемен айналысу мүлдем қажет емес (тіпті кейде зиянды). Толығымен дерлік қоғамдық бұлтта өмір сүретін инфрақұрылымы бар опцияны қарастырмасақ та (және, не десек те, ол барған сайын танымал бола түсуде) және, мысалы, үй-жай немесе жеке бұлттарды алайық. «CCNP деңгейіндегі білім» бойынша «Сіз кетпейсіз.
Сонымен қатар, шын мәнінде, желілер - тек бір аймаққа (провайдер желілері, кәсіпорындар, деректер орталықтары, Wi-Fi ...) шоғырланған болсаңыз да, зерттеу үшін шексіз өріс бар болса да.
Әрине, көпшілігіңіз енді Python және басқа да «желілік автоматтандыруды» есте сақтайсыз, бірақ бұл тек қажетті, бірақ жеткілікті шарт емес. Желілік инженер «командаға сәтті қосылуы» үшін ол әзірлеушілермен де, басқа әкімшілермен/әзірлеушілермен де бір тілде сөйлей алуы керек. Бұл нені білдіреді?
- Linux жүйесінде пайдаланушы ретінде жұмыс істеп қана қоймай, сонымен қатар оны кем дегенде sysadmin-jun деңгейінде басқара алу: қажетті бағдарламалық жасақтаманы орнату, сәтсіз қызметті қайта іске қосу, қарапайым жүйелік блокты жазу.
- Linux жүйесінде желілік стек қалай жұмыс істейтінін, желі гипервизорлар мен контейнерлерде (lxc / docker / kubernetes) қалай жұмыс істейтінін түсініңіз (кем дегенде жалпы мағынада).
- Әрине, ansible/шеф/қуыршақ немесе басқа SCM жүйесімен жұмыс істей білу.
- Жеке бұлттарға арналған SDN және желілер туралы бөлек жол жазылуы керек (мысалы, TungstenFabric немесе OpenvSwitch). Бұл білімнің тағы бір үлкен қабаты.
Қысқасы, мен типтік Т-пішінді маманды сипаттадым (қазір айту сәнге айналғандай). Бұл жаңалық емес сияқты, бірақ сұхбат тәжірибесіне сүйене отырып, барлық желілік инженерлер жоғарыдағы тізімнен кем дегенде екі тақырыпты білуімен мақтана алмайды. Іс жүзінде «байланысты салаларда» білімнің болмауы әріптестермен қарым-қатынас жасауды ғана емес, сонымен қатар жобаның ең төменгі деңгейдегі инфрақұрылымы ретінде бизнестің желіге қоятын талаптарын түсінуді де қиындатады. Бұл түсініксіз өз көзқарасыңызды қорғау және оны бизнеске «сату» қиынырақ болады.
Екінші жағынан, «жүйенің қалай жұмыс істейтінін түсіну» әдеті желі қолданушыларына Habré/medium мақалаларынан және Telegram-дағы чаттардан технологиялар туралы білетін, бірақ не істеу керектігін мүлде білмейтін әртүрлі «жалпы мамандардан» өте жақсы артықшылық береді. осы немесе басқа бағдарламалық қамтамасыз ету принциптері бойынша жұмыс істейді ме? Ал белгілі бір заңдылықтарды білу, белгілі болғандай, көптеген фактілер туралы білімді сәтті ауыстырады.
Қорытынды немесе жай ғана TL; DR
- Желілік әкімші (мысалы, DBA немесе VoIP инженері) - бұл қажеттілік бірден туындамайтын (және ұзақ уақыт бойы туындамауы мүмкін) өте тар профилі бар маман (жүйелік әкімшілер/девтер/SRE-ден айырмашылығы) . Бірақ егер бұл орын алса, оны сыртқы сараптамамен алмастыру екіталай (аутсорсинг немесе «желіге де қарайтын» қарапайым жалпы мақсаттағы әкімшілер). Бір өкініштісі, мұндай мамандарға қажеттілік аз, және шартты түрде 800 программист пен 30 девоп/әкімшісі бар компанияда өз міндеттерін тамаша атқаратын екі ғана желілік қызметкер болуы мүмкін. Анау. нарық өте, өте кішкентай және жақсы жалақымен - одан да аз болды.
- Екінші жағынан, қазіргі әлемдегі жақсы сетевойшы тек желілердің өзін ғана емес (және олардың конфигурациясын қалай автоматтандыру керектігін), сонымен қатар осы желілердің үстінде жұмыс істейтін операциялық жүйелер мен бағдарламалық қамтамасыз етудің олармен қалай әрекеттесетінін білуі керек. Онсыз әріптестеріңіздің сізден не сұрап жатқанын түсіну және оларға өз тілектеріңізді/талаптарыңызды (ақылға қонымды) жеткізу өте қиын болады.
- Бұлт жоқ, ол басқа біреудің компьютері. Қоғамдық/жеке бұлттарды немесе хостинг провайдерінің қызметтерін пайдалану «сіз үшін барлығын кілт тапсыру негізінде жасайды» қолданбаңыздың әлі де желіні пайдаланатындығы фактісін өзгертпейтінін және онымен байланысты мәселелердің жұмысына әсер ететінін түсінуіңіз керек. сіздің өтінішіңіз. Сіздің таңдауыңыз – сіздің жобаңыздың желісіне жауап беретін құзырет орталығы қай жерде орналасады.
Ақпарат көзі: www.habr.com