Из сетевого инженера в DevOps: сети как преимущество, чего не хватает и зачем NetDevOps
Команда KAI Lab · · 8 мин чтения
Сетевому инженеру перейти в DevOps проще, чем кажется: DNS, балансировка, TLS и поиск проблемы по пути пакета — это большая часть разборов в Kubernetes и облаках, и здесь сетевик сильнее многих разработчиков. Не хватает обычно Linux на уровне администратора, Git, скриптов, контейнеров и CI/CD, а мостом между профессиями служит NetDevOps — автоматизация сетей через Ansible и Python.
Ниже — где сетевой опыт даёт фору, какие пробелы закрыть, как начать с автоматизации своей же сети и зачем здесь CCNA. Карта всех соседних переходов — в статье куда расти сисадмину и helpdesk.
Профиль не редкий. Среди 33 студентов KAI, чьи резюме мы разбирали в сентябре 2026 года, 17 — сисадмины, сетевики и специалисты helpdesk, медианный стаж — 5 лет, а 20 из 33 до учёбы не работали с DevOps.
Где сеть даёт фору
Kubernetes и облако — это много сети, спрятанной за YAML. Кто понимает, что происходит под ним, чинит быстрее.
| Что вы знаете из сетей | Как это выглядит в DevOps |
|---|---|
| DNS: записи, TTL, резолверы | Обнаружение сервисов в Kubernetes: у каждого Service есть имя вида my-svc.my-namespace.svc.cluster.local, а в /etc/resolv.conf пода стоит ndots:5 |
| Балансировка L4 и L7, health checks | Service, который реализует kube-proxy или прокси сетевого плагина; Ingress и Gateway API; readiness-пробы вместо проверок на балансировщике |
| Маршрутизация и NAT | Модель сети Kubernetes: у каждого пода свой IP, поды общаются напрямую, без NAT, даже на разных узлах. Сеть подов строит сетевой плагин (CNI) |
| ACL и firewall | NetworkPolicy на уровнях L3 и L4, security groups в облаке |
| TLS и сертификаты | Терминация TLS на входе в кластер, сертификаты в Secret, истёкший SSL-сертификат как классическая авария |
| tcpdump, Wireshark, путь пакета | Отладка между подами, узлами и балансировщиком: инструменты те же, интерфейсов и сетевых пространств имён больше |
Две детали, которые сетевик оценит сразу. Во-первых, NetworkPolicy сама по себе ничего не фильтрует: её применяет сетевой плагин, и если он политики не поддерживает, объект в кластере есть, а эффекта нет. Во-вторых, документация Kubernetes теперь называет Ingress API замороженным и рекомендует Gateway API — в нём шлюз (Gateway) и маршруты (HTTPRoute) описываются отдельными объектами.
Типичный вопрос дежурного «почему под не видит соседний сервис» начинается с DNS. Проверка по документации Kubernetes:
kubectl apply -f https://k8s.io/examples/admin/dns/dnsutils.yaml
kubectl exec -i -t dnsutils -- nslookup kubernetes.defaultServer: 10.0.0.10
Address 1: 10.0.0.10
Name: kubernetes.default
Address 1: 10.0.0.1kubectl exec -ti dnsutils -- cat /etc/resolv.confsearch default.svc.cluster.local svc.cluster.local cluster.local
nameserver 10.0.0.10
options ndots:5Сетевику здесь всё знакомо: какой резолвер, какие суффиксы поиска, почему короткое имя превращается в несколько запросов подряд. Разработчик на этом месте часто застревает. Больше приёмов — в статье DNS не резолвит в Linux.
Чего сетевику не хватает
- Linux как рабочая среда. systemd и journalctl, процессы, права, диски, пакеты. На собеседовании DevOps это спросят раньше, чем BGP.
- Git. Конфигурации и скрипты — только через репозиторий и merge request.
- Скрипты. Bash для обвязки, Python для автоматизации и работы с API.
- Контейнеры. Docker, образы, сети Docker, публикация портов.
- CI/CD. Пайплайн, который проверяет и выкатывает изменения без ручных шагов.
- Kubernetes целиком. Не только сеть, но и Deployment, пробы, лимиты ресурсов, хранилища.
- Метрики и алерты. Prometheus вместо опроса по SNMP, алерты на симптомы, а не на каждый порт.
Слабое место большинства сетевиков — Linux. Его стоит закрыть первым: всё остальное в DevOps запускается на нём.
NetDevOps: мост между ролями
NetDevOps — это практики DevOps, применённые к сети. Конфигурация описана кодом и лежит в Git, изменения проходят ревью и проверку в CI, а на оборудование их раскатывает инструмент, а не человек в консоли. Начинать удобно с того, что уже болит на работе: бэкап конфигураций, массовые однотипные изменения, проверка, что на всех коммутаторах одинаковые NTP и syslog.
Ansible для сети
Ansible работает с оборудованием без агента: подключается по SSH через ansible.netcommon.network_cli, а модули для конкретных ОС лежат в коллекциях, например cisco.ios. Описание VLAN на коммутаторах Cisco IOS:
- name: VLAN на коммутаторах доступа
hosts: access_switches
gather_facts: false
connection: ansible.netcommon.network_cli
vars:
ansible_network_os: cisco.ios.ios
tasks:
- name: Описать нужные VLAN
cisco.ios.ios_vlans:
config:
- vlan_id: 110
name: accounting
- vlan_id: 120
name: cctv
state: mergedstate: merged добавляет описанное к текущей конфигурации. overridden приводит VLAN на устройстве ровно к списку и удаляет лишние — его сначала пробуют на стенде. А rendered вообще не подключается к устройству и только показывает, какие команды ушли бы на коммутатор. Удобно для проверки в CI.
Python для сети
Для задач, которые не ложатся в модули Ansible, берут Python. Netmiko упрощает CLI-подключения к оборудованию разных вендоров, NAPALM даёт единый API поверх разных сетевых ОС. Минимальный скрипт на Netmiko:
import os
from netmiko import ConnectHandler
switch = {
"device_type": "cisco_ios",
"host": "10.10.10.10",
"username": "netops",
"password": os.environ["NET_PASSWORD"],
}
conn = ConnectHandler(**switch)
print(conn.send_command("show ip int brief"))
conn.disconnect()Пароль берётся из переменной окружения, а не из кода, и в репозиторий не попадает. Это та же дисциплина, что и в остальном DevOps.
Пайплайн для изменений сети
- Переменные сети — VLAN, интерфейсы, маршруты — лежат в Git.
- На merge request CI запускает
yamllintиansible-lintи рендерит конфигурацию. - Изменение прогоняется на стенде: в containerlab, GNS3 или EVE-NG.
- После ревью и слияния — раскатка на прод партиями, с бэкапом конфигурации перед изменением.
Такой пайплайн — готовый проект для резюме: в нём видны и сети, и Git, и CI.
CCNA как база
CCNA — не только про маршрутизацию. В официальном списке тем экзамена 200-301 v1.1 шесть разделов, и последний, Automation and Programmability, занимает 10%: REST API, JSON, возможности Ansible и Terraform, контроллерные сети. В разделе основ сетей есть отдельный пункт про виртуализацию — серверы, контейнеры и VRF. Подготовка к CCNA уже знакомит с DevOps-темами, пусть и на уровне «понимать, что это».
Дальше два пути, и их можно совмещать:
- CCNA Automation — экзамен 200-901 CCNAAUTO, раньше сертификат назывался DevNet Associate. Темы: разработка и API, развёртывание приложений, скрипты и тесты, инфраструктура как код на платформах Cisco. Формальных требований к кандидату нет, сертификат действует три года.
- CKA — если цель Kubernetes: два часа практических задач в командной строке, раздел Services & Networking — 20% веса.
Сертификат помогает пройти фильтр по резюме, но в DevOps сильнее работает репозиторий, где видно, как вы автоматизировали реальную сеть.
План перехода
| Шаг | Что делать | Что остаётся на руках |
|---|---|---|
| 1 | Linux на уровне администратора: systemd, журналы, права, диски | Свой Linux-сервер для инструментов автоматизации |
| 2 | Git и Python: ежедневный бэкап конфигураций в репозиторий через Ansible или Netmiko | Репозиторий с историей конфигураций и diff изменений |
| 3 | Docker и стенд: топология в containerlab, сервисы в контейнерах | Топология как код |
| 4 | CI: проверка и рендер изменений сети на каждый merge request | Работающий пайплайн |
| 5 | Kubernetes: k3s, сетевой плагин, NetworkPolicy, Ingress или Gateway API | Манифесты и заметки о разобранных поломках |
По объёму это сопоставимо с переходом из сисадмина в DevOps — несколько месяцев регулярной практики. Только у сетевика больше времени уходит на Linux, а у админа — на сети. Порядок остальных тем — в DevOps roadmap.
Если хочется попробовать DevOps-задачи без своего стенда, в симуляторе DevOps KAI Lab первый месяц как раз про сеть глазами DevOps: путь HTTP-запроса, порты, сертификаты и тикет «Сервис поднялся, но снаружи не открывается». Начать можно с бесплатного теста навыков.
Частые вопросы
Нужно ли сетевику учить программирование, чтобы уйти в DevOps? Нужен Python на уровне скриптов: работа с API, разбор JSON и YAML, шаблоны. Писать приложения не нужно. Хороший первый проект — бэкап конфигураций всех устройств в Git.
Что выбрать после CCNA: CCNP или DevOps? Если хочется глубже в сети — CCNP. Если тянет к автоматизации — Linux, CCNA Automation и DevOps-инструменты. NetDevOps позволяет не выбирать сразу: вы остаётесь сетевиком и набираете DevOps-опыт на своей же сети.
Бывают ли вакансии NetDevOps в Казахстане? Под таким названием почти нет: 25 сентября 2026 года поиск по слову NetDevOps на hh.kz по Казахстану не нашёл ни одной вакансии. Автоматизацию сетей стоит искать в требованиях к обычным вакансиям сетевых инженеров и DevOps, а не в заголовке.
Где больше вакансий — у сетевиков или у DevOps? По срезу hh.kz на 25.09.2026 по названию вакансии: «сетевой инженер» — 100, DevOps — 35. При этом 21 вакансия DevOps из 35 требует опыт от трёх лет, поэтому переходят чаще через смешанные задачи на текущей работе.
Что спросят сетевика на собеседовании DevOps? Linux, Docker и Kubernetes — обязательно, сети — как ваше преимущество: путь запроса от браузера до пода, DNS внутри кластера, TLS. Подборки — в статьях вопросы на собеседовании DevOps и вопросы по Kubernetes.
Источники
- Kubernetes. Services, Load Balancing, and Networking — модель сети, CNI, kube-proxy.
- Kubernetes. DNS for Services and Pods и Debugging DNS Resolution.
- Kubernetes. Network Policies и Ingress — статус Ingress API и рекомендация Gateway API.
- Cisco. CCNA Exam v1.1 (200-301) — Exam Topics.
- Cisco. CCNA Automation Certification.
- Ansible. Network Getting Started: first playbook и cisco.ios.ios_vlans.
- Netmiko, NAPALM, containerlab.
- The Linux Foundation. Certified Kubernetes Administrator (CKA).
- hh.kz, поиск по Казахстану, 25.09.2026: сетевой инженер — 100 вакансий, DevOps — 35, NetDevOps — 0.
- Данные о студентах — внутренний разбор KAI «Кто покупает — факт по 33 резюме и 12 кастдевам», 11.09.2026.