Джин Ким - Руководство по DevOps

Переключатель функциональности возможностей обычно реализуется через управление логикой работы приложений или элементов интерфейса с помощью условного оператора, включающего или отключающего функцию на основе параметра конфигурации, хранящегося где-то в системе. Это может быть просто файл конфигурации приложения (например, файлы конфигурации в форматах JSON, XML), либо он может быть реализован с помощью службы каталогов или даже веб-службы, специально разработанной для управления функцией переключения [99].

Переключение функциональных возможностей также дает возможность делать следующее:

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

• ненавязчиво ухудшить производительность: если наши сервисы испытывают сильную нагрузку, что в обычных условиях требует от нас увеличения мощности оборудования или, что еще хуже, способно привести к сбоям в обслуживании, мы можем использовать переключение функциональных возможностей для снижения качества обслуживания. Другими словами, мы можем увеличить число пользователей, получающих ухудшенную функциональность (например, уменьшаем число клиентов, которые могут получить доступ к определенным возможностям, отключив функциональности, интенсивно использующие процессор, такие как рекомендации, и так далее);

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

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

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

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

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

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

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

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

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

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