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

❤️‍🔥🤖 ИИ-агенты для аналитика: к концу практики можно стать сеньором [бесплатный доступ с 31 октября] 🤖 «К концу практикума можно стать сеньором» 😄 Так один из участников комментировал количество инструментов и возможностей, которые мы разбираем за одно занятие. Конечно, за 4 часа сеньором не стать. Но можно настроить ИИ-агентов, исследовать реальные API и научиться использовать нейросети так, чтобы они ускоряли работу, а не добавляли проблем. ❤️‍🔥 ИИ для работы аналитика: практика на задачах с REST API 🗓 Доступ только с 31.10 по 03.11 (сб-вт) 📹 Формат: в записи 🕐 На обучение: 4 часа 🟢 Участие бесплатное 🔗 Зарегистрироваться 👉 На практике вы: ➕ настроите ИИ-агента для работы с API-задачами ➕ исследуете запросы к реальным API через Postman и Insomnia ➕ разберётесь, как работать со Swagger и OpenAPI-документацией ➕ поймёте, какие задачи можно передавать ИИ, а где необходима проверка аналитика 👉 Разберём 10+ инструментов для работы с ИИ и API: ✔️ Qwen ✔️ ChatGPT ✔️ Claude ✔️ Postman ✔️ Insomnia ✔️ Swagger ✔️ и другие 👉 Этот практикум — можно пройти как полноценное самостоятельное занятие и сразу использовать полученные материалы и знания в работе. Если захотите продолжить обучение, он также станет введением к двум практическим программам: 🎓 Проектирование REST API Старт 3 ноября Специальные условия записи до четверга: сниженная цена и доп. практикумы "Интеграции 4.0" в подарок. 🎓 ИИ-Акселератор Старт 19 ноября Для тех, кто хочет глубже освоить ИИ для рабочих задач. P.S. Технические или организационные вопросы: @getanalyst или info@getanalyst.ru

Теперь на каждую повторяющуюся задачу я трачу в 2–3 раза больше времени 🤬😭 Новый способ успевать больше… Пару недель назад я сдала проект по AI-агентам в университете. Сдала его и подумала:

Ну какого черта?! Я сапожник без сапог!!! Для клиентов я с удовольствием исследую процессы и настраиваю им автоматизацию и агентов. Мне за это платят 🤑 А когда дело доходит до собственной рутины, включается классическое: «Сейчас быстрее сделаю вручную, а агента настрою потом».

И это «потом» может длиться месяцами 🙌 👉 Поэтому теперь у меня новое правило: если задача повторяется хотя бы раз в месяц, я не просто снова её выполняю, а сначала думаю, можно ли делегировать её AI-агенту. В итоге последние пару недель, вместо того чтобы выполнить задачку на 4 часа, я тратила все 8-12: 1. разбираю процесс по шагам 2. собираю AI-агента и подключаю инструменты 3. тестирую, нахожу ошибки и переделываю И нет, сразу времени больше не становится. Наоборот, сначала работы становится ещё больше. Зато! Задачи, которые в мае я вообще не могла доверить AI, сейчас агенты выполняют вполне уверенно. ‼️ И у меня нет возможности отложить текущие задачи и снять себя нагрузку, чтобы делать AI-агентов. Я трачу на это личное время. Минус сон, минус зал, минус отдых 🤬😡😭 Мой фитнес-браслет весь красно-жёлтый по восстановлению (это плохо), а недостаток сна приходится восполнять в выходные. Нет, это не та часть эксперимента, которую я рекомендую повторять. Но блин. Бесит. Иначе не получалось. Итого, делаю главные выводы: ▫️ Самое сложное — не выбрать модель, написать промпт или разобраться в агентах. ▫️ Самое сложное — нормально понять и описать собственный процесс, и найти на это время+вдохновение. Для меня таким мотивационным пинком стала учёба в Университете Джонса Хопкинса 💙 Сейчас создавать агентов можно разными способами: программировать, собирать в конструкторах или настраивать прямо внутри ChatGPT или Claude. Возможностей море. Мой следующий этап - создать CEO-агента: руководителя, который будет контролировать работу остальных агентов 😈 Но сначала нужно закончить этот сумасшедший месяц, в который я решила делегировать максимум возможного. На этом пост нытья окончен. Оставайтесь, через месяц расскажу, окупились ли вложения времени и денег в эту виртуальную команду — и начала ли я наконец работать меньше 🥲😀 📱 Tg | 💙 ВК | 💬 Max

✨ [Бесплатный практикум] ИИ для работы аналитика: практика на реальных задачах ✨ 👉 Представьте нового сотрудника. Отвечает мгновенно. Работает без выходных. Никогда не говорит «не знаю» — и звучит так уверенно, что спорить не хочется. Вы бы поручили ему написать контракт API, который уйдёт в разработку, или спроектировать продакшн БД для банковской подсистемы? Возможно, уже поручили. Это ваш ИИ-ассистент 🙂 Вопрос не в том, пользоваться ли ИИ. Пользуются все. Вопрос в том, где ему можно верить, а где проверять каждую строчку. Как его правильно настроить, чтобы требования и результаты от него имели 70+% готовности. Разберём всё это на открытом практикуме GetAnalyst 👇 ⚡️ ИИ для работы аналитика: практика на задачах с REST API 📅 Доступ 31 октября – 3 ноября (сб-вт) 🕘 Время на обучение: 4+ часа 🎯 Формат: запись, смотреть в удобное время 🟢 Бесплатно, нужна регистрация 🔗 Зарегистрироваться План: 1️⃣ Основы REST API — что должен знать системный аналитик 2️⃣ Для каких задач аналитику нужен ИИ при работе с API 3️⃣ Обзор 10+ ИИ-инструментов: Qwen, ChatGPT, Claude и другие 4️⃣ Практика настройки ИИ-агента для работы с задачами на API 5️⃣ Погружение в REST API на практике через Postman и Insomnia 6️⃣ Документирование REST API через Swagger В результате вы: ✅ настроите ИИ-агентов под свои задачи ✅ выполните реальные API-запросы ✅ поймёте, как ускорять работу с REST API без слепого доверия к ИИ Практикум будет полезен системным, бизнес- и начинающим аналитикам, которые хотят увереннее работать с API и современными ИИ-инструментами.

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

Присоединяйтесь на следующей неделе! 📱 Tg | 💙 ВК | 💬 Max

🔴😱 Сломанный найм в IT: виноват ли ИИ и как искать работу аналитику 💔 Почему системного аналитика не зовут на собеседования, даже если у него есть опыт? 💰 Что происходит с зарплатами и почему смена компании больше не гарантирует прибавку? 🤖 Виноват ли в этом ИИ? В этом выпуске обсуждаем рынок труда в IT в 2026 году — в России и других странах. Разбираем, как устроен отбор резюме через ATS, почему сотни откликов могут не приводить к приглашениям и как использовать ИИ-агентов для поиска работы. 🔗 Сайт эпизода с полезными материалами Эпизод для системных и бизнес-аналитиков, которые ищут работу, планируют сменить компанию или хотят понять, какие навыки развивать дальше. Видео: ⏯ YouTube ⏯ RuTube ⏯ VK Video Аудио: ⏯ Apple Podcast ⏯ Яндекс.Музыка ⏯ Telegram ⏯ Castbox ⏯ Звук ⏯ Spotify GetAnalyst — база знаний с разборами проектов для Middle+/Senior системных аналитиков 🚀 📱 Tg | 💙 ВК | 💬 Max

Сегодня искать работу только через hh — это добровольно выбрать самый сложный путь к офферу... Конкуренция среди кандидатов выросла, 200-400-700 откликов на вакансию стало нормой, поэтому важно не просто отправлять больше откликов, а использовать несколько каналов одновременно. Разбираемся, какие площадки работают и чего от них ожидать 👇 🔵 Telegram-каналы – это топ для РФ и СНГ Вакансии часто публикуют напрямую HR, руководители или сотрудники компаний. Можно быстро увидеть новую позицию и связаться с живым человеком, пока не прилетели сотни откликов. Но проверяйте автора и работодателя: часть публикаций копируется с других площадок, а среди прямых объявлений встречается мошенничество. 🔴 hh.ru – работает Вакансий много, офферы через него получают. Но конкуренция огромная. Плюс часть вакансий может месяцами оставаться открытой для сбора базы кандидатов или просто для поддержания видимости, что компания продолжает нанимать. Откликаться стоит, но рассчитывать только на hh я бы не стала. 🟢 GetMatch.ru – норм Работают чуть слабее. Вакансий меньше, но хорошие реальные предложения там есть. Проблема та же: на сильные позиции быстро приходит много кандидатов. 🔹 LinkedIn – работает как hh Может работать даже лучше hh по вакансиям в России и СНГ. Особенно полезен для поиска международных компаний, удалённой работы и прямого выхода на рекрутера. При этом цифра «300 откликов» не всегда означает 300 отправленных резюме. Если отклик ведёт на внешний сайт, LinkedIn может учитывать людей, которые только нажали кнопку перехода. Но скорость всё равно важна: свежую вакансию с небольшим количеством кандидатов заметить проще. Важно учитывать, что LinkedIn официально заблокирован на территории РФ. ⚪ Сайты компаний – ок Использовать стоит, особенно если вы уже знаете, в каких компаниях хотите работать. На сайте можно: ▫️ проверить, действительно ли вакансия ещё открыта ▫️ найти позиции, которых нет на агрегаторах ▫️ посмотреть смежные роли ▫️ подписаться на обновления Но это уже не секретный способ обойти конкуренцию. Все давно знают, что можно зайти на карьерную страницу компании. А ваши анкета и резюме при этом часто всё равно попадают в ту же ATS. 🔘 Хабр Карьера – не надо тратить время По нашим наблюдениям сейчас даёт самый слабый результат. Откликаться можно, но делать эту площадку основным каналом поиска я бы точно не стала. 📱 Рекрутеры и кадровые агентства – не лучший вариант Это отдельный канал, о котором часто забывают. Добавляйте в контакты рекрутеров, которые работают с ИТ и аналитиками. Отвечайте на сообщения, даже если прямо сейчас не готовы менять работу. 💡 Часть позиций сначала появляется во внутренних базах агентств и профессиональных чатах, а уже потом выходит в открытый поиск. 💚 Рекомендации — один из самых сильных способов Рекомендация не гарантирует оффер и не отменяет техническое собеседование. Но она сильно повышает вероятность, что ваше резюме действительно увидит живой человек. Иногда анкету всё равно придётся зарегистрировать в ATS, но рекрутер будет видеть, что кандидата рекомендовал сотрудник компании. А в некоторых компаниях сотрудник ещё и получит бонус, если вас наймут. ✅ Поэтому нетворкинг сейчас важен как никогда. Ходите на конференции и митапы. Общайтесь с коллегами, HR и руководителями. Поддерживайте отношения с бывшими коллегами и одногруппниками. Рассказывайте знакомым, что рассматриваете предложения. ❗️ И главное — не начинайте поддерживать контакты только тогда, когда работа понадобилась срочно. Итого — рабочая стратегия сейчас: 1️⃣ Несколько каналов 2️⃣ Быстрый контакт / отклик 3️⃣ Тёплый вход: рекомендации, профессиональные сообщества, конференции и бывшие коллеги. Не выбирайте одну «лучшую» площадку. Стройте воронку поиска и отслеживайте, откуда приходят просмотры, ответы и собеседования. 👉 Подборку Telegram-каналов для поиска заветных офферов СА и БА можно забрать по 🔗 этой ссылке #КарьераGA 📱 Tg | 💙 ВК | 💬 Max

🌶 Одновременное редактирование в REST API: решаем проблему затирания чужих изменений [ETag + If-Match] 🌶 Петя и Настя открыли один документ и начали его редактировать. Петя первым сохранил изменения. Настя нажала «Сохранить» чуть позже. Если сервер просто примет оба обновления, изменения Насти могут затереть то, что сохранил Петя. При этом оба увидят, что сохранение прошло успешно. Как решить? 👉 Для этого можно использовать ETag + If-Match. ETag часто рассматривают только как механизм кеширования. Но он также помогает решить проблему одновременного обновления. Разберём на примере 👇 Два пользователя одновременно открыли один документ и получили одинаковые данные: Запрос:

GET /documents/4831

Ответ:

HTTP/1.1 200 OK
ETag: "17"
Content-Type: application/json

{
  "name": "Версия 0",
  "number": "123/9364",
  "text": "Тут текст ...."
}

Оба пользователя редактируют документ, соответствующий версии ETag: "17". 🏁 Первый пользователь сохраняет изменения Приложение передаёт полученный ETag в заголовке If-Match, в метод изменения документа. Запрос:

PATCH /documents/4831
If-Match: "17"
Content-Type: application/json

{
  "name": "Версия от Пети",
  "number": "123/9364",
  "text": "Тут текст ...."
}

Сервер при получении API запроса: 1️⃣ проверяет в API, что текущий ETag=17 2️⃣ проверяет в БД, что ETag совпадает с текущей версией документа 3️⃣ сервер сохраняет изменения в БД 4️⃣ возвращает успешный ответ на запрос с новым ETag:

HTTP/1.1 204 No Content
ETag: "18"

и телом ответа, при необходимости. 🏁 Второй пользователь пытается сохранить документ, но уже старую версию Его запрос такой же как и у первого клиента, ETag всё ещё 17, хотя по факту изменение первого пользователя уже принято и изменения произошли. Запрос:

PATCH /documents/4831
If-Match: "17"
Content-Type: application/json

{
  "name": "Версия от Насти",
  "number": "123/9364",
  "text": "Тут текст ...."
}

Но документ уже имеет ETag: "18" после изменений первого пользователя (Пети). Сервер не должен перезаписывать изменения первого пользователя. Сервер при получении API запроса: 1️⃣ проверяет в API, что текущий ETag=17 2️⃣ проверяет по БД текущую версию, а там уже 18 3️⃣ возвращает ошибку:

HTTP/1.1 412 Precondition Failed
Content-Type: application/json

{
  "errorCode": "VERSION_CONFLICT",
  "message": "Документ был изменён другим пользователем. Обновите данные и повторите действие.",
  "traceId": "2a48c7..."
}

Клиенту для обработки такой ошибки надо: 1. повторно получить новую версию документа GET /documents/4831 2. предложить пользователю сравнить версии: объединить изменения или начать редактирование заново ❗️ Нельзя получить новую версию данных с ETag=18 и автоматически повторить запрос на изменение с новым ETag: так клиент всё равно может затереть чужие данные. 📌 Логика обработки запроса на редактирование ✅ If-Match совпадает с текущим ETag → выполнить изменение и вернуть новый ETag ❌ If-Match не совпадает → вернуть 412 Precondition Failed и не изменять ресурс ⚠️ If-Match отсутствует, хотя условное обновление обязательно → можно вернуть 428 Precondition Required, если это предусмотрено контрактом API Само значение ETag непрозрачно для клиента: его не нужно разбирать или вычислять самостоятельно. Клиент должен сохранить полученное значение от GET /resources/{id} и вернуть его в If-Match для PATCH /resources/{id} без изменений. 📌 Почему здесь HTTP-412, а не HTTP-409? 412 Precondition Failed означает, что не выполнилось условие из заголовка If-Match. 409 Conflict используют для других конфликтов состояния или бизнес-правил, не связанных с проверкой условного запроса. 📌 Где хранится ETag в БД? Сам ETag обычно не хранится в БД в виде строки ETag: "18". В таблице ресурса хранится техническое поле версии: таблица document ——— id: 4831 name: Версия 0 version: 17 updated_at: ... ——— К посту добавила более подробный чек-лист для вашей копилки полезных материалов от GetAnalyst 🤝 #RestApiGA

🩵 Открыли предзапись на «Дизайн REST API» — старт 3 ноября 🩵 Знать, чем GET отличается от POST, и помнить основные HTTP-коды — ещё не значит уметь проектировать REST API. На реальном проекте аналитику нужно определить: 🔹 методы и параметры запросов 🔹 структуру JSON-моделей 🔹 проверки, права доступа, ответы и ошибки 🔹 содержание контракта для разработчиков и тестировщиков 🔹 сценарий работы 🔥 ИИ может быстро сгенерировать API-контракт, но не гарантирует, что он будет корректным. Поэтому аналитику важно уметь проектировать API, проверять решения ИИ и аргументировать свои решения. На практическом курсе «Дизайн REST API» мы последовательно проходим весь процесс: от бизнес-требований и сценария до готового и проверенного API-контракта. 🎓 Что входит в программу: ▫️ 50 часов материалов в записи ▫️ 80% программы — разбор реальных задач 🟢 онлайн-практикумы ▫️ обратная связь по материалам и заданиям в мини-группе ▫️ шаблоны, примеры, инструкции и чек-листы, которые можно использовать в работе ▫️ разборы задач с собеседований ▫️ проверка домашних заданий ▫️ использование ИИ для проектирования, проверки и доработки API-контрактов 🚀 Для кого актуально: ▫️ Junior СА — чтобы систематизировать знания и научиться проектировать API с нуля ▫️ Middle СА — чтобы увереннее принимать и аргументировать проектные решения ▫️ бизнес-аналитикам ▫️ тестировщикам ▫️ backend-разработчикам 📌 В процессе обучения вы разработаете свой API-проект: ✅ постановки задач в Confluence ✅ коллекции запросов Postman/Insomnia/Bruno ✅ OpenAPI-спецификацию в Swagger ✅ контракты методов и JSON-модели ✅ контракты асинхронных запросов ✅ требования к авторизации и обработке ошибок ❤️‍🔥 mock-сервер с работающим API В результате у вас останется проект, который можно подробно разобрать и показать на собеседовании. 🩵 Дизайн REST API 📅 Старт — 3 ноября 🎁 До 29 октября действует цена предзаписи, а мини-курс «Интеграции систем 4.0» можно получить в подарок. Посмотреть полную программу и бесплатно оставить заявку можно по ссылке: 👉 Посмотреть программу и оставить заявку Сомневаетесь, подойдёт ли вам эта программа? Напишите в ЛС @getanalyst, с какими задачами по API вы уже работаете и чему хотите научиться. Мы честно подскажем, соответствует ли курс вашему опыту и целям 🤝 #RestApiGA

📁 Потоковая передача и Range: как отдавать большие файлы в REST API 📁 При передаче больших файлов часто смешивают два разных механизма: ✅ потоковую передачу ✅ получение файла частями с Range Но это не одно и то же. 📌 Потоковая передача файла При обычной потоковой передаче клиент отправляет запрос на получение файла:

GET /files/4831/content

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

HTTP/1.1 200 OK
Content-Type: application/pdf
Content-Disposition: attachment; filename="report.pdf"
Content-Length: 5242880

%PDF-1.7...

Для клиента это один обычный HTTP-ответ со всем содержимым файла. Потоковая передача описывает то, как сервер читает и отправляет данные. Это не отдельный формат ответа и не означает, что файл обязательно можно скачать частями. 👉 Во время потоковой передачи HTTP-ответ остаётся незавершённым, а соединение с клиентом — активным, пока сервер не передаст весь файл или передача не прервётся. 📌 Получение файла частями с помощью Range Если клиенту нужно получить только определённую часть файла, он передаёт заголовок Range:

GET /files/4831/content
Range: bytes=0-1048575

Такой запрос означает: 💡 вернуть байты с позиции 0 по позицию 1048575. Сервер возвращает не весь файл, а только запрошенный диапазон:

HTTP/1.1 206 Partial Content

Content-Type: application/pdf
Content-Disposition: attachment; filename="report.pdf"
Accept-Ranges: bytes
Content-Range: bytes 0-1048575/5242880
Content-Length: 1048576

Обратите внимание на headers: ▫️ 206 Partial Content — возвращена только часть файла ▫️ Accept-Ranges: bytes — сервер поддерживает получение файла по диапазонам байтов ▫️ Content-Range — показывает границы возвращённой части и полный размер файла ▫️ Content-Length — содержит размер возвращаемой части, а не всего файла Поддержка Range нужна, например, для: ▫️ возобновления прерванного скачивания ▫️ перемотки видео и аудио ▫️ параллельной загрузки частей большого файла ▫️ получения только необходимого фрагмента данных 👉 Что вернуть при некорректном диапазоне Если клиент запросил диапазон, которого в файле не существует, сервер возвращает:

HTTP/1.1 416 Range Not Satisfiable
Content-Range: bytes */5242880

Число после / показывает полный размер файла. Например, нельзя запросить байты начиная с позиции 6000000, если размер файла составляет только 5242880 байт. 👉 Какие заголовки надо определить в требованиях Content-Type — формат содержимого файла:

Content-Type: application/pdf

Content-Disposition — как браузер должен обработать файл:

Content-Disposition: attachment; filename="report.pdf"

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

Content-Disposition: inline; filename="report.pdf"

Content-Length — размер всего ответа в байтах:

Content-Length: 5242880

В ответе 206 Partial Content это размер возвращаемой части файла. Accept-Ranges — сообщает о поддержке получения файла частями:

Accept-Ranges: bytes

Content-Range — показывает, какой диапазон возвращён:

Content-Range: bytes 0-1048575/5242880

👉 Как описать в задаче Можно использовать такую формулировку: Метод GET /files/{fileId}/content должен проверить наличие файла и права пользователя на его получение. Если заголовок Range не передан, метод возвращает всё содержимое файла с кодом 200 OK. Сервер должен читать файл из хранилища и передавать его клиенту потоком, не загружая файл целиком в оперативную память. Если передан корректный заголовок Range, метод возвращает запрошенный диапазон байтов с кодом 206 Partial Content. Если запрошенный диапазон не существует, метод возвращает 416 Range Not Satisfiable. 🔗 Пример Amazon S3 GetObject Используйте этот пост как основу для постановки задач на получение больших файлов через REST API 🩵 #RestApiGA | Tg | ВК | Max

📁 Как вернуть файл в REST API: 5 вариантов реализации с реальными примерами 📁 Формулировки «метод возвращает файл» для разработки недостаточно. Нужно определить: ▫️ где хранится файл ▫️ передаём ли мы его в теле ответа или возвращаем ссылку ▫️ должен ли файл открываться в браузере или скачиваться 📌 1. Передать содержимое файла в теле ответа Подходит, если пользователь должен получить файл сразу, а API самостоятельно проверяет права и передаёт его содержимое. В теле ответа возвращаются бинарные данные - сам файл.

HTTP/1.1 200 OK
Content-Type: application/pdf
Content-Disposition: attachment; filename="report.pdf"

%PDF-1.7...

Если файл большой, сервер может читать его из хранилища и сразу передавать клиенту частями, не загружая целиком в оперативную память - это уже будет потоковая передача. 🔗 Пример Google Drive 📌 2. Файл закодированный в Base64 Здесь сервер сначала преобразует байты PDF-файла в строку Base64, а потом помещает её в JSON.

HTTP/1.1 200 OK
Content-Type: application/json

{
  "fileName": "report.pdf",
  "contentType": "application/pdf",
  "content": "JVBERi0xLjcKJ..."
}

Клиент должен: ▫️ получить JSON ▫️ извлечь значение поля content ▫️ декодировать Base64 обратно в байты ▫️ сохранить полученные байты в файл нужного формата 🔺 Base64 без необходимости лучше не использовать: объём данных увеличится примерно на треть, а серверу и клиенту потребуется больше памяти на обработку. 🔗 Пример GitHub 📌 3. Вернуть временную ссылку Подходит для больших файлов и файлов из объектного хранилища — например, S3. API проверяет права пользователя и возвращает ссылку, по которой клиент скачивает файл напрямую из хранилища:

{
  "downloadUrl": "https://storage.example.com/...",
  "expiresAt": "2026-10-20T12:00:00Z"
}

В требованиях нужно указать: ▫️ срок действия ссылки ▫️ для какого файла и HTTP-метода она действует ▫️ можно ли использовать её повторно ▫️ нужно ли журналировать факт выдачи ссылки, не сохраняя сам URL 🔗 Пример для Dropbox 📌 4. Разделить метаданные и содержимое файла Подходит, если сначала нужно показать пользователю информацию о файле, а скачивание он запускает отдельно. Сочетается с любым из трёх способов выше.

GET /files/{fileId}

Метод возвращает метаданные:

{
  "id": "4831",
  "name": "report.pdf",
  "mediaType": "application/pdf",
  "size": 5242880,
  "status": "READY"
}

Сам файл возвращает отдельный метод:

GET /files/{fileId}/content

Примеры Box API: 🔗 получение информации о файле (тут и URL на скачивание) 🔗 скачивание содержимого файла. 📌 5. Получение файла частями Подходит для больших файлов, видео, возобновления прерванной загрузки и параллельного скачивания. Клиент передаёт диапазон байтов:

GET /files/4831/content
Range: bytes=0-1048575

Сервер возвращает только запрошенную часть:

HTTP/1.1 206 Partial Content
Content-Type: application/pdf
Accept-Ranges: bytes
Content-Range: bytes 0-1048575/5242880
Content-Length: 1048576

🔗 Пример Amazon S3 GetObject Важно: потоковая передача и Range — не одно и то же. При потоковой передаче сервер последовательно читает и отправляет файл, не загружая его целиком в память. Клиент при этом может получить обычный ответ 200 OK. При использовании Range клиент сам запрашивает конкретную часть файла, а сервер возвращает 206 Partial Content. Сохраняйте пост и используйте его как шпаргалку, когда будете описывать получение файлов в REST API 🤝 #RestApiGA | Tg | ВК | Max

📌 Шпаргалка по HTTP-методам: безопасность, идемпотентность, кэшируемость и тело JSON 📌 В англоязычной Wikipedia уже обновили таблицу свойств HTTP-методов: в ней появился новый метод QUERY, описанный в RFC 10008. https://en.wikipedia.org/wiki/HTTP#Request_methods Эта таблица — моя вечная шпаргалка для подготовки к собеседованиям. Свойства методов из таблицы 👇 📤 Запрос может содержать тело — Request payload Показывает, может ли запрос содержать данные в body. Для POST, PUT, PATCH и QUERY тело является обычной частью запроса. Для GET, HEAD и DELETE тело технически может быть передано, но его общая семантика стандартом не определена. Более того, некоторые серверы и промежуточные компоненты могут отклонить такой запрос. 📥 Ответ может содержать тело — Response payload Показывает, может ли сервер вернуть данные в body. Например, HEAD возвращает только заголовки. У ответов 204 No Content и 304 Not Modified тела быть не должно. 🛡 Safe — безопасный Метод считается безопасным, если клиент не запрашивает изменение состояния целевого ресурса. Например: ▫️ GET получает данные ▫️ HEAD получает заголовки ▫️ QUERY получает данные При этом логирование, сбор статистики и другие внутренние побочные действия сервера не делают метод небезопасным. 🔁 Idempotent — идемпотентный Несколько одинаковых запросов должны иметь тот же ожидаемый эффект, что и один. Например, первый DELETE может вернуть 204, а повторный — 404, но ресурс в обоих случаях удалён. POST и PATCH по умолчанию не считаются идемпотентными. 🗄 Cacheable — кэшируемый Ответ можно сохранить и повторно использовать по правилам HTTP-кэширования. Это зависит от: ▫️ Cache-Control ▫️ клиента и сервера ▫️ CDN и прокси ▫️ реализации метода Даже POST и PATCH могут кэшироваться при выполнении специальных условий. Спорные случаи лучше проверять по RFC. Сохраняйте, если готовитесь к собеседованиям или изучаете HTTP и REST API 💙 #RestApiGA 📱 Tg | 💙 ВК | 💬 Max

💥 А вы бы решили эту задачу по SQL с JOIN на 4 таблицы? Ответ в конце, а разбор уже сегодня в 19:00 Мск 💥 ИИ может написать SQL-запрос за несколько секунд. Но системному аналитику всё равно нужно разбираться в SQL, чтобы понимать: ▫️ как связаны данные в таблицах; ▫️ как API читает и изменяет данные; ▫️ что нужно изменить в БД под новую функциональность; ▫️ не вернул ли ИИ работающий, но логически неправильный запрос. И на технических собеседованиях SQL по-прежнему спрашивают. 👉 Поэтому на практикуме будем не просто разбирать синтаксис, а писать и проверять запросы на реальной PostgreSQL БД платформы для работы с ИИ-моделями. Для занятия я подготовила: ▫️ PostgreSQL БД на удалённом сервере — как на любом рабочем проекте ▫️ приложение-тренажер с практическими заданиями, которое останется у участников ▫️ задачи на разные виды JOIN, объединение нескольких таблиц, GROUP BY, HAVING, UNION и UNION ALL ▫️ гайд по SQL, по которому можно быстро повторить всю самую важную теорию перед собеседованием После практикума вы сможете увереннее строить сложные запросы, замечать типичные ошибки и проверять SQL, созданный с помощью ИИ. 🔥 SQL-запросы с JOIN: практика на реальной БД 🗓 19 октября, 19:00 Мск 🐘 PostgreSQL 💻 DBeaver 🟢 Проект: AI-платформа 📹 Запись будет доступна после эфира 🎁 Бонус: занятие «Маппинг данных. Практика формирования JSON на основе БД и UI» 🔗 Записаться на практикум Стоимость участия от 1 450 рублей А пока — задача для самопроверки 👇 В интернет-магазине есть таблицы: customer (id, full_name) order (id, customer_id, status, created_at) order_item (order_id, product_id, quantity, unit_price) product (id, category_id) Найдите покупателей, которые за 2026 год: ▫️ сделали не менее трёх оплаченных заказов; ▫️ купили товары минимум из двух категорий; ▫️ потратили более 20 000 рублей. Выведите имя, количество заказов, количество товаров, количество категорий и общую сумму покупок. Ответ 🔽 . . . . . . . . . .

SELECT
    c.full_name,
    COUNT(DISTINCT o.id) AS orders_count,
    SUM(oi.quantity) AS items_count,
    COUNT(DISTINCT p.category_id) AS categories_count,
    SUM(oi.quantity * oi.unit_price) AS total_spent
FROM customer c
JOIN "order" o ON o.customer_id = c.id
JOIN order_item oi ON oi.order_id = o.id
JOIN product p ON p.id = oi.product_id
WHERE o.status = 'PAID'
  AND o.created_at >= DATE '2026-01-01'
  AND o.created_at < DATE '2027-01-01'
GROUP BY c.id, c.full_name
HAVING COUNT(DISTINCT o.id) >= 3
   AND COUNT(DISTINCT p.category_id) >= 2
   AND SUM(oi.quantity * oi.unit_price) > 20000
ORDER BY total_spent DESC;

Главный подвох — COUNT(DISTINCT o.id): после соединения с товарами один заказ превращается в несколько строк. #БД_и_SQL_GA

Искать работу сейчас сложно. Хоть джуну, хоть мидлу 😞 Делюсь актуальными новостями с полей: что нам рассказывают HR и работодатели и что мы видим со стороны кандидатов. 👉 Картина по всему миру примерно одинаковая: кандидатов больше, чем вакансий. ▫️HR получают тысячи откликов, а хорошие специалисты неделями не могут дойти даже до первого собеседования. ▫️Экономика плохая, а не AI всех заменил. ▫️ В то же время AI поменял требования к продуктивности. ❗️ Рынок сейчас на стороне работодателя. Но это не значит, что вакансий и офферов нет. Просто правила поиска работы сильно изменились. 👉 Теперь важно не только подходить вакансии, но и откликнуться одним из первых. Пример на реальных событиях: + На вакансию СА пришло 400 откликов за 3 дня. + После автоматического отбора с AI или через поиск "по ключам" в ATS осталось 50 кандидатов. + Посмотрит ли HR все 50 резюме? Нет. Он открывает первые 10. Среди них все сильные кандидаты для интервью. + Они приходят на интервью и один из них забирает оффер. Получается, можно идеально подходить по требованиям, пройти через ATS и всё равно остаться без ответа просто потому, что до вашего резюме не дошли. Сейчас кто первым откликнулся — тот и молодец. И да, кажется, я беру обратно свои слова о том, что ИИ-агенты с автооткликом для поиска работы не нужны 🤷‍♀️ Похоже, нужны, чтобы: ▫️ отслеживать новые вакансии ▫️ проверять их по вашим критериям ▫️ выбирать подходящую версию резюме из 2-3 ▫️ быстро готовить и отправлять отклик При этом не нужно переписывать резюме с нуля под каждую вакансию. Достаточно подготовить 2-3 сильные версии под разные типы позиций и нормально настроить поиск. 👉 Какие площадки сейчас работают? 🔹 Telegram-каналы — это топ для России и СНГ. 🔹 hh.ru — тоже работает, но конкуренция большая. 🔹 LinkedIn — тоже работает для поисков как в России, так и зарубежом, но конкуренция как у hh. 🔹 habr-карьеру не советую. Подробно про рабочие площадки для поиска расскажу в следующем посте. 👉 Будьте готовы к новой воронке Раньше наши студенты могли написать: «Отправил 30 откликов, получил 10 приглашений и 5 офферов». Сейчас 100 откликов могут принести пять собеседований — и это уже отличный результат. Конечно, это не универсальная формула. Но общая тенденция именно такая: откликов требуется больше, ответы приходят реже, а конкуренция на каждом следующем этапе выше. Сейчас действительно нужно быть сильным кандидатом: иметь хорошее резюме, быстро реагировать, готовиться к собеседованиям и разбираться не только в базе, но и в сложных технических темах. И это касается не только начинающих аналитиков. Опытные специалисты проходят через ту же сложную воронку. 👉 Стоит ли сейчас менять работу? Если на текущем месте всё нормально, возможно, сейчас не лучший момент увольняться в пустоту. Можно использовать это время, чтобы развиваться: углубляться в архитектуру, интеграции и работу с ИИ — и выходить на рынок уже более сильным кандидатом. Но если работа вас тормозит, вы давно не развиваетесь или понимаете, что пора уходить, — ищите новую фоном. 👌 Рынок тяжёлый, но результаты есть Мы продолжаем получать от студентов GetAnalyst сообщения о собеседованиях и новых офферах. Сейчас идёт активный осенний период найма. До середины декабря ещё можно успеть пройти собеседования и получить хороший оффер. Поэтому не ждите идеального момента. Обновляйте резюме, настраивайте поиск, подключайте ИИ, следите за новыми вакансиями и откликайтесь быстро. А как сейчас проходит ваш поиск работы? Какие площадки реально дают результат и какая у вас конверсия из откликов в собеседования? Делитесь опытом в комментариях. Думаю, сейчас эта информация будет особенно ценна. #КарьераGA 📱 Tg | 💙 ВК | 💬 Max

❗️ Новый 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 подходит. Для сложного поиска — уже нет. Пример GET ❌ POST с фильтрами в теле запроса. Можно красиво передать фильтр в JSON: POST /products/search { "city": "spb", "priceFrom": 1000, "priceTo": 5000, "categories": ["hotel", "apartment"], "sort": "rating,asc" } Но появляются другие проблемы: ▫️ нецелевое использование: POST - предназначен для создания данных, а не для чтения ▫️ он не идемпотентный: при повторном вызове ожидаются изменения ▫️ его сложнее кэшировать Пример 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

⚡ Если вы уже умеете писать простые SELECT, то следующий шаг, где чаще всего начинается боль — это JOIN. JOIN — это тот самый оператор в SQL, когда многие “вроде понимают”, но в реальной задаче внезапно: 🙁 пропали строки 🙁 появились дубли 🙁 “а почему тут пусто?” 🤖 С ИИ стало проще писать SQL, но не всегда проще понимать, что именно он написал и насколько корректный результат получился. А на технических собеседованиях СА по-прежнему спрашивают про JOIN, связи между таблицами и SQL-запросы. И там уже важно самостоятельно объяснить логику, а не просто получить готовый запрос от ИИ. На практике с JOIN всё решается быстро. Когда один раз руками разберёте логику, отработаете несколько сложных типовых кейсов руками и сохраните лайфхаки для понимания, то всё становится проще. Приглашаем вас на онлайн-практику в следующий понедельник, где будем подробно разбираться с JOIN-ами на реальной БД👇 🔥SQL-запросы с JOIN: на реальной БД через DBeaver 🗓 19 октября, 19:00 Мск План: 1. Виды JOIN и разбор примеров - когда какой нужен 2. Практика JOIN-запросов на реальной БД PostgreSQL: типовые рабочие кейсы 3. Самоконтоль и практика с использованием ИИ 👉 Записаться на практикум Стоимость участия от 1 450 рублей ✅ Запись будет доступна в платформе 🎁 Бонус: занятие в записи "Маппинг данных: БД и JSON" Вопросы? Пишите через сайт или в ЛС @getanalyst 🤝

❌🙅‍♀️🙅‍♂️ Что системному аналитику НЕ нужно уметь в работе с логированием и мониторингом, а что нужно? 🔎 Нужно ли аналитику самостоятельно устанавливать OpenTelemetry Collector, разворачивать Prometheus и администрировать Elasticsearch? Нет. Это задача DevOps и/или разработчиков. Но и требования «логировать запросы и ошибки» или «добавить мониторинг» тоже не результат работы аналитика. 🟢 Задача СА определить: ▫️ какие данные должна формировать система ▫️ как связать события одного сценария ▫️ какие показатели измерять ▫️ как обнаруживать отклонения ▫️ что должны увидеть разработчики, поддержка и бизнес при возникновении проблемы 👉 Что системному аналитику обычно НЕ нужно уметь? ❌ Самостоятельно разворачивать и администрировать весь observability-стек ❌ Настраивать кластеры Prometheus, Elasticsearch, OpenSearch, Loki или Tempo ❌ Устанавливать и конфигурировать агенты, exporters и collectors ❌ Владеть сложными запросами на PromQL, LogQL, TraceQL или KQL ❌ Самостоятельно проектировать инфраструктуру хранения телеметрии и рассчитывать её ресурсы ❌ Настраивать маршрутизацию уведомлений в Alertmanager и других системах на уровне DevOps ❌ Самостоятельно реализовывать весь набор дашбордов и диагностировать ошибки в коде вместо разработчиков ❌ Знать интерфейс каждого инструмента на уровне администратора 💡 При этом «не нужно администрировать» не означает «не нужно открывать инструменты». Аналитику полезно уметь зайти в Grafana, Kibana, Jaeger или OpenShift Console, выбрать нужный период, применить фильтры и найти информацию по конкретной операции. 👉 Что системному аналитику действительно нужно уметь? ✅ Отличать метрики, логи и трассировки. ✅ Понимать назначение инструментов сбора, хранения и анализа телеметрии, которые используются в вашем проекте ✅ Использовать инструменты проекта для поиска и фильтрации логов, метрик и трассировок: выбрать период, сервис и среду, найти данные по конкретной операции. ✅ Проверить путь запроса между компонентами и определить, на каком шаге возникла ошибка или задержка. ✅ Определить обязательные события и поля структурированных логов, чтобы решать 2 предыдущие задачи с ошибками прода без боли. ✅ Описать технические и бизнес-метрики. ✅ Указать точки начала и завершения измеряемых интервалов. ✅ Задать условия алертов: порог, период наблюдения, severity, получателя и ожидаемое действие. ✅ Определить сроки хранения логов, метрик и трассировок. ✅ Предусмотреть маскирование персональных данных, токенов, паролей и других секретов в логах. ✅ Уметь проверить передачу контекста трассировки через HTTP, брокеры сообщений и фоновые задачи. ✅ Определить, какие дашборды и фильтры нужны поддержке, разработчикам и бизнесу. 📌 Недостаточно написать: «Логировать процесс формирования отчёта» Нужно определить: ▫️ события: + задача зарегистрирована + сообщение опубликовано + обработка начата + файл создан + операция завершена успешно или ошибкой ▫️ обязательные поля логов: + время + сервис + среда + operationId, requestId, traceId, messageId + номер попытки + результат + HTTP-код для событий HTTP ▫️ технические метрики: + время ожидания в очереди + длительность обработки + полное время операции + доля ошибок + возраст незавершённых задач ▫️ алерты: + если более 5% операций завершаются ошибкой в течение 10 минут, то отправить уведомление ответственной команде с уровнем High 👉 Что фиксировать в постановке задачи? В разделе «Логирование, мониторинг и аудит» для задачи определить: ☑️ перечень событий, которые должны записываться ☑️ структуру записей и обязательные поля ☑️ правила создания и передачи идентификаторов ☑️ перечень метрик и правила их расчёта ☑️ точки начала и завершения измеряемых интервалов ☑️ требования к распределённой трассировке ☑️ условия срабатывания алертов ☑️ каналы уведомлений и ответственных ☑️ сроки хранения и правила доступа к данным ☑️ требования к маскированию чувствительной информации ☑️ состав дашбордов, графиков и фильтров. Сохраняйте как чек-лист для ваших постановок задач 🤝 #АрхитектураGA #ИнтеграцииGA 📱 Tg | 💙 ВК | 💬 Max

📊🔥 Grafana, Kibana, OpenTelemetry: какие инструменты наблюдаемости нужны системному аналитику? 🔎 «Посмотрите логи» — фраза, которую системный аналитик рано или поздно услышит на любом проекте. Пользователь сообщает об ошибке. Разработчик говорит, что сервис работает. На дашборде всё зелёное. В логах одного компонента запрос принят успешно. Но результат пользователь так и не получил. Чтобы разобраться, недостаточно знать название Kibana или уметь открыть Grafana. Нужно понимать, какие данные собирает система, где они хранятся и как связать одну пользовательскую операцию между несколькими компонентами. 👉 Три вида данных 🔹 Метрики показывают состояние системы в числах: ▫️ количество запросов ▫️ время ответа ▫️ процент ошибок ▫️ размер очереди ▫️ загрузку CPU и памяти ▫️ количество незавершённых бизнес-операций Метрики помогают заметить проблему и оценить её масштаб, но обычно не объясняют, что случилось с конкретным запросом. 🔹 Логи фиксируют отдельные события: ▫️ запрос получен ▫️ валидация не пройдена ▫️ сообщение опубликовано в брокер ▫️ worker начал обработку ▫️ внешний сервис вернул ошибку ▫️ операция завершена По логам можно разбирать конкретный сценарий, если записи структурированы и содержат нужные идентификаторы. 🔹 Трассировки показывают путь запроса через компоненты системы. Одна трасса состоит из отдельных шагов — spans. По ней можно увидеть, какие сервисы участвовали в обработке, сколько времени занял каждый вызов и на каком участке возникла ошибка. 👉 Инструменты мониторинга и логирования для наблюдения за системой: 📌 OpenTelemetry 📌 Prometheus 📌 Grafana 📌 Loki 📌 Tempo или Jaeger 📌 Elasticsearch + Kibana 📌 OpenSearch + OpenSearch Dashboards 📌 OpenShift 👉 Как эти инструменты используются вместе? Допустим, пользователи долго ждут формирования отчёта. 1️⃣ В Grafana видно, что полное время формирования отчётов выросло с двух до восьми минут. 2️⃣ В Prometheus обнаруживаем рост размера очереди и количества операций в статусе PROCESSING. 3️⃣ По operationId находим в Kibana или Loki записи конкретной операции. 4️⃣ По traceId открываем трассировку в Tempo или Jaeger и видим, что обращение worker к БД занимает большую часть времени. 5️⃣ В OpenShift проверяем состояние worker: количество экземпляров, перезапуски, события и потребление ресурсов. Каждый инструмент отвечает на свою часть вопроса. Ни один из них не заменяет остальные полностью. 📌 Полезные подкасты для изучения: 🔗 5 метрик мониторинга, которые решают 80% проблем в статье есть крутая схема С4 с демо архитектуры, где есть OpenTelemetry 🔗 Метрики мониторинга для системного аналитика: RPS, CPU, брокеры, SLO, SLI, SLA и SRE в статье хорошая подборка скринов дашбордов мониторинга из Grafana для реальной системы А подробно про каждый инструмент рассказываю на картинках к посту 🖼🔖 #АрхитектураGA #ИнтеграцииGA

Мы так заняты тем, что ещё не получилось, что забываем радоваться тому, как далеко уже зашли 🥹 В эту поездку в Сан-Франциско меня прямо накрыло этим ощущением. Я наслаждалась каждой секундой и осознавала масштаб. ИИ, конференция, невероятные встречи, новые знакомства, потрясающие люди. Фото с самой конференции пока даже не трогаю 😀 Через общих знакомых из tech-сферы познакомилась с нереально крутой семьёй. Как же здорово встречать людей, с которыми можно часами разговаривать не только о бизнесе, но и просто об этой прекрасной жизни ❤️ И отдельный момент, в который сердце замерло - рабочий день в Salesforce Tower, самом высоком здании Сан-Франциско, с видом на город. Сижу, работаю и думаю: «Ну кто бы мне сказал 5 или 10 лет назад, что я вообще здесь окажусь?!» 😱 👉 Я постоянно настолько погружена в работу, планы и бесконечные новые цели, что вообще забываю оглянуться по сторонам. А ведь если бы мне 5 лет назад показали фотографии из этой поездки, я бы просто не поверила. Поэтому я много останавливалась и говорила себе: «Катя, ну ты посмотри, это же вау!» 🥹✨ И очень хочется, чтобы вы тоже почаще замечали, как много всего классного уже случилось в вашей жизни. Ведь то, что сегодня кажется обычным, ещё 5 лет назад могло быть чем-то совершенно недостижимым! ❤️‍🔥

⚡️ Contract First API в эпоху ИИ-агентов: OpenAPI, AsyncAPI, MCP на практике 🤖 Сначала согласовать контракт API, а потом писать код — в этом суть подхода Contract First. Звучит понятно, пока в команде не возникают вопросы. ▫️ Кто разрабатывает контракт — аналитик или разработчик? ▫️ Что должно быть в OpenAPI-спецификации, а что остаётся в требованиях и документации? ❗️ И зачем системному аналитику разбираться в Git? В этом выпуске разбираем Contract First с точки зрения работы системного аналитика. 🔗 Материалы к эпизоду с видеоуроками по OpenAPI, AsyncAPI, MCP Выпуск актуален для системных и бизнес-аналитиков, которые работают с требованиями к API и интеграциям и хотят разобраться, как меняются эти задачи с появлением ИИ-агентов. 📌 Подкаст доступен на площадках: ⏯ Apple Podcast ⏯ Яндекс.Музыка ⏯ Telegram ⏯ Castbox ⏯ Звук ⏯ Spotify ⏯ Amazon ⏯ RuTube ⏯ YouTube ⏯ VK Video 📚 Видеоуроки к эпизоду 📹 OpenAPI, AsyncAPI и Git для системного аналитика: разбор на демо-проекте ⏯ YouTube ⏯ RuTube ⏯ VK Video 📹 Как работает MCP-сервер: разбираемся на практике с MCP Inspector и Codex ⏯ YouTube ⏯ RuTube ⏯ VK Video 🌱📈 GetAnalyst — техническая база знаний системного аналитика 📱 Tg | 💙 ВК | 💬 Max