Доклады конференции Saint HighLoad++ 2026

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

This talk is highly applicable to backend engineers, SREs, and architects working with high-concurrency APIs, microservices, or Fintech stacks. By using Pix as a concrete, battle-tested case study, you will walk away with proven strategies for enforcing latency as a hard design constraint, applying heavy cryptography (mTLS, XML envelope signatures), and protecting your core infrastructure from cascading failures or internal DDoS vectors.

Фундаментальный доклад, из которого вы узнаете (или вспомните), что такое CAP и PACELC, зачем нужны Saga и 2PC. А также на реальных примерах увидите, как выбор между консистентностью, доступностью и задержкой осуществляется не на уровне системы в целом, а на уровне отдельных шагов бизнес-операций.

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

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

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

В докладе я расскажу:

• Про "3 уровня прожарки данных" (Rare, Medium, Well-Done) и почему без уровня Rare корпоративный обмен данными невозможен.

• Как мы ушли от ненадежных автономных чат-агентов («Agentic AI») к детерминированным пайплайнам (AI Flow) со строгими контрактами на стыках.

• Как "научить" локальные модели (Qwen, DeepSeek) решать задачи Data Governance, и сравним их с облачной Gemini.

• Почему без глубокого промпт-инжиниринга локальные LLM проваливают задачи ИБ, и какие техники реально работают.

• Разберем архитектуру системы автоматической классификации чувствительных данных на базе событий (Event-driven) из каталога OpenMetadata.

Расскажу какие есть варианты построение сетевой связности для bare-metal узла Kubernetes через BGP или L2 связность.

Применение технологии FPGA в продуктах компании UserGate. Для чего мы используем аппаратное ускорение, какие преимущества нам это даёт и какие у нас текущие результаты. Один из примеров применения, это повышения производительности системы предотвращения вторжений. Во многих наших платформах мы имеем возможность увеличивать производительность IDPS на x*12 Гбит/с, где x – это количество дополнительных модулей ускорения, которые мы можем вставлять в платформы.

В инженерии классический RAG не работает: семантический поиск легко путает допуски («0.02» вместо «0.012» на чертеже), а модели не видят топологию изделия (Болт ➝ Насос ➝ Двигатель). В докладе я разберу архитектуру CosmoSphere — гибридную систему поиска в закрытом контуре. Вы узнаете: Ядро: Как мультимодальная Nemotron-3-Omni-30B (Mamba+MoE) нативно совмещает чтение ГОСТов и сложный OCR чертежей без внешней каскадной обработки. Память: Скрещивание графовой базы FalkorDB и Qdrant для «триангуляционного поиска» (подъем точности с 60% до 94%, галлюцинации <2%). Инференс: Как уложить мультимодальный конвейер, обход графа и LLM-ризонинг в 80GB VRAM с помощью TensorRT-LLM и Triton без падений по OOM. Чистота: Сборка SOTA-стека из компонентов, доступных для Enterprise-контура в 2026 году.

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

В рамках доклада рассматриваются следующие вопросы:

• построение распределённой архитектуры:
компромиссы распределённых систем (CAP), мультимастер-репликация, механизмы HWM/UTD, организация Pull-модели синхронизации, совместимость версий и обеспечение репликации при поэтапном обновлении системы;

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

Greenplum стал closed source. Но мы продолжаем развивать его в Apache Cloudberry. Как емко заметил в свое время Andy Pavlo, основной проблемой Greenplum было то, что никто больше не ставил его добровольно. Мы хотим это изменить. Например, добавили новый формат хранения PAX. PAX - колоночное хранилище для гибридной транзакционной и аналитической обработки. Ближайший аналог - parquet/orc. Зачем еще один формат? Краткий ответ - для производительности, потому нужны еще и улучшения в движок выполнения запросов, чтобы сделать аналог zone maps и bloom filter из parquet. Детали нового формата PAX и улучшений в движке запросов расскажу в докладе.

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

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

Больше Постгресов богу Постгреса! Давайте на своём ноуте накодим себе доработанный напильником Постгрес: соберём, изучим внутренности, что-то улучшим, что-то сломаем, всё протестируем и надёжно склеим скотчем.

Расскажу, как MongoDB работает в реальной продакшн-среде: как хранилище, кеш, брокер сообщений, time-series и распределенная база данных. Покажу, где она действительно справляется и позволяет упростить стек, а где на практике пришлось перейти на специализированные решения: Redis, Kafka, VictoriaMetrics. Поделюсь архитектурными компромиссами, эксплуатационными нюансами и выводами, которые помогают трезво выбирать инструменты.

Работая в крупных компаниях, я часто сталкивался с мнением, что батчевую разработку можно переделать на потоковую. Иногда дело заходило дальше и создавались платформы, которые позволяли реализовывать потоковую обработку при помощи SQL. К примеру, в Райфе основой потоковой обработки был SQL, а исполнителем этого SQL - Apache Flink. Подходило это решение не везде, далеко не везде. Давайте на примере Apache Flink разбёремся, где потоковую разработку на SQL невозможно реализовать, где можно - но только с костылями, а где SQL справляется с задачей.

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

Знания многих о модуле TPM 2.0 ограничиваются тем, что он зачем-то обязательно (или не очень) нужен для установки Windows 11. В своём докладе я хочу пролить свет на его функционал, рассказать как он устроен и как с его помощью можно защищать свои секреты (и секреты своих пользователей). Так же я расскажу, что нужно, чтобы достучаться до него из своего кода и поделюсь утилитой, которую я специально написал для тестирования возможностей этого модуля и демонстрации принципов его работы.

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

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

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

На воркшопе мы разберём Langfuse — open source инструмент наблюдаемости для AI-приложений. Покажем, как организовать централизованный мониторинг ИИ-агентов и прямо на месте сделаем демо-агента наблюдаемым. Участники научатся трассировать вызовы LLM, собирать метрики, оценивать качество ответов и выполнять диагностику агентов так же, как и обычных продовых сервисов и приложений. Минимум слайдов, максимум практики: реальный агент, реальный прод-подход и живое инструментирование вместе с аудиторией.

Важно! Для участия в данном формате с собой необходимо иметь ноутбук. Код для воркшопа и требования к подготовке по ссылке: https://github.com/bocharovf/langfuse-workshop

Postmortem-анализ является одним из ключевых инструментов повышения надежности ИТ-систем, поскольку позволяет выявлять корневые причины сбоев и снижать риск их повторения. По мере усложнения ИТ-ландшафта, роста числа взаимосвязей между сервисами и усиления экосистемного взаимодействия проведение такого анализа в ручном режиме требует все больших временных и организационных затрат. При этом ожидания бизнеса остаются неизменными: критически важные системы должны восстанавливаться быстро, а разбор инцидентов — быть глубоким, системным и приводить к предотвращению аналогичных событий в будущем. В докладе будет представлен практический опыт развития postmortem-процесса в нашей компании: от создания централизованного подразделения Mission Control Center и формализации единых подходов для экосистемы до отказа от Excel- и Word-документов в пользу специализированных инструментов, автоматизации рутинных операций и создания Postmortem Copilot. Особое внимание будет уделено тому, как поэтапная автоматизация позволила сократить трудоемкость анализа критичных инцидентов и при этом сохранить необходимый уровень качества и полноты разбора. Результатом внедрения данного подхода стало существенное ускорение postmortem-анализа: время выполнения рутинной части процесса сократилось с 4–6 часов до 30 минут. Дополнительно был внедрен контроль качества проведенного анализа критичных инцидентов, что способствовало повышению эффективности восстановления критически важных систем; соответствующий показатель улучшился на 26% год к году. В настоящее время мы развиваем гибридный подход к автоматизации postmortem-процесса с применением методов искусственного интеллекта и машинного обучения в сочетании с ручной экспертной валидацией. В рамках доклада будет показано, какие этапы postmortem-анализа целесообразно автоматизировать в первую очередь, где проходит граница применимости AI/ML-подходов и почему сохранение экспертного участия остается необходимым условием для достижения баланса между скоростью и качеством анализа критичных инцидентов.

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

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

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

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

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

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

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

Внедрение ИИ-инструментов провоцирует у разработчиков всех уровней компетенций фундаментальный кризис идентичности:

• смещение из роли «создателя» в роль «контролёра ИИ» воспринимается ими как потеря статуса и профессиональной ценности
• исчезает «момент победы» - удовлетворение от самостоятельного решения сложных задач.

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

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

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

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

С трансформацией процессов разработки в сторону Agentic Development Lifecycle (ADLC) количество уязвимостей и возможностей для атаки в инфраструктуре растёт пропорционально числу агентов. Каждый агент имеет привилегии для управления инфраструктурой, работы с инструментами, доступа к данным. Компрометация такого агента открывает доступ ко всему, с чем он работает.

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

AI-агенты уже умеют писать код, но на больших проектах быстро упираются в навигацию: читают слишком много файлов, тратят лишние токены, медленно находят нужные символы и часто теряют контекст из-за базовых инструментов (grep / read). В докладе расскажу про ast-index — Rust CLI для структурной индексации кода через Tree-sitter и SQLite/FTS5. Покажу метрики и в общем расскажу про применение инструмента и как он появился.

GigaChat это уникальная российская LLM, которую обучают, оптимизируют и масштабируют в продакшне. Голосовые ассистенты, управление роботами, мультимодальность — всё держится на одной текстовой модели.

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

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

Что заберёте с собой: — Стоимость обучения LLM: где уходят ресурсы и как это сократить — Оптимизация цикла исследований: от данных до экспериментов — Почему одна базовая текстовая модель выигрывает у зоопарка специализированных — Продакшн-кейсы и российской LLM

Мы строим платформу инференса и обычно пропагандируем идею "локальные LLM в продакшн". Но для средних и малых компаний рекомендация часто будет противоположная: не надо начинать с покупки GPU. В докладе покажу, где именно ломается экономика локального инференса и почему "поставим vLLM на свою карту" не равно "получим дешёвый продакшн-сервис".

Разбор будет через TCO. RTX 5090 можно арендовать за 50-90 тыс. рублей в месяц или купить за 300-500 тыс., но железо — только первая строка затрат. Дальше появляются ДЦ, электричество, охлаждение, сеть, мониторинг, деплой, кусочек или полный DevOps на поддержку и несколько человеко-месяцев на запуск. Даже если модель даёт хорошие tok/s в бенчмарке, карта ночью простаивает, днём упирается в потолок, а среднемесячная загрузка редко похожа на провайдерские 50-70%.

В конце разберём исключения: ИБ или регуляторика; GPU-парк в наследство от прошлого проекта; CAPEX, который проще защитить, чем OPEX; подозрительно постоянная нагрузка/training, под которую железо можно занять почти круглосуточно. В остальных случаях сначала стоит смотреть на API/OpenRouter, отечественные сервисы с оплатой по токенам или аренду GPU на короткий тест.

LLM в продакшене - это не только качество ответов, но и управляемая производительность под реальной нагрузкой. В self-hosted сценариях на итог влияет много факторов: от выбранного движка до объёма памяти. В докладе я покажу, как мы в Магните построили воспроизводимый пайплайн нагрузочного тестирования для выбора подходящей LLM и настройки конфигов сервинга - с упором на возможность повторить это на своём железе. Мы разберём, как организовать нагрузочные тесты на Locust для корректного измерения TTFT/ITL/TPS, находить порог стабильности и избежать искажения результатов из-за упрощённых условий тестирования. Отдельно продемонстрирую, какие сигналы в observability помогают объяснять деградации и подтверждать эффект изменений.

Две части: первая сильно техническая (как устроено) - минут на 25, вторая перетекает из первой - как с этим жить - на оставшиеся 15

-- Первая часть

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

1. Что под капотом: весь низкоуровневый флоу того, что происходит после команды "сделай мне фичу Х"

   • Контекстное окно и харнесс
   • Токенизатор и его особенности работы с кодом
   • Проблемы контекстного окна, компактизация

2. Поиск кода: поиск, сигналы и документация

   • векторный поиск против разновидностей grep, плюсы и минусы подходов
   • high-signal tokens как философия ретрива
   • культура документации и сложности

3. Экономика: где горит бюджет

   • cache-hit и ttl
   • План/реакт и effort
   • cost per call / per outcome

4. Код как дашборд

   • Какая телеметрия появилась
   • acceptance vs revert
   • silent drift & regression set

-- Вторая часть: Ключевой тейк: изменение скорости написания кода требует переосмысления SDLC целиком, а не просто одной части.

1) Что происходит со структурой команды — стафф-лок тает (когда знание про то как работает Х у одного-двух человек) — специализации размываются (T-shape становится шире, вертикаль мельче) — численность команд падает

2) Как меняется культура работы и процессы - толерантность к перетурбациям инструментво (новый софт скилл) - изменение роли код-ревью - дисциплина эвалов становится общей на разработку вместо только ML

3) Новые боттлнеки и роли людей - что становится узким местом - как меняется иерархия в команде

Финальный вывод о том что инструменты становятся не просто инструментами - они меняют весь процесс и требуют его переосмысления

Аналитики тратят часы на SQL-запросы, которые «почти как в прошлый раз, но не совсем». Каждая BI-система — свой синтаксис, каждый дашборд — ручная работа, каждая выгрузка — снова с нуля. Знакомо?

А что если просто написать: «Посчитай MAU и выручку по тарифам с 2025 года» — и получить готовый интерактивный график через 30 секунд?

Воркшоп построен по слоям. Сначала поднимаем рабочую среду и снимаем главную боль: агент читает схему вашей БД, историю запросов и отвечает на бизнес-вопросы на человеческом языке — без SQL вручную.

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

OpenCode — MIT open source, работает в терминале, без IDE и регистраций. Поддерживает 75+ провайдеров: Claude, GPT, Gemini и локальные модели через Ollama — данные не покидают вашу инфраструктуру.

Что заберёте с собой: - Поднятый рабочий стек с AI-агентом, настроенным под аналитику - Готовый AGENTS.md и понимание, как масштабировать решение в команде - Навык итеративного построения AI-инструментов: от прототипа до продакшена

Что сможете вписать в резюме: - Опыт построения AI-агентов для аналитики данных - Работа с OpenCode, ClickHouse, Redash, MCP в связке - Внедрение LLM-инструментов в data-процессы с учётом enterprise-требований

В эпоху активного развития больших языковых моделей перед разработчиками часто встает дилемма: как совместить преимущества нескольких специализированных моделей, обученных на разных задачах, не запуская при этом множество моделей одновременно? В докладе мы рассмотрим актуальную проблему объединения параметров языковых моделей (model merging) и познакомимся с существующими подходами: от простого усреднения весов до методов LoRA merging и Task Arithmetic. Вы узнаете, почему традиционные методы часто приводят к деградации качества и как можно это исправить.

Мы представим новый метод Significant Deltas Merging with Weights (SDM-W), который позволяет интеллектуально объединять модели, учитывая только значимые изменения параметров и автоматически определяя вклад каждой модели. На практических примерах покажем, как метод помогает создать универсальную модель, которая одинаково хорошо справляется с генерацией кода, вызовом тулов и корпоративными задачами. Результаты экспериментов демонстрируют сохранение 95-98% точности при экономии до 30% вычислительных ресурсов.

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

Пройдем путь от незащищенного агента к укрепленному, с примерами атак и фиксов: обход логики системных промптов с примерами из контестов и багбаунти, обходы ML guardrails с помощью сдвигов текста, шифрования ответов, смены языка и др. LLM guardrails через подбор состязательных суффиксов/префиксов, кейсы из Web3 (например, атака на автономных агентов с переводом активов), Telegram/Discord/Twitter агентов и мультиагентов

Практическая ценность: - Алгоритм аудита для своих LLM-агентов: как выявить уязвимости вроде prompt-injection или supply chain атак. - Шаблоны защит: опенсорсные инструменты (Ml Guardrails, Llama Guard, выбран за эффективность в блокировке 99.997% jailbreaks по тестам на 300k промптах). - Ссылки на таксономию уязвимостей промптов и сравнение моделей от нас (из исследования апрель 2025), и от Pangea (август 2025) - Ссылки на OWASP Top-10 LLM, AI agents, MITRE и предлагаемые ими схемы защиты

AI-агенты в enterprise без контекста — дорогие игрушки. Мы в Райффайзенбанке построили две платформы — Context Annotation (разметка бизнес- и технического контекста организации) и Context Memory (персистентная память агентов о клиенте) — которые дают агентам связное представление "модели мира" организации и клиента. Расскажу, как мы пришли к этой архитектуре, какие грабли собрали и какие результаты получили на трёх кредитных продуктах.

Тезисы (общие): Токены растут вверх в цене, голый Claude или Codex уже не может удовлетворять требованиям современной разработки, но выход есть. Если хорошо настроить окружение, то можно вернуть старый добрый в 2025. Как это сделать - расскажу в своем докладе

Что происходит после фразы “давайте просто развернём open-source модель у себя”? На опыте Битрикс24 разберу грабли self-hosted AI: контекст, vLLM, GPU-пулы, evals, качество, стоимость и миллионы запросов в месяц. На выходе - чек-лист решений и метрик, который поможет оценить готовность к своим моделям и не сжечь бюджет на железе.

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

Архитектурное соревнование надо? Викторина по System Design и Архитектуре в live режиме! Будет яростный челендж по протоколам, архитектуре, паттернам и антипаттернам! А также по истории IT! Участники пройдут заранее отборочный этап на канале system_design_world. Записывайтесь! Сильнейшие ТОП-4 выйдут в финал уже на самой конференции! Где покажут чьи архитектурные мозги оказались сильнее! Окунитесь в мир System Design, участвуйте и болейте за своего финалиста!

Как context engineering заменяет prompt engineering Под капотом AI-агентов: как собирается контекст и почему он важнее модели AI-readability: как сделать проект понятным для AI-агентов Best practices: AGENTS.md, CONTEXT.md, MCP, Skills и toolchains Максимальный контекст: интеграция AI-агентов с трекером задач, CI и коллекторами ошибок

Как превратить LLM из обычного чат-бота в рабочий инструмент разработки 🔥

На этом воркшопе мы ближе познакомимся с мультиагентной разработкой, разберём подход Spec-Driven Development, а также в live-режиме сделаем фичу для небольшого проекта.

В рамках разработки фичи мы последовательно будем использовать разные роли, через которые обычно проходит задача в продуктовой команде:

• системный аналитик

• backend-разработчик

• frontend-разработчик

• тестировщик

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

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

(!) Для интерактивного участия требуется наличие ноутбука с софтом для вайбкодинга.

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

Средства ИИ разработки позволят нам не тратить время на boilerpalte-ы для Solidity, Python, JS и сосредоточиться на демострации работы различных видов сервисов, оперирующих криптоактивами.

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

Внедрение AI в разработку ПО - тема новая, но весьма горячая, и материалов про то, как внедрять самое новое и самое прогрессивное в интернете достаточно.

Чего в интернете не достаточно, так это практических руководств по внедрению AI именно в процессную часть разработческой рутины.

Фактически, я хочу рассказать о своем тернистом пути:

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

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

Доклад продолжает разговор о State of AI4SDLC (https://devopsconf.io/moscow/2026/abstracts/17935) и фиксирует, что AI в разработке уже перестал быть просто экспериментом, так как он массово используется для всех основных сценариев: coding, review, planning, debugging и работы с документацией. И теперь вопрос в том, а как встроить ускорение отдельных сценариев вокруг в наш продакшен цикл разработки: с понятной целью, достаточным контекстом, корректной интеграцией, доверием к результату и измеримым эффектом. И главное как это сделать не просто в стартапе или в greenfield проектах, а в устоявшейся компании в которой сотни, если не тысячи инженеров работают над созданием и развитием AI продуктов.

Кто такой CTO? Архитектор, психолог, менеджер, продавец, или кто-то ещё?

Почему вам не надо становиться СТО? А если очень-очень хочется, с чем придётся столкнуться?

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

Кажется, что если платформа живет внутри BigTech, то там уже все давно правильно спроектировано, обдумано и выстрадано. Спойлер: нет. Боли есть всегда. В любой доменной платформе. Если это не BigTech, а стартап — боли там тоже есть, просто о них еще не знают. А потом мы все дружно и героически их чиним. И периодически сами же снова создаем — потому что никто из нас не идеален, особенно когда домен еще не прожит и времени на «сначала подумать» традиционно нет.

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

Мы возьмем четыре платформенных домена, которые довольно часто одновременно существуют внутри одного BigTech: — FinTech — Compliance — заказы и корзина в e-commerce — каталог и витрины и посмотрим на них как на одноранговые системы.

Потому что самое интересное — не в различиях. Самое интересное — в том, насколько одинаково они ломаются.

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

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

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

Это разговор для тех, кто хотя бы раз приходил в новую компанию, смотрел на платформу и думал: «О, опять ОНО!».

А вы уже в AI-native разработке? Или просто выдали разработчикам Claude/Cursor и считаете, что внедрили AI? Или построили сквозной процесс с общим контекстом? Или вся агентная инфраструктура уже работает автономно, а людям оставлены HITL-вставки в критичных точках? Кто-то застрял на начальных этапах, кто-то пытается перепрыгнуть стадии и запрыгнуть в полную автоматизацию.

В докладе:

— разберу мировые и локальные модели оценки зрелости AI в разработке;

— покажу, как честно определить, на каком уровне находится ваша команда или компания;

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

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

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

Проектирование WAL — это поиск инженерного компромисса между скоростью записи, временем фиксации транзакций, временем восстановления после сбоя и надёжностью системы хранения. В зависимости от требований, для каждой отдельной СУБД этот компромисс будет решатся по-разному.

В докладе я покажу модель принятия решений при проектировании WAL на примере PostgreSQL, SQLite и DuckDB, а также расскажу, как в OtterBrix мы построили собственный WAL.

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

Название: Почему инженеры не становятся фаундерами. 5 блокеров и методика преодоления. Описание: Четыре раза я выбирал роль CTO, а не фаундера. Стартап в Испании, ЛитРес, Kion, VK Cloud. Каждый раз находились причины: то рано, то рынок не тот, то времени нет, то денег жалко. Сейчас, уйдя в независимые и запуская свое, я понимаю: каждая из этих "причин" была конкретным блокером. Три из них сидели в голове, два маскировались под психологию, но на самом деле были задачами на операционную модель и тайм-менеджмент. В РФ разработчиков больше, чем почти где угодно. Стартапов из этих разработчиков рождается непропорционально мало. Причины есть и структурные (рынок, регулирование, капитал), и личные. В докладе разбираю вторые: пять конкретных блокеров, которые тормозят переход инженера в фаундера. Три психологических, два структурных. По каждому: формулировка, кейс из своего опыта, конкретная методика, чек-лист.

Что заберете с собой: - Карта 5 блокеров инженера на пути к стартапу с методикой преодоления каждого - Документ "Готовность к стартапу: 5 срезов" (навыки, перфекционизм-тест, команда, финансовая модель, карта недели) - Фреймворк минимального стека фаундера, который собирается за 2 месяца - Шаблон бизнес-эксперимента до первой строчки кода - Понимание, какой из блокеров ваш, и конкретный первый шаг по нему

В IT появился новый язык, на котором все уже говорят, но словарь ещё никто не согласовал. Что такое AI-native компания? AI-native, AI-first, AI Engineer, Prompt Engineer — эти слова все чаще в вакансиях и стратегиях. Но пока мы понимаем их по-разному. Решили вместе обсудить и собрать первый живой AI-глоссарий сообщества. Посмотрим, где получится договориться, а где споры только начнутся.

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

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

Как если из словосочетания «Внутреннее CRM-решение» исчезнет слово «внутреннее».

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

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

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

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

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

К корпоративным ресурсам компании уже давно подключаются не только сотрудники. С распространением облачных сервисов и ИИ-помощников доступ получают приложения, автоматизированные бизнес-процессы и ИИ-агенты. Пароля и двухфакторки недостаточно для надежной защиты. 90% успешных кибератак начинаются с компрометации учетных данных, а 80% инцидентов проходят в обход двухфакторной аутентификации. Нередко в инфраструктуре компании можно найти давно забытую учётку с админ-правами, которую несколько лет назад создал уволенный девопс. Про неё никто ничего не знает, но удалить страшно — вдруг что-то перестанет работать. Чтобы такие истории не превращались в инциденты, к Identity Security нужно подходить комплексно. В докладе разберём Identity Security Platform — решение, в котором все взаимосвязано: Устойчивая к современным кибератакам MFA. IDM и IGA для управления жизненным циклом учетных записей и контроля доступа. Directory Services и Certificate Authority как альтернатива классическому Microsoft AD. Тру SSO, объединяющее веб, легаси и десктоп-приложения в единую сессию (и да, с Single Log Out тоже). Контроль привилегированного доступа, принцип минимальных привилегий и новые подходы к управлению ИИ-агентами. Разберём, как всё это работает вместе, выстраивается в единую систему и заменяет набор разрозненных инструментов.

Расскажу о том, как Read IT Club трансформирует обучение в мире ИТ, занимаясь рецензированием и переводом технической литературы. Мы обеспечиваем точность терминологии и иллюстраций, чтобы книги оставались надежным источником знаний и уменьшали путаницу среди читателей. Покажу, как наш подход увеличивает доступность информации для русскоязычного сообщества и помогает избежать ошибок, которые могут помешать пониманию технологий. Поделюсь опытом книжных дебагеров: от ценности, получаемой благодаря сотрудничеству с издательствами, до навыков, которые помогают сделать качественный выбор литературы для обучения.

Мы расскажем, как мы строили отказоустойчивый Low Code поверх сразу 4х СУБД PostgreSQL/Oracle/RED/YDB в период импортозамещения

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