Интеграция и внешние идентификаторы

Необходимость интеграции с внешней системой — для многих это уже рутина, будни распределённых систем. Мы интегрируем сервисы/микросервисы, разные домены, встраиваем чужие решения в свои или наоборот. Однако что может пойти не так в давно работающей интеграции? 😏

Сначала сформулирую капитанские тезисы, а потом перейду к истории из реальной практики.

☑️ Контролируйте характер и размерность импортируемых данных.

☑️ Храните внешние идентификаторы с использованием универсальных типов данных.

〰️〰️〰️

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

В публичном API тип данных PersonID определён как long — 64-разрядное целое число. Выбранной размерности более чем достаточно, поскольку предполагается хранение данных не более чем для 100 миллионов человек. Всё работает прекрасно уже 15 лет, однако на этапе импортозамещения БД документов вскрылся один критический недостаток.

Во-первых, было обнаружено, что есть документы, у которых значение PersonID значительно превышает заявленные 100 миллионов. Например, максимальное значение на сегодняшний день составляет 9999998756120159. 😳 Во-вторых, данные свидетельствуют о значительных пропусках в диапазонах PersonID, хотя представители внешней системы заверяли, что у них обычный Sequence в PostgreSQL. Наконец, в ходе дальнейшего разговора выяснилось, что во внешней БД PersonID представлен типом данных NUMERIC(20) — целым числом размерностью до 20 десятичных разрядов. Это была вишенка на торте 🍑, т.к. в публичном API сейчас используется long, который позволяет работать с числами до 18 (с "хвостиком") десятичных разрядов. Что это значит для нас? Если такие скачки в генерации продолжатся, значения PersonID очень скоро выйдут за пределы размерности long и наш сервис не сможет сохранять новые документы. Последнее означает полную остановку нашего сервиса на неопределённый срок, что совершенно недопустимо.

Выхода из этой ситуации два:

1️⃣ В своей системе использовать тип данных, который один-в-один соответствует типу данных во внешней системе.

2️⃣ В своей системе использовать универсальный тип данных, а преобразование типов делать только на уровне сетевого взаимодействия.

Учитывая, что внешняя команда не предоставляет ни гарантий размерности для PersonID, ни внятного объяснения причин столь странных значений этого идентификатора, было принято решение пойти по второму пути, отвязав свою систему от особенностей мироустройства внешней. В итоге в новой импортозамещенной БД документов для хранения PersonID стали использовать строковый тип данных (text).

〰️〰️〰️
В этой истории мы приблизились к (эпик)фэйлу, но не допустили его и приготовились к негативному сценарию. 😃 Не стесняйтесь, делитесь своими фэйлами в комментариях. 😉⬇️

#arch #db

DevSecOps & Shift-Left

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

В чём, собственно, интерес. Во-первых, я думаю, что основные открытия и изменения нас ждут в междисциплинарных областях. Одни знают, но не могут; другие могут, но не знают. Очевидно, что с этой проблемой активно помогает справляться AI. Во-вторых, разработчики в основном сконцентрированы на архитектуре и функциональности. По данным Positive Technologies 82% уязвимостей обусловлено ошибками в коде. Да, исследование не очень свежее, но я не думаю, что соотношение концептуально поменялось. Иначе говоря, разработчики обычно и не задумываются о том, что их чистый код может быть уязвим, и, как правило, даже не знакомы с инструментами проверки кода на безопасность. В общем, я решил заполнить этот пробел и подготовить несколько постов на тему "DevSecOps глазами разработчика". Надеюсь, что будет интересно и познавательно, а также создаст предпосылки для обсуждения. 😏

〰️〰️〰️

Мало нам всяких XXXOps, появился еще и DevSecOps. 🙈 Суть заключается во встраивании автопроверок безопасности в цикл разработки с целью нахождения уязвимостей на самых ранних этапах. В контексте этого направления существует концепция Shift-Left — сдвиг проверок в левую часть цикла, то есть ближе к его началу. Это позволяет не допустить ошибки или значительно удешевить стоимость их исправления. 📈

Обратите внимание, что техника Shift-Left стала популярной не только в сфере ИБ. Если посмотреть недавние доклады на тему архитектурного контроля, то можно заметить тот же "сдвиг влево". Многие компании добавляют стадию согласования технического решения до момента его реализации, а некоторые автоматизируют этот процесс. На эту тему рекомендую посмотреть доклад про TDR от Павла Лакосникова (Авито). Аналогичные истории я слышал на прошедшем TechLeadConf.

Таким образом, DevSecOps-конвейер расширяет привычный нам CI/CD и состоит из нижеследующих этапов. Можно считать их "точками расширения", в которые можно встроить инструменты проверки на ИБ.

✅ Pre-commit — проверка кода до того, как он будет за-commit-чен (pre-commit hook). Как правило, производится сканирование кода на наличие незашифрованной конфиденциальной информации: пароли, токены, API-ключи и т.п. Типы инструментов: Secret Detection.

✅ Pre-build — проверка кода после того, как он был за-push-ен. Производится статический анализ исходного кода и его зависимостей на наличие распространённых уязвимостей (см. OWASP Top Ten) и лицензионной совместимости. Типы инструментов: Secret Detection, SAST, SCA.

✅ Post-build — проверка артефакта, собранного из исходного кода, например, JAR-архива, NuGet-пакета или Docker-образа. Производится анализ окружения и зависимостей приложения, отыскиваются устаревшие версии пакетов и библиотек. Типы инструментов: Binary SCA.

✅ Test-time — проверка приложения, которое запущено с целью тестирования из собранного артефакта. Производится попытка "сломать" приложение, имитируя действия злоумышленников, или обнаружить проблемы в runtime. Типы инструментов: DAST, OAST, IAST.

🚀 Post-deploy — обеспечение безопасности приложения после развёртывания в production-среде. Совокупность мер и средств, которые осуществляют мониторинг, анализ, обнаружение и блокировку подозрительной активности. Типы инструментов: RASP, Sandboxing, Self-sandboxing.

〰️〰️〰️

Предлагаю сильно не переживать на счёт неизвестных аббревиатур, т.к. в последующих постах я расскажу, что это такое и почему это не так страшно. 👔 А пока предлагаю посмотреть на OWASP Cheat Sheet Series — серию практичных рекомендаций, как можно улучшить безопасность своего кода (слева в навигаторе можно выбрать язык или технологию).

Делитесь историями про свою первую встречу с ИБ. 😃⬇️

#security #devops

DevSecOps - build phase

Первая фаза DevSecOps-конвейера относится к сборке. Сегодня предлагаю рассмотреть возможные проверки и инструменты этой фазы. Преимущество буду отдавать популярным open-source-решениям. ⬇️

Все проверки этой фазы выполняются методом белого/серого ящика — анализируется код, файлы проекта или метаданные артефактов сборки.

Pre-commit

На этапе Pre-commit можно настроить Secret Detection. Вызов сканера интегрируется в Git через pre-commit hook. Преимущества понятны, а вот к недостаткам следует отнести необходимость локальной установки и настройки, поддержка идентичности которой отдельная и крайне неприятная задача. Между тем, многие настройки можно положить в Git.

Управление секретами — прежде всего определённый уровень инженерной культуры проекта. Иначе говоря, сначала нужно договориться о способе работы с секретами, а потом вводить инструменты контроля. 👔

Инструменты:

🕚Trivy — универсальный сканер для обнаружения проблем с безопасностью. Производит анализ пакетов в SBOM, находит известные уязвимости (CVE), некорректные настройки в IaC, конфиденциальную информацию и секреты, проблемы с лицензированием. Имеет подробную документацию и интеграцию с множеством инструментов.

🕚gitleaks — сканер для детектирования секретов в Git-репозитории, файловой системе и stdin. Позволяет гибко настраивать правила проверки.

Pre-build

На этом уровне можно настроить следующие проверки:

✅ Secret Detection — обнаружение секретов, но уже после того, как изменения отправлены в центральный репозиторий. Инструменты: GitLab Secret Detection 🆓; Trivy; gitleaks.

✅ Static Application Security Testing (SAST) — анализ исходного кода на наличие распространённых уязвимостей. Отчёт включает список уязвимостей со ссылкой на конкретные фрагменты кода. 🎯 Статический анализ не запускает проверяемый код, следовательно, провоцирует множество ложно-положительных срабатываний и пропускает некоторые виды уязвимостей. Инструменты: GitLab SAST 🆓, GitFlic SAST; PVS-Studio SAST; SonarQube.

✅ Software Composition Analysis (SCA) — обнаружение уязвимостей в используемых зависимостях с открытым исходным кодом, анализ лицензионной совместимости и возможные риски нарушения лицензионных прав. Инструменты: Trivy; PVS-Studio SCA; GitLab Dependency Scanning; GitFlic SCA.

Как мне кажется, несмотря на все недостатки, по соотношению прилагаемых усилий и получаемого эффекта статический анализ остаётся самым простым и рабочим инструментом. Обратите внимание, что часть проверок доступна из коробки CI/CD, следовательно, подключить эти проверки будет проще. Некоторые инструменты могут быть интегрированы в IDE (Trivy, PVS-Studio).

📱 Для SCA требуется сформировать файл SBOM (метаописание проектных зависимостей). Они бывают разных форматов, поэтому выбирать нужно тот, который совместим с используемым SCA. В Java файл SBOM проще всего формировать на этапе сборки. Например, для генерации SBOM в формате CycloneDX используйте официальный Gradle-плагин.

Post-build

На этом уровне выполняется Binary SCA — обнаружение уязвимостей в бинарных артефактах, полученных после сборки. Проверяться может как содержимое файлов, так и их хэш-сумма. В последнем случае по хэш-сумме находят сведения о файле в открытых базах уязвимостей. Инструменты: GitLab Container Scanning 🆓; Trivy; grype; clair.

〰️〰️〰️

Был ли у вас позитивный опыт использования статических сканеров? 😉 Я тут вспомнил одну историю... ⬇️

#security #devops

Моделирование данных / Структуризация

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

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

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

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

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

Что нужно для хорошей организации:

☑️ Сформировать словарь предметной области. Язык предметной области (ubiquitous language), единство терминологии — это кости скелета системы. Расположите термины и их определения там, где они чаще всего используются. Например, в корне Git-репозитория. На ревью жёстко пресекайте любые вольности с терминологией.

☑️ Сформулировать соглашение об именовании. Единство стиля, единство подхода задаёт узнаваемую форму и устраняет разночтения и недопонимания. Некоторые IDE позволяют сохранять правила именования в Git-репозиторий, чтобы ими пользовалась вся команда. Дополнительно можно создать модульные тесты на проверку структуры.

☑️ Выбрать корректный критерий структуризации. Важность данного требования трудно переоценить, т.к. оно задаёт направление развития, определяет точки роста. Для этого нужны хорошие познания предметной области или, как минимум, проблематики. Согласитесь, что иначе предусмотреть логические слои или очертить ограниченные контексты будет крайне затруднительно. Подобные решения обязательно отражайте в ADR и технической документации.

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

Структура — важная составляющая для функционального роста системы. Именно по этой причине в основе известных подходов моделирования данных лежит определение способа организации данных. Например, Kimball's modeling, Inmon's modeling, Data Vault. Между тем, отсутствие единственно верного подхода подчёркивает, что нет универсальной и всеобъемлющей структуры, которая бы подходила всем. Мы, как архитекторы и разработчики, должны выбрать наиболее подходящий вариант, исходя из условий и ограничений.

〰️〰️〰️

Завтра я раскрою два других аспекта моделирования данных — переиспользование и производительность. А пока по традиции предлагаю делиться собственным опытом. 😉 Насколько у вас сильный болевой порог, когда видите беспорядок или нелогичность в организации? 😃

#view #arch #dev #db

Моделирование данных / Переиспользование

Удачная модель данных склонна к повторному использованию. Это позволяет строить новые конструкции на основе существующих. 🚀

Что нужно для переиспользования:

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

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

Например, стоит или нет выделять адрес клиента в отдельный элемент (Value Object или Entity)? Или лучше поместить эти данные in-plane в агрегат клиента? Если добавить отдельный элемент, то что делать, когда адрес может быть указан частично? Или когда адрес не может быть изменён, т.к. является частью бизнес-события, допустим, "адрес платежа". Даже в таком простом примере очень много нюансов.

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

#view #arch #dev #db

Моделирование данных / Производительность

Модель данных должна соответствовать характеру ее использования. Любое расхождение с этим приводит к снижению производительности. 📈

Такое часто наблюдается при использовании одной и той же модели для принципиально разных целей. Классический пример: сырые данные (OLTP) используются для построения отчётов (OLAP).

Моделирование не должно быть в отрыве от возможностей используемой базы данных. Иначе это будет то, на что чаще всего похоже использование ORM: швейцарский нож, который может многое, но имеет кучу ограничений — недонож, недоштопор, недоотвертка. (Заранее прошу прощения, если задел чувства верующих. 😃)

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

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

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

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

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

〰️〰️〰️

Я постарался описать моменты, на которые обращаю внимание в работе. Получается ли у меня всегда всё делать идеально? Нет, конечно. 😃 Есть разные преграды и обстоятельства, приходится идти на вынужденные компромиссы. Однако, главное — видеть цель и идти к ней. 💪

#view #arch #dev #db

Оптимистичная архитектура

Сегодня будет сказ про оптимистичную архитектуру. В нём можно разглядеть себя или своих знакомых. Основано на реальных событиях, но все совпадения случайны! 🎲😃

〰️〰️〰️

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

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

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

"Верни мне документы, которые удовлетворяют <этим> критериям, а из найденного я возьму только один-единственный атрибут"; "Найди все документы <этого> типа за всю историю существования системы, а я возьму только их количество"; "Найди <подобные> документы у всех клиентов" и т.д.

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

Выяснилось, что подобные запросы — это попытки внешних систем сделать какую-либо аналитику (OLAP) на основе исходных данных (OLTP). Однако микроядро по своей сути задумывалось как OLTP-фасад с функцией фильтрации документов внутри агрегата клиента. Однако благодаря оптимистично-многообещающему API поиска ситуация начала выходить из-под контроля.

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

〰️〰️〰️

Думаю, что история ясна и пора перейти к капитанским советам:

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

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

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

☑️ Универсальных моделей не бывает. Модель данных должна соответствовать характеру её использования. Мы не можем игнорировать этот аспект, в том числе и на уровне API. Если строим аналитику и отчётность на базе сырых данных, то важно помнить, что это может создать риски в будущем.

⁉️ А вы попадали в похожую долговую яму?

#arch

День знаний

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

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

Меня зовут Александр Межов. Я зашёл в мир профессиональной разработки в 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