Развертывание и тестирование критически важных рабочих нагрузок в Azure

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

Развертывание и тестирование должны быть основой для всех операций приложений и инфраструктуры, чтобы обеспечить согласованные результаты для критически важных рабочих нагрузок. Будьте готовы к развертыванию еженедельно, ежедневно или чаще. Разработайте конвейеры непрерывной интеграции и непрерывного развертывания (CI/CD) для поддержки этих целей.

Стратегия должна реализовать следующее:

• Строгое предварительное тестирование. Обновления не должны вводить дефекты, уязвимости или другие факторы, которые могут поставить под угрозу работоспособность приложений.

• Прозрачные развертывания. В любое время можно развертывать обновления, не затрагивая пользователей. Пользователи должны продолжать взаимодействие с приложением без прерывания.

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

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

Эта область проектирования содержит рекомендации по оптимизации процессов развертывания и тестирования с целью минимизации простоя и поддержания работоспособности и доступности приложений.

Внимание

Эта статья является частью серии критически важных рабочих нагрузок Azure Well-Architected Framework. Если вы не знакомы с этой серией, рекомендуется начать работу с критически важной рабочей нагрузкой?

Развертывание без простоя

Просмотрите следующее видео для обзора развертывания без простоя.

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

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

Эталонные реализации критически важных для критически важных подключений и Azure иллюстрируют этот подход к развертыванию, как показано на этой схеме:

Среды приложений

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

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

Существуют некоторые распространенные аспекты.

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

• Все среды должны использовать инфраструктуру в качестве артефактов кода (IaC), таких как Terraform или шаблоны Azure Resource Manager (ARM).

Среды разработки

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

Рекомендации по проектированию

• Возможности. Более низкие требования к надежности, емкости и безопасности допустимы для сред разработки.

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

• Плотность. Командам требуется несколько сред для поддержки параллельной разработки функций. Они могут сосуществовать в одной подписке.

Рекомендации по проектированию

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

• Используйте автоматизированный процесс для развертывания кода из ветвь компонента в среду разработки.

Тестовые или промежуточные среды

Эти среды используются для тестирования и проверки. Многие циклы тестирования выполняются для обеспечения развертывания без ошибок в рабочей среде. Соответствующие тесты для критически важной рабочей нагрузки описаны в разделе "Непрерывная проверка и тестирование ".

Рекомендации по проектированию

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

• Жизненный цикл. Эти среды являются короткими. Они должны быть уничтожены после завершения проверки тестов.

• Плотность. Можно запускать несколько независимых сред в одной подписке. Кроме того, следует рассмотреть возможность использования нескольких сред в выделенной подписке.

Примечание.

Критически важные приложения должны подвергаться строгому тестированию.

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

Рекомендации по проектированию

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

• Создайте синтетическую нагрузку пользователя, чтобы обеспечить реалистичный тестовый случай для изменений в одной из сред.

  Примечание.

  Эталонная реализация "Критически важный для сети" содержит пример генератора нагрузки пользователя.

• Определите количество промежуточных сред и их целей в рамках цикла разработки и выпуска.

Рабочие среды

Рекомендации по проектированию

• Возможности. Требуются самые высокие уровни надежности, емкости и безопасности для приложения.

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

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

Рекомендации по проектированию

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

Эфемерные развертывания синего и зеленого цвета

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

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

Рекомендации по проектированию

• Возможности технологий. Воспользуйтесь встроенными функциями развертывания в службах Azure. Например, служба приложение Azure предоставляет вторичные слоты развертывания, которые можно переключить после развертывания. С помощью Служба Azure Kubernetes (AKS) можно использовать отдельное развертывание pod на каждом узле и обновить определение службы.

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

• Влияние на затраты. Существует дополнительная стоимость из-за двух параллельных развертываний, которые должны сосуществовать до завершения развертывания.

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

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

Рекомендации по проектированию

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

• Используйте глобальную подсистему балансировки нагрузки, например Azure Front Door, для оркестрации автоматического перехода трафика пользователей между голубыми и зелеными средами.

• Чтобы перейти трафик, добавьте зеленую конечную точку внутреннего сервера, которая использует низкий трафик к весу тома, например 10 процентов. Убедившись, что объем трафика в зеленом развертывании работает и обеспечивает ожидаемое работоспособность приложения, постепенно увеличивает трафик. При этом примените короткий период увеличения, чтобы поймать ошибки, которые могут не сразу быть очевидными.

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

  На этом этапе списание старой и неактивной синей среды. Для следующего развертывания повторите процесс с синим и зеленым обратным цветом.

Развертывание с областью подписки

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

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

Рекомендации по проектированию

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

  Внимание

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

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

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

Рекомендации по проектированию

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

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

Непрерывная проверка и тестирование

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

Просмотрите следующее видео, чтобы получить общие сведения о непрерывной проверке и тестировании.

В этом разделе основное внимание уделяется тестированию внешнего цикла. В нем описываются различные типы тестов.

Тест	Description
Модульное тестирование	Подтверждает, что бизнес-логика приложения работает должным образом. Проверяет общий эффект изменений кода.
Тестирование дыма	Определяет, доступны ли компоненты инфраструктуры и приложений и как ожидалось. Как правило, тестируется только один сеанс виртуального пользователя. Результатом должно быть то, что система отвечает ожидаемыми значениями и поведением. Распространенные сценарии тестирования дыма включают достижение конечной точки HTTPS веб-приложения, запрос базы данных и имитацию потока пользователя в приложении.
Тестирование пользовательского интерфейса	Проверяет, развернуты ли пользовательские интерфейсы приложений и что взаимодействие с пользовательским интерфейсом выполняется должным образом. Для управления автоматизацией пользовательского интерфейса следует использовать средства автоматизации пользовательского интерфейса. Во время теста пользовательского интерфейса скрипт должен имитировать реалистичный пользовательский сценарий и выполнить ряд шагов для выполнения действий и достижения предполагаемого результата.
Нагрузочное тестирование	Проверяет масштабируемость и операцию приложения путем быстрого увеличения нагрузки и (или) постепенно до достижения предопределенного порогового значения. Нагрузочные тесты обычно предназначены для определенного потока пользователя, чтобы убедиться, что требования приложения удовлетворяются определенной нагрузкой.
Стресс-тестирование	Применяет действия, которые перегружают существующие ресурсы, чтобы определить ограничения решения и проверить возможность системы восстановить правильно. Основной целью является определение потенциальных узких мест производительности и ограничений масштабирования. И наоборот, уменьшайте вычислительные ресурсы системы и отслеживайте, как она ведет себя под нагрузкой, и определите, может ли она восстановиться.
Тестирование производительности	Объединяет аспекты нагрузочного и стресс-тестирования, чтобы проверить производительность при нагрузке и установить поведение тестов для работы приложения.
Тестирование хаоса	Внедряет искусственные сбои в систему, чтобы оценить способ реагирования и проверить эффективность мер устойчивости, операционных процедур и устранения рисков. Завершение работы компонентов инфраструктуры, намеренное снижение производительности и введение ошибок приложений — это примеры тестов, которые можно использовать для проверки того, что приложение будет реагировать должным образом при выполнении сценариев.
Выполнение тестов на проникновение	Гарантирует, что приложение и его среда соответствуют требованиям ожидаемого состояния безопасности. Цель заключается в выявлении уязвимостей безопасности. Тестирование безопасности может включать сквозную цепочку поставок программного обеспечения и зависимости пакетов с проверкой и мониторингом известных распространенных уязвимостей и уязвимостей (CVE).

Рекомендации по проектированию

• Автоматизация. Автоматическое тестирование важно для своевременной и повторяемой проверки изменений в приложении или инфраструктуре.

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

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

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

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

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

Рекомендации по проектированию

Просмотрите следующее видео, чтобы узнать, как можно интегрировать тестирование устойчивости с конвейерами CI/CD Azure DevOps.

• Обеспечение согласованности путем автоматизации всех тестов на компонентах инфраструктуры и приложений. Интегрируйте тесты в конвейеры CI/CD для оркестрации и запускайте их, где это применимо. Сведения о вариантах технологии см. в разделе "Средства DevOps".

• Обработайте все артефакты теста как код. Они должны поддерживаться и управлять версиями вместе с другими артефактами кода приложения.

• Выровняйте соглашение об уровне обслуживания тестовой инфраструктуры с соглашением об уровне обслуживания для циклов развертывания и тестирования.

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

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

  Совет

  Azure Chaos Studio — это собственный набор средств экспериментирования хаоса. Средства позволяют легко проводить эксперименты хаоса и внедрять ошибки в службах Azure и компонентах приложений.

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

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

• Сканируйте и отслеживайте сквозную цепочку поставок программного обеспечения и зависимости пакетов для известных CVEs.

  • Используйте Dependabot для репозиториев GitHub, чтобы убедиться, что репозиторий автоматически обновляется с последними выпусками пакетов и приложений, от которые он зависит.

Инфраструктура в виде развертываний кода

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

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

Рекомендации по проектированию

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

• Автоматизация. Все развертывания должны быть полностью автоматизированы. Человеческие процессы подвержены ошибкам.

Рекомендации по проектированию

• Примените IaC, гарантируя, что все ресурсы Azure определены в декларативных шаблонах и поддерживаются в репозитории системы управления версиями. Шаблоны развертываются, а ресурсы подготавливаются автоматически из системы управления версиями с помощью конвейеров CI/CD. Мы не рекомендуем использовать императивные скрипты.

• Запретить операции вручную для всех сред. Единственное исключение — это полностью независимые среды разработчика.

Инструменты DevOps

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

Корпорация Майкрософт предоставляет два набора инструментов на основе Azure, GitHub Actions и Azure Pipelines, которые могут эффективно развертывать критически важные приложения и управлять ими.

Рекомендации по проектированию

• Возможности технологий. Возможности GitHub и Azure DevOps перекрываются. Их можно использовать вместе, чтобы получить лучшее из обоих. Распространенный подход заключается в хранении репозиториев кода в GitHub.com или GitHub AE при использовании Azure Pipelines для развертывания.

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

• Региональная доступность. С точки зрения максимальной надежности зависимость от одного региона Azure представляет операционный риск.

  Например, например, трафик распределяется по двум регионам: региону 1 и региону 2. Регион 2 размещает экземпляр инструментов Azure DevOps. Предположим, что в регионе 2 произошел сбой, и экземпляр недоступен. Регион 1 автоматически обрабатывает весь трафик и должен развертывать дополнительные единицы масштабирования, чтобы обеспечить хороший интерфейс отработки отказа. Но это не сможет быть в состоянии из-за зависимости Azure DevOps в регионе 2.

• Репликация данных. Данные, включая метаданные, конвейеры и исходный код, должны реплицироваться в разных регионах.

Рекомендации по проектированию

• Обе технологии размещаются в одном регионе Azure, что может ограничить стратегию аварийного восстановления.

  GitHub Actions хорошо подходит для задач сборки (непрерывная интеграция), но может не использовать функции для сложных задач развертывания (непрерывное развертывание). Учитывая широкий набор функций Azure DevOps, мы рекомендуем использовать его для критически важных развертываний. Однако вы должны сделать выбор после оценки компромиссов.

• Определите соглашение об уровне обслуживания доступности для средств развертывания и убедитесь в соответствии с более широкими требованиями к надежности приложений.

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

Стратегия ветвления

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

Рекомендации по проектированию

• Свести к минимуму доступ. Разработчики должны выполнять свою работу в feature/* и fix/* ветвях. Эти ветви становятся точками входа для изменений. Ограничения на основе ролей должны применяться к ветвям в рамках стратегии ветвления. Например, только администраторы могут создавать ветви выпуска или применять соглашения об именовании для ветвей.

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

Рекомендации по проектированию

• Определите приоритет использования GitHub для управления версиями.

  Внимание

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

• Активируйте автоматизированный процесс тестирования для проверки изменений кода до их принятия. Участники группы также должны просматривать изменения.

• main Рассматривайте ветвь как непрерывно перемещаемую и стабильную ветвь, которая в основном используется для тестирования интеграции.

  • Убедитесь, что изменения вносятся main только через PR. Используйте политику ветви для запрета прямых фиксаций.
  • Каждый раз при объединению mainpr в среду интеграции он должен автоматически запускать развертывание в среде интеграции.
  • Ветвь должна считаться стабильной main . Она должна быть безопасной для создания выпуска в main любой момент времени.

• Используйте выделенные release/* ветви, созданные из main ветви и используемые для развертывания в рабочих средах. release/* Ветви должны оставаться в репозитории и могут использоваться для исправления выпуска.

• Задокументируйте процесс исправления и используйте его только при необходимости. Создайте исправления в ветви для последующего объединения в fix/* ветвь выпуска и развертывания в рабочую среду.

ИИ для DevOps

Методологии AIOps можно применять в конвейерах CI/CD, чтобы дополнить традиционные подходы к тестированию. Это позволяет обнаруживать потенциальные регрессии или ухудшения состояния, а также позволяет развертываниям быть предварительно остановленными, чтобы предотвратить потенциальные негативные последствия.

Рекомендации по проектированию

• Объем данных телеметрии. Конвейеры CI/CD и процессы DevOps выдают широкий спектр данных телеметрии для моделей машинного обучения. Данные телеметрии варьируются от результатов тестирования и результатов развертывания до операционных данных о компонентах тестирования с составных этапов развертывания.

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

• Изменения развертывания. Изменения в развертывании должны храниться для автоматического анализа и корреляции с результатами развертывания.

Рекомендации по проектированию

• Определите данные процесса DevOps для сбора и анализа данных. Данные телеметрии, такие как метрики выполнения тестов и данные временных рядов изменений в каждом развертывании, важны.

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

• Внедрение рабочего процесса MLOps.

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

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

Следующий шаг

Ознакомьтесь с рекомендациями по обеспечению безопасности.

Безопасность