Как мы автоматизируем регрессию сети: каждая сборка и один diff

В release notes новой прошивки написано «исправления ошибок и улучшения производительности». Вторую половину фразы никто не измеряет. Ручная регрессия занимает у инженера 2–3 дня на релиз, и каждый дедлайн вычеркивает из нее пару пунктов, первыми самые долгие: сходимость с полной таблицей, прогон по размерам кадров, чек-лист на 40 пунктов. Мы превращаем этот список в регрессионный набор, который перезапускается на каждой смене прошивки, конфигурации или релиза и сравнивает результат с последней сборкой, которую вы утвердили.

Стенд

На подписке CloudLAB устройство остается на стенде между сессиями. Автоматическая коммутация подключает его к генераторам стенда или к нашему собственному генератору трафика, так что прогону не нужны ни заявка, ни инженер рядом. Устройство настраивается через API; если API нет, скрипт работает с консолью или веб-интерфейсом, медленнее и с риском сломаться при смене интерфейса.

Каждый тест-кейс живет кодом в вашем репозитории: топология, конфигурация устройства, профиль трафика, ступени нагрузки, длительность, критерий pass. Ваш CI-джоб вызывает набор через API или CLI с номером сборки и получает вердикт рядом с юнит-тестами; ночное расписание использует ту же точку входа. Почему платформы безопасности нужно перепроверять после каждого обновления, мы разбирали в отдельном посте. Здесь речь о механике.

Что проверяем

• Исходное состояние: версия прошивки, которую сообщает устройство, конфигурация, примененная скриптом, счетчики до первого кейса и после последнего
• Throughput и latency на портах от 1G до 100G с вашими размерами кадров и профилем трафика, против baseline
• Latency p99 на каждой ступени нагрузки: более медленный путь в коде часто виден здесь раньше, чем сдвигается максимальная скорость
• Сходимость и failover с полной таблицей маршрутов или сессий: потеря линка, потеря соседа, переключение HA, разрыв по каждому потоку в миллисекундах
• Функциональный чек-лист, от 40 до 150 пунктов с захватом трафика на каждый; известные проблемы помечены как known
• Производительность безопасности с включенной инспекцией: throughput, соединения в секунду, одновременные сессии
• Дрейф: каждый KPI за последние сборки рядом

У каждого KPI есть допуск, согласованный с вашей командой до первого автоматического прогона: несколько процентов для throughput, фиксированный лимит в миллисекундах для сходимости, ноль для функционального пункта. Baseline – первый полный прогон на сборке, которой вы доверяете. Он хранится вместе с конфигурацией, профилем трафика и схемой стенда, чтобы следующие прогоны сравнивались с тем же самым.

Что обычно ломается

Тихая регрессия. Пример ночного прогона на сборке ядрового маршрутизатора: 37 из 38 пунктов чек-листа проходят, сходимость в пределах лимита, throughput на кадрах 1518 байт на 6 % ниже предыдущей сборки, latency p99 при нагрузке 70 % выросла на 18 %. В release notes нет ни того, ни другого. Прогон идет 2 ч 40 мин без людей, красный результат лежит в пайплайне в 06:10. Руками чек-лист на 40 пунктов для прошивки ядрового маршрутизатора занимает 2 дня.

Дрейф. KPI, который теряет 1 % за релиз, проходит каждую отдельную проверку и через год оказывается на 6 % ниже. Каждое сравнение с предыдущей сборкой зеленое, сравнение с утвержденным baseline нет. В отчете есть оба.

Набор, который кричит «волки». В первые недели красный прогон часто вина самого набора: веб-форма, в которой переехало поле, baseline, снятый с другим профилем трафика, нулевой допуск на KPI, который плавает на 2 % между прогонами. Каждый такой случай исправляется в наборе и записывается, чтобы дальше красная полоса указывала на устройство.

Что в отчете

Одна страница, которую ваша команда читает за 5 минут: что изменилось с последней утвержденной сборки, pass, fail или known по каждому пункту, diff KPI к предыдущей сборке и к baseline, тренд. За ней: статистика генератора, счетчики устройства до и после, захват трафика каждого проваленного пункта, лог консоли. Скрипты, конфигурации, пороги и история прогонов уходят в ваш репозиторий с документацией, так что набор запускается и в вашей лаборатории. Первый набор занимает от 3 недель, начиная с ручного прогона, который дает тест-план и baseline.

С чего начать

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