* Все что написано в данной статье находится в процессе разработки и публично еще не анонсировано (почти эксклюзив), так что некоторые вещи могут работать иначе или не работать вовсе
Привет!
Сегодня я расскажу о пока еще публично не анонсированном, но уже доступном для использования сервисе в Microsoft Azure Websites под названием Testing In Production (TiP). С его помощью вы сможете начать тестировать свои облачные веб-приложения более тонко и точно, показывая новый функционал лишь малой части ваших пользователей, оставляя в «безопасности» большинство посетителей. Одним из способов использования TiP является A/B тестирование, которое может быть использовано в различных сценариях. И прежде чем мы перейдем к сути, стоит прежде рассказать, а что же это такое и для чего оно нужно.
A/B тестирование
Если опираться на само название методики, то можно догадаться, что A/B тестирование — это про то, что мы тестируем какие-то две версии продукта (A и B). Если говорить более точно, то данная методика (также называемая как split-test или testing in production) позволяет вам анализировать поведение пользователей веб-сайта в зависимости от неких изменяемых факторов. Например, вы хотите внедрить новый функционал, но не до конца уверены, как он повлияет на лояльность и конверсию (если вы продаете что-то). Чтобы не делать ложных предположений, основанных на личных суждениях и предпочтениях (которые, увы, зачастую не имеют ничего общего с мнением большинства), вы можете запустить новую фичу работать параллельно с предыдущей версией сайта, направляя по 50% трафика туда и туда. Затем, в зависимости от полученных результатов (данные от вашей метрики — конверсия, переходы по страницам, количество комментариев или что-то еще), вы принимаете решение об успешности или не успешности вашего нового решения и его дальнейшей судьбе: быть ли ему запущенному на 100% или же удаленному навсегда.
На самом деле A/B тестирование куда более сложная штука. В нем заложены множества теорий из статистики, поскольку вы должны понимать, что принятие решения об успешности нового функционала должно быть взвешенным и иметь под собой вполне конкретные основания. Так, например, если вы владеете интернет-магазином по продаже чего либо, и решите, что с 25 декабря вы будете продавать новогодние ели (но оформите это в виде A/B теста), то конечно же в период с 25 по 31 декабря ваш вариант B будет просто светиться положительными результатами конверсии. Если вдруг вы окажетесь не сильно умным владельцем бизнеса, то вы можете решить, что раз результаты положительны, стоит оставить продаваться эти елки постоянно, пустив «новую фичу в лайв». Однако, по вполне понятным причинам, вас ждет жуткое разочарование где-то после 7 января, когда закончится Рождество. Именно поэтому важно понимать, что любое ваше решение относительно запуска или отката нового функционала должно быть статистически верным, а для этого требуется более длительный срок для мониторинга.
Более подробно про A/B тестирование и статистические изыскания вокруг него можно поискать в интернете, я оставлю это на вашей совести. А далее мы рассмотрим, как можно организовать такое тестирование для вашего сайта, размещенного в Microsoft Azure.
Технологии
Допустим, что вы уже освоили теоретическую часть и понимаете, что такое статистика и как ей манипулировать пользоваться. Но теперь встает вопрос — а как реализовать A/B тестирование с технической точки зрения? Если у вас есть веб сайт, как ему (или серверу) понять, в какой вариант (A или B) направить каждого конкретного пользователя? И кто должен этим заниматься — непосредственно веб-приложение или же веб-сервер? Идем дальше, и возникают следующие вопросы. Что делать с новым посетителем? Каким-то образом его надо распределить по вариантам, причем так, чтобы общее число посетителей и там и там оставалось примерно одинаковым. А что делать с пользователем, который вернулся на сайт, побывав на нем ранее и уже поучаствовавшем в эксперименте? Его можно либо заново распределить случайным образом, либо направить в ту группу, к которой он принадлежал раньше. И как все это дело мониторить? Ведь мало анализировать общую условную конверсию (прирост или убыль), надо еще понимать, как эта конверсия ведет себя в зависимости от каждого варианта.
Встроенные решения для сплит тестов предлагает, например, MailChimp. Поскольку A/B тестирование довольно часто используют именно как маркетинговый инструмент, применение его в почтовых рассылках более чем оправдано. Есть подобные инструменты и для веб-сайтов. Например, Optimizely, Visual Website Optimizer и даже Google Analytics. Но все они позволяют вам манипулировать лишь контентом, делая невозможным тестирование и анализ каких-то поведенческих вещей (или совершенного нового функционала). Эти инструменты — чисто маркетинговые, и для использования в технологическом продукте не пригодны. Я надеюсь, что кто-то в комментариях сможет предложить другие сервисы (или готовые решения для веб-серверов), которые позволяют проводить A/B тестирование ваших приложений с минимумом затрат. А я же расскажу о новых возможностях облака Microsoft Azure для решения подобных задач.
Testing in production
Понятие Testing in Production (TiP) появилось в Azure совсем недавно и до сих пор находится в стадии развития. Компания еще официально не объявляла о данном сервисе, однако он уже доступен в новом портале управления Azure и вы можете самостоятельно опробовать его в действии.
На самом деле TiP — это не только и не столько A/B тестирование, сколько комплексный подход к оценке успешности очередного внедрения. Платформа TiP представляет несколько основных видов тестирования (прошу прощения, что термины на английском, но я не рискну указать некорректный перевод):
- Canary Testing — тестирование ранних версий или прототипа продукта на маленьком объеме внешних пользователей с целью оценки успешности идеи.
- Ramp-Up Testing (также известное как Canary Deployment) — процесс тестирования прототипа с постепенным увеличением доли пользователей, задействованных в тестировании. По сути это медленное развертывание нового решения, при наличии ошибок в котором вы сможете избежать больших рисков
- Recovery Testing — не совсем тестирование. Возможность при выпуске нового функционала на боевые сервера и при обнаружении критической ошибки, моментально откатиться на предыдущую стабильную версию, которая остается в виде дублирующего развертывания
- A/B Testing — то, с чего мы начали, и то, к чему так или иначе можно свести все предыдущие виды.
Все эти различные подходы к тестированию строятся вокруг одного технического решения в Azure, поэтому вам не придется изучать кучу документации (которой, пока, кстати, нет) и настраивать множество различных параметров. Все делается в одном месте, а уж вам решать, как именно вы этим воспользуетесь. Давайте, наконец, перейдем к практической части — как же заполучить новые возможности для своего web-приложения.
Подготовка
Для того, чтобы начать пользоваться услугами Testing in Production, ваш сайт должен, во-первых, работать в облаке Microsoft Azure (что очевидно), а, во-вторых, иметь уровень конфигурации Standard. Данное требование вызвано тем, что для работы тестирования вам необходимо создавать новые слоты развертывания, которые есть только в уровне Стандарт.
Выберите сайт, который будете тестировать
Итак, выбираем нужный нам веб-сайт и переходим в панель настроек. Где-то в самом низу притаилась заветная кнопка под названием Testing in Production, по нажатию на которую откроется мастер создания нового сервиса.
Ссылка на создание тестирования
Создание тестирования
Вас попросят создать слоты для развертывания новых версий. Здесь начинается простор для творчества, потому что вы вольны сами решать, сколько слотов вам надо. Причем надо понимать, что слот может использоваться как для участия в тестировании, так и независимо от этого. Вы можете иметь отдельный слот для внутреннего тестирования (например, если у вас настроен continuous integration), отдельный слот-песочницу, отдельно выделить специфический функционал и так далее. При этом, на базе тех же слотов, вы можете организовать A/B тестирование (о чем ниже).
Чтобы добавить слот, вам надо указать его имя и источник конфигурации, откуда вы можете импортировать настройки другого слота. Кстати, стоит помнить, что название production зарезервировано под основную версию приложения, так что не удивляйтесь, если Azure будет ругаться на это имя.
Добавление нового слота
Создадим необходимое количество слотов (пусть для примера их будет три) и назовем как-то осмысленно:
Список слотов
Каждый слот, по сути, представляет из себя самостоятельный сайт, к которому можно получить доступ по ссылке вида <имя_основного_сайта>-<имя_слота>.azurewebsites.net. Также, как и обычный сайт, вы можете развернуть свой код в слоте с помощью Publish Profile или иными привычными способами.
После того, как все слоты определены и необходимый функционал в них присутствует, мы готовы к тестированию!
Настройка тестирования
Для того, чтобы начать тестировать наши решения (будь то A/B или Canary тесты), необходимо указать, какую часть наших пользователей мы хотим направить и куда. Возвращаемся в панель Testing in Production, где теперь мы можем регулировать проценты распределения пользователей по слотам:
Добавление вариантов для тестирования
При добавлении новых слотов к тестированию, вы всегда можете видеть, сколько пользователей будет направлено на основной сайт. Когда вариантов немного, это не так так важно, зато может быть удобно, когда вы начнете активно пользоваться новыми возможностями и будете держать десятки запущенных тестов (удачи в мониторинге всего этого!).
Кстати, поскольку каждый слот представляет собой некое подобие полноценного веб-приложения, то вы можете организовывать более сложные сценарии с древовидными тестами (тест внутри теста):
Вложенные тесты
В приведенном примере видно, что в сценарии вложенных тестов роль базы выполняет уже не production-слот, а выбранный тест (в нашем случае test-1). Теперь если проанализировать всю картину, то получится следующее — 10% всех наших пользователей направляются в вариант test-1. Затем 50% остается в этом варианте, а еще 50% (от первоначальных 10%, не забываем) направляется снова в production.
Если у вас есть только один вариант для тестирования, тогда вам достаточно просто направить 50% пользователей в базу и 50% пользователей в вариант, чтобы получить равномерное распределение и принимать решения об успешности, опираясь на статистику и конкретные показатели. Но что если вы хотите протестировать несколько вариантов одновременно? Или же вы не хотите, чтобы на новый функционал сразу же направилось 50% посетителей, а желаете ограничиться лишь 10%? В этом случае сравнение варианта с базой будет некорректным, потому что в обоих случаях выборка посетителей (абсолютное их количество) будет отличаться. Именно для таких сценарием может быть использован древовидный подход, когда вы сначала отсекаете лишь малую часть пользователей в тестируемый вариант, а потом внутри него «возвращаете» 50% обратно в базу. В этом случае, при правильном мониторинге, вы сможете увидеть достоверные результаты, основанные на одинаковых величинах.
Все это распределение выполняется за кулисами вашего веб сайта, поэтому пользователю достаточно лишь набрать URL нужной ему страницы. Подмена версий произойдет незаметно, без каких-либо редиректов или дополнительного кода. Однако если вам, как разработчику, потребуется прямой доступ к какому-то варианту, то вы всегда можете обратиться к нему по его прямой ссылке (сайт-вариант.azurewebsites.net).
Как это работает
Пока какой-либо информации о том, как именно это устроено, крайне мало. Однако мне известно (и, к счастью, мне не запрещено этим делиться), что за кулисами TiP устроен так, что вам, как разработчику, не нужно особо беспокоиться о корректности проведения тестирования. При самом первом посещении вашего сайта новым пользователем, сервис решает, в какой из вариантов его определить. Как именно это происходит пока непонятно и все ограничивается лишь словами, но если у вас будет интерес, я могу попробовать узнать подробности. После того, как сервер решил, куда же именно стоит направить пользователя, ему присваивается соответствующая кука. Впоследствии, с помощью нее сервер определяет, куда определить этого посетителя, если он решил вернуться. Таким образом вам гарантируется, что один и тот же человек будет прикреплен к одному и тому же варианту, до тех пор пока пользователь не решит удалить куки.
Установленная кука
Мониторинг
Пока что для мониторинга результатов тестирования готовых решений нет и вам предоставляется полная свобода в выборе подходящего сервиса. Вы можете воспользоваться встроенным в Azure сервисом Application Insights, который позволяет собирать статистику посещений и тому подобные вещи. Вы можете попытаться настроить Google Analytics или Яндекс.Метрику. Но в любом случае, что бы ни придумали в Microsoft, отслеживать свою конверсию вы должны самостоятельно, потому что для каждого она своя. Например, для кого-то конверсия — это переход по ссылке, а для кого-то — установленное приложение или положительный фидбек. В любом случае все зависит от конкретного продукта и целей тестирования, поэтому не стоит ждать чего-то универсального. Я уверен, что Microsoft вскоре покажет инструменты мониторинга, заточенные под конкретно TiP, но они не будут панацеей от всех бед, и это надо четко понимать.
Что дальше
Резонный вопрос, который может возникнуть после прочтения этой статьи — «и что мне делать с сырым продуктом?». Я сознательно написал эту статью именно сейчас, до публичного представления сервиса, когда он еще находится в стадии разработки. Моей целью было, во-первых, рассказать об очень удобном инструменте тестирования ваших веб-приложений (кстати, A/B тестирование проводят в Facebook, Booking.com и множестве других компаний), а во-вторых, подтолкнуть вас начать использовать его именно сейчас и своими отзывами помочь команде разработчиков делать сервис лучше. Они честно признаются, что многое еще предстоит сделать, и что многие фишки пока доступны только из PowerShell, однако работа идет и вскоре этот сервис будет работать и приносить пользу. Так что если вы любите быть в авангарде, то это отличный шанс попробовать что-то раньше других.
Есть оличное видео, демонстрирующее на живых примерах, как работает Azure Testing In Production - http://channel9.msdn.com/Shows/Web+Camps+TV/Enabling-Testing-in-Production-in-Azure-Websites.
P.S.
Если вы решили самостоятельно потестировать новые возможности Testing in Production и столкнулись с ошибками/проблемами или у вас есть предложения по улучшению, то, пожалуйста, напишите об этом мне. Я постараюсь направить все отзывы непосредственно команде разработчиков, чтобы они могли сделать этот сервис лучше.
Автор: glamcoder
