Доклады

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

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

Каждый день на Авито размещаются десятки тысяч объявлений. Их путь — от нажатия кнопки «разместить объявление» до появления в поисковой выдаче — проходит через множество сервисов и компонентов, живущих под высокой нагрузкой.

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

1. Архитектура ранжирования с помощью моделей и факторов (фич).
2. Инференс моделей ранжирования в поиске Ozon.
3. Попадание новых моделей ранжирования в прод.
4. Вычисление графа зависимостей между моделями и фичами (входами для моделей).
5. Автоматические проверки перформанса и качества перед доставкой моделей в продакшн.
6. Пайплайн добавления новых факторов ранжирования в прод.
7. Затрону минусы нашего прошлого решения (https://highload.ru/spb/2023/abstracts/10173) и расскажу, во что feature store превратился.

Работаете с высоконагруженными брокерами сообщений? Планируете масштабироваться или уже наступали на грабли при расширении? Этот доклад — для всех, кто хочет увидеть как по-разному масштабируются два мощных брокера сообщений: Apache Kafka и YDB Topics.

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

Закончу доклад сравнением YDB Topics и Apache Kafka и сравнением сценариев, когда использовать один, а когда другой.

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

На опыте развития распределенной облачной платформы NGENIX (50+ узлов по всей России и странам СНГ, 7+ Tbps, миллионы RPS) расскажу о том, как:
* оптимально выбирать и использовать технологии балансировки в интернете от уровня сети до уровня приложений: BGP Anycast, DNS, HTTP;
* получать данные, необходимые для принятия правильных решений по балансировке;
* объективно мониторить (в т.ч. распределенно) и сравнивать эффективность таких распределенных решений.

Из доклада слушатели поймут принципы балансировки в интернете и осознанно смогут применять их и реализующие их сервисы для своих веб-ресурсов.

1. Intro. О проекте с большим количеством внешних систем для сбора данных.
2. Решаем, как будем собирать данные и как их обрабатывать.
3. Систематизация и хранение данных: готовые импортозамещенные инструменты.
4. Расскажу и покажу, почему не стоит париться из-за безопасности.
5. Почему бизнесу важно следить за проектом в реальном времени и принимать решения.

Реальный кейс о том, как я собрал такую систему и в итоге все были счастливы — бизнес, разработчики и я =)

В своем докладе я опишу опыт внедрения распространения данных по паттерну EventStreaming для наполнения DataLake в ecom.tech. А именно:
* почему мы в целом пошли в эту историю и какие проблемы решали;
* как мы подошли к задаче в первый раз, почему отказались от общепринятого CDC (Postgres WAL / Debezium), какие инструменты были выбраны и почему;
* где и по какому принципу хранили сначала, храним сейчас и согласуем схемы данных;
* как организовывали кросс-ДЦ-распространение схем и данных;
* почему далеко не все продуктовые команды в восторге от внедрения похода, и как мы адаптировали подход после сбора критики;
* почему EventStreaming может быть не лучшим вариантом для вашего продукта, какие есть стратегии мягкого внедрения или замещения в целом.

Доклад фокусируется на архитектурных решениях для RAG-систем, где чанкинг становится узким местом при масштабировании. Рассматриваются 10 стратегий оптимизации, их комбинации и интеграция с Weaviate, Qwen и Llama.

Решаемые проблемы:
* high latency при индексировании больших данных (PDF, код, таблицы);
* потеря контекста из-за неадаптивного разделения текста;
* сложности балансировки между скоростью (throughput) и точностью (recall).

Ключевые стратегии чанкинга:
- Fixed-Size: делит текст на чанки фиксированного размера (например, 4 слова);
- Sentence-Based: разбивает текст на чанки по предложениям;
- Semantic-Based: группирует предложения по семантической схожести, объединяя их в чанки;
- Recursive: делит документ на чанки, рекурсивно разбивая их до выполнения условий (например, минимальный размер);
- Sliding Window: создает чанки с перекрытием, сдвигая окно на заданный шаг;
- Hierarchical: организует чанки по иерархической структуре документа (например, заголовки, абзацы);
- Topic-Based: группирует предложения в чанки на основе тем, определенных с помощью тематического моделирования;
- Modality-Specific: разбивает документ на чанки в зависимости от типа контента (текст, изображения, таблицы);
- Agentic: использует агента для принятия решений о стратегии разбиения и создания чанков;
- Hybrid Approach: комбинация NLTK-статистик и нейросетевых моделей.

Архитектурные инновации:
* интеграция Weaviate как векторной БД с поддержкой мультимодальности и гибридного поиска;
* оптимизация пайплайнов через LangChain и LlamaIndex для работы с Qwen и Llama;
* кэширование чанков и эмбеддингов в Redis для снижения задержек.

Результаты:
- ускорение индексирования в 2 раза (с 10 сек./док. до 5 сек./док.) при обработке 50K PDF-документов;
- повышение recall на 12% в тестах с медицинскими отчетами;
- снижение стоимости инференса Llama/Qwen за счет уменьшения избыточных чанков.

AsyncAPI — это как Swagger, только для асинхронного мира событий, очередей и сообщений. И если вы работаете с Kafka, Websockets или любыми другими event-driven-системами, этот стандарт может помочь вам в описаниях этих взаимодействий.

В докладе разберем практическое применения AsyncAPI, какие есть инструменты для работы с ним и как применить подход APIFirst.

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

В докладе расскажу про:
* проблемы крупного монолита при переезде в облако;
* переход от stateful к stateless;
* способы транспорта данных;
* оркестрацию применения данных в облаке;
* шардирование сервиса в облаке.

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

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

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

Про Apache Kafka не слышал только ленивый. Apache Kafka — это высокопроизводительная потоковая платформа, предназначенная для передачи и обработки больших объемов данных с минимальной задержкой. В каких только системах Kafka сейчас не используется!

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

Начнем с основ, но копнем глубже, выйдя за рамки общеизвестной информации. Так что же внутри черного ящика? Мы погрузимся в анатомию Kafka, сравним производительность операций ввода/вывода для Sequential IO vs Random IO, подробно рассмотрим файловую структура хранилища, а также изучим, где и как технология Zero Copy применяется в Kafka для достижения пределов быстродействия.

Погрузимся в тему тюнинга Kafka для экстремальных нагрузок. Поговорим про пакетную обработку, pipelining, компрессию данных (compression.type).

Далее оценим влияние типа сериализации на производительность передачи данных. На основе результатов бенчмаркинга «json vs protobuf», полученных с реального прод-кластера, оценим влияние параметров batch.size, linger.ms и compression.type на RPS.

В самом конце проведем обзор архитектуры большой высоконагруженной информационной системы на примере топологии геокластера, построенного на базе Apache Kafka. Сравним stretched vs connected clusters и рассмотрим практические сценарии использования Mirror Maker 2.

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

В 2ГИС поисковые данные обновляются довольно часто — особо активные сегменты могут обновляться раз в 10 минут. Насколько быстро эти данные начнет использовать поисковый движок, настолько свежие данные увидит пользователь. Поэтому основная задача — быстро доставить свежие данные до пользователя.

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

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

Брокеры сообщений широко применяются во всем IT, в частности RabbitMQ, однако это далеко не магическая коробка и написать свой код так, чтобы не потерять свои сообщения — крайне нетривиальная задача.

RabbitMQ — это сложный инструмент, а любой сложный инструмент требует точной настройки. Мы окунемся глубже в архитектуру RabbitMQ, посмотрим, где мы с легкостью можем ошибиться и потерять сообщения и как себя от этого застраховать. Глянем на 8 практических кейсов работы с RMQ, в которых опишем нюансы работы, хорошие практики и неочевидные сюрпризы, с которыми вы можете столкнуться.

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

На мастер-классе мы вместе с участниками определим, какие варианты распила монолита могут быть, разобьем существующий монолит на ограниченные контексты, спроектируем несколько шагов выпила частей из монолита. А также изобретем несколько паттернов, обсудим плюсы и минусы реализаций.

Компания Антиплагиат – поисковик, ищущий совпадения в текстовых документах. Нагрузка меняется в течение суток вслед за нормальной активностью пользователей в РФ и странах СНГ, кроме того, есть ярко выраженная сезонность, пиковая нагрузка июня в 10 раз больше пиковой нагрузки в июле. Автомасштабирование сервисов позволяет очень сильно экономить. Я расскажу о том, как это устроено у нас в кубах. Казалось бы, используй спотовые инстансы и будешь экономить 70%, но не все так просто на самом деле. Можно экономить больше, при этом масштабирование будет происходить достаточно быстро, даже с толстыми ML-моделями.

В докладе будет рассказано о практике оптимизации настроек и опыте использования оптимизированных K8s-кластеров под управлением deckhouse на прерываемых (спотовых) инстансах в AWS и YC. Текущий суммарный размер K8s: 5500 подов, 3000 ядер, 8 ТБ памяти (в сезонном пике мы ожидаем стандартного увеличения кластера в 3-5 раз). Основной упор будет сделан на конкретных решениях, позволяющих платить меньше, а работать быстрее/надежнее. Расскажу о нашем практическом опыте в настройках, влияющих на скорость масштабирования, скорость работы и доступность сервисов. Пройдемся по особенностям использования compute-сервисов облаков, позволяющих снизить стоимость эксплуатации при сохранении приемлемого для компании уровня надежности.

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

Я не верю, что проектировать отказоустойчивые и хорошо масштабируемые энтерпрайзы можно по книжкам. Как показывает мой 5-летний опыт в вузе и 10-летний в профессии, одно и то же решение вы увидите и в best и bad practice, плюс одно может перетекать в другое с течением времени (помните, совсем недавно монолиты были чистым злом? :) А все потому, что конкретное решение будет хорошим или плохим только в конкретных условиях его применения. Поэтому узнать про архитектурные паттерны и приемы можно из книжек, а вот научиться их применять — только на практике.

СДЭК к вашим услугам :) У нас за 25 лет накопился большой опыт и хороших, и плохих решений. Делали ли мы костыли? Еще как! Изобретали ли велосипеды? Возможно, лучшие в стране! А иногда мы думали, что приносим архитектуру в жертву, а оказывалось, что это было лучшее решение, которое отлично работает спустя годы...

Интересно, сможете ли вы отличить одно от другого? Приходите на мой доклад и узнайте, сколько баллов наберете в нашем интерактивном тесте. Я буду рассказывать контекст, принятое решение. Дальше вы будете голосовать — костыль/велосипед или best practice получилось? И после этого я дам ответ. Практика — критерий истинности, поэтому правильную категорию будем определять по полученным последствиям.

Команда Видеоаналитики Сибура занимается анализом онлайн-видеопотока с более 2000 камер, распределенных по заводам от Твери до Томска. Потребность в анализе большая, при этом вычислительные ресурсы меньше, чем у IT-гигантов. Анализируем разное: процессы производства продукции, соблюдение техники безопасности (наличие страховочной привязи, касок) и многое другое. При разработке решений приходится учитывать такие условия, как географическая распределенность камер, отсутствие GPU и доступа к облакам, а также более 40 различных computer vision-моделей.

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

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

Я расскажу:
* как работают голосовой стек Алисы и механизм синхронизации голосовых запросов;
* как развивались продуктовые требования к алгоритму «контрактивации», какие вызовы это поставило перед нами и способы их решения;
* как мы обеспечиваем отказоустойчивость и быстродействие системы.

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

Наш продукт для видеоконференций создает более 10 000 записей встреч в день, и пользователи ожидают саммари как можно раньше. SLA на генерацию саммари изначально был 1 час, но это делало функцию малоценной. Дополнительное ограничение, это время подготовки транскрипции, что накладывает дополнительные требования к скорости обработки и получению саммари.

Я расскажу, как мы построили систему, которая выдерживает 10K+ запросов в день и выдает саммари за 5–15 минут. Разберем архитектуру фичи от создания записи до получения саммари, влияние SLA на компоненты системы.

В сетях ЦОД и в Интернет часто используется Anycast-маршрутизация трафика для распределения нагрузки на уровне сети, это удобно и масштабируемо, позволяет экономнее расходовать IPv4-адреса.

Сервисы для B2B-клиентов/партнеров VK Tech, размещаемые в ЦОД, имеют дело с конфиденциальной информацией (например, перс. данные), которую нужно защищать по закону. Требования ИБ «закрываются» шифрованием с применением туннелей на базе российских ГОСТ-алгоритмов. И тут нас подстерегает проблема совместимости Anycast и VPN-криптошлюзов.

Архитекторы и сетевые инженеры вынуждены чем-то жертвовать и, как результат, страдает масштабируемость, неоптимальная утилизация производительности, «растянутые» между ЦОД кластеры и/или ручная схема обеспечения отказоустойчивости.

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

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

Задумывались ли вы, как именно бизнес влияет на финальное инженерное решение? А как действует архитектор, чтобы отразить потребности бизнеса в технике?

В рамках доклада я разберу реальный архитектурный путь от сбора и постановки требований до работающей системы. На конкретном примере покажу, как приложение обрастает бизнес-функционалом. Как новые требования доказывают правильность выбранных решений и влияют на поиск и выбор новых. Как одно техническое ограничение создает «паттерн», влияющий на всю архитектуру. Последовательно будут разобраны: паттерн SAGA и шаблон Event Sourcing'а, изоляция асинхронного сбора данных и планировщик отложенных задач. Подсвечу особенность работы с Кафкой под нагрузкой и почему оркестраторов много не бывает.

Естественным этапом развития систем серверной виртуализации является виртуализация сети — возможность создавать виртуальные сетевые инфраструктуры «под задачу», не будучи стесненным рамками реальной сетевой инфраструктуры предприятия. Подобный этап развития настал и у проекта zVirt.

Для обеспечения виртуализации сети в нашей системе мы исследовали существующие решения и остановились на интеграции готового SDN — OVN. При интеграции мы столкнулись с различными проблемами, начиная от просадок в производительности при увеличении нагрузки на SDN и заканчивая задачами, связанными с оберткой в продукт.

В докладе расскажу:
* чем отличается интеграция SDN в облако и SDN в систему виртуализации, почему разработка «механизма» сложнее, чем разработка «политики»;
* почему мы остановились на готовом SDN, а не писали сами;
* с какими трудностями столкнулись при попытках сделать универсальное решение;
* компромиссы и их цена: чем пришлось пожертвовать;
* сравним производительность нашей системы со «стоковой».

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

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

Миллион мастер-реплик в проде? Встречаем сетевой консенсус Ethereum 2.0 — самой децентрализованной базы данных в мире.

В действующей сети Ethereum действительно уже больше миллиона активных валидаторов, каждый из которых периодически становится лидером в сетевом консенсусе. И хотя число реальных мастер-серверов сети оценивается в десятки тысяч, сетевой консенсус Ethereum 2.0 на данный момент является самым децентрализованным консенсусом в мире, безопасность которого обеспечивается примерно $100 млрд замороженных активов и который работает без серьезных сбоев уже несколько лет. Если перекладывать на язык баз данных, то мы имеем БД с мастер-мастер-реплицкацией между огромным числом реплик, устойчивую не только к сбоям, но и к сговору большого числа валидаторов. Доклад рассказывает про эту механику репликации, основные алгоритмы, организацию такой сети и ее параметры.

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

При росте популярности приложения растет и нагрузка на сервис. Я расскажу, как мы в компании МТС Юрент справлялись с нагрузкой данных от самокатов при росте парка.

В докладе затрону:
* архитектуру группу сервисов кластера IоT;
* какие сложности были, и какие принимали решения при росте 10 тыс., 50 тыс., 100 тыс. устройств;
* с какими ограничениями столкнулись в базе данных MongoDb;
* как Redis помог выдерживать текущие нагрузки.

Лидеры рынка СУБД в сегменте крупных предприятий — Oracle, MS SQL, PostgreSQL, несмотря на то, что архитектура этих платформ складывалась больше трех десятилетий назад.

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

Умело установленный «точный» индекс может значительно ускорить целое семейство запросов с фильтрацией. Но когда нет возможности создать такой индекс и не остается ничего кроме сканирования всей таблицы, нас может выручить data skipping. С появлением нового колоночного движка в Tarantool в этом появилась необходимость, потому что индексы в нем менее эффективны, чем в строчном хранилище, и сканировать таблицу приходится чаще.

В докладе я расскажу о том, как мы делали максимально гибкий и легковесный data-skipping-индекс в реалиях и без того шустрой in-memory-СУБД, какие виды таких индексов распространены и почему мы так полюбили простые логические предикаты.

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

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

Авито постоянно растет, и по мере этого роста нам пришлось перевозить наши шардированные БД размером от 1 ТБ до 5 ТБ с больших и быстрых Bare Metal на маленькие и медленные K8s-коробочки до 300 ГБ. В докладе расскажу, как именно мы с этим справились и какие «подводные камни» встретились на пути.

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

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

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

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

Можно ли увеличить latency, добавив слой кеширования? Конечно, да. Ведь в облаках между нашим приложением и Valkey (опенсорсный форк Redis) будет сеть. А если мы решили горизонтально масштабироваться, то где гарантия, что мы выбрали лучший хост для выполнения наших запросов?

Посмотрим, что с этим делать. Обсудим, что случилось в Valkey 8.0 и 8.1 для улучшения latency (и почему это помогает). Разберемся, стоит ли переходить на valkey-only-клиенты, если наша цель — минимальные задержки выполнения запросов.

И заодно посмотрим, что нового с точки зрения улучшения latency в высоких перцентилях в rdsync (Open Source-тул для улучшения отказоустойчивости Valkey от Yandex Cloud).

WAL — один из ключевых компонентов внутреннего устройства Postgres. Файлы WAL для истории бэкапов жмутся в несколько раз, что говорит об избыточности. Изменяя физические параметры кластера, можно существенно повысить и эффективность локальной записи, и пропускную способность репликации, а можно создать неприятные инциденты.

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

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

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

В 2024 году Ozon полностью перенес свою инфраструктуру объектного хранилища на собственное решение S3-server Lusca. В докладе я расскажу, как мы выбирали хранилища индекса; думали, как реализовать strong consistency на eventual consistency базе; открывали для себя особенности фоновых процессов ScyllaDB и придумывали свои алгоритмы. А еще о том, как боролись с восстанием зомби на Хеллоуин и воскрешали терабайты данных.

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

Опыт кастомного подхода к шардированию PostgreSQL в ядре процессинга заказов Яндекс Такси. Как справляемся с нагрузками и строгими требования к доступности и latency. Как организация данных помогла реализовать простой и надежный механизм решардирования.

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

Мы обсудим:
* как векторный поиск улучшает ответы больших языковых моделей;
* принципы работы векторного поиска и его применение в YDB;
* основные проблемы и сложности при разработке векторного индекса;
* особенности и преимущества глобального синхронного индекса;
* стратегии масштабирования и оптимизации производительности;

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

Часто при работе с графами требуются инструменты для быстрой аналитики, проверки гипотез и прототипирования алгоритмов с высокой производительностью. У таких задач часто нет высоких требований к частоте запросов, но если граф слишком большой для Python, результатом аналитики является сравнимый по размеру граф, а результаты нужны очень быстро, то не всегда и графовая БД является удобным решением. Альтернативой может быть хранение в S3 исходного графа свойств (LPG) и результатов аналитики.

Наша команда анализирует графы крупного размера (~1 млрд вершин, ~50 млрд ребер с историей изменений) в облачной инфраструктуре, мы быстро вычисляем метрики, где необходимо обработать большую часть графа (OLAP и Graphalytics) для фич и и точечных запросов для OLTP-сценариев аналитики. Например, PageRank рассчитываем за 25 минут, Jaccard — за 100 минут.

В докладе поделимся опытом работы с JanusGraph поверх Cassandra, DuckDB с расширением DuckPGQ и GraphScope. Расскажем о производительности решений для работы с графами в S3. Покажем результаты сравнения форматов хранения LPG: от Parguet и Iceberg до нового GraphAR от Alibaba, с обсуждением их преимуществ и ограничений в сценариях аналитики (OLAP и OLTP).

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

Уже дважды на хайлоаде я рассказывал про наш опыт развертывания и управления распределенным S3-совместимым хранилищем на базе MinIO. Приятно, что доклады находят своих слушателей и вопросы мне в телеграм продолжают приходить до сих пор. Некоторе просят продолжения. Поэтому я решил сделать еще один доклад на эту тему, тем более, что наш опыт растет вместе с объемом места, которое занимает информация в нашем хранилище. Сейчас оно размещается в 4 ДЦ, включает в себя 12 нод и 300 дисков.

Итак, коротко о том, что я хочу рассказать в этом году.

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

2. Эффективность сжатия.
Я уже рассказывал, что MinIO поддерживает сжатие. Но насколько оно эффективно и как быстро работает? Красивые цифры и графики.

3. Быстродействие.
Расскажу, как клиентам удалось под 100% загрузить нам канал в одном из ДЦ, переливая данные с серверов в S3. При том, что для хранения мы используем обычные SAS-диски.

4. Стоимость.
Мы используем не просто SAS-диски. Мы используем б/у SAS-диски небольшого объема, но в большом количестве. Расскажу, как мы к этому пришли.

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

В процессе развития сервиса мы упирались в несколько проблем — ClickHouse не любит обновления, а для нас это критично. Объемы данных требуют буквальных объемов железа, и даже когда оно есть — мы упираемся в его производительность. Шардирование обратно зависимых таблиц тормозит скорость выдачи, а плагин укладывает БД запросами, когда должен отдавать сравнение исторических данных по товару за секунду.

По роду деятельности мы занимаемся аналитикой товаров на маркетплейсах, собираем очень много данных. Например, на WildBerries размещено 110 млн товаров, для каждого товара мы зайдем в его карточку, запишем данные (как он выглядит, какое у него текстовое описание, сколько остатков, какие были продажи, цвета, поставщик и производитель). Сохраним это в базу данных и повторим раз в сутки. Для четверти товаров мы это будем делать раз в три часа, а для 20-25 млн товаров — каждые 15 минут. Теперь добавим сюда Ozon, где товаров в два раза больше, Яндекс Маркет и параллельные разработки новых партнеров. Все это в сумме весит около 750 ТБ uncompressed-данных в ClickHouse.

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

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

Сейчас в хранилище RUTUBE более 250 Пбайт и более 400 млн единиц видеоконтента. Архитектура хранилища была заложена еще до появления таких решений, как Ceph и Amazon S3, используется до сих пор и имеет ряд преимуществ перед коробочными решениями.

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

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

Как с помощью Debezium и Kafka настроить синхронизацию данных между географически распределенными узлами БД Postgres, а также как автоматизировать переключение между базами в случае отказа и минимизировать простой.

Что слушатель вынесет с доклада?
* Рабочий подход к реализации георезервирования PostgreSQL. Он успешно работает в продакшне для клиентского MDM у одного из крупнейших заказчиков.
* Пошаговое руководство по настройке Debezium, написанию sink-коннектора и адаптации Java-приложения для работы с несколькими базами.

В любом облаке встает задача о доставке пользовательского I/O из виртуальной машины в систему хранения. У себя в MWS мы сделали это с помощью SPDK (storage performance development kit).

В докладе мы расскажем о том, что SPDK из себя представляет и зачем его, вообще, использовать. Рассмотрим, какие концепты были приняты при его проектировании и как это влияет на разработку. Покажем, какую нагрузку мы от него ожидали и как получилось на самом деле. Углубимся в подход message passing'a, который используется при обработке I/O, и расскажем, что пришлось доработать, чтобы целевые показатели производительности были достигнуты в нашем случае.

В конце доклада решим, готов ли SPDK к использованию в production и стоит ли, вообще, за него браться.

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

Вопрос только, с какой СУБД это возможно. Требования известны:
* СУБД должна работа с 10К и большим количеством соединений на заурядном серверном оборудовании;
* СУБД должна работать как с диском, так и с данным в памяти;
* эффективность работы дисковой СУБД с данными из кэша должна быть сравнима с показателями in-memory-решений;
* СУБД должна уметь масштабироваться на оборудовании с большим числом ядер.

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

Предлагаем рассмотреть СУБД Сокол в озвученных обстоятельствах в сравнении с другими системами.

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

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

В докладе я расскажу:
* про нашу систему внутреннего биллинга и ресурсные дашборды для продуктовых команд;
* про механизмы Garbage Collector в инфраструктуре и другие инструменты для оптимального использования ресурсов;
* как продуктовые команды планируют свои бюджеты на инфраструктуру;
* как мы договорились с бизнесом и считаем эффективность IТ-платформы.

Почему и как мы пишем на Rust новые утилиты массовой асинхронно-неблокирующей работы с AWS-совместимыми облаками для Яндекс Облака и VK Cloud. Расскажем, как мы реплицируем события бакета s3 и как мы удалили несколько петабайт и миллиарды файлов на Rust, активно используя асинхронные сокеты и аллокатор jemalloc. Поделимся опытом, как правильно и быстро писать полезные утилиты, работающие с AWS-совместимым API и как быстро прокачать стеку асинхронного Rust разработчиков других стеков: Python, Java, PHP, JavaScript.

Cluster API — это мощный инструмент для декларативного управления жизненным циклом Kubernetes-кластеров. Он активно развивается и поддерживает множество провайдеров для различных платформ: GCP, AWS, Azure, vSphere, bare metal и др. Однако на момент начала нашего проекта не существовало открытого провайдера для Yandex Cloud — что делало невозможным его использование в гибридных инфраструктурах.

Этот доклад будет полезен DevOps-инженерам, SRE и платформенным командам, которые стремятся упростить и унифицировать управление кластерами с помощью Cluster API, в том числе в Yandex Cloud, а также тем, кто интересуется разработкой собственных провайдеров.

Я расскажу, как мы в Т‑Банке решили эту проблему, разработав собственный Cluster API-провайдер для Yandex Cloud с нуля. Разберем архитектуру, взаимодействие с Yandex Cloud API, управление ресурсами (инстансами, балансировщиками). Особое внимание уделю нюансам разработки инфраструктурных провайдеров: спецификации CRD и reconciliation loop. Провайдер уже доступен в open source, и я покажу, как его можно начать использовать.

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

Осознанное потребление ресурсов — это то, к чему мы стремимся в Яндекс Вертикалях. У нас тысячи сервисов и сотни хранилищ данных, поэтому контроль потребления ресурсов был нетривиальной задачей, но на помощь пришла наша IDP!

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

Задумываетесь над внедрением системы единого входа (SSO)? Расскажу на примере реального опыта, поделюсь инсайдами, как мы это сделали.

Почему стоит прийти:
* для архитекторов и DevOps-инженеров: вы получите готовые примеры интеграции Keycloak с ключевыми компонентами ML-инфраструктуры — никаких абстрактных теорий, только проверенные решения;
* для тех, кто работает с мультитенантными системами: узнаете, как разграничить доступ между разными организациями и командами внутри одной платформы без компромиссов по безопасности;
* для руководителей IT-проектов: поймете, как централизовать управление доступом и сократить издержки на администрирование множества разрозненных систем.

Ключевые аспекты доклада:
* тонкости настройки OpenID Connect для Airflow, MLFlow и Superset — нюансы, которых нет в документации;
* простые решения для сервисов без нативной поддержки OAuth;
* практические кейсы организации изолированных пространств в Grafana через Keycloak;
* разделение авторизации для пользователей и для межсервисного взаимодействия.

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

Приходите за практическими инсайтами, которые сэкономят вам недели разработки и тестирования!

В этом докладе я расскажу, как мы построили единую платформу аутентификации для группы компаний.

Рассмотрим:
* почему мы разделили авторизацию и аутентификацию;
* почему Keycloak;
* как мы деплоим Keycloak, чтобы не бояться даунтаймов;
* управляем Keycloak, через IaC с помощью Pulumi (и почему именно Pulumi);
* разработали типовые архитектурные принципы работы с Keycloak;
* стандартизировали заявки на создание сущностей Keycloak;
* авторизуем пользователей из мульти-AD-инфрастурктуры с кучей дублей учетных записей между AD.

Каждая ДЗО имеет свой стек технологий и уровень зрелости IT-ландшафта. Но при этом необходимость взаимодействия друг с другом никуда не делась. Как взаимодействовать, если с одной стороны REST, а с другой Kafka? Или RabbitMQ и Kafka? Под каждый поток данных писать адаптер?

Расскажу, как мы в команде MWS Octapi решили эту проблему с помощью Event Mesh. Теперь пользователю достаточно сформировать манифест взаимодействия, описать поток данных при помощи Json Schema и все. Система поднимет валидатор, коннектор, контроллер… Упорядочит потоки, сформирует артефакты гарантированной доставки и запустит поток.

Часто шутят, что Istio — это всего лишь 500 мегабайт на сайдкар. Но это обидная неправда — на самом деле сайдкары бывают и по гигабайту.

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

SaluteEye — платформа продуктовой аналитики. Собираем события с умных устройств Сбера и других источников, обрабатываем и предоставляем для аналитики и мониторинга технических показателей продуктов. Сегодня мы собираем и обрабатываем более 5 млрд событий в день и храним в быстром доступе аналитиков более 200 Тб, но так было не всегда...

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

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

В докладе я расскажу:
* что такое онлайн-биллинг? >80 млн абонентов, 1 млрд транзакций в секунду;
* разбираем легаси-продукт, который никто не описывал 30 лет: 3,5 млн строк превращаются в 1700 тарифов и 11 унифицированных классов услуг;
* в чем сложность замены онлайн-биллинга? 80% проектов свопов неуспешны. Расскажу про классические ошибки;
* итак, мы создали онлайн-биллинг. Как мигрировать? Виды миграции и выбор подхода;
* ключевые проблемы, с которым мы столкнулись в процессе миграции: боттлнеки в 20 тыс. абонентов, сигнальные штормы и «дергания» миллионов абонентов.

Kubernetes API основан на объектной модели, которая позволяет эффективно управлять ресурсами. Custom Resource Definitions (CRD) обеспечивают удобный и мощный механизм для расширения API Kubernetes, позволяя большинству пользователей создавать свои ресурсы и управлять ими без сложной дополнительной логики. Однако в некоторых случаях возможностей CRD может быть недостаточно. В таких ситуациях на помощь приходит Extension API Server — более гибкий способ расширения API, позволяющий реализовывать сложную логику, недоступную через CRD.

Мы расскажем о том, как мы 8 лет делаем AdGuard DNS — один из самых крупных в мире DNS-сервисов. В цифрах это 5 млн RPS, 100 млн активных пользователей и 10 ПБ трафика в месяц.

Рассказ будет включать историю от первых наивных попыток на Java до масштабных решений с сотней серверов, Anycast BGP и самописным сервером. За это время мы прошли бесконечный путь экспериментов, а также столкнулись с неожиданными открытиями, связанными с выбором железа, особенностями работы современных браузеров и мобильных устройств и неочевидными деталями такой простой с виду вещи, как DNS. Наш путь не обошелся без забавных курьезов и инцидентов, от «удаления DNS» до взаимодействия с крупными магистральными провайдерами, которые показали, насколько сложной может быть настройка BGP.

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

Для тех, кто уже понял, что такое SLI/SLO, теперь станет понятно, как это реализовать на практике.

Представь, ты — инициативный разработчик или инженер. Ты уже узнал, какая классная штука SLO и как оно помогает поддерживать работу сервисов и не замедлять разработку. Ты уже продал это руководству и команде — все жаждут увидеть это в действии. Ты полон энтузиазма и уверенности, что все быстро сделаешь, ведь, кажется, это делали много раз в разных компаниях, следуя заветам книг Google. Ты начинаешь искать готовый вариант, чтобы сделать первый MVP как можно быстрее. И понимаешь, что готового рецепта нет. Ты начинаешь поиск источников о практиках других компаний, инструментов для реализации и находишь частичные данные, но ты не знаешь, насколько этот айсберг велик. А хочется по-горячему, пока интерес не остыл, показать хоть что-то команде и принести пользу.

Поделюсь нашим опытом и наработками. Я бы хотел все это знать и иметь в самом начале работы с SLO.

Какие механизмы беспарольной аутентификации можно встроить в PAM-систему: FIDO2, WebAuthn, одноразовые токены, биометрия, сертификаты. В чем риски безопасности и неудобство для пользователей паролей. Механизмы Passwordless (FIDO2/WebAuthn (аппаратные ключи), TOTP/push-токены, биометрия, сертификаты PKI). Реализация в PAM-системах: протоколы (SAML, OAuth), гибридные сценарии, управление жизненным циклом. Кейсы: банки (FIDO2), DevOps (сертификаты), корпорации (биометрия + TOTP).

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

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

Вторая часть доклада будет посвящена выявлению и предотвращению скрап-атак. Расскажу о комплексных решениях защиты, потенциале AI в этой сфере и поделюсь несколькими кейсами достойной защиты — как простыми (коды и CAPTCHA), так и сложными (rate limiting и внедрение системы детекции аномалий).

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

До встречи!

Перевод платформы партнерских отношений МТС с устаревшего корпоративного SDK и корпоративного агента SSO на OAuth2/ OIDC с рефакторингом всей внутренней архитектуры безопасности.

Челленджи:
* 7 сценариев аутентификации, различающиеся типом принципала, флоу, ресурсом, способом управления сессией и т. д.;
* 2 IDP (OAuth2/OIDC) + различное легаси (формы, LDAP, HTTP Basic и т. п.) в одновременной работе;
* 2 собственных веб-ресурса и 10 смежных для различной аудитории, использующих платформенные функции;
* 2 технологических разворота и 4 года работы.

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

Погрузимся в архитектуру, OAuth2, микросервисы, рекомендации OWASP, немножко Spring.

Современный SOC (Security Operation Center) в BigTech-компании — это сотни систем, миллионы событий и десятки гигабайт событий в секунду. Не каждая SIEM-система способна выдержать такую нагрузку и легко масштабироваться под новые требования растущего бизнеса.

Расскажем, как нам удалось пересобрать систему, чтобы обрабатывать больше 2 млн событий в секунду и хранить суммарно больше 10 петабайт данных в сжатом виде, как мы пришли к идее создания потокового коррелятора на базе Apache Flink, как разработали DSL для написания правил на базе библиотеки Flink CEP и почему отказались от Flink SQL.

Рассмотрим:
* несколько живых актуальных CVE. Будут примеры реальных свежих CVE от момента ресерча до их эксплуатации;
* пример эксплуатации CVE без эксплоита (когда его нет в паблике);
* как оценивать CVE и какие параметры учитывать;
* ресурсы и сканеры, которые помогут выявить CVE.
Напоследок — пример 0DAY.

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

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

Но главное, обсудим, какую роль для безопасности имеет своя аппаратная платформа. Приходите — разберемся вместе.

Тема с Supply Chain уже который год не на слуху, закономерно развиваются и меры предотвращения таких атак. Одним из популярных фреймворков является SLSA, однако он достаточно абстрактен и не учитывает некоторые виды атак.

В докладе вы узнаете про фреймворк OSC&R, мы сравним его с SLSA и разберемся, какие конкретно атаки нам угрожают и что с этим делать.

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

Главная проблема фаззинга — это сбор данных. Для того чтобы выявить уязвимость, нужно собрать как можно больше входных точек, параметров запросов и — самое главное — поддерживать согласованность типов значений для этих параметров. В докладе рассмотрим различные источники, откуда можно добыть данные:
1. OpenAPI-спецификации,
2. Postman-коллекции,
3. proxy (BurpSuite, proxify),
4. логи (Elasticsearch),
5. данные команд нагрузочного тестирования (ammo для yandex-tank).

В качестве движка сканирования рассмотрим open source-инструмент от команды Project Discovery — nuclei, который поддерживает фаззинг и имеет community фаззинг-шаблоны. Рассмотрим, как конвертировать данные из упомянутых выше источников в формат, подходящий для nuclei, и запустить фаззинг.

1. Рост количества и значимости API, статистика по векторам атак.
2. Различия в эффективности позитивной и негативной модели защиты.
3. Зависимость скорости разработки приложения от системы защиты API.
4. Трехэтапный подход Вебмониторэкс к управлению и защите API, основанный на гибриде позитивной и негативной модели.
5. Эффект от внедрения в CI/CD конвейере высоконагруженных систем.
6. Иллюстрация на примере кейса внедрения в СберАвто.

Мир цифровой безопасности полон хороших намерений... и плохих интерфейсов.
Мы привыкли к тому, что безопасность — это сложно, запутанно и раздражающе.
Но что, если дело не в самой безопасности, а в том, как мы ее проектируем?

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

Доклад будет полезен как участникам продуктовых команд — они поймут, как стоит проектировать и разрабатывать свои приложения, — так и безопасникам, которых мы постараемся уберечь от over-engineering’а вверенных им сервисов!

Что мы знаем о надежности дата-центров?

На сайте нам расскажут про то, как все круто зарезервировано, соответствует какому-нибудь TIER и аптайм за последние N лет. Откроем SLA и увидим там две девятки! Три девятки! Или даже четыре девятки! Лучше, конечно, пять девяток.

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

Давайте разберемся, что значат эти самые девятки, как они считаются, что может сломаться в ЦОДе и сколько времени может занять восстановление вашего проекта.

Как варить Nginx, чтобы не только узнать о том, что прилетел DDoS, но и выдержать его.

* Что, вообще, можно поменять в systemctl и зачем?
* Мониторинг Nginx: почему VTS — это круто, но медленно, зачем нужен angie и какие еще есть модули.
* Способы сбора access log.
* По каким ключам рейтлимитить? JA4 — что это за зверь?
* Кэш как таблетка от DDoS (но не серебряная пуля).

Доклад, который будет интересен SRE и DevOps-инженерам, бэкенд-разработчикам и техлидам. Поговорим о телеметрии: формат OpenTelemetry, Qryn и Coroot. Как внедрять, как расследовать инциденты и как сделать свою высоконагруженную систему с̶ч̶а̶с̶т̶л̶и̶в̶о̶й̶ работающей.

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

Postmortem-анализ — ключевой процесс для понимания причин сбоев и предотвращения их повторения на ИТ-ландшафте. ИТ-системы становятся сложнее за счет потребления сервисов друг друга (особенно это критично в экосистеме). Ручной анализ сбоев таких систем требует все больше времени и ресурсов и перестает соответствовать ожиданиям бизнеса: быстрое восстановление и глубокий анализ для предотвращения повторения.

В своем докладе поделюсь эволюцией этой практики у нас в компании: создание централизованного подразделения Mission Control Center, формализация подхода для экосистемы; уход от табличек Exсel/Word в пользу удобных инструментов; автоматизация простейших действий.

Все это позволило нам ускорить процесс анализа критичных инцидентов (с 4-6 часов до 1-2) за счет автоматизации рутинных действий. А введенный контроль качества проведенного анализа критичных инцидентов позволил продуктовым командам быстрее восстанавливать работу критически важных систем (на 26% год к году).

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

Техплатформа Городских сервисов обеспечивает работу Яндекс Такси, Еды, Лавки и Доставки. Для каждого из этих направлений важна стабильность и надежность. И поэтому один из ключевых аспектов проектирования дашбордов для более чем 2000 микросервисов – их роль в диагностике и расследовании инцидентов. Дашборды должны помогать оперативно выявлять проблемы и их причины, что позволяет ускорить реакцию на инциденты и минимизирует время простоя. В этом контексте важно не только предоставить пользователям данные о текущем состоянии системы, но и организовать информацию так, чтобы она помогала быстро разобраться в ситуации и найти источник проблемы.

В своем докладе я подробно остановлюсь на следующих пунктах:
1. кто и как пользуется микросервисными дашбордами;
2. как генерируются дашборды для микросервисов;
3. какие требования мы предъявляем к дашбордам;
4. как выглядит дашборд микросервиса в Городских сервисах Яндекса.

Наша команда в СберТехе разрабатывает и сопровождает СУБД Platform V DataGrid (aka Apache Ignite SberEdition), которая используется в Сбере в 200+ системах и развернута на 5000+ серверах.

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

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

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

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

Всегда хотели вжух-вжух и дебажить сети в этих ваших куберах и докерах, но не знали, с чего начать? Приходите — покажем, расскажем и научим основополагающим вещам в этом нелегком деле!

На нашем workshop мы разберем те кирпичики, из которых построены все сети как под K8s, так и под стандартными облаками. Проведем лабораторные работы и выдадим домашнее задание по следующим темам:
* набор утилит iproute2 как основной способ взаимодействия с сетевым стеком linux;
* устройство сетевых namespace в ядре linux;
* виртуальные сетевые интерфейсы: виды, особенности, применение;
* OpenVSwitch: лучший сетевой швейцарский нож.

Мы в МТС давно поняли, что мониторинг отдельных хостов, приложений или баз данных не дает полного представления о качестве сервиса для пользователей и непрозрачен для менеджмента. Но переход к мониторингу полноценных бизнес-сценариев в масштабах 400+ продуктов оказался непростым и полным сюрпризов.

В докладе мы поговорим о том, как нам удалось описать ключевые сценарии использования наших продуктов с помощью 3500 индикаторов качества SLI и установить для них разумные целевые значения SLO. Поделимся опытом создания единого дашборда здоровья продуктов для менеджмента и собственного интерфейса для настройки расчета индикаторов на базе VictoriaMetrics и PromQL. Расскажем о том, как мы преодолели не только технические, но и организационные трудности при внедрении нашего подхода в МТС.

Разработка программного обеспечения и его эксплуатация — это не только масштабирование, автоматизация и передовые технологии, но и постоянная борьба с неожиданными отказами, ошибками и нестандартными ситуациями. В этом докладе я расскажу о самых запоминающихся «граблях», на которые довелось наступить за 20 лет в IT.

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

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

Ни для кого не секрет, что современные архитектурные решения для ML, помимо мощностей ЦПУ, задействуют ресурсы тензорных или графических ускорителей. В итоге производительность упирается в пропускную способность шины, и не всегда перенос вычислений на ускоритель стоит свеч. Обсудим, каким образом эта проблема может быть решена в процессорах на базе архитектуры RISC-V и почему многие эксперты считают ее будущим для ML-приложений.

Но чтобы будущее наступило, необходимы не только процессоры, но и работающая на них программная экосистема. Покажем, как удалось не только портировать на RISC-V важную составляющую ML-фреймворков — высокопроизводительную Open Source-библиотеку линейной алгебры Eigen, но и «малой кровью» оптимизировать ее под векторное расширение RISC-V RVV.

Посмотрим, что дает «ручная» векторизация на RISC-V и Arm, на примере двух широко используемых высокопроизводительных Open Source-библиотек линейной алгебры — Eigen и OpenBLAS. Поймем, почему автовекторизации не хватает для ускорения приложений AI/ML, AR/VR, CV, HPC. На графиках производительности увидим, далеко ли до roofline и где прячутся compute-bound- и memory-bound-алгоритмы.

Если вы
* не понимаете, зачем программисты продолжают оптимизировать руками в век стремительно умнеющих компиляторов, то вам сюда;
* находитесь в противоборствующем лагере и не отдаете производительность целиком на откуп компилятору, то вам тоже сюда;
* вообще никогда не задумывались о каких-то оптимизациях и не понимаете, из-за чего весь сыр-бор, то тоже приходите!

Даже если вы не знаете, кто такая линейная алгебра, больно не будет.

В 2019 году мы начали предлагать в аренду клиентам выделенные серверы на базе десктопных процессоров Intel Core i9-9900K. И через некоторое время столкнулись с тем, что процессоры сильно перегреваются в 1U-корпусе и серверы выходят из строя. Стандартное воздушное охлаждение не справлялось. Увеличивать размеры корпусов мы не хотели — теряли в плотности размещения серверов в стойке и, как следствие, деньги. Это заставило нас искать нестандартные решения в направлении жидкостного охлаждения.

Путь оказался тернистым. Первые решения от поставщиков с кастомной СЖО, казалось, решили проблему, но на самом деле только отсрочили ее. Через пару лет серверы стали массово выходить из строя. Это привело к длительным простоям оборудования и необходимости замены клиентских серверов. Самостоятельные попытки решить вопрос также не приводили к успеху. Все это подтолкнуло нас к более глубокому изучению вопроса: разобрали по «косточкам» всю систему охлаждения, проанализировали конструктивные особенности, технические ошибки, изучили опыт геймеров и кастомеров и в итоге создали собственную систему — надежную в использовании и простую в обслуживании.

В докладе расскажем:
* зачем мы начали ставить десктопные процессоры в клиентские серверы, в то время как конкуренты нас осуждали;
* как решали проблемы с СЖО, чем нам помогли и помешали поставщики;
* на какие «грабли» наступили и что нужно было делать по-другому;
* happy end или очередной этап развития: как дело обстоит сейчас и что мы планируем делать дальше.

Представьте: 30+ устройств как отечественных, так и зарубежных, с разной архитектурой и форм-фактором — IP-камеры, электросчетчики, планшеты, одноплатные компьютеры и т.д. Все они разбросаны по офису словно детали пазла, из которых не складывается единая картинка. Как превратить это в цельную тестовую лабораторию с удаленным управлением, Wi-Fi и автотестами?

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

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

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

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

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

Расскажу о нашем таком случае:
* как приложение лежало и восстановилось «само собой» через 15 минут;
* как сайд-эффект настройки сети для микросервисов в кубере привел нас к даунтайму;
* как нашли причины в случайной статье от Cloudflare;
* как мы почти забили на исправление, а по итогу довели исправление в Linkerd-комьюнити.

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

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

Почему стоит прийти на доклад? Вы узнаете:
🔹 уникальный опыт масштабирования: путь от обновления десятков устройств до управления флотом из 30 000+ устройств — с конкретными техническими решениями и граблями, на которые мы наступили;
🔹 архитектурные решения без компромиссов: как мы реализовали чистую архитектуру на Python и создали экосистему с Redis, PostgreSQL и S3-хранилищем, способную работать в двух дата-центрах;
🔹 практика построения процессов: канареечные релизы, A/B-тестирование и система автоматического отката в условиях, когда цена ошибки — простой всего склада;
🔹 реальные кейсы работы в закрытом контуре: как договариваться с безопасниками, что делать, когда нет доступа к публичному облаку, и как автоматизировать процессы в изолированной среде.

Что вы унесете с доклада?
✓ Готовые архитектурные паттерны для построения собственной системы обновлений.
✓ Понимание, когда нужно делать свое решение, а когда лучше взять готовое.
✓ Подходы к масштабированию сервисов для тысяч устройств.
✓ Методы обеспечения отказоустойчивости при обновлении критически важных систем.

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

В своем докладе я расскажу про:
* первую версию архитектуры, державшую нагрузку в тысячи раз меньше текущей;
* сложности, с которыми мы столкнулись. В частности, как положили Kafka для части сервисов;
* развитие архитектуры вплоть до текущей версии, выдерживающей 1 500 000 RPS;
* как мы ежедневно записываем 20 терабайт трафика;
* зачем мы это делаем.

* Информационная безопасность и конфиденциальность данных: похожие понятия, но разные акценты;
* защита данных во время использования: централизованный и децентрализованные подходы;
* разные судьбы яиц, сложенных в одну корзину, или основные проблемы централизации;
* децентрализация: как делать математику с числами, не глядя на сами числа, или Multi-Party Computation (MPC, совместные конфиденциальные вычисления);
* пример применения MPC: как Bloomtech сделал первую в РФ (а, может, и в мире) межбанковскую платформу конфиденциальных вычислений, которая работает на проде;
* цена конфиденциальности: проблемы технологии совместных конфиденциальных вычислений вчера и сегодня;
* перспективы технологии: MPC как неотъемлемая часть цифровой инфраструктуры и стандарт для информационных коллабораций.

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

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

Сама система построения и перестроения карты — это сложный продукт, рожденный на стыке технологий. Она объединяет данные от лидаров, одометрических сенсоров и GNSS, чтобы создать точное и актуальное представление окружающей среды. Эта карта позволяет автономным транспортным средствам и роботам определять свое местоположение и уверенно ориентироваться в пространстве.

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

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

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

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

Я расскажу про то, как трансформируется индустрия космических дата-центров, при чем тут лазеры, реален ли ЦОД в космосе и надо ли охлаждать серверы, если в космосе очень холодно. Конечно же, мы обсудим, какие страны какие проекты делают, российские космические ЦОДы и что могут делать энтузиасты для космических вычислений.

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

Отдельное внимание уделим процессу разработки высоконагруженных систем в автомобилях от анализа рынка до тестирования на реальных примерах. В частности, мы погрузимся в проблематику того, как 17 различных высоконагруженных систем уживаются в одном автомобиле на примере адаптивного круиз-контроля. Несмотря на то, что пользователю могут быть важны всего 2-3 функции, он получает много дополнительных возможностей, что создает сложности в их восприятии и использовании.

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

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

В докладе расскажу:
* какие источники данных мы сейчас используем и как с ними работать по стандарту;
* как мы в Яндексе решаем эту задачу на миллионах RPS (алгоритмы и их архитектурное применение);
* о технических тонкостях: оптимизации алгоритмов, негоциации параметров в установлении TCP сессии и почему это не работает, особенностях кэширования в разных точках применения;
* как мы поддерживаем актуальное состояние информации об устройствах.

Какой путь проходит спутниковый снимок, прежде чем вы увидите его в Яндекс.Картах?

Приглашаем вас на уникальный доклад, раскрывающий все тайны высоконагруженных систем обработки геопространственных данных. Игорь Орпанен погрузит вас в захватывающий мир современных технологий обработки спутниковых изображений.

О чем расскажем.
🔍 За гранью видимого: вы увидите сырые данные, которые поступают непосредственно со спутников, и узнаете о сложных этапах их трансформации.
🌍 Пиксель за пикселем: почему команде Яндекс приходится буквально пересобирать каждый снимок, как модели рельефа и нейросетевые модели помогают картографам с публикацией изображений.
⚙️ Высоконагруженные технологии в действии: детальный разбор Cloud Optimized GeoTIFF, Pansharpening и RPC-трансформаций — инструментов, обрабатывающих терабайты данных ежедневно.
🛠 Инженерные вызовы: реальные проблемы, с которыми сталкиваются разработчики при обработке спутниковых данных, и элегантные решения, позволяющие миллионам пользователей видеть безупречные карты.

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

Самый дешевый билет — не всегда лучший для пользователя. В Авиасейлс мы внедрили ML-скоринг, чтобы ранжировать билеты по вероятности покупки. По пути столкнулись с data drift, разными источниками данных, провалами в нефункциональных требованиях и неожиданным ростом лейтенси.

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

* Мир шоссейно-кольцевых гонок.
- Суть дисциплины.
- Суть мотоспорта: сочетание технической подготовки мотоцикла и скила пилота.
-- Техническая часть. Чем гоночный мотоцикл отличается от обычного (спойлер: почти всем).
-- Пилот и умение управлять мотоциклом. Из чего складывается пилотирование.
-- К чему приводят критические ошибки при пилотировании, помимо ухудшения времени круга. Самые распространенные виды падений.
* Данные не врут. В отличие от пилотов мотогонок 😃
- Необъективность ощущений пилотов. Как мы оцифровываем скилы.
-- Датчики, которые мы ставим.
-- Метрики, которые мы собираем.
-- Примеры графиков, основанных на реальных данных.
- Разбор телеметрии. Что мы видим на графиках, и как картинки на экране приводят к победе в чемпионате.
-- Пример 1. Закрытие газа.
- Пример 2. Улучшение техники торможения, сдвиг точки торможения (1 поворот трассы Igora Drive).
- Пример 3. Изменение траектории и увеличение скорости прохождения поворота (4 поворот трассы Moscow Raceway).
* Заключение. Мотоспорт и снимаемые метрики как метафора реальному бизнесу.

Low-code- и no-code-решения привлекают своей простотой, вроде как устраняющей нужду в отладке, трассировке, профилировании и других инструментах «классического» программирования. Но в масштабах реальных промышленных проектов без них оказывается трудно, ведь иначе как понять, что делает та или иная low-code-конструкция под капотом? И, что особенно важно, как она ведет себя под нагрузкой?

В докладе мы посмотрим на имплементацию этих функций на примере российской IoT-платформы AggreGate, где встроенный язык выражений был наделен средствами трассировки и визуализации, позволяющими low-code-разработчикам видеть ход и результаты выполнения их команд на всех этапах от редактора до production. Особый акцент сделаем на производительности:
построение/слияние/кэширование деревьев разбора, ленивая загрузка результатов, троттлинг вычислений — словом, все, что позволяет сохранить сервер живым, а отладку — пригодной даже при сотнях тысяч RPS.

Доклад посвящен применению GPU для ускорения алгоритмов решения геометрических задач в САПР. Работа с геометрией на видеокартах выходит далеко за рамки компьютерных игр, а вычисления на GPU успешно применяются не только для нейросетей, но и в реальных инженерных задачах. Представьте, что вам необходимо спроектировать электросеть в городе или на промышленном объекте. Традиционный подход с использованием алгоритмов поиска пути на графах работает, но сталкивается с серьезной проблемой: для получения действительно точных расчетов графы становятся гигантскими, и время построения этих графов перестает быть приемлемым.

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

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

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

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

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

Если вы хотите уменьшить ресурсы на разработку backend’а, но при этом не потерять простоты развития, масштабируемости, прозрачности и безопасности вашего решения, то этот доклад точно для вас!

Поделимся своим опытом и расскажем, как нам тут помогают GraphQL и предметно-ориентированное проектирование!

Мы делаем low code-решения, импортозамещающие иностранные инструменты — Hasura, Firebase, Supabase, Strapi и так далее. Инструмент позволяет генерировать GraphQL-сервис по модели данных, объединять уже существующие сервисы в федерации, применять правила безопасности.

В докладе расскажем про путь, который мы прошли, в аспекте ключевой истории — эффективного использования GraphQL и DDD. Почему это может быть полезно как разработчикам, так и бизнесу. Поговорим про предметно-ориентированное проектирование, анемичные модели, определение связей между объектами и, в конце концов, генерацию сервиса с API по модели.

Также в докладе будет погружение в две важнейших и сложнейших темы — управление транзакциями (оптимистичные и пессимистичные блокировки) и безопасность — RBAC, ABAC и OpenID.

Завершение доклада будет посвящено федерации GraphQL, подходу к мониторингу производительности приложения и open source.

В рамках доклада расскажу:
1. вредные советы по работе с ClickHouse — поделюсь полученными на собственном опыте знаниями, распространенными ошибками при создании и разработке на CH-кластере. Расскажу, к каким последствиям приводят ошибки и как их избежать;
2. про внедрение шардгрупп. Расскажу, как поменяли политику работы с кластером и перевели первые 2 домена за неделю;
3. про результаты первого квартала — раскрою, как мы вышли на стабильность кластера в 99,9% и разделили большой кластер между аналитическими командами.

Доклад будет полезен как командам, плотно работающим с ClickHouse, так и тем, кто только стоит на стадии выбора архитектуры. Он поможет избежать ошибок и сразу получить лучший результат.

В 2018 году в Авито появилось in-house-решение для автоматизации A/B-экспериментов. За несколько лет платформа выросла в зрелый продукт, с помощью которого производятся почти все релизы нового функционала Авито — это 4000+ экспериментов в год.

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

* Каждый день в Авито активны сотни экспериментов.
* Объем сырых данных (кликстрим и т.д.) исчисляется миллиардами строк.
* В одном эксперименте — до 30 тыс. метрико-разрезов.
* На выходе имеем около полумиллиарда рассчитанных стат. тестов (дисперсии, p-value и т.д.).

При этом весь compute мы успеваем провести за несколько часов на относительно небольшом (в масштабах Авито) кластере Trino. Расскажу об основных способах оптимизации, которые позволяют эффективно утилизировать вычислительные ресурсы.

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

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

Стриминг активно используется платформой ОК уже более 10 лет, и за это время используемый нами фреймворк успел значительно вырасти и измениться.

В этом докладе я расскажу о том, как устроен стриминг в ОК, а также о всех патчах и фейлах, возникших в процессе обновления стримингового фреймворка 10-летней давности: об отсутствии обратной совместимости, проблемах с партиционированием, сложностях во взаимодействии с Apache Kafka, Apache Hadoop YARN и о том, как с этим боролись.

Сталкивались с проблемами синхронизации данных между системами? Боролись с постоянными кейсами «данные разъехались» или перегружали базы неоптимальными запросами? Тогда этот доклад для вас!

О чем расскажем. Change Data Capture (CDC) — это не просто модное слово, а рабочий инструмент решения бизнес-задач. На примере реальных кейсов Евгений покажет, как построить надежный пайплайн изменений данных, который станет фундаментом вашей data-driven-архитектуры.

Вы узнаете:
* как Debezium и Kafka-Connect формируют идеальную пару для построения надежной CDC-системы;
* почему Heartbeat — критически важный компонент, без которого ваша репликация может незаметно «отставать» (и как это предотвратить);
* секретные приемы оптимизации, позволяющие обрабатывать миллионы записей без потери производительности.
+ мастер-класс по использованию сигналов в Debezium — революционный подход к управлению снепшотами, который снизит нагрузку на ваши БД в разы.

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

Чтобы можно было эффективно работать с данными, необходимо, чтобы эти данные были представлены в качественном и едином агрегированном знании о клиенте, которое представляет собой синергию данных из множества индустрий. В МТС единым агрегированным знанием о клиенте является Customer Data Products (CDP), а его сердцем — продукт Golden Record.

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

География X5 Group — вся Россия: от Калининграда до Владивостока. 30 000 объектов (магазины, дарксторы, постаматы 5post, курьеры) завязаны на 80 распределительных центров (РЦ) в 8 федеральных округах. Чтобы управлять такой цепочкой поставок, данные из WMS должны поступать в дата-платформу с задержкой в секунды — максимум минуты.

Но при этом:
* разные РЦ — это физически независимые дата-центры,
* сеть между РЦ и дата-платформой может временно отвалиться,
* нельзя давать на компоненты РЦ повышенную нагрузку,
* подключение новых РЦ должно работать «в один клик».

В X5 мы построили отказоустойчивый, масштабируемый и полностью open source-стек на базе Debezium, Kafka, Flink, Trino и Iceberg. Без ручных операций со стороны дата-инженеров, без боли при изменениях и без закрытых решений.

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

Мы разрабатываем платформу для рекомендаций для всех компаний экосистемы Сбера, начиная от онлайн-кинотеатров до мира e-commerce. За прошедшие годы мы разработали универсальные подходы создания персонализированных рекомендаций.

В докладе поделюсь аспектами MLOps-архитектуры для запуска рекомендательных сценариев:
* как выглядит cloud-native-платформа для построения production-ready рекомендательных сценариев и почему это важно;
* какие MLOps-инструменты нужны для быстрого запуска достаточно сложных рекомендательных сценариев (от инструментов обработки больших данных до Feature Store и онлайн-моделей).

В современном мире масштабные языковые модели (LLM) требуют нового подхода к организации процессов разработки, тестирования и деплоя. Доклад посвящен практическому разбору адаптации классического MLOps для LLM-проектов в средних компаниях.

В рамках выступления будут рассмотрены:
* ключевые отличия разработки LLM-решений, включая особенности работы с данными, промптами (тестирование, безопасность, версионирование) и инференс-процессом;
* проблематика мониторинга — от отслеживания биллинга и токенов до сбора комплексных метрик;
* сравнение API-like- и on-premise-подходов, а также инструментарий для дебаггинга и отладки в условиях эксплуатации LLM;
* практический roadmap по созданию LLMOps-инфраструктуры с конкретными метриками для оценки эффективности.

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

Осенью этого года мы запустили одну из самых сильных языковых моделей, говорящих на русском, — GigaChat MAX
Эта модель — синтез самых современных технологий распределенного обучения и качественных данных.

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

В последние годы вертикальные видео стали стандартом в мире цифрового контента, но как найти для них действительно увлекательные моменты?

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

Ключевая проблема: как гарантировать работодателям увеличение просмотров вакансий в 3-10 раз (платный KPI), не нарушая релевантность выдачи для пользователей, если:
* просмотры зависят от позиции, но нет формулы «позиция → клики»;
* статические бусты приводят к перегреву/исчезновению вакансий.

Решение: PID-регулятор, заимствованный из инженерных систем (температура, круиз-контроль), адаптированный для ранжирования в реальном времени.

Технические компоненты:
* A/B-тест для измерения «ненаблюдаемого»;
* 5% трафика (контроль) → базовый уровень просмотров для каждой вакансии;
* цель для платных тарифов: базовый уровень × 3 (или 10).

PID-логика: P (ошибка «цель vs факт»), I (история дефицита), D (предсказание перебуста).
Формула коэффициента: U(t) = K_p × e(t) + K_i × ∫e(t)dt + K_d × de(t)/dt.

Архитектура: нормирование релевантности (скоры → [0,1]), фичстор (история просмотров, PID-параметры), стартовый буст для новых вакансий через сигмоиду.

Результаты для highload-систем:
* KPI для бизнеса: 89% вакансий на тарифе ×3 и 94% на ×10 выполнили цели;
* для пользователей: CTR +1.5%, время отклика ↗7% (более релевантный выбор).

Применимость подхода.
Класс задач: динамическое ранжирование с бизнес-ограничениями (просмотры, конверсии, доход).
Стек: высоконагруженные поисковые системы, где требуется баланс между монетизацией и UX.
Ограничения: требует A/B-тестов для калибровки и точного измерения «ненаблюдаемых» метрик.


Почему это будет в докладе:
* реальные кейсы «танцующих» вакансий в выдаче (графики + логика PID);
* архитектурные решения для работы в реальном времени.

Сравнение PID vs ML: когда что выбрать.

Ключевой вывод: PID-регулятор — интерпретируемый и ресурсоэффективный способ балансировки в highload, не требующий глубокого ML. Но гибрид «PID + прогнозирование» — следующий шаг.

В докладе я расскажу, что такое состязательные суффиксы, почему любая LLM им подвержена, как самостоятельно создать такой суффикс и почему OpenAI не считает это угрозой безопасности. Также я поделюсь результатами исследования о переносимости суффиксов между различными моделями и дам советы по тестированию ИИ-приложений на основе LLM.

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

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

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

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

Зачем бизнесу нужна автоматизация измерений габаритов и веса товаров? Как точные и быстрые измерения помогают сократить затраты и оптимизировать логистику.

В докладе я расскажу путь разработки нашего аппаратного решения для измерения весогабаритных характеристик товаров.
От выбора оборудования до проектирования архитектуры системы. С какими техническими вызовами мы столкнулись и как их преодолевали. Как нейронные сети помогают измерять объекты и повышать точность. А также поделюсь реальными результатами: данными из продакшна, выводами и итогами проекта.

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

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

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

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

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

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

В докладе я расскажу, как мы создали трейдер-бот для управления тысячами рекламных кампаний на основе data-driven-подхода с целью максимизации ключевых бизнес-метрик на платформе Телеграм. Бот в режиме реального времени заменяет собой 100% функционала множества людей или может быть использован в качестве «цифрового консультанта». В основе лежит комплексная архитектура со своими контурами хранения, мощным ML-движком и интеграция с Telegram Ads API.

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

В настоящем докладе авторы обобщают опыт переноса поисковых движков ВК в собственную реализацию облака VK (OneCloud). При обсуждении проблем и их решений для проприетарного облака выделяются те вопросы, которые могут встретиться и в других инсталляциях облаков, например:
* как настроить планировщик для корректного разделения процессорного времени между задачами с разными приоритетами;
* как настроить cgoups для валидной работы с disk cache;
* как не деградировать из-за разделения между задачами аппаратных средств CPU, таких как кэш, branch prediction unit и других ресурсов.

Speed Networking — это нетворкинг для всех, кто хочет познакомиться с другими участниками конференции без особых усилий. Для участия необходима регистрация в месте проведения формата. Количество мест ограничено, запишитесь заранее❗️

Инциденты, отказоустойчивость, реагирование, инфраструктурная безопасность — все, что защищает бизнес и не дает системам падать. Здесь обсуждают не только мониторинг и SRE, но и безопасную архитектуру, уязвимости, контроль доступа, SOC и практики secure-by-default.

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

Для участия вам потребуется ноутбук.

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

Условия участия:
* наличие ноутбука с поддержкой Docker Compose;
* допускается как индивидуальное участие, так и командное (до 3 человек в команде);
* перед началом соревнования каждый участник должен зарегистрироваться в месте проведения в системе, указав телеграм-аккаунт, имя/nick, выбрать основную технологию из списка (PostgreSQL, MySQL, MongoDB, ClickHouse, Java. Golang, Phyton и т.п.).

Победителей ждут призы.

Speed Networking — это нетворкинг для всех, кто хочет познакомиться с другими участниками конференции без особых усилий. Для участия необходима регистрация в месте проведения формата. Количество мест ограничено, запишитесь заранее❗️

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

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

Speed Networking — это нетворкинг для всех, кто хочет познакомиться с другими участниками конференции без особых усилий. Для участия необходима регистрация в месте проведения формата. Количество мест ограничено, запишитесь заранее❗️

Тема сессии: закрытая, но открытая дискуссия для тимлидов, хедов, СТО и тех, кто рулит. Как расти без выгорания, держать баланс между техом и управлением, принимать тяжелые решения, масштабировать процессы и сохранять людей. Здесь не объясняют, кто такой тимлид — здесь обсуждают, как быть им лучше.

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

Раскроем внутреннюю кухню разработки высоконагруженных компонентов одного из крупнейших стриминговых сервисов России.

ЧТО ВЫ УЗНАЕТЕ.
🚀 Путь трансформации: история превращения статичной главной страницы в динамическую ленту с персонализацией и сложной бизнес-логикой. Реальные архитектурные решения и причины их принятия.
📹 Технологии вертикального видео: как Иви создал собственный сервис коротких видео и интегрировал его во все уголки приложения.
⚙️ Полный редизайн бэкенда: почему потребовалось переписать серверную часть для новой системы рекомендаций и как это было реализовано без простоев сервиса.
🧠 Гибридный подход к контенту: объединение рекомендаций холодного и горячего старта, бизнес-правил и редакторского кураторства в единую высокопроизводительную систему.
⚡ Оптимизация под нагрузкой: реальные цифры изменения времени ответа посредством разных методов оптимизации бэкенда при непрерывно растущем RPS.

ПОЧЕМУ СТОИТ ПРИЙТИ:
* реальный опыт от практиков, а не теоретические рассуждения;
* технические детали работы с высокими нагрузками и опыт оптимизации стримингового сервиса;
* возможность узнать о подходах к построению рекомендательных систем, работающих в режиме реального времени;
* живое общение с экспертом, который готов ответить на ваши вопросы.

Speed Networking — это нетворкинг для всех, кто хочет познакомиться с другими участниками конференции без особых усилий. Для участия необходима регистрация в месте проведения формата. Количество мест ограничено, запишитесь заранее❗️

Тема сессии: глубокие техобсуждения. Как мы проектируем сложные системы, справляемся с нагрузкой, раскладываем монолиты и настраиваем CI/CD без боли. Архитектурные паттерны, кэширование, интеграции, контрактные API, очереди и все, что крутится под капотом современного highload-сервиса.

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

Speed Networking — это нетворкинг для всех, кто хочет познакомиться с другими участниками конференции без особых усилий. Для участия необходима регистрация в месте проведения формата. Количество мест ограничено, запишитесь заранее❗️

Тема сессии свободная. Для обсуждения любых тем и расширения круга знакомств.

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

Speed Networking — это нетворкинг для всех, кто хочет познакомиться с другими участниками конференции без особых усилий. Для участия необходима регистрация в месте проведения формата. Количество мест ограничено, запишитесь заранее❗️

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

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

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

Разберем, как может выглядеть архитектура потоковой обработки данных на референсах от AWS. И построим свою архитектуру из open source-компонентов, таких как Kafka Connect, Apache Kafka и Apache Flink.

У нас не задеплоилось с первого раза, давайте влепим кол инфраструктуре. А то, что мы криво поставили переменные пода — это не к нам, это к DevOps. Часто ли вы такое слышали от разработчиков, тестировщиков или поддержки? Как сделать доказательную базу того, что с инфраструктурой все хорошо, а проблема в коде?

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

Что спрятано под кнопкой «Я согласен», которую многие нажимают, не читая соглашений, когда обращаются к AI-помощникам?

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

Основано на лицензионных соглашениях ChatGPT, GigaChat, Copilot, Codeium, CodeWhisperer, Gemini.
Путей обхода не будет.
Подводные камни будут.