Привет, Хабр! На связи Евгений Ращупкин, APO UserGate, и Дмитрий Ларин, CPO Hadal Project. Это текстовая версия нашего совместного доклада «Цифровой двойник, или Как контролировать изменения в сложной сетевой инфраструктуре», который мы представили на Saint HighLoad++. Мы расскажем, как связать физическую лабораторию, эмуляцию и симуляцию в единый процесс, чтобы проверять изменения до прода и контролировать их результат в реальной сети.
После одного минорного обновления ПО в компании нарушилась работа IPsec-туннелей до всех филиалов. На бумаге обновление выглядело безопасным. Вендор проверил релиз, инженер выполнил стандартную процедуру, мониторинг после выкладки показывал привычную картину. Связность при этом исчезла — и начался ночной разбор полетов.
Для сетевого инженера в такой ситуации есть отдельный жанр прогноза: «обновил в проде, вроде работает». Иногда к нему добавляются карты Таро. Карты обещают, что сеть будет работать, однако бизнесу нужны более надежные основания.
Цена ошибки при внесении изменений уже давно намного выше, чем просто доставление неудобств отдельному инженеру. Из-за сетевого изменения может остановиться филиальная сеть, платежный контур или медицинский сервис. Поэтому привычное правило «работает, не трогай» перестает действовать. Поток изменений растет, и каждому из них нужен понятный жизненный цикл.
Почему сеть никогда не бывает готова
Сеть представляет собой живую сложную систему. Она постоянно развивается, обрастает новыми узлами и хранит следы решений, которые принимались много лет назад. Мы видим три источника сложности.
Первый источник — мультивендорность. В одной инфраструктуре соседствуют разные производители, поколения оборудования, операционные системы, версии прошивок и подходы к настройке. Особенно много сюрпризов возникает на стыках. Каждый компонент может успешно пройти проверку в своей лаборатории, а их сочетание в конкретной сети — дать новый сценарий отказа.
Второй источник — историческое наследие. Большая сеть редко строится с чистого листа. Команды продолжают развивать то, что получили от предшественников, латают отдельные участки и добавляют новые технологии. История решений документируется неравномерно. В результате схема в Confluence и фактическая топология постепенно расходятся.
Третий источник — динамичность. Релизы ПО, патчи информационной безопасности, новые узлы, миграции и изменения конфигурации идут непрерывным потоком. Сеть вчера и сеть сегодня часто отличаются. Перед изменением важно понять текущее состояние, иначе тестовый стенд воспроизведет устаревшую картину.
Ручной процесс обычно охватывает только часть этого потока. Инженер собирает небольшой стенд из ЗИП, настраивает его, устанавливает обновление и выполняет несколько проверок. На это уходит время, и в итоге результат с неоправданно высокой долей доверия распространяется на прод.
При изменениях конфигурации проверок до прода часто еще меньше. После выкладки остается мониторинг, который видит уже известные показатели и события. Он редко отвечает на вопросы о достижимости между какими-либо двумя точками, дрейфе политик безопасности и точной разнице состояний сети.
Вся проблема сводится к двум потребностям:
проверять ПО и конфигурацию до внесения изменений в прод;
проверять результат после внесения изменений и поддерживать контроль во времени.
Для этих задач нужен набор взаимосвязанных инструментов.
Три класса задач и как выбрать для них инструменты
Под словом «тестирование» часто скрываются разные процессы. Мы разделяем их на три класса:
· Тестирование ПО. Сюда входят новые релизы и прошивки, функциональные и нагрузочные тесты, проверка технологического стека и производительности оборудования. Все это выполняется до прода.
· Тестирование изменений. Здесь проверяется конкретная конфигурация или сценарий. Например, что произойдет после изменения строки в политике маршрутизации, сохранится ли IPsec-связность, пройдет ли трафик критически важного сервиса.
· Контроль изменений. Эта задача начинается после выкладки. Нужно проверить фактическое состояние сети, обнаружить дрейф, нарушения требований ИТ и ИБ, новые пути прохождения трафика и основания для отката.
Для выбора инструмента мы смотрим на три параметра: точность, масштаб и трудозатраты. Точность показывает близость модели к реальному оборудованию. Масштаб определяет количество узлов, которое можно охватить за один раз. Трудозатраты отражают объем ручной работы при подготовке окружения и сценариев.
Универсального инструмента нет. Широкий охват уменьшает количество деталей на отдельный узел. Максимальная точность требует оборудования и времени. Поэтому три подхода должны работать на разных участках одного процесса.
Физическая лаборатория: максимальная достоверность
Физическая лаборатория нужна для глубокой валидации конкретного устройства или релиза. В ее основе лежит реальное оборудование, часто собранное из ЗИП. Такой стенд позволяет увидеть точное поведение на уровнях от L1 до L7, подключить генераторы трафика и провести финальную приемку критически важного узла.
Этот подход особенно полезен при выборе оборудования. Можно проверить поддержку нужного технологического стека, пропускную способность, порты и поведение под нагрузкой. Если важна работа ASIC или специфического аппаратного механизма, реальное устройство дает самую достоверную картину.
Масштаб лаборатории ограничен единичными узлами или небольшим сегментом. Сборка, настройка и проверка выполняются вручную. Смена сценария часто требует перенастройки стенда. Когда количество релизов и тест-кейсов растет, лаборатория становится узким местом. Поэтому мы используем ее как точный инструмент для критически важных элементов и сохраняем оборудование в составе более широкого тестового контура.
Эмуляция: безопасная среда для ответа на вопрос «что будет, если»
Эмулятор запускает виртуальные машины или контейнеры с образами операционных систем сетевых узлов. Из них собирается цифровая копия конкретного сегмента. В UserGate мы развиваем для этой задачи uInfraTwin.
Эмуляция хорошо подходит для пошаговых изменений конфигурации и пользовательских сценариев. В лабораторию можно подключить виртуальные и физические генераторы трафика, включая TRex, IXIA и Xinertel, а также добавить реальные устройства из ЗИП. Получается гибридная среда, в которой проверяются функции, нагрузка и взаимодействие компонентов.
На практике сценарий выглядит так:
Берем актуальные конфигурации нужного сегмента.
Поднимаем виртуальные узлы с теми же образами ПО.
Воспроизводим пользовательский или аварийный сценарий.
Вносим изменение пошагово.
Прогоняем функциональные и нагрузочные тесты.
Сохраняем результат как повторяемый тест-кейс.
Сборка и модификация сегмента занимают минуты. Один и тот же стенд можно запускать многократно, включать в автоматический пайплайн и передавать вендору вместе с конфигурацией, которая воспроизводит ошибку.
У эмуляции есть границы. Для каждого производителя нужны доступные образы виртуальных узлов. Эти узлы потребляют заметный объем ресурсов. Например, один виртуальный экземпляр IOS XR может требовать около 8 ГБ оперативной памяти. Аппаратные особенности части L2-сценариев моделируются с ограничениями. Кроме того, эмулятор обычно охватывает сегмент, а размер большой корпоративной сети может измеряться десятками тысяч устройств.
Эмуляция отвечает за безопасный эксперимент до выкладки. Для наблюдения за всей сетью нужен больший масштаб.
Симуляция: модель фактического состояния сети
Симулятор собирает конфигурации, топологию и состояние устройств, затем строит математическую модель поведения сети. Реальное ПО каждого узла для этого не запускается. Такой подход позволяет регулярно обновлять модель и охватывать десятки тысяч сетевых элементов при умеренных вычислительных затратах.
Есть два основных класса симуляторов:
· Симуляторы control plane строят модель по конфигурациям. Они позволяют оценить влияние планируемой конфигурации до ее применения. К этому классу относятся Batfish, Cisco WAE и Juniper WANDL.
· Симуляторы data plane используют фактическое состояние устройств, включая таблицы RIB и FIB. Они отвечают на вопросы о текущих путях трафика и результате уже выполненного изменения. В эту группу входят Hadal, Forward Networks и IP Fabric.
Принцип работы симулятора аналогичен навигационной карте. Мы задаем точки A и B, после чего модель показывает возможные маршруты прохождения трафика и причины, которые мешают достижимости. Расчет выполняется без отправки тестового трафика по рабочей сети. Так можно контролировать маршруты end-to-end, stateful firewall, NAT, policy based routing, балансировку и сегментацию. Модель также хранит состояние во времени и помогает увидеть, какие устройства и параметры изменились перед инцидентом.
Симуляция опирается на ограниченный набор реализованных технологий. Баг новой прошивки внутри конкретного устройства лучше искать в физической лаборатории или эмуляторе. Математическая модель решает задачи сетевого масштаба: достижимость, дрейф, соответствие политикам и поиск отклонений.
Синтез инструментов: закрытие жизненного цикла
Физическая лаборатория отвечает на вопрос «работает ли железо». Эмуляция помогает проверить «что будет, если» до прода. Симуляция показывает фактическое состояние сети, пути трафика и историю изменений.
В нашей трактовке цифровой двойник представляет собой связанный контур. Одна его часть регулярно получает данные из реальной инфраструктуры и строит модель всей сети. Вторая часть поднимает выбранный сегмент в безопасной среде с образами ПО и генераторами трафика. Физические устройства добавляются там, где требуется аппаратная точность.
Такой контур подразумевает три стадии работы: археологию сети, тесты до прода и контроль в проде.
Стадия 1. Проводим археологию сети
Иногда нас спрашивают, почему мы говорим «археология», хотя существует слово «архитектура». Архитектура описывает замысел. Археология показывает фактическое устройство инфраструктуры, включая все слои, которые появились за годы эксплуатации. Иногда в компании все хорошо документировано. Но на практике чаще приходится брать лопату и выяснять, что находится в сети.
Археология включает:
инвентаризацию всех активов;
актуальную карту подключений;
связь сетевых узлов с критически важными бизнес-сервисами;
загрузку оборудования;
технологический стек на каждом участке;
конфигурации, маршруты и фактическое состояние устройств.
Эти данные следует обновлять автоматически. Карта, которую инженер рисует раз в полгода, быстро превращается в исторический документ. Цифровой двойник должен несколько раз в день получать актуальные данные о состоянии инфраструктуры или работать с другой частотой, подходящей для конкретной сети.
Археология становится фундаментом тестов. Она помогает выбрать критически важные сегменты, собрать реальные конфигурации, описать ожидаемую достижимость и понять, какие сценарии имеют бизнес-приоритет.
Стадия 2. Тестируем каждый релиз и изменение до прода
На этом этапе физическая лаборатория, ЗИП и эмуляция объединяются в stage. Здесь проверяются кандидаты на закупку, новые прошивки, изменения конфигурации, пользовательские сценарии и нагрузка.
Набор тестов должен отражать реальную инфраструктуру. Для филиальной сети это могут быть IPsec-туннели, динамическая маршрутизация, доступ к центральным сервисам, резервирование каналов и политики межсетевого экрана. Для дата-центра набор будет другим. Универсального списка, опять же, нет: он не сможет учесть именно ту особенность, которая образовалась в вашей сети за годы.
Каждый найденный инцидент превращается в регрессионный сценарий. После сбоя IPsec-туннелей проверка их связности должна войти в постоянный набор. Следующий релиз пройдет тот же путь автоматически.
Так появляется единое хранилище тест-кейсов. Инженеру больше не требуется каждый раз вспоминать историю отказов и собирать стенд с нуля. Команда развивает тестовую базу вместе с инфраструктурой.
Стадия 3. Контролируем прод после выкладки
Успешный stage дает основание для изменения. После выкладки цифровой двойник сравнивает ожидаемое и фактическое состояния.
Для бесшовной миграции мы проверяем сохранение нужных сессий, маршрутов и доступности критически важных сервисов. Если изменение должно создать новый путь, он также входит в спецификацию. Параллельно контролируются требования ИТ и ИБ, отсутствие неожиданных связей между сегментами и конфигурационный дрейф.
Важная задача симуляции состоит в ранней проверке сегментации. Допустим, две группы устройств относятся к изолированным зонам и никогда не должны обмениваться трафиком. Документация содержит нужную политику. Фактическая сеть тем временем меняется. Симулятор по конфигурациям и состоянию устройств вычисляет достижимость между зонами. Нарушение можно обнаружить до появления реального потока в запрещенном направлении.
Такой контроль дополняет мониторинг. Прикладная команда получает ответ на вопрос, находится ли причина в сервисе или в транспортной инфраструктуре. Сетевые инженеры могут показать конкретный путь, изменение состояния и точку нарушения.
Петля обратной связи
Самая полезная часть подхода проявляется, когда симуляция и эмуляция обмениваются данными:
Симулятор обнаруживает аномалию в проде.
История состояний показывает, что и когда менялось.
Команда выбирает проблемный сегмент.
Актуальные устройства, конфигурации и связи переносятся в эмулятор.
В лаборатории воспроизводится ситуация и проверяется исправление.
После ревалидации исправление попадает в прод.
Симулятор снова контролирует состояние всей сети.
Техническая интеграция Hadal и uInfraTwin строится вокруг этого перехода. Hadal собирает карту сети и данные о состоянии оборудования. Пользователь выбирает нужный участок, после чего связанные устройства и конфигурации передаются в uInfraTwin. Там поднимается лаборатория с тем же сегментом. Команда работает с ним безопасно и сохраняет сценарий для повторных запусков.
Этот процесс можно поддерживать силами собственной команды. Также возможна сервисная модель, при которой поставщик помогает настроить инструменты и тестовые сценарии. Организационная схема зависит от компетенций и масштаба компании. Важнее закрепить владельцев процесса, правила обновления тестов и критерии допуска в прод.
Как выглядит связка stage и prod
В одном из проектов для финансового сектора мы построили две среды, объединенные в единый контур.
В stage вошли физические устройства из ЗИП, эмуляция и генераторы трафика. Команда подготовила сценарии для разных филиалов, архитектур и технологических стеков. Каждое изменение проходило функциональные и нагрузочные проверки.
Prod находился под регулярным контролем симулятора. Система проверяла достижимость, политики безопасности и фактическое состояние сети. Обнаруженное отклонение становилось основанием для отката и возвращалось в stage как новый сценарий.
Получается двунаправленный поток. Проверенные изменения идут из stage в prod. Инциденты, дрейф и новые особенности идут из prod обратно в тестовый набор. Чем дольше работает контур, тем точнее он отражает историю конкретной сети.
Лестница зрелости: поднимаемся постепенно
Полноценный контур требует времени, данных и новых привычек команды. Поэтому для его построения мы используем лестницу из пяти уровней.
Уровень 0 — реакция. Сеть живет по принципу «работает, не трогай». Команда тушит пожары и выполняет ситуативные проверки.
Уровень 1 — физическая лаборатория. Критически важные обновления проверяются на реальном оборудовании до прода. Обычно этот уровень появляется после инцидента.
Уровень 2 — эмуляция. Количество сценариев растет, релизы проходят повторяемые автотесты, лабораторные сегменты собираются быстрее.
Уровень 3 — контроль прода. Симуляция дает видимость всей сети, выявляет нарушения и показывает результат изменений.
Уровень 4 — непрерывный контроль изменений. Планируемые изменения моделируются до применения, каждое изменение проходит stage, а обратная связь из prod пополняет тесты.
Археология — фундамент лестницы: нельзя тестировать неизвестные устройства и связи. Переход на следующий уровень имеет смысл после выстраивания устойчивого процесса на предыдущем.
С чего начать
Для старта достаточно двух шагов.
Первый шаг — это аудит. Обнаружьте устройства, соберите конфигурации, постройте актуальную карту связей и выделите узлы, от которых зависят критически важные сервисы. Выберите один сегмент с понятной бизнес-ценностью.
Второй шаг — это повторяемый тест. Возьмите критически важное обновление или пользовательский сценарий, поднимите сегмент в лаборатории, подключите генератор трафика и опишите ожидаемый результат. Сохраните проверку, чтобы следующий релиз прошел тот же путь.
Дальше можно добавить автоматический сбор состояния, контроль достижимости и петлю возврата инцидентов в stage. Каждая ступень должна снижать конкретный риск и давать измеримый результат: меньше ручной сборки, больше повторяемых тестов, более быстрый поиск причины и более понятное решение об откате.
Ценность цифрового двойника складывается из четырех вещей: 1) большой базы автотестов, 2) связи с реальной инфраструктурой, 3) уверенности при обновлениях, 4) воспроизводимых доказательств для вендора. Главные цели — стабильность продовой среды и контролируемый поток изменений.
Сеть продолжит меняться. Задача команды — сделать так, чтобы каждое изменение проходило известный маршрут: актуальные данные, безопасная проверка, управляемая выкладка и непрерывный контроль. Тогда пятничный релиз останется обычной инженерной процедурой, и карты Таро наконец можно будет вернуть владельцу.
Если у вас уже есть такой контур, расскажите в комментариях, как вы проверяете сетевые изменения до продакшена и какие данные возвращаете из прода в тестовый набор. Особенно интересны случаи, когда эмуляция или симуляция помогли заранее обнаружить риск или быстрее разобраться с инцидентом.
