Стратегии архитектуры для безопасных методов развертывания

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

OE:11

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

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

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

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

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

Обеспечение безопасности и согласованности развертываний

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

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

Внедрение прогрессивной модели воздействия

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

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

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

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

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

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

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

Разработка надежных моделей работоспособности рабочей нагрузки

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

Реализация механизмов обнаружения сбоев

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

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

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

Настройте защитные ограничения для развертывания

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

Не полагаться только на один тип теста. Разные тесты выявляют разные типы сбоев. Например, тесты стабильности контракта проверяют, остается ли фигура API совместимой, а тесты поведения проверяют правильность функциональности API. Если вы планируете развертывать изменения в правилах безопасности сети, имитируйте влияние сначала, чтобы убедиться, что вы не случайно блокируете важный трафик и приводит к сбою. Включите моделирование сетевых политик в проверки перед развертыванием, если в выпуске изменяются NSG или правила администратора безопасности в Диспетчер виртуальных сетей Azure. Анализатор влияния правил Azure Network Watcher позволяет проверять предлагаемые изменения правил на соответствие шаблонам реального трафика до их применения, чтобы критически важный трафик приложений и управления не был непреднамеренно заблокирован. Эта проверка снижает риск сбоев, вызванных развертыванием. Его следует использовать вместе с поэтапным развертыванием и планами отката, поскольку полнота анализа зависит от доступных данных о трафике.
Реализуйте выключатели для автоматического остановки трафика в службу, в которой возникают проблемы. Это может помочь предотвратить дальнейшее ухудшение состояния системы.

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

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

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

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

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

Удаление или объявление компонента устаревшим является одним из изменений с наиболее высоким риском, которые возможны. После удаления ресурс часто исчезнет навсегда, и восстановление может оказаться трудным. Даже то, что кажется праздным или незначительным, может по-прежнему поддерживать критически важную скрытую зависимость. Рассматривайте каждое удаление как необратимое и следуйте преднамеренному, безопасному подходу, например:

Подтверждение бездействия. Убедитесь, что ресурс действительно не используется. Определите четкие индикаторы бездействия в полном цикле пользователя или бизнеса. Если вы видите какие-либо действия, такие как запросы, вызовы маршрута, изменения глубины очереди, оценки фича-флагов или запросы DNS, изучите и убедитесь, что это обоснованно, прежде чем продолжить.
Сохраните состояние перед удалением. Создайте моментальный снимок, экспорт или резервную копию ресурса и пометьте его датой удаления или проверки.
Отключите перед удалением. По возможности переместите компонент в отключенный или автономный режим вместо немедленного удаления. Это помогает безопасно выявлять скрытые зависимости. Пропустите этот шаг, только если требования к соответствию или безопасности требуют немедленного удаления.
Мониторинг с помощью окна наблюдения. Наблюдайте через окно мониторинга, которое охватывает как обычные, так и пиковые образцы использования. Любая неожиданная активность в течение этого периода должна перезапускать процесс вывода из эксплуатации.
Очистка остаточных ссылок. Убедившись в полном отсутствии активности, очистите все связанные ссылки на удаленный компонент.

Упрощение функций Azure

Azure Pipelines и GitHub Actions поддерживают многоэтапные развертывания, используя шлюзы одобрения, которые помогут вам разработать стратегию постепенного развертывания.
Используйте слоты для промежуточных версий службы приложений Azure, чтобы легко переключаться между версиями кода. Слоты для промежуточного этапа полезны для тестирования в промежуточных средах и могут использоваться для развертывания по модели blue-green.
Храните флаги функций веб-приложения и управляйте ими в Конфигурация приложений Azure. С помощью этой службы можно создавать, изменять и развертывать функции в единой плоскости управления.
Разверните рабочие приложения на виртуальной машине с помощью VM Applications.
Используйте балансировщики нагрузки Azure для реализации стратегий развертывания и раскрытия работоспособности ваших приложений рабочей нагрузки с помощью собственных ресурсов.
Анализатор влияния правил Azure Network Watcher позволяет проверять предлагаемые изменения правил на основе шаблонов реального трафика до их применения, чтобы критически важные потоки трафика приложений и управления не были непреднамеренно заблокированы. Эта проверка снижает риск сбоев, вызванных развертыванием. Используйте это вместе с поэтапным развертыванием и планами отката, поскольку полнота анализа зависит от доступных данных о трафике.
Используйте расширение "Application Health" для отчета о состоянии приложений из экземпляра наборов виртуальных машин. Расширение проверяет конечную точку локального приложения и обновляет состояние работоспособности на основе ответов TCP/HTTP(S), полученных от приложения.
Используйте Azure Logic Apps для создания новой версии приложения при каждом обновлении. Azure поддерживает журнал версий приложений и может вернуть или повысить уровень до любой предыдущей версии.
Функции Azure Flex Consumption постепенно заменяет экземпляры при обновлении, что может уменьшить перебои во время поэтапного развертывания. Считайте такое поведение мерой по ограничению области воздействия, а не заменой проверки зависимостей, тренировок по откату и тестирования совместимости версий.
Многие службы баз данных Azure предоставляют функции восстановления на заданный момент времени, которые позволят вам откатить изменения. К службам, поддерживающим восстановление на определенный момент времени, относятся:

Пример

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

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

Контрольный список операционного превосходства

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

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

Обратная связь

Были ли сведения на этой странице полезными?

Last updated on 2026-02-11