Мрежови (не) необходими

По време на писането на тази статия търсенето в популярен сайт за работа на фразата „мрежов инженер“ даде около триста свободни работни места в цяла Русия. За сравнение, търсенето на фразата "системен администратор" връща почти 2.5 хиляди свободни позиции, а "DevOps инженер" - почти 800.

Означава ли това, че мрежовиците вече не са необходими в дните на печелившите облаци, докер, kubernetis и вездесъщия обществен Wi-Fi?
Нека да го разберем (c)

Да се ​​запознаем. Казвам се Алексей и съм мрежовик.

Занимавам се с мрежи повече от 10 години и работя с различни *nix системи повече от 15 години (имах възможност да избера и Linux, и FreeBSD). Работил съм в телекомуникационни оператори, големи компании, които се смятат за „предприятия“, а отскоро работя в „млади и дръзки“ финтех, където облаци, devops, kubernetes и други страшни думи, които определено ще накарат мен и колегите ми ненужни. Някой ден. Може би.

отказ от отговорност: „В нашия живот не всичко, винаги и навсякъде, но нещо, понякога на места“ (c) Максим Дорофеев.

Всичко, написано по-долу, може и трябва да се счита за лично мнение на автора, без да претендира за истина от последна инстанция и дори за пълноценно изследване. Всички герои са измислени, всички съвпадения са случайни.

Добре дошли в моя свят.

Къде можете да намерите мрежи?

1. Телекомуникационни оператори, компании за услуги и други интегратори. Всичко е просто: мрежата за тях е бизнес. Те или директно продават свързаност (оператори), или предоставят услуги за стартиране/поддържане на мрежите на своите клиенти.

Тук има много опит, но не много пари (освен ако не сте директор или успешен мениджър продажби). И все пак, ако харесвате мрежи и сте едва в началото на пътуването си, кариерата в поддръжка на някой не много голям оператор ще бъде дори сега идеална отправна точка (във федералните всичко е много скриптирано и там има малко място за творчество). Е, историите за това, че е възможно да израснеш от дежурен инженер за няколко години до C-ниво мениджър, също са съвсем реални, макар и рядко, по обясними причини. Винаги има нужда от кадри, защото все още има текучество. Това е и добре, и лошо едновременно - винаги има свободни места, от друга страна - често най-активните/умните достатъчно бързо или се повишават, или отиват на други, "по-топли" места.

2. Условно "предприятие". Няма значение дали основната му дейност е свързана с ИТ или не. Основното е, че разполага със собствен ИТ отдел, който се занимава с осигуряването на работата на вътрешните системи на компанията, включително мрежи в офиси, комуникационни канали към клонове и др. Функциите на мрежов инженер в такива компании могат да се изпълняват "на непълно работно време" от системен администратор (ако мрежовата инфраструктура е малка или в нея е ангажиран външен изпълнител), а мрежовият мениджър, ако все още съществува, може гледам телефония и SAN едновременно (не nuacho). Плащат по различни начини - силно зависи от маржа на бизнеса, големината на компанията и структурата. Работих както с фирми, където cisco редовно се „зареждаха в варели“, така и с компании, където мрежата беше изградена от изпражнения, клечки и синя електрическа лента, а сървърите не бяха актуализирани, приблизително, никога (трябва да кажа, че има също нямаше резерви). Тук има много по-малко опит и почти сигурно ще бъде в областта на твърдото заключване на доставчика или „как да направим нещо от нищо“. Лично на мен ми се стори ужасно скучно там, въпреки че много хора го харесват - всичко е доста премерено и предвидимо (ако говорим за големи компании), „дора-баджато“ и т.н. Поне веднъж годишно някой голям доставчик казва, че са измислили друга мега-супер-дупер система, която автоматизира всичко сега и всички системни администратори и мрежови специалисти могат да бъдат овърклокнати, оставяйки няколко да натискат бутони в красив интерфейс. Реалността е, че дори и да пренебрегнем цената на решението, мрежовиците няма да отидат никъде оттам. Да, възможно е вместо конзолата отново да има уеб интерфейс (но не конкретно желязо, а голяма система, която управлява десетки и стотици такива железа), но знания за това „как работи всичко вътре ” все още ще са необходими.

3. Продуктови компании, чиято печалба идва от разработването (и често от експлоатацията) на някакъв софтуер или платформа – точно този продукт. Обикновено те са малки и пъргави, все още са далеч от мащаба на предприятията и тяхната бюрократизация. Именно тук същите тези devops, cubers, dockers и други ужасни думи се срещат в големи количества, които със сигурност ще превърнат мрежата и мрежовите инженери в ненужен рудимент.

Как се различава мрежовият мениджър от системния администратор?

В разбирането на хората, които не са от ИТ - нищо. И двамата гледат черния екран и пишат някакви заклинания, понякога тихичко псуват.

В разбирането на програмистите - може би предметната област. Сисадмините администрират сървъри, мрежовите служители администрират суичове и рутери. Понякога администраторът е лош и всичко се проваля за всички. Е, в случай на странно, мрежовиците също са виновни. Само защото майната ти, ето защо.

Всъщност основната разлика е подходът към работата. Може би сред мрежовите специалисти има най-много привърженици на подхода „Работи - не го докосвайте!“. Обикновено можете да направите нещо (в рамките на един доставчик) само по един начин, цялата конфигурация на кутията - ето я, на дланта ви. Цената на грешка е висока, а понякога и много висока (например, трябва да изминете няколкостотин километра, за да рестартирате рутера, и в този момент няколко хиляди души ще останат без комуникация - ситуация, която е доста често срещана за телеком оператор ).

Според мен това е причината, поради която мрежовите инженери, от една страна, са изключително силно мотивирани за стабилност на мрежата (а промените са основният враг на стабилността), и второ, знанията им отиват повече в дълбочина, отколкото в ширина (не ви трябва за да можете да конфигурирате десетки различни демони, трябва да знаете технологиите и тяхното внедряване от конкретен производител на оборудване). Ето защо системният администратор, който гугли как да регистрира vlan на tsiska, все още не е мрежов мениджър. И е малко вероятно той да може ефективно да поддържа (както и да отстранява неизправности) повече или по-малко сложна мрежа.

Но защо ви е необходим мрежов мениджър, ако имате хостър?

Срещу допълнителни пари (и ако сте много голям и обичан клиент, може би дори безплатно, „като приятел“), инженерите на центъра за данни ще конфигурират вашите комутатори, за да отговарят на вашите нужди и може би дори ще ви помогнат да създадете BGP интерфейс с доставчици (ако имате собствена подмрежа от ip адреси за обявяване).

Основният проблем е, че центърът за данни не е вашият ИТ отдел, това е отделна компания, чиято цел е печалба. Включително и за Ваша сметка като клиент. Центърът за данни предоставя стелажи, осигурява им електричество и студ, а също така дава някаква свързаност по "подразбиране" с интернет. Въз основа на тази инфраструктура центърът за данни може да разположи вашето оборудване (колокация), да ви наеме сървър (специализиран сървър) или да предостави управлявана услуга (например OpenStack или K8s). Но бизнесът на центъра за данни (обикновено) не е администриране на клиентска инфраструктура, защото този процес е доста трудоемък, слабо автоматизиран (а в нормален център за данни всичко е автоматизирано), още по-лошо унифициран (всеки клиент е индивидуален) и като цяло изпълнен с претенции („казвате ми, че сървърът е бил настроен и сега се е сринал, вината е изцяло ваша!!!111“). Следователно, ако домакинът ще ви помогне с нещо, тогава той ще се опита да го направи възможно най-просто и „кондо“. Защото е трудно да се направи - нерентабилно, поне от гледна точка на разходите за труд на инженерите на този хостър (но ситуациите са различни, вижте отказа от отговорност). Това не означава, че домакинът непременно ще направи всичко лошо. Но изобщо не е факт, че той ще направи точно това, от което наистина се нуждаете.

Изглежда, че нещо е съвсем очевидно, но няколко пъти в моята практика се натъкнах на факта, че компаниите започнаха да разчитат на своя хостинг доставчик малко повече, отколкото трябва, и това не доведе до нищо добро. Отне много време, за да се обясни подробно, че никое SLA няма да покрие загуби от престой (има изключения, но обикновено е много, МНОГО скъпо за клиента) и че хостингът изобщо не е наясно какво се случва в клиентската инфраструктура (с изключение на много общи показатели). И хостера също не прави резервни копия вместо вас. Ситуацията е още по-лоша, ако имате повече от един хостър. В случай на проблеми между тях, те със сигурност няма да разберат вместо вас какво се е объркало.

Всъщност мотивите тук са абсолютно същите като при избора на „собствен екип от администратори срещу аутсорсинг“. Ако рисковете са изчислени, качеството е подходящо и бизнесът няма нищо против - защо не опитате. От друга страна, мрежата е един от най-основните слоеве на инфраструктурата и едва ли си струва да я давате на външни хора, ако вече поддържате всичко останало сами.

Кога имате нужда от мрежовик?

Освен това ще се съсредоточим върху модерни продуктови компании. С операторите и предприятията всичко е плюс или минус ясно - малко се е променило през последните години и мрежовиците бяха необходими там преди, те са необходими сега. Но с тези много „млади и дръзки“ нещата не са толкова прости. Често те поставят своята инфраструктура изцяло в облаците, така че дори не се нуждаят от администратори, с изключение на администраторите на същите тези облаци, разбира се. Инфраструктурата, от една страна, е доста проста в дизайна си, от друга страна, тя е добре автоматизирана (ansible / марионетка, terraform, ci / cd ... добре, знаете). Но дори и тук има ситуации, когато не можете да правите без мрежов инженер.

Пример 1, класически

Да предположим, че една компания започва с един сървър с публичен ip-адрес, който се намира в центъра за данни. След това има два сървъра. След това още ... Рано или късно има нужда от частна мрежа между сървърите. Тъй като „външният“ трафик е ограничен както от честотната лента (например не повече от 100Mbps), така и от количеството изтеглено / качено на месец (различните хостери имат различни тарифи, но честотната лента към външния свят, като правило, е много по-скъпо от частна мрежа).

Хостингът добавя допълнителни мрежови карти към сървърите и ги включва в своите комутатори в отделен vlan. Между сървърите се появява „плоска“ LAN. Удобно!

Броят на сървърите расте, трафикът в частната мрежа също расте - архивиране, репликации и т.н. Домакинът предлага да ви премести на отделни суичове, така че да не пречите на другите клиенти и те да не ви пречат. Домакинът поставя някакви превключватели и по някакъв начин ги конфигурира - най-вероятно оставяйки една плоска мрежа между всичките ви сървъри. Всичко работи добре, но в определен момент започват проблемите: закъсненията между хостовете периодично растат, регистрационните файлове се кълнат в твърде много arp пакети в секунда и пентестерът изнасили цялата ви локална област по време на одита, като счупи само един сървър.

Какво трябва да направя?

Разделете мрежата на сегменти - vlans. Настройте свое собствено адресиране във всяка vlan, изберете шлюз, който ще прехвърля трафик между мрежите. На шлюза конфигурирайте acl за ограничаване на достъпа между сегментите или дори поставете отделна защитна стена до него.

Пример 1, продължение

Сървърите са свързани към локалната зона с един кабел. Превключвателите в стелажите са някак си свързани помежду си, но при авария в една стойка падат още три съседни. Схеми съществуват, но има съмнения относно тяхната актуалност. Всеки сървър има свой публичен адрес, който се издава от хоста и се свързва към стелажа. Тези. при преместване на сървъра адресът трябва да се промени.

Какво трябва да направя?

Свържете сървъри с помощта на LAG (Link Aggregation Group) с два кабела към превключватели в шкафа (те също трябва да бъдат излишни). Запазете връзките между стелажите, преправете ги със „звезда“ (или модерния сега CLOS), така че загубата на една стойка да не засегне останалите. Изберете "централни" стелажи, където ще бъде разположено ядрото на мрежата и където ще бъдат включени други стелажи. В същото време подредете публичното адресиране, вземете от хостера (или от RIR, ако е възможно) подмрежа, която вие сами (или чрез хостера) обявите на света.

Може ли „обикновен“ системен администратор, който няма задълбочени познания за мрежите, да направи всичко това? Не съм сигурен. Домакинът ще го направи ли? Може би ще стане, но ще ви трябва доста подробен TOR, който също трябва да бъде съставен от някой. и след това проверете дали всичко е направено правилно.

Пример 2: Облачно

Да предположим, че имате VPC в някакъв публичен облак. За да получите достъп от офиса или локалната част от инфраструктурата до локалната мрежа във VPC, трябва да настроите връзка чрез IPSec или специален канал. От една страна, IPSec е по-евтин. няма нужда да купувате допълнителен хардуер, можете да настроите тунел между вашия сървър с публичен адрес и облака. Но - закъснения, ограничена производителност (тъй като каналът трябва да бъде криптиран), плюс негарантирана свързаност (тъй като достъпът минава през обикновен интернет).

Какво трябва да направя?

Повишете връзката чрез специален канал (например AWS го нарича Direct Connect). За да направите това, намерете партньорски оператор, който ще ви свърже, решете най-близката до вас точка на свързване (и вие в оператора, и операторът в облака) и накрая настройте всичко. Може ли всичко това да се направи без мрежов инженер? Със сигурност да. Но как да отстраните без него в случай на проблеми вече не е толкова ясно.

И също така може да има проблеми с наличността между облаци (ако имате multicloud) или проблеми със закъснения между различни региони и т.н. Разбира се, сега има много инструменти, които увеличават прозрачността на случващото се в облака (същите хиляди очи), но това са всички инструменти за мрежов инженер, а не заместител.

Бих могъл да скицирам още дузина такива примери от моята практика, но мисля, че е ясно, че в един екип, започвайки от определено ниво на развитие на инфраструктурата, трябва да има човек (или по-добре повече от един), който знае как мрежата работи, може да конфигурира мрежово оборудване и да се справя с проблеми, ако възникнат. Повярвайте ми, той ще има какво да прави

Какво трябва да знае един мрежовик?

Изобщо не е необходимо (и дори понякога вредно) мрежовият инженер да се занимава само с мрежата и нищо друго. Дори и да не разглеждаме варианта с инфраструктура, която живее почти изцяло в публичен облак (и каквото и да се каже, става все по-популярен), а да вземем например локални или частни облаци, където само „знание на ниво CCNP „Няма да си тръгнеш.

В допълнение към всъщност мрежите - въпреки че има просто безкрайно поле за изучаване, дори ако се концентрирате само в една посока (мрежи на доставчици, предприятия, центрове за данни, Wi-Fi ...)

Разбира се, много от вас сега ще си спомнят Python и други "мрежови автоматизации", но това е само необходимо, но не и достатъчно условие. За да може мрежовият инженер „успешно да се присъедини към екипа“, той трябва да може да говори на един език както с разработчиците, така и с колегите си администратори/devops. Какво означава?

• да можете не само да работите в Linux като потребител, но и да го администрирате, поне на ниво sysadmin-junior: инсталирайте необходимия софтуер, рестартирайте повредена услуга, напишете прост systemd-unit.
• Разберете (поне в общи линии) как работи мрежовият стек в Linux, как работи мрежата в хипервайзори и контейнери (lxc / docker / kubernetes).
• Разбира се, можете да работите с ansible/chef/puppet или друга SCM система.
• Трябва да се напише отделен ред за SDN и мрежи за частни облаци (например TungstenFabric или OpenvSwitch). Това е още едно огромно знание.

Накратко описах типичен Т-образен специалист (както сега е модерно да се казва). Изглежда, че не е нищо ново, но според опита от интервютата не всички мрежови инженери могат да се похвалят със знания по поне две теми от списъка по-горе. На практика липсата на познания „в сродни области“ затруднява много не само комуникацията с колегите, но и разбирането на изискванията, които бизнесът налага към мрежата като инфраструктура от най-ниско ниво на проекта. И без това разбиране става по-трудно разумно да защитите своята гледна точка и да я „продадете“ на бизнеса.

От друга страна, самият навик да „разбираме как работи системата“ дава много добро предимство на мрежовите специалисти пред различни „генералисти“, които знаят за технологиите от статии в Habré/medium и телеграм чатове, но нямат абсолютно никаква представа какви принципи има това или този софтуер работи. А познаването на някои закономерности, както знаете, успешно замества знанието на много факти.

Заключения, или просто TL;DR

1. Мрежовият администратор (като DBA или VoIP инженер) е специалист с доста тесен профил (за разлика от sysadmins / devops / SRE), нуждата от която не възниква веднага (и всъщност може да не възникне дълго време) . Но ако възникне, тогава е малко вероятно да бъде заменен от външни експерти (аутсорсинг или обикновени общи администратори, „които също се грижат за мрежата“). Малко по-тъжното е, че нуждата от такива специалисти е малка и условно в компания с 800 програмиста и 30 devops/admin може да има само двама мрежовици, които да си вършат перфектно работата. Тези. пазара беше и е много, много малък, а още по-малко с добра заплата.
2. От друга страна, един добър мрежовик в съвременния свят трябва да познава не само самите мрежи (и как да автоматизира тяхната конфигурация), но и как операционните системи и софтуерът си взаимодействат с тях, които работят върху тези мрежи. Без това ще бъде изключително трудно да разберете какво колегите искат от вас и да предадете (разумно) вашите желания / изисквания към тях.
3. Няма облак, това е просто чужд компютър. Трябва да разберете, че използването на публични/частни облаци или услугите на хостинг доставчици, „които правят всичко вместо вас“, не отменя факта, че вашето приложение все още използва мрежата и проблемите с него ще повлияят на работата на вашето приложение . Вашият избор е къде ще се намира центърът за компетентност, който ще отговаря за мрежата на вашия проект.

Източник: www.habr.com