Доклады

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

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

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

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

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

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

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

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

После того, как мы переехали с 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 Облаке и какой ценой этого достигли.

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

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

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

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

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

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

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

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

Когда у вас 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

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

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

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

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

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

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

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

Рассказ о том, как команда TATLIN.Backup добавила в продукт снапшоты для файловых систем и не заняла ими все диски.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Познакомимся с еще одним инструментом сериализации данных. Сравним подходы работы с ним и с более популярным решением - Protobuf.

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

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

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

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-практик.