Share via

автоматизация

  • Статья

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

Рекомендации по автоматизации платформы

  • Реализация методологии "Все как код" (EaC) позволяет вашим командам получить ключевые преимущества, создать сильную культуру разработки и позволить всем участникам каждой команды узнать, как и какие ресурсы развертываются. EaC также помогает командам платформы применять ключевые методики разработки, которые повышают их гибкость и эффективность. Ваши команды могут отслеживать изменения и контролировать, какие из них будут перенесены в рабочую среду, используя код в репозиториях и используя системы управления версиями для управления им.
  • Команды могут следовать принципу "4 глаза" и использовать одноранговый программирование или рецензирование , чтобы гарантировать, что изменения в коде никогда не вносятся в одиночку. Одноранговое программирование и рецензирование повышают качество кода, позволяют командам делить ответственность за изменения и расширять знания команды о том, что согласовано и развернуто. Обзор кода — это отличный способ для участников команды изучить новые методы и методы программирования и автоматизации.
  • Teams должны использовать системы управления версиями, такие как Git, вместе с репозиториями Git, для принудительной проверки. Репозитории Git позволяют командам определять важные ветви и защищать их с помощью политик ветвей. Вы можете использовать политику, чтобы требовать изменения кода в этих ветвях в соответствии с определенными критериями, такими как минимальное количество утверждений участников группы, прежде чем они смогут объединиться в защищенная ветвь.
  • Командам следует связать методологию EaC и процесс проверки изменений вместе с процессом непрерывной интеграции и непрерывной поставки (CI/CD ). Каждое изменение кода должно автоматически запускать процесс CI, который выполняет статические развертывания анализа, проверки и тестирования кода. Ci гарантирует, что разработчики проверка свой код на раннем этапе (часто называемое быстрым тестированием сбоя или сдвига влево) на наличие ошибок, которые могут привести к проблемам в будущем. В зависимости от того, какую стратегию ветвления использует ваша команда, изменения в любой важной ветви должны активировать развертывание в разных средах. После утверждения изменений и их объединения в mainпроцесс cd развертывает эти изменения в рабочей среде. Эта система управления кодом предоставляет команде единый источник достоверных сведений о том, что выполняется в каждой среде.
  • Чтобы обеспечить полную самовосстановление платформы и обеспечить самообслуживание для ваших команд рабочей нагрузки, ваша команда платформы должна автоматизировать все (часто называемое экстремальной автоматизацией) от подготовки, настройки и управления платформой до подготовки подписки целевой зоны для групп рабочей нагрузки. Крайняя автоматизация позволяет команде платформы сосредоточиться на предоставлении ценности, а не на развертывании, настройке и управлении платформой. Экстремальная автоматизация также создает цикл самостоятельного улучшения, который дает вашей команде больше времени для создания дополнительной автоматизации.
  • Так как команды платформы автоматизируют операционные действия и сокращают вмешательство человека, они должны переключиться на важные задачи, которые позволяют и ускоряют инновации команды рабочей нагрузки в Azure. Чтобы достичь этого, ваша команда платформы должна пройти несколько циклов создания и разработки по мере реализации средств, сценариев и улучшений возможностей вашей платформы.
  • Существует несколько вариантов, которые помогут вашей команде приступить к развертыванию целевой зоны Azure. Эти параметры зависят от текущих возможностей команды и могут расти по мере развития команды. В частности, при развертывании платформы можно выбрать интерфейс на основе портала, Bicep или Terraform в зависимости от навыков и предпочтений IaC Teams.
    • Новые и новые команды платформы, которые по-прежнему знакомятся с инфраструктурой как кодом (IaC) и более знакомы с использованием портала для развертывания ресурсов и управления ими, могут использовать для запуска акселератор целевой зоны Azure , который поддерживает команды, которые по-прежнему используют подход ClickOps . ClickOps — это процесс подготовки, настройки ресурсов и управления ими, щелкнув порталы, консоли управления и мастеры. Этот акселератор позволяет вашей команде использовать портал в качестве средства начального развертывания и постепенно, по мере роста зрелости разработки платформы, для дальнейшего использования Azure CLI, PowerShell или IaC.
    • Решение AzOps позволяет командам развивать свои методы автоматизации платформы и управления от ClickOps до DevOps. Ваша команда может перейти от использования своих личная учетная запись доступа к использованию принципов и методик DevOps, полагаясь только на CI/CD с AzOps и IaC. AzOps позволяет вашей команде принести собственную архитектуру, использовать архитектуру, развернутую акселератором портала целевой зоны Azure (после первоначального развертывания на портале, так как интеграция AzOps не является частью портала ALZ), интегрироваться с развертыванием с поддержкой brownfield или использовать пользовательские шаблоны (Bicep или ARM) для создания и ввода в эксплуатацию платформы.
    • Команды платформы с установленными навыками и возможностями могут применять кодифицированный подход, который соответствует принципам и методикам DevOps. Ваша команда должна в значительной степени основываться на IaC и современных методах разработки, переходя от использования доступа Azure в личных учетных записях и от выполнения всех операций через конвейер CI/CD. Чтобы ускорить этот переход, ваша команда должна использовать ускорители на основе IaC, такие как ALZ-Bicep или модуль Terraform целевых зон Azure .
  • Акселераторы на основе IaC имеют ограниченные область управления. Новые версии предоставляют больше возможностей и расширенные возможности управления ресурсами. При использовании акселератора вашей команде следует рассмотреть многоуровневый подход, который начинается с ускорителя, а затем добавляет уровень автоматизации. Уровень автоматизации предоставляет возможности, необходимые вашей команде для полной поддержки рабочих нагрузок с помощью функций платформы, таких как развертывание контроллера домена для устаревших приложений.
  • Когда команда платформы переходит на подход DevOps, ей необходимо создать процесс обработки экстренных исправлений. Они могут использовать разрешения, соответствующие управление привилегированными пользователями (PIM), для запроса доступа для выполнения исправлений, а затем вернуть его в код, чтобы ограничить отклонение конфигурации, или использовать код для реализации быстрого исправления. Ваша команда всегда должна регистрировать быстрые исправления в своем невыполненной работе, чтобы они могли переработать каждое исправление позже и ограничить свой технический долг. Слишком большой технический долг приводит к замедлению в будущем, так как некоторый код платформы не полностью проверен и не соответствует рекомендациям и принципам командного программирования.
  • Вы можете использовать Политики Azure , чтобы добавить некоторую автоматизацию на платформу. Рассмотрите возможность использования IaC для развертывания Политик Azure и управления ими, которые часто называются политикой как кодом (PaC). Эти политики позволяют автоматизировать такие действия, как сбор журналов. Многие платформы PaC также реализуют процесс исключения, поэтому запланируйте для команд рабочей нагрузки запрос на исключения из политик.
  • Используйте управление на основе политик, чтобы сообщить командам рабочей нагрузки, когда они пытаются развернуть ресурсы, которые не соответствуют элементу управления безопасностью. Рассмотрите возможность развертывания политик с deny эффектом для этих ситуаций, что позволяет командам рабочей нагрузки также рассматривать все как код и избегать смещения конфигурации, когда код объявляет одно, а политика изменяет параметр во время развертывания. Избегайте использования modify эффектов, например, если команда рабочей нагрузки развертывает учетную запись хранения с supportOnlyHttpsTraffic = false определенным в своем коде modify , где политика меняется true на на во время развертывания, чтобы обеспечить ее соответствие. Это приводит к отклонению кода от того, что развертывается.

Рекомендации по проектированию автоматизации платформы

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

Дополнительные сведения