👩‍🏫🚀 Как выбрать ментора системному аналитику: 5 практических советов 👨‍🏫🚀

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

В такие моменты появляется запрос на ментора — опытного специалиста, который помогает структурировать цели, ответить на вопросы, дать практику, выстроить шаги в развитии, снизить тревогу и двигаться вперёд заметно быстрее.

В этом эпизоде разбираем кто такой ментор, когда он действительно нужен, как проходит работа с ним и чего от неё можно (и нельзя) ожидать. Говорим о том, как выбрать «своего» человека, не слить время и деньги и в итоге получать от менторства конкретный результат, а не просто галочку «я сходил к ментору».

🔗 Сайт эпизода


Эпизод доступен в:

⏯ Apple Podcast
⏯ Яндекс.Музыка
⏯ Telegram
⏯ Castbox
⏯ Звук
⏯ Spotify
⏯ RuTube
⏯ YouTube
⏯ VK Video


Сообщество GetAnalyst — место, где системные аналитики растут быстрее 🚀

🎯 Интеграции - ключ к пониманию того, как система работает “под капотом” 🎯

Когда я только начинала работать системным аналитиком, мои постановки задач сводились к описанию экранов: что нажали → что увидели.
И это было ОК 😃

А потом пришёл “умный и важный” Backend-разработчик и сказал примерно так:

Теперь мы делаем не монолит, где UI + логика + БД в одной кодовой базе.
Теперь у нас Frontend и Backend, которые общаются по API

И вот тогда я впервые узнала интеграции на минимальном уровне:
➡️ Frontend → Backend

Но настоящий “аттракцион” начался позже, когда появилась задача получать данные из внешней системы 👀
➡️ наш Frontend → наш Backend → внешняя система

➡️ а потом интеграции микросервисов

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

С годами интеграций становилось больше: разные API, протоколы, асинхрон, оборудование. И этот тип задач в итоге стал моим самым любимым🙌

Сейчас я рада делиться своим опытом в интеграциях с вами!



Уже на следующей неделе мы откроем предобучение на практической программе:

👉 Интеграции систем для СА и БА

🗓 Модули в записи: с 24 декабря 2025
🟢 Первый онлайн: 21 января 2026

🔗 Узнать подробнее и записаться


Результат:
✔️ Описываете интеграционные Use Cases
✔️ Уверенно работаете с API: REST, SOAP, GraphQL, gRPC, WebSocket
✔️ Опыт работы с Postman
✔️ Знаете нотацию C4 для архитектуры
✔️ Понимате асинхрон, в т.ч. брокеры
✔️ Можете сделать задачу на интеграционный REST API метод
✔️ У вас десятки примеров документации, которые можно переиспользовать в работе

Это то, что сейчас спрашивают Middle+ системных аналитиков на собеседованиях, и то, что реально нужно в работе.


Приглашаем вас начать новый 2026 год с навыка, который даёт уверенность в системном анализе и рост в карьере 🎄


Вопросы? Пишите @getanalyst или на info@getanalyst.ru. Поможем оценить текущие навыки и разобраться, подойдёт ли вам программа 🤝

📚 Чек-лист: типовые требования к обработке ошибок в Интеграциях 📚

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

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

Также не хочется получать разочарования на этапе тестирования, когда довольный тестировщик нашел очередной баг, что ведет к “уточнениям по аналитике”, очередным кругам доработок, задержкам релизов и отвлечению от новых задач.

😄👉 Я абсолютно уверена, что работа аналитика - победить тестировщика,
то есть первым найти все потенциальные ошибки и сбои, которые может создать пользователь. Поэтому круто, когда в Системный Анализ переходят Тестировщики.

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

1. Аутентификация
2. Доступ
3. Тайм-аут
4. Ошибки по документации внешней системы
5. Неизвестные ошибки, которых не было в документации и не планировалось их обрабатывать (новые коды, неизвестные форматы тела ответа)
6. Новые статусы или значения справочников, которые не совпадают с нашими перекодировочными таблицами, описанными в маппинге данных

Подробности в мини-книге к посту 📚

#ИнтеграцииGA

📖🔖 Всё про OAuth 2.0 с примером за 3 минуты 📖


👉 OAuth 2.0 — это стандарт, который позволяет вашему приложению получить ограниченный доступ к данным пользователя во внешнем сервисе без передачи пароля


👉 Ключевая идея на примере FoodDeliveryGA

✅ пользователь логинится в приложении FoodDeliveryGA и подтверждает доступ к его личным данным на стороне внешнего сервиса (Mail.ru) - через его безопасную web-форму

✅ FoodDeliveryGA получает токены доступа и работает дальше через API

❌ пароль пользователя от Mail.ru приложению FoodDeliveryGA никогда не передают


👉 Роли в OAuth 2.0
на примере FoodDeliveryGA

▫️Resource Owner (Владелец ресурса) — пользователь
Человек, который хочет войти в приложение FoodDeliveryGA и даёт согласие на доступ к его данным в Mail.ru для этого приложения

▫️Client (Клиент) — приложение FoodDeliveryGA
Frontend + Backend (в зависимости от схемы), которое инициирует авторизацию

▫️Authorization Server (Сервер авторизации) — Mail.ru
На предоставляемой им web-форме пользователь вводит логин/пароль Mail.ru и подтверждает доступ к данным

▫️Resource Server (Сервер ресурсов) — API Mail.ru
Методы REST API, где лежат данные пользователя (например, профайл / user info, информация о друзьях, посты на стене в социальной сети Мой Мир и другие данные).
Эти методы мы вызываем с использованием токена, который получили после аутентификации пользователя

💡 Часто Authorization Server и Resource Server находятся “в одном провайдере” (как Mail.ru), но логически это разные роли и с точки зрения Mail.ru это разные сервисы (сервера)


👉 Алгоритм работы OAuth 2.0 по шагам на картинке
для Grant Type=authorization_code


👉 OAuth 2.0 Grant Types - алгоритмы
authorization_code
refresh_token
client_credentials
implicit
password
device_code


👉 Ключевые параметры OAuth 2.0
для API-методов (в URL и JSON)

response_type
client_id
client_secret
redirect_uri

scope
state

refresh_token
access_token
token_type
expires_in

Зависят от Grant Type


Продолжение в следующих постах #FoodDeliveryGA_oauth 🚀

#ИнтеграцииGA

🧩 22 декабря | Маппинг данных: БД и JSON 🧩

Если вы хоть раз описывали интеграцию или требования к REST API-методу, то возможно вам знакомо:
- в БД одно, в JSON другое, а на UI третье,
- «а почему поле так называется»,
- «а откуда берём значение»,
- «а что если null»,
- «а как это маппить в требованиях».


Чтобы закрыть эти вопросы раз и навсегда и уверенно чувствовать себя в связке JSON ↔ БД, приглашаю вас на онлайн-практикум 👇

🧩 Маппинг данных: БД и JSON
🗓 22 декабря, 19:00 Мск

👉 Записаться на практикум
Стоимость участия от 1390 рублей


✅ Запись будет опубликована в платформе на следующий день после занятия
🎁 Занятие в записи по использованию AI для проектирования БД + SQL


План:
1. Знакомство с JSON
2. Практика формирования JSON для API методов на основе БД и дизайна UI
3. Описание маппингов данных
4. Автоматизация задачи с использованием AI-инструментов


В результате практикума вы:
✔️ Поймёте, как связать UI → JSON → БД в одну логичную схему
✔️ Заберёте себе понятный подход, как оформлять маппинг в требованиях
✔️ Получите практический опыт, который можно сразу применять в работе


По вопросам можно написать @getanalyst или info@getanalyst.ru.


До встречи онлайн! 🤩

🔑 Ключевые параметры OAuth 2.0 🔑

Прежде чем разбирать OAuth 2.0 flows (grant types) - алгоритмы, давайте познакомимся с его ключевыми параметрами.


📌 Шаги в OAuth 2.0

👉 Запрос на авторизацию - получение code

GET .../oauth/authorize
?response_type=code
&client_id=...
&redirect_uri=...
&scope=...
&state=...

👉 Callback на ваш redirect_uri - получен code

GET https:// testapp .com/api/v1/auth/oauth/provider/callback
?code=/...
&state=...

👉 Обмен code на токены

POST .../oauth/token

grant_type=authorization_code&
code=...&
client_id=...&
client_secret=...&
redirect_uri=...

📌 Параметры:

1️⃣ response_type
Тип результата, который вы хотите получить на шаге авторизации - регулирует ответ на GET /authorize

Где используется:
В URL для GET /authorize


2️⃣ client_id
Публичный идентификатор приложения, который предоставляет провайдер OAuth 2.0 (Mail ru /Google и др) после его регистрации у себя.

Где используется:
+ в URL для GET /authorize
+ в теле POST /token
+ иногда в запросах на обновление токена или в других grant types


3️⃣ client_secret
Cекрет (пароль) вашего приложения, который предоставляет провайдер OAuth 2.0 после регистрации

Где используется:
чаще всего в POST /token


4️⃣ redirect_uri
Это URL, куда провайдер OAuth 2.0 возвращает пользователя после аутентификации

Пример:
Пользователь вводит логин и пароль от своего Google-аккаунта на безопасной форме от Google. После этого Google делает переход на redirect_uri

Кто формирует:
Владелец приложения, который будет использовать OAuth 2.0.
Он указывает его в настройках при регистрации.

Где используется:
+ в URL для GET /authorize
+ в теле POST /token


5️⃣ scope
Список прав/доступов, которые вы запрашиваете у пользователя.

Пример:
Ваше приложение запрашивает у пользователя доступ к его Google-аккаунту:
+ ФИО
+ почта
+ Google-диск, чтение
и др.

scope=profile,email,drive:read

Кто формирует:
Владелец приложения

Где используется:
В URL для GET /authorize

На что влияет:
+ какие данные/действия разрешены для access_token
+ что пользователь увидит в окне согласия на безопасной форме от провайдера OAuth


6️⃣ state
Случайная строка для защиты от подмены (CSRF атаки) и для связывания “запрос-ответ”

Кто формирует/проверяет:
Backend приложения, который использует OAuth 2.0

Где используется:
+ отправляется в URL для GET /authorize
+ возвращается провайдером в redirect_uri вместе с code или error

Backend генерирует state, сохраняет (в сессии/БД/кэше), потом сравнивает с ответами от OAuth 2.0 провайдера

Если state не совпал — считаем запрос из процесса авторизации атакой/ошибкой и прерываем его


7️⃣ code (authorization code)
Временный одноразовый код, который провайдер возвращает после успешного входа пользователя.

Он нужен, чтобы безопасно обменять его на токены (access/refresh) через POST /token

Где появляется:
В URL на вашем redirect_uri (callback) после логина.

🕘 Есть срок жизни:
Обычно короткий (минуты/часы)


8️⃣ access_token
Токен доступа к API провайдера (Resource Server).

Где появляется:
В ответе на POST /token.

Как используется:
В дальнейших запросах к API провайдера (Resource Server).

Пример:
Подписываем запрос на получение файлов с Google-диска пользователя с access_token.

🕘 Есть срок жизни:
Обычно короткий (минуты/часы)


9️⃣ refresh_token
Это “токен обновления”.

По нему можно получить новый access_token без повторного запроса логина+пароля у пользователя.

Где появляется:
В ответе на POST /token.
Но не всегда выдаётся провайдером и не всегда нужен.

Как используется:
в запросе POST /token с grant_type=refresh_token.

🕘 Есть срок жизни:
либо нет, либо длинный (месяцы/год)


🔟 token_type
Тип токена.
Чаще всего Bearer.

Где появляется:
В ответе на POST /token


1️⃣1️⃣ expires_in
Срок жизни access_token в секундах.

Где появляется:
в ответе POST /token

Как используется:
+ ваше приложение рассчитывает момент истечения: expiresAt = now + expires_in
+ когда время подходит, то приложение обновляет access_token через refresh_token (фоново) или заново ведёт пользователя на авторизацию

#ИнтеграцииGA
#FoodDeliveryGA_oauth