Как «Яндекс.Облако» разрабатывает свои сервисы

Это совокупность факторов: организационных, процессуальных и технологических. Наш ориентир в плане построения потока разработки сервисов — Amazon Web Services (AWS).

Современная облачная платформа — масштабная и разноплановая структура. Решения лидеров рынка — AWS, Microsoft Azure и Google Cloud Platform — состоят из сотен различных сервисов. Чтобы достичь подобного уровня, Яндекс.Облаку, как достаточно небольшой компании по сравнению с лидерами, нужно было сформировать четкий план развития и обеспечить доступ пользователей к нему. Клиенты хотят видеть, что было вчера, что есть сегодня и куда будет двигаться платформа завтра. Им нужно понимать, каков наш потенциал, не возникнет ли ситуация, когда мы будем вынуждены остановиться, чтобы решить внутренние проблемы, например с масштабированием.

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

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

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

У Яндекс.Облака это комбинация из трех типов сервисов. Во-первых, зрелые сервисы, которые долго находятся в общем доступе. Они как раз и обеспечивают добавление новых возможностей. Во-вторых, сервисы, которые только что вышли. Главное при работе с ними — управление ожиданиями пользователей. Нужно понимать, какие критически важные возможности не были включены в первую версию, чтобы добавить их в ближайший релиз. Команды новых сервисов, по сути, занимаются не столько добавлением возможностей, сколько исправлением недостатков, получают обратную связь от пользователей. И наконец, третий тип — сервисы на стадии ограниченного доступа, мы называем ее Preview. Фактически это апробация MVP (Minimum Viable Product) — версии продукта с минимально необходимой функциональностью. Подобная комбинация позволяет нам постоянно добавлять новые возможности и сервисы. А пользователь видит непрерывное развитие платформы.

Если говорить об организационном уровне, то за каждый сервис должен отвечать отдельный руководитель. В AWS это Single Threaded Leader — специалист, который несет ответственность за все аспекты развития сервиса. Он занимается организационной и продуктовой частью, архитектурой решения. Такой подход позволяет руководителю и его команде концентрироваться на продукте и двигать свою часть платформы вперед.

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

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

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

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

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

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

Следующая фаза — интеграционное тестирование: проверяются взаимодействие между сервисами и сценарий каждого из них. Затем идет нагрузочное тестирование, его можно считать частью интеграционного или отдельным процессом. Последний шаг — preproduction-тестирование.

Оно полностью автоматизировано. Более того, у нас в команде нет выделенных тестировщиков. Я сторонник гомогенных команд с минимальным разделением на дисциплины и профессии. Люди, которые у нас занимаются разработкой, тестированием и поддержкой, — это инженеры-разработчики. Они пишут и код, и тесты. Мы в автоматическом режиме проводим check-in, npm-тесты, используем системы нагрузочного тестирования.

Я бы также выделил кросс-тестирование: новая версия каждого сервиса тестируется на совместимость с production-версиями всех остальных.

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

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

Тарификация и продвинутый мониторинг вводятся после Preview. Соответственно, нагрузочное и функциональное тестирование тоже откладываются. В общий доступ сервис переходит, когда вводится вся запланированная функциональность. Это первое условие. Второе — валидация MVP. Мы должны убедиться в том, что компании начали пользоваться продуктом, что пользователей достаточно и они готовы платить за сервис.

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

Конечно, многие решения мы заимствовали у других сервисов. Например, как и Microsoft, мы делаем автоматический бутстрэп всего кластера, который позволяет при необходимости поднять Яндекс.Облако с нуля в автоматическом режиме. Опыт Google пригодился при работе с API: мы так же стремимся к максимальной консистентности и используем строгие гайдлайны API для всех сервисов. Взаимная независимость сервисов базируется на опыте Amazon. У них же мы переняли использование максимального количества решений с открытым исходным кодом.

Ошибки, правда, все равно случаются. Так, мы недооценили рост популярности Kubernetes, поэтому в Яндекс.Облаке Managed Kubernetes пока есть только в закрытом Preview. Если бы мы были точнее в прогнозах, то запустили бы сервис на полгода раньше.

Облако — это в первую очередь инфраструктура. Поэтому она на первом месте. Следующие по популярности — сервисы машинного обучения, и здесь кроется отличие Яндекс.Облака от «большой тройки». Наши ML-сервисы создавались на базе зрелых внутренних сервисов, первоначально разработанных для нужд самой компании. Третье место занимают управляемые базы данных (Managed Data Bases).

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

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