GetAnalyst - Навыки • Системный анализ • Бизнес-анализ – Telegram
GetAnalyst - Навыки • Системный анализ • Бизнес-анализ
19.5K subscribers
2.09K photos
74 videos
203 files
1.19K links
Разбор задач на проектирование систем 🚀 Канал для системных аналитиков, бизнес-аналитиков, тестировщиков и менеджеров проектов

Админ @getanalyst
Сайт https://getanalyst.ru
Чат t.me/getanalystchat
Начинающим в IT @getanalyststart

РКН №5013005196
Download Telegram
Чек-лист по работе с Интеграциями для СА и БА

Системный аналитик должен уметь рассказывать про свой процесс работы с задачами на интеграции: от момента получения требований до создания задач на разработку.

Хочу поделиться с вами пошаговым планом, описывающим этот процесс.

Пусть он станет вашим помощником при работе с задачами на интеграции и в подготовке к собеседованиям.


👉 Краткий чек-лист по работе с задачами на интеграции:

☑️ Получить вводные от заказчика
☑️ Выделить компоненты системы: внешние, внутренние
☑️ Найти API-документацию для каждого из внешних сервисов, а если необходимо, то и для внутренних
☑️ Нарисовать схему архитектуры — первое приближение
☑️ Описать процессы, которые нужно поддержать в системе
☑️ Найти по API-документации соответствующие процессам методы, добавить их в описание
☑️ Уточнить схему архитектуры (и далее постоянно актуализировать по ходу детального проектирования и постановок задач)
☑️ Получить доступы к API
☑️ Протестировать API своими силами или с помощью разработчиков
☑️ Сопоставить наборы данных, доработать/спроектировать БД нашей системы при необходимости, описать маппинг данных
☑️ Создать задачи в Jira и выстроить порядок разработки
☑️ Сделать детализацию постановок задач в Confluence на основе исследований, проведенных ранее


👉 Полный пошаговый план работы с задачами на интеграции в статье.

#ИнтеграцииGA
32🔥13❤‍🔥1
C4_Context_Архитектура_CityGA.png
243.5 KB
🏙 Архитектура в C4 для проекта #CityGA 🏙

С чего начинается понимание, как работает интеграция?

Один из первых шагов — показать схему архитектуры, чтобы увидеть:
✔️ какие компоненты есть (приложения, сервисы, БД и т.д.)
✔️ как они взаимодействуют друг с другом (API, через брокер и др), потоки данных,
✔️ что и куда сохраняется.

Без этого сложно понять, как на самом деле работает система "под капотом".

Поэтому показываю вам архитектуру CityGA, и сразу в нотации моделирования С4.


👉 Архитектура CityGA включает:

Frontend:
🔺 Мобильные и веб-приложения пользователей
🔺 Веб-приложение администратора

Backend:
▫️ Основной сервис (монолит) — вся основная бизнес-логика системы, интеграция с KudaGo
▫️ БД Основная — хранит все данные по системе.
▫️ Файловое хранилище — фото, документы
▫️ Брокер сообщений — очередь задач для фоновой обработки, пока только события о необходимости отправить уведомление (SMS/email/push).
▫️ Сервис уведомлений — отдельный компонент, чтобы асинхронно (фоново) рассылать уведомления пользователям, не задерживая работу алгоритмов и ответы пользователям. Интегрирован с Firebase и Dashamail
▫️ БД Уведомлений — хранит историю отправленных уведомлений, шаблоны.

Интеграции с внешними системами:
🔹 KudaGo
🔹 DashaMail
🔹 Firebase



🗺️ Архитектура в C4 для CityGA показана на двух уровнях:

L1. C4/Context — система и окружение (роли пользователей, внешние системы).

L2. C4/Container — приложения, сервисы, БД, брокеры, протоколы интеграции, технологии и протоколы.


👉 Для проработки интеграции и тех-сценариев нам критически важен именно уровень C4/Container: на нём видно, как именно приложения и сервисы взаимодействуют внутри системы.


Схема архитектуры — это отправная точка для описания интеграционного Use Case, на которой мы по сути видим потоки данных 🙌

Сохраняйте примеры схем архитектуры C4 в копилку, пригодится для работы на ваших проектах 😉


#ИнтеграцииGA
👍16🔥14❤‍🔥52
🧐 Анализ API-документации KudaGo: что нужно перед интеграцией 🧐

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

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

Разбираемся на примере #KudaGoAPI, как анализировать API-документацию.

Документация
Вводная страница

Вид API
Нигде явно не указан.
HTTPs-запросы.
Все GET - так как получение данных.
Все POST/GET = HTTP API.
Это можно назвать REST like API, так как по факту в публичной документации только запросы на получение данных и метод GET выбран верно.

Авторизация и аутентификация
Не требуется.
Этот раздел отсутствует.
Это публичный API без ограничений на использование.

Тестовые доступы
Не нужны, так как это публичный API на чтение и никаких данных для авторизации к API тоже нет.

Рекомендации по использованию API
Отсутствуют.
Получаем данные в любом порядке и используем на своё усмотрение.

Ограничения и особенности
Даже если на сервере KudaGo есть ограничение на количество запросов с одного ip-адреса, что очень даже вероятно, то его не указали в документации :)

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


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

Сначала продумываю интеграционные Use Cases, не зная деталей внешнего API. А потом подбираю нужные методы.

Для нашей задачи с #CityGA нужны будут методы, связанные с получением мероприятий и событий в городах:
Список городов - их id используются в остальных методах
Список событий
Список мест, куда сходить
Список показов для фильмов в кино

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

Это простая API-документация для анализа. И у нас ещё есть более интересная интеграция с системой email рассылок DashaMail, которую мы также проанализируем 🤝

#ИнтеграцииGA
🔥274👍4❤‍🔥1
🧶 Исследование API через Postman 🧶

Документация ≠ реальность.

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

Он заранее подстраховывает разработчиков, уточняя нюансы, которых нет в API-документации внешней системы.


Что важно проверить аналитику для интеграции:
Как работает аутентификация в API
Успешную работу всех API-методов
Протестировать ошибки (при авторизации, отсутствии данных и другие), чтобы понять, как внешняя система реагирует на нештатные ситуации


Делюсь с вами практическими руководствами по исследованию API внешних систем через Postman:

📹 Postman: навык тестирования REST API за вечер

📚 Практическое руководство по Postman - тестирование API DaData

📚 Практическое руководство по Postman - тестирование API Unisender

📚 Практическое руководство по Postman - тестирование API банка ВТБ

📚 Практическое руководство по Postman - тестирование API ChatGPT

👉 В этих руководствах всё четко, с картинками и по шагам.

С ними вы сможете освоить Postman за выходные, и сразу же пополните своё портфолио несколькими коллекциями запросов 🙌

В дополнение:
Попробуйте сами протестировать запрос на получение списка городов и получение списка событий в API KudaGo, чтобы закрепить полученный навык 😉

#ИнтеграцииGA
🔥48174❤‍🔥3👍1
Мы провели вместе почти год... ❤️‍🔥

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

Для меня это огромная ответственность, чтобы вести коллег в аналитике не по отдельному направлению, а вообще по всем. С нуля.

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

Это ваше время.
Это моё время.
И по итогам, как я вижу, всё не зря.

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


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

Мало просто купить курс — его надо изучить, тогда обязательно будет результат.


Ни добавить, ни убавить.

Спасибо, что выбираете GetAnalyst ❤️

#студентыGetAnalyst
23❤‍🔥6👍6
Гайд по Postman - KudaGo и DashaMail [GetAnalyst].pdf
16.3 MB
📙 Практический гайд по Postman - тестирование #KudaGoAPI и #DashaMailAPI 📙

Одним из первых и важнейших шагов при интеграции с внешней системой является исследовательское тестирование API. Например, через Postman.

Почему?
👉 Документация может быть устаревшей или неполной.
👉 В ней могут отсутствовать примеры или важные детали о полях.
👉 API может вести себя иначе, чем предполагается по описанию.
Аналитик начинает «угадывать», как оно работает, и ставит задачи разработке наобум.

В итоге — ошибки в логике, лишняя переписка с разработчиками, затянутое внедрение и разочарование от интеграции, которая
«не взлетела с первого раза»....

❗️ Именно поэтому исследовательское тестирование API — это не просто полезный навык, а необходимая часть работы аналитика при интеграции.

Чтобы погрузиться в процесс исследовательского тестирования API на практике для проекта #CityGA, подготовила для вас практический гайд по тестированию в Postman:
🔸 KudaGo API
🔸 DashaMail API

Внутри:
1. Погружение в Postman с нуля
2. Инструкция по получению API-ключа для DashaMail (ключ GetAnalyst, чтобы не проходить шаг запроса ключа у тех. поддержки - получить тут)
3. Пошаговая инструкция по тестированию KudaGo API
4. Пошаговая инструкция по тестированию DashaMail API

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

Сохраняйте в избранное и обязательно выполните эту практику до конца этой недели 🤝

#ИнтеграцииGA
19🔥5👍31❤‍🔥1
🧐 Анализ API-документации DashaMail: что нужно перед интеграцией 🧐

На прошлой неделе опубликовала результат анализа документации KudaGoAPI.

В этом посте разбираемся с #DashaMailAPI

Документация
Вводная страница

Вид API
Нигде явно не указан.
HTTPs-запросы.
Все POST или GET - любой вариант сработает
Все POST/GET = HTTP API.
Даже на запросы по созданию данных можно использовать GET. Поэтому API нельзя назвать REST like.

Авторизация и аутентификация
Стандартный способ аутентификации по API-key.
Ключ для авторизации из раздела «Аккаунт» - «Интеграции» (получать через UI).
Подставляется в query-параметры запроса (после ?).

Тестовые доступы
Нет.
Если необходимо тестировать API, то рекомендуется создать второй бесплатный тестовый аккаунт.

Рекомендации по использованию API
Отсутствуют.
Получаем и создаем данные в любом порядке, используем на своё усмотрение.

Ограничения и особенности
Ответ может быть в одном из нескольких форматов.
Для его задания используйте переменную format:
+ JSON (default)
+ JSONP
+ XML
Количество писем, которое может быть отправлено (или кол-во адресатов), ограничивается тарифами.


Общие требования к обработке ошибок
Ссылка на перечень внутренних кодов ошибок errors
Ответы на все запросы при этом HTTP-200 всегда, даже при ошибках.


Список методов для нашей задачи
Для рассылки уведомлений в #CityGA нужны будут методы:
Добавляем адресную базу
Добавляем подписчика в базу
Удаляем подписчика из базы
Создаем рассылку
В ходе исследовательского тестирования и описания интеграционных Use Case возможно потребуется больше методов.


Эта информация, которая получена в результате первичного анализа API-документации DashaMail, поможет далее в исследовательском тестировании API и в постановке интеграционных задач на разработчиков 📝

#ИнтеграцииGA
15👍5🔥2❤‍🔥1
🧩🎁 Открыта запись на Интеграции [до 25 сентября спец цены и БД+SQL в подарок] 🎁🧩

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

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


👉 В программе Интеграции систем
мы на практике разбираем все детали работы с задачами: от анализа API-документации до создания структуры требований и постановок задач на разработчиков.

🗓 Старт: 8 октября 2025
🔗Подробности и регистрация

Формат:
10 живых онлайн-встреч
Один проект в течение всей программы
Решение реальных задач
Обратная связь и индивидуальный подход

🎁 По заявкам до 25 сентября дополнительное обучение по БД+SQL в подарок + самые выгодные условия.


Вопросы?
Пишите @getanalyst или на почту info@getanalyst.ru
Поможем оценить текущие навыки, пришлем дополнительную информацию и ответим на вопросы 🤝
Please open Telegram to view this post
VIEW IN TELEGRAM
13❤‍🔥2
⭐️ Интеграционный Use Case: разбираемся на примере интеграции с #KudaGoAPI и #DashaMailAPI ⭐️

Интеграционный Use Case отличается от обычного тем, что он содержит технические детали:
+ вызовы API,
+ сохранение данных в БД,
+ обмен данными между микросервисами через брокеры,
+ и другие.

То есть всё то, что помогает понять, как "перетекают" данные в ходе работы системы.

Разбираемся подробнее на примере для #CityGA, где у нас UI в процессе работы вообще отсутствует 😱


📌 Use Case:
+ Автоматическая рассылка событий по расписанию

👉 Приложения и системы:
+ Backend CityGA
+ Kafka Broker

👉 Внешние системы:
+ KudaGo API
+ DashaMail API

👉 Предусловия:
+ Для каждого города задан часовой пояс
+ В CityGA сохранены предпочтения пользователей по категориям и выбран город
+ В DashaMail заранее созданы адресные списки под каждую группу категорий
+ В Kafka создан топики notifications.email.events для получения сообщений о необходимости запуска рассылки


👉 Основной сценарий:

1. Для каждого поддерживаемого города в системе еженедельно, по средам, в 10:00 его часового пояса, срабатывает планировщик задач в Backend.

2. Backend рассчитывает окно предстоящей недели - с чт по ср.
Пример:
Сегодня 17 сентября 2025 (ср).
Плановое окно для выбора новых мероприятий:
18.09.2025 00:00 → .24.09.2025 23:59:59 (GMT+3).
Для KudaGo это Unix-секунды:
actual_since=1758178800,
actual_until=1758783599.


3. Выполняется первичный запрос по событиям в выбранном городе на указанный период, без фильтра по категориям, в API KudaGo:
GET /public-api/v1.4/events

+
Получаем до 10 записей за один запрос от KudaGo
+ Использовать порядок сортировки favorites_count при получении данных от KudaGo
+
Исключать события «всегда доступно»/«без времени» - фильтрация на стороне CityGA

3.1. Сформировать сообщение в топик Kafka notifications.email.events для отправки рассылки, со списком из 10 полученных событий от KudaGo и с id листа подписчиков на город, у которых не настроены фильтры по категориям.


4. Далее повторять запрос по событиям в выбранном городе на указанный период, через API KudaGo, с фильтрами по категориям.
GET /public-api/v1.4/events

Например:
+ у одной группы пользователей в избранном только бизнес-события, выполнить запрос только с фильтром по этой категории на 10 записей;
+ у другой группы пользователей в избранном бизнес-события и детские мероприятия, выполнить запрос только с фильтром по этим двум категориям на 10 записей;
и т.д.

4.1. По каждому уникальному набору фильтров формировать сообщение в топик Kafka notifications.email.events для отправки рассылки, со списком из 10 полученных событий от KudaGo и с id листа подписчиков.

Повторять 4 и 4.1 для всех уникальных наборов категорий у пользователей в городе.

-------

5. Сервис Уведомлений последовательно читает сообщения из брокера Kafka.

5.1. После считывания очередного сообщения Сервис Уведомлений формирует HTML шаблон письма для рассылки.

5.2. Сервис Уведомлений вызывает API DashaMail для создания и отправки рассылки, передавая на вход созданный HTML-шаблон, id листа контактов из DashaMail и другие параметры (см. маппинг), метод:
campaigns.create


5.3. Сервис Уведомлений логирует вызов метода внешней системы.

-------


👉 Альтернативные сценарии и дополнительные детали
Всё будет, но не сейчас.
Оформим в Confluence 😎


Это первый подход к описанию логики работы системы.
Use Case ещё будет доработан.


📌 Вопросы,которые остаются после первого подхода к написанию интеграционного Use Case:
А. Есть ли у вас предложения по улучшению логики работы (алгоритма)?
Б. Должны ли мы что-то в процессе работы сохранить в БД?
В. Дейстительно ли метод campaigns.create сразу создает и отправляет рассылку? Нужны дополнительные действия?
Г. Можем ли мы фильтровать события «всегда доступно»/«без времени» на стороне KudaGo?
Д. Откуда мы получаем комбинации категорий?

Это то, что сейчас точно упущено в Use Case.

Рассуждайте, пробуйте отвечать на мои вопросы и задавайте свои в комментариях 🙌 Будем улучшать его вместе!


#ИнтеграцииGA
Please open Telegram to view this post
VIEW IN TELEGRAM
❤‍🔥17👍6🔥43
🔑 5 основных способов авторизации в API и их влияние на интеграции 🔑

При проектировании интеграций, системному аналитику важно заранее продумать сценарий авторизации запросов во внешнюю систему.

Почему?

1. Без авторизации вызовы API просто не пройдут — интеграция «упадёт» уже на первом шаге.

2. Разные механизмы требуют разной логики работы и обработки ошибок.

3. Чёткое понимание процесса авторизации упрощает тестирование и облегчает отладку сценариев интеграции.



📌 Основные способы авторизации
API Key
Basic Auth
Bearer Token
JWT Token
OAuth 2.0
Mutual TLS (по сертификатам)



📌 Как оформлять в требованиях?

При работе с задачей на интеграцию, аналитик пишет требования к интеграционным API-методам или Backend-процессам для своей системы, в логике которых встроены вызовы внешних API.

👉 Не дублируйте требования к авторизации в одном и том же внешнем API в каждом Use Case, который его использует.

Вместо того, чтобы в каждом интеграционном Use Case описывать требования к авторизации во внешней системе и обработку её ошибок, достаточно вынести общие требования к авторизации в отдельную статью (+задачу) и затем ссылаться на неё.

При описании отдельных API-методов или Backend-процессов лучше фокусироваться только на специфике их работы.



📌 Обработка ошибок


Важно предусмотреть и описать требования к обработке ошибок аутентификации и авторизации в процессе работы интеграции:

401 Unauthorized — неверные или отсутствующие учётные данные. Возможна повторная фоновая аутентификация.

403 Forbidden — недостаточно прав для выполнения операции, хотя аутентификация (учётные данные) может быть верной.

419 Token Expired — срок действия токена истёк, требуется рефреш или повторная фоновая аутентификация.

429 Too Many Requests — превышен лимит запросов (для API Key/токена OAuth, учетной записи).



📌 Логирование
Логируйте и мониторьте случаи ошибок авторизации.
Если попытки повторной фоновой авторизации не приводят к успеху, то есть высокий риск, что интеграция "упала".



#ИнтеграцииGA
16👌10👍8❤‍🔥3