Comments 63
«… по словосочетанию «пожарный» выдавал около трёхсот вакансий по всей России. Для сравнения, поиск по фразе «врач-педиатр» выдаёт почти 2.5 тысячи вакансий, а «постовой ДПС» — почти 800...»
Как-то так
Вы очень сильно не правы. Точнее, правы, если ограничиваться очень простыми сетями. А вот если копнуть глубже, все становится очень динамично. Когда я пришёл в телеком, сети строились на Frame Relay, а резервирование в LAN делали на STP. Сейчас FR можно найти разве что в музее, а за STP вас засмеют. Зато появляется SDWAN (за рубежом — уже, у нас пока только самые передовики), в ДЦ строятся CLOS фабрики, и вообще строят малтиклауд. А сеть в том же AWS отличается от классических сетей примерно как тесла от телеги. Вроде и там и там колеса и обе ездят. А если строишь малтиклауд, то это надо скрестить ещё.
И по поводу книжек. Обратите внимание, что в переводе на русский есть материал только уровня CCNA. Остальные нет смысла переводить, устаревают быстрее.
А как же ЦОДы? Можно встретить ещё как, целый отдел только лишь сетевиков :)
Всё зависит от задач.
Когда я работал у интернет-провайдеров, то основными требованиями было понимание принципов работы сетей, умение быстро локализовать и ликвидировать неисправность (в случае когда 1000+ абонентов остались без интернета) и «чуйка на неисправности».
Половина инженеров у провайдера не понимают в Linux, CCNA и другие страшные слова тоже не знают =) Про документирование можно вообще не вспоминать, как и про английский…
Мое мнение: сетевые инженеры, которые постоянно развиваются и любят свою профессию — нужны. Люди, которые застряли на уровне «заменим свитч на чердаке, а Linux сами занимайтесь» — они тоже нужны, но это не сетевые инженеры, а уровень монтажника.
Другое дело, что я неоднократно встречал сетевиков, которые не хотят (не любят / не умеют / не могут) изучать что-то за пределами Cisco, BGP/OSPF и так далее. Linux для них — тёмный страшный лес. И даже место для таких, я уверен, найдётся. Но мало, и занедорого
Плохо, когда человек превращается в биоробота и не понимает, а что он, собственно делает (особенно таким грешат всякие дежурные иженеры из операторов, всё знание которых про MPLS / L3VPN / BGP как правило сводится к набору команд, которые нужно в циску вбить, чтобы заработало.
Как и написали, все зависит от кругозора и готов ли сотрудник дальше развиваться. Поэтому всегда будут ситуации, когда будет нужен человек, который должен выяснить проблемы в сети. И не совсем ясно, почему автор считает, что при использовании kubernetes сетевики не нужны, очень даже нужны — упала сеть в кубере, иди и смотри какой плагин, контейнер не запускает сеть. На опыте было, что kubernetes не запускался из-за MTU (у провайдера 1470, вместо 1500) — искал причину долго и стало немного стыдно, что не посмотрел на такой параметр, про который новоиспеченные девопсы с курсов, даже могут не знать.
1) Линь на тазике живее всех живых. Особенно сейчас, когда есть DPDK, и можно не тратиться на какой-нибудь MX.
2) Далеко не везде в столицах нужны серты, если речь не про интеграторов или какой-то очень суровый энтерпрайз.
Ну и насчёт смысла в ней быть — каждый выбирает сам. Но могу точно сказать, что здесь всё ещё много интересного
Про DPDK и MX разверните пожалуйста.
Если это про fd.io то он IMHO пока больше Фреймворк для создания своего ПО чем продукт который можно в бой пускать.
Если что-то иное — поделитесь пожалуйста тема интересна.
Не тут вопрос был в разрезе именно DPDK.
Просто что вы описали я и так знаю — у меня сеть в ДЦ на white box коммутаторах и Cumulus.
FRR так же активно используем.
Пока нет, возможно позже.
С самим кумулусом проблем не сильно много, у нас больше проблем с обвязкой управления сетью которая досталась в наследство.
Разница с вендорами — нужно детально понимать как работают все компоненты, что-бы всё было стабильно, впрочем как и с любыми комплексными OSS решениями из мира linux.
Другое дело, что готового дистрибутива, который можно развернуть и «заменить MX», мне еще пока не попадалось, но решить для себя конкретные задачи силами полутора программистов — запросто.
При наличии sr-iov / DPDK можно
а) удобнее виртуализовывать такие роутеры (используя готовый софт-роутер или собрать свой)
б) делать всякие штуки типа NAT / DPI, опирающиеся на DPDK.
В общем я к чему — по моему опыту, софтроутеры как жили, так и живут (в среднем сегменте), и ничего с ними не сделается, особенно для процессороёмких задач типа NAT / DPI и прочего
Какие решения посоветуете?
Именно в разрезе замены MX?
Софт роутер это хорошо, но при скоростях 10G+ становится грустно даже с NAT и просто маршрутизацией уже на средних PPS.
Cumulus? VyOS? 10G+ мне кажется вполне прожёвывается даже плюс-минус стоковым linux-ядром с тюненным sysctl, и проблемы начинаются на 40G+
На forum nag ru можно глянуть я думаю, там много тредов на эту тему
Cumulus это про коммутаторы пока что, full view он там не переварит.
10G на line rate это проблема если PPS большой, пока его пережёвывает только fd.io поверх DPDK и продукты построенные на нём, например https://www.tnsr.com/
А вот MX и аналоги спокойно справляются.
Стоковое ядро с тюненным sysctl живёт до первого DDoS на 10mpps потом становится весело.
Нет TNSR пощупать не получилось, но щупал ванильный fd.io на самосборе с интеловвми картами — он показал line rate на маршрутизации без NAT и фильтров между 2 10G. TNSR построен на fd.io с рядом оптимизаций так что на базе опыта с fd.io я склонен доверять заявленным показателям.
И да full view и не один держит не напрягаясь frr на рядовом железе, проблема в data plane и его задержках при использовании ядра linux, а не в control plane.
Есть подвижки с DPDK и eBPF+XDP но они пока не могут быть применены достаточно широко т.к. это инструменты для разработки, а не готовое решение конкретных задач.
Сейчас, да, продолжает расти потребность крупных организаций в сетевиках, которые разбираются с облачными технологиями (у AWS есть специальные сертификаты под это).
Что объединяет это рынок: отдельно взятый сетевик, без дополнительных обязанностей — это удел крупных предприятий, чего не скажешь про DevOPS или сисадминов.
(PS: это исходя из 10 лет опыта работы ведущим сетевиком в крупном Западном SaaS предприятии)
Значит ли это, что сетевики более не нужны во времена победивших облаков, докера, кубернетиса и вездесущего публичного вайфая?
Ну, кто-то же должен будет настраивать сети для всего этого…
Ну, кто-то же должен будет настраивать сети для всего этого…
По опыту работы в сетях самое главное для сетевика это диагностика, остальное — вторично. Часто решал задачи в saas и других системах, когда отваливалась as. запускали кольцо в несколько километров на 10ти гигабитах, VPN с урезанным MTU без возможности задать этот MTU, потеря vlan тегов, поиск кластеризации аплинков (ru работает, com лагает), да тупо знание в различии в 20 ответах команды ping часто помогает решить проблему, не говоря уже об NGN (sip-voip). Такие спецы как единороги.
Также часто было «я знаю в чем проблема, дайте мне админа, я скажу что сделать», и это помогало. А всякие лаги с потерей window size в TCP пакетах на стриминговых сервисах та еще головная боль :)
У меня есть несколько клиентов, которые раза 2 в год звонят и спрашивают «куда копать», когда их персонал уже всё перепробовал
Долгое время у сетевиков (как и у СХДшников, например) из средств диагностики была, по сути, только лампа подачи питания на корпусе железки. Тут придется Вангой стать от безысходности. Но ничего, сейчас туда насыпается какое-то количество внешних программистов, и они вытащат на свет весь ужос, происходящий в вендорских коробках.
Самое главное — это знать, как оно работает. Это поможет и в диагностике и в проектировании / строительстве.
А так — вы всё правильно пишете, но дело обычно не ограничивается только диагностикой.
Автор, расскажите пожалуйста для кого написана эта статья и какие выводы должен сделать читатель.
Это предупреждение молодого поколения чтобы не шли в сетевики? (з/п небольшая, а вакансий мало)
Это ожидание поддержки на тему "вы нужны ребята"?(20 лет назад телефонисты также говорили друг другу)
Не, ну серьёзно это напоминает нытьё таксоблогеров на ютубе, что мол мы делаем важное дело, нас не ценят, автопилоты нас не заменят и всё в таком духе.
Мне не нужно одобрение — я пишу то, что думаю.
Предупреждение… наверное, да. И не только / не столько для молодых.
Мир меняется. Чтобы быть востребованным (читай: хорошо зарабатывать) нужно знать не только свою песочницу, не только то, что понятно, изучено и испробовано.
С другой стороны, узкая специализация на то и узкая, что если уж она понадобилась, то проще нанять спеца с нужными знаниями, чем надеяться на то, что прилетит вдруг волшебник в голубом вертолёте и всё сделает «как надо».
Вопрос к автору и сетивикам.
В статье пишется, что на базе хостера или провайдера поднять маршрутизацию между vlanи развернуть acl и т д. Не разу не сталкивался с тем, что бы хостер/оператор предоставлял доступ к своим коммутаторам для настройки своей сети. Или вы описали какой то частный случай?
Недавно искал работу, пришлось уйти из этой сферы в интеграцию. Пока не жалею, здесб хоть мои сертификаты прогодились и платят достойно:)
Резюмируя, мне кажется что сетевики как отдельная область скоро перестанут существовать. Сейчас век разрабов, а им не надо большие сети, им подавай докеры, куберы и прочую виртуализацию.
С другой стороны, я считаю что сетевик должен быть в первую очередь инженером. А настоящий инеженер должен уметь разобраться во всем: в линуксах, в докерах, в программировании и т.д. Так что не пропадем :)
Про провайдинг всё так. Очень интересно с точки зрения технологий и "влияния", но очень плохо с деньгами. И это не только в РФ так, боюсь. Провайдинг во всём мире превращается в commodity, уже не нужно большое количество квалифицированных инженеров, а нормальный R&D есть только у самых крупных и инженеров там очень немного.
С интеграторами не всегда всё радужно бывает, но если получилось найти хорошее место, то очень рад за вас :)
Ну и с выводами соглашусь. Сетевик это прежде всего инженер, а инженер, вне зависимости от специализации, должен обладать живым умом и быть способным разбираться со всяким неопонятным.
Все так. В нашей крупной не ИТ международной компании (Fortune 500), только в России десяток собственных сетевых инженеров, не считая коллег в глобальных и локальных подрядчиках. Задача товарищей в передаче технических требований между различными командами, с обязательной экспертизой. Везде жестокий waterfall и ручной труд. Ожидаю что неизбежная автоматизация сильно упростит взаимодействия и освободит рабочие места.
www.udemy.com/course/it-networking-career-planning-guide-for-best-outcomes
CCIE давно девальвировался.
Хочется предсказуемости, стабильности, и выписывать лещей пионэрам разработчикам? Надо идти в безопасники…
Если сильно охото заниматься сетями, SDN, security и т.п. могу посоветовать Фактор Групп в Москве. Они в эту тему упарываются.
Сетевики (не) нужны