Контрольный список для миграции в облако:8 шагов для обеспечения плавного (и безопасного) перехода в облако

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

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

Контрольный список миграции в облако

Борьба с облачной миграцией — обычная проблема для бизнеса. Недавние исследования показывают, что 55 % переносов в облако либо происходят со значительными задержками, либо превышают бюджет. .

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

• Общая стоимость владения (TCO).
• Как команда будет перемещать огромные объемы данных и критически важных приложений в облако.
• Различные варианты облачного развертывания и интеграции.
• Потенциальные новые риски кибербезопасности.
• Насколько подготовлена ​​внутренняя команда для работы в облаке.

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

Выберите архитектора миграции

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

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

Выделенный архитектор также должен предоставить полную картину вашей ИТ. Этот процесс включает в себя ответы на следующие вопросы:

• Какие приложения у вас есть и кто ими пользуется (и как часто)?
• Насколько важны для бизнеса приложения, которые вы планируете перенести?
• Какие ресурсы потребляют программы и зависят ли они от других приложений?
• Какие соглашения об уровне обслуживания, меры по обеспечению непрерывности бизнеса и меры по обеспечению соответствия действуют в настоящее время?
• Есть ли проблемы с производительностью, влияющие на текущие операции?

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

• Выполните миграцию.
• Работать в облачной среде.

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

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

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

Установите цели миграции и ключевые показатели эффективности

Следующим шагом является определение основной цели (целей) миграции. Вот некоторые распространенные высококлассные цели:

• Модернизация устаревшего приложения.
• Ускорение работы определенного сервиса.
• Улучшение операционных возможностей.
• Повышение отказоустойчивости системы.
• Улучшение взаимодействия с пользователем.
• Достижение лучшей масштабируемости службы.
• Снижение текущих расходов.
• Повышение безопасности данных.

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

• КПЭ, которым вы следуете в процессе миграции.
• КПЭ после миграции.

Вот наиболее распространенные ключевые показатели эффективности, которые компания может отслеживать в процессе миграции:

• Продолжительность переноса (как в целом, так и для каждого приложения).
• Доступность важнейших сервисов.
• Продолжительность простоя служб и центров обработки данных.
• Снижение качества обслуживания из-за простоя.
• Количество созданных заявок на обслуживание.
• Стоимость миграции.

Давайте рассмотрим некоторые ключевые показатели эффективности после миграции, которые может отслеживать ваша команда:

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

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

Выполнить оценку данных и приложений

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

• Уровни риска данных.
• Объем и тип данных, которые вы планируете перенести.
• Общая устойчивость данных.
• Юридические требования к конфиденциальности данных (если таковые имеются).
• Наиболее серьезные угрозы целостности данных.
• Возможные сценарии нарушения или утечки данных после переноса.

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

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

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

Оцените варианты миграции в облако

Следующим шагом в контрольном списке миграции в облако является оценка того, какие приложения требуют того или иного типа интеграции с облаком. У вас есть два варианта:

• Поверхностная интеграция с облаком (так называемая "подъем и перенос"): Когда вы поднимаете и перемещаете приложение, вы практически не вносите изменений в код и устанавливаете приложение в облаке более или менее в его текущей форме. Перенос приложения без каких-либо изменений называется повторным хостингом.; внесение незначительных изменений при переносе приложения в облако является рефакторингом .
• Глубокая облачная интеграция: В отличие от своего мелкого аналога, глубокая облачная интеграция требует, чтобы вы модифицировали приложение, чтобы воспользоваться преимуществами облачных функций. Изменения могут варьироваться от относительно простых настроек (таких как настройка автоматического масштабирования и динамической балансировки нагрузки) до расширенных обновлений (таких как включение бессерверных вычислений), которые превращают приложение в облачное решение.

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

Компании также часто принимают решение об удалении или сохранении приложений при оценке того, какой сервис требует того или иного типа интеграции:

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

Выберите правильную модель развертывания облака

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

• Общедоступное облако (многопользовательская среда, предоставляющая доступ к вычислительным ресурсам через Интернет или через выделенное прямое соединение).
• Частное облако (система с одним арендатором, в которой предприятие использует облачные ресурсы в своем собственном центре обработки данных).
• Гибридное облако (сочетание локальных систем, общедоступных и частных облаков, в котором рабочие нагрузки перемещаются между средами посредством автоматизации и оркестровки).
• Многооблачная среда (сочетание двух или более общедоступных облачных сред IaaS).
• Облако сообщества (инфраструктура, совместно используемая несколькими компаниями с общими потребностями или проблемами).

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

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

Выберите поставщика облачных услуг

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

• Цены.
• Подбор услуг.
• Доступно в определенных регионах.
• Гарантия бесперебойной работы.
• Знакомство вашей внутренней команды со стеком технологий поставщика.
• Соответствие отраслевым требованиям (например, хранение пользовательских данных в месте происхождения в соответствии с CCPA или GDPR).
• Поддержка после миграции и управляемые ИТ-услуги.

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

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

Выполнить необходимый рефакторинг

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

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

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

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

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

Методически переносите и переключайте трафик с локальных операций

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

Вот как должен выглядеть этот подход к миграции:

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

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

• Все сразу: Команда переключает весь локальный трафик, как только приложение начинает работать в облаке.
• Немного за раз: Вы переводите нескольких клиентов в новую среду после того, как команда настроит облачное приложение. Если все работает должным образом, вы продолжите переводить клиентов на облако, пока все конечные пользователи не перейдут на новое приложение.

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

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