ЗП 300к! СОБЕСЕДОВАНИЕ на СИСТЕМНОГО АНАЛИТИКА

Ищем сейчас системного аналитика. Занимается у нас взаимодействием с госорганами. Это получение разного рода запросов на эти запросы по системам банка и предоставление ответа. Это если кратенько. А у нас микросервисы, Java, Kafka. Ищем системного аналитика по скилам.

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

Где-то на уровне middle, а я проведу техническую часть собеседования. С нами ещё это владелец продукта и это системный аналитик на этом проекте.

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

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

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

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

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

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

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

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

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

Хорошо. Ну, в системном анализе уже 4 года, последние два с половиной года работаю в компании как вендор, и от него где-то последние полтора года на проекте. Что за проект? Это автоматизация кредитного конвейера, систем взыскания. Если попроще, в общем, система, которая помогает банку обрабатывать кредиты, работать с задолженностями, то есть от принятия решений по клиенту до процесса взыскания. Также в системе у нас есть админка, с помощью которой сотрудники банка, операторы колл-центров, коллекторы, специалисты бэк-офиса могут отслеживать статусы по задолженностям. Проект достаточно сложный, то есть у нас много интеграций, высокая нагрузка, логика с высоким влиянием на деньги банка. Внутри у нас есть две модели: одна помогает понять, с каким случаем сложности нужно работать в первую очередь, ещё одна помогает оценивать, насколько вероятно нам вернуть деньги. Что ещё? Интеграция с госсервисами, по брокерам у нас Kafka. Немножко расскажу про задачи, которые я делаю. Начну с требований. Требования поступают в достаточно высоком формате от продакта. Я их собираю, уточняю, формализую, потом декомпозирую до уровня пользовательских кейсов. Дальше перевожу в ТЗ для разработчиков. Описываю API-контракты, у нас REST, то есть продумываю схему взаимодействия между сервисами. По базам работаю, у нас на проекте это PostgreSQL и Oracle, пишу SQL-запросы на уровне джойнов, агрегатных функций, подзапросов. Всё, что касается бизнес-процессов, это BPMN, можно писать flow. Ну и подсказываю разработчикам, если что-то непонятно в доке. Могу помочь тестировщику прогнать основные моменты в Postman. По команде у нас три бэка, два фронта, два мобильщика, два тестировщика, два стейкхолдера. Вот мой коллега. Что ещё? Проект тоже на Java, вроде. Что вспомнил? Угу.

Там могу помочь тестировщику прогнать какие-то основные моменты в постмае. По самой команде у нас три БКА, два фронта, два эмльщика, два тестировщика, два стентика. Вот я мой коллега. Так, у нас чего ещё? И сам проект у нас тоже на джаве, вроде. Что

Хорошо. А расскажи поближе к твоей зоне ответственности. Процесс, я так понимаю, большой, и, наверное, этим занимается не одна команда.

А вот какая именно твоя часть часть, за какой функционал ты отвечал, отвечаешь. Угу. А, и, ну, чуть по техничке, там тоже говоришь много ростов. Что за рысты? как используете там, опять же, что проектировал сам с нуля, там что

Какая именно твоя часть, за какой функционал ты отвечал, отвечаешь?

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

Угу. И по технике: ты говоришь, много REST-ов. Что за REST-ы, как используете, что проектировал сам с нуля, что дорабатывал, как строится работа?

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

Угу. Ну, в общем, про мою зону. Давай начну. У меня это в основном функционал взыскания и интеграции, которые связаны вокруг него. Я отвечал за сбор и формализацию требований, то есть декомпозицию до уровня user story и use cases, проектирование бизнес-процессов в BPMN. Также всё, что касается интеграции между микросервисами, внешними системами. Если поконкретнее, я проектировал API-контракты взаимодействия между сервисами, участвовал в проектировании БД, писал SQL.

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

Давай добавим деталей. Взаимодействие между какими системами? Что это было за взаимодействие, именно что проектировал, для чего, какие функции?

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

Ты про то, что касается REST, да? Или ты имеешь в виду SOAP? Про что рассказать?

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

Ну да. Ты в принципе можешь начать с того, что тебе ближе. Если что, потом уточню вопросы.

взаимодействию ну допустим с ну автомизирова системы и ML там в основном через Rest с госсервисами, ну, через SUAP, вот фоновые там обновления статусов шли через скавку.

Так, по сервисам. Смотри, у нас было несколько. Один сервис это автоматизированная банковская система: там лежали договоры, остатки, статусы, задолженности, операции. Также два микросервиса, как я говорил вначале: они отдавали скоринг и приоритет обзвона. Ещё интеграции с госсервисами: ФНС, ФССП через SMEV3, для проверки задолженности и дополнительных данных по договорам. Взаимодействие с автоматизированной системой и ML в основном через REST, с госсервисами через SOAP, фоновые обновления статусов шли через Kafka.

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

Вот. Или подробнее что-то ещё? Над какой значимой фичей работал в недавнем времени?

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

Давай расскажу про проект автоматизации исков и запуска юридического этапа. Я прорабатывал иск о взыскании задолженности. То есть когда клиент уже не платит, мы запускаем hard collection, чтобы подать иск. Я прорабатывал флоу от верификации данных до формирования и передачи пакета документов на иск. Конкретно я описывал контракты между автоматизированной банковской системой, BPM-движком, сервисом генерации документов, прорабатывал статусы, ошибки, краевые сценарии: например, что делать, если не хватает данных или они не прошли валидацию. Участвовал в проектировании автоматического запуска процесса после наступления нужных условий, согласовывал логику с BA, тестировщиком и продактом. По результатам мы ускорили запуск юридического этапа.

проектировании автоматического запуска процесса в комунде, то есть после наступления нужных условий, но также согласовывал логику с БКОм, тестировщиком там, ну, и доктонером в целом. То есть по результатам, то есть мы ускорили запуск юридического этапа.

А расскажи, от кого поступали требования и как, если у тебя возникали вопросы, ты их уточнял?

Угу. Ну, требования в основном поступали от продуктонера. Вот у него и уточнял. А это дистанционный формат у тебя удалёнка была или в офисе взаимодействовали?

Угу. Требования в основном поступали от продакта, у него и уточнял.

Угу. Так, ну фиксировал конфлюненсы. Вот если ты про это, а кто-то валидировал потом эти требования, договорённости требования.

Это дистанционный формат, у тебя удалёнка была или в офисе взаимодействовали?

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

Удалёнка. Вопросы задавал через Яндекс Телемост, созванивались. Если надо было что-то фиксировать или был большой объём информации, как вы это делали?

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

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

на этом звонке скорее всего будет с его стороны ээ ну разговор на высоком тонах.

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

Вот это А ты, ну вот проводил эти встречи, интервью для каких целей заказчикам? Угу.

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

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

Угу. А ты системным аналитиком был в команде один или кто-то ещё был? Два у нас было. Вы друг друга дополняли или у каждого своя зона ответственности?

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

Вот так. А что у тебя было в твоей аналитике? Как строился документ? Какая структура была киданы? Ты туда добавлял обязательно?

Что там описывал? В общем, на что обращал внимание? Угу. Так, ну, если мы говорим про то, что я уже писал confluency, то есть то, что у нас получается касается мм интеграции, то есть это у нас чего, то есть, ну, условно цель, там,

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

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

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

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

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

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

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

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

Вот так. Угу. Так-с. О'кей. Давай немножко по прямо базовым вопросам пройдёмся. Какие виды архитектуры ты знаешь?

Угу. Ну давай так начнём. Смотри, какие у нас есть архитектуры. У нас есть монолит, ээ у нас есть микросервисы, у нас есть бессервисная, у нас есть сервисноориентированная.

Вот там, вроде бы, так. Плюсы, минусы монолита и микросервисов. Ага. Давай. Ну, монолит он плюсы монолита в том, что его быстрее запустить.

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

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

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

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

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

А, о'кей. Э, что такое SUAP? В чём разница? Угу. Так, ну, вообще R - это архитектурный стиль для построения м ну архитектурный стиль, короче, который обычно работает поверх HTTP, то есть чаще он передаёт JSON, также может XML условно, ээ, чего, ну,

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

или legacy. Вот там больше формулизация. Можно jon передать, да? Нет. А XML в росте можно.

Чем в целом отличается XML Jon? Угу. Зачем их два одну и тоже в целом?

Ну, Jonще, понятней, короче, в общем, легче читается. Вот. А XML он такой, ну, более тяжёлый, более старый, вот для таких строгих прям схем. Вот. Не знаю, нормально ли объяснил.

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

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

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

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

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

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

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

Нормально. О'кей. А из чего состоит апизапрос? Угу. Так, ну, про апи запрос. У нас есть метод, у нас есть чего? URL, м, header, body, м, query passam.

Угу. А в чём отличие get и пост? Ну, getст get нам нужен для получения данных, пост для создания.

А можно ли передать тело в гите? М, да. Можно. А зачем? Да типы ошибок HTTP.

Смотри, 100 информационные, 200 окей, 300 перенаправление, 400 ошибка клиента, 500 ошибка сервера. Ок. Так. Ок. А так-с.

Что такое демпотентность? Угу. Ну, идемпотентность - это такое свойство, когда у нас повторное совершение запроса не даёт такой же результат, как какой первый. Вот это если вкратце. Вот продолжение нормально. Ну если по методам getp delete идентетный постпач не

идемпотентный. Как сделать идемпотентными? Мм, что именно? А, ну сумоч включает допотентности наверное. Угу. Как он определяется?

Чего? Ну как? Обычно типа UUID вот это или про что? Ну, исходя из каких соображений, кто его формирует ещё раз? Кто его формирует и зачем он нам нужен?

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

Угу. Ну на стороне мм нашего БКА мы его формируем вот чтобы и потом уже передаём. если я правильно понимаю.

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

Чем отличается от heaving? Угу. Ну, вин у нас после группировки идёт вду. Какиефуфу. Так, у тебя только были запросы данных.

DML оди, да? То есть смотри ещё раз. Ну, на уровне джоинов агрегатных функций подзапросов. Вот так вот.

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

таблицу. Ты про это спрашиваешь? Да. Ну, а-э, это тестовые какие-то таблицы или это проект?

Ну, в в самом нашем проекте как добавлял. Угу. Ну, через интерфейс или запросами? Ну, запросами.

Откуда запросы брал? Ну, смотри, ты спрашиваешь продель типа там типа create alter и дроп. Вот это вот, да?

Ну, условно, я не помню, спрашиваешь типа, как я прописывал запрос там create или что?

Ну, откуда у тебя пришло знание, как написать этот запрос? Ну, какое у table, как мне пришло или Ну, да, ну, в плане я не очень понимаю, типа, откуда мне пришло зна, что нам нужно создать таблицу или, допустим, там, не

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

Не, ну условно то, что create - это создать ээ таблицу - это как бы ну синтаксис из общих знаний.

А ладно, давай чуть по-другому спрошу. Иишками пользуешься какими-нибудь в работе? М да. Какими? Для каких целей?

Ну допустим м, когда вот смотри, допустим, когда м не знаю, какой-то очень сильный подзапрос может надо написать, допустим, могу прогнать условно, да, какие-то обычные, типа там GPT или PSК. Вот. Ну, естественно, я по 10 раз проверяю, как бы правильно записан записан запрос, всё

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

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

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

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

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

Так-с. А чуть-чуть про Кавку. Что такое партиции? Угу. Ну, партицы - это части топика.

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

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

Вот. А какие есть ограничения по партиям и консюмерам? Ты про гарантии доставки спрашиваешь или именно вот про Нет, скорее, кто может, сколько одновременно читать консюмеров партицию, как они её читают.

Угу. Так, ну смотри, мм, у нас есть, допустим, то, что если мы говорим про группу консюмеров, то они могут одновременно читать один топик.

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

Для чего их делят на группы? А, ну для того, чтобы какую-то информацию, которая подходит как бы и для того, для того консюмера, они как бы вместе как бы считывали, чтобы по отдельности не читали.

Угу. Если это одна группа, сейчас последнюю секунду связь плохо. А если это одна группа консюмеров, то в отношении партиции какие ограничения действуют?

Угу. Ну, может, ты имеешь в виду порядок, типа, что они там друг с другом словно читают?

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

А с чем связано это ограничение? Ээ, ну, с тем, что, допустим, нельзя как бы одновременно одну партису читать и в неё записывать. Вот так. Ладно.

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

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

То есть удобство, смотри, да? То есть мы, когда мы нормализуем, мы там убираем дубли, у нас меньше аномалий. Вот обычно вот так.

Какая самая одна из самых распространённых нормальных форм? Ну, третья. В чём её особенность? Основные критерии.

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

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

Угу. Условно, то, что нам нужно было базу нормализовать. Вот. И ты про вот это говоришь, да? Ну или были какие-то моменты, которые ты говоришь: "Ну, не здесь надо, допустим, отдельно это хранить".

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

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

А скажи, почему ищешь работу? Угу. Ну, как я уже в начале упоминал, я устроен, условно в Вендере на проекте. Вот текущий проект у нас завершается, а новых не предвидите, но мне так в компании говорят. Я, в принципе, как бы

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

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

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

А сейчас, сори. Ну, давай разберём твои вопросы. У нас ещё есть практическая часть, мы не посмотрели.

Вот как раз делаем немножко передышку, наверное, этот умственную. Разберёмгутвои вопро 5 минут, да? 5 минут поспрашиваю.

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

Что-то автоматизировано, что-то у нас оперцентр по почте отвечает. Мы занимаемся автоматизацией ручных процессов и, а, так скажем, созданием новых согласно законодательству.

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

У, а что за ML-модели? Какой у них функционал? Это, какие результаты были достигнуты? Ээ, ну, то есть у нас простомодели прямо непосредственно не были связаны именно с, м, с интеграцией с госорганами. Или ты хочешь просто промальмодели? А нет, я

просто думала, что именно, ну, именно на этом процессе вы внедрили. Мне стало интересно. Нет.

Угу. Всё понятно. То есть с госорганами вы точно так же. Это ФССП получается, да?

Да. И ФНС. Угу. Всё понятно. Так подскажи пожалуйста по десятибалльной шкале как системный аналитик, как себя оцениваешь?

Угу. М ну наверное на восемь. То есть есть куда расти. Угу, конечно. Куда бы хотелось расти? Кингвича через 5 лет.

М, ну, через 5 лет ну до конца, в общем, я не прямо поопределился. Хотя бы, наверное, быть либо лидом системы, уйти в менеджмент, либо архитекторам, наверное, больше в архитектуру. Вот пока как бы и в ту сторону всё нравится. Вот.

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

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

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

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

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

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

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

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

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

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

Угу, понятно. А ты в Москве, да, проживаешь? Да, да, готов там, не знаю, день раз в неделю или парочку приезжать к нам в офис?

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

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

Вот. Да, это было бы отлично. Ну вкратце да, задавай. У нас не очень много времени, но 5 минут.

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

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

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

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

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

Вот с нами Хрупина Надежда. Это тоже наш ведущий системный аналитик. Она у нас в Ростове. А один тестер Катя в Пензи, а все остальные в Москве.

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

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

строил. Хорошо. Ну, последней, наверное, задам. А какие вот основные задачи, которые система аналитик делает на проекте?

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

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

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

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

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

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

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

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

там сходить к системному аналитику, там выставить change request, запрос на то, чтобы нас взяли там в бэклок подключили и так далее. Э собрать тоже информацию, что за методы там, как они ведутся. Есть ещё, мм, не знаю, там, насколько это тебя будет

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

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

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

Ходил на собеседование. Есть ли оферы уже? Угу. Ну прямо именно офера у меня нет.

Ну конечно, да. То есть во многих компаниях, то есть где-то там на уже там прошёл техничку, где-то там teamфиit, вот жду обратную связь. Вот так, то есть активно ищу.

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

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

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

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

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

М, вроде, вроде вижу, да? Так-с. М. Хх. Чего? Запрос сделаем. Ответ. Договор создан. Ошибка резервирования.

Угу. Мм. Так. То есть у нас уже на вот этом этапе произошла ошибка. Угу.

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

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

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

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

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

Угу. Так. М. Ну, смотри, то, что у нас тут договоры, у нас тут резервирование счёта. Угу.

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

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

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

его мм ну зарезервировать наш счёт, вот, чтобы там, ну, Да, вот так. Я думаю, так.

Мм. Так, а давай разберём ситуацию. Вот у нас отправили запрос, он лёг, да, на втором шаге, когда резервирование счёта.

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

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

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

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

Попробовать может повторно выполнить операцию? Мм, да, может пробовать повторно. А расскажи трассировку кратенько, сделай, что в этот момент будет происходить.

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

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

системе? Чего? Так, ну это мы, смотри, мы же отправили мм ещё раз. Мы же мы отправили с отсюдасюда статус. Ну, наверное, на БКЕ. А нет, смотри, на этой на БДшке вот, то есть у нас, смотри, вот и открытие счёта, и

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

Угу. Да. Тогда тогда в БД вот этого резервирование счёт мы до него не достучались.

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

Ээ так, ну тогда, да, всё-таки ты прав на тогда на бдшке вот этого FP договора.

Вот там будет у нас этап статус Fed. Вот что мы не смогли. Какие ещё статусы будут ФП договора?

Угу. Ну, наверное, у нас будет статус всё хорошо. Не знаю. Ок. Ээ процессинг, то, что у нас происходит, вот эта вот операция. М, чего, наверное, пока хватит трёхтусов.

Ну и fail, да, ты предлагал ещё fail processing там и о'кей. Угу. А, а для чего ФП договор? Надо знать, что у нас дальше с операцией произошло.

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

потому что у нас уже прошёл. А если он там статус у нас processing, тоже самое, а вот если статус FA у нас всё-таки, то тут уже м, наверное, будет будет у нас плохая ситуация, потому что м если мы

знаем, что у нас на ФП договоре статус Feld, то тогда м нет, почему плохая?

Тогда наоборот хорошая, что можем всё-таки сделать Redй. Вот. А, а скажи, ФП договор узнает о том, что процессинг или фейт у нас с операции, как он будет узнавать это?

Да ну, смотри, мы же м от ФП договора мм м а смотри, смотрим эту схему. Так, ещё раз. Так, секунду. Мм так. ВП договор у насправляет запрос. Статус мы храним, допустим, у нас всё хорошо. Отправили сюда. Ээ, так. Ну, он это будет знать ээ

от нашего оркестратора. Вот. Мм просто ещё раз послушал ваш вопрос. М ты предлагаешь как я услышал, чтобы мы хранили статус операции ФП договор. Ну, то есть там а создан договор в процессе, да там Угу.

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

Вот. Потому что договор-то как бы у нас ну вот в этом случае у нас он создался.

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

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

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

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

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

Что будет ключом? Угу. Ключ. Так, ещё раз. Напрос на создание договора. М. Так, смотри, то есть у нас будет какой-то там номер договора. Мм, чего? Ну, наверное, вот номер договора будет ключом.

Одного номера договора достаточно. Мм, смотри, так у нас у клиент существует наш. Ну, наверное, данные там, ну, возможно, смотри, номер расчётного счёта, мм, номер договора, ну, и, возможно, данные клиента, то есть там имя, фамилия, там паспортные данные.

Мм, откуда берётся номер договора? Хорошо. Так, тут нужно всё-таки подумать. Номер договора у нас мм создание договора всё-таки, да? Номер договора появляется у нас на на ФП договор. М спрос так запрос на закрытие счёта. Запрос на задание договора. Ээ

да, всё-таки давай пере пере перерасскажу. Номер договора у нас появляется на ФП договор. Вот. И тогда мм чего, чего? Ммх тогда смотри, по-другому скажу. То есть ключом П даной ситуации у нас будет так. То есть, ээ, то, что касается

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

Ну, наверное, просто какой-то, ну, ключей ДПТ, не знаю, может быть, с помощью UID можем сделать.

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

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

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

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

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

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

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

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

счёта? Не клиент через 3 дня, да, с пятницы, субботу, воскресенье он отдыхал. Угу. В понедельник приходит, опять открывает своё приложение, жмёт кнопку "Открыть расчётный счёт".

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

Да, я думаю, тут нужно добавить мм всё то, что касается мм времени работы нашего запроса. Вот ээ допустим там Acccessor Airfash Toen. Возможно, ты про это вот это говоришь.

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

Угу. Истекает срок. Допустим, ты как системный аналитик, ээ если у тебя такой вопрос: "Сколько хранится ключ и как его обновлять, как ответишь на этот вопрос?" Угу. Ну, тут вопрос про то, что как именно я отвечу или у кого-то спрошу ли

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

моих знаний не хватает, тут уже нужно сходить, спросить у архитектора, если у нас он существует.

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

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

Угу. Так. Ну, смотри, номер договора у нас существует, он меняться не будет. Мм, но у него будет там время создания договора. Если мы там новый создаём, он будет меняться.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Угу. Как мы от них избавляемся? Смотри, мы можем добавить ээ мм к нашему договору в этот нашу в таблицу наших договоров, ну, ээ строку Create, ээ, и тогда у нас будет время жизни нашего договора. Ты сказал день. Ну и

получается, мы там в конце дня м или там, ну, у нас же получается сколько? 24 часа м будем ходить к Не, давай так или нет? Ты на сказал про то, что у нас если условно там 8:00 утра договор создан и там, допустим, да,

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

Так, а мы - это кто? Ээ кто мы? Ну вот этот вот наш сервис оркестратор, открытие счёта, да?

А ему это нужно. Мм. Так, смотри, ну давай подумаем ещё раз. Да. Давай. Так. А как он будет ходить?

Угу. Э, смотри, ну, у нас это будет БД в нашем вот этого оркестратора. И он, ну, то, что я сказал, он будет, ну, вот если у нас до конца дня 0:0 нам нужно договор нездельным, то вот в 0: он, э, сходит и, ну, в БД в свою и

все м договоры, где у нас creт это сегодняшнюю дату, он их ээ как бы поменяет там статус на чего closed или как там failed.

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

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

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

Вот. Ээ, наверное, ещё статус ему надо учитывать. Так, статус смотри. Сейчас подумаю. Ну, одного ж кэйта будет недостаточно.

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

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

И дальше, ээ, мы их выбрали, и нам нужно поменять статус на cl в этих ээ как мы их передадим. Что это будет за метод? Как будем вызывать, как передавать?

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

допустим, пост там наши м контракты м которые там давай так, пост contracts, с, наверное, close. Вот. Или с помощью патча, то есть можем контрак, да, вот, наверное, лучше патч патч контракт статус. Вот. И статус меняем.

Угу. Все передаём за раз. М. Так, ну смотри чего. Ну смотри, если у нас 100 договоров, то не давай так. Если у нас 10 договоров, то можем за раз. Если 100, ну тогда вот уже лучше, наверное, воспользоваться асинхронным методом,

кавкой. Угу. Давай пока этот к этому Я согласен, что здесь это будет удобней. Перейдём. Блин, время переходить уже нету.

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

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

достаточно только вот тогда вот этих сервисов. Может ли делать это само ФП договор? Мм, может ли она сама меня статус?

Думаю думаю да. Что для этого ей нужно? Угу. Ну, нам нужно какой-то вот, ну, а фильтрация, может быть, нам нужна по этим по статусам, э, там, апдейтить в БДшки, так или я чуть-чуть, а, как ФП договор будет понимать, какой

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

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

Так-с. Ладно. Ок. Ок. М. Блин, что у тебя по времени, скажи? Да я-то могу ещё минут 10, наверное.

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

Вот здесь или со второго даже по седьмой. Вот здесь перевести с рестов на асинхрон.

Угу. Так, ну давай. Мм, смотри. Э, ну, наверное, вот запрос. Так, третий запрос нам пошёл. Мм, третий запрос пошёл. Допустим, у нас там 1.000 мм запросов.

И нам ст. Давай тогда вот с нашего оркестратора запрос идёт в м в кавку ээ в какой-то топик там открытия счёта, в топик договоров там какой-то. И наш этот ФП договор сервис наш консюмер читает вот этот вот топик

ээ этих договоров нашей кавки. Он читает, обрабатывает и выдаёт ответ м ну давай оркестратору нашему.

Так, дальше он бьёт куда? Ну вот получается, смотри. Да, ещё раз. Оргистратор в Кавку, кавка в Кавке читает ФП договор и потом Угу. ВП договор у нас ээ вычитал наш договор мм и потом он его, ну, передаёт ээ статус.

О'кей, давай. Да, да, да. То есть тоже у нас снова кладётся в в этот в кавку. Мм.

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

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

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

Новый топик этого резерви. Так, топик какого-то, назовём его топик резервированных счетов. Из него читает наш вот этот ФП резервирование счёта. Мм, прочитал, мм, даёт ответ. И ответ тоже идёт через кавку, через другой топик. Топик ответов там по резервированию счёта, из которого

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

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

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

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

Угу. Надо ли об этом, э, кому-то ещё сказать? М, да, это нужно нам записать в БД, что нас счёт зарезервирован.

Угу. Вот. И потом уже ФП договор на надо знать о том, что счёт зарезервирован.

Угу. Так, ФП договор. Договор к счёту, конечно, мы тоже нужно знать. То есть нам нужно, чтобы у нас мм БДФ по договора знала об этом. Мм, как она узнает?

Как она об этом узнает? Но мы после того, что у нас оркестратор вот вычитал из топика, что у нас там зарезервирован счёт, нам нужно отправить запрос мм на запись в м в БДФП договора.

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

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

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

асинхронный запрос записи в БД ээ ХП договора, где у нас э к на в эту в сущность нашего договора записывается номер вот этого счёта.

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

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

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

А как через кавку? М, ну, например, то же самое, как и аналогично с теми пунктами, которые я говорил у нас. То есть от седьмого пункта идёт стрелочка в каф, где у нас мм смотри, да, да, где у нас

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

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

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

Так, ну по постараюсь ответить по команде. Там ещё так два аналитика. Мм, а вы ищете аналитика на, получается, условно не на замену, а на расширение.

Да, расширение, да. Расширение. Так, про задачи рассказать. Архитектор есть у вас? А, честно, я не знаю точно.

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

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

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

же архитектор, вот, ну, как и у меня, допустим, в команде, то можно сказать, что скорее его нет. Угу.

А PM там есть присутствует. А, ну вот как есть ВП по сути отчасти это и PM тоже.

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

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

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

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

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

Супер. Хорошо. Спасибо. Всё, Кирилл, спасибо. Всё, пока. Всё, хорошего вечера тебе. Пока-пока. y