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

описание

Разбор задач на проектирование систем 🚀 Канал для системных аналитиков, бизнес-аналитиков, тестировщиков и менеджеров проектов Админ @getanalyst Сайт https://getanalyst.ru Чат t.me/getanalystchat Начинающим в IT @getanalyststart

← к каналу @getanalysts

22 311

подписчиков

Охват к подписчикам

12,3%

ERR

Реакции к просмотрам

0,76%

775 на 32 постов

Пересылки к просмотрам

2,58%

2 635

Постов в день

1,0

всего 32

Где отзываются чаще

доля реакций к просмотрам

14 окт. 2024 г.📌 Новый проект по REST API - аренда авто через приложение #RentACar 📌 Этот месяц мы посвятим проектированию REST API методов. По итогам голосования самый большой запрос оказался на разбор связи между REST API и БД. Но этот вопрос гораздо шире. Поэтому мы также затронем его связь с бизнес-процессами, UI/UX и оптимизацией приложений. Проект, на котором мы будем погружаться в тему - аренда автомобилей через приложение #RentACar. 👉 О проекте 👉 ✔️ Приложения и пользователи: + мобильные и веб-приложения для клиентов. + веб-приложение для сотрудников и администраторов. ✔️ Бизнес-процесс: 1. Клиент выбирает даты аренды, место получения и выдачи, и ищет варианты. 1.1. Результаты можно фильтровать по классу и марке автомобиля, по цене. 1.2. Результаты можно сортировать по цене (возрастание / убывание). 2. Клиент заказывает машину через приложение и сразу вносит оплату онлайн. 2.1. Машина становится недоступна для бронирования на эти даты. 3. Клиент забирает машину из места аренды. 3.1. Сотрудник собирает персональные данные водителей - права + паспорта. Вводит вручную и загружает сканы документов; 3.2. Сотрудник подтверждает выдачу автомобиля. 4. Клиент возвращает машину в место аренды. 4.1. Сотрудник подтверждает возврат автомобиля. ✔️ Дополнительно о бизнесе и разработке: + есть офисы в разных городах (места, где можно взять и вернуть машину); + машину можно взять в одном офисе, а вернуть в другом; + стоимость авто зависит от дня недели и места возврата - учитывать это при настройке цен; + к заказам можно продавать страховки, но пока это будет вне системы; + клиенты могут повреждать авто, но пока это будет учитываться вне системы. 👉 В рамках работы над REST API 👉 ✅ Проектируем БД и анализируем как она влияет на методы REST API ✅ Делаем с нуля методы POST, GET, PUT, PATCH, DELETE ✅ Ставим задачи на разработчиков ✅ Смотрим, как вести документацию в Postman и Swagger Подписаны на канал? Значит вы участвуете в проекте и получаете ваш новый опыт 🤝 Проект объявляется открытым 🎉 #RestApiGA2,43%
3 авг.📚🤖 AI-ассистент для подготовки к собеседованию по REST API (и не только) 📚🤖 Вопросы и задачи с собеседований — это всегда отличный способ размяться перед реальным интервью и вспомнить то, что давно не использовали в работе. Прикрепила к посту два файла: 1. Только вопросы - файл "Задания REST API" 2. Эти же вопросы, но с ответами - файл "Задания + ответы REST API" 🤖 Инструкция по подготовке к интервью с помощью AI: 👉 1. Скачайте pdf-файл с ответами из этого поста (второй по порядку). 👉 2. Откройте любой из предложенных ИИ и войдите в аккаунт, используя свою учетную запись Google. https://chatgpt.com/ - лучше платный, бесплатный в последнее время ведёт себя плохо https://claude.ai/ - можно бесплатно, но есть лимиты https://gemini.google.com/ - можно бесплатно, но есть лимиты, которые не сильно портят качество https://qwen.ai/ - полностью бесплатный, но хуже память (контекстное окно), может забыть о чем говорили и суть документов через 15-20 сообщений https://chat.deepseek.com/ - полностью бесплатный, но память еще хуже чем у qwen, слабее qwen 👉 3. Откройте новый диалог (New Chat в левом меню). 👉 4.1. Загрузите файл. В зоне ввода текста есть иконка "+" или "скрепка". Нажмите на неё и появится иконка скрепки с надписью "Добавить файл" (Add photos & files"). 👉 4.2. Вставьте промпт: Представь, что ты ведущий системный аналитик с опытом более 10 лет в IT. Ты хочешь нанять senior системного аналитика к себе в команду и я пришёл к тебе на техническое собеседование. Ты строгий и занудный, требуешь четких ответов с примерами. Используй файл, который я добавил, и на его основе задавай мне по одному случайному вопросу. Чередуй вопросы по теории и практические задания, задачи, как на реальных проектах. Старайся идти глубже и давать связанные вопросы с подвохами. Вопросы также можно задавать в других формулировках по сравнению с документом. После того, как я отвечу, давай оценку моим ответам по 10-бальной шкале по критериям: точность ответа, понимание вопроса. Поясняй каждый балл и предлагай как можно было бы улучшить мой ответ. Каждый раз, когда я буду писать "следующий вопрос", ты можешь задавать мне следующий вопрос из моего документа или придумывать аналогичные, с подобными задачами. Сразу после этого сообщения можешь задать мне первый вопрос. 👉 5. Ваше собеседование началось. Отвечайте на вопросы. ❗️ Не печатайте текст на теоретические вопросы, а говорите ответы голосом, где возможно! Используйте иконку "микрофон", чтобы записывать свои ответы и отдавать их на проверку Искусственному Интеллекту. Получайте обратную связь от ИИ и улучшайтесь 😌 + В помощь на собеседования: JSON Editor Online ✅ Открытая база вопросов и заданий с собеседований на СА Больше вопросов и ответов по другим темам, чтобы проверить себя и подготовиться к успешному техническому интервью 🔗 База вопросов для СА Скачиваете в виде PDF-страницы и прикладываете в ИИ. Либо даёте ссылку на неё в промпте из п.4.2 и готовитесь к собеседованию не только по REST, но и по другим темам. Сохраняйте и пользуйтесь. Сейчас или в будущем 🤝 🔥 и 🩷 приветствуются)) #RestApiGA #AI_for_analysts2,30%
11:49✅📌 Какой тип данных выбрать для id (PK) в БД — bigint или UUID? 📌✅ Вопрос про integer / bigint или UUID всегда был. Оба подхода встречаются на практике. Годами integer / bigint часто выбирали для PK (Primary Key) ради производительности. А UUIDv4 выбирали, когда важна уникальность id на огромных объемах данных. Но с UUIDv7 старое правило стоит пересмотреть 👇 👉 Почему integer был быстрее Дело было в индексации. Индекс — это как алфавитный указатель в книге: чтобы найти нужную запись, БД не перебирает миллион строк подряд, а использует отдельную упорядоченную структуру дерева. ▫️ Если id (PK) генерируется последовательно: 1 → 2 → 3 → 4 → ... новые значения обычно попадают в правую часть B-tree индекса — дерева, в котором значения хранятся в отсортированном виде и разбиваются по диапазонам между узлами. Поэтому БД в основном работает с одной и той же крайней областью индекса, а не вставляет записи в случайные места по всему дереву. Такие вставки предсказуемы и хорошо сохраняют локальность данных. ▫️ А теперь UUIDv4: a3f8b2c1-91c2-4b7e-8f3a-6d2e9c1b7a4f Он генерируется случайно. Ни алфавитного, ни цифрового порядка. Следующий UUID может попасть в совершенно другую часть диапазона индекса. В результате вставки затрагивают разные страницы B-tree, хуже используют кэш и могут чаще приводить к разрыву страниц. На больших таблицах и при интенсивной записи данных в БД это уже имеет значение. Поэтому UUID обычно особенно полезен там, где идентификатор нужно генерировать независимо: ✔️ делать гарантированно уникальным ✔️ в нескольких микросервисах ✔️ на разных узлах ✔️ на клиенте ✔️ без общей последовательности в одной БД 👉 Что изменилось Почти год назад PostgreSQL 18 добавил встроенную функцию: uuidv7() UUIDv7 — уже не случайный UUIDv4. В его старших битах хранится время генерации. Поэтому значения получаются упорядоченными примерно по времени создания и новые UUID чаще оказываются рядом друг с другом в индексе B-tree. 👉 То есть один из главных недостатков UUIDv4 — хаотичные вставки по всему индексу — существенно уменьшается с приходом UUIDv7. Так что теперь UUIDv7 можно гораздо смелее рассматривать как PK для новых таблиц, особенно в распределённых системах с сервисами и микросервисами. Но это не значит, что bigint больше не нужен. 📌 При выборе типа данных для id (PK) всё ещё надо учитывать минимум 3 вещи: 1️⃣ Размер integer — 4 байта bigint — 8 байт uuid — 16 байт И дело не только в самой таблице. PK потом становится FK в других таблицах, попадает в индексы — и объем данных начинает множиться. 2️⃣ Способ генерации ID Если у нас одна БД и централизованная генерация идентификаторов в одной БД — bigint может быть отличным вариантом. Если ID должны независимо создавать несколько микросервисов — UUID становится намного удобнее. 3️⃣ Приватность UUIDv7 «помнит» время. Если такой ID передаётся наружу: /orders/{uuid} /users/{uuid} /payments/{uuid} из него можно определить примерное время создания объекта. Для некоторых систем это нежелательная утечка метаданных. 💡 Поэтому UUIDv7 не делает bigint устаревшим. Но убирает один из главных аргументов против UUID — хаотичные вставки UUIDv4 в B-tree. А что сейчас используете в своих проектах для PK: bigint, UUIDv4 или уже UUIDv7? 👇 #БД_и_SQL_GA 📱 Tg | 💙 ВК | 💬 Max2,00%
13 авг.🔴 Почему откликаться на 200 вакансий с помощью ИИ хуже, чем на 20 вручную 🔴 Сейчас поиск работы уже можно автоматизировать почти полностью. Можно настроить ИИ-агента в Claude / ChatGPT, который будет: → искать вакансии → сравнивать их с вашим опытом → оценивать соответствие → находить пробелы → адаптировать резюме → готовить сопроводительные письма → и даже отправлять отклики Звучит идеально. ❗️ Но бездумно автоматизировать отправку откликов я настоятельно НЕ рекомендую. 1️⃣ Высокий % совпадения ещё не значит, что вакансия вам подходит В ИИ можно хорошо настроить критерии совпадения для вашего резюме + вакансии: • должность • уровень • зарплата • формат работы • технологии • обязательные требования Но вакансии редко описаны настолько формально. Например, у системного аналитика совпали REST API, SQL, UML, интеграции и нужный уровень опыта. ИИ оценил вакансию на 85% соответствия. Но среди требований есть: «нужен опыт в банковских платежах от 2 лет». У вас его нет. Для человека это может быть причиной не откликаться. Для ИИ — просто одно несовпадение из десяти. Да, критичные требования тоже можно заложить в правила агента. Но определить их автоматически получается не всегда. 2️⃣ Массовая адаптация резюме может навредить Под одну вакансию ИИ сильнее подчеркнул Kafka. Под другую — микросервисы. Под третью — архитектуру. И вот в одной компании уже лежат несколько версий вашего резюме с разными акцентами и формулировками. Нерелевантные отклики могут закончиться отказами ещё на этапе просмотра резюме. 👉 В результате вы просто создаёте себе историю неудачных откликов внутри конкретной компании. 3️⃣ «Теневой бан» Я бы не говорила, что после 50 откликов hh.ru автоматически отправляет кандидата в какой-то общий чёрный список. Так это не работает. Но у конкретной компании почти всегда хранится история: ▫️ предыдущих откликов ▫️ версий резюме ▫️ отказов ▫️ этапов собеседований ▫️ комментариев рекрутеров Плюс на рынке есть дружественные IT-компании, которые обмениваются базами кандидатов. И если ИИ отправил ваше резюме на 10 неподходящих вакансий одного банка, а потом появилась действительно ваша вакансия — вы уже не новый кандидат. Поэтому проблема скорее не в «теневом бане», а в том, что можно испортить историю кандидата внутри конкретной компании. 4️⃣ ИИ может ошибиться уже при самом отклике В вакансии при отклике могут спросить: ▫️ сколько лет у вас опыта с платежами? ▫️ готовы ли вы работать из офиса? ▫️ когда можете выйти? ▫️ какая зарплата вас устроит? ИИ может ответить «оптимально под вакансию», а не так, как ответили бы вы. И тогда отказ можно получить ещё на уровне ATS, до того, как резюме нормально посмотрит человек. 👉🟢 Тогда как использовать ИИ правильно? Я бы автоматизировала не количество откликов, а качество отбора: ИИ-агент: 🔎 находит вакансии -> 🎯 оценивает соответствие -> 🚩 отсеивает неподходящие -> 📊 подсвечивает пробелы -> 📝 помогает адаптировать резюме без выдумывания опыта (либо выбрать из 1-3 готовых, что лучше) -> 📝 пишет сопроводительное письмо Вы, как кандидат: 👀 проверяете вакансию -> ✔️ выбираете одну из своих версий резюме -> 👀 проверяете сопроводительное -> 📩 отправляете отклик. То есть: ❌ ИИ → 200 автоматических откликов ✅ ИИ → 200 вакансий → 20 подходящих → 20 качественных откликов с 1–3 базовыми версиями резюме Такой подход намного разумнее. ИИ должен экономить время на поиске работы, а не помогать быстрее испортить собственную историю кандидата. Актуально видео по настройке такого агента? Ставьте 🔥 📱 GetAnalyst | 💙 VK | 💬 Max #AI_for_analysts1,55%
21 окт. 2024 г.⚡️ Как строится URL для REST API методов - разбор примеров для #RentACar ⚡️ Разбираем на примере методов: 👉 POST /car 👉 GET /car 👉 GET /car/{carId} Подробности в картинках к посту. 0️⃣ Метод HTTP Не относится к URL, но тесно связан с ним. Описывала правила выбора в этом посте. 1️⃣ Протокол В начале любого URL указывается протокол HTTP(s), который обеспечивает передачу данных. 2️⃣ Доменное имя Основной адрес, по которому можно обращаться к серверу. 3️⃣ Путь (Path) Путь включает в себя один или несколько сегментов, разделённых слешами (/). ▫️“api” - указатель на каталог API сервера, может быть название вида api. Это необязательный сегмент, может отсутствовать в URL. ▫️имя api - указывает на конкретный интерфейс API, предназначенный для разных пользователей системы. ▫️v1 - версия API, важна для поддержки совместимости с предыдущими версиями. ▫️car - это ресурс, к которому осуществляется доступ. В данном случае “машина”. Может быть во множественном числе (cars). ▫️{carId} - это параметр в пути URL (path-параметр), указывающий на конкретный авто по его id в БД системы. Фигурные скобки {} обозначают переменную часть URL, значение которой должно быть предоставлено клиентом (например, идентификатор 12345). 4️⃣ Query-параметры (Query-parameters) Дополнительные параметры запроса после ?, необязательны. Если их несколько, то перечисление через символ &. Обычно используются для фильтров, сортировок и пагинации при получении списков методом GET, но могут быть и в других API-методах. В примере: GET …/car?offset=0&limit=10&dateFrom=2024-10-10&dateTo=2024-10-15 👉 ?offset=0&limit=10 указывает на запрос результатов с 0-го, ограниченный 10-ю результатами на страницу. Это два отдельных query-параметра, которые являются элементами пагинации (постраничного получения данных через API). 👉 &dateFrom=2024-10-10&dateTo=2024-10-15 - фильтр на период аренды, даты “с” и “по”. Это основные элементы URL в REST API, которые помогают точно определить, к какому ресурсу (сущности) должен быть осуществлен доступ 💾 #RestApiGA1,51%
5 авг.🔥 QUERY vs POST: 2 примера постановки задачи на поиск с десятками фильтров 🔥 Что делать, если параметров фильтрации и сортировки слишком много для передачи в URL? Раньше для таких сценариев часто использовали: POST /products/search Фильтры, сортировку и пагинацию передавали JSON-объектом в теле запроса. Теперь появился отдельный HTTP-метод для безопасного и идемпотентного поиска с телом запроса, вместо "костыля" с POST: QUERY /products 🔵 К посту прикрепляю две полноценные постановки задачи - выгрузки из Confluence: 1️⃣ Поиск товаров через POST /products/search — вариант, подготовленный до появления QUERY. 2️⃣ Поиск товаров через QUERY /products — обновлённый пример с новым HTTP-методом (в этом документе также можно посмотреть, как супер-подробно описать требования к кэшированию результатов поиска). 💾 Скачивайте оба файла и сравнивайте: ✔️ как изменился endpoint ✔️ как передаются фильтры ✔️ как описывается контракт метода ✔️ какие требования важно зафиксировать для Backend Когда на проекте появится поиск с десятками фильтров, у вас уже будет готовый образец постановки задачи — и для привычного POST, и для нового QUERY. 🔖 Обязательно сохраняйте этот новый образец требований по REST API в личный архив и поддержите пост ❤️🔥, если это то, что вам актуально #RestApiGA #FarmFreshGA 📱 Tg | 💙 ВК | 💬 Max1,49%
6 авг.🤖🔖 Бесплатный AI-скилл от GetAnalyst для постановки задач на REST API + шаблон требований 🔖🤖 Пока кто-то продаёт AI-скиллы для аналитиков, я отдаю свои бесплатно 🙌 Сегодня делюсь скиллом (навыком) по проектированию REST API. Скилл превращает бизнес-сценарий, Use Case, макет или несколько строк про вашу задачу в полноценную постановку задачи на один REST API-метод. 👉 Что он делает: ✔️ задаёт уточняющие вопросы, если данных недостаточно ✔️ проектирует URI, параметры, headers и JSON ✔️ описывает валидации, ответы и ошибки ✔️ формирует пошаговый алгоритм Backend ✔️ добавляет маппинг с БД ✔️ учитывает кэширование, НФТ, логирование и мониторинг ➕ спорные решения и допущения выносит перед постановкой, не засоряя сам документ комментариями 📝 Самый актуальный и полный шаблон требований GetAnalyst и куча обучающих примеров были использованы при создании скилла. Примеры постановок задач по этому шаблону показывала в этом посте. 👉 К посту прикрепляю: 🤖 скилл для Claude / OpenAI 📝 PDF-шаблон постановки задачи на REST API метод 🔗 Инструкция по установке и использованию скилла в ChatGPT Plus и Claude 👉 Также скилл можно использовать в: + Gemini CLI — именно CLI, не обычный Gemini в браузере + GitHub Copilot (например, в VS Code) + Cursor + и других инструментах. Скачивайте, устанавливайте и используйте бесплатно ❤️‍🔥 #AI_for_analysts #RestApiGA 📱 Tg | 💙 ВК | 💬 Max1,36%
7 авг.🧐 URI vs URL: кажется, что это одно и то же. Но в чём разница? 🧐 URI и URL мы встречаем постоянно: ▫️ в адресной строке браузера ▫️ в документации к API ▫️ в постановках задач API: Base URL, URI, endpoint На первый взгляд, всё это одно и то же: просто «ссылка», «эндпоинт» или «адрес метода». 👉 Да, URI и URL часто используют как взаимозаменяемые понятия. Но технически это не одно и то же. Коротко: 🌟 URL — это один из видов URI. 🌟 Каждый URL является URI, но не каждый URI является URL. А ещё существует URN. Разберёмся на простых примерах 👇 1️⃣ URI — идентификатор ресурса Uniform Resource Identifier Это общее понятие: строка, которая идентифицирует какой-либо ресурс. Примеры URI: + https://api.example.com/v1/products/42 + mailto:user@example.com + urn:isbn:9783161484100 👉 Все три записи идентифицируют ресурсы, но делают это по-разному. 2️⃣ URL — адрес ресурса Uniform Resource Locator Он не только идентифицирует ресурс, но и показывает, где он находится и как к нему обратиться. Например: https://api.example.com/v1/products/42 По этому адресу клиент может отправить HTTP-запрос и получить данные о товаре. https://getanalyst.ru/about Это URL, который вы вводите в браузере, чтобы перейти на страницу "О нас" на веб-сайте с доменом "getanalyst.ru". Здесь: ▫️ https — схема обращения ▫️ api.example.com и getanalyst.ru — домены ▫️ /v1/products/42 и /about— пути к ресурсам 👉 Поэтому данные строки являются одновременно: ✅ URI — потому что идентифицирует ресурс ✅ URL — потому что указывает его адрес и способ обращения 3️⃣ URN — имя ресурса Uniform Resource Name Он идентифицирует ресурс по устойчивому имени, но не указывает, где этот ресурс находится. Например: urn:isbn:9783161484100 urn:issn:2049-3630 Это уникальные идентификаторы книги. Книга может продаваться в разных магазинах и храниться в разных библиотеках, но её ISBN/ISSN от этого не изменится. URN может идентифицировать не только книгу. Например, <urn:uuid:...> задаёт устойчивый идентификатор объекта. При этом URN не сообщает, на каком сервере находится объект и как его получить. 👉 Итого по URN: ✅ является URI ❌ не является URL: сам по себе не указывает сетевой адрес ресурса и способ его получения Главное, что нужно запомнить: ✅ URI — общее понятие: идентификатор ресурса ✅ URL — URI, который показывает адрес ресурса и способ обращения ✅ URN — URI, который задаёт устойчивое имя ресурса, но не указывает адрес В REST API мы преимущественно работаем с HTTP(S) URL. А слово endpoint обычно используют для обозначения точки обращения к API: сочетания HTTP-метода (GET/POST/PUT...) и адреса ресурса. Теперь, увидев в постановке задачи Base URL, URI и endpoint, вы точно знаете, почему это не три названия одного и того же 😉 ——- P.S. А к чему относится "mailto:user@example.com"? ——- #AI_for_analysts #RestApiGA 📱 Tg | 💙 ВК | 💬 Max1,20%
18 окт. 2024 г.✅ REST API - пошаговый план проектирования методов с нуля + пример ✅ Для проектирования REST API методов рекомендуется использовать пошаговый подход: 0. Выбор сущности — определите, для какой сущности разрабатывается API-метод. 1. Анализ потребностей клиента — выясните, какие данные и функциональность требуются на всех экранах, связанных с сущностью. Это поможет создать универсальный JSON-объект (body), который можно использовать для всех операций CRUD-модели. 2. Сопоставление с БД — проверьте, какие данные уже есть в базе данных, и какие необходимо добавить для реализации метода. 3*. Доработка БД — добавьте недостающие таблицы и поля, если это необходимо. 4*. Требования к интеграции — если данные должны поступать из внешней системы или отправляться в неё, учтите это в разработке. 5. Определение доступа — задайте роли пользователей, которым будет доступен API-метод. 6. Алгоритм работы (Use Case) — опишите логику работы метода, включая все возможные ошибки. 7. Проектирование запроса REST API — определите метод (GET, POST и т.д.), URL, заголовки (headers) и тело (body) запроса. 8. Проектирование успешного ответа — укажите HTTP-статус, заголовки и тело ответа. 9. Проектирование ошибок — опишите неуспешные ответы: HTTP-статус, заголовки и тело для каждой ошибки. * - необязательные пункты, зависят от задачи. Самые первые и важные шаги - понять потребности клиента и оценить полноту данных в БД. Потому что именно на их основе мы проектируем JSON-структуры данных. Подготовила для вас мини-книгу с примером применения этой пошаговой инструкции для проекта #RentACar 🙌 Книга прикреплена к посту. #RestApiGA1,16%
11 авг.✅ 5 пунктов, которые постоянно теряют в ТЗ на API ✅ URL, HTTP-метод, параметры запроса и JSON обычно описаны. А вот следующие 5 вещей встречаются гораздо реже, хотя именно про них потом начинаются вопросы у разработчиков и проблемы в проде 👇 1️⃣ Кэширование Если данные можно кэшировать — это должно быть описано в требованиях. Чаще всего — для операций получения данных (GET). ▫️ Что кэшируем? ▫️ Где: Backend, Redis, другое хранилище? ▫️ Какой TTL (время жизни)? ▫️ Что входит в ключ кэша? ▫️ Когда и кем кэш инвалидируется? Написать просто «результат кэшировать на 10 минут» часто недостаточно. 2️⃣ Идемпотентность Что произойдёт, если один и тот же запрос придёт дважды? Особенно критично для создания заказов, платежей, бронирований и других изменяющих операций. ▫️ Выполним операцию повторно? ▫️ Вернём результат первого запроса? ▫️ Как определим, что запрос повторный? Пользователь нажал кнопку два раза — система должна знать, что с этим делать. 3️⃣ Единый формат ошибок от API Не так, что один метод возвращает: {"error": "Not found"} другой: {"message": "Something went wrong"} а третий свою структуру. Для API должна быть определена единая модель возврата ошибок: ✅ единая структура JSON-ошибки ✅ правила использования HTTP-статусов Иначе каждый новый метод постепенно начинает жить своей жизнью. 4️⃣ Что делать, если операция выполнилась только частично Например: Backend сохранил данные в БД → вызвал внешнюю систему → внешний вызов завершился ошибкой. Или: внешняя система выполнила операцию → а сохранить результат в нашей БД не получилось. ▫️ Что откатываем? ▫️ Что повторяем? ▫️ Нужна ли компенсационная операция? ▫️ В каком состоянии оставляем данные? Особенно важно в интеграционных сценариях, где один пользовательский запрос запускает несколько операций. 5️⃣ Логирование и мониторинг Пользователь пишет: «Вчера в 15:42 я оплатил заказ, но статус не изменился». Что дальше? ▫️ Есть ли requestId / correlationId? ▫️ Передаётся ли он между сервисами? ▫️ Что пишем в логи? ▫️ Какие технические и бизнес-метрики собираем? ▫️ На какие ошибки должны срабатывать алерты? Требования к логированию и мониторингу — такая же часть постановки задачи, как JSON запроса и ответа. Ни один из этих пунктов технически не выглядит чем-то сверхсложным. Но именно их легко пропустить, а потом выяснять, как должна вести себя система, уже вместе с разработчиками. Иногда в проде 🥲 #RestApiGA 📱 GetAnalyst | 💙 VK | 💬 Max1,12%
14 авг.🧠 Как создать AI Skill с нуля в ChatGPT и Claude: гайд для системного аналитика 🤖🛠 Промпт за промптом, а ИИ всё равно каждый раз выдаёт разный результат, и приходится заново объяснять, что нужно и в каком формате. AI Skills, или просто «скиллы», помогают решить эту проблему. Это готовый набор инструкций, знаний, шаблонов и правил, который можно использовать повторно без долгих объяснений в каждом новом чате. 🔗 Материалы к эпизоду Разбираемся, что такое AI Skills, чем они отличаются от обычных промптов и проектов в ИИ, и на практике с нуля создаём скилл для постановки задач на интеграции. Видео: ⏯ YouTube ⏯ RuTube ⏯ VK Video ⏯ Telegram Аудио: ⏯ Apple Podcast ⏯ Яндекс.Музыка ⏯ Castbox ⏯ Звук ⏯ Spotify GetAnalyst — системный анализ на практике ❤️‍🔥 📱 Tg | 💙 ВК | 💬 Max0,97%
9 авг.😰 От Junior в 7 раз чаще требуют навыков Middle и Senior... Это не моё ощущение. Это результат исследования PwC — одной из крупнейших консалтинговых компаний в мире. В 2026 они разобрали больше 1 млрд вакансий и подтвердили этот факт на 2,4 млн junior-вакансий в США. ❗️При этом ИИ не отменяет Junior-позиции. Но поднимает планку входа в профессию и требования к грейдам в целом. Причина логичная. ИИ всё лучше делает то, на чём раньше учились начинающие: ▫️ собрать первый черновик документа ▫️ структурировать требования ▫️ написать SQL ▫️ разобрать API ▫️ построить диаграмму ▫️ найти варианты решения 👉 Ценность специалиста смещается от «умею сделать» к «понимаю, ЧТО нужно сделать, могу проверить результат и принять решение» Для аналитика попросить ИИ спроектировать REST API или написать Use Case недостаточно. Нужно самому уметь ответить: ✅ какие сценарии он пропустил ✅ корректно ли спроектирован контракт API ✅ что будет при ошибках ✅ где нарушена бизнес-логика ✅ подходит ли решение вашей архитектуре Если не можешь это проверить — ты не контролируешь результат, а угадываешь вместе с ИИ 🤷‍♀️ LinkedIn фиксирует тот же сдвиг с другой стороны. Растут требования: 1️⃣ к владению AI-навыками, 2️⃣ к мягким навыкам (софт-скиллам) — работа со стейкхолдерами, коммуникация, лидерство. Я же продолжаю повторять: 👉 ИИ не заменит аналитика. Но аналитик с ИИ будет всё сильнее выигрывать у аналитика без него. 👉 А фундаментальные знания — не менее, а более важны. Ведь теперь надо понимать, где накосячил ИИ. Потому что его ответы всегда красивы, но далеко не всегда верны. 📚 Источники: PwC — Global AI Jobs Barometer 2026 LinkedIn — Skills on the Rise 2026 А вы уже видите это на собеседованиях или в требованиях к джунам? Делитесь опытом в комментариях👇 #AI_for_analysts 📱 Tg | 💙 ВК | 💬 Max0,95%