Что ломается при росте систем — и как это разбирают на практике ⤵️

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

Эти четыре выступления из программы Saint HighLoad++ 2026 для тех, кто работает с архитектурным долгом, выносом функционала из монолита, платформенными ошибками на масштабе и внедрением AI в production-контур. Здесь и кейсы команд, и практические разборы инженерных решений — когда важно не только увидеть результат, но и понять, как к нему пришли.

1️⃣ Игра «System Design». Владимир Невзоров (Servicepipe)
Архитектурная викторина: задачи про протоколы, архитектуру, паттерны, антипаттерны и историю IT. Формат, в котором можно проверить собственное инженерное мышление на практических вопросах.

2️⃣ Мастер-класс «Детские болезни доменных платформ в BigTech: архитектурные ошибки, которые дорого чинить». Екатерина Лысенко (Независимый эксперт)
Разбор повторяющихся архитектурных ошибок в платформенных доменах: FinTech, compliance, заказы, каталог. Как похожие решения в разных системах со временем приводят к одинаковым проблемам.

3️⃣ Вынос функционала из монолита. Алексей Лосев (Wildberries & Russ)
Мастер-класс о том, как выносить критичный функционал, когда на полноценный распил монолита нет времени и ресурсов. На примере сервиса мастер-баланса — разбор нескольких архитектурных подходов, их плюсов и минусов, а также особенностей работы с базами данных и шардированием.

4️⃣ Мультимодальный RAG для чертежей и ГОСТов: как подружить NebulaGraph, Qdrant и Nemotron-Mamba в закрытом контуре. Андрей Носов (Raft)
Разбор гибридной системы поиска для инженерных задач: работа с чертежами, регламентами и структурой изделий, сочетание графового и векторного поиска, запуск AI-стека в приватном контуре с ограниченными ресурсами.

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

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

В IT появился новый язык. И никто не уверен, что мы говорим об одном и том же.

AI-native, AI-first, AI Engineer, Prompt Engineer — эти слова все чаще видим в вакансиях и стратегиях. Но спроси трех людей, что они значат, и получишь три мнения. Это создает путаницу на собесах, в командах, в стратегиях.

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

Начинаем с четырех терминов:
🔹 AI-native компания: что это и чем принципиально отличается от обычной
🔹 AI-first подход: синоним AI-native или все же что-то другое
🔹 AI Engineer: новая роль или переименованный ML Engineer
🔹 Prompt Engineer: профессия будущего или временный навык

👉 Напишите нам, как вы это понимаете. Коротко, своими словами, из своей практики.
 
Все варианты мы соберем и вынесем на живую дискуссию на Saint TeamLead Conf и Saint HighLoad++ в Питере. Там участники вместе с экспертным советом разберут, что получилось, и зафиксируют финальные версии в глоссарии. Авторы формулировок будут указаны.

Потом цикл повторится: новые термины, новый сбор, новая дискуссия.

Решения, которые экономят месяцы.

В инженерной работе многое упирается не в поиск решения, а в скорость: понять, какой путь сработает в вашем контексте, и не тратить недели на проверку лишних вариантов.

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

Программа Saint HighLoad++ 2026 особенно сильна в темах AI: от практики внедрения ML/LLM в продукты до инфраструктуры, данных и архитектурных решений, которые делают такие системы устойчивыми в проде. Рядом — платформенные подходы, эксплуатация и масштабирование: все, что определяет, как сегодня развиваются сложные инженерные системы.

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

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

✅ Если планировали участвовать, программу уже стоит посмотреть внимательно. Финальное повышение цены на билеты — 1 июня.

Ждем вас 22 и 23 июня в Санкт-Петербурге на Saint HighLoad++ 2026 🖐️

Архитектурное соревнование надо?

На Saint HighLoad++ 2026 вас ждет викторина по System Design и архитектуре в live-режиме 🔥

Ведущий игры: Владимир Невзоров, старший backend-разработчик на проекте Антибот по защите крупнейших банков, маркетплейсов от массовых ботовых атак.

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

✅ Для участия нужно заполнить форму до 17:00 сегодня (21.05)
➡️ Отборочный этап пройдет сегодня в 19:00 по ссылке

Четверо сильнейших выйдут в финал уже на самой конференции. Окунитесь в мир System Design, участвуйте и болейте за своего финалиста 🙌

Если вы строите продукт на базе AI или внедряете AI для внутренних нужд компании, приходите на доклад Егора Андреева «Почему вам (скорее всего) не нужен локальный LLM-инференс», с которым он выступит на Saint HighLoad++ 2026.

В этом видео Егор поделился некоторыми деталями своего доклада 📝

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

Обычно за этим стоят hidden complexity, неожиданные side effects и ограничения, которые не видны ни в happy path, ни в документации.

Принесли вам записи трех докладов Saint HighLoad++ 2025 — про production-инциденты, масштабирование и интеграции, где реальность оказалась сложнее исходной архитектурной модели.

1️⃣ От даунтайма в проде из-за сетевой ошибки до коммита в апстрим Linkerd. Вадим Макеров.
Этот доклад — история разработчика из компании, столкнувшейся с проблемами в эксплуатации Linkerd. Вадим рассказал о том, как он подошел к решению проблемы, которую в итоге взяли в апстрим проекта, а система начала работать лучше.

2️⃣ Эволюция PostgreSQL-хранилища размещений в Авито. Евгений Константинов.
Инженеры Авито поделились я опытом масштабирования базы для размещений объявлений — фактически гигантского упорядоченного «лога» с метаинформацией и со сложной логикой обновления. Отчасти ретроспективный доклад о том, какие оптимизации использовали и к чему пришли в результате.

3️⃣ Семь кругов финтеха: драма в двух эпизодах. Маргарита Моногарова.
Маргарита на примерах и собственном опыте рассказала, почему интеграция — это не просто взять и вызвать API. Разбор проблемных ситуаций и exception paths поможет ИТ-специалистам при интеграции различных систем (и финтех-систем в первую очередь) не допускать ошибок, которые могут дорого стоить.

Если вам знакомы ситуации, когда система в production начинает жить по своим правилам — эти записи стоит посмотреть 🖐️

#записидокладов

Друзья, поговорим об внедрении AI?

Слишком много хайпа вокруг, слишком много инфоцыганства. В YouTube каждая вторая реклама про "Научу вайбкодить доходный бот" :)

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

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

О том, что построить vault на команду требует пересборки всех технических процессов в команде. А полноценное внедрение AI в цикл SDLC в компании означает перестройку буквально всех управленческих процессов и к нему надо готовиться заранее, а не бросаться на амбразуру.

На серьёзном уровне, как профессионалы. Хотим мы или не хотим, но похоже, нас с этим вашим AI теперь жить.

В письме анонсы двух треков, новой конференции и плейлист с видео про внедрение AI, которые уже звучали этой весной.

Новая конференция

Agentic Dev Conf — новая самостоятельная конференция Онтико. Конференция целиком посвящена внедрению AI в SDLC: от сбора требований и дизайна до деплоя и эксплуатации в продакшене. Отдельный трек для инженерного менеджмента: метрики ROI, трансформация найма, новые роли. Специальный трек Tiny Teams для тех, кто строит продукты командой 1–3 человека с парком AI-агентов.  (CFP открыт)

Saint HighLoad++ 2026, 22–23 июня, Санкт-Петербург

Внутри HighLoad++ мы впервые запускаем отдельный стрим «Внедрение ИИ в цикл разработки» (треть программы). Практика на воркшопах, разбор с цифрами от CTO и бизнеса прямо на сцене, понимание того, как меняется роль разработчика, когда код пишет агент. 

Saint TeamLead Conf 2026, 25–26 июня, Санкт-Петербург

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

Ну и плейлист, делимся, пока не устарел :)

Выступлений по теме “AI в SDLC” с прошедших DevOpsConf 2026, AiConf 2026, GolangConf  2026.

До встречи на конференциях!


Олег Бунин и
Команда Онтико, теперь вайбкодящая по ночам и скучающая по ночным застройкам :)

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

В программе Saint HighLoad++ 2026 вас ждут три доклада с конкретными подходами, решениями и выводами из production — опытом, который поможет по-новому посмотреть на собственную архитектуру, процессы и ограничения.

1️⃣ Architecture of an Instant Payment System (by Brazil). Pablo Aguilar (QuintoAndar).
Как устроен аналог СБП в Бразилии, как это всё работает с регуляторами и ЦБ и какие подводные грабли попались разработчикам.
Доклад будет интересен всем, кто занимается платежными системами у нас в стране, круто будет сравнить: как это не у нас, а у соседей в Бразилии. Там есть уникальные моменты, есть другая регуляторка. Также полезно будет пообщаться со спикером после доклада и узнать, как они работают с этими структурами, как это делается 😉

2️⃣ Автоматизация PostMortem: баланс между скоростью и качеством анализа критичных инцидентов. Андрей Давыдков (МТС Диджитал).
Живой кейс МТС: как Mission Control Center прошёл путь от Excel-табличек до AI-Copilot, который сам предлагает Root Cause и меры. Конкретные цифры: анализ инцидента ускорился в 3–4 раза, охват вырос кратно. Практичный доклад с рецептами, которые можно забрать «в понедельник».

3️⃣ Тест-драйв ClickHouse: 24 миллиарда событий в сутки. Сергей Волков (Сбер).
В вашей системе сбора метрик, логов или параметров задействованы Kafka и ClickHouse, и вы думаете, что вы в шоколаде? А проводили ли вы нагрузочное тестирование своей системы? Вооот! Вам точно будет интересно узнать, как это сделали инженеры из Сбера на трех разновеликих сетапах.

Если вы отвечаете за надёжность, эксплуатацию или развитие production-систем — сохраняйте эти доклады в своё личное расписание на конференции и воспользуйтесь возможностью обсудить детали со спикерами лично.

Встречаемся 22 и 23 июня в Санкт-Петербурге 🖐

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

На Saint HighLoad++ этим летом мы собрали отдельный стрим про ИИ в разработке. В программе — доклады, воркшопы, батлы и разборы решений от команд, которые уже внедряют ИИ в продакшен и готовы обсуждать не только удачные кейсы, но и то, что пошло не так.

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

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

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

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

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

На Saint HighLoad++ 2026 вы получите не только официальную часть программы, но также, не менее важное, живое взаимодействие: паузы между сессиями, пространства для спокойного обсуждения и кулуары.

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

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

➡️ Посмотрите программу конференции и выберите темы и форматы, которые помогут вам решить текущие задачи — и которые имеет смысл обсудить лично.

✋ С 1 июня финальное повышение цены, забронируйте билет заранее по текущей стоимости.

Переезды без боли, шардирование без даунтайма и эволюция архитектуры — записи трех докладов с конференции Saint HighLoad++ 2025 ⤵️

Как инженеры меняют работающие системы не через «переписать все с нуля», а постепенно: развивая, мигрируя и пересобирая production по частям. Разный масштаб, разные технологии, общий принцип — архитектурные изменения без остановки бизнеса.

1️⃣ История технической эволюции сервиса объявлений Авто.ру: от начала до наших дней. Андрей Борунов.
История сайта Авто.ру началась в 1996 году с простой доски объявлений и форума для автомобилистов. За прошедшее время он претерпел множество трансформаций, чтобы оставаться актуальным для пользователей и справляться с высокой нагрузкой. Это классическая история перехода от монолита к микросервисной архитектуре. Андрей рассказал, как происходила эта эволюция, и как сейчас они справляются с зоопарком из десятка микросервисов.

2️⃣ Переезд в облако рекламного движка с baremetal под высокой нагрузкой. Артем Букин.
В докладе: проблемы крупного монолита при переезде в облако; переход от stateful к stateless; способы транспорта данных; оркестрация применения данных в облаке; шардирование сервиса в облаке. На примере этого опыта вы узнаете, как перевести высоконагруженную систему с монолитной архитектурой и большим объемом данных на облачную инфраструктуру.

3️⃣ Как мы без downtime шардировали и мигрировали MongoDB на 20 ТБ. Иван Перевощиков.
Рассказ о типовой ситуации в большом бизнесе, когда команде приходится решать несколько задач одновременно: переезд базы в Kubernetes для запаса по нагрузке, решардирование со сменой ключа и все это без даунтайма. Иван показал, какие инструменты они выбрали, как доработали и что получилось.

Продуктивного просмотра 🙌

#записидокладов

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

В программе Saint HighLoad++ 2026 есть два доклада и мастер-класс, где эти решения разбираются через реальные инженерные ограничения и последствия выбора.

1️⃣ Вынос функционала из монолита. Алексей Лосев (Wildberries & Russ).
Бывает, что «распилить» монолит не хватает времени и ресурсов. Но есть критичный функционал, который необходимо вынести. В рамках мастер-класса участники решат задачу выноса сервиса мастер-баланса из монолитной банковской системы. По ходу изобретут несколько паттернов, обсудят плюсы и минусы различных технологических решений, погрузятся в особенности работы баз данных и шардирование.

2️⃣ MongoDB как единственное хранилище. Использование, проблемы, боль и последствия. Игорь Анохин (K2 Cloud).
Использовать инструменты, в которых у нас наибольшая экспертиза, — весьма эффективная стратегия. Но в какой момент наступит та самая грань, после чего инструмент все же стоит сменить? MongoDB для очередей/timeseries и подобие транзакционности — Игорь поделится таким опытом на примере облака.

3️⃣ Как организовать сетевую связность bare-metal Kubernetes. Антон Паус (Cloud.ru)
В докладе варианты построения сетевой связности для bare-metal узла Kubernetes через BGP или L2 связность.

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

До встречи 22 и 23 июня в Санкт-Петербурге на Saint HighLoad++ 2026 🙌