Сетевики (не) нужны

    На момент написания этой статьи поиск на популярном работном сайте по словосочетанию «Сетевой инженер» выдавал около трёхсот вакансий по всей России. Для сравнения, поиск по фразе «системный администратор» выдаёт почти 2.5 тысячи вакансий, а «DevOps инженер» — почти 800.

    Значит ли это, что сетевики более не нужны во времена победивших облаков, докера, кубернетиса и вездесущего публичного вайфая?
    Давайте разбираться (с)



    Давайте знакомиться. Меня зовут Алексей, и я сетевик.

    Я больше 10 лет занимаюсь сетями и больше 15 лет работаю с различными *nix системами (довелось ковырять и Linux, и FreeBSD). Работал в операторах связи, крупных компаниях, которые принято считать «энтерпрайзом», а последнее время работаю «молодом и дерзком» финтехе, где облака, девопсы, кубернетесы и прочие страшные слова, которые обязательно сделают меня и моих коллег ненужными. Когда-нибудь. Может быть.
    disclaimer: «В нашей жизни не всё, всегда и везде, а кое что, иногда и местами» (с) Максим Дорофеев.

    Всё ниженаписанное можно и нужно считать личным мнением автора, не претендующим на истину в последней инстанции, и даже на полноценное исследование. Все персонажи вымышленны, все совпадения случайны.
    Добро пожаловать в мой мир.

    Где можно вообще встретить сетевиков?


    1. Операторы связи, сервисные компании и прочие интеграторы. Тут всё просто: сеть для них — это бизнес. Они либо напрямую продают связность (операторы), либо оказывают услуги по запуску/обслуживанию сетей своих заказчиков.

    Опыта здесь много, денег — не очень (если вы не директор или успешный менеджер-продажник). И тем не менее, если вам нравятся сети, и вы только в начале пути, карьера в саппорте какого-нибудь не очень крупного оператора будет, даже сейчас, идеальной точкой для старта (в федеральных всё очень скриптовано, и простора для творчества мало). Ну и истории про то, что можно из дежурного инженера дорасти за несколько лет до C-level manager тоже вполне реальны, хотя и редки, по понятным причинам. Потребность в кадрах есть всегда, потому что текучка таки имеет место быть. Это и хорошо, и плохо одновременно — всегда есть вакансии, с другой стороны — зачастую, самые активные/умные достаточно быстро уходят либо на повышение, либо в другие, более «тёплые» места.

    2. Условный «энтерпрайз». Не важно, связана ли его основная деятельность с ИТ, или нет. Главное — что в нём есть свой IT отдел, который занимается обеспечением работы внутренних систем компании, в том числе сети в офисах, каналов связи в филиалы и т.д. Функции сетевого инженера в таких компаниях может «по совместительству» выполнять системный администратор (если сетевая инфраструктура небольшая, или ей занимается внешний подрядчик), а сетевик, если он всё-таки есть, может присматривать заодно за телефонией и SAN (ненуачо). Платят по-разному — сильно зависит от маржинальности бизнеса, размеров компании и структуры. Я работал и с компаниями, где циски регулярно «грузили бочками», и с компаниями, где сеть строили из фекалий, палок и синей изоленты, а серверы не обновляли, примерно, никогда (надо ли говорить, что никаких резервов тоже предусмотрено не было). Опыта здесь сильно меньше, и он, почти наверняка будет в области жёсткого vendor-lock, либо «как из ничего сделать кое-что». Лично мне там показалось дико скучно, хотя многим нравится — всё достаточно размеренно и предсказуемо (если мы говорим о крупных компаниях), «дораха-бахато» и т.д. Не реже раза в год какой-нибудь крупный вендор говорит, что придумал очередную мега-супер-пупер-систему, которая вот вообще всё сейчас автоматизирует и всех сисадминов и сетевиков можно будет разогнать, оставив парочку для нажимания на кнопки в красивом интерфейсе. Реальность же такова, что, даже если абстрагироваться от стоимости решения, никуда сетевики оттуда не денутся. Да, возможно, вместо консоли снова будет веб-интерфейс (но уже не конкретной железки, а большой системы, которая управляет десятками и сотнями таких железок), но знания «как всё внутри устроено» всё равно понадобятся.

    3. Продуктовые компании, прибыль которой приносит разработка (и, часто, эксплуатация) какого-нибудь софта или платформы — того самого продукта. Обычно они небольшие и шустрые, им ещё далеко до масштабов энтерпрайзов и их бюрократизованности. Именно здесь массово водятся те самые девопсы, куберы, докеры и прочие страшные слова, которые обязательно сделают сеть и сетевых инженеров ненужным рудиментом.

    Чем сетевик отличается от сисадмина?


    В понимании людей не из ИТ — ничем. И тот, и другой смотрят в чёрный экран и пишет какие-то заклинания, порой тихонько матерясь.

    В понимании программистов — разве что предметной областью. Сисадмины админят серверы, сетевики админят коммутаторы и маршрутизаторы. Иногда админят плохо, и у всех всё падает. Ну в случае всякого странного виноваты тоже сетевики. Just because fuck you, that's why.

    На самом же деле, главное отличие — это подход к работе. Пожалуй, именно среди сетевиков больше всего встречается сторонников подхода «Работает — не трогай!». Сделать какую-то вещь (в рамках одного вендора) можно, как правило, только одним способом, вся конфигурация коробки — вот она, на ладони. Цена ошибки — высокая, а иногда и очень высокая (например, придётся ехать за несколько сотен километров, чтобы перезагрузить роутер, а в это время без связи будут сидеть несколько тысяч человек — вполне обычная для оператора связи ситуация).

    На мой взгляд, именно поэтому именно сетевые инженеры, с одной стороны, крайне сильно мотивированы на стабильность сети (а изменения — главный враг стабильности), а во-вторых, их знания идут больше вглубь, чем вширь (не нужно уметь конфигурировать десятки разных демонов, нужно знать технологии и их реализацию у конкретного производителя оборудования). Именно поэтому сисадмин, который нагуглил, как на циске прописать влан — это ещё не сетевик. И вряд ли он сможет эффективно поддерживать (а так же траблшутить) более-менее сложную сеть.

    Но зачем нужен сетевик, если у вас есть хостер?

    За дополнительную денежку (а если вы очень крупный и любимый клиент — может даже и бесплатно, «по дружбе») инженеры датацентра настроят ваши коммутаторы под ваши нужды, и, возможно, даже помогут поднять BGP-стык с провайдерами (если у вас есть своя подсеть ip-адресов для анонса).

    Основная проблема в том, что датацентр — это не ваш IT-отдел, это отдельная компания, целью которой является получение прибыли. В том числе за счёт вас, как клиента. Датацентр предоставляет стойки, обеспечивает их электричеством и холодом, а так же даёт некоторую «дефолтную» связность с интернетом. На основе этой инфраструктуры датацентр может разместить ваше оборудование (colocation), сдать вам в аренду сервер (dedicated server), или предоставить managed service (например, OpenStack или K8s). Но бизнесом датацентра (обычно) не является администрирование инфраструктуры клиентов, потому что этот процесс довольно трудозатратный, плохо автоматизируется (а в нормальном датацентре автоматизировано всё, что только возможно), ещё хуже унифицируется (каждый клиент индивидуален) и вообще чреват претензиями («вы мне сервер настроили, а он теперь упал, это вы во всём виноваты!!!111»). Поэтому если хостер и будет вам в чём-то помогать, то постарается сделать это максимально просто и «кондово». Ибо делать сложно — невыгодно, как минимум с точки зрения трудозатрат инженеров этого самого хостера (но ситуации бывают разные, см. дисклеймер). Это не означает, что хостер обязательно всё сделает плохо. Но совсем не факт, что он сделает именно то, что было вам нужно на самом деле.

    Казалось бы, вещь достаточно очевидная, но я несколько раз сталкивался в своей практике с тем, что компании начинали полагаться на своего хостинг-провайдера чуть больше, чем следовало, и ни к чему хорошему это не приводило. Приходилось долго и подробно объяснять, что ни один SLA не покроет убытков от простоя (есть исключения, но обычно это очень, ОЧЕНЬ дорого для клиента) и что хостер вообще не осведомлён о том, что творится в инфраструктуре заказчиков (кроме очень общих показателей). И бэкапов хостер тоже за вас не делает. Ещё хуже обстоит дело, если хостеров у вас больше одного. В случае каких-то проблем между ними, они уж точно не будут выяснять за вас, что же всё-таки пошло не так.

    Собственно, мотивы здесь ровно такие же, как при выборе «своя команда админов vs аутсорс». Если риски посчитаны, качество устраивает, а бизнес не против — почему бы и не попробовать. С другой стороны, сеть — это один из самых базовых слоёв инфраструктуры, и едва ли стоит отдавать его на откуп ребятам со стороны, если всё остальное вы уже поддерживаете сами.

    В каких случаях нужен сетевик?

    Далее речь пойдёт именно про современные продуктовые компании. С операторами и энтерпрайзом всё плюс-минус ясно — там мало что поменялось за последние годы, и сетевики там были нужны раньше, нужны и сейчас. А вот с теми самыми «молодыми и дерзкими» всё не так однозначно. Частенько они размещают свою инфраструктуру целиком в облаках, так что даже и админы им, особо, не требуются — кроме админов тех самых облаков, конечно же. Инфраструктура, с одной стороны, довольно простая по своему устройству, с другой — хорошо автоматизирована (ansible/puppet, terraform, ci/cd… ну, вы знаете). Но даже тут есть ситуации, когда без сетевого инженера не обойтись.

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

    Предположим, компания начинает с одного сервера с публичным ip-адресом, который стоит в датацентре. Потом серверов становится два. Потом больше… Рано или поздно, появляется необходимость в приватной сети между серверами. Потому что «внешний» трафик лимитируется как по полосе (не более 100Мбит/с например), так и по объёму скачанного/отданного в месяц (у разных хостеров разные тарифы, но полоса во внешний мир, как правило, сильно дороже приватной сети).

    Хостер добавляет в серверы дополнительные сетевые карты и включает их в свои коммутаторы в отдельный vlan. Между серверами появляется «плоская» локалка. Удобно!

    Количество серверов растёт, трафик в приватной сети тоже — бэкапы, репликации и т.д. Хостер предлагает отселить вас в отдельные коммутаторы, чтобы вы не мешали другим клиентам, а они не мешали вам. Хостер ставит какие-то коммутаторы и как-то их настраивает — скорее всего, оставив между всеми вашими серверами одну плоскую сеть. Всё работает хорошо, но в определённый момент начинаются проблемы: периодически вырастают задержки между хостами, в логах ругань на слишком большое количество arp-пакетов в секунду, а пентестер при аудите поимел всю вашу локалку, сломав лишь один сервер.

    Что нужно сделать?

    Разделить сеть на сегменты — vlan'ы. Настроить в каждом влане свою адресацию, выделить шлюз, который будет перекидывать трафик между сетями. На шлюзе настроить acl для ограничения доступа между сегментами, либо вообще поставить рядом отдельный фаервол.

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

    Серверы подключены к локалке одним шнурком. Коммутаторы в стойках как-то между собой соединены, но при аварии в одной стойке отваливаются ещё три соседних. Схемы существуют, но в их актуальности есть сомнения. У каждого сервера свой публичный адрес, который выдаётся хостером и привязан к стойке. Т.е. при перемещении сервера адрес приходится менять.

    Что нужно сделать?

    Подключить серверы с помощью LAG (Link Aggregation Group) двумя шнурками к коммутаторам в стойке (их тоже нужно резервировать). Соединения между стойками зарезервировать, переделать на «звезду» (или модный нынче CLOS), чтобы выпадение одной стойки не влияло на другие. Выделить «центральные» стойки, в которых будет располагаться сетевое ядро, и куда будут включаться другие стойки. Заодно привести в порядок публичную адресацию, взять у хостера (или у RIR, если есть возможность) подсеть, которую самостоятельно (или через хостера) анонсировать в мир.

    Может ли всё это сделать «обычный» сисадмин, не обладающий глубокими знаниями в сетях? Не уверен. Будет ли это делать хостер? Может и будет, но от вас потребуется довольно детальное ТЗ, которое тоже нужно будет кому-то составить. а потом проконтролировать, что всё сделано правильно.

    Пример 2. Облачный

    Предположим, у вас есть VPC в каком-то публичном облаке. Чтобы получить доступ из офиса или on-prem части инфраструктуры к локальной сети внутри VPC, вам нужно настроить подключение через IPSec или выделенный канал. С одной стороны — IPSec дешевле, т.к. не надо покупать дополнительное железо, можно настроить туннель между вашим сервером с публичным адресом и облаком. Но — задержки, ограниченная производительность (т.к. канал требуется шифровать), плюс негарантированная связность (т.к. доступ идёт через обычный интернет).

    Что нужно сделать?

    Поднять подключение через выделенный канал (например, у AWS это называется Direct Connect). Для этого найти оператора-партнёра, который вас подключит, определиться с ближайшей к вам точкой включения (как вас в оператора, так и оператора в облако), и, наконец, всё настроить. Можно ли всё это сделать без сетевого инженера? Наверняка, да. А вот как это без него траблшутить в случае проблем — уже не так понятно.

    А ещё могут возникнуть проблемы с доступностью между облаками (если у вас мультиклауд) или проблемы с задержками между разными регионами и т.д. Безусловно, сейчас появилось много инструментов, которые повышают прозрачность того, что происходит в облаке (тот же Thousand Eyes), но это всё инструменты сетевого инженера, а не его замена.

    Я мог бы ещё десяток таких примеров из своей практики набросать, но, думаю, понятно, что в команде, начиная с определённого уровня развития инфраструктуры, должен быть человек (а лучше больше одного), который знает, как работает сеть, сможет настроить сетевое оборудование и разобраться в проблемах, если они возникнут. Поверьте, ему будет чем заняться

    Что должен знать сетевик?

    Совсем не обязательно (и даже, иногда, вредно), сетевому инженеру заниматься только сетью и более ничем. Даже если не рассматривать вариант с инфраструктурой, которая почти целиком живёт в публичном облаке (а он, как ни крути, становится всё популярнее и популярнее), и взять, например, on premise или приватные облака, где на одних только «знаниях на уровне CCNP» не выедешь.

    Помимо, собственно, сетей — хотя тут просто бескрайнее поле для изучения, даже если концентрироваться только на каком-то одном направлении (провайдерские сети, энтерпрайз, датацентры, вайфай...)

    Разумеется, многие из вас сейчас вспомнят про Python и прочую «network automation», но это лишь необходимое, но не достаточное условие. Чтобы сетевой инженер «успешно влился в коллектив», он должен уметь разговаривать на одном языке и с разработчиками, и с коллегами админами/девопсами. Что это значит?

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

    Если кратко, то я описал типичного T-shape специалиста (как сейчас модно говорить). Вроде бы ничего нового, однако же по опыту собеседований далеко не все сетевые инженеры могут похвастаться знаниями хотя бы по двум темам из списка выше. На практике, отсутствие знаний «в смежных областях» очень сильно затрудняет не только коммуникацию с коллегами, но и понимание требований, которые бизнес предъявляет к сети, как к самой низкоуровневой инфраструктуре проекта. А без этого понимания становится сложнее аргументированно отстаивать свою точку зрения и «продавать» её бизнесу.

    С другой стороны, та самая привычка «разбираться в том, как работает система» даёт сетевикам очень хорошее преимущество перед различными «специалистами широкого профиля», которые знают о технологиях по статьям на Хабре/медиуме и чатикам в телеграме, но совершенно не представляют, на каких принципах работает тот или иной софт. А знание некоторых закономерностей, как известно, успешно заменяет знание множества фактов.

    Выводы, или просто TL;DR


    1. Сетевой администратор (как и DBA или VoIP-инженер) — это специалист довольно узкого профиля (в отличие от сисадминов/девопсов/SRE), потребность в котором возникает далеко не сразу (и может не возникать долго, на самом деле). Но если когда возникает, то его вряд ли получится заменить экспертизой со стороны (аутсорс или обычные админы широкого профиля, «которые ещё и за сетью присматривают»). Что несколько более печально — потребность в таких спецах мала, и, условно, в компании на 800 программистов и 30 девопсов/админов может быть всего два сетевика, которые прекрасно справляются со своими обязанностями. Т.е. рынок был и есть весьма и весьма небольшой, а так, чтобы с хорошей зарплатой — и того меньше.
    2. С другой стороны, хороший сетевик в современном мире должен знать не только, собственно, сети (и как автоматизировать их настройку), но и как с ними взаимодействуют операционки и софт, которые поверх этих сетей бегают. Без этого будет крайне сложно понять, что просят от тебя коллеги и донести (обосновано) свои пожелания/требования к ним.
    3. There is no cloud, it's just someone else's computer. Нужно понимать, что использование публичных/приватных облаков или услуг хостинг-провайдеров «который вам всё делает под ключ» не отменяет того, что ваше приложение всё ещё использует сеть, и проблемы с ней будут влиять на работу вашего приложение. Ваш выбор — где будет располагаться центр компетенции, который будет отвечать за сеть вашего проекта.
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

    Комментарии 63

      +13
      Я сетевик! Я нужен!
        +5
        Таких контор, где вы нужны, по пальцам пересчитать.
          +3
          Да-да, молодец. Главное не переживай. Теперь выпей чайку, успокойся и иди новую статью писать =)
          +1
          IT непрерывно расширяется и усложняется, поэтому люди из этих самых «сисадминов/девопсов/SRE» постоянно уходят в более тонкую специализацию.
            +3
            И это тоже. С другой стороны — очень много хайпа и очень много новых технологий постоянно появляется. В итоге «узкая специализация» это, зачастую, просто год-два опыта + курсы у каких-нибудь инфоцыган + сертификаты.
              +1
              Хайп да, большой фактор. IT давным давно стал «модным» движением, когда технология часто выбирается исходя из красоты строчки в резюме, а не эффективности ее использования в конкретной задаче.
              С другой стороны чем больше людей делает такой выбор тем спокойнее на душе :)
              +1
              Мне кажется, это работает в обе стороны: был DBA, освоил линуксы, ансиблы — стал вполне себе админом, и т.д.
                +2
                Не представляю себе как можно работать с базами не понимая как таже база работает с операционкой и железом. Наверное это какие-то специальные DBA?
                  +3
                  Среди ораклоидов такое встречал. Они знают Оракл и слабо представляют, что там ниже по стеку
                    0
                    Оракл это отдельный большой мир, да.
                    +4
                    Как нефиг делать. Если человек всю жизнь специализировался на postgres (включая подробное чтение и написание Документации), он может быть запросто быть не в курсе трёх с половиной революций в районе networkd/netplan/network-manger/ufupdown. А там есть прилично о чём чесать голову. И устройство cgroups/namespaces ему тоже не важно.
                      +4
                      Да, это специальны DBA из моего примера про то, что иногда люди(например, бывшие студенты) устраиваются на первую работу и работают с каким-то очень ограниченным стэком технологий или с очень узкой специализацией, не очень представляя, что происходит вокруг. Но при этом, они вполне ответственные и амбициозные, они осваивают то, с чем работают и растут в этом направлении. Потом они начинают осваивать смежные технологии/сферы и происходит то, о чём я и написал.

                      Если вас удивило или обидело то, что я привёл в пример именно DBA — прошу меня извинить. Но я сам видел, как именно DBA знал в линуксе только свои /u00 и /u01 и больше ничего, ни о каких системах управления конфигурациями, например, и речи не шло.

                      Я ещё видел людей, которые отвечали за систему мониторинга, они могли её установить командами из документации, но что такое LA они не знали, мол, мы даём только платформу, а что мониторить — сами решайте.

                      А ещё я видел человека, который поддерживал AD в очень большой компании и он рассмеялся мне в лицо, когда я сказал про DNS на LInux. Вот реально, человек очень хорошо разбирался в AD и мог админить винду, но про BIND он даже не слышал.
                        +4
                        О да, в больших компаниях такого валом. Когда берутся специалисты на очень узкие задачи. В итоге каждый окукливается в своём пузыре и не сильно стремится за него вылезать (такое не поощряется ни коллегами, на чью поляну ты хочешь залезть, ни руководством).
                          0
                          Мне как раз интресно как бывает в жизни. У меня очень специфичный опыт, поэтому и интересно как люди живут без понимания стека.
                            0
                            «В нашей жизни не всё, всегда и везде, а кое что, иногда и местами» (с) Максим Дорофеев.

                            Вот примерно так:)
                    +1

                    «… по словосочетанию «пожарный» выдавал около трёхсот вакансий по всей России. Для сравнения, поиск по фразе «врач-педиатр» выдаёт почти 2.5 тысячи вакансий, а «постовой ДПС» — почти 800...»


                    Как-то так

                      +7
                      Мне кажется, есть ещё один момент: технологии, с которыми работают сетевики, как правило уже вполне себе зрелые и стандартизованные, по ним написаны десятки книг и тысячи статей. Плюс от вендора к вендору реализации базовых вещей отличатся не сильно, и, условно, если можешь настроить влан на циске — то и на хуавее тоже сможешь без проблем. Да и 80% задач сетевика в обычной компании(не в телекоме, а в энтерпрайзе любого размера) покрывается вполне ограниченным набором технологий — вланы, OSPF, IPSec и т.д. Но эти технологии нужно именно понимать, чтобы успешно решать задачи.
                      Если же говорить о девопсе — то тут многие технологии и инструменты только формируются и развиваются, часто никто даже не обещает обратной совместимости между версиями, а многие инструменты, которые кажутся такими классными и перспективными сейчас, не факт, что будут столь же нужными через пару лет(чего не скажешь о BGP). Так что, по-моему, тут скорее нужен кругозор. Но, безусловно, понимать, как работают фундаментальные вещи, тоже нужно.
                        0

                        Вы очень сильно не правы. Точнее, правы, если ограничиваться очень простыми сетями. А вот если копнуть глубже, все становится очень динамично. Когда я пришёл в телеком, сети строились на Frame Relay, а резервирование в LAN делали на STP. Сейчас FR можно найти разве что в музее, а за STP вас засмеют. Зато появляется SDWAN (за рубежом — уже, у нас пока только самые передовики), в ДЦ строятся CLOS фабрики, и вообще строят малтиклауд. А сеть в том же AWS отличается от классических сетей примерно как тесла от телеги. Вроде и там и там колеса и обе ездят. А если строишь малтиклауд, то это надо скрестить ещё.
                        И по поводу книжек. Обратите внимание, что в переводе на русский есть материал только уровня CCNA. Остальные нет смысла переводить, устаревают быстрее.

                          +1
                          Да, возможно я и не прав, но тем не менее, много ли есть компаний, где у сетевиков есть необходимость поднимать и сопровождать условный сегмент-роутинг, опшн-си стыки и ещё что-нибудь хитромудрое? Такие, безусловно, есть, но их не так уж и много, в РФ это большая тройка, магистралы, датацентры и несколько крупных технологических компаний, типа Яндекса. В остальных тясячах компаний, где есть сетевые инженеры, набор технологий и ограничивается условным уровнем CCNA.

                          Но посыл мой был не в этом. Я хотел сказать, что если я знаю, как работает BGP — эти знания мне пригодятся и через 5 лет, и, почти наверняка, через 10. Тот же IS-IS сильно поменялся с момента появления? Да, оброс фичами, TLV понадобавляли, но суть-то осталось той же самой. С OSPF тоже всё примерно так же.

                          При чём тут мультиклауд я, если честно, не понял вовсе. Равно как и AWS(кстати, что вы считаете теслой, а что телегой?). В AWS сеть от вас скрыта почти полностью, вы можете управлять только распределением подетей и парой сервисов, типа DX, TGW, VPC-пиринга и т.д. Какие-то небесные технологии амазона вам, как пользователю, недоступны, так что стоит ли сравнивать пользовательский интерфейс, который вам предоставила платформа с полноценной сетью, которую вы строите и эксплуатируете? Но, повторюсь, я почти наверняка вас не понял, а вы на самом деле сетевик в Амазоне и говорите именно про небесные технологии(но тогда ваши слова про мултиклауд неуместны) :))

                          Если же говорить о девопсе, то 3 года назад я мог быть гуру Docker-swarm, но вот конфуз, кому сейчас нужен сворм? Или Nomad? Наверно есть компании, но надо признать, что эти технологии всё, учить их — пустая трата времени в мире победившего кубернетиса(только для развития кругозора, разве что). А одни и те же задачи можно решить десятком разных продуктов, и непонятно, какой лучше и правильнее.

                          А книги не переводят по-моему, по другой причине: книги уровня > CCNA нужны очень маленькому числу читателей, вот и всё:)) Неужели то, что написано в какой-нибудь «MPLS in SDN era» уже устарела?
                        +7
                        «Где можно вообще встретить сетевиков?»
                        А как же ЦОДы? Можно встретить ещё как, целый отдел только лишь сетевиков :)
                          +4
                          Далеко не везде требуется инженеру уметь в ansible, python, да даже в vlan…
                          Всё зависит от задач.
                          Когда я работал у интернет-провайдеров, то основными требованиями было понимание принципов работы сетей, умение быстро локализовать и ликвидировать неисправность (в случае когда 1000+ абонентов остались без интернета) и «чуйка на неисправности».
                          Половина инженеров у провайдера не понимают в Linux, CCNA и другие страшные слова тоже не знают =) Про документирование можно вообще не вспоминать, как и про английский…

                          Мое мнение: сетевые инженеры, которые постоянно развиваются и любят свою профессию — нужны. Люди, которые застряли на уровне «заменим свитч на чердаке, а Linux сами занимайтесь» — они тоже нужны, но это не сетевые инженеры, а уровень монтажника.
                            +1
                            Ну это из той же серии, что и обезьяну можно научить гвоздить забивать, обезьяной она от этого быть не перестанет.
                            Другое дело, что я неоднократно встречал сетевиков, которые не хотят (не любят / не умеют / не могут) изучать что-то за пределами Cisco, BGP/OSPF и так далее. Linux для них — тёмный страшный лес. И даже место для таких, я уверен, найдётся. Но мало, и занедорого
                              +2
                              Человеку может быть не интересен LInux, но при этом ему интересны менеджерские задачи, или архитектурные, например. Они хорошо знают, где, когда и как попилить сеть на сегменты и какие InterAS-стыки поднять, но как посмотреть дамп трафика в линуксе — им и не важно.
                                +2
                                Разные интересы — это прекрасно.
                                Плохо, когда человек превращается в биоробота и не понимает, а что он, собственно делает (особенно таким грешат всякие дежурные иженеры из операторов, всё знание которых про MPLS / L3VPN / BGP как правило сводится к набору команд, которые нужно в циску вбить, чтобы заработало.
                                  +2
                                  А чаще, какие команды вбить, чтобы примерно понять, что именно сломалось и на кого именно повесить эту аварию :)
                                    0
                                    Хорошо, если знают набор команд. Было время, я писал скрипты для securecrt и вешал на кнопки.
                              +2
                              Статья хорошая, но и комментарии очень хорошие.
                              Как и написали, все зависит от кругозора и готов ли сотрудник дальше развиваться. Поэтому всегда будут ситуации, когда будет нужен человек, который должен выяснить проблемы в сети. И не совсем ясно, почему автор считает, что при использовании kubernetes сетевики не нужны, очень даже нужны — упала сеть в кубере, иди и смотри какой плагин, контейнер не запускает сеть. На опыте было, что kubernetes не запускался из-за MTU (у провайдера 1470, вместо 1500) — искал причину долго и стало немного стыдно, что не посмотрел на такой параметр, про который новоиспеченные девопсы с курсов, даже могут не знать.
                                0
                                Я-то как раз на собственном опыте убеждался, и не раз, что сетевики нужны, даже если «всё в Кубере». Но вот у бизнеса / ит-менеджеров иногда иное мнение (ака «мы сейчас тут наймём девопсов, поставим кубер, и ни дба, ни сетевики нам не нужны»
                                +1
                                10лет был админом в провайдере. И линуховый, т.к. все маленькие провы начинают с ПЦ+Линь. Но сейчас ушел, т.к. провы укрупняются, а админы на периферии не нужны, а в столицах нужны с сертами. Да и уходят провы от линя: нынче купил железку — она и БЖП держит, она же кастомер сервисы держит (всех юзеров сразу), только биллинг к ней и все! Поэтому сфера сужается, смысла в ней быть все меньше…
                                  +1
                                  А вот тут сразу по нескольким пунктам не соглашусь ;)
                                  1) Линь на тазике живее всех живых. Особенно сейчас, когда есть DPDK, и можно не тратиться на какой-нибудь MX.
                                  2) Далеко не везде в столицах нужны серты, если речь не про интеграторов или какой-то очень суровый энтерпрайз.
                                  Ну и насчёт смысла в ней быть — каждый выбирает сам. Но могу точно сказать, что здесь всё ещё много интересного
                                    +1

                                    Про DPDK и MX разверните пожалуйста.
                                    Если это про fd.io то он IMHO пока больше Фреймворк для создания своего ПО чем продукт который можно в бой пускать.


                                    Если что-то иное — поделитесь пожалуйста тема интересна.

                                      0
                                      Мне кажется, уже довольно много такого, начиная с каких-то пакетов, которые можно заиспользовать напрямую или в составе своего софта, типа Bird или FRR, и заканчивая целыми дистрибутивами Linux — VyOS или Cumulus Linux.

                                      Но я не настоящий сварщик, каску на стройке нашёл, так что самому применять не приходилось, но я слышал, что наши сетевики такое используют вот прямо сейчас :)
                                        0

                                        Не тут вопрос был в разрезе именно DPDK.


                                        Просто что вы описали я и так знаю — у меня сеть в ДЦ на white box коммутаторах и Cumulus.


                                        FRR так же активно используем.

                                          0
                                          Ааа, ясно, тогда извините, что влез.

                                          А у вас нет планов описать свой опыт построения и эксплуатации вашей сети? Насколько она большая, какие фичи используются, как впечатления от кумулусов? Что нравится/не нравится по сравнению с циско/джунипер/хуавей/и т.д.? Мне кажется, это довольно интересная тема.
                                            0

                                            Пока нет, возможно позже.
                                            С самим кумулусом проблем не сильно много, у нас больше проблем с обвязкой управления сетью которая досталась в наследство.


                                            Разница с вендорами — нужно детально понимать как работают все компоненты, что-бы всё было стабильно, впрочем как и с любыми комплексными OSS решениями из мира linux.

                                            +2
                                            Ну вот мы на базе DPDK построили собственные брасы, которые вполне успешно молотили 10к+ абонентов на мелкую и дешевую коробку. Потом, правда, программу свернули, но не из-за неуспешности, а скорее по политическим мотивам.

                                            Другое дело, что готового дистрибутива, который можно развернуть и «заменить MX», мне еще пока не попадалось, но решить для себя конкретные задачи силами полутора программистов — запросто.
                                          +1
                                          PC и раньше могли молотить трафик мегапакетами.
                                          При наличии sr-iov / DPDK можно
                                          а) удобнее виртуализовывать такие роутеры (используя готовый софт-роутер или собрать свой)
                                          б) делать всякие штуки типа NAT / DPI, опирающиеся на DPDK.

                                          В общем я к чему — по моему опыту, софтроутеры как жили, так и живут (в среднем сегменте), и ничего с ними не сделается, особенно для процессороёмких задач типа NAT / DPI и прочего
                                            0

                                            Какие решения посоветуете?
                                            Именно в разрезе замены MX?


                                            Софт роутер это хорошо, но при скоростях 10G+ становится грустно даже с NAT и просто маршрутизацией уже на средних PPS.

                                              0
                                              Я тут тоже не очень настоящий сварщик, если честно, и давно не сталкивался с такими задачами.
                                              Cumulus? VyOS? 10G+ мне кажется вполне прожёвывается даже плюс-минус стоковым linux-ядром с тюненным sysctl, и проблемы начинаются на 40G+
                                              На forum nag ru можно глянуть я думаю, там много тредов на эту тему
                                                0

                                                Cumulus это про коммутаторы пока что, full view он там не переварит.
                                                10G на line rate это проблема если PPS большой, пока его пережёвывает только fd.io поверх DPDK и продукты построенные на нём, например https://www.tnsr.com/


                                                А вот MX и аналоги спокойно справляются.
                                                Стоковое ядро с тюненным sysctl живёт до первого DDoS на 10mpps потом становится весело.

                                                  0
                                                  Ого, а вы уже успели попробовать TNSR? Он-то full view держит? А что по pps? Неужели он такой производительный получился?
                                                    0

                                                    Нет TNSR пощупать не получилось, но щупал ванильный fd.io на самосборе с интеловвми картами — он показал line rate на маршрутизации без NAT и фильтров между 2 10G. TNSR построен на fd.io с рядом оптимизаций так что на базе опыта с fd.io я склонен доверять заявленным показателям.

                                                      0

                                                      И да full view и не один держит не напрягаясь frr на рядовом железе, проблема в data plane и его задержках при использовании ядра linux, а не в control plane.
                                                      Есть подвижки с DPDK и eBPF+XDP но они пока не могут быть применены достаточно широко т.к. это инструменты для разработки, а не готовое решение конкретных задач.

                                      +3
                                      Добавлю, что сетевики, умеющие автоматизировать программировать деплоймент — дорогой и редкий товар что в EU, что в Долине.
                                      Сейчас, да, продолжает расти потребность крупных организаций в сетевиках, которые разбираются с облачными технологиями (у AWS есть специальные сертификаты под это).

                                      Что объединяет это рынок: отдельно взятый сетевик, без дополнительных обязанностей — это удел крупных предприятий, чего не скажешь про DevOPS или сисадминов.

                                      (PS: это исходя из 10 лет опыта работы ведущим сетевиком в крупном Западном SaaS предприятии)
                                        +1
                                        Да, всё так.
                                        0
                                        Значит ли это, что сетевики более не нужны во времена победивших облаков, докера, кубернетиса и вездесущего публичного вайфая?

                                        Ну, кто-то же должен будет настраивать сети для всего этого…
                                          +1
                                          Сетевиков в провайдерах всегда будет меньше, чем компаний-клиентов этих самых провайдеров. А с учётом облаков и прочего self-service далеко не всем нужен не то что сетевик на ставку, но даже компетенции в сетях.
                                            0
                                            Ну, кто-то же должен будет настраивать сети для всего этого…

                                            По опыту работы в сетях самое главное для сетевика это диагностика, остальное — вторично. Часто решал задачи в saas и других системах, когда отваливалась as. запускали кольцо в несколько километров на 10ти гигабитах, VPN с урезанным MTU без возможности задать этот MTU, потеря vlan тегов, поиск кластеризации аплинков (ru работает, com лагает), да тупо знание в различии в 20 ответах команды ping часто помогает решить проблему, не говоря уже об NGN (sip-voip). Такие спецы как единороги.
                                            Также часто было «я знаю в чем проблема, дайте мне админа, я скажу что сделать», и это помогало. А всякие лаги с потерей window size в TCP пакетах на стриминговых сервисах та еще головная боль :)
                                            У меня есть несколько клиентов, которые раза 2 в год звонят и спрашивают «куда копать», когда их персонал уже всё перепробовал
                                              0

                                              Долгое время у сетевиков (как и у СХДшников, например) из средств диагностики была, по сути, только лампа подачи питания на корпусе железки. Тут придется Вангой стать от безысходности. Но ничего, сейчас туда насыпается какое-то количество внешних программистов, и они вытащат на свет весь ужос, происходящий в вендорских коробках.

                                                0

                                                Самое главное — это знать, как оно работает. Это поможет и в диагностике и в проектировании / строительстве.
                                                А так — вы всё правильно пишете, но дело обычно не ограничивается только диагностикой.

                                              0
                                              Профессиональные энергетики остались нужны только на электростанциях, профессиональные телефонисты — только в операторах, профессиональные специалисты по мультимедиа… ну вы поняли. Ждём, когда очередь дойдёт до девопсов и программистов, колесо прогресса никого не пощадит.
                                                +2

                                                Автор, расскажите пожалуйста для кого написана эта статья и какие выводы должен сделать читатель.
                                                Это предупреждение молодого поколения чтобы не шли в сетевики? (з/п небольшая, а вакансий мало)
                                                Это ожидание поддержки на тему "вы нужны ребята"?(20 лет назад телефонисты также говорили друг другу)
                                                Не, ну серьёзно это напоминает нытьё таксоблогеров на ютубе, что мол мы делаем важное дело, нас не ценят, автопилоты нас не заменят и всё в таком духе.

                                                  0
                                                  Мне не нужна поддержка — я вполне уверен в собственных знаниях и навыках.
                                                  Мне не нужно одобрение — я пишу то, что думаю.
                                                  Предупреждение… наверное, да. И не только / не столько для молодых.
                                                  Мир меняется. Чтобы быть востребованным (читай: хорошо зарабатывать) нужно знать не только свою песочницу, не только то, что понятно, изучено и испробовано.

                                                  С другой стороны, узкая специализация на то и узкая, что если уж она понадобилась, то проще нанять спеца с нужными знаниями, чем надеяться на то, что прилетит вдруг волшебник в голубом вертолёте и всё сделает «как надо».
                                                  0

                                                  Вопрос к автору и сетивикам.
                                                  В статье пишется, что на базе хостера или провайдера поднять маршрутизацию между vlanи развернуть acl и т д. Не разу не сталкивался с тем, что бы хостер/оператор предоставлял доступ к своим коммутаторам для настройки своей сети. Или вы описали какой то частный случай?

                                                    0

                                                    Обычно это делается либо на веделенном железе (которое вам продаст / сдаст в аренду хостер), либо в виртуальном окружении (если это облако)

                                                    0
                                                    Лично для меня, самым интересным местом для работы остается провайдинг. Т.к. там задачи для сетевика более глобальные, интересные и от сетевика много что зависит. Но беда в том, что провайдинг практически умер в этой стране. И сейчас если и найдешь местного провайдера, где ты можешь что-то решать, а не просто быть болванчиком и выполнять приказы сверху- то это провайдер эконом класса у которого все на соплях слеплено. Я сначала думал что это касается только маленьких городов, но когда поработал в местном провайдере в крупном городе. Я понял, что это везде так, т.к. такой трэшатины я давно не видел.
                                                    Недавно искал работу, пришлось уйти из этой сферы в интеграцию. Пока не жалею, здесб хоть мои сертификаты прогодились и платят достойно:)
                                                    Резюмируя, мне кажется что сетевики как отдельная область скоро перестанут существовать. Сейчас век разрабов, а им не надо большие сети, им подавай докеры, куберы и прочую виртуализацию.
                                                    С другой стороны, я считаю что сетевик должен быть в первую очередь инженером. А настоящий инеженер должен уметь разобраться во всем: в линуксах, в докерах, в программировании и т.д. Так что не пропадем :)
                                                      0

                                                      Про провайдинг всё так. Очень интересно с точки зрения технологий и "влияния", но очень плохо с деньгами. И это не только в РФ так, боюсь. Провайдинг во всём мире превращается в commodity, уже не нужно большое количество квалифицированных инженеров, а нормальный R&D есть только у самых крупных и инженеров там очень немного.


                                                      С интеграторами не всегда всё радужно бывает, но если получилось найти хорошее место, то очень рад за вас :)


                                                      Ну и с выводами соглашусь. Сетевик это прежде всего инженер, а инженер, вне зависимости от специализации, должен обладать живым умом и быть способным разбираться со всяким неопонятным.

                                                        0
                                                        Между инженером и обезьяной довольно много градаций и мне не совсем понятно откуда такой негатив к квалификации техника.

                                                        Вы же не принижаете авиатехников, которые также все делают по инструкции и могут сесть за отступление от нее, а чем хуже рядовые админы и сетевики?
                                                          0
                                                          Человек, который только кнопки нажимает, но не понимает, что там под капотом творится — он именно что обезьянью работу делает. Это не про соблюдение регламентов.
                                                          И никакого негатива к техникам нет :)
                                                      +1

                                                      Все так. В нашей крупной не ИТ международной компании (Fortune 500), только в России десяток собственных сетевых инженеров, не считая коллег в глобальных и локальных подрядчиках. Задача товарищей в передаче технических требований между различными командами, с обязательной экспертизой. Везде жестокий waterfall и ручной труд. Ожидаю что неизбежная автоматизация сильно упростит взаимодействия и освободит рабочие места.

                                                        0
                                                        Немного оффтопика — вы упомянули Thousand Eyes. Скажите, пожалуйста, вы использовали этот инструмент, можете поделиться опытом и впечатлениями?
                                                          0
                                                          Сам не использовал, но много хорошего слышал.
                                                          0
                                                          У Dolphined было лучший курс по ориентации в карьере. Раньше он был бесплатен.
                                                          www.udemy.com/course/it-networking-career-planning-guide-for-best-outcomes
                                                          CCIE давно девальвировался.
                                                          Хочется предсказуемости, стабильности, и выписывать лещей пионэрам разработчикам? Надо идти в безопасники…
                                                          Если сильно охото заниматься сетями, SDN, security и т.п. могу посоветовать Фактор Групп в Москве. Они в эту тему упарываются.

                                                          Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                                          Самое читаемое