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

Расписание конференции

Скачать программу

Программа продолжает формироваться

Расписание будет меняться

30 ноября

Конгресс холл

Пекин-Шанхай

Дели-Калькутта

Сан-Паулу

Рио-де-Жанейро

Кейптаун

09:30

10:00

10:50

11:10

12:00

12:20

13:10

13:30

14:20

14:40

15:30

15:50

16:40

17:00

17:50

18:10

19:00

09:30

10:00

10:50

11:10

12:00

12:20

13:10

13:30

14:20

14:40

15:30

15:50

16:40

17:00

17:50

18:10

19:00

Открытие конференции

09:30 — 10:00 / 30.11

Залы: «Конгресс холл», «Пекин-Шанхай», «Дели-Калькутта», «Сан-Паулу», «Рио-де-Жанейро», «Кейптаун»

Доклад

Биржа на миллиард из одной строки кода, или добро пожаловать в AMM (Automatic Market Maker)

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

Сергей Прилуцкий (MixBytes)

10:00 — 10:50 / 30.11

Зал «Сан-Паулу»

Классический HighLoad++

Слот в разработке

10:00 — 10:50 / 30.11

Залы: «Дели-Калькутта»

Слот в разработке

10:00 — 10:50 / 30.11

Залы: «Рио-де-Жанейро»

Доклад

Харнес, который написал сам себя: SDLC highload-проекта на 100 агентов

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

Направление при поддержке

Андрей Носов (Raft)

10:00 — 10:50 / 30.11

Зал «Конгресс холл»

AI-агенты: как доверять результату и контролировать действия?

Доклад

Читаем с реплики в 2026

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

Андрей Бородин (Yandex Cloud)

10:00 — 10:50 / 30.11

Зал «Пекин-Шанхай»

Базы данных под нагрузкой

Доклад

YaFF: как zero-copy-представление в Protobuf помогает экономить железо

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

Даниил Гавриловский (Яндекс)

10:00 — 10:50 / 30.11

Зал «Кейптаун»

Когда стандартной производительности уже недостаточно

Перерыв

10:50 — 11:10 / 30.11

Залы: «Конгресс холл», «Пекин-Шанхай», «Дели-Калькутта», «Сан-Паулу», «Рио-де-Жанейро», «Кейптаун»

Перерыв

10:50 — 11:10 / 30.11

Залы: «Конгресс холл», «Пекин-Шанхай», «Дели-Калькутта», «Сан-Паулу», «Рио-де-Жанейро», «Кейптаун»

Перерыв

10:50 — 11:10 / 30.11

Залы: «Конгресс холл», «Пекин-Шанхай», «Дели-Калькутта», «Сан-Паулу», «Рио-де-Жанейро», «Кейптаун»

Перерыв

10:50 — 11:10 / 30.11

Залы: «Конгресс холл», «Пекин-Шанхай», «Дели-Калькутта», «Сан-Паулу», «Рио-де-Жанейро», «Кейптаун»

Перерыв

10:50 — 11:10 / 30.11

Залы: «Конгресс холл», «Пекин-Шанхай», «Дели-Калькутта», «Сан-Паулу», «Рио-де-Жанейро», «Кейптаун»

Перерыв

10:50 — 11:10 / 30.11

Залы: «Конгресс холл», «Пекин-Шанхай», «Дели-Калькутта», «Сан-Паулу», «Рио-де-Жанейро», «Кейптаун»

Доклад

26 гейтов недоверия: как мы отдали прод AI-агенту

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

Направление при поддержке

Волков Денис (Сбер), Разумовский Дмитрий (Сбер)

11:10 — 12:00 / 30.11

Зал «Конгресс холл»

AI-агенты: как доверять результату и контролировать действия?

Доклад

Векторный, полнотекстовый и гибридный поиск в YDB: контекст для моделей на реальных данных

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

Александр Зевайкин (YDB)

11:10 — 12:00 / 30.11

Зал «Пекин-Шанхай»

Базы данных под нагрузкой

Мастер-класс

Мы наняли ИИ, что дальше? Или техноэкстремизм, который мы заслужили

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

Направление при поддержке

Георгий Меликов (Exordos)

11:10 — 12:00 / 30.11

Зал «Кейптаун»

AI-агенты: как доверять результату и контролировать действия?

Доклад

Отечественная кластерная суперкомпьютерная OS: правда или вымысел

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

Сторожилов Илья (КуБорд (ООО "ОКТ"))

11:10 — 12:00 / 30.11

Зал «Сан-Паулу»

Классический HighLoad++

Мастер-класс

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

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

Евгений Харченко (Независимый эксперт), Сергей Пищуленок (Райффайзен Банк)

11:10 — 13:10 / 30.11

Зал «Дели-Калькутта»

AI-агенты: как доверять результату и контролировать действия?

Мастер-класс

OpenClaw против хаоса: сможет ли SRE-агент справиться с авариями?

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

Филипп Бочаров (МТС Web Services (MWS))

11:10 — 13:10 / 30.11

Зал «Рио-де-Жанейро»

AI-агенты: как доверять результату и контролировать действия?

Перерыв

12:00 — 12:20 / 30.11

Залы: «Конгресс холл», «Пекин-Шанхай», «Сан-Паулу», «Кейптаун»

Перерыв

12:00 — 12:20 / 30.11

Залы: «Конгресс холл», «Пекин-Шанхай», «Сан-Паулу», «Кейптаун»

Перерыв

12:00 — 12:20 / 30.11

Залы: «Конгресс холл», «Пекин-Шанхай», «Сан-Паулу», «Кейптаун»

Перерыв

12:00 — 12:20 / 30.11

Залы: «Конгресс холл», «Пекин-Шанхай», «Сан-Паулу», «Кейптаун»

Бэкап-апокалипсис: ищем альтернативные решения для БД размером в 100+ терабайт, когда стандартные решения бессильны!

Стандартные инструменты резервного копирования полностью пасуют, когда объем базы данных переваливает за сотню терабайт. Логические дампы и классическое копирование файлов превращаются в бесконечный процесс длиной в сутки, который уничтожает производительность дисков, перегружает процессоры и гарантированно срывает RTO. В случае масштабной аварии восстановление распределенной системы может затянуться на недели, что неприемлемо для бизнеса. В докладе мы разберем реальный опыт эксплуатации сверхкрупных распределенных СУБД на базе MongoDB и Cassandra и найдем альтернативные решения для защиты данных с минимальным влиянием на продуктив. Вот основные тезисы доклада: Проблема: Почему стандартные утилиты неприменимы на огромных объемах. Физические ограничения дисковой подсистемы и иллюзия безопасности бэкапов.Инфраструктурный путь: Создание мгновенных снимков файловой системы через LVM-снапшоты на изолированных репликах. Математика капасити-планирования: формулы расчета прироста дисковой нагрузки (RPS) и идеального сайзинга области изменений. Опасности скрытой нагрузки механизмов Copy-on-Write и жесткий тротлинг процессов на уровне ядра Linux.Эксплуатационные хаки: Риски нарушения консистентности распределенных данных и появление orphaned-документов при восстановлении. Использование встроенной репликации для бэкапа и физическое клонирование файлов реплик с попутным решением проблемы дефрагментации.Нативный NoSQL-подход: Организация параллельного распределенного бэкапа по диапазонам токенов в Cassandra для линейного масштабирования скорости.Инфраструктура хранения: Сравнение объектных хранилищ, сетевых шар и распределенных файловых систем для эффективного размещения бэкапов. Сравнение подходов и матрица выбора решений. Выводы и заключение: Бэкап огромных БД – сложная техническая задача, так как стандартные подходы и инструменты не работают. Без применения нестандартных подходов риск потери данных становится неприемлемым.

Андрей Комягин (STM Labs)

12:20 — 13:10 / 30.11

Зал «Пекин-Шанхай»

Базы данных под нагрузкой

Доклад

Изучаем аномалии поведения систем с помощью исследовательского тестирования

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

Секция при поддержке

Цитман Дмитрий (Мир Plat.Form)

12:20 — 13:10 / 30.11

Зал «Кейптаун»

Нагрузка растет, а система теряет устойчивость

Мастер-класс

Как работать за десятерых, но получать один оклад

Год назад я запускал один агентный поток и успевал читать каждую строку кода. Сегодня у меня до десяти параллельных окон агентной разработки, и держать в голове каждый поток физически невозможно. Если у вас так же, то вы не одиноки. Это новая инженерная дисциплина, у которой пока нет учебника. Но есть этот мастер-класс. Он для разработчиков и тимлидов, у которых уже работают агенты. Что вы увидите вживую: работу десяти агентных окон в реальном времени; приём смены и точки, где нужны мои решения; ревьюера (параллельный harness), который принимает код без меня; hooks-гейты и протокол взаимодействия между агентами; честную экономику дня (что ушло на токены, что на моё время). Отдельно разберу устройство своего harness с долговременной памятью. Всё это применяется в первый же рабочий день: правила «что отдать агенту и какое правило за это платит», шаблоны постановки и ревью, промпт критика. А свой предел параллельности (сколько окон вести именно вам) посчитаем на месте.

Максим Шаланкин (MWS)

12:20 — 14:20 / 30.11

Зал «Сан-Паулу»

AI-агенты: как доверять результату и контролировать действия?

Доклад

Обвязка важнее модели: AI-поиск уязвимостей в микросервисах

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

Направление при поддержке

Михаил Юматов (ЦИАН), Эрик Шахов (Циан)

12:20 — 13:10 / 30.11

Зал «Конгресс холл»

AI-агенты: как доверять результату и контролировать действия?

Перерыв

13:10 — 13:30 / 30.11

Залы: «Конгресс холл», «Пекин-Шанхай», «Дели-Калькутта», «Рио-де-Жанейро», «Кейптаун»

Перерыв

13:10 — 13:30 / 30.11

Залы: «Конгресс холл», «Пекин-Шанхай», «Дели-Калькутта», «Рио-де-Жанейро», «Кейптаун»

Перерыв

13:10 — 13:30 / 30.11

Залы: «Конгресс холл», «Пекин-Шанхай», «Дели-Калькутта», «Рио-де-Жанейро», «Кейптаун»

Перерыв

13:10 — 13:30 / 30.11

Залы: «Конгресс холл», «Пекин-Шанхай», «Дели-Калькутта», «Рио-де-Жанейро», «Кейптаун»

Перерыв

13:10 — 13:30 / 30.11

Залы: «Конгресс холл», «Пекин-Шанхай», «Дели-Калькутта», «Рио-де-Жанейро», «Кейптаун»

Доклад

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

В крупной компании задача проходит цепочку ролей — от владельца продукта до разработки — и на каждой передаче теряет контекст. ИИ-агенты эту проблему не решают: всё знание о продукте в них не помещается, а готовые инструменты рассчитаны на одного разработчика и один репозиторий. Мы собрали свой framework разработки — Genome — и обкатываем его на платформе B2B-продаж МТС: 5 команд разработки, десятки интеграций. В докладе: как давать агенту только нужный под задачу контекст, соблюдая корпоративные стандарты;как передавать работу между ролями через агентов и проверять её на каждом стыке;реальный эпик: как Genome не дал нам пообещать бизнесу невыполнимый срок;Подход не привязан к модели и инструменту — его можно забрать к себе по частям.

Илья Кудряшов (MWS), Игорь Симонов (MWS)

13:30 — 14:20 / 30.11

Зал «Рио-де-Жанейро»

AI-агенты: как доверять результату и контролировать действия?

Доклад

ИИ-конвейер разработки полного цикла в Диасофт: от кнопки "сделать" до релиза на прод

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

Направление при поддержке

Старов Дмитрий Владимирович (Диасофт), Петров Илья Валерьевич (Диасофт)

13:30 — 14:20 / 30.11

Зал «Пекин-Шанхай»

AI-агенты: как доверять результату и контролировать действия?

Доклад

Как мы адаптировали SDD для 100+ микросервисов

Агенты разработки сделали написание кода быстрее, но перенесли узкое место в понимание исходного замысла, подбор контекста и проверку результата. Расскажу, как мы адаптировали OpenSpec для нескольких репозиториев и межсервисных изменений. Выбрали режим spec-anchored, зафиксировали границы владения и добавили независимую проверку реализации. Разберём потерю замысла между задачей, спекой и кодом, бесконечные замечания ревью-агентов и мастер-спеки, на которые уходили месяцы. Отдельная проблема: объём текста, который инженеру приходится вычитывать. Что заберёте с собой: - Классификацию пяти отказов агентов - Правила фиксации границ изменения и матрицу приёмки со ссылками на строки кода - Сравним режимы работы со спецификациями и определим, каким задачам нужен полный контур, а где он лишь задерживает релиз

Направление при поддержке

Рамиль Мамедов (Сбер)

13:30 — 14:20 / 30.11

Зал «Кейптаун»

AI-агенты: как доверять результату и контролировать действия?

Доклад

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

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

Олег Табота (Яндекс Еда)

13:30 — 14:20 / 30.11

Зал «Дели-Калькутта»

Базы данных под нагрузкой

Слот в разработке

13:30 — 14:20 / 30.11

Залы: «Конгресс холл»

Перерыв

14:20 — 14:40 / 30.11

Залы: «Конгресс холл», «Пекин-Шанхай», «Дели-Калькутта», «Сан-Паулу», «Рио-де-Жанейро», «Кейптаун»

Перерыв

14:20 — 14:40 / 30.11

Залы: «Конгресс холл», «Пекин-Шанхай», «Дели-Калькутта», «Сан-Паулу», «Рио-де-Жанейро», «Кейптаун»

Перерыв

14:20 — 14:40 / 30.11

Залы: «Конгресс холл», «Пекин-Шанхай», «Дели-Калькутта», «Сан-Паулу», «Рио-де-Жанейро», «Кейптаун»

Перерыв

14:20 — 14:40 / 30.11

Залы: «Конгресс холл», «Пекин-Шанхай», «Дели-Калькутта», «Сан-Паулу», «Рио-де-Жанейро», «Кейптаун»

Перерыв

14:20 — 14:40 / 30.11

Залы: «Конгресс холл», «Пекин-Шанхай», «Дели-Калькутта», «Сан-Паулу», «Рио-де-Жанейро», «Кейптаун»

Перерыв

14:20 — 14:40 / 30.11

Залы: «Конгресс холл», «Пекин-Шанхай», «Дели-Калькутта», «Сан-Паулу», «Рио-де-Жанейро», «Кейптаун»

Доклад

"Деревянные рубли" и еще 4 ошибки: как small-tech строила надежность без SRE-команды

Шесть лет назад инциденты у нас считали в Excel, и вело эту таблицу даже не ИТ, а бизнес. Сегодня у нас есть централизованная наблюдаемость, SLO/SLI на собственной метрике "негативное влияние" и автоматизация инцидентов вплоть до ботов и AI-ассистентов. Расскажу о пяти ошибках, которые мы совершили по дороге: - ждали идеальной модели; - сами решили, что важно бизнесу (те самые "деревянные рубли"); - сделали Zabbix центром всего; - добавляли мониторинг уже после сбоя; - автоматизировали хаос. В цифрах: MTTR снизился с 4 часов до 30 минут, доступность выросла до 99,9%. В конце дам чек-лист: с чего начать, если у вас нет своей SRE-команды.

Антон Скутин (Петрович-Тех)

14:40 — 15:30 / 30.11

Зал «Кейптаун»

Нагрузка растет, а система теряет устойчивость

Доклад

Код перестал быть узким местом: пять этапов перехода к AI-first-разработке

Команда из 6 backend-разработчиков переносила монолит Яндекс.Афиши B2B на событийную архитектуру. Агенты ускорили написание кода, но ревью захлебнулось. Затем выяснилось: перенос старой логики без продуктовой проработки создаёт новое легаси. Пройдём пять этапов: от агента для unit-тестов до эксперимента с автономной разработкой сервисов. Путь до автономных агентов, которые он закрывают около 50% задач, пишут примерно 75% нового кода в сервисе. Попытка отдать им архитектуру провалилась. Архитектуру и E2E-тесты вернули инженерам, проверку сервисов построили вокруг контрактов и автотестов. На докладе разберём, где на каждом этапе возникало следующее узкое место, какие задачи подходят для AI и зачем понадобились рамоки контроля. Что заберёте с собой: - карту узких мест на каждом из пяти этапов - рамки контроля внедрения AI: ревью по OpenAPI и protobuf, контрактные и нагрузочные тесты, границы эксперимента на некритичных компонентах. Покажем, как применять их в работе.

Направление при поддержке

Юрий Шашкин (Яндекс)

14:40 — 15:30 / 30.11

Зал «Конгресс холл»

AI-агенты: как доверять результату и контролировать действия?

Доклад

Маверик: 100 000 обращений за 2 месяца — как построить агентную платформу, которая доводит 90% задач до результата без человека

Когда 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; — выбрать метрики, которые показывают реальную пользу агента.

Виталий Лукин (X5 Tech)

14:40 — 15:30 / 30.11

Зал «Дели-Калькутта»

AI-агенты: как доверять результату и контролировать действия?

Слот в разработке

14:40 — 15:30 / 30.11

Залы: «Сан-Паулу»

Эволюция борьбы с гонками в WMS Ozon: как мы обрабатываем миллионы операций и избегаем рассинхронизации данных

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

Максим Рауба (Ozon)

14:40 — 15:30 / 30.11

Зал «Пекин-Шанхай»

Архитектура и распределенные системы

Доклад

Экономика AI без иллюзий: когда внедрение окупается, а когда становится новой строкой затрат

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

Направление при поддержке

Кирилл Евсеенко (СберЗвук)

14:40 — 15:30 / 30.11

Зал «Рио-де-Жанейро»

Экономика AI-инструментов

Перерыв

15:30 — 15:50 / 30.11

Залы: «Конгресс холл», «Пекин-Шанхай», «Дели-Калькутта», «Сан-Паулу», «Рио-де-Жанейро», «Кейптаун»

Перерыв

15:30 — 15:50 / 30.11

Залы: «Конгресс холл», «Пекин-Шанхай», «Дели-Калькутта», «Сан-Паулу», «Рио-де-Жанейро», «Кейптаун»

Перерыв

15:30 — 15:50 / 30.11

Залы: «Конгресс холл», «Пекин-Шанхай», «Дели-Калькутта», «Сан-Паулу», «Рио-де-Жанейро», «Кейптаун»

Перерыв

15:30 — 15:50 / 30.11

Залы: «Конгресс холл», «Пекин-Шанхай», «Дели-Калькутта», «Сан-Паулу», «Рио-де-Жанейро», «Кейптаун»

Перерыв

15:30 — 15:50 / 30.11

Залы: «Конгресс холл», «Пекин-Шанхай», «Дели-Калькутта», «Сан-Паулу», «Рио-де-Жанейро», «Кейптаун»

Перерыв

15:30 — 15:50 / 30.11

Залы: «Конгресс холл», «Пекин-Шанхай», «Дели-Калькутта», «Сан-Паулу», «Рио-де-Жанейро», «Кейптаун»

Доклад

Гарантированная доставка на Госуслугах: миллиард доставленных заявлений в год

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

Сергей Станиславский (РТЛабс)

15:50 — 16:40 / 30.11

Зал «Пекин-Шанхай»

Архитектура и распределенные системы

Доклад

Когда защите нужна защита: как мы ломали и восстанавливали Антиробот Яндекса

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

Секция при поддержке

Иван Тямгин (Яндекс)

15:50 — 16:40 / 30.11

Зал «Кейптаун»

Нагрузка растет, а система теряет устойчивость

Слот в разработке

15:50 — 16:40 / 30.11

Залы: «Рио-де-Жанейро»

Доклад

PostMortem Copilot: как LLM + MinHash LSH снижают повторяемость инцидентов

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

Евгений Лачугин (МТС Диджитал)

15:50 — 16:40 / 30.11

Зал «Дели-Калькутта»

Нагрузка растет, а система теряет устойчивость

Доклад

Real-time обновление HNSW: последний шаг к свежим данным в RecSys

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

Александр Смолин (Яндекс)

15:50 — 16:40 / 30.11

Зал «Сан-Паулу»

Архитектура и распределенные системы

Доклад

Self-Improving Software Factory: от AI-агентов к автономному SDLC

Что такое 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 постепенно улучшает сама себя.

Направление при поддержке

Андрей Неведин (Райффайзен Банк)

15:50 — 16:40 / 30.11

Зал «Конгресс холл»

AI-агенты: как доверять результату и контролировать действия?

Перерыв

16:40 — 17:00 / 30.11

Залы: «Конгресс холл», «Пекин-Шанхай», «Дели-Калькутта», «Сан-Паулу», «Рио-де-Жанейро», «Кейптаун»

Перерыв

16:40 — 17:00 / 30.11

Залы: «Конгресс холл», «Пекин-Шанхай», «Дели-Калькутта», «Сан-Паулу», «Рио-де-Жанейро», «Кейптаун»

Перерыв

16:40 — 17:00 / 30.11

Залы: «Конгресс холл», «Пекин-Шанхай», «Дели-Калькутта», «Сан-Паулу», «Рио-де-Жанейро», «Кейптаун»

Перерыв

16:40 — 17:00 / 30.11

Залы: «Конгресс холл», «Пекин-Шанхай», «Дели-Калькутта», «Сан-Паулу», «Рио-де-Жанейро», «Кейптаун»

Перерыв

16:40 — 17:00 / 30.11

Залы: «Конгресс холл», «Пекин-Шанхай», «Дели-Калькутта», «Сан-Паулу», «Рио-де-Жанейро», «Кейптаун»

Перерыв

16:40 — 17:00 / 30.11

Залы: «Конгресс холл», «Пекин-Шанхай», «Дели-Калькутта», «Сан-Паулу», «Рио-де-Жанейро», «Кейптаун»

Доклад

Единая веб-платформа для инженеров данных: как мы объединили 10+ микросервисов и сократили time-to-market

Работая в крупной ритейл-компании, мы управляем более чем 12 000 потоками данных и хранилищем объёмом 12+ петабайт. Инженеры данных ежедневно работают с набором разрозненных инструментов: среды разработки, GitLab, Airflow, SQL-движки, различные сервисы хранения и трансформации. Такой «зоопарк» увеличивает time-to-market, усложняет онбординг и создает зависимость от контекста конкретных людей и команд. Мы решили объединить ключевые процессы разработки потоков данных в единую веб-платформу: одно входное окно для создания, редактирования и оркестрации пайплайнов, интегрированное с Airflow и GitLab через API. В докладе расскажем: - как родилась идея и как мы её «продавали» внутри, - как проектировали архитектуру из 10+ микросервисов, - как решали задачи сложной интеграции, - почему выбрали low-code-подход, - какие ошибки допустили, - и какие результаты получили на текущем этапе. Это практический кейс о создании внутреннего продукта для data-инженеров: с реальными ограничениями по ресурсам, итерациями, отказами и эволюцией решения.

Никита Калганов (X5 Tech)

17:00 — 17:50 / 30.11

Зал «Кейптаун»

Архитектура и распределенные системы

Доклад

История на миллион коммитов: как мы работаем с графом истории в Arc VCS

В Яндексе активно используют монорепозитории и trunk‑based development — это ускоряет разработку: ежедневно в trunk вливают до 10 000 коммитов, а общая длина ветки превысила 21 миллион коммитов. Масштабы выявили ограничения классических алгоритмов (в том числе из git) — пришлось адаптировать и оптимизировать подходы. В докладе расскажу, как мы ускорили работу с историей в Arc VCS на трёх уровнях: 1) лог коммитов: отказ от классического BFS и его оптимизация; 2) история файла: три реализации индекса и сравнение с решениями из svn и git; 3) blame: создание индекса для отображения авторства каждой строки. Вы узнаете, как устроены привычные инструменты, где упираются в ограничения по производительности и как их можно ускорить. Покажу одну из самых старых строк в кодовой базе Яндекса — пример кода, который живёт без изменений уже 20 лет.

Юрий Чернышов (Yandex Infrastructure)

17:00 — 17:50 / 30.11

Зал «Сан-Паулу»

Классический HighLoad++

Доклад

Как обнаружить атаку среди легитимных действий: ML без дополнительного ПО на хостах

Хакеры используют украденные учетные записи, легитимные в инфраструктуре компании, и стандартные средства удаленного доступа, такие как RDP, SSH и другие. Это делает хакеров невидимыми для традиционных систем сетевой безопасности. Если для перемещения или вредоносных действий используются IoT-устройства или хосты, на которых не установлены агенты, такая активность может остаться незамеченной даже самыми передовыми агентскими средствами защиты и SIEM. В докладе будет рассматриваться опыт применения различных ML-моделей и их ансамблей для детектирования вредоносной активности, связанной со взломом и последующим использованием легитимных учетных записей и протоколов удаленного доступа и дальнейшего развития атаки.

Станислав Грибанов (Гарда )

17:00 — 17:50 / 30.11

Зал «Дели-Калькутта»

Классический HighLoad++

Доклад

Как приземлить форк LangFlow на банковский энтерпрайз: от инструмента AI-автоматизации для сотрудников до масштабируемого ассистента на миллион клиентов

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

Георгий Дьячков (Альфа-банк)

17:00 — 17:50 / 30.11

Зал «Пекин-Шанхай»

Архитектура и распределенные системы

Доклад

Сказ о том, как девопсы писали платформу LLM-инференса для облачных провайдеров

«Парни, теперь вы будете разрабами. И мы с вами напишем платформу LLM-инференса для облачных операторов». С такими словами я год назад пришёл к своей команде девопсов. Парни покрутили у виска. Но поверили. Мы годами строили и эксплуатировали инфраструктуру. Я и ключевые члены команды успели поработать по обе стороны отношений оператор-вендор. Представления о хорошем инфраструктурном софте у нас были, как и представления о плохом. Теперь предстояло проверить, как мы справимся сами. Расскажу, зачем мы взялись писать собственный Kubernetes Operator и стоило ли ли оно того. Как проектировали систему, в которой отказ управляющей части не должен останавливать пользовательские запросы. И как выбирали, чем провайдер будет управлять через наш API, а что платформа должна делать сама. Будут и интересные повороты. Автомасштабирование, на которое я возлагал большие надежды, ждала неожиданная судьба. Веб-интерфейс, собранный для себя, клиенты потребовали включить в продукт. А автоматический мониторинг моделей, который мы считали само собой разумеющимся, неожиданно вызвал восторг. Каждый эпизод начинается с ситуации из нашей работы: какие варианты были, что выбрали и что получилось. На этих примерах покажу, какие требования оправдывают собственную разработку, где можно обойтись готовыми компонентами и какие предположения стоит проверить прежде, чем вкладываться в сложную функцию.

Егор Андреев (Впрод)

17:00 — 17:50 / 30.11

Зал «Рио-де-Жанейро»

Архитектура и распределенные системы

Слот в разработке

17:00 — 17:50 / 30.11

Залы: «Конгресс холл»

Перерыв

17:50 — 18:10 / 30.11

Залы: «Конгресс холл», «Пекин-Шанхай», «Дели-Калькутта», «Сан-Паулу», «Рио-де-Жанейро», «Кейптаун»

Перерыв

17:50 — 18:10 / 30.11

Залы: «Конгресс холл», «Пекин-Шанхай», «Дели-Калькутта», «Сан-Паулу», «Рио-де-Жанейро», «Кейптаун»

Перерыв

17:50 — 18:10 / 30.11

Залы: «Конгресс холл», «Пекин-Шанхай», «Дели-Калькутта», «Сан-Паулу», «Рио-де-Жанейро», «Кейптаун»

Перерыв

17:50 — 18:10 / 30.11

Залы: «Конгресс холл», «Пекин-Шанхай», «Дели-Калькутта», «Сан-Паулу», «Рио-де-Жанейро», «Кейптаун»

Перерыв

17:50 — 18:10 / 30.11

Залы: «Конгресс холл», «Пекин-Шанхай», «Дели-Калькутта», «Сан-Паулу», «Рио-де-Жанейро», «Кейптаун»

Перерыв

17:50 — 18:10 / 30.11

Залы: «Конгресс холл», «Пекин-Шанхай», «Дели-Калькутта», «Сан-Паулу», «Рио-де-Жанейро», «Кейптаун»

Доклад

Вайбкодинг в облаке: API, документация и деплой под агента, а не под человека

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

Александр Сербул (Битрикс24)

18:10 — 19:00 / 30.11

Зал «Конгресс холл»

AI-агенты: как доверять результату и контролировать действия?

Доклад

Комплаенс как системный анализ: как формулировать требования по 152-ФЗ, ФСТЭК и КИИ, чтобы их можно было реализовать в highload-системе

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

Татьяна Маркина (ТризТех (PT))

18:10 — 19:00 / 30.11

Зал «Сан-Паулу»

Работа в условиях блокировок и нестабильной связности

Доклад

Найти, изменить и доказать: как внутри устроены кодовые агенты

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

Направление при поддержке

Дмитрий Антипов (Группа Сбер / VSRobotics)

18:10 — 19:00 / 30.11

Зал «Пекин-Шанхай»

AI-агенты: как доверять результату и контролировать действия?

Доклад

От TLS до подписи: все способы неправильно использовать сертификаты

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

Максим Башканков (YADRO)

18:10 — 19:00 / 30.11

Зал «Дели-Калькутта»

Классический HighLoad++

Доклад

Свой "Claude Cowork" внутри контура компании - как мы прикрутили OpenCode к GitLab и получили универсального внутрикорпоративного агента для самых разных задач.

Публичные ИИ-ассистенты (вроде Claude в роли цифрового коллеги) удобны и эффективны, но для бизнеса они часто неприемлемы: конфиденциальные данные уходят вовне, отсутствует единая ролевая модель доступа, а прогнозировать и контролировать затраты на API практически невозможно. В российских реалиях добавляется критический риск: зарубежный сервис могут в любой момент ограничить, заблокировать или отключить без предупреждения. Мы спроектировали и внедрили собственную on-premise альтернативу: OpenCode в качестве среды выполнения (runtime) и GitLab как слой хранения, версионирования и синхронизации. Агент работает полностью внутри закрытого контура компании и никак не зависит от доступности внешнего SaaS. В докладе разберем: Персональные и общие данные: как разграничить права доступа и настроить бесшовную синхронизацию контекста через Git. Оптимизацию ресурсов: сколько изолированных сред выполнения (sandbox) реально поднять на одном сервере и как можно оптимизировать расход памяти. FinOps и онбординг: как контролировать расходы (по пользователям, группам и моделям) и обучать сотрудников эффективной работе с агентом без «слива» бюджета на старте. Аналитику баз знаний (RAG): как отслеживать утилизацию документов и выявлять «мертвый груз». Стратегический выбор: стоит ли инвестировать в разработку собственного агента ради технологической независимости и безопасности.

Направление при поддержке

Иван Красников (wikilect.com)

18:10 — 19:00 / 30.11

Зал «Кейптаун»

Работа в условиях блокировок и нестабильной связности

Слот в разработке

18:10 — 19:00 / 30.11

Залы: «Рио-де-Жанейро»