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

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

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

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

1. Используйте средства оценки. Такие средства, как Миграция Azure или другие продукты, автоматизируют обнаружение компонентов и конфигураций рабочей нагрузки. Эти средства сокращают затраты ручного труда и обеспечивают согласованный сбор данных в вашем окружении, хотя могут пропустить незадокументированные зависимости. Для создания схем можно использовать средство, например 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 и другие средства оценки, могут обнаруживать эти проблемы в среде без проверок конфигурации вручную.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. Используйте средство модернизации приложений GitHub Copilot (.NET и Java).Модернизация приложений GitHub Copilot предоставляет подробные оценки рабочих нагрузок для .NET и Java. Она объединяет возможности оценки AppCAT с помощью помощи на основе искусственного интеллекта Copilot, чтобы ускорить модернизацию и упростить ее. Эта интеграция выступает в качестве партнера по программированию, помогая вам:

   • Учёт зависимостей приложения
   • Изменение и оптимизация исходного кода для служб Azure
   • Обновление кода и устранение общих уязвимостей и угроз (CVEs)
   • Контейнеризация приложений для гибкого развертывания
   • Создание файлов развертывания для упрощения миграции
   • Сокращение усилий с помощью программирования с помощью искусственного интеллекта

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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