Всё больше Java-разработчиков переходят от приложений, использующих синхронный стек, к реактивным решениям на базе Spring WebFlux и Kotlin Coroutines. Такой переход позволяет строить более масштабируемые и устойчивые к высокой нагрузке системы, эффективно используя пул потоков и асинхронное выполнение задач. Однако вместе с преимуществами реактивного подхода появляется и новая неочевидная проблема — потеря MDC-контекста (Mapped Diagnostic Context), который традиционно используется для сквозной трассировки запросов в логах.

Привет! Меня зовут Андрей Романюк, я руковожу группой качества WEB в онлайн-кинотеатре Okko. В этой статье я расскажу о процессе, с помощью которого мы снизили количество багов, которые мы выкатываем в прод, когда мы о них уже знаем.(Естественно, мы всё равно их выкатываем, но таких багов в релизах стало намного меньше :) 

О чём поговорим:

Привет, Хабр. Меня зовут Лёша Круглик, я занимаюсь коммерческой разработкой около 7 лет. Писал код для Epam, Альфа Банка и Яндекса, а последние года три занимаюсь разработкой в Okko.

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

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

Привет, Хабр! Сегодня поговорим про инфраструктуру как код. Почему Terraform уже не единственный игрок в мире IaC, а Pulumi становится всё более актуальным. Я расскажу, как эти инструменты работают, чем отличаются, и почему стоит присмотреться к Pulumi, особенно, если вы хотите гибкости и мощи в управлении облаками.

Как сделать ретроспективу полезной и интересной

Привет! Меня зовут Настя, я работаю проектным менеджером и скрам-мастером в онлайн-кинотеатре Okko. За последний год я провела более 100 ретроспектив в разных командах. Не все из них были удачными.

5k RPS, 5ms Latency и 100 экспериментов одновременно. История о том, как наша команда перестраивала веб-сервис для сплитования трафика в высокопроизводительную систему. С какими ограничениями Cpython и Gil столкнулись на пути, как обходили "узкие места" и оптимизировали сервис до микросекунд. В общем, всё о том, как мы построили "космолет" на Python и взлетели! Ну и, конечно же, ответ на вопрос: "Почему не Go? ".

Работа с Playwright всегда доставляет мне удовольствие. «Наиграв» уже десятки, если не сотни часов в библиотеке, решая проблемы, копаясь в исходниках или на просторах сети, я практически всегда находил удачное решение. И это я списываю не столько на свой опыт, сколько на удобство самой библиотеки. Чаще всего удачные решения находились уже в коробке. А то, что приходилось допиливать руками, всегда сопровождалось ощущением игры и веселья – настолько приятно и легко работать с этим инструментом. Вот уже год, как наши тесты работают стабильно без каких-либо значимых изменений. Сегодня я расскажу вам о скриншотных тестах, реализованных на основе Playwright и Storybook.

Как именно работают механизмы, которые позволяют LLM так эффективно взаимодействовать с контекстом? Принято рассматривать нейронные сети как black-box, не разбираясь, что на самом деле происходит во время их инференса. Однако можно немного заглянуть «в мозги» нейронным сетям и попытаться понять, за что отвечают те или иные группы параметров модели.

Меня зовут Михаил Коновалов, я работаю ML-инженером в Okko. В этой статье я хочу рассмотреть несколько публикаций, посвященных интерпретации механизма Attention в трансформерах.

Superset не самый новый bi-инструмент, но его популярность продолжает расти. На мой взгляд, он достаточно прост в освоении, но все же требует некоторых усилий и времени, чтобы разобраться куда тыкать, чтобы загрузить данные и нарисовать красивый отчет. Лично я за свою карьеру в IT уже второй раз сталкиваюсь с необходимостью переезда на этот инструмент. Он снова новый для компании и многие сотрудники с ним раньше не работали. Поэтому я и решила написать статью-шпаргалку, которая поможет в несколько кликов создать работающий дашборд и всегда будет под рукой.

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

Okko – один из крупнейших онлайн-кинотеатров в России c нагрузкой в несколько тысяч запросов в секунду, в котором персональные рекомендации занимают важное место. Для улучшения пользовательского опыта нужно не только предоставить качественные рекомендации, но и обеспечить быстрый доступ к ним.

В этой статье мы поделимся:

1. Описанием, как мы использовали инструменты Jaeger и Grafana для выявления узких мест в производительности, что привело к выявлению критических проблем со сборщиком мусора;

2. Анализом влияния различных настроек сборщика мусора на время ответа, что позволило сократить его вдвое для 99% запросов;

3. Когда и почему стоит рассматривать изменение стандартных настроек сборщика мусора (на примере нашего случая).

Планируете внедрить или уже используете Appium-тесты для Android и задумываетесь о многопоточности? У нас есть для вас полный гайд, как реализовать это с помощью Selenoid – предварительно немного взбодрив образы для поддержки последних версий Android, и при этом сделав тестовую инфраструктуру стабильной, как молоток.

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

Данный материал может быть полезен тем, кто только начинает разрабатывать аналогичные системы, и, возможно, сомневается в полезности кроссмодальных факторов в текстовом поиске. 

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

Меня зовут Петр. Я работаю инженером по данным в Okko и обожаю ClickHouse. 

Примерно в середине прошлого года мы начали переезжать с PostgreSQL на ClickHouse. Одной из главных причин переезда была низкая производительность: среднее время аналитического запроса составляло около минуты. Сейчас, после переезда, среднее время запроса в аналитическом кластере — около 2 с. И это не предел.

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

Статья в основном для тех, кто только начинает свой путь работы с кликхаусом: мы посмотрим, как делать не надо, и как можно сделать лучше.

В этой статье не будет объяснений почему для переезда мы выбрали именно этот инструмент. Не будет и глубокой теории о его внутреннем устройстве. Отметим лишь: в правильных руках ClickHouse — одна из самых быстрых колоночных СУБД для OLAP запросов.

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

Меня зовут Максим Шевченко и последние два года я занимаюсь развитием платформы экспериментов в Okko, одном из ведущих онлайн-кинотеатров в России. Наша команда разрабатывает инструменты, которые позволяют продуктовым командам самостоятельно проводить А/В тесты и анализировать их результаты. Мы отвечаем за весь цикл экспериментов – от помощи в дизайне и выдаче пользователям разного опыта до предоставления рекомендаций по принятию решений.

Когда речь заходит об А/В-тестах, первыми в голову приходят статистические методы: различные параметрические или непараметрические критерии и многое другое. Но если взглянуть шире, становится понятно, что статистика – лишь часть экспериментов. Довольно важная часть, но не единственная. В контролируемых онлайн-экспериментах также важны сплитование трафика, удобное управление изменениями пользовательского опыта, обработка данных, дашборды, система мониторинга и многое другое.

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

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

В прошлой статье мы начали историю создания одного из компонентов платформы экспериментов в компании Okko — сервис сплитования трафика.

Там были описаны небольшие, но эффективные оптимизации Python-кода, которые могут быть полезны в практически любом сервисе на этом языке.

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

Привет, Хабр, на связи Okko! У нас одна из самых больших медиатек в России, поэтому мы постоянно работаем над развитием алгоритмов поиска и рекомендаций. Новые фичи тестируются с помощью А/Б тестов. Количество фичей неустанно растет, поэтому было решено создать специальную платформу для проведения экспериментов. Она позволила бы удобно их заводить и настраивать, сплитовать трафик в онлайн-режиме и формировать результаты экспериментов.
Мы — команда разработки платформы экспериментов — посвятим цикл рассказов самому важному и сложному компоненту сервиса — сплитовалке трафика. В этой статье расскажем о небольших по сложности, но больших по значению оптимизациях в коде, которые мы сделали, чтобы разогнать нашу платформу до скорости ракеты 🚀

Привет! Меня зовут Алексей Карпов, я DevOps-инженер (MLOps) отдела ML разработки в OKKO. Хочу поделиться опытом в работе с Apache Airflow в связке с Kubernetes. Расскажу, как установить Airflow в Kubernetes, настроить автоматическую синхронизацию DAG'ов с удалённым репозиторием, а также как отладить его работу. Всё это — на примере запуска простейшего DAGа. 

Всем привет!

В этой статье я бы хотел поделиться инструментом, который мы в Okko используем для UI-автотестов для клиентских приложений платформы Android. 

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

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

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

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

Реализация динамических типов на GraphQL выглядит довольно естественно. Однако, есть определенные сложности.