В мире ИТ закупки часто напоминают азартную игру. ИТ руководители балансируют между бюджетными ограничениями и риском, что новая инфраструктура «ляжет» под реальной нагрузкой. Ключ к решению – переход от интуитивных допущений к доказательной базе на основе реалистичного тестирования.
Налог на неопределенность
Производители при тестировании устройств сочетают синтетический трафик и AppMix c воспроизведением процентного соотношения различных типов приложений. Однако, здесь возникают нюансы:
Уникальность профилей: каждое предприятие, сегмент сети имеет уникальный профиль трафика.
Статичность во времени: профиль фиксируется на момент тестирования, но в реальной сети соотношение приложений постоянно меняется.
Сложность L7-симуляции: современные подходы требуют полноценной симуляции L7-потоков трафика веб-сервисов, протоколов и приложений, а не просто множественных TCP/UDP-сессий.
Шифрование как критический фактор: доля TLS/HTTPS-трафика зачастую приближается к 100%. Симуляция такого трафика требует значительных вычислительных мощностей, поэтому часть вендоров для красивых цифр упрощают симуляцию или используют проигрывание ранее записанного трафика (PCAP), что непригодно для тестирования современных устройств с DPI и SSL MITM.
Тендерные ловушки: в погоне за победой вендоры часто предлагают минимально подходящую под требования модель. С учетом маркетинговых цифр в документации заказчик получает оборудование, работающее на пределе возможностей уже в день установки.
Опытные инженеры, учитывая вышеизложенное, еще закладывают емкость на несколько лет вперед. В итоге коэффициент запаса составляет от 2 до 5 раз с учетом роста. Это и есть «налог на неопределенность» – переплата при отсутствии точных данных.
Стратегия оптимальной конфигурации
Эта стратегия базируется на нагрузочном тестировании с профилями трафика (AppMix), приближенными к реальности конкретного предприятия. Вместо того, чтобы покупать «вслепую» модель в 3 раза мощнее, методология предлагает:
Определить точку насыщения (предел производительности при сохранении качества обслуживания)
Учесть деградацию мощности при включении новых фич (новые сигнатуры DPI часто «съедают» ресурсы той же железной платформы)
Сопоставить данные с прогнозом роста трафика из систем мониторинга
Закупить оптимальное решение
Планово запрашивать бюджет на развитие без авралов
Экономический эффект
Выбор неподходящей модели в масштабах предприятия – это десятки миллионов рублей потерь. Разница в цене между соседними моделями в линейке может достигать 300-350%. Если тестирование докажет, что младшая модель справится с конкретным профилем трафика даже с учетом роста, экономия на одной закупке составит ощутимую сумму.
Например, одно тестирование, проведенное независимыми тестировщиками, выявило следующую картину производительности межсетевых экранов при обработке реальных рабочих нагрузок:
TCP базовые тесты: все устройства показали примерно одинаковые результаты, соответствующие рекламным материалам производителей
Web-приложения, VDI, базы данных, зашифрованный трафик: производительность устройств отличается на 30-50% в худшую сторону от цифр, указанных в маркетинговых брошюрах
Такое тестирование заняло всего три дня, но предоставило заказчику количественные данные, необходимые для обоснованного выбора решения.
Реализм против синтетики
Чтобы стратегия сработала, недостаточно запустить iPerf, Speedtest и даже Trex. Методология требует создания реалистичных условий:
Динамическая симуляция L7
Синтетика не нагружает процессоры глубокой инспекцией пакетов. Нужно эмулировать живой трафик (ERP, видеосвязь, базы данных), причем не через проигрывание записанных PCAP-файлов (которые неэффективны для тестов SSL MITM), а через генерацию уникальных сессий «на лету» (кстати, из всех решений на рынке только IXIA умеет это делать).
Иголка в стоге сена
Атаки не происходят в пустой сети в 2 часа ночи. Нужно проверять эффективность защиты в моменты пиковой нагрузки. Задача устройства найти и заблокировать одну вредоносную транзакцию среди миллионов легитимных, не допустив ложных срабатываний и не испортив жизнь пользователям.
Учет эксплуатации
Тестирование должно проводиться с включенными модулями аналитики и журналирования, именно в том режиме, в котором устройство будет работать в реальности.
Почему компании избегают тестов (и почему они неправы)
Вот список самых популярных «отмазок»
«Мы верим вендору». Цель вендора верифицировать функции в фиксированном юзкейсе. Ваша сеть уникальна, и никто, кроме вас, не проверит ее совместимость с железом.
«Это дорого». Раньше это было так. Сегодня облачные лаборатории позволяют развернуть стенд удаленно (например, мы это сделали в Москве) и провести тесты за 3 дня, не тратя месяцы на закупки и логистику.
«Это муторно. Мы посмотрим результаты у соседей/интегратора». Опыт другой компании бесполезен из-за разницы в профиле приложений и настройках безопасности. Более того, результаты интеграторов могут быть весьма спорны из-за «дружбы» с конкретным брендом.
«У нас есть пентесты». Пентест проверяет наличие дыр, но не показывает, как сеть поведет себя при атаке под нагрузкой 80%.
Заключение
В условиях, когда циклы разработки сократились, а обновления прошивок выходят каждые 1-2 недели, тестирование становится непрерывным процессом. Вопрос руководства или заинтересованных сторон: «Как вы узнали, что это сработает?» имеет только один приемлемый ответ: «Потому что мы это протестировали».
Переход к модели «покупка на основе данных» позволяет компаниям:
Оптимизировать бюджет: сэкономить от 20% до 50% за счет отказа от ненужной избыточности
Усилить позицию в переговорах: получить дополнительные скидки от вендора, имея на руках доказательства реальной производительности
Защитить репутацию: гарантировать устойчивость бизнеса в моменты критических нагрузок
Ускорить Time-to-Market: быстрее внедрять новые сервисы, зная точные пределы своей инфраструктуры
Использование современных инструментов вроде Облачной лаборатории РУТЕСТ превращает ИТ из «черной дыры» для бюджета в прозрачный и предсказуемый процесс.