Към момента на писането на тази статия, търсенето на популярния сайт за работа с фразата „Мрежов инженер“ показваше около триста обяви за работа в цяла Русия. За сравнение, търсенето с термина „системен администратор“ дава почти 2.5 хиляди обяви, а „DevOps инженер“ — почти 800.
Означава ли това, че мрежовите специалисти вече не са нужни в ерата на облаците, Docker, Kubernetes и всеобхватния публичен Wi-Fi?
Нека разберем (с)
Нека се запознаем. Казвам се Алексей и съм мрежов инженер.
Занимавам се с мрежи повече от 10 години и работя с различни *nix системи над 15 години (имал съм възможност да работя с и Linux, и FreeBSD). Работил съм при оператори на връзка, в големи компании, които се считат за „предприятия“, а в последно време работя в „млад и амбициозен“ финтек, където облаци, DevOps, Kubernetes и останалите страшни термини, които задължително ще направят мен и колегите ми ненужни. Някога. Може би.
дисклеймър: „В нашия живот не всичко е, винаги и навсякъде, а нещо, понякога и на места“ (с) Максим Дорофеев.
Всичко, написано по-долу, може и трябва да се счита за лично мнение на автора, което не претендира за окончателна истина и дори за пълноценно изследване. Всички персонажи са измислени, всички съвпадения са случайни.
Добре дошли в моя свят.
Къде изобщо можем да срещнем мрежовите специалисти?
1. Оператори на връзка, сервизни компании и други интегратори. Тук всичко е просто: мрежата за тях е бизнес. Те или директно продават свързаност (оператори), или предоставят услуги по стартиране/поддържане на мрежите на своите клиенти.
Има много опит тук, но парите не са съвсем много (освен ако не сте директор или успешен търговски мениджър). Въпреки това, ако обичате мрежите и сте само в начален етап, кариерата в поддръжката на някой не особено голям оператор би била, дори и сега, идеалната стартова точка (в федералните компании всичко е силно сценаризирано и има малко пространство за творчество). И историите за това как от дежурен инженер можете да станете C-level мениджър за няколко години също са доста реални, макар и редки, по разбираеми причини. Нуждата от кадри винаги съществува, защото текучеството е на лице. Това е както добро, така и лошо в същото време — винаги има свободни работни места, от друга страна — често най-активните/умните бързо напускат, или за повишение, или в други, по-„топли“ места.
2. Условен «ентерпрайз». Независимо от того, свързана ли основната им дейност с IT или не. Важното е, че имат собствен IT отдел, който се занимава с осигуряването на работата на вътрешните системи на компанията, включително мрежите в офисите, комуникационните канали до клоновете и т.н. Функциите на мрежовия инженер в такива компании могат да бъдат изпълнявани "по заемане" от системен администратор (ако мрежовата инфраструктура е малка, или ако се грижи за нея външен изпълнител), а мрежовият специалист, ако все пак съществува, може да следи за телефонията и SAN (не е шега). Заплатите варират — значително зависят от маржиналността на бизнеса, размерите на компанията и структурата. Работил съм и с компании, където циско рутерите редовно "се товарят с бъчви", и с компании, където мрежата е изградена от фекалии, пръчки и синя лента, а сървърите не са обновявани почти никога (трябва ли да казвам, че резерви също не са предвидени). Опитът там е значително по-малко и почти сигурно ще бъде в областта на строгото vendor-lock или „как да направим нещо от нищо“. Лично ми се стори ужасно скучно, макар на мнозина да им харесва — всичко е доста размерно и предсказуемо (ако говорим за големи компании), "дораха-бахато" и т.н. Не по-рядко от веднъж годишно някой голям вендор казва, че е измислил следващата мега-супер-пупер система, която изобщо автоматизира всичко и всички системни администратори и мрежови инженери могат да бъдат уволнени, оставяйки двама-трима да натискат бутони в красив интерфейс. Реалността обаче е такава, че, дори да се абстрахираме от цената на решението, мрежовите специалисти няма да изчезнат. Да, може би вместо конзолата отново ще има уеб интерфейс (но вече не за конкретно устройство, а за голяма система, която управлява десетки и стотици такива устройства), но знанията за "как всичко е устроено отвътре" все пак ще бъдат необходими.
3. Продуктови компании, чийто приход идва от разработката (и често експлоатацията) на софтуер или платформа — същият този продукт. Обикновено те са малки и динамични, далеч са от мащабите на предприятията и тяхната бюрократичност. Именно тук масово се срещат онези така наречени девопси, кубери, докери и други страшни думи, които задължително ще направят мрежата и мрежовите инженери ненужен рудимент.
Какво е различието между мрежовия инженер и системния администратор?
В разбирането на хора, които не работят в ИТ — нищо. И двамата гледат в черен екран и пишат някакви заклинания, понякога тихо псуват.
В разбиранията на програмистите — може би само предметната област. Администраторите управляват сървъри, мрежовиците управляват комутатори и маршрутизатори. Понякога не управляват добре, и всички неща се сриват. В случай на нещо странно виновни са и мрежовиците. Just because fuck you, that’s why.
Наистина, основната разлика е подходът към работата. Може би сред мрежовиците най-много се срещат поддръжници на подхода „Работи — не пипай!“. Някаква задача (в рамките на един вендор) обикновено може да бъде изпълнена само по един начин, цялата конфигурация на устройствата — ето я, на дланта. Цената на грешката е висока, а понякога и много висока (например, може да се наложи да пътувате на стотици километри, за да рестартирате рутер, а през това време без връзка ще останат няколко хиляди души — напълно обичайна ситуация за оператора на мрежата).
Според мен, именно затова мрежовите инженери, от една страна, са крайно мотивирани за стабилност на мрежата (а промените — основният враг на стабилността), а от друга, техните знания вървят повече в дълбочина, отколкото в ширина (не е нужно да знаят как да конфигурират десетки различни демони, нужно е да познават технологиите и тяхната реализация при конкретния производител на оборудване). Именно затова системен администратор, който е намерил в Google как да настрои VLAN на Cisco — това не е мрежовик. И едва ли ще може ефективно да поддържа (а също така и да решава проблеми с) повече или по-малко сложна мрежа.
Но защо е нужен мрежовик, ако имате хостер?
При допълнителна заплата (а ако сте много голям и обичан клиент — може дори безплатно, „по приятелство“) инженерите на датацентъра ще настройкат вашите комутатори според вашите нужди и, възможно, ще помогнат и за вдигане на BGP-връзката с доставчиците (ако имате своя подмрежа ip адреси за анонс).
Основният проблем е, че данните център не е вашият ИТ отдел, а е отделна компания, чиято цел е да получава печалба. Включително от вас, като клиент. Данните център предоставя стойки, осигурява им електричество и охлаждане, а също така осигурява определена „стандартна“ свързаност с интернет. На основата на тази инфраструктура, данните център може да разположи вашето оборудване (colocation), да ви наеме сървър (dedicated server) или да предостави управлявана услуга (например OpenStack или K8s). Но бизнесът на данните център (обикновено) не е администрирането на инфраструктурата на клиентите, тъй като този процес е доста трудоемък, трудно автоматизиран (а в нормален данни център автоматизирано е всичко възможно), още по-трудно унифициран (всеки клиент е индивидуален) и всъщност носи рискове от претенции ("вие ми конфигурирахте сървъра, а сега той падна, вие сте виновни!!!111"). Затова, ако хостерът ви помогне с нещо, ще се опита да го направи максимално просто и "кондово". Защото да правиш сложно — не е изгодно, най-малкото от гледна точка на разходите на инженерите на хостера (но ситуациите са различни, вижте отказа от отговорност). Това не означава, че хостерът непременно ще направи всичко зле. Но съвсем не е сигурно, че той ще направи точно това, от което наистина имате нужда.
Казва се, че това е доста очевидно, но съм се сблъсквал няколко пъти в практиката си с факта, че компаниите започват да разчитат на своя хостинг доставчик повече, отколкото трябва, и това не води до нищо добро. Налагаше ми се да обяснявам дълго и подробно, че никой SLA не покрива загубите от престои (има изключения, но обикновено това е много, МНОГО скъпо за клиента) и че хостерът изобщо не е информиран за това, какво се случва в инфраструктурата на клиентите (освен много общи показатели). И хостерът също не прави резервни копия вместо вас. Още по-лоша е ситуацията, ако имате повече от един хостер. В случай на проблеми между тях, те определено няма да уточняват вместо вас какво точно се е объркало.
Същността на мотивите тук е точно същата, както при избора между "своя екип администратори vs аутсорсинг". Ако рисковете са оценени, качеството удовлетворява, а бизнесът не е против — защо да не опитате? От друга страна, мрежата е един от най-базовите слоеве на инфраструктурата и вряд ли е разумно да я оставите на случайни хора, ако всичко останало вече поддържате сами.
В кои случаи е нужен мрежов инженер?
По-нататък ще говорим конкретно за съвременните продуктови компании. С операторите и предприятията всичко е плюс-минус ясно — там нищо особено не се е променило през последните години, и мрежовите инженери бяха нужни по-рано, нужни са и сега. Но що се отнася до младите и дръзки компании, нещата не са толкова еднозначни. Често те разполагат инфраструктурата си изцяло в облака, така че даже администратори не им трябват — освен администраторите на самите облаци, разбира се. Инфраструктурата от една страна е сравнително проста по своята структура, а от друга — добре автоматизирана (ansible/puppet, terraform, ci/cd… добре знаете как е). Но дори и тук има ситуации, в които не може без мрежов инженер.
Пример 1, класически
Предположим, че компанията започва с един сървър с публичен IP адрес, който се намира в датацентъра. После сървърите стават два. След това повече… Рано или късно, се появява необходимост от частна мрежа между сървърите. Защото "външният" трафик е ограничен както по скорост (например не повече от 100 Мбит/с), така и по обема на изтеглените/предадените данни на месец (различните хостъри предлагат различни тарифи, но свързаността към външния свят, като правило, е много по-скъпа от частната мрежа).
Хостерът добавя допълнителни мрежови карти в сървърите и ги включва в своите комутатори в отделен VLAN. Между сървърите се появява "плоска" локална мрежа. Удобно!
Броят на сървърите нараства, трафикът в частната мрежа също – бекъпи, репликации и т.н. Хостинг компанията предлага да ви отдели в отделни суичове, за да не пречите на другите клиенти и те да не пречат на вас. Хостинг компанията поставя някакви суичове и ги конфигурира по определен начин – вероятно оставяйки между всичките ви сървъри една плоска мрежа. Всичко работи добре, но в определен момент започват проблемите: периодично се увеличават забавянията между хостовете, в логовете има оплаквания за твърде голямо количество arp-пакети в секунда, а пентестерът по време на одита е успял да получи контрол над цялата ваша локална мрежа, считайки само един сървър.
Какво трябва да се направи?
Да се раздели мрежата на сегменти – VLAN. Да се конфигурира в всеки VLAN своя адресация, да се отдели шлюз, който ще прехвърля трафика между мрежите. На шлюза да се конфигурира ACL за ограничава достъпа между сегментите или изцяло да се постави отделен защитен екран.
Пример 1, продължение
Сървърите са свързани към локалната мрежа с един кабел. Суичовете в рафтовете са свързани помежду си по някакъв начин, но при повреда в един рафт, три съседни падат. Схеми съществуват, но в тяхната актуалност има съмнения. Всеки сървър има свой публичен адрес, който се предоставя от хостера и е свързан с рафта. Т.е. при преместване на сървъра, адресът трябва да бъде променен.
Какво трябва да се направи?
Да се свържат сървърите с помощта на LAG (Link Aggregation Group) с два кабела към суичовете в рафта (те също трябва да бъдат резервирани). Свързванията между рафтовете да се резервират, да се променят на „звезда“ (или модерен напоследък CLOS), за да не се влияе падането на един рафт на другите. Да се изготвят „централни“ рафтове, в които ще бъде разположено мрежовото ядро, и където ще се включват другите рафтове. Заедно с това да се подреди публичната адресация, да се вземе от хостера (или от RIR, ако е възможно) подсет, който самостоятелно (или чрез хостера) да бъде анонсиран в света.
Може ли всичко това да направи „обикновен“ системен администратор, който не разполага с дълбоки познания в мрежите? Не съм сигурен. Ще го направи ли хостера? Може би да, но от вас ще се изисква доста детайлно ТЗ, което също трябва да бъде съставено от някого. А след това да се контролира, че всичко е направено правилно.
Пример 2. Облак
Да предположим, че имате VPC в някое публично облако. За да получите достъп от офиса или on-prem част от инфраструктурата до локалната мрежа вътре в VPC, трябва да настроите свързване чрез IPSec или специален канал. От една страна — IPSec е по-евтино, т.к. не трябва да купувате допълнително оборудване, можете да настроите тунел между вашия сървър с публичен адрес и облака. Но — закъснения, ограничена производителност (т.к. каналът трябва да бъде криптиран), плюс ненадеждно свързване (т.к. достъпът става чрез обикновения интернет).
Какво трябва да се направи?
Да подемете свързването чрез специален канал (например, при AWS това се нарича Direct Connect). За целта намерете оператор-партньор, който ще ви свърже, определете се с най-близката до вас точка на включване (както за вас към оператора, така и за оператора към облака) и, накрая, на всичко това да бъде настроено. Може ли всичко това да се направи без мрежов инженер? Сигурно, да. А как да се отстраняват проблеми без него — вече не е толкова ясно.
И могат да възникнат проблеми с наличността между облаците (ако имате мултиоблачност) или проблеми със закъсненията между различни региони и т.н. Безусловно, сега има много инструменти, които повишават прозрачността на това, което се случва в облака (същия Thousand Eyes), но това са инструменти за мрежов инженер, а не негова замяна.
Можех да дам още десет подобни примери от своята практика, но, мисля, ясно е, че в екипата, започвайки от определено ниво на развитие на инфраструктурата, трябва да има човек (а по-добре не един), който знае как работи мрежата, ще може да настрои мрежовото оборудване и да се справи с проблемите, ако възникнат. Повярвайте, той ще има с какво да се занимава.
Какво трябва да знае мрежовият инженер?
Не е задължително (и дори понякога е вредно), мрежовият инженер да се занимава само с мрежата и нищо друго. Дори да не разглеждаме варианта с инфраструктура, която почти изцяло живее в публично облако (а той, каквото и да си говорим, става все по-популярен), и да вземем за пример on-premise или частни облаци, където само с "знания на ниво CCNP" не се излиза.
Освен мрежите — тук има буквално безкрайно поле за изучаване, дори ако се фокусирате само върху някаква една насока (провайдерски мрежи, предприятия, центрове за данни, Wi-Fi…)
Разбира се, много от вас ще си спомнят за Python и другата „автоматизация на мрежата“, но това е само необходимо, но недостатъчно условие. За да може мрежовият инженер да се „влее успешно в екипа“, трябва да умее да разговаря на един и същ език както с разработчиците, така и с колегите администратори/DevOps. Какво означава това?
- да може не само да работи в Linux като потребител, но и да го администрира, поне на ниво джуниор системен администратор: да инсталира необходимия софтуер, да рестартира падналия сървис, да напише прост systemd unit.
- да разбира (поне в общи линии), как работи мрежовият стек в Linux, как е устроена мрежата в хипервизорите и контейнерите (lxc / docker / kubernetes).
- Разбира се, трябва да може да работи с ansible/chef/puppet или друга система за управление на конфигурации.
- Отделно, трябва да се спомене за SDN и мрежите за частни облаци (например, TungstenFabric или OpenvSwitch). Това е още един обширен пласт знания.
Ако трябва да обобщя, описах типичния T-shape специалист (както е модерно да се казва в днешно време). Някак си не изглежда ново, но от опит с интервюта далеч не всички мрежови инженери могат да се похвалят с познания поне по две теми от горния списък. В практиката, липсата на знания в „съседни области“ затруднява не само комуникацията с колегите, но и разбирањето на изискванията, които бизнесът поставя към мрежата, като най-ниското ниво на инфраструктурата на проекта. А без това разбиране става по-трудно да се аргументира своята позиция и да се „продаде“ на бизнеса.
От друга страна, навикът да „разбира как работи системата“ дава на мрежовите специалисти много добро предимство пред различни „широкообхватни специалисти“, които знаят за технологии само от статии в Хабре/Medium и чатове в Telegram, но нямат представа на какви принципи работи конкретният софтуер. А познанията за някои закономерности, както е известно, успешно заменят знанието на много факти.
Изводи, или просто TL;DR
- Мрежовият администратор (както и DBA или VoIP инженер) е специалист с доста специализирана насоченост (в отличие от системните администратори/DevOps/SRE), от който нуждата не възниква веднага (и може дълго да не се появява, всъщност). Но когато тази нужда се прояви, трудно ще бъде да се замени с експертиза от външни лица (аутсорсинг или обикновени администратори с обща насоченост, „които също следят мрежата“). По-скоро тъжно е, че нуждата от такива специалисти е ниска и, условно казано, в компания с 800 програмисти и 30 DevOps/администратори може да има само двама мрежови администратори, които отлично изпълняват своите задължения. Тоест, пазарът е и остава доста малък, а дори и с добро заплащане — още по-малък.
- От друга страна, добрият мрежови администратор в съвременния свят трябва да знае не само мрежи (и как да автоматизира тяхната настройка), но също така как операционните системи и софтуерът, които работят над тези мрежи, взаимодействат помежду си. Без това ще бъде изключително трудно да разберете какво колегите искат от вас и да предадете (обосновано) своите желания/изисквания към тях.
- Няма облак, само чужд компютър. Трябва да разберете, че използването на публични/частни облаци или услуги от хостинг доставчици „които правят всичко за вас на ключ“ не отменя факта, че вашето приложение все още използва мрежата и проблемите с нея ще влияят на работата на вашето приложение. Вашият избор е къде ще се намира центърът на компетенция, който ще отговаря за мрежата на вашия проект.
Източник: habr.com
