Объединенные гибридные и многооблачные операции

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

Краткое руководство. Гибридные и многооблачные службы Azure

Мы объясним, как решения Azure Arc, Azure Monitor, Служба Azure Kubernetes, Microsoft Fabric, Azure IoT и Azure Local, помогают объединить управление и модернизировать ИТ-службу во всех средах. Цель заключается в создании стандартной операционной модели, которая разбивает силосы и обеспечивает согласованные методики везде. Мы подробно рассмотрим, как защитить, управлять и модернизировать ресурсы из облака в edge, объединяя ранее изолированные команды и системы в рамках одной стратегии на основе Azure.

Первым шагом является создание четкой стратегии гибридной и многооблачной среды, которая соответствует вашим бизнес-целям и подчеркивает объединение. Это выравнивание обеспечивает бизнес-ценность (гибкость, устойчивость, оптимизацию затрат, инновации), определяющую вашу облачную стратегию, а не случайные решения. Ключевые действия на этом этапе включают определение драйверов и визуального зрения, настройку руководящих принципов, определение облачного набора и сопоставление служб Azure с целями.

1. Определение бизнес-драйверов для гибридной и многооблачной среды

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

• Гибкость поставщика. Уменьшите зависимость от любого отдельного поставщика, чтобы снизить риск зависимости и позволить оптимизацию затрат и оптимальное использование услуг. Например, избегайте полагаться исключительно на функции одного облака, если альтернатива может сэкономить затраты или предложить уникальные возможности.
• Разнообразие бизнес-подразделений: размещение различных команд, приобретений или дочерних компаний, использующих различные платформы. Единая стратегия предотвращает операционные оси и устанавливает централизованное управление во всех средах при уважении существующих инвестиций.
• Соответствие требованиям и местонахождение данных. Соблюдение нормативных требований для суверенитета данных или конкретных элементов управления безопасностью. Используйте Azure Local, в составе которого теперь находится Azure Stack HCI, для рабочих нагрузок, которые должны оставаться на локальных серверах. Подключитесь к облачным службам Azure для других данных и приложений.
• Устойчивость и аварийное восстановление. Повышение доступности путем распределения рабочих нагрузок и создания отработки отказа в нескольких средах. Устойчивость поддерживает операцию во время локализованных сбоев; аварийное восстановление восстанавливает обычные операции после более широких инцидентов. Проектирование восстановления между Azure и дополнительными средами (другими облаками или локальной средой) с помощью унифицированных процессов, чтобы обеспечить минимальное время простоя.
• Оптимизация производительности. Поместите рабочие нагрузки ближе к пользователям или источникам данных, чтобы уменьшить задержку. Например, разверните локальные экземпляры Azure в расположениях фабрики для обработки в режиме реального времени, сохраняя централизованную координацию с помощью облачных служб Azure.
• Модернизация и инновации. Использование специализированных облачных служб для преобразования. Например, используйте службы ИИ Azure и аналитику Microsoft Fabric при интеграции данных и приложений в других облаках по мере необходимости.
• Объединение силосов: устранение внутренних силосов между инфраструктурой, облаком и командами приложений. Создайте общие средства и процессы, такие как Azure Arc для управления ресурсами, Azure Monitor для наблюдения, чтобы создать общую видимость и совместную работу между ранее изолированными группами.

Для каждого бизнес-драйвера свяжите его с определенным бизнес-результатом или ключевым показателем эффективности. Например, если драйвер "избегает простоя", результат может достичь доступности 99,99%. Если "поддержка глобального расширения" является драйвером, результат может быть запущен в некоторых новых географических регионах в течение года. Если объединение силосов является целью, результат может быть 20% сокращение эксплуатационных накладных расходов путем объединения ИТ-процессов. Ориентация драйверов на результаты гарантирует, что стратегия направлена на обеспечение измеримой стоимости. Задокументируйте эти драйверы и требуемые результаты четко, так как они будут управлять всеми последующими решениями.

2. Создание четкого заявления о видении для гибридной и многооблачной среды

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

• "Создайте адаптивную облачную платформу, которая объединяет всю инфраструктуру и команды, позволяя любому приложению работать, где он лучше всего соответствует бизнес-потребностям". (Подчеркивает гибкость и единство.)
• "Обеспечение согласованного взаимодействия с клиентами с 100% время простоя через многооблачную устойчивость". (Основное внимание уделяется надежности и непрерывности.)
• "Увеличьте частоту развертывания на 50% путем стандартизации DevOps в облаке и локальной среде". (Основное внимание уделяется повышению гибкости и процесса.)
• "Сократите локальный объем ресурсов на 50% за два года, чтобы сократить затраты, а также расширить управление облаком для всех оставшихся локальных ресурсов". (Подчеркивает эффективность и облачные операции.)

3. Установка метрик успешности для гибридной и многооблачной среды

Наряду с видением определите 2–5 ключевых показателей успеха (КПЭ) для измерения прогресса. Каждый основной драйвер из предыдущего шага должен соответствовать по крайней мере одному ключевому показателю эффективности. По возможности сделайте их конкретными и ограниченными по времени. Например, если гибкость является драйвером, ключевым показателем эффективности может быть сокращение времени на подготовку инфраструктуры с недель до часов во всех средах в течение 12 месяцев. Если оптимизация затрат является фактором, ключевой показатель эффективности может заключаться в улучшении использования инфраструктуры на 30% за счет использования облачных ресурсов и консолидации. Оцените затраты на данные при выходе и синхронизацию перед внедрением бурстинга. Включите также метрику безопасности или соответствия требованиям. Например, задайте цель так, чтобы 100% подключенных и в охвате ресурсов соответствовали базовым политикам безопасности, которые измеряются с помощью Azure Policy и Defender for Cloud.

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

4. Настройка принципов гибридной и многооблачной среды

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

1. Определите облачно-нейтральное и облако-специфическое использование. Определите, где вы хотите создавать облачные решения, не зависящие от конкретного облака, и использовать облачные нативные сервисы. Для каждой рабочей нагрузки определите, является ли переносимость критической. Например, для основных систем записей можно определить приоритет нейтралитета, используя такие технологии, как Служба Azure Kubernetes, контейнеры или базы данных, которые выполняются в любом месте. В отличие от этого, для проектов, ориентированных на клиентов или инноваций, можно использовать облачные службы PaaS, такие как Функции Azure, для ускорения разработки.

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

3. Оправдайте сложность использования нескольких облачных решений. Многооблачный подход может внести сложность, например, несколько наборов навыков, различные архитектуры и потенциально более высокие затраты, такие как затраты на передачу данных между облаками. Установите принцип, согласно которому использование другого облака должно иметь четкое обоснование. Используйте Azure по умолчанию для новых развертываний, если только уникальные возможности или бизнес-требования не требуют иного. Если используется дополнительное облако, интегрируйте его через Azure и периодически пересматривайте ее необходимость. Эта преднамеренная позиция позволяет избежать разрастания неуправляемых, разложенных развертываний на разных платформах. Если разработчик предлагает использовать другую технологию аналитики данных, они должны иметь сильную причину и запланировать ее интеграцию. В противном случае они должны использовать аналитические предложения Azure, такие как Microsoft Fabric.

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

5. Выберите облачное сочетание для гибридной и многооблачной среды

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

1. Выберите свой облачный портфель на основе требований. Оцените бизнес-и технические потребности, чтобы решить сочетание облачных платформ. Многие предприятия используют несколько общедоступных облаков для удовлетворения различных потребностей или устаревших инвестиций. Документируйте, какие платформы следует использовать и почему. Кроме того, определите, какую роль играет локальная инфраструктура. Например, вы можете использовать Azure для большинства рабочих нагрузок и поддерживать локальные системы для определенных систем управления фабрикой с помощью Azure Local. Быть конкретными. Определите критически важные рабочие нагрузки, которые должны оставаться в локальной среде, и планировать их модернизировать, размещая на платформе Azure Local и подключая к управлению через Azure Arc, а также определить любые исключительные случаи для других облаков. Убедитесь, что эта планируемая стратегия связана с вашими драйверами, например, использование вторичного облака для повышения устойчивости или специализированных возможностей.

2. Сделайте Azure основным уровнем управления для всех сред. Очевидно, что Azure должна служить главным центром для управления ресурсами во всех облаках и локальной среде. Это решение является стратегическим, так как Azure предлагает надежное гибридное управление с помощью Azure Arc и связанных служб. Проецируя ресурсы AWS, Google Cloud и локальные ресурсы в Azure для управления, вы централизуете свои знания и инструменты. На практике это означает, что вы должны управлять ресурсами AWS из Azure с помощью Arc, а не управлять ресурсами Azure из средств AWS. Межоблачные службы Azure (Arc, Microsoft Defender для облака, Azure Monitor) хорошо подходят для этой роли концентратора, обеспечивая интеграцию и согласованность.

3. Проектирование унифицированной операционной модели. Узнайте, как ИТ-операции должны функционировать в этой гибридной или многооблачной настройке. Определите процессы, которые работают во всех средах. Например, ваша политика должна предусматривать инвентаризацию всех серверов (виртуальных машин Azure, локальных серверов, AWS EC2). Они также должны быть настроены с помощью Azure Arc и управляются политикой Azure для ресурсов с поддержкой Azure и Arc. Для AWS или Google Cloud используйте мультиоблачные соединители Defender для облаков, чтобы определить состояние защищенности, поскольку соответствие достигается через мультиоблачные соединители Defender для облаков, а не через прямое назначение политик Azure. Конвейеры CI/CD следует использовать в GitHub Actions/Azure DevOps, развертывая приложения в любой целевой среде с помощью утвержденных шаблонов. Сетевые операции должны рассматривать Azure как концентратор, связывающий другие сайты и облака, и команда безопасности должна использовать Microsoft Sentinel для просмотра всего. Описывая эту целевую операционную модель, вы формируете ожидания, что унифицированные операции должны заменять изолированные структуры, такие как отдельные оперативные команды для каждого облака. Она готовит организацию к изменениям в повседневной работе и объясняет, как добиться согласованности.

4. Создайте унифицированные команды для поддержки кроссплатформенных операций. Наряду с технологией, спланируйте человеческий аспект. Создайте вспомогательные команды для обучения и поддержки команд, работающих с платформами и нагрузками. Включите участников из традиционных ИТ-отделов, облачных команд и безопасности. Обучите локальных ИТ-специалистов в Azure и облачных навыках, чтобы они могли управлять ресурсами в любой среде с помощью средств Azure. Этот подход показывает, что вы ожидаете совместную работу и перекрестное обучение. В некоторых случаях это может означать реорганизацию. Может быть, объединение отдельных облачных команд или централизованная платформа, которая обслуживает все бизнес-подразделения. Благодаря этому эта часть стратегии гарантирует, что структура организации поддерживает операционную модель.

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

6. Сопоставление гибридных и многооблачных служб Azure с целями

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

Документирование этого сопоставления гарантирует, что ваша стратегия включает конкретный план игры, ориентированный на Azure. Она также помогает определить пробелы в навыках и требованиях к инструментам на ранних этапах. Например, если вы планируете использовать Microsoft Fabric для аналитики, вы знаете, что вам нужны навыки интеграции данных и опыт Power BI. Если Azure Arc является центральным элементом, вы планируете обучение для ваших операционных команд по работе с Arc. Этот шаг преобразует стратегические намерения в конкретные службы Azure, которые реализуют их.

Результат стратегии

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

• Бизнес-драйверы и область: объединение ИТ-операций, требования к времени бесперебойной работы для мультиоблака, требования периферийных вычислений.
• Заявление о видении: Azure — это основная платформа и плоскость управления, интегрирующая другие облака и локальные системы, чтобы обеспечивать единую, гибкую цифровую инфраструктуру.
• Метрики успеха: конкретные целевые показатели доступности, скорости развертывания, экономии затрат и соответствия требованиям.
• Руководящие принципы: позиции по предотвращению блокирования привязки, использование Azure по умолчанию, а также облачных нейтральных конструкций там, где это необходимо.
• Облачная смесь: какие среды используются (Azure, локальная инфраструктура через Azure Local, другие облака) и почему.
• Ключевые технологии: Azure и любые службы, отличные от Azure, решили выполнить стратегию.

Чтобы проиллюстрировать, ниже приведен пример фрагмента стратегии:

• Пример сводки стратегии. Организация проводит адаптивный гибридный и мультиоблачный подход для объединения ИТ-операций при использовании лучших облачных возможностей для каждой необходимости.
• Драйверы: избегайте простоя (целевой < 1 час/год). Соблюдайте законы о местонахождении данных ЕС. Разбить операционные блоки для повышения эффективности (целевой показатель — сокращение операционных расходов на 20%).
• Видение. Azure — это наше основное облако и плоскость управления, интегрирующая все остальные среды. Мы должны улучшить глобальное покрытие с помощью Azure плюс одного дополнительного облака и локального облака Azure для локальных потребностей.
• Принципы облака: Используйте нативные службы Azure для достижения отличия и скорости. По умолчанию выполнять новые развертывания в Azure, если только веские требования не диктуют иное.
• Облачная смесь: в настоящее время около 50% локальной среды для модернизации с помощью Azure Local, 40% Azure, 10% AWS для конкретного варианта использования. Долгосрочная цель: 70% Azure, с оставшимися локальными системами, работающими через Azure Local, и только нишевое использование других облаков.
• Ключевые технологии Azure: Azure Arc для объединения управления ресурсами. Azure Monitor и Defender для комплексной видимости и безопасности. Расширение облака Azure на локальные ресурсы. AKS для контейнеров. Microsoft Fabric для объединения аналитики данных. Azure IoT для устройств периферии. Entra ID для единой идентификации. Стандартизованные Azure Pipelines для всех развертываний. Мы должны измерять успех благодаря нашей способности удовлетворять целевые показатели частоты работы и развертывания, сохраняя строгое соответствие безопасности на всех платформах.

Утверждение этого стратегического документа заинтересованными сторонами гарантирует, что все согласованы перед переходом. Теперь вы можете перейти к подробному планированию с помощью надежного плана игры, ориентированного на Azure.

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