Оптимизация затрат после миграции

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

Оптимизируйте перенесенные рабочие нагрузки с точки зрения затрат

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

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

Средства оптимизации затрат

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

Инструмент	Описание	Ресурс
Оптимизация ресурсов	Просмотрите метрики использования сервиса и откорректируйте их, чтобы они соответствовали требованиям рабочей нагрузки.	рекомендации по затратам помощника по Azure
Зарезервированные экземпляры виртуальных машин Azure	Зарезервированные экземпляры позволяют вам заключать обязательства по ресурсам в Azure, которые используются часто. Подумайте о резервировании экземпляров для рабочих нагрузок, которые всегда активны.	Управление резервированиями для ресурсов Azure Определение размера виртуальной машины Azure (ВМ) для максимального использования резервирования
Планы экономии Azure	Планы экономии Azure обеспечивают экономию до 65% по сравнению с оплатой по мере использования при фиксации расходов на фиксированный почасовой объем служб вычислений в течение одного или трех лет.	рекомендации по планам экономии Azure
Управление затратами	Управление затратами Майкрософт позволяет отслеживать затраты среды и управлять ими.	Управление затратами Рекомендации по резервированию в модуле Advisor
Платформа FinOps	FinOps — это дисциплина, которая объединяет принципы финансового управления с облачными технологиями и операциями, чтобы обеспечить организациям лучшее понимание своих облачных расходов.	Что такое FinOps?

Списание устаревших ресурсов

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

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

Продолжить мониторинг

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

Хотя ресурсы могут быть отключены, они по-прежнему могут использовать хранилище, сеть и другие ресурсы инфраструктуры. Если они снова включены, они могут вызвать непредвиденные проблемы, если только они не были удалены.

Отслеживайте следующие сигналы для ресурсов:

• вычисления: использование вычислительных ресурсов, таких как центральный процессор и оперативная память.
• хранилище: использование ресурсов, например ввод-вывод диска (I/O).
• Сетевые: использование сети ресурсов, включающее входящий и исходящий сетевой трафик с устройств. Например, проверьте ресурсы, использующие брандмауэры и подсистемы балансировки нагрузки для обмена данными.
• журналы: журналы Windows и приложений.
• другие сигналы: любые другие сигналы, которые вы использовали для мониторинга активов, когда они были размещены в предыдущей рабочей среде.

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

Тестирование окон и проверки зависимостей

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

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

Определение периода тестирования и обслуживания

• время низкого воздействия: определите время с низким влиянием в вашем окне тестирования. Выберите время, когда использование приложения находится на самом низком уровне.
• Очистить тестовые случаи. Определите четкие тестовые случаи, которые можно выполнить в окне тестирования, которое соответствует реальным действиям, выполняемым пользователями приложения. Эти действия не должны быть поверхностными, а вместо этого должны охватывать каждый используемый процесс. Вы можете повторно использовать тестовые случаи из миграции, если они у вас есть. Если у вас есть пользователи или другие участники группы, которые часто работают в приложении, попробуйте выполнить тесты.
• Расписание и обмен данными: Запланируйте окно обслуживания на всё доступное у вас время. Вы должны стремиться к минимуму четыре часа.
  • План: Спланируйте окно, чтобы пользователи приложений могли заранее подготовиться. Две недели разумны.
  • Сообщите: Заранее объявите об изменении. Задайте ожидание, что во время этого периода обслуживания может возникнуть сбой и что система может не реагировать. Пользователи не должны ожидать, что приложение будет доступно в течение этого времени.

До окна технического обслуживания

• Запустите тестовые случаи: Выполните тестовые случаи и мониторьте использование ресурсов.
  • При обнаружениииспользования не следует приступать к периодам обслуживания. Вместо этого следует изучить дополнительные сведения о том, используются ли ресурсы.
  • Если вы не обнаружилииспользования, вы можете перейти к периоду обслуживания.

Во время периода обслуживания

• Отключить ресурсы: Отключите ресурсы, помеченные для вывода из эксплуатации.
  • Выключите устройства, если они по-прежнему включены.
  • Удалите ресурсы из любых подсистем балансировки нагрузки и убедитесь, что они не могут отвечать на входящие запросы.
• Выполните тесты: Выполните тестовые сценарии для рабочей нагрузки, выполняющейся в Azure.
  • тесты успешно выполнены без сбоя: ресурсы не используются в настоящее время.
    • Передайте конец окна изменений, чтобы пользователи знали, что они могут ожидать стабильности в приложении снова.
    • Перейдите к следующему разделу после успешного выполнения тестов.
  • тесты не прошли: ресурсы могут использоваться на данный момент, и рекомендуется провести больше тестирования.
    • Повторно включите ресурсы, помеченные для вывода из эксплуатации, и повторите неудачные тестовые случаи.
    • Если тестовые случаи по-прежнему завершаются ошибкой, может возникнуть не связанная проблема. Вам нужно протестировать больше в течение периода обслуживания, а также начать эскалацию, чтобы убедиться, что у вас есть правильный уровень поддержки.
    • Если тестовые случаи перестают завершаться сбоем, проблема, скорее всего, связана с предыдущей проблемой. Вы должны оставить активы включёнными и закрыть окно обслуживания после завершения тестирования.
    • Изучите проблему за пределами запланированного периода обслуживания. Запланируйте еще один период обслуживания для изменений перенесенной рабочей нагрузки и запланируйте дополнительные периоды обслуживания для тестирования.

Период хранения и проверка данных

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

Рассмотрите период хранения

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

Рассмотрите требования к управлению данными

Команда, занимающаяся управлением данными в вашей организации, может предъявлять более строгие требования сверх 30-дневного периода хранения.

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

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

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

Проведение ретроспективы