Чек-лист: что не забыть при миграции в облако

TAdviser продолжает серию публикаций в новом формате – «Чек-лист». Практические советы о том, как просто и быстро переехать в облака - тема нового материала, где в тонкостях подготовки ИТ-систем компании к миграции в облака помог разобраться Георгий Мегрелишвили, исполнительный директор «СБКлауд».

До миграции

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

• преодоление ограниченности собственных ИТ-истем и возможность при пиковых нагрузках наращивать мощности;
• трансформация CAPEX в OPEX за счет снижения затрат на развитие ИТ-инфраструктуры, строительство и модернизацию собственных ЦОД;
• снижение показателя time-to-market;
• ускорение запуска новых информационных систем;
• уменьшение рисков при прогнозировании потребностей в вычислительных ресурсах.

Проект «Тотальный диктант» был ограничен в развитии серверными мощностями НГУ, на которых был развернут. Миграция в облако позволила поставить новые рекорды: в 2019 году диктант писали в реальном времени более 15000 человек в 80 странах, а в общей сложности к сайту, трансляциям и учебным курсам в день проведения акции обратились более 120000 человек во всем мире. Несмотря на столь масштабные нагрузки и разные часовые пояса, «Тотальный диктант» прошел без сбоев.

Провести мониторинг производительности
Чтобы не запланировать потребления избыточных облачных ресурсов, эксперты настоятельно рекомендуют провести мониторинг производительности существующих ИТ-систем до миграции.
Провести инвентаризацию всех элементов, которые готовятся к миграции
Самое главное – провести «ревизию» того, что планируется переносить в облако. Важно понять, на каком оборудовании работают приложения, с какими операционными системами, какое специализированное и прикладное ПО задействовано. Возможно, часть серверов уже не используется под действующие системы или объем имеющихся ресурсов избыточен. При проведении инвентаризации целесообразно учитывать данные мониторинга производительности.
Определить потребности в облачных ресурсах
По итогам инвентаризации надо определить потребность в ресурсах, операционных системах, прикладном и специализированном ПО, а также средствах информационной безопасности.

Выбор провайдера

Определиться с выбором облачной модели
Существует две модели:
Первая представляет собой облачный минимум — провайдер обеспечивает исключительно доступность виртуальных машин.
Есть более комплексный подход: провайдер и предоставляет ресурсы, и инфраструктуру (IaaS), и ПО (SaaS), а также оказывает услуги по интеграции и технической поддержке. В этом случае провайдер играет роль интегратора и берет на себя оценку потребности в ресурсах, планирование и проведение миграции данных и приложений, организацию сопровождения. Это особенно пригодится, если при миграции будет неизбежно отключение действующих ИТ-систем.
Оценить надежность партнера
При выборе облачного провайдера важно учитывать репутацию потенциального партнера и наличие в его портфолио аналогичных кейсов.
Оценить адекватность ценового предложения
Низкая цена на услуги облачных провайдеров может маскировать неудовлетворительное качество и высокие риски, либо маркетинговый «айсберг», где под привлекательной стартовой ценой таятся скрытые платежи или невозможность гибко управлять затратами на облачную инфраструктуру.

Более гуманный и технологически продвинутый способ – дать клиенту возможность самостоятельно определять, где размещаются его ресурсы – в более «дорогом» или «демократичном» сегменте облака, комбинировать эти сегменты, перебрасывать ресурсы из одного в другой сегмент самостоятельно. Мы реализовали эту идеологию, впервые в России объединив в одном облаке, в рамках единой панели управления, сегменты на разных гипервизорах – VMware и KVM.

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

Договориться об SLA
Важно убедиться, что у всех участников процесса есть единое понимание задач и способов их реализации, достигнуто соглашение SLA (об уровне предоставления услуг), а зоны ответственности разграничены. Все договоренности должны быть задокументированы – в контракте, регламентах, инструкциях.

Миграция и последующие действия

Перенести данные
Информация из собственной инфраструктуры заказчика в инфраструктуру провайдера будет передаваться по специально созданному каналу большой мощности через интернет или VPN.
Протестировать функционал систем, развернутых в облаке
По завершении миграции требуется проверить целостность и доступность данных. Во избежание проблем рекомендуется поддерживать работоспособность старой площадки после переключения на новую инфраструктуру в течение 1-2 недель. Только убедившись, что все работает корректно, можно отключить старую площадку или сохранить ее как резервный ресурс (ЦОД «холодного резерва»).