День знаний

Сегодня День знаний, с чем всех и поздравляю! 🍁 Знания объединяют нас на конференциях, в тематических чатах и каналах. 🤝 За прошедшие три месяца размер моего канала увеличился вдвое. 🚀 Это очень вдохновляет и мотивирует меня как автора. Спасибо вам, что присоединились, читаете, оставляете обратную связь и остаётесь лояльны. ❤️

Сегодня необычный пост, сегодня я хочу рассказать о себе. Для вновь прибывших, с кем мы еще незнакомы. В общем, давайте знакомиться! Не только со мной, но и друг с другом, если есть такое желание. ⬇️

Меня зовут Александр Межов. Я зашёл в мир профессиональной разработки в 2006 году, и с тех пор это моя жизнь и страсть. В моём послужном списке также есть 10 лет стажа в роли преподавателя ВУЗа, что оставило во мне тягу делиться личными открытиями и помогать всем, кто только начинает свой путь. 🤓

На данный момент я работаю в небольшой компании, в связи с чем совмещаю несколько ролей: техлид, архитектор, backend-разработчик, а в каких-то ситуациях даже системный аналитик. 😃 Последние 8 лет пишу на Java, до этого на C#.

➡️ О чём мой канал? Большая часть рассматриваемых тем касается System Design. Иногда я позволяю себе посты из разряда "философских рассуждений старпёра" 😃, но чаще всего про более насущные темы: архитектура, разработка, базы данных, личные наблюдения. Тут навигация по каналу, а тут подборка моих постов и статей.

➡️ Кому будет интересен? Думаю, что моя основная целевая аудитория — это backend-разработчики, техлиды, архитекторы и системные аналитики.

➡️ Как часто я пишу? Примерно раз в неделю и чаще всего long-read-ы.

⚠️ Для меня важны качество и полезность материала, поэтому, если вам нетрудно, пожалуйста, пройдите ➡️этот анонимный опрос. 🙏🏻 (Всего 5 вопросов с вариантами для выбора.)

Всем желаю успешного учебного года! Кто в теме, тот в теме. 😃

#pin

Доступность

Раз сегодня День знаний, то я подумал, что было бы неплохо обзавестись академической рубрикой #knowledge_day, в которой напоминать про вещи, которые хорошо бы знать и помнить каждому. И сегодня начнём с "девяток". 💯

Вы когда-нибудь пытались собрать несколько человек в одном месте в одно и то же время? Согласитесь, что это бывает нелегко даже для компании из трёх человек. И даже если двое уже на месте 🚀, третий может серьёзно опоздать. 🐌 Примерно то же самое может произойти и в программной системе, когда для выполнения какой-то операции нужен доступ к нескольким службам одновременно. Например, сходить в парочку микросервисов и БД.

Как только вы слышите на очередном собрании, что кто-то предлагает усложнить алгоритм добавлением еще одного звена, вспоминайте о доступности. Я давно заметил, что в пылу обсуждений об этом нередко забывают: "Для ускорения роутинга мы сделаем в PostgreSQL специальную таблицу..." Если PostgreSQL будет недоступен, то стабильный, но медленно работающий роутинг перестанет работать. Вы к этому готовы?

Доступность – это способность системы долго и непрерывно находиться в рабочем состоянии. Она измеряется в процентах. 100% означает, что сервис всегда работоспособен, но такой показатель практически недостижим, поэтому говорят о "девятках". Сервис с доступностью 99.99% недоступен 8.64 секунды в сутки.

🗂 Как вычислить общую доступность? Если компоненты работают последовательно, то вероятность полного отказа равна произведению вероятностей отдельных отказов. Допустим, у вас есть три компонента системы с известной доступностью: A=99%, B=98%, C=97%. Общая доступность равна: A*B*C=0.99*0.98*0.97=0.9411. Это значит, что такая система может быть недоступна (1-0.9411)*24=1.41 часа в сутки. Многовато, не так ли?

Я не специалист по этой теме, но знаю, где можно получить такие знания и попросить консультации:

🛫 Канал The Last of 9s
🛫 Чат QA — Load & Performance
🛫 Чат ALLSLO - все про SLO

ArchiMate убрать нельзя оставить

Наконец-то я добрался до просмотра обзорного вебинара про ArchiMate. Пять спикеров по 15 минут делятся опытом использования ArchiMate, рассказывают, чем они рисуют прямоугольники и стрелки. 😃

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

Итак, тезисно, что я для себя вынес. Что-то из этого было сказано явно, что-то является моими личными умозаключениями.

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

🔵 ArchiMate — это не догма, а стандартизированный графический язык моделирования. Он очень проработанный, зрелый, но с высоким порогом для входа. Если вы до сих пор эффективно решаете свои задачи без ArchiMate, не переживайте, вы всё делаете правильно.

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

🔵 В большинстве компаний нет явно выделенного архитектора, поэтому многим хватает моделей в стиле C4 Model и сопутствующих инструментов типа PlantUML, Structurizr, LikeC4. Про LikeC4 я услышал впервые, но он стал моим фаворитом, поэтому рекомендую!

🔵 Все хотят web-based-решение, т.к. это существенно упрощает коммуникацию. Картинки устаревают сразу после их отправки, а диаграмма по ссылке всегда актуальна и для ее просмотра не требуются предустановки. Также web-based-решения концентрируют все знания об архитектуре в одном месте и предоставляют возможность создания интерактивных диаграмм.

🔵 Продолжаю наблюдать повышенный интерес к теме AaC и связанные с ним вопросы: автогенерация архитектурных диаграмм, дизайн-ревью, автотестирование архитектуры. Многие начинают с автогенерации с использованием трэйсинга, анализа кода или deployment-файлов. Подробнее об этом см. по ссылкам 1, 📱 2, 📱 3.

🔵 Был наброс, что behavior-диаграммы не нужны, они очень быстро устаревают, а поддерживать их в актуальном состоянии очень сложно и дорого. Например, Sequence Diagram. Доля правды в этом есть, но с точки зрения разработчика именно behavior-диаграммы позволяют быстрей разобраться, что происходит, т.к. по одним статическим моделям о многих вещах можно лишь догадываться.

〰️〰️〰️

🟦⬜️⬛️ Близится День программиста и достаточно насыщенные выходные. Я собираюсь принять очное участие в E-CODE 2025 (13 и 14 сентября). Если кто-то будет там же, пишите, встретимся. 😉

➡️ Ещё у меня есть ссылка на одно крутое событие ➡️ онлайн-конференцию HighLoad++ Genesis, которая пройдет 13 сентября! Мероприятие бесплатное.

#view #arch

Волшебная кнопка

Прочитал отличную статью про тестирование, которую написал Александр Раковский, и она заставила меня подумать, что я хочу увидеть в любом проекте сразу, как говорится, с "порога". Представьте, вы приходите в новый проект, делаете git clone и...

За всё время повидал разные репозитории, стили, подходы, рылся и с удовольствием продолжаю рыться в open-source, открывая что-то новое. Но знаете, что всегда напрягает при первом рассмотрении? Когда для запуска проекта и начала разработки недостаточно просто открыть IDE и нажать "волшебную кнопку". ✨

Подобные вещи нужно делать сразу, со старта проекта, и с каждым днём двигаться к максимальному упрощению этого процесса. Реализация "волшебной кнопки" может быть разной. Реальная кнопка или run-конфигурация в IDE, shell-скрипт, инструкция с описанием простых шагов, команда в Gradle, эмулятор, тест и т.д.

Почему это важно?

➡️ Быстрый онбординг. Сотрудник не тратит время на настройку окружения, с этим он разберётся чуть позже. Главная задача на старте — как можно быстрей войти в предметную область проекта и познакомиться с его кодовой базой.

➡️ Культура автоматизации. Разработчик становится на шаг ближе к операционной команде; начинает задумываться о том, как и где его код будет работать, как его будут эксплуатировать. Больше никаких отговорок в стиле: "Не знаю, у меня всё работает 😄".

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

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

После 2-го курса проходил производственную практику. Руководитель для прикола дал задание настроить FTP-сервер. Ну, как настроить... Взять из стоящей в углу пыльной коробки комплектующие, собрать из них сервак, установить на него Linux, скомпилировать и настроить FTP. С заданием я справился, но суть вы поняли. Спустя годы я попал на проект, для работы в котором нужно было запустить 5 экземпляров IDE, настроить и связать между собой 5 экземпляров Tomcat, установить и настроить базу данных и т.д. и т.п. И таким в команде занимался каждый! 🐒 Следующие пару дней я потратил на автоматизацию запуска окружения и приложения в Docker. Время развёртывания сократилось до минуты. После этого разработчики реже прерывались на кофе, зато их глаза стали не такие красные. 😃

С чего можно начать?

1️⃣ Создайте в корне репозитория readme.md. Добавьте в него описание последовательности шагов, необходимых для сборки и запуска проекта.

2️⃣ Автоматизируйте описанные шаги. Можно не всё сразу, но шаг за шагом старайтесь сокращать количество ручных действий.

3️⃣ Вовремя актуализируйте эти артефакты. Чтобы всё и всегда было в актуальном состоянии, переиспользуйте эти практики в своём CI/CD.

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

〰️〰️〰️

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

#view #dev #devops

Вайб-аналитика

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

Недавно прошла онлайн-конференция Systems Design, посвящённая проектированию с помощью AI. Особенно примечательным был доклад "Как ИИ помогает закрыть разрыв между аналитиком и разработчиком" (📱 видео & презентация).

Ребята разрабатывают AI IDE для аналитиков и архитекторов. По факту это расширение для VSCode — AI IDE BAS (см. инструкцию по установке на официальном сайте). Установив расширение, появляется панель с AI-чатом, где можно выбирать роль, от имени которой будет происходить общение: бизнес-аналитик, системный аналитик, архитектор и т.д. Работа с каждой ролью сопровождается автоматическим созданием артефактов — Markdown-файлов и PlantUML-диаграмм. Весь необходимый контекст для ролей уже вшит в плагин, поэтому писать громоздкие промты не нужно, можно использовать естественный язык.

Выглядит очень заманчиво, поэтому я решил не откладывать всё в долгий ящик и попробовал проверить работу этого инструмента на знакомых мне задачах. Скажу сразу, что для "старта с нуля" это прям огонь! 🔥

➡️ Единая стилистика оформления
➡️ Структурированный набор артефактов
➡️ Краткость, последовательность и лаконичность описания
➡️ Согласованность всей выдачи
➡️ Наличие автопроверок

Разработчики, несомненно, знают толк в аналитике, поэтому инструмент стоит внимания, как минимум, чтобы посмотреть, "как принято в лучших домах", и сопоставить это со своим представлением о хорошем.

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

🗂Как кастомизировать контекст и создавать собственные роли? Открыть панель "AI IDE BAS". В левом нижнем углу, в переключателе ролей выбрать "шестерёнку", после чего откроется диалог "Modes". Для экспорта существующих ролей в текущую рабочую директорию нажмите "Export Rules"; для создания новой роли нажмите "плюсик". Роли будут экспортированы в каталог .roo; настройки каждой роли будут разложены по подкаталогам с префиксом rules-.

Теперь что касается AI. Подойдёт любая модель, совместимая с OpenAI. По умолчанию предлагается использовать DeepSeek. Однако я использовал бесплатную модель deepseek-chat-v3.1:free от OpenRouter (менять в настройках). Его дневного лимита хватает для достаточно продолжительного эксперимента.

#ai #tools #arch

Вайб-аналитика - запись митапа 📺

Вчера вечером относительно спонтанно сделал внутренний митап на тему AI IDE BAS, про который я написал вчера. Рассказал про первые впечатления и опыт настройки этого инструмента. На удивление получилось вполне смотрибельно, но если только поставить скорость воспроизведения на x1.5. 😃 Поэтому, если кого-то волнует эта тема, вот 📱 ссылка на запись (и презентацию).

Контракт между приложением и окружением

Наши приложения используют множество внешних зависимостей — библиотек, пакетов, модулей.📦 Между тем тестируется только разрабатываемый код, давая нам определённую уверенность в его надёжности. Но что там с надёжностью используемых зависимостей? По большому счёту, только наша вера.🤷🏻‍♂️

Конечно, я слукавил. В рамках обычного тестирования косвенно покрываются и внешние зависимости. Однако при этом речь идёт только об их функциональном тестировании, ведь нам доступен только публичный API библиотек, а реализация скрыта. И это нормально, в этом суть инкапсуляции.

Но как в таких условиях понять, что на самом деле производится за кулисами? Где взять уверенность, что вызываемый код делает только то, что нужно, и не более; не лезет туда, куда не просили; не использует больше ресурсов, чем предполагалось и т.д. Например, вызывая функцию Math.Max(x,y), мы наивно или интуитивно предполагаем, что примерно делается на уровне реализации. Ясно, что это простой пример, но если подумать, то значительная часть нашего кода основана на таких предположениях.

Во что это выливается на практике? Например, в аморфные Dockerfile's, в которых границы дозволенного для приложения либо совсем не определены, либо урезаны до предела. В первом случае, чтобы ничего не сломать у приложения; во втором, наоборот, чтобы ничего не сломать в инфраструктуре. Часто и справедливо идут по второму сценарию, выстраивая барьеры в виде различного рода изоляции, лимитов и т.п. Но если изоляция и лимитирование выполнены некорректно, это приводит к нестабильному или непредсказуемому поведению приложения, его многочасовой отладке и тестированию. Например, так возникает неожиданный OOM Killer, CPU throttling, VM pauses, временная недоступность, скачки/замедления/ускорения времени и т.п. Иногда всё это смешивается воедино, и с трудом понимаешь, что же пошло не так.

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

Например, если разрабатывается web-приложение, которое для обработки входящих запросов должно прослушивать 8080 порт и только его, то почему бы не объявить это явно? Разработчик это знает, следовательно, он мог бы это требование к окружению выразить в виде обычного кода. Аналогично, если приложению не нужен доступ на запись в файловую систему.

К счастью, такие механизмы есть, они доступны из коробки и являются частью возможностей ядра Linux. К сожалению, об этом мало кто знает, а тех, кто об этом говорит, ещё меньше. Одним из ярких представителей таких инструментов является проект Landlock. Посмотрите, как лаконично он позволяет объявить контракт между приложением и ОС.

err := landlock.V5.BestEffort().Restrict(
  landlock.RODirs("/usr", "/bin"),
  landlock.RWDirs("/tmp"),
  landlock.BindTCP(8080),
  landlock.ConnectTCP(5432),
)

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

Такая самоизоляция позволяет уменьшить поверхность возможной атаки и на корню избавиться от возможных zero-day-уязвимостей, которые могут (транзитивно) заехать через подключаемые внешние зависимости. При этом подход идеален для MSA, т.к. границы функциональности каждого микросервиса определены достаточно чётко.

〰️〰️〰️

С данной темой я выступил для студентов в минувший четверг. На самом деле необычные ощущения — вернуться в универ, ведь я не преподавал уже 8 лет.🙈 На мероприятие меня позвали спонтанно, за день до начала. Однако материал у меня уже был, поэтому надеюсь, что получилось хорошо. А пока только одна фотка со мной.😃

#conf

Решардирование данных через промежуточный топик

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

Контекст

Существует множество серверов для обслуживания большого потока пользовательских запросов. Например, для обработки поисковых запросов, сбора клиентской телеметрии, создания документов в крупной медицинской системе и т.д. Помимо основной логики обработки формируется лог запросов для их последующего (асинхронного) анализа. Лог запросов формируется в виде топика Log-based-брокера, например, в Apache Kafka, который обслуживает набор специализированных серверов-обработчиков. Такая обработка может формировать, например, топ поисковых запросов или список интересов пользователя.

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

Проблемы

➡️ Продюсеры берут на себя обязательства по обеспечению удобства обработки данных топика, в который они пишут.

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

➡️ Возможна слишком большая нагрузка на брокер и сеть, если количество продюсеров и партиций велико. Каждый продюсер создаёт TCP-соединение с брокером, отвечающим за партицию, в которую производится запись. При большом количестве партиций для P продюсеров и B брокеров будет создано P*B соединений. В результате при масштабировании системы могут существенно возрасти транспортные расходы, нагрузка на брокер и сеть.

Решение

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

Этот подход называется решардированием данных на основе промежуточного агрегирующего слоя.

Плюсы

👍 Продюсер пишет так, как ему удобно.

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

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

Минусы

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

👎 Отсутствие гарантий ACID. Соответственно, всё те же проблемы с гарантиями доставки, дублированием, идемпотентностью и т.п. (В YDB Topics эта проблема решена.)

👎 Увеличение времени доставки данных в целевой топик.

👎 Увеличение размера хранимых данных.

#tip #arch #tech

⬆️⬆️⬆️

Пример расчётов количества TCP-соединений с брокером и как их можно сократить за счёт промежуточного топика.

Предположим, для обработки пользовательских запросов необходимо поднять P=1000 серверов. Пусть всего имеется B=10 брокеров; а лог запросов партиционирован по идентификатору пользователя и имеет 1000 партиций. Скорей всего, в такой системе будет около P*B=1000*10=10000 TCP-соединений между продюсерами и брокерами (т.к. каждый продюсер будет соединён с каждым брокером).

Если добавить промежуточный топик с партиционированием по продюсеру, то уникальных ключей будет P=1000. Допустим, мы решили, что для такого топика достаточно сделать 10 партиций и, соответственно, до С=10 промежуточных консюмеров. В такой системе количество TCP-соединений с брокерами будет не более P*1+С*B=1000*1+10*10=1010, что на порядок меньше предыдущего варианта.

Второй закон архитектуры

Вчера в канале Руслана Сафина вышел пост, в котором он, в том числе, поднял тему, каким должен быть ИТ-архитектор, чтобы его не заменили на ИИ в (ближайшем) будущем.

Скажу сразу, что я согласен с его постановкой. Для меня всегда была важна структура знаний — дерево знаний. А технологические вещи я всегда считал за листья, которые меняются у дерева каждый сезон. Не держись за лист, иначе осенью тебя унесет ветром вместе с ним; держись за дерево и его корни. Познай искусство бонсай и взращивай своё дерево знаний, чтобы оно было крепким и здоровым. Рост не должен быть хаотичным, он должен быть последовательным, от корней к листьям, а не наоборот. 💪

Много раз становился свидетелем жалоб, что не успевают за прогрессом; что не могут понять, как работают инструменты, т.к. за частным не видели общего. В этой связи всегда давал один совет — пойти по пути структуризации знаний и найти место инструмента в дереве знаний. Понять, откуда выросла эта ветка, и почему так сложилось. Для этого нужны фундаментальные знания, а их проще получить через книги, а не статьи в стиле "how to".

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

Пока я думал над всем этим, я понял, что мы открыли "второй закон архитектуры", который был сформулирован Нилом Фордом и Марком Ричардсом:

Почему важнее, чем как.

(Первый закон: "Всё в архитектуре соткано из компромиссов".)

Подобные инсайты запускают очередную структуризацию мыслей. И круто, что приходим к одному и тому же, пусть и разными путями. 😉

#view #arch

Вспомогательная таблица для ускорения выборки

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

Контекст

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

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

Вполне вероятно, что в целях нормального распределения данных, их партиционирование будет выполнено по времени создания элементов данных (например, времени создания документа; времени снятия показаний). Гранулярность партиционирования определяется выбранной БД, объемом данных и интенсивностью их поступления.

Пример таблицы с показаниями датчиков в ClickHouse:

CREATE TABLE history (
  tag String,
  date Date DEFAULT toDate(time),
  time DateTime64(3, 'UTC'),
  value Float64
)
ENGINE = MergeTree()
PARTITION BY toYYYYMM(date)
ORDER BY (tag, date, time)

Проблемы

В системе очень часто (или всегда) запрашивают данные без указания временного диапазона, но, возможно, с указанием дополнительных фильтров. Например, получить документы по пациенту у терапевта; получить показания датчика со значениями выше нормы.

SELECT tag, time, value
FROM history
WHERE tag = :tag
  AND value > :value

Без указания временных границ приходится сканировать все партиции за всё время. В результате запрос выполняется очень долго и создает большую нагрузку на I/O.

Решение

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

CREATE MATERIALIZED VIEW history_info
ENGINE = ReplacingMergeTree()
PARTITION BY toYYYYMM(date)
ORDER BY (tag, date)
POPULATE
AS
SELECT tag, date
FROM history
GROUP BY tag, date

По такой таблице, например, можно очень быстро найти левую границу данных:

SELECT min(date)
FROM history_info
WHERE tag = :tag

Эту информацию можно использовать как подсказку в основном запросе:

SELECT tag, time, value
FROM history
WHERE tag = :tag
  AND value > :value
  AND date >= (
    SELECT min(date)
    FROM history_info
    WHERE tag = :tag
  )

➡️ Подобное решение можно адаптировать и под другие варианты партиционирования данных, а производная таблица "подсказок" может быть более или менее информативной. Основная её цель — это существенно сократить объем выборки без потери качества результата.

Плюсы

👍 Существенное ускорение времени выполнения запроса.

👍 Существенное снижение нагрузки на I/O.

Минусы

👎 Усложнение кода приложения для создания производной таблицы, наполнения её данными и поддержания их в актуальном состоянии. Если данная проблема решается средствами СУБД, как, например, в ClickHouse, то данный минус несущественный.

👎 Увеличение размера хранимых данных.

#tip #db

Как начать структурировать опыт

Друзья, а вы пробовали коротко, ёмко и понятно описать причину технической проблемы или неудачи? Если нет, то я очень рекомендую. Это упражнение позволяет отрефлексировать и структурировать только что полученный опыт. В этот момент вы занимаетесь огранкой алмаза, золотодобычей своего профессионализма. На входе у вас тонны грубой руды, а на выходе один прекрасный алмаз, бесценная частичка ваших знаний. 💎 В итоге насмотренность конвертируется в повышение квалификации. 💪

➡️ Упражнение очень простое. Заведите себе "дневник", в котором в свободном, но желательно единообразном формате, описывайте ситуацию, последовательность ваших действий, причину произошедшего и итоговое решение. Описание должно быть кратким, структурированным, но очень ёмким и понятным. Через некоторое время вы обязательно заметите положительный эффект. Как минимум, сможете блеснуть зрелостью своего опыта или получить больше уверенности на собеседовании. 🚀

На следующей неделе, 6 и 7 ноября пройдёт крупнейшая IT-конференция для разработчиков высоконагруженных систем — HighLoad++. Я буду выступать на Fail-митапе, где расскажу про свой самый крупный профессиональный фэйл за прошедшие 1.5 года. Многие знают, что подобные рассказы часто оказываются более ценными, чем красочный доклад про успешный успех. Fail-секция — это шанс быстро получить "огранённый" ценный опыт и не повторить чужих ошибок. Для меня этот формат в новинку, однако я надеюсь, что рассказ будет не только интересным и смешным, но и полезным. 🐒

Если будете вместе со мной на конференции, пишите. Познакомимся ближе, буду рад общению. 🤝 Как минимум, приходите на Fail-митап 6 ноября в 18:10. 🫰

#tip #conf

Ключевые темы HighLoad++ 2025

2 дня конференции, 5000+ участников, 10 параллельных треков, 121 доклад, 10 мастер-классов и, конечно же, Fail-митап. (На котором, я, надеюсь, не сильно зафэйлился. 😃) Вот таким стал прошедший HL++. 🚀 Очень много информации, которую нужно обработать и структурировать.

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

Много докладов было про AI (16). Очевидно, что эта тема стремительно врывается в нашу жизнь и диктует новые правила игры. Пока многие практические применения AI выглядят как обучение медведя катанию на велосипеде с целью его дальнейшей отправки на олимпиаду. Однако очень хорошо, что компании пытаются найти границы применимости AI. Короче, держим хвост по ветру и не теряем бдительности. 🐈

Традиционно для HL++ много докладов про архитектуру и масштабируемость (34), про мои любимые базы данных (17), низкоуровневые и хардкорные оптимизации. Короче, всё, за что мы любим HL++. 😄 Что-то я успел посмотреть очно, но большая часть находится в моём бэклоге. ⭐️

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

А ещё для нас смертных устроили открытую встречу с министром цифрового развития М.И. Шадаевым. Разговор получился долгим и достаточно откровенным. Надеюсь, что видео будет доступно в ближайшее время.

На финальной фотке виновники всего торжества, включая меня. Очень рад, что стал частью этой команды и мероприятия и, надеюсь, смог сделать его чуточку лучше. ❤️

#conf

Меры предосторожности при работе с РСУБД

В пылу сражения легко забыть базовые меры предосторожности. 👊 Именно по этой причине разговоры о подобных вещах всегда актуальны. Предлагаю пройтись по ключевым рекомендациям при работе с РСУБД. За основу взят зажигательный доклад "Хайлоад на ровном месте", дополненный моими комментариями. 🔥

0️⃣ Количество соединений с БД — это дорогой и ограниченный ресурс, который контролируется как со стороны БД, так и со стороны приложения. Чем больше параллельных обращений к БД, тем большего размера нужен пул соединений; иначе тот, кому не досталось соединения, зависнет до появления свободного. Следовательно, будут таймауты, рост числа wait-потоков, рост потребления памяти (как минимум, на стек), рост потребления CPU (как минимум, на переключение контекста) и множество ярких эмоций. 😄

1️⃣ Idle-соединение — это открытое, но не используемое соединение. Например, приложение открывает соединение, а затем начинает делать длительные вычисления (или даже поход во внешние сервисы), и только в конце начинает выполнять запросы к БД. При таком подходе пул соединений будет израсходован очень быстро, и указанные выше проблемы возникнут практически сразу.

2️⃣ Idle-in-transaction-соединение — это idle-соединение, в котором началось выполнение транзакции. Чаще всего такое провоцируют фреймворки. Например, Spring-аннотация @Transactional, помещённая на верхний уровень процесса обработки запроса, захватит не только работу с БД, но и весь остальной код. Ко всем вышеуказанным проблемам можно смело докинуть увеличение времени транзакции, длительные блокировки в БД, расходы на хранение версий (MVCC), раздувание WAL (Wall-Ahead Log).

🗂 Для "защиты" PostgreSQL от неблагонадёжных приложений следует использовать PgBouncer, который проксирует обращения к базе с целью пулинга соединений. Он позволяет активным соединениям вытеснять idle-соединения (но не idle-in-transaction), увеличивая тем самым общую пропускную способность.

3️⃣ Если транзакция открывается только для чтения (SELECTs), то при уровне изоляции Read Committed её лучше убрать, т.к. "толку" от неё всё равно не будет. Благодаря этому можно избавиться от idle-in-transaction-соединений. А вот если транзакция всё-таки нужна, тогда нужно повышать уровень изоляции, как минимум, до Repeatable Read, но такое нужно далеко не каждому.

4️⃣ Для минимизации времени блокировок в БД все UPDATEs в коде нужно сместить ближе к месту закрытия транзакции. Конечно, это не избавит от idle-in-transaction-соединений, но это лучше, чем ничего.

5️⃣ Пессимистичную блокировку следует применять, если много коллизий, т.е. имеется высокая конкурентность при изменениях. Однако часто достаточно оптимистичной блокировки, которая избавляет от необходимости явного открытия обрамляющей транзакции, следовательно, от описанных выше проблем. Если же пессимистичная блокировка всё-таки нужна, то её можно реализовать не на уровне БД, а с помощью внешних механизмов (например, key-value-хранилищ).

6️⃣ Медленные запросы могут исчерпать пул соединений, даже если таких запросов не очень много. Поэтому контролируем время выполнения запросов и анализируем планы запросов (explain). Частые проблемы: нет индексов на внешние ключи (foreign keys); используется антипаттерн OrIsNull; используется offset pagination (часто в сочетании с OrIsNull) вместо keyset pagination; выбираются лишние данные (особенно TOAST).

#tip #dev #devops

Базовые элементы архитектурного фреймворка

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

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

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

Как видите, архитектура системы — это не точка на прямой, а точка в многомерном пространстве (согласно авторам — в 4-мерном пространстве). В этом и кроется причина, по которой мы не можем дать архитектуре односложное определение, но можем описать её с разных сторон, одновременно отвечая на вопрос, почему решение именно такое, какое есть. Невозможно составить полное представление об архитектуре системы только по одному измерению, их нужно рассматривать в комплексе.

1️⃣ Структура системы (structure of the system) — тип используемого архитектурного стиля (или стилей). Например, микросервисная, многоуровневая, микроядерная и т.д. Стиль задаёт структуру, но не отвечает на вопрос "почему". Без всего остального — это просто прямоугольники и стрелки.

2️⃣ Свойства архитектуры (architecture characteristics) — важнейшие черты системы, определяющие критерии успеха. Свойства не связаны с функциональными возможностями системы, но нужны для её корректной работы. Авторы называют их "словами с окончанием -ость" (англ. -ility): масштабируемость, производительность, доступность, безопасность и т.д.

3️⃣ Архитектурные решения (architecture decisions) — правила построения системы и ограничения. Например, "доступ к базе данных возможен только с уровня бизнес-логики". Естественно, что решения не высечены в камне, и их можно и нужно подвергать сомнению. Главное, чтобы вокруг всего этого был выстроен процесс архитектурного контроля.

4️⃣ Принципы проектирования (design principles) — верхнеуровневые установки и рекомендации. Например, "для повышения производительности и ослабления связанности отдавать предпочтение асинхронному взаимодействию"; "для улучшения наблюдаемости использовать трассировку всех публичных методов сервиса" и т.п.

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

➡️ Как это всё связано с практикой и при чём тут фреймворк? Посмотрите на свою систему сквозь призму этих измерений. Для каждого ограниченного контекста определите 3 самых важных архитектурных свойства. Если у каждого контекста свой набор свойств, а у вас "монолит", тогда вам, возможно, следует задуматься о декомпозиции. Затем посмотрите на свои архитектурные решения и проверьте, способствуют ли они достижению выбранных свойств. А структура и принципы проектирования работают на общее дело? Я думаю, что вы уже поняли, как это работает.

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

〰️〰️〰️

Если вам зашла эта тема, ставьте реакции и я расскажу, как подобная практика может помочь избежать неприятностей в разработке. 😏

#arch

Декомпозиция в стиле квантовой архитектуры

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

Например, К. Ричардсон выделяет два основных подхода к декомпозиции:

🕚По бизнес-возможностям (by business capability). Система разбивается на области, в которых бизнес генерирует прибыль. Бизнес-возможности организации определяют то, чем она является. Это более стабильное описание, в отличие от того, как организация ведёт свой бизнес. Например, обработка платежей будет всегда, и неважно, как именно она будет реализована.

🕚 По поддоменам (by subdomains). Способ декомпозиции системы на основе подходов Domain-driven design (DDD). Каждый поддомен определяет ограниченный контекст (bounded context), который соответствует одному сервису.

🗂 Есть и более экзотические методы, которые я описывал ранее в статье "Как еще определять границы микросервисов".

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

Пожалуй, первое, что приходит на ум, это принципы ООП, сформулированные Р. Мартином, включая SRP (Single Responsibility) и CCP (Common Closure), а также его метрики успешности декомпозиции: абстрактность (соотношение абстрактных элементов к конкретным); нестабильность (соотношение исходящих связей компонента ко всем).

Однако всё это мне никогда не давало полной уверенности. Позже я понял причину: они нацелены в первую очередь на техническую сторону вопроса, а не прикладную; оценку существующего кода, а не того, который предстоит написать.

Думаю, по этой причине М. Ричардс и Н. Форд ввели понятие архитектурного кванта — уникального набора архитектурных свойств, действующих в рамках единицы развертывания — компонента (сервиса). При этом к свойствам предъявляются следующие требования.

1️⃣ Непредметный взгляд на проектирование. Функциональные требования определяют, что должно делать приложение, а архитектурные свойства задают эксплуатационные критерии успеха, способствующие реализации требований.

2️⃣ Влияние на структурные аспекты проектирования. Архитектурное свойство является таковым, если оно влияет на структуру проекта. Например, в одном случае безопасность — это архитектурное свойство, а в другом нет. При обработке платежей через сторонний сервис безопасность важна, но она не повлияет на структуру проекта и будет ограничена технологическими мерами (шифрование, хэширование и т.п.). А вот самостоятельная реализация платежей, возможно, потребует структурной и физической изоляции платёжного сервиса.

3️⃣ Ключевая или важная роль в успешности решения. Архитектурное свойство является таковым, если оно необходимо для успешной реализации. Поддержка каждого свойства усложняет проектирование, поддержка множества свойств — бессмысленна. Выбранные свойства должны работать на вас, а не наоборот.

О чём это говорит?

➡️ Производительность, масштабируемость, безопасность, надёжность, доступность — это только слова! В рамках отдельно взятого компонента они могут стать архитектурными свойствами только в том случае, если без них успех проекта невозможен. Понимание этого позволяет сфокусироваться на самых важных вещах и правильно расставить приоритеты.

И как это помогает оценить успешность декомпозиции?

➡️ Возьмите два взаимосвязанных сервиса и определите для них 3 самых важных архитектурных свойства. Каждый сервис — архитектурный квант, он определяет границы действия архитектурных свойств. Мысленно следуя по связи между сервисами, проверьте её адекватность. Если производительный сервис зависит от непроизводительного; безопасный — от небезопасного; масштабируемый — от немасштабируемого и т.д., значит, вы сделали что-то не так.

〰️〰️〰️

Всем добра и правильной декомпозиции! Если тема показалась интересной, поддержите меня. В следующий раз разберём, что есть помимо cohesion и coupling, и зачем это на практике. ❤️

#arch

Порочные связи между компонентами

Думаю, многие пытались оценивать качество своей архитектуры, анализируя входящие и исходящие связи между элементами. В этом контексте принято говорить о cohesion и coupling. А что насчёт качества связей? 😏

Принцип каскадного снижения связанности, предложенный Русланом Сафиным, контролирует баланс между cohesion и coupling на разных уровнях декомпозиции. Однако данный принцип, как и сами понятия cohesion и coupling, не отвечает на вопрос, насколько оправданы существующие связи, насколько они здоровы. Что если наличие связи между элементами не связывает их, а привязывает один к другому, сдерживая развитие обоих? Такие связи можно назвать обременительными, нездоровыми, порочными. 🫠

Большую попытку категоризировать виды связей предпринял Meilir Page-Jones в своей книге "What Every Programmer Should Know About Object-Oriented Design" (1996), введя понятие connascence (от лат. "рождённые вместе"). В русскоязычной литературе можно встретить прямую транслитерацию — коннасценция, но я предпочитаю слово взаимозависимость (interdependence), т.к. сам автор сказал, что это точный синоним.

Два элемента взаимозависимы, если для поддержания общей работоспособности они должны изменяться одновременно.

Вместе с определением было предложено несколько степеней взаимозависимости, которые подразделяются на две группы: статические (в программном коде) и динамические (во время исполнения). Подробные примеры можно найти на сайте https://connascence.io/

Как это можно привязать к практике?

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

Всё равно непонятно, давай рассмотрим пример!

➡️ Короче, во-первых, нужно убедиться, что декомпозиция сделана правильно. Это уже решит большую часть проблем со связями или, наоборот, выявит недостатки. Во-вторых, выявленные взаимозависимости нужно удалить или свести их влияние к минимуму. Например, вы заметили, как модель одного ограниченного контекста передается без изменений в другой. Что будет, если эта модель поменяется в одном из контекстов? Возможно, стоит задуматься об инкапсуляции транспортного слоя между двумя контекстами? Самый банальный вариант — использовать DTO.

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

Возьму на себя смелость сформулировать категории связей, актуальные на сегодняшний день:

🔗 Явная/неявная. Например, АОП провоцирует множество неявных связей и взаимополаганий.

🔗 Статическая/динамическая. Связь между компонентами предопределена или определяется во время исполнения.

🔗 Асинхронная/синхронная. Есть ли жесткая синхронизация взаимодействия компонентов, управляемая оркеструющим алгоритмом/механизмом.

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

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

〰️〰️〰️

Желаю всем здоровых связей! ❤️ А в следующий раз разберём, что с этим делать дальше. 🚀

#arch

9 архитектурных заблуждений о распределённых системах

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

Это цитата, а сами заблуждения сформулированы более 30 лет назад (1991-1997) и до сих пор актуальны. Авторство приписывают Peter Deutsch и некоторым инженерам из Sun Microsystems.

1️⃣ Сеть надёжна. Думаем о том, как будет совершаться вызов или доставляться сообщение. Обеспечение надёжности передачи можно возложить на внешние механизмы (инфраструктуру, очереди, оркестраторы, outbox и т.п.); и/или самостоятельную реализацию (retries, dead letter, deadline propagation, circuit breakers и т.п.). На этом же уровне думаем о возможной многократной доставке, порядке и идемпотентности обработки.

2️⃣ Нулевая задержка. Думаем, в какой сети происходит взаимодействие: в локальной или глобальной (через горы-моря-океаны). Задержка более проблематична, чем пропускная способность, ведь есть физические ограничения по скорости передачи. Соответственно, стараемся минимизировать количество сетевых взаимодействий; размер передаваемых данных; оптимизируем маршруты, необходимые для выполнения каждого сценария; вспоминаем про кэширование, пакетную обработку и локальность вычислений.

3️⃣ Неограниченная пропускная способность. Пропускная способность растет, но растут и наши потребности. Вопрос лишь в том, насколько они адекватны. Насколько адекватно, когда сервис возвращает модель из множества атрибутов, но из всех нужен только один? Умножаем размер одного такого сообщения на их количество в секунду и сравниваем полученный результат с пропускной способностью используемой сети, принимая во внимание возможные сетевые потери. Только на оптимизации трафика можно существенно сэкономить и улучшить показатели. Тут можно вспомнить и про бинарные форматы (Avro, Protobuf, MessagePack).

4️⃣ Сеть безопасна. С одной стороны, уровень безопасности должен соответствовать уровню возможных угроз. С другой, для атаки всегда пытаются найти самое слабое звено. Поэтому в идеале защита не только по внешнему периметру, но и внутри. Как минимум, стоит задуматься об аутентификации/авторизации запросов, разделении аккаунтов доступа к используемым ресурсам (БД и т.п.). Для себя я нашел очень хорошую шпаргалку по этой теме — OWASP Cheat Sheet.

5️⃣ Топология не меняется. После развертывания приложение уже не под вашим контролем. Считаем, что приложение развертывается в дикой и враждебной среде, где узлы появляются и исчезают в случайные моменты времени. Никогда не полагаемся на конкретные маршруты, узлы и IP-адреса; всё должно быть адаптивно. Изменение топологии не должно заставлять менять приложение.

6️⃣ Администратор всегда один. Проблема проявляется сильней, если есть отдельная операционная команда или даже отдельная организация, которая выполняет эту роль. Налаживаем коммуникации, автоматизируем развертывание, добавляем средства диагностики и инструкции использования. Всё это работает в обе стороны: упрощаете жизнь операционной команде — упрощаете жизнь себе.

7️⃣ Передача данных бесплатна. Сериализация/десериализация — это затраты на память и CPU; возможность передачи по сети — это затраты на оборудование и его обслуживание. Здесь архитектор и разработчик должны еще раз вернуться к заблуждениям 2 и 3.

8️⃣ Сеть однородна. Даже в локальной сети однородность — редкое достижение. Разные производители и ресурсы, ОС и приложения, разные версии API и т.д. Выжить в этом безумном мире помогает стандартизация и обратная совместимость.

И 9-е бонусное заблуждение лично от меня 😏

9️⃣ Контейнеры бесплатны. Не хватает производительности — докинем еще несколько экземпляров! Выглядит разумно для "тушения пожаров", но не в долгосрочной перспективе. Оптимизация кода или пересмотр решения — улучшают производительность; масштабирование — позволяет справиться с нагрузкой!

〰️〰️〰️

Думаю, что каждый увидел себя в каждом эпизоде! Но кто без греха?! 😃 Всем поменьше заблуждений! ❤️

#arch

Трансформация конференций

Если кто-то пропустил, то в течение года нарастал хайп на тему того, что текущий формат конференций уже устарел. И вот накануне нового года Онтико сформулировало концепцию "конференций развития", заявив об этом во всех своих каналах и чатах.

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

#conf