Доклады

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

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

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

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

В докладе разберем как масштабируются разные брокеры сообщений и ответим на следующие вопросы:
- Что будет если просто добавить партиций?
- Как себя поведет брокер при замене диска?
- Что случиться, если добавить новый брокер в кластер?
- Когда уже нет смысла масштабировать существующий кластер и проще создать новый рядом?
Все это я сопровожу примерами масштабирования Apache Kafka и YDB Topics с замерами того, насколько при расширении кластера упала скорость работы.
Закончу доклад сравнением YDB Topics и Apache Kafka и сравнением сценариев, когда использовать один, а когда другой.

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

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

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

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

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

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

Решаемые проблемы:

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

Ключевые стратегии чанкинга:
Semantic Chunking (на основе Qwen-7B): разделение по смысловым границам.
Recursive Split: иерархическая декомпозиция текста.
Fixed-Size with Overlap: фиксированные окна с перекрытием для сохранения контекста.
Token-Limited Dynamic Chunking: адаптация под лимиты токенов LLM (например, Llama-3).
Rule-Based Chunking: правила для специфичных данных (например, разделение по секциям договоров).
Content-Aware Chunking: анализ типа контента (текст/таблица/код) через Unstructured.io.
Graph-Based Chunking: связь чанков через графы (предотвращение разрывов контекста).
Sliding Window with Threshold: динамическое определение границ на основе эмбеддингов.
Hybrid Approach: комбинация NLTK-статистик и нейросетевых моделей.
Cluster-Driven Chunking: предварительная кластеризация данных для группировки связанных чанков.

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

Результаты:
Ускорение индексирования в 2 раза (с 10 сек/док до 5 сек/док) при обработке 50K PDF-документов.

Повышение recall на 12% в тестах с медицинскими отчетами.

Снижение стоимости инференса Llama/Qwen за счет уменьшения избыточных чанков.

Доклад посвящен документированию API и подходу API-First, который мы активно используем в нашей ежедневной работе. Мы поделимся практическими кейсами, как внедрение API-First помогло нам решить ключевые проблемы: ускорить разработку, улучшить взаимодействие между командами и повысить качество документации. Вы узнаете о наших лучших практиках в создании документации, организации CI/CD и автоматизации процессов, которые мы отточили на реальных проектах. Этот доклад будет полезен всем, кто работает или планирует работать со спецификациями: разработчикам, тестировщикам, аналитикам и всем, кто сталкивается с вызовами в управлении API.

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

В докладе расскажу:
· Про проблемы крупного монолита при переезде в облако
· Переход от stateful к stateless
· Способы транспорта данных
· Оркестрация применения данных в облаке
· Шардирование сервиса в облаке
· Перевод разработки в облако

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

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

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

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

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

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

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

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

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

Далее оценим влияние выбранного типа сериализации на производительность – посмотрим бенчмарки “json vs protobuf” на примере data payload с реальных проектов. В рамках этой части доклада пристально посмотрим и на влияние компрессии (gzip vs snappy).

А что, если хочется еще быстрее? Поднимем тему тонкой настройки Kafka для максимальной оптимизации производительности. Поговорим про тюнинг пакетной обработки и настройку batching, linger.ms. Посмотрим на бенчмарки и оценим влияние этих параметров конфигурации на реальных примерах с ПРОДа.

Не обойдем стороной тему семантик и гарантий доставки данных – at least once, at most once и exactly once. Тут отдельно остановимся на сценариях их применения в реальных системах.

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

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

Брокеры сообщений широко применяются во всем 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-клиентов/партнеров, размещаемые в ЦОД, имеют дело с конфиденциальной информацией (например, персданные), которую нужно защищать по закону. Требования ИБ "закрываются" шифрованием с применением туннелей на базе российских ГОСТ-алгоритмов. И тут нас подстерегает проблема совместимости Anycast и VPN-криптошлюзов.
Архитекторы и сетевые инженеры вынуждены чем-то жертвовать, и как результат, старадает масштабируемость, не оптимальная утилизация производительности, "растянутые" между ЦОД кластеры и/или ручная схема обеспечения отказоустойчивости.

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

Рано или поздно практически каждая бигтех компания пишет свой сервис уведомлений. Однако, несмотря на различия в бизнес-моделях, спектр решаемых ими проблем практически идентичен. В рамках доклада мы разберём архитектурный путь от сбора и постановки требований до работающей системы. На конкретном примере рассмотрим, как приложение, «перекладывающее сообщения из шины в СМС-ки», обрастает функционалом.
В докладе будут разобраны:
– Event Sourcing доменных событий компании
– Подсистема асинхронного сбора данных
– Каскадирование транспортов отправки по стоимости
– Планировщик отложенных задач
– Специфика Golang, повлиявшая на способ организации инстансов
– SRE-практики, чтобы это всё не упало
Как хорошо проработанные требования влияют на успешный запуск, почему не каждая простая задача является таковой и как одно техническое требование создаёт «паттерн", влияющий на всю архитектуру? Об этом вы узнаете из моего доклада.

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

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

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

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

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

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

При росте популярности приложения растет и нагрузка на сервис. Я расскажу как мы в компании МТС Юрент справлялись с нагрузкой данных от самокатов при росте парка.
В докладе затрону:
* Архитектуру группу сервисов кластера IOT
* Какие сложности были и как решали при росте 10тыс, 50тыс, 100тыс устройств
* С какими ограничениями столкнулись в базе данных MongoDb
* Как Redis помог выдерживать текущие нагрузки

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

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

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

Авито постоянно растет и по мере этого роста появилась у нас задача: пришлось перевозить наши БД размером от 1 ТБ до 5 ТБ с наших больших и быстрых LXC на маленькие и медленные DBaaS-коробочки до 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 поможет вам проектировать ваши сервисы с учётом специфики этой подсистемы.

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

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

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

Опыт кастомного подхода к шардированию 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.

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

Размещение – не только процесс публикации объявления, но и его результат, "билетик" в поисковую выдачу для объявления на Авито. Каждый день мы создаём 10 миллионов новых размещений.

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

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

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

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

В этом докладе мы расскажем о нашем опыте работы с SPDK — высокопроизводительным фреймворком для разработки систем хранения данных.
Расскажем, как использовать компоненты SPDK для создания эффективных решений для облака, и какое место он занимает в облаке MWS.
Поделимся, с какими сложностями мы столкнулись во время его эксплуатации, а также опытом улучшения существующих компонентов и разработки новых.
Доклад будет интересен всем, кто увлекается системами хранения данных и технологиями kernel bypass.

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

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

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

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

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

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

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

Почему и как мы пишем на 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) в свою инфраструктуру.

Расскажу о текущих вариантах интеграции с сервисами машинного обучения - Airflow, MLFlow, Superset. Как сервисы поддерживают OpenID Connect, как разделяется авторизация пользователей и авторизация сервисов. Как внедрить решение в рамках платформы работающей в multitenant режиме.

Также обсудим интеграцию с сервисами мониторинга. Рассмотрим изоляцию пользователей Grafana по организациям при помощи Keycloak. И как внедрить Keycloak для сервисов, которые не поддерживают OAuth.

Строим платформу аутентификации

Сбор требований
Внутренние пользователи
Внешние пользователи
Выбираем решение
Почему keycloak?
Выбор источника правды для данных (IDM система)
Отказоустойчивость
Мультицод
Холодный и горячий резерв
Управление As a Code
Всё как код
Почему Pulumi
Создаём Self Service

Каждая ДЗО имеет свой стек технологий, и уровень зрелости IT-ландшафта. Но при этом, необходимость взаимодействия между друг другом никуда не делась. Как взаимодействовать, если с одной стороны REST, а с другой Kafka? Или RabbitMQ и Kafka? Под каждый поток данных писать адаптер? Расскажу, как мы в команде Integration Platform решили эту проблему с помощью Event Mesh. Теперь пользователю достаточно сформировать манифест взаимодействия, описать поток данных при помощи Json Schema и все. Система поднимет валидатор, коннектор, контролер… Упорядочит потоки, сформирует артефакты гарантированной доставки и запустит поток.

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

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

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

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).

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

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

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

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

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

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

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

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

До встречи!

Современный 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, то можно увидеть там две девятки! три девятки! или даже четыре девятки! лучше, конечно, пять девяток.
А что эти "девятки" означают? Чем отличается надёжность и доступность?
Вот даёт один дата-центр SLA в пять девяток, а второй "всего" четыре. Значит, первый лучше?

А если питание во всём ДЦ упадёт на пару минут - это в рамках SLA? А если упадёт только одна -- ваша -- стойка?
А если сеть "моргнула", является ли это нарушением SLA?
И, самое главное, сколько в итоге пролежит именно ваш проект?

Я прочитал много разных SLA, а некоторые даже написал, и мне есть, что сказать.

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

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

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

Postmortem-анализ ключевой процесс для понимания причин сбоев и предотвращения их повторения на ИТ-ландшафте. ИТ-Системы становятся сложнее за счет потребления сервисов друг друга (особенно это критично в экосистеме). Ручной анализ сбоев таких систем требует все больше времени и ресурсов, и перестает соответствовать ожиданиям бизнеса: быстрое восстановление + глубокий анализ для предотвращения повторения.
В своем докладе поделюсь эволюцией этой практики у нас в компании: формализация подхода для экосистемы; уход от табличек Exсel/Word в пользу удобных инструментов; автоматизация простейших действий.
Все это позволило нам ускорить процесс анализа критичных инцидентов (с 4 – 6 часов до 1 -2 часов) за счет автоматизации рутинных действий. А введенный контроль качества проведенного анализа критичных инцидентов позволили продуктовым командам быстрее восстанавливать работу критически важных систем (на 26% год к году).
Сейчас, мы с уверенностью смотрим в сторону полной автоматизации PostMortem c использованием ML-инструментов, где автоматизация разбора инцидента будет дополняется экспертной оценкой наших инженеров.

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

Я работаю в команде сопровождения DataGrid (Apache Ignite Sber Edition).
Мы сопровождаем все кластеры DataGrid в Сбере, которых более 200, а High Season 2024 прошли "без единого разрыва".
За время работы мы исправили много прикольных проблем на проме и не только.
В докладе представлю postmortem наиболее интересных.
Расскажу, как мы находим корневые причины проблем, какую фактуру собираем для разбора проблем сложного 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 тестам получать не только пищу к сценариям автотестов о которых вы даже не задумывались, но и находить упущенные пласты в самых сложных высоконагруженных приложениях.

Разногласие в дефолтных настройках TCP и CNI может приводить к различным сайд-эффектам в трафике системы и приводить к ошибкам в приложении в kubernetes-кластере. Но есть случае, когда сайд-эффект встречается редко и приводит к даунтайму приложения.
Расскажу про инцидент с зависанием на 15 минут в нашей системе. Какие особенности работы TCP, gRPC Keepalive мы подчернули для проверки статуса соедиения. В чем именно нам не помог ServiceMesh, на который мы рассчитывали.
И какую еще настройку стоит подкрутить у вас в микросервисах или все же использовать ServiceMesh

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

Как мы разработали систему OTA обновления прошивок на 30000+ устройств

1. Введение:
- Необходимость собственной системы обновления прошивок складских устройств.
- Требования к системе: риски и ограничения при работе в закрытом контуре
- Готовые варианты "из коробки", и почему мы пришли к самописному решению.

2. Выбор стэка и подготовка к разработке
- Почему мы выбрали Python
- Кеширование в Redis
- S3 (CEPH) для хранения файлов прошивок
- Микросервис или монолит

3. Архитектура системы:
- Структура микросервиса по заветам дядюшки Боба. Чистая архитектура, и с чем её едят
- Redis, Postgres и S3, взаимодействие, и при чем тут паттерн Repository
- React Admin для быстрой админ консоли. Когда бэкендер пишет фронт, история успеха
- Контракты между бэкендом и приложением на устройстве

4. Релизный цикл
- Построение релизного цикла
- Как мы настроили выкатку канареечных релизов
- A/B тесты
- Откат прошивки в случае критического бага

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

6. Заключение.
- Чему мы научились пока разрабатывали систему OTA обновления прошивок
- От Системы обновления прошивок, к собственной экосистеме.

В 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-трансформации. Разберём возникающие проблемы и как мы их решаем.

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

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

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

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

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

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

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

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

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

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

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

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

Поговорим про предметно-ориентированное программирование, анемичные модели, определение связей между объектами и, в конце концов, генерацию сервиса с API по модели.

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

Завершение доклада будет посвящено федерации GraphQL (объединение и выравнивание микросервисов по спецификации) и AI-помощнику.

В рамках доклада расскажу:

1. Вредные советы по работе с ClickHouse — поделюсь полученными на собственном опыте знаниями, распространёнными ошибками при создании и разработки на CH-кластере. Расскажу, к каким последствиям приводят ошибки и как их избежать.

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

3. Результаты первого квартала – раскрою, как мы вышли на стабильность кластера в 99,9% и разделили большой кластер между аналитическими командами.

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

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

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

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

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

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

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

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

1. Использование Debezium и kafka-connect для репликации
- Использование Kafka-Connect для доставки изменений из базы данных в топик Kafka

2. Роль Heartbeat, и как он решает проблему отставания слота репликации
- Heartbeat облегчает мониторинг Debezium.
- Решение проблемы отставания в PostgreSQL при чтении части таблиц.

3. Сигналы в 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 и онлайн моделей)

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

В рекомендациях Wildberries большое количество DS-ов (200+ сотрудников), много команд и широкий спектр задач: LLM, NLP, Computer Vision и другие. Поэтому необходимо унифицированное решение, чтобы дата саентисты могли в автоматизированном режиме работать с какой-либо платформой: ставить модели на обучение, на инференс и так далее. За основу для MLOps-платформы был взят Airflow в связке с Kubernetes.
В докладе будут рассказано с какими "боттлнеками" приходится сталкиваться при разработке масштабируемой платформы, а также подробно будут рассмотрены решения двух важных задач:
— Масштабируемый способ хранения в сложной топологии секретов Vault и подключение их в Kubernetes поды задач Airflow.
— Защищенный способ реализации запуска задач в нескольких кластерах Kubernetes

Основные задачи, которые нужно решать полноценной стриминговой платформе - это хранение событий, доставка этих событий до хранилища, ну и конечно обработка c возможность хранения состояния(так называемый stateful processing). Разберём как может выглядеть архитектура потоковой обработки данных на референсах от AWS. И построим свою архитектуру из open-source компонент, таких как Kafka Connect, Apache Kafka и Apache Flink.

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

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

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

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