Как перенести бизнес в облако? 8 шагов для эталонной миграции

Согласно исследованию ^[1], 42% российских компаний планируют увеличить вычислительные мощности в 2025 году. Один из вариантов успешного масштабирования — миграция в облачную инфраструктуру. С его помощью можно снизить затраты, гибко управлять ресурсами и гарантировать безопасность данных.

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

Почему бизнес откладывает миграцию: мифы об облаке

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

Огромный пул работ над приложением

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

Непродуманная архитектура

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

Увеличение расходов

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

Технологическая зависимость

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

Нет экспертизы у сотрудников

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

Низкая скорость работы

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

Даже небольшой простой работоспособности несет финансовые и репутационные риски для компании.

Какие факторы подталкивают к облаку: бизнес-эффект от миграции

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

Отказоустойчивость 

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

На данный момент организация Disaster Recovery на базе облака — это самый распространенный и оптимальный сценарий на практике компаний. Облачную инфраструктуру легче создавать и масштабировать. Если компания использует Terraform или иные инструменты IaC-подхода, развернуть резервную площадку можно за несколько минут. 

Также очевидным преимуществом является модель оплаты pay-as-you-go — оплата за потребленные ресурсы, которую поддерживают облака. Если компании не нужна активная репликация инфраструктуры 24/7/365, она может экономить на ресурсах. 

Подробнее о характеристиках Disaster Recovery → ^[2]

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

Безопасность

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

Например, облако Selectel соответствует 152-ФЗ до первого уровня защищенности, а также имеет лицензию ФСТЭК, сертификат PCI DSS и другие. Это значит, что вы можете хранить персональные данные пользователей и соответствовать требованиям российского законодательства.

Оптимизация расходов

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

Большим преимуществом являются система постоплаты и гибкая тарификация ресурсов. Также можно на время отключить облачные серверы в период простоя или сэкономить до 70% ^[3] с помощью прерываемых виртуальных машин.

Гибкость и масштабирование

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

Простота в использовании

Многим нравится, что облачные платформы превращаются в маркетплейсы или конструкторы. Достаточно подобрать необходимую конфигурацию в несколько кликов, чтобы арендовать сервер ^[4]. В результате специалистам необязательно иметь глубокую экспертизу, они могут использовать облачные ресурсы в качестве PaaS-решения.

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

Панель управления Selectel ^[5] работает по такой же механике. В ней можно создать виртуальную машину, а также арендовать PaaS-сервисы — например, облачные базы данных или Managed Kubernetes.

Развитие бизнеса

Сегодня компаниям нужно развиваться так быстро, как этого требует рынок. Внедрение AI-технологий — еще один драйвер миграции в облако. Для работы с ними нужны производительные GPU ^[6] для сложных вычислений — например, NVIDIA® Tesla® A100, A30 и RTX™ 6000 ADA.

При этом самостоятельная закупка процессоров — нецелесообразное действие. Один ускоритель может стоить более миллиона рублей. А кроме самой покупки придется наладить логистику и доставку оборудования до вашего сервера. Гораздо выгоднее почасово арендовать GPU-мощности у провайдера для решения конкретной задачи.

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

«Облако сегодня все больше напоминает маркетплейс: множество готовых сервисов, удобная экосистема, понятный саппорт — все это действительно привлекает. Но именно эта «легкость входа» часто оборачивается ощущением вендорлока. Чтобы воспользоваться преимуществами конкретной платформы, приходится адаптировать архитектуру и процессы под нее. А если в будущем возникнет необходимость миграции — выйти из такой зависимости будет куда сложнее».

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

Роли и зоны ответственности

Selectel отвечает за бесперебойную работу платформы в рамках SLA, своевременное предоставление ресурсов, стабильность базовых сервисов и техническую поддержку. Также помогает команде миграции с разъяснением специфики работы облачных функций и возможных сценариев их применения.

Команда ITSumma отвечает за полный цикл миграции: от проектирования архитектуры и реализации через IaC до тестирования, переключения трафика и ввода инфраструктуры в эксплуатацию.

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

Эталонная миграция: 8 шагов

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

Шаг 1. План и требования

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

ITSumma. Недавно мы осуществляли миграцию по принципу lift and shift ^[7]. Целью клиента была смена хостера, так как текущий оказался ненадежен. Благодаря четко поставленной цели м не производили лишних работ и быстро перевезли проект.

Шаг 2. Аудит и документация

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

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

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

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

Шаг 3. Техническое задание

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

Особое внимание стоит уделить сетевой связности, схеме сети и сопоставлению требований с возможностями новой инфраструктуры. Чаще всего миграция не происходит по принципу простого lift and shift. 

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

Шаг 4. Разработка новой инфраструктуры

При разработке новой инфраструктуры не стоит пренебрегать использованием Infrastructure as Code ^[8] (IaC). Этот подход значительно упрощает переразвертывание уже мигрированной инфраструктуры — например, если потребуется добавить ресурсы или перенести виртуальную машину между регионами и зонами доступности. Специфические настройки облака, такие как секьюрити группы, можно задавать через API провайдера, CLI или с помощью инструментов вроде Terraform.

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

Шаг 5. Предварительная подготовка

Компаниям необходимо подготовить сценарий аварийного восстановления (Disaster Recovery). Он состоит из регулярного создания бэкапов и четкого плана отката на случай непредвиденных ситуаций во время миграции.

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

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

Шаг 6. Миграция

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

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

Эталонный пример, когда переезжали сначала процессы, а затем приложения, — кейс Тануки ^[9].

Кроме того, Selectel начисляет до 1 000 000 бонусов ^[10] на два месяца при переезде с инфраструктуры других провайдеров или собственной инфраструктуры on-premise. Также поддерживает на всех этапах переезда: от организации встречи с архитектором, который ответит на вопросы, до миграции силами опытных DevOps-инженеров. 

Шаг 7. Приемо-сдаточные испытания

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

Если все проверки прошли успешно, фиксируются результаты и обновляется документация: схема инфраструктуры, состав виртуальных машин и сервисов, параметры резервного копирования, сетевые настройки и настройки управления доступом (IAM).

Параллельно с испытаниями можно настроить системы мониторинга, алертинг и финальную валидацию SLA (выполнения всех соглашений об уровне сервиса).

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

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

Шаг 8. Переключение и введение в эксплуатацию

После успешного завершения испытаний начинается процесс переключения трафика на новую инфраструктуру. Если архитектура это позволяет, рекомендуем использовать поэтапное включение — методы canary или blue/green. Особенно при переходе с on-premise на облако.

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

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

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

Когда можно доверять инфраструктуре

Разберем основные признаки, когда можно доверять инфраструктуре провайдера.

1. Провайдер обеспечивает отказоустойчивость. Дата-центры Selectel соответствуют международным стандартам Tier III. Все инженерные системы многократно зарезервированы, чтобы во время плановых работ сервисы функционировали в привычном режиме. 

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

2. Инфраструктура соответствует требованиям безопасности. У Selectel есть инфраструктура, для которой проведена не только оценка эффективности, но и аттестация по 17 приказу ФСТЭК. Это значит, что клиент может размещать системы, которые выполняют требования безопасности.

Ознакомиться с сертификатами и заключениями можно на странице безопасности Selectel ^[11].

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

«Облачная платформа Selectel соответствует наивысшему уровню защиты, поэтому актуальна для компаний, которые работают с наиболее чувствительными категориями персональных данных. Мы, в свою очередь, готовы предоставить им надежные сервисы для работы с персональными данными в соответствии с законом РФ».