Каждый день в 18:00 клиентам становится доступна отчётность по продажам, и многие одновременно нажимают кнопку «Загрузить отчёт». Это может быть детализированный отчёт по списаниям, юридическая отчётность, аналитическая выгрузка или API, используя который клиент получает данные для дальнейшей обработки. В этот момент даже хорошо подобранное хранилище может стать узким местом.

В моей практике разработки часто встречаются сценарии, когда необходимо предоставить доступ к большому количеству данных по HTTP. На первый взгляд задача выглядит простой: берём подходящее хранилище, пишем endpoint, выполняем запрос и отдаём результат пользователю. Но на практике такая схема быстро упирается в ограничения.

11:07 — разработчик пишет: «Готово, можно смотреть».
11:10 — менеджер уверен, что задача уже ушла в тестирование.
13:00 — выясняется, что проверка на стороне тестирования не начиналась.

Никто не забыл про задачу и не нарушил процесс. Она просто зависла между «готово» и «взял». Такие паузы редко выглядят критичными, но именно из них складываются задержки релизов, сорванные сроки и ощущение, что все постоянно заняты, а работа движется медленнее, чем должна.

Я работаю QA-инженером в Ozon Tech и часто вижу, как задачи переходят между разработкой, тестированием, менеджерами и другими командами. Статус в тикете может быть обновлён, договорённость в чате зафиксирована, но ни то ни другое не гарантирует, что следующий шаг кто-то действительно принял.

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

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

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

Просим пристегнуться. Мы начинаем взлёт.

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

И тут стоит подчеркнуть, что детект должен быть достаточно хорошим и в идеале не занимать весь капаситет L1 SOC ложными сработками. Первая линия организует непрерывный мониторинг состояния защищённости корпоративной вычислительной сети совершенно разными способами, о чём можно прочитать в статье моей коллеги Как измерить то, чего не видно: метрики SOC.

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

Масштабирование автотестов — закономерный этап развития любого растущего проекта. С увеличением количества автотестов меняются требования к архитектуре, инфраструктуре и процессам разработки. Репозиторий становится сложнее, возрастает время выполнения прогонов, увеличиваются затраты на поддержку и диагностику падений. На каждом этапе проекту требуются новые инструменты и подходы, которые позволяют сохранить скорость разработки и устойчивость всей системы автоматизации.

Меня зовут Михаил, в Ozon занимаюсь тестированием и автоматизацией финансовых сервисов маркетплейса. До этого за шесть лет мне довелось поработать в шести компаниях и получить опыт в проектах разного масштаба. Многие из них проходили нижеописанные этапы развития, хотя различались продуктами, командами и технологическим стеком. В этой статье я разделю этот путь на четыре условных уровня и покажу, какие метрики сигнализируют о необходимости роста, а также разберём этот процесс на всех уровнях: от архитектуры фреймворка до выстраивания процессов и TestOps.

Всем привет! Меня зовут Алёна, я руководитель группы аналитики отдела Compliance и безопасности данных в Ozon. Звучит длинно, поэтому мы с командой называем себя просто датасеками — от Data Security. В информационной безопасности я почти 13 лет, из них 4,5 года в Ozon. До этого больше восьми лет работала в интеграторе и занималась в основном персональными данными и банковской безопасностью — вопросами чистого compliance. Сейчас у меня команда из 11 человек, и мы занимаемся безопасностью данных в Ozon.

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

Всем привет! Меня зовут Муса. Наша команда занимается витринами данных по товарному учёту.

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

Первое решение выглядело просто: положить данные в ClickHouse и сделать JOIN. Но одна выгрузка считалась около 12 часов, а нам нужно было укладываться в десятки минут.

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

Привет, Хабр! Я Вадим, разработчик QA-платформы в Ozon. Стандартного testing в Go хватает юнит-тестам, но большим end-to-end-сценариям нужно больше: Allure-отчёты, плагины, Suite’ы, параметризация, параллельные запуски. Мы не нашли в Go-экосистеме инструмент, который закрывал бы всё это, не ломая привычный go test, — и написали свой: Testo. Сегодня на нём работает больше 60 тысяч тестов для 500+ сервисов Ozon, а теперь мы опубликовали его в open source.

В статье покажу Testo и плагины в деле: как небольшой Go-тест шаг за шагом превращается в полноценный e2e-сценарий с отчётами, фикстурами, хуками и шагами, сохраняя привычный вид.

Привет! Мы команда рекомендательной системы Ozon, и сегодня мы хотим рассказать о нашем пути от приближённого поиска соседей (ANN) к точному KNN на GPU. Этот материал для тех, кто работает с рекомендациями, поиском или большими векторными пространствами и задумывается о том, можно ли выжать максимум из железа, не жертвуя качеством.

В индустрии уже есть примеры, когда команды рекомендаций уходят от готовых ANN-индексов к более специализированным GPU-решениям скоринга. Мы же опишем, как это выглядит в масштабах российского e-commerce, и расскажем о результатах A/B-тестов. Сразу оговоримся: это не «Hello, world» с парой тысяч векторов, а продакшен на десятки миллионов пользователей и сотни миллионов товаров, где каждый час пайплайна и каждый процент recall имеют цену.

Привет, Хабр! Меня зовут Богдан Бурков, я старший инженер по тестированию в мобильном приложении для продавцов 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-тесты для таких сценариев.

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

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