Доклады

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

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

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

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

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

В докладе будет представлен практический опыт создания масштабируемой RAG-системы с LLM для автоматизации обслуживания гостей. На примере стека Langchain, FastAPI, Langgraph, Redis, GPT-4o, RabbitMQ и Qdrant подробно разберем архитектуру отказоустойчивого цифрового ассистента для отелей, который:
- оформляет и отменяет бронирования, информирует о наличии номеров и изменениях статуса;
- консультирует по всем вопросам на основе базы знаний отеля;
- предлагает и подключает дополнительные услуги;
- генерирует ссылки на оплату и проверяет их статус;

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

Расскажу о развитии LLM матчинга в wildberries. Агентный подход позволяет автоматизировать написание качественных промптов для конкретной категории товаров.

В начале июля мы выкатили на нашей платформе разметки опцию разметки на 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-бот, Голосовой ассистент;
* Какие модели и какие провайдеры лучше подходят под какие задачи;
* Реальные примеры решения задач нашей команды разработки;
* Какие ресурсы нужны для запуска модели здесь и сейчас небольшой команде разработчиков;

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

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

Как собрать настоящего LLM-агента: с планировщиком, памятью, инструментами и RAG - чтобы он решал реальные бизнес-кейсы.
Разберём рабочие паттерны, практические хаки по экономии токенов и снижению latency, а также примеры multi-agent команд, которые уже работают в проде.
Изучим как измерять качество, ставить guardrails и правильно мониторить агентов.

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

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

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

Отдельное внимание уделим кодовым данным: расскажем, как мы используем LLM для фильтрации и аннотации кода, а также для генерации синтетических программ. Поделимся опытом работы с репозиториями в духе Qwen-Coder и покажем, как можно измерять обучающую ценность кодовых данных на практике.

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

Отдельно остановимся на методах отбора web-текстов по специализированным доменам, как это реализовано в статье от Essential AI.

Покажем, как устроена наша инфраструктура для генерации триллионов токенов синтетики: как сегментируются и фильтруются тексты, как устроены reverse-prompt цепочки, LLM-заметки, QA-пары к текстам и как мы справлялись с падениями генераций при непрерывной нагрузке кластера из тысяч GPU для обеспечения 100% утилизации.

Завершим обзором будущих направлений: от инструктивных бенчмарков вроде SWE-bench до новых критериев фильтрации и алгоритмических задач с автоматической проверкой решений.

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

Наше решение:
Мы разработали паттерны, обеспечивающие надежную работу AI-агентов в продакшн-среде:
- Уникальная идентификация операций и полный трейс действий агента в AEF.
- HealthCheck и мониторинг, специфичные для AI-агентов.
- Механизмы предотвращения зацикливания (TTL, лимиты попыток).
- ByPass-режим для продолжения работы системы без агента в случае сбоев.
- Поддержка отката изменений для критичных операций.
- GuardRails для управления рисками и безопасности.

Практическая польза для аудитории
Участники получат:
- Чек-лист для безопасного внедрения AI-агентов.
- Набор готовых паттернов и требований по надежности для интеграции GenAI в enterprise-среду.
- Понимание того, как избежать “паралича” ИТ-сервисов при отказах AI-агентов, обеспечить полноценный аудит и восстановление, а также интегрировать агентов в существующие BCP-планы (планы непрерывности бизнеса).

В основе доклада — реальный опыт внедрения в продакшен критичных банковских систем в экосистеме Сбера.

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

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

Бизнес задача: в связи с окончанием поддержки текущей системы контроля SWIFT-платежей, рисков и клиентов из-за политической обстановки возникла необходимость сделать своё решение.
Получилось справиться в две итерации: сначала использовали в качестве базового движка поиска OpenSearch, но этот подход себя не оправдал - из-за специфики проверок очень медленно работает.
Во второй итерации написали свой специализированный поисковый in-memory движок на замену OpenSearch, о котором и расскажу в докладе.

В своё время мы рассказывали про внутренний платёжный шлюз Яндекса - https://highload.ru/moscow/2023/authors/16191, в котором используем детерминированные конечные автоматы и event sourcing. С того момента прошло много времени, в нашей системе появилось много новых платёжных интеграций.

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

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

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

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

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

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

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

В докладе рассматривается устройство систем предотвращения утечек конфиденциальной информации (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. Как эти проблемы были решены и какие выводы были сделаны на будущее.

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

В App.Farm - PaaS-платформе РСХБ.Цифра - мы прошли тернистый путь от одной "большой" Kafka до реализации услуги "Kafka as a Service" c индивидуальными кластерами "под ключ" для решения бизнес-задач. За 3 года в промышленной эксплуатации это решение обслуживают всего 2 инженера. Расскажем честную историю: от ошибок создания первой архитектуры (риски, высокие затраты) до успешной трансформации в "Kafka as a Service" с использованием Kubernetes-операторов и middleware с парсингом протокола.

В докладе поделимся:
- Почему мы отказались от одной "большой" Kafka, и как этим минимизировали затраты на сопровождение
- Как через декларативный GitOps-подход (с примерами кода) автоматизировать развёртывание кластеров Kafka в Kubernetes
- Как упростить авторизацию с помощью middleware, "влезая" в протокол обмена
- Как мы настроили пресеты настроек Kafka под запросы пользователей PaaS-платформы (статистика, отзывы)
- Сравнение архитектур с чек-листом, поделимся топом ошибок в проде и рекомендациями по эволюции для Вашего проекта

Практические решения, которые Вы сможете забрать для себя:
- Автоматизация развертывания через Kubernetes-операторы + Strimzi (покажем код)
- Решение kafka-proxy с парсингом протокола для упрощения авторизации
- Декларативные пресеты настроек железа под потребности бизнеса
- Автоматизация обновлений Kafka без простоев

Идеально для инфраструктурных инженеров, сотрудников SRE, Platform-разработчиков, DevOps-инженеров и архитекторов, работающих с highload-интеграциями.

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

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

В докладе расскажу, как в Яндекс Такси мы масштабировали массовое чтение событий из брокера на большом, разнородном стеке технологий. Разберём различные архитектурные подходы, сравним их по стоимости и сложности внедрения. Подробно остановлюсь на нашём конечном выборе — push-модели — и объясню, почему она оказалась оптимальной. Кроме технических нюансов, поделюсь реальным опытом поэтапного внедрения решения и организацией взаимодействия между командами — эти аспекты часто оказываются не менее сложными, чем сама разработка.

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

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

Поиск авиабилетов кажется простым делом: ввёл «Москва — Сочи» и через несколько секунд получил десятки вариантов. Но за кулисами работает многоуровневый конвейер обработки данных: каждый пользовательский запрос превращается в десятки обращений к внешним API и тысячи предложений. Кешировать их можно лишь на короткое время.

Источники ассортимента сильно различаются по скорости и качеству: ответы приходят через 2 или 10 секунд, пересекаются, противоречат друг другу и быстро устаревают. Мы выявляем дубликаты, устраняем конфликты, обогащаем информацию, а также строим маршруты с пересадками — задачи, которые раньше выполняли специализированные системы.

Ключевая метрика — time‑to‑first‑offer: пользователи ждут быстрых результатов, даже если не все источники успели ответить.

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

В докладе я расскажу:
- почему поиск авиабилетов — это не просто бизнес‑логика про тарифы, а настоящий Highload со специфическими метриками качества;
- как мы прошли путь от «это не может работать» до «бизнес в нас поверил»;
- как устроены доменные слои поиска и где внутри системы «взрывается» нагрузка;
- на какие компромиссы и приёмы оптимизации пришлось пойти, где не сработали первоначальные идеи;
- каких целей и показателей в продакшн мы достигли, а каких целей достичь не удалось;
- какие новые вызовы стоят перед системой после 5 лет эксплуатации;
- что вы можете применить у себя.

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

За последние 3 года Vitastor стал универсальной SDS. Появилось много новых функций и оптимизаций - и полноценная кластерная файловая система VitastorFS, и S3, и k8s-оператор, и zero-copy в io_uring, и локализованные чтения, и совсем безумные вещи вроде Antietcd - встроенного заменителя etcd всего лишь на 3.5 тысячи строк кода (сам etcd - это более 150 тысяч строк).

Однако одной вещи не хватало давным-давно - более умного и быстрого слоя хранения. Идея не давала покоя буквально все эти годы, и только сейчас наконец кристаллизовалась и вылилась в практическую реализацию. Результаты отличные - снижение потребления CPU и повышение производительности буквально в 3-4 раза. Это при том, что уже и так было быстро, а CPU и так потреблялось мало!

Новое хранилище одновременно простое и сложное. Оно эффективно использует особенности архитектуры современных SSD накопителей, при этом решая сразу массу проблем и закладывая основу для реализации дополнительных функций.

О нём и будет доклад!

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

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

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

В Яндексе все сервисы используют общую инфраструктуру хранения данных, в центре которой находится единое объектное хранилище - MDS. Например, в нем хранят свои данные Я. Диск, Почта, Музыка, а также оно лежит в основе Yandex Object Storage. В докладе расскажу про эволюцию нашей системы, вызовы, проблемы, как мы их решали и что получилось.

При проектировании и эксплуатации нашего хранилища, мы сталкиваемся с серьезными техническими вызовами: уже сейчас в MDS хранится около 4 ЭБ данных, распределенных по нескольким тысячам серверов и обрабатывает более 1.5M RPS. Также к хранилищу предъявляются высокие требования по доступности и надежности (4 и 11 "девяток").

При этом данных с каждым годом становится все больше, и мы должны уметь масштабироваться на порядки. Архитектурные ограничения старой версии MDS не давали нам этого достичь:
- Централизованный control-plane и стейт кластера мешали дальше наращивать число серверов
- Клиентская репликация в data-plane приводила к проблемам согласованности при отказах
- При поломке железа система часто требовала вмешательство человека, что усложняло эксплуатацию и снижало надежность

В докладе подробно разберу новую архитектуру нашего хранилища и как она решает описанные проблемы:
- Децентрализация - унесли всю сложную логику из control-plane в "умный" дисковый слой и избавились от централизованного состояния кластера
- Self-healing и декларативное управление кластером - автоматизировали починку всех типовых отказов, а декларативное состояние кластером позволяет в целом упростить эксплуатацию системы. Значительно ускорили время реакции на поломку дисков - до нескольких минут.
- Репликация данных на основе Raft - отказались от клиентской кворумной репликации с сложной фоновой синхронизацией в пользу боле простого и надежного алгоритма

Расскажу как себя ведет себя система при отказах и как graceful degradation позволяет нам оставаться доступными при отказе больших частей системы. Поговорим про эксплуатацию, на какие метрики смотрим. Расскажу какие альтернативы рассматривали, что не сработало, и почему не взяли популярное готовое решение (ceph, minio).

Что заберете с собой:
- Принципы проектирования exascale хранилища
- Архитектурные решения: как организовать взаимодействие control и data plane, как реализовать репликацию данных, добиться высокой отказоустойчивости
- Паттерны автоматизации эксплуатации (self-healing, декларативное управление)
- Метрики мониторинга здоровья кластера из тысяч серверов

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

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

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

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

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

В Yandex Go DMP работает платформа потоковой обработки на Apache Flink — сотни джобов ежесекундно гонят терабайты данных через YTsaurus. Но так было не всегда.

В этом докладе мы раскроем ключевые хаки, которые позволили нам:
- Увеличить пропускную способность с единиц МБ/с до 100+ МБ/с в одну таблицу
- Разогнать лукапы с 100 RPS до 15 000 RPS благодаря нативной поддержки асинхронности и кешам
- Пересчитывать сотни терабайт данных полученные в потоковом режиме

Мы разрабатываем высокопроизводительные коннекторы не только для YTsaurus — и поделимся практическими приёмами, которые сделают ваши решения быстрее и надежнее.

Несмотря на то что кубер уже, казалось бы, живёт в каждом продакшне, и он уже стал обыденностью с точки зрения использования, для многих механизмы его работы остаются Terra Incognita. В докладе расскажу как не заблудиться лесу объектов Kubernetes, а так же выйти оттуда не просто живым, со здоровым рассудком, но и с победой.

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

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

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

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

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

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


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

В Яндексе используется, пожалуй, самое большое инфраструктурное облако в России, под его управлением находятся десятки тысяч сервисов и 150 тысяч серверов.
Страшно ли в такой системе проводить обновления? Как обеспечить максимальную надёжность и при этом сохранить высокий темп релизов?
Мы поговорим о том, как сделать простой сложную инфраструктуру. Что делать, если бизнес-юниты предъявляют разные функциональные требования. Как жить, если инфраструктура постоянно эволюционирует. Расскажу о том, как мы используем Kubernetes и CRD манифесты для управления инфраструктурой, и как нам в этом помогает Protobuf.

Инфраструктура заказной разработки — страшный сон для любого специалиста ИБ: большое количество сервисов (GitLab, Nexus, Jaeger, Jira, Nextcloud, Confluence, Sentry, Kubernetes, Kibana и др.), «тестовые» и «демо»-сервисы с инфраструктурной обвязкой — БД, брокеры сообщений, S3‑совместимые хранилища. А иногда есть еще и PROD‑контур — сервисы, предоставляемые клиентам по SaaS модели. При этом бизнес требует делать больше за меньшее число человеко‑часов. В таких условиях DevOps‑инженеры успевают лишь «чинить» очередную упавшую сборку, а полноценное администрирование сервисов становится факультативом, пока загружается пайплайн. Подобные ситуации порождают огромное количество рисков ИБ. Самый распространённый из них — «подвисшие» и общие учётные записи.

В докладе расскажу:

- как решить проблему силами «половины» DevOps‑инженера и набором open‑source‑решений;
- как развернуть все необходимые сервисы;
- как построить интеграции;
- сколько ресурсов требуется.

многие продукты внедряют 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, облачной инфраструктурой и человеческим фактором.

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

Расскажу о том, как мы приоритизируем задачи из post-mortem без конфликта с продуктом и основываясь на простых и понятных метриках. Попутно поговорим о приоритетах инцидентов, матрицах, рисках и подсчетах потерь на инцидентах. Если вы устали от бесконечно повторяющихся инцидентов или наоборот – от спринтов, состоящих из техдолга на 99,99% – вам сюда.

Расскажу о том, как мы строили свою систему автоматического тестирования многоагентной системы (технология автономного вождения): - Тестирование автономного транспорта требует работы с симуляторами и интеграцией множества компонентов - Выбор оптимального набора тестов для запуска (не все тесты нужны на каждом коммите). - Параллельный запуск автотестов в условиях ограниченных ресурсов симулятора. - Анализ результатов интеграционных тестов (ложные падения, флаки, сложная диагностика). - Эффективный репортинг и нотификации для быстрого реагирования. - Ошибки в выборе подходов (например, XFAIL, безусловный per-commit прогон) и их последствия. Доклад будет полезен тем, кто сталкивается с сложностями в автоматизации тестирования распределённых и ресурсоёмких систем. Слушатели узнают не только про успешные решения, но и про антипаттерны, которые стоит избегать

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

В 2024 году оборот Flowwow достиг 17 миллиардов рублей. Думаете, наш движок — это Golang? Нет! Ядро работает на PHP — языке, который на протяжении последних 30 лет постоянно хоронят. Но для нас это инструмент, который приносит реальную прибыль.

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

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

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

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

Linux top-у верить нельзя, картам памяти - тоже.

Доклад о том, как правильно анализировать память Java приложений и на какие вопросы в каких инструментах нужно искать ответы. Часто стандартные утилиты и средства операционной системы могут расходиться с тем, что Вы будете видеть в условной VisualVM или Jconsole. Разберёмся, почему так и где же находится истина.

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

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

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

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

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

Как робот доставки Яндекса передвигается в реальном городе, избегая пешеходов, машин и неожиданных препятствий?

Доклад раскроет устройство системы восприятия, ключевой технологии любого робота. Я расскажу какой hardware мы используем для получения данных из окружающего мира и их обработки (сенсоры - парктроники, камеры, лидар; вычислитель). Коснемся ML моделей восприятия, а именно модели 3D-детекции объектов и сегментации лидарного облака, карты заполненности, трекера объектов, модели детекции светофоров, различных вспомогательных моделей.

Я расскажу истории из production - как мы добиваемся realtime скорости обработки данных и как модели справляются со сложными городскими условиями. Затроним процессы, связанные с предотвращением восстания машин (тестированием робота), а именно оффлайн тесты, приемку релизов, путь от симуляций до уличных тестов. Это практический кейс для всех, кто строит realtime-системы с машинным обучением для реального мира!

Что вы унесете с собой:
- Детальный обзор архитектуры системы восприятия робота доставки Яндекса;
- Знания о ML-моделях восприятия и их адаптации под жесткие realtime требования;
- Истории и уроки из production-тестирования в реальном мире;
- Советы по оптимизации AI для edge-устройств с фокусом на scalability.

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

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

Доклад раскрывает внутреннюю кухню моделей оценки кредитного риска и принципов работы кредитного/скорингового конвейере — от заявки клиента до финального решения и периода после принятия решения о выдаче кредита — и покажет, как данные превращаются в управляемый финансовый риск. Начнём с бизнес-контекста: почему оценка кредитного риска - ключевой фактор стабильности и конкурентоспособности бизнеса. Затем пошагово разберём архитектуру современного скорингового конвейера.

Особое внимание уделим «внутренней кухне»:
- PD, EAD, LGD — как обучить эти модели, как калибровать и измерять её качество.
- Поведенческий скоринг — как использовать историю платёжного поведения для переоценки рисков и повышения LTV.
- Расчёт Expected Credit Loss — как объединять модели в единую метрику риска и переводить её в бизнес-решения.
- Внедрение и мониторинг: оффлайн-, ретро- и бэк-тесты, A/B-эксперименты, а также алерты по дрейфу данных, стабильности и бизнес-метрикам.
- SOTA-подходы

Вы уйдёте с чёткой схемой проектирования каскада моделей кредитного конвейера и decisioning-логики под бизнес-метрики, набором проверенных метрик/процедур мониторинга и готовыми приёмами.

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

Конференции завалены историями успеха. Но путь к успеху всегда лежит через фейлы, о которых рассказывать не принято. Но только не на нашем fail-митапе!

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

Любая компания стремиться расти и развиваться. Рост может быть обусловлен выходом на новые рынки, увеличением охвата, открытием новых направлений.
Каждый рост компании сопровождается ростом внутреннего ИТ, а кроме роста есть внутренние вызовы - повсеместное внедрение 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 на единый сетевой шлюз, который использует контекст сборки для неотвратимого контроля всех зависимостей и артефактов.