Общие облачные операции управления

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

Реализация общих операций управления

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

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

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

3. Создайте матрицу ответственности между платформой, рабочей нагрузкой и традиционными ИТ-командами. Матрица ответственности документирует владение службами, операциями и вспомогательными функциями в области технологий. Эта документация снижает неоднозначность и повышает подотчетность. Например, одна команда платформы может создавать многократно используемые модули инфраструктуры, а другая команда использует их для создания посадочных зон. Команды рабочей нагрузки управляют ресурсами и операциями, зависящими от рабочей нагрузки.

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

Создание возможностей платформы в качестве внутренних продуктов

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

Проектирование служб платформы в виде модульных и многократно используемых продуктов

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

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

   • Azure корпоративное управление (группы управления, политики, архетипы)
   • Вендор подписки
   • Сеть с концентраторами и периферийными устройствами
   • Внутренние модули инфраструктуры как кода (IaC), основанные на проверенных модулях Azure (AVM)
   • Средства для разработчиков, такие как внутренние платформы разработчиков (IDP)

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

Использование методик управления продуктами для развития возможностей платформы

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

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

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

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

   • Подключение к облаку
   • Поддержка облачной разработки и сборки
   • Облачная безопасность и управление
   • Управление удостоверениями и доступом
   • Сеть или подключение

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

Оптимизировать размер команд платформы для охвата необходимых навыков и обеспечения масштабируемости

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

1. Начните с команд "двух пицц" для поддержания гибкости и фокуса. Команда "two-pizza" обычно включает 6-10 членов, который является широко принятым эталоном для эффективного размера команды. Этот размер обеспечивает надежную совместную работу и быстрые циклы обратной связи. Избегайте более крупных команд, которые вводят сложность координации и сокращают скорость доставки.

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

   Role	Responsibilities	Размер команды
   Инженеры сети	Проектирование и управление облачными подключениями и гибридными сетями.	2
   Инженеры Infrastructure-as-Code (IaC) или DevOps	Автоматизация развертываний и управление конвейерами CI/CD.	2
   Инженеры по идентификации	Управление проверкой подлинности, авторизацией и управлением удостоверениями.	2
   Инженеры по безопасности	Применение политик безопасности, мониторинг угроз и обеспечение соответствия требованиям.	2

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

3. Инвестируйте в DevOps и IaC навыки, чтобы обеспечить автоматизацию и масштабируемость. Разработка возможностей DevOps и IaC между группами платформ. Инженеры платформы должны быть опытными в:

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

Дальнейшие шаги