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

前往频道在 Telegram

Разбор задач на проектирование систем 🚀 Канал для системных аналитиков, бизнес-аналитиков, тестировщиков и менеджеров проектов Админ @getanalyst Сайт https://getanalyst.ru Чат t.me/getanalystchat Начинающим в IT @getanalyststart

显示更多

俄罗斯30 996 技术与应用6 243...

📈 Telegram 频道 GetAnalyst - Навыки • Системный анализ • Бизнес-анализ 的分析概览

频道 GetAnalyst - Навыки • Системный анализ • Бизнес-анализ (@getanalysts) 俄语语言赛道中的是活跃参与者。目前社区聚集了 21 797 名订阅者，在 技术与应用 类别中位列第 6 243，并在 俄罗斯 地区排名第 30 996 位。

📊 受众指标与增长动态

自 невідомо 创建以来，项目保持高速增长，吸引了 21 797 名订阅者。

根据 09 六月, 2026 的最新数据，频道保持稳定运转。过去 30 天订阅人数变化为 394，过去 24 小时变化为 14，整体触达仍然可观。

认证状态： 未认证
互动率 (ER)： 平均受众互动率为 14.51%。内容发布后 24 小时内通常能获得 7.81% 的反应，占订阅者总量。
帖子覆盖： 每篇帖子平均可获得 3 160 次浏览，首日通常累积 1 702 次浏览。
互动与反馈： 受众积极参与，单帖平均反应数为 43。
主题关注点： 内容集中在 api, брокер, архитектура, oauth, микросервисов 等核心主题上。

📝 描述与内容策略

作者将该频道定位为表达主观观点的平台：
“Разбор задач на проектирование систем 🚀 Канал для системных аналитиков, бизнес-аналитиков, тестировщиков и менеджеров проектов Админ @getanalyst Сайт https://getanalyst.ru Чат t.me/getanalystchat Начинающим в IT @getanalyststart”

凭借高频更新（最新数据采集于 10 六月, 2026），频道始终保持新鲜度与高覆盖。分析显示受众积极互动，使其成为 技术与应用 类别中的关键影响点。

21 797

订阅者

+1424 小时

+777 天

+39430 天

3 160

帖子浏览量

~ 1 70224 小时

~ 1 96048 小时

14.51%

参与率

~ 2

每日帖子数

Ads index

beta

数据加载中...

吸引订阅者

六月 '26

+135

在1个频道中

五月 '26

+540

在5个频道中

Get PRO

四月 '26

+551

在3个频道中

Get PRO

三月 '26

+477

在5个频道中

Get PRO

二月 '26

+526

在3个频道中

Get PRO

一月 '26

+675

在4个频道中

Get PRO

十二月 '25

+481

在5个频道中

Get PRO

十一月 '25

+512

在5个频道中

Get PRO

十月 '25

+545

在4个频道中

Get PRO

九月 '25

+597

在5个频道中

Get PRO

八月 '25

+840

在4个频道中

Get PRO

七月 '25

+520

在3个频道中

Get PRO

六月 '25

+441

在4个频道中

Get PRO

五月 '25

+541

在5个频道中

Get PRO

四月 '25

+596

在4个频道中

Get PRO

三月 '25

+666

在5个频道中

Get PRO

二月 '25

+724

在5个频道中

Get PRO

一月 '25

+678

在3个频道中

Get PRO

十二月 '24

+639

在4个频道中

Get PRO

十一月 '24

+632

在2个频道中

Get PRO

十月 '24

+714

在2个频道中

Get PRO

九月 '24

+726

在3个频道中

Get PRO

八月 '24

+743

在3个频道中

Get PRO

七月 '24

+741

在2个频道中

Get PRO

六月 '24

+699

在2个频道中

Get PRO

五月 '24

+773

在3个频道中

Get PRO

四月 '24

+852

在2个频道中

Get PRO

三月 '24

+654

在2个频道中

Get PRO

二月 '24

+605

在2个频道中

Get PRO

一月 '24

+589

在1个频道中

Get PRO

十二月 '23

+514

在0个频道中

Get PRO

十一月 '23

+565

在1个频道中

Get PRO

十月 '23

+476

在1个频道中

Get PRO

九月 '23

+532

在0个频道中

Get PRO

八月 '23

+399

在0个频道中

Get PRO

七月 '23

+419

在0个频道中

Get PRO

六月 '23

+341

在0个频道中

Get PRO

五月 '23

+230

在0个频道中

Get PRO

四月 '23

+182

在0个频道中

Get PRO

三月 '23

+212

在0个频道中

Get PRO

二月 '23

+69

在0个频道中

Get PRO

一月 '23

+75

在0个频道中

Get PRO

十二月 '22

+152

在0个频道中

Get PRO

十一月 '22

+216

在0个频道中

Get PRO

十月 '22

+140

在0个频道中

Get PRO

九月 '22

+72

在0个频道中

Get PRO

八月 '22

+158

在0个频道中

Get PRO

七月 '22

+116

在0个频道中

Get PRO

六月 '22

+167

在0个频道中

Get PRO

五月 '22

+299

在0个频道中

Get PRO

四月 '22

+652

在0个频道中

日期	订阅者增长	提及	频道
10 六月	+16
09 六月	+17
08 六月	+10
07 六月	+14
06 六月	+6
05 六月	+13
04 六月	+12
03 六月	+21
02 六月	+11
01 六月	+15

频道帖子

🟡 Оптимизация БД. Работа с индексами [15 июня, 19:00 Мск] 🟡 В требованиях это выглядит просто: ▫️ добавить поиск ▫️ сделать фильтр по статусу ▫️ отсортировать по дате ▫️ собрать отчёт за период А потом внезапно оказывается, что запрос на “просто список” ходит в БД слишком долго, API долго отвечает, а задача превращается в разговор про оптимизацию. И вот здесь аналитику важно понимать хотя бы базовую логику индексов, чтобы не описывать поиск, фильтры и отчёты в отрыве от того, как они будут работать на реальных данных в больших системах. На следующей неделе на практике разберём: 1️⃣ как нефункциональные требования связаны с БД 2️⃣ что такое индексы и зачем они нужны 3️⃣ знакомство с БД проекта и определение таблиц с индексами 4️⃣ почему избыточная оптимизация может навредить 5️⃣ как учитывать индексы в постановке задачи на разработку 🟡 Оптимизация БД. Работа с индексами 🗓 15 июня, 19:00 Мск (пн) ✅ Онлайн-практика ➕ Видеоуроки для подготовки 👉 Узнать подробнее и записаться (от 1 490 руб) До встречи онлайн! Вопросы? Пишите @getanalyst 🤝

2	❌ API Gateway = точка отказа? ❌ Отличный вопрос, который могут задать на собеседовании. Ответ: Да — если он не масштабирован горизонтально. Если на сервере развернут единственный инстанс (установленная копия) API Gateway и он выйдет из строя, работа всех клиентов, которые в него обращаются, остановится. Пользователи не смогут достучаться до микросервисов, даже если сами микросервисы продолжают работать. ❌ Что будет, если API Gateway «упадёт»? 1. Внешние клиенты потеряют доступ к сервисам. 2. Внутренние вызовы (если они идут через Gateway) тоже могут быть нарушены. 3. В логах вы увидите HTTP 502 / 503 ошибки (Bad Gateway / Service Unavailable). 4. Мониторинг начнёт фиксировать обрыв соединения и рост ошибок. Это будет сложно не заметить 🥲 👉 Как это решается? Чтобы API Gateway не стал "узким горлышком", применяют следующие решения: 🟢 Горизонтальное масштабирование Несколько инстансов API Gateway, развернутых за балансировщиком нагрузки. Тогда при сбое одного — остальные продолжают обслуживать запросы. 🟢 Health-check и авто-рестарт Kubernetes и другие оркестраторы позволяют перезапускать поды/контейнеры при сбое. 🟢 Failover-механизмы Некоторые решения "из коробки" поддерживают автоматическое переключение между инстансами при сбоях. 🟢 Разделение входящего трафика В больших системах могут использовать несколько API Gateway по зонам или типам трафика (например, публичный API и внутренний API) Несмотря на сбой API Gateway, внутренние сервисы продолжают жить, поэтому, если они не делают обратные вызовы в API Gateway для обращения в другие сервисы, то все начатые цепочки транзакций (запросов) будут выполнены. Т.е. данные не теряются, процессы продолжаются. API Gateway - потенциальная точка отказа в системе? 👉 Да Но при нормальной инфраструктуре не должен быть ею. Мы разбираем это на программе по архитектуре. Это часть про стык Инфраструктуры и Архитектуры, который важно осознавать аналитикам. #АрхитектураGA 📱 Tg \| 💙 ВК \| 💬 Max	1 641
3	🤩 Оркестрация и API Gateway – разбор реального примера 🤩 Разбираемся, как в реальной жизни работают оркестрация и API Gateway на примере системы для парковок #ParkingGA. Для этого погружаемся в детали 👉 процесса завершения парковки, когда после распознавания гос. номера автомобиля на выезде с парковки нужно: ✔️ проверить наличие авто в черном списке, ✔️ рассчитать стоимость парковки, ✔️ проверить, есть ли абонемент для оплаты, ✔️ списать средства с электронного кошелька, ✔️ сформировать чек, ✔️ отправить уведомления. 👉 Этот сложный процесс выполняется на разных микросервисах. В его работе могут происходить ошибки и исключительные ситуации, и главное, нельзя прервать процесс в середине без последствий. Поэтому для его обслуживания прекрасно подходит стратегия с Оркестрацией. ⚖️ Когда нужен оркестратор? ✅ Бизнес-процесс охватывает много микросервисов и нужна централизованная координация их взаимодействия (иначе эта логика разрозненно реализуется в нескольких сервисах). ✅ Процесс сложный или длительный, требующий надёжности (сохранение состояния, повторы, откаты по шаблону Saga). ❌ Задача проста и укладывается в прямые вызовы пары сервисов (либо реализуется внутри одного микросервиса). ❌ Вы используете хореографию событий (event-driven architect, брокеры), где микросервисы обрабатывают события. Оркестратор упрощает управление сложными процессами, но применять его стоит только когда действительно необходим. В простых случаях лишний слой добавит сложности. И, конечно, на схеме есть API Gateway, который при приёме запроса от клиента: 🔹 проверяет авторизацию запроса, 🔹 понимает, куда перенаправить обработку запроса в зависимости от API-метода: напрямую в микросервис или в оркестратор, если это сложный процесс. 👉 Изучайте схему архитектуры, прикрепленную к посту, и описанный по шагам алгоритм к ней. 📚 Связанные материалы: API Gateway Оркестрация Сохраняйте в избранное ♥️ Можете использовать этот пример, если вас попросят рассказать про оркестрацию на собеседовании 🤝 #АрхитектураGA 📱 Tg \| 💙 ВК \| 💬 Max	1 879
4	+1 🔔 Сегодня закрываем доступ к практикуму по микросервисной архитектуре 🔔 Если в проектах вы уже слышите Kafka, RabbitMQ, события, оркестрация, но пока не всегда понимаете, как это превращается в требования и архитектурные схемы, то этот урок стоит посмотреть сегодня. 🧡 Хореография и оркестрация микросервисов 🕘 За ~4 часа разберёте, как проектировать процессы в микросервисной архитектуре и показывать взаимодействие сервисов на схемах. 👉 Что внутри: 1️⃣ Монолит и микросервисы 2️⃣ Разработка схемы архитектуры 3️⃣ Оркестрация: практика 4️⃣ RabbitMQ и Kafka 5️⃣ Хореография: практика Практикум особенно полезен, если вы уже выросли из простых задач и хотите увереннее разбирать процессы, где участвуют несколько сервисов, брокер и внешние системы. 🔗 Забрать бесплатный доступ* *Если уже регистрировались — письмо с доступом на почте. Если письмо не нашли, можно зарегистрироваться повторно. 👉 Это полноформатный вводный урок к программе Проектирование архитектуры для СА. Бесплатный урок даёт вводную практику и глубокое понимание отдельной темы. А на основной программе будем собирать архитектурное мышление системно: от схем до решений, которые можно защищать перед командой. 🚀 Узнать о курсе по Архитектуре для СА Вопросы? Пишите @getanalyst 🤝 —- P.S. За обратную связь огромнейшая признательность, очень ценю 💖	2 100
5	+7 Ирина пришла к нам, когда уже меняла работу. То есть не в моменте “когда-нибудь потом пригодится”, а когда новые знания нужны прямо сейчас. А дальше всё сложилось идеально: 👉 новый проект, Kafka, микросервисы, много систем и взаимодействий. В такой ситуации архитектура перестаёт быть абстрактной темой “для общего развития”. Она становится способом быстрее понять новую систему: какие сервисы за что отвечают, потоки данных, связи, почему изменение в одном месте может внезапно "стрельнуть" в другом. 👉 Особенно ценно видеть, как человек в момент смены работы берёт задачи сложнее, и постепенно чувствует себя увереннее на новом уровне. Ирина, спасибо за доверие и удачи на новом месте! 💜 #студентыGetAnalyst 📱 Tg \| 💙 ВК \| 💬 Max	2 156
6	🎷 Оркестрация микросервисов: от схемы к требованиям 🎷 Оркестрация – это подход, при котором специальный сервис-оркестратор выступает «дирижёром» для группы микросервисов (МС). 👉 Оркестратор централизованно управляет сложным бизнес-процессом: 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	1 967
7	⚡ Все говорят про 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	2 204
8	🟠 Открыли бесплатный доступ к 4-часовой практике по архитектуре 🟣 Не мини-урок на 20 минут и не “послушать про микросервисы в целом”. Разбираем то, где у аналитиков обычно начинается путаница: когда один процесс проходит через несколько сервисов, брокер сообщений, события и внешние системы. Что важно понять: ▫️ кто управляет процессом ▫️ где нужен прямой API-вызов ▫️ где лучше использовать RabbitMQ или Kafka ▫️ как распределить ответственность между сервисами ▫️ чем хореография отличается от оркестрации на практике ▫️ как показать это на архитектурной схеме 🧡 Хореография и оркестрация микросервисов 📅 Только до 9 июня (вт) 🕘 4 часа практики 👉 План: 1. Основы архитектуры систем: монолит и микросервисы 2. Разработка схемы архитектуры для проекта 3. Оркестрация процессов: практика 4. Введение в брокеры сообщений (RabbitMQ, Kafka) 5. Хореография процессов: практика 🔗 Забрать бесплатный доступ* *Если уже регистрировались — письмо с доступом на почте. Если письмо не нашли, можно зарегистрироваться повторно. Продуктивной практики! 🧡	2 439
9	🔖 База знаний по брокерам для СА: теория + практика + примеры 📚 Делимся с вами подборкой статей, постов и подкастов, которые помогут разобраться с темой: 📌 Брокеры и очереди — общая теория 📚 Очередь сообщений - что это и как работает? 📝 Всё про брокеры: как работают и зачем нужны 📝 Очередь 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	2 787
10	+9 🐇 Брокер RabbitMQ - полный гайд 🐇 1. Что такое RabbitMQ и зачем он нужен 2. Как работает RabbitMQ 3. Очереди, обменники (exchange), routing и binding key - ключевая терминология и внутреннее устройство брокера 4. Типы обменников: direct, fanout, topic, headers 5. Пошаговый разбор: пример использования RabbitMQ в микросервисной архитектуре Подробно разбирали брокер в подкасте: 🎧 RabbitMQ и его отличия от Kafka: что важно знать системным аналитикам Сохраняйте в избранное, пригодится и в работе, и перед собеседованиями 🔖 #АрхитектураGA	3 135
11	Когда в проекте появляются брокеры, микросервисы и десятки интеграций между ними, «просто описать требования» уже недостаточно. Нужно понимать как проектировать архитектуру. Именно это разбираем на практической программе: 💎 Проектирование архитектуры 🗓 Старт — 9 июня Программа для Middle+ аналитиков, которые хотят выйти на уровень Senior / Solutions Architect. ▫️ Монолит, SOA, микросервисы ▫️ C4 для понятных архитектурных схем ▫️ НФТ для проекта ▫️ REST, GraphQL, gRPC, WebSocket ▫️ Kafka и RabbitMQ для асинхронных интеграций 🎁 Предзапись завершается сегодня: скидка + мини-курс «Интеграции 4.0» в подарок ➕ Бесплатный вводный практикум "Хореография и оркестрация микросервисов" с 6 по 9 июня Если думали, решайте сегодня. 👉 Занять место со скидкой Вопросы: @getanalyst	2 825
12	⭐️ Архитектура 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	2 570
13	⭐️ 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	2 548
14	🧡 [6–9 июня] Хореография и оркестрация микросервисов: открытый практикум для аналитиков 🧡 В простых задачах всё понятно: Frontend → Backend → БД. Но в распределённой архитектуре один процесс может затрагивать сразу несколько сервисов, брокер сообщений и внешние системы. И аналитику нужно решить: ▫️ кто запускает процесс ▫️ какой сервис отвечает за каждый шаг ▫️ где использовать прямой API-вызов ▫️ где передавать события через Kafka или RabbitMQ ▫️ когда нужна оркестрация, а когда — хореография ▫️ как всё это показать на архитектурной схеме 👉 Этому и посвящён новый практикум по хореографии и оркестрации микросервисов. На занятии вы разберёте: ✔️ как устроены процессы в микросервисной архитектуре; ✔️ как проектировать оркестрацию и хореографию; ✔️ какую роль играют RabbitMQ и Kafka; ✔️ как отображать взаимодействия сервисов на схемах. Подойдёт системным аналитикам, которые уже работают с интеграциями и проектированием систем и хотят глубже разобраться в микросервисной архитектуре, событийном взаимодействии и построении сложных процессов. 🧡 Хореография и оркестрация микросервисов: практика проектирования процессов 📅 Доступ 6 - 9 июня 🕘 Время на обучение: ~4 часа 🎯 Формат: урок в записи, можно пройти в удобное время 🔗 Зарегистрироваться Это полноформатный вводный урок к практической программе «Проектирование архитектуры» для системных аналитиков, которая стартует 9 июня. Если к активному осеннему найму хотите увереннее работать с архитектурой, проектировать сложные процессы и претендовать на более сильные позиции — присоединяйтесь 🙌 Вопросы? Пишите @getanalyst или на info@getanalyst.ru.	2 616
15	🚦 Всё про брокеры: как работают и зачем нужны 🚥 Брокеры — это посредники в передаче сообщений между системами или сервисами. Они позволяют асинхронно обмениваться данными и обеспечивают гарантию доставки сообщений. 👉 Принцип работы: ▫️ Сервис 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	3 463
16	🎻 Всё про оркестрацию: как работает и зачем нужна 🎻 Оркестрация — это паттерн управления взаимодействием сервисов, при котором один центральный компонент (оркестратор) координирует все вызовы и определяет порядок действий. 👉 Принцип работы: 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	2 667
17	Обучение в Johns Hopkins University было ошибкой 🤡 Я пошла туда с мыслью: «Ну всё, сейчас разберусь, как работает AI, и хотя бы на год закрою вопросы с новым обучением». А в итоге AI уже тихо переставляет мебель в моих карьерных планах 😄 В апреле я закончила программу Applied Generative AI в Johns Hopkins University. И не успела нормально выдохнуть после одного семестра, как взяла на следующий Agentic AI. Потому что я уже зашла слишком далеко, чтобы просто остановиться. Не зря же я начала программировать 🙈 Сейчас я активно использую Claude Code, настраиваю AI-агентов, собираю приложения и экспериментирую на своих задачах. И периодически чувствую себя человеком, который открыл слишком много дверей одновременно. Инструментов много. Возможностей ещё больше. 👉 А в голове местами красивый, но всё-таки хаос. Хочу его структурировать. Мне важно понять, как лучше проектировать AI-агентов, как встраивать их в архитектуру больших систем, где они реально полезны и что из этого можно применять в работе аналитика. А остаться именно в Johns Hopkins решила потому, что мне очень близко, как там дают AI: глубоко, наглядно и через практику. Собственно, именно так я сама стараюсь строить обучение в GetAnalyst. Всё самое полезное, как обычно, принесу аналитикам в GetAnalyst ❤️‍🔥 Так что пока отдыхаю, насколько получится. А с июля снова учёба 🤓 И да, это уже не просто интерес к AI, а новые карьерные планы.	2 996
18	❌🤖 Перестаньте использовать ИИ как простой чат-бот: настройте проекты под свои задачи 🤖🚀 Многие работают с нейросетями так: «Сделай мне диаграмму» «Напиши 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	3 442
19	💎 Хореография и оркестрация микросервисов: практика [6–9 июня] 💎 Микросервисная архитектура — это не только про то, чтобы разделить систему на отдельные сервисы. Главное начинается дальше: нужно спроектировать, как эти сервисы будут взаимодействовать в реальных бизнес-процессах. Аналитику важно понимать, кто за что отвечает, как передаются данные, где нужны события, а где лучше использовать прямые вызовы или оркестрацию. На новом практическом занятии разберём, как проектировать такие процессы и показывать их на архитектурных схемах. 💎 Хореография и оркестрация микросервисов: практика проектирования процессов 📅 Доступ 6 - 9 июня (сб-вт) 🕘 Время на обучение: ~4 часа 🎯 Формат: урок в записи, можно смотреть в удобное время 🔗 Зарегистрироваться 👉 План: 1. Основы архитектуры систем: монолит и микросервисы 2. Разработка схемы архитектуры 3. Оркестрация процессов: практика 4. Введение в брокеры (RabbitMQ, Kafka) 5. Хореография процессов: практика 👉 Практикум полезен, если вы: ✔️ уже работаете с API и интеграциями, но хотите глубже понимать микросервисную архитектуру ✔️ готовитесь к интервью на Middle+/Senior системного аналитика; ✔️ часто слышите на проектах “Kafka”, “RabbitMQ”, “события”,“микросервисы”, но хотите разложить это в понятную систему ✔️ стремитесь работать с более сложными архитектурными задачами, а не только с экранами, CRUD и простыми API. Есть планы разбираться в интеграциях микросервисов? Регистрируйтесь и смотрите практикум в удобное время с 6 по 9 июня 👍	3 464
20	😰 Уволить или обучать? 😰 Жёсткий, но очень честный вопрос для любого руководителя. Отвечаю. Проблема не всегда в том, что человек «чего-то не знает». Есть вещи, которые обучением почти не лечатся. ✅ Ошибся, признал и пришёл с вариантом исправления. Или обсудить, как такое не допустить в будущем? Обучать. Потому что ошибка — это не катастрофа. Катастрофа — это когда человек защищает ошибку до последнего, перекладывает ответственность на разработчиков, тестировщиков, заказчика, ретроградный Меркурий и «непонятный контекст». ✅ Медленный, но внимательный и с горящими глазами? Обучать. Скорость приходит с практикой. Особенно, если человек умеет задавать вопросы, принимает обратную связь и не боится сложных задач. ✅ Мало знает, но хочет расти? Обучать. Навыки наращиваются: API, интеграции, БД, микросервисы. Главное, чтобы человек не делал вид, что уже всё знает. 🚩 Ноет, что всё плохо? Уволить. Если человек видит риски и аргументирует — это ценно. Если человек просто разрушает энергию команды и заражает всех ощущением «ничего не получится» — это проблема. 👉 Системный аналитик должен видеть проблемы. Но зрелый аналитик приносит не только проблему, а ещё и варианты решения. 🚩 Сдал задачу в разработку = снял ответственность. Уволить. Потому что аналитик — это не человек, который «написал документ и ушёл». Он связывает бизнес, разработку, тестирование, поддержку. Если он не помогает команде переводить с бизнесового на разработческий — он не выполняет ключевую часть своей роли. 🚩 Даёт результаты, но токсичен в общении? Уволить. Можно быть сильным специалистом, но если после каждого созвона команда выгорает, разработчики боятся задавать вопросы, а тестировщики получают ответы в стиле «ну это же очевидно» — это разрушает рабочую среду. Высокий уровень экспертизы не даёт права быть токсичным. 🚩 Оспаривает каждое решение? Уволить. Если аналитик спорит аргументированно, защищает качество системы и помогает найти слабые места — это плюс. Если спорит ради спора, чтобы показать свою ценность, саботирует договорённости и не может принять командное решение — это уже не критическое мышление, а управленческая проблема. 🚩 Умный, но не разделяет миссию продукта или компании. Уволить. Потому что аналитик влияет на решения. Он участвует в формировании требований, архитектурных обсуждениях, приоритизации, коммуникации с бизнесом. Если человек внутренне не верит в то, что команда строит, он будет постоянно тормозить движение. Иногда не специально. Просто потому что у него другая картина мира. Я более 7 лет руковожу проектами на 1млн+ пользователей. Я более 3 лет веду свой бизнес с командой на 20+ человек. Я не хочу быть вовлеченной в задачи своих сотрудников, сидеть как «курица наседка» и следить за каждым. 👉 Уволить или заменить? Мой вывод такой: Обучать стоит тех, у кого не хватает навыков, но есть ответственность, честность, интерес и желание расти. А расставаться стоит с теми, кто разрушает команду: токсичностью, вечным негативом, отсутствием ответственности или саботажем общего направления. Потому что сильная команда строится не только на hard skills. Иногда один человек с хорошими навыками, но плохим отношением к людям наносит системе больше ущерба, чем джун, который пока путает POST и GET, но хочет разобраться 🙌	3 340

查看所有帖子