Во моментот на пишување, пребарувањето на популарната локација за работа за фразата „Мрежен инженер“ покажа околу триста слободни работни места низ Русија. За споредба, пребарувањето за фразата „системски администратор“ враќа речиси 2.5 илјади слободни работни места, а „инженер DevOps“ - речиси 800.
Дали ова значи дека вмрежувачите повеќе не се потребни во деновите на победничките облаци, докер, кубернети и сеприсутниот јавен Wi-Fi?
Ајде да го сфатиме (и)
Ајде да се запознаеме. Моето име е Алексеј, и јас сум вмрежувач.
Јас се занимавам со вмрежување повеќе од 10 години и работам со различни *nix системи повеќе од 15 години (имав шанса да ги одберам и Linux и FreeBSD). Работев во телекомуникациски оператори, големи компании, кои се сметаат за „претпријатија“, а од неодамна работам и во „млади и смели“ финтех, каде облаци, девопс, кубернети и други застрашувачки зборови што дефинитивно ќе ме натераат мене и моите колеги непотребни. Некој ден. Можеби.
одрекување: „Во нашиот живот, не сè, секогаш и секаде, туку нешто, понекогаш на места“ (в) Максим Дорофеев.
Сè што е напишано подолу може и треба да се смета за лично мислење на авторот, не тврдејќи дека е крајната вистина, па дури и полноправна студија. Сите ликови се фиктивни, сите коинциденции се случајни.
Добредојдовте во мојот свет.
Каде можете да најдете мрежни работници?
1. Телеком оператори, услужни компании и други интегратори. Сè е едноставно: мрежата за нив е бизнис. Тие или директно продаваат поврзување (оператори) или обезбедуваат услуги за лансирање/одржување на мрежите на нивните клиенти.
Овде има големо искуство, но не многу пари (освен ако не сте директор или успешен менаџер за продажба). А сепак, ако сакате мрежи, а вие сте само на почетокот на вашето патување, кариерата за поддршка на некој не многу голем оператор ќе биде, дури и сега, идеална почетна точка (сè е многу напишано во федералните, и таму е малку простор за креативност). Па, приказните за фактот дека е можно да се прерасне од дежурен инженер за неколку години до менаџер на Ц-ниво се исто така сосема реални, иако ретки, од очигледни причини. Секогаш има потреба од кадри, бидејќи се уште има промет. Ова е и добро и лошо во исто време - секогаш има слободни места, од друга страна - често најактивните/паметните доволно брзо или добиваат унапредување или одат на други, „потопли“ места.
2. Условно „претпријатие“. Не е важно дали неговата основна дејност е поврзана со ИТ или не. Главната работа е што има свој оддел за ИТ, кој е ангажиран во обезбедувањето на работата на внатрешните системи на компанијата, вклучувајќи мрежи во канцеларии, канали за комуникација до филијали итн. Функциите на мрежен инженер во такви компании може да ги извршува „со скратено работно време“ од системски администратор (ако мрежната инфраструктура е мала, или во неа е ангажиран надворешен изведувач), а менаџерот на мрежата, доколку сè уште постои, може внимавајте на телефонијата и САН во исто време (не нуачо). Тие плаќаат на различни начини - тоа силно зависи од маржата на бизнисот, големината на компанијата и структурата. Работев и со компании каде што циско редовно се „натоваруваа во буриња“, и со компании каде што мрежата беше изградена од измет, стапови и сина електрична лента, а серверите не беа ажурирани, приближно, никогаш (потребно е да се каже дека таму немаше ниту резерви) . Овде има многу помалку искуство, и речиси сигурно ќе биде во областа на цврста брава на продавачот, или „како да се направи нешто од ништо“. Лично, таму ми се чинеше диво досадно, иако на многумина им се допаѓа - сè е прилично мерено и предвидливо (ако зборуваме за големи компании), „дора-бајато“ итн. Барем еднаш годишно, некои големи продавачи велат дека дошле до друг мега-супер-дупер систем кој автоматизира сè сега и сите системски администратори и вмрежувачи може да се оверклокуваат, оставајќи неколку да притискаат копчиња во прекрасен интерфејс. Реалноста е дека, дури и ако ги игнорираме трошоците за решението, мрежните лица нема да одат никаде од таму. Да, можно е наместо конзолата повторно да има веб-интерфејс (но не одредено парче железо, туку голем систем кој управува со десетици и стотици такви парчиња железо), но знаење за „како се работи внатре “ сепак ќе биде потребно.
3. Компании за производи, чиј профит доаѓа од развојот (и, често, работењето) на некој софтвер или платформа - токму тој производ. Обично тие се мали и пргави, се уште се далеку од обемот на претпријатијата и нивната бирократизација. Токму овде истите тие девопови, кубери, докери и други страшни зборови се наоѓаат во голем број што сигурно ќе ги направат мрежните и мрежните инженери непотребен зачеток.
Како мрежниот менаџер се разликува од sysadmin?
Во разбирањето на луѓето не од ИТ - ништо. И двајцата гледаат во црниот екран и пишуваат некои магии, понекогаш тивко пцуејќи.
Во разбирањето на програмерите - можеби предметната област. Sysadmins администрира сервери, networkers администрира прекинувачи и рутери. Некогаш админот е лош, и на сите им паѓа се. Па, во случај на некое чудно, виновни се и мрежерите. Само затоа што те ебам, затоа.
Всушност, главната разлика е пристапот кон работата. Можеби, меѓу вмрежувачите најмногу има поддржувачи на пристапот „Работи - не допирајте го!“. Обично можете да направите нешто (во рамките на еден продавач) само на еден начин, целата конфигурација на кутијата - тука е, на дланка. Цената на грешката е висока, а понекогаш и многу висока (на пример, треба да патувате неколку стотици километри за да го рестартирате рутерот, а во тоа време неколку илјади луѓе ќе останат без комуникација - ситуација што е доста вообичаена за телекомуникацискиот оператор ).
Според мое мислење, затоа мрежните инженери, од една страна, се исклучително силно мотивирани за стабилноста на мрежата (а промените се главниот непријател на стабилноста), и второ, нивното знаење оди повеќе во длабочина отколку во ширина (не ви треба за да можете да конфигурирате десетици различни демони, треба да ги знаете технологиите и нивната имплементација од одреден производител на опрема). Затоа системскиот администратор, кој гуглаше како да регистрира влан на циска, сè уште не е менаџер на мрежа. И малку е веројатно дека тој ќе може ефективно да поддржи (како и да решава проблеми) повеќе или помалку сложена мрежа.
Но, зошто ви е потребен мрежен менаџер ако имате хостер?
За дополнителни пари (и ако сте многу голем и сакан клиент, можеби дури и бесплатно, „како пријател“), инженерите на центрите за податоци ќе ги конфигурираат вашите прекинувачи за да одговараат на вашите потреби и, можеби, дури и ќе помогнат да се подигне интерфејсот BGP со провајдери (ако имате сопствена подмрежа на ip адреси за објавување).
Главниот проблем е што центарот за податоци не е ваш ИТ оддел, тоа е посебна компанија чија цел е да оствари профит. Вклучително и на сметка на вас како клиент. Центарот за податоци обезбедува лавици, им обезбедува струја и студ, а исто така дава одредена „стандардна“ конекција на Интернет. Врз основа на оваа инфраструктура, центарот за податоци може да ја ко-лоцира вашата опрема (колокација), да ви изнајми сервер (посветен сервер) или да обезбеди управувана услуга (на пример, OpenStack или K8s). Но, работата на центарот за податоци (обично) не е администрација на клиентска инфраструктура, бидејќи овој процес е прилично трудоинтензивен, слабо автоматизиран (а во нормален центар за податоци сè е автоматизирано), унифициран уште полошо (секој клиент е индивидуален) и генерално полн со тврдења („ти ми кажуваш дека серверот е поставен, а сега падна, се е твоја вина!!!111“). Затоа, ако домаќинот ќе ви помогне со нешто, тогаш тој ќе се обиде да го направи што е можно поедноставно и „кондо“. Зашто е тешко да се направи - непрофитабилно, барем од гледна точка на трошоците за работна сила на инженерите на овој хостер (но ситуациите се различни, видете го одрекувањето). Ова не значи дека домаќинот нужно ќе направи сè лошо. Но, воопшто не е факт дека тој ќе го направи токму она што навистина ви требаше.
Се чини дека работата е сосема очигледна, но неколку пати во мојата пракса наидов на фактот дека компаниите почнаа да се потпираат на нивниот хостинг провајдер малку повеќе отколку што треба, и тоа не доведе до ништо добро. Беше потребно долго време детално да се објасни дека ниту еден SLA нема да ги покрие загубите во застој (има исклучоци, но обично е многу, МНОГУ скапо за клиентот) и дека хостерот воопшто не е свесен што се случува во инфраструктурата на клиентите (освен многу општи показатели). А и хостерот не ти прави бекап. Ситуацијата е уште полоша ако имате повеќе од еден хостер. Во случај на какви било проблеми меѓу нив, тие сигурно нема да ви откријат што тргнало наопаку.
Всушност, мотивите овде се сосема исти како и при изборот на „сопствен тим од администратори наспроти аутсорсинг“. Ако ризиците се пресметани, квалитетот одговара, а на бизнисот не му пречи - зошто да не го пробате. Од друга страна, мрежата е еден од најосновните слоеви на инфраструктурата и едвај вреди да се даде на надворешни лица, ако веќе сам поддржувате сè друго.
Кога ви треба вмрежувач?
Понатаму, ќе се фокусираме на модерни производствени компании. Со операторите и претпријатијата, сè е плус или минус јасно - малку е променето таму во последниве години, а вмрежувачите беа потребни таму порано, потребни се сега. Но, со тие многу „млади и смели“ работите не се толку едноставни. Честопати тие ја сместуваат својата инфраструктура целосно во облаците, па дури и не им требаат администратори, освен администраторите на истите тие облаци, се разбира. Инфраструктурата, од една страна, е прилично едноставна во дизајнот, од друга страна, е добро автоматизирана (ансибилна / кукла, тераформа, ci / cd ... добро, знаете). Но, дури и овде има ситуации кога не можете без мрежен инженер.
Пример 1, класичен
Да претпоставиме дека компанијата започнува со еден сервер со јавна IP-адреса, која се наоѓа во центарот за податоци. Потоа има два сервери. Потоа повеќе... Порано или подоцна, има потреба од приватна мрежа помеѓу серверите. Бидејќи „надворешниот“ сообраќај е ограничен и од пропусниот опсег (не повеќе од 100 Mbps, на пример) и од количината на преземени / поставени месечно (различни хостери имаат различни тарифи, но пропусниот опсег кон надворешниот свет, по правило, е многу поскапо од приватна мрежа).
Хостерот додава дополнителни мрежни картички на серверите и ги вклучува во нивните прекинувачи во посебен vlan. Се појавува „рамна“ LAN мрежа помеѓу серверите. Удобно!
Расте бројот на сервери, расте и сообраќајот во приватната мрежа - бекап, репликации итн. Хостерот нуди да ве премести на одделни прекинувачи за да не се мешате со другите клиенти, а тие да не ви пречат. Хостерот става некакви прекинувачи и некако ги конфигурира - најверојатно, оставајќи една рамна мрежа помеѓу сите ваши сервери. Сè работи добро, но во одреден момент започнуваат проблемите: одложувањата помеѓу домаќините периодично растат, дневниците пцујат премногу пакети Arp во секунда, а петестерот ја силувал целата ваша локална област за време на ревизијата, кршејќи само еден сервер.
Што треба да направам?
Поделете ја мрежата на сегменти - vlans. Поставете ваше сопствено адресирање во секој vlan, изберете порта што ќе пренесува сообраќај помеѓу мрежите. На портата, конфигурирајте acl за да го ограничите пристапот помеѓу сегментите или дури да ставите посебен заштитен ѕид до него.
Пример 1, продолжува
Серверите се поврзани со локалната област со еден кабел. Прекинувачите во решетките се некако меѓусебно поврзани, но во случај на несреќа во една решетка, паѓаат уште три соседни. Шеми постојат, но постојат сомнежи за нивната релевантност. Секој сервер има своја јавна адреса, која ја издава домаќинот и е врзана за решетката. Оние. при преместување на серверот, адресата треба да се смени.
Што треба да направам?
Поврзете ги серверите користејќи LAG (Група за агрегација на врски) со два кабли со прекинувачите во решетката (тие исто така треба да бидат вишок). Резервирајте ги врските меѓу решетките, преправете ги со „ѕвезда“ (или сега модерен CLOS) за губењето на едната решетка да не влијае на другите. Изберете „централни“ решетки каде ќе се наоѓа јадрото на мрежата и каде ќе бидат вклучени други полици. Во исто време, редете го јавното обраќање, земете од хостерот (или од RIR, ако е можно) подмрежа, која вие самите (или преку хостерот) ја објавувате на светот.
Може ли „обичен“ системски администратор кој нема длабоко познавање на мрежите да го направи сето ова? Не е сигурно. Дали домаќинот ќе го направи тоа? Можеби ќе биде така, но ќе ви треба прилично детален TOR, кој исто така ќе треба да го состави некој. а потоа проверете дали се е направено правилно.
Пример 2: Облачно
Да претпоставиме дека имате VPC во некој јавен облак. За да добиете пристап до локалната мрежа во VPC од канцеларискиот или делот од инфраструктурната преработка, треба да поставите врска преку IPSec или посветен канал. Од една страна, IPSec е поевтин. нема потреба да купувате дополнителен хардвер, можете да поставите тунел помеѓу вашиот сервер со јавна адреса и облакот. Но - одложувања, ограничени перформанси (бидејќи каналот треба да се шифрира), плус негарантирано поврзување (бидејќи пристапот оди преку редовниот Интернет).
Што треба да направам?
Подигнете ја врската преку посветен канал (на пример, AWS го нарекува Direct Connect). За да го направите ова, најдете партнер-оператор кој ќе ве поврзе, одлучува за точката на поврзување што е најблиску до вас (и вие во операторот и операторот во облакот) и, конечно, ќе постави сè. Дали сето ова може да се направи без мрежен инженер? Сигурно, да. Но, како да се решат проблемите без него во случај на проблеми веќе не е толку јасно.
И, исто така, може да има проблеми со достапноста помеѓу облаците (ако имате мултиоблак) или проблеми со доцнење помеѓу различни региони, итн. Се разбира, сега има многу алатки кои ја зголемуваат транспарентноста на она што се случува во облакот (истите Thousand Eyes), но сите овие се алатки за мрежен инженер, а не замена.
Би можел да скицирам уште десетина такви примери од мојата пракса, но мислам дека е јасно дека во тимот, почнувајќи од одредено ниво на развој на инфраструктурата, треба да има човек (или подобро, повеќе од еден) кој знае како мрежата работи, може да ја конфигурира мрежната опрема и да се справи со проблемите доколку се појават. Верувај ми, тој ќе има што да прави
Што треба да знае вмрежувачот?
Воопшто не е потребно (па дури и понекогаш штетно) мрежен инженер да се занимава само со мрежата и ништо друго. Дури и ако не ја разгледаме опцијата со инфраструктура која живее речиси целосно во јавен облак (и, што и да се каже, станува сè попопуларна), и да земеме, на пример, во простории или приватни облаци, каде што само „Знаење на ниво на CCNP „Нема да заминете.
Покрај, всушност, мрежите - иако има едноставно бескрајно поле за проучување, дури и ако се концентрирате само на една насока (мрежи на добавувачи, претпријатија, центри за податоци, Wi-Fi ...)
Се разбира, многумина од вас сега ќе се сеќаваат на Python и друга „мрежна автоматизација“, но ова е само неопходен, но не и доволен услов. За да може мрежен инженер „успешно да се приклучи на тимот“, тој мора да може да го зборува истиот јазик и со програмерите и со колегите администратори / развивачи. Што значи тоа?
- да може не само да работи во Linux како корисник, туку и да го администрира, барем на ниво на sysadmin-junior: инсталирај го потребниот софтвер, рестартирајте ја паднатата услуга, напишете едноставна системска единица.
- Разберете (барем во општи термини) како работи мрежниот стек во Linux, како работи мрежата во хипервизори и контејнери (lxc / docker / kubernetes).
- Се разбира, бидете способни да работите со ansible/chef/puppet или друг SCM систем.
- Треба да се напише посебна линија за SDN и мрежи за приватни облаци (на пример, TungstenFabric или OpenvSwitch). Ова е уште едно големо знаење.
Накратко, опишав типичен специјалист за форма на Т (како што е сега модерно да се каже). Се чини дека не е ништо ново, меѓутоа, според искуството од интервјуата, не сите мрежни инженери можат да се пофалат со познавање на најмалку две теми од горната листа. Во пракса, недостатокот на знаење „во сродни области“ ја отежнува не само комуникацијата со колегите, туку и разбирањето на барањата што бизнисот ги наметнува на мрежата како инфраструктура на најниско ниво на проектот. И без ова разбирање, станува потешко разумно да ја одбраните вашата гледна точка и да ја „продадете“ на бизнисот.
Од друга страна, самата навика „да се разбере како функционира системот“ им дава многу добра предност на вмрежувачите во однос на разните „генералисти“ кои знаат за технологиите од написите на Habré/медиумите и телеграмските разговори, но немаат апсолутно никаква идеја на кои принципи е ова или тој софтвер работи. А познавањето на некои законитости, како што знаете, успешно го заменува знаењето за многу факти.
Заклучоци, или едноставно TL;DR
- Мрежен администратор (како DBA или VoIP инженер) е специјалист со прилично тесен профил (за разлика од sysadmins / devops / SRE), чија потреба не се појавува веднаш (и може да не се појави долго време, всушност) . Но, ако се појави, тогаш веројатно нема да биде заменето со надворешна експертиза (аутсорсинг или обични генералистички администратори, „кои исто така се грижат за мрежата“). Она што е нешто потажно е што потребата од такви специјалисти е мала и, условно, во компанија со 800 програмери и 30 devops/admins, може да има само двајца вмрежувачи кои совршено си ја вршат работата. Оние. пазарот беше и е многу, многу мал, а уште помалку со добра плата.
- Од друга страна, добар вмрежувач во современиот свет треба да ги знае не само самите мрежи (и како да ја автоматизира нивната конфигурација), туку и како оперативните системи и софтверот комуницираат со нив, кои работат преку овие мрежи. Без ова, ќе биде исклучително тешко да разберете што бараат колегите од вас и да им ги пренесете (разумно) вашите желби / барања.
- Нема облак, тоа е само туѓ компјутер. Треба да разберете дека употребата на јавни / приватни облаци или услугите на давателите на хостинг „кои прават сè за вас“ не го негира фактот дека вашата апликација сè уште ја користи мрежата, а проблемите со неа ќе влијаат на работата на вашата апликација . Вашиот избор е каде ќе биде сместен центарот за компетентност, кој ќе биде одговорен за мрежата на вашиот проект.
Извор: www.habr.com