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

Шаблоны канареечных релизов и cluster immune systems

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

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

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

При использовании этого шаблона, когда мы делаем выпуск, то наблюдаем, как программное обеспечение работает в каждой среде. Когда что-то кажется неправильным, мы выполняем откат, в противном случае мы выполняем развертывание в следующей среде[97].

На рис. 21 показаны группы сред в компании Facebook, созданные для поддержки этого шаблона релизов:

Рис. 21. Шаблон канареечного релиза (источник: Джез Хамбл, Дэвид Фарли «Непрерывное развертывание ПО. Автоматизация процессов сборки, тестирования и внедрения новых версий программ»)

• группа A1: производственные серверы, обслуживающие лишь внутренних сотрудников;

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

• группа A3: остальная часть производственных серверов, развертывающихся после того, как программное обеспечение на серверах в кластере А2 достигнет определенных критериев приемлемости.

Cluster immune system — расширение шаблона канареечного релиза, в ней системы мониторинга производства связываются с процессами релиза и автоматизируется откат на предыдущую версию кода, если производительность системы со стороны пользователя отклоняется от заданных показателей сильнее, чем ожидается. Например, когда коэффициенты пересчета для новых пользователей падают ниже сложившихся показателей на 15–20 %.

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

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