Автоматизация сети

Автоматизация сети — рассмотрим основные связанные вещи. Общие моменты относительно автоматизации сети в целом. И частные, касаемо автоматизации сети в 2025 году.

С чего бы начать? Так тут много всего, много разнопланового, мысли разбегаются. Наверное начну с определения границ текущего рассмотрения. Давайте ещё раз проговорим про три типа сети:

• Провайдерская сеть;
• Энтерпрайзная сеть (сеть организации);
• Сеть дата-центра.

В провайдерской сети трафик от разных абонентов нужно инкапсулировать, мультиплексировать, поместить в среду передачи для доставки из точки A в точку B. В энтрепрайзной сети трафик вертикальный, идёт снизу от пользователей на уровне доступа вверх к ресурсам, подключенным к ядру сети, и вверх в интернет (и обратно). Поскольку все крупные компании гео-распределеные, нужно гонять трафик между локациями. В дата-центрах также есть гео-распределённость, если смотреть внутрь самого дата-центра, то трафик там (в отличии от энтерпрайза) горизонтальный, между серверами. Конечно же сильное упрощение, но если брать основное, такое вот оно получается. Добавьте сюда различие в используемых линейках оборудования и протоколах (обзорное видео на тему).

Казалось бы разные сети, ну и что, а автоматизация-то тут причем? Автоматизация это про скрипты, какая разница что за сеть? Нет, разница может случиться. В чём она могла бы заключаться, поговорим далее. Пока же договоримся о том, что будем рассматривать автоматизацию только энтерпрайзной сети.

Автоматизация энтерпрайзной сети

И тут такое дело, что автоматизация гео-распределения уже есть. Да-да, это мой любимый SD-WAN. Не надо ничего придумывать, берётся готовое решение, их много, внедряется, профит. Готовая автоматизация, управляться с которой сможет один человек, максимум два для резервирования (на случай отсутствия первого). Причём двоих хватит на инсталляцию большого размера и числа устройств. Разумеется понадобятся техники на местах, не без этого, но двоих центровых хватит для обслуживания огромной структуры. Почему? Вот потому что автоматизация и автоматизация будет выполнять 99% работы (вкалывают роботы, а не человек).

Раз между локациями автоматизировано (и выдумывать здесь ещё один велосипед нет смысла), значит автоматизировать нужно непосредственно сами локации. Внутри локации. То есть, всем известную two-tier/three-tier модель сети от циски, которая жива-здорова и применяется везде. Существует решение SD-Access всё от той же циски, с фабрикой и управляющим DNA Center. Да, тоже готовая автоматизация казалось бы. Только вот не взлетело оно, другие вендоры не предложили похожего, а самих внедрений по пальцам пересчитать. Как-то не прижилось. И похожая по концепции ACI (Application Centric Infrastructure, та же фабрика, тот же DNA Center чуть изменённый) тоже не особо взлетела, сложно-дорого, много вопросов и главное много проблем при эксплуатации. Напомню, ACI (в рамках энтерпрайза и Enterprise Architecture соответственно) нацелена на модуль Server Farm. Получается решения здесь вроде есть, а вроде их и нету.

Подытожим предварительно: Нужно выдумать про автоматизацию энтерпразной локации, изобретать. Подождите ржать: Всё давно есть, а он тут выдумывать собрался, гыыыыы! В этом-то и заключается главная ошибка текущего подхода к автоматизации сети. Не всё, к сожалению, есть. Наоборот, есть только немношк, гулькины слёзы. Даже если и есть что-то, давайте ещё поизобретаем? Никто же не мешает и не запрещено.

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

---

Вопросы за автоматизацию

• А что вообще такое автоматизация сети?
• Какая основная цель автоматизации сети?
• Нужна ли автоматизация сети, может лучше без неё?
• На каком уровне находится автоматизация в некой абстрактной организации?
• Как, в каком виде, реализовать автоматизацию сети?
• Какие предварительные требования для внедрения автоматизации?
• Что считать автоматизированной сетью?

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

Постановка правильных вопросов гарантирует высокую вероятность успешного исхода дела.

Вопросы поставлены, постараемся ответить. Это будет весьма интересно и если мои ответы не устроят, будут абсурдными неправильными/неполными/узкими, вы пожалуйста помогайте. Включайтесь в обсуждение. Один разум хорошо, но не всегда достаточно. В любом случае, при развитии автоматизации, эти вопросы встанут рано или поздно и ответы будут даны. Почему же не нами? Почему бы нам не стать первопроходцами в некотором смысле? Давайте попробуем. Часть вопросов очевидно при этом развалится ещё на подмножество вопросов. Да, вот так сложно. Ну и тема непростая.

Отвечая на вопросы, разложим автоматизацию сети по полочкам, проясним моменты и незаметно для самих себя придём к заключительным выводам. Формулирование выводов и станет по сути процессом изобретения. Точнее так: После понимания финального вывода как же реализовывать автоматизацию сети, изобретать что-либо далее уже не понадобится.

Что такое автоматизация сети

Очень интересная вещь. Исчерпывающего определения нету. А нету его по причине “что вроде бы и так ясно”. Зачем определять то, что интуитивно понятно? Нет, господа мои хорошие, не ясно и не понятно. В том то и дело. Сначала всегда даются определения-аксиомы, на их базе строится дальнейший контент и логика. Это хороший, правильный тон при разработке любой области знаний, любой математической модели. Сначала аксиомы, потом теоремы. Только так и никак иначе.

Давайте спросим у Яндекса как всегда. Что тут? АДСМ конечно, Хабр “наше всё” и отдельные сайты. Нет ответа. Если не увидел/не нашёл, киньте в меня ссыль плз. Самое лучшее из найденного:

Сетевая автоматизация — это процесс автоматизации настройки, управления, тестирования, развертывания и эксплуатации физического и виртуального сетевого оборудования.

Масло масляное, автоматизация — процесс автоматизации. Логично, поддерживаю, обеими руками “за” даже. Как быть, Яндекс не помог? Поразмышлять самому вокруг темы. Так и сделаю. Размышляю: Может ли существовать сетевая автоматизация в отрыве от сетевого оборудования? — Скорее нет, чем да. Возможно да в каких то мелких вопросах, связанных с планированием, выполнением, верификацией. Значит, отметим момент:

Автоматизация сети — это всегда про сетевое оборудование.

Именно поэтому автоматизация сети не может быть чем-то умозрительным, только концепцией или только методологией. Она (автоматизация) имеет конечный результат, который можно “пощупать” руками.

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

А что из этого нужно и хотелось бы автоматизировать? — Да всё! Всё, абсолютно всё. Тем более что типовой целевой конфиг, типовая инвентаризационная запись, типовое внесение изменений при реагировании на типовое событие:

Сеть заточена чтобы быть автоматизированной.

Дальше: Может ли автоматизация сети существовать в отрыве от сетевого инженера и его задач? — Точно нет. Поэтому в первом приближении определение следующее:

Автоматизация сети — упрощение выполнения типовых задач сетевым инженером, возникающих на всех этапах жизненного цикла оборудования.

Всё что даёт упрощение, является автоматизацией в том или ином виде. Не обязательно про скрипты. Уволился с работы, стало совсем просто — сильная автоматизация (шутка). Упрощение, в этом смысл. Было: Инженер работает много и сложно, стало: Он же работает мало и просто. Здесь же ответ на вопрос, для чего автоматизация сети нужна:

Автоматизация сети нужна для значительного (!) снижения сложности эксплуатации сети, времени, издержек и затрат на такую эксплуатацию.

Раз упоминали затраты, скажем и про бизнес (сказал А, говори Б).

Автоматизация сети и бизнес

Бизнес всегда про деньги, а раз автоматизация сети снижает затраты, значит бизнес в ней крайне заинтересован. Значит, нравится вам или нет, автоматизация сети будет внедряться, расти, ширится, пока не захватит всё. Появятся коммерческие решения. Во множестве. И будут пользоваться значительным спросом. Не потому что я так придумал или хочу. По законам рынка.

Обратная сторона палки, количество сетевых инженеров сильно подсократится. И это тоже выгодно для бизнеса, так как зарплаты основная статья расходов и квалифицированному инженеру надо платить много. Вопрос: Нужна ли автоматизация сети или нет, отвечен. Нужна/нет.., она будет. Глобальной автоматизации быть, требование бизнеса, требование рынка.

Текущий уровень автоматизации сетей

А что же у нас на текущий момент по стране с автоматизацией сетей? Мы совместно с телеграм-каналом NetAutomation Area до НГ запулили опросец, какая автоматизация сети применяется на предприятиях у читателей моего канала и канала NetAutomation. Да, выборка крайне маленькая, с другой стороны сетевых инженеров тоже несильно много. Судя по ответам, в примерно трети организаций никакой автоматизации сети нет, а там где есть — основное решение это Ansible, используемый совместно с самописными скриптами. Про “у нас всё круто и всё автоматизировано” заявило пару человек. Насколько такие результаты близки к реальной ситуации? Думаю, очень близки, весьма достоверные.

Вот такой печальный текущий уровень автоматизации сети на предприятиях РФ. Или вообще нету, или местечковое применение самописных скриптов (для решения отдельных, узких задач). Автоматизация сети точно есть в крупном финтехе, провайдерах, дата-центрах, IT-гигантах. Но если брать энтерпрайз, даже крупный из первой сотни, автоматизация сети хоть в каком-то виде присутствует далеко не везде. Таким образом, развитие автоматизации сети в нашей стране на момент находится в очень начальном состоянии. И впереди большой путь. Который приведёт куда? К глобальной автоматизации конечно же. Куда ещё. Обязательно. Тут без вариантов. И у нас, и во всём мире.

Почему Ansible

Если открыть талмуд (CCNP Enteprise Guide, выпущенный Cisco Press и датируемый 2020 годом), то там кроме Ansible упомянуты Salt и Puppet. Почему же они не взлетели, а Ansible да? Подзабыл этот момент немножко, на самом деле на поверхности. Salt/Puppet решения agent-based, а Ansible agent-less. Для серверов наверное непринципиально, а для сетевых железок критично (агент должен быть в прошивке). Таким образом, этот (Ansible) выстрелил, а те за бортом.

Озвучим очевидный результат:

Сейчас, в 2025 году, автоматизация сети равно Ansible.

Поэтому никто и не копает глубже. Есть Ansible, он же и есть автоматизация сети, что ещё нужно? А мы копаем как раз далеко, за Ansible.

Как реализовать автоматизацию сети

Главный вопрос: Казалось бы бери Ansible и вперёд, да? Не так всё просто. Тут придётся с большим удовольствием ткнуть в болевые точки текущей ситуации. Именно поэтому не хотел выкладывать разбор результатов опроса про автоматизацию сети до НГ. Портить новогоднее настроение людям всякими инсинуациями, считаю не очень.. А сейчас уже можно.

Вот это вот синкопа? — Чушь собачья, а не синкопа. Вот синкопа.

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

А как же это бывает тогда? Обшаривается интернет/спрашивается у ChatGPT, здесь-там надёргивается готовых скриптов/солюшенов под Ansible, пробуется на тестовой железке, правится буквально пару строчек и в прод. В лучшем случае. В худшем, из частей надёрганных скриптов лепится такой Франкенштейн-скрипт. А решаемая задача, это обычно тут разлив/верификация конфигов на устройства. Да, друзья, одна единственная задача. Ведь Ansible только система управления конфигурациями. Да, вопрос разлива конфигов безусловно важен, но по факту это не вся автоматизация сети:

Автоматизация сети не только в разливе конфигов.

Что же получается из всего этого? То есть, возможно какую-то задачу по внесению изменений на устройства мы действительно упростим. При этом нужно уметь в Ansible (условно просто), в “писать” скрипты (посложнее), желательно выучить Питон (совсем сложно), настроить планировщик тасков и много чего ещё (тоже занимает время). Получается решая одну сложность, мы получаем другую. Какая из них больше, так сразу и не скажешь. Чтобы оценить объёмы возможного труда, предлагаю посмотреть видос с linkmeup.

Обобщаем: Да, скрипт даёт универсальность, значительную гибкость, выполняется в заданное время действительно без участия человека. Но сколько нужно ручного труда, прежде чем такой скрипт появится, заправится правильно в Ansible, поставится на выполнение. Верификация результатов работы вручную. Можно впихнуть верификацию и даже откат изменений в сам скрипт. Представьте насколько при этом увеличиваются объёмы ручного труда. То есть снеговики “скриптовики” по сути каторжники. Голова у них всегда в цветах (что видно, что они демонстрируют), а известное место значительно в мыле (что скрыто, что предшествует “триумфу”).

Примеры автоматизации

Живых примеров очень мало. Очень-очень-очень. В основном что-то там как-то автоматизированное в лабораторной среде. В EVE. Да, круто, академично, важно, проделана большая и сложная работа. Только это всё не про жизнь. Какое отношение это имеет к реальной жизни? Далёкое, мягко скажем. Автоматизация это? Нет, не автоматизация. Всего лишь умозрительный пример. Раскатайте в прод, на настоящие железки, сразу станет автоматизацией. А так-то “мультики рисовать” многие умеют и любят. Ещё раз подчеркну мысль:

Автоматизация возможна только в продуктовой среде.

NAPALM/Nornir

Ansible очень хорош для работы с линуксовыми серверами, идеален даже. Но вот для сетевого оборудования не так хорош. Появился NAPALM (Network Automation and Programmability Abstraction Layer with Multivendor support), затем Nornir. Тут уже серьёзней:

• Сравнение текущей конфигурации с целевой;
• Откат изменений при ошибке.

Казалось бы супер? С одной стороны да, с другой всё тот же “разлив конфигов only”. Автоматизация сети жёстко залипла на разливе конфига. Единообразия тоже нет, пошёл значительный разнобой. Кто-то только за Ansible из командной строки (AWX кривой), кто-то за AWX (тут есть то, чего нет в обычном Ansible), кто-то за связку Ansible/NAPALM и конечно же люди за Nornir. Сейчас вышла Annet от Яндекс (тоже про разлив конфига), поди в этом во всём разберись..

Скрипт и сетевой инженер

Продолжаем: А если не хочется учить никакой Python(ессно), разбираться в структуре YAML/XML? И хочется при этом исключить из своей жизни всякий самопись? Как уйти от сложности скриптов и программирования? Ведь давайте честно, скрипты/программирование и связанные вещи, не задача сетевого инженера. Разраба, программера, нетопса — да (смешное такое название эти ооопс, как будто у тебя из кармана уже что-то спи.. пропало), сетевого инженера — нет.

Сетевой инженер не пишет программные инструменты, он ими пользуется.

NetBox, Zabbix, Grafana. Мы же не пишем их, правильно? Берём готовое, пользуемся функционалом. А чем отличается сфера автоматизация сети? Ничем. Почему она должна быть самописная? Не должна. Хотелось бы работать с уже готовым инструментом. Не просто инструментом и не просто разливать конфиги, а с коробочным решением, комбайном автоматизации, закрывающим как можно больший спектр вопросов по автоматизации сети.

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

Сложности создания комбайна автоматизации сети

Прежде чем реализовывать комбайн, нужно понять какие задачи возникают в нашей сети. И тут всплывает намеренно пропущенный мной ранее вопрос:

• Автоматизация сети привязана к вендору, моделям оборудования и специфике организации или же нет?

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

Задача такая.., ого-го! И разработчикам софта по автоматизации придётся это сделать. В том или ином виде. И они делают уже сейчас. Пример, Hadal Project предлагает формализацию в виде Цифровой Двойник Сети (Network Digital Twin). Далее, Яндекс, не знаю выкатят ли они прям коммерческий комбайн (хотелось бы), но у себя в дебрях разработки пользуют аналогичный подход (другими словами ту же формализацию сети), названный ими Сеть как Код.

Провайдер/Энтерпрайз/ДЦ

Здесь возвращаемся к автоматизации сети провайдера, энтерпрайза и дата-центра. Поскольку сильно отличается схема прохождения трафика, сетевые задачи/оборудование, значит отличается и формализованная модель сети. Сыграет ли это роль в создании комбайнов автоматизации сети или нет? Не могу сказать. Может да, может нет. Волне возможно появление универсального решения, закрывающее потребности всех. Возможно так.

Возможно автоматизация пойдёт совершенно разными путями. Так в дата-центре без варианта фабрика, 2-3 локации, число коммутаторов десятки на локацию, они однотипные, с продвинутым функционалом относительно энтерпрайза, практически линукс-машины. В такой ситуации набирает обороты концепт CI/CD. Что не подходит для энтерпрайза с сотнями разных (!) локаций, с тысячами разношёрстных коммутаторов, где циска 2950 зачастую не самый плохой уровень. В дата-центре комбайны могут и не прижиться либо же они будут со своей cпецификой.

Тут не смогу, к сожалению, заглянуть за горизонт событий. Не знаю.

---

Существующие комбайны

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

Специализированный (под мониторинг) комбайн автоматизации Zabbix. Видел люди делают классные интерактивные карты сети с помощью Zabbix. Опять же, не знаю за все возможности. Ещё сюда же, SolarWinds, NetXMS (маленький комбайнчик для отрисовки карт), LibreNMS. Также специализированный (под ИБ) коммерческий EFROS Defens Operations.

Упомянутый выше Hadal Project. Уже умеет многое (может как-нибудь расскажу), будет уметь ещё больше. Думаю, совсем скоро комбайны автоматизации сети посыпятся как из рога изобилия (мой прогноз). Делают/пишут/пытаются прям многие (ниша вкусная, перспективно-денежная, не занятая). Возможно есть уже ещё, возможно есть уже много, допустим у индусов и уже прям с ИИ (пофантазирую). Не видел, не щупал. Пою то, что знаю.

NSO

Cisco Crosswork Network Services Orchestrator (NSO), куда же без циски, она же без мыла.., сами понимаете. Вроде бы они сделали мультивендорное решение, по крайней мере так заявляют:

Multivendor, Supports Cisco infrastructure and over 1000 third-party device types and cloud services through Network Element Drivers

Не щупал работу тулзы, но вроде бы не требует установки агента:

Depending on the type of devices supported, it communicates with the devices using different methods. CLI, SNMP, NETCONF, and RESTCONF..

Сама циска позиционирует NSO как грядущую замену Ansible. Взлетает плохо (смотри картинку про Tolling Trends). Сидел и думал (вы правильно поняли): Вроде бы всё есть, почему не летит (ломят цену, только появилось)? Ответа у меня нету (если знаешь/работал/в теме, напиши). Тем не менее, попытка засчитана. Кстати, можно запросить триальную версию и попробовать NSO бесплатно (если докажешь/поверят, что ты “иностранец”).

Дополняю инсайдерской инфой. Средней руки внедрение NSO стоит миллионы долларов (да-да, не миллион, а миллионы). Понятно, с таким прайсом оно взлететь не может. Теперь ясно.

NOC Project

Отечественная разработка, открытая, бесплатная. Использует для работы с устройствами CLI/SNMP. NOC Project точно одна из первых (существует с 2007 года) попыток реализовать более-менее комплексный подход к автоматизации сети. И некая формализация тут конечно же присутствует. Есть объекты, например Interface, а чтобы реализовать вариативность есть профиль объекта, Interface Profile.

Подобно NSO не взлетает NOC Project. И даже нигде не упоминается. Если открыть какую-то статью про сетевую автоматизацию, там не будет ничего о NOC. Прямо наверное феномен. Так или иначе:

NSO (и подобное) грядёт.

Аргументация против комбайнов

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

• Не понимаю, что он мне может помочь решить. Ну вот все в одном и чего?

Много чего. Интерактивная карта сети, всегда актуальная, всегда с реальным состоянием устройств на момент. В зависимости от толщины линка на карте, сразу понятно это 100Mbit, или 1Gbit, или 10Gbit. Достаточно просто взглянуть. Далее, из одной точки управления:

• Накатывание изменений на любое количество однотипных устройств (одного производителя, одной линейки) с выводом результата разумеется;
• Исчерпывающая информация по любому устройству здесь же, включая статистику пинга за любой период и преднастроенных метрик (красивенько, во встроенной Grafana);
• Ведение учета устройств, с произвольным редактированием параметров для любой группы устройств;
• Все версии конфига всех устройств с раскраской синтаксиса и дифами любых двух версий для устройства;
• Список текущих проблем на устройствах;
• Достаточное количество всяких отчётов.

Это всё перечислял возможности бесплатного NOC Project в 2025 году. Последующие коммерческие проекты предложат очевидно больше. И будут предлагать больше и больше от версии к версии. Ясно как пень день.

А теперь, использующие Ansible/AWX, скажите: Ваши могучие скрипты/плейбуки/модули/плагины могут хоть что-то подобное? Сомневаюсь. Работая в таком комбайне, чувствуешь себя весьма комфортно, “пауком в паутине”.

• Решений типа я тут щас вам подниму контейнер в докере и вжух всё само, мне кажется мы ещё долго не увидим.

Ну как не увидим? Вот одно по крайней мере работающее есть, иные в разработке. Дальше только больше.

• То есть, тебе бы кто-то всё внедрил, показал на какие кнопки три кнопки жать, а ты потом эксплуатировал настроенную сеть за много денег?

Понятно, что конкретно я ленивый, глупый и люблю деньги. Ваще даже не спорю. 🙂 Стараюсь сразу после приёма на работу сеть отладить, чтобы потом сидеть и особо ничего не делать. И да, за это много платят (представляете?). Вопрос не в том.

Нажать “три кнопки” и быстро получить результат и есть смысл/цель автоматизации сети.

Да, так точно! Не сидеть по ночам кропать из кусков скрипты, ставить их на запуск, а утром получать люлей за то, что половина сети не работает. В этом сидении нет никакого геройства. И трудоголизм не оплачивается. Дисциплина (на мой взгляд) тратить время на семью, свои увлечения, строго в 18.10 закрывая крышку рабочего ноутбука. Но выдавая при этом на работе результат больше, за меньшее время. Иначе тема автоматизации не была бы мне так интереса. Тут два в одном: Интерес фана сетей и шкурный интерес “работника Балды”. Поистине гремучая смесь: А ещё больше, а ещё за меньшее время?

Something as Code

Шутки в сторону, серьёзнейшая проблема подхода Infrastructure, Configuration, Nework.. as Code в том, что при ошибке или неточности в коде, может наступить катастрофа. Как последствие от применение такого кода на продуктовой структуре. Проблема известна очень давно, умозрительный пример рассказан здесь:

Это одно из слабых мест подхода Configuration-as-Code. В руках человека оказывается очень мощный инструмент, при неправильном использовании которого возможны самые печальные последствия.

Необязательно прям тяжёлый импакт, но риски такового есть. По незнанию, невнимательности, неверным исходным данным. Код всё время разный, практически каждый раз есть отличия. Пишут его, скажем “программисты от сетей”. Ну и обычно нет регламента, что любое изменение кода (даже самое мелкое) должно быть обкатано в виртуальной среде. И даже обкатка в виртуальной среде не 100% гарантия. Так как виртуальная среда не является точной копией продуктовой. В результате, после применения кода в продуктовой среде возникают вещи, которых не было в виртуальной. Всё это только увеличивает вероятность наступления нештатной ситуации. Что делать?

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

Верификация работы скрипта (с автооткатом в случае сбоя) обязательна.

Прогноз за комбайны

Ну и возьмём в целом: Ребята, вы считаете, что через условные 10 лет будут какие-то кривые самописные на коленке скрипты в ходу? Действительно так считаете? На серьёзе? Что это путь автоматизации сети? Сомневаюсь опять. Моя ставка, ещё раз усилю, за готовые коммерческие комбайны для автоматизации. Цискин NSO тут headshot как раз. Бизнес уже сейчас требует такие и с радостью будет покупать. Точно знаю, поскольку уже участвовал в пилотах подобного софта. Денюжка уже приготовлена бизнесом, необходимость есть. А пользующие Ansible, думаю, станут дино из прошлого века, как сейчас использующие Perl.

Требования для внедрения автоматизации

Абсолютно никаких требований. Автоматизация даст результат на любой сети. Но чем лучше сеть, чем она больше подбита и собрана, тем лучше будет результат от автоматизации. Если сеть развальня и даже если вообще неизвестная сеть, результат будет. Очень хороший результат. Лучше покажу на примере (где пруфы?!!).

Что считать автоматизированной сетью

Полностью автоматизированных сетей скорее всего попросту не существует. Или же где-то в “тайном забугорье”/”закромах родины” (которых никто ессно не видел своими глазами, но все верят, любят и ждут). Постарался выше подробно проанализировать почему так:

Нет пока такого класса решений, чтобы могли всю сеть зааффектить автоматизацией.

Если же используются скрипты/Ansible, или комбайн, или есть SD-WAN (SD-Access/ACI), наверное можно назвать сеть частично автоматизированной. Хотя это совершенно разные подходы, они реально существуют/применяются. Отдельно либо же совместно в любом сочетании. Сети без данных подходов считаем неавтоматизированными. Как-то вот так.

Полностью автоматизированная сеть

Крайний наверное вопрос по теме: Что же хотя бы приблизительно можно считать полностью автоматизированной сетью? По моему мнению, это такая сеть, где автоматизировано каждое направление:

• Мониторинг, тут Zabbix с автоотсылкой алертов по категориям в разные группы TG и на почту;
• Инвентаризация, здесь NetBox со сканированием сети, автодобавлением устройств и автоэкспортом в Zabbix с выбором шаблона;
• Интерактивная карта локаций, некая программа, которая умеет в реальном времени отслеживать устройства и стоить карту;
• Безопасность, некая автоматизации для безопасности сети, как минимум она должна уметь анализировать правила FW на избыточность/противоречивость, а также NetFlow.

Получается четыре боковых/вспомогательных ответвления автоматизации сети. Теперь “frontend/backend”:

• В качестве фронта, система для массового накатывания конфы и чтобы умела брать устройства из NetBox;
• Наконец бэк, некая система, закрывающая пробелы между остальными системами, тем самым увязывающая их вместе, склеивающая их воедино. В качестве такой системы (с большой натяжкой) может выступать NOC Project, возможно NSO/Hadal Project (не щупал пока руками).

И завершающий момент здесь:

• SD-WAN, в качестве автоматизации связи между локациями энтрепрайза.

Когда всё это есть/реализовано, да, похоже на полную автоматизацию. Но у кого такое есть? 🙂

Вся эта автоматизация будет гораздо менее эффективна, когда нет вспомогательных программ. Таких например, как Lansweeper. Сюда же нужно добавить грамотную Вики, грамотный Хелпдеск. И сюда же нужно отнести стандартизацию (названий, конфигов и так далее), документирование сети, регламенты на манипуляции с оборудованием/конфигами/программами:

Автоматизация сети максимально засияет только в правильной обвязке.

Погнали скорее к примеру автоматизации сети на комбайне NOC Project!

---

Пример автоматизации

Из реальной жизни, совсем свежий, прям перед НГ было. Компания купила новый бизнес. Для нас абсолютно неважно, что это за бизнес. Там несколько площадок, одна центральная с порядка 130 единиц сетевого оборудования, по имеющемуся от прошлых админов списку. Известно, что всё D-Link (чур меня, чур!), серии DGS в основном, известен диапазон IP адресов для менеджмента (10.112.220.0/24), пароль админа на SSH. Известно также, что SNMP включен (?) на устройствах, но комьюнити не настроено, а LLDP выключен (определено просмотром нескольких устройств). Карты/топологии нет, никакой. Ну.., надеяться на классную/подбитую/отлаженную сеть.., наверное здесь смысла нет.

У меня имеется развёрнутый NOC Project (далее программа) последней версии на момент написания (24.1). Есть сетевая связность до новой локации (диапазона адресов железок).

Онбординг устройств

Делается буквально за минуту и очень просто.

Заранее подготовил в программе отдельный сегмент сети (создаётся из шаблона), по сути добавил новую строку записи для нового сегмента и всё. Сегмент этот нужен для отрисовки карты. Карта отрисовывается отдельно для каждого сегмента. Административный домен, определяющий права доступа к устройствам для пользователей программы, уже был создан ранее. Тоже просто запись. Выполняю через CLI VM:

./noc network-scan  --autoadd --adm-domain=AZ --obj-profile=default --segment=AZ33 10.112.220.0/24

По умолчанию при выполнении поиска для опроса используется дефолтное комьюнити public. Так как не настроено на железках, менять в команде не стал (возможность есть). Поскольку SNMP не отработал, это просто голые записи (возвращаясь к вопросу о подбитости сети). Исторически всегда забивал вручную. Вот первый раз попробовал автодобавление.

Редактирование свойств

Начинаем набивать смыслом созданные записи. Заходим в пункт программы Managed Objects, здесь все (вообще все) записи устройств. Их может быть тысячи. Нужно отфильтровать, фильтруем по названию сегмента AZ33. Остались только найденные железки, теперь их нужно выбрать. Для наглядности выбранные записи помещаются в Корзину (Basket).

После выбора загорается (становится доступным) пункт Group Operation. Там много всего, фича последних версий NOC, раньше было не так. Подчёркиваю, у нас групповое редактирование (Group Edit). Выполняю сразу для всех выбранных записей, а именно добавляю (пишу очень упрощённо, чтобы было более-менее понятно):

• Профиль DLink DxS, он уже есть в программе. По сути набор скриптов, которые разрабы написали для длинка;

Тут возникает некоторая путаница, у самого D-Link есть отдельно линейки DES/DGS/DXS (и ещё десяток). Буду использовать профиль DLink DxS именно для DES/DGS. В программе ещё много других профилей для длинка. Выбираю этот, так как он работает отлично с большинством моих свичей.

• Профиль объекта (obj-profile в команде онбординга), заранее созданный из шаблона профиль, определяющий какие именно скрипты профиля DLink DxS использовать. Как, с какими интервалами;
• Схему входа на устройства SSH;
• Строку SNMP комьюнити (её пока нет на самих устройствах);
• Применяю изменения.

Занимает пару минут.

Выполнение команд

Устройства у меня уже выбраны на прошлом шаге.

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

Где-то получилось 10-15 запусков группового выполнения команд для групп однотипных устройств. Причесал.. Показал результат коллегам, было возражение, что всё тоже самое (выполнение одинаковых команд на группе устройств) можно сделать из SerureCRT. Согласен. А в SerureCRT есть быстрая фильтрация отбираемых устройств по множеству фильтров? А информативный графический вывод? Вот ответ: Пользоваться некоторой функцией всегда удобнее в продукте, который под эту функцию заточен. В NOC Project быстрее, удобнее. Из минусов та же ручная верификация (вот бы сюда привернуть разлив конфигов по шаблону, с проверкой/откатом.., была бы бомба).

После чего запускаю процесс группового опроса (Run discovery now). Опрос длится до 10 минут. По окончании есть вся инфа по устройствам, есть карта.

И тут прикольный момент. Если в профиле объекта отмечен чекбокс Profile (а он отмечен), то при опросе будет сделана попытка автоматически переопределить профиль скриптов (у нас DLink DxS) на более подходящий. Для нескольких железок так и случилось, профиль переопределился (на DLink.DxS_Industrial_CLI). Зачем это рассказываю? Для понимания, Discovery не какая-то мутно-дубовая процедура, сделано даже чуть интеллектуально.

Построение карты

Устройства уже слинкованы, осталось войти в редактирование карты (сегмента) и красиво их растащить. Это можно сделать в автоматическом режиме (кнопка Reset Layout, в виде докторского чемоданчика). Либо же руками.

Итого

Показанное само за себя говорит. За два часа принято в работу 100+ устройств. Локация из полностью неизвестной, стала полностью готовой к обслуживанию. Можем полноценно работать с ней. За эти же два часа получили и топологию, и овер-много инфы, и состояние оборудования с актуальными конфигами. Ещё раз, поскольку важно: Всё это сделано единым инструментом из единой точки управления.

Что ещё не сказал про NOC Project? Он может разворачиваться кластером в несколько нод. И поддерживать в таком варианте более 20 тысяч устройств. Масштабируемость отличная. Никогда сам такого не делал, но планирую.

Куда ушло два часа

Резонный вопрос: Если так быстро и просто, на что потрачены два часа? Нужно присмотреться к картинке карты выше. Там есть устройства, показанные жёлтым цветом. Это устройства с ошибками опроса. Вот на них и ушло. В результате большая часть из них стали зелеными (без ошибок). А есть ещё зелёные, но без линков. Тоже потребовало внимания. Порядка 10 устройств пришлось настраивать вручную (а как же). И там были в том числе не длинки, и в том числе не коммутаторы. По результатам всё успешно настроилось и заведено в программу как положено.

Ещё есть сомнения в необходимости/пользе комбайна автоматизации сети для сетевого инженера в частности/сетевого администрирования в целом? Метод “трёх кнопок” рулит.

---

Заключение

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

Честно говоря, недоволен как эта статья получилась. Потому как местами слишком размыл основную мысль, недостаточно подробно и чётко выразил. Стопудово наврал по тексту или был неточен. В последствии дополню/исправлю. Но так-то статья нужная и насущная:

Сейчас и далее — время автоматизации сети.

Приглашаю поделиться мнением в Tелеграм канал