Доклады

За последний год в Яндекс-Поиске прошли три крупных релиза генеративных ответов: SearchGPT (генеративные ответы в поиске), Нейро и Поиск с Алисой.

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

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

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

Разработка планировщика движения для автономных транспортных средств — это одна из самых амбициозных и комплексных задач на пересечении современных технологий. В нашей работе мы применяем передовые методы машинного обучения и анализируем большие объёмы данных. Каждый день мы сталкиваемся с множеством сложнейших технических вызовов самого разного характера: от организации эффективного сбора данных до оптимизации инференса моделей и снижения нагрузки на CPU.

Расскажу, как мы создаем ML-планировщик:
1) Почему вообще хотим заменить алгоритмическое решение на решение на базе трансформеров
2) Как собираем данные с помощью джойстиков и как очищаем их для обучения
3) Как запускаем модель на ограниченных бортовых ресурсах робота
4) Что мы видим в closed-loop симуляторе, а что в нем не можем увидеть
5) Как это уже работает на реальном роботе, и что планируем дальше.

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


Расскажу, как мы пришли от кастомных автоматик под каждый проект разметки к настраиваемой автоматике на платформе. Как устроена архитектура микросервисов и данных, мониторинги, контроль нагрузки. Полезно будет всем, кто стремится настроить регулярные авторазметки на генеративных моделях и экспериментирует с LLM-as-a-judge.

Расскажу, как мы в RUTUBE сократили время ответа поддержки в 2 раза, автоматизировав 80% запросов. Покажу конкретные цифры: было 40+ тематик поддержки, тысячи запросов в день, постоянно растущая база знаний — стало автоматическое решение, которое работает 24/7 и всегда обладает актуальной информацией. Если вы думаете о внедрении RAG или уже обожглись на первой попытке — этот доклад для вас.

Что разберём:
- Рабочую архитектуру RAG-системы, обрабатывающей тысячи запросов в день
- Конкретные метрики для оценки качества (спойлер: accuracy — не главное)
- Почему наивный RAG провалился и как мы пришли к гибридному поиску (BM25 + FRIDA)
- Сравнительные таблицы: Milvus vs альтернативы
- Реальные метрики качества: как мы снизили долю "Я не знаю" с 40% до 15%
- Антипаттерны: почему 90% RAG-проектов умирают (спойлер: дело не в LLM)

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

Мы расскажем о том, как делать инференс гигантских Mixture-of-Experts моделей. Разберем на практике, как построить и масштабировать гетерогенный кластер, в котором правильная архитектура сети и памяти становится важнее "голых" петафлопс.

Мы в компании активно внедряем LLM-агентов в свою работу и продукты, которые разрабатываем для наших клиентов. Имеем уже коммерческий опыт в создании виртуальных помощников на базе ИИ разных провайдеров — он облачных гигантов (OpenAI, Anthorpic, Сбер) до локальных моделей, запущенных на домашней видеокарте RTX 3060.

В докладе раскрою следующие темы:
* Что такое вообще MCP-сервера и как с ними работать;
* Какие есть MCP-клиенты и как их использовать;
* Способы реализации агентов: CLI, Telegram-бот, Голосовой ассистент;
* Какие модели и какие провайдеры лучше подходят под какие задачи;
* Реальные примеры решения задач нашей команды разработки;
* Какие ресурсы нужны для запуска модели здесь и сейчас небольшой команде разработчиков;

В докладе расскажу все, что нужно знать для разработки своих ИИ-агентов — как лично для себя, так и для бизнеса.

Никакого вайб-кодинга и "ИИ заменит программистов". Я сторонник мысли, что работы нам только прибавится благодаря подобным возможностям, предоставляемыми ИИ.

- Разобраться в ролях планировщика, инструментов, памяти, контекста и RAG.
- Обзор свежих фреймворков 2025 г.  LangChain 0.2, Microsoft AutoGen, CrewAI и их проблемы.
- Научиться собирать работающие цепочки и многоагентные ансамбли.
- Понять, как измерять качество, ставить guardrails и мониторить.

Практический воркшоп будет состоять из 2х частей:
Первая часть. Твой первый опыт с моделью, как не облажаться и довести её до прода. Быстрый способ тестировать бизнес гипотезы. Напишем готовую обвязку для модели.
Вторая часть. В воркшопе я хочу рассказать и показать как выбрать оптимальный подход (no-code/code-first) и правильные инструменты для создания агентов под задачу, поделиться практическим кейсом быстрого запуска агента в условиях ограниченных ресурсов и неопределенности.

В СБЕРе стартовала масштабная трансформация связанная с внедрением GenAI. Её основная цель: автономизировать бизнес-процессы (там, где это возможно) и максимально освободить сотрудников от рутинных задач.
Доклад раскрывает следующие темы:
• Сложности при внедрении GenAI в enterprise (Обсудим как AI-агентов к банковским системам без негативных последствий)
• Управление специфичными рисками (Обсудим роль требований в создании надёжных решений)
• Кейсы: что необходимо предусмотреть, чтобы снизить влияние на пользователей, в случае сбоев/галлюцинаций AI-агентов
Доклад будет интересен руководителям/владельцев продуктов, перед которыми стоит задача внедрить GenAI решения в существующий ИТ-ландшафт

Мастер-класс по созданию AI-агента и многоагентного взаимодействия (агент+критик):

К концу МК у каждого будет:
✅ Понимание архитектуры и паттернов современных агентов
✅ Рабочий агент прикладной задачи с инструментами, памятью и контекстом
✅ Прототип мультиагентного взаимодействия через MCP

Важно - для участия требуется наличие ноутбука!

Как часто мы смотрим на фактическую работу приложения при отказе т.н. "точки правды" в виде той же базы данных? А как часто мы устраиваем физические "учения" по отказу одного из цодов?

В этом воркшопе мы возьмём кластер БД (PG), построенный по общепринятым практикам, который позволяет пережить отказ минимум одного ЦОДа, и попробуем поломать его, устроим хитрые кейсы (выдернем физически питание и сеть из сервера, устроим задержки по сети), изучим реакцию на наши издевательства и наконец потрогаем базовый managed DBaaS своими руками изнутри (на базе Patroni).

Бонус - ЦОДы будут имитировать реальные физические серверы, приходите "дёрнуть рубильник"!

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

Что такое финансовый фрод и зачем с ним бороться?
Чем chargeback отличается от refund, и что такое friendly fraud?
Какие бывают кейсы финансовых потер и недополученной прибыли и как их избежать?
Как AML, Compliance и Disputes стали частью современной риск системы.
Ну и самое главное, какой же должна быть архитектура, что бы все это потянуть...

Стартап — это постоянный цикл проверки гипотез. Чем быстрее и дешевле вы тестируете свои предположения, тем выше шансы на успех. Облака обеспечивают гибкость и масштабируемость, что идеально подходит для начальных этапов: пет-проектов, PoC и MVP.

Однако когда стартап выходит на рынок, набирает пользователей и начинает работать с большими объемами данных (документы, фото, видео и т. п.), расходы на облачную инфраструктуру могут сравняться с фондом оплаты труда всей команды. В этот момент стоит задуматься о переходе на собственное оборудование.

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

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

В докладе рассматривается устройство систем предотвращения утечек конфиденциальной информации (Data Leak Prevention, DLP — на примере DLP Solar Dozor). Рассматриваются ключевые элементы архитектуры и потенциальные причины возникновения избыточной нагрузки. Даются советы как избежать проблем с производительностью.

1) Зачем нам нужен ещё один фреймворк?
2) Происхождение фреймворка EA on a Page
3) Отличительные черты фреймворка
4) Ключевые компоненты фреймворка и их смысл
5) Использование фреймворка на практике

Как мы в ЕДИНОМ ЦУПИС развивали архитектуру проекта, чтобы сохранить SLA 99.99 при активном росте проекта и нагрузки.
Покажу ключевые изменения, а также то, что нас к ним подтолкнуло, какие подводные камни мы обошли и с какими сложностями пришлось столкнуться.

Представьте: ваш облачный трафик — это нервная система. Каждый пакет — как импульс, который нужно контролировать. К нам в K2 Cloud обращались клиенты и ИБ-партнёры с запросами на сервис зеркалирования трафика — технологию копирования сетевого трафика для анализа и мониторинга, которая позволяет распознавать сетевые атаки и проводить анализ защищённости инфраструктуры.

Мы рассмотрели реализацию этого сервиса на уровне нашей SDN-платформы — OVN. На неё мы перешли несколько лет назад, чтобы получить свободу в разработке и уйти от ограничений проприетарных решений. Хотя технология в OVN была, её пришлось дорабатывать под условия облачной инфраструктуры.

Открытость OVN сыграла нам на руку — мы не просто адаптировали функциональность, а полностью переработали её, и теперь наши улучшения доступны в апстриме OVN.

Дополнительным стимулом к реализации стало желание стать первым российским облаком с готовым решением Traffic Mirroring — и нам это удалось.

В докладе я расскажу, как мы реализовали этот механизм в нашей SDN-платформе на базе OVN и интегрировали его с NTA-решениями.

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

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

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

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

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

Как построить Kafka as a Service в Kubernetes, чтобы пользователи работали с ним, а не избегали его?

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

Поделимся:
- как выглядела наша первая архитектура Kafka, и почему мы отказались от неё;
- каким образом трансформировали архитектурное решение, чтобы минимизировать затраты на сопровождение;
- как через декларативный подход автоматизировали развёртывание кластеров Kafka в Kubernetes;
- как мы упростили пользователям авторизацию на Kafka, спойлер: сделали middleware с влезанием в протокол обмена;
- как настроили тарификацию под запросы пользователей PaaS-платформы.

Сделаем сравнительный анализ различных архитектур Kafka as a Service и подведем итог, чтобы вы могли определить свой путь.

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

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

Три попытки, три архитектуры:
• RAG v1.0: Быстрый старт за неделю → провал в проде. Система не могла связать симптом из одного документа с протоколом лечения из другого
• GraphRAG: Качество ответов взлетело → бюджет тоже. $6-7 за индексацию одной карточки, тысячи долларов на весь корпус медицинских статей
• LightRAG: Оптимальный баланс. Сохранили преимущества графов, снизили затраты в 10 раз

Что разберем детально:
- Архитектура LightRAG: инкрементальная индексация, дедупликация сущностей, двухуровневый поиск
- Реальные расчеты стоимости для каждого подхода с конкретными цифрами
- Специфика MedTech: работа с регуляторами (HIPAA, GDPR), цитируемость источников
Сравнительная таблица: когда какой подход выбирать

Практическая ценность:
Готовый фреймворк выбора RAG-архитектуры + экономическое обоснование для защиты решения перед бизнесом.

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

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

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

В докладе расскажу, как мы трансформируем подход к инфраструктуре: перестраиваем процессы, команды, роли и инженерную культуру. Почему отказались от «DevOps как набора тулов» в пользу продуктового мышления в CoreTech. Как мы превращаем инфраструктурные компоненты в управляемые ресурсы, а SRE-инженеров — в разработчиков платформы и её же клиентов.

Доклад - попытка ответить на следующие вопросы:
- Как эволюционируют системы управления инфраструктурой?
- Инфраструктурная платформа для одного продукта? Серьезно?
- Как масштабирование меняет оргструктуру, процессы и образ мышления?
- Как освоить инфраструктуру из сотен, тысяч и десятков тысяч хостов?
- Почему k8s - нечто большее, чем поды, деплойменты и сервисы?
- Как технически и процессно устроена инфраструктурная платформа в Sage?

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

После того, как мы переехали с VMware NSX-MH на opensource SDN решение OVN, облачные сети у нас были устроены так: OVN нам давал L2-изоляцию между облачными подсетями, firewall на портах ВМ (security groups + port security), DHCP и возможность подключения внешних инфраструктур клиентов выделенными соединениями через HW VTEP (L2 Gateway).
Остальные сетевые сервисы облака продолжали, как и раньше, работать на сетевых нодах в LXC-контейнерах, которые запускались для каждого VPC в зоне доступности. DNS, межсетевой FW, VPNaaS — все эти сервисы, и, самое главное, взаимодействие между разными сетями (в том числе в разных зонах доступности), разными сегментами - Интернет, VPN, осуществлялось внутри LXC-контейнеров стандартными средствами Linux.
Такое решение имело ряд недостатков, которые с внедрением OVN мы собирались устранить:
- SPOF в L3-сервисах (маршрутизация, NAT);
- сетевая нода и сам LXC с veth - bottleneck в плане производительности;
- В LXC NAT был реализован при помощи iptables, поэтому использовал conntrack - это лишние накладные расходы;
- "маленький LXC, но большой домен отказа" - все сетевые функции VPC в зоне доступности.
Мой рассказ будет о том, как мы планировали улучить сетевые сервисы в К2 Облаке и какой ценой этого достигли.

Разберем известный антипаттерн очередей на PostgreSQL. Поймем можно ли сделать рабочими такие очереди под большой нагрузкой, если очень хочется. А так же почему в Яндекс Диске для некоторых нагруженных сценариев используем именно такой подход, а не классические очереди

Какими принципами надо руководствоваться, чтобы создать систему, где скорость задержки - микросекунды, а количество заявок - десятки и сотни тысяч. Что такое Performance-Driven Development (PDD), и почему без него такую систему не создать. Какие практические подходы надо использовать.

Рассмотрим актуальные скорости трафика и методы их съема. Узнаем, почему 400Gbps - сегодняшняя реальность. Погрузимся в теорию программного съема и на практических примерах компании «Гарда» разберем, как достигли 400Gbps. Главный фокус – на неочевидных оптимизациях схемы и кода, давших прорыв в производительности, а также вывод - решение есть почти всегда, надо стараться найти.

Когда ваш сервис обрабатывает сотни тысяч транзакций в секунду, потеря даже одного события может стоить бизнесу миллионы. Transaction Outbox кажется простым паттерном, пока не начинает ломаться под реальной нагрузкой: WAL переполняется, реплики отстают на часы, а CDC-коннекторы падают от back-pressure.

Я помогаю масштабировать событийную архитектуру от тысяч до сотен тысяч событий в секунду. В докладе поделюсь болезненными уроками: как сделать outbox под 100k+ событий/сек, оптимизация WAL.

Вы узнаете конкретные техники оптимизации: от zero-copy публикации до асинхронного чтения с реплик. Разберём архитектурные решения для горизонтального масштабирования и построения observability, которая действительно поможет в 3 утра при инциденте.

И главное — обсудим честно, когда Outbox становится антипаттерном и пора переходить к другим решениям.

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

В докладе поделюсь практическим опытом решения задач real-time аналитики в условиях:
- Миллионы/миллиарды записей, распределенных по десяткам сервисов в большом B2B-продукте
- Требование отклика в сотни миллисекунд
- Постоянные изменения данных, включая обновления "задним числом"

Что вы узнаете:
- Архитектурные паттерны для быстрой фильтрации и агрегации в распределенной системе
- Концепция обновляемой Read-Only реплики: подводные камни и решения (холодный старт, гонки, скорость обновлений)
- Предагрегаты на PostgreSQL и ClickHouse: когда колоночных БД недостаточно
- Техники обработки исторических изменений без полного пересчета
- Путь от ad-hoc решений к платформизации


Для кого доклад:
Архитекторы, разработчики и техлиды, работающие с высоконагруженными системами и аналитикой в real-time.


Практическая ценность:
В конце доклада получите готовый cheatsheet с проверенными решениями для типовых задач real-time аналитики.

Когда у вас 2.2 млн DAU, 500k+ ресторанов и жесткие требования по latency, готовые решения перестают работать. Расскажу, как мы за один квартал построили рекламный движок, который:

Обрабатывает >600 RPS с 99 перцентилем <50ms на кандидатогенерации
Работает по CPA-модели (Cost Per Action) вместо классического CPC
Упростил путь рекламодателя с 5 шагов до 3
Технические детали, которые разберем:
• Кандидатогенерация за 50ms: сравнение геоиндексов (R-tree vs H3 Uber vs Geohash) на реальных данных
• ML в продакшене: как предсказываем вероятность заказа и потенциальную выручку в real-time
• Аукционы VCG vs GSP: почему провели сотни offline-симуляций перед выбором конфигурации
• Архитектура: C++ микросервис для аукциона, обработка событий, проклейка конверсий с TTL 48 часов
• Борьба с каннибализацией: механизмы амнистирования ставок и organic_tolerance

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

Доклад посвящён реальному опыту масштабирования GitLab от маленького контейнера до крупного распределённого решения в трёх датацентрах с нагрузкой 4000 запросов в секунду. Мы подробно рассмотрим ограничения, с которыми столкнулись при росте нагрузки и пользователей, и конкретные шаги по решению этих проблем:
• Почему Docker-контейнер стал узким местом и как мы решили эту проблему.
• Причины перехода на различные редакции GitLab (от CE до собственной редакции): какие преимущества получили и когда стоит переходить на новую редакцию.
• Проблемы производительности, когда SSH перестал успевать проверять ключи, и как это исправили.
• Оптимизация хранения и бекапов, включая миграцию на S3 и смену подхода к резервному копированию.
• Отделение очередей и GitLab в отдельные сервисы для повышения стабильности.
• Почему и как мы мигрировали на Kubernetes-кластер.
• Масштабирование GitLab VCS и внедрение балансировки для отказоустойчивости.
• Переход на In-memory(redis/valkey) базы данных и разделение нагрузки на несколько кластеров.
После доклада слушатели смогут лучше понять, как последовательно и эффективно масштабировать GitLab и аналогичные сервисы, избегать распространённых ошибок и заранее подготовиться к техническим ограничениям инфраструктуры.

Если вы пишете Kubernetes-операторы, то наверняка сталкивались с такими вопросами:

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

Особенно остро эти вопросы встают, когда вы разрабатываете не один оператор, а PaaS-платформу, архитектура которой построена на каскаде операторов. Этот подход мы используем в PaaS App.Farm.

В этом докладе мы поделимся своим опытом реализации простого и надежного механизма garbage-collection, который решает все поставленные выше вопросы, НО противоречит рекомендациям в документации Kubernetes.

Все, кто, как и мы, «не читали» документацию Kubernetes, welcome!

Я расскажу о том, как применять ML в кэшировании, какие проблемы и выгоды несет такой подход и почему эвристических методов хватит всем

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

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

В инженерной работе есть как успехи, так и провалы. Причем о последних не очень любят рассказывать. Тем не менее рассказы о провалах поучительны, они позволяют другим учиться на чужих ошибках. Одной из основных фич Tarantool 1.7 была поддержка дискового движка, который назвали винил. Планировали до конца 2016 года тщательно протестировать и стабилизировать функциональность движка, но по разным причинам сделать этого не получилось, а вместо стабильности до последнего времени это был один из компонентов Tarantool, который был сложен в эксплуатации, который крешился под нагрузкой и который тяжело было поддерживать. Сейчас, когда от большинства проблем получилось избавиться, можно ретроспективно взглянуть на историю появления дискового движка, осмыслить причины сложности разработки, эксплуатации и поддержки. Я расскажу историю дискового движка в Tarantool с организационной и инженерной точек зрения, расскажу как мы решали проблемы с винилом и реанимировали его репутацию среди пользователей.

Когда в компании объемы данных постоянно растут, в какой-то момент в них становится довольно сложно ориентироваться, и не утонуть в этом болоте помогает Каталог Данных. У нас уже было проприетарное решение, но, к сожалению, из-за всем известных событий возникли проблемы с лицензиями и ему пришлось искать альтернативу.
В своем докладе я поделюсь опытом поиска и внедрения нового каталога данных в МТС BigData, как мы выбирали решение и пришли к opensource и как нам пришлось сидеть на двух стульях(зачеркнуто) каталогах в процессе миграции.
Так же расскажу каким образом мы извлекаем метаданные с кластеров размером десятки петабайт незаметно для самих кластеров, с какими проблемами столкнулись на пути к данному решению и на какие trade-off при этом пришлось пойти.

При работе 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. Коснусь вопросов отличия гарантий, подходов к написанию запросов и эксплуатационных характеристик. Эти особенности стоит учесть заранее, чтобы не столкнуться с ними посреди процесса миграции.

Разрабатывая собственную файловую систему, мы столкнулись с проблемой: как эффективно и быстро реализовать механизм снапшотов для защиты данных? Для хранения метаданных файловой системы мы используем RocksDB, популярную реализацию LSM-дерева на диске, которая будто бы идеальна для этой задачи — но на пути оказались скрытые рифы, неочевидные из документации.

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

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

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

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

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

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

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

Механизм репликации используется для обеспечения отказоустойчивости в базах данных.
Популярная разновидность -- master-slave репликация -- требует, чтобы среди нескольких узлов с одинаковыми данными был выбран главный (master), который будет доступен не только для чтения, но и для записи.
В случае его отказа необходимо выбрать нового главного среди оставшихся чтобы сохранить возможность писать данные.
Это можно делать вручную при сбое, но алгоритмы консенсуса, например RAFT и Paxos, позволяют произвести переключение автоматически.
Проблема в том, что такие алгоритмы требуют наличия минимум трёх зон доступности, а платить за них может быть накладно.
Попробуем разобраться, какие есть способы ограничиться двумя дата-центрами и при этом обеспечивать автоматическое переключение в момент сбоя.
Рассмотрим возможные трансформации алгоритма RAFT для сценария с данными в двух зонах доступности.
Предложим несколько вариантов с внешним кворумным хранилищем и с отдельным сервисом-координатором.

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

Яндекс Доставка — высоконагруженный сервис, считающий 10 000 офферов в секунду (каждый оффер — JSON ~30 КБ). Нам нужно укладываться в 20 мс на сохранение и при этом сохранять персистентность данных. В своём докладе я дам выжимку нашего трехлетнего пути:
• PostgreSQL под write-heavy и TTL: с какими ограничениями мы столкнулись и почему масштабирование упирается в архитектуру базы.
• Переход к Redis/Valkey: почему in-memory хранилище подходит под эту задачу и как мы не потеряли гарантии.
• Хранение офферов на клиентах Ya.Go вместо собственной БД: когда это оправдано, какие подводные камни и что важно учесть при внедрении.

Использование Raft-автоматов давно стало одним из стандартов индустрии для построения отказоустойчивых систем. В нашем докладе мы расскажем о том, как поверх автоматов построены динтаблицы YTsaurus — распределённая база данных класса NewSQL. На примере задачи балансировки шардов базы данных без даунтайма расскажем, как обеспечить жизнь нескольких тысяч автоматов в одном кластере и какие бывают протоколы передачи сообщений между автоматами.

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

Мы в динамических таблицах YTsaurus более 10 лет строим распределённую СУБД. Нашим SQL-подобным языком запросов пользуются разработчики в Яндексе, и многие из них хорошо владеют C++ и используют его в работе. Это основной язык, который используется в наших User-Defined Functions. Другие используемые в Яндексе языки не подходят, потому что не работают так же быстро.
WebAssembly – технология для безопасного запуска произвольного кода в изолированном окружении. Именно она позволяет нам запускать любой пользовательский код на C++ внутри нашей СУБД и не бояться.
В докладе расскажу:
- как мы внедрили WebAssembly во взрослый SQL-движок, работающий в продакшене;
- почему WebAssembly выполняется и безопасно, и быстро;
- что требуется от хорошего WebAssembly рантайма, и как нам пришлось допиливать существующий;
- как кросс-компилировать под WebAssembly код произвольной сложности, а не только игрушечные примеры;
- почему это лучший способ поддержать UDF на настоящий момент.

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

Мы в Т-Банке запустили внутреннюю продакшн-платформу для синтеза визуального контента. В докладе расскажу, как поднимали «супертяжелые» ML-модели в Kubernetes: как справлялись с огромными образами и весами, строили архитектуру вокруг особенностей инференса и выжимали максимум подручными средствами. Будет полезно тем, кто планирует завести огромные ML-модели в проде.

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

Технический стек и архитектурные решения:
- асинхронная обработка через Kafka для управления потоком задач;
- Triton Server для эффективного инференса ML-моделей без OOM на длинных видео;
- кастомный Speech Worker как оркестратор с балансировкой нагрузки;
- собственные ASR-модели на базе FastConformer.

Практические кейсы из production:
- Обработка экстремально длинного контента (24+ часа) без потери производительности.
- Борьба с "галлюцинациями" моделей на музыке, шумах и спецэффектах.
- Горизонтальное масштабирование под переменную нагрузку видеохостинга.
- Работа со сложным аудио: от зашумленных записей до музыкальных клипов.

Что вы узнаете:
- как организовать pipeline обработки для достижения требуемой пропускной способности;
- конкретные оптимизации для снижения задержек и увеличения throughput;
- стратегии мониторинга и обеспечения отказоустойчивости.

Доклад будет полезен разработчикам, которые сталкиваются с задачами обработки больших объемов аудио/видео данных, масштабирования ML-сервисов и построения отказоустойчивых систем под высокие нагрузки.

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

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

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

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

Next Best Action: от просроченной задолженности к прибыли через персонализацию коммуникаций

В современном банковском секторе критически важно эффективно управлять просроченной задолженностью. Мы разработали систему, которая уже на первом месяце применения увеличила объём возврата средств на 25%.

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

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

Как за год превратить сотни разрозненных CV-моделей в единый, масштабируемый пайплайн, который ежедневно обрабатывает 10+ млн карточек товаров (50+ млн изображений и 500K видео)? В докладе раскрою DS архитектуру системы модерации «Wildberries»: как мы унифицировали модели через TensorRT и DALI, перешли к шаблонной архитектуре «общий бэкбон - лёгкие головы» и построили ансамбль в Triton, чтобы снизить нагрузку и ускорить деплой. Расскажу, как автоматизировали ретроскоринг, прогнозируем нагрузку на модераторов и используем LLM для перепроверки. Это не просто кейс - это готовая инженерная система, которую можно масштабировать под любые задачи в сфере модерации.

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

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

Внедряя Apache Flink в свои процессы обработки данных, возникают потребности по реализации новых коннекторов или модификации существующих. В этом докладе я хочу рассказать некоторые детали процесса разработки различных видов коннекторов (source, sink, lookup), а также дам несколько практических советов, которые позволят разработать производительный коннектор с удобным API и возможностями для кастомизации.

Kubernetes прекрасный оркестратор, в том числе и для виртуальных машин
Но что необходимо для того чтобы ВМ была надежной и стала по настоящему “first class citizen”, как сделать так, чтобы с ней можно было работать также как с обычным контейнером.

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

Этот доклад — история о том, как мы в команде разработчиков и инженеров строили гибкую инфраструктуру тестовых стендов в условиях, где у Dev — свои пайплайны, у QA — свои требования, а у Ops — совсем другая повестка.

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

Будет про Helm, ArgoCD, кастомные пайплайны, технические ограничения, борьбу за управляемость и немного драмы из реальной разработки.

Хотите построить сеть для облака с нуля? Хотите "швейцарский нож" для подобной задачи? Проведем мастеркласс по созданию распределенной виртуальной сети между виртуалками.
В наше время появляется много новых облаков, но вот новые SDN появляются редко. Мы в VK Cloud написали свой собственный SDN. И теперь, помаленьку, выкладываем его в opensource. На этом мастерклассе я покажу небольшой кусочек нашего SDN, который, тем не менее, выполняет очень важную функцию - он служит для организации распределенного свитча в виртуальной сети. Кроме этого он умеет еще много всего, например быть распределенным роутером. Это не полноценный SDN, а скорее универсальный инструмент, которым можно решить кучу около сетевых проблем вокруг облаков и k8s.


В качестве dataplane используем Open vSwitch и gobgp. Обеспечиваем совместимость с набором стандартов EVPN.

Инфраструктура заказной разработки - страшный сон для любого ИБ специалиста. Большое количество сервисов, таких как gitlab, nexus, jaeger, jira, nextcloud, confluence, sentry, kubernetes, kibana ... Большое количество “тестовых” сервисов и сервисов “для демонстрации” с инфраструктурной обвязкой в виде баз данных, брокеров сообщений, s3 совместимых хранилищ ... А иногда есть еще и PROD контур - сервисы предоставляемые клиентам по SaaS модели. При этом бизнес требует делать как можно больше за как можно меньшее количество человеко-часов. В таких условиях обычно DevOps инженеры успевают только “чинить” очередную упавшую сборку, а полноценное администрирование сервисов становится факультативом, пока загружается пайплайн.
Подобные ситуации порождают огромное количество рисков ИБ. Самый распространённый из них - подвисшие и общие учетные записи.
Поговорим о том, как этот вопрос решалась силами половины DevOps инженера и набором OpenSource решений.

многие продукты внедряют LLM через облачные или SaaS‑решения — обмен данными, генерация контента, интеграция в бизнес‑процессы, при этом не думая о юридических особенностях и возможных рисках.

Обсудим следующее:

Что происходит с данными пользователей (персональные, коммерческие)? Как обеспечить GDPR‑подобное соответствие?

Как формулировать лицензионные соглашения и условия использования — особенно в связке с open‑source и сторонними LLM (особенно при fine‑tuning)?

Кто несёт ответственность за ошибки ИИ‑генерации — вред пользователю, нарушение прав третьих лиц, дискриминационные или токсичные результаты?

В докладе расскажем нашу историю перехода от реактивной безопасности к продуманной экосистеме в Kubernetes кластерах. Подробно рассмотрим этапы внедрения и развития Kyverno Admission Controller на масштабах крупной Enterprise компании.

Большая сила требует большой ответственности. Особенно когда большие вы.

Ваш маркетплейс вырывается вперёд и громит конкурентов. Трафик исчисляется сотнями тысяч rpm или даже rps! Вы начинаете привлекать всё больше внимания. Маркетинговый отдел радуется! Но весь ли этот трафик полезный?

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

Абстрагируемся от радужного мира честных запросов. Рассмотрим трафик изнутри. Посмотрим на типы атак. Защиту от них. И поймём, что нормально защититься в XXI веке можно только комбинируя все возможные способы и держа руку на пульсе 24/7.

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

В рамках подготовки к получению сертификата ФСТЭК России по 118-му приказу мы столкнулись с реальными ограничениями существующих решений. Многие доступные инструменты решают лишь отдельные задачи: кто-то фокусируется на образах, кто-то — на манифестах, а кто-то — на стадии запуска.

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

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

1. Что такое токенизация и зачем она нужна.
2. Платёж через терминал, как это происходит.
3. Как устроены мобильные платежи в НСПК.
4. Особенности оплаты картой в интернете.
5. Проблемы при оплате картой в интернете.
6. Как скрыть чувствительные данные.
7. Протокол взаимодействия, доверие в интернете.

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

Я расскажу о том какие проблемы связанные с распределением совокупного 200k+ RPS-ного трафика есть в нашей более чем 300 микросервисной системе, какие инструменты для борьбы с ними мы реализовали, и как их применяем. А так же расскажу про инцидент, где все обилие наших знаний и инструментов не помогло удержать сервис.

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

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

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

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

Вы не знаете, как измерить SLA в большом продукте, так чтобы все были согласны с ним?
Вы сомневаетесь в достоверности текущих расчетов SLA?
Бизнесу не понятен Ваш SLA измеренный в "технических попугаях"?
Вы не знаете как подступиться к снаряду "посчитать SLA"?

Тогда этот доклад для Вас. Доклад будет освещать аспекты измерения SLA, бизнесовую и техническую составляющие, продажу коллегам, автоматизацию и использование AI, достоверность расчетов и многое другое, с чем мы столкнулись за годы развития процесса инцидент менеджмента.

На мастер-классе разберем полезные опции и важные нюансы для дебага и траблшутинга Java приложений, запущенных в Kubernetes. Версии и инструменты JDK, что делать с JRE, как читать логи ошибок и логи GC, влияние реквестов и лимитов - все это мы разберем на примере оператора elasticsearch и самописного чарта для запуска SpringBoot приложения.

В условиях высокой нагрузки на сервисы и сложных технических проблем важно иметь эффективные практики для быстрого устранения инцидентов. Я хочу поделиться опытом решения кризисных ситуаций на примере одного из моих инцидентов, связанного с 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 и хочет понять, где тонко и как не порвать.

В гонке за перфомансом java-приложений технологии Ahead-of-Time выходят на передний план. Подходы основанные на AOT используются в GraalVM для статической компиляции, в JDK для кэширования и ускорения загрузки классов и они всё ближе подбираются к Spring Framework. И речь здесь не о компиляции проекта в автономный исполняемый файл. В Spring Framework технологии AOT позволяют оптимизировать работу приложения за счет замены механизмов рефлексии на кодогенерацию. Тема не всем известная поэтому в докладе обсудим как это работает и что с этим можно делать.

На этом воркшопе мы напишем небольшую браузерную игру на Rust. Для начала разберёмся с инструментами и скомпилируем Rust проект в WebAssembly. Потом посмотрим как использовать полученный wasm модуль из JS. Решим проблему циклических ссылок в Rust и научимся работать с JS коллбеками из Rust кода. Напишем рендерер используя 2d canvas. И, если останется время, то обсудим мультиплеер, или даже напишем свой сервер.

Оборот Flowwow за 2024 составил 17 млрд рублей.
Наверное, он работает на Golang? Нет! Под капотом PHP. Тот самый PHP, рожденный умирать последние 30 лет. Но для нас он рожден приносить деньги.
До какого уровня может вырасти проект и оставаться при этом в стартовой экосистеме? У нас это PHP, но будет работать и в сходных экосистемах NodeJS, Python.
Какие пиковые нагрузки может вытянуть проект? На примере Flowwow расскажу, какие готовые опенсорс решения (доступные и вам) мы используем, как все это настраиваем и почему не уходим на Golang. Все технологии открыты и любой разработчик может повторить наш путь.

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

В этом докладе расскажем про наш опыт перехода от использования Protocol Buffers к FlatBuffers в связке с языком Go и gRPC. Детально разберём причины и процесс миграции, рассмотрим проблемы, с которыми столкнулись, а также обсудим результаты этой миграции.

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

Чаще всего узким местом в высокопроизводительных системах является оперативная память (RAM). Если CPU способны выполнять до 4-х инструкций за такт, то обращение к памяти от единиц тактов для кеша L1 до сотен тактов для RAM. Если при разработке ПО учесть организацию RAM, то можно ощутимо ускорить производительность.

На примере нашего приложения расскажем как мы при помощи профилирования нашли узкие места в программе. Какие CPU метрики (DTLB miss, L2/L3 cache miss, RAM throughput) проседали, какие решения мы применяли для увеличения производительности. Эти простые методы применимы для широкого круга задач разработки.

Имеется следующая задача: по заданным координатам точки необходимо определить, в какой регион она попала. Система должна обеспечивать высокую пропускную способность (высокий RPS), устойчивость к внезапным всплескам нагрузки (вплоть до лавинообразной), а также 100% точность геометрических вычислений.
Простая реализация задачи без ограничений тривиальна, однако построение эффективного решения требует комплекса оптимизаций на всех этапах. Для достижения максимальной производительности были использованы приемы из линейной алгебры, особенности работы процессоров x86/x64, иерархические алгоритмы поиска, неочевидные оптимизации.

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

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

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

Как мы работаем с огромным потоком данных
с Пол тысячи модулей и обменом данными 1000000 посылок в день.
Новая База Данных (Kepri)
Полная поддержка MQTT 5.0.
Новые классические очереди v2
Улучшения потоков (транзакции, сжатие).
Упрощение управления кластерами.
Удаление устаревших функций (возможно ли работать если у Вас старые очереди).

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

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

Поделимся реальным опытом бесшовной миграции высоконагруженного сервиса уведомлений с Oracle на ScyllaDB. Вы узнаете, как организовать такой переход, минимизировать риски и сохранить доступность для миллионов пользователей.
Прослушав доклад, вы на конкретном примере узнаете:
- о проектном решении, использующим Kafka, балансировщик, куки
- с какими проблемами придётся столкнуться и как их решить
- какие инструменты и метрики использовать для мониторинга за миграцией
- что необходимо предусмотреть заранее, чтобы потом не было больно
В рамках доклада разберём:
• почему мы приняли решение уйти от Oracle и что повлияло на выбор ScyllaDB;
• как спроектировали архитектуру параллельной работы двух хранилищ;
• как использовали Kafka, балансировщики и куки для безопасного переключения;
• какие сложности нас поджидали (от асинхронности до отказа дата-центра) и как мы их преодолели;
• какие метрики и инструменты мониторинга использовались на каждом этапе;
• какие цифры подтверждают успех миграции.
Доклад будет полезен инженерам и архитекторам, которые:
• работают с высоконагруженными системами;
• планируют миграцию с монолитных решений;
• ищут реальные кейсы бесшовной миграции и data-consistency стратегий.

1. Что такое кредитный риск?
2. Зачем бизнесу нужно оценивать риск?
3. Обзор архитектуры скоринговых моделей и процесса принятия решения о выдаче кредита
- Как с помощью каскада моделей оценивать кредитный риск?
- Общая структура скоринговой системы: от заявки до и после принятия решения.
- Роль стоп-факторов в процессе принятия решений.
4. Модели оценки кредитного риска: PD, EAD, LGD
- Что такое Probability of Default (PD), Exposure at Default (EAD) и Loss Given Default (LGD)?
- Основные принципы построения моделей PD, EAD и LGD.
- Методы оценки качества моделей.
- Особенности данных и калибровка для каждой модели.
5. Поведенческий скоринг
- Что такое поведенческий скоринг и его роль в кредитном конвейере?
- Основные принципы построения поведенческого скоринга
- Методы оценки.
6. Принцип работы каскада скоринговых моделей
- Как работают модели в процессе принятия решения и как они решают бизнес-задачу?
- Расчёт ожидаемых потерь (EL) на основе моделей LGD, EAD и PD.
7. Мониторинг и внедрение новых скоринговых моделей
- Как мониторить стабильность и эффективность модели?
- Метрики мониторинга
- Процесс выкатки: от эксперимента до продакшн-релиза.
- оффлайн-тест
- ретро-тест
- бэк-тест
- а/б-тест
8. SOTA-подходы в скоринге
- Нейросетевой подход в скоринге
- Улучшение качество скоринга через другие скоринговые модели, телеком данные, девайс данные и др.

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

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

Казалось бы, ТЗ — это главный источник правды. Но чем выше ты растешь в карьере, тем реже можешь ответить своим коллегам, что «этого не было в ТЗ». Нужно думать на шаг вперед. Нужно предвидеть, что в том самом ТЗ, которое для тебя центр и основа, рано или поздно появится или исчезнет пара слов, и это полностью поменяет картину мира.

Как если из словосочетания «Внутреннее CRM-решение» исчезнет слово «внутреннее».

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

На игре мы попрактикуемся предусматривать неожиданные повороты и находить выходы из неочевидных ситуаций.

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

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

Столкнулись с парадоксом: сервис формально работал, но клиенты уходили из-за невозможности использовать бонусы здесь и сейчас. Оказалось, мониторить «всё подряд» бесполезно — нужен точечный контроль ключевых сценариев.

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

📍Как small-tech эволюционировала от фиксации инцидентов в Excel к централизованной системе наблюдаемости с метриками, логами и трейсингом
📍Внедрение SLO/SLI на основе собственной метрики «негативное влияние» для измерения качества сервисов
📍Автоматизация управления инцидентами: от ручного эскалации к чат-ботам и AI-ассистентам.
Трансформация дежурных администраторов в команду оперативного реагирования с четкими SLA
📍Практические кейсы: снижение MTTR с 4 часов до 1.5 часов, рост доступности сервисов до 99.9%

Современные исследования сталкиваются с многими вызовами: низкая воспроизводимость результатов, рутинные задачи и растущая сложность междисциплинарных проектов. В этом докладе мы покажем, как ИИ-ассистенты становятся ключевыми союзниками ученых, трансформируя научный процесс.
В этом докладе мы расскажем, как ИИ-ассистенты (как уже хорошо себя зарекомендовавшие, так и новые нишевые - на примере инструментов OSA и ChemCoScientist, созданных ИТМО) помогают решать эти проблемы:
- Использование ИИ для получение качественно новых результатов
- Автоматизация рутины: как ИИ берет на себя обработку данных, проверку гипотез и оформление результатов, освобождая время для творческой работы
- Open Source: как ИИ-инструменты помогают улучшать открытый научный код


Мы поделимся кейсами из экосистемы AI4Science Университета ИТМО, где такие инструменты уже сократили время на создание поддержку научных проектов, а также обсудим, как внедрить ИИ-помощников в различные сценарии.

Расскажу, как наша платформа внутренней аналитики выросла с 8 млн до 160+ млн событий в сутки только за первый год. При линейном масштабировании стоимость инфраструктуры увеличилась бы в 20 раз, что стало критичным для бюджета. Основные расходы: ClickHouse, Kafka и GreenPlum. Встал вопрос: как сохранить производительность, но удержать рост расходов хотя бы в пределах 4-5x?

Решение
Комплексная оптимизация стоимости хранения и обработки данных:
- Настройка TTL политик в ClickHouse с переносом на дешевые диски и S3 (экономия 20-30%)
- Оптимизация политик S3 (warm/cold storage)
- Отказ от избыточной мультизональности и версионности
- Использование облачных фич: холодные партиции GaussDB, шедулинг ресурсов
- Сжатие данных в Kafka и переход на дешевые диски вместо SSD

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

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

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