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

📌 Интеграции: полная и актуальная подборка материалов от GetAnalyst 📚 Подборка мини-книг, практических руководств и примеров задач, чтобы реально разобраться и закрепить тему. Всё от А до Я👇 📌 Введение в Интеграции: 📚 Книга по основам интеграций 📝 Виды интеграций: полный справочник 📝 Виды API для интеграций: справочник 📝 Интеграции: чек-лист по работе с задачами 📝 Как аналитику работать с задачами на интеграции — пошаговая инструкция 📚 Интеграционные Use Cases vs Обычные — разбор с примерами 🎧 Подкаст "Проблемы в работе с задачами на интеграции" 🎧 Опасные интеграции - про альтернативные сценарии и обработку типовых ошибок 📹 Задача на интеграцию по API: разбор с технического собеседования СА 🎧 Открытая база вопросов с собеседований на СА 2026 📌 Практика в Postman для исследования API: 🎧 Postman: навык тестирования REST API за вечер 📝 Инструменты для тестирования в API ♦️ Руководства по Postman: 📚 API DaData 📚 API Unisender 📚 API банка ВТБ 📚 API ChatGPT 📚 API KudaGo и DashaMail 📚 API для OAuth 2.0 в Mail ru 📚 API нейросети Groq AI 📌 Асинхронный обмен данными + брокеры: 📚 Очередь сообщений - что это и как работает? 📝 Всё про брокеры: как работают и зачем нужны 📝 Очередь vs Брокер: вопросы с подвохом 🎧 Доставить и не потерять: синхронизация данных в распределенных системах ♦️ Kafka: 🎧 Kafka: что нужно знать Системному аналитику 📝 Kafka - что надо знать для работы СА 📝 Устройство Kafka 📝 Алгоритм работы Kafka 📝 Как встроить Kafka в архитектуру, и главное зачем 📝 Пример использования Kafka - проект #FarmFreshGA 📝 Kafka в деле: подробный разбор примера использования в МСА ♦️ RabbitMQ: 🎧 RabbitMQ и его отличия от Kafka: что важно знать системным аналитикам 📝 Брокер RabbitMQ - полный гайд с разбором примера использования в микросервисах 📚 Брокер RabbitMQ - пошаговая практика по развёрыванию и тестированию через CloudAMPQ ♦️ Постановки задач / ТЗ с брокерами: 💎 Пример реального интеграционного Use Case: с микросервисами, cron и kafka - проект BookingGA 💎 Пример технического Use Case с брокером в микросервисной архитектуре - проект GreenChargeGA 📌 Шаблоны и примеры постановок задач: 💎 Подборка готовых постановок задач на Интеграции [выгрузки из Confluence] 📌 Обучения для СА и БА: 🎓 Практический курс Интеграции Систем 🎓 Материалы для самообучения по Интеграциям (пакеты вебинаров) Также всё по интеграциям всегда можно найти в Telegram-канале @getanalysts по хэштегу #ИнтеграцииGA 🙌 📱 Tg | 💙 ВК | 💬 Max

🟢 А вы бы решили эту SQL-задачу на собеседовании? 🤔 Кажется, что SQL можно не учить: AI же напишет запрос. Но системному аналитику SQL всё ещё нужен, чтобы понимать: ▫️ как хранятся данные в системе ▫️ как API работает с данными ▫️ что менять в БД под новую функциональность ▫️ и где AI написал запрос с ошибками И на собеседованиях SQL еще спрашивают. Поэтому в следующий понедельник проводим практикум по SQL с подключением к реальной БД PostgreSQL: 🎯 Инструмент DBeaver. Практика SQL-запросов 🔖 Проект: AI-платформа 🐘 СУБД: PostgreSQL 🗓 13 июля 2026 🕖 19:00 Мск 📹 Запись будет доступна на следующий день 🎁 Бонус: доступ к занятию «Оптимизация БД. Работа с индексами в БД» 🔗 Подробности и запись Стоимость участия от 1 450 рублей А пока — задача с собеседования для самопроверки 👇 По ней сразу видно, насколько уверенно вы чувствуете себя в SQL: 👍 решите быстро - вы в форме 🧐 зависнете - значит на практике будет максимум пользы ➡️ Задача: В системе интернет-магазина есть таблицы:

customer (id, full_name, phone)
order (id, number, customer_id, status, total_amount, created_at)

Нужно написать SQL-запрос, который покажет, сколько каждый покупатель потратил в интернет-магазине за 2026 год и сколько заказов сделал. Учитываем только оплаченные заказы: status = 'PAID' В результате вывести: + имя покупателя; + телефон покупателя; + количество оплаченных заказов за 2026 год; + общую сумму покупок за 2026 год. Ответ 🔽 . . . . . . . . . . . . . . . Ответ 🔽

SELECT
c.full_name AS customer_name,
c.phone AS customer_phone,
COUNT(o.id) AS orders_count,
SUM(o.total_amount) AS total_spent
FROM customer c
JOIN "order" o
ON o.customer_id = c.id
WHERE
o.status = 'PAID'
AND o.created_at >= '2026-01-01'
AND o.created_at < '2027-01-01'
GROUP BY
c.id,
c.full_name,
c.phone
ORDER BY
total_spent DESC;

#БД_и_SQL_GA

❗️ Новый HTTP-метод QUERY: значительное изменение стандарта впервые за 16 лет ❗️ 👉 Новый стандарт RFC 10008 от 15 июня 2026 https://www.rfc-editor.org/info/rfc10008/ добавил новый HTTP-метод "QUERY". Он закрывает боль, с которой аналитики и разработчики встречаются каждый раз, когда проектируют работу со списками и поиском, где нужно: + много фильтров, + сортировки, + пагинация. 👉 Назначение QUERY: поиск по каталогу с десятком фильтров. Например: ▫️ категория ▫️ цена ▫️ город ▫️ даты ▫️ сортировка ▫️ пагинация ▫️ доп параметры 👉 Вопрос собеседования:

Как сделать запрос на получение данных с кучей фильтров?

Старые ответы: ❌ GET с фильтрами в URL

GET /products?city=spb&priceFrom=1000&priceTo=5000&sort=rating...

Логика правильная: + GET - про получение данных. + мы ничего не создаём, ничего не меняем, просто читаем данные. Но у GET есть проблема. Если фильтров много: ▫️ URL становится огромным ▫️ прокси, браузеры и балансировщики могут резать длинные адреса ▫️ сложные JSON-фильтры неудобно кодировать в строку ▫️ параметры запроса засоряют логи Для простого поиска GET подходит. Для сложного поиска — уже нет. ❌ POST с фильтрами в теле запроса. Можно красиво передать фильтр в JSON:

POST /products/search

{
  "city": "spb",
  "priceFrom": 1000,
  "priceTo": 5000,
  "categories": ["hotel", "apartment"],
  "sort": "rating,asc"
}

Но появляются другие проблемы: ▫️ нецелевое использование: POST - предназначен для создания данных, а не для чтения ▫️ он не идемпотентный: при повторном вызове ожидаются изменения ▫️ его сложнее кэшировать Новый ответ: ✅ QUERY с фильтрами в теле запроса Он забирает лучшее у двух подходов: 🟢 От POST он берёт тело запроса То есть сложный фильтр можно передать в JSON:

QUERY /products/search
Content-Type: application/json

{
  "city": "spb",
  "priceFrom": 1000,
  "priceTo": 5000,
  "categories": ["hotel", "apartment"],
  "sort": "rating, asc"
}

🟢 А по смыслу QUERY ближе к GET Он говорит серверу и всей инфраструктуре по пути: этот запрос только читает данные и не меняет состояние ресурса. Из этого следуют два важных свойства: 👍 1. QUERY можно безопасно повторять Если сеть оборвалась, клиент может повторить запрос. Метод заявлен как идемпотентный. 👍 2. Ответ на QUERY можно кэшировать Но не просто по URL. Ключ кэша должен учитывать: ▫️ адрес запроса ▫️ тело запроса ▫️ связанные метаданные То есть: один и тот же URL + один и тот же фильтр = можно вернуть готовый ответ из кэша. А другой фильтр в body = другой результат и другой ключ кэша. Это особенно полезно для тяжёлых поисковых запросов, каталогов и аналитических выборок. ❗️ Актуальные проблемы 2026 для HTTP QUERY Хотя QUERY уже есть в стандарте HTTP, экосистема ещё догоняет. Проблемы: ▫️ сервер или фреймворк пока не понимает такой метод ▫️ API Gateway может не пропустить незнакомый тип запроса ▫️ CDN может ещё не уметь нормально кэшировать такие ответы ▫️ генераторы документации не знают этот метод (в том числе OPEN API) ▫️ в Postman и других инструментах тестирования QUERY пока не добавлен ▫️ SDK не поддерживают этот метод ▫️ в браузере могут появиться дополнительные проверки перед запросом Поэтому пока с внедрением QUERY лучше не торопиться. 👉 Как внедрять: ▫️ для внутренних API (обмен данными между микросервисами, для ваших веб- и мобильных приложений) — можно начинать использовать. ▫️ для публичных API (подключение к вам партнеров, интеграции с внешними систами) — лучше пока подождать. Перед внедрением обязательно проверьте поддержку в стеке разработки, документации, клиентах, шлюзах, кэшах и инструментах мониторинга. Так что теперь в HTTP: 👉 GET, POST, PUT, PATCH, DELETE, QUERY OPTIONS, HEAD, TRACE, CONNECT 👉 Запомните логику: ▫️ простой поиск — GET ▫️ создание — POST ▫️ сложный поиск с body — QUERY Стандарт появился. Теперь ждём, когда инструменты и инфраструктура массово обновятся. ❤️‍🔥 Подписывайтесь на GetAnalyst, чтобы быть в курсе актуальных обновлений IT, важных для аналитиков #ИнтеграцииGA #RestApiGA

🔔 Доступ к бесплатному практикуму по интеграциям открыт ДО ЗАВТРА: REST, GraphQL и gRPC 🚀 Разбираем, как читать API-документацию, настраивать запросы в Postman для REST, GraphQL и gRPC и понимать, какие выводы потом перенести в требования на интеграцию. 💫 Интеграции по REST, GraphQL и gRPC: 🧡 знакомство через Postman 📅 Доступ до 7 июля (вт) 🟢 В записи, можно смотреть в удобное время 🕘 3,5 часа практики 👉 Получить доступ* Несколько ярких отзывов за выходные 🩷 Александр:

Очень много конкретики, практические примеры. Как всегда всё на высоте!

Марина:

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

Ландыш:

Ваши бесплатные занятия лучше, чем другой платный курс, который я прошла(

Это действительно то обучение, которое можно не просто «посмотреть», а сразу забрать в работу 😉 👉 Получить доступ* * Если уже регистрировались — письмо с доступом у вас на почте, направили в субботу утром. Если не нашли, можно зарегистрироваться повторно. Продуктивной и вдохновляющей недели! 🚀 📱 Tg | 💙 ВК | 💬 Max

Не все отзывы идеальны. Но и нельзя научиться плавать, проходя тест “что делать, если тонешь”. Когда ты хочешь чему-то реально научиться, сотня тестов не заменит одну нормальную задачу, где нужно разобраться, проверить, ошибиться, переделать и собрать решение. Вот этим мы и занимаемся в GetAnalyst. На этой неделе завершили последнее занятие апрельского потока Интеграций 🤗 Спасибо вам за вопросы, домашки, честные отзывы, активность после работы и желание не просто послушать, а реально разобраться. На скринах немного того, ради чего всё это делается 💚 #студентыGetAnalyst 📱 Tg | 💙 ВК | 💬 Max

🩵🩷 Открыли бесплатный доступ к 3-х часовой практике по REST API, GraphQL, gRPC через Postman 🧡💙 Не мини-урок на 30 минут и не “послушать про API в целом”. Разбираем то, где у аналитиков обычно начинается путаница: как подступиться к новой интеграции, как читать API-документацию и как руками работать с REST, GraphQL и gRPC через Postman. 👉 Интеграции по REST, GraphQL и gRPC: знакомство через Postman 📅 Доступ до 7 июля (вт) 🕘 3,5 часа практики 🟢 В записи, можно смотреть в удобное время 📌 План: 1. Интеграции: порядок работы над задачами 2. Основы REST API + практика в Postman 3. Основы GraphQL + практика в Postman 4. Основы gRPC + практика в Postman 5. Порядок изучения новых API 🔗 Забрать бесплатный доступ* *Если уже регистрировались — письмо с доступом на почте. Если письмо не нашли, можно зарегистрироваться повторно. Продуктивной практики! 🧡 📱 Tg | 💙 ВК | 💬 Max

🧠 Проектируем AI-чат: где заканчивается нейросеть и начинается обычная автоматизация? 💡🤖 Разбираю на примере AI-чата #MedAssistGA для записи к врачу. На первый взгляд всё просто. 💬 Пользователь:

«У меня болит горло третий день, к кому идти?»

💬 AI:

«Вам нужен ЛОР»

🔎 и дальше показывает врачей. 👉 Но в реальном продукте так делать технически криво. Потому что AI не должен управлять всем сценарием записи к врачу. Иначе он может превратиться в хаотичного диспетчера. ❗️ Это не автономный AI-агент. 👉 Как обычно разделяют ответственность: 🧠 AI помогает понять смысл сообщения пользователя. ⚙️ Backend+UI управляют бизнес-сценарием. 1️⃣ Что делает AI AI нужен там, где есть неопределённость. Пользователь может написать: ▫️ «Болит горло и температура» ▫️ «У ребёнка сыпь» ▫️ «Мне нужен врач по спине» ▫️ «У меня уже есть диагноз, к кому записаться?» То есть пользователь пишет не структурированные данные, а обычный человеческий текст. И вот здесь AI полезен. Он должен: ✅ понять намерение пользователя ✅ аккуратно уточнить симптомы ✅ не ставить диагноз ✅ не назначать лечение ✅ определить подходящую специализацию врача ✅ распознать потенциально опасные симптомы ✅ вернуть структурированное решение для Backend 📌 Например: 💬 Пользователь:

«Третий день болит горло, температура 37.8, заложен нос»

💬 AI:

«По описанию вам может подойти консультация ЛОР-врача. Уточните, пожалуйста, есть ли сильная боль при глотании, налёт на миндалинах или затруднение дыхания?»

После уточнения AI возвращает не просто текст, а структурированное решение:

{
  "intent": "find_doctor",
  "specialty": "ENT",
  "specialtyName": "ЛОР",
  "urgency": "planned",
  "reason": "Пользователь описал боль в горле, насморк и температуру",
  "nextStep": "ASK_CITY"
}

И всё. На этом интеллектуальная часть закончилась. 2️⃣ Что делает автоматизация Дальше не нужно заставлять AI «думать», какую кнопку показать. Это уже обычный backend/UI-flow. После того как AI определил специализацию, система ведёт пользователя по понятному сценарию: 1. Спросить город 2. Подтвердить город 3. Показать клиники в этом городе 4. Дать выбрать клинику ИЛИ сразу показать врачей по найденной специализации 5. Дать отсортировать врачей по рейтингу/стажу/ближайшему слоту 6. Перейти к записи 📌 Например: AI определил:

{
  "specialty": "ENT",
  "specialtyName": "ЛОР"
}

Дальше Backend переводит чат в состояние ASK_CITY. UI показывает:

«В каком городе хотите найти врача?»

Пользователь выбирает город через виджет или пишет город текстом. После на UI можно спросить что для пользователя более важно: выбрать клинику или врача? Если клиника, то потом Backend переводит чат в состояние SELECT_CLINIC. UI показывает клиники. Потом Backend показывает врачей по параметрам: ▫️ город = Москва ▫️ клиника = выбранная клиника ▫️ специализация = ЛОР ▫️ сортировка = по рейтингу / ближайшему слоту И далее обычная автоматизация для записи к врачу, без AI. 👉 А если пользователь пишет текст вместо выбора в виджете? 📌 Например: Система ждёт выбор клиники, а пользователь пишет:

«А до скольки работает клиника на Ленина?»

Тогда это уже событие clinic_info. Система должна: 1. понять, о какой клинике речь; 2. получить часы работы из справочника; 3. ответить пользователю; 4. не потерять текущий сценарий записи. 📌 Ещё пример. Система уже показала ЛОР-ов, а пользователь пишет:

«А можно лучше к терапевту?»

Тогда это событие change_specialty. Система должна изменить специализацию и обновить список врачей. 👉 Почему не надо отдавать всё AI ❌ Сложнее контролировать бизнес-процесс ❌ Сложнее тестировать сценарии ❌ Сложнее обрабатывать ошибки ❌ Сложнее объяснить разработчикам, что именно должно происходить ❌ Сложнее защититься от странных пользовательских сообщений ❌ Сложнее обеспечить стабильный UX AI может хорошо понять смысл текста. Но запись к врачу — это уже не «магия нейросети», а обычный процесс, подлежащий автоматизации. В следующем посте покажу, как под такой сценарий написать системный промпт 🤝 #ИнтеграцииGA

🔔 Завтра закрываем лучшие условия на Интеграции 🔥 3 июля завершается предзапись на программу по самым сильным условиям за всю историю GetAnalyst. 🎁 До завтра можно закрепить: ✔️ доступ 8/12 месяцев вместо стандартных 6/9 ✔️ курс «БД и SQL: продвинутый уровень» в подарок ✔️ мини-курс «REST API для аналитиков 3.0» в подарок ✔️ закрытую встречу по задачам с собеседований Предзапись — это заявка, а не оплата. Она закрепляет за вами условия предзаписи до дня старта потока. 📚 Интеграции систем 🟣 Старт программы — 8 июля 👉 Оставить заявку А если сейчас хочется начать с бесплатной практики — приходите на вводный практикум 😌 Это полноценное практическое занятие на 3,5 часа, а не просто презентация программы. Вы сможете уже сейчас: + разобраться, чем REST, GraphQL и gRPC отличаются на практике; + попробовать работу с API в Postman; + понять, как аналитику читать API-документацию; + забрать практические навыки, которые можно применить в рабочих задачах. 🧡 Интеграции по REST, GraphQL и gRPC: знакомство через Postman 📅 Доступ 4–7 июля 🕘 3,5 часа практики 🟢 В записи, можно смотреть в удобное время 🔗 Зарегистрироваться Можно просто прийти за знаниями и уже сейчас получить практические навыки по интеграциям 🙌

🔥 Разбор с тех собеса на СА: задача на интеграцию по API 🔥 «Вам дали задачу на интеграцию с платёжной системой по API. Ваш порядок действий?» — и тишина. Именно такие задачи дают на технических собеседованиях SA. И именно на них теряются даже опытные аналитики, потому что непонятно, с чего начать и где остановиться. Разобрала одну такую задачу от начала до конца: интеграция ЭДО с DaData и Т-Банком: ✅ архитектура, ✅ интеграционные Use Case, ✅ маппинг, ✅ эндпоинты, ✅ постановки задач команде. 👉 Смотрите демо решения на удобной площадке: ⏯ YouTube ⏯ RuTube ⏯ VK Video ⏯ Telegram 🎧 Аудио-формат: ⏯ Apple Podcast ⏯ Яндекс.Музыка ⏯ Castbox ⏯ Звук ⏯ Spotify 🔗 Статья с доп. материалами по задаче 📱 Tg | 💙 ВК | 💬 Max

🤖 Tool Calling в AI: что это и как работает 🤖 Когда пользователь пишет в чат «болит горло, к кому записаться» — AI не знает расписание врачей вашей клиники. Он НЕ может просто «посмотреть в вашу БД». Но он может попросить вашу систему это сделать. Именно так работает Tool Calling. 👉 Что такое Tool Calling Tool Calling — механизм, при котором AI не отвечает текстом, а возвращает команду: «вызови вот этот инструмент с вот этими параметрами». Ваш бэкенд выполняет вызов, возвращает результат обратно в модель, и только тогда AI формирует финальный ответ пользователю. ❗️ Важно: AI не вызывает ваши сервисы напрямую. Он только говорит «что сделать». Вызов tool уже на стороне вашего Backend. 👉 Сценарий: пациент описывает симптомы, чтобы получить рекомендацию врачей 🔹 Шаг 1. Пользователь пишет в чат «Три дня болит горло, температура 38» Сообщение уходит на AI Chat Service. AI Chat Service отправляет запрос в Groq AI с системным промптом и сообщением пользователя. В запросе также передаётся список доступных инструментов — tools. 🔹 Шаг 2. Groq AI возвращает tool calls Groq анализирует симптомы, определяет специализацию врача, но возвращает не текст, а команду:

{
  "tool_calls": [{
    "function": {
      "name": "get_doctors",
      "arguments": {
        "specialty": "therapist",
        "city": "Moscow"
      }
    }
  }]
}

🔹 Шаг 3. AI Chat Service вызывает Сервис Врачей

GET /doctors?specialty=therapist&city=Moscow

Сервис Врачей возвращает список специалистов. 🔹 Шаг 4. Результат возвращается в Groq AI AI Chat Service передаёт ответ обратно в модель как tool result:

{
  "role": "tool",
  "content": [{
    "doctor_id": "d-001",
    "name": "Смирнова Елена Павловна",
    "specialty": "therapist",
    "rating": 4.9,
    "clinic": "Поликлиника №7"
  }]
}

🔹 Шаг 5. Groq AI формирует финальный ответ Теперь у модели есть данные — она отвечает пользователю: «Судя по симптомам, рекомендую терапевта. Нашел специалистов в вашем городе...» 👉 Каждый tool — это полноценный API-контракт Для get_doctors нужно описать: ▫️ входные параметры и их типы ▫️ обязательные и необязательные поля ▫️ что возвращается в модель ▫️ обработку ошибок: что вернуть если врачей нет и т.п. Если контракт описан плохо, AI получит неожиданный ответ и либо сломается, либо даст пользователю неверную информацию. 💡🧡 Чтобы понять как это работает, лучше всего попробовать на практике в Postman В канале опубликовала практическое руководство по тестированию API Groq AI через через Postman. В нём показано как работать с tool call и посмотреть что реально возвращает Groq. 🔗 руководство по исследованию API к AI через Postman Tool calling — это интеграционный API-контракт, где на другой стороне не разработчик, а языковая модель. С пониманием tool calling можно уверенно переходить к постановке интеграционной задачи с AI 🙌 #ИнтеграцииGA #MedAssistGA Tg | ВК | Max

🔴 [4–7 июля] GraphQL возвращает 200 OK. Даже когда ошибка. В REST такого не бывает. В GraphQL — норма. Ошибки живут внутри тела ответа JSON, в поле errors, а не в HTTP-статусе. Пока не знаешь — теряешься. Это только одна из неожиданностей при первом знакомстве с GraphQL. У gRPC тоже свои особенности. 👉 На этой неделе разбираем все три вида API руками в Postman — без теории в вакууме, сразу с практикой: 🧡 Интеграции по REST, GraphQL и gRPC: знакомство через Postman 🗓 4–7 июля 📹 Формат: запись, смотрите в удобное время 🔗 Зарегистрироваться ————————-————— 💎 Хотите системно разобраться с интеграциями по API и брокерам? Новый поток «Интеграции систем» стартует на следующей неделе. Впервые этим летом — максимальный набор подарков и скидок на предзаписи за всю историю GetAnalyst 🎁 🎓 Подробнее о программе ————————-————— 📱 Tg | 💙 ВК | 💬 Max

⚡ Синхрон, асинхрон, стриминг — в чём разница и когда что выбирать? ⚡ Про эти виды обмена данными постоянно спрашивают СА и БА на собеседованиях. Разбираю на примерах #MedAssistGA. 📌 Синхронный обмен Отправили запрос — ждём ответа, только потом идём дальше. Когда нужен: результат нужен прямо сейчас, чтобы продолжить сценарий. Примеры: ▫️ GET /doctors — запросили список врачей, ждём, показываем пользователю ▫️ GET /schedule — запросили слоты, ждём, показываем пользователю расписание ▫️ POST /appointments — создали запись, ждём подтверждения от сервиса, показываем пользователю Здесь нельзя идти дальше без ответа. Синхрон — единственный вариант. 📌 Асинхронный обмен Отправили сообщение — не ждём ответа, продолжаем работу. Результат получим позже. Когда нужен: результат не нужен мгновенно, запрос "тяжелый" (занимает много времени) и важна надёжность обработки. Пример из #MedAssistGA: 1. Врач запрашивает сводный отчёт по приёмам за месяц POST /reports/appointments 2. Система принимает запрос, кладёт задачу в очередь к обработке (RabbitMQ/Kafka) и сразу возвращает HTTP-201 со статусом "отчет формируется" и id будущего отчета. 3. Врач продолжает работу в системе. 4. Когда отчёт готов, Сервис Уведомлений присылает push или email со ссылкой на скачивание. Суть: мы не "крутим кружок" и не держим соединение открытым, пока система собирает данные. Пользователь может делать что угодно. А по готовности просто зайти и скачать итоговый результат. 📌 Стриминг (SSE и WebSocket — API реального времени) Данные передаются не одним ответом, а потоком. Соединение остаётся открытым на время передачи ответа. SSE (Server-Sent Events) — однонаправленный поток сервер → клиент. Работает поверх обычного HTTP. Пример из #MedAssistGA: 1. Пользователь задал вопрос в чате 2. AI Chat Service направил его в Groq 3. Groq генерирует ответ токен за токеном (слово за словом) и возвращает по SSE 4. AI Chat Service получает поток и передаёт его дальше во фронт, тоже через SSE 5. Пользователь видит текст по мере появления, не ждёт полного ответа. 📌 WebSocket — двусторонний канал, обе стороны инициируют сообщения. В #MedAssistGA его нет — но если добавим онлайн-чат врач–пациент, появится WebSocket. Пользователь сможет писать сообщения в чат и сразу получать новые сообщения от сервера без обновления страницы. Соединение между Frontend и Backend будет оставаться открытым, поэтому сервер сможет доставлять новые сообщения на экран в реальном времени. 👉 Как выбирать ▫️ Результат нужен сейчас → синхронный REST ▫️ Задача долгая или результат не нужен мгновенно → асинхронный (Kafka, RabbitMQ) ▫️ Сервер передаёт данные клиенту потоком → SSE ▫️ Обе стороны обмениваются в реальном времени → WebSocket #ИнтеграцииGA 📱 Tg | 💙 ВК | 💬 Max

🤯 Я больше не хочу учиться. Вообще. Это перебор 🤯 Именно так я решила в апреле, когда закончила программу по прикладному AI в Johns Hopkins University. Потому что учеба — это не просто «посмотреть уроки». Это время. Это силы. Это деньги. Это снова включать голову после работы, проектов, бизнеса и жизни. И честно? Я не думала, что так быстро снова решусь на новую учебу 🫠 Но на этой неделе у меня начался новый этап в Johns Hopkins — теперь про AI-агентов. И снова не через «соберите красивого бота в визуальном конструкторе за 15 минут», а через Python, код, архитектуру и нормальную инженерную логику. Да, опять будет тяжело 😅 Но я точно понимаю, зачем мне это нужно. Потому что учеба ради учебы — бессмысленна. Учеба нужна, когда ты понимаешь, как применить знания: ▫️ в проектах ▫️ в продуктах ▫️ в новых услугах ▫️ в росте своей экспертизы и дохода После прошлой программы у меня уже есть 4 новых проекта, связанных с AI, 3 из них уже закрыты и оплачены $$$$$ 🎉 И это как раз тот случай, когда знания быстро превращаются не в «сертификат на полку», а в реальные задачи, деньги и новый уровень профессиональной уверенности. Теперь немного заметок с первых занятий 👇 💡 AI-агент Это уже не просто чат, которому вы написали вопрос и получили текстовый ответ. AI-агент — это искусственный интеллект, который может делать действия: ▫️ сходить в интернет ▫️ обратиться к API ▫️ прочитать файл ▫️ запустить код То есть ChatGPT, Claude, Gemini, Cursor и другие инструменты становятся агентами тогда, когда они начинают что-то делать во внешнем мире, а не просто отвечать текстом. 📌 Напоминание: не надо везде AI Если задачу можно решить обычной автоматизацией без AI — лучше решить её обычной автоматизацией. Потому что AI почти всегда добавляет: ▫️ стоимость ▫️ сложность ▫️ риски ▫️ нестабильность результата ▫️ необходимость контроля качества 👉 Где нужен AI? Use cases из реального мира 1️⃣ Мониторинг логов и алертов AI-агент получает алерт, сам смотрит логи, метрики, последние релизы и помогает понять, почему упал сервис. В идеальном мире — ещё и предлагает исправление в коде. 2️⃣ Поддержка пользователей AI-агент отвечает на типовые вопросы клиентов, ищет ответы в базе знаний, проверяет статус заказа или заявки и снижает нагрузку на операторов. 3️⃣ HR и внутренние процессы AI-агент может помогать разбирать резюме, сопоставлять опыт кандидата с вакансией и отвечать сотрудникам на вопросы по регламентам компании. 4️⃣ Финансовые процессы AI-агент может анализировать счета, платежи, расходы, отклонения в транзакциях, готовить отчёты и подсвечивать риски. Плюс трейдинг. 5️⃣ Разработка кода Claude, Cursor и другие инструменты помогают писать код, искать ошибки, создавать тесты и работать с кодовой базой. 6️⃣ Личные ассистенты Пользователь пишет: «Найди и купи мне билеты на такие-то даты, самые дешые». Агент сам построит алгоритмы поиска и найдет билеты, но финальное подтверждение покупки за человеком. Потому что «купил не тот билет» — это уже не случайная галлюцинация, а реальные деньги. 👉 И еще один важный вывод: AI-агент не должен принимать финальное решение там, где ошибка стоит денег, безопасности, юридических последствий или доверия клиента. AI может: ▫️ собрать данные ▫️ проанализировать ▫️ предложить решение ▫️ подготовить черновик ▫️ подсветить риск Но в критичных и денежных сценариях человек должен подтверждать действие. 👉 Что актуально аналитикам? AI-агенты помогают автоматизировать бизнес-процессы, и кто-то должен описывать: ▫️ где агент участвует в процессе ▫️ какие инструменты он может вызывать ▫️ какие данные ему доступны ▫️ где нужен человек и это ок для бизнеса ▫️ как обрабатывать ошибки ▫️ что логировать ▫️ как тестировать результат работы AI 👉 В общем, я снова учусь. Хотя совсем недавно думала: «Ну его к черту. Больше не хочу». Знание итогов замотивировало: если учиться не ради галочки, а ради применения — результаты есть. Не всегда сразу. Не всегда легко. Но есть. Так что новый этап стартовал. Буду делиться с вами полезными заметками со своей учебы 💙 #AI_for_analysts

🧡 [4–7 июля] Интеграции по REST, GraphQL и gRPC через Postman 🧡 API-документация есть, задача на интеграцию есть — а с чего начать и как потом описывать требования, не всегда понятно. Особенно если это не только привычный REST, но ещё GraphQL или gRPC. На открытом практикуме покажем, как аналитику разобраться с разными видами API для интеграций систем и проверить их работу на практике: 🧡 Интеграции по REST, GraphQL и gRPC: знакомство через Postman 🗓 Доступ 4–7 июля 2026 🟢 Формат: в записи, смотрите в удобное время 👉 В результате вы: ▫️ Получите пошаговый план и практику по работе с задачами на интеграцию ▫️ Поймёте, чем отличаются REST, GraphQL и gRPC ▫️ Увидите, как проверять API в Postman ▫️ Самостоятельно протестируете методы по пошаговой инструкции ▫️ Разберётесь, на что смотреть в API-документации перед описанием интеграционных требований 🔗 Узнать подробнее и зарегистрироваться Регистрируйтесь — доступ будет открыт только с 4 по 7 июля 🤝 📱 Tg | 💙 ВК | 💬 Max

🚩 «Быстро» — это не требование. А вот RPS, SLO, SLA и CPU — уже конкретика, с которой можно работать 🚀 Мониторинг — это не только про DevOps. Системный аналитик, который не понимает метрики, рискует написать требования, которые невозможно проверить, выполнить или измерить. 🔗 Статья с доп. материалами В этом выпуске разбираем мониторинг с точки зрения аналитика. Выпуск будет полезен системным и бизнес-аналитикам, которые работают с нефункциональными требованиями, интеграциями, архитектурой, брокерами сообщений, API и вопросами надёжности систем. Заберёте для себя много полезных примеров НФТ. Видео с презентацией: ⏯ YouTube ⏯ RuTube ⏯ VK Video ⏯ Telegram Аудио: ⏯ Apple Podcast ⏯ Яндекс.Музыка ⏯ Castbox ⏯ Звук ⏯ Spotify GetAnalyst — сообщество, где аналитики растут быстрее 🚀 📱 Tg | 💙 ВК | 💬 Max