Data Platform. Владимир Бородин

Здравствуйте, уважаемые зрители, друзья, коллеги. Меня зовут Антон Черновцев, я девелопер-адвокат Яндекс Клауд и рад приветствовать вас здесь, в нашем новом шоу «Как мы делаем Яндекс Клауд». И сегодня здесь... В этом первом выпуске у меня мой коллега Владимир Бродин, руководитель платформы данных. Владимир, здравствуй. Привет. Всем привет. Слушай, мы задумали вот этот формат, чтобы рассказать некоторые внутренние части.

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

Что-то сделать такое. Почему нельзя взять что-то готовое, подходящее, и прямо сразу использовать? И вот, например, вот ProBlock, да? Они мне говорят, ну вот есть же OpenStack. Ну, возьмите... Используйте. И разверните по быстренькому облако. Что там писать-то? Да, есть такое распространенное мнение. Наверное, не только снаружи компании много, кто и внутри. Например, я был одним из тех, вот когда облако начиналось, кто говорил, не надо, короче, писать с нуля, давайте OpenStack допилим.

Это сколько лет было назад, получается? Это был 16-17 год, то есть 7-8 лет. То есть это тогда появились планы о том, что надо писать это всё дело? Да, да. Где-то в конце 2016 года было принято решение о том, что давайте запрыгивать в поезд публичного облака.

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

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

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

Есть, конечно. В смысле, мы не все велосипедим. Велосипедов в Яндексе правда много, типа больше, чем, наверное, в среднем по больнице. Но далеко не все мы пишем с нуля. Например, не знаю, например, виртуальная сеть облака, она построена на OpenContrail. нынче это называется Tanks and Fabric, они там переименовались. В общем, это готовый проект, который мы взяли и активно допиливаем, развиваем. Вот.

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

Это тоже, по сути, мы берем готовое и там некоторым образом красиво запаковываем. В общем, далеко не всегда мы велосипедем. Есть много историй, где берем готовое.

что-то с рынка, что-то там изнутри Яндекса были какие-то хорошо готовые технологии, которые мы в облако взяли. Я в этом смысле, кстати, мы приблизились вот к той теме, где ты... Глубоко в материале, скажем так, ты вообще во всем понимаешь внутри Яндекс.Клауд, но МДБ это твоя вотчина, как это в некотором смысле, потому что ты, во-первых, с одной стороны, руководитель платформы данных.

Вокруг там много баз данных, которым ты в некотором смысле приложил руку, где-то как разработчик, где-то как руководитель. А вот как происходит этот процесс адаптации? Вот взяли готовый проект. Ну, вот, например, open source, ты говорил про Postgres, но также, если мы откроем Яндекс.Клауд, мы там увидим в Data Platform, ну, просто там... Больше 10 движков, да. Да, и... Проектов вообще там порядка 20 из них, большинство из них open source. Ну, в некотором смысле.

Понятно, там все эти обвязки, они уже потом нами доделаны. Но как вообще происходит эта адаптация? Откуда корни растут, так сказать? Так, ну, грубо говоря, была какая-то команда, у которой была экспертиза в Пасгресе. Это, на самом деле, команда вышла из Яндекс.Почты, которая там перевозила почту Сорокла на Пасгрес. Вот, в частности, я оттуда. И сначала стали делать, еще до появления публичного облака, стали делать Postgres и The Service внутри компании.

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

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

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

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

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

И с этой точки зрения нельзя просто так взять какой-нибудь сервис, который есть внутри Яндекса, и типа, не знаю, там, Ctrl-C, Ctrl-V, задеплоить его в облако. Иногда хочется, ты думаешь, ну оно же здесь есть уже, давай берем сюда. Начинается. какие-то вещи. Тебе нужно, значит, проинтегрироваться с облачной ресурсной моделью. Организация Cloud Folder. Внутри у нас другая ресурсная модель.

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

использует. Ну и, в общем, там вот набор доделок, который нужно сделать для того, чтобы вот сервис, годный для внутренних пользователей, предоставить в облаке, он на самом деле немаленький. И чем дальше, тем длиннее он становится. Ну, потому что сейчас, например, не знаю, чтобы новый сервис появился, он обязательно должен быть там с Audit Trails проинтегрирован для... Для того, чтобы следить за событиями области безопасности. Да, для аудита безопасности всех сервисов «Омлака».

Чтобы логи не просто куда-то отгружались, а конкретный сервис отгружались. Да-да-да. Ну, в общем, количество интеграций, которые тебе нужно сделать, там, логи в логинг, графики в мониторинг, метрики, аудитные события в Audit Rails. там, шифрование через KMS или LogBox. Ну, это вот количество интеграции, оно растёт, и как-то запускать новый сервис, оно, ну... сложнее становится. И это в целом немалый объем работы, вот взять что-то готовое из внутренней инфры и предоставить в облаке.

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

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

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

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

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

Там было какое-то количество вещей, которое нас в этой open-source не устраивало, и мы понесли, значит, contribution в open-source upstream. Contribution большой, мы там добавили инкременты, шифрование, сжатие, ну, в общем, много классных фичей. принесли, и как-то у нас там диалог с мейнтейнерами не очень сложился. Мы, в конце концов, с ними созвонились. Тогда еще скайпом люди созванивались. Вот.

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

распределять там, какой кластер на какой бэкапный сервер бэкапить и так далее. И, ну, в общем, для нас были какие-то проблемы. И тут объектный сторож, который есть и работает. Который сам по себе распределенный, умеет ездить и сам так далее. Вот. Мы понесли туда, тоже попробовали небольшой contribution, бак маленький поправили, его приняли через 7 месяцев. Просто pull request висел 7 месяцев, мы периодически пинговали, и ничего не происходило. Ну и мы решили, что...

Ну, что-то как-то тяжело. Это тоже не тот open source, который мы хотим. А форкать мы не очень любим. Либо толкаем в AppStream, либо с форком жить такая история. И примерно в это время... Появился open-source проект Val-G. Это, собственно, взяли вот Val-I и переписали... Val-I на питоне написано. Взяли Val-I и переписали на Go. Вот появилось и название Val-G. И там энтузиасты из Цитуса, по-моему, написали.

И мы попробовали, нам понравилось, понесли туда contribution, их активно принимают, и в какой-то момент времени ребята из CITUS'а сказали, знаете, вы тут уже контрибьютите больше нас, давайте теперь вы будете мейнтейнерами. И вот теперь мы мейнтейнем... Да-да-да. И теперь мы мониторим этот проект. Я к чему? Возвращаясь к твоему вопросу. Довольно сложный путь адаптации из такого условного... Казалось бы, фича-то всем нужна. Казалось бы, бэкапы.

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

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

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

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

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

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

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

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

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

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

Но вот ты им там предлагаешь, вот, короче, есть NBS, у нас там есть диски, они там, не знаю, медленнее, чем мы бы хотели. И вот можно там закопаться, их оптимизировать или идти в какой-нибудь... в АЭМ, там, и миллионы РПС скелить, чтобы мы быстро отвечали и надежно работало. Ну, потому что банально, те же токены выдавать для... Да-да, ну там вот, типа, миллион РПС, порядок такой. Кстати, если график посмотреть, он такой по нагрузке растет. Он растет. Вот.

Это один класс задач. Ну вот, типа закопаться в какие-то вот детали low-level, такой перформанс-оптимизации.

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

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

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

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

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

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

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

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

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

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

начать с запросов 500 или latency вырастет, или какие-то другие проблемы у нас начались. Это банально. Мы просто медленнее будем выкатывать новые фичи. Да, да, и это тоже. Или, ну, в общем... Понятное дело, тех долг, он есть, мы его выплачиваем. Копитивы. Да, да, да. Его нельзя не платить.

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

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

Потому что вот разработчик сам использует свой сервис. Давай, мне кажется, мы должны про это поговорить. Давай, давай. Дукфудинг — это принцип, который был заложен. в Cloud еще Яном Лещинским, человеком, который Облако запускал первым SEO. И заложен вот прям с самого, я не знаю, с самого начала. У нас первый стенд облака, который вот был разлит.

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

Но мы тогда вот по наставлению Яна занимались тем, чтобы реализовать две вещи. Self-host и DogFood. Self-host это чтобы, типа, всё... все сервисы облака жили в облаке. Чтобы у меня снаружи ничего не находилось. Да-да-да. Это... Ну, и Дукфудинг, по сути, про то же самое. Мы сами используем свои сервисы, свое облако. Это, с одной стороны, создавало некоторое давление, там, не знаю, сервисы более высокого уровня. Например, MDB использовали виртуалки. эти диски и инфраструктуры там некоторым образом

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

откуда эти люди появляются в команде, потому что команда большая, и только у тебя 100 человек. Больше ста. Больше ста. Давай я не буду называть конкретные числа. Вот. А в плане, откуда появляются, как раз числа могу назвать. За последние полгода мы наняли 28 человек. Из них 10, это пришли ребята из... После стажировок. То есть мы взяли их на стажировку, они три месяца постажировались, потом мы взяли их в штат. Практически твой путь, потому что ты же тот же в Яндекс.

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

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

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

Опять же, я, например, работал там в почте, потом ротировался в Cloud. И так, ну, в общем... Популярная у нас практика, там, не знаю, ты уперся в потолок, вырос, или, не знаю, уже там что-то в коллективе тебе начало не нравиться, или еще какие-то вещи. Мотивация поменялась, опять же, хочу вот такое попробовать. Да-да-да, вот. Это популярно. Вот, короче, три стрима, откуда люди к нам приходят. Это мы их выращиваем из стажеров, мы нанимаем уже людей более опытных.

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

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

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

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