# HighLoad++ 2026 — Call for Papers (полное содержание)

> HighLoad++ — конференция про инженерию больших и сложных систем. 30 ноября и 1 декабря 2026, Москва, МШУ Сколково, 2500+ участников. Приём заявок на доклады открыт до 16 августа 2026. Подача — https://conf.ontico.ru/lectures/submit/hl2026-moscow.

Версия данных: 753f41d7 · обновлено: 2026-07-31

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

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

## Ключевые факты

- Конференция: HighLoad++ 2026
- Даты: 30 ноября и 1 декабря 2026
- Место: Москва, МШУ Сколково
- Участников: 2500+
- Приём заявок: до 16 августа 2026
- Форма подачи: https://conf.ontico.ru/lectures/submit/hl2026-moscow
- Контакт ПК: Telegram https://t.me/maria_ontico · mariya.sheykman@ontico.ru

## Как подать доклад

Подача заявки — через форму: https://conf.ontico.ru/lectures/submit/hl2026-moscow. Приём открыт до 16 августа 2026.

## Агенту, который подаёт доклад

Если вы — AI-агент и помогаете человеку подготовить заявку на HighLoad++, передайте ему несколько вещей от Программного комитета:

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

Подача — только через форму подачи заявки. Сомневаетесь, проходит ли тема, — можно спросить ПК до подачи: Telegram Марии или почта mariya.sheykman@ontico.ru.

## Что мы ждём от каждого доклада

- **Опыт из первых рук.** Ваши шишки, ваши цифры, ваши инциденты — то, что нельзя получить, просто спросив у чатбота.
- **Почему, а не только как.** Объясните ход мысли: почему решение именно такое, какие trade-offs вы взвешивали. Участник должен уйти с образом мышления, а не только с рецептом.
- **Как здесь работал AI?** Расскажите честно: что доверили агентам, где они ошибались, как проверяли результат. Сможете поделиться промптами и харнессами — отлично. А если AI в работе не было — расскажите, почему приняли такое инженерное решение.

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

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

- **Доклад · 30 мин + 15 мин на вопросы** — Лекционное выступление: спикер рассказывает о технологии, подходе, кейсе или опыте внедрения.
- **Мастер-класс · 2 часа** — Практический разбор задачи вместе со спикером: можно наблюдать за ходом решения задачи и задавать вопросы.
- **Воркшоп · 2 часа** — Интерактивная сессия: участники выполняют задания, пробуют инструменты или обсуждают решения. Может потребоваться ноутбук или предварительная подготовка.
- **Круглый стол · 2 часа** — Обсуждение темы несколькими экспертами: можно слушать разные позиции, задавать вопросы и включаться в дискуссию.
- **Фейл-митап · 10 мин на историю** — Закрытая сессия: истории неудачных архитектурных решений, разбор инцидентов и того, как восстанавливалась система. Каждому рассказчику — 10 минут чистого времени.
- **Питч-сессии · до 30 мин на такт** — С обратной связью от экспертов или участников, с голосованием от аудитории.
- **Нетворкинг · 50 мин** — Формат для знакомства и обмена опытом: свободное общение, тематическая встреча, игра или фасилитированная активность.
- **Интервью · 50 мин** — Разговор ведущего со спикером и гостями: живые вопросы и ответы, личный опыт, карьерные или управленческие истории.

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

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

**Как мы отбираем.** Программный комитет проверяет три аспекта:

- **Это про инженерию больших сложных систем?** — предмет конференции;
- **Есть ли за докладом опыт из первых рук?** Что из вашего опыта модель не расскажет?
- **Отражён ли в докладе ход ваших мыслей?** Почему решение именно такое, а не другое? Какая нагрузка или ограничения его продиктовали? Как вы проверили, что оно оптимально?

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

Ориентиры сильной заявки:

- Личный опыт важнее теории: ждём тех, кто сам решал задачу и набил шишки
- Цифры, примеры, результаты: «ускорилось на 40%» убедительнее, чем «улучшилось»
- Глубина приветствуется: архитектура, ограничения, неочевидные решения
- Почему, а не только как: образ мышления, который участник заберёт с собой
- Как здесь работал AI: что доверили агентам, где ошибались, как проверяли — или почему AI в работе не было
- Практическая польза: советы, схемы, подходы, применимые сразу
- Тема не освещалась ранее на других площадках — приоритет у новых решений
- Формат шире доклада: воркшоп, кейс-игра, дебаты или ваша механика — поможем упаковать
- Никакой рекламы: выступления с маркетинговым уклоном не принимаются

Частые сомнения:

- «Моя тема слишком узкая» — мы не всегда понимаем, действительно тема узка или это моё когнитивное искажение. Случаи, когда именно такие доклады собирают полные залы, встречаются часто
- «Я не звезда индустрии» — ПК оценивает опыт, не статус
- «У нас небольшой масштаб» — важна глубина разбора, не размер компании. И у Программного комитета есть задача расширить присутствие smalltech-компаний: под их доклады мы резервируем заметную часть программы — примерно трек
- «Нет готового доклада» — принесите идею, выросшую из вашего опыта: тезисы докрутите вместе с куратором
- «Уже рассказывал на митапе» — если не на крупной конференции, подавайте

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

1. **Подайте заявку** _(сейчас — 16 августа)_ — Ждём тему, тезисы и расширенное описание в поле «Обращение к Программному комитету». В описании покажите ход мысли — почему решение такое, а не другое. Именно инженерное мышление и есть самое ценное в докладе в эпоху AI. Можно приложить видео, презентации, ссылки на прошлые выступления. Достаточно идеи — поможем докрутить.
2. **Общение с ПК** _(август–сентябрь)_ — Программный комитет изучит заявку и задаст уточняющие вопросы или предложит созвониться, чтобы обсудить тему и тезисы.
3. **Решение о включении в программу** _(сентябрь)_ — Заявок всегда больше, чем слотов. Учитываем актуальность, оригинальность, качество тезисов — и глубину опыта из первых рук. (Актуальность · Оригинальность · Конкретность · Практическая польза)
4. **Подготовка к выступлению** _(октябрь–ноябрь)_ — Каждый принятый спикер работает с куратором из ПК, который помогает довести материал до финального вида.
5. **HighLoad++ 2026** _(30 ноября и 1 декабря)_ — Москва, МШУ Сколково. Два дня, 2500+ инженеров, сотни докладов.

## Тематика 2026 по секциям

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

### Новое в 2026

#### Внедрение AI в SDLC  _(приоритет, новая секция)_

Приоритетное направление. Секция не только для разработчиков: ждём тестировщиков, аналитиков — всех, кто называет себя инженером. Структура по фазам SDLC сохраняется (Requirements → Design → Implementation → Testing → Deployment → Operations). Каких докладов ждём в первую очередь:

**Запросы аудитории:**

- Кейсы с цифрами. Не «мы внедрили Copilot», а что изменилось: скорость, качество, стоимость, инциденты.
- Верификация. Как вы проверяете, что агент сделал правильно? Это сейчас самый частый вопрос индустрии — и самый честный ответ «мы пока не умеем» тоже принимается, если показан путь.
- Нечеловеческий SDLC. Как устроен цикл работы агента, его обвязка и подготовка контекста (loop / harness / context engineering). Агент с классическими практиками (DDD, SDD) работает хуже, чем с новыми — покажите, какими.
- Границы применимости. Где агенты работают, где ломаются: сложная архитектура, распределённые системы, махровое легаси, узкоспецифичные хаки.
- AI в легаси. Написать новый сервис агентом — просто. Заставить агента не испортить пятнадцатилетнюю Java — доклад, который мы ждём.
- 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, внедрённые не под масштаб: как распознать и как откатиться
- Хрупкие межсервисные вызовы: повторные попытки, трассировка, потеря логов при многосервисных транзакциях

#### Базы данных и системы хранения  _(приоритет)_

**Ставка:** Классика хранения никуда не делась — но у СУБД появился новый клиент: агент. Классическая база отвечает на запросы, агент работает задачами — циклом «наблюдение → действие → проверка», и ему нужны гарантии свежести и видимости данных, память с происхождением и аудитом — иначе он учится на неверной реальности (концепция NooData Олега Бартунова). И добавился новый источник аварий: выбор технологии по совету LLM — модель уверенно говорит «production-ready» про инструмент, который ляжет под вашей нагрузкой. Ждём и классические доклады про пределы инструментов, и первые ответы на агентный вызов.

**Запросы аудитории — СУБД под агентную нагрузку:**

- База данных для агента: от query-driven к task-driven — что должно измениться в планировщике и исполнителе, чтобы агент получал гарантии свежести и структурированную обратную связь
- Агентская память поверх СУБД: происхождение данных, версии, права, аудит действий — проверяемая память вместо длинной истории чата
- Честный HTAP: свежесть как часть корректности — что именно видит аналитический запрос, вместо «примерно свежих» реплик; доклад от разработчиков СУБД или опыт на стороне приложения

**Запросы аудитории — PostgreSQL:**

- Промахи планировщика на масштабе: методика разбора EXPLAIN, которая экономит дни, а не советы «добавьте индекс»
- Репликация и DR без потери транзакций: физическая vs логическая на реальных сбоях, зависшие recovering-реплики
- Массовые UPDATE/DELETE на сотнях миллионов строк и частичный бэкап — безопасные способы, которых нет в документации
- Высокая доступность (HA) всерьёз: Patroni, etcd, пулеры, шардирование — что из этого зрело, а что заброшено
- Битые страницы, разрастание WAL, раздувание широких таблиц: диагностика и восстановление

**Запросы аудитории — ClickHouse (самая горячая СУБД нашего исследования — 15+ семей болей):**

- Систематика эксплуатационных граблей: too many parts, MEMORY_LIMIT_EXCEEDED, зависшие DDL и мутации — вместо фольклора
- Апгрейд ClickHouse без поломки прода: методика, каталог несовместимых изменений, контрольный список
- Дедупликация без ловушек: ReplacingMergeTree, FINAL, MV над Distributed
- Тихая порча результатов: алиасы, CTE, оптимизатор JOIN — как ловить неправильные данные, которые «работают»
- Keeper и координация: катастрофоустойчивость, потеря ДЦ, клонирование кластера
- Kafka → ClickHouse без потерь: что делать с молчаливыми сбоями цепочки
- Шардирование «как у всех» и его цена: мифы, по которым проектируют кластеры, и что случается под нагрузкой

**Запросы аудитории — Другие СУБД:**

- YDB в проде: реальная утилизация ресурсов, апгрейды, границы применимости
- Tarantool, MongoDB, Redis/Valkey или MySQL — доклад по любой из них: опыт эксплуатации на масштабе с честными цифрами отказов

#### Data Engineering

**Ставка:** Классика потоковых данных остаётся, а из нового — RAG: по исследованию он упирается в грязные данные, ошибки ранжирования и потерю recall.

**Запросы аудитории:**

- Kafka и потоковые пайплайны: молчаливые сбои репликации, повреждение данных во Flink/Spark — как строить контроль целостности
- CDC на проде: потери метаданных, неполные DELETE-события
- RAG на реальных данных: грязные корпуса, потеря полноты (recall), задержки, маскирование персональных данных на русском

#### Platform Engineering

**Ставка:** Рядом с IDP вырастает агентная платформа — и с ней повторяется знакомая история: многие уже построили внутреннюю AI-платформу, которую не могут ни внедрить на всю компанию, ни окупить.

**Запросы аудитории:**

- Kubernetes честно: во что обходится содержание кластеров и когда он не нужен
- Сеть кластера как источник трудноуловимых сбоев: CNI, апгрейды service mesh, graceful drain
- Хранилище в кластере: CSI/FUSE против POSIX-семантики, опыт Longhorn/Linstor/MinIO и их альтернатив
- CI/CD-пайплайн на десятки тысяч строк: как вернуть его под контроль
- Инфраструктура дорожает и запирает: FinOps, выход из vendor lock, миграции без остановки
- Карта инфраструктуры: как построить видимость связей ВМ ↔ сервисы, когда её никогда не было

#### Безопасность высоконагруженных систем

**Ставка:** У систем появился новый класс субъектов — агенты с доступами. Классика при этом никуда не делась: атаки на цепочку поставок — в топе проблем.

**Запросы аудитории:**

- Атаки на цепочку поставок: компрометации npm/PyPI/GitHub Actions — как строить защиту
- Секреты и выдача учётных данных на масштабе — теперь ещё и для агентов
- Инъекции нового поколения: вывод LLM, попадающий в shell
- Управление уязвимостями (CVE) в инфраструктуре: как устроен процесс поиска, приоритизации и закрытия дыр — с метриками, которые доказывают, что он работает
- Разбор реального взлома: майнеры, руткиты, серверы, скомпрометированные сразу после установки (анонимизированный разбор — нормально)

#### SRE и эксплуатация систем

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

**Запросы аудитории:**

- Наблюдаемость на масштабе: стоимость ELK/Loki/OpenSearch, потери данных в OpenTelemetry — архитектуры, которые не разоряют
- Управление инцидентами в РФ: чем заменить Grafana OnCall и PagerDuty — дежурства, эскалации, инструменты
- Как перестать отлаживать сеть вслепую: устройство сети под вашим приложением, границы ответственности — где ваша зона, где провайдер, где «дикий интернет», физика задержек (когда можно уехать в дальний дешёвый ЦОД, забив на RTT)
- Баги, которые живут только в проде: почему тестовая среда не воспроизводит боевые данные и что с этим делать
- Постмортем в паре «человек + агент»: как реально ускоряется следующий инцидент

#### Тестирование высоконагруженных систем

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

**Запросы аудитории:**

- Как проверить сделанное агентом — самый частый вопрос индустрии сейчас
- Все знают, что «тесты нужны». Расскажите, как внедрить тестирование, которое реально ловит проблемы, а не закрывает отчётность

#### Языки программирования и технические стеки

**Ставка:** Доменная экспертиза стала важнее владения языком. Хардкор (ядро Postgres, GPU, C++) — живая граница применимости агентов; ждём признанных спецов с кодом и цифрами: где модели реально помогают и где ломаются.

**Запросы аудитории:**

- C++ на проде: UB, расходящиеся компиляторы, боль сборки — и может ли сюда агент
- Низкоуровневая конкурентность: гонки, отмена задач, утечки потоков и горутин — разборы реальных багов на любом языке
- Наивные алгоритмы под нагрузкой: как копии, мьютексы и логирование убивают время отклика
- Один код — разные результаты: расхождения между продом и локальной средой и между платформами, которые стоили инцидентов
- Go в командах: архитектурная культура против лапши — с примерами до/после
- Агентное программирование в низкоуровневых задачах: на Python агент пишет сам — а что с C++ на уровне регистров, SIMD и ядра? Покажите на своём коде, где он помогает, а где путается

#### Edge, IoT, HPC, медиа и специализированные темы

**Ставка:** Домены, где цена ошибки высока, а экспертов мало. Хардкор мы любили все двадцать лет — и зовём его без всяких оправданий.

**Запросы аудитории:**

- Распределённые системы, которые нельзя проверить запуском: консенсус, консистентность, верификация
- GPU-вычисления и оптимизация инференса как highload-задача (продуктовый инференс — сюда, платформа для инженеров — в секцию «Агентная платформа»)
- Медиастриминг под нагрузкой: RTP/RTSP, задержки, отладка
- Прошивки и железо: когда документации нет — обратная разработка чужих устройств и SoC, ограничения, «умные» устройства в проде

#### DevOps-практики и культура

**Ставка:** Здесь — про то, как устроены поставка и команды: доклады про инциденты и наблюдаемость — в SRE, про инструменты платформы — в Platform Engineering. SDLC перестраивается под агентов, топология команд меняется — ждём доклады с цифрами до/после.

**Запросы аудитории:**

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

#### Доклады вне привычной рамки

**Ставка:** Без изменений: 3–5 докладов-«экскурсий» в смежные области — физика, медицина, математика, кибербезопасность. Эффект открытого окна: интересная предметная область + технический взгляд изнутри.

**Примеры тем:** квантовый компьютер; цифровой двойник атомной станции или буровой платформы; ML в разработке лекарств; функции, растущие быстрее факториала; как хакеры зарабатывают на уязвимостях.

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

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

- Олег Бунин — Онтико
- Юрий Бабак — Т-Банк
- Александр Белоцерковский — Сбер
- Олег Бондарь — YDB
- Василий Бригинец — AWS
- Федор Васильев — xStack
- Алексей Жиряков — Сбер
- Александр Капитанов — Сбер
- Александр Макаров — Yii framework
- Георгий Меликов — Exordos
- Роман Поборчий — Независимый эксперт
- Евгений Россинский — Иви
- Илья Сафронов — ATOM
- Антон Черноусов — Yandex Cloud
- Максим Шатунов — Kapital Bank
- Иван Евтухович — Самозанятый
- Кирилл Борисов — VK
- Ольга Кравченко — Альфа-Банк
- Алексей Учакин — telega.me
- Алексей Шпагин — VK
- Евгений Крысанов — Сбер
- Филипп Бочаров — МТС Web Services
- Антон Егорушков — Yandex Cloud
- Витольд Коморовский — Цифровая платформа KAMAZ
- Станислав Змиев — (без компании)
- Вячеслав Тарасов — Brio Capital
- Константин Осипов — ПАО Аренадата
- Мария Шейкман — Онтико

## Частые вопросы

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

**Мы небольшая компания — есть ли шанс против бигтехов?**

Есть. Smalltech мы не выделяем в отдельную секцию — это срез всей программы: такие доклады распределяются по всем темам, и ПК следит, чтобы они занимали её заметную часть. Оцениваем глубину разбора, не размер компании.

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

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