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

✍️ 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. Что нужно убрать, чтобы реально её сделать? Вот и весь секрет продуктивности. Не в том, чтобы быть продуктивной каждую минуту. А в том, чтобы каждый день возвращать себя к главному. Хаос всё равно будет. Срочные мелочи тоже. И ночные доработки... Вопрос только в том, кто управляет днём: ты или бесконечный поток задач.

Каждый новый день — новая возможность✔️ Используйте его, чтобы двигаться к целям и мечтам. Никогда не поздно начать что-то новое. Пусть всё получится😊 #GAfrindlyreminder