что нужно знать сетевому инженеру
Что должен знать сетевой инженер? Чек-лист
Относительно недавно наша компания организовала программу стажировки для молодых специалистов по направлениям:
1) Основы сетей. Думаю здесь и так все понятно. Только что понимать под “основами”? Ранее я записал видео курс молодого бойца, однако он подходит только для старта карьеры и его явно недостаточно для хорошего специалиста. По моему мнению инженер должен обладать знаниями на уровне CCNA или Comptia Network+. Сертификат в принципе не обязателен, но очень приветствуется (это поможет в карьере). На русском языке вряд ли получится что-то найти, поэтому могу только порекомендовать курсы от CBT Nuggets (платные). Есть интересные курсы на площадке Udemy.
2) Сетевые эмуляторы/симуляторы. Здесь тоже все очевидно. Трудно представить сетевого инженера, который не умеет пользоваться Cisco Packet Tracer или GNS3. UNetLab (теперь EVE NG) тоже будет весьма полезен. Вы просто обязаны уметь быстро развернуть макет “на коленке”. Навыки работы с VirtualBox и VMware Workstation также обязательны.
3) Основы безопасности сетей. Данный пункт многие забывают либо просто избегают. В целом, безопасность сетей это отдельное направление, однако оно абсолютно не самостоятельное. Невозможно серьезно заниматься безопасностью сетей не понимая как сеть работает. Можно утверждать и обратное — нельзя строить сеть совершенно не задумываясь о безопасности. Именно поэтому я настоятельно рекомендую изучить защиту сетей на уровне CCNA Security или Comptia Security+. Лично мне больше всего нравится курсы от CBT Nuggets и Cybrary. В простейшем случае можно начать вот с этого.
4) Основы криптографии. Данный пункт вытекает из предыдущего. Почти все компании активно используют VPN, Интернет все активнее переходит на https, кругом используются пароли… Очень печально видеть сетевого специалиста, который не понимает разницу межде pre-shared key и certificate based аутентификацией. Вы как минимум должны отличать симметричное шифрование от несимметричного, понимать что такое хэш и уметь хотя бы на пальцах объяснить основы PKI. Если рассматривать русскоязычные ресурсы, то есть несколько удачных курсов на Интуит. Лучшие курсы по криптографии на мой взгляд на Coursera.
5) Основы дизайна сетей. Хороший инженер должен не только уметь администрировать существующие сети, но и создавать новые. Это совершенно разные вещи. Для этого вам однозначно нужно знать основы дизайна. Отличная подготовка — CCDA (лучшее от CBT Nuggets). Также я попытался описать основные моменты в Архитектуре корпоративных сетей и в одном из наших вебинаров.
6) Документирование сетей. Данный пункт не любят большинство инженеров. Настраивать и тестировать сети это почти всегда весело, а вот разрабатывать документацию — ужасно скучно. Структурная схема, L2/L3 схемы, IP-адресация, описание настроек… Каждый инженер обязан уметь разрабатывать подобную документацию. Если вы создали и настроили сеть, но после этого не оставили ни единого документа с описанием, то вы просто не доделали свою работу — это халтура. К сожалению мне не приходилось встречать литературу, где бы описывали процесс создания технической документации (не проектирование). Если знаете подобное руководство, прошу написать в комментариях.
Не сетями едины
При работе с сетью весьма трудно избежать контактов с серверной инфраструктурой. Именно поэтому вы должны обладать хотя бы базовыми навыками в этой сфере. В большинстве организаций серверные специалисты выделяются в отдельную группу. При этом сетевые специалисты очень часто вынуждены с ними контактировать и должны общаться на “одном языке”. Ниже мы опишем еще несколько необходимых навыков для сетевого инженера:
7) Технологии виртуализации. Трудно представить компанию, которая бы не использовала средства виртуализации. Причем в виртуализацию уходят не только сервера, но и сети. Во многих организациях межсетевые экраны, маршрутизаторы, системы предотвращения вторжений также представлены в виде виртуальных машин. Вы просто обязаны иметь базовые навыки по работе с VMware ESXi и Microsoft Hyper-V. Необходимо понимать, что такое виртуальный свич или виртуальный адаптер. Опять же, рекомендую курсы от CBT Nuggets. Также можно посмотреть на Udemy.
8) Основы работы с Linux. Думаю данный пункт также для всех очевиден. Огромное количество маршрутизаторов и межсетевых экранов базируется именно на Linux. Proxy, Anti-Spam, IPS, DLP системы… все это в большинстве случаев слегка модифицированный Linux. Поэтому очень важно уметь ориентироваться в файловой системе, выполнять простейшие команды траблшутинга (ip route, tcpdump, traceroute) и править конфигурационные файлы с помощью встроенных текстовых редакторов (vi). Базовый курс по CentOS будет неплохим началом.
9) Основы работы с Windows Server. Практически в любой компании есть Windows Server, который за одно организует такие важные сервисы как NTP, DNS, DHCP и т.д. И было бы весьма неплохо уметь настраивать хотя бы эти службы, без которых сеть не будет функционировать в принципе. Лично мне нравится данный мини курс.
10) Основы программирования (bash, python). В жизни любого сетевого инженера появляется момент, когда встает задача автоматизации рутинных процессов. Здесь на выручку приходят “скрипты” (чаще всего bash или python). Бесплатных курсов по основам python великое множество и даже на русском языке. Однозначно рекомендую к изучению.
11) Английский. Если вы решили строить карьеру в области IT, то английский язык должен стать вашим вторым родным языком. Примите это за аксиому. Мое мнение — если вы плохо знаете английский, то вы плохой IT-шник. Как бы обидно это не звучало. 95% всех действительно полезных материалов публикуются в интернете именно на английском языке. Тот же экзамен CCNA сдается именно на английском языке. Почти весь материал на русском, это либо перевод (не всегда верный), либо устаревшая информация, т.к. новую просто еще не успели перевести. Более подробно об этом можно почитать здесь.
С нашей точки зрения именно так выглядит список необходимых знаний для сетевого инженера. Это необходимый фундамент для дальнейшего профессионального роста.
Кроме того, относительно недавно компанией Cisco была опубликована статья “Network Transformation and Essential Skills for Next Generation Network Engineers”. Если перевести дословно, то получится что-то вроде: “Трансформация сетей и основные навыки сетевых инженеров следующего поколения”. Если кому то лень читать презентацию полностью, то здесь будут отображены основные моменты (на русском).
Будем рады, если вы поделитесь своими мыслями по поводу необходимых навыков сетевого инженера.
P.S. Также хотели вам сообщить, что мы периодически проводим бизнес-завтраки где обсуждаем различные IT-технологии. Из ближайшего:
Зарегистрироваться можно здесь. При регистрации на Workshop укажите ту тему, которую Вы хотели бы посетить.
Сетевики (не) нужны
На момент написания этой статьи поиск на популярном работном сайте по словосочетанию «Сетевой инженер» выдавал около трёхсот вакансий по всей России. Для сравнения, поиск по фразе «системный администратор» выдаёт почти 2.5 тысячи вакансий, а «DevOps инженер» — почти 800.
Значит ли это, что сетевики более не нужны во времена победивших облаков, докера, кубернетеса и вездесущего публичного вайфая?
Давайте разбираться (с)
Давайте знакомиться. Меня зовут Алексей, и я сетевик.
Я больше 10 лет занимаюсь сетями и больше 15 лет работаю с различными *nix системами (довелось ковырять и Linux, и FreeBSD). Работал в операторах связи, крупных компаниях, которые принято считать «энтерпрайзом», а последнее время работаю в «молодом и дерзком» финтехе, где облака, девопсы, кубернетесы и прочие страшные слова, которые обязательно сделают меня и моих коллег ненужными. Когда-нибудь. Может быть.
disclaimer: «В нашей жизни не всё, всегда и везде, а кое-что, иногда и местами» (с) Максим Дорофеев.
Всё ниженаписанное можно и нужно считать личным мнением автора, не претендующим на истину в последней инстанции, и даже на полноценное исследование. Все персонажи вымышленны, все совпадения случайны.
Добро пожаловать в мой мир.
Где можно вообще встретить сетевиков?
1. Операторы связи, сервисные компании и прочие интеграторы. Тут всё просто: сеть для них — это бизнес. Они либо напрямую продают связность (операторы), либо оказывают услуги по запуску/обслуживанию сетей своих заказчиков.
Опыта здесь много, денег — не очень (если вы не директор или успешный менеджер-продажник). И тем не менее, если вам нравятся сети, и вы только в начале пути, карьера в саппорте какого-нибудь не очень крупного оператора будет, даже сейчас, идеальной точкой для старта (в федеральных всё очень скриптовано, и простора для творчества мало). Ну и истории про то, что можно из дежурного инженера дорасти за несколько лет до C-level manager тоже вполне реальны, хотя и редки, по понятным причинам. Потребность в кадрах есть всегда, потому что текучка таки имеет место быть. Это и хорошо, и плохо одновременно — всегда есть вакансии, с другой стороны — зачастую, самые активные/умные достаточно быстро уходят либо на повышение, либо в другие, более «тёплые» места.
2. Условный «энтерпрайз». Не важно, связана ли его основная деятельность с ИТ, или нет. Главное — что в нём есть свой IT отдел, который занимается обеспечением работы внутренних систем компании, в том числе сети в офисах, каналов связи в филиалы и т.д. Функции сетевого инженера в таких компаниях может «по совместительству» выполнять системный администратор (если сетевая инфраструктура небольшая, или ей занимается внешний подрядчик), а сетевик, если он всё-таки есть, может присматривать заодно за телефонией и SAN (ненуачо). Платят по-разному — сильно зависит от маржинальности бизнеса, размеров компании и структуры. Я работал и с компаниями, где циски регулярно «грузили бочками», и с компаниями, где сеть строили из фекалий, палок и синей изоленты, а серверы не обновляли, примерно, никогда (надо ли говорить, что никаких резервов тоже предусмотрено не было). Опыта здесь сильно меньше, и он, почти наверняка будет в области жёсткого vendor-lock, либо «как из ничего сделать кое-что». Лично мне там показалось дико скучно, хотя многим нравится — всё достаточно размеренно и предсказуемо (если мы говорим о крупных компаниях), «дораха-бахато» и т.д. Не реже раза в год какой-нибудь крупный вендор говорит, что придумал очередную мега-супер-пупер-систему, которая вот вообще всё сейчас автоматизирует и всех сисадминов и сетевиков можно будет разогнать, оставив парочку для нажимания на кнопки в красивом интерфейсе. Реальность же такова, что, даже если абстрагироваться от стоимости решения, никуда сетевики оттуда не денутся. Да, возможно, вместо консоли снова будет веб-интерфейс (но уже не конкретной железки, а большой системы, которая управляет десятками и сотнями таких железок), но знания «как всё внутри устроено» всё равно понадобятся.
3. Продуктовые компании, прибыль которой приносит разработка (и, часто, эксплуатация) какого-нибудь софта или платформы — того самого продукта. Обычно они небольшие и шустрые, им ещё далеко до масштабов энтерпрайзов и их бюрократизованности. Именно здесь массово водятся те самые девопсы, куберы, докеры и прочие страшные слова, которые обязательно сделают сеть и сетевых инженеров ненужным рудиментом.
Чем сетевик отличается от сисадмина?
В понимании людей не из ИТ — ничем. И тот, и другой смотрят в чёрный экран и пишет какие-то заклинания, порой тихонько матерясь.
На самом же деле, главное отличие — это подход к работе. Пожалуй, именно среди сетевиков больше всего встречается сторонников подхода «Работает — не трогай!». Сделать какую-то вещь (в рамках одного вендора) можно, как правило, только одним способом, вся конфигурация коробки — вот она, на ладони. Цена ошибки — высокая, а иногда и очень высокая (например, придётся ехать за несколько сотен километров, чтобы перезагрузить роутер, а в это время без связи будут сидеть несколько тысяч человек — вполне обычная для оператора связи ситуация).
На мой взгляд, именно поэтому именно сетевые инженеры, с одной стороны, крайне сильно мотивированы на стабильность сети (а изменения — главный враг стабильности), а во-вторых, их знания идут больше вглубь, чем вширь (не нужно уметь конфигурировать десятки разных демонов, нужно знать технологии и их реализацию у конкретного производителя оборудования). Именно поэтому сисадмин, который нагуглил, как на циске прописать влан — это ещё не сетевик. И вряд ли он сможет эффективно поддерживать (а так же траблшутить) более-менее сложную сеть.
Но зачем нужен сетевик, если у вас есть хостер?
За дополнительную денежку (а если вы очень крупный и любимый клиент — может даже и бесплатно, «по дружбе») инженеры датацентра настроят ваши коммутаторы под ваши нужды, и, возможно, даже помогут поднять 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, если есть возможность) подсеть, которую самостоятельно (или через хостера) анонсировать в мир.
Может ли всё это сделать «обычный» сисадмин, не обладающий глубокими знаниями в сетях? Не уверен. Будет ли это делать хостер? Может и будет, но от вас потребуется довольно детальное ТЗ, которое тоже нужно будет кому-то составить. а потом проконтролировать, что всё сделано правильно.
Предположим, у вас есть VPC в каком-то публичном облаке. Чтобы получить доступ из офиса или on-prem части инфраструктуры к локальной сети внутри VPC, вам нужно настроить подключение через IPSec или выделенный канал. С одной стороны — IPSec дешевле, т.к. не надо покупать дополнительное железо, можно настроить туннель между вашим сервером с публичным адресом и облаком. Но — задержки, ограниченная производительность (т.к. канал требуется шифровать), плюс негарантированная связность (т.к. доступ идёт через обычный интернет).
Поднять подключение через выделенный канал (например, у AWS это называется Direct Connect). Для этого найти оператора-партнёра, который вас подключит, определиться с ближайшей к вам точкой включения (как вас в оператора, так и оператора в облако), и, наконец, всё настроить. Можно ли всё это сделать без сетевого инженера? Наверняка, да. А вот как это без него траблшутить в случае проблем — уже не так понятно.
А ещё могут возникнуть проблемы с доступностью между облаками (если у вас мультиклауд) или проблемы с задержками между разными регионами и т.д. Безусловно, сейчас появилось много инструментов, которые повышают прозрачность того, что происходит в облаке (тот же Thousand Eyes), но это всё инструменты сетевого инженера, а не его замена.
Я мог бы ещё десяток таких примеров из своей практики набросать, но, думаю, понятно, что в команде, начиная с определённого уровня развития инфраструктуры, должен быть человек (а лучше больше одного), который знает, как работает сеть, сможет настроить сетевое оборудование и разобраться в проблемах, если они возникнут. Поверьте, ему будет чем заняться
Что должен знать сетевик?
Совсем не обязательно (и даже, иногда, вредно), сетевому инженеру заниматься только сетью и более ничем. Даже если не рассматривать вариант с инфраструктурой, которая почти целиком живёт в публичном облаке (а он, как ни крути, становится всё популярнее и популярнее), и взять, например, on premise или приватные облака, где на одних только «знаниях на уровне CCNP» не выедешь.
Помимо, собственно, сетей — хотя тут просто бескрайнее поле для изучения, даже если концентрироваться только на каком-то одном направлении (провайдерские сети, энтерпрайз, датацентры, вайфай. )
Разумеется, многие из вас сейчас вспомнят про Python и прочую «network automation», но это лишь необходимое, но не достаточное условие. Чтобы сетевой инженер «успешно влился в коллектив», он должен уметь разговаривать на одном языке и с разработчиками, и с коллегами админами/девопсами. Что это значит?
С другой стороны, та самая привычка «разбираться в том, как работает система» даёт сетевикам очень хорошее преимущество перед различными «специалистами широкого профиля», которые знают о технологиях по статьям на Хабре/медиуме и чатикам в телеграме, но совершенно не представляют, на каких принципах работает тот или иной софт. А знание некоторых закономерностей, как известно, успешно заменяет знание множества фактов.
Опыт построения карьеры сетевого инженера
инженер IP-сетей компании Linxdatacenter
Карьеру в ИТ сегодня чаще всего ассоциируют с задачами в области разработки софта. Программист, тестировщик, системный архитектор, тим-лид и подобные позиции у всех «на слуху». Между тем, ничуть не менее важная область современных цифровых решений представлена сетями, где свой вклад в создание и работу самых современных digital-продуктов делают сетевые инженеры.
Кто такой сетевой инженер?
Прежде всего, определимся с терминами. Сетевой инженер — это специалист, отвечающий за создание, настройку и обслуживание внутренних компьютерных сетей компании, а также за взаимодействие ИТ-инфраструктуры компании с внешними сетями. «Сетевики» должны обладать серьёзным уровнем знаний в области дизайна и поддержки работы сетей, однако их работа будет включать в себя элементы серверного администрирования и программирования.
Требуется разбираться в локальных сетях, оборудовании и софтверных решениях, используемых в компании для управления сетевой составляющей ИТ-систем. Все это обеспечивается только высоким уровнем квалификации сетевого специалиста: пробелы в образовании и практическом опыте могут обойтись компании очень дорого, а с учётом глубины интеграции бизнес-процессов в цифровой среде, масштабы потенциальных убытков иногда довольно трудно представить, и лучше их не допускать даже в теории.
Ценность сертификации
Развитие любой карьеры зависит от конкретного человека, в особенности от осознанности выбора, нацеленности на результат и готовности к трудностям. При построении карьеры в сфере ИТ стоит выделять приоритетные направления и задачи. Я начал процесс самообразования, имея за плечами успешную карьеру в совершенно другой, не связанной с ИТ и телекоммуникациями области.
В качестве первой, промежуточной, цели на карьерном пути сетевого инженера можно назвать сертификацию одного или нескольких вендоров сетевого оборудования. Если рассматривать наиболее популярного вендора, то получение знаний на уровне CCNA (первый уровень в системе сертификаций Cisco) является объективным входным барьером для работы сетевым инженером.
Этот сертификат не является свидетельством определённого уровня знаний, но указывает на наличие базового понимания работы с сетевым оборудованием. Для людей, только начинающих карьеру в отсутствии опыта работы, наличие сертификата может быть хорошим подспорьем при устройстве на работу.
Прохождение курса CCNA на базе одного из учебных центров даёт определённые знания, но с точки зрения полученного опыта, максимальный результат можно получить только с уже имеющимися знаниями, путём их структурирования на курсе и получения ответов на уже сформировавшиеся вопросы. Очень многое зависит от преподавателя на курсе, стоит искать преподавателя не только с собственной высокой квалификацией, но и с хорошими навыками преподавания.
Источники информации
Перед прохождением курса любого из вендоров необходимо уделить время тщательному изучению профессиональной литературы по сетевой тематике и ИТ в целом. Среди огромного объёма доступных ресурсов для развития, для себя я выделил следующие:
Эти ресурсы — обязательная база.
Дополнительные источники
Этими источниками я пользуюсь на текущий момент при подготовке к сертификациям:
Всё перечисленное — лишь основные источники информации, которыми пользовался я сам. На текущий момент они помогли мне добиться поставленных перед собой целей. Я продолжаю активно ими пользоваться в ежедневной работе и дальнейшем самообучении.
Думаю, что для начала карьеры этого списка более чем достаточно. На просторах сети много рекомендаций типа «читать всё и обо всём», но книги по сетевой тематике достаточно объёмные, так что я бы не рекомендовал распыляться. В любом случае придётся осваивать разные направления для того, чтобы на одном языке разговаривать с коллегами из других департаментов, но на этапе становления глубоко погружаться, например, в виртуализацию однозначно не стоит.
Вендоры: Cisco как стандарт, Китай как перспектива
Что касается вендоров, то после освоения Cisco я однозначно рекомендую изучать Juniper, однако начинать с него будет тяжелее ввиду специфического представления конфигурации. Cisco в этом плане на порядок более «новичок-френдли» вендор: для сравнения, страница конфигурации на Cisco в переложении на Juniper будет составлять уже 2–3 страницы. Juniper — это продвинутый этап, следующая ступень вашего образования в сетях.
Cisco можно с уверенностью называть отраслевым стандартом сегодня. Возможно, в будущем мы увидим китайских вендоров, занимающих значимую нишу на этом рынке (Huawei, H3C, D-Link). Но пока что для начального этапа становления сетевого инженера можно почти полностью полагаться на Cisco и созданную вокруг их решений экосистему образовательного контента и сертификаций.
Отмечу, что ценность вендорских сертификатов очень разная, они по-разному воспринимаются вашими будущими работодателями и коллегами. Каждый решает сам, надо их получать или не надо, главное — получение определённого уровня практики в процессе подготовки. Некоторые сертификаты обязательно включают практическую часть с выполнением реальных заданий, и в этом их неоспоримая, а, может быть, и главная ценность. Пока ты активно готовишься к экзаменам, то получаешь опыт и базовые навыки, которым на начальном этапе профессионального развития взяться больше неоткуда.
Дальнейшее развитие: основные направления
Дальнейшее и более глубокое развитие «сетевика» я вижу через проработку компетенций в области информационной безопасности сетей.
Всё более заметную роль в связи с развитием облаков играет и виртуализация, поскольку на виртуальную парадигму работы переходят не только сервера, но и сети (виртуальные маршрутизаторы, сетевые экраны и т. д.).
Весьма актуальным умением становятся также навыки, позволяющие автоматизировать определённые рутинные процедуры работы сетевых инженеров, а значит, нужно уметь писать код, хотя бы на базовом уровне для решения простейших задач автоматизации.
По мере развития технологий будет трансформироваться и содержание работы сетевых специалистов. Чтобы соответствовать этим изменениям, нужно постоянно самостоятельно совершенствовать свои профессиональные знания и навыки.