Как правильно мигрировать в отечественное облако?

Ситуация с использованием ресурсов иностранных провайдеров варьирует от условно терпимой до невозможной. Это зависит от того, чьими ресурсами пользуются заказчики. Например, сервисы AWS и Azure вроде бы как в строю – регистрация недоступна только для новых клиентов. Между тем, нет понимания, как за услуги платить частным лицам: российские банки отключены от SWIFT, транзакции не проходят. Как вариант – устроить пляски с бубном (то есть с VPN, иностранными платежными системами и международными сервисам переводов), но это трудозатратно и подходит не для всех.

Для крупных клиентов по-прежнему работают облачные дистрибьюторы, которые имеют возможность оплатить счета для международных контрагентов, но как будет развиваться ситуация в дальнейшем – неизвестно. Есть и крайние случаи: Oracle Cloud полностью прекратил предоставление сервисов своим заказчиков на территории России: они даже не могут не могут войти в свои учетки и сделать бэкап на сторонние ресурсы. Параллельно с этим провайдер предлагает воспользоваться ЦОД в Германии, но это также подходит далеко не всем заказчикам.

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

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

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

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

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

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

2.  Предварительное планирование миграции. Необходимо проанализировать потребность в вычислительных ресурсах, возможно, нарастить производительность через соответствующие запросы провайдеру, проработать вопросы защиты ИТ-инфраструктуры, так как на определенном этапе часть данных будет находиться в исходной среде, а часть - в целевой инфраструктуре. Наконец, определить тип миграции. Ее можно осуществить двумя путями: at one с переносом всей инфраструктуры из точки А в точку B либо поэтапно с последовательной миграцией систем. В этом случае важно отслеживать связность между ними.

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

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

5. Организационное планирование. Нужно выделить отдельного человека в команде, который будет отвечать за все административные вопросы: определит цели и план проекта, разработает RACI-матрицу (она важна, если в процессе миграции участвует совместно клиент и провайдер/провайдеры), запланирует время для восстановления работоспособности целевой инфраструктуры или отката в случае сбоя и т.д. 

***

Вполне возможно, что происходящее ничего, кроме раздражения, у пользователей не вызывает. Но ситуация не безнадежна. Облачный рынок в России развивается более десяти лет, здесь действительно существует серьезная конкуренция между провайдерами, которая толкает предоставление сервисов на качественно новый уровень. Например, по скорости реакции и максимальному сроку ответа отечественные поставщики уже на голову выше иностранных коллег. За рубежом редко отвечают на сообщения клиентов в течение 10–15 минут. Внешнеполитические вызовы определенно станут драйверами развития рынка. Предполагаем, что вслед за запросами требовательных пользователей, которые ранее использовали ресурсы иностранных провайдеров, российские игроки также расширят портфолио своих сервисов – в формате SaaS или предоставляемых по модели управляемых услуг.

C оригиналом статьи можно ознакомиться на IT World