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

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

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

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

Определение

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

Применение строгой политики автоматизированных развертываний на основе шаблонов

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

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

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

Развертывание повторяемой и неизменяемой инфраструктуры в виде кода

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

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

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

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

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

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

Использование одного набора артефактов развертывания во всех средах

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

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

Отражение организационной структуры в цепочке поставок

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

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

Выбор правильного метода развертывания

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

Используйте подход с постепенным расширением воздействия, например канареечные развёртывания, чтобы снизить риск того, что до клиентов дойдут незамеченные ошибки. Разверните изменения в небольших контролируемых группах на этапах, чтобы обнаружить проблемы до широкого выпуска. Начальная группа развертывания может быть группой клиентов, которые осведомлены о стратегии развертывания. Этот подраздел клиентов может терпеть некоторое количество непредвиденного поведения и предоставлять отзывы. Или это может быть группа внутренних пользователей, которая помогает ограничить влияние ошибок во время развертывания.

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

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

Выполните многоуровневый подход

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

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

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

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

Включение комплексных типов тестирования

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Реализация шлюзов качества в процессах продвижения кода

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

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

Возможности ИИ: Устраняйте узкие места при проверке, автоматически направляя PR нужным профильным экспертам (SMEs). Начните с использования Copilot, чтобы оценить масштаб и влияние. Затем добавьте интеграцию агента CI/CD для оценки изменений кода, конфигураций и шаблонов утверждения. Предоставьте доступ с минимальными привилегиями только к необходимым артефактам, таким как репозитории, конвейеры, данные конфигурации, история инцидентов и журналы согласований. С помощью этого доступа можно оценить влияние, назначить рецензентов, определить узкие места и рекомендовать автоматическое утверждение или дополнительную проверку. Для рабочих нагрузок с высоким уровнем ценности обучить исторические данные для прогнозирования рисков развертывания и результатов утверждения. Участвуйте людей в процессе и будьте осторожны с автоматическим утверждением.

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

Azure DevOps — это коллекция служб, которые помогают создавать совместную, эффективную и согласованную практику разработки.

Azure Pipelines предоставляет службы сборки и выпуска для поддержки CI/CD в ваших приложениях.

GitHub Actions для Azure интегрируется с Azure для упрощения развертываний. Используйте GitHub Actions для автоматизации процессов CI/CD. Вы можете создавать рабочие процессы, которые будут создавать и тестировать каждый пулл-реквест в ваш репозиторий или развертывать объединенные пулл-реквесты в продакшен.

Для развертываний IaC можно использовать Terraform, Bicep и Azure Resource Manager. В зависимости от ваших требований и знакомства с инструментами ваша команда может использовать один или несколько этих средств для развертываний и управления ресурсами.

Пример

Для примера, демонстрирующего, как использовать Azure Pipelines для создания конвейера CI/CD, смотрите Базовую архитектуру Azure Pipelines.

Дополнительные ссылки

• Azure DevOps
• Azure Pipelines
• Шаблон меток развертывания
• Действия GitHub для Azure
• Основной компонент эффективности производительности
• Опора надежности
• Основные принципы безопасности

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

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