Сейчас не особо слежу за около аналитическими каналами, но один из тех, что читаю - Системный сдвиг от Юрия Куприянова. Как по мне, самое ценно там - это комплексный взгляд на создание it-решений: от продукта и бизнеса, до архитектуры и технических деталей. Т.е. мышление аналитика здорового человека, а не “дайте требования, я вам апи и сиквенсы нарисую”.

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

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

Примеры интересного:

— инфографика с основными способами интеграции

— чек-лист стандартов в области интеграции и API

— 10 техник проверки полноты требований

— скрытая работа по проектированию систем, которую выполняет системный аналитик

— применение ChatGPT в работе системного аналитика: раз и два

А еще недавно Юрий был у нас в гостях, обсуждали профессию, перспективы, тренды и много всякого.

🔥🔥🔥 НОВЫЙ ВЕБИНАР
ИЗ АНАЛИТИКА В ПРОДАКТА #005!
И снова привет аналитикам в канале!

Наш специальный гость - Константин Семенов, автор канала Аналитик на галере, ваш любимый спикер конференций, который более 10 лет был аналитиком, и вот уже не первый год трудится продактом!

С Костей разговор будет более чем интересным. Вот лишь некоторые из тех вопросов. которые собираюсь ему задать:

💡 Продакт в заказной разработке - такое вообще возможно? Где такое бывает и в чем особенности?

💡 Мыши, вагоны, деньги, психотерапевты.. - менять домены как перчатки и не терять в качестве. Как???

💡 Западные vs Российские корпорации взглядом продакта. В чем принципиальная разница?

💡 Стать продактом в VK - какой нужен опыт и что спрашивают на собесе?

💡 Зачем продакту еще и свой пет-проект? И стоит ли заводить "питомца" аналитику

🔥22 апреля (вторник) 18:00🔥
РЕГИСТРАЦИЯ ➡️

_____
Приходи сам и пересылай пост коллегам - вдруг им это важно? Приноси с собой свои вопросы и сомнения - на все ответим. Записи прошлых вебинаров ищи тут

#карьера

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

#образование

Галлюцинации LLM - это не баг, а мега фича для образования.

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

Почему этот же паттерн не срабатывает при обучении у других людей?

Есть мировые авторитеты, условные Ричардсон, Ньюман, Фаулер, еще кто. У них большой опыт разработки, огромный в консалтинге, тысячи часов размышлений над темой. Значит ли, что их предпосылки и выводы всегда верны? Значит ли, что их опыт переносим в вашу сферу?

Нет, конечно. Обычно такие люди сами просят не принимать их слова на веру.

За ними идут эксперты с авторскими программами, где они напрямую делятся опытом. Но не такие известные в комьюнити. Значит ли, что их опыт “хуже”? Конечно, нет. Но и споров и челленджей со стороны комьюнити они могли пережить меньше. А могли больше.

Про школы с кураторами "от года", менторов-вкатнуов и прочих вспоминать не буду.

Интересно, как чОтко критическое мышление срабатывает на LLM, но отключается, если нам приглянулся образ или история человека. Если не доверяете глюкам AI - то обучение с ними может быть эффективнее и безопаснее, чем с людьми.

Галлюцинирую - значит, существуют

Кафка больше не центр вселенной

Яндекс предложил альтернативу и выкатил свой кафка-совместимый брокер - YDB Topics, заявляют повышенную надежность и масштабируемость из коробки, без дополнительных мучений.

Что это, и как оно работает, не представляю, но в среду нас зовут на вебинар, где обещают рассказать:

 • о транзакциях между топиками и таблицами, и почему больше не нужен Transactional Outbox

 • про механизмы CDC для отслеживания изменений и переноса данных внутри СУБД

 • как достигается доступность 99,99%, и как работает авто балансировка и мгновенное подключение новых ресурсов без участия человека

 • как внедрить YDB Topics в кровавом энтерпрайзе, с жесткими требованиями к безопасности

Характерно, что реализовали брокер, который тесно интегрирован со своей же базой - YDB. Идея не нова, но интересно посмотреть на реализацию.

В общем, приходите в среду 23 апреля в 12:00

🔗 Рега тут

У нас постепенно распространяется роль техпродакта, но пока нет единого мнения, что это за зверь. Поэтому сегодня делаем стрим с Леной Царьковой - техпродактом из Авито, в прошлом СА.

Сегодня в 19:00 мск, рега тут.

И думаю, он будет не последним.

#оффтоп

Не пускайте детей в интернет, он от этого тупеет - предупреждали нас в старых злобных рунетах.

Интересно, понимал ли автор, на сколько точно его фраза будет отражать реальность эпохи LLM?

#архитектура

Есть у нас традиция: каждый месяц зазываю всех в кейс-клуб NextWay, где мы собираемся небольшим кругом аналитиков / архитекторов / разрабов и самозабвенно предаемся архитектуре.

Если конкретнее, мы берем реальные задачи из разных доменов и проходим весь путь проектирования решения: от выявления требований к декомпозиции системы на сервисы, выбору технологий, проектированию апи и модели данных. Никаких книжных ютубов, url-shortner’ов и key-value хранилищ, с которыми вы никогда в жизни не встретитесь.

Вот примеры некоторых кейсов: выпуск и доставка карты, умная лента заказов для маркетплейса, система A/B-тестов, риалтайм доска “миро-заменитель”.

В субботу пилим онлайн-чат со службой поддержки. Фича, которую вы можете встретить почти в любом своем приложении. Будем работать с высокой нагрузкой, думать о масштабировании, выбирать read / write модели и типы хранилищ, сравнивать способы интеграции с точки зрения реализации НФТ.

Суббота, в 10:00 мск, рега тут

🗓 25 апреля, 18:30 мск, Пятница
📍Офлайн | 💻 Онлайн

🔧 Инструменты для тех, кто проектирует системы

Это будет пятница. Доклады по 10 минут, на которых —
каждый спикер отдаст в руки инструмент: фреймворк, методику или конкретный шаблон, которые можно применить уже в понедельник.

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

🎤 В конце ребята из ХАП проведут PowerPoint-караоке,
— команды, случайные слайды и импровизация на максималках.
И конечно же, "база": нетворкинг, закуски

Про инструменты расскажут:
🪛 Глеб Гончаров — придёт с инструментом архитектурных ката
🧲 Денис Бесков — принесёт ИИ-мультитул аналитика
🔩 Дмитрий Безгулый — JBTD-фреймворк для аналитиков и проектировщиков
🛠 Максим Чернухин — раскроет принцип проектирования против легаси
🧰 Дарья Мороз — придёт с UX-набором для документации

Организаторы — Ви.Tech, команда инженеров из ВсеИнструменты.ру
Спецгости и движ — Холиварные аналитические посиделки

Приходите — тут регистрация.

#конференции

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

Сам не попадаю, буду на DUMP. Кто тут из екб?

🗓 25 апреля, 18:30 мск, Пятница
📍Офлайн | 💻 Онлайн

🔧 Инструменты для тех, кто проектирует системы

Это будет пятница. Доклады по 10 минут, на которых —
каждый спикер отдаст в руки инструмент: фреймворк, методику или конкретный шаблон, которые можно применить уже в понедельник.

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

🎤 В конце ребята из ХАП проведут PowerPoint-караоке,
— команды, случайные слайды и импровизация на максималках.
И конечно же, "база": нетворкинг, закуски

Про инструменты расскажут:
🪛 Глеб Гончаров — придёт с инструментом архитектурных ката
🧲 Денис Бесков — принесёт ИИ-мультитул аналитика
🔩 Дмитрий Безгулый — JBTD-фреймворк для аналитиков и проектировщиков
🛠 Максим Чернухин — раскроет принцип проектирования против легаси
🧰 Дарья Мороз — придёт с UX-набором для документации

Организаторы — Ви.Tech, команда инженеров из ВсеИнструменты.ру
Спецгости и движ — Холиварные аналитические посиделки

Обязательно приходите — тут регистрация.

Кто о чем, а мы о сисдизайне

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

Стрим с Филом Дельгядо о сисдизайне на интервью

Несколько тезисов:

— Секция сисдизайна не показывает, может ли человек проектировать системы в рамках своих задач - внезапно, да?

— Многие кандидаты приходят со знаниями из книг по интервью. Причем интервьюеры тоже.

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

— Единообразие и прозрачность обычно противоречат эффективности. В том числе в найме.

— Отдать найм в команды, может быть намного эффективнее, чем делать его централизованным.

В целом рекомендую его выступления - живое руководство по критическому мышлению.

А вот доклад Александра Поломодова, как и почему проводят сисдизай секции в ТБанке

#архитектура

🔥 Снижай драматизм: уроки от Slack

Давайте сразу: проект провалился. Все, расходимся, жизнь кончена?! Да хрен там плавал!

Вот история Slack, который вырос из игры Glitch. Если по-простому: ребята несколько лет делали онлайн-игру, вбухали кучу денег и сил, но все никак. Игрушка не взлетела. Что, плакать и расходиться? Нет, они закрыли проект без лишних слез и заметили, что внутри команды круто работают их же внутренние чаты. И сделали пивот в корпоративный мессенджер. Теперь весь мир знает Slack.

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

Где логика в том, чтобы загонять команду в панику и драматически орать «мы горим!»? Это тупик, господа.

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

А у вас бывали пивоты в карьере или проекте, которые внезапно «выстреливали»?

Карьера продакта

Вот да

Чет устал я от анонсов, поэтому просто напоминалка: завтра начинаем курс по проектированию API.
Подробнее о нем писал тут, в том числе, почему это не только для джунов.

Еще в этот раз решил добавить бонус-занятие: посмотрим на TypeSpec как альтернативу Swagger, и помучать разные LLM для проектирования и документирования API - пусть вместо нас работают.

🚀 12-13 апреля пройдёт Третья онлайн-конференция Systems Design Online, посвящённая проектированию современных информационных систем для бизнеса.

Организатор конференции, школа системного анализа и проектирования Systems.Education, стремится развивать культуру проектирования эффективных информационных систем, делясь реальным практическим опытом, проверенными подходами и инновационными идеями. Именно поэтому главная тема конференции в этом году — «Компромиссы проектирования — баланс между атрибутами качества, финансированием и сроками».

🗓 Конференция Systems Design Online пройдёт в два дня:
12 апреля (сб) — день докладов
13 апреля (вс) — день мастер-классов и воркшопов

Вас будут ждать:
— Более 20 докладов от опытных архитекторов, аналитиков и технических лидеров
— 3 воркшопа и 2 мастер-класса с акцентом на практику
— 2 тематические секции: Архитектура, Искусственный интеллект и Машинное обучение
— Неограниченный доступ к записям всех докладов
— Постоянный чат в Telegram

Каждая из 2 секций в этом году будет раскрывать тему конференции с разных сторон:

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

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

👥Конференция Systems Design Online будет интересна:
— разработчикам и аналитикам
— архитекторам и руководителям ИТ-проектов

Подробнее о конференции здесь

Следить за новостями конференции можно в Telegram-канале @systems_design_online

План конференций на апрель:

— 11 апреля StormConf, о которой уже писал. Кто вживую собирается?

— 12-13 апреля Systems Design Online с большой секций по архитектуре

— 25 апреля DUMP в Екатеринбурге, буду рассказывать про API как продукт

— 26 апреля открытый Flow в олнайне, там вещаю про фейлы, которые собрали при проектировании этого API

Как бы еще везде успеть и выжить, пожалуйста.

#интеграция #API

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

С одной стороны, это Yet Another REST API Course для джунов-миддлов, чего вы там не видели? Люди знакомятся c HTTP, учатся делать типичный REST API, тестить и документировать сервиcы.

С другой - все чаще вижу на занятиях сеньоров и лидов. Зачем им это?

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

“Делать правильно” никому не нужно. Важно спроектировать API, которое не превратится через полгода в нечитаемое месиво, а под каждую доработку не нужно будет втыкать костыли на каждой стороне. Для этого мы разбираем уровни зрелости REST API, их границы применения, и когда стоит использовать RPC API.

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

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

Так что приходите за обязательной базой или расширением горизонтов. 5-23 апреля, рега тут.

Ультимативный гайд по софтам

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

1. Не давайте коммитов, пока полностью не поймете задачу. Если не понимаете - сообщите об этом и задайте вопросы.

2. Когда начинаете работать над задачей, дайте знать об этом заинтересованной стороне.

3. Если не можете взять задачу сразу или в оговоренные сроки - сразу сообщите об этом.

4. Если вы столкнулись с проблемой, и не можете ее решить - сообщите об этом.

5. Но перед этим попробуйте решить ее самостоятельно. Хотя бы подумайте над вариантами. Никто не любит тех, кто на каждый чих бежит паниковать.

6. Если понимаете, что не успеете в сроки - сообщите об этом сразу. Это никому не понравится, но отрулить будет на порядок проще, чем в последний момент.

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

8. Если на встрече у вас нет ответа на вопрос, так и скажите: пока не могу ответить, беру в работу. Буллшит-импровизации и попытки увильнуть видны почти всегда.

Поздравляю! Вы адекватнее ~83,57% людей на рынке.

#коммуникации #манагерское

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

Забирайте и проходите, если еще не. Штука не только полезная, но и залипательная - успокаивает лучше рыбок.

#конференции

Программа NextConf сухими цифрами:
- 3 практических воркшопа
- 4 доклада формата методички бери-и-делай
- 3 доклада про архитектурные подходы
- 3 карьерные активности, включая обзор рынка и круглый стол

У меня все. Встречаемся завтра.

#манагерское #книжное

Уже писал, что "требований" как вещи-в-себе не существует.

Ибо нет человека, который точно знает: если (не) сделать Х, то мы получим такой-то профит / урон. Бизнес всегда оперирует неопределенностью и вероятностями. Исключениями могут быть:

Заказная разработка
Подкладываем портянку "требований" к договору, по которому происходит оплата с приемкой. Спасает не всегда - с крупными клиентами можете остаться без денег или попасть в блеклист.

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

Что тогда приносят стейкхолдеры, продакты, бизнес-эксперты? Да что угодно: боли, хотелки, потребности, готовые решения, поток сознания - причем никогда не угадаешь, что они принесли в этот раз. Тогда что делать? Разбираться в людях и контексте.

Мне в этом плане нравится книга The Mom Test / Спросите вашу маму

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

Кому стоит прочитать:

 • Продакту и заказчику - чтобы понять контекст и проблемы клиентов / пользователей

 • Аналитику и тимлиду - чтобы понять, зачем эта фича нужна заказчику

 • Разрабу и QA - чтобы понять, зачем аналитик запихал этот метод в апи

 • Владельцу внутренней платформы типа ESB, CI/CD и т.п. - чтобы заранее планировать развитие ваших сервисов

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

Завтра делаем стрим о DDD с фокусом на то, как оно влияет на процессы и роли в команде, и какую ценность может создавать аналитик при таком подходе. Заходите на чаек

Нашелся репозиторий вида "все про интеграцию": технологии, паттерны, протоколы. Не знаю, как использовать, но может вам полезно будет: https://github.com/stn1slv/awesome-integration

Готовы окунуться в мир реального опыта, а не скучной теории? Тогда конференция "Опыт BPM из реального мира" для вас! Это событие, где каждая презентация — это не просто слова, а реальные кейсы и опыт (иногда грустный).

Что вас ждёт?

🎤 Спикеры из Т-банка, ВШЭ, YADRO, Glorax, ABPMP.
🎙 Живые истории и примеры: Только опыт, проверенный в реальных условиях, а не сухие теоретические выкладки.
🤝 Нетворкинг на максимум: Возможность познакомиться с профессионалами, обменяться опытом и найти новых единомышленников в дружеской атмосфере.

Дата и время:
11 апреля 2025, пятница, 09:30–19:00

Место проведения:
Москва, пр-т Мира, 36 строение 1 (Согласие Холл)

Не упустите шанс получить заряд практических знаний и ценные знакомства, которые помогут вам двигаться вперед! Ну и супер-классный мерч :)

Присоединяйтесь и убедитесь, что теория — это хорошо, но настоящий опыт меняет всё! 🚀

https://conf.stormbpmn.com/

erid: 2W5zFJ5nSet Реклама. ИП Котов Д.Г. ИНН 463312037917

#конференции

По плотности событий апрель можно объявлять месяцем аналитика, но начнем его на NextConf 29 марта - это как апрель, только на два дня раньше. Лейтмотив конфы - проектирование систем, которые работают, не падают, решают задачи бизнеса, состоят не только из костылей. Основные блоки:

— Работа с бизнесом, Event Storming, DDD

— Выявление НФТ, расчет нагрузки и ресурсов, проектирование распределенных систем

— Интеграция, координация бизнес-транзакций, работа данными

— Управление, документирование, рефакторинг архитектуры

— Немного поговорим о карьере аналитика и состоянии рынка

А вот темы про BPM в программу уже не поместились. За этим надо идти на StormConf 11 апреля - конфа от создателей того самого StormBPMN, оффлайн, с живыми людьми!

Тем временем мы опубликовали программу NextConf. Будет много про архитектуру, интеграции и данные. Пару тем еще уточняем, но спикеры и материал огнище. Сегодня лень писать рекламные тексты, поэтому смотрите программу и приходите 29 марта на воркшопы и доклады.

#карьера

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

Ну и если у вас мысли-вопросы есть, приходите пообщаться.
https://t.me/SmartSpeaker_public/256

#брокеры

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

Работа Кафки просто и наглядно

Шикарная визуализация работы Кафки: https://softwaremill.com/kafka-visualisation

И менее шикарная, но тоже пригодится: https://evoura.com/kafka-traffic-visualizer

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

Разбираемся с основами, начинаем здесь:

1. Установите: 1 брокер, 1 консьюмер группа, 1 консьюмер, 2 партиции. Посмотрите, как сообщения распределяются между партициями.

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

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

4. Перенесите третьего консьюмера в отдельную консьюмер группу. Сравните потребление сообщений в двух консьюмер группах.

Теперь понаблюдаем за работой с ключами, переключитесь сюда:

5. Установите 2 партиции, key range = 4. Посмотрите как сообщения с одинаковым ключом распределяются между партициями

6. Установите 3 партиции, потом 4.

7. Установите 6 партиций. Что изменилось? Почему так происходит?

Возвращаемся в основной симулятор:

8. Установите: 2 брокера, фактор репликации - 2, 1 консьюмер группа, 1 консьюмер. Посмотрите, где и как реплицируются партиции и сообщения.

9. Установите: 3 брокера, фактор репликации = 2. Посмотрите, как теперь работает репликация.

10. Установите: фактор репликации = 1. Посмотрите, как теперь работает репликация.

11. Установите: фактор репликации = 3. Обратите внимание, как распределяются между брокерами мастер-партиции (яркие) и их реплики (блеклые)

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

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

#брокеры

О планах на март

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

15 марта очередная встреча кейс-клуба, будем проектировать выпуск виртуальной карты, думать об управлении процессом, вспоминать о CQRS. Кто каждый раз просит напоминалку - вот она.

#архитектура

Выложили записи докладов с ArchDays’2024.

Был живьем, но большую часть времени провел на архкате. Буду теперь досматривать.

#архитектура

Есть академические штуки, о которых много говорят, но непонятно, как их применять на практике.

Например, CAP-PACELC теорема. Она рассматривает синхронизацию между нодами хранилища и задает нам два простых вопроса:

— Если сбой, что важнее: консистентость или доступность?

— Если штатно, что важнее: консистентность или скорость отклика?

Круто, и что мне с этим делать? Я архитектуру кафки и постгри проектировать не собираюсь. Чтобы кто-то садился и задавался вопросом: “Какую же модель мне выбрать для сервиса заявок: CP или AP??” - тоже никогда не встречал. Тогда зачем мне это кроме шаблонных собесов?

А если посмотреть шире?
Наш сервис-система-компания - это миллионы-миллиарды объектов, которые постоянно меняют свое состояние. Меняют в рамках определенных правил, ограничений, процессов, которые ведут к бизнес-цели. Фактически, мы занимаемся непрерывной синхронизацией состояний этих объектов.

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

Есть пара: процессинг заказов и платежный сервис, что критичнее
— консистетность или доступность?
— консистентность или время отклика?

А для пары процессинг заказов и бухгалтерия?

Из ответов следует выбор модели strong / eventually consistency. А из этого следует, как будем управлять распределенными транзакциями: оркестрация, хореография, воркфлоу и т.д. А из этого, где нам нужны будут ретраи с идемпотентностью, а где события будем кидать.

Получается, с самой верхней абстракции курьер-заказ до простенького ретрая мы постоянно думаем о согласованности, вокруг которой крутятся CAP-PACELC теоремы. Вот и бесполезный академизм на практике.

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

#манагерское

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

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

Как продакту, мне интересно делать идеальные продукты с совершенным UX и мегафичами, кастдевить пользователей и получать восторженный фидбек. И чтобы все было аналитикой обвешано - тестить дерзкие гипотезы и дизраптить рынок. Потому что это мегакруто. Правда еще выручку растить нужно, и чтобы экономика сходилась, иначе инвесторы денег не дадут. А тут эти технари с нытьем про техдолг и костыли.

Как предприниматель (у мен одного ощущение, что слово “бизнесмен” сейчас воспринимают как пошлый атавизм из 90х?) в гробу я видал всю эту вашу итшечку и смузи-фичи. Каждое утро я просыпаюсь и думаю, как бы вообще ничего не делать и побольше заработать. Вчера продал пару новых проектов крупным партнерам и собрал концепт нового стратегического направления. Нужно быстро запустить все за пару недель, максимум месяц. В смысле, какой проект важнее? Все важно, они издеваются что ли?! Даже сроки внятные назвать не могут.

Ну и что?
Чтобы заниматься наиболее интересными для себя вещами, придется понять и принять интересы других. И будет это ой как непросто. А задача манагера на разных уровнях - развивать это принятие и понимание в обе стороны.

Отправка событий от бека к фронту

Лень монтажить вебинар, пока вынесу с него интересный вопрос:

- Если WebSockets, HTTP/2, SSE позволяют слать сообщения с бека на фронт, то почему в основном говорят о WebSockets для двухстороннего взаимодействия?

Server Sent Events
Чтобы получать события с сервера клиент кидает GET-запрос с указанием в заголовках, что хочет сохранить соединение и получать события. Если сервер так умеет, то создается длительное соединение, и он начинает слать сообщения клиенту, пока кто-нибудь соединение не закроет.
Работает SSE поверх HTTP/1.1 и выше.

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

Если честно, я даже не знаком с людьми, которые использовали SSE. Нашел пару примеров:
⁃ В SuperJob их юзают просто чтобы не заморачиваться, как я понял.
⁃ Тут их используют для реализации subscriptions в GraphQL. Ну ок, есть логика

У вас был такой опыт? Поделитесь в комментах, плз.

HTTP/2
Взаимодействия между клиентам и сервером делятся на стримы. Каждый стрим состоит из одного request-сообщения и одного response-сообщения. Каждое сообщение может состоять из одного и более фреймов.

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

Получается, что внутри стрима мы можем слать фреймы в двух направлениях. НО - создать стрим может только клиент. Т.е. парадигма request-response в протоколе сохраняется.

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

На практике проще сразу брать gRPC, который использует эту механику. Но это новый стек, новые проблемы.
Либо заюзать те же SSE.

Почитать: Хардкорный разбор HTTP/2

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

Позволяет слать события только в обе стороны: сервер <—> клиент.
Сложнее в реализации, чем SSE, т.к. многие не умеют его готовить, нужно затаскивать новый протокол и тулинг в проект.

Почитать: основы вебсокетов, мини книга с погружением.

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

#интеграция

WAW 2025

На выхах добрался до WAW, который оставил неожиданно приятные впечатления. За счет небольших размеров получилось очень лампово и душевно, было время обсудить интересное. Только 1,5 дня мало((

Выделялись три основных темы: сисдизайн, лидерско-манагерское, AI. Трек сисдизайна получился особо удачно, спасибо Ане Вичуговой, Зое Степчевой и скромному мне. Надеюсь, никого не упустил?

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

Я же делал воркшоп по сисдизайну, где разбирали кейс доставки карты в сокращенном виде. Прошло бодро и активно, 5 из 6 команд дошли до конца, все довели решение до рабочей версии.

Несколько закономерностей, которые заметил еще в рамках нашего кейс-клуба:

Реализация НФТ
Характерное поведение аналитика: определить требования к нагрузке, доступности, масштабированию… и забыть про них. Не происходит валидации, как мы реализовали требования на уровне архитектуры, основное внимание уделяется бизнес сценариям. Не надо так;)

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

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

На другие секции удалось только мельком заглянуть, ничего конкретного не скажу.
Спасибо оргам и всем участникам за конфу, встретимся через год ❤‍🔥

#конференции

Выложили запись собеса сисаналитика в Т-Банке. Наверное, лучший из всех, что видел на ютубе.

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

Категорически рекомендую как нанимающим лидам, так и кандидатам.

У меня лишь один вопрос остался: если вот это все делает аналитик, то чем вообще занимается разработка?

Завтра в соседнем канале обсуждают сокращения в бигтехах и будущее IT-рынка РФ. Кто будет:

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

Михаил Максимов – опытный бизнес-аналитик и бизнес-архитектор, расскажет, как адаптироваться к изменениям.

Константин Семёнов – автор канала «Аналитик на галере», продакт в крупной российской компании, поделится ситуацией с аналитиками в продуктах в РФ.

Анна Вязанкина – лидер компетенции анализа в крупном интеграторе, ex-преподаватель курса «Системный аналитик», расскажет про ситуацию около крупного Enterprise.

Сам бы зашел, но буду вести вебинар по сетевому ликбезу для тех, кто занимается интеграциями.

Эти выхи буду на WAW. Кто еще там? Го чай пить и знакомиться.
А завтра утром веду воркшоп по сисдизайну - заходите, чтобы посмотреть, чем мы в нашей архсекте занимаемся.

#интеграция

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

Рега тут

#интеграция #архитектура

На фоне стабильной тенденции к переходу из аналитиков в архитектуру не менее стабильно возникает вопрос: “А как это делать вообще?”

Есть минимум два варианта:

— закопаться в книгах по архитектуре и штурмовать вакансии архитектора

— понять, что уже есть для нужной роли, и постепенно двигаться к ней, отбирая у кого-нибудь подходящие задачи

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

Сначала копнем в работу сетей и инфры, чтобы понять влияние на выбор технологий. Здесь же разберемся, как и почему работает балансировка. Дальше начинаем думать о надежности, и учимся использовать circuit breaker’ы, адаптивные ретраи и другие паттерны отказоустойчивости. Где-то рядом придется задуматься о производительности и кэшировании, а там и выборе технологии под кэш. А потом потребуют развесистый бизнес-процесс реализовать на несколько сервисов, и вот вам проектирование распределенной системы с транзакциями.

Таким образом получаем трек: локальные интеграции -> интеграционная архитектура -> полноценный сисдизайн. Останется еще с хранилищами попрактиковаться.

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

#архитектура

Еще одна фича архклуба - жестокое обращение с организаторами, каждый кейс перед релизом тестят на мне 🥴

Чтобы собрать сколько-то адекватную архитектуру онлайн-доски aka миро, пришлось вспоминать слова CQRS, EventSourcing, думать о конкуретности с блокировками, и вообще было больно в мозг.

Если хотите пострадать вместе со мной пощупать все это на практике и порешать незаезженный кейс - заходите завтра. Будет больно и весело.

Классная мини книга про вебсокеты.

• История и проблематика
• Детали работы протокола
• Масштабирование и отказоустойчивость

#интеграция

#интеграция #брокеры

Ничего мы вам не гарантировали. Часть 2
Начало тут

Если еще можно смириться с тем, что exactly once доставки не существует, то с at least once начинается откровенная шизофрения.

Использование at least once гарантирует, что сообщение будет доставлено не менее одного раза, верно? Внимание, вопрос: сколько раз реально может быть доставлено сообщение?

Правильно, сколько угодно. Или вообще не придти. Почему так?

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

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

Хотя таких случаев должно быть немного, на больших объемах может выстрелить. Но важно помнить - все врут.

#API #интеграция

REST и GraphQL

Продолжая прошлый пост. Если подумать, в REST и GraphQL заложены схожие идеи:

Граф объектов

◽️Согласно HATEOAS клиент перемещается по графу от объекта к объекту за счет их слинкованности и выполняет необходимые действия над объектами. Таким образом достигается само документируемость API.

◽️GraphQL сразу предоставляет схему графа, по которой клиент одним запросом получает необходимые объекты, заранее зная их структуру и связи между ними.

Разница в работе с графом определяет, возникают ли у нас проблемы с избыточными вызовами: N+1, получение разнородных объектов в одном ответе. Это корневая причина появления GraphQL.

Представления объектов

В обоих случаях клиент может получать объекты в нужном представлении. В ресте фокус на формат данных, в gql - на атрибутный состав.

Стандартизация допустимых действий
◽️HTTP-глаголы в для реста
◽️Query и mutations в GraphQL

При этом на практике GraphQL используют поверх HTTP, где он оказывается на нулевом уровне зрелости реста (или в RPC Swamp, как обозвал его Ричардсон), наследуя все проблемы RPC over HTTP.

В итоге идеи близки, реализации противоположны - забавный дуализм.

#архитектура

Первое правило аритектурного клуба - никому не рассказывать о клубе.

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

◽️Кто еще сомневается, можете почитать и решить, нужно ли это вам.

◽️Кто не в теме - мы регулярно встречаемся в сисдизайн клубе, где проектируем архитектуру под реальные задачи, а не избитые выдуманные кейсы из книг и ютуба. В прошлый раз была система A/B-тестов, в следующий раз будет риалтайм борда, которые активно растут на волне импортозамещения в РФ. Следующий раз - это 16го февраля.

П - прозрачность.

Кейс-клуб - сисдизайн здорового человека.

P.S. Тайминги лечим, верим в победу.

#API #интеграция

GraphQL. Не язык ты мне

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

Причины понятные:
◽️Если автор человек - тщеславие и личный бренд
◽️Опенсорсное решение - продвижение в массы в целях компании
◽️Проприетарное решение - нужно больше золота

Обыкновенные маркетинг, если кратко.

Та же история “языком запросов к API”. Что говорят авторы:
“GraphQL is a query language for APIs and a runtime for fulfilling those queries with your existing data”.

С их слов GraphQL это:
◽️язык запросов к API, что бы это не значило
◽️некий рантайм, в котором эти запросы обрабатываются

Начнем с языка, что видим:
1️⃣ Все запросы имеют определенную структуру, близкую к JSON
2️⃣ Ответы представлены в виде JSON, который имеет структуру из запроса с заполненными значениями
3️⃣ Не привязан к конкретному транспорту
4️⃣ Доступные действия и данные описывают с помощью своего Schema Definition Language - SDL

Ничего не напоминает?

Если брать п.1-3, то практически полной аналогией можно назвать JSON-RPC.

Если брать п.1-4, то все это SOAP.

Фактически, преред нами сетевой протокол уровня 7+ по модели OSI.

Ок, что там с рантаймом?
Для обработки запросов нужен некоторый компонент, который будет их парсить, валидировать, собирать/обновлять инфу из источников, публиковать SDL. Больше всех на слуху Apollo Server, но есть куча других опенсорсных и проприетарных решений.

Что, опять дежавю? Все так, тезисы полностью распространяются на тот же SOAP. Или gRCP, если сделать скидку на его бинарность.

В итоге получаем, что GraphQL это:
1️⃣ Протокол передачи данных
2️⃣ Технология с различными реализациями
3️⃣ Отчасти архитектурный подход к взаимодействию с фронтами

Вот и все, никакой мистики.

Здесь можно задать резонный вопрос: “Что ты придираешься, нормально звучит же: язык запросов”
◽️Во-первых, реально встречаю недопонимание у людей в этом вопросе.
◽️Во-вторых, если термин не несет новых смыслов, то зачем вообще его вводить?

А так, честный HATEOAS тоже можно языком запросов назвать, это даже корректнее будет.

Кто хочет копнуть глубже, посмотрите наш стрим с Денисом Лукьяновым, там еще куча материалов в описании.

#API

В разговоре отличное сравнение возникло: уровни зрелости REST API это как нормальные формы БД - описывают подходы к проектированию, но никак не отвечают на вопрос эффективности. Зрелый и нормальный - не значит эффективный для текущей задачи.

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

Хотя само слово “зрелость” выбрано максимально неудачно - Ричардсон, иди думай еще.

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

Кто ждал запись - вот она