ПРО АНАЛИТИКА | СИСТЕМНЫЙ АНАЛИТИК | АЛЕКСАНДР НЕЗДЕМИНА
رفتن به کانال در Telegram
Здесь бизнес и системные аналитики превращаются в уверенных профи, которые спокойно проходят собесы и работают в 🔝 компаниях🔥 В канале больше пользы, чем на курсах крупных школ🤌🏻 Отзывы @proanalitica_feedback По всем вопросам @proanalitika_manager
نمایش بیشتر6 019
مشترکین
اطلاعاتی وجود ندارد24 ساعت
-187 روز
-3530 روز
در حال بارگیری داده...
کانالهای مشابه
ابر برچسبها
اشارات ورودی و خروجی
---
---
---
---
---
---
جذب مشترکین
سپتامبر '26
سپتامبر '26
+15
در 1 کانالها
اوت '26
+44
در 0 کانالها
Get PRO
ژوئیه '26
+46
در 0 کانالها
Get PRO
ژوئن '26
+74
در 0 کانالها
Get PRO
مه '26
+58
در 0 کانالها
Get PRO
آوریل '26
+72
در 0 کانالها
Get PRO
مارس '26
+70
در 0 کانالها
Get PRO
فوریه '26
+58
در 0 کانالها
Get PRO
ژانویه '26
+632
در 9 کانالها
Get PRO
دسامبر '25
+52
در 0 کانالها
Get PRO
نوامبر '25
+251
در 1 کانالها
Get PRO
اکتبر '25
+356
در 5 کانالها
Get PRO
سپتامبر '25
+154
در 0 کانالها
Get PRO
اوت '25
+222
در 1 کانالها
Get PRO
ژوئیه '25
+786
در 11 کانالها
Get PRO
ژوئن '25
+586
در 15 کانالها
Get PRO
مه '25
+797
در 11 کانالها
Get PRO
آوریل '25
+460
در 13 کانالها
Get PRO
مارس '25
+945
در 8 کانالها
Get PRO
فوریه '25
+187
در 7 کانالها
Get PRO
ژانویه '25
+509
در 7 کانالها
Get PRO
دسامبر '24
+2 731
در 6 کانالها
Get PRO
نوامبر '24
+52
در 2 کانالها
Get PRO
اکتبر '24
+47
در 0 کانالها
Get PRO
سپتامبر '24
+110
در 0 کانالها
Get PRO
اوت '240
در 0 کانالها
Get PRO
ژوئیه '240
در 0 کانالها
Get PRO
ژوئن '24
+16
در 0 کانالها
Get PRO
مه '24
+24
در 0 کانالها
Get PRO
آوریل '24
+20
در 0 کانالها
Get PRO
مارس '24
+28
در 1 کانالها
Get PRO
فوریه '24
+31
در 0 کانالها
Get PRO
ژانویه '24
+55
در 0 کانالها
Get PRO
دسامبر '23
+65
در 0 کانالها
Get PRO
نوامبر '23
+24
در 0 کانالها
Get PRO
اکتبر '23
+55
در 0 کانالها
Get PRO
سپتامبر '23
+487
در 0 کانالها
| تاریخ | رشد مشترکین | اشارات | کانالها | |
| 04 سپتامبر | +9 | |||
| 03 سپتامبر | +1 | |||
| 02 سپتامبر | +2 | |||
| 01 سپتامبر | +3 |
پستهای کانال
🔥 ПРОЖАРКА ПО SYSTEM DESIGN: МОК-СОБЕС В ПРЯМОМ ЭФИРЕ 🔥
8 сентября, 19:00 МСК | 1 час | Онлайн
Владимир (@system_design_world) и я делаем колаб: живое мок-собес интервью по систем-дизайну.
Тема, которую всё чаще спрашивают на собесах в блоке про интеграции.
🎯 ЧТО БУДЕТ
Сначала задача на проектирование от Владимира
Кандидат собирает решение вживую (~35 мин)
А дальше разбор решения: что получилось, где стоило иначе
Ваши вопросы в конце
Я, Саша Нездемина — модератор и комментатор
Разбираем, конечно, решение, а не человека.
👤 а также, ИЩЕМ ОДНОГО КАНДИДАТА
Ты подходишь, если:
✔️ Работаешь аналитиком и проектировал интеграции;
✔️ В систем-дизайне ориентируешься, но хочешь практики.
✔️ Свободен 8 сентября, 19:00–20:00
✔️ Готов к публичному разбору и возможной записи для YouTube
Заявки принимаются до воскресенья.
➡️ [АНКЕТА КАНДИДАТА]
И жду всех остальных
Будет полезно, честно и с разбором реальных кейсов.
Сохраняй дату, зови коллег.
Увидимся 8 сентября в 19:00 🔥
| 2 | ДОБАВИЛИ РЕТРАИ, А СТАЛО ХУЖЕ. ПОЧЕМУ?
Хочу продолжить тему после последнего разбора задачи.
Первый момент, который описан в задаче - это то, что разрабы добавили ретраи.
И тут мне попалась интересная статья от Ozon Bank про то, как retry и timeout, которые должны повысить надежность, при кривой настройке, эту самую надежность и убивают.
Те, кому интересно могут почитать.
Она годная, но я тут в кратце накидаю мыслей, которые можно забрать аналитикам.
➖➖➖
1️⃣ НАДО ПОМНИТЬ ПРО ТО, ЧТО РЕТРАИ (ПОВТОРЫ) ЗАПРОСОВ МОГУТ УСИЛИТЬ ПРОБЛЕМУ.
Кейс ребят
Представьте, что у вас 10.000 запросов в минуту и 10% из них падает.
Если мы накидываем ретраи, то даже с одной дополнительной попыткой - это плюс тысяча запросов, то есть уже около 11.000, а если попыток три, то до трех тысяч сверху.
И прилетают эти запросы именно тогда, когда сервису и так плохо 🥲
С точки зрения отдельного клиента - логика нормальная: не прошел запрос просто повторяем его, но если так делают тысячи клиентов одновременно, то retry превращается из механизма устойчивости в механизм усиления сбоя.
Поэтому, про это надо помнить.
Еще момент про который надо помнить с РЕТРАЯМИ - это то, что повторения могут привести к каскадному отказу сервисов.
Это как?
Представьте, что у вас есть цепочка из Сервисов и API: API → сервис A → сервис B → сервис C.
Если сервис C начинает затупливать, а сервис B из-за этого решает, что это временный сбой и начинает делать повторные вызовы, а сервис A видит, что B отвечает медленно, и тоже начинает ретраить, то при ретрае в три раза - это увеличение количество запросов до 9 вместо 1.
Поэтому, возникает каскад отказов и система становится нестабильной.
Поэтому при сильной связанности сервисов про это надо помнить и с ретраями работать очень аккуратно.
➖➖➖
2️⃣ НАДО ПРАВИЛЬНО РАБОТАТЬ С ТАЙМАУТАМИ
Часто аналитики доверяют разрабам эту темку и опираются на стандартные паттерны по таймаутам, но если по стандарту таймауты у нас короткие, то из-за этого могут возникнуть обрывы соединения на ровном месте. При этом сервер об этом не знает и может дальше продолжить выполнять наш запрос. И из-за этого у нас может начаться возьня с дублями.
При этом длинные таймауты излишне держат соединение.
Поэтому, не забиваем на эту тему и стараемся работать с ними и прописывать в требованиях.
Мне понравился механизм определения, который предложили коллеги из 🛍.
Смотреть на реальную latency сервиса, например, на p99 и добавлять небольшой буфер, но также стоит опираться на другие критерии, например SLA.
Короче, учитываете эти моменты и будет вам счастье на проекте 😘
Было полезно ставим 🔥
➖➖➖
Места на курсе потихоньку уменьшаются
➡️ -15 ИЗ 40 МЕСТ | 475 |
| 3 |  "После курса у меня появилось гораздо более целостное понимание того, как проектируются и работают интеграции между системами + стало больше уверенности в коммуникации с разработчиками: теперь я могу не просто сформулировать бизнес-требование, а гораздо лучше объяснить техническую часть интеграции и задать правильные вопросы" - такие результаты получила после прохождения курса ученица 9-ого потока Валентина Нижникова
➖➖➖
ТОЧКА А ИЛИ ЧТО БЫЛО ДО КУРСА?
До курса я работала бизнес-аналитиком и уже участвовала в проектах, связанных с сайтами, CRM и интеграциями. Я умела собирать требования, описывать бизнес-логику, формировать ТЗ и взаимодействовать с разработчиками, но именно в части интеграций не всегда хватало технической глубины.
Было понимание, что необходимо интегрировать, но не всегда было достаточно уверенности в том, как именно происходит взаимодействие систем на техническом уровне: какие запросы и ответы используются, как проектируются API, как работают очереди и асинхронные интеграции, что происходит с данными при ошибках и как правильно описывать такие процессы для разработки.
Особенно сложно было самостоятельно разбираться в архитектуре интеграций и понимать, где заканчивается зона ответственности одной системы и начинается другой.
ТОЧКА Б ИЛИ ЧТО СТАЛО ПОСЛЕ КУРСА?
После курса появилось гораздо более целостное понимание того, как проектируются и работают интеграции между системами.
Стало проще:
✔️ декомпозировать интеграцию на отдельные процессы и компоненты;
описывать REST API, запросы, ответы, параметры и маппинг;
✔️ понимать назначение HTTP-методов и кодов ответа;
✔️ работать с Postman и Swagger;
проектировать взаимодействие через RabbitMQ и Kafka;
✔️ понимать разницу между синхронным и асинхронным взаимодействием;
✔️ описывать очереди, события, Listener и JOB;
✔️ формировать статусные модели для асинхронных процессов;
✔️ видеть не только функциональные требования, но и возможные ошибки, retry, дублирование сообщений и другие сценарии.
Самое главное — стало больше уверенности в коммуникации с разработчиками. Теперь я могу не просто сформулировать бизнес-требование, а гораздо лучше объяснить техническую часть интеграции и задать правильные вопросы.
Для меня это, пожалуй, главный результат курса.
КАК ПОМОГ КУРС?
Особенно полезной стала практическая часть.
Мне понравилось, что задания были максимально приближены к реальной работе бизнес-аналитика.
На практике я стала активнее использовать и лучше понимать:
✔️ Postman — для проверки API-запросов и ответов;
✔️ Swagger — для работы с API-документацией;
✔️ PlantUML — для описания последовательности взаимодействия систем;
✔️ маппинг входных и выходных параметров;
описание интеграций с внешними системами;
✔️ RabbitMQ и Kafka при проектировании асинхронного взаимодействия.
Особенно запомнился переход от обычного REST-взаимодействия к асинхронной архитектуре. Когда разбираешь цепочку вроде Frontend → API → RabbitMQ → Warehouse → Kafka → Listener → БД, становится гораздо понятнее, как работают распределённые системы и почему в них важны статусы, идентификаторы сообщений, обработка ошибок и идемпотентность.
Также очень помогло выполнение собственных API-заданий. Когда самостоятельно описываешь endpoint, таблицы параметров, маппинг, алгоритм и альтернативные сценарии, понимание становится намного глубже, чем после простого просмотра теории.
РЕКОМЕНДОВАЛА БЫ КУРС ДРУГИМ?
Да, однозначно рекомендовала бы, особенно бизнес-аналитикам, которые хотят перейти от работы преимущественно с функциональными требованиями к более техническому уровню.
Курс хорошо подходит тем, кто хочет разобраться в интеграциях не только на уровне терминов, но и научиться самостоятельно описывать их для разработки.
Особенно рекомендую его тем, кто, как и я, уже работает аналитиком, но чувствует, что не хватает технической базы для уверенной работы с API и интеграциями.
➖➖➖
➡️ САЙТ КУРСА | 494 |
| 4 | И напоследок, хочу обратить внимание на одну вещь.
Трое из четверых, прежде чем предлагать решение, задали уточняющие вопросы
Это говорит о том, что они не бегут сразу в бой, а хотят выяснить причины и только потом лечить их.
Про инструменты (вебхук, circuit breaker) можно просто знать, все это гуглится за вечер, а вот увидеть чего в условии не хватает, по гуглу не научишься. Для этого в голове должна быть понимание, а не россыпь фактов.
Вот эта разница и решает на собесе.
Не количество выученных паттернов, а порядок, в котором вы к задаче подходите.
Ровно этому я и учу на курсе.
Мы не заучиваем паттерны, мы тренируем формировать интеграции по шагам, от теории к практики. Закрываем полный цикл, который можно применять на любом проекте.
➡️ Приглашаю на курс "ИНТЕГРАЦИИ И ПРОЕКТИРОВАНИЕ API":
✔️разложите знания в систему,
✔️получите практику на реальных кейсах,
✔️ научитесь защищать решение, а не только придумывать его
СТАРТ 21 СЕНТЯБРЯ
ОСТАЛОСЬ 27 МЕСТ ИЗ 40
СЛЕДУЮЩИЙ ПОТОК ТОЛЬКО В 2027 ГОДУ
➡️ САЙТ КУРСА | 608 |
| 5 | РЕШЕНИЕ ЗАДАЧИ ИЗ РЕАЛЬНОГО СОБЕСА (ПРО СЕРВИС БОНУСОВ)
Спасибо всем кто накидал варианты 🔥
У вас получились классные ответы и каждый посмотрел на ситуацию с разных сторон, поэтому для начала пройдусь по вашим ответам 😉
➖➖➖
ВАШИ ВАРИАНТЫ
➡️ Анастасия
В целом, направление очень верное: уйти в сторону асинхрона хороший вариант. При этом условие, что нельзя использовать брокер сохраняется.
Если мы будем использовать хук и при этом не ждем ответа, а сервис бонусов сам дергает наш вебхук, то сервис заказов действительно перестанет виснуть. И в теории проблему мы закроем.
Но основная проблема у нас не с сервисом заказов, а с сервисом бонусов, поэтому этому сервису легче не станет. Потому что нагрузка останется прежней. И если этот сервис приляжет, то вебхук не дернуть.
➡️ Маргарита
У тебя, как и всегда, все по красоте, а зная твой опыт, и сомнений нет.
У тебя классная идея на счет создания фонового воркера и в целом, опасения очень валидны, что данные могут разъехаться.
И еще, все круто с пониманием, что "нужен ОК от бизнеса, что списание бонуса может быть залочено в момент пика" + сама мысль о том, что надо померить цифры 🔥
Чего не хватило?
Так это мыслей по поводу таймаутов и объяснения, почему зависают сами заказы, но про это подумал Лёша 😄
➡️ Алексей
Круто, что сразу с плеча, про лечение сервиса. Я такие заходы люблю, когда провожу собесы. Обычно на интервью дают специально куцые условия, чтобы понять - вы будете уточнять детали или сразу в бой накидывать решения.
По сути, если бы сервис бонусов сломался после релиза, откат решил бы все, но в условии сказано, что сервис нестабилен давно и умирает, именно при повышенном спросе, поэтому это не сломанная версия, "но это не точно", но больше нехватка ресурсов под нагрузкой и откат тут не поможет.
И еще момент, в условии не сказано, чей это сервис с бонусами - наш или сторонней команды или вообще вендорский какой-то.
Если наш, то проблем нет, а если чужой, то чинить может быть проблематично и долго. Хотя целевой вариант может быть таким.
➡️ Александр
Первый вопрос прям в точку, а именно узнать в чем вообще смысл бонусов и на что они влияют не просто важно, а критически важно, потому что если мы не знаем зачем, то можем лечить не то и не теми методами.
Это как с головной болью.
Лучшее лекарство ТОПОР. Действует один раз, но лечит не так, как надо 😂
Дальше, правда ты ушел в тему с подами в кубере, но в условии явно прописано, что мы не можем наращивать мощности.
В реальной жизни - рабочая схема, и если даже нет возможности на увеличение мощностей, то можно попробовать их выбить😁
➖➖➖
Теперь к решению
Не знаю, как вы, но я при работе с задачами всегда иду по стандартному алгоритму:
1) Сбор требований, чтобы понять зачем вообще что-то решать и что мы решаем.
2) Потом смотрю возможности и ограничения.
Они явно видны из ответов собеседующих
3) И только на этом этапе начинаю накидывать реализацию.
Но так как в текущих реалиях спросить не у кого, то работаем с тем, что мы знаем и можем предположить.
1️⃣ меня смущает - это накинутые ретраи.
Если у нас сервис с бонусами и так страдает, то увеличение ретраев могут дать дополнительную нагрузку. Как минимум в 3 раза, так как у нас максимальное количество повторов 3 штуки.
Поэтому я бы от этой истории возможно избавился бы.
2️⃣ Почему у нас зависают заказы, хотя ломаются бонусы?
Тут надо подумать над связкой и вообще проработать бизнес-процесс. По идее, формирование заказа и работа с бонусами - это два разных процесса, а в текущих реалиях - это каскадный отказ, так как один сервис зависит от другого.
То есть прорабатываем процессы, прежде чем чинить.
Понятное дело, что в рамках интервью это не полечим, поэтому можно поработать с текущим состоянием и что-то полечить.
➖➖➖
ЧТО ЛЕЧИМ?
📌 Таймауты
Надо понять какие они сейчас и от чего зависят. От каждого отдельного сервиса или от заказа.
📌 Ретраи
Раз сделали, значит была какая-то логика, но их мы можем разнести так, чтобы была растущая пауза.
Например: 100мс, 400, 1600. | 522 |
| 6 | РАЗБОР ЗАДАЧИ ИЗ РЕАЛЬНОГО СОБЕСА
Тренируем мышление системного аналитика и свою насмотренность в подходах к решению задач
Как все проходит?
✔️ ниже я отправляю условия задачи,
✔️ вы накидываете свои варианты ее решения в комментариях,
✔️ я присылаю правильный вариант решения задачи с моими развернутыми комментариями
📌 есть вероятность, что могу комментировать ваши варианты решения
Погнали 🚀
➖➖➖
ЗАДАЧА
➡️ Условие:
У нас интернет-магазин.
Когда клиент оформляет заказ - сервис заказов синхронно идет в сервис бонусов, чтобы списать бонусные баллы.
Сервис бонусов последнее время работает нестабильно и может отвечать больше 3-х секунд из-за чего мы ловим таймауты.
Разработчики добавили ретраи, чтобы полечить эту проблему. Добавили 3 попытки. Это временно помогло, но не спасло, так как при повышенном спросе, например, когда у нас черная пятница, сервис бонусов просто умирает, и заказы зависают.
При этом возможности нарастить мощности в виде железа нет.
И внедрить отдельный брокер тоже.
➡️ Что надо сделать?
Предложить вариант решения.
Что можно сделать, чтобы сервис был живой и все работало?
➖➖➖
Жду ваши варианты в комментариях 🚀
#задача@proanalitica | 677 |
| 7 | ЗАЧЕМ Я ВООБЩЕ СОБРАЛ ЭТОТ КУРС?
Мне регулярно пишут с просьбой взять в менторство или разобрать задачу с проекта. И я почти всегда отказываю.
Звучит странно, да?
Человек сам несет деньги, а я говорю нет, но именно в этом отказе и лежит ответ.
Следите за ходом моих мыслей
Как выглядит консультация?
Приходит аналитик и приносит какой-то кейс, например,
У нас интеграция с БД. Мы переделываем логику получения данных, но есть уже сформированный легаси и поэтому не знаю, как спроектировать правильно, что делать?
За час-два я накидаю три-четыре варианта, потому что за 14+ лет насмотрелся на такие задачи в разных видах.
Человек уходит довольный, запрос закрыт.
А дальше он несет это решение команде. И на первых же уточняющих вопросах начинает сыпаться.
Почему выбрали такой способ?
Какие ограничения?
Что будет, если...?
Решение у него есть.
Понимания, почему оно такое, нет.
В моменте консультация - это волшебная таблетка.
В перспективе медвежья услуга, потому что с новой задачей человек окажется ровно там же, где был.
Давайте приведу пример на игре в шахматы.
Если вам рассказали, как выиграть конкретную партию, вы ее выиграете, но играть в шахматы вы не научились, потому что если изменится ситуация и соперник пойдет иначе, то действия вам нужно применять уже другие.
А если вы узнаете правила, поймете как ходят фигуры, научитесь мыслить и понимать ограничения и возможности, то сможете разобрать любую позицию, в какой бы момент к ней ни присоединились.
С интеграциями ровно так же.
Кстати, когда я создавал курс, то думал, что главным запросом на курс будет - закрыть пробелы в знаниях, но самым частым запросом отказался - систематизация уже имеющихся.
Ученики приходят не с пустой головой, а с полной.
Потому что тут статья, там ролик, здесь обсуждение в рабочем чате, и вот уже разрозненные знания в голове.
И вроде читал и про идемпотентность, и про проектирование, и про ресты и вроде все яснопонятно, но где и когда применить в своем проекте эти знания - непонятно.
Отсюда и растет та самая невозможность обосновать свой выбор, чтобы объяснить команде почему решение именно такое и для этого нужна система, а не набор разрозненных фактов.
Плюс из-за такой каши в голове возникает чувство, что я самоучка, который недостаточно всего знает и что меня вот-вот разоблачат как недостойного.
Вот как это описала одна из учениц:
Любая задача, связанная с API, вызывала страх. Я постоянно отвлекала опытных коллег вопросами или искала разрозненную информацию в интернете. Чувствовала себя неуверенно и неэффективно.
Именно поэтому я создал курс, а не консультации/менторство.
Ничего волшебного, просто три вещи, которых нет у самостоятельного изучения:
✔️ последовательность - темы идут в том порядке, в котором складываются в систему, а не в том, в котором вам попались. При этом идем от простого к сложному.
✔️ практика, где вы сами делаете постановку, проектируете, а я спрашиваю ровно то, что могут спросить в команде.
Задаю вопросы, даю пояснения и направляю, чтобы вы могли улучшить результат.
✔️ возможность спросить по ходу, а не гадать.
Я за практический подход, поэтому если вы работаете на проекте и во время прохождения курса у вас возникает какая-то ситуация, то я с удовольствием разберу ее в чате и накидаю варианты, как на консультации. Только ответ будет привязан к тому материалу, который вы проходите.
И таким образом вы не просто получите обратную связь, а еще и сразу примените ее на практике.
В моменте это сложнее, чем просто придти на консультацию. Надо напрягать мозг, делать домашки, переделывать, если ошибся.
Волшебной таблетки не будет, я ее и не продаю.
И еще,
от разовых консультаций я отказываюсь до сих пор, хотя денег можно заработать быстрее и проще.
Просто через месяц человек возвращается с той же проблемой, только задача другая, а после курса почти нет, потому что уже сами разбираются что к чему.
А вы как считаете?
Разовая консультация по задаче или все-таки разбираться в базе?
➡️ Стартуем 21 сентября. Подробнее здесь | 774 |
| 8 |  Отвечаю на самые частые вопросы по курсу, которые поступают в службу заботы @proanalitika_manager
➖➖➖
Где посмотреть программу и стоимость?
На сайте курса:
➡️ https://proanalitika.ru/?utm_source=telegram&utm_medium=post&utm_campaign=28.08.2026
Старт обучения – 21 сентября
Длительность – 6 недель
➖➖➖
Есть ли рассрочка?
Да, есть рассрочка для 🇷🇺 , 🇧🇾 , 🇰🇿
Оформить рассрочку можно на странице оплаты.
Для этого нужно перейти на сайт:
➡️ https://proanalitika.ru/?utm_source=telegram&utm_medium=post&utm_campaign=28.08.2026
Нажать «Оплатить обучение», заполнить перс данные и на странице оплаты выбрать оплату в рассрочку.
Для 🇷🇺: от Т банка, Яндекс Сплит*
Для 🇧🇾 и 🇰🇿: ресурс Развитие (после оформления заявки с вами свяжется менеджер для обсуждения деталей)
*перед тем, как оформить рассрочку - снимите самозапрет на ГосУслугах, иначе будет автоматический отказ
➖➖➖
Можно ли оплатить картой РБ, РК или какой-либо другой?
Мы подключили все возможные способы из существующих: и для граждан РФ, и для оплаты за границей, включая СНГ.
➖➖➖
Я работаю на зарубежном рынке, мне подойдет?
Да, потому что курс предполагает изучение фундаментальных, БАЗОВЫХ знаний, которые никак не отличаются для других стран.
У нас есть студенты, которые успешно работают на рынке США, Европы и т.д.
➖➖➖
Есть ли чат студентов?
Да, и это не флудилка, а реальное профессиональное комьюнити.
Чаты не замолкают и после окончания курса: там всегда можно спросить совета, получить точечное решение, поделиться своими успехами или найти вакансию.
➖➖➖
Подойдет ли это под мой стек технологий?
Навык проектировать интеграции нужен сейчас везде и я даю принципы, которые едины для всех стеков технологий.
ОСТАЛОСЬ 25 ДНЕЙ ДО СТАРТА
➡️ https://proanalitika.ru/?utm_source=telegram&utm_medium=post&utm_campaign=28.08.2026
➖➖➖
Боюсь, что не успею совмещать учебу и работу
Сейчас расскажу почему вы точно все успеете :)
Теоретические уроки
Курс состоит из ранее записанных уроков со средней продолжительностью примерно 15-20 минут.
Скринкасты выполнения практических заданий
Примерно, в среднем, 20-30 минут
Практические задания
Бывают разные, но занимают в среднем от 30 минут до 1.5 часов в среднем.
+ Гибкое расписание
По понедельникам вам сразу выдается доступ к урокам всего модуля и каждый смотрит и выполняет ДЗ в своем темпе. В следующий понедельник открывается доступ к следующему модулю и тд
+ есть одна дополнительная неделя курса (шестая), чтобы вы точно успели сдать и получить обратную связь от сопровождающего, практикующего аналитика.
➡️ ПОСМОТРИ ПРОБНЫЙ УРОК, чтобы по понять, как все устроено изнутри
➖➖➖
Могу ли я сделать налоговый вычет?
Да, так как моя школа имеет образовательную лицензию.
Есть сомнения перед покупкой, так как уже купил курс и сижу теперь изучаю ссылки на Хабр за 50к.
Специально для вас записал видео, как выглядит все изнутри, чтобы этих сомнений не осталось.
Записываю такое видео, чтобы показать с какой любовью все устроено на курсе и хочу отдельно отметить, что не было ни одного потока, где мы бы не допиливали курс в лучшую сторону 😘
➡️ ПРИСОЕДИНИТЬСЯ | 748 |
| 9 | ЧТО ДЕЛАТЬ, ЧТОБЫ НЕ СПИСАТЬ БАБЛО ДВА РАЗА ПРИ ИНТЕГРАЦИИ С ВНEШНИМ ШЛЮЗОМ?
Представьте, что вы проектируете оплату заказа и при этом работаете с внешним шлюзом.
Хэппи пас абсолютно понятен: пользователь жмет "оплатить", мы отправляем запрос в платежный шлюз и получаем ответ о том, прошла оплата или нет.
Но что делать, если у нас что-то пошло не так?
Например, словили таймаут и теперь не понимаем, что с платежом произошло и списалось ли баблишко?
➖➖➖
Часто, когда делаются интеграции, все проектируют стандартную логику. Получилось выполнить запрос — отлично. Не получилось — что-то с этим делаем. Например, повторяем запрос или просто выдаем ошибку.
Но в этом кейсе все немного сложнее, потому что у нас есть внешняя сторона у которой состояние может отличаться от полученных нами данных.
То есть фактически у нас на руках три возможные реальности:
✔️ запрос не дошел до шлюза и денег нет,
✔️ запрос дошел, деньги списались, а ответ потерялся по дороге к нам,
✔️ запрос дошел и прямо сейчас обрабатывается.
Получается, что фактически сам платеж находится в каком-то состоянии, но на нашей стороне появляется неопределенность.
И что с этим можно сделать?
1️⃣ Проработать правильно статусную модель.
Не делать категорично SUCCESS или CANCELED, а добавить еще промежуточные статусы, например, IN_PROGRESS, ERROR.
Это нужно, чтобы не показать пользователю в случае 500-ки или timeout ошибку с какой-нибудь кнопкой "Повторить".
В этом случае у нас есть риск двойного списания деньжат, а промежуточный статус как раз решает проблему до выяснения обстоятельств.
2️⃣ Прорабатываем механизм уточнения статуса транзакции у шлюза.
Без этого у нас могут зависнуть транзакции без движения.
3️⃣ Обязательно продумываем SLA промежуточного статуса.
Грубо говоря, нам надо прописать, через сколько статус IN_PROGRESS должен перейти в другой и при наступлении этого времени еще раз продергиваем шлюз, чтобы подтвердить реальный статус и либо отменяем оплату или меняем на CANCELED, если шлюз так это подтвердил, потому что если мы такую логику не продумаем, то у нас будут зависшие транзакции.
4️⃣ Всегда помним про идемпотентный ключ, чтобы не создать новый платеж.
Еще можно продумать функциональность сверки данных между внешним шлюзом и нами. Грубо говоря, раз в сутки забирать у шлюза реестр операций и сравнивать его со своим, чтобы найти косячные транзакции и лишние проводки в случае чего.
И конечно, корректно работаем с ошибками и отдаем фронту промежуточные статусы, например, "Платеж обрабатывается, мы сообщим об окончании" вместо того, чтобы просто кидать ошибку и давать возможность делать повторный запрос.
➖➖➖
В итоге, при работе с внешней системой всегда закладывайте чуть больше, чем в интеграциях между сервисами, потому что внешний шлюз или какая-то другая система нам не подчиняется и нам всегда нужна перестраховка. | 825 |
| 10 |  Вернулся вчера с IT-регаты
Армения, озеро Севан, лодки J70, наши ребята из айти.
Гонялись на таких же лодках, как в Барселоне и с тем же капитаном + девочка из моей барселонской команды, но в этом году было одно изменение.
В команде была девушка, которая имеет опыт и даже разряд по парусному спорту. Марина, если читаешь — привет 👋
В парусных гонках, есть такая история, что когда у вас есть ВЕТЕР, то все ок и ошибки можно ликвидировать и они не так сильно влияют, но если его нет, то тут от опыта команды зависит очень многое.
Первый день мы тренировались.
Что-то получалось, что-то нет.
Такая притирка команды была, но вся команда обсуждала, что можно улучшить.
Квалификационный день не задался.
Мы совершали ошибки и все равно докручивали.
А вот когда пошли гонки из четырёх заездов три раза - мы заняли второе место. Это очень круто для команды которая не профи 🔥
И тут последний день.
На Севане такой штиль, что лодка практически стоит на месте и чтобы выигрывать - надо принимать неочевидные решения.
Если такого опыта в команде нет, вы просто стоите на воде и смотрите, как уезжают другие.
Вот тут опыт Марины нам очень сильно помог. Она рассказывала, как работать с весом. Милиметровала паруса. Гонка превратилась в шахматы.
Марина вместе с капитаном работали в очень тесной связке, понимая друг друга без слов и благодаря такой филигранности - мы с каждой гонкой улучшали результат.
➖➖➖
Так вот, к чему я это всё?
Когда в команде есть человек у которого опыта чуть больше, чем у остальных, то он поднимает уровень всех: вы забираете не только результат, но и то, что он передает по дороге.
Поэтому посмотрите на свою команду. Вы там на какой позиции?
✔️ Если рядом есть тот, кто шарит сильнее, то тащите из него опыт, пока он рядом
✔️ Если такого человека в команде нет, то идите за опытом во вне, не появится он сам
✔️ Если сильный в команде вы, то не стесняйтесь делиться. Расскажите как вы думаете над задачей, а не только что получилось на выходе.
Так вы сможете достать в себе то, чего раньше не замечали.
➖➖➖
Кстати, мы по итогам всех гонок остались 4ми, проиграли полупрофи, которые работают инструкторами.
Считаю такой результат ТОП 🔥
➖➖➖
А еще напоминал, что меньше, чем через месяц стартует 11 поток курса «ИНТЕГРАЦИИ И ПРОЕКТИРОВАНИЕ API».
Разберем как ставить ТЗ на разработку. Обменяемся опытом и прокачаем навыки по синхронным и асинхронным интеграциям
➡️ САЙТ КУРСА | 983 |
| 11 |  ИЩУ АНАЛИТИКОВ, КОТОРЫЕ ХОТЯТ СТАТЬ УВЕРЕННЫМИ ПРОФИ, СПОКОЙНО ПРОХОДИТЬ СОБЕСЫ И РАБОТАТЬ В ТОП КОМПАНИЯХ 🔥
Именно такой результат тебя ждет после прохождения моего курса-практикума "ИНТЕГРАЦИИ И ПРОЕКТИРОВАНИЕ API"
И сегодня, я открываю продажи на последний поток курса в этом году
КУРС ПОДХОДИТ:
✔️ системным аналитикам,
✔️ бизнес-аналитикам,
✔️ продакт менеджерам,
➡️ которые хотят получить фундаментальные, БАЗОВЫЕ знания в теме интеграций, а так же структурировать и углубить текущие и научиться:
✔️ решать с легкостью интеграционные задачи, знать с чего в них начать и иметь план действий,
✔️ ставить ТЗ на разработчиков и прокачаться в этом вопросе,
✔️ говорить на одном языке с командой и понимать о чем идет речь на встречах,
✔️ чувствовать себя, как рыба в воде на технических собесах и не испытать ужас, когда надо решить практическую задачку
❗️ДЕЙСТВУЙ и уже через 5 недель ты получишь первый результат❗️ | 1 288 |
| 12 | Файл над которым я и моя команда работали около 2-х месяцев
Что в нем?
Самые частые вопросы по интеграциям, которые задают на реальных собесах 🔥🔥🔥
Как мы их собрали?
Мы упоролись с командой и решили прошерстить весь рынок, а еще отсмотрели не один десяток видео, да и что уж скромничать, сами провели тонну реальных собесов и выделили больше 700!!! уникальных вопросов по разным темам.
А потом, из этих 700 отобрали 100 просто самых горячих, часто встречающихся вопросов, которые относятся к моей любимой теме - интеграции.
А еще и систематизировали их по частоте 🔥
Почему именно интеграции?
Потому что на ней валится большинство 🥲
Как получить этот файл?
➡️ ЗАБРАТЬ ЗДЕСЬ
➡️ ЗАБРАТЬ ЗДЕСЬ
➡️ ЗАБРАТЬ ЗДЕСЬ | 1 661 |
| 13 | А что за файлик со 100 вопросами ? | 1 498 |
| 14 | КАК СДЕЛАТЬ АСИНХРОН ЧЕРЕЗ HTTP?
Недавно проходил собес на лида.
И знаете что?
Не важно какого уровня вакансия, вопросы могут быть примерно одинаковые.
Я сейчас активно готовлю ответы на файл со 100 вопросами и каково же было мое удивление, когда на этом собесе мне попался вопрос прямо оттуда.
Вопрос такой:
как можно сделать асинхронное взаимодействие через HTTP?
И ведь не для всех очевидно, что через HTTP вообще можно реализовать асинхрон, поэтому про это и предлагаю сегодня подробнее.
➖➖➖
Начнем с самого частого случая.
Представьте, что вы проектируете выгрузку тяжелого отчета. Пользователь нажимает кнопку заказать, а отчет собирается минуту, а то и две.
Синхрон тут нам точно не подходит, потому что такой запрос точно свалится с ошибкой по таймауту. И поэтому нам нужно делать асинхрон.
Самый простой способ это сделать polling.
Как он работает?
Сервер не заставляет клиента ждать, а сразу отвечает кодом 202 Accepted, и отдает инфо, откуда забрать отчет. Это может быть id из системы или URL в заголовке Location.
Дальше клиент по этой ссылке или id периодически опрашивает сервер и узнает статус готовности. И когда документ будет готов, то мы его заберем.
Это самый простой способ забабахать асинхрон через HTTP, но у него есть минус в виде паразитной нагрузки.
Поэтому, когда мы его выбираем, нам надо помнить про частоту ретраев с которыми мы ходим с запросом.
➖➖➖
Как мы можем реализовать еще? Особенно если у нас нет клиента, а общается сервер с сервером?
В этом случае мы можем использовать webhook.
В этом кейсе не клиент нас опрашивает, а мы сами дергаем его webhook, как только отчет готов. Главное знать, что нужно дернуть.
➖➖➖
Еще один вариант - это SSE.
В этом случае также у нас идет работа через HTTP, но сервер сам, без всякого запроса, постоянно шлет клиенту свежие данные.
Также еще можно сказать про websocket, но там только само соединение устанавливается по HTTP, но дальше происходит подмена протокола.
Вот такие 4 способа.
➖➖➖
Что важно при ответе на собесах, на мой взгляд, если мы знаем про все это применение?
Если вы собеседуетесь на уровень мидлл+, то важно не только ответить, какими способами можно реализовать, но еще добавить контекста: в каких кейсах какой паттерн стоит использовать.
И тогда все будет в шоколаде.
Вот такие дела.
➖➖➖
Кстати, напоминаю, что уже на следующей неделе стартуют продажи курса "ИНТЕГРАЦИИ И ПРОЕКТИРОВАНИЕ API".
Кто хочет попасть, не забудьте добавиться в лист предзаписи на сайте, на следующей неделе мой менеджер Лиза уже начнет всем писать ❤️ | 1 859 |
| 15 | ТЕСТОВОЕ ЗАДАНИЕ БОЛЬШЕ НИЧЕГО НЕ ДОКАЗЫВАЕТ
Раньше тестовое было самым дешевым фильтром на найме.
Схема простая: даешь кандидату кейс, например, у тебя есть две системы и ему надо описать интеграцию, наикдать методы API, нарисовать sequence.
Что еще не маловажно - это еще и скоростной способ проверки.
Можно просмотреть десять работ за час и в среднем троих позвать дальше на разговор.
Что происходит сейчас?
Приходит десять одинаково приличных работ.
Очень похожие user story, грамотные формулировки и все как под копирку.
А почему?
Потому что ИИ сломал этот фильтр, так как любой худо-бедно прошаренный кандидат пользуется ИИ-шкой.
И это не хорошо и не плохо, но теперь, если ты нанимаешь аналитика, то такой отбор ну вообще ничего не показывает.
А что делать?
1️⃣ Давать такие задания, но вычислять ИИ-шные ответы от обычных.
Например, по кавычкам-елочкам, длинным тире и "важно отметить".
Но к сожалению, такой подход тоже не работает.
Потому что если слегка поправить текст или явно прописать, чтобы ИИ-шка не писала эти маркеры и руками поправить текст, то ни один детектор, включая человеческий не отличит текст.
Это, кстати, подтверждают ребята из штатов, которые в Университете Мэриленда провели такой эксперимент.
Поэтому, зарубежные компании уже внедряют другой подход и думаю наши тоже скоро подтянутся.
2️⃣ Они просто начинают на техническом интервью просить кандидата показать, как он через ИИ, будет решать задачку.
Например, просят запустить Copilot, Cursor, Claude и погнали.
Логика у них простая - кандидаты итак делают это скрытно, а без ИИ не видно, как человек реально работает, а если сразу начать работать через ИИ-шку, то можно понять ход мысли и как человек умеет работать и с инструментом, и как он критически мыслит, как формулирует задачи и так далее.
Еще читал, что в Shopify вообще пошли дальше и просят сразу показать инструменты, которыми пользуется человек. Какие у него есть скиллы, как он с ними работает.
Ну и конечно, начинают возвращать очное общение в офисе, как в старые добрые, чтобы увидеть реального человека без всяких обвесов.
Так что теперь думаю не стоит удивляться, если вас позовут в офис на какой-нибудь из раундов, потому что просто артефакт, сделанный без наблюдения, больше ничего не значит.
Как это было раньше.
➖➖➖
И ключевое
Если раньше закрывали глаза и спрашивали типовые кейсы, то теперь смотрят и копают вглубь, что бы понимать, как думаете и что реально имеете в виде практического опыта.
Нанимать так дороже.
Несколько минут чтения тестового превратились в час живого разговора с каждым, но других вариантов я пока не вижу.
Поэтому, если вы готовитесь к собеседованию, то знайте, что теперь ценят умение объяснить каждое свое и не свое решение: почему так реализовали, где ИИ ошибался и что вы за ним поправили.
Было полезно - ставь 🔥
➖➖➖
Подписывайся на резервный канал, чтобы не потерять
💙 я в ВК | 🇷🇺 я в Макс | 1 562 |
| 16 |  Ну что?
Сегодня уже пятница и вот я возвращаюсь с постом на тему - что можно прокачать, чтобы быть в теме AI first и чтобы вы были не просто пользователи АИ-шки, а вообще понимали, что вы делаете и на какие навыки смотрят люди.
В основном, конечно, это разбито за рубежом, а вот у нас, наверное, еще не так, но хотя всякие большие финтехи, типа Сбера и того же Райфа, уже рассматривают эту тему.
В целом, все скиллы, которые вам нужны для того, чтобы быть AI-Native, можно посмотреть на картинке к этому посту и из них нужно понимать и знать хотя бы 3-4, но чем больше, тем лучше.
➖➖➖
Основное большинство пользователей обычно зависает на двух топовых: Claude и ChatGPT, а какие-то альтернативы не рассматривают: тот же QWEN, тот же Kimi и другие LLM-ки, которые можно использовать в работе.
Дальше
Вы умеете создавать и использовать скиллы, не только Claude, вообще скиллы, и понимаете, вообще что это такое и на что они влияют.
Крутая штука с которой я до сих пор борюсь и прокачиваюсь - второй мозг. Тут можно почитать про GBrains и Obsidian.
Следующая штука, которая очень важная на мой взгляд, написана вот так: «Вы ведете и обновляете CLAUDE.MD».
Понятное дело, что у Codex это его AGENT.MD, но то, с чем мы столкнулись для того, чтобы не жрать токены, приходится прям хорошо работать с этим файлом, чтобы ничего лишнего туда не попало.
Ну и, конечно же, куда же без наших интеграций.
Обычно, если раньше у нас все требовали умения работать с API, подключать их, то здесь нам важно уметь не только работать с самим API, но еще и уметь работать с MCP:
• уметь их подключать,
• настраивать,
• понимать вообще, что такое токенизация,
• как это все работает.
А остальное уже по мелочи.
То есть уметь управлять контекстом, например, не писать, как я в прошлом посте писал, все в одном окне, создавать проекты, уметь создавать различные рутинсы, подключать различные коннекторы, которые вы можете.
Ну и последнее, что самое важное, наверное, будет в будущем, это все-таки умение экономить токены, потому что сейчас я думаю, вы слышали миллионы вообще историй уже про то, как чуваки спалили токены очень-очень быстро и потратили там бюджет годовой за один месяц.
Вот такие вот 9 основных навыков, которые хочет видеть рынок.
Поэтому прокачивайтесь вообще, смотрите, чекайте, что вы знаете, что не знаете, и развивайтесь в этой теме.
Скорее всего, как бы мы ни хотели, это в той, либо иной части, к нам точно придет.
И про себя могу отметить, что уже навыки, работа с таким набором вещей мне помогают достаточно хорошо ускорить мою работу.
Ну и вопрос, конечно же, к вам
Кто этим пользуется, не пользуется?
Вы сколько уже навыков из этого используете в работе? | 1 436 |
| 17 |  5 ОТВЕТОВ, КОТОРЫЕ ВЫДАЮТ, ЧТО ВЫ НЕ ШАРИТЕ ЗА ИИ, А ПРОСТО ОБЫЧНЫЙ ПОЛЬЗОВАТЕЛЬ
Недавно был на вебинаре у Ai-First агенства. Ребята делают крутые штуки.
Например, парсят linkedIn и HH и вообще все, что только можно для того, чтобы закрывать вакансии, где требуются крутые спецы.
Так вот, понравился комментарий владелицы про то, что AI прошареным чувакам готовы платить больше, чем обычным спецам процентов на 20-30, нооооо при этом часто такие люди валятся на простых рассказах о том, как они используют ИИ в работе.
И вот они
1. Пользуется только веб-чатом;
2. Один огромный диалог на все;
3. Вставляют секретные ключи прямо в чат;
4. AI все сделает за меня;
5. Бесплатной версии достаточно.
Звучит банально, но блин, реально. Очень многие мои знакомые действительно так и делают.
Просто юзают GPT и скидывают туда все. При этом это очень крутые ИТ профи.
Поэтому, не делайте так 😉
Кстати, интересно узнать на что стоит сделать упор, чтобы прокачать себя в ИИшности? Тоже в этой презе было.
Ставь 🔥, если да | 1 628 |
| 18 | 🔥 СРОЧНЫЕ НОВОСТИ 🔥
Друзья, расскажу, какие планы у меня по запуску курсов в этом году
➡️ ИНТЕГРАЦИИ И ПРОЕКТИРОВАНИЕ API
21 сентября стартует последний поток этого года.
Если планируете учиться — самое время определяться, особенно, если хотите пройти обучение через работодателя, потому что процесс оформления документов небыстрый, так что инициировать его лучше уже сейчас.
➡️ БД (базы данных и основы SQL)
Курс, который традиционно запускался раз в год, в конце октября.
В этом году решение такое: набора для всех не будет. На БД смогут попасть только те, кто прошёл интеграции — у вас уже есть контекст и понимание концепции, без этого разобраться в БД будет сложнее.
Новых курсов пока не планирую.
Хочу сосредоточиться на том, чтобы:
— улучшить текущий курс по интеграциям;
— проработать тему с ИИ — сейчас это требуется почти везде, AI First компании ждут, что вы понимаете, как работать с ИИ.
Хочу, чтобы вы могли этому научиться.
Что можно сделать прямо сейчас?
✔️ Хотите на курс по интеграциям? Записывайтесь в лист ожидания на сайте курса.
Те, кто в листе, получают лучшие условия.
Старт продаж — середина августа.
✔️ Планируете оплату через юрлицо? Ждем запрос от работодателя на почту info@proanalitika.ru
✔️ Хотите на курс по БД? Предложение пришлю в чате учеников в ближайшие 2 недели | 1 655 |
| 19 |  Очень часто вижу новости о том, что свершилось чудо и в HTTP протоколе появился новый метод - QUERY.
Если так подумать, то это не сильная революция, но она сможет снять головную боль в кейсах, когда вам надо было сделать гигантские фильтры.
➡️ Почитать про метод можно тут
Интересно, как быстро его начнут внедрять в проекты, что думаете? | 1 668 |
| 20 | Вчера наткнулся на классичейский кейс, который любят давать продакты на интервью, после технички.
Звучит так:
"Хочу, чтобы каждое утро у меня на столе лежал бутерброд. Как ты это реализуешь?"
Кому попадался такой кейс - ставьте 🔥
Что обычно делает аналитик?
Правильно, идет копать эту тему и начинает мучать продакта.
- Какой хлеб,
- какая начинка,
- во сколько положить,
- кто готовит,
- что с бутиком делать в выходные.
Ну вы поняли, то есть начинает собирать контекст.
Однако, это типичная ситуация на которой вы завалитесь, потому что не надо сразу бежать и крафтить бутики, пока не поймете, а ЗАЧЕМ он хочет его получить.
➖➖➖
Что нам надо выяснить в самом начале?
Почему бутерброд?
Это можно делать через пять ПОЧЕМУ.
Исходя из ответов, уже будет понятно, что с этим делать. Действительно нужен бутер или может быть нужен комплексный завтрак, а может быть нужно альтернативное решение и вообще надо такси заказать и в рестик отвезти. Ну вы поняли 😉
Когда понятно стало зачем, допустим, хочет сытно завтракать, начинаем углубляться и выяснять глубинные потребности:
✔️ Какая цель? Что он этим завтраком хочет получить? Взбодрится, отвлечься, что-то еще.
✔️ Что для него "сытный завтрак"?
✔️ Есть аллергии, ограничения, рекомендации врача?
✔️ Во сколько он в офисе и обязательно ли еда должна ждать на столе?
✔️ Кто это готовит, заказывает и оплачивает?
Поняв ответы на все вопросы, в итоге у вас вряд ли по итогу окажется бутерброд 😁 У вас будет совершенно другое решение.
➖➖➖
Подытожу 2 мыслями:
✔️ Если вам задают такие абстрактные вопросы на собесе, то не бегите вперед паравоза и не сразу решайте задачу, а повыясняйте.
✔️ Когда мы работаем в проектах, очень часто при интеграциях всплывают такие хотелки заказчика.
Только они не выглядят, как бутик, а просто заказчик приходит не с потребностью, а с готовым решением, например, "сделай мне выгрузку в Excel", "прикрути вебхук", "добавь поле status".
При этом часто, то что он себе придумал делать - ну вообще не надо и это так не работает.
Поэтому не тащите в разработку первое, что озвучил клиент, а отделить его решение от настоящей потребности. | 2 047 |
