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

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

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

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

  • Реализация методологии "Все как код" (EaC) позволяет командам разблокировать ключевые преимущества, создавать сильную культуру разработки и предоставлять возможность всем участникам каждой команды проверять, каким образом и какие ресурсы развертываются. EaC также помогает командам платформы внедрять ключевые методики разработки, которые повышают гибкость и эффективность. Ваши команды могут отслеживать изменения и контролировать, какие из них перемещаются в рабочую среду, сохраняя код в репозиториях и используя системы управления версиями для его администрирования.
  • Команды могут следовать принципу 4-х глаз и использовать парное программирование или проверку кода коллегами, чтобы гарантировать, что изменения в коде никогда не вносятся самостоятельно. Одноранговое программирование и пиринговая проверка повышают качество кода, позволяют командам делиться ответственностью за изменения и увеличивать знания команды о том, что согласовано и развернуто. Обзор кода — это фантастический способ для участников команды, чтобы узнать о новых методах и методах написания кода и автоматизации.
  • Команды должны использовать такие системы управления версиями, как Git, и Git-репозитории для проведения код-ревью. Репозитории Git позволяют командам определять важные ветви и защищать их с помощью политик ветвей. Вы можете использовать политику, чтобы требовать изменения кода в этих ветвях для удовлетворения определенных критериев, таких как минимальное количество утверждений участников группы, прежде чем они смогут объединиться в защищенную ветвь.
  • Команды должны соединять методологию EaC и процесс проверки изменений с процессом непрерывной интеграции и непрерывной доставки (CI/CD). Каждое изменение кода должно автоматически активировать процесс CI, который выполняет статический анализ кода, проверку и тестовые развертывания. CI гарантирует, что разработчики рано проверяют свой код на наличие ошибок (часто это называют быстрым обнаружением ошибок или тестированием на более ранних этапах), которые могут вызвать будущие проблемы. В зависимости от того, какую стратегию ветвления использует ваша команда, изменения в любой важной ветви должны активировать развертывание в разных средах. После утверждения и объединения изменений в main процесс CI/CD развертывает эти изменения в рабочей среде. Эта система управления кодом предоставляет команде один источник истины для того, что выполняется в каждой среде.
  • Чтобы гарантировать, что ваша платформа полностью самовосстановляется и предоставляет самообслуживание для команд по рабочим нагрузкам, команда вашей платформы должна автоматизировать всё (часто называемое крайней автоматизацией): от предоставления услуг, настройки и управления платформой до предоставления подписки зоны целевого назначения для команд по рабочим нагрузкам. Крайняя автоматизация позволяет вашей команде платформы сосредоточиться на предоставлении ценности, а не на развертывании, настройке и управлении платформой. Экстремальная автоматизация также создает самоусиливающийся цикл, который дает вашей команде больше времени для создания дальнейшей автоматизации.
  • По мере того как команды платформы автоматизируют операционные действия и сокращают вмешательство человека, они должны переключить свое внимание на важные задачи, которые позволяют и ускоряют инновации группы рабочей нагрузки в Azure. Чтобы достичь этого, ваша команда платформы должна проводить несколько итераций циклов создания и разработки, в то время как они внедряют инструменты вашей платформы, скрипты и усовершенствования функциональных возможностей.
  • Для вашей команды доступны различные варианты, чтобы приступить к развертыванию стартовой зоны Azure. Эти параметры зависят от текущих возможностей вашей команды и могут расти по мере развития вашей команды. В частности, для развертывания платформы можно выбрать опции на основе портала, Bicep или Terraform, в зависимости от навыков использования инфраструктуры как кода (IaC) и предпочтений команд по инструментам.
    • Новые и развивающиеся команды платформ, которые только начинают знакомиться с IaC и используют портал для развертывания и управления ресурсами, могут воспользоваться акселератором зоны приземления Azure. Этот акселератор поддерживает команды, которые в настоящее время используют подход ClickOps . ClickOps — это процесс подготовки, настройки и управления ресурсами, щелкая через порталы, консоли управления и мастеров. Этот акселератор позволяет команде использовать портал в качестве начального средства развертывания. По мере роста зрелости разработки платформы ваша команда может постепенно включить Azure CLI, PowerShell или IaC.
    • Решение AzOps позволяет командам развивать свои методики автоматизации и управления платформой, переходя от ClickOps к возможностям DevOps. Ваша команда может перейти от использования личного доступа к использованию принципов и методик DevOps, основанных только на CI/CD с AzOps и IaC. AzOps позволяет вашей команде использовать собственную архитектуру, использовать архитектуру, развернутую акселератором портала целевой зоны Azure (после первоначального развертывания на основе портала, так как интеграция AzOps не является частью интерфейса портала ALZ), интегрироваться с развертыванием браунфилда или использовать пользовательские шаблоны (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, документации, развертывания и тестирования.
  • Используйте управление версиями для управления всеми репозиториями кода, включая:
    • Инфраструктура как код
    • Политика как код
    • Настройка в качестве кода
    • Развертывание в виде кода
    • Документация как код
  • Реализуйте принцип четырёх глаз и процесс парного программирования или парной проверки чтобы убедиться, что все изменения кода проверяются вашей командой перед развертыванием в рабочей среде.
  • Примите стратегию ветвления для команды и задайте политики ветви для ветвей, которые вы хотите защитить. С политиками ветви команды должны использовать запросы на вытягивание для внесения изменений в слияние.
  • Используйте непрерывную интеграцию и непрерывную доставку (CI/CD), чтобы автоматизировать тестирование кода и развертывание в разных средах.
  • Чтобы автоматизировать все, например, подготовку, настройку и управление вашей платформой, а также создание подписок на целевую зону для команд рабочих нагрузок.
  • Используйте один из доступных акселераторов, которые соответствуют возможностям вашей команды, чтобы приступить к развертыванию целевых зон Azure.
  • Планируйте использовать многоуровневый подход к развертыванию для добавления возможностей, которые не охватываются акселератором, но необходимы для полной поддержки команд рабочей нагрузки.
  • Создайте процесс использования кода для реализации быстрых исправлений. Всегда регистрируйте быстрые исправления в невыполненной работе вашей команды, чтобы каждое исправление можно было переработать позже, а также чтобы вы могли ограничить технический долг.
  • Использование инфраструктуры в качестве кода для развертывания политик Azure и управления ими (часто называемых политиками как код)
  • Реализуйте процесс исключения для политик. Запланируйте, чтобы команды с рабочей нагрузкой могли запрашивать освобождение от политик, и будьте готовы снять ограничения с команд по мере необходимости.
  • Используйте "Управление на основе политик", чтобы заблокировать группы рабочих нагрузок при попытке развернуть ресурсы, которые не соответствуют контролю безопасности. Это помогает уменьшить смещение конфигурации, где код объявляет другое состояние, чем то, что в конечном итоге развертывается.

Подробнее