Безопасная миграция в облако: 8 ключевых шагов для бесшовного перехода

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

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

Чек-лист миграции в облако

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

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

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

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

Выберите ведущего архитектора миграции

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

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

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

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

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

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

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

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

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

Установите цели миграции и KPI

Следующий шаг — установить основные цели миграции. Некоторые частые высокоуровневые цели:

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

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

• KPI, которые вы следите во время процесса миграции.
• Пост-миграционные KPI.

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

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

Посмотрим на некоторые пост-миграционные KPI, которые ваша команда может отслеживать:

• Инфраструктурные KPI (CPU usage, memory footprint сервиса, дисковая производительность, балансировка нагрузки, латентность, пропускная способность сети и др.).
• Метрики производительности приложения (error rates, количество таймаутов, среднее время отклика (ART), пиковое время отклика (PRT), аптайм, доступность и др.).
• KPI пользовательского опыта (количество спайков запросов, ошибки HTTP статус-кодов, брошенные и залогированные исключения, лаг, времена отклика и др.).
• Метрики бизнес-воздействия (длительность чекаута, подписки/отписки, engagement rates и др.).
• Костовые KPI (ежемесячный биллинг, затраты на штат, сторонние инструменты, консалтинговые затраты и др.).

Вам нужно установить базовое значение (baseline) для каждого KPI перед решением, что отслеживать. Baselining — процесс измерения текущего (пре-миграционного) состояния приложения и сервиса. Эти KPI позволят определить, приемлема ли пост-миграционная производительность или нет.

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

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

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

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

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

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

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

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

• Поверхностная облачная интеграция (a.k.a. lift-and-shift): когда вы lift-and-shift приложение, вы вносите мало или никаких изменений в код и настраиваете приложение в облаке более или менее в его текущем виде. Миграция приложения без изменений известна как рехостинг (rehosting); внесение незначительных изменений при переносе приложения в облако — рефакторинг (refactoring).
• Глубокая облачная интеграция: в отличие от поверхностного варианта, глубокая интеграция требует модификации приложения для использования облачных фич. Изменения могут варьироваться от относительно простых настроек (auto-scaling, динамическая балансировка нагрузки) до продвинутых обновлений (включение serverless computing), делающих приложение cloud-native решением.

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

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

• Retiring — процесс идентификации устаревшего приложения или сервиса, не несущего ценности при загрузке в облако.
• Retaining — решение оставить приложение on-prem, обычно из-за опасений безопасности или комплаенса.

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

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

• Публичное облако (multi-tenant среда, предоставляющая доступ к вычислительным ресурсам через интернет или выделенное прямое соединение).
• Приватное облако (single-tenant система, в которой предприятие запускает облачные ресурсы в собственном дата-центре).
• Гибридное облако (смесь on-prem систем, публичных и приватных облаков, в которой рабочие нагрузки движутся между средами через автоматизацию и оркестрацию).
• Мультиоблако (смесь двух или более публичных облачных IaaS сред).
• Комьюнити-облако (инфраструктура, разделяемая между несколькими компаниями с общими нуждами или заботами).

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

• Публичное облако предоставляет масштабируемую среду с моделью pay-per-usage. Хотя высокомасштабируемо, публичное облако может не быть идеальным для чувствительных рабочих нагрузок.
• Приватное облако идеально для компании с бюджетом на запуск on-prem облачной среды, кастомной под миссионно-критичные рабочие нагрузки.
• Гибридное облако позволяет запускать чувствительные рабочие нагрузки on-prem, одновременно используя масштабируемость публичного облака во время всплесков спроса.
• Пока гибридное облако высоковыгодно при правильном выполнении, есть специфические вызовы гибридного облака, о которых нужно знать перед проектированием гибридной архитектуры.
• Мультиоблако — отличный выбор для фирм, обеспокоенных vendor lock-in, или компаний, желающих микс-энд-матчить сервисы от множественных провайдеров.

Выберите облачного сервис-провайдера

Если вы не выбрали настройку on-prem приватного облака, следующий пункт чек-листа — найти облачного провайдера. Хотя большинство вендоров предлагают похожие сервисы, они не все одинаковы. Ключевые соображения при выборе провайдера:

• Цены.
• Выбор сервисов.
• Доступность в конкретных регионах.
• Гарантии аптайма.
• Знакомство in-house команды с технологическим стеком провайдера.
• Отраслевые требования комплаенса (например, хранение пользовательских данных в локации происхождения по CCPA или GDPR).
• Пост-миграционная поддержка и managed IT сервисы.

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

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

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

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

Цель — сделать ПО работающим максимально эффективно и эффективно в облаке. Например, ваша команда может рефакторить приложение для:

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

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

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

Методично мигрируйте и переключайте трафик с on-prem операций

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

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

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

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

• Все сразу: команда переключает весь on-prem трафик, как только приложение начинает работать в облаке.
• Понемногу: вы переносите нескольких клиентов в новую среду, как только команда настраивает облачное приложение. Если все работает как ожидалось, вы продолжаете переключать клиентов в облако со временем, пока все конечные пользователи не будут полагаться на новое приложение.

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

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