Speaker A
Угу. Мы сейчас разберём пару кейсов. Э-э, ну, не пару, несколько, в общем. Это те кейсы, которые ты, скорее всего, столкнёшься при работе у нас.
Разбор реального кейса собеседования системного аналитика: от уточнения бизнес-цели добавления Яндекс.Pay до сценариев возвратов, таймаутов эквайринга и идемпотентности.
Key Takeaways
- Перед работой над задачей важно уточнить бизнес-цель, сценарии использования, ограничения и интеграции
- Аналитик должен продумывать альтернативные и исключительные сценарии, включая возвраты и сбои
- В платёжных системах критичны идемпотентность, обработка таймаутов и корректное статусное моделирование
- Версионирование API необходимо, чтобы не сломать старых клиентов мобильного приложения
- Ценится не единственно верное решение, а способность обосновать подход и задавать правильные вопросы
What the video covers
- Интервьюер разбирает типовые кейсы, с которыми кандидат столкнётся на работе системного аналитика
- Кейс: бизнес-заказчик (продакт-оунер) просит срочно добавить Яндекс.Pay в мобильное приложение
- Первый шаг — уточнить бизнес-цель, границы задачи и цель роста конверсии
- Выясняются сценарии использования помимо оплаты, например возвраты денег при недовольстве едой или отсутствии товара
- Обсуждаются сроки, интеграции, требования безопасности и понятность user flow
- Рассматриваются сценарии через use case: happy path, альтернативные сценарии, циклы, параллельные процессы
- Разбирается процесс расчётов с Яндекс.Pay: списание у клиента и банковский перевод денег на следующий день
- Кейс таймаута эквайринга: что показать пользователю и что делать на сервере, включая статус «платёж в обработке» и проверку статуса системой
- Обсуждаются ключ идемпотентности, версионирование API для мобильного приложения и совместимость со старыми клиентами
- Сравниваются форматы обмена данными (например, XML для банков и госструктур) и вопросы интеграций
Chapters
- 00:00Введение и формат собеседования
- 02:00Уточнение бизнес-цели и сценариев интеграции Яндекс.Pay
- 04:30Сценарии возврата и процессы расчётов
- 09:38Таймаут эквайринга и обработка платежа
- 20:00Идемпотентность и поля данных
- 22:46Версионирование API и совместимость клиентов
- 28:20Выбор форматов интеграции и внешние сервисы
- 38:46Обсуждение интеграций и архитектурных решений
Full Transcript — Download SRT & Markdown
Speaker A
Вот, это и у тебя сложится впечатление, что тебя ожидает, и для нас э-э будет понимание, как как бы ты подошёл к решению той или иной задачи. Вот, я сразу скажу, что, наверное, правильных решений нет, наверное, есть подходящее решение в зависимости от то того или
Speaker A
Вот, это и у тебя сложится впечатление, что тебя ожидает, и для нас э-э будет понимание, как ты подошёл бы к решению той или иной задачи. Вот, я сразу скажу, что, наверное, правильных решений нет. Наверное, есть подходящее решение в зависимости от того или иного подхода. Угу. Э-э, и от условий, которые к тебе приходят. Э-э, вот, поэтому интересно больше даже, как ты мыслишь.
Speaker A
Вот, и э-э как ты подойдёшь к решению той или иной ситуации. Вот, э-э первое мы, наверное, начнём, так как у нас много работы с бизнесом, представим, что к тебе бизнес-заказчик приходит там, пусть будет это продакт-оунер, говорит тебе, что нам нужно срочно
Speaker A
Вот, и э-э как ты подойдёшь к решению той или иной ситуации. Вот, э-э, первое мы, наверное, начнём, так как у нас много работы с бизнесом. Представим, что к тебе приходит бизнес-заказчик, пусть будет это продакт-оунер, и говорит тебе, что нам нужно срочно добавить новый метод оплаты, например, Яндекс.Pay. Угу. Э-э, в мобильное приложение. Какие будут твои первые шаги? Как ты поймёшь, что задача готова для того, чтобы взять её в работу и начинать описывать?
Speaker A
Угу. Так, сервис. Э-э. Какой-то сервис, э-э и мы в мобильное приложение добавляем э-э Яндекс.Pay.
Speaker A
Угу. Так, сервис. Э-э. Какой-то сервис, э-э, и мы в мобильное приложение добавляем э-э Яндекс.Pay.
Speaker A
мы хотим, чтобы ну, как бы удобней э-э смог оплачивать, чтобы больше пользователей ну, как бы подключить в нашу воронку, чтобы мы э-э Да, давай, давай будем говорить, что больше пользователей, то есть, условно, мы хотим увеличить, много клиентов обращаются и говорят, что хотят видеть
Speaker A
О'кей. Да, да, новый способ оплаты. Новый способ оплаты. Угу. Угу. Так, ну, вообще, м-м, нам нужно уточнить. Ну, наверное, я бы уточнил бизнес-цель, то есть границы задачи, что именно мы хотим дать пользователю. Ну, наверное, мы хотим, чтобы было удобнее оплачивать, чтобы больше пользователей подключить в нашу воронку, чтобы мы э-э... Да, давай будем говорить, что больше пользователей, то есть, условно, мы хотим увеличить конверсию. Много клиентов обращаются и говорят, что хотят видеть новый способ оплаты Яндекс.Pay. Угу. Так, наверное, э-э, у нас мобильное приложение, м-м, только мобильное приложение, да? То есть веба не будет?
Speaker A
Ну, хороший вопрос, да. Говорим, что пока только мобильное приложение интегрировано да. Так, э, хорошо, э, наверное, какие у нас есть, э, сценарии использования? То есть это, не знаю, может, там при оплате, а может быть там и в каком-то ещё сценарии можно его
Speaker A
Ну, хороший вопрос, да. Говорим, что пока только мобильное приложение интегрировано, да. Так, э, хорошо. Наверное, какие у нас есть сценарии использования? То есть это, не знаю, может, при оплате, а может быть и в каком-то ещё сценарии можно его задействовать? В плане: какие сценарии помимо оплаты есть? Так, смотри, у нас есть Яндекс.Pay. Э.
Speaker A
Ну возможно э вот этот Яндекс.Pay, ну, просто я я видел что э когда ну допустим в вот недавно смотрел в Яндексе, там когда оплачиваешь какую-то покупку в ресторане, то, допустим, по карте там Альфа-Банка дают -500, э, рублей именно
Speaker A
Ну, возможно, вот этот Яндекс.Pay... Я видел, что, когда, допустим, недавно смотрел в Яндексе, там, когда оплачиваешь какую-то покупку в ресторане, по карте Альфа-Банка дают минус 500 рублей именно по этой карте. То есть возможно мы сможем добавлять какой-то бонус при оплате этим Яндекс.Pay, если Яндекс будет давать какой-то кэшбэк.
Speaker A
Мм, о'кей, хорошо. Угу. А если тебе еда в ресторане не понравилась то э, и ты или там оплатил и потом ты говоришь, что тебе еда не понравилась, допустим, или ещё что-то.
Speaker A
Мм, о'кей, хорошо. Угу. А если тебе еда в ресторане не понравилась, и ты оплатил, а потом говоришь, что тебе еда не понравилась, допустим, или ещё что-то. Что происходит в этом случае?
Speaker A
Ну, да, да. А, ну, э, смотри, если еда не не понравилась, то есть, э, пользователь что делает? Он э, пишет в поддержку, э, поддержка узнаёт, э, ну, как бы пользователь может как бы и соврать, то есть это не только если еда
Speaker A
А, в нашем кейсе мы про это говорим.
Speaker A
такой сценарий есть. Да, тогда ну, э, тогда можно рассмотреть э возврат э денежных средств. Вот. Ну, то есть я я к тому, что смотри, то есть, э, я спросил, какая у нас, э, хмм, бизнес-цель, э, что мы хотим дать пользователю, а какие у нас
Speaker A
Ну, да, да. Смотри, если еда не понравилась, то пользователь что делает? Он пишет в поддержку, поддержка узнаёт. Ну, пользователь может и соврать. То есть это не только если еда не понравилась. Может быть такое, что, предположим, ресторан тоже согласен, условно, там не было какого-то товара. Такой сценарий есть.
Speaker A
есть, как скоро мы хотим вот эту вот задачу. Вот э по хмм. Какие у нас будут интеграции?
Speaker A
Да, тогда можно рассмотреть возврат денежных средств. Вот. Я к тому, что я спросил, какая у нас бизнес-цель, что мы хотим дать пользователю, а какие у нас сценарии использования, это мы проговорили. Ещё важно уточнить, какие у нас ограничения по срокам, как скоро мы хотим эту задачу. Какие у нас будут интеграции?
Speaker A
Вот э потом э чего дальше? То есть, это мы спросили, что дальше у нас э.
Speaker A
Тоже. По безопасности нужно уточнить, потому что это всё-таки платежи.
Speaker A
Понять. Ну, user flow будет. User flow будет, то есть, условно, клиент заходит, видит новый способ оплаты, выбирает Яндекс.Pay, нажимает кнопку оплатить, как бы, деньги списываются с Яндекс.Pay, мы мы начинаем отправку заказа, всё.
Speaker A
Потом что дальше? Это мы спросили. Что дальше у нас?
Speaker A
Ну, да. О'кей э. Что ещё можно сделать? Ну, ну, может, надо естественно потом э.
Speaker A
Вообще нужно понять, есть ли у нас понятный user flow, то есть пользователь заходит, нажимает, потом что дальше происходит. Это тоже нужно понять.
Speaker A
Фронт. То есть, какие там должны быть кнопки хмм вот. ещё до макета там далеко, ну, и как бы, мы ещё это не не обсудили всё до конца.
Speaker A
Ну, user flow будет. Условно, клиент заходит, видит новый способ оплаты, выбирает Яндекс.Pay, нажимает кнопку «Оплатить», деньги списываются с Яндекс.Pay, мы начинаем отправку заказа, всё.
Speaker A
Да, смотри, то есть, э, если у нас есть возврат, мы можем, ну, естественно, это всё прорабатывать через, э, use case, то есть, там можно сделать у нас, э, happy pass, можно альтернативный сценарий, можно loop, можно там.
Speaker A
Угу. Это тебе пишет продукт. Инженеры распишут, что там по поводу возвратов. Это уже твоя задача, условно, узнать, какие ещё сценарии есть.
Speaker A
С картами может, или был опыт? А именно с поддержкой? М? Именно с поддержкой, чтобы такого не было.
Speaker A
Ну, да. О'кей. Что ещё можно сделать? Наверное, потом набросать макет, прототип, как у нас должен выглядеть этот экран.
Speaker A
электронными сообщениями. А на следующий день нам Яндекс уже непосредственно зачисляет, делает банковский перевод. Угу.
Speaker A
Фронт. То есть какие там должны быть кнопки. До макета далеко, и мы ещё не обсудили всё до конца.
Speaker A
работать. Вот, как думаешь, что ещё нужно? Э, что, ну, мы продолжаем, да, про вот эту задачу?
Speaker A
Возможно, когда он услышал про... а, это нам не сделают, дурака можно было свалять, а он уже передумал, уже не делает.
Speaker A
Ну, смотри, можем ещё зафиксировать, э, там, не знаю, все роли и статусы, то есть что я имею ввиду, то есть у нас кто будет инициировать процесс, Угу.
Speaker A
Да, смотри, если у нас есть возврат, мы можем, естественно, всё это прорабатывать через use case: можно сделать happy path, альтернативный сценарий, можно loop, можно параллельные. Так, чего ещё? Это мы спросили. Ты до этого работал с картами, может, или был опыт именно с поддержкой?
Speaker A
Хороший поинт. Угу, хороший поинт. Что ещё, м? Ну, какие-то бизнес-правила нам нужно тоже, м.
Speaker A
Не, не с поддержкой, я имел в виду вообще как аналитик. Смотри, процесс по деньгам происходит так: когда деньги списываются с клиента через Яндекс.Pay, фактически они никуда не переводятся, мы просто обмениваемся электронными сообщениями. А на следующий день Яндекс непосредственно зачисляет нам деньги банковским переводом. Угу.
Speaker A
Чего ещё? Какие-то дубли могут быть условно, что м-м, ну, допустим если это повторение, допустим, если человек заказывает вот по нашему Я-Яндексу заходит в лифт, там несколько раз нажимает и уходит там одинаковые запросы, это тоже не хорошо.
Speaker A
Да, я рассказывал про взаиморасчёты. У нас есть ещё процесс взаиморасчётов, о котором продукт сейчас очень сильно задумывается, потому что он хочет просто увеличить количество операций, но при этом не задаётся вопросами, как будет работать бэк-офис. Как думаешь, что ещё нужно? Мы продолжаем про эту задачу?
Speaker A
В это время идёт запрос на наш сервер, мы идём в эквайер и не получаем ответ от эквайера, падаем по таймауту. Что мы должны показать пользователю и что мы должны сделать на сервере нашем?
Speaker A
Да, да, да, да, да. Так, о'кей. Это мы собрали. Ну, смотри, наверное, нам нужно ещё зафиксировать все роли и статусы. Что я имею в виду: кто будет инициировать процесс, кто условно платит, кто будет получать, а также куда поставить бэк-офис, отмену, возврат. Может быть, кстати, не просто возврат, а частичный возврат. Тоже прописать.
Speaker A
давай, давай ещё раз вводные я скажу. Смотри, наш сервис пошёл к эквайеру и отправил запрос, и мы упали по таймауту. Я не говорил, что ошибка произошла на стороне эквайера.
Speaker A
Хороший поинт. Угу, хороший поинт. Что ещё? Какие-то бизнес-правила нам тоже нужно добавить. Какая-то скидка может быть, или, допустим, если у нас пользователь в чёрном списке, то он не может условно пользоваться Яндекс.Платежом, условно, я не знаю.
Speaker A
Вот, так, то есть мы мы показываем пользователю ошибку и тогда мы после этого, ну, мы сможем разобраться, по какой причине у нас эта ошибка произошла и уже что-то исправить.
Speaker A
Чего ещё? Могут быть дубли, условно, если человек по нашему Яндексу заходит, несколько раз нажимает и уходит, там одинаковые запросы. Это тоже нехорошо.
Speaker A
Попробуйте попозже. Ну, например, попробуйте ещё раз оплатить. А что означает таймаут? Означает ли что, если мы не получили ответ от от эквайера, что эквайер не провёл эту операцию.
Speaker A
Давай тогда, раз мы плавно говорим об этом, представим, что клиент нажимает на кнопку «Оплатить». В это время идёт запрос на наш сервер, мы идём в эквайер и не получаем ответ от эквайера, падаем по таймауту. Что мы должны показать пользователю и что мы должны сделать на сервере нашем?
Speaker A
эквайера. Ну, вообще, на самом деле, таймаут, ну, не обязательно должен означать, что у нас операция не прошла, то есть, это Верно.
Speaker A
Если так произошло. Да, смотри, в таком случае у нас происходит ошибка. Мы пользователю показываем ошибку. Если ошибка произошла на стороне эквайринга, то это скорее всего на стороне сервиса, и тогда это уже... Давай, давай, ещё раз вводные я скажу. Смотри, наш сервис пошёл к эквайеру, отправил запрос, и мы упали по таймауту. Я не говорил, что ошибка произошла на стороне эквайера.
Speaker A
успешный ответ. Угу. То есть, нам нужно, в общем, проверить, э-э, м-м, статус, короче, то есть, э-э, что у нас, ну, за про, э-э, статус запроса, то есть, у нас, э-э, Так, можем логи посмотреть, кстати, например, э-э, тоже там будет понятно.
Speaker A
Тогда да, тогда на стороне... тогда на стороне пользователя, и тогда это будет, ну, четырёхсотые, условно, ошибки.
Speaker A
Дальше мы что попробовать? Я просто запутался немножко. Сейчас, погоди, погоди. А-а, если мы скажем, попробуйте ещё раз, и мы признаём то, что таймаут не означает, что эквайер не выполнил операцию, то мы теоретически можем сделать два списания за один заказ.
Speaker A
Вот, так, то есть мы показываем пользователю ошибку, и тогда мы после этого, ну, мы сможем разобраться, по какой пр
Speaker A
когда мы делаем этот э-э, запрос, у нас не не факт, что оплата не прошла, может, возможно, она прошла, то есть, э-э, нам, то есть, платёж мы не не должны повторить просить, э-э, чего, то есть, мы чего?
Speaker A
Ну, можем повторить, может быть, попросить клиента там зайти в мои заказы, сделать проверку статуса, то есть возможно э-э, он э-э, возможно, возможно, он завис.
Speaker A
как решение, но мы сейчас будем не грузить клиента, не будем его по кнопочке это делать.
Speaker A
Мы клиенту просто покажем платёж в обработке и ожидайте заказ создан, платёж в обработке. Зачем его заставлять самому чекать статус, когда это по идее наша система может сделать, да?
Speaker A
Да, да. Хорошо, о'кей. Ну, давай тогда определяемся, да? Фиксируем, что мы клиенту показываем платёж в обработке.
Speaker A
М-м. Пока что. Так, дальше идём по серверу. Смотрим что дальше. Да, да. Хорошо, дальше смотрим по серверу.
Speaker A
Верно? Мы не получили ответ, упали по таймауту. Что должен делать тогда наш сервис в этом случае? Какие требования мы выставим ему?
Speaker A
Угу. Так, то есть у нас запрос прошёл, мы не знаем он прошёл, не прошёл.
Speaker A
Если мы по таймауту, в общем, ответ не получаем, у нас сервис, ну, не должен э-э считывать платёж сразу. То есть его нужно, ну, мы переводим его в статус в обработке. Вот. Дальше можем э-э ну, в каком-то асинхронном э-э
Speaker A
формате проверить э-э итоговый статус э-э у платежа у у эквайера. Вот. Хорошо, да. Запрашиваем статус у эквайера.
Speaker A
Потом по факту уже обновить э-э вот этот вот статус и потом ещё у клиента.
Speaker A
Ага, хорошо. То есть мы запрашиваем статус у эквайера, и он нам говорит, предположим, операции нет. То есть, ну, до него оказалось, что запрос всё-таки не дошёл.
Speaker A
Вот, и операцию он не создал. Что мы Что мы делаем? Что делает наш сервис?
Speaker A
Так, так, смотри, э-э если получается, пользу прошёл к эквайеру, эквайер говорит, что у него нету э-э нету вообще этого Нет этого операции.
Speaker A
Операции, да. Значит, у нас запрос, ну, реально не дошёл. Вот, такое, ну, наверное, может произойти. То есть сервис у нас должен считать э, платёж э ну, не созданным, то есть, зафиксировать, короче, ошибку и попробовать как-то э, в данном случае, м, по и пользователю мы
Speaker A
уже показываем, что платёж там не прошёл. Повторить. Отменяем, то есть, условно, платёж. Пишем, что платёж не прошёл, заказ тоже отменяем и говорим, что вот не прошёл. Э, это, да, как бы одно из решений. Это, естественно, нам поможет, но я тебе так скажу, добавлю
Speaker A
ещё э, другую проблему. Это то, что у нас транзакций много, партнёры не всегда стабильно работают, а, и бывает, что они просто моргнули. Э, это 1%, 1% из всего, из всех твоих транзакций, которые ты делаешь за день.
Speaker A
Но за день мы делаем на сумму там 1 млрд руб. Ну, да. Вот. И 1% из 1 млрд ты уже как бы тратишь, э, там, сколько? 100 тыс. 100 млн.
Speaker A
Угу. Вот, 100 млн мы теряем там, условно, или там, где, ну, 10 млн. Ну, условно, это большие суммы.
Speaker A
Вот. И как бы, ну, говорю тебе, что мне не нравится эта идея, что как бы ты отменяешь платёж. Может, мы что-то другое можем сделать?
Speaker A
Э, смотри, можем, э, использовать, ну, наверное, ты говоришь про брокер, то есть, мы можем в асинхронном э формате взаимодействовать.
Speaker A
Нет, брокер нам не поможет, потому что партнёр не готов к брокеру. Это большая интеграция, это он не будет на это переходить.
Speaker A
Угу. М, ну, и плюс это долго. Мы сейчас будем это полгода делать, а я хочу решение сейчас.
Speaker A
Так, нам, смот, смотри, а нам, нам нужно, если я правильно понял, что чтобы мы вот это вот 1% не отменяли, а как-то это всё обошли, чтобы у нас полностью всё проходило, да?
Speaker A
Ну, стараться, да, то есть, условно, минимизировать всё-таки это. Угу. Так то получается, как минимум 1% всегда отказываешь и бизнес теряет свои деньги.
Speaker A
как раз таки в ручную обработку можно перевести, чтобы такие кейсы дорабатывать, не знаю. И как это будет работать?
Speaker A
Так, смотри. Давай подумаем. У нас мы остановились на том, что м мы, допустим, не получи, нам Сбер говорит, что заказа такого нету.
Speaker A
Угу. Мы это фиксируем и тогда вот на этом моменте уже можно перевести этот кейс на ручную обработку. То есть тогда уже можно уже вручную там проверить логи, например, почему так произошло там ошибку.
Speaker A
О'кей, хорошо. То есть ну он проверил и как бы видит просто, что там случился какой-то сбой сети и что дальше?
Speaker A
Так, ну случился сбой сети, тогда нам нужно всё-таки отменить заказ, если такое такое произошло.
Speaker A
Ты же не решил проблему, ты снова отменяешь. Смотри, да, давай давай подумаем ещё раз, чего. То есть он посмотрел по логам, видит, что у нас сбой сети, да, произошёл.
Speaker A
Да. Ну не важно по какой причине, на самом деле, тайм-аут случился. Смотри, нам нужно тогда, ну о'кей, давай так попробуем перевести статус в в обработке.
Speaker A
Угу. Всё равно. Дальше делаем повторную попытку там через какой-то короткий интервал, пробуем. Сотрудник это делает или как?
Speaker A
Смотри, если мы перевели на ручную обработку, э Да. сотрудник посмотрел и у нас э ошибка сети.
Speaker A
Тогда если он это видит, тогда да, сотрудник пробует ещё раз вручную это сделать. Ну ты помнишь контекст, что у меня таких операций много.
Speaker A
Угу. И 1% и ты сейчас, э, допустим, там у меня там миллион транзакций за день. И ты сейчас э я должен нанять ораву людей, которые будут каждый день 100.000 транзакций проверять вручную?
Speaker A
Да, смотри, хорошо. Давай, давай давай так. Короче, э, смотри, ещё раз. То есть у нас, э, вручную, допустим, посмотри, человек посмотрел.
Speaker A
Давай, давай давай давай тогда так. Э, вообще, пока остановимся, короче, уберём ручной. Вот э если у нас миллион транзакций, там у нас одна ошибка, один процент ошибок, э, короче, нам нужно автоматически это обрабатывать как-то, да?
Speaker A
Э, ставим, тогда мы можем поставить в очередь ну на повтор, чтобы у нас, ну, мы сделали повтор, условно. Тогда мы сможем э отказаться от ручной проверки.
Speaker A
Безопасно ли отправить на повтор ещё раз в системе наш? Так, смотри, у нас же было сказано, что, э, э, эквайер, э, отметил, что у нас нет, э такого э кейса да?
Speaker A
Нет такой транзакции, да. Нет такой транзакции. Угу. Э, значит, э, Так, ну ты ещё говорил, что у нас про- произошло сбой и он говорит, что у нас нет такой транзакции.
Speaker A
Так, насколько безопасно? Ну, вообще, не знаю, на 100% наверное, это точно небезопасно, может быть, ещё какая-то ошибка произошла.
Speaker A
Э пам-па-пам. М-м. Когда будет безопасно отправить ещё раз и не будет никаких последствий, даже если нам вернули ответ, что такой операции нет пока что?
Speaker A
быть, всё-таки тут мы можем использовать ключ идемпотентности, чтобы у нас каждый запрос был, э, идемпотентный?
Speaker A
Вот. То есть нужно убедиться, что эквайер поддерживает ключ идемпотентности и даже если повторный вызов отправить, то он не создастся ещё раз с одним и тем же ключом, он не создаст два раза одну и ту же операцию.
Speaker A
Угу. Хорошо. О'кей. Э, так, по этому кейсу всё, наверное. Спасибо. Давай тогда перейдём к следующему. А-а, а-а, мы сейчас будем обсуждать по поводу, а-а, изменений в методе для мобильного приложения. То есть, мобильное приложение общается с нашим сервером, а-а, и от сервера получает, а-а, по
Speaker A
определённому методу получает там какой-то какой-то набор данных. Сейчас мы сфокусируемся только на одном, на одном поле. Это amount. То есть, условно, раньше мобильное приложение обращается, запрашивает у сервера, и сервер ему возвращает, а-а, поле в JSON, и amount. Тип тип у этого поля строка.
Speaker A
Бизнес почему-то почему-то бизнес пришёл с этим требованием и говорит: уберите, в общем, это поле amount, вместо него, а-а, сделайте новое поле, а-а, которое будет называться, а-а, там, sum, там, я не знаю, оно будет числом, или value, а-а, и будет числом. И добавь ещё поле
Speaker A
одно это а-а, валюта, currency, и она пусть будет строкой. Вот, а старое поле уберите, оно мешает.
Speaker A
Угу. Что ты будешь делать? Поставишь так задачу разработчикам? Опишешь, начнёшь описывать или или что-то спросишь?
Speaker A
Так, у нас была пересту- пересту, да? У нас была передача данных, а-а, и бизнес сказал, что нам нужно поменять, а-а, поле. Там с amount и amount поменяем на другое с строкой.
Speaker A
Ну, добавляем два новых поля, amount убираем. Давай так. Смотри, нам нужно, ну, во-первых, уточнить, а-а, требования, то есть, а-а, задать вопрос. То есть, мы amount, короче, ну, полностью удаляем?
Speaker A
Или там, полностью удаляем? Потом новое поле у нас, а-а, в каком формате оно у нас будет?
Speaker A
Число. Так, а точно ли оно нам нужно? Это поле. Да, точно. Обязательно. Так, о'кей.
Speaker A
Э-э. Так, мы добавляем amount и добавляем ещё что? Currency, да? Да, валюту ещё. Угу.
Speaker A
М-м. Смотри, м-м, так, тут можно ещё, ну, наверное, подумать то, что у нас должно быть э-э э-э, версионирование, то есть сначала у нас, э-э, ну, старый формат, мы будем переводить потом на новый формат. Э-э, так.
Speaker A
Зачем? Э-э, ну, потому что, м-м, почему? Ну, смотри, то есть у нас, э-э, допустим, одна версия - это у нас amount, э-э, вторая версия у нас одно поле меняется, второе добавляется.
Speaker A
Вот. Да, да. Нам точно нужно добавить, чтобы, э-э, плавно потом перейти, э-э, ну, чтобы у пользователя был потом плавный переход с одной версии на другую.
Speaker A
Если это мобильное приложение внесёт правки одновременно с бэкендом, нужно ли тогда делать поддержку двух версий?
Speaker A
М-м. Так, ну, интересный вопрос. Я так не скажу. Ну, давай предположим, что, если ты, если ты всё-таки задал уточняющий вопрос, что одновременно, одновременно ведёт, то, наверное, не нужно.
Speaker A
Угу. Вот. Так э-э В чём особенность, э-э, давай, давай остановимся. Мы, в чём особенность мобильного приложения?
Speaker A
От, э-э, от веба. От веба, да. Смотри, мобильное приложение, оно, э-э, может быть, во-первых, на разных, э-э, операционных системах, то есть оно может быть на iOS, может быть на этом, Андроиде.
Speaker A
Андроиде. То есть оно, м-м, вообще, что могу сказать? Ну, оно может, э-э, обновляться не у всех пользователей одновременно, то есть поэтому у нас, э-э, всё-таки бэк должен какое-то время поддерживать старую и новую версию.
Speaker A
Угу. А фишка Да, то есть там Да, всё, всё, я понял, я понял, в чём фишка. То есть всё-таки, если у нас веб, то скорее всего можно сразу перевести. Если у нас будет мобильное приложение, тогда всё-таки версионирование нам нужно
Speaker A
добавить. Даже если будут делать одновременно, ребята, да? Потому что останутся старые версии. Да, да, да. Или, допустим, на каких-то, условно, айфонах уже может не поддерживаться эта новая версия нашего приложения.
Speaker A
Ну, это понятно тоже. Санкционный список понятно. Хорошо. О'кей, то есть мы добавляем версионирование и только в версионировании говорим о том, что вот новые поля там появляются в V2, допустим. V1 остаётся по-старому работать, возвращается только старое поле.
Speaker A
Как ещё можно решить помимо версионирования? Допустим, вот мы говорим, что нам версионирование не нужно.
Speaker A
Можно как-то по-другому то решить эту проблему? Мы говорим, что нам не нужно. Ну, точнее, мы считаем это избыточным. Я объясню, почему избыточно. Я даже могу представить кейс, когда это нужно. Когда мы не можем версионировать. Я скажу тебе так, что у меня, допустим, есть
Speaker A
у этого сервиса, который вот ты, к которому обращается мобильное приложение и получает вот этот ответ, обращается ещё 100 потребителей. Я не хочу все, а всем 100 потребителям мне не важно. Они вообще не смотрели никогда на поля amount, им это не важно.
Speaker A
И мы сейчас заставляем заставим все 100 потребителей перейти на новые вер- новые версии, для которых ничего для них не поменяется и просто будут планировать работу.
Speaker A
Так, то есть мы не будем поддерживать какой-то переходный там период и сразу, короче, всё заменим оба поля.
Speaker A
Ну, нет, я не говорил, что мы не хотим поддержать. Мы хотим ещё и поддержать этот переходный период.
Speaker A
Так, на мобилке версионирования у нас не будет, ты сказал да? Ну, мы не хотим делать версионирование, потому что мы заставим ещё 100 потребителей перейти на новую версию.
Speaker A
Так, ещё раз, повтори пожалуйста, что что нам нужно ещё, ну, что нам нужно ещё, ну, что посмотреть или что предпринять, чтобы что?
Speaker A
Какие альтернативы есть помимо версионирования, если сделать обратно несовместимые правки? Угу. Так. Так, если о'кей, версионирование мы отметаем м-м.
Speaker A
Э-э пам-пам-пам ну Можно, можно подойти к вопросу так, задуматься, а почему мы вообще придумали версионирование? Потому что, наверное, мобильное приложение смотрело на это поле, да? И как бы, если оно перестанет приходить, то она будет ломаться, так?
Speaker A
Так, а, ещё может быть то, что у нас вот новые поля, э-э, обязательными не станут все, вот эти два.
Speaker A
По старой? Не, ну, смотри, мы же, смотри, у нас было одно поле amount, мы его заменили на на на какое новое, как оно называется?
Speaker A
Value и currency. На value, на, amount мы заменили на value и добавили ещё currency. И вот у нас э-э обязательны ли, ну, старая, про старую мы не говорим, оно, наверное, было обязательное. Вот, но, новые у нас, э-э, поля, они тоже будут
Speaker A
обязательными? Ну, и, и, и оба, и оба? Да. Да, тоже будут обязательны. Э-э, ну, мы можем, так, смотри, э-э, версионирование, ну, мы точно можем поддерживать э-э ну, старый, новый формат одновременно.
Speaker A
Так. Как это будет забито? М-м, с, на переходный период, м-м, Так, смотри, у нас, давай, всё-таки углубимся. У нас есть две версии, э-э, мы должны поддерживать, обе на переходный период. То есть, мы будем два вот этих формата поддерживать
Speaker A
одновременно, то есть, э-э, э-э если м-м чего? У У какой-то должен быть адаптер на бэке. То есть мы принимаем э-э, старые какие-то данные, с- с- с- хочешь в старом формате, в новом формате, потом их, э-э, переносим в одну внутреннюю
Speaker A
модель условно. И да- дальше они у нас, э-э, конвертируются, и мы одновременно конвертируем, может быть, через шину данных это можем сделать, чтобы она как-то конвертировала.
Speaker A
Ну, то есть э-э, форматировала данные уже в одну, э-э, единый формат, короче. Вот. Так.
Speaker A
Давай на примере, я запутался. Сейчас вот у тебя Ага. был JSON, и в этом JSON'е раньше возвращался amount, а теперь возвращается, э-э, вместо amount возвращается value и currency.
Speaker A
Вот. Угу. Как можно, не вер- не добавляя версию, Э-э, ну, смотри, у нас есть JSON-схема.
Speaker A
Да. И в JSON-схеме у нас отображается, какие у нас поля, короче обязательные какие необязательные. И вот у нас тогда будет, э-э, наверное, две JSON-схемы. То есть одна будет одна, ну, короче, в старом формате, другая будет, э-э, в новом формате.
Speaker A
Так. Но мы не решили проблему, потому что у нас старая версия мобильного приложения не может, э-э, в себе изменить существующую свою кодовую базу.
Speaker A
Угу. Она с- ожидает, что будет возвращаться поле amount, а оно не возвращается. Если мы не добавляем версионирование, верно?
Speaker A
Так, смотри. Сейчас. То есть мы а- а- amount меняем на э-э value, добавляем currency, и у нас, э-э, что? В чём проблема? То есть у у нас, э-э, что? Повтори, пожалуйста.
Speaker A
Ну, проблема в том, что мобильное приложение ожидает, что в ответе будет возвращаться amount, а он не возвращается.
Speaker A
Угу. Возвращается какой-то value, который старое приложение ничего не знает. Да, то есть мы получается, да, вот эту новую версию не подготовили.
Speaker A
Так, то есть у нас старая версия мобильного приложения ожидает amount, бэк уже отдаёт value там и currency.
Speaker A
Вообще-то, то есть без без этого без версионирования у нас старый как бы бэк будет ломаться, потому что Хорошо.
Speaker A
Он имеет ли не убирать старое поле, а просто добавить два новых? Угу. Так. Ну да.
Speaker A
Мы можем просто добавить два новых. Угу. Так, и Почему вот это сработает? Что мы будем делать?
Speaker A
В чём разница? Смотри, у нас как раз-таки вот это вот JSON схема мы её поменяем и у нас будет в ней два новых поля.
Speaker A
И Угу. Так, ну тогда на бэке у нас бэк-то всё всё ещё бэк всё ещё у нас как бы привык условно к старой JSON схеме.
Speaker A
Что значит привык? Смотри, смотри ладно. Да, смотри. То есть всё-таки да, давай так, давай подумаем вот так вот. То есть он всё-таки, думаю, сработает, то есть если мы старый контракт не будем ломать, то есть у нас старое приложение
Speaker A
прочитает продолжает считывать amount. Новые клиенты ну смогут условно использовать новые поля. То есть если у нас, ну, смотри А старый Да, тоже.
Speaker A
Тоже использует новые поля? Ещё раз. Или только старые? Не, я про подумал просто ты говоришь про старые поля. Я сказал новые клиенты могут использовать новые поля, а ты спрашиваешь могут ли старые клиенты Старые клиенты с по э-э новые поля.
Speaker A
Э-э Так, смотри, ну э-э если так мы про весь версионирование не говорим да уже?
Speaker A
Ну, да, мы же говорим, что это нам не подходит. Решение. Так, тогда старые клиенты новые поля тоже должны уметь э-э использовать.
Speaker A
Вот. Подожди. И как они смогут это сделать? Даже с версионированием ты тоже не сможешь это сделать. Старый клиент работает по старому, то есть с ним ничего не сделаешь уже.
Speaker A
Так, о'кей, давай, хорошо, мы отметаем. Давай, старые клиенты э-э он типа э-э без изменений каких-то он не будет считать старые поля. Тогда у нас э-э Нет, как раз старые клиенты будут читать старые поля, а новые он не может.
Speaker A
Да, да, да, да, старые не могут. клиенты могут читать только новые поля и при этом старые поля старые поля просто игнорировать и не смотреть на них.
Speaker A
Ну, вообще тут можно, не знаю, кардинально поменять, можем какой-то э-э э-э Ну, новую вообще, короче, так новую версию апишки мы можем сделать.
Speaker A
Там Это про Мы мы немножко обнулились, мы же только что сказали, что мы не хотим использовать это. Ладно.
Speaker A
Давай э-э последний кейс проработаем, я не знаю, может ли у тебя были э-э такие случаи, когда ты э-э приносил задачу на груминг и у тебя там есть интеграция с каким-то методом или сервисом, да, э-э для получения там данных или для совершения какой-то
Speaker A
операции. Э-э и разработчик читает, ознакамливается с твоей постановкой и говорит, что э-э слушай, ну, давай мы не будем делать интеграцию с тем сервисом, который ты предлагаешь, а сделаем интеграцию с другим сервисом, к которому у нас уже есть интеграция, и будем
Speaker A
вызывать вот существующий метод. И и разработчик мотивирует это тем, что он на неделе сделает быстрее. Э-э ну, и соответственно, если продукт услышит информацию он скажет: "Да, конечно, давайте делать так, почему там делаем интеграцию с другим".
Speaker A
Угу. Вот. Согласимся мы на это, э, будем ли мы что-то подсвечивать, какие-то риски, не риски?
Speaker A
Угу. Так, э, у нас, э, м, разработчик говорит, что можем использовать другой метод, а мы изначально думали, что надо другой.
Speaker A
Так, э, ну, сразу, конечно, мы не будем, ну, не будем соглашаться вообще ни на что. То есть, если у нас есть какая-то готовая интеграция, м, Угу.
Speaker A
мы уже, как бы, какую-то, может быть, документацию подготовили, а там нам нужно заново прорабатывать, то есть, как минимум, на на это у нас времени уйдёт.
Speaker A
Э, так, ну, ты говоришь, что у нас, э, разработчик говорит, что по новой интеграции у нас как бы всё уже нала- налажено, допустим, мы это уже использовали, какой-то метод, э, и мы можем сделать это быстрее.
Speaker A
Так э Ну, используя существующую интеграцию, которая уже есть у разработчика, да, не не переходя на то, что ты указал в своей постановке и в своей ты указал какую-то новую новый сервис, Угу.
Speaker A
который разработчик ещё не делал интеграцию. Мм. Ну, смотри, нужно посмотреть ещё на, э, сами эти интеграции.
Speaker A
То есть, возможно, э, нам то, что предлагает разработчик, этот сервис, он как бы мы уже и так его используем, но, возможно, он э, не знаю, м, взаимодействует м мы мы же почему-то выбрали, э, новую интеграцию, то есть, у неё есть какие-то
Speaker A
у нас плюсы и нужно как бы проверить, э, э, отвечает ли тем же требованиям то, что предлагает, э, разработчик. Вот, то есть, то есть, возмо- возможно, смотри, то есть, про что я говорю, то есть, у нас допустим м
Speaker A
мы делали интеграцию с каким-то, э, каким-то банком. Ну, не знаю, мы мы, допустим, не банк, делаем интеграцию с банком. И у нас, э, SOAP Э-э.
Speaker A
Да. предполагается. А разработчик говорит, что э-э, нет, у нас, короче, мы мы так с REST-ом работаем, давай с REST-ом. Вот.
Speaker A
И это как бы реально можно, допустим, даже сделать быстрее. Э-э. Угу. Но, э-э, у нас тогда будет, э-э, м-м, нам это не подойдёт, потому что э-э.
Speaker A
XML, э-э, он больше подходит как раз-таки для взаимодействия с какими-то, условно банками какими-то госструктурами, потому что он э-э, более такой безопасный, более строгий.
Speaker A
Вот. Тогда в этом моменте всё-таки можно вот это вот подсветить. Так, что ещё? М-м.
Speaker A
Ну, это конкретный пример, ну, там тоже как бы есть госучреждения, которые работают по JSON-у и нормально вроде всё продаётся.
Speaker A
Кажется, это уже достаточно устаревшая информация. Если вдаваться в подробности ну я я понял твой поинт. Условно, типа, поменять формат это не не всегда, допустим, хорошо. Но мы говорим хорошо формат, допустим, тот же. Что там, что там JSON.
Speaker A
Так, смотри, возможно, э-э, Мы сегодня, кстати, обсуждали эту тему, тоже, которая вроде бы важна.
Speaker A
Угу. Так э-э смотри. Ну возможно вот э-э ту интеграцию, которую мы предполагаем, э-э, она возможно не знаю, по, э-э, не знаю, по скорости будет э-э, быстрее, чем то, что нам предлагает разработчик. И тогда, ну, и по скорости, по скорости взаимодействия,
Speaker A
например. Вот. И тогда Ну, спросим, есть ли у них SLA, насколько они быстро отвечают. Это важный поинт, да?
Speaker A
Да. Возможно, мы не выберем от этого что что какой ещё критерий влияет на выбор решения?
Speaker A
С- Так, скорость, это мы проговорили. Так, безопасность, это мы тоже проговорили на SOAP-е и REST-е.
Speaker A
Э-э. так, наверное, пропускная способность, возможно тоже. Скорость ответа выясняем, выясняем RPS, выясняем, сколько они его делают, да?
Speaker A
Так, э-э. Если у нас, э-э, уже какая-то готовая документация со стороны, ну, вот этого внешнего сервиса, то есть, возможно, там уже есть, э-э, то, на что мы можем опираться. Так, ну, и тут у нас тоже же, э-э, уже гото-
Speaker A
разра- разработчик предлагает какой-то готовый сценарий, то есть, это тоже не то. Так. Ну, возможно, там документации нет у этого партнёра, разработчик там видит в коде, что у него как бы есть, но самой документации может и нет, конечно, это
Speaker A
тоже может повлиять на решение. А, то есть, разработчик пос- сказал, что может быстрее, но, типа, про доку ничего не говорил.
Speaker A
Нет, нет. А, ну, да, то есть, нужно, условно, спросить у разработчика, ну, почему он он так думает, то есть, если у нас какая-то документация, э-э, по вот этому, э-э, интеграции к которой Нет, документации нет, но он видит в
Speaker A
своём коде. Он видит в своём коде, что вызывается такой-то метод, и всё. Там, значит, он даёт какие-то данные.
Speaker A
Так, ну, нам нужно, э-э, точно, ну, допустим, если это один разработчик э-э возможно провести э-э не знаю, ну, условно, по- покер планирование, условно, по оценке этой задачи, то есть, возможно, это какой-то разработчик, ну, вам ведь вообще джун, и
Speaker A
он вот нам она предлагает, а у нас есть, допустим, какие-то сеньоры, э-э, и они как-то могут подсветить, что тут у нас, э-э, ну короче допустим подсветить какие у нас могут быть риски, вот в в этом формате.
Speaker A
Э-э так. Ну, это мы немножко мы перекладываем уже ответственность Ну, да. в другую в другую часть команды. Давай давай мы всё-таки попытаемся сами разрулить этот вопрос. Ну, и выяснили уже достаточно много, мы выяснили по поводу RPS-а, мы выяснили по поводу
Speaker A
скорости ответа, э-э, выясняем, что по поводу есть ли нет документации у места, которое он даёт, то есть ознакомиться.
Speaker A
А что ещё важно? Так, что нам ещё важно? Давайте подумаем сейчас. Э-э. Так, какой у нас тип интеграции? Тоже типа она синхронная или асинхронная?
Speaker A
О'кей. Тут на самом деле это важно, потому что если мы там предлагаем добавить кафку, а этот этот нам сразу же говорит: "Ну, у нас тут всё да, не знаю, просто работало", то как бы это тоже нам не не круто,
Speaker A
потому что нужна отказоустойчивость, например. Чего ещё? М-м. Так, ну вообще понять, какие есть у нас ограничения и риски.
Speaker A
Так, это к чему? Как мы будем проверять эти интеграции? Чего ещё? Вообще наверное ещё по формату входных выходных данных.
Speaker A
Какие у нас обязательные поля? То есть, я к тому, что, например, у нас вот есть условно Graphql, и там у нас один endpoint, а в ресте у нас может быть много разных ендпоинтов. То есть, тут же тоже нужно смотреть,
Speaker A
чего оно подходит, это не подходит. Угу. Чего ещё? Так. Ошибки. Коды ошибок. Так, это, наверное, тоже Ну, это да, наверное, больше к документации относится. Если документация отсутствует, то, наверное, мы Идемпотентность тоже можем поговорить.
Speaker A
Угу. Угу. О'кей, хорошо. Слушай, наверное, наверное, в целом мы охватили достаточно много критериев. Я согласен, что в первую очередь, наверное, нас волнует пропускная способность. А-а.
Speaker A
Из того, что я бы, наверное, ещё посвятил, не знаю, может, сталкивался или нет, это то, что сервис может быть legacy уже, да? То есть, к которому обращаются для разработчики, его вообще планируют вырубить.
Speaker A
И разработчик может сам себе, условно, зарыл яму и сказал, что она, оказывается, вот этот метод тоже нужно тогда переделать, условно.
Speaker A
Поэтому, правильно что наверное принимать сразу решение на веру и говорить о том, что если за неделю он выполнен быстрее, это не всегда есть хорошо.
Speaker A
Скорость не самое главное, главное Да. Много много факторов, в общем, влияет на принятие решений.
Speaker A
Хорошо. Так, у меня, наверное, вопросов больше нет.
Topics:системный аналитиксобеседованиеЯндекс.Payuse caseидемпотентностьэквайрингтребованияинтервью ITаналитикаплатежи
