Планирование среды Azure для оценки затрат

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

Планирование архитектуры Azure

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

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

2. Спланируйте архитектуру целевой зоны Azure. Зона запуска предоставляет общие службы и фундамент управления и политики для всех рабочих нагрузок. Эта архитектура обеспечивает точную оценку затрат на уровне платформы и готовности к эксплуатации.

   • Используйте целевую зону Azure в качестве основы для архитектуры платформы. Зоны приземления Azure предоставляют масштабируемую и безопасную основу для корпоративных сред. К ним относятся критически важные компоненты, такие как удостоверения, сети и элементы управления. Используйте инструкции в статье "Что такое целевая зона Azure?".

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

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

Выберите соответствующие службы Azure

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

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

3. Выберите управляемые службы для облачных рабочих нагрузок. Предложения платформы как услуги (PaaS) снижают операционные издержки путем абстрагирования управления инфраструктурой. Эти службы повышают масштабируемость, безопасность и надежность при минимизации административных усилий. Выберите управляемые службы для новых или модернизованных рабочих нагрузок, если для обеспечения соответствия требованиям, производительности или совместимости не требуется управление уровнем инфраструктуры. Для рекомендаций по облачно-нативному дизайну, см. раздел CAF Cloud-native для облачно-нативных рекомендаций.

4. Согласуйте выбор службы в соответствии с вашей стратегией миграции. Подход к миграции определяет наиболее подходящие службы Azure. Для сценариев переноса на другую платформу выберите службы, которые соответствуют вашим текущим компонентам. Для переплатформирования или перепроектирования важно отдавать приоритет решениям PaaS, которые поддерживают цели модернизации. При переходе с другого поставщика облачных служб используйте сопоставление служб Amazon Web Services (AWS) для Azure или Google Cloud для сопоставления служб Azure для поиска нужных служб.

Выберите соответствующий уровень служб

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

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

   • Просмотрите требования к компоненту архитектуры, собранные на этапе оценки.
   • Сопоставьте требования к ЦП, памяти, хранилищу и IOPS с доступными SKU.
   • Определите все необходимые функции, доступные только в SKU более высокого уровня, даже если потребности в производительности указывают на более низкий уровень.

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

   • Оцените одновременное использование пользователями, объем транзакций и требования к задержке.
   • Выберите номер SKU, соответствующий этим целевым объектам, и проверьте его с помощью тестирования производительности.
   • Настройте номер SKU на основе результатов теста для оптимизации затрат и производительности.

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

   • Просмотрите параметры доступности службы и соглашения об уровне обслуживания.
   • Выберите SKU, поддерживающие зональную избыточность или переключение на региональный резерв.
   • Убедитесь, что выбранный уровень соответствует целям времени восстановления (ОСРВ) и целевым точкам восстановления (RPOS).

Определение стратегии регионального развертывания для каждой рабочей нагрузки

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

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

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

3. Проверьте соответствие нормативным и отраслевым стандартам. Убедитесь, что архитектура развертывания и конфигурации резервного копирования соответствуют применимым требованиям соответствия, таким как MARS-E, HIPAA или GDPR. Много региональные развёртывания могут привести к проблемам с размещением данных или вопросами суверенитета. Обратитесь к группе соответствия требованиям, чтобы убедиться, что ваша региональная стратегия соответствует юридическим и нормативным обязательствам.

Оценка затрат на основе архитектуры

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

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

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

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

Оценка операционных затрат для целевой модели службы

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

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

Повторное вычисление оценок затрат при отклонении прогнозов

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

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

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

Проверка допущений с помощью тестовых развертываний

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

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

Создание базовых показателей затрат

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

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

Следующий шаг