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

А тут точно надо AI? Показательная история из университета 🤓

Мне кажется, моя учёба по AI в Johns Hopkins University продолжается бесконечно 😅

И она делает меня счастливее, потому что ощущение “как много я не знала” - лучшее!
Но и без "поумничать" у меня судя по всему никуда.


На последнем занятии мы разбирали готовое решение AI чат-бота для интернет-магазина на Python.
Учебное демо - ок… но я-то думаю про реальность.

И поэтому снова начала перестраивать архитектуру решения и рассуждать с преподавателем по поводу изменения кода на 80% 😃

Почему?
👉 Потому что многие путают внедрение AI и обычную автоматизацию, и пытаются засунуть LLM туда, где достаточно нормально запрограммировать.



📌 Рассказываю к чему докопалась:
1. Есть AI чат-бот для Интернет-магазина.
2. Пользователь пишет:
«Где мой заказ? И когда его доставят?»
3. LLM (большая языковая модель = AI) понимает: вопрос индивидуальный → просит номер заказа.
4. Пользователь присылает номер.


И дальше варианты 👇

1️⃣ Заранее, до начала диалога, загрузить в LLM всю базу заказов (через файл) и искать там

Это было в учебном примере.
Ок, так можно.
Но зачем в LLM вообще вгрузили базу заказов?
Всех-всех пользователей. Там и персональные данные, и чеки, и всё в этом файле.
Ещё и через большой JSON-файл, который явно при каждом новом диалоге (или хотя бы раз в час), надо обновлять.
Зачем вообще заставлять LLM парсить этот JSON?

При таком раскладе ещё и сложные промпты надо писать, чтобы LLM ни в коем случае не выдала данные по чужому заказу и не раскрыла чужие перс данные.

Если уж что-то и подгружать, то только заказы авторизованного пользователя в начале диалога.
Но нет, в учебном примере грузили вообще всё 🥲

2️⃣ Пусть LLM через MCP полезет в базу и достанет данные

Уже лучше.
Есть недавно созданный MCP-протокол, используя который можно подключиться к вашей БД PostgreSQL и забирать из неё нужные данные напрямую.
Это уже лучше, чем работа с JSON-файлом со всеми заказами.
Одна проблема появляется.
Надо защищаться, чтобы у нас не украли БД, обманув LLM через вредоносный промпт (команду к AI).
Про MCP делала небольшое демо тут.

3️⃣ Мы принимаем номер заказа от пользователя и далее вызываем обычный метод системы, который возвращает статус и дату доставки

Как по мне - это лучший вариант.
Простая и привычная автоматизация, которая решает все проблемы защиты перс данных и потенциальных атак, которые могут сделать для LLM.
Тут:
+ и запросы к AI экономим (да-да, запросы по API платные, если не своя LLM, а, например, DeepSeek или OpenAI)
+ и кучу промптов на защиту от кражи перс данных придумывать не надо
+ LLM - про понимание пользователя, вызов метода из кода - про понятное получение данных из БД


Итого 👇
В задаче на AI-чат-бота для интернет-магазина LLM нужна не как “доступ к базе”, а как умный диспетчер:
• распознать команду от пользователя “получить статус доставки” или иную
• запросить у пользователя номер заказа
• аккуратно вызвать нужный метод
• красиво сформулировать ответ пользователю
Остальное - отдайте программистам на автоматизацию.

А “парсить огромный JSON” и писать кучу защитных промптов - это норм как учебный пример, но не как продакшн.


Такая вот история 😃
Надеюсь удалось донести вам чуть больше "подводных камней" про системы с AI.


А вообще я уже много месяцев с урывками выходных и в абсолютном завале со своей учёбой.
Но узнавать и пробовать новое,особенно в AI - 🤍🤍🤍


#AI_for_analysts

⏯ ЭПИЗОД 39:
Всё про WebSocket: что это, где используют и зачем он в архитектуре

WebSocket встречается всё чаще. И понимать его хотя бы на базовом уровне становится важно.

Там, где есть чаты, одновременная работа пользователей и любые обновления в реальном времени, WebSocket API появляется очень быстро 💬

Подробно рассказываем про WebSocket в новом выпуске подкаста GetAnalyst:

🔗 Сайт эпизода с шаблоном задачи на WebSocket API


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

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


Сообщество системных аналитиков GetAnalyst — опыт здесь 📍

🔗 Протокол HTTP и его связь с REST API 🔗

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

👉 Структура метода HTTP API
(без архитектурного стиля REST)

Запрос:
+ тип метода (GET/POST/PUT/PATCH/DELETE)
+ URL (https://api.test.com/public/v1/products?name=Яблоко&limit=10)
+ заголовки - headers
+ тело запроса (json/xml/html/файл и другие)

Ответ:
+ статус код (HTTP-200 и другие)
+ заголовки - headers
+ тело ответа (json/xml/html/файл и другие)

REST API — это архитектурный стиль, использующий HTTP в качестве протокола передачи данных (или: основанный на протоколе HTTP).

👉 Структура метода REST API = Структуре метода HTTP API
Только REST API методы используют дополнительные рекомендации по тому, как их делать.


Например:
▫️ в REST API используется полный набор методов GET/POST/PUT/PATCH/DELETE, а в HTTP API могут быть все POST 🥲
▫️ в REST API рекомендуется использовать JSON-формат сообщений, а в HTTP API можно делать что угодно.


Всё самое важное про HTTP на картинках к посту ☝️

🔗 Ещё подробнее про связь HTTP и REST API в этой статье.


#RestApiGA

🔑 "Войти через Госуслуги / Google / Mail ru": пример постановки задачи на OAuth 2.0 интеграцию 🔖

Сегодня одна из самых популярных задач — подключить единый аккаунт для входа во все приложения: “через Госуслуги”, “через Google” и т.д.

Я показываю подход на примере Mail.ru OAuth 2.0, потому что:
✔️ документация на русском (в отличие от Google),
✔️ можно быстро создать тестовое приложение и прогнать сценарий в Postman руками (в отличие от Госуслуг),
✔️ на нём удобно разобрать нюансы, которые потом повторяются и для других провайдеров.


Я подготовила:
👉 шаблон постановки задачи: “Первичная регистрация аккаунта через ‘Войти c Mail.ru’”.
Это интеграционный Use Case.


На что важно обратить внимание:

◽️ 1) Токен Mail.ru — не “токен вашей системы”
В этом сценарии access_token Mail.ru нужен только, чтобы один раз получить базовые данные профиля и создать пользователя.
Дальше пользователь должен работать на внутренней авторизации FoodDeliveryGA (в примере — Bearer Token на 30 дней).
Внутренняя авторизация может быть тоже OAuth 2.0, а может отличаться, как в примере, и быть более простой.


◽️ 2) Есть внешние методы OAuth и внутренние методы вашей авторизации
В постановке чётко разделены:
+ внешние вызовы (Mail.ru OAuth + REST API),
+ внутренние API FoodDeliveryGA (/auth/mailru/authorize, /auth/mailru/token).


◽️ 3) Flow “через code”, а не “токен сразу на фронт”
Показан безопасный вариант OAuth 2.0:
Frontend получает code, а токены внешнего провайдера получает уже Backend.
Это стандарт для продуктовых решений.

◽️ 4) Декомпозиция задачи важна
В примере только Use Case авторизации, а по факту нужно делать:
+ первичную регистрацию
+ привязку акканта Mail.ru к существующей учетке
+ вход в аккаунт (очередная авторизация)
+ проверка доступа хотя бы раз в 24 часа (что токен не отозвали и не сменили)
+ деавторизация.


📌 Шаблон можно использовать как основу для постановок задач для “Войти через Google / Госуслуги” — меняется провайдер и детали API, но структура постановки задачи остаётся такой же.


Документ точно пригодитя 🔖🤝
Сохраните — это шаблон, который закрывает 80% типовых вопросов по OAuth.


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

✅ 42 API-термина, которые спрашивают СА на собеседовании: чек-лист ✅

👉 Ключевые:
1. API (Application Programming Interface)
2. REST API (Representational State Transfer)
3. HTTP-методы запросов
4. Эндпоинты
5. Коды ответов
6. Ограничение частоты запросов (Rate Limiting)
7. Полезная нагрузка (Payload)
8. Заголовки (Headers)
9. Аутентификация
10. Авторизация
11. Пагинация
12. Кэширование


👉 Дополнительно:
1. OAuth
2. JWT Token
3. API Gateway
4. API Keys
5. Basic Authentication
6. Bearer Tokens
7. CORS
8. Webhooks
9. OpenAPI
10. API Versioning (Версионирование API)
11. Content Negotiation
12. Query Parameters
13. Path Parameters
14. API Documentation
15. API Monitoring
16. Throttling
17. Circuit Breaker
18. Idempotency (Идемпотентность)
19. API Proxy
20. Retry Logic (Логика ретраев / повторов)
21. Batch Processing (Пакетная обработка)
22. API Security
23. Health Checks
24. API Testing
25. Mock APIs
26. API Marketplace
27. API Schema
28. Semantic Versioning (Семантическое версионирование)
29. Hypermedia
30. API Deprecation (Устаревание API)


Всё самое важное и нужное в одном месте 😎

#RestApiGA

📚 Практическое руководство по исследованию OAuth 2.0 в Mail ru 📚


Как разобраться с OAuth 2.0?
Только на реальной практике 💻

Пройдите один из ключевых Flow для OAuth 2.0 через Postman, на примере интеграции с OAuth 2.0 сервером от Mail ru.

Интеграция с сервером OAuth 2.0 от Mail ru нужна, чтобы сделать кнопки в приложении:
+ "Войти через аккаунт Mail ru"
+ "Зарегистрироваться через аккаунт Mail ru".


👉 Результат работы по руководству:
1. Поймёте полную последовательность шагов OAuth 2.0 (Grant Type = Authorization Code)
2. Разберётесь, чем отличаются access token и refresh token
3. Поймёте, где и как токены использовать при вызове API
4. Чётко увидите, когда токен получать, как долго хранить и когда обновлять


🔖 Сохраняйте руководство и повторяйте шаги в Postman — это самый быстрый способ реально разобраться с OAuth.


Больше по OAuth 2.0:
#FoodDeliveryGA_oauth
#ИнтеграцииGA

🎯 Чек-лист навыков Системного Аналитика: полная и актуальная версия 2026 🎯

В начале года я собрала полный список навыков, которые чаще всего ждут от системного аналитика в 2026 — от требований и БД до интеграций, API и архитектуры.

Посты:
🔗 Часть 1
🔗 Часть 2
🔗 Часть 3 - инструменты


А теперь - самое полезное 👇
Я собрала всё это в одну статью и добавила:
▫️ маркировку навыков по уровням (junior / middle / senior)
▫️ формулу, как оценить свой грейд

🔗 Ссылка на статью


Чтобы было удобно собрать личный план развития, мы сделали PDF-чек-лист.
Можно скачать, распечатать и отмечать прогресс — или просто сделать скрины и отмечать прямо на них.
📄 [PDF прикреплён к посту]


👉 Рекомендации:
1. Пройдите по чек-листу и отметьте свои навыки.
2. Выберите по 2-3 навыка на каждый месяц 2026 года к освоению.
3. Через год перепроверьте себя: что нового выучили.


Сохраняйте в избранное и оценивайте свой грейд — это та штука, к которой реально полезно возвращаться весь год 🚀


Подписывайтесь на @getanalysts, чтобы быть в курсе самых актуальных новостей для БА и СА 🚀

💥 Задачи с собеседования по SQL для аналитиков 💥


Сегодня в 19:00 Мск проведём продвинутую практику по БД+SQL, где разберём задачи уровня Middle+ / Senior, которые встречаются и в работе, и на собеседованиях.

💥 SQL-запросы с JOIN на реальной БД через DBeaver
🔗 Подробности и запись
Стоимость участия от 1 650 рублей

✅ Запись будет доступна в платформе
🎁 Бонус: занятие в записи "Маппинг данных: БД и JSON"



А пока — задача для самопроверки 👇
По ней сразу видно, насколько уверенно вы чувствуете себя в SQL (JOIN-ах):
👍 решите быстро - вы в форме,
🧐 зависнете - значит на практике будет максимум пользы.


Задача:

В системе Интернет-магазина есть таблицы:
▫️ user (id, firstname, lastname, phone)
▫️ order (id, number, user_id, created_at)
▫️ product (id, name, price)
▫️ order_product (order_id, product_id, amount, sale_price)

Нужно написать SQL-запрос, который вернёт список заказов, где:
▫️ более 5 продуктов,
▫️ общая стоимость более 5 000 рублей.

В результате вывести:
+ номер заказа,
+ количество товаров,
+ имя пользователя-покупателя,
+ телефон покупателя,
+ полную стоимость заказа.

Ответ 🔽
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

SELECT
    o.number AS order_number,
    SUM(op.amount) AS items_count,
    CONCAT(u.firstname, ' ', u.lastname) AS customer_name,
    u.phone AS customer_phone,
    SUM(op.amount * COALESCE(op.sale_price, p.price)) AS total_price
FROM "order" o
JOIN "user" u
  ON u.id = o.user_id
JOIN order_product op
  ON op.order_id = o.id
JOIN product p
  ON p.id = op.product_id
GROUP BY
    o.id, o.number, u.firstname, u.lastname, u.phone
HAVING
    SUM(op.amount) > 5
    AND SUM(op.amount * COALESCE(op.sale_price, p.price)) > 5000
ORDER BY total_price DESC;

Какие ещё интересные задачи по SQL недавно встречали на собесах?
Делитесь в комментариях ✍️


#БД_и_SQL_GA

🟢🟠 Инструменты системного аналитика для работы с API 🟡🟣

API — это не только для разработчиков. Аналитику оно нужно, чтобы проверять как работает наш Backend или внешняя система, и не тащить ошибки в разработку.


👉 Для работы с интеграциями:
Задача аналитика — проверить, что документация совпадает с реальностью (или собрать её, если документации нет):
+ какие endpoint’ы есть
+ какие параметры обязательны
+ какие статусы/ошибки возвращаются
+ какие поля приходят в JSON-ответе


👉 Работа с Backend и мобильными командами:
Нужно уметь самому проектировать и документировать API с нуля, чтобы ставить задачи на разработчиков.
Желательно с использованием специализированных инструментов как Postman и Swagger, а не только в Confluence-подобных системах.


Инструменты, которые помогают системным аналитикам в тестировании и документировании API:

🟠 Postman
🟡 SoapUI
🟣 Insomnia
🟢 Swagger

Подробности по каждому инструменту в картинках к посту ☝️


👉 Практика

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

🟠 Postman: Практическое руководство с примером тестирования открытого API
🟠 GraphQL — знакомство на практике через Postman [пошаговая инструкция]
🟠 Postman: навык тестирования REST API за вечер
🟢 Swagger - практичкское руководство по разработке документации в OpenAPI + пример

Пробуйте инструменты и пополняйте свой опыт работы 🤝


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