Выкладываем видео митапа, посвященного продуктам, которые лидируют представители Ozon, Авито, Skyeng.

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

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

В прошлом году я рассказывала, как мы организовали мониторинг Kubernetes CronJob на основе kube-state-metrics, Thanos Receive и Thanos Ruler. За год мы нашли ответ на вопрос, почему же крон может не запускаться. И в этой статье я хочу рассказать об основных причинах и проблемах, о которых мы узнали. 

Спойлер: многие не задумываются о том, как устроен и управляется CronJob.

Привет, Хабр!

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

Много коммитов утекло с того момента, когда мы с вами общались в прошлый раз. Вышло обновление 0.5, которое привнесло множество изменений, в том числе и в интерфейсах, а также обновление 0.6, которое добавило поддержку test plan из TestOps. Более подробно об обновлениях написано в Release Notes.

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

Исторически сложилось, что в Ozon основной объём поддержки осуществляется через чат. В 2020 году бот закрывал 27% от общего числа обращений, а в 2022-м — уже 62%. Это сотни тысяч тикетов в день, при этом качество ответов не ухудшилось. Важность чат-бота выросла в разы.

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

Делимся видео и слайдами с прошедшего митапа, посвящённого автотестированию на Go. Под катом найдёте запись докладов:

— Go, Allure и HTTP, или Как мило тестировать HTTP-сервисы на Go.

— Как подружить QA и разработку через применение практики хранения тестов в коде.

Также обсудили с коллегами из Ozon, Авито, Skyeng и Mirantis тему «Как войти в профессию автотестирования и построить карьерный путь» в формате круглого стола.

Привет всем гоферам! Я пишу на Go уже четыре года — начиная с версии 1.10. Сейчас я занимаюсь разработкой одних из важнейших сервисов в логистике Ozon. 

Не успели мы до конца оправиться от долгожданного релиза Go 1.18 c дженериками, в котором нам предоставили дженерики, как команда Go анонсировала следующий бета-релиз Go 1.19.

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

Навстречу приключениям изменениям!

Привет! Меня зовут Сергей, я старший разработчик в Ozon и раньше вообще не был замечен в QA.

Все мы привыкли к лёгкому написанию тестов на Python и Java — это основные языки автотестировщиков с богатым инструментарием утилит и всего, что упрощает жизнь. Что нужно для написания автотестов для HTTP-сервиса на Python или Java? Гугл, бутылочка крафта и два часа времени. 

А как быть в случае с Go? Как раз на нём мы в большинстве случаев пишем микросервисы. И если тесты написаны на другом языке, разработчики не могут внести в них свой вклад или отревьюить их. Поэтому внутри Ozon активно развивается Go-сообщество QA, и этим ребятам тоже нужно тестировать HTTP-сервисы и проверять отчёты в Allure. Как настоящие сварщики мы подумали: «Если чего-то не хватает, нужно написать своё». Сказано — сделано: встречайте опенсорс-библиотеку CUTE в BDD-стиле, которая облегчает тяготы создания автотестов и упрощает переход на Go. Главные фичи: создание HTTP-тестов, возможность реализовывать проверки из коробки, Allure-отчёты и низкий порог входа. Инструкция — под катом.

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

Привет, Хабр! Я Ани, отвечаю в Ozon Tech за обучение.

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

Контест нам заменяет скрининг — мы проверяем технические навыки и опыт работы будущих участников, так как курсы рассчитаны на мидлов.

Ранее мы публиковали разбор задач по направлениям Go и QA (раз, два), пришло время поделиться задачами для C#, iOS (Swift) и Android (Kotlin, Java).

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

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

Меня зовут Саша, я работаю в команде тестирования Ozon Fintech. В прошлый раз я рассказывала о типах нагрузочного тестирования (НТ) и о том, как создавать пушки под свои нужды. Сегодня же научу запускать НТ по кнопочке в CI. Статья будет полезна тем, кто уже имеет наработки по НТ, но ещё не автоматизировал их или ищет способы запускать тесты не по крону.

Привет! Как и обещали, возвращаемся с записью второго митапа для мобильных разработчиков от Ozon Tech и сообщества Coffee&Code. В анонсе я уже рассказал о нашем стеке, что у нас 150+ мобильных инженеров и подход Backend-Driven UI — повторяться не буду. Вместо тысячи слов — просто посмотрите запись:)

Чтобы поделиться кодом, нужно создать библиотеку и разместить её в самостоятельном репозитории. Но иногда возникает необходимость хранить библиотеку вместе с сервисом, который её использует, — это может быть полезно при разработке в open source, в процессе дробления монолита на микросервисы и при шеринге своим API. Среди Go-разработчиков существует мнение, что экспортируемые библиотеки стоит хранить в директории pkg.

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

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

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

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

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

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

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

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

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

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

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

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