**РЕАЛЬНОЕ собеседование на СИСТЕМНОГО АНАЛИТИКА — Transcript & Summary | SozAI**
Source: https://sozai.app/transcript/real-systems-analyst-job-interview/

Разбор реального кейса собеседования системного аналитика: от уточнения бизнес-цели добавления Яндекс.Pay до сценариев возвратов, таймаутов эквайринга и идемпотентности.

## Key Takeaways

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

## What the video covers

- Интервьюер разбирает типовые кейсы, с которыми кандидат столкнётся на работе системного аналитика
- Кейс: бизнес-заказчик (продакт-оунер) просит срочно добавить Яндекс.Pay в мобильное приложение
- Первый шаг — уточнить бизнес-цель, границы задачи и цель роста конверсии
- Выясняются сценарии использования помимо оплаты, например возвраты денег при недовольстве едой или отсутствии товара
- Обсуждаются сроки, интеграции, требования безопасности и понятность user flow
- Рассматриваются сценарии через use case: happy path, альтернативные сценарии, циклы, параллельные процессы
- Разбирается процесс расчётов с Яндекс.Pay: списание у клиента и банковский перевод денег на следующий день
- Кейс таймаута эквайринга: что показать пользователю и что делать на сервере, включая статус «платёж в обработке» и проверку статуса системой
- Обсуждаются ключ идемпотентности, версионирование API для мобильного приложения и совместимость со старыми клиентами
- Сравниваются форматы обмена данными (например, XML для банков и госструктур) и вопросы интеграций

## Chapters

1. 00:00 Введение и формат собеседования
2. 02:00 Уточнение бизнес-цели и сценариев интеграции Яндекс.Pay
3. 04:30 Сценарии возврата и процессы расчётов
4. 09:38 Таймаут эквайринга и обработка платежа
5. 20:00 Идемпотентность и поля данных
6. 22:46 Версионирование API и совместимость клиентов
7. 28:20 Выбор форматов интеграции и внешние сервисы
8. 38:46 Обсуждение интеграций и архитектурных решений

Answers

## Questions about this video

Какой первый шаг при получении задачи добавить новый способ оплаты?

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

Что делать, если эквайер не отвечает и запрос падает по таймауту?

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

Почему важны идемпотентность и версионирование в этом кейсе?

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

## Full Transcript — Download SRT & Markdown

00:00

Speaker A

Угу. Мы сейчас разберём пару кейсов. Э-э, ну, не пару, несколько, в общем. Это те кейсы, которые ты, скорее всего, столкнёшься при работе у нас.

00:13

Speaker A

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

00:30

Speaker A

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

00:39

Speaker A

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

00:55

Speaker A

Вот, и э-э как ты подойдёшь к решению той или иной ситуации. Вот, э-э, первое мы, наверное, начнём, так как у нас много работы с бизнесом. Представим, что к тебе приходит бизнес-заказчик, пусть будет это продакт-оунер, и говорит тебе, что нам нужно срочно добавить новый метод оплаты, например, Яндекс.Pay. Угу. Э-э, в мобильное приложение. Какие будут твои первые шаги? Как ты поймёшь, что задача готова для того, чтобы взять её в работу и начинать описывать?

01:08

Speaker A

Угу. Так, сервис. Э-э. Какой-то сервис, э-э и мы в мобильное приложение добавляем э-э Яндекс.Pay.

01:17

Speaker A

Угу. Так, сервис. Э-э. Какой-то сервис, э-э, и мы в мобильное приложение добавляем э-э Яндекс.Pay.

01:34

Speaker A

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

01:50

Speaker A

О'кей. Да, да, новый способ оплаты. Новый способ оплаты. Угу. Угу. Так, ну, вообще, м-м, нам нужно уточнить. Ну, наверное, я бы уточнил бизнес-цель, то есть границы задачи, что именно мы хотим дать пользователю. Ну, наверное, мы хотим, чтобы было удобнее оплачивать, чтобы больше пользователей подключить в нашу воронку, чтобы мы э-э... Да, давай будем говорить, что больше пользователей, то есть, условно, мы хотим увеличить конверсию. Много клиентов обращаются и говорят, что хотят видеть новый способ оплаты Яндекс.Pay. Угу. Так, наверное, э-э, у нас мобильное приложение, м-м, только мобильное приложение, да? То есть веба не будет?

02:01

Speaker A

Ну, хороший вопрос, да. Говорим, что пока только мобильное приложение интегрировано да. Так, э, хорошо, э, наверное, какие у нас есть, э, сценарии использования? То есть это, не знаю, может, там при оплате, а может быть там и в каком-то ещё сценарии можно его

02:20

Speaker A

Ну, хороший вопрос, да. Говорим, что пока только мобильное приложение интегрировано, да. Так, э, хорошо. Наверное, какие у нас есть сценарии использования? То есть это, не знаю, может, при оплате, а может быть и в каком-то ещё сценарии можно его задействовать? В плане: какие сценарии помимо оплаты есть? Так, смотри, у нас есть Яндекс.Pay. Э.

02:28

Speaker A

Ну возможно э вот этот Яндекс.Pay, ну, просто я я видел что э когда ну допустим в вот недавно смотрел в Яндексе, там когда оплачиваешь какую-то покупку в ресторане, то, допустим, по карте там Альфа-Банка дают -500, э, рублей именно

02:44

Speaker A

Ну, возможно, вот этот Яндекс.Pay... Я видел, что, когда, допустим, недавно смотрел в Яндексе, там, когда оплачиваешь какую-то покупку в ресторане, по карте Альфа-Банка дают минус 500 рублей именно по этой карте. То есть возможно мы сможем добавлять какой-то бонус при оплате этим Яндекс.Pay, если Яндекс будет давать какой-то кэшбэк.

02:55

Speaker A

Мм, о'кей, хорошо. Угу. А если тебе еда в ресторане не понравилась то э, и ты или там оплатил и потом ты говоришь, что тебе еда не понравилась, допустим, или ещё что-то.

03:09

Speaker A

Мм, о'кей, хорошо. Угу. А если тебе еда в ресторане не понравилась, и ты оплатил, а потом говоришь, что тебе еда не понравилась, допустим, или ещё что-то. Что происходит в этом случае?

03:14

Speaker A

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

03:29

Speaker A

А, в нашем кейсе мы про это говорим.

03:37

Speaker A

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

03:52

Speaker A

Ну, да, да. Смотри, если еда не понравилась, то пользователь что делает? Он пишет в поддержку, поддержка узнаёт. Ну, пользователь может и соврать. То есть это не только если еда не понравилась. Может быть такое, что, предположим, ресторан тоже согласен, условно, там не было какого-то товара. Такой сценарий есть.

04:01

Speaker A

есть, как скоро мы хотим вот эту вот задачу. Вот э по хмм. Какие у нас будут интеграции?

04:10

Speaker A

Да, тогда можно рассмотреть возврат денежных средств. Вот. Я к тому, что я спросил, какая у нас бизнес-цель, что мы хотим дать пользователю, а какие у нас сценарии использования, это мы проговорили. Ещё важно уточнить, какие у нас ограничения по срокам, как скоро мы хотим эту задачу. Какие у нас будут интеграции?

04:18

Speaker A

Вот э потом э чего дальше? То есть, это мы спросили, что дальше у нас э.

04:25

Speaker A

Тоже. По безопасности нужно уточнить, потому что это всё-таки платежи.

04:35

Speaker A

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

04:45

Speaker A

Потом что дальше? Это мы спросили. Что дальше у нас?

04:55

Speaker A

Ну, да. О'кей э. Что ещё можно сделать? Ну, ну, может, надо естественно потом э.

05:02

Speaker A

Вообще нужно понять, есть ли у нас понятный user flow, то есть пользователь заходит, нажимает, потом что дальше происходит. Это тоже нужно понять.

05:09

Speaker A

Фронт. То есть, какие там должны быть кнопки хмм вот. ещё до макета там далеко, ну, и как бы, мы ещё это не не обсудили всё до конца.

05:17

Speaker A

Ну, user flow будет. Условно, клиент заходит, видит новый способ оплаты, выбирает Яндекс.Pay, нажимает кнопку «Оплатить», деньги списываются с Яндекс.Pay, мы начинаем отправку заказа, всё.

05:23

Speaker A

Да, смотри, то есть, э, если у нас есть возврат, мы можем, ну, естественно, это всё прорабатывать через, э, use case, то есть, там можно сделать у нас, э, happy pass, можно альтернативный сценарий, можно loop, можно там.

05:35

Speaker A

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

05:48

Speaker A

С картами может, или был опыт? А именно с поддержкой? М? Именно с поддержкой, чтобы такого не было.

05:56

Speaker A

Ну, да. О'кей. Что ещё можно сделать? Наверное, потом набросать макет, прототип, как у нас должен выглядеть этот экран.

06:13

Speaker A

электронными сообщениями. А на следующий день нам Яндекс уже непосредственно зачисляет, делает банковский перевод. Угу.

06:20

Speaker A

Фронт. То есть какие там должны быть кнопки. До макета далеко, и мы ещё не обсудили всё до конца.

06:36

Speaker A

работать. Вот, как думаешь, что ещё нужно? Э, что, ну, мы продолжаем, да, про вот эту задачу?

06:45

Speaker A

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

06:59

Speaker A

Ну, смотри, можем ещё зафиксировать, э, там, не знаю, все роли и статусы, то есть что я имею ввиду, то есть у нас кто будет инициировать процесс, Угу.

07:09

Speaker A

Да, смотри, если у нас есть возврат, мы можем, естественно, всё это прорабатывать через use case: можно сделать happy path, альтернативный сценарий, можно loop, можно параллельные. Так, чего ещё? Это мы спросили. Ты до этого работал с картами, может, или был опыт именно с поддержкой?

07:23

Speaker A

Хороший поинт. Угу, хороший поинт. Что ещё, м? Ну, какие-то бизнес-правила нам нужно тоже, м.

07:30

Speaker A

Не, не с поддержкой, я имел в виду вообще как аналитик. Смотри, процесс по деньгам происходит так: когда деньги списываются с клиента через Яндекс.Pay, фактически они никуда не переводятся, мы просто обмениваемся электронными сообщениями. А на следующий день Яндекс непосредственно зачисляет нам деньги банковским переводом. Угу.

07:48

Speaker A

Чего ещё? Какие-то дубли могут быть условно, что м-м, ну, допустим если это повторение, допустим, если человек заказывает вот по нашему Я-Яндексу заходит в лифт, там несколько раз нажимает и уходит там одинаковые запросы, это тоже не хорошо.

08:05

Speaker A

Да, я рассказывал про взаиморасчёты. У нас есть ещё процесс взаиморасчётов, о котором продукт сейчас очень сильно задумывается, потому что он хочет просто увеличить количество операций, но при этом не задаётся вопросами, как будет работать бэк-офис. Как думаешь, что ещё нужно? Мы продолжаем про эту задачу?

08:12

Speaker A

В это время идёт запрос на наш сервер, мы идём в эквайер и не получаем ответ от эквайера, падаем по таймауту. Что мы должны показать пользователю и что мы должны сделать на сервере нашем?

08:27

Speaker A

Да, да, да, да, да. Так, о'кей. Это мы собрали. Ну, смотри, наверное, нам нужно ещё зафиксировать все роли и статусы. Что я имею в виду: кто будет инициировать процесс, кто условно платит, кто будет получать, а также куда поставить бэк-офис, отмену, возврат. Может быть, кстати, не просто возврат, а частичный возврат. Тоже прописать.

08:45

Speaker A

давай, давай ещё раз вводные я скажу. Смотри, наш сервис пошёл к эквайеру и отправил запрос, и мы упали по таймауту. Я не говорил, что ошибка произошла на стороне эквайера.

08:55

Speaker A

Хороший поинт. Угу, хороший поинт. Что ещё? Какие-то бизнес-правила нам тоже нужно добавить. Какая-то скидка может быть, или, допустим, если у нас пользователь в чёрном списке, то он не может условно пользоваться Яндекс.Платежом, условно, я не знаю.

09:06

Speaker A

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

09:20

Speaker A

Чего ещё? Могут быть дубли, условно, если человек по нашему Яндексу заходит, несколько раз нажимает и уходит, там одинаковые запросы. Это тоже нехорошо.

09:28

Speaker A

Попробуйте попозже. Ну, например, попробуйте ещё раз оплатить. А что означает таймаут? Означает ли что, если мы не получили ответ от от эквайера, что эквайер не провёл эту операцию.

09:38

Speaker A

Давай тогда, раз мы плавно говорим об этом, представим, что клиент нажимает на кнопку «Оплатить». В это время идёт запрос на наш сервер, мы идём в эквайер и не получаем ответ от эквайера, падаем по таймауту. Что мы должны показать пользователю и что мы должны сделать на сервере нашем?

09:53

Speaker A

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

09:59

Speaker A

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

10:08

Speaker A

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

10:21

Speaker A

Тогда да, тогда на стороне... тогда на стороне пользователя, и тогда это будет, ну, четырёхсотые, условно, ошибки.

10:35

Speaker A

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

10:51

Speaker A

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

11:04

Speaker A

когда мы делаем этот э-э, запрос, у нас не не факт, что оплата не прошла, может, возможно, она прошла, то есть, э-э, нам, то есть, платёж мы не не должны повторить просить, э-э, чего, то есть, мы чего?

11:19

Speaker A

Ну, можем повторить, может быть, попросить клиента там зайти в мои заказы, сделать проверку статуса, то есть возможно э-э, он э-э, возможно, возможно, он завис.

11:30

Speaker A

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

11:37

Speaker A

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

11:47

Speaker A

Да, да. Хорошо, о'кей. Ну, давай тогда определяемся, да? Фиксируем, что мы клиенту показываем платёж в обработке.

11:56

Speaker A

М-м. Пока что. Так, дальше идём по серверу. Смотрим что дальше. Да, да. Хорошо, дальше смотрим по серверу.

12:05

Speaker A

Верно? Мы не получили ответ, упали по таймауту. Что должен делать тогда наш сервис в этом случае? Какие требования мы выставим ему?

12:14

Speaker A

Угу. Так, то есть у нас запрос прошёл, мы не знаем он прошёл, не прошёл.

12:21

Speaker A

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

12:39

Speaker A

формате проверить э-э итоговый статус э-э у платежа у у эквайера. Вот. Хорошо, да. Запрашиваем статус у эквайера.

12:47

Speaker A

Потом по факту уже обновить э-э вот этот вот статус и потом ещё у клиента.

12:52

Speaker A

Ага, хорошо. То есть мы запрашиваем статус у эквайера, и он нам говорит, предположим, операции нет. То есть, ну, до него оказалось, что запрос всё-таки не дошёл.

13:02

Speaker A

Вот, и операцию он не создал. Что мы Что мы делаем? Что делает наш сервис?

13:07

Speaker A

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

13:18

Speaker A

Операции, да. Значит, у нас запрос, ну, реально не дошёл. Вот, такое, ну, наверное, может произойти. То есть сервис у нас должен считать э, платёж э ну, не созданным, то есть, зафиксировать, короче, ошибку и попробовать как-то э, в данном случае, м, по и пользователю мы

13:38

Speaker A

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

13:58

Speaker A

ещё э, другую проблему. Это то, что у нас транзакций много, партнёры не всегда стабильно работают, а, и бывает, что они просто моргнули. Э, это 1%, 1% из всего, из всех твоих транзакций, которые ты делаешь за день.

14:16

Speaker A

Но за день мы делаем на сумму там 1 млрд руб. Ну, да. Вот. И 1% из 1 млрд ты уже как бы тратишь, э, там, сколько? 100 тыс. 100 млн.

14:26

Speaker A

Угу. Вот, 100 млн мы теряем там, условно, или там, где, ну, 10 млн. Ну, условно, это большие суммы.

14:32

Speaker A

Вот. И как бы, ну, говорю тебе, что мне не нравится эта идея, что как бы ты отменяешь платёж. Может, мы что-то другое можем сделать?

14:40

Speaker A

Э, смотри, можем, э, использовать, ну, наверное, ты говоришь про брокер, то есть, мы можем в асинхронном э формате взаимодействовать.

14:50

Speaker A

Нет, брокер нам не поможет, потому что партнёр не готов к брокеру. Это большая интеграция, это он не будет на это переходить.

14:59

Speaker A

Угу. М, ну, и плюс это долго. Мы сейчас будем это полгода делать, а я хочу решение сейчас.

15:07

Speaker A

Так, нам, смот, смотри, а нам, нам нужно, если я правильно понял, что чтобы мы вот это вот 1% не отменяли, а как-то это всё обошли, чтобы у нас полностью всё проходило, да?

15:19

Speaker A

Ну, стараться, да, то есть, условно, минимизировать всё-таки это. Угу. Так то получается, как минимум 1% всегда отказываешь и бизнес теряет свои деньги.

15:28

Speaker A

как раз таки в ручную обработку можно перевести, чтобы такие кейсы дорабатывать, не знаю. И как это будет работать?

15:35

Speaker A

Так, смотри. Давай подумаем. У нас мы остановились на том, что м мы, допустим, не получи, нам Сбер говорит, что заказа такого нету.

15:46

Speaker A

Угу. Мы это фиксируем и тогда вот на этом моменте уже можно перевести этот кейс на ручную обработку. То есть тогда уже можно уже вручную там проверить логи, например, почему так произошло там ошибку.

16:05

Speaker A

О'кей, хорошо. То есть ну он проверил и как бы видит просто, что там случился какой-то сбой сети и что дальше?

16:14

Speaker A

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

16:21

Speaker A

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

16:35

Speaker A

Да. Ну не важно по какой причине, на самом деле, тайм-аут случился. Смотри, нам нужно тогда, ну о'кей, давай так попробуем перевести статус в в обработке.

16:46

Speaker A

Угу. Всё равно. Дальше делаем повторную попытку там через какой-то короткий интервал, пробуем. Сотрудник это делает или как?

16:54

Speaker A

Смотри, если мы перевели на ручную обработку, э Да. сотрудник посмотрел и у нас э ошибка сети.

17:04

Speaker A

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

17:19

Speaker A

Угу. И 1% и ты сейчас, э, допустим, там у меня там миллион транзакций за день. И ты сейчас э я должен нанять ораву людей, которые будут каждый день 100.000 транзакций проверять вручную?

17:32

Speaker A

Да, смотри, хорошо. Давай, давай давай так. Короче, э, смотри, ещё раз. То есть у нас, э, вручную, допустим, посмотри, человек посмотрел.

17:41

Speaker A

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

17:58

Speaker A

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

18:10

Speaker A

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

18:25

Speaker A

Нет такой транзакции, да. Нет такой транзакции. Угу. Э, значит, э, Так, ну ты ещё говорил, что у нас про- произошло сбой и он говорит, что у нас нет такой транзакции.

18:36

Speaker A

Так, насколько безопасно? Ну, вообще, не знаю, на 100% наверное, это точно небезопасно, может быть, ещё какая-то ошибка произошла.

18:42

Speaker A

Э пам-па-пам. М-м. Когда будет безопасно отправить ещё раз и не будет никаких последствий, даже если нам вернули ответ, что такой операции нет пока что?

18:54

Speaker A

быть, всё-таки тут мы можем использовать ключ идемпотентности, чтобы у нас каждый запрос был, э, идемпотентный?

19:00

Speaker A

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

19:10

Speaker A

Угу. Хорошо. О'кей. Э, так, по этому кейсу всё, наверное. Спасибо. Давай тогда перейдём к следующему. А-а, а-а, мы сейчас будем обсуждать по поводу, а-а, изменений в методе для мобильного приложения. То есть, мобильное приложение общается с нашим сервером, а-а, и от сервера получает, а-а, по

19:33

Speaker A

определённому методу получает там какой-то какой-то набор данных. Сейчас мы сфокусируемся только на одном, на одном поле. Это amount. То есть, условно, раньше мобильное приложение обращается, запрашивает у сервера, и сервер ему возвращает, а-а, поле в JSON, и amount. Тип тип у этого поля строка.

19:52

Speaker A

Бизнес почему-то почему-то бизнес пришёл с этим требованием и говорит: уберите, в общем, это поле amount, вместо него, а-а, сделайте новое поле, а-а, которое будет называться, а-а, там, sum, там, я не знаю, оно будет числом, или value, а-а, и будет числом. И добавь ещё поле

20:12

Speaker A

одно это а-а, валюта, currency, и она пусть будет строкой. Вот, а старое поле уберите, оно мешает.

20:21

Speaker A

Угу. Что ты будешь делать? Поставишь так задачу разработчикам? Опишешь, начнёшь описывать или или что-то спросишь?

20:30

Speaker A

Так, у нас была пересту- пересту, да? У нас была передача данных, а-а, и бизнес сказал, что нам нужно поменять, а-а, поле. Там с amount и amount поменяем на другое с строкой.

20:44

Speaker A

Ну, добавляем два новых поля, amount убираем. Давай так. Смотри, нам нужно, ну, во-первых, уточнить, а-а, требования, то есть, а-а, задать вопрос. То есть, мы amount, короче, ну, полностью удаляем?

20:55

Speaker A

Или там, полностью удаляем? Потом новое поле у нас, а-а, в каком формате оно у нас будет?

21:04

Speaker A

Число. Так, а точно ли оно нам нужно? Это поле. Да, точно. Обязательно. Так, о'кей.

21:13

Speaker A

Э-э. Так, мы добавляем amount и добавляем ещё что? Currency, да? Да, валюту ещё. Угу.

21:19

Speaker A

М-м. Смотри, м-м, так, тут можно ещё, ну, наверное, подумать то, что у нас должно быть э-э э-э, версионирование, то есть сначала у нас, э-э, ну, старый формат, мы будем переводить потом на новый формат. Э-э, так.

21:36

Speaker A

Зачем? Э-э, ну, потому что, м-м, почему? Ну, смотри, то есть у нас, э-э, допустим, одна версия - это у нас amount, э-э, вторая версия у нас одно поле меняется, второе добавляется.

21:50

Speaker A

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

22:00

Speaker A

Если это мобильное приложение внесёт правки одновременно с бэкендом, нужно ли тогда делать поддержку двух версий?

22:06

Speaker A

М-м. Так, ну, интересный вопрос. Я так не скажу. Ну, давай предположим, что, если ты, если ты всё-таки задал уточняющий вопрос, что одновременно, одновременно ведёт, то, наверное, не нужно.

22:20

Speaker A

Угу. Вот. Так э-э В чём особенность, э-э, давай, давай остановимся. Мы, в чём особенность мобильного приложения?

22:28

Speaker A

От, э-э, от веба. От веба, да. Смотри, мобильное приложение, оно, э-э, может быть, во-первых, на разных, э-э, операционных системах, то есть оно может быть на iOS, может быть на этом, Андроиде.

22:41

Speaker A

Андроиде. То есть оно, м-м, вообще, что могу сказать? Ну, оно может, э-э, обновляться не у всех пользователей одновременно, то есть поэтому у нас, э-э, всё-таки бэк должен какое-то время поддерживать старую и новую версию.

22:56

Speaker A

Угу. А фишка Да, то есть там Да, всё, всё, я понял, я понял, в чём фишка. То есть всё-таки, если у нас веб, то скорее всего можно сразу перевести. Если у нас будет мобильное приложение, тогда всё-таки версионирование нам нужно

23:11

Speaker A

добавить. Даже если будут делать одновременно, ребята, да? Потому что останутся старые версии. Да, да, да. Или, допустим, на каких-то, условно, айфонах уже может не поддерживаться эта новая версия нашего приложения.

23:23

Speaker A

Ну, это понятно тоже. Санкционный список понятно. Хорошо. О'кей, то есть мы добавляем версионирование и только в версионировании говорим о том, что вот новые поля там появляются в V2, допустим. V1 остаётся по-старому работать, возвращается только старое поле.

23:41

Speaker A

Как ещё можно решить помимо версионирования? Допустим, вот мы говорим, что нам версионирование не нужно.

23:48

Speaker A

Можно как-то по-другому то решить эту проблему? Мы говорим, что нам не нужно. Ну, точнее, мы считаем это избыточным. Я объясню, почему избыточно. Я даже могу представить кейс, когда это нужно. Когда мы не можем версионировать. Я скажу тебе так, что у меня, допустим, есть

24:05

Speaker A

у этого сервиса, который вот ты, к которому обращается мобильное приложение и получает вот этот ответ, обращается ещё 100 потребителей. Я не хочу все, а всем 100 потребителям мне не важно. Они вообще не смотрели никогда на поля amount, им это не важно.

24:18

Speaker A

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

24:30

Speaker A

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

24:38

Speaker A

Ну, нет, я не говорил, что мы не хотим поддержать. Мы хотим ещё и поддержать этот переходный период.

24:45

Speaker A

Так, на мобилке версионирования у нас не будет, ты сказал да? Ну, мы не хотим делать версионирование, потому что мы заставим ещё 100 потребителей перейти на новую версию.

24:57

Speaker A

Так, ещё раз, повтори пожалуйста, что что нам нужно ещё, ну, что нам нужно ещё, ну, что посмотреть или что предпринять, чтобы что?

25:06

Speaker A

Какие альтернативы есть помимо версионирования, если сделать обратно несовместимые правки? Угу. Так. Так, если о'кей, версионирование мы отметаем м-м.

25:25

Speaker A

Э-э пам-пам-пам ну Можно, можно подойти к вопросу так, задуматься, а почему мы вообще придумали версионирование? Потому что, наверное, мобильное приложение смотрело на это поле, да? И как бы, если оно перестанет приходить, то она будет ломаться, так?

25:40

Speaker A

Так, а, ещё может быть то, что у нас вот новые поля, э-э, обязательными не станут все, вот эти два.

25:49

Speaker A

По старой? Не, ну, смотри, мы же, смотри, у нас было одно поле amount, мы его заменили на на на какое новое, как оно называется?

25:57

Speaker A

Value и currency. На value, на, amount мы заменили на value и добавили ещё currency. И вот у нас э-э обязательны ли, ну, старая, про старую мы не говорим, оно, наверное, было обязательное. Вот, но, новые у нас, э-э, поля, они тоже будут

26:12

Speaker A

обязательными? Ну, и, и, и оба, и оба? Да. Да, тоже будут обязательны. Э-э, ну, мы можем, так, смотри, э-э, версионирование, ну, мы точно можем поддерживать э-э ну, старый, новый формат одновременно.

26:28

Speaker A

Так. Как это будет забито? М-м, с, на переходный период, м-м, Так, смотри, у нас, давай, всё-таки углубимся. У нас есть две версии, э-э, мы должны поддерживать, обе на переходный период. То есть, мы будем два вот этих формата поддерживать

26:45

Speaker A

одновременно, то есть, э-э, э-э если м-м чего? У У какой-то должен быть адаптер на бэке. То есть мы принимаем э-э, старые какие-то данные, с- с- с- хочешь в старом формате, в новом формате, потом их, э-э, переносим в одну внутреннюю

27:05

Speaker A

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

27:18

Speaker A

Ну, то есть э-э, форматировала данные уже в одну, э-э, единый формат, короче. Вот. Так.

27:29

Speaker A

Давай на примере, я запутался. Сейчас вот у тебя Ага. был JSON, и в этом JSON'е раньше возвращался amount, а теперь возвращается, э-э, вместо amount возвращается value и currency.

27:43

Speaker A

Вот. Угу. Как можно, не вер- не добавляя версию, Э-э, ну, смотри, у нас есть JSON-схема.

27:52

Speaker A

Да. И в JSON-схеме у нас отображается, какие у нас поля, короче обязательные какие необязательные. И вот у нас тогда будет, э-э, наверное, две JSON-схемы. То есть одна будет одна, ну, короче, в старом формате, другая будет, э-э, в новом формате.

28:09

Speaker A

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

28:18

Speaker A

Угу. Она с- ожидает, что будет возвращаться поле amount, а оно не возвращается. Если мы не добавляем версионирование, верно?

28:29

Speaker A

Так, смотри. Сейчас. То есть мы а- а- amount меняем на э-э value, добавляем currency, и у нас, э-э, что? В чём проблема? То есть у у нас, э-э, что? Повтори, пожалуйста.

28:43

Speaker A

Ну, проблема в том, что мобильное приложение ожидает, что в ответе будет возвращаться amount, а он не возвращается.

28:48

Speaker A

Угу. Возвращается какой-то value, который старое приложение ничего не знает. Да, то есть мы получается, да, вот эту новую версию не подготовили.

29:02

Speaker A

Так, то есть у нас старая версия мобильного приложения ожидает amount, бэк уже отдаёт value там и currency.

29:10

Speaker A

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

29:16

Speaker A

Он имеет ли не убирать старое поле, а просто добавить два новых? Угу. Так. Ну да.

29:28

Speaker A

Мы можем просто добавить два новых. Угу. Так, и Почему вот это сработает? Что мы будем делать?

29:35

Speaker A

В чём разница? Смотри, у нас как раз-таки вот это вот JSON схема мы её поменяем и у нас будет в ней два новых поля.

29:49

Speaker A

И Угу. Так, ну тогда на бэке у нас бэк-то всё всё ещё бэк всё ещё у нас как бы привык условно к старой JSON схеме.

30:01

Speaker A

Что значит привык? Смотри, смотри ладно. Да, смотри. То есть всё-таки да, давай так, давай подумаем вот так вот. То есть он всё-таки, думаю, сработает, то есть если мы старый контракт не будем ломать, то есть у нас старое приложение

30:16

Speaker A

прочитает продолжает считывать amount. Новые клиенты ну смогут условно использовать новые поля. То есть если у нас, ну, смотри А старый Да, тоже.

30:32

Speaker A

Тоже использует новые поля? Ещё раз. Или только старые? Не, я про подумал просто ты говоришь про старые поля. Я сказал новые клиенты могут использовать новые поля, а ты спрашиваешь могут ли старые клиенты Старые клиенты с по э-э новые поля.

30:47

Speaker A

Э-э Так, смотри, ну э-э если так мы про весь версионирование не говорим да уже?

30:54

Speaker A

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

31:06

Speaker A

Вот. Подожди. И как они смогут это сделать? Даже с версионированием ты тоже не сможешь это сделать. Старый клиент работает по старому, то есть с ним ничего не сделаешь уже.

31:17

Speaker A

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

31:32

Speaker A

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

31:40

Speaker A

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

31:49

Speaker A

Там Это про Мы мы немножко обнулились, мы же только что сказали, что мы не хотим использовать это. Ладно.

31:57

Speaker A

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

32:12

Speaker A

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

32:29

Speaker A

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

32:42

Speaker A

Угу. Вот. Согласимся мы на это, э, будем ли мы что-то подсвечивать, какие-то риски, не риски?

32:48

Speaker A

Угу. Так, э, у нас, э, м, разработчик говорит, что можем использовать другой метод, а мы изначально думали, что надо другой.

32:58

Speaker A

Так, э, ну, сразу, конечно, мы не будем, ну, не будем соглашаться вообще ни на что. То есть, если у нас есть какая-то готовая интеграция, м, Угу.

33:05

Speaker A

мы уже, как бы, какую-то, может быть, документацию подготовили, а там нам нужно заново прорабатывать, то есть, как минимум, на на это у нас времени уйдёт.

33:16

Speaker A

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

33:28

Speaker A

Так э Ну, используя существующую интеграцию, которая уже есть у разработчика, да, не не переходя на то, что ты указал в своей постановке и в своей ты указал какую-то новую новый сервис, Угу.

33:41

Speaker A

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

33:50

Speaker A

То есть, возможно, э, нам то, что предлагает разработчик, этот сервис, он как бы мы уже и так его используем, но, возможно, он э, не знаю, м, взаимодействует м мы мы же почему-то выбрали, э, новую интеграцию, то есть, у неё есть какие-то

34:08

Speaker A

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

34:23

Speaker A

мы делали интеграцию с каким-то, э, каким-то банком. Ну, не знаю, мы мы, допустим, не банк, делаем интеграцию с банком. И у нас, э, SOAP Э-э.

34:33

Speaker A

Да. предполагается. А разработчик говорит, что э-э, нет, у нас, короче, мы мы так с REST-ом работаем, давай с REST-ом. Вот.

34:40

Speaker A

И это как бы реально можно, допустим, даже сделать быстрее. Э-э. Угу. Но, э-э, у нас тогда будет, э-э, м-м, нам это не подойдёт, потому что э-э.

34:54

Speaker A

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

35:03

Speaker A

Вот. Тогда в этом моменте всё-таки можно вот это вот подсветить. Так, что ещё? М-м.

35:10

Speaker A

Ну, это конкретный пример, ну, там тоже как бы есть госучреждения, которые работают по JSON-у и нормально вроде всё продаётся.

35:20

Speaker A

Кажется, это уже достаточно устаревшая информация. Если вдаваться в подробности ну я я понял твой поинт. Условно, типа, поменять формат это не не всегда, допустим, хорошо. Но мы говорим хорошо формат, допустим, тот же. Что там, что там JSON.

35:38

Speaker A

Так, смотри, возможно, э-э, Мы сегодня, кстати, обсуждали эту тему, тоже, которая вроде бы важна.

35:46

Speaker A

Угу. Так э-э смотри. Ну возможно вот э-э ту интеграцию, которую мы предполагаем, э-э, она возможно не знаю, по, э-э, не знаю, по скорости будет э-э, быстрее, чем то, что нам предлагает разработчик. И тогда, ну, и по скорости, по скорости взаимодействия,

36:10

Speaker A

например. Вот. И тогда Ну, спросим, есть ли у них SLA, насколько они быстро отвечают. Это важный поинт, да?

36:15

Speaker A

Да. Возможно, мы не выберем от этого что что какой ещё критерий влияет на выбор решения?

36:22

Speaker A

С- Так, скорость, это мы проговорили. Так, безопасность, это мы тоже проговорили на SOAP-е и REST-е.

36:29

Speaker A

Э-э. так, наверное, пропускная способность, возможно тоже. Скорость ответа выясняем, выясняем RPS, выясняем, сколько они его делают, да?

36:41

Speaker A

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

37:00

Speaker A

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

37:12

Speaker A

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

37:20

Speaker A

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

37:34

Speaker A

своём коде. Он видит в своём коде, что вызывается такой-то метод, и всё. Там, значит, он даёт какие-то данные.

37:40

Speaker A

Так, ну, нам нужно, э-э, точно, ну, допустим, если это один разработчик э-э возможно провести э-э не знаю, ну, условно, по- покер планирование, условно, по оценке этой задачи, то есть, возможно, это какой-то разработчик, ну, вам ведь вообще джун, и

37:55

Speaker A

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

38:09

Speaker A

Э-э так. Ну, это мы немножко мы перекладываем уже ответственность Ну, да. в другую в другую часть команды. Давай давай мы всё-таки попытаемся сами разрулить этот вопрос. Ну, и выяснили уже достаточно много, мы выяснили по поводу RPS-а, мы выяснили по поводу

38:23

Speaker A

скорости ответа, э-э, выясняем, что по поводу есть ли нет документации у места, которое он даёт, то есть ознакомиться.

38:31

Speaker A

А что ещё важно? Так, что нам ещё важно? Давайте подумаем сейчас. Э-э. Так, какой у нас тип интеграции? Тоже типа она синхронная или асинхронная?

38:46

Speaker A

О'кей. Тут на самом деле это важно, потому что если мы там предлагаем добавить кафку, а этот этот нам сразу же говорит: "Ну, у нас тут всё да, не знаю, просто работало", то как бы это тоже нам не не круто,

38:57

Speaker A

потому что нужна отказоустойчивость, например. Чего ещё? М-м. Так, ну вообще понять, какие есть у нас ограничения и риски.

39:07

Speaker A

Так, это к чему? Как мы будем проверять эти интеграции? Чего ещё? Вообще наверное ещё по формату входных выходных данных.

39:20

Speaker A

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

39:35

Speaker A

чего оно подходит, это не подходит. Угу. Чего ещё? Так. Ошибки. Коды ошибок. Так, это, наверное, тоже Ну, это да, наверное, больше к документации относится. Если документация отсутствует, то, наверное, мы Идемпотентность тоже можем поговорить.

39:56

Speaker A

Угу. Угу. О'кей, хорошо. Слушай, наверное, наверное, в целом мы охватили достаточно много критериев. Я согласен, что в первую очередь, наверное, нас волнует пропускная способность. А-а.

40:09

Speaker A

Из того, что я бы, наверное, ещё посвятил, не знаю, может, сталкивался или нет, это то, что сервис может быть legacy уже, да? То есть, к которому обращаются для разработчики, его вообще планируют вырубить.

40:21

Speaker A

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

40:31

Speaker A

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

40:42

Speaker A

Скорость не самое главное, главное Да. Много много факторов, в общем, влияет на принятие решений.

40:51

Speaker A

Хорошо. Так, у меня, наверное, вопросов больше нет.

Topics: системный аналитик собеседование Яндекс.Pay use case идемпотентность эквайринг требования интервью IT аналитика платежи

Учить по этому видео

- [Карточки по этому видео](https://sozai.app/ru/tools/flashcard-maker/?from=transcript&id=87561)
- [Тест по этому видео](https://sozai.app/ru/tools/quiz-generator/?from=transcript&id=87561)
- [Кроссворд по этому видео](https://sozai.app/ru/tools/crossword-maker/?from=transcript&id=87561)
- [Филворд по этому видео](https://sozai.app/ru/tools/word-search-maker/?from=transcript&id=87561)
- [Шпаргалка по этому видео](https://sozai.app/ru/tools/study-guide-maker/?from=transcript&id=87561)

Бесплатно, составлено ИИ по этой расшифровке. Без регистрации.


---
This is the markdown twin of https://sozai.app/transcript/real-systems-analyst-job-interview/ — the same content, without the markup.
Published by SozAI (https://sozai.app). Reuse and quotation are allowed with attribution and a link back.
Machine-readable index: https://sozai.app/llms.txt · data API: https://sozai.app/api/