Оценка рабочих нагрузок для миграции в облако

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

Оценка архитектуры рабочей нагрузки

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

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

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

3. Архитектура документа. Храните схемы архитектуры, списки компонентов и данные конфигурации в формате, поддерживающем планирование и проверку. Используйте такие средства, как Microsoft Visio, электронные таблицы или вики-сайты Azure DevOps для поддержания этой информации.

Оценка компонентов рабочей нагрузки

Для каждой рабочей нагрузки собираются подробные базовые метрики производительности и использования из текущей среды. Эти данные критически важны для правильного изменения размера ресурсов Azure и сравнения производительности после миграции

1. Сбор метрик рабочей нагрузки. Отслеживайте использование ЦП, памяти, операций ввода-вывода на дисках (чтение/запись, IOPS), сетевую пропускную способность и пиковую конкурентную нагрузку или пользовательскую нагрузку. Определите ежедневные или еженедельные пики, чтобы понять потребности в емкости. Измеряйте среднее время отклика для транзакций пользователей, пропускную способность заданий, обрабатываемых в час, и любые метрики, связанные с соглашением об уровне обслуживания. Это помогает обеспечить соответствие перенесенных рабочих нагрузок одинаковым требованиям к производительности бизнеса.

2. Сбор сведений о конфигурации. Обратите внимание на конфигурации масштабирования, текущие размеры виртуальных машин или спецификации физических серверов (ядра ЦП, ОЗУ), тип ос и версия, тип хранилища (SSD/HDD) и емкость и любое специальное оборудование, например GPU. Эти сведения сообщают о выборе размеров виртуальных машин Azure или служб PaaS. Также запишите сведения о лицензировании программного обеспечения, так как это может включать использование гибридного преимущества Azure или требовать миграцию лицензий.

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

   Компонент безопасности	Action	Purpose
   Инвентаризация удостоверений	Запись всех учетных записей служб, учетных записей пользователей и ключей API, используемых приложениями для проверки подлинности	Влияет на порядок миграции при выборе между подходом lift-and-shift или модернизацией
   Документация по шифрованию	Задокументировать текущие методы шифрования для данных в состоянии покоя и данных в процессе передачи	Сопоставите эти требования со службами шифрования Azure для поддержания стандартов безопасности
   Конфигурация безопасности сети	Запись правил безопасности сети, конфигураций брандмауэра и списков управления доступом	Используйте эти сведения для разработки групп безопасности сети Azure и политик доступа

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

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

Сопоставление внутренних и внешних зависимостей

1. Установите внутренние зависимости. Опишите, как компоненты рабочей нагрузки взаимодействуют друг с другом и с иными системами в вашей организации. Используйте средства мониторинга сети или мониторинг производительности приложений для просмотра подключений среды выполнения между службами. Это сопоставление помогает определить группирование в волнах миграции. Например, если приложение A постоянно вызывает Базу данных B, их можно перенести вместе или обеспечить сетевое подключение между Azure и исходной средой, пока они не находятся в облаке.

2. Определите все внешние зависимости. Вывод списка внешних служб, с которыми взаимодействует рабочая нагрузка. Эти зависимости включают платформы SaaS, api-интерфейсы партнеров, локальные системы и сторонние службы, необходимые для правильной работы приложений. Чтобы понять все зависимости, необходимо каталогизировать все вышестоящие и нижестоящие интеграции, общие службы и конвейеры данных. API документов, системы обмена сообщениями, процессы ETL, общие базы данных, методы проверки подлинности, шаблоны обмена данными и соглашения на уровне обслуживания. Просмотрите документацию по интеграции и провести интервью с владельцами приложений, чтобы обеспечить полную видимость всех внешних подключений. Это комплексное сопоставление предотвращает сбои интеграции и поддерживает точную последовательность миграции.

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

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

5. Используйте зависимости для планирования миграции. Организуйте рабочие нагрузки в волны миграции, чтобы минимизировать нарушенные зависимости. Подробнее см. "Планирование волн миграции".

Оценка соответствия и операционных требований

1. Определите требования к соответствию нормативным требованиям. Четкое понимание требований соответствия нормативным требованиям гарантирует соответствие архитектуры Azure юридическим, отраслевым и организационным обязательствам. Эти требования влияют на выбор регионов, доступность служб, защиту данных и архитектурные решения. Нормативные и стандарты соответствия включают глобальные, региональные, отраслевые и внутренние политики. Эти стандарты могут включать GDPR, HIPAA, FedRAMP, ISO 27001 или финансовые правила, такие как SOX. Каждый стандарт предъявляет определенные требования к обработке данных, управлению доступом, шифрованию и аудиту. Необходимо определить все применимые стандарты для каждой рабочей нагрузки, проконсультировавшись с заинтересованными сторонами юридических, комплаенса и безопасности.

2. Документируйте соглашения об уровне обслуживания, RPO и ОСРВ. Соглашения об уровне обслуживания (СО), цели точки восстановления (RPO) и цели по времени восстановления (RTO) определяют допустимые уровни доступности и потерь данных. Эти метрики помогут разработать стратегии резервного копирования, репликации и отработки отказа. Эти значения необходимо задокументировать для каждой рабочей нагрузки, чтобы архитектура соответствовала ожиданиям непрерывности бизнес-процессов. См. раздел "Определение требований к надежности".

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

4. Проверьте интеграцию isV с Azure. Многие рабочие нагрузки зависят от программного обеспечения от независимых поставщиков (ISV). Перед миграцией необходимо убедиться, что все программное обеспечение ISV совместимо с Azure. Используйте документацию поставщика, тестовые среды или прямую проверку с ISV. Определите все необходимые обновления, замены или изменения конфигурации. Кроме того, определите, применяются ли гибридные преимущества Azure или другие модели лицензирования. Включите затраты на лицензирование и корректировки совместимости в план миграции для точного бюджетирования и планирования.

Оценка кода приложения

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

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

1. Используйте AppCAT для приложений .NET и Java.AppCAT предоставляет подробные оценки для рабочих нагрузок .NET и Java. Это средство определяет устаревшие API, неподдерживаемые пакеты SDK и проблемы конфигурации, которые могут предотвратить успешную миграцию. Используйте AppCAT для создания рекомендаций по совместимости и модернизации для этих рабочих нагрузок.

2. Используйте сторонние средства для других языков приложений. Такие средства, как CloudPilot и CAST Highlight, поддерживают такие языки, как Python, JavaScript, Node.jsи Go. Эти средства определяют изменения на уровне кода, необходимые для совместимости Azure, и предоставляют аналитические сведения о модернизации. Используйте эти средства для оценки non-.NET и рабочих нагрузок, отличных от Java.

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

Проверка совместимости платформы и пакета SDK

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

2. Проверьте поддержку Azure для языка и платформы приложения. Убедитесь, что Azure поддерживает версию .NET, Java, Python, JavaScript, Node.jsи Go. Используйте официальную документацию Azure для проверки совместимости.

3. Избегайте ненужных изменений платформы. Переход на новую платформу (например, с .NET Framework на .NET Core) должен осуществляться только при наличии веского бизнес-обоснования. Изменения платформы требуют значительных усилий по разработке и тестирования.

Оценка баз данных

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

1. Определите все базы данных, используемые приложением. Создайте полную инвентаризацию всех баз данных, используемых приложением. Включите типы ядра СУБД (SQL Server, MySQL), версии и модели размещения (например, локальные, IaaS, PaaS). Используйте такие инструменты, как Azure Migrate, для систематического сбора этой информации. Укажите, является ли база данных локальной, размещенной на виртуальных машинах или доставлена в качестве управляемой службы. Эта информация помогает определить готовность к миграции и совместимость целевой платформы.

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

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

Создание и обслуживание регистра рисков

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

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

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

Дополнительные сведения см. в разделе CAF Govern — Оценка облачных рисков

Ресурсы и средства Azure

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