**Собеседование Middle+ системного аналитика | Базовые вопросы — Transcript & Summary | SozAI**
Source: https://sozai.app/transcript/middle-system-analyst-interview-questions/

Собеседование на позицию Middle+ системного аналитика: базовые вопросы по требованиям, инструментам и методологиям.

## Key Takeaways

- Системный аналитик должен хорошо понимать виды требований и их классификацию.
- Владение инструментами моделирования и ведения документации является важным навыком.
- Знание методологий Agile и Scrum помогает эффективно управлять проектами и изменениями.
- Понимание технических основ, таких как DNS и web-запросы, полезно для системного аналитика.
- Гибкость в управлении задачами и спринтами критична при работе с изменяющимися требованиями заказчика.

## What the video covers

- Обсуждение процесса разрешения доменных имен через DNS и получения HTML-страницы.
- Разбор видов требований: функциональные, нефункциональные, бизнес-правила и пользовательские требования.
- Объяснение модели Вигерса и взаимосвязи бизнес-проблем, требований и артефактов.
- Пример разделения функциональных и нефункциональных требований на примере отображения баланса по кнопке.
- Используемые инструменты: BPMN, UML (диаграммы юзкейсов, активности, классов), текстовая документация.
- Опыт работы с таск-менеджерами: JIRA, Redmine.
- Различия в обозначениях на sequence-диаграммах (синхронные и асинхронные запросы и ответы).
- Знание методологий разработки: Agile, Scrum, Waterfall (Tef).
- Обсуждение управления спринтами при изменении задач и приоритетов заказчика.
- Общее понимание гибкости и взаимодействия с пользователем в Agile и Scrum.

Answers

## Questions about this video

Что происходит, когда в браузере вводится адрес сайта?

Вводится доменное имя, которое отправляется на DNS-сервер для получения IP-адреса. Затем браузер обращается к веб-серверу по этому IP и получает HTML-страницу для отображения.

Какие виды требований выделяются в системном анализе?

Выделяют функциональные, нефункциональные требования, бизнес-правила и пользовательские требования. Бизнес-правила обычно включаются в нефункциональные требования.

В чем разница между Agile и Scrum?

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

## Full Transcript — Download SRT & Markdown

00:02

Speaker A

Так, всё у меня, да? О'кей. Так, а, Руслан, такой вопрос. М, когда ты в браузере, в командной строке вписываешь любой адрес, будь это там, я не знаю, поисковик Google.com или будь это, я не знаю, сайт t2.ru, а происходит некая магия, после которой у тебя отображается страница сайта. Скажи, пожалуйста, что под капотом? О'кей. По факту мы вводим домен. Вот. И это должно уходить на DNS-сервер. Вот в плане того, что мы отправляем домен, а под капотом там по факту это айпишник, IP-адрес. Вот DNS-сервер по домену возвращает айпишник. После этого мы на веб-сервер какой-то идём, отправляем этот айпишник, там происходит запрос и условно приходит нам в ответе HTML-страничка. О'кей. Так, а с какими видами требований ты знаком, с какими сталкивался? Ну, по факту с базовыми. То есть это функциональные требования, нефункциональные требования. Ну, там можно выделить ещё бизнес-правила, но они обычно как бы их можно выделить в отдельную когорту. Ну вот так. Ну ещё есть пользовательские требования тоже, если их можно выделить в отдельную когорту. В общем, так. Угу. Смотри, у нас есть страница, а, с балансом, ну, условно говоря, при нажатии на кнопку, а можно я тебе чуть-чуть перебью? А, по поводу бизнес-правил. А, всё-таки бизнес-правила — это отдельный вид требований или какая-то абстракция, из которой вытекают отдельные требования? То есть по поводу формирования, какие требования за какими формируются и какие артефакты, к примеру, ты можешь назвать при формировании требований. То есть, грубо говоря, там, не знаю, знаком ли ты со стандартной моделью Вигерса. Ну, стандартная модель Вигерса из себя и представляет, что там есть функциональные, нефункциональные требования. А бизнес-правила, они включаются в нефункциональные требования. Ну, бизнес-правила включаются в нефункциональные требования, а нефункциональные и функциональные требования растут из бизнес-правил. Наверное, они растут из бизнес-требований по модели Вигерса, мне кажется. Самое главное, не вообще даже не бизнес, не требование, да, если поговорить по Вигерсу, он говорит о том, что самое первое, что стоит, из чего потом всё остальное формируется — это бизнес-проблема. То есть которую мы решаем, это бизнес-идея — это бизнес-проблема. И из неё уже вытекают функциональные, нефункциональные требования, а в нефункциональные требования ещё можно добавить пользовательские требования и бизнес-правила. И вот как-то так. Ну хорошо. Ну это вот, как я помню, как я читал того же Вигерса вот по разработке и работе с требованиями. Да. Хорошо. Угу. Владимир, не слышно вас? Да, я понял. А есть страница, на которой при нажатии на кнопку должен отобразиться баланс. Собственно говоря, а что бы ты выделил к функциональным требованиям, что бы ты выделил к нефункциональным требованиям? А по факту, если у нас появляется, ну, у нас есть кнопка, по нажатию на которую, и там у нас появляется баланс. О'кей. Мм, функциональное требование — это действительно такое, как мне кажется, базовое. То есть при нажатии на кнопку получить баланс на странице должен отображаться баланс в виде числового значения либо там в виде значения с плавающей точкой. То есть это является функциональным требованием, то есть как система реагирует на взаимодействие с пользователем. А, например, насколько быстро должен появляться баланс? Например, когда мы говорим, что по нажатию на кнопку должен происходить, скажем так, визуализация того, что кнопка нажимается и вот всякое такое. Это можно назвать нефункциональными требованиями. Как-то так. То есть если разделить по большому счёту, функциональные требования — это как система взаимодействует с пользователем, как что она выдаёт, а нефункциональные — это условно характеристики самой системы. О'кей. Так, м, с какими, ну, собственно говоря, с какими инструментами ты в принципе работал? То есть ведение документации, там графики, схемы. По ведению документации, на самом деле, у меня, наверное, какой-то базовый шаблон в целом. Это работа с BPMN, когда я описываю бизнес-процесс, работа с UML. Обычно это диаграмма юзкейсов, диаграмма активности и, за редким исключением, диаграмма классов. И текстовая, ну, просто писать текст документации. То есть вот, наверное, такой стандартный набор. Угу. А скажи такую вещь. В качестве таск-менеджера, что у вас использовалось? Джира, может быть, что-то ещё? ВАК-менеджер, вот в IT-контакте была Джира, сейчас в Себанде Redmine. Угу. О'кей. Такой вопрос ещё: ты говорил, что используешь в, скажем так, в Юмейле используешь литип-диаграммы, используешь, получается, диаграммы классов редко и подскажи о сиквенс-диаграмме. Так, я же говорю, да? А диаграмма кейсов, sequence, activity на самом деле не так часто использовал, наверное, да? Всё, всё, всё, всё хорошо. Тогда вопросов нет. Ну, о'кей. А, чтобы далеко не уходить, условно говоря, если мы говорим про sequence-диаграмму, а в чём у тебя разница будет стрелки с ответом, синхронный, асинхронный запрос или что? Угу. Там разница стрелки в том, что когда у нас синхронный запрос, у нас сплошная линия со стрелкой. Когда асинхронная, она пунктирная. Угу. А если мы говорим про возврат, кстати, вот хороший вопрос. Возврат он тоже штриховой, но у него галочка, она вроде полностью закрашенная, а в асинхронном она такая, как сказать, как будто бы такие две линии. Я точно не, ну точно не вспомню, но как-то так. То есть в плане Юмейла я могу так сказать, в плане Юмейла у тебя запрос — это стрелка с чёрточкой, стрелка, а ответ — это две чёрточки, стрелка, асинхронный ответ — две чёрточки, две стрелки. Вот так. То есть графически я не могу вспомнить, как я в плане писал. Это вот так они отображаются. Ну, это по факту правильно. Это половинчатая стрелка. Вот. О'кей. А скажи, пожалуйста, с Confluence работал? Да. С таким инструментом, как JIRA, сталкивался? Не сталкивался ещё раз. С таким плагином, как JIRA, сталкивался? Нет. Нет, честно, нет. Понятно. Немногие, кто его использует. О'кей. А какие виды методологий ты знаешь? Ну, по, ну, методологии по Scrum. Ну, по факту его только с этим. Ну, есть ещё методология, там и две методологии, скажем так, я так полагаю. А в чём разница между Agile и Scrum? Ну, Agile у него главная идея в том, что пользователь превыше всего, то есть делать маленькие итерации, взаимодействовать с пользователем. Функционал прежде всего, то есть потребность пользователя — это прежде всего. То есть мы очень гибки в этом плане. А Tef — это то, что ты заранее собираешь все требования, и у тебя требования очень жёстко, ну, то есть документы, условно, с требованиями, видением проекта и всё остальное. Это очень жёстко забинжено. И ты потом просто идёшь как водопад, то есть потоком просто идёшь, ты всё и делаешь без каких-то явных изменений. Угу. А вот смотри, а если мы говорим про Agile и Scrum, не водопад, а именно Agile и Scrum. PG — это вроде методология, а Scrum — это уже как, как сказать, это вот идеи, собранные у пользователя, а Scrum — это вот то, как ведётся сам проект. Если вот как-то так. О'кей. А, смотри, собственно говоря, вы стартанули СНТ, у вас уже есть набор задач оценённых и так далее. Тут прибегает заказчик и говорит: "У меня есть идея на пару миллионов". Вот нужно реализовать эти две задачи, которые, собственно говоря, принесут денег, да. Вот что в этом случае должно произойти непосредственно со спринтом? По факту, если говорить своего личного опыта, либо задачи заменяются из спринта, либо спринт может расшириться в днях. То есть он будет не двухнедельный, а вот условно у нас был такой опыт, что он мог растянуться. Вот. Но по большей части в 80% случаях мы просто заменяли задачи. То есть у нас... Ну, это если они эквивалентны. А как могут быть, если эквивалентны? Одна задача принесёт миллионы, а другая не принесёт миллионы. Нет, эквивалентны по времени реализации. Ну, то есть они меняются, если они не эквивалентные, ты спросил, то есть 1/5, да? Если они эквивалентные, да, да, да. Ага. Заменить получится. А если они не эквивалентные, ну тогда либо расширять спринт, либо отказываться не то, что одна задача меняет другую, а несколько задач по...

00:24

Speaker A

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

00:44

Speaker A

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

01:03

Speaker A

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

01:20

Speaker A

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

01:34

Speaker A

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

01:53

Speaker A

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

02:11

Speaker A

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

02:29

Speaker A

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

02:43

Speaker A

хорошо. Ну это вот, как я помню, как я читал того же Вигерса вот по разработке и работе с требований. Да. Хорошо. Угу.

02:53

Speaker A

Владимир, не слышно вас? Да, я понял. А есть страница, на которой при нажатии на кнопку должен отобразиться баланс.

03:01

Speaker A

Собственно говоря, а что бы ты выделил к функциональным требованиям, что бы ты выделил к нефункциональным требованиям?

03:08

Speaker A

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

03:18

Speaker A

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

03:35

Speaker A

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

03:53

Speaker A

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

04:02

Speaker A

О'кей. Так, м, с какими, ну, собственно говоря, с какими инструментами ты в принципе работал? То есть введение документации, там графики, схемы. По ведению документации, на самом деле, у меня, наверное, какой-то базовый шаблон в целом. Это работа с BPменом, когда я

04:25

Speaker A

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

04:34

Speaker A

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

04:47

Speaker A

Джира, может быть, что-то ещё? ВАКменеджер вот в IT-контакте была жира, сейчас в себанде Redminde.

04:54

Speaker A

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

05:10

Speaker A

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

05:26

Speaker A

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

05:44

Speaker A

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

05:57

Speaker A

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

06:11

Speaker A

То есть графически я не могу вспомнить, как я в планле писал. Это вот так они отображаются. Ну, это по факту правильно. Это половинчатая стрелка.

06:19

Speaker A

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

06:40

Speaker A

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

06:56

Speaker A

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

07:09

Speaker A

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

07:23

Speaker A

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

07:40

Speaker A

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

07:58

Speaker A

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

08:05

Speaker A

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

08:21

Speaker A

части 80% случаях мы просто заменяли задачи. То есть у нас Ну, это если они эквивалентны. А как могут быть, если эквивалентны? Одна задача принесёт миллионы, а другая не принесёт миллионы.

08:31

Speaker A

Нет, эквивалентны по времени реализации. Ну то есть они меняются, если они не эквивалентные, ты спросил, то есть 1/5, да? Если они эквивалентные, да, да, да. Ага. Заменить получится.

08:45

Speaker A

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

09:00

Speaker A

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

09:13

Speaker A

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

09:21

Speaker A

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

09:33

Speaker A

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

09:53

Speaker A

наверное, проблемы, когда ты только устраиваешься и вникаешь проблемы с предметной областью, когда ты приходишь в какую-то компанию. И аналитик тоже очень достаточно хорошо должен понимать предметную область той сферы, в которой он работает. Вот. О'кей. А сталкивался ли ты с противоречивыми требованиями?

10:10

Speaker A

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

10:17

Speaker A

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

10:30

Speaker A

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

10:46

Speaker A

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

10:59

Speaker A

О'кей. А какие виды интеграции ты знаешь? Рест очень, ну, с рестом я вот именно хорошо работал. SOAP чуть-чуть работал, умел читать. И интеграция работала с Rabit MQ, а в пт проектах имею кавку такую лёгкую очень. И также в работе было, но

11:21

Speaker A

так глазком совсем смотрел. Это Websocket. Угу. А какие ещё, в принципе, есть виды интеграции? Есть RPS, есть GRPS, есть так, ну вот REST, SOUP, а, а, брокер сообщений и там этот корпоративная шина, как отдельно её можно выделить. Ну и, наверное, всё. А

11:42

Speaker A

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

11:55

Speaker A

Окей. А, ну, собственно говоря, а из чего состоит, ээ, HTTP запрос? HTP запрос из урла, из хедеров, если они нужны, и бади. Угу. А ещё из чего? Бади.

12:12

Speaker A

Бади. Тело запрос. Это бади. Угу. Ну, а ещё урол хедеры. А, метод, который мы используем.

12:24

Speaker A

Да, самый первый. Ну, собственно говоря, основные методы put, patch, get, post, delete. Угу. А в чём разница между put, patch?

12:40

Speaker A

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

12:58

Speaker A

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

13:13

Speaker A

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

13:31

Speaker A

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

13:46

Speaker A

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

13:59

Speaker A

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

14:11

Speaker A

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

14:20

Speaker A

Ну, он называется restless. А когда мы используем, а, restful, да? То есть это у нас там модель зрелости Ричардсона.

14:28

Speaker A

Угу. Да. Ну, один - это рест. Это если у нас все методы. Если у нас, собственно говоря, нет, это вот начальный этап. Это да, там на три уровня вроде. Нулевой, первый, второй, потом и добавляется ещё.

14:39

Speaker A

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

15:00

Speaker A

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

15:14

Speaker A

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

15:32

Speaker A

да. О'кей. Так, а у тебя есть какие-нибудь вопросы Игор? Ну, наверное, что касается реста, нет, наверное, может быть, что-то, когда мы спрашивали о подходах интеграции, назвали такие технологии, как RPC, JPC SUAP подскажи пожалуйста можно ли всё это считать все эти протоколы,

15:56

Speaker A

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

16:10

Speaker A

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

16:24

Speaker A

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

16:37

Speaker A

честно, не было. Угу. И, наверное, такой вопрос ещё получается, если работал хорошо с рестом, наверное, знаком со спецификацией Open AP, правильно? То есть вот формировал либо ямблы, либо jйсоны для описания аше. Кстати, вот тоже хороший вопрос. А на самом деле я с

16:54

Speaker A

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

17:07

Speaker A

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

17:21

Speaker A

вот так это реализовано. А так в целом с OpenP я работал, да, то есть свою документацию поделать и всё в этом духе, потестировать её сразу в свагере UI. То есть это было Угу. И по асинхро по асинхронным интеграциям с

17:38

Speaker A

асипеком использова есть спецификация которая называется, если не ошибаюсь, API, то есть то же самое, что Open AP, только для асинхронного взаимодействия, описания топиков. И нет, не, ну, до асинхрона мы ещё дойдём. Ну, ну ладно, да. Угу. Так. А, о'кей. А, смотри, ну,

17:59

Speaker A

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

18:20

Speaker A

Пятисотка - это внутренняя ошибка сервера. Угу. А сотка? Сотка когда я сотка-то видел. А я не вспомню. Извините.

18:30

Speaker A

О'кей. Так, а со свакером работал, да? Для чего использовали? По большей части это чисто для Swager UI, для того чтобы просто тестировать методы. По Но по большей части я работал с поманом больше, со свагером. Так, у кого на

18:49

Speaker A

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

18:57

Speaker A

Угу. А проектировать интерфейсы для свагера приходилось? только в учебных целях. Обычно приходил всегда на готовую документацию. Ну либо там, да, только на готовую докумен, ну то есть либо документацию, которую мы там у себя ведём другую. То есть обычно

19:11

Speaker A

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

19:21

Speaker A

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

19:35

Speaker A

и ты на нём описываешь просто свои рестметоды, то есть что в ни входит, какой тип данных, вроде как.

19:41

Speaker A

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

19:55

Speaker A

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

20:09

Speaker A

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

20:34

Speaker A

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

20:49

Speaker A

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

21:06

Speaker A

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

21:18

Speaker A

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

21:29

Speaker A

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

21:36

Speaker A

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

21:53

Speaker A

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

22:16

Speaker A

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

22:27

Speaker A

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

22:45

Speaker A

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

22:50

Speaker A

Ну, о'кей. А, о'кей. Webсокет ты назвал, но давай так. А, а куда ты будешь пулять? Тебе адрес нужен. В плане адрес чего? Сервера или что? Нет, клиента. Так, ну ачек. О'кей. Ага. Не понял. Ну ладно. О'кей.

23:10

Speaker A

Так. По поводу очередей с ты работал с реbbтом MQ. О'кей. А с капкай, я так понимаю, меньше взаимодействовала, да? Только вот по теории.

23:21

Speaker A

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

23:41

Speaker A

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

23:53

Speaker A

сохранение на надис как-то, но в целом, если мы говорим в сухом остатке, то этого не предусмотрено. Вот.

24:01

Speaker A

О'кей. А с какими реляционными базами ты Вот можно я вопрос задам поводу Ребита? Ты говорил, что ты работал с Ребитом. В Ребите есть такая сущность, как обменник. Чем она отличается от очереди?

24:12

Speaker A

Как какая? Ещё раз. Exchange. Обменник. Обменник. Чем очереди отличается? Сейчас я вспомню. Exchange. Exchange. Очередь это по факту туда, куда мы просто кладём наши сообщение. Их может быть несколько.

24:30

Speaker A

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

24:42

Speaker A

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

24:57

Speaker A

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

25:13

Speaker A

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

25:24

Speaker A

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

25:34

Speaker A

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

25:46

Speaker A

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

26:02

Speaker A

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

26:15

Speaker A

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

26:26

Speaker A

Это столпчатые, это файловые, это графовые и это какие ещё? Какие-то ещё были. Вот. То есть ключ значения. А ключ значения. Вот. Спасибо большое.

26:36

Speaker A

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

26:45

Speaker A

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

26:59

Speaker A

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

27:10

Speaker A

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

27:22

Speaker A

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

27:37

Speaker A

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

27:50

Speaker A

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

27:59

Speaker A

Вот. То есть по факту а нереляционки, чем они ещё круче, они же намного лучше подходят на чтение. Вот.

28:09

Speaker A

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

28:25

Speaker A

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

28:41

Speaker A

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

28:55

Speaker A

надо. О'кей. Так, а для чего? Ну давай так. Наиболее частый кейс ключ значения. Для чего мы можем ключ значения?

29:03

Speaker A

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

29:20

Speaker A

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

29:34

Speaker A

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

29:55

Speaker A

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

30:11

Speaker A

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

30:22

Speaker A

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

30:32

Speaker A

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

30:41

Speaker A

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

30:52

Speaker A

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

31:01

Speaker A

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

31:15

Speaker A

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

31:29

Speaker A

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

31:42

Speaker A

То есть, да, есть когда кэш у тебя просто тут, а есть когда Да, всё. Угу.

31:46

Speaker A

Понял вопрос. О'кей. А смотри, ну, собственно говоря, у тебя по нереаляционке всё? По нереаляционке всё. Ну, по реаляционной базе данных, если к нему вернёмся, наверное, вопросы ещё будут.

31:58

Speaker A

Ну вот, да, я хочу туда готовиться. А, ну, собственно, давай начнём с банальности. В чём разница между DDL и DML? Domain dat ddl dd data definition language и data manipulating language. А, то есть это на создание и на изменение. Там у тебя

32:22

Speaker A

команды А манипуляция - это изменение этих данных. А-а, а это, это, э, приведи примеры. Приведи примеры. SQL там MySQL. Это это это же оно.

32:37

Speaker A

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

32:47

Speaker A

Не совсем. М Ну так я и не вспомню, честно говоря. Не, не прямо погружённы. Я знаю, что у тебя у тебя есть процесс там, да, extract transform load ddl вот это.

33:02

Speaker A

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

33:15

Speaker A

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

33:32

Speaker A

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

33:51

Speaker A

CRU model модель create update delete. Угу. А если провести, скажем так, взаимодействие с ростами? Get put patch post dele. Нет, нет. Ну, соответственно, что get это будет такая-то команда. А, а, ну вот put - это у нас update, это будет команда.

34:14

Speaker A

Delete в Delete. Create - это post, а read - это get. Угу. Смотри, а почему? А за Ну давай так. У тебя есть таблица, а в которой у тебя есть идентификатор и у тебя есть некое другое уникальное поле. Предположим, что если

34:35

Speaker A

мы говорим про физическое лицо, то в одном случае у тебя банальный идентификатор 1 2 3 4 5, а в другом у тебя инне. Вот. А почему поиск по идентификатору происходит гораздо быстрее по чем по другому уникальному пользу? Скорее всего, потому что

34:50

Speaker A

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

35:07

Speaker A

умолчанию индекс. О'кей. Так, а какие виды связи в принципе существуют? Один к одному, один ко многим, многие ко многим. Угу. А если нам нужно организовать многие ко многим, как через связную таблицу? Угу. Так, Егор, у тебя есть вопрос? Ну, наверное, знаком ли ты

35:29

Speaker A

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

35:44

Speaker A

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

36:03

Speaker A

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

36:14

Speaker A

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

36:28

Speaker A

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

36:45

Speaker A

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

36:53

Speaker A

Ну, а как это ты? А вот такой вопрос. А что значит на уровне твоей транзакции?

36:58

Speaker A

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

37:13

Speaker A

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

37:21

Speaker A

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

37:37

Speaker A

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

37:48

Speaker A

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

38:05

Speaker A

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

38:21

Speaker A

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

38:38

Speaker A

А, собственно говоря, с какими форматами ст может работать? Форматами этой в этом контенттайпе, который у нас естьгу application, text plin, pdf pкст и что-то ещё. Вроде всё.

38:57

Speaker A

Application. А, а может ли R работать с XML? В принципе, в принципе, да. О'кей.

39:05

Speaker A

А давай так. По поводум. М приходилось ли тебе работать с этим форматом? Да, только читать. То есть ээ Да, то есть у нас были какие-то запросы, то есть они работали прекрасно. Ну, то есть это вот что-то такой древний кусочек

39:21

Speaker A

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

39:37

Speaker A

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

39:46

Speaker A

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

40:07

Speaker A

есть самого метода. О'кей. А для чего, в принципе, нам нужен VSDL? А в SDL - это как раз-таки уже а описание того, как системы будет с друг с другом взаимодействовать, то есть язык их общения. Ну, то есть, если XSD описывает

40:22

Speaker A

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

40:35

Speaker A

Какую интеграцию? Ещё раз. Какая интеграция? Синхронная или что? Или нет? Нет, нет. Давай так. А, SUAP то, что или Да, SOAP, конечно. Да.

40:47

Speaker A

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

41:03

Speaker A

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

41:17

Speaker A

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

41:31

Speaker A

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

41:39

Speaker A

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

41:57

Speaker A

Угу понял. Так, а, ну и, собственно, вопрос по Джейсону. В чём разница между квадратными фигурными скобками? Фигурный объект квадратный список. Ой, так. Я тебе сейчас покажу задачку. Условно говоря, тебе дали стажёра, да, под крыло.

42:21

Speaker A

Вот он создал Jon. Ну, по сути, описал рест. Тебе нужно посмотреть и выявить основные ошибки, которые он допустил. А может быть, наоборот, всё хорошо. Ну да, давайте посмотрим.

42:35

Speaker A

Разработчик. Так, видно? Сейчас у меня грузит. Да, видно. Так. Так давайте посмотрим метод полного head IP версия users http 11 host content type text plane. Ну, он пишет content type plin. А здесь у нас jon это первое. Угу. Что

43:02

Speaker A

должно быть? application. Угу. Так, ну у него и метод ещё head, хотя это должен быть get.

43:20

Speaker A

Метод полного обновления. А, метод полного обновления данных. Так, тогда это вообще пост, извините, я не прочитал. Ой, какой пост? Если мы хорошо говорим про это, то этот пут.

43:32

Speaker A

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

43:48

Speaker A

урле ещё можно некоторые данные, ну, как сказать, их менять. То есть, если у тебя в BD лежит ID 1 2 3 4, но ты не хочешь в общее обозрение в Урл отдавать, что ID 1 2 3 4, ты можешь это ещё условно

43:58

Speaker A

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

44:06

Speaker A

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

44:22

Speaker A

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

44:32

Speaker A

Хорошо. Так, ну вот он указал мы пут. Ставим айдишник такой, email, usernрame. Ну, с точки зрения запроса тут, а, usеer ID внизу, который не вставлен, его надо вставить. Да нет, ну я его добавил. Вот смотри, условно говоря, user ID - это

44:49

Speaker A

опять же уникальный идентификатор, который нам однозначно идентифицирует пользо пользователя. Да. Да. Что корректнее использовать: ID или user ID?

44:59

Speaker A

User ID. Ну, хотя, а если с точки зрения быстроты использования? Так, а если айдишник, который сформирован условно на стороне BD автоматически, но почему бы его не использовать? Лучше его тогда использовать. Нет. А с точки зрения безопасности, что мы user ID лучше

45:17

Speaker A

использовать. User ID, ну, который у нас сформированный. Ну, слушайте, в остальном вроде usернейм, тест вроде, ну, то есть всё нормально. То есть ещё ответ добавить какой будет и всё. Ну, то есть я больше я больше проблем не вижу,

45:30

Speaker A

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

45:44

Speaker A

Так. Пав параметром, да, сделать его. Не услышал. Параметром его сделать занесё. Да, не крёй, а параметром, да. Угу. Так, о'кей. Так.

46:06

Speaker A

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

46:25

Speaker A

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

46:45

Speaker A

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

46:59

Speaker A

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

47:17

Speaker A

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

47:32

Speaker A

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

47:44

Speaker A

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

48:00

Speaker A

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

48:18

Speaker A

можем о'кей, основные данные по клиенту? Да, мы можем. А можем ли мы кэшировать условно баланс? Нет, такое нельзя. Кэши.

48:24

Speaker A

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

48:33

Speaker A

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

48:46

Speaker A

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

48:56

Speaker A

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

49:10

Speaker A

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

49:23

Speaker A

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

49:37

Speaker A

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

49:47

Speaker A

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

50:00

Speaker A

сделать этот legси, попробовать разбить и посмотреть там по паттерну сага. То есть у нас там либо оркестрация какая-то будет, либо хореография. То есть это не каскадно будет, а он там вот оркестрация, например, то есть он будет приходить куда-то в ту место, которое

50:15

Speaker A

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

50:23

Speaker A

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

50:41

Speaker A

приходят, а при этом ещё мы добавлять будем, что А, хотя, а, ну, типа он приходит, какие-то запросы делает, и мы их, ну, вот я про что я спрашиваю, 10.000 пользовате приходит, 10.000 запросов делают на БКЕ. И при этом ещё

50:53

Speaker A

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

51:12

Speaker A

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

51:23

Speaker A

Ну, я соглашусь, да, тогда так. А ещё один есть вариант. Ещё вариант есть. Так, ну мало ли, может, ну ладно.

51:33

Speaker A

Хотя ты сказал, что в принципе запуть. Ладно. Да. Так. А а я вас на секунду просто спрошу.

51:43

Speaker A

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

51:49

Speaker A

Ну у нас Давай так, у нас остались ещё общие технические вопросы. Угу. Вот единственное, я не знаю, успеем ли мы про нас рассказать. Угу. Вот. Ну давайте постараемся. Просто у меня в 13:15 надо будет 100%, к сожалению, уйти. Поэтому я

52:06

Speaker A

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

52:21

Speaker A

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

52:38

Speaker A

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

52:52

Speaker A

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

53:05

Speaker A

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

53:20

Speaker A

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

53:38

Speaker A

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

53:50

Speaker A

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

54:08

Speaker A

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

54:14

Speaker A

Нет. Ну да, чтобы избежать подбора. О'кей. А с понятием Open ID знаком? Open ID Open ID Connect.

54:24

Speaker A

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

54:45

Speaker A

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

55:03

Speaker A

чём отличие HTTP от HTTPS именно вот на уровне реализации? Ну HTTPS, то есть там у нас SSL есть, то есть у нас вот организация, которая занимается тем, что сертифицируют какие-то сайты, то есть она вот э выдаёт им такое значение, что

55:19

Speaker A

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

55:33

Speaker A

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

55:47

Speaker A

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

56:01

Speaker A

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

56:18

Speaker A

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

56:33

Speaker A

внутренней системе. Ну по сути это внешняя система, которая как раз-таки идентифицирует пользователя. А понял? Ну может это может быть один вариант, это Idдентиity провайдеer.

56:44

Speaker A

Аessменеджер - это как раз Да, то, что ты озвучил. У, понял. Понял. А с ОА работал? Нет. ОА - это этот метод, ну, это метод аутификации. Угу. То, что у тебя есть ключ, выдаётся токен твой. Вот как разтаки Идентиity провайдер его выдаёт.

57:00

Speaker A

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

57:14

Speaker A

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

57:24

Speaker A

Угу. Что такое? О'кей. Так, а смэсками знаком, что это? Как это? CMS, да? Центр чего это? А можно жеть? Знаешь, не сталкивался content management system. А нет.

57:43

Speaker A

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

57:58

Speaker A

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

58:10

Speaker A

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

58:24

Speaker A

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

58:30

Speaker A

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

58:46

Speaker A

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

59:03

Speaker A

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

59:17

Speaker A

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

59:32

Speaker A

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

59:38

Speaker A

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

59:52

Speaker A

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

60:05

Speaker A

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

60:18

Speaker A

новое. То есть вот с точки зре, ну, то есть с связанный переход э на микросервис с новой организацией структур команд, да? То есть, как я читал, когда-то, была прикольная фраза: "Мicросервис придумали менеджеры". Вот.

60:32

Speaker A

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

60:38

Speaker A

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

60:53

Speaker A

ним взаимодействовал, он бордингом ему проводил. Вот. Ну, наверно. Так, у меня, наверное, вопросов нет, Егор.

61:04

Speaker A

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

61:09

Speaker A

Ну, шикарно. Ну, у нас есть, Руслан, смотри, у нас есть две опции. Либо мы рассказываем про себя.

Topics: системный аналитик требования функциональные требования нефункциональные требования бизнес-правила BPMN UML Agile Scrum JIRA

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

- [Карточки по этому видео](https://sozai.app/ru/tools/ai-flashcard-generator/?from=transcript&id=73318)
- [Тест по этому видео](https://sozai.app/ru/tools/quiz-generator/?from=transcript&id=73318)

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


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