Привет! Я Дмитрий Колесников, Team Lead DS-команды «Платформа модерации» в Wildberries & Russ. В этой статье по мотивам моего доклада на HighLoad расскажу, как у нас получилось превратить сотни Computer Vision моделей в единый масштабируемый пайплайн, который ежедневно обрабатывает 15 млн карточек товаров (50+ млн изображений и 500K видео).
Привет! Меня зовут Иван Откидач, я DevOps-инженер в команде DBA. Моя основная специализация — NoSQL-базы данных, в частности Redis и MongoDB. С каждым месяцем количество Redis, находящихся на нашей поддержке, растёт, поэтому обеспечение их стабильной и надёжной работы — один из приоритетов нашего подразделения. В этой статье мы разберем, как устроен механизм отказоустойчивости в Redis Cluster и почему он может давать сбои в multi-AZ-инфраструктуре. Также покажем один из практических подходов к решению этой проблемы.
Когда смотришь на современные AI-агенты, быстро замечаешь одну общую черту: почти все они живут на тяжелом стеке. Где-то это Node.js, где-то Python, где-то длинная цепочка зависимостей, сервисов и фоновых процессов. На этом фоне nullClaw выглядит почти инородно: один бинарный файл, Zig, быстрый запуск, мало занимаемой памяти и минимум лишнего.
Для этой статьи я смотрел nullClaw в состоянии v2026.3.13-1-g78366e9. Для сравнения я отдельно прогнал те же сценарии на свежем npm-релизе OpenClaw 2026.3.12.
Сразу оговорюсь: это не сравнение полноты платформ. nullClaw я смотрю как маленький single-binary runtime на Zig, а OpenClaw — как более широкий self-hosted gateway/agent stack с Node-зависимостью, daemon/gateway-режимами и Control UI. Поэтому ниже я сравниваю не «кто лучше вообще», а цену локального запуска в одинаковых коротких сценариях: служебные команды, один agent-run, маленькая coding-задача и пачка параллельных небольших coding-задач.
Привет, Хабр! Меня зовут Ибрагим и я бэкенд-разработчик в команде, которая разрабатывает C2C-площадку в Wildberries — раздел, где пользователи могут продавать друг другу товары через объявления. За каждым объявлением и заказом стоит набор данных, который аналитики используют для отслеживания метрик платформы: жизненный цикл объявлений, конверсии, статусы заказов.
Чтобы эти данные попадали в ClickHouse к аналитикам, нам нужна была надёжная синхронизация из PostgreSQL. Долгое время она работала через polling-сервис — и какое-то время нас это устраивало. Но по мере роста платформы проблемы стали проявляться всё чаще: данные терялись, лаг репликации достигал нескольких минут, а нагрузка на базу росла вместе с объёмами.
Когда проблема стала достаточно ощутимой, мы с тимлидом начали смотреть в сторону CDC — он подсветил Debezium как подходящий инструмент, я взял реализацию на себя: написал Go-сервис, развернул всю инфраструктуру локально и протестировал. Далее описал девопсам всю схему и мы развернули инфраструктуру на виртуалках. В этой статье расскажу, что из этого вышло.
Привет, Хабр! Отличный день, чтобы поделиться карьерными историями айтишниц Wildberries & Russ. Поговорили про профессиональный путь, амбиции и поиск баланса между работой и жизнью.
Привет! На связи вновь команда Геосервисов. Как вы помните, в прошлой статье я делился нашим опытом партиционирования и теми выводами, к которым мы пришли. Но на этом история не закончилась. Что же было дальше?
Партиционирование завершилось успешно. VACUUM сократился с 6+ часов до ~20 минут. Запросы ускорились. Мы думали, что всё позади. Через неделю после swap проверили реплику — и обнаружили, что она пуста.
В высоконагруженных системах балансировка трафика быстро перестаёт быть просто задачей распределения запросов. Сегодня на реальном опыте разбираем путь от BGP Anycast к L4-балансировке и XDP: зачем она понадобилась, как помогла справиться с ограничениями Anycast, повысить отказоустойчивость и производительность, а также почему балансировщик стал точкой входа для защиты от L4-DDoS. Статья будет полезна инженерам, которые проектируют и развивают инфраструктуру под высокий трафик и пиковые нагрузки.
Всем привет! Поводом для написания этой статьи послужила ситуация, с которой мы в команде Геосервисов столкнулись.
Когда наша база данных нормализованных OSM-данных достигла размеров в 600+ ГБ, VACUUM стал занимать 6+ часов. Мы начали приближаться к пределу хранилища (600 GB из 1 TB), а производительность запросов деградировала. Стало очевидным — партиционирование неизбежно.
В этой статье: как мы готовили миграцию, какие грабли собрали, и почему для управления долгоживущим процессом недостаточно стандартного мониторинга.
Всем привет! Меня зовут Никита Крестьянинов, я руководитель группы управления бизнес-процессами служб сервиса в команде Russtech. Сегодня я хочу рассказать, как мы совместно со стажерами разработали ИИ-инструмент, способный отслеживать состояние работы цифровых рекламных конструкций.
Эта статья будет полезна тем, кто отчаянно нуждается в документации, но не обладает ресурсами и навыками технического писателя. Например, менеджерам, разработчикам или тестировщикам, небольшим стартапам, проектам внутри копаний или командам, которые хотят облегчить погружение новых сотрудников в проект и процессы.
Меня зовут Люсьена Мирославская, я работаю техническим писателем в Wildberries третий год. На протяжении развития моей карьеры в IT, а это более пяти лет суммарно в разных компаниях, я часто сталкиваюсь с проблемой недостаточности документации. Её или нет, или она неактуальная, неполная, неверная, да и несистематизированная, а иногда просто непонятная. Я не волшебник, поэтому не смогу вместить весь свой опыт в одну статью, но точно задам направление для ориентира и помогу, как минимум, создать черновик документации.
Думаю, многие сталкивались с ситуацией, когда в компании есть множество различных сервисов, которым нужно асинхронно обмениваться данными. Databus — это волшебная шина, которая как раз решает эту задачу.
В этой статье я расскажу, как устроен централизованный, надёжный и удобный способ асинхронного взаимодействия сервисов внутри Wildberries. Я Виктор Такташов, Golang-разработчик в команде Trust & Safety. С задачами Highload знаком не понаслышке, потому что когда-то занимался сервером популярной онлайн-игры. К тому же я больше шести лет занимался борьбой, так что с проблемами расправляюсь умело и хладнокровно :-)
Почему мы решили сделать Databus
Всем привет! Меня зовут Максим, я Go-разработчик в Wildberries & Russ. В высоконагруженных системах сотни сервисов взаимодействуют ежесекундно, и любой малейший простой системы напрямую влияет на прибыль бизнеса. Чтобы уметь быстро находить причины и устранять их за короткие сроки придуманы инструменты, обеспечивающие наблюдаемость приложения. Сегодня поговорим о том, как обеспечить observability и почему без нее жизнь продукта превращается в «черный ящик».
Всем привет! Меня зовут Татьяна Цикунова, я работаю системным аналитиком уже более 5 лет и за это время получила опыт в 4 проектах, а также долгое время имела честь онбордить новых аналитиков в разных командах.
Тема онбординга важна для любого IT-специалиста. Поэтому сегодня разберёмся, как провести онбординг системного или бизнес-аналитика в новую команду не только успешно, но и эффективно.
Начнём с того, что я кратко расскажу, из чего состоит статья. Мы поговорим о сложностях, с которыми сталкивается аналитик на новом проекте, расскажем лайфхаки для качественного онбординга, а в конце заправим это дело практическим чек-листом.
Я — Антон Марунько, руководитель в продуктовых компаниях уже более шести лет, помогаю строить и обучать команды в сфере IT.
Команда работает больше, процессов добавили, людей наняли. А результат тот же. Или хуже. Почему улучшения не работают? Рассказал, как перестать улучшать всё подряд и начать делать команду быстрее:
• Почему масштабирование команды не даёт результата (и что делать вместо этого);
• Когда стоит делегировать задачи, а когда нет;
• Как найти одно узкое место, которое тормозит всю систему.
В статье — разбор реальных кейсов от IT-команд до распределенных продуктовых групп, с примерами правильных и ошибочных решений.
Привет, Хабр! С вами команда Russtech — разработчики ведущего российского оператора рекламы вне дома Russ. Сегодня мы расскажем о еще одном нашем IT-продукте — платформе управления контентом на цифровых экранах Russ Player. Данный инструмент помог нам существенно оптимизировать работу с креативами и добиться гибкого, эффективного планирования рекламных кампаний. В статье разберем, что представляет собой система вещания, как формируется расписание эфира и какие возможности в цифровой рекламе вне дома (DOOH) открывают realtime-механики.
Можно сделать самую лучшую на свете модель, но от нее будет мало проку, если не обеспечить ее интеграцию в реальные бизнес-процессы.
Всем привет, я Илья Бадекин — Data Scientist в команде товарных рекомендаций Wildberries, и в данной статье расскажу о том, зачем текстовый энкодер в команде «Товарных рекомендаций» Wildberries, на что он способен и как мы сжимали его эмбеддинги для онлайн-доранжирование рекламных баннеров по запросам пользователей.
Всем привет! Меня зовут Татьяна Кутузова, я работаю в Wildberries & Russ ML-инженером. Вместе с Иваном Горбуновым и Елисеем Мягких мы занимаемся разработкой AI-детектора изображений, который помогает отличать реальные фотографии от сгенерированных нейросетями.
Детектор появился из практической потребности: генеративные модели стали достаточно хороши, чтобы их результат массово попадал в пользовательский контент, и платформе понадобился автоматический способ с этим работать. Создание такого инструмента — это не только обучение модели, но и большое количество инженерных, продуктовых и методологических решений: что считать генерацией, на каких данных обучаться, как обеспечить устойчивость к новым моделям и как интегрировать детектор в реальные процессы.
В этой статье рассказываем, как мы подошли к созданию AI-детектора: от выбора архитектуры и данных до продуктовых границ и сценариев применения. Отдельное внимание уделяем тому, как в таких задачах корректно оценивать качество модели, какие метрики имеют смысл и почему их интерпретация не менее важна, чем сами числа.
Привет! Я Владислав Раев, DevOps & DevTools Engineer в команде Wildberries & Russ. Сегодня погружу вас в увлекательную историю о том, как мы наводили порядок в Nexus OSS и экспериментировали с Terraform и Ansible. Спойлер: контекст оказался важнее технологий.
Всем привет! На связи Ваня Ващенко, и я лид по развитию нейросетевых моделей в команде персональных рекомендаций Wildberries. Раньше я развивал B2C-рекомендации и нейросети кредитного скоринга в крупнейшем банке, а теперь вы видите результаты моей работы каждый раз, когда заходите на главную страницу любимого маркетплейса. Сегодняшний рассказ — о том, как мы развиваем WildBERT.
Публичные выступления плотно вошли в мою жизнь ещё в школе. Мне довелось выступать на научных конференциях, собраниях, занятиях. В числе необычных аудиторий — собрание офицеров и иностранные студенты из Африки. Последние несколько лет я активно выступаю с докладами в ИТ, делюсь опытом публичных выступлений с ребятами из команды.
В статье обсудим базовые шаги, которые позволят спикеру эффективно подготовить публичную речь и сформируют каркас для дальнейшего развития навыка.
