Привет, я Таня, и наша команда занимается разработкой инфраструктуры для нагрузочного тестирования (НТ) в Ozon. Наша цель — предоставить разработчикам простой и понятный инструмент для подготовки и самостоятельного запуска нагрузочных тестов — можно сказать, нагрузочное тестирование as a service. У нас НТ широко распространено и поставлено на поток — большинство продуктовых сервисов регулярно тестируется по расписанию, в автоматическом режиме. Кстати, подавляющая часть тестов проводится не на тестовых стендах, а прямо в продакшене. Это связано с определёнными рисками, ведь есть ещё и реальный пользовательский трафик. Обложившись алертами и автостопами (критериями для автоматической остановки тестов), мы сводим эти риски к минимуму.  

Компания растёт, увеличивается число пользователей и сервисов. В один прекрасный день нам стало тесно в рамках одного дата-центра — началось масштабное расширение на три ЦОДа. Каждый сервис обзавёлся дополнительными инстансами — и новыми требованиями к нагрузке. У НТ-разработчиков появилась задача тестировать сервисы, разбросанные по разным ЦОДам, и при этом ничего не уронить (мы ребята высоконагруженные). Кроме того, для уменьшения объёмов трафика между ЦОДами и сетевых задержек сервисы при взаимодействии перешли с серверной на клиентскую балансировку. Так как при НТ требуется максимально точно воспроизводить клиентский трафик, от генераторов нагрузки ожидалось такое же поведение. О том, какие перед нами стояли задачи и как мы с ними справились, читайте под катом. 

Привет, Хабр! Меня зовут Сергей, я руководитель команды поиска в Ozon. Сегодня я расскажу об эволюции наших поисковых систем: как всё начиналось более 20 лет назад с обычных SQL-запросов, как мы осваивали Sphinx и Elasticsearch и как сейчас наш собственный поисковый движок O2 на базе Apache Lucene выдерживает нагрузку в десятки тысяч RPS в сезон распродаж. Исторические хроники восстанавливались по воспоминаниям современников и представлены для полноты картины. Новейшая история описана на основе собственного опыта, поэтому подробностей будет на порядок больше. Поехали!

Мы нечасто задумываемся о том, как работает тот или иной сервис и какой объём работ скрывается за тем, чтобы товар или услуга прибыли к нам вовремя. Взять, например, «чёрную пятницу» и День холостяка в e-com — дни самых больших распродаж. Казалось бы, что там такого? Со стороны может выглядеть, что главное — прогреть аудиторию предложениями разной степени заманчивости и запастись товарами на складах. Конечно, это не так. На деле нескольким дням распродаж предшествует год активной подготовки: от прогнозирования нагрузки и закупки железок до перестройки архитектуры. О том, на что мы обращали внимание и как готовились к высокому сезону, читайте под катом. 

Привет! Меня зовут Саша Свиридов, я руковожу отделом мобильной разработки в Ozon. В моей команде чуть больше 80 человек — это Android- и iOS-разработчики и QA-инженеры. Мы делаем основное приложение Ozon для покупателей. Моя команда состоит из семи кроссфункцинальных групп разработки, каждая из которых отвечает за определенный скоуп задач. Спектр наших задач очень широк: мы разрабатываем чаты на сокетах, работаем с картографией, с потоковым видео, пушами, с аналитикой, со сложным UI. Пожалуй, у нас нет только GameDev:)

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

Чем поделимся на митапе:

— Какие метрики собираются и как мы боремся за перформанс приложения.

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

— Как работает новая модель многопоточности. На примерах разберём, что нового появилось в Swift и как это подружить со своим кодом. 

— Круглый стол, на котором мы обсудим темы, предложенные вами при регистрации на мероприятие.

Подробнее про наш стек и программу — под катом.

Привет всем, кто хочет изменять интерфейс мобильного приложения до выхода нового релиза, всем, кто хочет без лишних доработок на клиенте проводить А/B-тестирование, и всем, кто хочет забыть о срочных «новых пятничных промоакциях», которые нужны уже в понедельник. В этой статье мы поговорим об основах Backend-Driven UI: рассмотрим абстрактно, как всё работает на бэкенде и на клиенте. 

С нарастающими скоростями и распределёнными системами всё сложнее бывает создать приложение удобным для конечного пользователя. Программы обладают кучей фич. Но выполняют ли они то, что нужно юзерам? А скорость их выполнения достаточная? А производительность при выполнении не хромает? На эти вопросы помогает ответить нагрузочное тестирование (НТ).

Меня зовут Саша, я работаю в команде тестирования Ozon Fintech и расскажу про разнообразный спектр вариантов НТ: как именно мы его применяем и какие инструменты используем. Статья будет полезна тем, кто уже что-то слышал про НТ и хочет добавить его в свой проект, но пока страшновато. Давайте разбираться!

Привет, Хабр! Меня зовут Вова, я разрабатываю observability-платформу в Ozon. Как-то раз в наш уголок на 42 этаже заглянули коллеги — и поделились наблюдением. Если открыть рядом графики времён запросов и ответов двух живущих в Kubernetes и общающихся между собой микросервисов, то иногда можно наблюдать большую разницу в высоких квантилях: клиент считает, что один ответ из сотни ему приходит за сто миллисекунд, сервер же говорит, что успевает ответить за десять.

Куда ушло время? Можно ли его вернуть? Под катом расскажу о том, с какими граблями может столкнуться микросервис, живущий в типичной инсталляции Kubernetes.

Традиционного пятничного контента вам в ленту. Меня зовут Соня, я деврел-менеджер команды Ozon Tech. Я помогаю нашим инженерам делиться опытом и создавать комьюнити по профессиональным интересам, организовываю митапы и занимаюсь продвижением опенсорс-проектов.

Ozon Tech как бренд сформировался относительно недавно, хотя за ним стоит команда из 3к+ IT-специалистов. Несколько месяцев назад мы подумали, что было бы круто, если бы у нас появился собственный талисман (он же маскот). Сегодня расскажу, как мы предложили инженерам самим придумать и изобразить его и в процессе убедились, что талантливый человек талантлив во всём.

Выкладываем запись с прошедшего Ozon Tech ML Meetup: были рады поделиться опытом с коллегами из Яндекс Маркета, AliExpress Россия, Циан и увидеть гостей оффлайн, как в старые-добрые времена. 

Под катом найдете запись докладов:

• Spark Streaming: в погоне за оптимальной утилизацией и прозрачностью на Hadoop,

• Го обсудим: продакшен ML на Golang,

• Платформенные решения. Решаем проблемы жизненного цикла ML-сервиса,

• Как мы перестали бояться иероглифов и полюбили китайскую инфраструктуру.

После докладов на круглом столе обсудили процессы и роли в ML-командах крупных IT-компаний.

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

Я разрабатываю сервисы в команде платежей Ozon. Мы много времени уделяем тому, чтобы все транзакции были обработаны корректно, даже если речь идёт о нагрузке в 2к платежей в минуту (именно столько у нас было в пике в период ноябрьских распродаж). Кстати, сейчас, по результатам нагрузочного тестирования, мы выдерживаем 13к платежей в минуту.

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

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

Правильное построение ETL-процессов (преобразования данных) — сложная задача, а при большом объёме обрабатываемых данных неизбежно возникают проблемы с ресурсами. Поэтому нам требуется выискивать новые архитектурные решения, способные обеспечить стабильность расчётов и доступность данных, а при необходимости и масштабируемость — с минимальными усилиями.

Когда я пришел в Ozon, мне пришлось столкнуться с огромным количеством ETL-джоб. Прежде чем применить модель машинного обучения, сырые данные проходят множество этапов обработки. А само применение модели (то, ради чего существует команда) занимает всего 5% времени.

Выкладываем запись с Ozon Tech PostgreSQL Meetup. Ранее я уже описывал нашу инфраструктуру: весь PostgreSQL основан на виртуальных машинах — 2К в тестовой среде и ~8К в проде. Это около 2К кластеров баз данных. Так как у нас микросервисная архитектура, мы придерживаемся принципа 1 сервис = 1 база. Нагрузка на базы может быть приличная: 2-2,5 млн транзакций в секунду, а WAL-трафик порядка 1.5 ГБ/c. 

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

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

Привет, меня зовут Евгений, и я никогда не был программистом — написание кода вызывало у меня чуть ли не смертельную скуку. Конечно, за двадцатилетнюю карьеру приходилось писать скрипты на PowerShell, Python и т. д., но о серьёзной разработке речи не было. Тем не менее моя профессиональная деятельность не ограничивалась системным администрированием. В какой-то момент я познакомился с Microsoft SharePoint — технологией, которая и определила вектор моего развития как IT-специалиста.

SharePoint — это огромный конструктор со множеством деталей, из которых можно собрать практически что угодно — от корпоративного новостного портала до mission critical системы. В нём собраны все необходимые службы и приложения для работы с контентом. Кроме того, SharePoint позволяет создавать несложные сайты с уникальным дизайном и лендинги. А вот что касается автоматизации бизнес-процессов, то тут администраторы быстро понимают, что есть два пути: либо разрабатывать фичи самостоятельно (или обращаться к программистам), либо использовать внешние (по отношению к SharePoint) решения. Я пошёл по второму пути — и в итоге, пришел к no-code/low-code (NC/LC) — решениям, позволяющим создавать приложения практически без использования сложного кода. Это подкупает: можно быстро разрабатывать сложные решения, не прибегая к программированию. Но всё оказалось не так просто, и сегодня я расскажу, почему NС/LC-решения не взлетели в Ozon.

Привет! Меня зовут Антон, я ведущий инженер по тестированию в Ozon: занимаюсь созданием и поддержкой end-to-end Go-тестов бэкенда для QA.

Мы довольно долго писали тесты в основном на Python. Go – молодой язык, и популярных устоявшихся инструментов у него пока немного. В Python есть pytest, в Java – JUnit и TestNG, в Go – пока что весьма свободно. 

Однажды, в очередной раз переписав группу старых Python-тестов, я решил, что надо что-то менять. Эта мысль в итоге привела меня к созданию нашей собственной опенсорс-библиотеки – с поддержкой Allure без перегрузки интерфейса, инфраструктурой для хранения тестов как в одних репозиториях с сервисами, так и в отдельных, репортами в Slack и разными другими штуками.

Почему мы всё-таки решили создать своё решение, с какими сложностями пришлось разбираться в процессе и как это может пригодиться вам для тестов на Go, я расскажу в этой и следующих статьях. Сегодня – об интеграции с Allure. 

Для таргетинга мы в Ozon используем сегменты, в которые группируем пользователей по интересам. Интересы могут быть определены через систему трекинга событий. Последние в свою очередь формируются в процессе взаимодействия пользователя с маркетплейсом Ozon. На основе сегментов мы отправляем нотификации, рассылаем письма, показываем рекомендации, баннеры, страницы с товарами и цены на товары, участвующие в маркетинговых акциях. В принципе, на сегменты можно завязать любую механику. Мы даже А/В тесты иногда проводим с ними.

Первоначально сегменты создавались вручную: поступал запрос от заказчика, после чего проводилась аналитическая работа по сбору требований. Количество заявок на создание сегментов со временем только увеличивалось. Чтобы автоматизировать процесс создания сегментов мы решили сделать конструктор сегментов для DMP — Data Management Platform. Это относительно молодой проект, ему чуть больше двух лет, но он полностью себя оправдал. Сегодня расскажу вам о нашем опыте. Меня зовут Евгений Чмель, и я руковожу командой DMP & CDP.