Доклады конференции 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, которая превращает вероятностную «магию» нейросетей в предсказуемый и надежный конвейер обогащения метаданных. В докладе я расскажу: - Как мы ушли от ненадежных автономных агентов («Agentic AI») к детерминированным цепочкам задач (AI Flow) со строгими типизированными контрактами на стыках. - Как "научить" локальные модели решать задачи Data Governance и сравним их производительность и точность с Gemini. - Почему подходы, работающие на тяжелых облачных моделях, не работают на локальных LLM. - Разберем архитектуру системы автоматической классификации чувствительных данных - DPO-copilot.

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

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

Как построить систему поиска знаний, которая понимает не только текст регламентов, но и структуру изделия из чертежей, когда у вас всего одна карта H100 и строгие требования к приватности? Стандартный RAG здесь не работает: векторный поиск не видит связей между «гайкой» и «двигателем», а обычные VLM галлюцинируют на таблицах технических требований. В докладе я разберу архитектуру «Hybrid Fusion RAG» — гибридную систему поиска для инженерных задач. Вы узнаете: Почему мы отказались от Qwen 3 в пользу гибридной архитектуры Mamba+MoE (Nemotron-3-Nano-30B) и как это помогает загружать в контекст целые ГОСТы. Как скрестить NebulaGraph и Qdrant для «триангуляционного поиска», чтобы повысить точность с 60% до 94%. Оптимизация инференса: как запустить OCR чертежей, Graph-траверсал и LLM-ризонинг на 80GB VRAM, используя BF16 и TensorRT-LLM. Лицензионная чистота: сборка SOTA-стека из компонентов, доступных для Enterprise-контура в 2026 году.

• сравнение производительности служб каталогов (MS Active Directory, Free IPA, Samba DC) в основных сценариях использования протоколов LDAP, Kerberos;
• CAP теорема в службе каталогов - решение проблем репликации и устойчивости;
• оптимизация и применение KV-хранилища (Badger DB) для задач быстрого поиска объектов произвольной структуры;
• оптимизация распределенной обработки большого объема сетевых запросов на Go - наш опыт.

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 и хочет понять, где тонко и как не порвать.

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

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

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

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

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

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

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

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

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

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

Мы 15 лет строили инфраструктуру для финтеха и телекомов. Полтора года назад к нам пришли клиенты с задачей «запустите LLM в проде». Мы взялись, собрали платформу на open-source стеке и запустили в production у облачного провайдера Nubes на потребительских GPU (RTX 5090).

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

В докладе — экономика inference с конкретными числами:

— Формула себестоимости токена: P = 1M × R / (Q × 3600 × U). Разберём каждую букву, покажу как подставить своё железо и получить свою цену

— Таблица по 7 моделям (от 4B до 120B) на RTX 5090: throughput, себестоимость при разной утилизации. Разброс себестоимости между моделями — в 10 раз, и это не очевидно до тестов

— Что влияет на экономику: квантизация (одна настройка — минус 60% себестоимости), утилизация GPU, выбор модели под задачу. Почему маленькая модель на одной карте может быть выгоднее большой на четырёх

— Чему нас научил рынок: мы общались с командами, у которых 100-500 GPU. Оказалось, что автоскейлинг inference не решён даже у них, а типичная рабочая нагрузка — 1-2 карты, не десятки

Слушатели унесут формулу расчёта себестоимости, таблицу бенчмарков и понимание, как устроена экономика LLM inference — чтобы не считать на глазок, а знать цену своего токена.

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. Как это сделать - расскажу в своем докладе

В докладе поделимся практическим опытом переезда высоконагруженных AI-сценариев с вендорских моделей как услуги (MaaS) на локальные (on-premise) LLM, STT и эмбеддинги. Расскажем про реальные инженерные проблемы такого перехода: от ограничений контекстного окна и ресурсоемкости его обработки до деградации скорости инференса на фреймворках вроде vLLM и сложностей балансировки разноплановой нагрузки. Развенчаем популярные мифы о хостинге моделей и дадим конкретные инсайты, основанные на эксплуатации ансамбля моделей, обрабатывающего миллионы запросов в месяц.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Сажаем рядом бизнес и тех отдел. У бизнеса вопросы из P&L, у тех отдела — ответы про другую экономику. Каждый аргумент проверяется оппонентом — за кулисами такие разговоры идут давно, мы постараемся выноести их на сцену.

Ряд кейсов покрывают весь цикл расходов на AI: лицензии, инфраструктура, смена моделей, планирование, команды, утилизация. С реальными цифрами и позициями обеих сторон. Цифры из практики: $120K → $180K на лицензиях за год; $500K за свой кластер против $180K подписки; реальная утилизация AI-ассистентов; разница в скорости отделов при одинаковом бюджете.

Что заберёшь домой как CTO или Владелец бизнеса: рамку для разговора друг с другом. Какие расходы признавать как OPEX, какие как страховку, как обосновывать context engineering, почему сравнение «лицензия vs ещё один разработчик» — некорректное. И в обратную сторону — какие отговорки тех отдела перестают работать, когда бизнес считает всерьёз.

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

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

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

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

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

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

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

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

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

Два тимлида. Четыре раунда. Один вопрос: разработчик должен думать как продакт — или это путь к хаосу? Одна сторона считает, что 80% фич не выстреливают, а значит лучше катить мелко, смотреть метрики и не строить собор там, где хватит навеса. Другая — что быстро выкатил значит быстро сломал доверие, а «потом переделаем» на практике означает никогда. Формат — батл: аргументы, панчи, голосование зала. Без слайдов на 80 страниц.

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