Сетевики (не) нужны
На момент написания этой статьи поиск на популярном работном сайте по словосочетанию «Сетевой инженер» выдавал около трёхсот вакансий по всей России. Для сравнения, поиск по фразе «системный администратор» выдаёт почти 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 и сети для приватных облаков (например, TungstenFabirc или OpenvSwitch). Это ещё один огромный пласт знаний.
Если кратко, то я описал типичного T-shape специалиста (как сейчас модно говорить). Вроде бы ничего нового, однако же по опыту собеседований далеко не все сетевые инженеры могут похвастаться знаниями хотя бы по двум темам из списка выше. На практике, отсутствие знаний «в смежных областях» очень сильно затрудняет не только коммуникацию с коллегами, но и понимание требований, которые бизнес предъявляет к сети, как к самой низкоуровневой инфраструктуре проекта. А без этого понимания становится сложнее аргументированно отстаивать свою точку зрения и «продавать» её бизнесу.
С другой стороны, та самая привычка «разбираться в том, как работает система» даёт сетевикам очень хорошее преимущество перед различными «специалистами широкого профиля», которые знают о технологиях по статьям на Хабре/медиуме и чатикам в телеграме, но совершенно не представляют, на каких принципах работает тот или иной софт. А знание некоторых закономерностей, как известно, успешно заменяет знание множества фактов.
Выводы, или просто TL; DR
1. Сетевой администратор (как и DBA или VoIP-инженер) — это специалист довольно узкого профиля (в отличие от сисадминов/девопсов/SRE), потребность в котором возникает далеко не сразу (и может не возникать долго, на самом деле). Но если когда возникает, то его вряд ли получится заменить экспертизой со стороны (аутсорс или обычные админы широкого профиля, «которые ещё и за сетью присматривают»). Что несколько более печально — потребность в таких спецах мала, и, условно, в компании на 800 программистов и 30 девопсов/админов может быть всего два сетевика, которые прекрасно справляются со своими обязанностями. Т.е. рынок был и есть весьма и весьма небольшой, а так, чтобы с хорошей зарплатой — и того меньше.
2. С другой стороны, хороший сетевик в современном мире должен знать не только, собственно, сети (и как автоматизировать их настройку), но и как с ними взаимодействуют операционки и софт, которые поверх этих сетей бегают. Без этого будет крайне сложно понять, что просят от тебя коллеги и донести (обосновано) свои пожелания/требования к ним.
3. There is no cloud, it’s just someone else’s computer. Нужно понимать, что использование публичных/приватных облаков или услуг хостинг-провайдеров «который вам всё делает под ключ» не отменяет того, что ваше приложение всё ещё использует сеть, и проблемы с ней будут влиять на работу вашего приложение. Ваш выбор — где будет располагаться центр компетенции, который будет отвечать за сеть вашего проекта.
