GetAnalyst - Навыки • Системный анализ • Бизнес-анализ

🔔 Сегодня закрываем доступ к практикуму по микросервисной архитектуре 🔔 Если в проектах вы уже слышите Kafka, RabbitMQ, события, оркестрация, но пока не всегда понимаете, как это превращается в требования и архитектурные схемы, то этот урок стоит посмотреть сегодня. 🧡 Хореография и оркестрация микросервисов 🕘 За ~4 часа разберёте, как проектировать процессы в микросервисной архитектуре и показывать взаимодействие сервисов на схемах. 👉 Что внутри: 1️⃣ Монолит и микросервисы 2️⃣ Разработка схемы архитектуры 3️⃣ Оркестрация: практика 4️⃣ RabbitMQ и Kafka 5️⃣ Хореография: практика Практикум особенно полезен, если вы уже выросли из простых задач и хотите увереннее разбирать процессы, где участвуют несколько сервисов, брокер и внешние системы. 🔗 Забрать бесплатный доступ* *Если уже регистрировались — письмо с доступом на почте. Если письмо не нашли, можно зарегистрироваться повторно. 👉 Это полноформатный вводный урок к программе Проектирование архитектуры для СА. Бесплатный урок даёт вводную практику и глубокое понимание отдельной темы. А на основной программе будем собирать архитектурное мышление системно: от схем до решений, которые можно защищать перед командой. 🚀 Узнать о курсе по Архитектуре для СА Вопросы? Пишите @getanalyst 🤝 —- P.S. За обратную связь огромнейшая признательность, очень ценю 💖

Ирина пришла к нам, когда уже меняла работу. То есть не в моменте “когда-нибудь потом пригодится”, а когда новые знания нужны прямо сейчас. А дальше всё сложилось идеально: 👉 новый проект, Kafka, микросервисы, много систем и взаимодействий. В такой ситуации архитектура перестаёт быть абстрактной темой “для общего развития”. Она становится способом быстрее понять новую систему: какие сервисы за что отвечают, потоки данных, связи, почему изменение в одном месте может внезапно "стрельнуть" в другом. 👉 Особенно ценно видеть, как человек в момент смены работы берёт задачи сложнее, и постепенно чувствует себя увереннее на новом уровне. Ирина, спасибо за доверие и удачи на новом месте! 💜 #студентыGetAnalyst 📱 Tg | 💙 ВК | 💬 Max

🎷 Оркестрация микросервисов: от схемы к требованиям 🎷 Оркестрация – это подход, при котором специальный сервис-оркестратор выступает «дирижёром» для группы микросервисов (МС). 👉 Оркестратор централизованно управляет сложным бизнес-процессом: 1. знает какие сервисы вызвать по API (обычно REST / gRPC) 2. в каком порядке 3. работает с условиями, сложными алгоритмами 4. если что-то пойдёт не так, то он "откатит" операцию на всех МС, которые уже были вызваны Так сложный процесс превращается в цепочку задач. А единый центр контроля "Оркестратор" следит за их выполнением. 🔗 Подробная теория 👉 Как работает оркестратор на примере Интернет-магазина: 1. Покупатель оформляет заказ через Web-приложение. 2. Web-приложение отправляет API-запрос на Backend, в API Gateway.

POST .../orders

3. API Gateway маршрутизирует запрос на Оркестратор. 4. Оркестратор присваивает id новой операции и вызывает API сервиса заказов. 5. Сервис Заказов создает новый заказ в БД. Результат - в Оркестратор. 6. Оркестратор вызывает сервис Склада, чтобы зарезервировать товар. 7. Склад подтверждает резерв или сообщает об отсутствии товара. Результат - в Оркестратор. 8. Оркестратор вызывает сервис Доставка для оформления отправления. 9. Сервис доставки рассчитывает маршрут и время доставки, оформляет доставку. Результат - в Оркестратор. 10. Оркестратор вызывает сервис Уведомлений, чтобы отправить покупателю уведомление (e-mail или SMS) о подтверждении заказа и деталях доставки. 11. Сервис Уведомлений выполняет отправку сообщений. Результат - в Оркестратор. 12. Оркестратор отправляет итоговый ответ на запрос в API Gateway, откуда он возвращается в Web-приложение. 🔹 Оркестратор вызывает API сервисов и ждёт ответ. 🔹Он может сохранять состояние процесса, чтобы возобновить его при сбое. 🔹 Если что-то идёт не так, оркестратор выполнит компенсации - откатит выполненные шаги. Так что к написанному надо добавлять требования к обработке ошибок. 📦 Популярные решения для оркестрации: ▫️ Camunda – BPM-движок с поддержкой диаграмм процессов (BPMN). ▫️ OpenBPM - аналог Camunda в России. #АрхитектураGA 📱 Tg | 💙 ВК | 💬 Max

⚡ Все говорят про AI-агентов. Но что это значит для аналитика? 🤖 Давайте разберёмся. 👉 Чем агент отличается от общения с AI в чате Вы пишете промпт в чат и получаете ответ. Новое сообщение — новый ответ. Любое новое действие = написать новое сообщение. Это простое общение с генеративным AI. Это не AI-агент. AI-агент — это когда модель сама решает, что делать дальше.

Получила задачу → выбрала инструмент → выполнила шаг → посмотрела на результат → решила, что делать следующим шагом.

И так по кругу, без участия человека на каждом шаге. Пример простого AI-агента: 1. Говорим агенту «проверь все открытые задачи в Jira и сформируй отчёт». 2. AI-агент сам заходит в Jira, сам фильтрует, сам структурирует, сам пишет отчёт. 3. Мы получаем итоговый результат. 🕓 Что ещё круче обычного диалога с AI — AI-агент может запускаться без нашего участия, а по событию или по расписанию. 👉 Из чего состоит агент — минимум, который надо знать: ▫️ LLM — мозг. принимает решения, генерирует текст ▫️ Tools – инструменты: поиск в интернете, запросы к API, работа с файлами, выполнение кода ▫️ Memory — память: краткосрочная (контекст сессии) и долгосрочная (база знаний, векторное хранилище) ▫️ Оркестратор — логика: в каком порядке запускать шаги, как обрабатывать ошибки 👉 Почему аналитику важно изучать как работают AI-агенты и как их создавать Потому что агент — это не просто разработческая история, а архитектурная. Когда бизнес говорит «хотим автоматизировать обработку заявок через ИИ», то аналитик должен уметь ответить на вопросы: ▫️ Какие инструменты нужны агенту? (доступ к каким системам) ▫️ Где граница автономии: что агент решает сам, что эскалирует человеку? ▫️ Как логировать действия агента для аудита? ▫️ Что происходит при ошибке на одном из шагов? ▫️ Кто и как валидирует результат работы AI-агента? Это требования. И их кто-то должен написать. 👉 Паттерны проектирования AI-агентов: ▫️ ReAct — агент чередует «думаю» и «делаю», объясняя свои шаги ▫️ Plan & Execute — сначала строит план целиком, потом выполняет ▫️ Multi-agent — несколько агентов с разными ролями: один ищет, другой анализирует, третий пишет итог ▫️ Human-in-the-loop — агент останавливается и ждёт подтверждения на критических шагах Последний паттерн обязателен в любой системе, где агент влияет на реальные данные или деньги. Если этого нет в архитектуре — это не фича, это баг, который ещё не случился. 👉 Где строят агентов ▫️ n8n — визуальный конструктор, схема агента собирается по аналогии с bpmn. ▫️ Claude Cowork — даёшь цель, агент сам работает с твоими файлами и приложениями на компьютере, возвращает готовый результат. Для нетехнических специалистов. ▫️ Claude Code — то же, но для разработчиков и вайбкодеров: работает в терминале, читает весь код проекта, пишет и редактирует файлы, запускает тесты, итерирует — всё через естественный язык. ▫️ LangChain / LangGraph — фреймворки для разработчиков, здесь реализуют ReAct и Multi-agent. Аналитику знать детали необязательно, но понимать структуру — полезно. AI-агенты — это новый класс систем, которые надо уметь проектировать. Аналитик, который понимает агентную архитектуру — это уже новый уровень в профессии. #AI_for_analysts 📱 Tg | 💙 ВК | 💬 Max

🟠 Открыли бесплатный доступ к 4-часовой практике по архитектуре 🟣 Не мини-урок на 20 минут и не “послушать про микросервисы в целом”. Разбираем то, где у аналитиков обычно начинается путаница: когда один процесс проходит через несколько сервисов, брокер сообщений, события и внешние системы. Что важно понять: ▫️ кто управляет процессом ▫️ где нужен прямой API-вызов ▫️ где лучше использовать RabbitMQ или Kafka ▫️ как распределить ответственность между сервисами ▫️ чем хореография отличается от оркестрации на практике ▫️ как показать это на архитектурной схеме 🧡 Хореография и оркестрация микросервисов 📅 Только до 9 июня (вт) 🕘 4 часа практики 👉 План: 1. Основы архитектуры систем: монолит и микросервисы 2. Разработка схемы архитектуры для проекта 3. Оркестрация процессов: практика 4. Введение в брокеры сообщений (RabbitMQ, Kafka) 5. Хореография процессов: практика 🔗 Забрать бесплатный доступ* *Если уже регистрировались — письмо с доступом на почте. Если письмо не нашли, можно зарегистрироваться повторно. Продуктивной практики! 🧡

🔖 База знаний по брокерам для СА: теория + практика + примеры 📚 Делимся с вами подборкой статей, постов и подкастов, которые помогут разобраться с темой: 📌 Брокеры и очереди — общая теория 📚 Очередь сообщений - что это и как работает? 📝 Всё про брокеры: как работают и зачем нужны 📝 Очередь vs Брокер: вопросы с подвохом 📝 Хореография и оркестрация в микросервисной архитектуре 📝 7 вопросов с подвохом по Архитектуре: хореография + понимание брокеров в EDA 📌 Kafka 📙 Официальная документация 📝 Kafka - что надо знать для работы СА 📝 Устройство Kafka 📝 Алгоритм работы Kafka 📝 Как встроить Kafka в архитектуру, и главное зачем 📝 Пример использования Kafka - проект #FarmFreshGA 📝 Kafka в деле: подробный разбор примера использования в МСА 🎧 Kafka: что нужно знать Системному аналитику 📌 RabbitMQ 📙 Официальная документация 📝 Брокер RabbitMQ - полный гайд с разбором примера использования в микросервисах 📚 Брокер RabbitMQ - пошаговая практика по развёрыванию и тестированию через CloudAMPQ 🎧 RabbitMQ и его отличия от Kafka: что важно знать системным аналитикам 📌 Постановки задач / ТЗ 📝 Пример реального интеграционного Use Case: с микросервисами, cron и kafka - проект BookingGA 📝 Пример технического Use Case с брокером в микросервисной архитектуре - проект GreenChargeGA 📚 Книги ▫️ Apache Kafka. Потоковая обработка и анализ данных. Гвен Шапира ▫️ Kafka в действии. Дилан Скотт ▫️ Проектирование событийно-ориентированных систем. Бэн Стопфорд (есть в открытом доступе) Сохраняйте — пригодится для изучения темы с нуля, подготовки к собеседованиям и структурирования знаний 🤝 #АрхитектураGA 📱 Tg | 💙 ВК | 💬 Max

🐇 Брокер RabbitMQ - полный гайд 🐇 1. Что такое RabbitMQ и зачем он нужен 2. Как работает RabbitMQ 3. Очереди, обменники (exchange), routing и binding key - ключевая терминология и внутреннее устройство брокера 4. Типы обменников: direct, fanout, topic, headers 5. Пошаговый разбор: пример использования RabbitMQ в микросервисной архитектуре Подробно разбирали брокер в подкасте: 🎧 RabbitMQ и его отличия от Kafka: что важно знать системным аналитикам Сохраняйте в избранное, пригодится и в работе, и перед собеседованиями 🔖 #АрхитектураGA

Когда в проекте появляются брокеры, микросервисы и десятки интеграций между ними, «просто описать требования» уже недостаточно. Нужно понимать как проектировать архитектуру. Именно это разбираем на практической программе: 💎 Проектирование архитектуры 🗓 Старт — 9 июня Программа для Middle+ аналитиков, которые хотят выйти на уровень Senior / Solutions Architect. ▫️ Монолит, SOA, микросервисы ▫️ C4 для понятных архитектурных схем ▫️ НФТ для проекта ▫️ REST, GraphQL, gRPC, WebSocket ▫️ Kafka и RabbitMQ для асинхронных интеграций 🎁 Предзапись завершается сегодня: скидка + мини-курс «Интеграции 4.0» в подарок ➕ Бесплатный вводный практикум "Хореография и оркестрация микросервисов" с 6 по 9 июня Если думали, решайте сегодня. 👉 Занять место со скидкой Вопросы: @getanalyst

⭐️ Архитектура Kafka: топики, партиции, брокеры, кластеры ⭐️ ✔️ Топики (Topics) 1) Логическая категория или тема, куда Продюсеры отправляют сообщения, а Потребители их читают 2) Представляют собой поток сообщений, где каждое имеет: ключ, значение, метаданные 3) Не удаляют сообщения сразу после обработки — данные хранятся в топике в течение заданного времени 4) Могут быть разделены на партиции, что позволяет распределять нагрузку между Продюсерами и Консьюмерами ✔️ Партиции (Partitions) 1) Каждый топик состоит из одной или нескольких партиций (разделов) 2) Сообщения внутри партиции хранятся в строгом порядке (FIFO — "первым пришёл, первым обработался") 3) Разные партиции могут обрабатываться параллельно, что увеличивает производительность Kafka 4) Каждое сообщение в партиции получает уникальный порядковый номер (offset), который используется Потребителями для чтения данных 5) Продюсеры могут отправлять сообщения в партиции автоматически или по определённому ключу (например, все заказы одного клиента попадут в одну партицию) 6) Один потребитель из Группы Консьюмеров читает данные только из своей партиции, что позволяет распределять нагрузку. 7) Повышение надежности обеспечивается через репликацию: выделяют Leader Replica (основная копия данных партиции) и Follower Replica (копирует данные лидера в синхронном или асинхронном режиме) ✔️ Брокеры (Brokers) 1) Хранят топики и их партиции 2) Обрабатывают запросы Продюсеров на запись и Консьюмеров на чтение данных 3) Управляют репликацией партиций для отказоустойчивости 4) Автоматически перераспределяют нагрузку при добавлении новых брокеров в кластер ✔️ Кластер (Cluster) 1) Это группа брокеров, работающих вместе для масштабирования и распределённой обработки данных 2) Использует ZooKeeper или KRaft для координации (назначает лидеров партиций, отслеживает состояние брокеров) 3) Позволяет добавлять новые брокеры без остановки системы 4) Поддерживает автоматическое восстановление при сбоях отдельных узлов #АрхитектураGA 📱 Tg | 💙 ВК | 💬 Max

⭐️ Kafka — что надо знать для работы Системному аналитику ⭐️ Apache Kafka — это распределённая платформа потоковой обработки данных. Предназначена для публикации, хранения и обработки событий/сообщений в реальном времени. Основные компоненты: ✔️ Продюсеры (Producers) 1) Генерируют сообщения/события к обработке и отправляют в топики (темы). 2) Определяют, в какую партицию топика записывать данные: автоматически или по заданным правилам. 3) Могут быть чем угодно: микросервисы, устройства IoT и другие приложения. 4) Поддерживают режимы отправки: + Синхронный — ждёт подтверждения от Kafka перед отправкой следующего сообщения. + Асинхронный — отправляет сообщения без ожидания ответа. 5) Могут гарантировать доставку с разными уровнями подтверждения (acks): + acks=0 — без ожидания подтверждения (возможна потеря данных, высокая скорость). + acks=1 — подтверждение только от лидера партиции (среднее). + acks=all — подтверждение от всех реплик (максимальная надёжность). ✔️ Потребители (Consumers) 1) Подписываются на один или несколько топиков и получают сообщения/события. 2) Могут работать как отдельные клиенты или объединяться в группы (Consumer Groups) для параллельной обработки сообщений. 3) В группе консьюмеров каждый участник обрабатывает свою часть партиций. 4) Kafka гарантирует, что каждое сообщение будет обработано хотя бы одним потребителем в группе. 5) Модели доставки сообщений: + at-least-once — как минимум 1 раз, возможны дубликаты. + exactly-once — ровно один раз. ✔️ Топики (Topics) — логическая тема, куда продюсеры отправляют сообщения, а потребители их читают ✔️ Партиции (Partitions) — подмножество данных внутри топика, которое позволяет распределять нагрузку и масштабировать обработку сообщений. Каждый топик состоит из одной или нескольких партиций ✔️ Брокер (Broker) — сервер Kafka, который отвечает за хранение, управление и передачу данных внутри кластера ✔️ Кластер — это группа брокеров, работающих вместе для масштабирования и распределённой обработки данных #АрхитектураGA 📱 Tg | 💙 ВК | 💬 Max

🧡 [6–9 июня] Хореография и оркестрация микросервисов: открытый практикум для аналитиков 🧡 В простых задачах всё понятно: Frontend → Backend → БД. Но в распределённой архитектуре один процесс может затрагивать сразу несколько сервисов, брокер сообщений и внешние системы. И аналитику нужно решить: ▫️ кто запускает процесс ▫️ какой сервис отвечает за каждый шаг ▫️ где использовать прямой API-вызов ▫️ где передавать события через Kafka или RabbitMQ ▫️ когда нужна оркестрация, а когда — хореография ▫️ как всё это показать на архитектурной схеме 👉 Этому и посвящён новый практикум по хореографии и оркестрации микросервисов. На занятии вы разберёте: ✔️ как устроены процессы в микросервисной архитектуре; ✔️ как проектировать оркестрацию и хореографию; ✔️ какую роль играют RabbitMQ и Kafka; ✔️ как отображать взаимодействия сервисов на схемах. Подойдёт системным аналитикам, которые уже работают с интеграциями и проектированием систем и хотят глубже разобраться в микросервисной архитектуре, событийном взаимодействии и построении сложных процессов. 🧡 Хореография и оркестрация микросервисов: практика проектирования процессов 📅 Доступ 6 - 9 июня 🕘 Время на обучение: ~4 часа 🎯 Формат: урок в записи, можно пройти в удобное время 🔗 Зарегистрироваться Это полноформатный вводный урок к практической программе «Проектирование архитектуры» для системных аналитиков, которая стартует 9 июня. Если к активному осеннему найму хотите увереннее работать с архитектурой, проектировать сложные процессы и претендовать на более сильные позиции — присоединяйтесь 🙌 Вопросы? Пишите @getanalyst или на info@getanalyst.ru.

🚦 Всё про брокеры: как работают и зачем нужны 🚥 Брокеры — это посредники в передаче сообщений между системами или сервисами. Они позволяют асинхронно обмениваться данными и обеспечивают гарантию доставки сообщений. 👉 Принцип работы: ▫️ Сервис 1 (Producer/ Производитель) хочет отправить данные в Сервис 2 (Consumer/ Потребитель). ▫️ Сервис 2 в это время может быть перегружен или занят. ▫️ Чтобы Сервис 1 не ждал, пока Сервис 2 станет доступен, он кладет сообщение в Брокер и продолжает свою работу. ▫️ Брокер сохраняет сообщение и ставит его в очередь к обработке. ▫️ Как только Сервис 2 становится доступен, то он забирает сообщение из Брокера и обрабатывает его. По сути брокеры - это временные Базы Данных,которые гарантируют, что сообщения (данные) в них будут храниться, пока их не заберут и не обработают соответствующие системы или сервисы. НО! Это всё же не БД, хранить в них сообщения до бесконечности не надо. 👉 Брокеры могут использоваться: + в сервисной и микросервисной архитектуре (хореография), + в событийно-ориентированной архитектуре (EDA), + когда нужна фоновая обработка событий в монолите, + для асинхронных интеграций. 👉 Брокеры сообщений предлагают два основных шаблона обмена данными: 1. Точка-точка (Point-to-Point Messaging) Это паттерн, используемый в очередях сообщений, где существует один отправитель и один получатель. Каждое сообщение в очереди отправляется только одному получателю и может быть обработано только один раз. 2. Публикация-подписка (Publish/Subscribe) В этом паттерне отправитель (producer) публикует сообщения в определённую тему (topic), а подписчики (consumers) подписываются на темы, чтобы получать сообщения. Все сообщения, опубликованные в теме, доставляются всем приложениям, подписанным на неё. Применяется в случаях, где несколько систем должны получить одну и ту же информацию. Возможности и логика работы брокеров отличаются в зависимости от конкретного решения. Основные решения по брокерам на рынке: ✅ Apache Kafka ✅ RabbitMQ ✅ ActiveMQ ✅ Amazon MQ, Amazon SQS ✅ Яндекс Message Queue (YMQ) - аналог Amazon ✅ и другие. #АрхитектураGA 📱 Tg | 💙 ВК | 💬 Max

🎻 Всё про оркестрацию: как работает и зачем нужна 🎻 Оркестрация — это паттерн управления взаимодействием сервисов, при котором один центральный компонент (оркестратор) координирует все вызовы и определяет порядок действий. 👉 Принцип работы: 1. Клиент отправляет запрос оркестратору 2. Оркестратор вызывает Сервис 1, ждёт ответа 3. Оркестратор передаёт результат работы Сервиса 1 в Сервис 2, ждёт ответа 4. Оркестратор передаёт результат работы Сервиса 2 в Сервис 3, ждёт ответа 5. Оркестратор собирает итоговый ответ и возвращает клиенту (на картинке к посту - это API Gateway). Сервисы не знают друг о друге. Они знают только Оркестратора. Если вдруг в процессе вызова одного из них происходит ошибка, то Оркестратор может запустить компенсационные действия - отмену всех предыдущих шагов, которые уже могли быть выполнены. 👉 Когда применяется: • Когда важен строгий порядок вызова сервисов • Когда нужна централизованная обработка ошибок и компенсирующие транзакции • Когда бизнес-процесс сложный и его надо видеть целиком — оркестратор позволяет централизированно следить за логикой выполнения сложного алгоритма 👉 Паттерны проектирования микросервисов, где есть оркестратор: ✅ Saga (оркестрация) Длинная транзакция разбивается на шаги. Каждый шаг выполняет отдельный микросервис. Оркестратор вызывает каждый сервис по очереди. Если шаг падает — оркестратор запускает компенсирующие транзакции в обратном порядке. Пример для Интернет-магазина:

Заказ оформлен → списать деньги → зарезервировать товар → передать в доставку. ❌ Если доставка недоступна — вернуть резерв → вернуть деньги

✅ Process Manager Расширенный вариант Saga. Оркестратор хранит состояние процесса и может обрабатывать более сложные ветвления — не только линейную цепочку, но и условия, параллельные ветки, таймауты. 👉 Инструменты: ▫️ Camunda — BPM-движок, оркестрация на основе BPMN-схем, есть визуальный редактор ▫️ Apache Camel — интеграционный фреймворк, классика для оркестрации в enterprise ▫️ Temporal — современный инструмент для оркестрации распределённых workflow, ▫️ AWS Step Functions — облачная оркестрация от Amazon, описание через состояния ▫️ и другие. 👉 Плюсы и минусы: ✅ Логика процесса видна в одном месте — легко отлаживать и менять ✅ Централизованная обработка ошибок ✅ Проще трассировать и мониторить 🚩 Оркестратор становится точкой отказа 🚩 Все сервисы завязаны на оркестратора — если он меняется, затрагиваются все 🚩 При большом количестве процессов оркестратор превращается в «умный монолит» Полезные материалы: 🔗 Camunda и BPMN в микросервисах: успешный кейс для оркестрации процессов техподдержки По сути оркестрация — это про централизованный контроль и предсказуемость Когда бизнес-процесс критичный, порядок важен и ошибки нужно обрабатывать явно — оркестрация выигрывает у подхода с хореографией. #АрхитектураGA 📱 Tg | 💙 ВК | 💬 Max

Обучение в Johns Hopkins University было ошибкой 🤡 Я пошла туда с мыслью: «Ну всё, сейчас разберусь, как работает AI, и хотя бы на год закрою вопросы с новым обучением». А в итоге AI уже тихо переставляет мебель в моих карьерных планах 😄 В апреле я закончила программу Applied Generative AI в Johns Hopkins University. И не успела нормально выдохнуть после одного семестра, как взяла на следующий Agentic AI. Потому что я уже зашла слишком далеко, чтобы просто остановиться. Не зря же я начала программировать 🙈 Сейчас я активно использую Claude Code, настраиваю AI-агентов, собираю приложения и экспериментирую на своих задачах. И периодически чувствую себя человеком, который открыл слишком много дверей одновременно. Инструментов много. Возможностей ещё больше. 👉 А в голове местами красивый, но всё-таки хаос. Хочу его структурировать. Мне важно понять, как лучше проектировать AI-агентов, как встраивать их в архитектуру больших систем, где они реально полезны и что из этого можно применять в работе аналитика. А остаться именно в Johns Hopkins решила потому, что мне очень близко, как там дают AI: глубоко, наглядно и через практику. Собственно, именно так я сама стараюсь строить обучение в GetAnalyst. Всё самое полезное, как обычно, принесу аналитикам в GetAnalyst ❤️‍🔥 Так что пока отдыхаю, насколько получится. А с июля снова учёба 🤓 И да, это уже не просто интерес к AI, а новые карьерные планы.

❌🤖 Перестаньте использовать ИИ как простой чат-бот: настройте проекты под свои задачи 🤖🚀 Многие работают с нейросетями так: «Сделай мне диаграмму» «Напиши Use Case» «Спроектируй REST API» И каждый раз заново объясняют контекст, правила, формат результата и другие детали. В надежде, что ИИ сам быстро научится понимать задачи. Но в ИИ есть продвинутая функция — проекты. 📌 Проект — это рабочее пространство под конкретную аналитическую задачу. Поддерживается в: ChatGPT Qwen Claude Perplexity и других инструментах. ✅ Зачем это? Чтобы один раз настроить правила работы ИИ, загрузить примеры хороших результатов — и больше не собирать контекст с нуля в каждом новом чате. Проект превращает ИИ из “разового помощника” в настроенный рабочий инструмент под вашу задачу: ▫️ C4-диаграммы ▫️ UML ▫️ Use Cases ▫️ проектирование REST API ▫️ бизнес-требования ▫️ интеграционные сценарии 👉 Например, можно создать проект: "C4-диаграммы через Structurizr" И один раз добавить туда: ▫️ системный промпт ▫️ правила генерации диаграмм ▫️ примеры идеального кода ▫️ ваши требования к оформлению схем После этого вы не объясняете всё заново в каждом новом чате. Вы просто пишете: «Сделай C4 Container для медицинской системы» И получаете результат уже в нужном формате, в который вносите минимум правок. 👉 Пример простого системного промпта под C4, который можно добавить в проект:

Работай как системный аналитик и архитектор ПО с опытом более 10 лет в enterprise проектах.

Твоя задача — проектировать C4-диаграммы в формате Structurizr DSL.

Всегда:
- используй уровни C4: Context, Container, Component, если это уместно;
- явно показывай пользователей, внешние системы, backend-приложения, frontend-приложения, БД, брокеры и API Gateway;
- подписывай протоколы взаимодействия: REST API, GraphQL, WebSocket, Kafka, gRPC и т.д.;
- добавляй краткие описания для систем, контейнеров и связей;
- не придумывай лишние сервисы без необходимости;
- возвращай только готовый Structurizr DSL-код и короткое пояснение к схеме.

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

Дальше добавляете в проект 2–3 примера вашего идеального Structurizr-кода в виде файлов и всё. Настроенные проекты под разные задачи экономят аналитику не менее 10 часов в неделю. Не только потому что ИИ «делает работу за вас». А потому что вы перестаёте каждый раз объяснять ему одно и то же. 👉 Начать можно с одного проекта. Не нужно сразу настраивать десятки рабочих пространств под все задачи. Сделайте один проект под то, что чаще всего повторяется в вашей работе: диаграммы, Use Cases, REST API или требования. И вы быстро почувствуете разницу между “просто спросить у ИИ” и “работать с настроенным инструментом”. Ещё больше про ИИ для СА в @getanalysts 🤝 #AI_for_analysts #АрхитектураGA

💎 Хореография и оркестрация микросервисов: практика [6–9 июня] 💎 Микросервисная архитектура — это не только про то, чтобы разделить систему на отдельные сервисы. Главное начинается дальше: нужно спроектировать, как эти сервисы будут взаимодействовать в реальных бизнес-процессах. Аналитику важно понимать, кто за что отвечает, как передаются данные, где нужны события, а где лучше использовать прямые вызовы или оркестрацию. На новом практическом занятии разберём, как проектировать такие процессы и показывать их на архитектурных схемах. 💎 Хореография и оркестрация микросервисов: практика проектирования процессов 📅 Доступ 6 - 9 июня (сб-вт) 🕘 Время на обучение: ~4 часа 🎯 Формат: урок в записи, можно смотреть в удобное время 🔗 Зарегистрироваться 👉 План: 1. Основы архитектуры систем: монолит и микросервисы 2. Разработка схемы архитектуры 3. Оркестрация процессов: практика 4. Введение в брокеры (RabbitMQ, Kafka) 5. Хореография процессов: практика 👉 Практикум полезен, если вы: ✔️ уже работаете с API и интеграциями, но хотите глубже понимать микросервисную архитектуру ✔️ готовитесь к интервью на Middle+/Senior системного аналитика; ✔️ часто слышите на проектах “Kafka”, “RabbitMQ”, “события”,“микросервисы”, но хотите разложить это в понятную систему ✔️ стремитесь работать с более сложными архитектурными задачами, а не только с экранами, CRUD и простыми API. Есть планы разбираться в интеграциях микросервисов? Регистрируйтесь и смотрите практикум в удобное время с 6 по 9 июня 👍

😰 Уволить или обучать? 😰 Жёсткий, но очень честный вопрос для любого руководителя. Отвечаю. Проблема не всегда в том, что человек «чего-то не знает». Есть вещи, которые обучением почти не лечатся. ✅ Ошибся, признал и пришёл с вариантом исправления. Или обсудить, как такое не допустить в будущем? Обучать. Потому что ошибка — это не катастрофа. Катастрофа — это когда человек защищает ошибку до последнего, перекладывает ответственность на разработчиков, тестировщиков, заказчика, ретроградный Меркурий и «непонятный контекст». ✅ Медленный, но внимательный и с горящими глазами? Обучать. Скорость приходит с практикой. Особенно, если человек умеет задавать вопросы, принимает обратную связь и не боится сложных задач. ✅ Мало знает, но хочет расти? Обучать. Навыки наращиваются: API, интеграции, БД, микросервисы. Главное, чтобы человек не делал вид, что уже всё знает. 🚩 Ноет, что всё плохо? Уволить. Если человек видит риски и аргументирует — это ценно. Если человек просто разрушает энергию команды и заражает всех ощущением «ничего не получится» — это проблема. 👉 Системный аналитик должен видеть проблемы. Но зрелый аналитик приносит не только проблему, а ещё и варианты решения. 🚩 Сдал задачу в разработку = снял ответственность. Уволить. Потому что аналитик — это не человек, который «написал документ и ушёл». Он связывает бизнес, разработку, тестирование, поддержку. Если он не помогает команде переводить с бизнесового на разработческий — он не выполняет ключевую часть своей роли. 🚩 Даёт результаты, но токсичен в общении? Уволить. Можно быть сильным специалистом, но если после каждого созвона команда выгорает, разработчики боятся задавать вопросы, а тестировщики получают ответы в стиле «ну это же очевидно» — это разрушает рабочую среду. Высокий уровень экспертизы не даёт права быть токсичным. 🚩 Оспаривает каждое решение? Уволить. Если аналитик спорит аргументированно, защищает качество системы и помогает найти слабые места — это плюс. Если спорит ради спора, чтобы показать свою ценность, саботирует договорённости и не может принять командное решение — это уже не критическое мышление, а управленческая проблема. 🚩 Умный, но не разделяет миссию продукта или компании. Уволить. Потому что аналитик влияет на решения. Он участвует в формировании требований, архитектурных обсуждениях, приоритизации, коммуникации с бизнесом. Если человек внутренне не верит в то, что команда строит, он будет постоянно тормозить движение. Иногда не специально. Просто потому что у него другая картина мира. Я более 7 лет руковожу проектами на 1млн+ пользователей. Я более 3 лет веду свой бизнес с командой на 20+ человек. Я не хочу быть вовлеченной в задачи своих сотрудников, сидеть как «курица наседка» и следить за каждым. 👉 Уволить или заменить? Мой вывод такой:

Обучать стоит тех, у кого не хватает навыков, но есть ответственность, честность, интерес и желание расти.

А расставаться стоит с теми, кто разрушает команду: токсичностью, вечным негативом, отсутствием ответственности или саботажем общего направления. Потому что сильная команда строится не только на hard skills. Иногда один человек с хорошими навыками, но плохим отношением к людям наносит системе больше ущерба, чем джун, который пока путает POST и GET, но хочет разобраться 🙌

✅ Что такое API Gateway: 10 главных функций и роль в архитектуре [полный гайд] ✅ API Gateway (API-шлюз) — это единая точка входа для всех клиентских запросов к Backend. Обычно используется в микросервисной архитектуре. ❗️ Это такой же микросервис, как и сервис авторизации, сервис платежей и другие сервисы системы. На картинке к посту его можно также показывать синим прямоугольником. 👉 Главная функция API Gateway — маршрутизация запросов. Но, помимо этого, API Gateway предоставляет и другие важные функции: 1️⃣ Первичная обработка запроса 2️⃣ Валидация запроса 3️⃣ Проверка безопасности 4️⃣ Аутентификация и авторизация 5️⃣ Ограничение частоты запросов (Rate Limiting) 6️⃣ Маршрутизация к нужному сервису 7️⃣ Преобразование протоколов 8️⃣ Агрегация ответов 9️⃣ Возврат ответа клиенту 🔟 Логирование, мониторинг, обработка ошибок и кэширование 🔗 Ссылка на полный гайд API Gateway — это централизованная точка входа, которая упрощает взаимодействие клиентов с микросервисами и обеспечивает безопасность и управляемость системы. #АрхитектураGA

⚡ Архитектура для Системных Аналитиков — старт 9 июня ⚡ Ты уже Middle+. Понимаешь процессы, умеешь работать с интеграциями и API. И где-то внутри уже знаешь: следующий шаг — это архитектура. И ждёшь момент, когда ты не просто слушаешь про архитектуру — а сам её предлагаешь. Когда коллеги смотрят на твою схему и говорят «да, вот так и делаем». Именно для этого перехода мы сделали продвинутую программу для системных аналитиков, которые хотят расти до уровня Senior и в Solutions Architect: ⚡ Проектирование архитектуры 🗓 Старт: 9 июня 2026 👉 Узнать подробности о программе Что будем делать: ✔️ Строить архитектуру с нуля — монолит, сервисная, микросервисная ✔️ Работать с нотацией C4 — так, чтобы твои схемы читали и понимали все ✔️ Подбирать и использовать API на практике: REST, GraphQL, WebSocket и другие ✔️ Ставить задачи на брокеры: Kafka, RabbitMQ, Webhooks и асинхронное взаимодействие После программы: ✅ Приходишь на архитектурный митинг и ведёшь его, а не просто участвуешь ✅ Обосновываешь повышение грейда конкретными навыками ✅ Проходишь технические собесы и сам выбираешь оффер ✅ Переходишь из проектной разработки в продукт с SOA или микросервисами ✅ Закрываешь пробелы, которые давно хотел закрыть 🎁 Предзапись открыта до 4 июня: скидка + мини-курс «Интеграции 4.0 — продвинутый уровень» в подарок. 🟢 Осталось 18 мест. 👉 Занять место со скидкой Вопросы? Пишите в Telegram @getanalyst, на почту info@getanalyst.ru или через сайт.