**Какие задачи дают на собеседованиях системному аналитику в 2025? Реальные примеры — Transcript & Summary | SozAI**
Source: https://sozai.app/transcript/systems-analyst-interview-tasks-2025-real-examples/

Разбор реальных вопросов на собеседовании системного аналитика в 2025: требования, документация, Agile (Scrum/Kanban), микросервисы, базы данных и SQL.

## Key Takeaways

- Системному аналитику важно уметь документировать требования как текстом, так и диаграммами, в зависимости от типа требования
- В компаниях с Agile-процессами ТЗ по ГОСТу встречаются редко, чаще используются краткие PRD и фичевые документы
- Знание Scrum-церемоний и понимание различий Scrum и Kanban — базовое ожидание на собеседовании
- Для микросервисной архитектуры критичны вопросы согласованности данных и паттерны взаимодействия сервисов
- Практические задания на SQL и диаграммы последовательности часто включаются в процесс отбора

## What the video covers

- Типы требований системного аналитика: функциональные и нефункциональные, их атрибуты (атомарность, тестируемость, выполнимость)
- Способы документирования требований: юзкейсы для функциональных, текст для нефункциональных
- Управление требованиями при появлении новых фич и согласование с продукт-оунером
- Работа с ТЗ и ЧТЗ по ГОСТу и отличие от легковесной документации в гибких командах
- Различия Scrum и Kanban: спринты и планирование на 2 недели против непрерывного потока задач
- Scrum-мероприятия: дейли, ретроспектива, демо, планирование спринта, Three Amigos, груминг бэклога
- Архитектура микросервисов: хореография и оркестрация, проектирование по фичам и по потоку данных
- Вопросы по базам данных: отличие SQL-запроса от транзакции, индексы, репликация и согласованность данных
- Практические задания: написание SQL-запроса с фильтрами по стране и дате и построение диаграммы последовательности (sync/async взаимодействие)
- Обсуждение задач проект-менеджера в контексте роли аналитика

## Chapters

1. 00:00 Нефункциональные требования и характеристики системы
2. 02:40 Документирование требований и ТЗ
3. 04:50 Управление требованиями и изменения в спринте
4. 08:50 Scrum, Kanban и Agile-мероприятия
5. 12:00 Микросервисная архитектура и паттерны проектирования
6. 19:00 Базы данных, SQL и транзакции
7. 26:20 Практические задания: SQL-запрос и диаграммы
8. 41:00 Роль проект-менеджера и завершение

Answers

## Questions about this video

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

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

В чём различие Scrum и Kanban по мнению спикера?

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

Какие практические задания давали кандидату на собеседовании?

Кандидату предложили написать SQL-запрос с фильтрами по стране продукта и дате годности, а также построить диаграмму последовательности, показав синхронное и асинхронное взаимодействие между компонентами системы.

## Full Transcript — Download SRT & Markdown

00:00

Speaker A

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

00:17

Speaker A

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

00:38

Speaker A

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

00:48

Speaker A

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

01:02

Speaker A

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

01:17

Speaker A

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

01:31

Speaker A

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

01:44

Speaker A

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

02:03

Speaker A

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

02:12

Speaker A

Хорошо. А а приходилось ли тебе работать с ТЗ и с Чт? Ну да. То есть артефактами по факту моей работы сейчас иде, например, это как раз-таки написание ТЗК на разработчиков.

02:25

Speaker A

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

02:38

Speaker A

Ну не моя тема, на самом деле, как-то. Ну, честно говоря, не уважаю эту штуку.

02:41

Speaker A

Вот. Угу. То есть по факту, да? Ага. С такими документами, ТЗ и ЧТЗ, именно по ГОСТу, которые вот, знаешь, большие, объёмные, которые там по девятнадцатому ГОСТу или что-то по тридцать четвёртому? Я понимаю.

02:52

Speaker A

есть Пека по фиче какая-то, да, и плюс докумен, ну, то есть и всё. Больше не надо сильно париться, да.

02:58

Speaker A

Ну, не моя тема, на самом деле, как-то. Ну, честно говоря, не уважаю эту штуку. Это как будто бы больше государственные такие вещи. Вот. А мы тут как бы говорим: "Ну, я обычно работаю в компаниях пожайлу, да, и там у нас всё быстро может меняться, все дела". Ну и как-то вот привыкли к тому, что есть ТЗ, есть ПЕКА по фиче какой-то, да, и плюс документ, ну, то есть и всё. Больше не надо сильно париться, да.

03:12

Speaker A

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

03:22

Speaker A

Всё окей, я поняла тебя. Хорошо. А, ну, так как ты упомянул про Agile, да, я так понимаю, вы работаете по Scrum. То есть твой опыт — это работа по Scrum или по Kanban?

03:29

Speaker A

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

03:41

Speaker A

Не, по факту, по большому счёту, в первой компании это был Kanban, а вот сейчас мы по Scrum работаем, то есть там двухнедельные спринты и все дела.

03:50

Speaker A

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

04:02

Speaker A

Угу. А в чём в целом различие между Scrum и Kanban? О, сейчас я вспомню. По факту это же представляет из себя то, что Kanban — у тебя канбан-доска же есть, да? И у тебя по факту просто непрерывный какой-то процесс. У тебя есть задачи, они всё время есть. У тебя есть какой-то бэклог, и у тебя вот на твоей доске ты всегда можешь из бэклога себе перетаскивать в Todo и что-то будешь делать. А Scrum — это как раз-таки итеративный подход, и ты с спринтами работаешь. У тебя тоже есть бэклог, но ты вот из бэклога на 2 недели планируешь, что взять. А по Kanban ты просто делаешь то, что у тебя там, не знаю, на 3 месяца есть, да, у тебя бэклог какой-то, и ты просто по Kanban его перетаскиваешь, все задачки и делаешь их. Вот.

04:12

Speaker A

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

04:22

Speaker A

Угу. А в рамках Scrum какие ещё есть мероприятия? Какие бы ты выделил?

04:40

Speaker A

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

04:50

Speaker A

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

05:05

Speaker A

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

05:18

Speaker A

А что там ещё есть? Ну, вот ретро мы рассказали, да, то, что по ретроспективе спринта, условно. То есть мы это сказали: сам сборка спринта, three amigos, там было, ну, задачи, там защита техкома. Ну и, наверное, какие-то, знаешь, такие созвоны. А какие ещё? Ну, бывает ещё, когда у тебя Scrum в целом на 2 недели делится, но у тебя планы квартальные есть ещё. Есть такие ежеквартальные созвоны, вот, например, у нас, но это не скажу, что это прямо про Scrum, но вот у нас такое есть, поэтому, наверное, больше всё. А с грумингом бэклога? А, конечно, конечно, да. То есть когда мы грумим, мы берём туда... Ну да, то есть у нас это достаточно большой прямо пул задач, и бэклог тоже большой, он в целом разделяется. Вот, например, грумингом бэклога я занимаюсь по надстройке. То есть там супер много разных пользовательских задач, там от клиента какие-то платные запросы. Мы их вот смотрим и собираем, как раз-таки занимаемся грумингом этого бэклога там вот с продакт-оунером и разработчиками. Вот.

05:29

Speaker A

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

05:44

Speaker A

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

05:55

Speaker A

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

06:03

Speaker A

Ну, не совсем, на самом деле. Вот в IT-контакте, ну, когда вот есть же такое разделение между микросервисной архитектурой, да, и сервисно-ориентированной архитектурой, да, да. И, по сути дела, что IT-контакт, что CBN — это не супер большие биг-техи, да, в которых там реально микросервисная архитектура. Это всё-таки какая-то сервисно-ориентированная архитектура по большей части. То есть там пару систем есть, у каждой может быть БД, либо у двоих общая БД, но это сервисно-ориентированно, то есть там, знаешь, монолит, который пытается в микросервисы пойти. Вот поэтому по большей части я сервисно-ориентированной архитектурой и взаимодействовал.

06:14

Speaker A

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

06:27

Speaker A

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

06:37

Speaker A

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

06:52

Speaker A

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

07:08

Speaker A

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

07:15

Speaker A

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

07:29

Speaker A

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

07:40

Speaker A

Ну, ничего страшного. Самое главное, про один из самых популярнейших, скажем так, паттернов — сагу, как раз-таки про управление распределёнными транзакциями, ты рассказал. У

07:56

Speaker A

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

08:08

Speaker A

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

08:19

Speaker A

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

08:27

Speaker A

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

08:39

Speaker A

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

08:50

Speaker A

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

08:56

Speaker A

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

09:08

Speaker A

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

09:16

Speaker A

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

09:31

Speaker A

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

09:39

Speaker A

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

09:59

Speaker A

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

10:12

Speaker A

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

10:25

Speaker A

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

10:37

Speaker A

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

10:54

Speaker A

использовать, ну, вот банально не XMLку, да, а Jon, потому что она намного меньше весит.

10:59

Speaker A

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

11:18

Speaker A

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

11:31

Speaker A

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

11:45

Speaker A

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

11:55

Speaker A

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

12:11

Speaker A

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

12:22

Speaker A

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

12:32

Speaker A

Ну, app - это application program interface, да, это по факту, а, способ взаимодействия систем друг с другом.

12:40

Speaker A

Вот не обязательно клиента системы, то есть система и системой тоже можно общаться по апе. Да. Вот.

12:45

Speaker A

У, да. Хорошо. Вот. А, а какие у нас самые, ну, распространённые методы HTTP, так как мы говорим расска? Конечно, это Крудмодель, да, у нас это п, патч, э, get, post и delete.

13:02

Speaker A

Угу. А что такое методов? Это когда у тебя, кстати, на самом деле вот тут можно типа а немного углубиться.

13:13

Speaker A

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

13:26

Speaker A

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

13:45

Speaker A

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

13:52

Speaker A

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

14:02

Speaker A

Угу. О'кей. Но какие у нас методы являются? Get и не импотентными. Потом патч и кто delete, да? Да.

14:17

Speaker A

Угу. Т - это полное обновление, он не импотентен. Ну и пост - это создание, он тоже не импотентен. Вот.

14:23

Speaker A

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

14:29

Speaker A

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

14:54

Speaker A

Да, я работал с Ребитом на прошлой работе. Сейчас активно изучаю кавку. То есть её на работе хотят внедрить.

15:02

Speaker A

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

15:16

Speaker A

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

15:23

Speaker A

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

15:32

Speaker A

Угу. А в чём отличие Ребита от Кавки? Ну, по факту самое банальное, что у Ребита это first in first out, да? То есть там пуш-модель с консюмером. А у Ребита, ой, у Кавки это этот подписка на журнал считается по факту. И консюмер

15:50

Speaker A

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

15:57

Speaker A

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

16:11

Speaker A

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

16:24

Speaker A

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

16:40

Speaker A

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

16:55

Speaker A

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

17:08

Speaker A

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

17:18

Speaker A

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

17:26

Speaker A

Это там RPS, GRPS, потом Graph QL, а SOAP и какие-то событийные апи, наверное, ещё. Ну, что-то такое.

17:35

Speaker A

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

17:41

Speaker A

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

17:52

Speaker A

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

18:00

Speaker A

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

18:05

Speaker A

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

18:18

Speaker A

Ключ значения, графовая, столпчатая и какая-то вот не помню последнюю. Ну вот ты знаешь такой СУBD AMDB?

18:25

Speaker A

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

18:34

Speaker A

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

18:42

Speaker A

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

18:55

Speaker A

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

19:14

Speaker A

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

19:22

Speaker A

Угу. Вот так. О'кей. Отлично. А-а, а какие у нас уровни построения базы данных существуют?

19:32

Speaker A

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

19:48

Speaker A

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

20:00

Speaker A

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

20:10

Speaker A

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

20:27

Speaker A

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

20:40

Speaker A

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

20:54

Speaker A

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

20:59

Speaker A

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

21:12

Speaker A

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

21:26

Speaker A

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

21:41

Speaker A

Угу. Вот так. Угу. О'кей. А-а, зачем нам нужна нормализация БД? Ой, да потому просто потому, что каждой таблице будет храниться только то, что нужно в ней. И это для структурирования.

21:57

Speaker A

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

22:08

Speaker A

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

22:27

Speaker A

там BMW, а второй столбец - это модели. И у тебя может быть столбец BMW, а модели там 5,3,4 в одно в одной строчке.

22:36

Speaker A

Вот это это даже не в первой нормальной форме. То есть должно быть так, что строка BMW M5, BMW там 3 и всякое такое.

22:43

Speaker A

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

22:58

Speaker A

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

23:22

Speaker A

каждый неключевой атрибут а нетранзитивно зависит от первичного ключа. Вот так. Угу. Вот. Да, всё верно. Фух, сложно.

23:32

Speaker A

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

23:56

Speaker A

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

24:11

Speaker A

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

24:27

Speaker A

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

24:46

Speaker A

оптимизации делать? Разделить вообще свои таблицы на две на две категории. У тебя должны быть таблицы, которые данные заливаются, да? Это там all up и там второе, я забыл. То есть одно это, которое у тебя данные там обновляются всегда, а другие таблицы - это которые

24:59

Speaker A

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

25:14

Speaker A

Ой, что ещё такого? Вот, наверное, вот всё. Я вот не сильно там прямо силён вот в области БД. Вот что знаю, вот вот сказал.

25:23

Speaker A

Угу. Я тебя поняла. Отлично. А, ну и так, как ты сказал, что работал на всех уровнях с проектированием БД, я так понимаю, у тебя неплохо с СQэлем.

25:32

Speaker A

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

25:42

Speaker A

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

25:56

Speaker A

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

26:10

Speaker A

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

26:16

Speaker A

Поставщики и про Поставщики и продукты. Давай сейчас зарисуйся на тетрадке. О'кей. Поставщики, да? Давай. Да, да. Поставщики и продукты. Соответственно, у поставщиков идишник, как праймарики, а наименование, да, там из какой он страны.

26:32

Speaker A

У продуктов точно также есть айдишник, э, айдишник поставщика, как for, а наименование продукта, а страна, из которой продукт там и дата годности, да?

26:45

Speaker A

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

27:08

Speaker A

наименование продукта, наименование поставщика выводить. А сейчас и выводить наименование. наименование продукта и поставщика. Да.

27:21

Speaker A

Так, ну тут как будто обычный можно обойтись, да? Мм, мне его в чат написать?

27:27

Speaker A

Да, можешь с чата можешь, допустим, просто продемонстрировать мне экран там, допустим, в блокноте как-то или что?

27:33

Speaker A

Да, давай сечас, как тебе удобнее будет. Я сейчас мира просто открою, как бы, ну, чтобы вдруг что-то у нас ещё будет и в мира можно будет спокойно рисовать.

27:42

Speaker A

Так, сейчас демонстрация. Сейчас загрузится. Видно экран? А пока нет, не вижу. Воз А вот теперь вроде загружается. Да, вижу.

27:58

Speaker A

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

28:16

Speaker A

Select. А нам нужно product select products точка name запятая. Как поставщики, кстати, будут ка нет.

28:30

Speaker A

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

28:42

Speaker A

Секундочку, сейчас скажу тебя. Давай. А-а, а можешь provваiders, к примеру? О, спасибо. Прова. Проваiders. Точка тоже его имя, да?

28:53

Speaker A

Вот. А select providers. А дальше from providers а join products on providers id = products.providers providers ID where арона кого нам нужна, продукта или поставщика?

29:33

Speaker A

А продукта. Ага. Products country. А in Давай вот так напишем R. Ну, вдруг мы дополним список and products точка date. Просто date напишу, да, там дада. Может не вы больше либо равно. А как это у нас там датам? Ну, как угодно,

30:00

Speaker A

наверное, они могут писаться. Я уже не помню. Просто напиши как бы, да, в каком видео.

30:05

Speaker A

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

30:12

Speaker A

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

30:23

Speaker A

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

30:33

Speaker A

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

30:49

Speaker A

да. Ну вот у тебя есть пересечение каких-то таблиц, это у тебя inner joint будет да?

30:54

Speaker A

А left joint у тебя будет вот вот это всё, то есть и пересечение, и то, что в левой. Ну вот так бы, наверное, объяснил, думаю, было бы понятно.

31:02

Speaker A

Угу. Угу. Ага. Отлично. Хорошо. Да. Давай сразу дам тебе ещё одно, э, практическое задание, правда, не по сQэлю.

31:10

Speaker A

Что там? А ты упоминал, что ты работал сюмейлем, в том числе с с план юмейлем, я правильно понимаю? Работа.

31:17

Speaker A

Давай открою планil просто тогда. Да, давай. Угу. Так, вот так откроем. Это их документацию. А вот так перевагу. А с какими А с какими диаграммами у ЮМля тебе приходилось работать? По факту большой, по большому счёту это диаграмма Сиквенса, да? Вот. Угу.

31:38

Speaker A

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

31:49

Speaker A

Вот. А, и ещё использовалке диаграмму, но её лучше просто в мир рисовать, нежели в план писать. Вот.

31:58

Speaker A

Угу. Ну, всё, вот так. Ну давай тогда начнём. Давай тогда возьмём за SEC диаграмму.

32:04

Speaker A

Смотри, а у тебя есть процесс авторизации аутентификации пользователя в системе. Мог бы ты мне это показать на sequнс диаграмме, пожалуйста?

32:13

Speaker A

Без проблем. Так, что там? Parti party se user as user. А нет, не партип, это надо называть.

32:30

Speaker A

Это вроде Эктор может называться. Угу. Что там не так? Synx error. А это тут это просто то, что ты писал.

32:41

Speaker A

А front да [музыка] и DB asdb. Всё правильно. Да. М какой-то автор можем сделать, да, если он нам нужен.

33:04

Speaker A

Так, ну поехали. Userер. А как там? Вот так. To front. А вот логина и пароля.

33:18

Speaker A

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

33:45

Speaker A

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

33:57

Speaker A

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

34:11

Speaker A

Пойдёт. Угу. О. Да, давай, давай. А DB. Так. Вот так у нас или сейчас я вспомню, вроде вот так. DB на БК. Сейчас я посмотрю, как она нарисовалась. А аутификация прошла успешная аутика, то есть человек тот, за кого себя выдаёт.

34:30

Speaker A

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

34:50

Speaker A

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

34:59

Speaker A

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

35:12

Speaker A

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

35:20

Speaker A

Да. А вот как раз-таки вот это уже там асинхронное там взаимо, ну, то есть вот это вот это асинхронное взаимодействие уже как-то так. Вот.

35:28

Speaker A

Угу. О'кей. Хорошо. Давай дальше. Давай дальше. Продолжий. Тификация. А, успешная мотификация. Человек вы, ну, он есть у нас в этом. И БК отдаёт. Ну, у БКА опять же, наверное, какой-то процесс есть опять на БК, связанный уже с авторизацией, выдача конкретных прав,

35:49

Speaker A

да, но отправим это на фронт, то есть успешная авторизация. Вот успешный и front на usеer.

36:04

Speaker A

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

36:16

Speaker A

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

36:38

Speaker A

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

36:58

Speaker A

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

37:18

Speaker A

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

37:37

Speaker A

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

37:57

Speaker A

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

38:09

Speaker A

Угу. Это всё. О'кей. Супер. Угу. Так. О, одну секунду, я открою дверь. Хорошо. Да, хорошо.

38:23

Speaker A

Угу. Всё, я тут. Угу. А подскажите, приходилось работать с дживити токенами? Да. Вот как раз на lowcд платформе у нас были настроены они. То есть я понимаю, что Gon Webtкеen, да, у которого есть headers плюс ещё тело. И это из себя там

38:51

Speaker A

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

39:10

Speaker A

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

39:22

Speaker A

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

39:36

Speaker A

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

39:49

Speaker A

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

39:57

Speaker A

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

40:13

Speaker A

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

40:26

Speaker A

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

40:38

Speaker A

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

40:47

Speaker A

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

41:09

Speaker A

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

41:18

Speaker A

А по факту проjectжет менеджер - это человек, отвечает. Ну, то есть prodcter - это, если мы говорим, ну, когда есть команда, то бывает, ну, там в идеале либо в книжках есть productт owner, да, есть projectт-менеджер.

41:29

Speaker A

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

41:41

Speaker A

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

41:52

Speaker A

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

42:00

Speaker A

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

42:15

Speaker A

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

42:23

Speaker A

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

42:30

Speaker A

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

42:38

Speaker A

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

42:47

Speaker A

Что-то такое может быть есть. Но по большей части я вот сталкивался с багрепортом и с тесткейсами. Вот.

42:51

Speaker A

Угу. Угу. А какие у нас вообще в принципе классификации тестирования существуют? Сейчас скажу. Функциональное тестирование, да? Ручное.

43:03

Speaker A

Угу. Регрессионное. Угу. И смоук какие-то тесты я знаю ещё есть. Угу. А интеграционное тестирование ты не проводил?

43:13

Speaker A

А, ну конечно. Ну, блин, ну это это хлеб, аналитика. Я должен это проводить. То есть, ну, через Посмон либо через ещё в Майкрософте у нас, короче, у нас на сайте реализована двухфакторка, и Посман плохо умеет в двухфакторку. Там надо

43:26

Speaker A

куки копировать и вставлять как Headers в Postman и потом отправлять запрос. Это не супер удобно. И у нас, э, ну, не у нас, а в целом есть в Майкрософте такой плагин, называется RESED. И ты, когда в Майкрософте зашёл на сайт, то есть ты

43:40

Speaker A

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

43:55

Speaker A

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

44:16

Speaker A

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

44:31

Speaker A

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

44:42

Speaker A

фронту, и он так сверстал. Вот что-то такое. Угу. Угу. А что такое UI и что такое UX, знаешь?

44:50

Speaker A

Ну да, конечно. То есть не я в целом знаком с Фигмой, я даже в ней, э, э, работал. То есть вот те же прототипы, там какие-то базовые анимации, я знаю, как они там настраиваются в той же Фигме. UI - это user interface, UX - это

45:02

Speaker A

user experience. То есть UI - это условно, если прямо утрированно как-то говорить, да, это за внешний вид, UX - это за пользовательский опыт. Вот.

45:11

Speaker A

Угу. Да. Отлично. Хорошо. И ты упоминал, что у тебя есть петпроект, ты там занимался развёртыванием, то есть получается, ты знаешь функцию Девопса на проекте, кто это такой, за что он отвечает. Ну, типа, как бы, ну, вот базовую штуку спрашивал,

45:23

Speaker A

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

45:39

Speaker A

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

45:50

Speaker A

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

46:06

Speaker A

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

46:20

Speaker A

Да. Угу. О'кей. Отлично. Аа с системами логирования и мониторинга приходился работать на Ну, с графаной. Вот с графаной я по большей части работал, да.

46:30

Speaker A

Угу. Угу, угу. Отлично. Хорошо. А тогда у меня всё. Может быть, у тебя есть какие-то вопросы ко мне?

46:38

Speaker A

Ой, на самом деле нет. Ну, наверное, просто интересно сейчас вот что будет дальше.

Topics: системный аналитик собеседование требования Scrum Kanban микросервисы SQL Agile UML диаграммы IT-карьера

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

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

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


---
This is the markdown twin of https://sozai.app/transcript/systems-analyst-interview-tasks-2025-real-examples/ — 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/