❤️‍🔥🤖 ИИ-агенты для аналитика: к концу практикума можно стать сеньором [8-11 августа] 🤖❤️‍🔥

«к концу практикума можно стать сеньором» 😄

Так один из участников комментировал количество инструментов и возможностей, которые мы разбираем за одно занятие.

Конечно, за 4 часа сеньором не стать.

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



❤️‍🔥 ИИ для работы аналитика: практика на задачах с REST API

🗓 Доступ только с 8 по 11 августа

📹 Формат: в записи
🕐 На обучение: 4 часа
🟢 Участие бесплатное

🔗 Зарегистрироваться



👉 На практике вы:

➕ настроите ИИ-агента для работы с API-задачами
➕ исследуете запросы к реальным API через Postman и Insomnia
➕ разберётесь, как работать со Swagger и OpenAPI-документацией
➕ поймёте, какие задачи можно передавать ИИ, а где необходима проверка аналитика

👉 Разберём 10+ инструментов для работы с ИИ и API:

✔️ Qwen
✔️ ChatGPT
✔️ Claude
✔️ Postman
✔️ Insomnia
✔️ Swagger
✔️ и другие



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

Он также является вводным занятием к практическим программам:

🎓 Проектирование REST API
Старт 11 августа
Завтра — последний день предзаписи по специальным условиям.

🎓 ИИ-Акселератор
Старт 29 августа
Для тех, кто хочет глубже освоить ИИ для рабочих задач.



——

P.S. Технические или организационные вопросы: @getanalyst или info@getanalyst.ru

🧐 URI vs URL: кажется, что это одно и то же. Но в чём разница? 🧐

URI и URL мы встречаем постоянно:

▫️ в адресной строке браузера
▫️ в документации к API
▫️ в постановках задач API: Base URL, URI, endpoint

На первый взгляд, всё это одно и то же: просто «ссылка», «эндпоинт» или «адрес метода».

👉 Да, URI и URL часто используют как взаимозаменяемые понятия. Но технически это не одно и то же.


Коротко:

🌟 URL — это один из видов URI.
🌟 Каждый URL является URI, но не каждый URI является URL.

А ещё существует URN.


Разберёмся на простых примерах 👇


1️⃣ URI — идентификатор ресурса

Uniform Resource Identifier

Это общее понятие: строка, которая идентифицирует какой-либо ресурс.

Примеры URI:

+ https://api.example.com/v1/products/42
+ mailto:user@example.com
+ urn:isbn:9783161484100

👉 Все три записи идентифицируют ресурсы, но делают это по-разному.



2️⃣ URL — адрес ресурса

Uniform Resource Locator

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

Например:

https://api.example.com/v1/products/42
По этому адресу клиент может отправить HTTP-запрос и получить данные о товаре.

https://getanalyst.ru/about
Это URL, который вы вводите в браузере, чтобы перейти на страницу "О нас" на веб-сайте с доменом "getanalyst.ru".

Здесь:
▫️ https — схема обращения
▫️ api.example.com и getanalyst.ru — домены
▫️ /v1/products/42 и /about— пути к ресурсам

👉 Поэтому данные строки являются одновременно:
✅ URI — потому что идентифицирует ресурс
✅ URL — потому что указывает его адрес и способ обращения



3️⃣ URN — имя ресурса

Uniform Resource Name

Он идентифицирует ресурс по устойчивому имени, но не указывает, где этот ресурс находится.

Например:
urn:isbn:9783161484100
urn:issn:2049-3630

Это уникальные идентификаторы книги.

Книга может продаваться в разных магазинах и храниться в разных библиотеках, но её ISBN/ISSN от этого не изменится.

URN может идентифицировать не только книгу. Например, <urn:uuid:...> задаёт устойчивый идентификатор объекта. При этом URN не сообщает, на каком сервере находится объект и как его получить.

👉 Итого по URN:
✅ является URI
❌ не является URL: сам по себе не указывает сетевой адрес ресурса и способ его получения



Главное, что нужно запомнить:

✅ URI — общее понятие: идентификатор ресурса
✅ URL — URI, который показывает адрес ресурса и способ обращения
✅ URN — URI, который задаёт устойчивое имя ресурса, но не указывает адрес

В REST API мы преимущественно работаем с HTTP(S) URL.

А слово endpoint обычно используют для обозначения точки обращения к API: сочетания HTTP-метода (GET/POST/PUT...) и адреса ресурса.



Теперь, увидев в постановке задачи Base URL, URI и endpoint, вы точно знаете, почему это не три названия одного и того же 😉


——-
P.S. А к чему относится "mailto:user@example.com"?
——-

#AI_for_analysts #RestApiGA

📱 Tg | 💙 ВК | 💬 Max

🟢 Доступ к обучению открыт: практика по ИИ и REST API 🟢

Полноформатное обучение, в котором вы практикуетесь с 10+ инструментами и погружаетесь в REST API и ИИ.


💙 Как ИИ меняет работу аналитика: практика на задачах с REST API
🗓 Доступ до 11 августа

👉 План:
1. Основы REST API — что должен знать системный аналитик
2. Для каких задач аналитику нужен ИИ при работе с API
3. Обзор ИИ-инструментов: Qwen, ChatGPT, Claude и другие
4. Практика настройки ИИ-агента для работы с задачами на API
5. Погружение в REST API на практике через Postman и Insomnia
6. Документирование REST API через Swagger

📄 Инструкция по подготовке
🕘 Время на обучение: 4.5 часа


🔗 Получить доступ*
*Если зарегистрированы, то доступ уже направили сегодня утром и ранее, в подтверждении регистрации.


Вдохновляющих выходных!


📱 Tg | 💙 ВК | 💬 Max

😰 От Junior в 7 раз чаще требуют навыков Middle и Senior...

Это не моё ощущение. Это результат исследования PwC — одной из крупнейших консалтинговых компаний в мире.

В 2026 они разобрали больше 1 млрд вакансий и подтвердили этот факт на 2,4 млн junior-вакансий в США.


❗️При этом ИИ не отменяет Junior-позиции.
Но поднимает планку входа в профессию и требования к грейдам в целом.


Причина логичная. ИИ всё лучше делает то, на чём раньше учились начинающие:

▫️ собрать первый черновик документа
▫️ структурировать требования
▫️ написать SQL
▫️ разобрать API
▫️ построить диаграмму
▫️ найти варианты решения


👉 Ценность специалиста смещается
от «умею сделать»
к «понимаю, ЧТО нужно сделать, могу проверить результат и принять решение»


Для аналитика попросить ИИ спроектировать REST API или написать Use Case недостаточно.

Нужно самому уметь ответить:

✅ какие сценарии он пропустил
✅ корректно ли спроектирован контракт API
✅ что будет при ошибках
✅ где нарушена бизнес-логика
✅ подходит ли решение вашей архитектуре

Если не можешь это проверить — ты не контролируешь результат, а угадываешь вместе с ИИ 🤷‍♀️


LinkedIn фиксирует тот же сдвиг с другой стороны.

Растут требования:
1️⃣ к владению AI-навыками,
2️⃣ к мягким навыкам (софт-скиллам) — работа со стейкхолдерами, коммуникация, лидерство.


Я же продолжаю повторять:

👉 ИИ не заменит аналитика.
Но аналитик с ИИ будет всё сильнее выигрывать у аналитика без него.

👉 А фундаментальные знания — не менее, а более важны.
Ведь теперь надо понимать, где накосячил ИИ.
Потому что его ответы всегда красивы, но далеко не всегда верны.


📚 Источники:
PwC — Global AI Jobs Barometer 2026
LinkedIn — Skills on the Rise 2026


А вы уже видите это на собеседованиях или в требованиях к джунам? Делитесь опытом в комментариях👇


#AI_for_analysts

📱 Tg | 💙 ВК | 💬 Max

📌📚 Кэширование — подборка материалов для СА 📚📌

Если в API нужно кэширование, аналитику недостаточно написать: «кэшировать данные».

В требованиях стоит ответить хотя бы на базовые вопросы:

✔️ Что кэшируем — весь ответ или отдельные данные
✔️ Где кэшируем — в приложении, Redis, HTTP-кэше, CDN
✔️ Кто источник истины — откуда берём актуальные данные
✔️ Какой TTL — время жизни кэша
✔️ Допустимы ли устаревшие данные и как долго
✔️ Как формируется ключ кэша — какие параметры в него входят
✔️ Когда инвалидируем кэш — по TTL, событию или изменению данных
✔️ Что происходит при cache miss — откуда получаем данные
✔️ Что происходит, если кэш недоступен — идём в БД / внешний сервис / возвращаем ошибку
✔️ Какие HTTP-механизмы используем — Cache-Control, ETag, If-None-Match и другие, если они нужны

👉 Если эти вопросы закрыты, разработчику не придётся самому решать, как должен работать кэш.


Собрала материалы GetAnalyst, которые помогут разобраться в теме и посмотреть, как переводить кэширование в конкретные требования 👇

🔗 Всё про кэш - самое главное в одной мини-книге

🔗 Ключевые алгоритмы кэширования cahce-miss / cache-hit

🔗 3 уровня кэширования

🔗 4 директивы заголовка Cache-Control, которые важно различать

🔗 ETag и 304 Not Modified — недостающие строчки в 90% ТЗ на справочники через GET

📌 Пример требований к API-методу с кэшированием

Сохраняйте как чек-лист и сверяйте с ним следующие постановки задач 🔖


#RestApiGA

📱 GetAnalyst | 💙 VK | 💬 Max

✅ 5 пунктов, которые постоянно теряют в ТЗ на API ✅

URL, HTTP-метод, параметры запроса и JSON обычно описаны.


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


1️⃣ Кэширование

Если данные можно кэшировать — это должно быть описано в требованиях.
Чаще всего — для операций получения данных (GET).

▫️ Что кэшируем?
▫️ Где: Backend, Redis, другое хранилище?
▫️ Какой TTL (время жизни)?
▫️ Что входит в ключ кэша?
▫️ Когда и кем кэш инвалидируется?

Написать просто «результат кэшировать на 10 минут» часто недостаточно.


2️⃣ Идемпотентность

Что произойдёт, если один и тот же запрос придёт дважды?

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

▫️ Выполним операцию повторно?
▫️ Вернём результат первого запроса?
▫️ Как определим, что запрос повторный?

Пользователь нажал кнопку два раза — система должна знать, что с этим делать.


3️⃣ Единый формат ошибок от API

Не так, что один метод возвращает:

{"error": "Not found"}

другой:

{"message": "Something went wrong"}

а третий свою структуру.

Для API должна быть определена единая модель возврата ошибок:

✅ единая структура JSON-ошибки
✅ правила использования HTTP-статусов

Иначе каждый новый метод постепенно начинает жить своей жизнью.


4️⃣ Что делать, если операция выполнилась только частично

Например:
Backend сохранил данные в БД → вызвал внешнюю систему → внешний вызов завершился ошибкой.

Или:
внешняя система выполнила операцию → а сохранить результат в нашей БД не получилось.

▫️ Что откатываем?
▫️ Что повторяем?
▫️ Нужна ли компенсационная операция?
▫️ В каком состоянии оставляем данные?

Особенно важно в интеграционных сценариях, где один пользовательский запрос запускает несколько операций.


5️⃣ Логирование и мониторинг

Пользователь пишет:

«Вчера в 15:42 я оплатил заказ, но статус не изменился».

Что дальше?

▫️ Есть ли requestId / correlationId?
▫️ Передаётся ли он между сервисами?
▫️ Что пишем в логи?
▫️ Какие технические и бизнес-метрики собираем?
▫️ На какие ошибки должны срабатывать алерты?

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



Ни один из этих пунктов технически не выглядит чем-то сверхсложным.

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


#RestApiGA

📱 GetAnalyst | 💙 VK | 💬 Max

🔥 21 задача аналитика, которую можно ускорить с ИИ 🤖🚀

Искусственный интеллект уже меняет работу системных и бизнес-аналитиков.

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


Задачи, решение которых можно ускорить с ИИ:

▫️ анализировать требования;
▫️ исследовать предметную область;
▫️ писать БТ, ФТ и НФТ;
▫️ разрабатывать User Stories + критерии приёмки;
▫️ разрабатывать Use Case и интеграционные Use Case;
▫️ строить BPMN-диаграммы;
▫️ строить UML-диаграммы;
▫️ проектировать БД и ERD;
▫️ писать и проверять SQL-запросы;
▫️ анализировать API внешних систем для интеграций;
▫️ помогать проводить исследовательское тестирование API через Postman / Insomnia;
▫️ проектировать REST API, SOAP API, gRPC, GraphQL, WebSocket и SSE API;
▫️ разрабатывать контракты REST API в OpenAPI / Swagger;
▫️ готовить постановки задач на Backend, Frontend и Mobile по корпоративным шаблонам;
▫️ прорабатывать архитектуру системы;
▫️ строить архитектурные схемы в C4;
▫️ прототипировать UI;
▫️ готовить требования к RabbitMQ и Kafka;
▫️ анализировать документацию, логи и ошибки;
▫️ готовить переписку с коллегами и заказчиками;
▫️ работать с технической коммуникацией на английском.

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



Но дальше — ещё интереснее.

Следующий уровень для СА и БА — создание собственных AI-агентов и приложений под рабочие задачи 😍

Аналитик уже может не только получать отдельные артефакты с помощью ИИ, но и:

✔️ собирать собственные AI-решения,
✔️ автоматизировать процессы команды,
✔️ убирать ручную рутину,
✔️ самостоятельно создавать рабочие прототипы и MVP.

И здесь начинается следующий уровень: мы не просто используем AI — мы начинаем создавать рабочие приложения с AI.

Всё это есть здесь:
💙 ИИ-Акселератор для СА и БА



📱 GetAnalyst | 💙 VK | 💬 Max

#AI_for_analysts