arrod-back new-mail arrow atom Ресурс 2 cod-modern comp connect data-cod detail email fingerprint home input-user iso justice lan libra lifebuoy people planet rub shield speedtimer stat storage tel timer

Разумный переезд: пошаговое руководство по миграции в облако

14 февраля 2022
Время прочтения - 55 минут
  • #полезное
  • #экспертиза

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

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

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

1. Утвердить внутри компании общую стратегию трансформации и перехода в облако.

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

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

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

Вот некоторые KPI, которые стоит зафиксировать.

  • Доступность. Определитесь с целевой доступностью информационных систем.
  • Масштабируемость. Оцените потребности в росте мощностей и сформируйте требования к скорости и объёму изменений, к которым должна быть готова инфраструктура. Это может быть как линейный плановый рост, так и сезонные изменения или непрогнозируемый взрывной рост.
  • Стоимость владения. Как должна измениться стоимость владения информационными системами, включающая расходы на сами вычислительные мощности, ресурсы IT-специалистов, необходимые для их поддержки, а также накладные расходы.

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

2. Выбрать сервис-провайдера.

Как выбрать того самого? При выборе сервис-провайдера рекомендуем обратить внимание на следующие параметры:

  • портфель клиентов — опыт работы над разными проектами и реализованные кейсы;
  • возможность предоставления кастомизированных решений под конкретные потребности бизнеса заказчика, а не только коробочных решений;
  • наличие нескольких линий поддержки, включая вендорскую, и качество этой поддержки;
  • соответствие требованиям информационной безопасности и аттестация инфраструктуры по 152-ФЗ «О персональных данных» в том случае, если в облаке необходимо разместить информационные системы, которые хранят и обрабатывают персональные данные клиентов;
  • параметры соглашения об уровне сервиса (SLA).

3. Провести аудит информационных систем внутри компании: определить существующую архитектуру систем, их критичность для бизнеса, наличие обязательных систем защиты.

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

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

4. Определить стратегию миграции для каждого бизнес-приложения.

После аудита для каждого оценённого цифрового бизнес-актива необходимо определить стратегию миграции в облако. Прежде чем переходить в облака, стоит совместно с сервис-провайдером определить, какая из стратегий наиболее соответствует потребностям бизнеса. Эксперты Gartner выделяют пять ключевых стратегий, наиболее известных как 5R.

Повторный хостинг (Rehost) — облачный провайдер просто повторно развёртывает существующие системы на облачном сервере. Эту стратегию выбирают тогда, когда нет необходимости в значительных архитектурных изменениях.

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

Исправление (Revise). Эта стратегия наиболее актуальна, когда возникает потребность модернизировать устаревшие системы. Перед переходом в облако необходимо расширить или изменить базу кода. Такой подход помогает вывести работоспособность систем на тот же уровень, что и характеристики виртуальной среды облачного провайдера.

Перестройка (Repurchasing) — это переписка приложения с нуля на платформе сервис-провайдера (PaaS), удаление существующего кода и изменение архитектуры приложения. Такое решение открывает новые и инновационные функции через облачную платформу поставщика IT-решения.

Замена (Replace) — стратегия, которая предполагает отказ от существующих устаревших приложений, больше не отвечающих потребностям бизнеса, и переход на модель «программное обеспечение как услуга» (SaaS).

5. Совместно с сервис-провайдером выбрать наилучшее решение по размещению ресурсов — публичное, частное или мультиоблачное размещение, построить план миграции каждого из приложений и определить уровень сервиса (SLA).

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

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

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

Согласованный уровень качества предоставления сервиса — важнейший аспект при работе с облачным провайдером. Здесь в игру вступает SLA — уровень оказания услуг, который может включать параметры непрерывности, доступности, производительности, время реакции на обращения, время простоя в отчётном периоде и другие.

6. Зафиксировать все детали с сервис-провайдером — согласовать ТКП. Рассчитать общую стоимость владения для планирования затрат и оценки потенциальной экономии.

Сервис-провайдеры предлагают модель оплаты по мере потребления (pay-as-you-go) — заказчик платит только за те виртуальные мощности, которые были задействованы. После получения всех деталей и согласования технико-коммерческого предложения (ТКП) бизнес может рассчитать TCO. Это совокупная стоимость владения — общие расходы, которые возникают у компании из-за владения каким-то активом, в данном случае IT-инфраструктурой. Для облака считают мощности, которые нужны компании, чтобы закрыть все потребности.

Затраты на локальную инфраструктуру в основном складываются из капитальных затрат (CapEx), в то время как облачная инфраструктура обычно складывается из операционных расходов (OpEx). Получив все данные, бизнес может сравнить затраты на on-premise и облака и оценить уровень снижения затрат при заключении контракта с облачным провайдером на выбранный период.

7. Провести «тестовую» миграцию наименее критичной из систем в боевом режиме.

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

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

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

8. Финальный шаг — оценка соответствия поставленных целей и показателей эффективности (KPI) реальным результатам.

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

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