Книга: Руководство по DevOps

Выполняйте теневые запуски

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

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

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

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

В 2009 г., когда Джон Олспоу был вице-президентом отдела эксплуатации компании Flickr, он писал руководству компании Yahoo! о процессе теневого запуска: при таком процессе «увеличивается уверенность каждого работника почти до безразличия, если говорить о страхе перед возникновением проблем, связанных с нагрузкой на сервис. Я не имею представления, сколько развертываний кода в производство было выполнено в любой из дней в течение последних пяти лет, ведь в большинстве случаев я не беспокоился об этом, поскольку эти изменения сопровождались очень низкой вероятностью появления каких-либо нежелательных последствий. Если эти последствия все же проявлялись, любой из работников Flickr мог найти на веб-странице сведения о том, когда были внесены изменения, кто их внес, и точно узнать (строчка за строчкой), что именно было изменено»[100].

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

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

Оглавление книги