Доклады и форматы ++

Как строить pipeline на сотни миллиардов сырых HTML-страниц без бесконечного GPU-кластера. Погрузимся в архитектуру распределённой обработки веба: extraction основного контента, LID, document-level filtering, дедупликацию и каскадную маршрутизацию сложных страниц. Покажем, как сочетать CPU-first алгоритмы, лёгкие классификаторы и GPU-fallback, а также какие инженерные компромиссы возникают между throughput, стоимостью обработки и качеством итоговых данных.

AI в разработке обсуждается в терминах возможностей: ускорение, автоматизация, агенты, новый уровень продуктивности. Но как только разговор выходит за пределы демо и презентаций, возникает более жесткий вопрос: сколько на самом деле стоит это ускорение и где заканчивается эффект, а начинается новая статья затрат. В докладе разберем, из чего складывается полная стоимость владения в инженерной организации: токены, GPU-кластеры, on-prem и облако, платформенная команда, поддержка, интеграции, безопасность, тестовые контуры и цена инженерного времени.

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

Что заберете с собой • Каркас модели окупаемости AI для инженерной организации. • Список метрик, без которых нельзя честно обсуждать эффект от AI. • Подход к декомпозиции затрат: что учитывать кроме токенов и лицензий. • Низковисящие фрукты для быстрого pre-check: где смотреть экономику раньше всего. • Признаки, что пилот уже сейчас уходит в убыток, даже если формально выглядит перспективно. • Логику выбора между тремя сценариями: купить готовое, строить свое, не внедрять вовсе.

Расскажу, как мы с нуля обучили AliceAI-Foundation-80B-A3B-Base — MoE-модель на 80 млрд параметров, из которых около 3 млрд активируются для каждого токена. Покажу устройство её архитектуры: сочетание Kimi Delta Attention с полным attention и блочный вариант Attention Residuals, который позволяет слоям обращаться к представлениям предыдущих блоков.

Отдельно расскажу, как мы связали резкий скачок loss с ростом активаций MoE и стабилизировали обучение с помощью Z-Loss. В завершение разберу распределённую реализацию Muon, в которой пересылки данных выполняются параллельно с ортогонализацией, что примерно вдвое ускоряет шаг оптимизатора.

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

Что такое Software Factory и зачем она нужна. Переход от отдельных coding agents к системе, способной автономно проходить значительную часть SDLC — от постановки задачи до реализации, проверки и обратной связи.

Из каких уровней состоит Software Factory. Разберём архитектуру agentic-разработки: модель, inner harness, outer harness и orchestration/control plane — какую задачу решает каждый уровень и где проходят их границы ответственности.

Loop Engineering вместо одного большого агента. Покажем, как разработка раскладывается на циклы разного масштаба: inner loops для выполнения конкретной инженерной работы, outer loops для проверки результата и движения задачи по SDLC и meta loops для анализа и улучшения самой фабрики.

Как Software Factory устроена в Райфе. На практическом примере покажем архитектуру нашей фабрики: AI-агентов, их роли, orchestration, работу с репозиториями и инженерными системами, code review, QA/eval и end-to-end verification.

Как фабрика понимает, что результат хороший. Разберём verification и feedback loops: автоматические проверки, тесты, code review, evals, метрики и другие сигналы, которые позволяют не просто генерировать код, а контролировать качество результата.

Как работает Self-Improvement. Покажем, как результаты выполнения задач, ошибки, ревью и evals превращаются в изменения harness, правил, инструментов и поведения агентов — и как замкнуть цикл, в котором Software Factory постепенно улучшает сама себя.

Это деловая игра про жизненный цикл создания ИИ-агента: от идеи и первого прототипа до тестов, инцидентов и сопровождения в продакшене. Участники становятся командами-разработчиками, которые участвуют в тендере заказчика. Их задача — создать ИИ-агента для распознавания изображений и набрать максимум баллов. Победит не тот, кто быстро собрал прототип, а тот, кто построил более надёжный процесс: с понятной целью, проверками, правилами оценки рисков и улучшениями после ошибок. В ходе игры команды активно используют ИИ как партнёра по разработке: для анализа вариантов, поиска слабых мест, генерации тестов, разбора ошибок и улучшений. Факты: 1. В игре 4 раунда от первого прототипа ИИ-агента до мультиагентной системы. 2. За время игры происходит разбор полезных практик жизненного цикла создания ИИ-агента при совместной работе команды, заказчика и ИИ-ассистентов (agent brief, prompting, evals, guardrails, human-in-the-loop, postmortem, regression tests и др.). 3. Лучший результат даёт команда, работающая совместно с ИИ: человек отвечает за смыслы и управление рисками, а ИИ ускоряет аналитику, тесты и улучшение системы.

Все уже наняли ИИ в штат. Для стартапа игнорировать его сегодня — почти сознательно проиграть гонку скорости. Код появляется быстрее, чем мы успеваем его проверить. Но кто будет принимать PR, деплоить результат и отвечать, когда всё сломается?

Помните документ «первый день сотрудника», который дописывает каждый новичок? Теперь новичок — ИИ, и «контекст в голове» больше не работает. Приходится оформлять то, что годами держалось на договорённостях и личном опыте команды.

На наших реальных open-source-примерах разберём, как меняется SDLC — от требований и ревью до тестирования и эксплуатации. Зачем агенту полноценный стенд? Как сделать проверки и деплой быстрыми, воспроизводимыми и недорогими? И где проходят границы автономности — от reconciliation loop до безопасности?

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

Мы спроектировали и внедрили собственную on-premise альтернативу: OpenCode в качестве среды выполнения (runtime) и GitLab как слой хранения, версионирования и синхронизации. Агент работает полностью внутри закрытого контура компании и никак не зависит от доступности внешнего SaaS.

В докладе разберем:

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

Идея харнеса родилась не из теории, а из практики. Я делал проект в одиночку с ИИ-ассистентом и после каждой итерации переписывал не код, а agent.md и скиллы: каждую пойманную ошибку агента превращал в структурное ограничение, которое не даст повторить её снова. К моменту, когда проект стал командным, на руках был не только рабочий прототип, но и переиспользуемый харнес — 10 скиллов и 10 MCP-серверов.

Дальше начался второй, куда менее очевидный этап: то, что работало для одного человека, начало ломаться на команде из 5 человек и наборе из сотни параллельных агентов под нагрузкой 100 RPS. agent.md перестал быть личным дневником и стал общим ресурсом, который нужно версионировать. Правило "агент может почти всё, я слежу" перестало работать — понадобились явные границы (Red Zone/Green Zone) и права на уровне MCP-инструментов. Один агент, ждущий своей тестовой БД, превратился в очередь из десятков конкурирующих агентов — понадобился Resource Reservation Manager. В докладе — что именно из соло-практики выжило без изменений, что пришлось радикально переделать и как мы измеряли, что харнес вообще "сходится", а не просто накапливает противоречащие друг другу правила.

У всех нас есть легаси, которое из раза в раз требует времени и сил. А попытки выпилить его окончательно всё время проигрывают новым фичам. Теперь AI помогает быстрее писать код — но как не получить то же легаси, только на новом языке? Как проверить качество кода, который написал агент, и не потерять понимание системы? На примере переписывания монолита расскажу, где мы ускорились, на какие грабли наступили и как проверяли результат. И с чего вообще начать, если хочется попробовать у себя.

Все уже согласились, что агенты пишут код. Осталась одна маленькая проблема - между "агент собрал CRUD за вечер" и "агент коммитит в сервис на 500k RPS" лежит пропасть, в которую индустрия дружно не смотрит. Vibe coding довёз нас до продакшена. А до highload-продакшена - нет. Суть в чём. Тот AI SDLC, который нам продавали в 2024-2025 - "агент пишет, человек одобряет" - на больших нагрузках ломается по всем швам сразу. Ревью пухнет, on-call не понимает код, который дебажит в 3 ночи, а счёт за токены догоняет треть зарплаты мидла. И при этом отказаться от агентов уже никто не может - конкуренты-то не отказались. За столом - инженеры и лиды из крупного российского highload с прямо противоположными позициями. Одни уже перестроили SDLC под агентов и живут. Другие считают, что агентский код в hot path - это инцидент, отложенный во времени. Будем объективны - правы, скорее всего, обе стороны. Вопрос - на каких нагрузках заканчивается правота каждой.

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

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

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

Ни для кого не новость, что AI-агенты уже пишут код. Не автодополняют, а именно пишут: принимают задачу, генерируют файлы, прогоняют тесты. Но в enterprise-системе из десятков-сотен микросервисов этого мало. Агент изначально не знает, что в системе уже есть куча сервисов, которые можно реиспользовать. Напишет своё. Не знает ваших стандартов именования событий Kafka, правил аннотаций безопасности, паттернов обработки ошибок. Не проверяет, что код соответствует замыслу. Запустите ту же задачу завтра, получите другой результат. Для системы, которую поддерживают годами, это неприемлемо. Мы строим мультиагентский конвейер полного цикла: от бизнес-требования до верифицированного кода в репозитории и выпуска готовых артефактов. Ключевая идея: спецификация поведения как единственный источник истины, код как производный артефакт. Вокруг LLM выстроен детерминированный harness: контекст организации, gate-условия, валидаторы, генераторы кода из метаданных, проверка контрактов между сервисами. Модель меняется, инфраструктура остаётся. Доклад для тех, кто строит микросервисные распределённые системы (Go/Java, JS/TS/Angular/React, Kafka, PostgreSQL и т.п.). Для тех, кто уже использует AI-агентов и сталкивается с похожими проблемами: нет воспроизводимости, агент не знает корпоративного контекста, невозможно масштабировать на десятки сервисов параллельно. Покажем конкретную архитектуру, не абстрактные рассуждения.

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

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

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

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

В Циане первая попытка дать агентам весь проект принесла лавину ложных срабатываний. Расскажем, что пришлось построить вокруг модели, чтобы она начала находить реальные уязвимости: каких принципов придерживались, какой контекст передавали — граф сервисов, модель угроз, сработки классических сканеров — и почему без этого модель работает не лучше SAST. Покажем на примерах, какие классы дефектов AI Security Scan находит там, где детерминированные инструменты молчат, и во сколько это обходится.

Тезисы воркшопа

• Участники разберутся, почему AI-агенту недостаточно просто дать доступ к корпоративной документации и чем инженерный гайдлайн отличается от обычной инструкции.
• Каждая команда выберет конкретное инженерное правило или повторяющееся замечание из code review и сформулирует его так, чтобы оно было понятно и разработчику, и AI-агенту.
• Участники выполнят одну и ту же инженерную задачу дважды. Сначала без дополнительного контекста, затем с подключенным гайдлайном.
• Команды научатся описывать область применения правила, ограничения, причины выбора подхода, хорошие и плохие примеры, исключения и критерии проверки результата.
• Участники проведут перекрестное ревью гайдлайнов и проверят, можно ли однозначно понять и применить написанное правило.
• Готовые гайдлайны будут загружены в Developer Book и подключены к AI-инструментам через MCP.
• Команды сравнят результаты до и после подключения контекста и определят, какие части гайдлайна действительно повлияли на поведение AI.
• Участники познакомятся с системой оценки качества гайдлайнов и поймут, как находить неоднозначности, пропущенные ограничения и непроверяемые требования.
• По итогам воркшопа каждый участник получит готовый шаблон гайдлайна, методику его проверки и артефакт, который можно адаптировать для своей команды.
• Главный результат воркшопа состоит в том, что инженерное правило перестает быть пассивной документацией и становится рабочим контекстом для разработчика и AI-агента.

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

В докладе мы заглянем под капот кодовых агентов и постараемся разобраться, чем код похож и чем отличается от текста, как классический поиск стал зависеть от LLM и почему агенты вернулись к инструментам типа grep из 1973 года. Обсудим, как экономика KV-cache диктует архитектуру агентов, как RL учит модели находить код и почему те начинают взламывать среду, в которой их проверяют.

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

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

Большинство бизнес-сценариев ИИ-автоматизации не требуют гигантских фронтирных моделей - они просто не окупаются. При проектировании RAG и агентных систем harness (обвязка, архитектура применения модели) важнее самой модели: грамотно построенная RAG-система с моделью на 7B стабильно обыгрывает свежие GPT и Claude, работающие "в лоб" без хорошего RAG, особенно на специальных или закрытых доменах, не попавших в трейнсет этих самых GPT.

Но что такое "хорошо" и что такое "плохо" применительно к обвязке для RAG? Простой поиск по текстовым чанкам для контекста LLM - это плохо! На "грязных" реальных корпусах он теряет полноту и ломает поиск именно там, где нужна многошаговая аналитика. "Я такого не хочу даже вставить в книжку", а в рабочую систему - тем более.

А вот про "хорошо" я расскажу на примере нашего вкусного RAGU - открытого модульного движка GraphRAG для реального бизнеса, а не для GPU-rich компаний с кластерами на тысячи терафлопс. RAGU опирается на многошаговый harness, превращающий сырые документы в граф знаний последовательно и с самопроверкой. Мы обсудим границы применимости RAGU и его результаты на публичных бенчмарках в сравнении с LightRAG, HippoRAG 2 и другими вариантами harness, а также прикладные вопросы: какие ручки крутить, как выбирать стратегию поиска под свой домен и почему отсутствие «коробочного» дефолтного пайплайна - это сознательное архитектурное решение, а не баг.

Проблема: MAU агентных систем для PDLC в банке составляет 40+ тысяч человек. Ежедневно системами пользуются более 10 тысяч человек. При этом помимо пользователей за потребление токенов конкурируют автономные агенты, системы обучения моделей и замеров (бенчмарков). Токены затрачиваются не только на генерацию ответа, но и на сбор и анализ громадного объема корпоративного контекста, знаний, методик, правил регуляторов. В месяц мы потребляем более 10Т токенов, что требует значительного количества GPU-ресурсов и команд поддержки работоспособности.

Решение: • Балансировка задач по дневному и ночному инференсу. • Внедрение контекстного хранилища для эффективного управления контекстом (сокращение потребления токенов "на входе"). • Создание конвейеров автономной работы, включающих как ИИ-шаги, так и детерминированную логику ("Не используем ИИ там, где можно автоматизировать без ИИ", например, в сборке проектов).

Когда AI перестаёт отвечать текстом и начинает выполнять действия, одного LLM API уже недостаточно.

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

За четыре месяца мы построили Маверик — собственную агентную платформу X5.

Сегодня на платформе:

— 8 000+ пользователей; — 100 000+ обращений за два месяца; — 50+ подключённых корпоративных систем; — 250+ доступных агенту инструментов; — 100+ автоматизаций по расписанию; — 90% задач доводятся до результата без участия человека.

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

Что получит слушатель

После доклада слушатель сможет:

— спроектировать pipeline от пользовательского запроса до выполненного действия; — отделить agent core от моделей и интеграций; — собрать расширяемый tool layer; — определить, какие операции требуют human approval; — организовать выполнение кода в sandbox; — добавить model fallback без потери состояния задачи; — разделить executor и controller; — переводить диалоговые запросы в повторяемые workflow; — выбрать метрики, которые показывают реальную пользу агента.

Публичные лидерборды говорят, какая модель "умнее", но не сообщают о главном - будет ли агент полезен именно в вашей системе - с вашим API, компилятором, legacy и ограничениями.

Разрыв между public score и production usefulness - первое, с чем сталкивается команда, внедряющая LLM-агентов.

Расскажу, как мы строили собственный evals benchmark для AI-агентов, встроенных в игровой движок и его скриптовую экосистему: - почему оценивать важно систему, а не модель, и как спроектировать eval-задачи как изолированные воспроизводимые sandbox-среды - как вместо единого score построить карту навыков агента: исправление ошибок, работа с документацией и API, end-to-end-сценарии, безопасность - зачем мы отказались от агрегированного score в пользу семи независимых диагностических сигналов

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

Выступление относится к формату «Дебаты»

1. Почему стандартом единицы, формирующей инфраструктуру, должны становиться апплаенсы или так называемые ПАКи?
2. Можно ли построить ПАК на китайских GPU?
3. Сопоставимы ли метрики производительности GPU при использовании китайских GPU?
4. Можно ли достроить инфраструктуру с помощью китайских GPU, если она ранее была создана на Nvidia?
5. Нужно ли централизованное управление GPU, если мы говорим про ПАК?
6. Комплектующие ПАК могут быть не в реестре, и это ни на что не повлияет.
7. Китайские GPU – хуже, так как приходится иметь дело с непроверенными и ненадежными поставщиками.
8. Что экономически более оправдано – ПАК (как отдельный особенный вид on-prem) или облако?

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

В мастер-классе будет рассказ о том, как выглядит ALD Pro в продуктивной среде, как он эволюционировал, где находится сейчас, где и чем он отличается от Active Directory и почему большая часть администраторов плохо понимает даже Active Directory (и из-за этого совершенно не готова с него слезать). Мы разберем, где ALD Pro похоже на FreeIPA, а где совершенно непохоже, где стоит ожидать места для удара головой, а где его придется сделать самому.

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

Мы 17 лет развивали видеостриминговый серверный софт на Erlang, и пришло время менять базу.

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

Я системный аналитик, и моя основная задача — перевести 152-ФЗ, Приказ ФСТЭК №117 и 187-ФЗ в метрики, критерии приёмки и зоны ответственности команд. Без этого разработка встанет, а регулятор не примет систему. Расскажу на трёх живых примерах, как я это делала. Первый — локализация данных. Мы разложили «хранить ПДн в РФ» на NFR. На реализации выяснилось, что синхронная отправка во внешний сервис добавляет 300 мс латентности. Я переписала критерий: ответ пользователю не ждёт внешний сервис, достаточно подтверждения из РФ-БД. Формулировка изменилась — и система заработала. Второй — мониторинг ИИ по ФСТЭК. Мы спроектировали требования к логам для LLM. Объём логов вырос в 10 раз — исходные требования по retention пришлось пересобрать с компрессией и выгрузкой в холодное хранилище. Ещё одна правка: гардрейлы должны проверять не только вход, но и выход модели. Третий — согласия на обучение моделей. Мы сформулировали сценарии: базовое согласие, отдельное согласие на обучение, отзыв согласия. На практике удаление данных из модели невозможно. Я переформулировала требование: дообучение идёт только на данных с активным согласием, исторические данные остаются в модели. Регулятор принял этот компромисс. Главный вывод: качественные требования спасают проект. Нельзя передать закон разработчикам — нужно превратить его в проверяемые условия. И честно фиксировать технические ограничения как согласованные риски.

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

Пользователь открывает карточку сотрудника. API отвечает за 80 миллисекунд, Kafka lag в норме, consumer работает, Redis доступен. Но часть данных уже устарела: сотрудник уволен, а один из пользовательских сценариев всё ещё видит его активным.

Как понять, можно ли вообще доверять такому ответу?

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

PostgreSQL → Outbox/CDC → Kafka → Read Model → Redis → API

Покажу, почему timestamps, трейсы, Data Lineage и consumer lag хорошо объясняют, что произошло с данными, но ещё не отвечают на вопрос, насколько сильно мы можем доказать их актуальность в момент принятия бизнес-решения.

Сравним несколько способов проверки:

• полную реконсиляцию источника и проекции
• watermarks, чекпоинты, sampling и синтетические пробы
• индивидуальное доказательство прохождения значимых изменений
• токен консистентности и version-aware-чтения
• authoritative/strong-чтения для критических операций.

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

Поэтому для разных сценариев будем использовать разные гарантии. Информационный профиль может жить с ограниченной eventual consistency. Пользователь после собственной правки должен получить read-your-writes. А критическая операция должна либо получить достаточное доказательство актуальности нужных ей данных, либо честно признать состояние неизвестным и не выполнять действие.

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

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

Георезервирование — это уже не "модно", это уже привычная реальность. Но есть ряд проблем: - мы знаем, как обеспечить быстрое переключение при аварии - мы умеем адаптировать распределение нагрузки динамически в соответствии с потребностями - мы умеем обеспечивать resilience при аварии но как это обычно бывает, - "выберите два пункта из трех", а может есть вариант как получить все? Как говорится, «нам и то и другое, и можно без хлеба» (с)

Мы научились считать метрики А/Б-экспериментов в реалтайме (об этом был прошлый доклад) — и этот подход вырос из решения одной задачи в платформу реалтайм-сигналов. CORTe (COllector RunTime) на едином коде и методологии закрывает сразу три задачи — A/B-тестирование, онлайн-мониторинг продуктов и приёмку релизов. Сегодня на CORTe работают процессинги для Рекламы, Алисы, Маркета и других продуктов, а потоки доходят до >300K RPS на источник. Когда сигналы считаются в одном месте по единой методологии, метрики перестают расходиться между задачами — уходит проблема кросс-валидации и рассинхрона, когда одну и ту же метрику по-разному считают в экспериментах, мониторинге и приёмке. Использование CORTe даёт масштабируемое и интегрированное в инфраструктуру компании решение.

Расскажу об опыте приземления форка LangFlow в ИТ-ландшафт банка: от чистки кодовой базы и разделения бэкенда с фронтендом до масштабирования на большие объемы запросов. Покажу, как мы проводили оптимизацию на уровне кода, внедрили MongoDB и Redis и превратили Low-Code-платформу в ключевой компонент архитектуры AI-ассистента на миллионы пользователей.

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

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

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

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

Классическая модель I/O в Linux (blocking read/write, poll/epoll, POSIX AIO) упирается в накладные расходы на syscalls и context-switch при высоком RPS. io_uring – это не “ещё один API”, а смена модели: приложение общается с ядром через shared-memory-кольца (SQ/CQ) вместо синхронных вызовов, что открывает целый класс возможностей, которых в старом I/O не существует в принципе (не “хуже реализовано”, а отсутствует как концепция). Доклад показывает это на конкретных примерах и цифрах.

Чтение с реплики выглядит как простой способ масштабировать Postgres на чтение: добавили ещё один хост в строку подключения и разгрузили мастер. На практике тут два неочевидных сюжета. Первый: какие аномалии изоляции приложение может увидеть на реплике и почему Postgres их допускает. Второй: как приложению надёжно находить актуальный мастер и почему привычные способы работают хуже, чем кажется. Обе темы получили развитие в сообществе в 2026 году. Разберём на пальцах, почти без погружения в исходники, да тут ещё и не всё написано так-то.

Фоновая компактификация для удаления устаревших данных в LSM-деревьях традиционно запускается по таймеру - вслепую: на кластерах YTsaurus до 90% данных переписывались без изменений, а период приходилось подбирать вручную. Мы научили компактификацию запускаться по данным: у каждого чанка есть дайджест — сводка в несколько килобайт, по которой заранее видно, сколько места освободит перезапись. Расскажем про структуры данных внутри дайджестов, три алгоритма на их основе и грабли, собранные при раскатке. В продакшне подход срезал поток компактификации в разы, поднял её КПД на порядок и полностью убрал ручную настройку.

• Зачем нам потребовалась распределенная БД.
• Почему распределенные БД работают таким образом. Как реализован Serializable в YDB и какое слово из трёх букв у нас ассоциируется с этим.
• Практики, без которых мы бы не выжили: чтения отдельно от записей, контроль TLI и ретраев, свой UUID под таблетки, целостность без FOREIGN KEY, материализованные view вместо больших join, отстрел fullscan и планы запросов в приложении.

(будет обновлено позднее) Как построить корпоративных ИИ-агентов, которые знают системы и процессы компании, учитывают SDD/ADR, связывают договоренности из звонков с состоянием проекта и замечают отклонения от плана? И как сделать это без раздувания промптов и повторного сбора одного и того же контекста?

Мы покажем AI Semantic Layer, общий инфраструктурный слой между корпоративными данными и агентами. Он объединяет системы, документы, регламенты, логи, транскрипты встреч и, по сути, все интересующие компанию цифровые следы в связанную модель. Агент получает из нее небольшой фрагмент данных для своей задачи вместе со ссылками на источники.

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

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

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

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

Вот основные тезисы доклада:

1. Проблема: Почему стандартные утилиты неприменимы на огромных объемах. Физические ограничения дисковой подсистемы и иллюзия безопасности бэкапов.

2. Инфраструктурный путь: Создание мгновенных снимков файловой системы через LVM-снапшоты на изолированных репликах. Математика капасити-планирования: формулы расчета прироста дисковой нагрузки (RPS) и идеального сайзинга области изменений. Опасности скрытой нагрузки механизмов Copy-on-Write и жесткий тротлинг процессов на уровне ядра Linux.

3. Эксплуатационные хаки: Риски нарушения консистентности распределенных данных и появление orphaned-документов при восстановлении. Использование встроенной репликации для бэкапа и физическое клонирование файлов реплик с попутным решением проблемы дефрагментации.

4. Нативный NoSQL-подход: Организация параллельного распределенного бэкапа по диапазонам токенов в Cassandra для линейного масштабирования скорости.

5. Инфраструктура хранения: Сравнение объектных хранилищ, сетевых шар и распределенных файловых систем для эффективного размещения бэкапов.

6. Сравнение подходов и матрица выбора решений.

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

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

Я расскажу не про API поиска, а про инженерные решения при встраивании поиска в YDB: обновления вместе с таблицей, фильтры и права доступа, шардинг, сбои, SQL-план и ранжирование. Разберу кластеризованный векторный индекс, полнотекстовый индекс с BM25, цену N-грамм и фильтров, а также 'HybridRank'.

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

Вы узнаете:

• Какие данные помогли моделям дать лучший результат

• Как мы оценивали качество советов

• Как минимизировать вероятность сложить прод выполнив совет от LLM

• Как можно немного экономить токены

• Какие риски вы приобретаете когда начинаете советовать конкретные действия разработчикам

• Как наладить процесс улучшений имея подобную систему

Последние несколько лет мы в Яндекс Рекламе активно мигрировали с MapReduce-технологий на real-time. Последним, что отделяло нас от полностью real-time-обновления индексов, оставалось full-state-обновление индексов HNSW, которые позволяют Яндекс Рекламе находить самые релевантные для пользователей объявления среди миллиарда объектов. В докладе расскажу, как мы с помощью нового алгоритма обновления индекса HNSW смогли перейти на полностью real-time-процессинг данных.

Как подготовить Debezium и Oracle для миграции данных в системе авторизации Госуслуг: 200 таблиц, 10 ТБ данных, 200 млн пишущих транзакций в день.

Разберем: - Почему Debezium, а не триггеры или event-sourcing. - Основные проблемы: LOB-данные, длинные транзакции, SCN-шторм в Oracle и падения коннекторов. - Снятие снапшотов — доработка под большие таблицы, настройка и эффективная стратегия. - Трансформация данных на лету в пайплайне Debezium. - Подготовка Oracle и PostgreSQL для майнинга данных. - Настройка и доработка Debezium, и как масштабировать source connector вопреки документации. - Метрики мониторинга и допустимое время восстановления. - Какие доработки пришлось сделать, чтобы реализовать CI/CD по всем стендам - План — с чего начать, что проверять, как дорабатывать.

«Парни, теперь вы будете разрабами. И мы с вами напишем платформу LLM-инференса для облачных операторов». С такими словами я год назад пришёл к своей команде девопсов. Парни покрутили у виска. Но поверили.

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

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

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

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

Для ML/AI-задач стандартного планирования Kubernetes часто недостаточно: GPU-задачи конкурируют за ограниченные ресурсы, требуют очередей, приоритизации и более гибкого распределения вычислительных мощностей кластера. В докладе я покажу, зачем ML-инфраструктуре нужен отдельный планировщик GPU-задач, и разберу это на примере того, как мы реализовали это в Nova AI.

Основной фокус доклада - Volcano как практический инструмент для оркестрации GPU-нагрузок. Сравню его с Kueue и Kai Scheduler, объясню, как устроен Volcano, разберу динамическое дробление видеокарт.

Покажу прикладные кейсы: как настраивать очереди для задач разной важности, как Volcano можно использовать вместе с KubeRay для запуска распределенного инференса LLM.

В Яндексе активно используют монорепозитории и trunk‑based development — это ускоряет разработку: ежедневно в trunk вливают до 10 000 коммитов, а общая длина ветки превысила 21 миллион коммитов.

Масштабы выявили ограничения классических алгоритмов (в том числе из git) — пришлось адаптировать и оптимизировать подходы. В докладе расскажу, как мы ускорили работу с историей в Arc VCS на трёх уровнях: 1) лог коммитов: отказ от классического BFS и его оптимизация; 2) история файла: три реализации индекса и сравнение с решениями из svn и git; 3) blame: создание индекса для отображения авторства каждой строки.

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

Работая в крупной ритейл-компании, мы управляем более чем 12 000 потоками данных и хранилищем объёмом 12+ петабайт. Инженеры данных ежедневно работают с набором разрозненных инструментов: среды разработки, GitLab, Airflow, SQL-движки, различные сервисы хранения и трансформации.

Такой «зоопарк» увеличивает time-to-market, усложняет онбординг и создает зависимость от контекста конкретных людей и команд.

Мы решили объединить ключевые процессы разработки потоков данных в единую веб-платформу: одно входное окно для создания, редактирования и оркестрации пайплайнов, интегрированное с Airflow и GitLab через API.

В докладе расскажем: - как родилась идея и как мы её «продавали» внутри, - как проектировали архитектуру из 10+ микросервисов, - как решали задачи сложной интеграции, - почему выбрали low-code-подход, - какие ошибки допустили, - и какие результаты получили на текущем этапе.

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

Запустить Valkey в проде не очень сложно. Запустить его как Managed-сервис для тысяч клиентов с жесткими SLA - вызов, где стандартные инструменты ломаются один за другим. В этом докладе я расскажу о внутренней кухне нашего Managed Service for Valkey и поделюсь опытом эксплуатации.

Мы обсудим, почему мы выкинули встроенный Sentinel/Cluster failover и написали свой, как чтение AOF для бэкапов спасает нас от OOM-ов и как наш патч для PSYNC из AOF позволяет выкатывать обновления с рестартом, не перегружая primary-ноды генерацией RDB для реплик. Отдельно затронем суровую реальность эксплуатации сервиса на C: как организовать централизованный сбор minidump'ов без использования гигантских core-файлов и риска утечки пользовательских данных.

Будет много архитектуры и низкоуровневых деталей.

Каждый второй PostMortem заканчивается спором о причине, а половина «мер по недопущению» умирает в тексте документа. Мы построили инструмент — PostMortem Copilot, — который на базе LLM и поиска похожих инцидентов через MinHash LSH автоматически формирует гипотезу корневой причины, альтернативные версии, факторы инцидента и конкретные меры по четырём целям: «не повторится», «заметим раньше», «пострадаем меньше», «починим быстрее».

Расскажу, почему мы отказались от эмбеддингов в пользу коэффициента Жаккара, как эмпирически нашли оптимальный порог схожести, как построили AI-судью для объективного выбора LLM из десятка on-prem-моделей и почему модель — это лишь 30% успеха. Покажу продовые результаты. И расскажу, куда мы двигаемся дальше.

Современный NGFW обязан обрабатывать большие объемы зашифрованного трафика на скоростях до 400 Гбит/с, и бизнес больше не готов отключать функции безопасности ради производительности. Разрабатывая межсетевой экран с чистого листа, мы обошли классические ограничения, и все шло отлично, пока в этот идеальный конвейер не потребовалось встроить IPSec VPN. Обработка такого объема трафика всегда приводит к следующим проблемам: высокие требования к вычислительным ресурсам, плохой параллелизм, Elephant Flow и связанная с ним сложность балансировки нагрузки на несколько ядер CPU. Три вещи, которые вы унесёте с доклада. Каждая из них — не про VPN как таковой, а про приёмы, применимые к любому высоконагруженному приложению. Первая — понимание, где именно стандартный стек теряет производительность. Мы разберём классический путь пакета в Linux по стадиям и покажем, какие именно стадии не дают выйти за пределы. И почему тонкая настройка ОС не помогает на высоких скоростях. Вторая — набор архитектурных приёмов для высоконагруженного конвейера на примере NGFW. Отказ от использования функций ядра (kernel bypass), работа без копирования (zero copy), векторная обработка (vector processing), неделимый поток управления, аккуратная работа с памятью. Применимы к любому приложению, не только к NGFW. Третья — идеи, как параллелить то, что по природе плохо параллелится. VPN как раз из такого рода проблем. У нас есть поток данных, который хотелось бы обрабатывать параллельно на N ядрах, но параллельная обработка часто мешает, когда нам требуется поддерживать определенный порядок обрабатываемых данных, соблюдать консистентность общего состояния. Разберём каждый из пунктов на примере добавления IPSec в конвейер NGFW. На самом деле, приёмы универсальные, их может использовать каждый при решении своих задач, необязательно сетевых.

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

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

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

Давайте заглянем под капот WAF — как решений, к которым все привыкли, так и тех, что обрабатывают запросы совсем по-другому. Приходите послушать и обсудить, как ваш HTTP-запрос разбирается по кусочкам в поисках атак — ещё до того, как он доберётся до ваших backend-серверов.

Основная проблема:

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

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

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

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

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

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

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

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

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

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

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

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

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

Оптимизация - тема неиссякающая. Одним из классических методов оптимизации как для edge, так и для серверов является векторизация. При этом автовекторизация хорошо работает только на относительно простых задачах, а значит, актуальной остаётся задача ручной векторизации. Мы разработали небольшой кросс-платформенный векторный JIT-компилятор для x86, Arm и Risc-V - удобный инструмент для хардкор-оптимизаторов, пишущих на C++.

В докладе обсудим:

• Нишу нашего проекта, сравним его с разными JIT и AOT-решениями: xbyak, llvm, mir, rcc.

• Коротко остановимся на архитектуре и дизайне.

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

• Узнаем, как библиотека применялась в реальных проектах и какие результаты это принесло.

• Дальнейшие планы развития проекта.

Затраты на сериализацию — это налог, который платит любой сервис при записи и чтении данных. На больших объёмах классические подходы, такие как Protobuf, съедают слишком много ресурсов, а специализированные zero-copy-форматы (вроде FlatBuffers) требуют отказа от развитой экосистемы и усложняют интеграцию со смежными сервисами, где профиль нагрузки не требует таких оптимизаций. Чтобы решить эту проблему на масштабных нагрузках Рекламы Яндекса, мы разработали YaFF (Yet Another Flat Format).

В докладе расскажем, как сэкономить на десериализации, сохранив единую Protobuf-экосистему. Мы разберем архитектуру YaFF: как мир zero-copy объединяется с proto-схемами и привычными интерфейсами, а также чем приходится жертвовать ради нулевых аллокаций. На бенчмарках покажем, где именно достигается экономия железа, и посмотрим на готовые сценарии для оптимизации инфраструктуры. YaFF опубликован в opensource, так что все описанные подходы можно будет использовать в своих проектах.

Всё возрастающее энергопотребление на фоне развивающегося энергетического кризиса неизбежно ведёт к консолидации вычислительных ресурсов, в частности, в виде суперкомпьютерных систем с «человеческим лицом». Они должны представлять собой не кластер с SSH-доступом к виртуалкам, а user-friendly конечный продукт, предоставляющий дистанционным пользователям имитирующий вид обычной OS интерфейс, где привычным образом создаются, устанавливаются и запускаются программы, которые выполняются системой на предоставляемом кластером мощном оборудовании различного типа. В докладе предлагается снова обратить наше внимание к теме суперкомпьютеров, порассуждать об их важности, о том, какие они бывают и каким должно быть отвечающее современным вызовам суперкомпьютерное ПО, включая файловую и операционные системы. Будет сделан обзор существующего ПО для суперкомпьютеров как мировых, так и отечественных производителей. И, как это ни парадоксально, складывается ощущение, что за ситуацию в этой отрасли в РФ краснеть, вероятно, даже и не придётся.😉

Код проектов в DeFi имеет множество интересных особенностей, главная из которых - предельная лаконичность, интересные паттерны проектирования и максимальная оптимизация. Это прекрасно демонстрируют AMM (Automatic Market Makers) - децентрализованные пулы для обмена различных активов. Лучшие подобные проекты работают в полностью permissionless-среде, никем не управляются и представляют собой простые, красивые и законченные математические модели. Дневные объёмы этих проектов - десятки миллиардов долларов, топовые протоколы, строго следующие permissionless-паттернам, ни разу не были взломаны, и в этом заслуга минималистичного и элегантного дизайна. Доклад описывает основные идеи, алгоритмы и примеры кода и позволяет лично убедиться, что вся суть протокола и его безопасность могут базироваться буквально на одной строке кода. Базовая AMM - это пара сотен строк кода, которая на протяжении почти 10 лет без малейших изменений управляет миллиардами долларов, остается полностью актуальной и без сомнений является одним из самых демонстративных примеров применения блокчейн-технологий.

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

Используете Kubernetes? Автоматизируете управление инфраструктурой? Тогда вы уже пользуетесь Cloud Native-инструментами и практиками. Cloud Native-подходы выросли из облачного окружения, но могут применяться даже на bare metal. На основе данных исследования State of Cloud Native Russia 2026 и международных исследований покажем, какие инженерные capabilities ускоряют поставку, увеличивают стабильность продукта и повышают качество разработки. В докладе мы рассмотрим различные подходы, оценим их влияние на эффективность разработок и сравним эффекты их применения вне облачной среды. Рассмотрим три ключевых направления и их взаимное влияние: - AI-capabilities: как на эффективность команд влияют доступные ИИ-возможности: самостоятельная работа с контекстом, уровни автономности агентов и инструменты верификации результата. - Архитектурные и cloud-native-практики: какие свойства архитектуры и инфраструктуры упрощают внесение изменений, уменьшают связанность и стоимость эксплуатации, а также как это связано со скоростью разработки и стабильностью продукта. - DevSecOps capabilities: насколько безопасность интегрирована в стандартный процесс разработки, что удаётся автоматизировать и какие уровни контроля позволяют снижать риски без заметного уменьшения скорости поставки.

Компания Яндекс активно развивает направление автономного транспорта, в том числе развивается флот роботов-доставщиков. К 2027 году ожидаемый размер флота роботов-доставщиков оценивается в 20 тысяч устройств. Роботы-доставщики находятся постоянно на связи: передается в том числе видеоинформация камер.

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

Для достижения цели разработана методология оптимизации параметров кодирования и сравнения кодеков. Она опирается на общепринятые подходы: критерий BD‑Rate, точечный анализ для заданных значений битрейта/качества и сопоставление Rate‑Quality‑кривых. В ходе экспериментов варьировались ключевые параметры (промежуточное разрешение, Intra‑period, количество опорных кадров, HW Preset, тип битрейт‑контроля, размер буфера). Результат — снижение общего битрейта от четырёх камер робота-доставщика на 15 % при сохранении или улучшении визуального качества (до 30% на одной из камер)

Дополнительно оценены перспективные способы повышения эффективности сжатия: применение AV1‑энкодера (сокращение битрейта на ~10 %) и технологии Region of Interest (ROI) - перераспределение битрейта с периферийных участков в зону интереса — экономия 5–10 %. В качестве направлений дальнейшего развития выделены внедрение алгоритмов предобработки видео, полномасштабное использование AV1 и масштабирование ROI‑подхода.

В конце доклада рассмотрена задача сжатия 3D-облаков точек с использованием GPCC-стандарта и оригинальный ИИ-подход к ускорению кодека в практически автономном режиме на основе ИИ-технологий Яндекс. Приведено сравнение полученных результатов с индустриальным кодеком для облаков точек и полигональных моделей Draco, в том числе даны оценки полученной степени сжатия, достигнутого ускорения в сравнении с базовой версией (до 10 раз) и времени кодирования 1 облака точек (~ 500k точек)

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

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

Робот-доставщик встречает пешеходов, которые могут неожиданно пересечь его путь, и автомобили, маневрирующие в тесных придомовых зонах. Расскажем, как с помощью диффузионных моделей создавать таких интерактивных агентов и управляемые сложные сценарии для RL-обучения. Расскажем, как использовать диффузионные модели для создания интерактивных пешеходов в RL-симуляции. С помощью classifier-free guidance и LoRA-адаптеров можно усиливать редкие типы поведения и управлять сложностью обучающих ситуаций. Обсудим интеграцию модели в closed loop, генерацию целевых сценариев и практические проблемы реалистичности и устойчивости.

Доклад о построении системы обработки видео в реальном времени: от запуска модели YOLO и отслеживания объектов до подсчёта событий в нужных зонах, сохранения результатов, API и интерфейса для пользователей.

Главный акцент — решение реальных проблем, которые возникают при работе ML-сервиса: задержки, нестабильные видеопотоки (RTSP), нехватка CPU/GPU, качество бизнес-метрик, проверка результатов «глазами» и отслеживание ухудшения работы модели со временем.

Формат - доклад + демостенд

Компании, которой нельзя отдавать данные наружу, публичные API не помогут — нужен свой ИИ-стек. В ГНИВЦ мы собрали первую версию ИИ-песочницы целиком из open-source: инференс текстовых, мультимодальных и голосовых моделей, веб и API, RAG, наблюдаемость, агенты в контуре. Год назад одна A100, сейчас ~20 GPU, ~1000 пользователей, 60B токенов за 30 дней — подняли всё "двумя" руками. Расскажу, из чего собрать такую платформу и что забрать команде из 1–2 DevOps.

Мы хотели построить микросервисную SaaS-платформу, но вместо независимо развёртываемых сервисов получили распределённый монолит. Сервисы зависели от общей библиотеки контрактов, общались посредством RPC через RabbitMQ, обращались к базе данных и Redis через специальные микросервисы и образовывали циклические зависимости. В результате систему можно было тестировать и развёртывать только целиком, а один деплой занимал больше полутора часов. На реальных примерах я разберу архитектурные и инфраструктурные решения, которые постепенно сделали систему хрупкой: глобальную библиотеку с интерфейсами и DTO всех сервисов, преобладание интеграционных тестов и централизованные фикстуры, Supervisor внутри Docker-контейнеров, логирование через RabbitMQ. Доклад поможет распознать ранние признаки распределённого монолита и отличить локально удобное техническое решение от архитектурного антипаттерна. Я покажу не только последствия ошибок, но и причинно-следственные связи между ними, расскажу, какие компоненты системы пришлось переделывать и как расставлять приоритеты при распутывании подобных зависимостей.

Мы строим облачный гиперскейлер с нуля. Анализируя референсы, мы нашли интересный факт: в 2022 году AWS рассказал, что аутентифицирует более полумиллиарда API-запросов в секунду. Мы спросили себя: а сколько это в железе? И вместо оценок на салфетке собрали стенд проверки HMAC-подписей — сначала наивно, потом всерьёз.

Пройдём путь запроса от подписи до вердикта: каскад деривации ключей, SigV4 байт в байт, компактный кадр верификации вместо тяжёлого callout. Разгоним стенд с замерами «до/после» на каждом шаге — от 90 тысяч до миллиона RPS. По дороге — главный инсайт: выключение криптографии ускоряет систему лишь на 11%. Лимит миллиарда — не процессор, а сеть.

Все цифры — с открытой методикой и воспроизводимым кодом. Финал — честная арифметика миллиарда: тактов на запрос, терабиты на провод, узлы на стойку.

Шесть лет назад инциденты у нас считали в Excel, и вело эту таблицу даже не ИТ, а бизнес. Сегодня у нас есть централизованная наблюдаемость, SLO/SLI на собственной метрике "негативное влияние" и автоматизация инцидентов вплоть до ботов и AI-ассистентов.

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

В цифрах: MTTR снизился с 4 часов до 30 минут, доступность выросла до 99,9%. В конце дам чек-лист: с чего начать, если у вас нет своей SRE-команды.

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

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

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

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

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

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

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

Доклад о том, как превратить "если... то..." в проверяемую программу диагностики, которая: - работает на потоке телеметрии (метрики сессий, сетевые события, признаки соседних слоёв); - даёт воспроизводимую первопричину, а не "у каждого инженера своя версия"; - переживает миграцию сотен правил без "вроде ничего не сломали"; - остаётся понятной как для CI пайплайна так и для ИИ- агентов (стабильный идентификатор, объяснение, доказательства). Доклад про архитектуру диагностического движка: модель данных, контракт единиц измерения, смысл "события нет", ловушки миграции и граница с агентами (агент оркестрирует, движок решает).

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

AI-агенты уже стали частью разработки: они пишут код, проверяют решения и помогают командам двигаться быстрее. Но вместе с ускорением возникает более сложный вопрос: как управлять разработкой, в которой значительную часть работы выполняет агент? Готового универсального процесса здесь нет. У каждой компании свои продукты, ограничения, уровень риска и инженерная культура. Поэтому чужой пайплайн нельзя просто скопировать. Зато можно опереться на принципы, которые остаются неизменными независимо от команды и набора инструментов. В докладе разберём принципы работы с автономными агентами: кто задаёт намерение, в каких границах агент действует самостоятельно, как проверяется результат, где сохраняются полученные знания и как на основе обратной связи развивается сама система разработки. Посмотрим, как эти принципы превращаются в практические механизмы, а затем складываются в конкретный процесс с учётом продукта, команды и уровня риска. Вы унесёте с собой систему координат, по которой сможете выстроить собственную работу с AI-агентами.

Главная идея. Появление AI-агентов меняет не только скорость написания кода, но и само устройство разработки, Поэтому управлять нужно уже не отдельными действиями разработчика, а всей системой совместной работы людей и агентов. Универсального AI-процесса при этом не существует. У каждой организации свои продукты и требования безопасности, устройство команд и технологическая среда. Чужой пайплайн нельзя перенести один в один. Но можно перенести принципы: устойчивые правила, из которых команда может собрать подходящие ей механизмы и процесс.

Расскажем про вторую S в SDLC и как мы ищем баланс между традиционными appsec инструментами и AI в сопровождении безопасности разработки. Снизим нагрузку и шум от SAST-сканеров с помощью динамически формируемых рулсетов с учетом ландшафта и направлений разработки, построим граф вызовов и посчитаем на нем трассы от пользовательского ввода до уязвимой функции в нетривиальных кейсах, таких как sqli или SCA, независимо от того, умеет ли сканер в taint, соберем расширенный контекст по оставшимся сработкам для анализа LLM и appsec-ом.

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

Обсудим основные идеи, которые позволили нарастить производительность: замену интерпретации VRL-кода на JIT-компиляцию с использованием движка V8, ленивое декодирование и раннее кодирование событий, оптимизации над графом обработки.

Опишем control plane, который мы построили над новыми кластерами нормализации: failover, мониторинг, управление версиями пайплайнов и A/B-тестирование.

Мы расскажем о нашем опыте адаптации ОС РВ из китайской экосистемы openEuler к отечественному ландшафту - работе на разных архитектурах, имеющихся в наличии (классический x86-64, модный RISC-V), особенностях взаимодействия с китайским комьюнити, проблемах портирования и первого запуска. Постараемся ответить на вопрос - зачем нужна еще одна ОС РВ там, где есть QNX?

Поделимся реальным опытом миграции высоконагруженной системы авторизации и аутентификации (ЕСИА) c Oracle на PostgreSQL. Расскажем, как мигрировать распределенный монолит с 70+ приложениями, 200 таблиц, 200+ Тб данных, 160+ бизнес процессов с одной СУБД на другую. В рамках доклада разберём: как решить задачу по переходу системы на другую СУБД, когда у вас наслоение «так исторически сложилось» за 15 лет; разные подходы к способам миграций больших систем; как обеспечить консистентность данных при миграции; как переключить систему с одной СУБД на другую с минимальной недоступностью ключевых функций; мониторинг, логирование, утилиты проверки: что нам очень помогло; как доработать модель данных для PostgreSQL, чтобы производительность не уступала Oracle

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

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

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

1. Проектирование архитектуры сервиса, направленной на минимизацию задержки передачи сигнала на всех этапах информационного обмена — от городского API до сервисного уровня и далее до клиентского приложения.
2. Обеспечение устойчивой работы сервиса при высокой нагрузке, предполагающей одновременное обслуживание сотен тысяч сессий, соответствующих активным поездкам.
3. Реализация механизмов отказоустойчивости, гарантирующих непрерывность функционирования сервиса в случае выхода из строя нескольких его инстансов.
4. Оптимизация конфигурации базы данных и каналов доставки данных, включая проработку специфических аспектов их настройки для достижения максимальной эффективности и надёжности системы.
5. Переход от HTTP-поллинг-клиента к событийной схеме на websocket.

Расскажу о том, почему это нетривиальная задача - ответить на такие вопросы, как: - Сколько видеокарт нужно, чтобы разместить LLM? - Насколько быстро LLM будет отвечать в определенной конфигурации? - Какая конфигурация лучшая?

Старый SaaS умирает: «один интерфейс для всех» больше не работает. Код писать стало дёшево, фичи у всех одинаковые. Выигрывает тот, кто собирает сервис под конкретного пользователя в момент сессии — его кнопки, его метрики, его сценарий.

Персонализация — это архитектура, а не фича. Трехслойная модель: неизменяемое ядро + профиль пользователя как данные (JSON в Redis/PostgreSQL) + рендер-слой, который собирает UI. ИИ-агент обновляет профиль на основе поведения, но не пишет код и не трогает UI — это ключевой архитектурный выбор.

Безопасность — это архитектурное ограничение, а не компромисс. Утечка невозможна в принципе — потому что так спроектировано.

HaskiMail - сервис email-транспорта. Казалось бы, что там персонализировать? Отправил — получил. Но нет. Разработчик заходит в сервис и через неделю видит интерфейс, заточенный под его задачи, без единого клика в настройках.

Сколько стоят деньги? Но не в рублях или долларах, а в токенах? Вот и мы решили посчитать наконец, чего это стоит и почему. Расскажу о пути от заражения наших серверов майнинг-вирусом до рождения из этого нового продукта, который позволил решить проблему безопасности, и самое важное - выжимать из 100 долларов подписки все 10000 долларов :)

Специалисты по виртуализации и Kubernetes, dev-ops и ML/AI-инженеры работают с разными технологиями, но сталкиваются со смежными вопросами об архитектуре, ресурсах и эксплуатации ИТ-инфраструктуры.

На примере zVirt Community обсудим, как участники развивают не только продукт, но и сообщество, а что в такой разговор приносит команда вендора.

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

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

А что если делать крутое облако, полностью с нуля и как самостоятельный инфраструктурный бизнес? Облако здорового человека. Здесь начинается самое интересное!

Neocloud в классическом понимании — это облако под ИИ-нагрузки: свежие GPU и сеть, которая не давится при перекачке датасетов и весов. Но у большинства «новых облаков» мощная GPU-пушка установлена на тщедушного ослика — рядом с ускорителями стоят древние серверы на тормозных каналах. Мы собрали флот на B300, честные 400G до каждого хоста и compute только на Xeon 5/6 с DDR5 — и это лишь половина neocloud. Вторая половина — облако, построенное под ИИ-агентов, а не только под ИИ-нагрузки.

Каким должно быть современное облако? За сколько его можно сделать? Нужен ли штат из 500 разработчиков? Нужны ли 7,5 миллиарда рублей инвестиций? И самое важное: как сделать не дубль всех этих облаков, а действительно neo cloud, сочетающий в себе все основы надежной эксплуатации и работы с агентами в современных инфраструктурах? В общем, милости просим.

1. Как мы за пару месяцев масштабировали платформу до 2000 ИИ-агентов и чего нам это стоило?
2. Как дать бизнес-пользователям возможность самостоятельно создавать агентов без участия разработчиков и длинной цепочки согласования требований?
3. Как устроена единая мультиагентная платформа для разработчиков и сотрудников без технической подготовки?
4. Где проходит граница self-service: какие задачи бизнес может автоматизировать сам, а где всё ещё нужен разработчик.
5. Как сделать создание тысяч агентов безопасным: доступы к данным, инструменты, ограничения, аудит и контроль действий.

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

Обсуждение методологии статического анализа в разрезе ГОСТ Р 71207—2024: суть стандарта, как выбрать инструмент, как внедрить в процесс разработки. Связь стандарта с РБПО (ГОСТ Р 56939—2024), с методикой ВУ и НДВ 2026, с "Профилем защиты" ЦБ РФ и т. д.

расскажем про эволюцию разработки нового LAMP

Агенты и LLM везде. У нас много внедрений и видна объективная картина рынка. Практики бывают самые передовые, а бывают отстающие. Но одно понятно точно - AI уже очень глубоко проник в процессы написания кода. Код пишет агент, дебажит агент, коммитит агент и ревьюит агент. А потом он же и деплоит иногда. А IDE все равно нужна и никуда от нее не деться. А почему? Поговорим на докладе.

Проблема «зоопарка» метрик и отсутствия доверия: В докладе разбирается реальный кейс, когда два аналитика посчитали одну и ту же метрику (CTR) по-разному, получив противоположные результаты (Lift -18,3% и +8,83%). Мы обсудим, почему это происходит и как централизация экспериментов на платформе устраняет методологические ошибки и «поиск виноватых».

Экономическая эффективность: когда платформа окупается? Вы узнаете, как оценить целесообразность внедрения A/B-платформы, используя дерево решений «Build vs Buy». Мы разберем три сценария (SaaS, Open-source, собственное решение) и сравним их по срокам внедрения, TCO и скрытым рискам (вендор-лок, стоимость упущенных возможностей).

От теории к практике: расчет ROI: как на основе вводных данных (средний чек, количество экспериментов, средний lift) рассчитать реальный бизнес-эффект. Вы увидите, как выбрать решение, которое максимизирует прибыль, а не просто «покупает софт».

X.509-сертификаты обычно воспринимаются как готовый способ сделать систему безопаснее: включили HTTPS, настроили mTLS, добавили доверенные CA — и задача решена. На практике дьявол кроется в деталях: непонимание назначения полей сертификатов, неправильное использование списков отзыва, soft-fail-проверки доверия и многое другое.

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

Хакеры используют украденные учетные записи, легитимные в инфраструктуре компании, и стандартные средства удаленного доступа, такие как RDP, SSH и другие. Это делает хакеров невидимыми для традиционных систем сетевой безопасности.

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

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

Что делать, если один расчёт длится от десятков минут до нескольких часов, модели становятся всё тяжелее, а локальное исполнение перестаёт масштабироваться вместе с их сложностью?

В докладе поговорим о том:

• почему модель "микросервис + autoscaling" не всегда подходит для тяжёлых математических расчётов;
• где проходит граница между сервисной архитектурой и HPC;
• как меняется архитектура, когда главная метрика - не RPS, а time-to-result;
• зачем поверх вычислительного кластера нужна отдельная платформа;
• и какие новые задачи становятся возможны, когда вычислительные ресурсы перестают быть главным ограничением.

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

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

С цифрами и костылями. И с тремя вопросами, на которые стоит ответить, прежде чем нанимать своего первого виртуального сотрудника.

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

Мы собрали свой подход — Genome — и обкатываем его на платформе B2B-продаж МТС: 3 команды, десятки интеграций.

В докладе:

• как давать агенту только нужный под задачу контекст;
• как передавать работу между ролями и проверять её на каждом стыке;
• реальный эпик: как Genome не дал нам пообещать бизнесу невыполнимый срок.
• Подход не привязан к модели и инструменту — его можно забрать к себе по частям.

Большинство Text2SQL-систем по-прежнему строятся вокруг одной гипотезы: если SQL получился неправильным, модели не хватило контекста. Поэтому начинает переписываться промпт, к нему добавляются фрагменты схем хранилища, метаданные из data catalog и задача вновь отправляется той же модели. В production DWH упрётся в потолок 35% качества. Если у вас есть впечатление, что семантический слой - не серебряная пуля, решающая задачу Text2SQL, то вы правы.

Приходите на доклад, где мы разберём: * как создать agent-facing-проекцию данных хранилища и перестать угадывать решения задач, которые не описаны в скиллах; * почему важно создать таксономию Human-in-the-Loop как контракт между человеком и Text2SQL; * какие есть способы генерации SQL агентами и зачем их динамически выбирать по риск-метрикам; * какие эксперименты и метрики позволяют доказать, что сгенерированный SQL содержит ответ на вопрос пользователя.

Когда поиском пользуется человек, профиль запросов относительно предсказуем. Агент способен за одну пользовательскую задачу сделать серию вариативных вызовов API, поэтому дорогой retrieval может превратиться в риск каскадной деградации. Я расскажу, как мы готовим поиск в 360 на примере поиска по почте и календарю к такой модели нагрузки; Я подробно разберу как на примере календарных данных которые создают неприятную развилку: повторяющиеся встречи нужно представить в поисковом индексе, а одно событие может быть связано со множеством пользователей. Мы сознательно переносим тяжёлую работу в поставку и индексацию и заранее готовим поисковое представление событий, чтобы путь запроса оставался коротким и предсказуемым. Разберём trade-off между стоимостью индексации и сложностью чтения, цену быстрого retrieval и границы применимости такого подхода, а также как это влияет на надежность всей системы в условиях современных агентов.

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

Что вы увидите вживую: работу десяти агентных окон в реальном времени; приём смены и точки, где нужны мои решения; ревьюера (параллельный harness), который принимает код без меня; hooks-гейты и протокол взаимодействия между агентами; честную экономику дня (что ушло на токены, что на моё время). Отдельно разберу устройство своего harness с долговременной памятью.

Всё это применяется в первый же рабочий день: правила «что отдать агенту и какое правило за это платит», шаблоны постановки и ревью, промпт критика. А свой предел параллельности (сколько окон вести именно вам) посчитаем на месте.

Представьте SRE-инженера, который в 4 раза быстрее человека, не устаёт и с радостью поднимается по тревоге в три часа ночи. Именно такого виртуального сотрудника — AIOps-агента на базе OpenClaw — мы попробуем создать и протестировать на настоящей аварии прямо на сцене. Вы сами выберете, что ломать, и сделаете ставки — справится ли агент!

Сначала мы посмотрим на «наивную» реализацию агента, а потом — прокачаем его до зубов! Посмотрим, как изменятся его поведение, скорость работы и расход токенов. А в промежутках поговорим про open-source-инструменты и модели для AIOps, результаты опроса и курьёзные случаи.