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

🟠 Открыли бесплатный доступ к 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 или через сайт.

🔝 ТОП-3 нотации для моделирования архитектуры 🔝 Когда система становится сложнее одного монолитного backend + одной БД, архитектуру уже не получается держать «просто в голове». Команде для работы нужно наглядно видеть: ▫️ из чего состоит система ▫️ как приложения и сервисы связаны между собой ▫️ где проходят границы ответственности ▫️ какие есть внешние системы ▫️ как бизнес-логика влияет на архитектуру Для этого и используют архитектурные нотации. 👉 Не ради красивой схемы в документации, а чтобы при проработке задач команда понимала: ✔️ какие приложения и сервисы участвуют в изменении ✔️ через какие API, брокеры и БД они взаимодействуют ✔️ где проходит граница ответственности каждого компонента ✔️ какие внутренние интеграции нужно учесть ✔️ что может сломаться при доработке одного сервиса Основные нотации моделирования архитектуры 👇 1️⃣ C4 Model Официальный сайт Практический видеоурок Схема сфокусирована на техническом устройстве системы. Одна из самых практичных нотаций для аналитиков и архитекторов. C4 помогает показать архитектуру на разных уровнях детализации: ▫️ Context — система, пользователи и внешние системы ▫️ Container — приложения, backend, frontend, БД, брокеры, API Gateway ▫️ Component — внутренние компоненты конкретного приложения, не обязательный уровень ▫️ Code — детализация до кода, используется редко Почему любят C4: она достаточно простая, наглядная и не перегружает схему лишней информацией. 👉 Если нужно показать карту IT-продукта: объяснить архитектуру микросервисов или интеграций, показать технологии — чаще берут именно C4. 2️⃣ ArchiMate Официальный сайт Хорошие статьи ArchiMate используют в крупных компаниях и enterprise-архитектуре. В мире разработки нотация до сих пор считается экзотической и встречается редко. Её сила — в том, что она связывает между собой: ▫️ бизнес-цели ▫️ бизнес-процессы ▫️ приложения ▫️ данные ▫️ технологии ▫️ инфраструктуру ▫️ проекты и изменения 👉 ArchiMate помогает показать не только «какие у нас сервисы», но и зачем они вообще нужны бизнесу. Минус — нотация сложнее чем C4, поэтому может быть слишком тяжёлой для внедрения и понимания. 3️⃣ UML Официальный сайт Полный гайд по UML-Sequence + бесплатный AI-бот от GetAnalyst UML — более классическая и формальная нотация. С архитектурой связаны: ▫️ Component Diagram — показывает компоненты системы и связи между ними ▫️ Deployment Diagram — показывает, где и как развёрнуты приложения, серверы, БД и инфраструктура ▫️ Sequence Diagram — показывает последовательность взаимодействий между системами, сервисами и API На практике UML реже используют как основную карту архитектуры микросервисов. Для этого чаще берут C4, потому что она проще читается командой. 👉 Чаще берут, чтобы показать сценарии интеграции в отдельных задачах через UML Sequence. Другие нотации: 4️⃣ 4+1 Architectural View Model 5️⃣ SysML (Systems Modeling Language) 6️⃣ AADL (Architecture Analysis & Design Language) используются редко. 📌 Краткий чек-лист: что выбрать? 👉 Если нужно быстро и понятно показать архитектуру системы — берите C4. 👉 Если проектируете огромную enterprise-систему с нуля и нужно связать бизнес, приложения и технологии — смотрите в сторону ArchiMate. 👉 Если нужно показать интеграционный сценарий — добавляйте UML. Главное: Архитектурная схема должна помогать не “украшать документацию”, а прорабатывать задачи, видеть зависимости и быстрее принимать технические решения. 🔗 Исходники примеров схем положила сюда. 🔗 ТОП-5 нотаций моделирования архитектуры #АрхитектураGA 📱 Tg | 💙 ВК | 💬 Max

50+ слайдов за 20 минут. Не спрашивайте, как 😅 Это тот редкий случай, когда меня надо будет смотреть не на x2, а на x0.75... Эта неделя получилась полной событий: ✔️ Отметили день рождения GetAnalyst - 5 лет ✔️ Провели практикум по распределенным БД ✔️ Провели практикум по внедрению ИИ в работу СА ✔️ Выпустили новый эпизод подкаста про нотацию C4 для моделирования архитектуры ✔️ У меня в компании два новых огромных проекта и мне надо разруливать 🫠 ✅ И главное — я выступила на Analyst Days 22 с докладом про AI-прототипирование UI/UX Хочу искренне поблагодарить организаторов @AnalystDays: за приглашение, за доверие и за то, что нашли для меня тайм-слот, в который я вообще могла выступить. Разница с Москвой 10 часов, поэтому конференция для меня была после полуночи 🙈 👉 Во время выступления почувствовала себя Тиной Канделаки: 50+ слайдов, включая видео, примеры, прототипы — и всё это за 20 минут. Да, я знаю, что говорила быстро 😂 Но очень не хотелось растягивать тему и забирать время у оффлайн спикеров. Сейчас вокруг искусственного интеллекта очень много повторяющегося пустого хайпа. Мне же хотелось быть полезной и показать конкретный кейс: как AI можно использовать в работе СА и БА не “для вау-эффекта”, а как нормальный рабочий инструмент. Без магии. Без воды. Без лишних обещаний. С конкретными сценариями и пользой. Надеюсь, что удалось 🙌 Отдельное спасибо Тамаре Ушуровой за помощь в подготовке доклада и за созвоны в максимально компромиссное для наших часовых поясов время. Огромное спасибо моим студентам и участникам сообщества GetAnalyst, которые были на конференции и скидывали мне фото ❤️‍🔥 И Софья Калинина, отдельное спасибо за видео! Благодаря вам я увидела, что на Analyst Days было много наших)) Кто не успел посмотреть доклад вживую — у участников конференции запись появится примерно через 1-2 недели. Вопросы можно писать под этим постом или просто в чате в любое время. Только включайте не на ускорении. Я там уже сама всё ускорила 😅

🔥 Нотация C4 за 90 минут: как проектировать архитектуру на примере реальной задачи 💙🩵 Нотация C4 — один из самых мощных инструментов для моделирования архитектуры, но большинство делают диаграммы интуитивно и допускают одни и те же ошибки. 👉 В этом выпуске разбираем C4 системно — от теории до живого проектирования. За 90 минут проходим все ключевые уровни C4 — Context, Container и Component — и разбираем два реальных проекта. По каждому забираете полный комплект схем C4/Context и C4/Container. 🔗 Статья с доп. материалами Выпуск актуален всем, кто проектирует архитектуру систем, готовится к техническому собеседованию, или хочет наконец разобраться с нотацией C4 и начать применять её в своих проектах. Видео с демо решения: ⏯ YouTube ⏯ RuTube ⏯ VK Video ⏯ Telegram Аудио: ⏯ Apple Podcast ⏯ Яндекс.Музыка ⏯ Castbox ⏯ Звук ⏯ Spotify 🌱 GetAnalyst — место силы для Системных Аналитиков 📱 Tg | 💙 ВК | 💬 Max