Avsnitt

  • Что происходит, когда очередь сообщений выглядит пустой, а нода RabbitMQ уже задыхается от гигабайт данных? В этом выпуске разбираем реальную аварию: как массовые рассылки персонализированных писем превратили RabbitMQ в тяжелое хранилище объектов, для которого он архитектурно не предназначен.

    Telegram-канал сообщества: ⁠https://t.me/getanalysts⁠
    VK сообщество: ⁠https://vk.com/getanalyst⁠

    Статья к эпизоду с доп. материалами: ⁠https://getanalyst.ru/podcast/rabbitmq-dmx⁠

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

    Тайм-коды к эпизоду:

    00:00 | Заставка
    00:18 | Введение и знакомство со спикером
    01:36 | Для каких задач выбрали RabbitMQ
    03:12 | Как работают интеграции с внешними системами через брокер
    05:03 | DMX (Delayed Message Exchange) — задача, которая положила RabbitMQ
    07:21 | Где в логах и мониторинге видны признаки падения RabbitMQ
    08:27 | Последствия аварии и объём потерянных сообщений
    11:52 | Что входит в payload сообщения RabbitMQ
    14:00 | Порядок действий после падения RabbitMQ и почему не стоит проталкивать сообщения руками
    16:50 | Инструменты аналитиков для работы с RabbitMQ
    18:25 | Инфраструктура RabbitMQ: ноды
    19:45 | Рекомендации по проектированию взаимодействия с RabbitMQ

    Ведущая:
    ⁠Екатерина Ананьева⁠
    Основатель сообщества Системных Аналитиков GetAnalyst

    Гости:
    Софья Калинина,
    Старший cистемный аналитик, РТК ИТ.

  • Мониторинг — это не только про DevOps.

    Системный аналитик, который не понимает метрики, рискует написать требования, которые невозможно проверить, выполнить или измерить.

    Telegram-канал сообщества: https://t.me/getanalysts
    Статья к эпизоду: https://getanalyst.ru/podcast/monitoring-for-analysts

    В этом выпуске разбираем мониторинг с точки зрения аналитика:
    — что такое метрики мониторинга и откуда они берутся;
    — как метрики связаны с нефункциональными требованиями;
    — как описывать требования при пиковых нагрузках;
    — какие метрики нужны для брокеров сообщений;
    — чем отличаются SLO, SLI и SLA;
    — что такое четыре золотых сигнала SRE от Google: latency, traffic, errors, saturation.

    Отдельно говорим про реальный опыт проекта: как использовались Prometheus, Grafana и Kibana, и почему аналитику важно понимать, что именно команда будет мониторить при проблемах в продакшн.

    Выпуск будет полезен системным и бизнес-аналитикам, которые работают с нефункциональными требованиями, интеграциями, архитектурой, брокерами сообщений, API и вопросами надёжности систем. Заберёте для себя много полезных примеров НФТ.


    Тайм-коды к эпизоду:
    00:00 | Введение
    00:18 | Почему нужно знать про метрики мониторинга системным аналитикам
    01:47 | Что такое метрики мониторинга
    05:03 | Нефункциональные требования, влияющие на мониторинг
    09:15 | Этапы работы аналитика с метриками мониторинга
    12:20 | Ключевые метрики мониторинга и их источники
    14:18 | Детальный разбор каждой метрики мониторинга
    18:59 | Загрузка CPU и требования при пиковых нагрузках
    21:01 | Метрики мониторинга для брокеров сообщений
    23:02 | Метрики SLO, SLI и SLA
    26:21 | Инструменты для мониторинга: опыт реального проекта
    31:44 | Золотые сигналы SRE от Google
    34:10 | Итоги и чек-лист


    Ведущая:
    Екатерина Ананьева
    Основатель сообщества Системных Аналитиков GetAnalyst


    Гости:
    Елизавета Акманова,
    Старший cистемный аналитик, компания UseTech

  • Saknas det avsnitt?

    Klicka här för att uppdatera flödet manuellt.

  • Что такое mTLS и как это работает? Изучайте не в теории, а на практике!

    Сайт эпизода с материалами и ссылками на видео-площадки:
    https://getanalyst.ru/podcast/mtls
    Telegram-канал сообщества:
    https://t.me/getanalysts

    К концу выпуска понятно не только как это настроить mTLS, но и почему он так работает. Отдельно разобрали, как системному аналитику описать требования к mTLS-аутентификации и что могут спросить про TLS/mTLS на собеседовании.

    Выпуск будет полезен тем, кто проектирует интеграции с защищёнными API, пишет требования к API-аутентификации, готовится к собеседованию на Middle/Senior системного аналитика, а также всем, кто хочет разобраться с mTLS один раз — и больше не бояться сертификатов.

    Тайм-коды эпизода:

    00:18 | Введение и знакомство со спикером
    04:37 | Что такое mTLS и как он работает
    05:30 | Практика в Postman по mTLS: подготовка
    07:53 | Создание пространства в аккаунте Sber API
    09:16 | Подключение приложения к пространству в Sber API
    12:45 | Сохранение clientID и clientSecret. Загрузка сертификата
    14:13 | Загрузка корневого и выпускающего сертификатов Минцифры с Госуслуг
    16:29 | Распаковка сертификата Sber API с помощью OpenSSL
    22:13 | Настройка сертификатов в Postman для mTLS
    30:00 | Аутентификация через Postman с клиентским сертификатом: получение access token
    37:33 | Лайфхак по параметризации запросов в Postman
    38:41 | Отправка API-запроса в Postman с полученным токеном
    46:29 | Вопросы с собеседований: что могут спросить системного аналитика про TLS и mTLS
    54:03 | Оформление требований к mTLS-аутентификации
    55:15 | Схема mTLS-аутентификации: разбор алгоритма
    59:01 | Подведение итогов и рекомендации

    Ведущая:
    Екатерина Ананьева,
    Основатель сообщества Системных Аналитиков GetAnalyst.


    Гости:
    Надежда Дудник,
    Главный Инженер по Тестированию, Сбер,
    Автор блога ProTestingInfo в Telegram.

  • Нотация C4 — один из самых мощных инструментов для моделирования архитектуры, но большинство делают диаграммы интуитивно и допускают одни и те же ошибки. В этом выпуске разбираем C4 системно — от теории до живого проектирования.

    За 90 минут проходим все ключевые уровни C4 — Context, Container и Component — и разбираем два реальных проекта. По каждому забираете полный комплект схем C4/Context и C4/Container.

    Страница подкаста: https://getanalyst.ru/podcast/c4model
    Telegram-канал сообщества: https://t.me/getanalysts

    По ходу разбираем типичные ошибки в диаграммах C4, подвохи с нефункциональными требованиями при проектировании архитектуры, сравниваем монолит и микросервисную архитектуру, а также показываем внутренние интеграции микросервисов через Kafka и RabbitMQ.

    Выпуск актуален всем, кто проектирует архитектуру систем, готовится к техническому собеседованию на Middle или Senior, или хочет наконец разобраться с нотацией C4 и начать применять её в своих проектах.

    Тайм-коды эпизода:

    00:18 | Введение
    01:49 | Нотация C4 — что это и когда нужна системному аналитику
    03:40 | Ключевые уровни C4 и их назначение
    06:12 | Инструменты для создания C4: код и визуальные редакторы
    10:25 | Условие задачи на проектирование архитектуры для грейда Senior
    11:48 | C4/Context: ключевые элементы и подключение к draw.io
    15:56 | C4/Context: разбор готового примера
    18:31 | C4/Context: решаем задачу, проектируем роли пользователей и интеграции
    26:46 | C4/Container: ключевые элементы
    31:22 | C4/Container: разбор готового примера для микросервисов с брокером
    36:41 | Откуда аналитику брать технологии для C4/Container
    40:20 | C4/Container: проектируем монолитный Backend
    49:57 | C4/Container: особенности интеграции с платёжной системой
    51:37 | C4/Container: асинхронные уведомления с RabbitMQ и воркером
    56:26 | Микросервисная архитектура: определяем микросервисы для проекта
    01:01:10 | Подвох в задаче: НФТ по нагрузке — критерий уровня Senior
    01:03:08 | C4/Container: проектируем микросервисную архитектуру
    01:09:32 | Интеграция микросервисов через Kafka (хореография): демо на схеме
    01:21:42 | Как кастомизировать C4/Container и не перегружать схему
    01:23:24 | C4/Component: обзор элементов и пример
    01:25:46 | Итоги и рекомендации по нотации C4

    Ведущая:
    Екатерина Ананьева,
    Основатель сообщества Системных Аналитиков GetAnalyst.

  • Большинство системных аналитиков уверены, что знают REST API. Но на техническом собеседовании именно в этой задаче бывает больше всего ошибок.

    Разбираем реальную задачу с собеседования: проектируем REST API метод для системы технической поддержки — от первого вопроса интервьюеру до обработки ошибок.

    Telegram-канал сообщества: https://t.me/getanalysts
    Статья к эпизоду и ссылки на видео: https://getanalyst.ru/podcast/system-analyst-interview-restapi

    Идём по шагам: выбор HTTP-метода, структура URL, query-параметры для фильтров, сортировок и пагинации, заголовки, JSON и коды ошибок.

    После основного разбора — 20+ вопросов с подвохом, на которых аналитики чаще всего ошибаются: текстовый поиск, SQL-инъекции, оптимизация производительности, GET vs POST.

    🔍 Во время записи была допущена маленькая ошибка. Найдёте? Ответ — в статье к эпизоду.

    Эпизод полезен всем, кто готовится к техническому собеседованию на позицию системного аналитика и хочет перестать ошибаться там, где ошибаются все.


    Тайм-коды эпизода:

    00:18 | Введение
    02:22 | Условие задачи с технического собеседования системного аналитика
    03:55 | Какие уточняющие вопросы задать интервьюеру перед проектированием API
    06:02 | HTTP API vs REST API: в чём разница
    07:09 | Проектирование REST API-метода: HTTP-метод и URL
    14:12 | Query-параметры: как проектировать фильтрацию
    22:47 | Query-параметры: как проектировать сортировку в REST API
    25:49 | Query-параметры: как проектировать пагинацию
    26:36 | Headers: какие заголовки нужны в REST API-запросе
    31:46 | Ответ REST API: HTTP-статусы, headers, body и JSON
    38:23 | Проектирование JSON-ответа с нуля
    47:26 | camelCase или snake_case в JSON: что выбрать для REST API
    51:20 | Массивы в JSON: как правильно описывать списки объектов
    53:15 | Пагинация в REST API: как отразить в URL и JSON-ответе
    57:29 | Проектирование ошибок REST API: HTTP 400, HTTP 422 и другие статусы
    01:03:59 | Query-параметры на практике: особенности фильтрации и поиска
    01:05:40 | Вопросы с подвохом: фильтры и текстовый поиск в REST API
    01:08:38 | Вопросы с подвохом: доступ к данным, логирование и дополнительные фильтры
    01:12:17 | Вопросы с подвохом: как работает текстовый поиск
    01:13:04 | Вопросы с подвохом: пагинация, сортировка, SQL-инъекции и таймауты
    01:17:47 | Вопросы с подвохом: оптимизация производительности API
    01:19:49 | Почему GET, а не POST для получения данных. Форматы даты и другие спорные вопросы
    01:23:35 | Проектирование БД через ИИ-агента: связь БД, JSON и индексов
    01:26:47 | Как готовиться к техническому собеседованию системного аналитика

    Ведущая:
    Екатерина Ананьева,
    Основатель сообщества Системных Аналитиков GetAnalyst.

  • SSE API — тема, о которой говорят заметно реже, чем про REST, WebSocket или брокеры. И зря.

    Во многих системах нужен не просто классический запрос-ответ, а доставка данных в интерфейс в реальном времени: статусов, уведомлений, прогресса обработки и других изменений на экране без ручной перезагрузки. Один из подходов для таких сценариев — SSE.

    Сообщество GetAnalyst:
    https://t.me/getanalysts
    https://vk.com/getanalyst

    Сайт эпизода со ссылками:
    https://getanalyst.ru/podcast/sse

    В этом выпуске разбираем, как устроен SSE, где он встречается в реальных проектах, чем отличается от WebSocket, как влияет на архитектуру системы, безопасность и постановку задач в разработку.

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

    Тайм-коды эпизода:
    00:18 | Введение в SSE: как обмен данными в реальном времени связан с информационной безопасностью.
    04:00 | Что такое SSE API и как он работает.
    07:16 | Чем SSE отличается от HTTP с Keep-Alive.
    10:52 | Как выглядит SSE-соединение: инициализация запроса, сообщения в потоке, форматы данных.
    16:47 | Использование SSE API в реальных проектах: примеры.
    21:24 | Архитектурные решения при внедрении SSE: отдельный сервис или часть основной бизнес-логики.
    24:19 | Как сервис с SSE API должен быть связан с API Gateway.
    27:49 | Когда выбирать SSE, а когда WebSocket.
    34:17 | Преимущества и недостатки SSE.
    42:27 | Что системному аналитику учесть в постановке задачи на разработку SSE-метода: разбор шаблона документации.
    47:10 | С чего начать изучение SSE: как практиковаться, в том числе через Postman.

    Ведущая:
    Екатерина Ананьева
    Основатель сообщества Системных Аналитиков GetAnalyst.

    Гости:
    Владимир Бурмистров,
    Главный Системный Аналитик, T1.

  • Разбираем задачу системного аналитика, аналоги которой регулярно встречаются в реальной работе и на технических собеседованиях. Проектируем интеграцию системы ЭДО (электронный документооборот) по API с внешними сервисами DaData и Т-Банка.

    Telegram-канал сообщества: https://t.me/getanalysts
    Материалы к эпизоду: https://getanalyst.ru/podcast/system-analyst-interview-integrations (+ ссылки на видео)

    Идем по шагам: от выбора архитектуры (монолит vs микросервисы) и написания интеграционных Use Case до маппинга данных и проектирования REST API эндпоинтов. На практике смотрим, как читать API-документацию вендора, что выбрать для фоновой синхронизации оплат — Polling или WebHook, как обработать ошибки и сформировать финальные постановки задач команде разработки.

    Максимум практики по системному анализу и проектированию интеграций.

    Тайм-коды к эпизоду:

    00:18 | Введение. Рекомендация к просмотру видео-эпизода.
    01:57 | Постановка задачи: система ЭДО и вводные по интеграции с API DaData и Т-Банком.
    08:39 | Пошаговый план работы аналитика над интеграцией (статья: https://habr.com/ru/articles/735332/).
    10:44 | Проектируем архитектуру: монолитный подход.
    15:58 | Проектируем архитектуру: микросервисный подход.
    22:02 | Технический сценарий работы для кнопки «Заполнить по ИНН» в микросервисной и монолитной архитектурах.
    25:02 | Промежуточные итоги: чекаем шаги интеграции.
    26:43 | Интеграционный Use Case: алгоритм получения реквизитов по ИНН.
    31:43 | Сценарий генерации PDF-счета через внешний сервис и доработка архитектуры.
    36:32 | Фоновая синхронизация оплат с Polling. Разбор API Т-Банка, оптимизация архитектуры и UML-диаграмма.
    45:53 | Фоновая синхронизация оплат с WebHook: анализ API и UML-диаграмма.
    49:45 | Обработка ошибок и проектирование альтернативных сценариев.
    52:08 | Проектирование REST API эндпоинтов и маппинг данных.
    58:58 | Формируем итоговый список задач для Backend, Frontend и БД.
    01:01:55 | Итоги выпуска и практические рекомендации.

    Ведущая:
    Екатерина Ананьева,
    Основатель сообщества Системных Аналитиков GetAnalyst.

  • Всё чаще в разговорах о собеседованиях для системных аналитиков можно услышать про формат System Design Interview, связанный с проектированием архитектуры. Но что именно под ним имеется в виду, как он проводится и какие навыки проверяет?

    Telegram-канал сообщества: https://t.me/getanalysts
    VK сообщество: https://vk.com/getanalyst


    Статья к эпизоду с доп. материалами: https://getanalyst.ru/podcast/system-design-interview

    В этом эпизоде разбираем, что такое System Design Interview для системного аналитика, какие вопросы и задачи могут встретиться на таком собеседовании, какие компетенции оценивают и почему этот формат становится всё более актуальным.

    Эпизод особенно полезен для Middle+ и Senior аналитиков, которые уже работают с интеграциями, сервисами, микросервисной архитектурой или планируют переходить в более сложные продуктовые и технические команды.


    Тайм-коды к эпизоду:

    00:18 | Почему вопросы по архитектуре (System Design) становятся всё более актуальными на собеседованиях для системных аналитиков. Знакомство со спикером.
    04:18 | Что такое System Design Interview и как оно проводится.
    07:00 | Какие компетенции проверяет формат System Design Interview. Для каких грейдов используется.
    16:10 | Наблюдаемость системы: метрики, логирование, мониторинг. Что хотят от аналитика по этой части?
    19:53 | Этапы System Design Interview = этапы проектирования системы.
    24:20 | Почему компании внедряют System Design Interview для системных аналитиков.
    26:29 | Типичные ошибки системных аналитиков на собеседованиях.
    34:19 | Рекомендации по подготовке к System Design Interview. Как прокачивать навыки и где изучать темы.

    Ведущая:
    Екатерина Ананьева
    Основатель сообщества Системных Аналитиков GetAnalyst.

    Гости:
    Софья Калинина,
    Главный cистемный аналитик, РТК ИТ.

  • Если вам кажется, что low-code — это игрушка для маленьких проектов, этот эпизод развеет этот миф. Мы разобрали, как low-code внедряют в крупные корпоративные системы: с полноценной разработкой, процессами, безопасностью и реальными нагрузками — и как системный аналитик с его помощью двигает продукт наравне с разработчиками.

    Telegram-канал сообщества: https://t.me/getanalysts
    Статья к эпизоду: https://getanalyst.ru/podcast/low-code-for-analysts

    Если вы как системный или бизнес-аналитик хотите больше работать с техническими задачами, говорить с разработчиками на одном языке и приносить результат для продукта не только “в требованиях”, а в работающих решениях — этот выпуск для вас.

    Тайм-коды к эпизоду:
    00:18 | Знакомство со спикером. Актуальность Low-Code для системных аналитиков.
    01:37 | Что такое Low-Code? Как его используют в командах с полноценной разработкой.
    04:10 | Где Low-Code реально уместен: масштаб проектов. Виды Low-Code инструментов.
    08:23 | Low-Code в действующем крупном проекте: примеры задач и как аналитик работает с ними.
    21:10 | Задачи системного аналитика в Low-Code инструментах: что делает сам, где подключаются разработчики. Применение JavaScript и Python в работе аналитика. Реальный опыт.
    24:49 | Настройка голосового бота системным аналитиком на Low-Code. Пошаговый разбор задачи.
    32:23 | Безопасность и риски внедрения Low-Code в крупные IT-продукты, что нужно продумать заранее.
    37:32 | Low-Code как навык для резюме аналитика: ценность на рынке, влияние AI и вайб-кодинга. Есть ли смысл изучать?
    43:03 | Подведение итогов и рекомендации для аналитиков по изучению Low-Code.

    Ведущая:
    Екатерина Ананьева,
    Основатель сообщества Системных Аналитиков GetAnalyst.

    Гости:
    Елизавета Акманова,
    Старший cистемный аналитик, компания UseTech.

  • Многие системные аналитики рано или поздно задаются вопросом: а есть ли “системный аналитик” за рубежом — в США и Европе? Чем отличается работа аналитика в зарубежных командах?

    И если вы уже гуглили “Работа системным аналитиком в США” или “Systems analyst в Европе”, то вы могли заметить странную вещь: вакансии есть, но названия, требования и ожидания часто отличаются от того, к чему привыкли в СНГ.

    Сообщество GetAnalyst:
    https://t.me/getanalysts

    Статья к эпизоду с подборкой вакансий:
    https://getanalyst.ru/podcast/systems-analyst-in-the-us-and-europe


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

    🎧 Актуально для системных и бизнес-аналитиков, кто хочет расширить карьерный горизонт: понять, можно ли расти в международных компаниях, и какие конкретные навыки нужны для рынка США и Европы.

    Тайм-коды к эпизоду:

    00:18 | Введение: есть ли системные аналитики за рубежом? рынке США и Европы?

    02:01 | Вакансии Business Analyst - Бизнес-аналитик.
    11:51 | Вакансии Systems Analyst - Системный аналитик.
    14:47 | Вакансии Business Systems Analyst - Аналитик систем для бизнеса.
    20:04 | Вакансии Application Analyst / Application Manager - Аналитик приложений.
    22:09 | Вакансии Technical Product Manager / Technical Program Manager - Технический менеджер IT-продукта.
    24:42 | Другие роли: Analyst, Product Analyst, Requirements Engeneer.

    27:21 | Как часто аналитики встречаются в зарубежных командах разработки - США и Европа.
    32:23 | В каких компаниях системным аналитикам искать работу.
    34:10 | Почему в СНГ роль «Системный аналитик» популярнее, чем за в Европе и США.
    36:01 | Какие навыки должны быть у системного аналитика, чтобы уверенно искать работу на рынке Европы и США? Отличия от стандартной должности.
    42:34 | Принципы ведения документации.
    44:12 | Форматы интервью на аналитика: опыт из США.
    48:06 | Английский для работы аналитиком в США и Европе.
    49:31 | Предметные области: куда идти и где чаще бывают вакансии.
    50:51 | Пошаговая инструкция: как получить оффер в зарубежной компании.
    57:53 | Рекомендации по трудоустройству по всему миру.

    Ведущая:
    Екатерина Ананьева,
    Основатель сообщества Системных Аналитиков GetAnalyst.

  • WebSocket встречается всё чаще. И понимать его хотя бы на базовом уровне уже важно почти всем специалистам, включая системных аналитиков. Особенно если вы работаете (или хотите работать) в продуктовых командах и микросервисной архитектуре.

    Там, где есть чаты, одновременная работа пользователей и любые обновления в реальном времени, WebSocket API появляется очень быстро.

    Сообщество GetAnalyst:
    https://t.me/getanalysts

    Сайт эпизода со ссылками:
    https://getanalyst.ru/podcast/websocket

    В этом эпизоде разберём:
    - как работает WebSocket и чем он отличается от HTTP;
    - как встроить WebSocket в архитектуру и как он сочетается с API Gateway;
    - какие риски важно учесть аналитику: нагрузка, масштабирование и другие нефункциональные требования;
    - и в чём реальные плюсы от WebSocket.

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


    Тайм-коды к эпизоду:
    00:18 | Знакомство со спикером + кейс Dion: где WebSocket нужен в продукте.
    05:03 | Про WebSocket простыми словами: где и когда нужен.
    07:57 | Как работает WebSocket: установка соединения (HTTP Upgrade) и обмен сообщениями. Отличия от HTTP.
    14:37 | Примеры реальных кейсов, где нужен WebSocket.
    20:50 | Архитектура WebSocket: монолит vs отдельный сервис (масштабирование).
    27:10 | Как работают WebSocket и API Gateway в связке.
    30:52 | Преимущества и недостатки WebSocket.
    35:00 | Требования к WebSocket API от системного аналитика: пример ТЗ / постановки задачи.
    38:44 | С чего начинать изучение WebSocket: практические рекомендации.


    Ведущая:
    Екатерина Ананьева,
    Основатель сообщества Системных Аналитиков GetAnalyst.


    Гости:
    Владимир Бурмистров,
    Главный Системный Аналитик, T1.

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

    В такие моменты появляется запрос на ментора — опытного специалиста, который помогает структурировать цели, ответить на вопросы, дать практику, выстроить шаги в развитии, снизить тревогу и двигаться вперёд заметно быстрее.

    Сообщество GetAnalyst:
    https://t.me/getanalysts

    Сайт эпизода со ссылками:
    https://getanalyst.ru/podcast/how-to-find-a-good-mentor

    В этом эпизоде разбираем кто такой ментор, когда он действительно нужен, как проходит работа с ним и чего от неё можно (и нельзя) ожидать. Говорим о том, как выбрать «своего» человека, не слить время и деньги и в итоге получать от менторства конкретный результат, а не просто галочку «я сходил к ментору».

    Тайм-коды к эпизоду:

    00:18 | Почему может быть сложно найти своего ментора. Знакомство с ментором - Екатериной Герасимовой.
    05:43 | Кто такой ментор в IT и когда он действительно нужен.
    12:15 | Рекомендации по стратегии поиска работы системному аналитику. Типичные ошибки при поиске работы, и почему важны не только харды.
    18:46 | С чего начинается работа с ментором: какие вопросы ментор задаёт до встречи и как в идеале строится ход первой встречи.
    25:21 | Как строится процесс работы на занятии в зависимости от вида встреч по менторству.
    38:21 | Критерии выбора и оценки ментора. Какие результаты встречи считать нормальными, а какие — тревожным звоночком.
    53:39 | Сколько стоит 1 час работы с ментором, от чего зависит цена и за что вы на самом деле платите.
    55:33 | Подведение итогов и рекомендации по поиску «своего» ментора.


    Ведущая:
    Екатерина Ананьева,
    Основатель сообщества Системных Аналитиков GetAnalyst.


    Гости:
    Екатерина Герасимова,
    Ведущий системный аналитик, ментор.

  • В этом эпизоде обсуждаем, как AI меняет подход к моделированию бизнес-процессов и работе с BPMN.

    Telegram-канал GetAnalyst: https://t.me/getanalysts
    Сайт эпизода: https://getanalyst.ru/podcast/bpmn-and-ai

    Вместе с топовым экспертом по BPMN в России Денисом Котовым говорим про StormBPMN — инструмент для создания BPMN-диаграмм с поддержкой AI, разбираем, как создавать BPMN через код и в чём нейросети действительно могут помочь.

    Если вам только предстоит изучать BPMN или вы уже давно работаете с нотацией, этот выпуск поможет по-новому взглянуть на моделирование процессов и понять, как использовать AI в работе без лишней магии и разочарований.


    Тайм-коды к эпизоду:
    00:00 | Про актуальность использования AI для разработки BPMN.
    01:02 | Как нейросети «видят» BPMN-диаграммы.
    03:38 | Могут ли нейросети генерировать BPMN-диаграммы через код (XML)?
    04:58 | Как работает StormBPMN, как он интегрирован с AI и какие нейросети используются «под капотом».
    12:50 | Локальное обучение нейросетей для генерации BPMN на хороших примерах XML-кода.
    17:49 | Как начать изучать нотацию BPMN с помощью AI.
    23:56 | История появления инструмента StormBPMN.
    25:23 | Заключение и рекомендации.


    Важные ссылки:
    1) StormBPMN:
    https://stormbpmn.com/
    2) StormVerse - подборка примеров BPMN-диаграмм:
    https://stormbpmn.com/stormverse

    Ведущая:
    Екатерина Ананьева,
    Основатель сообщества Системных Аналитиков GetAnalyst.

    Гости:
    Денис Котов,
    Основатель StormBPMN, перевёл ABPMP CBOK и глоссарий BPMN на русский язык, проектирует процессы в Т-Банк.

  • Если вы рассматриваете Camunda для внедрения на проект и пытаетесь понять, «а оно нам точно надо?», или хотите разобраться как работает оркестрация процессов в микросервисной архитектуре — этот эпизод для вас.

    Telegram-канал сообщества: https://t.me/getanalysts
    Статья к эпизоду: https://getanalyst.ru/podcast/camunda-success-case

    Обсуждаем реальный опыт внедрения Camunda на действующем высоконагруженном проекте со старшим системным аналитиком. Рассказываем, где Camunda реально помогает развивать и поддерживать систему, а где добавляет новые головные боли. Когда стоит выбирать Camunda, а когда лучше пойти другим путём.


    Тайм-коды к эпизоду:
    00:18 | Знакомство с задачей для которой выбрали Camunda.
    03:03 | Почему выбрали Camunda: ключевые функции “из коробки” и альтернативы.
    04:55 | Camunda 7 vs Camunda 8. Проблемы Camunda 8 в условиях реального проекта.
    09:16 | Как Camunda оркестрирует процессы в микросервисной архитектуре: разбор реальных сценариев.
    15:08 | Обработка ошибок работы процессов в Camunda: ретраи, компенсации и что заложить в алгоритмах.
    16:32 | Проблемы Camunda: что реально вызывает боль у команды.
    23:50 | Преимущества внедрения Camunda для команды и бизнеса.
    26:49 | Задачи системного аналитика на проектах с Camunda. Кто отвечает за создание BPMN-диаграмм?
    31:13 | Может ли аналитик сам настроить и запустить бизнес-процесс в Camunda по BPMN-диаграмме - без кода и разработчиков.
    34:38 | Кому подходит Camunda / Кому не подходит Camunda.
    37:22 | Заключение и рекомендации, чтобы начать работать с Camunda в проекте.

    Ведущая:
    Екатерина Ананьева,
    Основатель сообщества Системных Аналитиков GetAnalyst

    Гости:
    Елизавета Акманова,
    Старший cистемный аналитик, компания UseTech

  • Для многих аналитиков и разработчиков нефункциональные требования к системе — тёмный лес. Понятно, что «система должна работать быстро и надёжно», но вот какие именно цифры написать в ТЗ, какие метрики указать и как всё это потом проверять — часто остаётся загадкой.

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

    Сообщество системных аналитиков GetAnalyst: https://t.me/getanalysts⁠⁠

    Материалы к эпизоду: ⁠⁠https://getanalyst.ru/podcast/monitoring⁠⁠

    В этом эпизоде мы разложим по полочкам:

    + что именно нужно мониторить на проекте,

    + какие инструменты обычно настраивают,

    + и главное — какие конкретные метрики и показатели можно и нужно писать в ТЗ.

    После выпуска у вас будет структурированное понимание, какие цифры писать в НФТ и как измерять качество системы, а не просто «надеяться, что всё ок».

    Тайм-коды эпизода:

    01:30 | Мониторинг и диагностика IT-систем: что это такое и зачем нужен системный мониторинг.

    6:25 | Что нужно мониторить в продакшене: ключевые метрики и показатели мониторинга для вашей системы.

    10:00 | Логирование и трассировка запросов: что это, зачем нужны, как работают и как связаны с системным мониторингом.

    11:45 | Конкретные нефункциональные требования к мониторингу: какие цифры по времени отклика писать в спецификации системы.

    14:06 | Как мониторить мобильные приложения.

    16:21 | Нефункциональные требования к нагрузке: какие значения % CPU и ресурсов указывать в требованиях.

    20:10 | Инструменты мониторинга и observability: что выбрать, когда и зачем. Стандарт OpenTelemetry и пример схемы архитектуры.

    27:35 | Реальные кейсы, где мониторинг помогает проектам. Мониторинг кэширования.

    33:04 | Кто на проекте настраивает мониторинг системы и что для этого нужно.

    35:41 | Источники требований к мониторингу: от кого они приходят, в каком виде и как собирать требования к метрикам.

    37:53 | Кто и как следит за показателями мониторинга на проекте: процессы, роли и работа с инцидентами.

    44:37 | Дашборды мониторинга: как понять, что нужен новый дашборд.

    46:27 | Итоги эпизода: рекомендации командам по внедрению мониторинга на разных стадиях проекта и практика «учебных тревог» в IT-проектах.

    Ведущая:
    Екатерина Ананьева, Основатель сообщества системных аналитиков GetAnalyst.

    Гости:
    Никита Улько, Техлид VK Tech.

  • Повсюду «AI, AI, AI»: Generative AI, LLM, Fine-Tuning, RAG — но что это значит для системных и бизнес-аналитиков? Куда бежать, что изучать и с чего начать, если уже сейчас хочется новый виток в карьере в направлении AI?

    В этом выпуске разбираем реальные проекты, задачи и роли в компании red_mad_robot: где место аналитика в Generative AI, какие навыки нужны на старте и как меняется работа команд по сравнению с «обычными» IT-проектами.

    Telegram-канал сообщества: ⁠https://t.me/getanalysts⁠
    Статья к эпизоду: ⁠https://getanalyst.ru/podcast/generative-ai-for-analysts
    red_mad_robot: https://www.redmadrobot.com/⁠
    AI акселератор для БА и СА: ⁠https://getanalyst.ru/education/ai-for-systems-analysts⁠

    Анастасия и Игорь «раскрывают кухню» Generative AI-проектов: RAG vs Fine-Tuning, Small LLMs, метрики качества, безопасность и свой реальный опыт работы. К концу эпизода вы поймёте, с чего начать переход, какие артефакты добавить в портфолио и чего ожидать на собеседованиях.

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

    Тайм-коды:

    00:00 | Введение в Generative AI и машинное обучение. Знакомство с опытом аналитиков в AI-компании.
    7:19 | Что такое Generative AI: короткое погружение и ключевые термины.
    12:49 | Популярные направления внедрения Generative AI: типовые бизнес-задачи и запросы.
    16:24 | RAG и Fine-Tuning: как адаптируют модели под задачи.
    18:37 | Оценка работы AI: качество ответов, замена человека, типичные проблемы.
    25:13 | Какие AI-модели внедряют в мире и РФ, безопасность использования AI.
    30:22 | Small LLMs: что это и как повышают безопасность внедрения.
    35:34 | Навыки для работы с Generative AI: отличия ролей аналитика, разработчика и тестировщика от обычных IT-команд.
    40:01 | Как начать карьеру в Generative AI без опыта и компетенций.
    50:30 | Страхи и барьеры компаний при внедрении Generative AI.
    57:53 | Реальные кейсы и экономика: где Generative AI даёт эффект, а где убытки.
    1:04:09 | Пожелания и рекомендации для бизнеса и IT-специалистов.

    Ведущая:
    ⁠Екатерина Ананьева⁠,
    основатель сообщества системных аналитиков GetAnalyst
    https://t.me/getanalysts

    Гости:
    Анастасия Панфëрова и Игорь Епанешников,
    компания red_mad_robot
    https://www.redmadrobot.com/⁠

  • Надоели бесконечные созвоны и непонятные встречи? Или вы только начинаете карьеру аналитика и хотите разобраться, какие мероприятия вообще есть в Scrum и зачем они нужны?

    TG-канал сообщества системных аналитиков GetAnalyst:
    https://t.me/getanalysts

    Сайт эпизода:
    https://getanalyst.ru/podcast/scrum-meetings

    Практические курсы для СА:
    https://getanalyst.ru/education

    В этом эпизоде мы разбираем все ключевые события Scrum — планирование, дейли, обзоры, ретроспективы и груминг. Делимся своим опытом, ошибками и лучшими практиками, чтобы вы могли увидеть, как это работает в реальных командах и применить полезное в своей работе.

    Подойдёт и новичкам, которые хотят погрузиться в атмосферу IT-разработки, и опытным аналитикам, которые ищут свежий взгляд и инсайты для улучшения своих процессов.

    Связанный эпизод: Всё про Agile, Scrum, Kanban и «Документация не нужна»

    Тайм-коды к эпизоду:

    00:00 | Введение. Зачем системному аналитику понимать мероприятия Scrum и как это помогает в работе с командой.
    01:21 | Основные мероприятия Scrum.
    05:07 | Планирование спринта: кто участвует, сколько длится, лучшие практики. Проблема 40 часов / неделю.
    20:38 | Когда проводить планирование.
    23:53 | Daily Scrum (Stand-up, Дейли): зачем нужны ежедневные митинги, кто участвует, как уложиться в 15 минут. Практики против «болтовни».
    34:10 | Обзор спринта (Sprint Review): что обсуждают, кто участвует и как это помогает команде и бизнесу увидеть реальную ценность работы.
    43:42 | Ретроспектива спринта: зачем нужна, кто участвует, примеры тем для обсуждения.
    57:36 | Методы ретроспектив: от “Mad-Sad-Glad” до “Воздушного шара”.
    1:00:02 | Груминг (Product Backlog Refinement, PBR): зачем нужен, кто участвует, cпособы проведения и подготовка.
    1:17:35 | Scrum-мастер: нужен ли он?
    1:22:45 | Резюме по эпизоду и подведение итогов.

    Ведущая:
    Екатерина Ананьева

    Гости:
    Кристина Виноградова
    Елена Киселева

  • Готовитесь к миграции данных между СУБД, планируете переезд с легаси системы на новую платформу, или запускаете проект по импортозамещению? Этот выпуск для вас!

    Разбираем типовые ошибки связанные с падением продакшн, и показываем, как их избежать. Теперь вы теперь точно не допустите их в своей практике. Слушайте, делайте заметки и делитесь с коллегами.

    Telegram-канал сообщества: ⁠https://t.me/getanalysts⁠
    Рекомендуемый чеклист НФТ: ⁠https://getanalyst.ru/podcast/nft⁠

    Тайм-коды эпизода:

    00:00 | Введение и предыстория: погружение в задачу на импортозамещение высоконагруженной системы.

    04:47 | Что случилось в день X, когда продакшн лёг: когда нефункциональные требования важны.

    08:51 | Разбор технического решения по миграции терабайтов данных.

    13:14 | Первые признаки “падения”: какие инструменты мониторинга показали сбой в системе.

    14:36 | Реакция команды и результаты анализа проблемы.

    18:15 | Погружение в технические детали бага.

    20:56 | Индексы в БД.

    25:55 | Оперативная реакция: что делать, когда миграция БД положила систему и какова в этом роль системного аналитика.

    29:47 | Кто виноват в “падении” продакшн? Проблемы игнорирования нефункциональных требований.

    32:17 | Примеры нефункциональных требований, которые надо было зафиксировать.

    34:42 | Рекомендации для аналитиков, кому предстоит работать с импортозамещением и миграции между СУБД.

    Ведущая:

    ⁠Екатерина Ананьева⁠,
    Основатель сообщества системных аналитиков GetAnalyst

    Гости:

    Елизавета Акманова,
    Старший cистемный аналитик компании UseTech

  • Если вы на пороге смены работы или хотите вырасти до уровня Senior Системного Аналитика — этот выпуск для вас.

    Мы собрали 10 ключевых вопросов с собеседований на позицию Senior Системный Аналитик (Старший Системный Аналитик), разбор ответов на них и полезные ссылки для самостоятельной подготовки.

    Telegram-канал сообщества:
    https://t.me/getanalysts

    Статья к эпизоду с полезными материалами и ссылками:
    https://getanalyst.ru/podcast/top-10-interview-questions-for-senior-analyst

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

    Включайте, чтобы начать свой путь к уровню Senior!


    Тайм-коды эпизода:

    01:00 | Виды архитектуры: монолит, SOA, MSA, EDA.
    07:42 | 8 шаблонов проектирования микросервисов.
    11:44 | Подходы к интеграции сервисов в распределенных системах.
    14:15 | API Gateway: что это, зачем нужен, преимущества и недостатки.
    19:57 | API Gateway как точка отказа в системе.
    22:54 | Оркестрация и хореография микросервисов.
    32:16 | Способы управления высокой нагрузкой для систем.
    34:59 | Проектирование БД: связь “многие-ко-многим”.
    37:53 | Миграция данных без простоя: как реализовать?
    44:44 | Виды интеграции систем.
    51:03 | Брокеры и очереди сообщений. RabbitMQ и Kafka.
    54:41 | Аутентификация и авторизация в API.

    Ведущая:
    Екатерина Ананьева
    Основатель сообщества Системных Аналитиков GetAnalyst

  • Монолиты, микросервисы, и… чистая архитектура. Как они связаны?

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

    Статья к эпизоду: https://getanalyst.ru/podcast/clean-architecture
    Telegram-канал сообщества: https://t.me/getanalysts

    В этом выпуске объясняем простыми словами, как работает чистая архитектура, зачем она нужна и какие принципы лежат в её основе.

    Тайм-коды эпизода:

    00:00 | Знакомство со спикером. Про путь из разработчика в системного архитектора.

    4:49 | Как архитекторы проверяют новые технологии: пишут код сами или делегируют?

    8:15 | Что такое “Читая архитектура” и чем отличается от микросервисной архитектуры.

    10:39 | Как выглядит чистая архитектура в нотации C4 / Component (L3): разбираем слои presentation, domain и data и связи между ними.

    15:45 | Какие слои надо дорабатывать в чистой архитектуре, если решили переехать с REST на gRPC?

    17:22 | Маппинг данных в чистой архитектуре. Разбор Use Case с описанием потока данных между слоями presentation, domain и data (для лучшего понимания смотреть на схему в статье).

    23:42 | Как несколько доменов могут жить внутри одного сервиса: как меняется организация слоёв чистой архитектуры.

    27:49 | Связь чистой архитектуры с монолитами, SOA и микросервисами.

    29:11 | Преимущества и недостатки чистой архитектуры.

    37:00 | Для каких проектов лучше подходит чистая архитектура.

    41:25 | Работа аналитиков на проектах с чистой архитектурой: особенности постановки задач и ведения документации.

    51:32 | Рекомендации по изучению подхода чистой архитектуры.

    Ведущая:
    Екатерина Ананьева,
    Основатель сообщества системных аналитиков GetAnalyst


    Гости:
    Никита Улько,
    Системный Архитектор, UseTech