Доклады

В докладе расскажу, как устроена архитектура RAG-системы RUTUBE, которая уже в 80% случаев даёт операторам службы поддержки готовый ответ и снижает время реакции на 10%. Рассмотрим, как мы совмещаем гибридный поиск (BM25 + семантический поиск FRIDA), локальные LLM (Vikhr-Nemo-12B) и интеграцию с системой поддержки. Разберём основные аспекты разработки и внедрения RAG.
- Технические детали: выбор Milvus как векторной БД для масштабируемого поиска, оптимизация эмбеддингов для русскоязычного контента.
- Интеграция в продукт: автоматическое обновление FAQ через Airflow.
- Мониторинг: метрики качества ответов через Kafka → ClickHouse → Grafana, включая KPI на доля ответов «Я не знаю» и другие решения.

В основе работы любого приложения всегда лежит железо. Оно может дать как буст нашему приложению, так и забрать "силы" у него. Но мы настолько привыкли к облачным решениям и Kubernetes (K8s), что уже просто забываем про эту истину.

Мы – Sage в Т-Банке. Мы владеем большим количеством инфраструктуры(серверов), на которое запускаем наши хранилища.

И вот мы получаем партию серверов от нового для нас вендора. И казалось бы, что же могло пойти не так? Мы же уже столько раз разворачивали наши Elasticsearch (ES), но именно в этот раз железо решило преподать нам урок. Наши плановые 2 недели превратились в 6+ месяцев.

Из доклада вы узнаете:
1. Архитектуру современного сервера глазами: процессоры, память, riser и RAID-контроллер
2. Наш опыт запуска ES на новом железе и на какие проблемы с аппаратным обеспечением (hardware) мы наткнулись.
3. Как при этом вел себя ES или сервер, и как мы доказывали что проблема не в приложении, а на уровне железа.
4. Как эти проблемы были решены и какие выводы мы сделали на будущее.

Доклад будет интересен как экспертам, так и начинающим.

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

Блокчейны - медленные и никогда не догонят Web2 сервисы, которые могут себе позволить просто "поверить на слово" доверенному серверу. Для соблюдения требований к безопасности в этих сетях все перепроверяют всех, что создает фундаментальные ограничения на скорость блокчейнов. Несмотря на это, сейчас, в Web3, где количество пользователей постоянно растет, проблемы скорости практически незаметны для обычных пользователей. Как этого удалось добиться?

В этом докладе мы рассмотрим как разные проекты решали проблемы масштабирования. Вертикально: как оптимизировались алгоритмы консенсуса, виртуальные машины и state transition, параллельное исполнение транзакций и ordering. Горизонтально: что такое sharding, L2 решения, optimistic и zk rollups, и какие подходы в них используются. Примерами будут служить реально работающие блокчейны: Ethereum, Solana, TON, Arbitrum, zkSync и многие другие.
Доклад будет полезен тем, кому интересно в каких направлениях развивается техническая мысль в децентрализованных сетях со строгими требованиями к устойчивости, детерминизму и целостности данных.

В распределённых системах 2025 года transaction outbox остаётся ключевым паттерном для атомарной публикации событий. В докладе разберём его архитектуру, проблемы с WAL, replica lag, back-pressure и способы масштабирования. Покажу, как проектировать надёжную публикацию, от индексов и CDC до observability и борьбы с edge-case’ами. Обсудим также, когда outbox — не лучший выбор.

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

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

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

Что делать, если нужна структура данных, которую необходимо менять прямо на проде? А если таких структур тысячи, атрибутов десятки тысяч, и множество из них — связи между объектами? Добавим сюда транзакционность, сложную валидацию, поиск по любым атрибутам среди десятков миллионов объектов.
Мы не понаслышке знакомы с этой ситуацией, ведь мы разрабатываем BPM систему для всех строительных и эксплуатационных процессов мобильной сети МТС. Мы прошли путь от классической EAV-модели к CQRS-архитектуре, сохранив EAV для мастер-данных и метаданных в Postgres, но вынеся чтение и поиск в ClickHouse по денормализованным JSON-объектам. В докладе разберем плюсы и минусы такого подхода, расскажем, как боролись с неконсистентностью, ограничениями JOIN в ClickHouse, масштабируемостью и задержками. Поделимся конкретными практиками и извлеченными уроками, которые помогут вам избежать дорогостоящих ошибок в своих проектах.

При работе Apache Spark промежуточные shuffle-данные по умолчанию хранятся на локальных дисках executor-ов, что связывает их жизненный цикл с конкретными процессами и хостами. Это создаёт уязвимости: сбой или вытеснение executor-а может привести к повторным вычислениям, замедлению работы и росту потребления ресурсов, особенно в долгоживущих и ресурсоёмких приложениях.

В стандартном подходе для повышения надёжности применяется External Shuffle Service, однако он по-прежнему опирается на локальное хранение и требует дополнительной поддержки со стороны инфраструктуры. Мы реализовали альтернативный подход: хранение shuffle-данных в распределённом хранилище YTsaurus. Такой способ повышает надёжность, упрощает квотирование ресурсов, позволяют динамически реконфигурировать кластер, а также открывают возможность применения альтернативного push-based подхода к shuffle-операциям без необходимости изменений со стороны Spark. Реализация полностью прозрачна и может применяться для всех Spark-задач, запускаемых на платформе YTsaurus вне зависимости от типа и объёма нагрузки.

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

Я поделюсь опытом миграции микросервиса с шардированного PostgreSQL на YDB: несмотря на похожесть двух СУБД, YDB далек от состония "drop-in replacement" для PostgreSQL. Коснусь вопросов отличия гарантий, подходов к написанию запросов и эксплуатационных характеристик. Эти особенности стоит учесть заранее, чтобы не столкнуться с ними посреди процесса миграции.

"Миграция контента в KION: как перенести сотни ТБ медиа без downtime"

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

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

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

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

Во всех организациях огромный объем передаваемых данных - это логи и метрики бегущих микросервисов. В Яндексе через YDB Topics каждую секунду пишется около 80 Гб логов.
Как разработчик YDB Topics, я расскажу:
- как в Яндексе устроен процесс обработки такого огромного объема логов
- что такое erasure кодирование и почему оно экономит половину места по сравнению с Kafka
- что такое федерации из кластеров брокеров сообщений: как в нее писать и читать, что произойдет при отказах. На примере Kafka и YDB Topics.
- какие недостатки у федерации из кластеров и в каких случаях она не подойдет
- как воспроизвести такой экономичный способ сбора логов на open-source технологиях и что нужно учесть, чтобы сделать из этого решения платформу

Яндекс Доставка — высоконагруженный сервис, входящий в состав платформы Яндекс Go, который считает 10 000 офферов в секунду (каждый оффер — JSON ~30 кБ). Нам нужно уметь сохранять все эти офферы за 20 мс и гарантировать персистентность данных. В своём докладе я дам выжимку нашего трехлетнего пути:

* Как мы жили с PostgreSQL, какие недостатки не позволяли его масштабировать
* Переход на Redis/Valkey. Почему in-memory хранилище подходит под эту задачу и как мы не потеряли гарантии
* Хранение офферов на клиентах Ya.Go вместо собственной БД. Результаты внедрения, неочевидные сложности

В мире СУБД постоянно меняется абсолютно все. Железо стремительно меняется, диски замещаются NVMe SSD, ядер в процессоре становится больше сотни, появляются новые способы работы с сетью, такие как RDMA. Появляются новые подходы, идеи, алгоритмы. Но еще важнее - все время меняются требования пользователей. В таком динамическом мире требуется или создавать с ноля современные СУБД каждые лет 10 или переписывать с нуля основные ее компоненты. В этом докладе сфокусируемся на двух конкретных компонентах СУБД: движке выполнения запросов и оптимизаторе запросов

Мы расскажем про WebAssembly в SQL-движке для безопасных UDF:
- Рассмотрим SQL UDF, боли и проблемы подхода
- Раскроем преимущества и ограничения технологии WebAssembly
- Посмотрим на эту же технологию в других СУБД
- Расскажем, как приделать WebAssembly к существующему SQL-движку
- Изучим преимущества результата над классическим подходом к UDF
- Расскажем про переиспользование функциональности других СУБД
- Покажем реальные проблемы кросс-компиляции произвольного кода под WebAssembly

Чтобы обеспечить автоматическими субтитрами миллионы часов UGC-контента, нужно не просто точно распознавать речь — требуется промышленная платформа, способная к экстремальному масштабированию. В RUTUBE мы прошли путь от ограниченного MVP на Whisper до высокопроизводительной системы на собственных моделях, которая сейчас обрабатывает новые пользовательские видео почти без задержки.
В докладе раскрою архитектурные решения, позволившие добиться такой пропускной способности: асинхронную обработку задач через Kafka, эффективный инференс моделей с помощью Triton Server, оркестрацию ресурсов через кастомный Speech Worker.
Вы узнаете, как мы:
- Научились без проблем обрабатывать видео любой продолжительности (вплоть до 24+ часов).
- Добились качества автоматических субтитров, сопоставимого с ручными, благодаря борьбе с «галлюцинациями» и NLP-анализу.
- Обеспечили горизонтальное масштабирование под любую нагрузку на видеохостинг.
Опыт будет полезен для ML- и бэкенд-разработчиков, работающих над сервисами обработки больших объемов аудиоданных в реальном времени.

Мы разработали решение, анализирующее структурную целостность около миллиона видеопотоков одновременно.

Это поток в 2 млрд строк в Clickhouse в сутки. Эти данные просматривают люди через Grafana, адаптированную для мультитенатного доступа и роботы, присылающие алерты в системы мониторинга клиентов.

В докладе технические детали:

* Запись в БД с множества версий нашего видеостримера
* Организация стейджинга, тестов и подбор железа под БД
* Чтение из кликхауса: как прикидываться прометеусом
* Связь личного кабинета с графаной, интеграция пользователей и ограничение доступа к данным
* И на сладкое: как всё это развернуть on-prem в редуцированном виде

⁃ Как Яндекс внедряет GPT для автоматизации различных процессов
⁃ Как построить RAG для высоко эффективной автоматизации обращений в службу поддержки
⁃ Какие уроки были извлечены в процессе переосмысления подхода к использованию языковых моделей

Боремся с длительными джоинами Spark датафреймов с геоданными в Apache Sedona (с условием в виде пространственного предиката типа ST_Contains) и побеждаем! Выясняем, почему здесь часто возникает перекос данных (Data Skew) и как его ликвидировать. Пишем инструмент для быстрых Spatial Joins.

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

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

1. Что такое токенизация и зачем она нужна.
2. Особенности оплаты картой в интернете.
3. Чего боятся пользователи при оплате картой.
4. Как оплатить картой без карты (без ввода реквизитов).
5. Снижение нагрузки на сайт магазина.
6. Авторизация платежа.

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

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

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

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

Бонус-трек: как поддержать себя и команду в условиях кризиса.

Полезные опции, важные нюансы для дебага и траблшутинга

У меня есть большой опыт решения инцидентов на нагруженных сервисах. Я часто беру на себя роль инцидент менеджера для разрешения кризисных ситуаций. Хочу поделиться с вами важными практиками для устранения проблем на проде на примере одного моего инцидента.

Эта история связана с DNS, облачной инфраструктурой, и человеческим фактором. На контур приходила очень высокая нагрузка и не все наши шаги для починки были верными. Инструменты не показывали проблему. Я сгорел во время этого инцидента и больно было не только моим пользователям.

Хочу рассказать про:
* Важность фиксации истории релизов и ведения внутренних чендждлогов
* Как правильно выкатывать опасные изменения (метрики) и почему это процесс а не разовая акция
* Что делать если откат не работает и нет инструментов для починки
* Ведение лога разбора инцидента и фиксация промежуточных действий
* Проверка масштабирования наживую и инструменты собранные на коленке
* Как правильно работать с горящими пользователя и тревожным руководством
* Почему стоит смотреть на проблему с других сторон и как не зашорить взгляд
* Как правильно строить процессы разработки и почему эти правила написаны кровью
* Почему важно иметь обратную связь от экспертных пользователей и реагировать на их проблемы

В нашей системе аналитики события проходят путь от шины данных через сервис сбора событий, попадают в Kafka, а затем — в ClickHouse с помощью Kafka-Engine. В архитектуре — три кластера ClickHouse (main, replica, sandbox) с настроенной репликацией, каждый из которых обслуживает свою зону ответственности: сбор, BI, пользовательские запросы.

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

— Как устроен наш стриминговый пайплайн: от шины данных до ClickHouse
— Как сервис сбора событий справляется с миллиардами событий
— Какие тесты проводили:
— 9 млрд событий в сутки
— 15 млрд событий в сутки
— 24 млрд событий в сутки — предел, к которому стремились
— Внезапный скачок нагрузки х2
— Сбой кластера ClickHouse и как он проявился
— Сбой Kafka и поведение пайплайна
— Запись всех событий в один проект вместо 50+ — и к чему это привело
— Kafka-Engine vs Kafka-Connect — замеры, сравнение, выбор
— Как организовали мониторинг и метрики, на что смотрели в Grafana и ClickHouse.
— Какие баги, затыки и инсайты мы получили, и как это повлияло на прод

Доклад будет интересен всем, кто работает с ClickHouse под высокой нагрузкой, собирает real-time данные, использует Kafka и хочет понять, где тонко и как не порвать.

Мастер класс посвящён практическим инструментам диагностики .NET-приложений: от поиска утечек памяти до оптимизации производительности многопоточных сценариев. Будут разобраны dotnet-trace, dotnet-dump, ClrMD, dotnet-monitor и их применение на реальных кейсах с демонстрацией кода и анализом дампов. Особое внимание уделяется автоматизации сбора дампов в Kubernetes. Материал будет полезен .NET-разработчикам, тестировщикам и DevOps-инженерам, заинтересованным в быстром поиске и устранении проблем производительности.

– Готовое решение "из коробки", DIY построение сценариев цифровизации для пользователей любого уровня ИТ подготовки.
– Унификация сбора данных: как мы реализовали подключение IoT устройств на разных протоколах (MQTT, Modbus, OPC-UA, TCP, GoodWAN, LoRaWAN, NB-IoT).
– DSL скрипты и No-code workflow для настройки пользовательских сценариев. Объединение всех объектов платформы и создание бизнес-процессов.
– Кросс-платформенные интерфейсы: web, IOS, Android

Все слышали про Transactional Outbox, но до сих пор нет библиотеки, которая реализует его единственно правильно. В докладе я покажу разные реализации Outbox, расскажу какие у них достоинства и недостатки, как выбрать реализацию под свою задачу. А также как использовать возможности PostgreSQL при реализации Outbox.

15 ноября 1996 миру был представлен ICQ - пионер сервисов мгновенного обмена сообщениями и некогда самый популярный IM. 26 июня 2024 года компания VK, на тот момент владеющая проектом, прекратила работу мессенджера.
Конец.
На самом деле всё гораздо интереснее. В 2019 году был представлен корпоративный мессенжер VK Teams, который фактически является... коробочной версией ICQ. Почему так вышло? Потому что проект актуальный. За годы существования, ICQ оброс множеством фичей - от тредов в сообщениях, до групповых видеоконференций, а учитывая изначальную ориентацию на поддержку высоких нагрузок, миллионов пользователей и отлаженную годами стабильность, он громко заявил о себе на рынке закрытых корпоративных onpremise-инсталляций в нашу непростую эпоху сплинтернета и разочарования в облаках.
Мне посчастливилось присоединиться к разработке коробочного решения этой без сомнения легендарной системы.
Но что такое проект, развивающийся с 1996 года? Давайте заглянем под капот аськи, оценим архитектуру, окунёмся в историю, сформулируем проблемы и вызовы и поговорим о путях развития.

Любая компания стремиться расти и развиваться. Рост может быть обусловлен выходом на новые рынки, увеличением охвата, открытием новых направлений.
Каждый рост компании сопровождается ростом внутреннего ИТ, а кроме роста есть внутренние вызовы - повсеместное внедрение AI, DPI, общих средств внутри компании, замена ролей на ИИ-помощники, код-ревью, создание артефактов с помощью ИИ. Постараемся ответить на вопрос благо это или нет, как такие средства могут помочь, а где могут повредить и помешать.
Обсудим, что делать в такой ситуации руководителю, куда смотреть, как развивать свои legacy проекты, чтобы не было мучительно больно и не превратить отлаженный механизм монолита в неуправляемый хаос микросервисов. Разберем топологии команд, изменились ли подходы за последние 10 лет при переходе к платформенным решениям и помогло ли это развитию devops-практик.