Speaker A
Так, ну что, всем привет. Небольшое лирическое вступление. А, собственно, спустя пару минут, наверное, вы увидите запись собеседования.
Разбор реального собеседования на позицию системного аналитика с зарплатой 200 000 в Virtuozzo/Вирту системс: вопросы о требованиях, интеграции с OpenStack и проектировании интерфейсов.
Key Takeaways
- Интервьюеры на собеседованиях системных аналитиков активно проверяют умение описывать конкретный опыт: источники требований, техники, последовательность работы и артефакты.
- Интеграционные проекты требуют анализа различий API и моделей данных между системами (например, подсети против сетей в OpenStack).
- При проектировании интеграции с большими наборами параметров важны маппинг, валидация и обработка ошибок.
- Необходимо уметь объяснить бизнес-процессы с таймаутами и компенсирующими действиями в микросервисной архитектуре.
What the video covers
- Автор выкладывает запись неудачного собеседования на позицию системного аналитика (вакансия на 200 000) в компанию Вирту системс, с целью личного архива и помощи другим кандидатам.
- Интервьюер проверяет опыт кандидата: два последних места работы с проектами с нуля, два предыдущих — небольшой опыт (8 и 4 месяца).
- Обсуждается интеграционный проект с OpenStack: управление подсетями, сетями и ролевой моделью, рассогласование API двух систем.
- Кандидат рассказывает о доработке функционала управления образами (назначение на проект, пользователя, организацию), включая макеты и юзкейсы.
- Интервьюер задаёт вопросы о сборе и фиксации требований: от кого, в каком виде, какие техники и нотации использовались.
- Обсуждается проектирование интерфейса с большим количеством параметров (около 300) при интеграции с внешним сервисом и маппинг параметров.
- Затрагиваются вопросы документации (Confluence, Swagger), проектирования БД (связующие таблицы для избранных товаров), моделирования сценариев библиотеки и магазина.
- Разбирается бизнес-процесс оплаты заказа с таймаутом 15 минут и откатом операций при отсутствии оплаты через микросервисы.
- Видео полезно как пример структуры технического собеседования системного аналитика и типичных вопросов интервьюера.
Chapters
- 00:00Вступление и причина публикации записи
- 02:53Вопросы о предыдущем опыте и интеграции с OpenStack
- 04:46Опыт проектирования и управления образами
- 07:00Сбор требований и последовательность анализа
- 13:20Проектирование интерфейса и маппинг параметров внешнего сервиса
- 18:20Документация, БД и моделирование библиотечной системы
- 33:10Бизнес-процесс оплаты и откат операций
Full Transcript — Download SRT & Markdown
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
У тебя первые два места там, ну, небольшой опыт, то есть там 8 месяцев, 4 месяца, но я просто только что обучался. На последних двух местах работы у тебя были проекты с нуля, ну или функционал прямо с нуля, который ты проанализировал, спроектировал. Ну вот как раз-таки это интеграция, про которую рассказывал. А подскажи, там только интеграционное взаимодействие или какое-то влияние на пользовательский интерфейс было, какой-то сценарий использования и так далее?
Speaker A
А с точки зрения именно поль пользовательского интерфейса, какие задачи были, которые тебе запомнились? Ну, наверное, самая, так скажем, большая, самая интересная.
Speaker A
Ну, они в любом случае у меня прорабатывались в начале интеграции. Вот. А-а, какие-то изменения отдельно от интеграции в системах, они тоже были.
Speaker A
зависимости от ролевой модели, соответственно, назначать эти образа, например, на проект, на пользователя, на организацию.
Speaker A
Вот, потому что, ну, как я говорил, заводил задачи на вторую команду разработки, которая разрабатывала платформу.
Speaker A
Вот. И там, соответственно, нужно было дорабатывать значительно экраны, э то есть это назначение всех этих ресурсов. Вот. И плюс также нужно ещё было настраивать интеграцию опн сне.
Speaker A
Вот. Ну и при этом ещё были доработки на нашей стороне, потому что опять же в рамках интеграции была разница по функционалу и по способам взаимодействия. То есть, к примеру, у нас есть определённые API-методы, которые позволяют, например, управлять подсетями в рамках сетей. Вот. Но во второй системе при этом нет такого управления, и там идёт управление только через сети. То есть у них соотношение одна сеть, одна подсеть. И в случае, к примеру, если нам нужно создать какую-то подсеть, то мы создаём просто сеть, потому что автоматически при создании сети создаётся и подсеть. Вот, соответственно, нужны были такие доработки системы уже отдельно от интеграции.
Speaker A
ВМКИ мы выбираем образ, там дополнительные диски. конфигурации и так далее. Угу. А, а связанное, наверное, как бы с бизнес-процессами, потому что здесь как бы не не в явном виде я вижу какой-то бизнес-процесс или он всё-таки как бизнес-процесс у тебя
Speaker A
А с точки зрения именно пользовательского интерфейса, какие задачи были, которые тебе запомнились? Ну, наверное, самая, так скажем, большая, самая интересная.
Speaker A
требования, да, и что ты дальше делал, с кем общался, чтодировал, то есть какие техники использовал и когда у тебя появлялись эти userстоories, как раз-кейсы, которые ты говорил, там ppмны и интерфейс. Ну, в какой последовательности, как это всё происходило?
Speaker A
Ну, из последнего вот что сразу вспомнил — это управление образами. А-а, на нашей платформе мы дорабатывали полностью функционал, то есть до этого было только управление, скажем так, создание и удаление образа. Вот. А мне, соответственно, нужно было полностью проработать историю, где была возможность в зависимости от ролевой модели назначать эти образы, например, на проект, на пользователя, на организацию.
Speaker A
скажем. Вот. Соответственно, мне дали приказ, мне необходимо было его проработать. Э-э, плюс также обсуждал, э-э, с РПС-разработчиками и среди аналитиков, скажем так, искать бестпракти по тому, как это правильно сделать. Юзкейсы, собственно, брались как раз-таки из этого приказа, поскольку
Speaker A
Плюс также дополнительно прорабатывать ещё со стороны обычного пользователя, то есть не по ролевой модели, если смотреть, то есть обычного пользователя, который управляет образами, помимо создания и удаления ещё и редактирования.
Speaker A
Вот, соответственно, по тому, что прорабатывал именно из документации, ну вот началось всё с формирования задачи большой, потому что у нас в команде достаточно большой акцент сейчас на формирование задач, чтобы можно было по одной задачке, грубо говоря, понять всё, даже
Speaker A
Вот. И там, соответственно, нужно было значительно дорабатывать экраны, то есть это назначение всех этих ресурсов. Вот. И плюс также нужно было ещё настраивать интеграцию с OpenStack. Вот. Потому что по сути интегрированы.
Speaker A
отдельно на бк. Вот. Плюс дополнительно проработаны макеты. Э макеты частично были доработаны, то есть я не могу сказать, наверное, что они делались с нуля. Вот. Потому что брали с соседней платформы нашей компании.
Speaker A
А что такое образы? Образы, скажем так, при создании виртуальной машины мы можем выбрать образ. Этот образ представляет из себя, скажем так, операционную систему, которая будет накатываться как раз-таки на ВМ. То есть при создании ВМ мы выбираем образ, там дополнительные диски, конфигурации и так далее.
Speaker A
Чаще всего от Projectменеджера приходила небольшая задачка, которую чаще всего нужно было переделывать, к примеру, в Epic, э, и накидывать несколькими задачами. В принципе, у нас в команде сделано так, что если по самооценке задачи, скажем так, при оценке задач у
Speaker A
Угу. А, а связанное, наверное, как бы с бизнес-процессами, потому что здесь как бы не в явном виде я вижу какой-то бизнес-процесс, или он всё-таки как бизнес-процесс у тебя полноценный был?
Speaker A
Вот. Ну и после в результате там какой-то большой задачи, где какая-то доработка, там также идёт декомпозиция задач на определённый фронт работы. То есть, например, на тестировщиков одна пойдёт задача с одним описанием на БК.
Speaker A
Немного не понял вопрос, что именно подразумевается под полным?
Speaker A
Ну то есть ну я понял, да, она тоже декомпозировалась. То есть к примеру, если мы берём какое-нибудь одно большое требование, ну, вот на примере тех же образов, да, где мы берём список требований, соответственно, мы можем сделать эпики на, например, ролевое
Speaker A
Ну, здесь, насколько я понимаю, с точки зрения интерфейса и бизнес-процесса, это как выглядело? Ты сказал, роли разные, можешь детализировать и здесь как бы рассказать, наверное, ну, в каком виде тебе пришли входные требования, да, и что ты дальше делал, с кем общался, что документировал, то есть какие техники использовал и когда у тебя появлялись эти user stories, юзкейсы, которые ты говорил, там BPMN и интерфейс. Ну, в какой последовательности, как это всё происходило?
Speaker A
Вот после этого в эпике мы уже нарезаем задачки там, допустим, по каждой прямо Чеф, в рамках которой нужно проработать аналитику. То есть, например, проработать аналитику на, например, создание образа, проработать аналитику на ээ назначение ресурса на на пользователя, например, или на
Speaker A
Угу. Ну, изначально задачка на меня упала от лида. Вот, лид мне сказал, что у нас сейчас проходит сертификация. Вот. И, соответственно, необходимо проработать ряд требований от ФСТЭК, это такой орган, который по сути предоставляет сертификаты, которые позволяют работать с госзаказчиками, так скажем. Вот. Соответственно, мне дали задачу, мне необходимо было её проработать. Э-э, плюс также обсуждал с РП-разработчиками и среди аналитиков, скажем так, искал бест-практики по тому, как это правильно сделать. Юзкейсы, собственно, брались как раз-таки из этого приказа, поскольку нужно было оттуда взять, ну, точнее, там были указаны как раз-таки те функциональные возможности, которые пользователь должен иметь, делать. То есть, например, управлять доступностью образов, там возможность редактирования образа, удаления и так далее.
Speaker A
Ну, собственно, из того, что мы подкрепляли по артефактам, всегда подкрепляли основную документацию, то есть техническое задание, где, собственно, указано то, что необходимо доработать этот функционал, спецификацию требований, в которой были указаны апи методы, которые должны как раз-таки работать на фронте и
Speaker A
Вот, соответственно, по тому, что прорабатывал именно из документации, ну вот, началось всё с формирования большой задачи, потому что у нас в команде достаточно большой акцент сейчас на формирование задач, чтобы можно было по одной задачке, грубо говоря, понять всё, даже если это задача размером с Epic. Вот. Э-э, соответственно, были проработаны юзкейсы, дополнено техническое задание общее на весь продукт, э-э, проработана спецификация требований, то есть API-методы, эндпоинты, все были дописаны, и создана задача на доработку отдельно на фронт, отдельно на бэк. Вот. Плюс дополнительно проработаны макеты. Э, макеты частично были доработаны, то есть я не могу сказать, наверное, что они делались с нуля. Вот. Потому что брали с соседней платформы нашей компании.
Speaker A
Ну, грубо говоря, обычный кейс, но просто ещё дополнительный UI макет переделывали. Угу. А, ну ты вот сказал про кнопку. А был ли опыт, когда нужно было спроектировать пользовательский интерфейс, но с большим количеством элементов ввода? не управление, да, чисто кнопочки и или вывод какой-то
Speaker A
Угу. А была ли у тебя такая активность, как декомпозиция задач? Когда у тебя пришла крупная задача, её нужно по какому-то принципу декомпозировать, не знаю, планово и поэтапно запускать, или это делал, ну, Team Lead, project-менеджер, кто этим занимался?
Speaker A
А там, если рассматривать элементы ввода, ну, по сути, скажем так, строчку с фильтрами. Вот при этом пользователь мог, а, как, например, у нас сейчас работают фильтры, мы можем фильтровать только почему-то одному. И когда мы добавляем фильтр, он, грубо говоря, по
Speaker A
Чаще всего от project-менеджера приходила небольшая задачка, которую чаще всего нужно было переделывать, к примеру, в Epic, и накидывать несколькими задачами. В принципе, у нас в команде сделано так, что если по самооценке задача, скажем так, при оценке задач у нас есть сторипоинты, а если порог превышает количество сторипоинтов при оценке, тогда нужно, соответственно, задачу декомпозировать.
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
Ээ, к нашим параметрам. Ну, то есть, ну, где к вашему IP или к BD? Э-э, я, наверное, бы делал копишки. Вот, соответственно, потому что, скажем так, чтобы мы могли, грубо говоря, гонять методы туда-обратно для того, чтобы получать ответ.
Speaker A
Угу. Вот. А-а, и, соответственно, в результате чего, э, после анализа посмотреть в БДЭшке, как что хранится у них и у нас.
Speaker A
Вот. Ну, у них тебе доступ могут не дать, у тебя только опишка, да. Собственно, всё это намапить. после этого завести, соответственно, задачу, куда приложить уже там юзкейсы, все эти интеграционные методы и так далее. Пообсудить с архитектором архитектуру там.
Speaker A
А ты вот сказал, посмотрю на нашу документацию, на их документацию. Вот на что ты обращаешь внимание? Вот тут задачка у нас, ну, как сказать, усложняется. Задача ситуация состоит в том, что там, к примеру, ну, порядка там 300 параметров, да, а у тебя на
Speaker A
интерфейсе их там 50 параметров, да, и на что ты будешь обращать внимание, когда ты вот увидишь там, блин, 300 параметров, как ты убедишься, что мы успешно там интегрируемся и процесс взаимодействия будет без ошибок работать? Ну, при маппинге параметров,
Speaker A
на что бы я смотрел? Во-первых, на то, как они мчатся по типам, а на то, как они мчатся по обязательности, соответственно, потому что, например, у нас может быть обязательный, у них он не обязательный.
Speaker A
Вот. Плюс ещё посмотреть по параметрам, которые, например, просто между собой не стыкуются. То есть, например, там, не знаю, давайте так придумаем, например, какой-нибудь параметр систему какой-нибудь legси такой, где будет какое-нибудь константное значение всегда. И вот оно у обоих систем,
Speaker A
например константное. Угу. Вот. А смотреть на все эти разногласия вот, наверное, наверное, да. Всё. Ты сказал ещё, что в рамках проектирования интеграции, ну, пользовался Посманом. С какой целью пользовался?
Speaker A
Ну, в рамках проектирования интеграции какой преследовал цель, так скажем? Ну, по постманом. Постманом, наверное, ну, постма я, по-моему, не называл, кстати, вот, но в основном, на самом деле, такие небольшие тесты делал через Вагр.
Speaker A
Вот. всего использовал для того, чтобы как пример задач. Задача от QA что вот есть такой метод, я не понимаю, как он работает, мне нужна дока, чтобы я мог понимать, как его правильно тестировать. Вот, соответственно, для этого я лез
Speaker A
там в Swager Postman. В общем, неважно. Смотрел, грубо говоря, коды ответов, пытался запустить методы, чтобы, к примеру, прикрепить ээ там, ну, пример ответа, пример запроса.
Speaker A
Угу. Ну и, собственно, там, например, в Свагере можно открыть э я не помню, как это называется, ну, в общем, структуру, структуру запроса, структуру ответа, где как раз-таки всё это можно увидеть. Ну, грубо говоря, какой тип параметра, как он называется.
Speaker A
Иногда там даже комментарии могут появиться. Это вообще хорошо тогда. Угу. А подскажи, в части проектирования Апи для бэкэнда занимался такими задачами?
Speaker A
Да, занимался. Угу. А где документацию? То есть где-то в Конфлюнсе делал или сразу в Свагере?
Speaker A
Э, в Свагере не делал, да, всё верно. Я делал её сразу в Конфлюнсе. Вот. И после этого уже заводил задачу на эээнд, где как раз-таки прикреплял ссылку на confнс. Угу. Какое содержание было постановки при проектировании апи?
Speaker A
Аэ, ну, собственно, необходимо проработать, необходимо разработать а метод, там, его основная цель этого апи метода. После этого там прикрепляю ссылку на USCASE, ну, всё так же на USCE, на техническое задание, а, и, собственно, на самописание этого апи метода.
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
Пост и Delete. Ага. А, собственно, мм, по основным параметрам, которые там они будут содержать себе, это, собственно, айдишник пользователя, а, айдишник товара. Угу.
Speaker A
И, в принципе, наверное-то и всё. Вот из если так мы прямо по простенькому делаем же есть вариант второй. Ээ, к примеру, вот сейчас в рамках интеграции мы это тоже прорабатываем.
Speaker A
А делать это всё через пут. Вот, где мы будем просто передавать айдишник пользователя и также передавать массивам айдишники товаров, которые будут находиться в избранно. То есть у нас будет список, скажем так, привязанных пользователю товаров по айдишникам, и мы массивом просто
Speaker A
передаём идентификатор. Угу. Вот. То есть, к примеру, если там у нас, да, пользователь под каким-то айдишником сначала мы, например, для добавления, мм, например, у него уже в избранном там пять товаров, да, ну вот прямо так назовём 1 2 3 4 5 массив. Чтобы
Speaker A
добавить, мы просто передаём пут, где идёт 1 2 3 4 5 и вот шестой товар для удаления. Мы просто отправляем ещё раз этот метод, но уже без шестёрки. То есть 1 2 3 4 5.
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
читателя найти. Так, хорошо. Также вопрос, какие, скажем так, какие данные предоставляет читатель? То есть он называет какой-то номер карточки своей или там Fio или, может, там, я не знаю, документ свой даёт, может там по паспорту выдают книжки.
Speaker A
Ну, в теории своей у него есть читательский билет, да, то есть какой-то абонемент, библиотеку, но он его может забыть, вот прийти, может быть, с документом, удостоверяющую личность. Ну да, с паспортом может прийти.
Speaker A
А-а, либо же и иногда готовы по по ФИ найти, ну, по каким-то контактным данным.
Speaker A
Так, ну хорошо, тогда базово, наверное, накидаю. Я не буду ещё больше уточняющих вопросов задавать, чтобы в деб не зайти. Вот. Ээ так, по фронту, что бы я указал? Ну, соответственно, поиск, который мы можем делать по ФИ, по номеру телефона, э-э,
Speaker A
по, допустим, там, по паспорту, хотя навряд ли это нужно. И, э, так, что я назвал? Номер телефона, документы, а, Fio и номер читательского билета вот по фронту, чтобы я отображал в результате поиска. Ну, к примеру, да, ну, там у нас указывается список, да,
Speaker A
там подходящих, к примеру, пользователь, ну, библиотекар среди всех этих пользователей найденных находит того, кого надо, по каким-то там, например, дополнительным фильтрам. А, к примеру, я не знаю, там по истории книжек, которые он берёт. Вот. А-а, основное, что я бы
Speaker A
показывал пользователю, чтобы, ну, библиотекар, чтобы он убедился, что это вот именно его, ну, груво горя тот человек пришёл. Э, фотография, дату заведения вот этого читательского билета э-э собственно Fioо номер телефона, там, так, номер читательского билета, не помню, говорил или нет,
Speaker A
допустим, какие-то документы. Плюс дополнительно я бы, наверное, указывал статус для того, чтобы мы могли, грубо говоря, оптимизировать немножко нашу БД.
Speaker A
То есть какие-то суперстарые там записи можно было удалять. Спустя время, если, например пользователь например завёл читательский билет спустя год там того, что он не пользовался, мы, например, заводим э статус неактивный и спустя ещё, например, год удаляем, вот, чтобы не
Speaker A
наполнять эту базу. Вот. Плюс я бы ещё, наверное, отобразил список книг, э-э которые он брал. Ну, типа историю обращений, так скажем.
Speaker A
Угу. Это уже в детальной карточке читателя, когда мы выбрали какого-то конкретного да? Угу. Ну, до этого я говорил, что список и там будут какие-то основные параметры там по пользователю типа ну FIO номер телефона, какой-нибудь статус, типа зелёный или красным
Speaker A
кругляшком. Будем отмечать в начале. Угу. Вот примерно так. Ну и также получается вот за счёт этого статуса мы сможем быстрее находить пользователя. То есть, к примеру, можем спросить там, давно вы были, недавно. Там может быть он сам знает, что у него отключили
Speaker A
читательский билет, он ужете как неактивный пользователь идёт. Но вот он ещё успел в этот предел, когда он неактивный, но его ещё и не удалили.
Speaker A
Там, например, спустя полтора года уходит, приходит, точнее, закры. А, хорошо. А, и плюс, плюс, что я бы указал, я вот вспомнил долги по книжкам.
Speaker A
Нати, если он, допустим, пять уже себе забрал, а у него там, например, лимит в пять книг, и он не может взять ещё одну, потому что у него уже висит на нём пять книжек.
Speaker A
Хорошо, давай такой кейс представим. Ну, вернёмся к интернет-магазинам, да. У нас есть процесс оформления заказа с участием нескольких микросервисов. То есть это сам магазин, да, он создаёт заказ, склад, он там проверяет наличие и резервирует товар. Оплата, ну, списывает
Speaker A
деньги. Микросервис, там уведомления, он оповещает там клиента, да, там, что за заказ там оплачен, там отправлен и так далее. А как организовать откат всей операции, если на каком-то этапе, ну, например, в оплате, да, возникла ошибка.
Speaker A
возникла ошибка или клиент вообще не оплатил тоже как сценарий возможный. Так, хорошо. Ну, мы в таком случае будем делать просто так, сейчас скажу синхронные методы, где мы просто будем сидеть, ждать ответа. Вот. И, к примеру, там, если вот смотреть последний пример,
Speaker A
да, где там он платил, но он пока ничего не сделал, мы просто сидим, ждём, когда Угу. закроется оплата, мы получим соответствующее например сообщение.
Speaker A
Там, к примеру, спустя 15 минут не пришёл там метод на, ну, не пришёл ответ на оплату, то мы, собственно, защаем ошибку, можем закрывать.
Speaker A
Ну, синхронный тут нам может не подойти, да? То есть там где-то в магазине, да? Я я немножко спутал.
Speaker A
А а каким образом асинхронное взаимодействие тогда реализовать? Ну, к примеру, мы ждём, скажем так, к примеру, у нас запускается процесс.
Speaker A
Соответственно, если за 15 минут процесс этот не закрыт по оплате, то мы, соответственно, возвращаем сообщение о том, что вот у нас стоп.
Speaker A
Вот. Ну, на самом деле, на самом деле там очень много можно всего проработать. То есть, к примеру, если вот, например, смотреть Озон, да, где можно заказать товар, но его ещё не оплатить, и там даётся 15 минут на оплату, но при этом
Speaker A
работа по товару уже идёт. То есть тут, на самом деле, по-разному может быть, если если нюанс именно в том, что мы не можем дальше что-то продолжать, какую-то работу в случае, если у нас 11 там сервисов застопорился.
Speaker A
Ну, а как асинхронное взаимодействие ты это сделаешь? Ну, вот на этапе оплаты возникла ошибка. Дальше с точки зрения системы микросервисов, да, что что должно произойти.
Speaker A
Ну, к примеру, вот сделать ивент, который будет там отправлять метод на уведомление пользователя, там, например, раз в 5 минут. Ну, то есть он будет три раза уведомлять пользователя в момент оплаты. Пока он будет ждать оплаты, ему будет приходить, например, метод на
Speaker A
на уведомление о том, что у него есть остался заказ, который он ещё не оплатил. Ну вот он его не оплатил. Вот прошло 15 минут, он его не оплатил. Как микросервис самого магазина и склада, да, там узнает. Нам же надо откатить всё как
Speaker A
обратно. Как они могут узнать об этом? Ну, соответственно, когда нам придёт уже ответ. Ну, это же асинхронное взаимодействие.
Speaker A
Тогда какой вариант асинхронного взаимодействия? Ты говоришь, давай так скажем. Какие варианты асинхронного взаимодействия? Тебе известно? Тут я уже затрудняюсь ответить.
Speaker A
Понял. Так, Евгений, спасибо тебе за предоставленные ответы.
Topics:системный аналитиксобеседованиеIT-вакансиитребованияOpenStackинтеграцияUMLбизнес-процессыAPIкарьера в IT
