Аннушка (Annet): как автоматизировать сеть и не поскользнуться на разлитом масле
Огромные сети, зоопарк вендоров и вечный человеческий фактор — это реальность, в которой живут современные сетевые инженеры. Когда конфигураций становится слишком много, а цена ошибки возрастает до масштабов падения целых дата-центров, ручной ввод команд в консоль превращается в опасную лотерею.
Аннушка (или Annet в open source)
это система, рожденная внутри Яндекса для решения проблем управления сложной сетевой инфраструктурой. Ее название — прямая отсылка к Булгакова: чья-то маленькая ошибка может изменить судьбу всей вселенной, а в нашем случае — работоспособность огромной сети. Основная задача системы — поддерживать идеальный порядок и гарантировать, что реальное состояние «железа» всегда соответствует тому, что описано в источнике правды.
Почему возникла потребность в новом инструменте
Работа в крупной компании накладывает свои ограничения. Сеть постоянно растет, конфигурации становятся сложнее, а оборудование — разнообразнее.
Мультивендорность как страховка.
Использование оборудования разных производителей — это не прихоть, а способ резервирования. Если в софте одного вендора найдется критический баг, есть шанс, что он не затронет устройства другого производителя.
Скорость обновлений.
Новые устройства появляются регулярно, и процесс их ввода в эксплуатацию должен быть поставлен на поток.
Подход Software Defined Configuration (SDC).
Чтобы управлять сетью эффективно, нужно применять те же практики, что и в разработке ПО: версионность, проверки и автоматическую выкатку.
Главная ставка была сделана на поддержание порядка. Существует система Inventory (источник правды), где описано идеальное состояние сети. Задача автоматизации — сделать так, чтобы реальная конфигурация на железках ни на йоту не отличалась от эталонной.
Киллер-фича: приведение к состоянию, а не просто правка
Большинство инструментов автоматизации умеют просто «докидывать» команды на устройство. Но что делать с тем мусором, который уже там есть? Как откатить изменения, если что-то пошло не так?.
Аннушка умеет приводить устройство к целевому состоянию. Она не просто вносит изменения, она сравнивает то, что есть, с тем, что должно быть, и генерирует патч. Если на устройстве есть лишняя команда, которой нет в Inventory, система сама поймет, как ее удалить или нейтрализовать.
Почему робот эмулирует человека (CLI vs API)
При выборе способа настройки оборудования часто встает вопрос: использовать ли современный NetConf/RestConf или старый добрый интерфейс командной строки (CLI)?
Проблема неполной реализации
Далеко не все вендоры полностью поддерживают API. Часто через NetConf можно сделать только часть настроек, а за остальными все равно придется идти в консоль.
Наследие (Legacy)
В любой большой сети есть старое оборудование, которое вообще не знает, что такое API. Игнорировать его нельзя, настраивать нужно.
Человекочитаемость
Сетевые инженеры привыкли к командам. Намного проще просмотреть список команд, которые робот собирается отправить на устройство, чем изучать огромный JSON-файл.
Именно поэтому Аннушка — робот, который эмулирует поведение человека в CLI. Она «общается» с устройством так же, как это делал бы инженер, но делает это быстрее, точнее и без усталости.
Источник правды: зачем нужен Inventory
Автоматизация начинается не со скриптов, а с системы инвентаризации. Если у вас нет единого места, где записаны все IP-адреса, хостнеймы, теги и связи устройств — автоматизировать нечего.
Единая точка истины.
В системе инвентаризации (например, Netbox) должно быть описано всё: какой хостнейм у железки, какие на ней интерфейсы, какие IP-адреса и какие теги ей назначены.
Запрет на обратную связь.
Важное правило: данные должны течь из Inventory на устройство, а не наоборот. Если вы разрешите системе «подсасывать» конфиг с железки и считать его правильным, вы просто автоматизируете хаос.
Декларативность.
Мы описываем не процесс («зайди и введи команду»), а результат («на этом интерфейсе должен быть такой-то VLAN»).
Важный совет: Не заливайте информацию из оборудования в Netbox автоматически. Если «железо» станет источником истины для Inventory, вы потеряете контроль. Источник истины должен диктовать волю оборудованию, а не наоборот.
Дорожная карта: как работает Workflow Аннушки
Весь процесс от идеи до настройки на устройстве можно представить в виде последовательных шагов:
Выгрузка данных из Inventory.
Берем все параметры устройства (интерфейсы, адреса, маршруты).
Построение моделей.
В отличие от жестких протоколов, здесь можно описывать только те части конфигурации, которые нам важны. Лишнее можно просто пропустить.
Генераторы.
Это кусочки Python-кода, которые превращают данные из модели в строчки конфигурации.
Расчет диффа (Diff).
Ядро системы сравнивает текущий конфиг устройства с тем, что выдал генератор. Результат — Unix-подобный вывод с «плюсиками» и «минусиками».
Создание патча.
Система переводит дифф в понятные устройству команды (например, заменяет «минус» на команду no или undo).
Деплой.
Отправка готового набора команд на оборудование через SSH или Telnet.
Генераторы: инструмент в руках инженера
Самое классное в системе то, что генераторы может писать не профессиональный программист, а обычный сетевой инженер. Логика очень простая:
Вы берете реальные команды, которые вводите руками.
Оборачиваете их в простую логику на Python (циклы for, условия if).
Используете оператор yield для выдачи каждой строчки конфига.
Это позволяет быстро переносить знания об устройстве в код. Если вы видите, что дифф после применения генератора стал нулевым — поздравляем, вы создали идеальное описание целевого состояния.
Порядок имеет значение: рулбуки и фильтры
В сетях нельзя просто набросать команды в произвольном порядке. Если вы сначала назначите IP-адрес на интерфейс, который еще не создали, устройство выдаст ошибку.
Аннушка поддерживает декларативное описание порядка (Ordering). Вы сами задаете правила: сначала создаем интерфейсы, потом вешаем адреса, затем настраиваем маршрутизацию. Система сама выстроит цепочку команд так, чтобы они применились без конфликтов.
Также используются ACL (списки контроля), но не сетевые, а внутренние. Они помогают системе понять, к каким именно частям конфигурации относится конкретный генератор. Это позволяет работать с конфигом гранулярно, не затрагивая лишнего.
Безопасность и «право на ошибку»
Автоматика может не только помочь, но и «выстрелить в ногу», если применять ее неосторожно. В Яндексе для минимизации рисков используются проверенные временем подходы:
Изолированная сеть управления.
Изменения в продуктовой сети и сети управления — это разные процессы, которыми часто занимаются разные люди.
Канареечные группы.
Обновления никогда не катятся сразу на всю сеть. Сначала — одно устройство, потом небольшая группа, и только после успешных тестов — все остальное.
Концепция «минус один дата-центр».
Инфраструктура спроектирована так, чтобы выживать даже при потере целого дата-центра. Это дает определенный запас прочности при проведении массовых работ.
Если что-то пошло не так, у инженера всегда есть возможность откатить коммит в Git и перевыкатить исправленную версию. Это гораздо быстрее и надежнее, чем пытаться судорожно исправлять ошибки руками в консоли.
Безопасность и «право на ошибку»
Автоматика может не только помочь, но и «выстрелить в ногу», если применять ее неосторожно. В Яндексе для минимизации рисков используются проверенные временем подходы:
Этап 1: Централизованное хранение конфигураций
Перестаньте настраивать роутеры «на лету».
Используйте Git (GitHub, GitLab, Gitea) для хранения всех конфигурационных файлов.
Каждое изменение должно сопровождаться комментарием (commit message).
Этап 2: Использование шаблонизаторов
Вместо того чтобы копировать один и тот же конфиг, создайте шаблоны (например, на Jinja2).
Вынесите уникальные параметры (IP-адреса, имена хостов) в отдельные переменные.
Этап 3: Подключение инструментов управления конфигурациями
Ansible: Отлично подходит для управления парком устройств. Позволяет применять настройки массово и следить за состоянием системы.
Terraform: Помогает описывать инфраструктуру как набор ресурсов. Особенно полезен, если вы используете облачные решения или виртуализацию (CHR).
Как начать использовать Аннушку (Annet)
Система теперь доступна в open source под названием Annet. Это не просто код, а целая экосистема для сетевой автоматизации.
С чего начать знакомство:
Лабораторные работы.
На GitHub доступен набор Docker-контейнеров. Вы можете развернуть у себя маленькую копию инфраструктуры: свой Netbox, Аннушку и виртуальные сетевые устройства.
Чит-шиты (Cheat sheets).
Существуют подробные инструкции, которые по шагам ведут через процесс создания первой автоматизации.
Сообщество.
Телеграме есть живое комьюнити, где разработчики и инженеры помогают новичкам разобраться с установкой и написанием первых генераторов.
Советы тем, кто застрял в рутине
Если вы чувствуете, что устали настраивать оборудование руками и постоянно исправлять мелкие опечатки, вот несколько рекомендаций:
1
Привлекайте роботов.
Роботы созданы для рутины. Они не устают, не ошибаются в буквах и исполняют ровно то, что написано в программе.
2
Начинайте с малого.
Не нужно пытаться автоматизировать сразу всю сеть. Возьмите один новый объект или одну новую локацию и попробуйте сделать ее «по-новому».
3
Инвентарь — это база.
аже если вы используете Ansible, задумайтесь о переходе на полноценный Inventory (Netbox или Nautobot). В будущем это сэкономит вам сотни часов поддержки.
4
Python — ваш лучший друг.
Это самый простой и популярный язык для сетевой автоматизации. Огромное количество библиотек и готовых примеров сделают старт максимально легким.
Автоматизация — это не страшно. Это способ превратить хаос из текстовых файлов и ручных правок в стройную, предсказуемую и надежную систему. Попробуйте Annet, посмотрите презентации коллег и присоединяйтесь к сообществу. Возможно, именно это станет тем моментом, когда ваша сетевая вселенная перестанет зависеть от случайно разлитого масла.
Финал
Внедрение автоматизации — это не просто попытка упростить жизнь инженеру, а единственный способ сохранить контроль над инфраструктурой, которая растет по экспоненте. Переход к декларативному управлению превращает настройку оборудования из «лотереи» в предсказуемый технологический процесс. Вместо того чтобы тратить часы на поиск опечатки в конфиге или борьбу с последствиями человеческого фактора, команда может сфокусироваться на архитектурных задачах и развитии сервисов, доверив рутину алгоритмам.