Speaker A
Скажи, пожалуйста, как тебе удобно общаться, на ты или на вы? На ты. Отлично. На ты? Угу. Согласна.
Мок-собеседование системного аналитика: самопрезентация, опыт в банках (Росбанк, Открытие), вопросы по брокерской деятельности, инвестициям и блокчейну. Разбор ошибок кандидата.
Key Takeaways
- Кандидату важно уметь чётко и структурированно рассказывать о своём опыте, отделяя реальные задачи от теоретических знаний
- Для системного аналитика в банке полезно понимать базовые финансовые инструменты, протоколы взаимодействия (REST, gRPC) и процессы поставки ПО
- Честное признание пробелов в знаниях с обещанием их восполнить лучше выдуманных ответов
- Ведение встреч и фиксация договорённостей в письменном виде — ключевые навыки аналитика
What the video covers
- Формат: прогон собеседования на позицию системного аналитика с обратной связью по ходу разговора
- Кандидат представляется, рассказывает о проектах в Росбанке (переход корпоративной соцсети на новый интерфейс) и в Открытии (сервис формирования отчётов)
- Обсуждается учебный проект банковского ДБО и опыт перевода сервиса с JSON-RPC на gRPC
- Разбираются понятия брокерской деятельности: долгосрочные инвестиции vs трейдинг, технический и фундаментальный анализ
- Затрагиваются блокчейн, смарт-контракты, криптобиржи и реестр акций
- Рассматриваются нефункциональные требования и выбор между REST, gRPC и другими протоколами
- Обсуждаются процессы разработки: гит-ветки, сборки, конфиги, версии поставок
- Кандидат признаёт пробелы в знаниях (например, по техническому анализу, блокчейну) и обещает изучить темы
- Ведущий даёт практические советы по ведению встреч аналитика и согласованию требований
- Видео полезно как пример неформального мок-интервью и типичных вопросов для аналитиков в финтехе
Chapters
Full Transcript — Download SRT & Markdown
Speaker A
А для начала представлю Я работаю в системном аналитике на прое системным аналитиком на чуть больше года. А я, к сожалению, не свят чем смогу, помогу, конечно.
Speaker A
Вот. А расскажи, пожалуйста, о себе. А был ли у тебя какой-то опыт, может быть, работы разработчиком или аналитиком в предыдущих периодах? А или можешь рассказать про неё?
Speaker A
Хорошо. Ну, вообще с банками я давно связана, но вот в разработке я как раз с момента обучения, соответственно вот э ну допустим у меня в резюме написано про Росбанк. Я действительно принимала участие вот в переходе корпоративной соцсети на новый
Speaker A
интерфейс. Мы очень много коммуницировали с, ну, так скажем, с заказной разработкой, с фендерами и ставили им задачу в Джири, отслеживали прогресс. То есть, в общем-то, здесь с точки зрения вот скорее какой-то бизнесовой части был опыт, но он не не
Speaker A
напрямую связан именно с работой системы. просто, ну, немножко знакомо вот это взаимодействие между командами и вот этот весь процесс.
Speaker A
А так вообще Угу. Ну, ты со стороны заказчика получаешь, получаешь процес, да, как раз, да, как оценивать это всё, э, работу.
Speaker A
Верно, да, с другой стороны побывала. А в каком учебном проекте ты была, какие задачки?
Speaker A
Угу. Ээ, так, я была на бумеранге, мы входили, там три команды. Ээ, я входила в команду, а-э, разработки веб-приложения банковского дистанционного банковского обслуживания.
Speaker A
И там я, ну, я достаточно быстро просто прошла все срезы. Я не успела там сильно много задачек решить. Э, но был опыт перевода сервиса с, там, допустим, с пятью или шестью методами на JRPC. То здесь тоже мы много с разработчиками
Speaker A
общались, прямо интересно было и как-то и кода было много. И в общем, вот такая интересная задача, про которую я тоже могу рассказать. Она у меня включена в резюме.
Speaker A
Да, я обратила на неё внимание. Это было самое интересное. [смех] Это такой тренд, мне кажется, немножко, да, на GRPC. Вроде я так край мух слышала, что в некоторых вакансиях прямо аэ как одно из таких желательных а навыков да спита.
Speaker A
Да, поговорим про это ещё. Не, то есть в банке есть, но не везде, не во всех микросервисах его используют. Вот. Но как бы я лично не сталкивалась, но твоё мнение послушать будет очень интересно.
Speaker A
[смех] Да, это прикольно. К сожалению, сложно оценить реально за полетел ли после этого сервис или споткнулся ещё обо что-то. Вот здесь, конечно, мне кажется, миллион нюансов.
Speaker A
Угу. Хорошо. О'кей. У тебя, конечно, достаточно требовательный проект, я хочу сказать. Я смотрю, да, что же мне делать там же.
Speaker A
Вот же тебе хороший вопрос. Ну, попытаемся хотя бы по верхам пройтись, по вопросом разобрать.
Speaker A
Вот там уже как бы как повезёт, потому что естественно если аа тех или тот, кто будет тебя собесить со стороны заказчика, захочет вникнуть дебри и тебя завалить, тут, наверное, ну, никто не поможет, и ответственности твоей уже в этом не будет.
Speaker A
Вот если потребуется просто знания как бы базовых вещей, тогда о'кей, это попробуем вырулить. Вот. А давай начнём с твоего рассказа и потом я задаю тебе вопросики, потом обсудим а обратную связь и можешь позадавать какие-то вопросы.
Speaker A
Угу. Хорошо. Да, расскажу про свой опыт. А я работаю системным аналитиком более чем 3 года. А удалось поработать в двух банках.
Speaker A
два совершенно разных проекта. Вот первый проект, а в нём было меньше технической составляющей и больше работы с требованиями и с, скажем так, с пользователями. А это была, а я работала в фронт-команде ээ банка Росбанка. А задача была перевести корпоративную соцсеть на новый
Speaker A
интерфейс. Здесь я много собирала требований, изучала м, ну, скажем, какие ошибки бывают, какие у пользователей случается боли, тем более, что это наши сотрудники были. Это было сделать, в принципе, довольно несложно.
Speaker A
А затем прописывала стари, ээ, рисовала интерфейсы вот Фигми, а, возможно, и переходы между ними, что позволяло очень хорошо отследить вот пользовательский путь. А команда у нас была небольшая, семь человек, два аналитика, два разработчика, два тестировщика и PM. А мы активно
Speaker A
взаимодействовали с, а, с тем, кто предоставлял нам вот это программное решение. Мы его просто вот, скажем, внедряли в наш ну внутренний контур. А то есть продукт был ответочное решение.
Speaker A
Что? Коробочное решение. Да, верно. Да, коробочное решение, но его нужно было как-то интегрировать, дать ему доступ, внедрить, как включить в наши внутренние процессы и чтобы он удовлетворял всем требованиям безопасности. Поэтому здесь надо было тоже нам с нашей стороны активно
Speaker A
поработать. А, мм, если есть какие-то вопросы, я готова ответить, но я могу вот к последнему проекту перейти. Вот где я сейчас заканчиваю работу. А сейчас я работаю в банке открытия, а уже в бэкэнд разработке. Мне захотелось вот фронт уйти больше вот в
Speaker A
технологии, а, в разработку микросервисной архитектуры. А, и вот в открытии мы как раз с командой занимались формированием сервиса, а, сервиса формирования отчётов. Вот в рознич у нас был департамент розничного бизнеса, а команд несколько команд, которые занимались платежами и
Speaker A
переводами. И вот наша команда занималась тем, что вот, э, разрабатывали сервис, который брал, э, информацию с платёжного сервиса, с сервисы переводов, сервисы информации о счетах, о клиенте и генерировал на основе вот этой информации отчёты, дашборды, диаграммы, чтобы пользователь
Speaker A
мог и выписку просто со списком операций ээ получить, ну, и также какую-то небольшую аналитику.
Speaker A
Команда была побольше. Ну, также мы вот с аналитиком в паре работали. Мм, ну и также активно с разработчиками, с смежными командами.
Speaker A
Угу. О'кей. А скажи, пожалуйста, а приходилось ли тебе сталкиваться с направлением брокерской деятельности? А, да, конечно. Наш сервис, в том числе собирал информацию ительности наших клиентов. Аа, то есть мы учитывали не только расходы, но и доходы, но, естественно, и вложения, и тот, а,
Speaker A
доход который наш пользователь получал. Поэтому а ну скажем мм верхнеуровнево, в принципе, вот сам сами само бывают решения, какие вот в банке они существуют. Плюс-минус в банках очень похожие решения. Это и и брокеров. То есть, в принципе, такое представление имеется.
Speaker A
Угу. Ну, что касается каких-то А так, нет, неправильно сказала. А, ну, то есть вы основывались на тех суммах, то есть финансовых показателей, то есть значений, да, и уже на основании этого какие-то делали свои отчёты, фичи.
Speaker A
Мы по факту регистрировали просто движение денежных средств и понимали, откуда, с какими целями человек переводит средства. Соответственно, если кто на свой э счётдил, но эти внутрибанковские платежи, внутри вот счетов одного клиента, мы также видели и всё это, то есть это было
Speaker A
удобно клиенту посмотреть, сколько он вложил средств, сколько он сейчас получает. Ээ Угу. сервис довольно популярный.
Speaker A
Вот и вывод денег вот в доверительное управление, да, можно так сказать. А, да, это вот именно я могу это записать, это как такое термин, который я могу использовать или это просто сейчас так мне нужно какие-то такие слова [смех] из реальной практики
Speaker A
использовать. Можешь просто это будет нормально. Ты всё хорошо пока рассказываешь, не переживай. О'кей. А вот хорошо.
Speaker A
[фыркает] М, ну, у нас в основном направление связанное с инвестициями, трейдингом, а, поэтому хотелось бы позадавать пару вопросов, если ты не против.
Speaker A
Да, конечно. А скажи, пожалуйста, вот в чём отличие как целена на долгосрочные вложения средств? А трейдинг - это игра на повышение, понижение стоимости акций или валюты.
Speaker A
Угу. То есть краткосрочная какая-то стратегия? Да. Краткосрочная, да, верно. Угу. А на чём вы больше основы и на чём основываются трейдеры в своих покупках?
Speaker A
Убирают более консервативные стратегии. трейдеры более рискованные, но более высокодоходные. Угу. А ты слышала про технический анализ и фундаментальный анализ?
Speaker A
Нет, надо почитать. Ну это что-то, наверное, с с краткосрочным и долгосроч О, отлично. Как технический и какческий анализ его могут использовать, естественно, все. А фундаментальный анализ - это больше это предполагает анализ отчётности, выручки, капитализации компании. То есть оценивается именно компания финансовым
Speaker A
показателям насчёт того, стоит ли в неё вкладывать деньги, будет ли она там устойчива в долгосрочной перспективе и так далее. А технический анализ - это больше анализ графиков.
Speaker A
А, и он используется больше, наверное, в трейдинге для того, чтобы поймать краткосрочные колебания. Угу.
Speaker A
Вот. Угу. Ну, то есть для трейдеров фактически это просто вот шкала, которая меняется с продавать на покупатели там что-то среднее. Вот когда покупаш, они анализируют вот этот график, да, типа голова и плеч идёт вниз. И вот на основании этого графика уже алгоритмы
Speaker A
выставляют, что типа продавай или покупай. А что знаешь ли ты, что такое шорт? Знакомое слово, сейчас запишу.
Speaker A
А, ну это, возможно, какая-то какое-то отсечение. Что-то что-то краткосрочное, но я не знаю, надо почитать. Как раз вот я и хотела от тебя добиться.
Speaker A
Что мне конкретно? То есть можно, я включила ролик, обалдела от количества незнакомых слов и думаю, нет, надо всё-таки как-то точечно именно то, с чем я, например, на практике да скажу я но взаимодействовала и вот знаю там какую-то базу. Вот всё. Шорт - это база,
Speaker A
видимо. [смех] Ну вот даже мно не знаю толком, что такое шорты, как это работает, потому что обычно все хотят прода, ну, покупить за более дешёвую цену и продать за более дорогую. То есть это стандартная обычья стратегия, которую знают, наверное, все.
Speaker A
А шорт - это наоборот. Шорт означает, что ты берёшь у банка, а акцию а в аренду, например, в начале дня и в конце дня ты должен вернуть её назад. И это означает, что ты играешь на понижение. И в случае, если цена упадёт, ты получаешь
Speaker A
доход, потому что ты её отдал по цене меньше, чем ты её взял в начале дня.
Speaker A
Угу. И как правило, да, ну это не обязательно, что это там в течение дня шорт можно оставить там и на все выходные, но это считается более рискованным. То есть шорт он всё-таки предполагает короткую какую-то операцию, как ты и сказала. Вот. Но вообще это
Speaker A
именно игра на понижение. Ну, это такая более агрессивная стратегия, да, ведь? Угу. Да, [фыркает] агрессивная, трейдерская как раз стратегия. Хорошо, если говорить про мобильное при вот как происходит путь, а, от выставления заявки, ну, допустим, я вложил сумму денег. Вот. А как проходит
Speaker A
путь от подачи заявки до, а, как бы фиксации этой акции на моём счёте? Закрепление за мной.
Speaker A
Ну, здесь, конечно же, нужно, если это микросервисная архитектура, вот всё зависит от того, как вот это принято. В принципе, через шину тоже довольно хорошо, наверное, это делать, потому что здесь гарантия доставки и, э, мультипротокольность, вот эта большая надёжность, что, в принципе, важно для
Speaker A
покупки, ну, для операции с акциями. Ну, вот, например, у нас микросервис. Тут я, конечно, уточню у интервьюера, какая архитектура предполагается, как какая у вас практика, ну вот в реальности, какой архитектура есть. Ну, допустим, если это микросервис, то точно это мм должна быть
Speaker A
устойчивая к отказам системы. То есть какой-то асинхронный, асинхронная обработка сообщений должна быть, должен быть запрос в репозиторий некие, некое хранилище акций, ээ, которое подтверждает покупку, то есть движение денег. Э и на счёте клиента блокировка этих средств. Обязательно нужно в асинхронном режиме
Speaker A
подтверждения, что, а, акция доступна, что мы её можем покупать, обмен, перечисление денег, получение акций, какая-то отметка вот в реестре этих акций, что эта акция продана, и тогда транзакция завершается. Здесь может быть несколько участников.
Speaker A
Например, если организовать это просто через, а, ашлюз, то есть с с мобильного приложения, а, допустим, можно BFF вообще модель использовать. У нас для веб сервиса будет отдельный шлюз для мобильного приложения, для десктопного.
Speaker A
Ну, десктопная вряд ли в банках используется. Ну, возможно, там iOS и Android. Вот, возможно, такое разделение. Вот, например, на свой шлюз переходит запрос, потом он идёт в, а, проверяет наличие счёта в аккаунтсервис, к примеру, он переходит, потом он переходит в платёжный шлюз, там
Speaker A
своя очень сложная система через корреспондентские счета. А я с ней непосредственно денег не берём в расчёт, как бы с ним. Угу.
Speaker A
Да. Да. Вот. Потом идёт запрос в репозитории этих акций или как, кстати, правильно называется? репозитория акции, ну некий некий ре Ну хорошо, реестр акции реестр. А где он, например, Мостбиржа та же мы можем через Мостбиржу.
Speaker A
А а если это иностранные акции? А иностранные акции в Российской Федерации, к сожалению, нельзя сейчас приобрести, но если бы можно было, то должен идти запрос через в любом случае посредника в той в роли той же Мосбиржи запрос за рубеж на право покупки. вот
Speaker A
этой акции. Подтверждение из зарубежа, подтверждение от Мосбиржи. Я веду, что это будет какой-то брокер. То есть это будет не регистр, [смех] да? Это будет какой-то брокер, с которым там заключены соглашения и как бы, собственно говоря, он и там уже мы отдаём ему на откуп, и мы
Speaker A
не следим, что он делает. Ну да, да, да, так проще будет, да. Угу. Это, в принципе, было, наверное, единственное. Хотела спросить, да, почему был выбран асинхронный обмен сообщениями?
Speaker A
Потому что возможны задержки в работе брокера. А, и клиент не должен быть в это время заблокирован. Возможно, допустим, при снижении стоимости акций или при ожидании роста акций возможен повышенный спрос на покупку или продажу.
Speaker A
И наше приложение должно работать безотказно, соответственно. А если мы м будем требовать от сервера моментальной обработки наших запросов, он может просто лечь.
Speaker A
А возможно моментальная обработка случае покупки акци ещё раз. Возможна ли моментальная обработка в случае покупки акций? Вот если мы рассмотрим клиентский путь, то как вот это происходит?
Speaker A
Ну, если мы хотим синхронную, в смысле операцию совершить, да, синхронное взаимодействие, ну, можно моментальное. Моментальное. Ну, можно, можно, в принципе, при при мм м а при использовать брокер сообщений, тот же Кавка, который принимает очень большое количество сообщений и способен быстро
Speaker A
транслировать их, получение этих сообщений для получателя, для подписчика. Здесь очень у него очень большая м как это сказать пропускная способность.
Speaker A
О'кей. А другой вариант, можем ли мы организовать это, аа, как ты сказала, моментально? То есть просто рест он отправил в заявку и сразу за ним закрепилась акция.
Speaker A
Мм, теоретически опять же, что мы имеем в виду под слово моментально? [фыркает] Это миллисекунда, это там 3-30 мисекунд секунда. Ну, допустим, если это там доля секунды, ну, возможно, нам нужно использовать какие-то как это интеграции, которые нам дают многопоточность. Тот же GRPC, например,
Speaker A
можно использовать, так как он сериализует данные, и они моментально могут в большом количестве несколькими потоками направляться к получателю.
Speaker A
Угу. Хорошо, я поняла. Давай вернёмся к клиентскому пути. Я клиент. А у меня открыт Я выставляю заявку на покупку акций. Что происходит дальше?
Speaker A
Вот я пишу, что я хочу купить акции а Росттелеком в количестве 10 штук по ценето.
Speaker A
Всё, сразу покупаем. Нет, оформляется заявка на покупку, потому что мы должны удостовериться у через брокера, что они доступны, что мы можем их купить. А у нас меняется статус. То есть, например, человек оформляет заявку в своём мобильном приложении на приобретение
Speaker A
акции. Ему выпадает список, он выбирает Ростелеком, количество, и он видит свой статус обязательно, что, например, статус ожидаем ответа брокера или может бы вообще закрыть эту процедуру просто, а за ваша заявка в обработке. Мы обязательно вам сообщим.
Speaker A
Как ты считаешь, есть место в этом процессе для какого-нибудь менеджера банка, который может подождать, пока цена упадёт, и купить для банка подешевле? Вот клиент выставил по два, взял по один купил.
Speaker A
А, ну здесь нужна безопасность ещё, да? Видимо, нет. Почему? Для банка это же хорошо.
Speaker A
Это доход. Что? [смех] Если это законно, то это законно. Почему? Он же выполнил. То есть ты закрепишь за клиентом. Он выставил заявку вот сегодня в час по два, а в 3 часа ты её исполнила и была уже цена один.
Speaker A
Ты же закрепила акцию за клиентом. Они просто Да, то есть это риск как бы на клиенте.
Speaker A
Почему нет? Ну, с точки зрения банка, конечно, это выгодно. Просто всё зависит от практики, насколько это проверяемая информация, насколько клиент сам может зайти на какой-нибудь сайт и посмотреть, а сколько вот на момент перехода моей заявки в исполнена, какая была стоимость
Speaker A
акции. А это то, если это если это нельзя посмотреть, то, конечно, это идёт доходы банка. Безусловно, это очень звучит как план да.
Speaker A
Ну, то есть всё-таки есть там роль менеджера, который связывается с доктором, выполняет какую-то свою задачу, после чего меняет статус, и это не происходит в течение 30 даже секунд и даже 30 минут.
Speaker A
А, то есть это невозможно. Моментальная покупка акции невозможна. Супер. Хорошо. Так, мне очень нравится, как ты отвечаешь. Честно говоря, говорят, что я очень так умно выгляжу.
Speaker A
Умно. Ничего не понимаю, но очень [смех] интересно. Очень достоверно отвечаешь. Мне понравилось. Так, ну вот надо про акции ещё вот это всё.
Speaker A
Ну, про акции мы в принципе проговорили нормально, а вот про крипторжу. Знакома ли ты с процессом покупки криптовалют? И как работает?
Speaker A
Нет, незнакомо, но явно тоже какой-то некий, ну, система, ну да, она попроще. Там нет брокера. Здесь как раз-таки возможна моментальная покупка. Здесь нет последника, правильно, в роли какой-то организации.
Speaker A
А у Альфабанка, по-моему, есть такая услуга, да, покупки криптовалюты. Да, да, есть. Я прогон проходила как раз с молодым человеком, который мне именно давал вот такую задачку. А как будет выглядеть сервис покупки криптовалюты?
Speaker A
Вот. А сложно, на самом деле, но это похоже на просто перевод денежных средств базово.
Speaker A
Угу. Да. Только взамен ты получаешь не сумму, как бы, а на свой кошелёк получаешь какую-то крипту. как обмен валюты, да, только не валюта, а крипта получается.
Speaker A
Какие здесь вот, например, у самое важное такое вот ну роль роль, да, криптобиржа криптобиржа, да, причём они должны быть зарегистрированы и так далее. Хорошо. Ну давай тогда тебя спрашиваю, что такое блокчейн технология и как это всё работает. Смарт-контракты.
Speaker A
Смарт-контракты не скажу. Блокчейн - это способ хранение информации, когда на предыдущую блок информации записывается в следующей итерации ещё информация. То есть вся предыстория хранится в каждой, а в каждом элементе этой цепочки, условно.
Speaker A
Угу. А что там с Что? Смартконтракт он, в принципе, на технологии блокчейна и основан что [фыркает] а ну выставляется например заявка что я вот готов продать по такой-то цене. И когда а предложение встречное соответствует, то типа короче, я типа сама не помню, я очень
Speaker A
давно. А это крипта тоже? Блокчей. Это же с блокчейном и криптой, да? Так, ну да, компьютерный алгоритм, который содержит условия договора и предназначен для как бы автоматической сделки.
Speaker A
Угу. Ну всё, у меня уже есть список того, что мне надо почитать. Да. Ковора.
Speaker A
Так, а, наверное, с этим пока всё. Я тебе отправлю ещё курсы на английском языке Смуle. Ты их уже, может быть, тебе кто-то отправлял?
Speaker A
Нет. Нет? Угу. Если у тебя с английским языком хорошо, можешь посмотреть. Да. Там не все прямо супер детализированные и полезные, но что-то можноть по тому же техническому анализу и так далее. Как это работает? А скажи, пожалуйста, с какими видами приложений тебе
Speaker A
приходилось работать? Мм, а в основном это были веб-приложения. С мобильными приложениями работала другая команда.
Speaker A
Угу. То есть iOS Android не было? Да, не было. Да. А что такое Webvw?
Speaker A
Webv, да, но это моё предположение, закашированная страница которая эээ при повторном обращении появляется гораздо быстрее, чем первый раз после запроса сервера. Нет.
Speaker A
Ну ты просто можешьтивное приложение, когда тебе, допустим, не хватает какой-то страницы, но ты не можешь делать релиз фронта полноценный, и тебе нужно какую-то страницу добавить или какой-то новый флоу. Вот ты можешь открыть VIW, которое представляет собой просто браузер, который открывается на
Speaker A
определённом как бы стенде. Угу. И туда засунуть любой контент. Это типа, вот эта функция, да? Веб внутри мобильного веба, а внутри мобильного. А приложение?
Speaker A
Угу. И этим занимается тоже веб-команда. Они помогают интегрировать вот этот кусочек, да? А, нужен просто deплинк, а, готовая страница и просто переходишь туда. Всё.
Speaker A
Вот в браузере можно делать всё, что угодно. Да, разработчик веб может Угу. контент сделать нативный, например.
Speaker A
Или оттуда можно открыть приложение партнёра даже. Угу. Так, а скажи, пожалуйста, а есть ли у тебя мм опыт чтения кода и понимания принципов и процесса разработки?
Speaker A
Ну, очень такое отдалённое, очень. То есть, если я знаю контекст, знаю, например, язык, я могу какие-то там символы просто погуглить, например, там доллар - это переменная, если она там стоит перед каком каким-то значением. То есть, если нужно, я разберусь на такого,
Speaker A
чтобы я м сходу посмотрела и поняла. Ну, ну вот, вот могу просто рассказать, если будет такой вопрос, что я работала с протобафайлом. По сути, это такой Java файл, ээ, где расписаны как-то процедуры. Вот у них есть название. В принципе, даже по названию
Speaker A
процедур можно относительно понять, о чём там речь. Вот мапинг с базой данных. То есть там вот эти мм параметры, они как раз называются так же, как в базе данных, например. Ну, практически там можно мапинг сделать, но в любом случае
Speaker A
они похожи. Угу. А в чём вообще интересного вопроса? В чём разница в разработке Ri и а JPC?
Speaker A
Ну, если прям совсем в общем, то R работает с ресурсами, а GRPC с э процедурами, с функциями. То есть, по сути, мы на удалённый сервер отправляем команды, ну, не команды, вот эти процедуры программируем, как если бы мы их писали
Speaker A
для своего компьютера, для своей какой-то физической машины. Угу. [откашливается] Формат данных. Формат данных отличается, конечно, да, в ресте, как правило, наиболее распространённый формат, а вот для JRPC характерен, ну, допустимо только использование протобафайла. То есть нужно тот же JSON, который мы получаем с
Speaker A
соседнего сервера, а, сервиса сериализовать и преобразовать в протобаffй. Только таким образом, э, сервис на JRPC его примет.
Speaker A
Угу. А, и он компактный, и, соответственно, он позволяет быстрее работать, чем R. И, кстати, на нём, что самое интересное, на нём можно реализовать функционал граф QL. То есть в расте мы должны все обязательные параметры запрашивать, а с помощью вот
Speaker A
функции Field Mask мы можем прямо отдельные только точечные э параметры запросить, и у нас таким образом трафик экономится.
Speaker A
Это очень удобный. сервис. А с точки зрения вот одна одного из таких главных принципов роста, разграничение клиента и сервера. Вот у ко у у кого лучше с этим в Росте или м ну в расте, да, клиент отправляет на сервер
Speaker A
запрос, а вот в GRPC - это мультипротокольность и как это полнодуплексное взаимодействие. То есть, э, запросы могут идти от сервера к клиенту, от клиента сервер в сервер. Вот здесь нужно правильно действительно прописывать, э, корректно провафайл, чтобы Угу.
Speaker A
всё работало корректно. Это требует, конечно, большей квалификации, чем просто написать порест интеграцию и методы.
Speaker A
Очень неразвёрнутый ответ. Ну и типа плюс, если ты хочешь поменять а какое-то звено в цепи клиента сервера, ты типа без проблем, а в JPC так не получится, потому что тебе протофайл нужно будет всё равно прописывать с двух сторон. Да
Speaker A
вот, а с точки зрения проектирования, а сервисов и решение архитектурных задач, вот тоже, допустим, сравним JRPC и R.
Speaker A
Вот в каких случаях лучше сработает JRPC, в каких случаях, при каком взаимодействии? Вообще нам нужно спроектировать какую-то систему, и она должна обладать какими-то характеристиками.
Speaker A
Вот допустим определённая производительность, объём данных. Мы мы знаем, да, что у нас есть такие нефункциональные требования. Вот в каких случаях лучше подойдёт, а для каких систем JPC, а для каких?
Speaker A
Угу. Ну, вероятно, для систем с открытым кодом лучше будет ст. Если мы хотим сделать, например, коммерческую версию AP то конечно сторонним разработчикам будет сложнее разобраться в JRPC, чем в Росте. То есть просто более читаем, более понятен и популярен.
Speaker A
А есть и даже другим командам, я бы сказала. Вот, кста, мы тоже с этим столкнулись, чтобы появилось очень много созвонов, потому что люди не знают эту технологию, и нужно каждой команде было объяснять, как же с этим быть. И причём ушли
Speaker A
разработчики, которые GRPC прописывали. Всё там, я смотрю, откат каких технологий. Я тоже ушла. [смех] Вот. И в итоге от каких-то от какого-то функционала отказались, потому что просто не разобрались, как с ним работать. Достаточно высокая квалификация требуется. Да, если много
Speaker A
команд и активное межсервисное взаимодействие, то и не очень большие нагрузки, то проще использовать рест эффективнее. Если у нас высоконагруженный сервис и мы сталкиваемся с большими проблемами производительности. Только тогда мы применяем GRPC.
Speaker A
О'кей, всё, согласна. Или, наверное, ещё большие объёмы данных тоже когда идут. А, да. Угу. Кстати, надо вот в клиентсервер ещё почитать поподробнее, как там GRPC это организовано. Прямо хороший вопрос.
Speaker A
То есть они они, получается, прописывают протофайл, и там они и действия клиента, и действия сервера, всё в одном файле у них.
Speaker A
Да. И если менять, то целиком новый файл подгружать видимо. Да. Угу. А, хорошо. Опять же, раз мы коснулись такой классной темы, можешь рассказать пример какой-то интересной фичи, которую ты разрабатывал, вот которая тебе прямо сильно запомнилась или нравилась?
Speaker A
Угу. На JRPC, может быть, да? Вот как раз GRPC, да, Катя, как раз хотела рассказать. А наш сервис был по работал по Росту, но Payment сервис из-за того, что нагрузки возросли, как раз пришлось перевести на GRPC. А так
Speaker A
как мы брали информацию с этого сервиса по по платежам, например, длительностью не больше 3 месяцев, как давностью не больше 3 месяцев, э свежие платежи мы брали с пеймента, поэтому нам нужно было прописать интеграцию по GRPC.
Speaker A
И это было действительно таким интересным опытом. Во-первых, э мы, ну, мы плотно работали с разработчиками, так как для всех, для нас это была новая технология. И впервые вот в отличие от обычного App First, у нас был в этом случае сначала код. И я
Speaker A
поняла, насколько это неэффективно, что всё-таки даже если новая технология, э необходимо сначала аналитику вникнуть в суть и прописать документацию. и потом только уже давать разработчикам даже пусть немножко сырую версию, но тем не менее, чтобы они писали по документации,
Speaker A
потому что получилось так, что пришлось и документацию менять ээ несколько раз, и с разработчиками общаться, чтобы они поменяли немножко реализацию чуть-чуть в другую сторону. [фыркает] Угу. Ну, без этого никуда.
Speaker A
Понятно, [откашливается] прикольно, мне понравилось. А-а, а скажи, пожалуйста, вот, а как строилось твоё взаимодействие с архитектором и какие, архитектурные артефакты тебе приходилось получать или, может быть, создавать сумой?
Speaker A
Угу. С архитектором я напрямую не так часто общалась. У нас был Тимлид, ну, скажем так, ээ не Тимлид, даже скорее, а продакт oур, который общался с Тимдом, и он нас приглашал.
Speaker A
Наверное, звучит, кстати, не очень правдоподобно. У нас должен быть тимлид, который должен общаться. Но у нас два два аналитика, да, хорошо. Тогда получается, что мы напрямую с ним общались, потому что один Тимлит, а другой, короче, ну такой команда
Speaker A
маловато. Тимлит при каком количестве аналитиков кстати появляется? Не меньше трёх, наверное, да? Обычно у нас один тех много-много команд, то есть на пять команд. А которых может быть подва?
Speaker A
Логично, может быть один тех техлит. А тимлид - это про психологию скорее. Да. Ага.
Speaker A
Да. Скорее, скорее в банке это будет техлит. Всё-таки техлит. Хорошо. Да. Ну, э, мы общались с архитектором примерно раз в 3 месяца, когда появлялась необходимость, когда вот аккумулировались новые, а, потребности в новом функционале, мм, и тех, и мы аналитики с со смежных команд,
Speaker A
получается, по отчётам, по аккаунту, несколько команд с payment сервиса. Мы обсуждали план на следующие 3 месяца.
Speaker A
И также при необходимости, если не удавалось на уровне тех ледов решить какую-то техническую задачу или был был вопрос по архитектуре, то тогда обращались к архитектору, но это было довольно редко.
Speaker A
А от него мы получали документацию, архитектурное решение, которое нам нужно было обновлять, поддерживать, дополнять своими данными. То есть получается, у нас вот один, например, был кластер, у нас, ну, он до сих пор есть кластер, и несколько команд дополняли по своему
Speaker A
функционалу. Ээ вот это документ по архитектурному решению. От него также мы получали диаграмму компонентов и развёртывание в UML.
Speaker A
Угу. А доработку ердиаграмм мы уже самостоятельно делали на основе не какая-то необходимость, если возникала, потому что мы же прописывали методы, документацию такую более детальную, поэтому больше в этом ориентировались, чем архитектор.
Speaker A
Угу. На местах, так скажем. О'кей. А согласовывала ли ты архитектурный документ, например, ту же диаграмму компонент?
Speaker A
А в смысле я готовила ли я её и согласовывала? Нет, если готовила архитектор, приходилось ли согласовывать и вообще какой был процесс согласования архитектурных артефактов?
Speaker A
Ну, здесь, на самом деле, было взаимодействие на уровне тех ледов, но мне бы очень хотелось вот как раз в новой команде у вас, а, быть ближе к именно к разработке архитектуры и уже ближе к принятию решений, потому что а я
Speaker A
получала эти документы, ну, если не говорить там каких-то деталей вот в этом архитектурном документе, по сути, в режиме чтения, то есть я их получала э уже в готовом виде. По крайне мере диаграмма уж точно диаграмма компонентов и какие-то, может
Speaker A
быть, детали, вот я говорю, дописывала в документации, но всё уже само решение было уже готово.
Speaker A
Да, оно готово. Но а есть ещё такие вещи, как служба информационной безопасности, которые должны согласовывать всё. Ну, должно быть как хотя бы парочку проволов от бизнеса инициа например от информационной безопасности. А у нас, например, отправляется аналитику, который участвует, ну, будет отвечать за
Speaker A
реализацию этой интеграции. Ну, в общем-то, и вот примерно такой флоу. То есть, она централизованную систему вводится заявка и отправляется на согласование всем, всесм всем.
Speaker A
Ещё раз. То есть архитектор готовит решение, он согласовывает с ИБ, дальше с бизнесом. Да, он сам ничего не согласовывает. Он заводит заявку и автоматически она падает всем на согласование, всем участникам, вот, которые должны согласовать всем отделом.
Speaker A
И системные аналитики уже пушат этот процесс. Нет, они не пушат этот процесс. Тот, кто инициирует, тот пушит сам. И аналитик может согласовывать, потому что архитектор тоже не может.
Speaker A
А, понятно. Понятно. В своём уровне какой-то можете нарисовать. Вот тут вот будет такая кавка. Угу.
Speaker A
Дальше уже там не его кластер или он там не уверен, как сейчас реализована эта фича. И в таком случае как бы аналитик уже рисовыват сам как.
Speaker A
А вот это правдоподобная история, что вот до 3х месяцев платёж он живёт на Payмент-сервисе в базе данных, а потом он, а, перекачёвывает в ABS. И чтобы, например, нам взять платёж, который старше этого периода, нам нужно через кавку взаимодействовать с обс и получать
Speaker A
уже в асинхронном режиме какую-то более такую старую информацию. И тут единственное может быть всё, что угодно, но через кавку зачем вам обращаться? Выбрать.
Speaker A
А как? Ну это большая система, нагруженная, к ней много кто обращается. Шийные сервисы либо MQ. Ну то есть уs есть своя очередь. Либо ши сервисы, которые на Ростере ABS она связана с шиной с вот с этими сервисами. А то есть то есть мне надо
Speaker A
знать про шину? Да, плохие новости. Они могут быть на сопе, они могут быть на Росте, но, как правило, оттуда можно получить информацию.
Speaker A
Угу. Уже готовы реализованы шинные сервисы. И в редких случаях, да, вот когда уже прямо большое количество запросов, может быть своя очередь, например, в банке у абсолюж.
Speaker A
Ну, пусть будет шире. Карки скорее будут вот по углам в маленьких каких-то более мелких вещах, а там будет что такое более глобальное, типа шины.
Speaker A
Всё понятно. Хорошо. Ладно. Мм. Так, хорошо. А раз мы уже коснулись темы техледа, расскажи, были ли у тебя цели на квартал, какие? И, мм, как помогли ли тебе они развиваться?
Speaker A
Угу. Ну вот, получается, прошло полных полгода а были цели м а ну вот как раз был процесс перехода на GRPC, это, в общем-то, было центральным такой точкой развития. И также необходимо было улучшить коммуникацию с командой, с командами Payment сервиса.
Speaker A
То есть был рассинхрон небольшой в обмене информации. Он был некритичный, но довольно неудобный. То есть либо это длительные созвоны, либо это какие-то такие переписки, которые заканчиваются ничем.
Speaker A
А, ну в итоге, конечно, мы эскалировали это и в итоге решали вопросы, но хотелось бы без эскалации. И поэтому я предложила отдельно созваниваться с командами, то есть их было несколько на пейменте, а отдельно с ними созваниваться и м составлять после
Speaker A
встреч, то есть ограничивать время встречи, допустим, не больше 30 минут и составлять после встречи такой адженду, ну, точнее, не адженду, а такой итог, к чему мы пришли в письменном виде. они согласовывают, и мы, ну, в определённой последовательности шли там
Speaker A
к следующей команде уже с согласованным выводом от первой команды. То есть, скажем, [фыркает] перевод, э, встреч от устного общения к, а, прописыванию всё вот в документе, через электронную почту. Ну, немножко стало лучше. Не знаю, насколько хватит сотрудников следовать такому плану, но то, что
Speaker A
фиксируется в документе, ну, в таком просто свободной форме, оно действительно лучше, э, структурирует работу, чем просто да договорились, а потом оказалось, что неправильно друг друга поняли.
Speaker A
И это было техas на коммуникацию. Это было это так срисофт, да, тех, ну, JRPC, но мы просто про него уже проговорили. Может, что-то ещё сказать, да? А была ли такая практика, что в техдолги записывали в техцелях?
Speaker A
Ну да, это было до Нового года. Нужно было закрыть ээ там ряд задач. Например, м, как пример могу привести, аэ прописывание методов взаимодействия с, мм, с аккаунтом, с персональными данными. Нужно было согласовать с а информационной безопасностью, э, с
Speaker A
безопасниками. а-а какую информацию, какой информации может иметь доступ наш сервис, потому что всё-таки это хранение персональных данных. И вот здесь это было не проработано, и мы, получается, получали данные в обезличенном виде, и у нас система дольше их обрабатывала.
Speaker A
Вот. Ну, то есть долг у вас такой образовался. О'кей, понятно. А развиваешь ли ты как-то самостоятельно свои технические с скилы?
Speaker A
Да, в последнее время стало интересно глубже погрузиться в тему баз данных. Ну вот, попыталась я скачать несколько книжек, но вот, честно говоря, м больше нравится видеоформат с где можно в читать. То есть это похоже на книгу, только более динамично, а, и
Speaker A
глаза немножко отдыхают. И обязательно я ещё стараюсь, по крайней мере, найти достаточно глубокий материал, например, когда читает вузовский преподаватель.
Speaker A
Прямо это золотые материалы можно прямо вот плейлист найти по теории базданных самого самых азов. Вроде всё знаешь, но какие-то детали там проговариваются. И вот я свободное от работы время по вечерам иногда включаю и слушаю и стараюсь, ну, изучать в том
Speaker A
числе на основе вот эшего м ну нашего сервиса. Угу. Часто вообще тебе приходилось на последнем месте работать делать SQL запросы и куда?
Speaker A
А в основном это были селекты в нашу локальную базу данных, а для того, чтобы посмотреть, ну, правильно сделать маппинг при описании при описании метода, то есть как как выглядит информация в базе данных, как её можно структурировать, каким там строчкам, грубо говоря, к
Speaker A
каким таблицам можно обратиться, чтобы получить ту или иную информацию. То есть, а, больше в качестве такого справочного материала. Но интересно было бы, конечно, м [фыркает] углубиться в аналитику баз данных, но насколько это вот релевантно проекту?
Speaker A
Угу. А запросы в тестовый модуль ABS приходилось делать? Мм, ну да, в общем, мм, здесь мне конкретно у меня не было доступа, но я видела, как делают это мой тех.
Speaker A
[фыркает] А как он подключался туда? Ну там, насколько я понимаю, определённый есть учётка определённая, в которую заходишь, у тебя должен быть доступ к ней, и он выгружал какие-то необходимые данные.
Speaker A
Угу. Ну, то есть был какой-то свой банковский софт, чтобы подключиться. И в принципе можно через дебир подключиться, наверное. Бивер. А вот, кстати, дебивер - это не для не для джинов такоя история такая типа тренировочная. Нет, это прямо реально используется. Конструкция
Speaker A
есть подключение кS через дебиль. Она реально используется. И на в удалённом рабочем столе он типа по умолчанию стоит. Поэтому это реальный инструмент.
Speaker A
Вот так же, как Кавкатуol, например, он же Offset Explorer. Кавка Tool - это для настройки Кавки.
Speaker A
Для того, чтобы посмотреть сообщение Кавке. А, о, здорово. Угу. А ты используешь это на своём проекте?
Speaker A
Да, я использовала. Я мы реализовывали триггерный виджет, там было перекладывание, там даже был MQ Bridge, мы получали из одной кавки, перекладывали в свою кавку мобайла и потом передавали опишку, а видтменеджмент, которая формирует весь главный экран. То есть это типа было
Speaker A
целевое решение. Вот всплывашка такая. Я я подключалась к кавке интеграционной общебанковской, которую заводила Снежная команда. А в принципе по функционал по перекладыванию нашей кавки, там уже разработчик наш сам знал. Ему особо там не надо было никакой помощи, инструкции, он там сам заводил
Speaker A
эти топики. Вот, в принципе, там проблем не было. Была проблема только всех всем рассказать, как подключиться к интеграционной, потому что нас не знал никто. Ни тестировщик, который суперопытный. 5 лет. Вот. Ну такой.
Speaker A
Ну да. Обычно, если никто не знает, как, то аналитик должен объяснить всем, как это сделать.
Speaker A
Эк. То есть он не должен там внутри пальчиками что-то набирать, да, ручками, а как зайти креды дать, показать, как подключиться по этим кредам, потому что дать креды и подключиться по кредам - это разныя вещь.
Speaker A
Вот. Э, в начале, в начале сложно, потому что там, ну, просто тупо очень много всего и не всё нешься сначала.
Speaker A
Ну, документации хватает. Как вот ты вот вообще понимала, что к чему? Её хватает, но она вся почти устаревшая и почти нету такой инструкции, что ты просто пойдёшь без по алгоритму и у тебя без проблем всё получится. Это почти
Speaker A
нереально. Жесть как да. Есть какие-то неучтённые моменты. менторгу. И если повезёт с ментором, то он [откашливается] прямо всё объяснит и расскажет. Но мне не повезло.
Speaker A
Блин, он был твой учитель, да? Как опалась, да? Но как бы 3 месяца тебе даются техски на обучение. То есть первые 3 месяца никакие таски не даются. Твои техски - это выполнять планы бординга, изучать документацию. как вот туда, как
Speaker A
[откашливается] там. Ну, причём, да, ментор помогает и доступы базовые какие-то завести, вот, которых тоже очень много. Пока только поймёшь, куда подключаться для того, чтобы просто ежедневную рутину делать, это, конечно, рдом. Ну, наверное, во всех банках так нормально, даже приходят и как бы ничего не знают.
Speaker A
Это норм. Угу. Ну, поэтому и даётся 3 месяца. Ну, 3 месяца для погружения это прямо много, да? Значит, там много вот этих.
Speaker A
И это ещё не означает, что ты погрузишься. Погрузишься ты где-то 8-9. Вот так нормально [смех] начнёшь уже как-то расслабленно, да, всё это делать. Угу.
Speaker A
Да, прикольно. Ну, посмотрим. Они, наверное, мне говорят, что они меньше стали практических задачек задавать на резюме, на собеседовании, да, больше.
Speaker A
Так, что ты сделаешь в этой ситуации? А как у вас вот это было? Да, как вот они сейчас у нас новый флоу готовится и там всё нормально. Ну, ты ещё по-старому пойдёшь, скорее всего, на два этапа да.
Speaker A
Но вот что для меня было самое сложное, потому что я в пилоте участвовала в рамках текстатаски, я была интервьером, у меня был доступ ко всем вопросам.
Speaker A
Кстати, у меня были самые сложные вопросы по безопасности. То есть я в лабе с таким вообще не сталкивалась.
Speaker A
прозличивание данных, но там вопросы про этолан влам. Ну, типа, вообще, что это такое? Вот это да.
Speaker A
Ну, это да, по безопасности самые стрёмные. И то есть если ты не отвечаешь на них, то не проходишь.
Speaker A
Да, это очень важно. Это как бы отдельный раздел. А, типа, какие виды хакерских атак вы знаете? Сейчас же вот не знаю, слышала ты, нет. Альфабанже додосит уже третью неделю.
Speaker A
Ого. Нет, не слышала. Всё отваливается. Сегодня опять полдня не работали. Капец. Вот такие дела. Ладно, я тебе ещё один вопрос хотела задать. Я тебя там де уже не буду а мучить, но один всё-таки хотичуть ответ. Какой у вас был гитфлоу?
Speaker A
Ну блин, зна зачем? [смех] Никакого. Ну как, ну флоу, ну это же для разработчиков. Вот я не очень понимаю. Я тоже слышала, что спрашивают про Gitlab, там GitHub, Git Flow. Зачем? Я как раз твою твою запись смотрела с каким-то
Speaker A
мальчиком. Да. Ты [смех] говорила, типа, ну заче, ну вот вот как правильно ответить? У нас не было совсем, я могу сказать, что у нас не было такого. Аналитики этим в нашем банке не занимались, но я готова на всё.
Speaker A
Хорошо. Ты вообще знаешь, что такое гит и что такое ветка или флоу? Ну да, а это флоу как раз и есть. Но вообще гит - это ну некое хранилище кода. Оно может быть локальным, может быть удалённым. То есть
Speaker A
сначала разработчик делает свою ветку кода на локальном на локальной части гита и потом мёрз её. Либо как это? Феч называется, да? Ээ, либо мёржит, если он встраивает свою ветку.
Speaker A
Феч - это другоя феч. Это просто обновление твоего проекта. А, rebй. Вот вот мёршй то же самое. Это обновление твоего проекта. Ты, например, себе скачала в intelligence идее и сразу там у тебя ж оно, ты, например, загрузила опишку вчера, а сегодня кто-то уже
Speaker A
смёрзл изменения. И твоя версия, которая на локальном твоём компе, она уже неактуальная. Тебе нужно ребейзнуться или сделать фэтч. Это одно и по сути одно и то же. И у тебя просто твоя версия на локальном компена обновиться.
Speaker A
А мёрш - это уже совсем другое. Это встраивание, интеграция, решение вот в общее, правильно? В общий поток.
Speaker A
Ну то есть я могу просто взять комита, залить мастера и сразу смёржить, да? Или как?
Speaker A
Нет. По-моему, там разделение идёт. То есть разработчик, например, делает код, а комитит его кто-то другой.
Speaker A
А он вот, да, вот это надо почитать, да, прям прямо внимательнее. Так, хорошо. Какие виды сред вообще были на твоём проекте?
Speaker A
Так, так, так, так. Какие виды сред? Ну, наверное докер правильно? Нет, вот это вообще Ну да, здесь я пас, наверное.
Speaker A
Так, всё, я тебя так и поймала на последних секундах. [смех] А, ну ты наверняка слышала про среду тест или интеграционную, среду де?
Speaker A
Угу. А боевую среду про и ещё быть прилай. Ещё раз. Тест деф. Деф. Что дальше?
Speaker A
Боевая среда или прод? Прод. Угу. На котором ведётся разработка. И между интеграционной и тестовой продом ещё может быть какой-нибудь прилай.
Speaker A
А что это такое? Или предп. Ну, это что-то наподобие интеграционной среды, которая тестируется в приближённой к боевым условиям.
Speaker A
Угу. Но она на самом деле не везде есть. Нету предпрода. Угу. Вот. И похожая история, она на самом деле из тфлоу или с ветками.
Speaker A
Тоже есть ветки. ДП, тест, мастер, он же про, э- и, в принципе, а, а, и ветка фича, на которую можно вносить изменений. И если ты хочешь залить изменения код в код, ты можешь, например, на тесте залить, сделать комит
Speaker A
напрямую прямо в тестовую. И, соответственно, в тестовой среде данной обновенции твой тестировщик может сразу потестить на тесте. Ему не надо переходить даже на фич ветку разработчика, если вносится сразу на тест. Если вы вносится изменения на фичветку разработчика, то он должен
Speaker A
отмёржить от тестовой среды фичевет, создать её, а сделать там комит, то есть внести изменения. И после этого тестировании а тестировщик не увидит по обычной тестовой среде ничего, пока он не переключится на фичетку. Это можно сделать в эмуляторе. Это можно сделать
Speaker A
на тестовом стенде, то есть просто прописываешь там даже вл а название фичеветки и ты как бы на неё переходишь, можешь тестить.
Speaker A
А [откашливается] после того, как фичатка протечена, ты должна это только типа первый этап, вы только проверили на тесте, работает это или нет. Ты берёшь, идёшь в мастер, потому что боевая среда зачастую от тестовая очень сильно отличается. И там, а, будет
Speaker A
другая нумерация полей, контейнер иногда. Ну, то есть, ну, это же, знаешь, так всегда. Тест не соответствует проду, потому что там за ним так никто не следит.
Speaker A
А ты идёшь в мастер или разработчик, он опять создаёт вечеретку уже на мастер и делает комит, который впоследствии уже пойдёт в прод.
Speaker A
И на этот коми создаётся пиар. То есть ты открываешь запрос намёрж. Угу. А ты типа вот этот пиар. [смех] Пиар - это очень важная штука. И на пиар а как правило есть правила определённых согласований. Вот если у тебя спросят
Speaker A
там: "А как происходили согласования?" Можно сказать, что через пиар. У нас, например, вот медловая дока, она тоже через пиары согласовывается.
Speaker A
То есть ты открыл и тебе должно прилететь, тебе там автоматически подобрались ревьюеры в количестве там 40ка, например, или 30 штук. И пока ты не получил там, не знаю, сколько заложено три-пять лайков, ты не можешь делать мёрш.
Speaker A
После того, как ты лайки собрал, ты делаешь мёрш, и твоя твой как бы комит и пиар уже готовы к раскатке в боевую среду. Только после этого можно вот ножить.
Speaker A
Ещё после мёжа нужно ещё раскатить. Ну, как бы, как правило, например, дока она сразу после мёрзжи заливается. А кот, конечно, надо катить, создавать задачу на раскатку, в неё подкреплять собранную собранную ноду, в общем, опишки, которую ты катишь, прикладывать пиар на конфиги,
Speaker A
если они есть. Вот. И всё вместе катить. Аналитик, что может делать? Он может, например, скорить поставку, потому что разработчик же может быть самодуром и типа теоретически раскатить что-то сам.
Speaker A
А вот с помощью скоринга аналитиком поставки определяется, что а действительно там нужно ли нагрузочное тестирование, сколько систем затрагивается, в чём суть вообще этой задачи, в чём суть изменения и так далее. То есть это всё скорит аналитик, и он за это отвечает.
Speaker A
Если он пропустил, то косяк будет ответственность будет поделена на двоих. Да, да, это всё записано, кто кто проскорил, какие значения писал и так далее.
Speaker A
Вот. А это не C сиди случайно тема? Вот это в какую тему? Это связано с CD, да? Просто нет такого вот как в старину, что типа всем занимается DevOBS. Нет, это всё распределено. того сможет быть один и только контроль процесс.
Speaker A
Угу. Да, но по сути это непрерывная интеграция, непрерывная доставка. Таким образом и достигается, потому что ты собираешь маленькие, а какие-то изменения и тратишь постепенно, а не ждёшь какого-то огромного большого релиза, не копишь это.
Speaker A
Вот. Плюс аналитик должен проверять версию, которая сейчас на проде, потому что другие команды могли раскатить твою опишку, пока ты готовил поставку. И если вы вдвоём закатитесь, всё.
Speaker A
То есть за другими тоже проверять, но там должна фигурировать твоя фамилия, чтобы ты поняла, что это к тебе как-то относится. Да нет, на есть система, которая м которая говорит, какая версия сейчас на Проде. И ты проверяешь, а, ну, например, если это
Speaker A
конфиге, то версия у тебя не меняется, но всё равно сборка должна быть другая. Но ты можешь сказать, что да, вот на проде сейчас девяносто вторая, так как мы катим только конфигетим тоже в девяносто вторую с конфигами новыми. А
Speaker A
если ты катишь код, тогда ты смотришь: "Ага, у меня девяносто вторая, она продейно вторая. Значит, всё, нам надо пересобирать поставку и делать девяносто третью, потому что кто-то уже что-то влил. И мы должны включить это в свою поставку, потому что если мы вольём в
Speaker A
свою такую же, мы, ну, как бы то, что сделала другая команда, нивелируем. Понятно? Ну, то есть версионность вот эту тоже нужно проверять. Угу.
Speaker A
Отлично. А вот это в какую тему? То есть, чтобы мне погрузиться, я обычно там либо видео какое-то включаю, либо какие-то статьи уже конкретно, где разбирается. Это А как можно сформулировать, чтобы про это ещё что-то почитать?
Speaker A
А пока я не очень пони. Почитай для начала просто прогит. Ну у тебя ж прямо суперлого времени не будет.
Speaker A
Как это всё работает? Почитай про битбакет. А про а как собирается поставка вот эти всякие ноды. Ну, честно говоря, я я в это особо не вникаю, да, всё равно за разработчиком.
Speaker A
Тебе нужно просто типа как бы базовые вещи понимать. А процес сам процесс, да. Вот.
Speaker A
Хорошо. А как я рассказала? достаточно. Может, менты есть вот для этого? Как какие там?
Speaker A
Мы же одинаковые инструменты все используем. Не знаю, там, а, ну, ну вот ребята говорили мёржить там, вот это всё комбитить, это, конечно, у разработчиков есть гит, но тебе-то в принципе зачем? Просто мм у нас же дока хранится вместе с кодом, мы
Speaker A
её в гит заливаем. А тебе зачем это? Ну, тебе не дадут, наверное, доступ. Ну да.
Speaker A
Понятно. То есть это самой всё само. А что такое? А что такое? Так, давай ещё, ну, 5 минуток дели, я тебя отпущу. А знаешь ты, что такое конфигурационный файл?
Speaker A
М, да. Э, он прописывает, мм ну скажем конфигурацию работы, допустим, веб-приложения или какой-то опишки, например. А, [фыркает] ну, например, XSD, вот XML схемы или Jonхемы могут быть частью вот такого такой информации.
Speaker A
Это, как правило, в формате яблоку, да, какие-то переменные данные подставляют. Ну, например, картинка. Вот ты же не будешь грузить новый код, когда тебе нужно всего лишь поменять картинку или какую-то циферку или тексто. Вот поэтому это всё выносится в конфигурационный
Speaker A
файл. Иногда туда и криды выносятся, но это уже будет скорее файл я как а с а окончанием том, а обычный типа точка yam, там будут всякие переменные. Вот. А тебе нужно а текстовки, картинки, какие-то иконки, ссылки, то есть всю эту
Speaker A
инфу, которую можно легко заменить, и она часто меняется, выносится в конфиге. Это некие такие буферы, где происходит обновление данных. Допустим, в том же, да, это просто файл в формате Yamл. Вот как есть файл в формате, так есть файл в
Speaker A
формате Я. Вот. И конфиги - это очень частая история. То есть часто нужно просто поменять конфиги.
Speaker A
Приехали новые картинки. У нас ребрендинг, у нас текст поменялся. Давайте допишем. Это всё задачи с конфигами. Угу. Угу. Ясно. Вот это я не знала максимально просто. Я тоже этого не знала, поэтому я тебе расскала и така что такое горцо. Ну ладно, я так
Speaker A
не сказала, конечно. Подумала, да, но да, подумала. А и были ли у вас на проектенкитого?
Speaker A
Вообще нет. Что-то такое непонятное. Ещё раз почитай. Deeplink - это ссылка, которая ведёт на либо какую-то другую страницу, либо на новую фич. Ну, как правило, на какую-то просто страницу. Экран открывается, новый экран.
Speaker A
Вот. А, как правило, когда тебе нужно реализовать какую-то новую фичу, ты, э, высылая, ну, какие-то параметры, например, твоего виджета, уже он содержит. То есть при нажатии на кнопку ты не запрашиваешь никакой инфы, она приходит у тебя уже в период
Speaker A
перезагрузки. То есть есть сразу предзагружен плин, куда ты переходишь дальше. В диплинках на самом деле ничего сложного нет. Нужно просто понимать, что это ссылка, переход на другой экран. И, как правило, ведётся общий реестр, куда мм все существующие диплинки с экранами прописываются.
Speaker A
Вот причём требование, что плинк веба и диплинк мобилки должен быть одинаковым. Угу. С точки зрения безопасности, наверное, да? Это же уязвимость потенциальная. Нет, просто, наверное, какая-то вот унификация, чтобы понимали, о чём идёт речь. Типа вот был общий реестр, и мы
Speaker A
понимали, какие экраны у нас уже есть, чтобы мы не не изобретали, наверное, то же самое по несколько раз, да? А, и фирток - это более сложная, ну, она как бы не сложная тоже, но сначала сложно понять, когда ты с этим не
Speaker A
сталкивался. А есть фечитоглы на фронтине, есть фечитоглы на медле. А фичитоглами можно закрыть какую-то новую функциональность или её часть.
Speaker A
Аа обычно приводится классический пример фичетоглов, что вот ты выбираешь какую-то, а, ну, грубо говоря, вот у тебя есть дети или нет детей, а снизу у тебя формочка имена твоих детей, да, и вотшь нет, то форма ниже пропадает. Вот это
Speaker A
пример реализации читогла. А, прикольно. Такая динамическая реакция [откашливается] на действия. Ты закрываешь и как бы что-то пропадает.
Speaker A
Но на практике это больше связано с поэтапной раскаткой новой фичи по фасттреку. То есть ты, когда выкатите новую фичу, не открываешь сразу функционал на 20 млн. Это запрещено.
Speaker A
Ты должна закрыть его фичтаглом и по умолчанию твоя фича недоступна до всех. То есть вы прописываете с разработчиком обращения к фитоглу, ты его заводишь и придумаешь, что он называется так-то, и по умолчанию он для всех закрыт. Дальше у аналитика идёт поэтапная работка
Speaker A
считало, и он добавляет туда курсы пользователей, то есть список айдишников, которым он занимается. Есть вот эта поэтапная раскатка. Сначала ты открываешь на рабочую группу для того, чтобы вы на бою могли своей команды посмотреть, а работает ли, потом открываешь набаг, чтобы открыть тоже
Speaker A
какие-то ошибки. И как бы это всё открывается с помощью фичигла, то есть и в какой-то момент её можно всегда закрыть.
Speaker A
То есть, если, например, что-то пошло не так, вы просто удаляете все укусы и, ну, айдишники из фичита, а, закрываете его, причём вам не нужно ни менять код, ничего. Это просто делается одной заявкой, и у вас всё закрыло. Вот уже
Speaker A
буквально через час. Вот. Э-э, то есть это такое больше, да, для безопасности каких-то новых фичей, для поэтапных и для поэтапной раскатки, чтобы посмотреть, что действительно там, ну, там, если это, например, на банк какая-то косячная фича попадёт и сотрудники найдут, это же не так
Speaker A
критично, как реальные клиенты. А вот а значит, фичок - это как бы скорее такой функционал, который закрывает. Плюс фичтокл может ещё использоваться, знаешь как?
Speaker A
А фильтро там можно какие-то прописывать фильтры, старается от этого уйти и говорить: "Прописывайте фильтры по плу". Например, пользователей больше в коде. Но иногда это тоже не очень рационально.
Speaker A
А то есть иногда проще вчитогре по умолчанию закрыть там, например, премиальные а фичилимов. Просто прописать, что вот пакет 1 2 3 - это у нас для них только будет открыта эта печа. И то же самое по версиям, потому что есть разные элементы фронта,
Speaker A
то есть в Альфабанке довольно хорошая дизайнсистема, она типа часто обновляется, но новый функционал он доступен не со всех версий. И часто бывает такая проблема, что, а, да, мы хотим новый экран, например, новый профиль, но не все современные элементы,
Speaker A
они будут доступны для старых версий. И таким образом ты должна придумать усечённый функционал для тех пользаков, у которых старые версии. Ты тоже не можешь их бросить, закрыть это фичиглом и прописать другой фильтр для новых версий, которых уже будет современные
Speaker A
картинки, современные там SDUI шаблоны, и для них то же самое в читоглом их разводишь, прописывая вот эти версии.
Speaker A
Такие дела. Ладно, я, короче, запись выключаю. можешь меня что-то
Topics:системный аналитиксобеседованиеIT карьерабанкиgRPCброкерская деятельностьблокчейнмок-интервьютребованияфинтех
