Меня спросили вообще всё! Реальное собеседование на системного аналитика

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

Я в Москве. Угу. Я не увидел кажу. Хорошо. Ну первый вопрос наверное стандартный да?

Я в Москве. Угу. Я не увидел, кажу. Хорошо. Ну, первый вопрос, наверное, стандартный, да?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ну и вот, соответственно, тогда мы будем считать RPS именно по этим пиковым точкам. Вот.

нас аудитория пользуется нашей системой, нашим приложением. Потому что у вас мобилка, да, какая-то там в 8:00 утра, когда едет в метро на работу и там в 5:00 вечера, когда едет в метро домой.

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

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

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

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

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

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

Да. Да. Ну вот мы проговорили про артефакты, которые ты готовишь, там ТЗ какое-то, вот нефункциональные требования описываешь. А если говорить про описание самих API, в каком формате, может быть, со Swagger работал?

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

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

осталось немно. Да. Да. Ну вот мы проговорили про артефакты, которые ты готовишь, там ТЗ какое-то, вот нефункциональные требования описываешь. А если говорить про описание самих АПИ, в каком формате, может быть, со Свагером работал?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Угу. Ну да, это действительно про удобство работы с требованиями. О'кей. Да, давай наверное про про рес SUAP поговорим поподробнее вообще, что это такое и ну и как сталкивался с этим делом. Всё.

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

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

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

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

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

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

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

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

Значит ст обладает предписывает, да? А значит, использует шесть принципов основные. Это клиент серверность, это шируемость, это statтless, это единообразие интерфейса, сеня архитектура и код по запросу. Вот, э, REST, ну, Rest AP, точнее, да, в Restful или Restlike, тут уж как

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

Вот. Ээ, ну, наверное, это всё. Если [смех] есть какие-то уточнения, то ты говори, я подсвечу.

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

А, Postman. В основном Postmanн, на самом деле. Volkswagen. Ээ, ну, постольку поскольку в принципе тоже, да, но вот, ну, Посмон просто, наверное, как-то чуть привычней. Вот. А, вот. А так, да, а, ну, если мы говорим про мобилки, то

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

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

Да, да, да, конечно. А из UL диаграмм, ну, вот ирдишка, ну, хотя хотя, по-моему по канону не относится к UML, но не суть. А значит, из чистых UMLных это state machine диаграммы рисовал, data flow диаграммы, activity диаграмма крайне редко, но иногда приходилось, а

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

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

Угу. Ну, то есть когда-то что-то было там по А если говорить про план UML, ну, насколько глубоко, то есть там вот есть оператор Destroy пользовался таким или нет?

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

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

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

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

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

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

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

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

Ну да. И ну я имею в виду, что насколько ты с ним вот как общался?

Кто-то, например, просто только читает. Кто-то вообще, в принципе, ничего никогда там не делал. А Угу.

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

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

где-то в тех, короче, лет пять, наверное, назад в тех краях значит, а был на двух проектах, где пытались внедрить Dogs of the CД. Вот. И, соответственно, вся аналитическая документация лежала как раз в ГТЕ рядом с кодом. И вот аналитику заставляли

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

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

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

Слушай, не уверен, что приходилось откатываться, честно говоря. Не уверен. Угу. Ну о'кей. Да, понял.

Продолжаем да? Угу. Давай, наверное, про базы данных поговорим. Вот, ну, ты уже упоминал Постгрес.

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

Ну да, конечно, в основном опыт был с реляционками. Это постгроз, это МСQL. Когда-то ещё до санкций. Вот, значит, да, и в принципе, наверное, всё. Ну, где-то на учебных проектах, понятно, видел MyQэль. Вот с Ороклом вообще никогда не пересекался.

Вот из нереляционок, э, немножко работал с Монгой. Вот, а именно в том плане, что, ну, непосредственно сам, да, как-то взаимодействовал. Вот. А так, ну, вот, допустим, в том же самокате там, ну, у нас на ДВХ Касандра имеется, Гринплам,

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

спокойно себя живёт. Вот. Ээ, ну вот, наверное, такие варианты. Угу. [смех] А оптимизировать запрос мы можем?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

проходил не там через номинальные 10 минут, да, а там через 955, например, через 956. Ну и так вот, короче, размазывать эту нагрузку по чуть-чуть.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ну да, как вариант. Или что-то, ну или там, я не знаю, какую-нибудь кронжообу в фоне, которая будет чекать таблицу в базе, да. и а обновлять соответствующее значения в КШР.

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

Кавка Connct да не знаю, с GDBC коннектором есть или там DBIUM для CDC, вот, э, но в остальном, по-моему, он так напрямую не прикручивается ни к БД, ни к кэшу, но я могу ошибаться здесь.

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

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

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

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

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

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

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

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

так и есть. Да, ну очень хорошо. Ну там, да, ещё есть кое-что. Ну в целом, да, так и есть.

Ну о'кей. Приходилось ли тут немножко сейчас разнобой чуть-чуть будет. У нас видишь где-то плавный вопрос один из другого текает. А где-то в разнобой будет. А с Фигмой вообще работал?

Да, да, да, с Фигми работал. И когда ты и сам что-то рисовал, ну, и с дизайнерами понятно взаимодействовал.

То есть, ну да, дизайн. А сейчас на текущем проекте у вас где рисуют дизайн?

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

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

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

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

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

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

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

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

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

системы мы можем затронуть, да, зафексить нашей фичой. И в зависимости от тяжести случая уже накидывал, э, ну, какой-то пхAD по оценке там 20-30%, 40%, условно. Вот.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Вот. Но из минусов, соответственно, ну, тут опять же зависит от того, какой паттерн мы используем или share database или database perвиice. Но, как правило, database perвиice считается по умолчанию.

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

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

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

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

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

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

Вот. Угу. А если ещё говорить про нагрузку и какие-то случаи, что нам надо обработать недоступность сервиса, вот есть такая штука, как circuit breaker. Угу.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Приходилось ли вот выполнять такие требования от безопасников по части маскирования вот этих вот чувствительных данных персональных?

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

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

Да, вроде бы нет. Вроде бы нет. Тогда спасибо за собеседование. Всё взаимно. Спасибо. Интересного дня.

Да, спасибо и вам. Хорошего дня. Да, всего доброго. До свидания. До свидания. До свидания.