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

Алексей Медошин, директор департамента защиты от 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, памяти и сети предсказуемо, после теста показатели возвращаются к базовым значениям без «залипания».

⏪️ Привет! Уже сталкивались с интересными кейсами по Kafka в проде?

Задали практичные вопросы Алексею Коровкину, техническому руководителю бэкенда клиентского приложения Wildberries.


⏹️ В каких сценариях вы используете Kafka и какую роль она играет в архитектуре?

Kafka применяется в следующих случаях:

— для асинхронных интеграций между командами,
— общения микросервисов внутри проекта без жёстких зависимостей,
— реализации event-driven architecture,
— паттерна Saga — чтобы максимально избегать распределённых блокировок.

⏹️ Какие типовые нагрузки у ваших потоков?

Kafka хорошо справляется с высокими нагрузками за счёт горизонтального масштабирования. Ключевая возможность — перечитывание топика с любого смещения (offset). Чтобы эта функция работала эффективно, критически важно правильно настроить Retention Policy— политику хранения сообщений в топике.

⏹️ Как вы подходите к дизайну топиков?

Дробление строго по доменной области не всегда оправдано — домен может быть большим и содержать очень разные сущности. Самый надёжный и универсальный подход — разбивать топики по типам событий.

⏹️Как вы выбираете ключ партиционирования (значение, по которому сообщения распределяются по партициям одного топика)?

Kafka гарантирует порядок сообщений только внутри одной партиции (логического сегмента топика, который обрабатывается независимо). Если для сущности критична строгая последовательность статусов — используем идентификатор сущности как ключ партиционирования. Если порядок не важен — оставляем дефолтное поведение для равномерного распределения нагрузки по консьюмерам (компонент, который читает и обрабатывает сообщения из топика).

⏹️ С какими проблемами вы сталкивались из-за неудачного выбора топиков?

Основная проблема возникает, когда в топике есть сущности, которые нельзя обработать идемпотентно (повторная обработка того же сообщения не приводит к изменению результата). В таком случае сдвиг offset приводит к ошибкам, и консьюмер не может продолжить корректную работу.

⏹️Какие гарантии доставки вы используете и почему?

Используем at-least-once — самый универсальный и безопасный вариант. Он исключает потерю сообщений (в отличие от at-most-once), а exactly-once слишком дорого стоит для брокера и всё равно не защищает от дублей при падении и перезапуске консьюмера.

⏹️Как вы работаете с дублями сообщений?

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

⏹️Как вы работаете с порядком событий и консистентностью?

Нарушение порядка — всегда признак проблемы в отправителе и повод для рефакторинга. Если это всё же происходит — отправляем событие в Dead Letter Queue (DLQ) на ручной разбор. «Силовое» переключение статуса маскирует проблему и часто приводит к трудноуловимым багам.

⏹️Какие метрики Kafka-консьюмеров для вас самые важные?

Самая критичная метрика — consumer lag (отставание консьюмера — разница между последним записанным и последним прочитанным смещением). Она сразу сигнализирует и о необходимости масштабирования, и о проблемах на стороне консьюмера.

⏹️Какие главные уроки вы вынесли из эксплуатации Kafka? Что бы сделали иначе?

Kafka — мощный, но не универсальный инструмент. Главные ошибки, которых стоит избегать:

— использование как замены базы данных;
— превращение в шину для синхронных RPC-вызовов;
— игнорирование ключей партиционирования;
— создание топиков без предварительного дизайна.

А какие вопросы по Kafka чаще всего возникают у вас в проектах?

👆 Пишите в комментариях — обсудим реальные кейсы!

⚠️⚠️⚠️ Новая вакансия в команду!

➡️ GO-разработчик в Геосервисы
middle/гибрид

Ищем специалиста с опытом работы с PostgreSQL или MongoDB. Желателен опыт работы с геосервисами, картами или в сфере логистики. Вы обладаете хорошими знаниями алгоритмов, умеете глубоко анализировать поставленную задачу и находить нестандартные, эффективные решения.

👀Откликнуться

⭐️⭐️ Save the date: встречаемся 26 марта на AntiDDoS Meetup Wildberries & Russ

26 марта 19:00 мск приглашаем вас на AntiDDoS-митап. В программе три технических доклада и нетворкинг с экспертами, которые каждый день работают с защитой в продакшне. Поговорим про инструменты генерации трафика, внедрение антибота в мобильное приложение без ущерба для UX и путь к VM-обфускации JavaScript.

⏹️Доклады:

— Гид по инструментам генерации трафика | Андрей Аксенов, QA Lead департамента защиты от DDoS-атак

Нагрузочное тестирование проще, чем кажется, если выбрать правильный инструмент под задачу. В докладе — практическое сравнение решений и четкие причины, почему перформанс-тесты должны стать регулярной практикой каждой команды.


— Антибот в мобильном приложении: зачем нужен и как работает | Денис Ульянов, руководитель продукта Antibot

Мобильный антибот требует баланса между жёсткой защитой и плавным UX. Расскажем, как адаптировать защиту под iOS и Android и почему мы перешли от скоринга устройства к машинному обучению для борьбы со сложными атаками.


— Как спрятать JavaScript на самом видном месте: путь к VM-обфускации в антиботе | Родион Черников, ведущий разработчик команды Antibot

Как сделать разбор защиты дорогим проектом для атакующего, найдя компромисс между инженерной сложностью и экономическими затратами.

⏹️Формат: офлайн в Москве + онлайн-трансляция

⏹️Сбор участников для офлайна начинается в 18:00

⏹️После докладов — афтепати и нетворкинг с разработчиками Wildberries & Russ.


⏩️ Регистрируйтесь, количество мест в офлайн ограничено.

⏩️ CHOOSE YOUR FIGHTER ⏪️🥹

🥹🤩🤩
🥹🤩🤩🤩🥹Go-разработчик
🤩🤩🤩🤩🥹🥹🥹🥹🥹🥹🥹🥹🥹🥹🥹🥹🥹🥹🥹🥹🥹🥹🥹🥹
Должность: Backend-разработчик (Go)

Ключевая характеристика: Пишет так, будто код завтра будут читать в суде. Минимализм, лаконичность, никаких лишних абстракций.

Главный страх: Что кто-то добавит в проект «чуть-чуть магии» и нарушит его идеальный context.

Что бесит больше всего: «Давай завернём это ещё в один слой»

Любимый напиток:
Американо. Без сахара. Без молока.

Эмоджи: ⚙️☕

Цитата: «Это можно написать проще»

🤩🤩🤩
🤩🤩🤩🥹Мобильный разработчик
🤩🤩🤩🤩🥹🥹🥹🥹🥹🥹🥹🥹🥹🥹🥹🥹🥹🥹🥹🥹🥹🥹
Должность: iOS / Android developer

Ключевая характеристика: Живёт между релизами, сторами и “ещё одну мелкую правку перед продом”.

Главный страх: Что после релиза на проде кнопка съедет на 2 пикселя и это увидит весь мир.

Что бесит больше всего: Стор отклонил билд / разная верстка на 347 устройствах

Любимый напиток: Матча или латте на альтернативном молоке

Эмоджи: 📱🚀

Цитата: «Локально всё работает.»

🥹🤩🤩
🥹🤩🤩🥹 Фронтенд-разработчик🥹
🤩🤩🤩🤩🥹🥹🥹🥹🥹🥹🥹🥹🥹🥹

Должность: Frontend developer

Ключевая характеристика: Человек, который держит визуальный мир на своих плечах и воюет с CSS.

Главный страх: Safari опять что-то решит по-своему.

Что бесит больше всего: правки без макета / legacy на 17 версиях React

Любимый напиток: Раф или латте

Эмоджи: 🎨💻

Цитата: «Это не баг, это фича рендера.»

🥹🤩🤩
🥹🤩🤩🤩🥹🥹QA-инженер
🤩🤩🤩🤩🥹🥹🥹🥹 🥹

Должность: Инженер по тестированию

Ключевая характеристика: Находит проблемы даже там, где их не было (именно поэтому прод жив).

Главный страх: релиз в пятницу.

Что бесит больше всего: «Не воспроизводится» / фича без требований

Любимый напиток: сидр.

Эмоджи: 🔍🧪

Цитата: «Повтори шаги, пожалуйста.»

🥹🤩🤩
🥹🤩🤩🥹🥹 🥹DevOps
🤩🤩🤩🤩🥹🥹🥹🥹🥹🥹🥹🥹🥹🥹🥹🥹🥹🥹🥹🥹

Должность: DevOps / SRE

Ключевая характеристика: Человек, который знает, почему всё упало. И почему он не виноват.

Главный страх: -rm rf // кто-то нажмёт kubectl delete не туда.

Что бесит больше всего: ручные деплои ИЛИ отсутствие логов

Любимый напиток: Черный кофе.

Эмоджи: 🔥🚨

Цитата: «А мониторинг у вас вообще был?»

🥹🤩🤩
🥹🤩🤩🤩🥹Системный аналитик
🤩🤩🤩🤩🥹🥹🥹🥹🥹🥹🥹🥹🥹🥹🥹🥹🥹🥹🥹🥹🥹🥹

Должность: System Analyst

Ключевая характеристика: Переводчик с языка бизнеса на язык разработчиков и обратно.

Главный страх: Что требования «примерно такие».

Что бесит больше всего: «Давайте без документации» // изменения требований на этапе релиза.

Любимый напиток: зеленый чай.

Эмоджи: 📊📝

Цитата: «Давайте зафиксируем»

👆 Пишите в комментариях, узнали коллег?

⭐️⭐️ NullClaw под лупой: зачем AI-агенту Zig, маленький бинарь и быстрый запуск

Почти все современные AI-агенты живут на тяжёлом стеке — Node.js, Python, длинные цепочки зависимостей. NullClaw выглядит на этом фоне почти по-другому: один бинарный файл, Zig, быстрый старт, мало памяти.

Проверили это на практике — замерили и сравнили с OpenClaw на реальных сценариях:

— Почему выбор языка влияет не только на производительность, но и на безопасность;
— Сравнение --help, agent-run и coding-задач: от 0.002 s и ~1.9 MB до 10 параллельных агентов;
— Почему разрыв по памяти в 10x важен не только на десктопе, но и на edge и wearables;
— ClawWatch как пример того, зачем вообще нужен компактный агентный runtime на устройстве.

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