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

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

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

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

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

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

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

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

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

Важно!

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

Развертывание с нулевым временем простоя

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

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

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

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

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

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

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

Ниже приведены некоторые распространенные рекомендации.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Примечание

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

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

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

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

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

  Примечание

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

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

Рабочих сред

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

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

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

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

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

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

Временные сине-зеленые развертывания

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  Важно!

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

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

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

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

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

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

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

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

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

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

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

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

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

ИИ для DevOps

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

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

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

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

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

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

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

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

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

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

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

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

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

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