Поделиться через

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

  • Статья

Применяется к этой контрольной рекомендации по операционному превосходству в 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.

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

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

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

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

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

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

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

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

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

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

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

Упрощение функций 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.

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

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

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