🟣 Привет! Продолжаем знакомить вас с нашими коллегами и тестировать форматы.

Сегодня на связи Влад Васильев, руководитель разработки фронтенда на портале продавцов WB. Говорим о карьере Влада и его ценностях в работе.


⭐️ — Влад, расскажи нам про свой карьерный путь

⭐️⭐️ А как вы сейчас балансируете трафик под пиковыми нагрузками?

Алексей Медошин, директор департамента защиты от DDoS-атак, делится реальным опытом перехода от BGP Anycast к L4-балансировке и рассказывает, причем тут L4 DDoS:

➡️ Почему Anycast перестал
справляться с равномерной балансировкой и плавным дрейном серверов;
➡️ Как Katran на XDP + DSR + modified Maglev решил эти проблемы;
➡️ Почему выбрали XDP вместо IPVS (производительность и безопасность);
➡️ 45+ млн PPS в тестовом Syn-Flood на одном сервере;
➡️ Зачем ввели байпас и получили +35% пропускной способности;
➡️ Как балансировщик стал первой линией защиты от L4-DDoS

Полезно инфраструктурным инженерам и SRE, которые упираются в лимиты Anycast или ищут эффективную защиту от флудов.


➡️ Читать на Хабре

🟣 Привет!

На связи Андрей Аксёнов, QA Lead департамента защиты от DDoS-атак Wildberries & Russ. В мини-интервью он расскажет, как в компании проводят нагрузочное тестирование систем, выдерживающих огромный трафик.


❓ Что для вас является объектом нагрузочного тестирования: отдельный сервис, цепочка сервисов, целый пользовательский сценарий?

Объект подбираем под конкретную задачу.

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

Цепочку сервисов нагружаем, чтобы увидеть реальную картину движения трафика, выявить очереди, коллизии и узкие места на всём пути.

Сквозные (end-to-end, E2E) пользовательские сценарии запускаем, чтобы убедиться: готовый функционал ведёт себя под нагрузкой именно так, как ожидает пользователь — от фронтенда через бэкенд до всех внешних интеграций.

❓ Какие типы нагрузки проверяете?

Используем все классические паттерны:

— Steady (стационарная нагрузка) — убеждаемся, что сервис стабильно держит предельную повседневную мощность в течение 1–2 часов без деградации.

— Soak (длительная нагрузка) — ищем скрытые проблемы: утечки памяти, незакрытые соединения и другие эффекты, которые проявляются только через часы или сутки.

— Spike (всплеск) — смотрим, как система реагирует на резкий пик трафика и насколько быстро восстанавливается после его спада.

❓ Какие метрики для вас ключевые?

Следим за двумя группами показателей.

Технические метрики качества сервиса:

— RPS (Requests Per Second — запросы в секунду) — главная характеристика пропускной способности.

— Latency (время ответа) — обязательно анализируем перцентили p95 и p99, потому что именно «хвост» распределения показывает реальный пользовательский опыт. Среднее значение часто обманчиво.

— Error Rate (процент ошибок) — стремимся к нулю, хотя в реальных условиях допустимый уровень зависит от сценария.

Утилизация ресурсов:
— CPU (загрузка процессора),
— Memory (потребление оперативной памяти),
— Network I/O (сетевая нагрузка).

❓ Какие инструменты используете?

Для нагрузки на уровне L7 (прикладной уровень) разработали собственный инструмент. Это высокопроизводительная система генерации трафика, которая точно воспроизводит поведение реальных покупателей и позволяет создавать нагрузку в сотни тысяч RPS.

Для L4 (транспортный уровень) применяем проверенные решения: Cisco TRex и MoonGen. На этом уровне генерируем «сырой» TCP/UDP-трафик, чтобы проверить пропускную способность сети, количество соединений и устойчивость к объёмным атакам.

❓ Как понимаете, что сервис выдержал нагрузку?

Сервис считается прошедшим тест, если выполняются три условия одновременно:

— Функциональность сохранена: нет ошибок в ответах, бизнес-логика исполняется корректно.
— Скорость в пределах нормы: например, p95 времени ответа не превышает установленный порог (часто < 10 мс для внутренних сервисов).
— Стабильность ресурсов: потребление CPU, памяти и сети предсказуемо, после теста показатели возвращаются к базовым значениям без «залипания».