Приём заявок открыт — до 31 июля 2026

Ваш опыт — то, чего не спросишь у модели

30 ноября и 1 декабря 2026, Москва. Расскажите о том, что реально работает под нагрузкой — и о том, что выглядело production-ready, но легло. Формат выбираете вы: доклад, воркшоп, кейс-игра или дебаты.

КонференцияHighLoad++ 2026
Дата30 ноября и 1 декабря
МестоМосква, МШУ Сколково
Участников2500+
Заявки до31 июля 2026

О чём HighLoad++ теперь

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

Ответ на вопрос «как сделать» подешевел — его даёт модель. Подорожало то, чего у модели нет: инженерное мышление, доменная экспертиза и опыт из первых рук. Почему система устроена именно так. Где инструмент ошибается и как это проверить. Что ляжет под нагрузкой, хотя выглядело production-ready. За этим и приходят на HighLoad++.

Три ожидания

Что делает доклад сильным

Опыт из первых рук

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

Почему, а не только как

Объясните ход мысли: почему решение именно такое, какие trade-offs вы взвешивали. Участник должен уйти с образом мышления, а не только с рецептом.

Как здесь работал AI?

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

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

Тематика 2026

О чём хотим поговорить на конференции

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

Внедрение AI в SDLC приоритет
Каких докладов ждём в первую очередь Честные кейсы вместо восторгов. Не «мы внедрили Copilot», а что изменилось: скорость, качество, стоимость, инциденты — с цифрами. Как вы верифицируете сделанное агентом — самый частый вопрос индустрии, и честный ответ «мы пока не умеем» тоже принимается, если показан путь.
Ищем прямо сейчас
  • Нечеловеческая разработка: как устроен цикл работы агента, его обвязка и подготовка контекста (loop / harness / context engineering). Агент с классическими практиками (DDD, SDD) работает хуже, чем с новыми — покажите, какими
  • Границы применимости: где агенты работают, где ломаются — сложная архитектура, распределённые системы, махровое легаси, узкоспецифичные хаки
  • AI в легаси: написать новый сервис агентом — просто. Заставить агента не испортить пятнадцатилетнюю Java — доклад, который мы ждём
  • LLM в продукте: как строить фичи для пользователей на моделях — поиск, генерация, ассистенты — под производственной нагрузкой
  • Верификация работы агента: методики, инструменты, честные ограничения
Полный список тем

Requirements & Analysis

  • Извлечение бизнес-требований из транскриптов интервью с помощью LLM
  • AI для выявления противоречий и пробелов в объёмных ТЗ
  • Генерация User Stories и критериев приёмки из бизнес-целей

Design & Architecture

  • Генерация прототипов и UI-компонентов по описанию
  • AI-архитектор: схема БД и микросервисные взаимодействия
  • Architecture as Code: актуальная документация при помощи LLM
  • AI помогает выбрать стек и паттерны, оценивая trade-offs

Implementation

  • Агентный подход: от Copilot к автономным кодинг-агентам
  • Рефакторинг монолитов и миграции на новые стеки
  • Code Review, где AI — первый и самый строгий проверяющий
  • Локальные модели (Llama/DeepSeek) в закрытых контурах
  • Актуальная документация в процессе написания кода
  • Loop, harness и context engineering — практики нечеловеческой разработки

Testing & QA

  • Автогенерация Unit- и Integration-тестов с высоким покрытием
  • Синтетические данные без риска утечки ПДн
  • Предсказание «хрупких» мест до тестирования
  • AI-анализ логов и Root Cause падающих пайплайнов

Deployment & CI/CD

  • Предсказание рисков релиза по истории коммитов и метрикам
  • Release Notes отдельно для бизнеса, маркетинга и инженеров
  • AI-driven Auto-rollback по аномалиям метрик
  • Оптимизация Kubernetes и Terraform агентами

Maintenance & Operations

  • AI-агенты для классификации и маршрутизации тикетов
  • Предсказание деградации и инцидентов (AIOps)
  • RAG по базе постмортемов для онбординга и дежурств
  • Автогенерация и тестирование патчей CVE

LLM в продукте

  • Пользовательские функции на LLM под производственной нагрузкой
Агентная платформа новая секция приоритет
Почему это HighLoad Компания решила перенести разработку на агентов. Нужны инструменты на тысячи инженеров — и это полноценная высоконагруженная система со всеми её проблемами. Agent Platform Engineering — новая секция HighLoad++.
Ищем прямо сейчас
  • Архитектура агентной платформы: с чего начать и почему платформы нынче ещё нужнее
  • On-premise инференс: железо, vLLM/llama.cpp на проде, падения под нагрузкой, KV-кэш, мульти-GPU, OOM — инференс как новая highload-дисциплина
  • Шлюз и доступы для агентов: агент эффективен, когда доступ широкий и без ручного согласования на каждый чих, — и опасен ровно по той же причине. Как выдавать, чем ограничивать и как не потерять данные и бизнес
  • Ограничители (guardrails): чем резать возможности агента, не убивая его пользу
  • Экономика: сколько стоит агентная платформа и как это посчитать. Никто не умеет: и работающая методика, и честное «мы считали так — и вот где ошиблись» соберут зал
  • Насколько агентную платформу можно построить самими агентами — и где предел
Ищем прямо сейчас — инференс и железо
  • Архитектура GPU-кластера под инференс: интерконнект, шедулинг, мультитенантность, утилизация
  • Экономика инференса: своя модель против внешнего API — с расчётом, где что выгоднее
Российские боли: как с этим жить новый блок
Что изменилось По нашему исследованию блокировки — боль номер один русскоязычного инженерного сообщества. Внешние условия мы не изменим — но можем обменяться инженерными ответами. Формат: не «как обойти», а «как построить систему, которая продолжает работать».
Ищем прямо сейчас
  • Архитектура связности, когда любой кусок может отвалиться: работа сразу с несколькими облачными провайдерами России, деградация без падения
  • Зависимости и репозитории: как жить, когда GitHub, PyPI и Docker Hub доступны через раз — зеркала, проксирование, вендоринг
  • DDoS-защита в зоне .ru: международные сервисы заблокированы, локальные пробиваются — что реально работает
  • TLS-сертификаты: жизненный цикл без инцидентов после ухода привычных CA
  • Мониторинг и оповещения, когда пуши и SaaS-сервисы ненадёжны
  • 152-ФЗ, СОРМ, реестры: комплаенс как инженерная задача, а не бумажная
  • Импортозамещение с открытыми глазами: честные сравнения, реальные миграции, цена вопроса
  • Надёжность на российских хостерах: SLA, которых нет, и архитектура поверх них
  • Железо для инференса под санкциями: параллельный импорт, китайские карты, аренда мощностей — как считать риски
Архитектура и масштабируемость приоритет
Что изменилось Агент выдаёт правдоподобную архитектуру за минуты, но не удерживает её — под инцидентом она разваливается. Мы планируем добавить в программу доклады о том, как удерживать архитектуру системы, которую пишут агенты, и честные разборы trade-offs.
Ищем прямо сейчас
  • Легаси-система на миллионы строк: как вы вернули управляемость — и что в этом смог и не смог агент
  • Каскадный сбой: одна плохая конфигурация уронила всю систему — анатомия инцидента и защита от расползания отказа
  • Честная цена модных паттернов: DDD, Clean Architecture, микросервисы «по рынку труда» — что стало с задержками, инцидентами и командой
  • Kafka/GraphQL/Kubernetes, внедрённые не под масштаб: как распознать и как откатиться
  • Хрупкие межсервисные вызовы: повторные попытки, трассировка, потеря логов при многосервисных транзакциях
Полный список тем
  • Архитектура систем с миллионами RPS и экстремальной нагрузкой
  • Микросервисная архитектура: истории успеха и провалов
  • Миграции с legacy-систем на современный стек
  • Геораспределённые архитектуры и работа с множеством ЦОДов
  • Архитектурные паттерны для масштабируемых систем
  • Производительность при резком росте нагрузки
  • Архитектура data-intensive приложений
  • Архитектурный надзор над системами, которые пишут агенты
  • Изоляция отказов и защита от каскадной деградации
Базы данных и системы хранения приоритет
Что изменилось Классика хранения никуда не делась — но у СУБД появился новый клиент: агент. Классическая база отвечает на запросы, агент же работает задачами — циклом «наблюдение → действие → проверка», и ему нужны гарантии свежести и видимости данных, память с происхождением и аудитом — иначе он учится на неверной реальности (концепция NooData Олега Бартунова). И добавился новый источник аварий: выбор технологии по совету LLM — модель уверенно говорит «production-ready» про инструмент, который ляжет под вашей нагрузкой. Ждём и классические доклады про пределы инструментов, и первые ответы на агентный вызов.
Ищем прямо сейчас — PostgreSQL
  • Промахи планировщика на масштабе: методика разбора EXPLAIN, которая экономит дни, а не советы «добавьте индекс»
  • Репликация и DR без потери транзакций: физическая vs логическая на реальных сбоях, зависшие recovering-реплики
  • Массовые UPDATE/DELETE на сотнях миллионов строк и частичный бэкап — безопасные способы, которых нет в документации
  • Высокая доступность (HA) всерьёз: Patroni, etcd, пулеры, шардирование — что зрело, а что заброшено
  • Битые страницы, разрастание WAL, раздувание широких таблиц: диагностика и восстановление
Ищем прямо сейчас — ClickHouse (самая горячая СУБД нашего исследования)
  • Систематика эксплуатационных граблей: too many parts, MEMORY_LIMIT_EXCEEDED, зависшие DDL и мутации — вместо фольклора
  • Апгрейд ClickHouse без поломки прода: методика, каталог несовместимых изменений, контрольный список
  • Дедупликация без ловушек: ReplacingMergeTree, FINAL, MV над Distributed
  • Тихая порча результатов: алиасы, CTE, оптимизатор JOIN — как ловить неправильные данные, которые «работают»
  • Keeper и координация: катастрофоустойчивость, потеря ДЦ, клонирование кластера
  • Kafka → ClickHouse без потерь: что делать с молчаливыми сбоями цепочки
  • Шардирование «как у всех» и его цена: мифы, по которым проектируют кластеры, и что случается под нагрузкой
Ищем прямо сейчас — остальные
  • YDB в проде: реальная утилизация ресурсов, апгрейды, границы применимости
  • Tarantool, MongoDB, Redis/Valkey или MySQL — доклад по любой из них: опыт эксплуатации на масштабе с честными цифрами отказов
Ищем прямо сейчас — СУБД под агентную нагрузку
  • База данных для агента: от query-driven к task-driven — что должно измениться в планировщике и исполнителе, чтобы агент получал гарантии свежести и структурированную обратную связь
  • Агентская память поверх СУБД: происхождение данных, версии, права, аудит действий — проверяемая память вместо длинной истории чата
  • Честный HTAP: свежесть как часть корректности — что именно видит аналитический запрос, вместо «примерно свежих» реплик; доклад от разработчиков СУБД или опыт на стороне приложения
Полный список тем
  • Масштабирование БД: шардирование, репликация, балансировка
  • Высокопроизводительные решения для хранения и обработки данных
  • Распределённые SQL и NoSQL-решения при высоких нагрузках
  • Отказоустойчивые хранилища и системы восстановления
  • Облачные базы данных: архитектура, особенности, использование
  • Нестандартные решения и подходы для хранения данных
  • Оптимизация запросов и производительности БД
  • Базы данных под агентную нагрузку: агентская память, гарантии свежести и видимости, HTAP
  • Векторные и семантические хранилища под производственной нагрузкой
  • Российские решения в области хранения данных
  • Программные и аппаратные системы хранения данных
  • Эксплуатация СУБД в продакшне: апгрейды версий, миграции, восстановление
Data Engineering
Что изменилось Классика потоковых данных остаётся, а из нового — RAG: по исследованию он упирается в грязные данные, ошибки ранжирования и потерю recall.
Ищем прямо сейчас
  • Kafka и потоковые пайплайны: молчаливые сбои репликации, повреждение данных во Flink/Spark — как строить контроль целостности
  • CDC на проде: потери метаданных, неполные DELETE-события
  • RAG на реальных данных: грязные корпуса, потеря полноты (recall), задержки, маскирование персональных данных на русском
Полный список тем
  • Построение эффективных ML-пайплайнов
  • MLOps: практики, инструменты, мониторинг
  • Распределённая обработка данных в реальном времени
  • Хранение и версионирование моделей и датасетов
  • Архитектура систем рекомендаций на больших масштабах
  • Оптимизация ETL для больших объёмов данных
  • Системы мониторинга качества данных и моделей
  • Высокопроизводительные вычисления для data science
  • Данные для LLM и RAG: пайплайны подготовки, качество корпусов
  • CDC и репликация данных между системами
Platform Engineering
Что изменилось Рядом с IDP вырастает агентная платформа (см. отдельную секцию) — и с ней повторяется знакомая история: многие уже построили внутреннюю AI-платформу, которую не могут ни внедрить на всю компанию, ни окупить.
Ищем прямо сейчас
  • Kubernetes честно: во что обходится содержание кластеров и когда он не нужен
  • Сеть кластера как источник трудноуловимых сбоев: CNI, апгрейды service mesh, graceful drain
  • Хранилище в кластере: CSI/FUSE против POSIX-семантики, опыт Longhorn/Linstor/MinIO и их альтернатив
  • CI/CD-пайплайн на десятки тысяч строк: как вернуть его под контроль
  • Инфраструктура дорожает и запирает: FinOps, выход из vendor lock, миграции без остановки
  • Карта инфраструктуры: как построить видимость связей ВМ ↔ сервисы, когда её никогда не было
Полный список тем
  • Построение внутренних платформ для ускорения разработки
  • Developer Experience как ключевой фактор эффективности
  • Управление большой инфраструктурой: от теории к практике
  • Kubernetes и облачная экосистема для высоконагруженных систем
  • Internal Developer Platforms: архитектура и практики внедрения
  • Мониторинг, управление ресурсами и оптимизация затрат
  • FinOps практики для облачных платформ
  • SDN, SDS: разработка и эксплуатация на масштабах
  • CI/CD-инфраструктура как система: пайплайны, раннеры, кеши на масштабе
  • Инвентаризация инфраструктуры: карта связей сервисов, ВМ и железа
Безопасность высоконагруженных систем
Что изменилось У систем появился новый класс субъектов — агенты с доступами (см. секцию «Агентная платформа»). Классика при этом никуда не делась: атаки на цепочку поставок — в топе болей сообщества.
Ищем прямо сейчас
  • Атаки на цепочку поставок: компрометации npm/PyPI/GitHub Actions — как строить защиту
  • Секреты и выдача учётных данных на масштабе — теперь ещё и для агентов
  • Инъекции нового поколения: вывод LLM, попадающий в shell
  • Управление уязвимостями (CVE) в инфраструктуре: как устроен процесс поиска, приоритизации и закрытия дыр — с метриками, которые доказывают, что он работает
  • Разбор реального взлома: майнеры, руткиты, серверы, скомпрометированные сразу после установки (анонимизированный разбор — нормально)
Полный список тем
  • DevSecOps и безопасность в процессе разработки
  • Защита от DDoS, высоконагруженных атак и ботов
  • Внедрение Zero Trust в масштабных инфраструктурах
  • Безопасность контейнеров и микросервисов
  • Масштабируемые решения для аутентификации и авторизации
  • Управление секретами в распределённой инфраструктуре
  • AI-технологии для обнаружения и предотвращения атак
  • Безопасность облачных инфраструктур
  • Безопасность цепочки поставок: зависимости, реестры пакетов, CI
  • Безопасность агентных систем: контроль действий и прав, prompt injection, границы доверия
SRE и эксплуатация систем
Что изменилось Здесь — про то, как система живёт и падает в проде. Во время инцидента агент — плохой помощник: чинить в моменте приходится человеку. Зато между инцидентами он силён: база знаний из постмортемов ускоряет следующий разбор.
Ищем прямо сейчас
  • Наблюдаемость на масштабе: стоимость ELK/Loki/OpenSearch, потери данных в OpenTelemetry — архитектуры, которые не разоряют
  • Управление инцидентами в РФ: чем заменить Grafana OnCall и PagerDuty — дежурства, эскалации, инструменты
  • Как перестать отлаживать сеть вслепую: устройство сети под вашим приложением, границы ответственности — где ваша зона, где провайдер, где «дикий интернет», физика задержек (когда можно уехать в дальний дешёвый ЦОД, забив на RTT)
  • Баги, которые живут только в проде: почему тестовая среда не воспроизводит боевые данные и что с этим делать
  • Постмортем в паре «человек + агент»: как реально ускоряется следующий инцидент
Полный список тем
  • Практики построения отказоустойчивых систем
  • Наблюдаемость: метрики, логи, трейсинг на масштабах
  • Автоматизация управления инцидентами
  • Методики постмортемов и снижения MTTR
  • SLO, SLA, SLI: практическое применение
  • Хаос-инжиниринг в продакшн-среде
  • Управление конфигурациями в распределённых системах
  • Оптимизация потребления ресурсов и финансовых затрат
  • Сетевая эксплуатация: балансировка, DNS, диагностика сетевых инцидентов
Тестирование высоконагруженных систем
Что изменилось Главный запрос индустрии — верификация сделанного агентом. «Как проверить» подорожало сильнее всего: агент, спроектировавший алгоритм три часа назад, не может написать к нему верификатор.
Ищем прямо сейчас
  • Как проверить сделанное агентом — самый частый вопрос индустрии сейчас
  • Все знают, что «тесты нужны». Расскажите, как внедрить тестирование, которое реально ловит проблемы, а не закрывает отчётность
Полный список тем
  • Нагрузочное тестирование при сверхвысоких нагрузках
  • Автоматизация функционального тестирования масштабных систем
  • Тестирование отказоустойчивости и восстановления после сбоев
  • Инструменты и методики непрерывного тестирования
  • Симуляция пиковых нагрузок и экстремальных сценариев
  • Мониторинг производительности в тестовых и продакшн-средах
  • Анализ и профилирование узких мест системы
  • Верификация кода и систем, созданных агентами
Языки программирования и технические стеки
Что изменилось Доменная экспертиза стала важнее владения языком. Хардкор (ядро Postgres, GPU, C++) — живая граница применимости агентов; ждём признанных спецов с кодом и цифрами: где модели реально помогают и где ломаются.
Ищем прямо сейчас
  • C++ на проде: UB, расходящиеся компиляторы, боль сборки — и может ли сюда агент
  • Низкоуровневая конкурентность: гонки, отмена задач, утечки потоков и горутин — разборы реальных багов на любом языке
  • Наивные алгоритмы под нагрузкой: как копии, мьютексы и логирование убивают время отклика
  • Один код — разные результаты: расхождения между продом и локальной средой и между платформами, которые стоили инцидентов
  • Go в командах: архитектурная культура против лапши — с примерами до/после
  • Агентное программирование в низкоуровневых задачах: на Python агент пишет сам — а что с C++ на уровне регистров, SIMD и ядра? Покажите на своём коде, где он помогает, а где путается
Полный список тем
  • Высокопроизводительные решения на PHP, Go, Rust, Java, C++, Python
  • Выбор технологий для конкретных задач и сценариев нагрузки
  • Оптимизация рантайма языков программирования
  • Асинхронное программирование и паттерны конкурентности
  • Эффективное использование памяти и ресурсов
  • Профилирование и оптимизация производительности кода
  • Техники горячего обновления в высоконагруженных системах
  • Агентная кодогенерация в системных языках: границы применимости
Edge, IoT, HPC, медиа и специализированные темы
Что изменилось Домены, где цена ошибки высока, а экспертов мало. Хардкор мы любили все двадцать лет — и зовём его без всяких оправданий.
Ищем прямо сейчас
  • Распределённые системы, которые нельзя проверить запуском: консенсус, консистентность, верификация
  • GPU-вычисления и оптимизация инференса как highload-задача (продуктовый инференс — сюда, платформа для инженеров — в секцию «Агентная платформа»)
  • Медиастриминг под нагрузкой: RTP/RTSP, задержки, отладка
  • Прошивки и железо: когда документации нет — обратная разработка чужих устройств и SoC, ограничения, «умные» устройства в проде
Полный список тем
  • Edge Computing: обработка данных на границе сети, низколатентные решения, синхронизация и консистентность
  • IoT: архитектура, протоколы, безопасность, обработка данных с сенсоров, промышленные системы
  • Высокопроизводительные вычисления: GPU, суперкомпьютеры
  • Потоковая обработка видео и мультимедиа
  • Высоконагруженные поисковые системы
  • Биллинг и платёжные системы под экстремальными нагрузками
  • Блокчейн: архитектура нод, консенсус, шардинг, MEV, mempool, DeFi
  • Квантовые вычисления, аппаратные ускорители, новые протоколы
  • Игровые движки и контент-пайплайны под нагрузкой
DevOps-практики и культура
Что изменилось Здесь — про то, как устроены поставка и команды: доклады про инциденты и наблюдаемость — в SRE, про инструменты платформы — в Platform Engineering. SDLC перестраивается под агентов, топология команд меняется — ждём доклады с цифрами до/после.
Ищем прямо сейчас
  • Критичные знания живут в головах и личных промптах сотрудников: опыт формализации в базу знаний, которую читают и люди, и агенты
  • Роль девопс/платформенного инженера: что от неё останется и что появится
  • Как агенты меняют экономику инженерных команд: опыт перестройки процессов с цифрами до/после
Полный список тем
  • Быстрая и надёжная поставка изменений в продакшн
  • Автоматизация процессов в сложных системах
  • Архитектура организации: топология, команды, взаимодействие
  • Управление инженерными знаниями: базы знаний, которые читают люди и агенты
Доклады вне привычной рамки
Без изменений 3–5 докладов-«экскурсий» в смежные области — физика, медицина, математика, кибербезопасность. Эффект открытого окна: интересная предметная область + технический взгляд изнутри. Это опыт, за которым иначе пришлось бы идти в другую профессию.
Примеры тем
  • Что может квантовый компьютер и где он уже работает?
  • Как устроен цифровой двойник атомной станции или буровой платформы?
  • Как машинное обучение помогает разрабатывать лекарства?
  • Какие функции растут быстрее факториала и зачем математикам такие штуки?
  • Как хакеры зарабатывают деньги на уязвимостях?
Конференция развития

Форматы: выбираете вы

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

Доклад

Доклад

50 мин

Лекционное выступление: спикер рассказывает о технологии, подходе, кейсе или опыте внедрения.

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

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

2 часа

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

Воркшоп

Воркшоп

2 часа

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

Круглый стол

Круглый стол

2 часа

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

Фейл-митап

Фейл-митап

2 часа

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

Питч-сессии

Питч-сессии

до 30 мин на такт

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

Нетворкинг

Нетворкинг

50 мин

Формат для знакомства и обмена опытом: свободное общение, тематическая встреча, игра или фасилитированная активность.

Интервью

Интервью

50 мин

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

Есть идея, но нет готового доклада? Этого достаточно

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

Обсудить идею с ПК →

Сильная заявка

Какие заявки мы ждём

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

Как мы отбираем

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

Сомневаетесь, проходит ли тема? Спросите до подачи: Telegram Валерии или valeria.guzhevnikova@ontico.ru — расскажите в двух строках, о чём думаете, и получите честный ответ.

Слабая заявка

«Как мы внедрили AI в команду: расскажу про подходы и практики»

Слишком общий опыт. Непонятно, что конкретно делали, что изменилось и что участник возьмёт в работу.

Сильная заявка

«Мы внедрили AI-ассистентов в команду 30 инженеров: вот что изменилось в скорости и качестве через полгода»

Понятен масштаб, есть временной горизонт и цифры, очевидна ценность для слушателя.

Частые сомнения
  • «Моя тема слишком узкая» — именно такие доклады собирают полные залы
  • «Я не звезда индустрии» — ПК оценивает опыт, не статус
  • «У нас небольшой масштаб» — важна глубина разбора, не размер компании
  • «Нет готового доклада» — принесите идею, выросшую из вашего опыта: тезисы докрутите вместе с куратором
  • «Уже рассказывал на митапе» — если не на крупной конференции, подавайте

Осталось сомнение, которого нет в списке? Напишите Валерии: Telegram · почта.

Проверьте себя

Подходит ли ваша тема для HighLoad++?

Короткий тест — 4 вопроса, 30 секунд. В конце — что именно усилить в заявке.

Процесс и даты

От заявки до сцены

Подайте заявку сейчас — 31 июля

Ждём тему, тезисы и расширенное описание в поле «Обращение к Программному комитету». Можно приложить видео, презентации, ссылки на прошлые выступления. Достаточно идеи — поможем докрутить.

Общение с ПК август–сентябрь

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

Решение о включении в программу сентябрь

Заявок всегда больше, чем слотов. Учитываем актуальность, оригинальность, качество тезисов — и глубину опыта из первых рук.

Актуальность · Оригинальность · Конкретность · Практическая польза

Подготовка к выступлению октябрь–ноябрь

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

HighLoad++ 2026 30 ноября и 1 декабря

Москва, МШУ Сколково. Два дня, 2500+ инженеров, сотни докладов.

Зачем выступать

Поделитесь опытом с теми, кто решает те же задачи

01

Внести вклад в сообщество

Ваши кейсы и находки помогают тысячам инженеров проходить похожие этапы быстрее.

02

Структурировать опыт

Когда формулируешь для других — понимаешь сам. Многие называют это главной ценностью участия.

03

Получить честную обратную связь

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

04

Заявить о себе

Видимость в сообществе, репутация эксперта, узнаваемость среди инженеров и архитекторов.

05

2500+ инженеров в одном месте

И все пришли именно за разговором с единомышленниками.

06

Куратор из ПК

Эксперт в теме вашего выступления поможет выстроить структуру и довести идею до сильного доклада.

07

Билет и проживание

Бесплатный доступ на оба дня. Иногородним компенсируем дорогу и забронируем отель.

08

Запись и онлайн-аудитория

Конференция очная, но доклады доступны онлайн и в записи — охват шире зала.

Голос спикеров

Те, кто уже выступал

Часто спрашивают

Вопросы

Я никогда не выступал. Можно подавать?

Конечно. Каждый принятый спикер работает с куратором из ПК. Опыт выступлений необязателен — важен ваш практический опыт.

Можно подать несколько заявок?

Да, на разные темы и форматы. Если у вас несколько сильных кейсов — подавайте все.

Можно предложить не доклад, а воркшоп или другой формат?

Да. Конференция сместилась в сторону интерактивных форматов: мастер-классы, кейс-игры, питч-сессии, дебаты, форсайты. Укажите желаемый формат в заявке или напишите нам — поможем выбрать и подготовить. Подробнее — в блоке «Форматы».

Моя тема не из списка. Стоит подавать?

Однозначно, если есть сильный контент. Список тем — приоритет, не ограничение. Рассматриваем все заявки с интересным практическим опытом.

Когда узнаю результат?

Финальные решения — в августе–сентябре 2026. Если потребуются уточнения или захотим обсудить тему — напишем раньше.

Есть гонорар?

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

Можно выступить онлайн?

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

Кто оценивает заявки?

Программный комитет — практики с реальным опытом эксплуатации высоконагруженных систем. Оценивают профессиональную глубину, не красоту формулировок.

Есть коммерческие слоты?

Нет. Все выступления проходят конкурсный отбор. Доклады с рекламным уклоном не принимаются. Хотите представить компанию — напишите нам о партнёрских возможностях.

Программный комитет

Кто отбирает доклады

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

Готовы рассказать о своём опыте?

2500+ инженеров ждут доклад с реальными кейсами и живым опытом — тем, что вы пережили сами.

Подать заявку →   Вопрос ПК в Telegram   Написать письмо