Пять историй разработчиков облака Яндекса: как помогать тысячам компаний управлять данными и любить челленджи
Рассказываем, кто и как разрабатывает продукт в облаке Яндекса, который за полгода принес 15% выручки и вырос по объему потребления клиентами на 390%. Про найм, инженерную культуру, opensource и челленджи.
Системы управления базами данных (СУБД), которые обеспечивают хранение и обработку данных, бизнес использует повсеместно — для построения прогнозов, проведения транзакций, сбора показателей, подключения рекомендательных систем и так далее.
Управляемые СУБД в облаке выбирают чаще всего по двум причинам: скорость развёртывания и расширения, и совокупная стоимость. Рассказываем, как устроена команда, которая разрабатывает Платформу данных в Yandex.Cloud.
Как устроена команда разработки
Рассказывает Владимир Бородин, руководитель Платформы данных в Yandex.Cloud
Компания-клиент может разместить СУБД на собственном оборудовании или же использовать управляемую базу данных в облачном провайдере — так называемые PaaS-решения (Platform as a Service), которые бизнес выбирает все чаще. У нас в Yandex.Cloud для этого создана Платформа данных — экосистема облачных сервисов для полного цикла работы с данными.
В руках нашей команды, которая ее развивает (сейчас это уже более 80 человек), и бэкенд, и фронтенд. Она существует даже дольше, чем само облако — с 2016 года, и предоставляет так называемую внутреннюю инсталляцию для разработчиков Яндекса, то есть работает не только для внешних, но и для внутренних клиентов — всех сервисов. Получается, что каждый разработчик в той или иной мере влияет на развитие продукта, которым пользуются и внутри компании, и в целом на рынке. В 2021 году по объему потребления клиентами Платформа данных выросла на 390% и стала лидером роста среди сервисов Yandex.Cloud. К тому же, управляемые базы данных Яндекс запустил раньше всех в России.
Еще о продукте и команде
Платформа данных состоит из трех основных частей: систем управления базами данных, сервиса Data Transfer для миграции и потоковой поставки изменений и сервиса DataLens для аналитики и визуализации. Data Transfer и DataLens — хорошие примеры новых и востребованных решений. Первое решает задачу миграции данных и change data capture (CDC), а второе предоставляет удобный способ анализа даже для тех, кто далек от мира данных.
Команда Data Platform создает в облаке управляемые сервисы вокруг популярных баз данных. Условно всех специалистов можно разделить на четыре подкоманды. Одна из них погружена в работу над так называемыми СУБД общего назначения — PostgreSQL, MySQL и SQL Server. Например, одна из групп в этой подкоманде плотно работает с PostgreSQL — делает вокруг нее сервисы, чтобы клиентам платформы было удобно управлять ею по нажатию одной кнопки: развернуть, сделать отказоустойчивой, проверить динамику и так далее.
Вторая команда занимается СУБД специального назначения, среди которых, например, разработанная в Яндексе реляционная СУБД ClickHouse с открытым исходным кодом для быстрой обработки аналитических SQL-запросов на структурированных больших данных в режиме реального времени; поисковая система с открытым исходным кодом Elasticsearch и другие.
Третья группа специалистов занимается процессингом данных — работает с Kafka, Spark и Hadoop. И четвертая занимается общей инфраструктурой — они делают вещи, которые от движка СУБД не зависят.
Как запускается процесс работы над проектами
Для управления качеством кода мы используем CI (Continuous Integration, практика непрерывной интеграции) и собственные инструменты, так как от него зависит работоспособность и крупных сервисов Яндекса, и всех внешних клиентов. Код обязательно требует ревью, даже если это просто фрагмент шаблона конфигурации сервера.
Для тестирования используем Docker, Behave, Godog и Jepsen. Каждое изменение в программном коде проходит полную пирамиду тестов: от статического анализа и юнитов до функциональных и инфраструктурных тестов. После этого мы контролируем риски и проверяем стабильность системы: с помощью таких инструментов, как SaltStack и Terraform, проверенный ревью и тестами код сначала раскатывается в preprod-окружение, потом во внутренний продакшн. В продакшн Облака релиз попадает только тогда, когда мы уверены в безопасности изменений. Разработанный Яндексом инструмент телеметрии Yandex Monitoring позволяет видеть состояние системы в режиме реального времени.
На распределение обязанностей внутри команды Data Platform можно посмотреть и под другим углом: есть работа над развитием платформы как продукта (новые функции и интеграции), есть поддержка систем, включая исправление ошибок и эксплуатацию, решение фундаментальных проблем (рост нагрузки, пиковое потребление и рефакторинг) и разработка баз данных и инструментов для opensource-сообщества.
Если говорить про языки программирования, то сейчас идет процесс переезда на Go — новые сервисы на нем пишутся, старые переписываются. Остались еще какие-то части на Python, но на Go уже 60-70% — это основной язык программирования.
Про создание трендов на рынке данных, инженерную культуру и opensource
Мы не создаем какие-то кастомные вещи, которые работают только на одного пользователя, а стремимся создавать и развивать что-то новое, что впоследствии будет востребовано на рынке. При этом нам важно сохранять инженерную культуру — при разработке мы думаем про качество и простоту поддержки в будущем, а не стремимся как можно быстрее запустить проект.
Так, впервые в мире удалось построить все управляемые сервисы вокруг сущности кластера, а не хоста. Например, мы единственные, кто сейчас в Managed service for PostgreSQL предоставляет кворумную репликацию — данные мастер-хоста автоматически реплицируются на две синхронные реплики внутри группы высокой доступности, а в случае отказа основного мастера одна из них берет на себя его роль. В модели, где центральной сущностью является хост, так сделать нельзя. То есть данные дублируются во всех репликах, но клиенту подтверждение транзакции отдается только тогда, когда одна (любая) реплика подтвердила их получение. И в случае отказа мастера новым станет именно эта реплика, на которой есть все данные.Таким образом, например при странных разделениях сети доступность становится выше.
Отдельно стоит сказать про opensource. Мы верим в силу сообщества и открытый исходный код. Также мы знаем, что наши решения могут пригодиться кому-то ещё, и поэтому активно коммитим в проекты вокруг своей деятельности. Однажды нам потребовалось обеспечить эффективное создание бекапов PostgreSQL в объектном хранилище, и для этого мы выбрали проект WAL-G. Спустя несколько месяцев наша команда стала его мейнтейнером. Кроме того, мы добавили туда поддержку MySQL, MongoDB, Redis и других движков. В случае MongoDB получилось даже сделать восстановление в точку (PITR). Так фича, которую крупные облачные провайдеры предлагают за деньги, стала доступна сообществу бесплатно.
Личный опыт
Я пришел в команду пять лет назад, когда мы были еще частью Яндекс.Почты, на позицию администратора баз данных PostgreSQL. Тогда как раз активно шел переезд Почты с Oracle на PostgreSQL. На руках на тот момент были офферы от других компаний, некоторые даже с более выгодными финансовыми условиями, но я все равно выбрал Яндекс. Меня привлек масштаб: десятки больших баз суммарным объемом в сотни терабайт и большой нагрузкой. Я подумал, что тут точно не буду скучать, и не ошибся. Сейчас у нас тысячи кластеров БД, миллионы запросов в секунду, а объем измеряется в петабайтах.
Адаптироваться было несложно, так как я уже имел опыт в этой области, да и команда очень дружелюбная — чувствовал себя максимально комфортно. Хорошая атмосфера и интересные задачи способствовали продуктивной работе. В итоге мы автоматизировали все, что могли, и доавтоматизировали до такой степени, что поняли, что из всего этого можем сделать сервис управляемых баз данных, что в итоге и сделали. Мы прошли длинный и интересный путь, в котором было все — от разработки новых систем резервного копирования до расследования случаев повреждения данных и их восстановления.
Базы данных, на мой взгляд, одна из самых интересных областей в IT: задачи здесь всегда сложные, ведь, в отличие от stateless-сервисов, у тебя всегда есть много данных, с которыми надо обращаться максимально аккуратно, их нельзя потерять или испортить. Из-за этого базы данных — достаточно консервативная область IT, в которой не спешат использовать новые «модные» технологии. Но при этом нужно максимально быстро и эффективно данные обрабатывать с использованием минимального количества ресурсов, что побуждает использовать новые технологии, тщательно их тестировать и аккуратно внедрять.
Можно сказать, что в Яндекс я пришел неожиданно (хотя и задумывался на тот момент о смене работы). Я получил приглашение на Yandex Weekend Offer и решил посмотреть, какие задачи там предлагают соискателям — тогда я сам занимался подбором разработчиков в своей компании и хотел узнать, как это устроено. Онлайн-часть, помню, решал буквально в последний момент, но в итоге успешно — меня пригласили на интервью. Я прошел все этапы и принял предложение, ведь Яндекс — это бренд, большая компания, интересные задачи. Плюс для меня все было новым — новый стек технологий, новый язык, новая область, и у меня получилось. Я был по большей части бэкендером, но еще ковырялся с фронтендом, потому что не было отдельного человека, учил Java Script, TypeScript — занимался клиентской разработкой. А в Яндексе — Go, Python, полный бэкенд, все покрыто тестами, куча автоматизации, смена парадигмы, смена языка. Получился классический выход из зоны комфорта. На данный момент я в команде больше трех месяцев, совсем скоро у меня закончится испытательный срок.
С 2015 года я веду в екатеринбургском филиале Школы анализа данных Яндекса курс «Алгоритмы и структуры данных». У меня всегда хобби были мало отличимы от работы, одно из моих увлечений — системы поиска в данных. В 2016 году, кажется, в одной из профессиональных рассылок я увидел однофамильца — Володю Бородина из Яндекса. Я узнал у него, используются ли в Яндексе технологии, улучшением которых я занимался как хобби. Потом мы довольно много общались по разным вопросам. В 2017 году, после того, как мы с ним обсудили состояние дел в сообществ, он позвал меня развивать PostgreSQL в Yandex.Cloud. Это звучало очень круто, потому что именно этим я занимался в свободное время. Но я сначала по привычке отказался. Когда летел домой, на соседнем кресле оказался человек, который только что проходил интервью в Яндексе — он рассказал, как интересно проходят собеседования. Тогда я и решил попробовать — пришел на собеседование на позицию «писать код про базы данных».
Управление данными — простой компонент, лежащий в основе любых новых штук. Он общий для всех, и поэтому мы стремимся решить самые сложные проблемы. Экстремальная сложность решаемых задач и полезность почти всем разработчикам в мире — вот что делает нашу работу перспективной.
В текущей команде работаю три года, хотя общий стаж в Яндексе — более девяти лет. Изначально я пришел в компанию, так как считал, что могу некоторые технические задачи делать лучше, чем докладчики от Яндекса.
На прошлой позиции было много рутины, а мне хотелось решать больше технических задач, поэтому я и перешел в облако. Мне хотелось работать со stateful-сервисами, потому что это сложнее — их можно потерять, испортить и сложно восстановить.
Мне нравится решать задачи, я могу менять их в зависимости от потребностей бизнеса. В Яндексе я уже был в роли SRE, разработчика, в облако приходил в роль технического менеджера, чтобы помогать с запуском, но мы сразу договорились, что после основного запуска я буду собирать команду и строить продукт по обработке данных с помощью экосистемы Apache Hadoop & Apache Spark. Сейчас моя команда развивает сразу два продукта: DataProc & Managed Service for Apache Kafka.
В Яндекс меня пригласили в 2016 году. На тот момент у меня уже был серьезный бэкграунд в разработке BI-решений. Но изначально меня приглашали на роль менеджера проекта — что было, как мне казалось, большим даунгрейдом. Но Алексей Башкеев (сейчас — СЕО Yandex.Cloud) на собеседовании рассказал, что в компании есть система Статистика, морально устаревшая, и нужно что-то новое. И когда я пришел, задача была не столько сопровождать существующую систему, а посмотреть, что из этого можно сделать. И через год, наверное, с третьей попытки запустился проект DataLens. Я был его, так скажем, и продакт-менеджером, и проджект-менеджером, и продакт-оунером в одном лице. Потом проект вырос в отдельную службу.
Было несколько критериев, которые убедили меня работать именно здесь. Во-первых, я понимал, с какими большими объемами данных работает Яндекс. Во-вторых, если раньше я внедрял BI для отдельных компаний как проекты, то здесь все устроено иначе — одна компания, но много заказчиков, разные бизнес-юниты. У них много данных, а требования, например, к скорости отображения данных довольно высокие относительно рынка. То есть для меня это был челлендж и технологический, и организационный.
Про рост и систему ревью
Рассказывает Кристина Диденко, HR-специалист в Yandex.Cloud
Для разработчика в Yandex.Cloud есть несколько традиционных пути роста: вглубь техническим специалистом — от младшего до ведущего, а затем в техлида, или же заниматься не только разработкой, но и менеджментом — развиваться по управленческой линии. Ценной бывает и та, и другая экспертиза. Бывают ситуации, когда человек растет, добирается до определенного уровня, а потом меняет профиль — решает уйти обратно просто писать код, сохраняя статус и уровень зарплаты. Здесь помогает то, что компании у всех сотрудников есть грейд — общий показатель уровня ответственности и профессиональных навыков сотрудника, который также влияет и на его доход.
Мы выстроили систему мониторинга результатов работы: специалист регулярно садится со своим руководителем и разбирается, какие цели достигнуты, где еще можно уйти вглубь, что получается, что интересно, а что нет. На основе этих результатов можно построить траекторию дальнейшего развития. В процессе ревью результаты сотрудников одинакового уровня сравниваются для того, чтобы оценка была более объективной. Итоги работы за полугодие влияют на доход: премии и бонусы в виде акций компании.
Как проходит процесс найма
Процесс найма новых разработчиков в Яндексе состоит из нескольких этапов. Обычно всё начинается с предварительного интервью, в ходе которого мы узнаем о вашем опыте и просим решить пару задач — код пишем в онлайн-редакторе. Затем проходят основные технические интервью с экспертами и представителями команды, содержание которых зависит от уровня позиции и специфики вакансии. А после назначаются финальные встречи с потенциальным руководителем и коллегами, где они подробно расскажут о своей работе и целях, но, тем не менее, также могут предложить решить технические задачи. Причем будет возможность пообщаться с несколькими командами и выбрать ту, которая подходит лучше всего. И когда все эти этапы пройдены успешно, то мы готовы предложить вам место в команде — презентовать оффер. Благодаря этой процедуре в Яндексе собралась команда очень продвинутых специалистов, работать с которыми интересно.
Но начать все же советую с самоопределения: какие вопросы и проекты вызывают у вас интерес? Вполне вероятно, что в списке вакансий уже есть те задачи.
Разработка платформ для работы с данными — устойчивый тренд
Хорошие специалисты по сервисам хранения и обработки данных будут нужны всегда и везде. Как показывает практика, их не может быть много — их всегда не хватает. В основе каждого проекта, продукта или сервиса лежат базы данных, с которыми важно уметь работать, правильно «готовить» и анализировать. В этой области бывают работники с узкой, но востребованной специализацией. В качестве примера можно привести специалистов с глубоким опытом работы с Greenplum (аналитическая колоночная массивно-параллельная СУБД, предназначенная для сложной аналитики по большим объёмам данных). И за такими специалистами компании готовы «охотиться».
Разрабатывая управляемые базы данных, специалист получает и углубляет свои знания не только в векторе разработки, но и эксплуатации этих же баз данных — одно без другого невозможно. Это важно и ценно, потому что открывается больше возможностей: можно пойти работать разработчиком прикладных приложений, например, а можно — специалистом по эксплуатации баз данных (DBA). Переходя, например, на позицию разработчика прикладных приложений, так или иначе человек будет работать с базами данных, и с таким бэкграундом реализация приложения будет более эффективной. И одни, и другие важны и необходимы практически каждому сервису.
Практически в любой отрасли есть большое количество данных, которые нужно уметь собирать и обрабатывать. И в каждой из них есть потребность в поиске и найме таких специалистов. Да, могут быть различия в базах данных, но зависят они непосредственно от целей и задач, которые ставит перед собой бизнес.
Подписывайтесь на блог Yandex.Cloud, чтобы узнавать еще больше новостей и историй об IT и бизнесе.
Другие истории, которые активно читают наши подписчики:
Это все, что нужно знать о Яндексе ))
"На руках на тот момент были офферы от других компаний, некоторые даже с более выгодными финансовыми условиями". - ещё вот это, это у них всегда так. Всегда есть работа за бОльшие деньги и с меньшим головняком, чем у них.
Хорошая попытка, Яндекс, но я к вам работать всеравно не пойду.
Какая скучная статья