Рекомендации по безопасному развертыванию

Статья
11/15/2023

Применяется к этой рекомендации по контрольным спискам операционной эффективности Azure Well-Architected Framework:

Четко определите методики безопасного развертывания рабочей нагрузки. Подчеркните идеалы небольших, добавочных, качественных методов выпуска. Используйте современные шаблоны развертывания и прогрессивные методы воздействия для управления рисками. Учет стандартных развертываний и развертываний в чрезвычайных ситуациях или с исправлениями.

В этом руководстве описываются рекомендации по использованию методов безопасного развертывания (SDP). Безопасные процессы и процедуры развертывания определяют, как безопасно вносить и развертывать изменения в рабочей нагрузке. Для реализации SDP необходимо думать о развертываниях с точки зрения управления рисками. Вы можете свести к минимуму риск человеческих ошибок в развертываниях и ограничить влияние проблемных развертываний на пользователей, реализовав SDP.

Ключевые стратегии проектирования

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

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

В следующих разделах приведены подробные рекомендации по каждому из этих аспектов.

Безопасность и согласованность

Независимо от того, развертываете ли вы обновление в коде приложения, инфраструктуре как коде (IaC), флаге функции или обновлении конфигурации, вы представляете риск для рабочей нагрузки. В рабочей среде нет развертываний с низким риском . Каждое развертывание должно соответствовать стандартному шаблону и должно быть автоматизировано, чтобы обеспечить согласованность и свести к минимуму риск человеческих ошибок. Очень важно, чтобы цепочка поставок рабочей нагрузки и конвейеры развертывания были надежными, безопасными и имели четко определенные стандарты развертывания. Рассматривайте каждое развертывание как возможный риск и подвергайте каждое развертывание одному и тому же уровню управления рисками. Несмотря на риски, следует продолжать развертывать регулярные изменения в рабочей нагрузке. Если не развернуть регулярные обновления, это может привести к другим рискам, например уязвимостям системы безопасности, которые необходимо устранить с помощью развертываний. Дополнительные сведения см. в статье Рекомендации по проектированию цепочки поставок разработки рабочих нагрузок.

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

Прогрессивное развертывание экспозиции

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

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

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

Модели работоспособности

Разработайте надежную модель работоспособности в рамках платформы наблюдаемости и стратегий надежности. Модель работоспособности должна предоставлять подробные сведения о компонентах и общей работоспособности рабочей нагрузки. Если во время развертывания вы получаете оповещение об изменении работоспособности, связанном с конечным пользователем, развертывание должно немедленно остановиться и провести исследование причины оповещения, чтобы помочь определить дальнейшие действия. Если конечные пользователи не сообщают о проблемах и все индикаторы работоспособности остаются зелеными в течение всего времени выпекания, развертывание должно продолжаться. Обязательно включите метрики использования в модель работоспособности, чтобы гарантировать, что отсутствие проблем, сообщаемых пользователем, и негативные сигналы о работоспособности не скрывают проблему. Дополнительные сведения см. в статье Создание модели работоспособности.

Обнаружение проблем

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

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

Откат изменений, особенно базы данных, схемы или других изменений компонентов с отслеживанием состояния, может быть сложным. Ваши рекомендации по SDP должны содержать четкие инструкции по обработке изменений данных в соответствии с структурой пространства данных для вашей рабочей нагрузки. Аналогичным образом, необходимо тщательно обрабатывать накат, чтобы sdp не пренебрегал и чтобы исправление или другие усилия по минимизации выполнялись безопасно.

Общие рекомендации SDP

Реализуйте управление версиями в артефактах сборки, чтобы гарантировать возможность отката и отката при необходимости.
Используйте поток выпуска или структуру ветвления на основе магистрали, которая обеспечивает тесно синхронизированную совместную работу в группе разработчиков, а не структуру ветвления на основе Gitflow или среды.
Автоматизируйте как можно больше sdp. Подробные инструкции по автоматизации процессов непрерывной интеграции и непрерывной поставки приложений (CI/CD) см. в статье Рекомендации по реализации автоматизации.
Используйте методы CI для регулярной интеграции изменений кода в репозитории. Методы CI помогут выявить конфликты интеграции и снизить вероятность крупных и рискованных слияний. Дополнительные сведения см. в руководстве по непрерывной интеграции.
Используйте флаги функций, чтобы выборочно включать или отключать новые функции или изменения в рабочей среде. Флаги функций помогают контролировать раскрытие нового кода и быстро откатывать развертывание при возникновении проблем.
Разверните изменения в промежуточных средах, которые зеркало рабочей среде. Практические среды позволяют протестировать изменения в управляемом параметре перед развертыванием в активной среде.
Установите проверки перед развертыванием, включая проверку кода, проверки безопасности и проверки соответствия требованиям, чтобы обеспечить безопасность развертывания изменений.
Реализуйте автоматические размыкатели цепи, чтобы автоматически останавливать трафик к службе, в которой возникают проблемы. Это может помочь предотвратить дальнейшую деградацию системы.

Протоколы SDP для экстренного реагирования

Установите предписывающие протоколы, которые определяют, как можно настроить SDP для исправления или для экстренных проблем, таких как нарушение безопасности или уязвимость. Например, протоколы SDP для экстренного реагирования могут включать:

Ускорение этапа продвижения и утверждения.
Тестирование состояния и ускорение тестирования интеграции.
Сокращение времени выпекания.

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

Упрощение azure

Azure Pipelines и GitHub Actions поддерживают многоэтапные развертывания с помощью шлюзов утверждения, которые помогут вам разработать прогрессивное развертывание для развертываний.
Используйте Служба приложений Azure промежуточные слоты, чтобы легко переключаться между версиями кода. Промежуточные слоты полезны для тестирования в промежуточных средах и могут использоваться для сине-зеленых развертываний.
Храните флаги функций веб-приложения и управляйте ими в Конфигурация приложений Azure. С помощью этой службы можно создавать, изменять и развертывать функции в единой плоскости управления.
Развертывание приложений рабочей нагрузки на виртуальной машине с помощью приложений виртуальных машин.
Используйте подсистемы балансировки нагрузки Azure для реализации стратегий развертывания и обеспечения работоспособности приложений рабочей нагрузки с помощью собственных ресурсов.
Используйте расширение работоспособности приложений для создания отчетов о работоспособности приложений из экземпляра масштабируемого набора виртуальных машин. Расширение проверяет конечную точку локального приложения и обновляет состояние работоспособности на основе ответов TCP/HTTP(S), полученных от приложения.
Используйте Azure Logic Apps для создания новой версии приложения при каждом обновлении. Azure ведет журнал версий приложений и может отменить изменения или повысить уровень до любой предыдущей версии.
Многие службы Базы данных Azure предоставляют функции восстановления на определенный момент времени, которые могут помочь в откате. К службам, поддерживающим восстановление на определенный момент времени, относятся:

Пример

Пример использования этой модели развертывания см. в руководстве по архитектуре кластеров Служба Azure Kubernetes (AKS).

Ссылки на сообщество

Контрольный список эффективности операций

Ознакомьтесь с полным набором рекомендаций.