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

  • Статья

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

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

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

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

Определение

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

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

Примечание

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

Основные принципы

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    Цель этого теста main заключается в оценке соответствия системы бизнес-требованиям и определении соответствия системы требуемым критериям доставки конечным пользователям.

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

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

Упрощение 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.

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

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

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