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

✅ 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)


Всё самое важное и нужное 🔖

#hardGetAnalyst

💻 Когда Системный Аналитик работает с REST API 💻

Глядя в вакансиях Системных Аналитиков на ключевые слова "REST API", полезно понимать, что может за этим скрываться.

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


👉 1. При создании новой функциональности
У вас в команде Frontend + Backend разрабатываются отдельно - разные кодовые базы.
Frontend / Мобильные приложения взаимодействуют с Backend по REST API.

Когда в системе нужно добавить новую функциональность, то от аналитика ожидают, что он может:

+ со стороны Backend - проектировать REST API:
▫️ Определить REST API методы, которые нужно разработать для работы Frontend.
▫️ Описать алгоритмы их работы, которые будут программировать разработчики.
▫️ Продумать требования к обработке ошибок.
▫️ Сделать ролевую модель доступов к REST API методам.
▫️ Спроектировать структуру API-методов:
+ на естественном языке описать входные параметры запроса и параметры ответа на запрос.
+ продумывать техническую реализацию и описывать сразу тип метода (GET, POST, ...), endpoint (URL), query-параметры, headers запроса и ответа, тело JSON запроса и ответа, статус-код ответа.
▫️ Описывать маппинги (сопоставление) данных между БД и параметрами API-методов (в URL, JSON).
▫️ Формировать техническую API-документацию, которую в дальнейшем будут использовать разработчики: в Postman, Confluence или Swagger (OpenAPI).

+ со стороны Frontend - подключение разработанного на Backend REST API метода:
▫️ Читать техническую REST API-документацию.
▫️ Проверять работу готовых REST API методов через Postman, чтобы убедиться, что все работает так, как описано в документации.
▫️ Описывать маппинги (сопоставление) данных между UI и параметрами API-методов (в URL, JSON).


👉 2. Интеграции внешние - подключение сторонних систем по REST API
Состав подзадач аналогичен подключению API на Frontend.
Отличия:
1. Работа ведется не с внутренней API-документацией, а с чужой - на внешние системы.
2. Интеграции - это обычно про взаимодействие Backend-ов. Алгоритм работы может включать одновременно несколько компонентов: наш Frontend, наш Backend (+БД), внешний Backend.
3. Всвязи с этим больше таблиц маппингов данных в постановках задач:
✔️ Маппинг 1: UI + наш REST API,
✔️ Маппинг 2: наш REST API + внешний REST API + наша БД.


👉2.1. Интеграции - создание интеграционных REST API-методов (дополнительно к п. 2)
Нужно сделать REST API-метод на Backend, который будет вызывать любой API внешней системы (хоть REST, хоть SOAP, хоть GraphQL).
Состав подзадач аналогичен проектированию API-методов на Backend.

Маппиг данных теперь будет не только для БД и параметрами нашего API-метода (в URL, JSON). К нему добавятся еще и параметры внешней системы, которые могут быть в любом формате в зависимости от вида API.


👉 3. Интеграции внутренние - обмен данными между сервисами и микросервисами по REST API
Состав подзадач аналогичен подключению API на Frontend, но больше компонентов в описании алгоритмов и таблиц маппингов.


👉 4. Для анализа ошибок работы ПО
Что-то пошло не так при работе Frontend (или мобильного приложения)?
Открываем консоль.
Анализируем запросы и ответы REST API методов.
Тестируем сложные ситуации через Postman, смотрим на результаты и ищем причины ошибок.



Рекомендация:
Для Системного аналитика важно понимать REST API не только с точки зрения возможностей, но и с точки зрения ограничений, типовых проблем и ошибок в проектировании.
Чем лучше вы их понимаете, тем качественнее будет работать ПО разработанное по вашим требованиям.


#hardGetAnalyst

Каждая новая задача — шанс стать немного опытнее, чем вчера.

Хорошего начала рабочей недели 🚀

✍️ 3 вида параметров HTTP, где чаще всего ошибаются аналитики ✍️

Гайд по параметрам HTTP (REST API) запросов, в которых чаще всего путаются новички:


👉 query — после ? в URL.
Используются для:
+ фильтров,
+ сортировки,
+ пагинации (limit+offset),
+ api-key (если так принято).

GET /users?name=Иван&limit=10&offset=20&order=name,asc

Получить список пользователей с именем "Иван", 10 записей, начиная с 20-ой, сортировать по алфавиту А -> Я.

Типичные проблемы:
• Отправляют бизнес-данные для создания/изменения в query, вместо использования тела json.
• Добавляют query в POST/PUT без причины.



👉 path — часть пути (эндпоинта).
Идентификатор конкретного ресурса.

GET /users/{userId} 
→ GET /users/12345

Можно внутри пути, когда иерархия:

PATCH /users/{userId}/archive

Типичные проблемы:
• Отправляют ?userId=… в query, хотя это выбор сущности по id, а не фильтр.



👉 body — тело запроса json.
Сообщение, когда создаём/меняем данные.
Только для POST | PUT | PATCH.
Кроме json могут быть другие форматы.

{
 "name": "Петр",
  "lastname": "Иванов",
  "bio": "Любитель системного анализа"
}

Типичные проблемы:
• Отправляют огромное количество параметров в query, которые там не помещаются, и могут быть обрезаны сервером при определенных настройках безопасности.
• Используют body(json) для GET или DELETE, где оно не поддержано.



В гайде:
✔️ название параметра и его определение
✔️ скрины из Postman
✔️ особенности
✔️ примеры


Изучайте, запоминайте и не путайтесь 🤝

#hardGetAnalyst

☀️ Летняя неделя знаний от GetAnalyst: скидка 25% на все материалы для самостоятельного обучения ☀️

Если вы всерьёз решили расти в системном анализе — начните с практики 😉

📌 До 24 июля — скидка 25%
на все материалы для самостоятельного обучения:
✔️ разборы задач с проектов
✔️ структурные подходы к анализу требований
✔️ чек-листы, инструменты, шаблоны
✔️ подготовка к собеседованиям и разбор рабочих задач

🎁 Промокод: LETO2026

👉 Выбрать материалы со скидкой

Темы:
▫️ Интеграции
▫️ REST API
▫️ Архитектура
▫️ БД и SQL, ER-диаграммы
▫️ Резюме и собеседования
▫️ Анализ требований
▫️ AI


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

Формат для тех, кто предпочитает учиться самостоятельно 🙌


Вопросы? Пишите @getanalyst или info@getanalyst.ru 📩

🤔 Разница в HTTP, REST и RESTful API 🤔

Вопросы “Что такое REST API?” или “Что такое RESTful API?” в разных вариациях и формулировках задают на технических собеседованиях системных аналитиков 👀

Чтобы уверенно отвечать на них и глубоко понимать значение REST API, необходимо знать этот набор определений:


1️⃣ API — это программный интерфейс для обмена данными между приложениями:

• мобильное приложение ↔️ сервер
• сайт ↔️ сервер
• один backend-сервис ↔️ другой backend-сервис
• внутренняя система ↔️ внешняя система

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


2️⃣ HTTP — это один из основных протоколов обмена данными в Интернете.

Он определяет, как клиент и сервер обмениваются сообщениями:
• клиент отправляет запрос
• сервер обрабатывает его
• сервер возвращает ответ

HTTP включает:
• методы: GET, POST, PUT, PATCH, DELETE и другие
• статус-коды: 200 OK, 201 Created, 400 Bad Request, 404 Not Found, 500 Internal Server Error и другие
• заголовки
• тело запроса и ответа

Важно: HTTP сам по себе ещё не делает API REST API.

Можно сделать HTTP API, где все методы будут через POST, с глаголами в URL и без нормальной ресурсной модели.

Например:

POST /createUser
POST /getUserInfo
POST /deleteUser

Это будет HTTP API, но не REST API.


3️⃣ REST (Representational State Transfer) — это архитектурный стиль для проектирования сетевых API.

Проще говоря, REST задаёт подход:
как правильно организовать взаимодействие клиента и сервера через ресурсы.

В REST данные представляются как ресурсы.

Например:

/users
/users/{userId}
/orders
/orders/{orderId}

С этими ресурсами выполняются действия через HTTP-методы:

GET /users/{userId}
POST /users
PUT /users/{userId}
PATCH /users/{userId}
DELETE /users/{userId}

То есть мы не пишем действие в URL, а используем связку:

HTTP-метод + ресурс

Если этот принцип не соблюдается, то это чаще просто HTTP API, а не REST API.


4️⃣ REST API — архитектурный стиль проектирования программных интерфейсов.

Такой API:
• работает с ресурсами
• использует HTTP-методы по смыслу
• адресует ресурсы через URL
• возвращает данные в удобном для клиента формате, чаще всего JSON
• использует HTTP-статусы для описания результата операции

Пример:

GET /api/v1/products
GET /api/v1/products/{productId}
POST /api/v1/products
PATCH /api/v1/products/{productId}
DELETE /api/v1/products/{productId}

5️⃣ RESTful API — это термин, который подчеркивает строгое следование принципам REST.

То есть, когда мы говорим, что API является "RESTful", мы хотим сказать, что он полностью соответствует архитектурным стилям и ограничениям, определенным в REST.

Это подразумевает, что API не только использует HTTP-методы и работает через URL, но и строго следует всем рекомендациям и лучшим практикам REST.



👉 По сути
HTTP — это протокол передачи данных.
REST — архитектурный стиль.
REST API — API, сделанный по принципам REST.
RESTful API — API, который подчёркнуто следует REST-подходу.

👉 В повседневной разработке эти различия зачастую стираются, и термины используются как синонимы.


Но на собеседовании лучше показать, что вы понимаете разницу:
🔹 не любой HTTP API является REST API,
🔹 но REST API обычно использует HTTP.

Желаю вам успешных технических собеседований 😉


#hardGetAnalyst

🐇💥 Почему падает RabbitMQ: реальный кейс, который должен знать системный аналитик 💥🐇

Что происходит, когда очередь сообщений выглядит пустой, а нода RabbitMQ уже задыхается от гигабайт данных?

Разбираем реальную аварию: как массовые рассылки персонализированных писем превратили RabbitMQ в тяжелое хранилище объектов, для которого он архитектурно не предназначен. Узнаете, как не надо использовать DMX.

🔗 Презентация к эпизоду

Выпуск актуален для системных аналитиков и архитекторов, которые проектируют интеграции через брокеры и готовятся к собеседованиям.


Видео с презентацией:
⏯ YouTube
⏯ RuTube
⏯ VK Video


Аудио:
⏯ Apple Podcast
⏯ Яндекс.Музыка
⏯ Telegram
⏯ Castbox
⏯ Звук
⏯ Spotify


📚 GetAnalyst — техническая база знаний системного аналитика


📱 Tg | 💙 ВК | 💬 Max

⚠️🤖 Аналитиков сокращают и заменяют AI-агентами? Что за этим стоит.

Вижу всё больше разговоров про AI-агентов.
Что они уже умеют.
Что скоро “заменят аналитиков”.
Что требования, схемы, user story и документацию теперь можно просто “попросить сделать у ИИ”.

Важно:

👉 Нет, реальность не выглядит как “аналитики больше не нужны”.
Но и делать вид, что ничего не меняется, уже нельзя.



Сейчас компании быстрее внедряют AI и AI-агентов в рабочие процессы.

И всё чаще появляется формат human-agent teams:
+ AI берёт на себя часть рутины и первые черновики,
+ человек ставит цель для AI, проверяет результат и принимает решения.

Но из этого не следует вывод “аналитиков уберут”.
Из этого следует другой вывод:

👉 у аналитиков меняются ключевые навыки.

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

Теперь часть этого ускоряет AI:
расшифровка встреч, декомпозиция требований, черновики user story, описание API, выжимка из документов, первые черновики артефактов.



И вот здесь начинается самое интересное 👇

Если часть “механической интеллектуальной работы” ускоряется, то роль аналитика смещается.
Не в сторону “кто красивее оформил требования”, а в сторону:
✔️ кто правильно понял бизнес-проблему,
✔️ кто увидел противоречия,
✔️ кто задал неудобные, но нужные вопросы бизнесу / пользователям,
❗️ кто отличил хороший AI-черновик от опасной ерунды,
✔️ кто смог собрать из AI, людей, процессов и систем работающую функциональность для бизнеса.



👉 По сути, аналитик не исчезает — он поднимается уровнем выше, начинает контролировать AI-агентов и ставить им задачи.

Теперь растёт ценность тех специалистов, кто умеет:

1. Формулировать задачу так, чтобы её вообще можно было решать.
AI может хорошо писать, но не всегда понимает, что именно нужно бизнесу.

2. Проверять и валидировать результат AI
Правдоподобный артефакт от AI ≠ корректный. Поэтому критическое мышление, проверка ограничений, корнер-кейсов и бизнес-правил становятся ещё важнее.

3. Проектировать human-in-the-loop процессы с AI (человек в цикле)
Чем больше AI в процессах, тем важнее понимать, где можно автоматизировать, а где обязательно нужен человек.

4. Работать на стыке бизнеса, архитектуры, данных и AI
Сильный аналитик понимает:
— где AI реально нужен,
— какие данные ему нужны,
— какие есть ограничения и риски,
❗️ где нужен AI-агент, а где хватит обычной автоматизации.

5. Управлять “цифровым трудом” AI
Всё больше специалистов будут не только делать руками, но и ставить задачи AI, проверять результат и выстраивать зону контроля.



И вот что лично мне кажется самым важным.

🎯 Главный риск сейчас не в том, что AI вытеснит всех аналитиков.
Просто рынок начнет делиться на две группы:
✖️ тех, кто продолжает работать “как раньше” и конкурирует с AI на уровне черновиков,
✅ и тех, кто использует AI как усилитель и сам становится дороже.

👉 Масштабная трансформация навыков будет во всех профессиях.
И аналитическое мышление для работы с AI будет цениться больше всего.

То есть вопрос:
“Нужны ли будут аналитики?”
некорректный.

Вопрос другой:
“Какие именно аналитики будут нужны?”

На мой взгляд, особенно вырастет ценность тех, кто умеет:
✅ думать системно,
✅ понимать архитектуру и интеграции,
✅ быстро разбираться в новых инструментах,
✅ валидировать результаты от AI,
✅ формализовывать правила и ограничения,
✅ проектировать процессы с участием AI,
✅ быть переводчиком между бизнесом, разработкой, данными и AI-инструментами,
⚠️ писать черновики кода с AI и быть программистами на уровне junior.

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



👉 AI не вытесняет сильных системных аналитиков.
Он очень жёстко подсвечивает, кто реально умеет анализировать, а кто просто много лет перекладывал текст из встречи в документ 🤷‍♀️

Когда переборщил с требованиями на уникальность 😆

#GAhahaha

🤖 ТОП 7 AI-инструментов для СА и БА 🤖

Наш основной ресурс — это время.
Поэтому AI сейчас — это не просто «игрушки», а полноценные джуны-аналитики, если уметь с ними правильно обращаться.


Мой личный топ 7 AI-инструментов, которые я постоянно использую в работе в 2026 в картинках 👉👉👉 #hardGetAnalyst

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

Если только начинаете изучать интеграции, то это отличный способ проверить знания и понять, какие темы стоит повторить.

А если уже готовитесь к смене работы — сохраните пост, он точно пригодится👌
 
1️⃣ Что такое интеграция?
Это организованный обмен данными и командами между двумя или более системами по согласованным правилам, форматам и протоколам.
 
2️⃣ Какие виды интеграций систем вы знаете?
Ответ: Полный гайд по видам интеграций для Системного аналитика
 
 
3️⃣ Чем синхронная интеграция отличается от асинхронной?
В синхронной вызывающая система сразу ждет ответ. В асинхронной она передает запрос или событие и получает результат позже, что обычно лучше для отказоустойчивости и слабой связанности.
 
4️⃣ Когда лучше использовать API, а когда брокер сообщений?
API подходит для мгновенного запроса-ответа. Брокер лучше для сценариев, где не нужен мгновенный ответ пользователю. Брокер берут для реализации асинхронных сценариев. Часто для интеграции сервисов и микросервисов внутри одной системы. Например - паттерн хореография.
Подробнее про архитектурный паттерн хореографии на примере задачи.
 
 
5️⃣ Что такое webhook? Что такое polling и long polling?
Ответ на примере практической задачи: Что такое вебхуки и зачем они нужны: собеседование на системного аналитика по API и Webhooks
 
6️⃣ Что делать, если webhook не дошел?
Нужно предусмотреть повторную отправку при сбоях (ретраи), вести журнал доставки, исключить повторную обработку одного и того же события и иметь резервную проверку статуса — автоматически через polling или вручную.
 
7️⃣ Когда нужен брокер сообщений?
Когда нужно асинхронно передавать события, разгрузить синхронные вызовы, повысить устойчивость и разъединить жизненные циклы систем. Часто используют для внутренних взаимодействий сервисов в системе.
 
8️⃣ Какие ошибки нужно описывать в интеграции?
Технические ошибки связи, таймауты, ошибки авторизации, валидации, бизнес-ошибки и ошибки недоступности внешней системы.
Книга "Чек-лист: типовые требования к обработке ошибок в Интеграциях"
 
9️⃣ Чем техническая ошибка отличается от бизнес-ошибки?
Техническая связана с инфраструктурой или транспортом, например timeout. Бизнес-ошибка означает, что система доступна, но операция не может быть выполнена по бизнес-правилам.
 
🔟 Что делать при тайм-ауте внешней системы?
Нужно заранее определить правила повторных попыток, время ожидания ответа, сценарий действий при сбое, текст для пользователя и логику обработки повторного запроса.
 
1️⃣1️⃣ Когда retry (повторные попытки вызова внешней системы) опасны?
Когда операция неидемпотентна, например создание платежа или заказа без защитного ключа от дублей.

Подкаст: Идемпотентность и коммутативность API: что это и как применяют на практике
 
1️⃣2️⃣ Что такое маппинг данных?
Это таблица соответствия полей между нашей системой, внешней системой и иногда БД, плюс правила преобразования и комментарии.
Подробный ответ с примером: что такое маппинг данных

#hardGetAnalyst

Меня периодически спрашивают, как я всё успеваю.

Работа, курсы, подкасты, посты, вебинары, консультации, команда, обучение, спорт, личные дела....

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

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


Так что честный ответ такой:
👉 Я успеваю не всё.
✅ Просто я стараюсь каждый день успевать главное.


И вот что мне в этом реально помогает.


1️⃣🔥 Я планирую не задачами, а блоками времени

У меня есть ежедневник, и я не пишу туда просто список из 25 пунктов. Список задач сам по себе бесполезен без оценок.

Я раскладываю день по блокам:

▫️ 15 мин — ответить на письмо, сделать план

▫️ 30 мин — список вопросов к созвону, небольшая правка в требованиях, UML Sequence к готовым требованиям, ОБЕД, ПРОГУЛКА

▫️ 45 мин — разобрать чаты, уточнить требования

▫️ 60 мин — написать простой Use Case, сделать задачу на доработку БД, собрать отчет, посмотреть что-то по учёбе, доделать "хвосты" дня

▫️ 90 мин — написать требования к API-методу, изучить API-документацию внешней системы, спроектировать новый процесс

▫️ 2-6 часов — спроектировать интеграционный Use Case, проработка новых требований, сложная аналитика

▫️ Задача на 6+ часов — разносится на несколько рабочих дней.

Так сразу видно, что в день физически не влезает “сделать всё”.
И тогда приходится выбирать.

👉 Блок кончился, а не успела?
Стоп. Продолжение завтра.
Максимум 15-30мин выхода за тайминг.
Это тренирует работать в фокусе, точнее оценивать, и повышает продуктивность.
На задачах с дедлайнами правило игнорируется))

👉 Отметки в ежедневнике:
+ выполнено
> перенесено



2️⃣ На день всегда есть одна главная задача
Не две, а одна.
👉 Та, после которой день уже считается успешным.
Даже если всё остальное уехало на завтра.



3️⃣ Созвоны не должны съедать день

Сначала глубокая работа, потом встречи.
Потому что один созвон посереди дня легко убивает фокус.

👉 Созвоны только в одной половине дня и желательно один за одним.
Хорошо, если во второй половине, когда мозг работает хуже.

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

🩷 А ещё идеально устраивать день без созвонов.
У меня есть такой в календаре, минимум 1 раз в неделю.



4️⃣ Фокус = телефона нет рядом
Не “экраном вниз”.
Не “на беззвучном”.

👉 Телефон физически убран.

Потому что один случайный заход в Telegram или Instagram — и всё.

Фокус ушёл.
Задача снова кажется тяжёлой.
Надо опять погружаться с нуля.



5️⃣ Спорт и прогулки — это не “если останется время”
Раньше я думала: сначала работа, потом остальное.
👉 Но проблема в том, что “потом” часто не наступает.

Сейчас активность — это обязательная часть дня, которая включена в расписание.

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

Можно сидеть за ноутбуком 8 часов нон-стоп.
Но это не значит, что все 8 часов ты реально работаешь.



6️⃣ Если концентрации нет — я всё равно начинаю

Самое сложное не сделать задачу, а начать.
Особенно, если задача сложная и у меня нет опыта.

В такие моменты я не жду вдохновения.

Я просто через силу открываю задачу и начинаю разбирать первый маленький кусок.

И почти всегда происходит одно и то же:
+ сначала тяжело,
+ потом мозг цепляется,
+ потом становится интересно,
+ а потом меня уже сложно оторвать.



7️⃣ Я всегда понимаю, зачем делаю задачу
Нет понимания цели = нет смысла делать.



📌 Главный принцип
Не успеть всё, а каждый день честно ответить себе на 3 вопроса:

1. Что сегодня самое важное?
2. Когда у меня есть фокус на эту задачу?
3. Что нужно убрать, чтобы реально её сделать?

Вот и весь секрет продуктивности.

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

Хаос всё равно будет.
Срочные мелочи тоже.
И ночные доработки...

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