Привет, Хабр! Меня зовут Богдан Бурков, я старший инженер по тестированию в мобильном приложении для продавцов Ozon Seller. В этой статье я хочу поделиться историей, как мы с коллегой, ведущим инженером по тестированию Владиславом Поповым (привет, Влад!), улучшали наш релизный процесс и что у нас из этого получилось.

Мы уже оптимизировали ручные проверки и увеличивали покрытие автотестами, но релизное тестирование всё равно занимало почти рабочий день. Подробнее об этом опыте можно прочесть в статье другого коллеги. Мы же решили копнуть глубже — не в сами тесты, а в процессы вокруг них. Выписали всё, что повторяется от релиза к релизу, отметили, какие действия блокируют переход на следующие этапы, оценили, сколько времени уходит на рутину, и выбрали те задачи, которые проще всего перенести в CI. Так мы нашли главную причину потерь времени и поняли, куда двигаться дальше.

В статье расскажу, что именно мы автоматизировали, что получилось не сразу и как в итоге сократили релизное тестирование примерно с семи до четырёх часов.

Привет! На связи Влад, разработчик product-facade — сердца витрины Ozon и одного из самых высоконагруженных сервисов, который выдерживает до 2,2 млн RPS. В прошлой моей статье я рассказывал об одном из архитектурных вызовов, с которым мы столкнулись в процессе работы. В этот раз продолжим тему микросервисной архитектуры и поговорим о том, что происходит, когда привычная строгость контрактов начинает мешать.

Одна из ключевых причин использования gRPC для связи между сервисами — строгий protobuf-контракт. Он даёт типизацию, фиксирует схему данных и снижает риск случайно сломать интеграцию. Но иногда случаются ситуации, когда эти плюсы загоняют нас в рамки. Например, когда сервис просто передаёт данные дальше, но его всё равно приходится обновлять из-за изменений, которые нужны только конечному потребителю. В таких случаях полезно знать, какие механизмы protobuf позволяют работать с контрактом более гибко, не отказываясь от него полностью. В статье расскажу о трёх из них и приведу примеры, для чего они могут применяться.

Представьте себе высоконагруженный сервис, который решает, с какого из множества складов нужно отправить товар покупателю. В пике через него проходит около 600 000 RPS, а строгий SLA требует ответа в пределах 50 мс. Для расчёта нужно за минимальное время выбрать оптимальный склад с учётом остатков, доступности и других данных, которые хранятся в разных микросервисах и их базах данных.

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

Привет, Хабр! В 2022 году я пришёл в Ozon Tech на позицию специалиста технической поддержки склада и начал разбираться, как настраивать и поддерживать оборудование на ФФ (фулфилмент), огромном складе площадью 70 000 м², где проходят операции от приёмки и хранения товаров до их подготовки к отправке на сортировочные центры. В тот момент всё работало стабильно. На складах использовались терминалы Zebra (ТСД — терминал сбора данных), вендор был на рынке, поддержка оставалась доступной, и никто особенно не задумывался, как всё устроено внутри. 

После изменения условий работы с вендором нам пришлось глубже разобраться в процессе настройки и поддержки устройств, чтобы сохранить стабильную работу терминалов на объектах. Оказалось, что поддерживать работу десятков тысяч терминалов по всей стране стало задачей с множеством неизвестных. Притом именно через них проходит большая часть складских операций, от приёмки и размещения товара до сборки и отгрузки заказов. Впереди нас ждали несколько лет разборов, ошибок, временных решений и постепенной перестройки всей системы. В какой-то момент казалось, что мы зашли в тупик. Но в итоге справились. Сейчас мы сократили время настройки терминала с 30 до 6 минут, управляем тысячами устройств удалённо и имеем единый лаунчер. В этой статье расскажу, как мы заново выстроили процесс настройки и управления терминалами на складах. Поехали!

Привет, Хабр! Меня зовут Алиса, я методолог информационной безопасности в Ozon. Я занимаюсь построением и улучшением процессов ИБ начиная от регламентов и требований до внедрения практических контролей в работу команд. Один из сложных участков в ИБ — работа с контрагентами. Компании используют внешние сервисы, подрядчиков, аутсорсинг, облака, интеграции и внешнюю разработку. При этом далеко не всегда понятно, кто отвечает за безопасность этих связей и с чего вообще начинать.

Привет, Хабр! Меня зовут Евгений Мазуренко, я руководитель отдела разработки финансового учёта в Ozon. Больше десяти лет управляю командами — маленькими и большими, продуктовыми и аутсорсинговыми. Раньше я искренне верил, что идеальный руководитель — это супергерой. Тот, кто всегда на подхвате, закрывает собой бреши, знает ответы на все вопросы и спасает проект собственным контролем. Я был в центре всего — код-ревью, баги, постоянная стыковка с продуктом. Мои часы «помощи» росли, и именно в этой роли я чувствовал свою необходимость и вклад.

А потом увидел обратную сторону. Скорость команды падала, энтузиазм угасал, инициатива стремилась к нулю. Запросы на помощь множились, а способность решать проблемы самостоятельно у команды таяла. Любое, даже самое очевидное решение требовало моего вмешательства. Тогда я осознал: моя «помощь» и была проблемой. Я создал систему зависимостей и оказался не спасательным кругом, а главным тормозом на пути роста команды. Сегодня в статье разберу три вещи, которые помогли мне иначе посмотреть на роль руководителя: как нанимать людей под команду, как давать задачи с понятным смыслом и как помогать так, чтобы не забирать у команды ответственность.

Весь этот шум вокруг AI заставляет задуматься, а выживут ли традиционные интерфейсы с окнами и кнопками. Не окажется ли, что через несколько лет основным интерфейсом станет одна умная строка, в которую мы просто пишем или говорим, что хотим получить? Я думаю, что графические интерфейсы не исчезнут. Но они изменятся — как уже менялись не раз.

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

Всем привет! Меня зовут Петя Портнов, я работаю в Ozon ведущим разработчиком в команде среднего поиска — слоя, который ранжирует поисковую выдачу.

Представьте, что вы вводите запрос в поисковую строку маркетплейса. За этим простым действием скрывается сложный поисковый пайплайн: миллионы товаров фильтруются, ранжируются и сортируются по релевантности. Но как именно система решает, что показать первым? В основе этого решения лежат вычисления, среди которых — сотни разнообразных формул, учитывающих цену, рейтинг, популярность, персонализацию и другие факторы. По мере развития системы таких формул становится всё больше, а сами они усложняются. В какой-то момент вычисления превращаются в узкое место: начинают потреблять значительную долю CPU, создают множество промежуточных объектов — и так для каждого поискового запроса. Возникает вопрос: как снизить стоимость таких вычислений в JVM?

В этой статье я расскажу, что сделали мы, чтобы снизить нагрузку на систему: как заменили интерпретирующий движок формул на динамический компилятор, выполняющий построение эффективного байт-кода, отлично векторизующегося JIT-компилятором. Это текстовая версия доклада с Joker 2025 с дополнениями, которые не вошли в выступление или появились в проекте уже после конференции.

Вы начинаете набирать запрос в поисковой строке на Ozon и сразу видите список вариантов. Иногда кажется, что поиск читает мысли. Хотя магии здесь нет. Есть система подсказок или саджестов (от англ. suggest), которая должна за доли секунды понять, что вы хотите, и предложить лучший вариант. На всё — 300 мс. Если она думает дольше, пользователь замечает «подвисание», раздражается и вводит запрос вручную.

Рано или поздно возникает вопрос, как одновременно держать высокое качество и жёсткие ограничения по скорости? Долгое время мы решали это классически. Брали готовые запросы и обучали градиентный бустинг над деревьями решений выбирать лучшие варианты. Работает? Да. Хватает ли этого? Уже нет. В какой-то момент мы упёрлись в потолок качества. Улучшать ранжирование становилось всё сложнее, а эффект был всё меньше. Тогда мы попробовали другой подход и начали генерировать подсказки, а не выбирать из готовых.

Когда речь заходит про автотесты, первыми на ум приходят проверки для UI, API или для мобильных устройств. Однако автотесты нужны не только для проверки пользовательских сценариев. Они могут решать и менее очевидные, но не менее важные задачи, например проверять работу пайплайнов. Если одни и те же пайплайны используют сотни сервисов и библиотек, любая ошибка в них быстро выходит за пределы одного проекта. У многих команд одновременно могут сломаться сборки, релизы и привычный процесс разработки. В нашем случае такие пайплайны работали примерно для 700 сервисов и более 200 библиотечных репозиториев. Чтобы гарантировать работоспособность пайплайнов, мы пришли к идее покрытия их автотестами.

В статье я расскажу, как мы в Ozon покрывали тестами работу пайплайнов в GitLab CI, какие требования нужно было учесть и как в итоге были устроены end-to-end-тесты для таких сценариев.

Разработка высоконагруженных систем — типовая инженерная задача. Для неё есть паттерны, инструменты и понятные подходы. Но что делать, когда нагрузке подвергаются не приложения, а люди? Когда одновременно растут сроки, количество задач и неопределённость — и сбой даёт уже не система, а команда?

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

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

Меня зовут Владимир Фрадков, я руковожу группой дизайна «Стандарты и развитие» в личном кабинете продавца Ozon. В этой статье я хочу поговорить о том, как упорядоченность и системность помогают в дизайне и почему единый документ с правилами может стать тем самым «кольцом всевластия» для вашего продукта.

Привет, я Таня — работаю ведущим продуктовым дизайнером опыта покупателя в Ozon. Среди моих продуктов «Избранное», «Вишлисты», мини-апп «Доставки посылок», а в прошлом я дизайнила «Карточку товара». Год назад я ротировалась в команду «Корзины», потому что хотела для себя новых вызовов.

На примере редизайна «Корзины», я хочу показать, как сегодня меняется роль дизайнера в продукте, чем дизайн-стратегия отличается от просто красивого концепта, почему такие изменения невозможно делать в одиночку.

Привет! Меня зовут Дмитрий, я ведущий разработчик в команде рекламного рантайма. Наша команда, как вы уже могли догадаться, занимается разработкой аукционов в поисковой рекламе Ozon.

В этой статье я хочу познакомить вас с механикой аукционов и рассказать, как мы делаем это в Ozon. Сначала мы разберёмся, что такое рекламный аукцион, что он имеет общего с аукционом в обычном понимании и как используется в контексте поисковой рекламы. А ещё подробно разберём аукцион типа VCG (аукцион Викри — Кларка — Гровса), вместе выведем формулы для него и посмотрим, какие результаты мы получили на практике.

Привет, Habr! Меня зовут Костя Козлов, я работаю в команде анализа и валидации экспериментов A/B-платформы Ozon. В предыдущей статье коллеги рассказали, как создать высокопроизводительную платформу сплитования пользователей на группы и стенд метрик. В этой статье расскажу, как построить поверх этого инструмент, который автоматически оптимизирует бизнес-метрики продукта за счёт "умного" перебора возможных вариантов его параметров.

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

Привет, Хабр! Меня зовут Настя, я работаю методологом в команде проекта Route 256 — онлайн-курсов продвинутой разработки от экспертов Ozon Tech. В этой статье мы обсудим, что делать, если в жизни становится слишком много информационного контента.

Например, у вас уже несколько месяцев остаются открытыми 15 вкладок «почитать потом», в закладках лежит «идеальный роадмап по Go», а в рекомендациях — «10 must-watch-докладов про архитектуру». В IT это особенно заметно: технологии и инструменты обновляются быстро, а вокруг постоянно есть поток учебных материалов, чтобы оставаться в теме. Нужно с этим что-то делать или нет?

Привет! Меня зовут Егор Лукьянов, я старший аналитик данных в Ozon Tech. В своей работе я часто сталкиваюсь с проблемой масштабируемости в pandas. Код, который быстро работает на гигабайте данных, начинает невыносимо тормозить на десяти. Уверен, эта боль знакома многим.

Сейчас есть быстрые альтернативы, например, Polars. Я сам пробовал переводить на него свои проекты. Скорость действительно впечатляет, но как в анекдоте есть нюанс: приходится переписывать чуть ли не весь код и привыкать к новому синтаксису. А это большая работа, на которую не всегда есть время.

И вот здесь я наткнулся на FireDucks — библиотеку, которая обещает решить эту проблему, просто заменив одну строку импорта. Звучало слишком хорошо, чтобы быть правдой. После опыта с Polars я был уверен, что где-то должен быть подвох.

Я решил проверить FireDucks на нескольких типичных задачах. В этой статье я хочу без лишнего хайпа поделиться тем, что у меня получилось. Мы посмотрим на реальные примеры кода, сравним скорость и разберёмся, где эта библиотека действительно хороша, а где могут быть проблемы.

Всем привет! Меня зовут Станислав Ким, я ML-разработчик в команде качества поиска Ozon. В этой статье расскажу, как мы перешли от ранжирования товаров к ранжированию предложений, внедрили «матрицу памяти» для переноса статистики и получили +0,9% к GMV на пользователя.

Представьте простую ситуацию. Вы — продавец электроники. Выводите на Ozon новую модель робота-пылесоса. Чтобы ворваться на рынок, вы ставите цену на 20% ниже конкурентов и отгружаете партию на ближайший склад, чтобы доставка была «завтра». Логика подсказывает: алгоритмы увидят выгодное предложение (дёшево + быстро), подкинут товар в топ, и продажи взлетят.

Реальность: проходит день, два... а товар висит на 5-й странице выдачи. Потому что для алгоритма ранжирования ваш пылесос — «чистый лист». У него нет истории продаж, нет кликов, нет отзывов. Рядом в топе — конкуренты: они дороже, доставка дольше, но у них есть история: тысячи заказов за прошлый год. Алгоритм «любит» их за накопленную статистику, а ваше выгодное предложение игнорирует — он просто не знает, чего от него ждать. В индустрии эта проблема называется cold start — и с ней сталкиваются все крупные маркетплейсы.

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

Всем привет! Меня зовут Юлия Новикова, и в мае 2025 года я стала Team Lead группы фронтенд-разработки в Ozon. В моей команде сейчас 5 разработчиков и 2 тестировщика, и мы создаём фронтенд для админок, которые управляют работой складов, РЦ (распределительный центр) и дарксторов. Но путь мой сюда был не самым тривиальным — до этого я была QA Lead, а не разработчиком.

А началось всё с того, что я начала думать: а что дальше? Кем я могу стать, если ещё вырасту? Вакансий руководителей тестирования, а особенно руководителей отделов тестирования, не так много, а хотелось больше влияния, больше развития. И я решила прыгнуть вбок и сменить профессию: стать тимлидом разработки. Расскажу, как это было и чего стоит ожидать тем, кто задумывается о таком же повороте.

Привет, Хабр! Я Маша, младший инженер по тестированию в Ozon Tech, а совсем недавно — стажёр. Сейчас я опишу, как здесь оказалась и что будет с вами происходить, если вы начнёте карьерный путь в Ozon Tech (но это не точно, у каждого из нас свой путь и команда!).

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