🔖 База знаний по брокерам для СА: теория + практика + примеры 📚

Делимся с вами подборкой статей, постов и подкастов, которые помогут разобраться с темой:

📌 Брокеры и очереди — общая теория
📚 Очередь сообщений - что это и как работает?
📝 Всё про брокеры: как работают и зачем нужны
📝 Очередь vs Брокер: вопросы с подвохом
📝 Хореография и оркестрация в микросервисной архитектуре
📝 7 вопросов с подвохом по Архитектуре: хореография + понимание брокеров в EDA

📌 Kafka
📙 Официальная документация
📝 8 шагов, чтобы разобраться с 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

🟠 Открыли бесплатный доступ к 4-часовой практике по архитектуре 🟣

Не мини-урок на 20 минут и не “послушать про микросервисы в целом”.

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

Что важно понять:
▫️ кто управляет процессом
▫️ где нужен прямой API-вызов
▫️ где лучше использовать RabbitMQ или Kafka
▫️ как распределить ответственность между сервисами
▫️ чем хореография отличается от оркестрации на практике
▫️ как показать это на архитектурной схеме


🧡 Хореография и оркестрация микросервисов
📅 Только до 9 июня (вт)
🕘 4 часа практики

👉 План:
1. Основы архитектуры систем: монолит и микросервисы
2. Разработка схемы архитектуры для проекта
3. Оркестрация процессов: практика
4. Введение в брокеры сообщений (RabbitMQ, Kafka)
5. Хореография процессов: практика

🔗 Забрать бесплатный доступ*

*Если уже регистрировались — письмо с доступом на почте. Если письмо не нашли, можно зарегистрироваться повторно.


Продуктивной практики! 🧡

⚡ Все говорят про 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

🎷 Оркестрация микросервисов: от схемы к требованиям 🎷

Оркестрация – это подход, при котором специальный сервис-оркестратор выступает «дирижёром» для группы микросервисов (МС).

👉 Оркестратор централизованно управляет сложным бизнес-процессом:
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