Почему 200 OK не гарантирует успешное завершение операции?

В интеграциях есть одна очень коварная вещь, которая становится причиной огромного количества проблем. Сервис вернул 200 OK, и все решили, что операция успешно завершилась.

Хотя на самом деле это может быть вообще не так. Важно понимать, что HTTP-ответ показывает только результат обработки конкретного запроса конкретным сервисом.
Он не гарантирует, что весь бизнес-процесс дошёл до конца.

Особенно это становится заметно в распределённых системах, где одна операция почти никогда не ограничивается одним действием.

Давайте вернемся к нашему примеру оформления заказа. Когда пользователь нажимает «купить» система должна создать оплату, зарезервировать товар,
создать доставку, обновить CRM, отправить уведомление и записать событие в аналитику.

Что может произойти?

Сервис заказов может успешно сохранить заказ и вернуть 200 ОК, но платёжный сервис может не ответить, событие может не дойти до очереди, а внешний сервис вообще может быть временно недоступен.

С точки зрения HTTP всё хорошо, а вот с точки зрения бизнеса операция выполнена только частично.

Именно поэтому в распределённых системах очень важно разделять успешную обработку запроса и успешное завершение бизнес-операции.

Это две совершенно разные вещи. 

И кстати, здесь мы видим, почему интеграции – это не «просто API». Проблемы возникают не в момент успешного запроса. Проблемы возникают между сервисами!

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

Поэтому мой совет всем, кто только учиться проектировать интеграции – смотрите не только на ответ API, а на полный жизненный цикл операции от первого запроса до момента, когда система действительно пришла в корректное конечное состояние.

 «Альбина, а можно прийти на консультацию просто с вопросами? Не по обучению, а просто разобрать конкретную ситуацию?»

Да, можно! И в последнее время таких запросов становится всё больше.

Кто-то приходит с вопросом по требованиям, кто-то с карьерным тупиком, а кто-то просто не понимает, куда двигаться дальше в профессии.

И для меня самое ценное, когда после консультации у человека появляется ощущение «теперь картина сложилась».

Делюсь одним из недавних отзывов. Очень благодарна вам за доверие ❤️

Для меня это всегда намного больше, чем просто созвон.

Записаться на консультацию можно у менеджера @ginfotech_manager 

Чем заменить обычные транзакции в распределенных системах 

Если продолжать нашу линию про event-driven, асинхронность и рассинхрон данных, то логично ответить еще на один вопрос «А почему мы просто не обернём всё в одну транзакцию?»

В монолите это звучит разумно: есть база данных - есть транзакция - либо всё записалось, либо ничего. Но в распределённой системе этот подход начинает разваливаться. Потому что у нас уже не одна база и не один процесс, а несколько сервисов, где у каждого своя БД, свой жизненный цикл, свои очереди и задержки.

И вот стандартный кейс: создали заказ, списали оплату, зарезервировали товар, отправили уведомление. И хочется, чтобы это всё было атомарно, но проблема в том, что между этими шагами нет общей транзакции. Нельзя сказать «если уведомление не отправилось, откати оплату».

Потому что: • сервис оплаты уже мог зафиксировать списание • склад уже мог зарезервировать товар • а уведомление вообще живёт в другой системе и упало позже

И тут появляется ключевая мысль: в распределённых системах мы не предотвращаем рассинхрон, мы учимся с ним работать

Тогда что вместо транзакций? 

Рассмотрим в следующем посте. 

Итак, вместо транзакций используются несколько паттернов. Одни из популярных – Saga и Outbox.

Saga – цепочка компенсирующих действий

Идея простая – мы не пытаемся сделать всё атомарно, мы строим процесс как набор шагов.
Если шаг не удался, мы не откатываем всё в ноль, мы выполняем компенсирующие действия.

Например:
• Создали заказ
• Списали оплату
• Зарезервировали товар
❌ Не удалось отправить в складскую систему

Что делаем?

Не откатываем всё назад, а:
• отменяем резерв
• возвращаем деньги
• помечаем заказ как отменённый

Это и есть saga — управляемый процесс с компенсациями.

Важно! Компенсация не равно откат в классическом смысле, это отдельная бизнес-операция.

Outbox – гарантированная доставка событий

Теперь другая ситуация: система говорит «заказ создан – отправим событие»

Но между записью в базу и отправкой события в брокер есть риск расхождения.

Например, заказ в БД есть, а событие в очередь не ушло (упал сервис)

И вот тут появляется outbox-паттерн, вместо того чтобы сразу отправлять событие, мы:
1. пишем заказ в БД
2. пишем событие в таблицу outbox
3. отдельный процесс читает outbox и публикует события

То есть БД становится источником истины и для данных, и для событий.

Почему системному аналитику важно в этом разбираться?

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

Если упростить всё до одной мысли:
• в монолите мы боремся за атомарность
• в распределённых системах за устойчивость процесса

И именно поэтому появляются event-driven, retry с ограничениями, saga,
outbox – на самом деле это просто попытка сделать нестабильный мир управляемым.

Приоритизация требований: почему приоритеты почти всегда меняются

Приоритизация требований в теории выглядит просто: есть список задач, есть методика, есть порядок выполнения. В реальности это почти никогда так не работает.

И я уверена, что вы сталкивались с тем, что у заказчика «всё срочно, горит!», у разработчиков «всё сложно», тестировщикам всё нужно протестировать, а аналитик оказывается между этими точками напряжения и должен собрать из этого что-то, что вообще можно реализовать.

И первая ошибка, которую делают многие начинающие аналитики – они пытаются зафиксировать это как статичную картину. Мол, вот приоритеты, вот список, дальше просто делаем по порядку. Но в живых продуктах приоритеты не существуют в стабильном виде. Они постоянно двигаются. И дело вовсе не в «плохом» управлении, а в том, что меняется контекст: рынок, сроки, ограничения, зависимость от других систем. По сути это нормальная ситуация.

Но здесь появляется главный конфликт, т.к. заказчик часто мыслит задачами: «нам нужно сделать эту фичу, потому что она важная для роста», на что у разработки сразу есть ответ: «если мы это сделаем сейчас, мы сломаем стабильность». И вот если аналитик просто передаёт требования дальше, он автоматически усиливает этот разрыв. В итоге команда получает не систему приоритетов, а набор конкурирующих ожиданий.

Как с этим работать на практике? 

У меня есть проверенный алгоритм. Расскажу в следующем посте. 

Спойлер: это вообще не про таблицы и методики.

Приоритизация требований: пошаговый план действий

В прошлом посте мы разобрали, что обычная задача может превратиться в ситуацию из басни про лебедь, рак и щуку – все тянут в свою сторону.

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

1. Сначала фиксируем контекст, а не требования!

Без контекста вообще невозможно проставить приоритеты. Надо уточнить эти вопросы: 
• зачем бизнесу это нужно сейчас
• какую проблему решаем
• что будет, если не делать вообще
• есть ли дедлайн, от которого всё зависит

Что мне нравится тут – что иногда на этом этапе оказывается, что срочность не такая уж и однозначная.

2. Разделяем ценность и стоимость

Спорить, что важнее бесполезно. Лучше взять и разложить:
• бизнес-ценность (что даёт фича)
• стоимость реализации (время, сложность, риски)
• последствия откладывания
• технические ограничения

По сути тут мы просто делаем картину видимой для всех сторон.

3. Выявляем зависимости

Перед тем как ставить приоритет, всегда смотрим:
• от чего эта задача зависит
• что блокирует другие задачи
• что сломается, если сделать это сейчас

Иногда задача кажется важной, но технически она вообще не может быть сделана первой.

4. Проговариваем варианты, а не одно решение

Никогда не приходите с одним вариантом. Формулируйте так:
• делаем сейчас и берём риск X
• откладываем и теряем Y
• упрощаем и получаем компромисс Z

За всех мы не решаем, но показываем последствия решений. Очень даже логично

5. Фиксируем договорённость, а не просто список задач

И только после этого появляется приоритизация! Но! Это не просто порядок задач.

Это зафиксированное решение:
• почему именно так
• какие риски приняты
• что сознательно отложено
• кто подтвердил решение

Без этого приоритеты не сработают, т.к. распадутся при первом изменении контекста.

Итого, вы больше не человек, который расставляет приоритеты, вы управляете логикой решений в системе. Используйте в работе и ставьте реакции, если было полезно!🔥🔥

Ошибки новичков, из-за которых их не берут на работу 

Я довольно часто вижу одинаковую картину у новичков: человек вроде бы что-то знает, прошёл курс, даже умеет делать диаграммы и пишет SQL на базовом уровне. Но на собеседовании или при разборе резюме возникает ощущение, что он не понимает, как выглядит реальная работа аналитика.

Одна из самых частых причин отказа – это фокус на инструментах вместо смысла. В резюме перечислены UML, BPMN, Postman, но нет ощущения, что человек умеет решать задачу. А в системном анализе всегда оценивают не знание нотаций, а способность разобраться в ситуации и разложить её на понятную систему.

Ещё очень заметно, когда у кандидата нет ни одного живого кейса. Не учебного в стиле «интернет-магазин», а такого, где видно контекст: зачем система, какие ограничения, что может пойти не так. Без этого сложно понять, как человек думает, а именно это и проверяют.
На собеседованиях это проявляется ещё сильнее. Новички часто сразу начинают отвечать на вопрос, не уточнив деталей. Хотя в реальной работе аналитик почти никогда не решает задачу сразу. Он сначала пытается понять, что вообще происходит, кто пользователи, какие есть ограничения, где система будет ломаться. И именно это отсутствие привычки задавать вопросы сразу бросается в глаза.

Есть ещё один момент, который сильно влияет на решение – слишком идеальные представления о системе. Когда человек проектирует всё так, будто нет старых систем, костылей, ограничений бизнеса и срочных правок. В реальности аналитик почти всегда работает в условиях, где всё уже сложнее и менее красиво, и важно это учитывать.

И отдельно стоит упомянуть базовое понимание интеграций. И я уже говорила, что здесь имеется в виду, что система не живёт одна: данные приходят, уходят, ломаются, повторяются. Если этого понимания нет, это сразу видно по ответам.
В итоге проблема обычно не в том, что новичок не дотянул по знаниям, а в том, что он ещё не показывает мышление системного аналитика. Не умеет демонстрировать, как он думает, как разбирает ситуацию и как принимает решения в условиях неопределённости.
И именно это, а не список технологий, решает, возьмут ли тебя на работу/стажировку. 

Поэтому я в канале даю не какие-то отдельные инструменты, оторванные от контекста, а информацию, которая поможет понять, что такое система в целом и какие у нее есть ограничения.

Если есть темы, которые вы бы хотели разобрать, пишите в комментариях.

Как системный аналитик влияет на бизнес-метрики

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

1. Он влияет на то, что вообще будет сделано

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

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

Иногда одно правильно уточнённое требование убирает фичу, которая бы не дала никакого эффекта на метрики. 

2. Он влияет на то, как фича будет работать

Один и тот же бизнес-запрос можно реализовать по-разному. Например, с лишними шагами в процессе, неудобной логикой или доп. ограничениями.
Либо наоборот, можно упростить путь пользователя так, что конверсия растёт просто из-за уменьшения трения.

Системный аналитик здесь влияет через структуру процесса и понимание пользовательских сценариев.

3. Он снижает стоимость ошибок и переделок

Каждая ошибка в требованиях – это переработка разработки, задержка релиза и ухудшение качества продукта. И всё это напрямую влияет на бизнес: скорость вывода фич и способность компании реагировать на рынок.

Хороший аналитик уменьшает количество «мы не так поняли», и это уже влияет на экономику продукта, даже если это не видно в метриках напрямую.

4. Он делает систему предсказуемой

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

А ведь предсказуемость – это основа роста. Без неё невозможно стабильно улучшать метрики, потому что команда постоянно тушит пожары.

5. Он влияет на скорость изменений

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

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

Если проще: системный аналитик создает систему, в которой бизнес может быть успешным.

Сохраняйте этот пост, чтобы правильно понимать свою ценность!

Интеграции: дайджест постов за 2026 год

Интеграции – это то самое место, где всё работало на тесте, но сломалось на проде, где аналитик становится переводчиком между системами, которые говорят на разных языках.

Я собрала для вас посты по интеграциям в один дайджест, чтобы вы могли быстро найти ответ, когда вопрос «а как это правильно описать?» возникает в самый неподходящий момент.

Читайте, сохраняйте и используйте в работе:

• Проектирование API с точки зрения безопасности
• Почему это задача аналитика?
• Rate limiting 
• Webhooks 
• Очереди, webhooks или polling? 
• 3 вопроса, которые я всегда задаю перед описанием интеграции
• Стратегии тестирования API: о чём часто забывают аналитики
• Что такое API-first и зачем он нужен
• Стандартизация кодов и форматов ошибок в API
• Версионирование API 
• API и бизнес-логика 
• Где на практике ломаются даже правильно спроектированные API

Пишите в комментариях, какие еще темы вы бы хотели разобрать?

Самое ценное в создании образовательных продуктов – ваши #отзывы и искренняя обратная связь. 

Делюсь отзывом Регины – она работала бухгалтером и решила выучиться на системного аналитика:

«Я работаю бухгалтером, и системный аналитик – совершенно новая и неизвестная для меня профессия. На курсе мне было полезно всё. Мне очень понравилось, что курс структурированный, без воды, огромное количество информации, ненужного не было совсем: тема, выжимка по теме, тестирование, практика. Очень понравилась работа с куратором – тебе помогают, поддерживают, направляют. Это очень ценно. С практикой были сложности, но благодаря куратору все получилось, но куратор не подсказывал, а направлял тебя и твои мысли. 

Самое интересное, что после обучения сейчас на работе бухгалтером я даже по-другому начала думать, особенно в работе с отчетами, фильтрации данных и т.д. Раньше я многое собирала, выверяла «ручками», а сейчас думаю, как сделать удобнее и проще. Так что мозг я прокачала на все 100%. И несмотря на то, что изначально я решила изучить профессию для общего развития, то сейчас я намерена попробовать себя в этой роли и пройти стажировку.»

Полную версию отзыва можно посмотреть по ссылке: https://vk.com/video251822710_456239170 

Регина, благодарю за искренность и желаю удачи в новой профессии! 🚀

«ТЗ готово, но задача не двигается»: почему аналитику критично понимать процессы разработки

Знакомая картина: вы пишете подробное ТЗ, согласовываете его с бизнесом, аккуратно оформляете в Confluence… а задача тихо висит в бэклоге три недели? Или вас зовут на ретроспективу, а вы сидите и думаете: «А что я тут должен говорить?». Или на дейли разработчик спрашивает: «А это в рамках текущего спринта или кидаем в бэклог?», а вы пожимаете плечами.

Спросите себя, а вы понимаете, как вообще работает команда? Где заканчивается дискавери и начинается деливери? Почему приоритеты меняются посреди итерации? Кто на самом деле принимает решение: скрам-мастер, продакт, тимлид или заказчик? Почему в Jira всё живёт по своим законам, а в голове у разработки по другим?

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

Аналитик без понимания процессов работает вслепую:

• Пишет идеальную спецификацию, но команда работает по канбану, и задача «тонет» в потоке операционки.  
• Приходит на планирование с готовыми Use Case, а команда оценивает риски и story points, и ваше ТЗ превращается в «историю», которую надо дробить.  
• Пытается наладить коммуникацию, но не знает, где проходит граница между аналитикой, QA и продактом, и начинает делать работу за всех, выгорая на ровном месте.  

Сегодня большинство компаний живут в миксе: Waterfall на стороне бизнеса, Scrum в разработке, канбан-метрики у лида… и аналитик оказывается переводчиком, который не знает грамматики ни одного из языков.

И тут вас выручает знание процессов! Вы перестаёте «скидывать ТЗ в чат», так как: 
→ Понимаете, в каком формате и на каком этапе требование должно попасть к команде, чтобы его не переписали три раза.  
→ Видите, где процесс создаёт трение, и предлагаете решение, а не жалуетесь на сроки.  
→ Говорите с разработкой, тестировщиками и бизнесом на одном языке, потому что знаете правила игры.  

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

А вы знаете в чем различие скрама от канбана?

Надо ли системному аналитику разбираться в проектировании интерфейсов?

Не раз слышала от системных аналитиков: «Моя зона ответственности – данные, API, бизнес-логика. А как это будет выглядеть на экране, пусть дизайнер нарисует». По факту это одна из самых дорогих иллюзий в IT.

Когда требования отдаются без понимания UX/UI, запускается цепная реакция:
🔹 Дизайнер получает ТЗ в духе «пользователь вводит данные, система сохраняет». Без сценариев, без состояний, без обработки ошибок. Приходится додумывать.
🔹 Разработчик верстает форму по макету, но не понимает, как обрабатывать валидацию, блокировку кнопок или переходы между состояниями. Пишет, как видит.
🔹 Заказчик получает работающую фичу, которой никто не пользуется, потому что путь пользователя сломан на третьем шаге.
🔹 Итог: бесконечные правки, споры «кто виноват», срывы сроков и ощущение, что продукт кривой, хотя архитектура безупречна.

UX/UI – это на самом деле про предсказуемость поведения системы с точки зрения человека. Аналитик, который понимает основы интерфейсного взаимодействия, работает иначе:
→ Описывает не только что система делает, но и как пользователь это воспринимает.
→ Заранее прописывает состояния экранов: загрузка, успех, ошибка, пустое состояние, недоступность функции.
→ Ставит требования к валидации, навигации, мобильной адаптации и доступности до того, как дизайнер откроет Figma.
→ Говорит с командой на одном языке, потому что знает, что такое user flow, wireframe и почему лишняя галочка может убить конверсию.

Системный анализ без понимания UX/UI – это проектирование моста, по которому невозможно ходить. Логика может быть идеальной, но если пользователь не понимает, как ею воспользоваться, вся работа идёт в минус.

А как у вас: требования к интерфейсам фиксируются до дизайна или как получится? Делитесь в комментариях 👇

Дорогие студенты, благодарю вас за ваши прекрасные #отзывы

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

«Курс понравился, отдельно отмечу работу куратора: со мной работала Лена, по-моему это самый лучший куратор, она и поддерживала, и объясняла. Лена, спасибо тебе за работу со мной! А еще круто, что есть демособеседование с Альбиной, т.к. не всегда есть возможность побеседовать с создателем курса, тем более с системным аналитиком. 
В процессе обучения мне понравилось, что было и легко, и сложно, и было много практики. Большие темы были разделены на подтемы. Понравилось, что нет жестких дедлайнов по сдаче работ.

Как результат, я могу составлять ТЗ, базово разбираюсь в фигме, есть понимание API и его проектирования. Планирую применять знания на практике, и думаю буду еще приходить к Альбине на консультацию. Спасибо Альбине и всей команде!»

Подробный отзыв можно посмотреть по ссылке  https://vk.com/video251822710_456239171  

Алия, благодарю за теплую обратную связь! И спасибо, что доверилась и выбрала меня в качестве учителя!

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