© 1995-2021 Компания «Инфосистемы Джет»
Как Яндекс Облако разрабатывает и тестирует свои сервисы
Эксклюзив

На что стоит обращать внимание при выборе облачной платформы

26.12.2019

Посетителей: 144

Просмотров: 198

Время просмотра: 2.6 мин.

Как Яндекс.Облако обеспечивает быстрый вывод сервисов на рынок?

 

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

 

На что стоит обращать внимание при выборе облачной платформы?

 

 

– Число сервисов, предоставляемых Яндекс.Облаком, за последний год выросло с 9 до 22. Как вы достигли такого высокого показателя? Что его обеспечивает: процессы, люди, практики?

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

– Какие сложности создает ускорение Time-to-Market? Есть ли здесь подводные камни?

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

 

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

 

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

– Как в Яндекс.Облаке построено тестирование новых сервисов?

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

 

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

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

– Автоматизировано ли тестирование? Какие практики вы применяете?

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

 

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

– В какой момент сервисы выходят в Preview-доступ? Как переходят в общий доступ?

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

 

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

 

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

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

– Опираетесь ли вы на опыт других компаний в индустрии? Если да, то помогает ли это избежать серьезных ошибок?

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

 

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

 

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

– Как, по вашему опыту, компании-разработчики и интеграторы пользуются Яндекс.Облаком? Какие сервисы наиболее востребованы?

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

– Я разработчик или интегратор. Что мне стоит учитывать при выборе облачной платформы?

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

 

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

Уведомления об обновлении тем – в вашей почте

Проблемы безопасности виртуальных сред: заплаточный подход

Прошедший 2012-й год показал, что компании в России начали вести реальную работу в области обеспечения защиты своих виртуальных сред (ВС)

Как перейти в облако и не облажаться

Свой дата-центр vs публичное облако. Кто кого? Варианты использования публичных облаков в корпоративном ИТ-ландшафте? Что нужно учитывать при переносе приложения в cloud-среду?

Приложения размером с интернет

Основные черты современных информационных систем – гибкость и динамика

Крупные компании готовы переносить системы в российские облака

В интервью нашему изданию Денис Абраменко рассказал, какие системы сервисная компания «Центр корпоративных решений», входящая в состав Fletcher Group, готов переносить в публичное облако и почему будущее ИТ-инфраструктур крупных компаний — за гибридными облачными моделями.

Там, за «облаками»...

Термин «облачные вычисления» появился давно. И разговоры про них идут не первый год. Но лишь с конца 2009- го «облака», согласно отчету Gartner, стали основным трендом ИТ- индустрии.

Обл'исполком

Рисунок «облака» всегда был стандартной метафорой для обозначения некоего общего для определённых терминальных устройств источника существования. Терминальные устройства менялись, метафора оставалась.

«Облачные» решения от EMC

Корпорация EMC в числе первых начала разработку продуктов, предназначенных для построения «облачной» инфраструктуры. В настоящее время EMC является лидером на рынке решений Cloud Ready для СХД.

Шесть ИТ-трендов корпоративного рынка

Конец уходящего года и начало нового – время ожиданий, надежд и прогнозов.

ИТ-сервис: тенденции развития

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

Спасибо!
Вы подписались на обновления наших статей
Предложить
авторский материал





    Спасибо!
    Вы подписались на обновления наших статей
    Подписаться
    на тему







      Спасибо!
      Вы подписались на обновления наших статей
      Оформить
      подписку на журнал







        Спасибо!
        Вы подписались на обновления наших статей
        Оформить
        подписку на новости







          Спасибо!
          Вы подписались на обновления наших статей
          Задать вопрос
          редактору








            Оставить заявку

            Мы всегда рады ответить на любые Ваши вопросы

            * Обязательные поля для заполнения

            Спасибо!

            Благодарим за обращение. Ваша заявка принята

            Наш специалист свяжется с Вами в течение рабочего дня