Облачная миграция: когда и как правильно переходить в облака

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

Здравствуйте, друзья! На связи снова Дмитрий Бессольцев – генеральный директор компании ALP ITSM. Сегодня хочу поделится опытом миграции в облако и рассказать о нюансах переноса данных в облачные виртуальные среды.

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

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

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

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

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

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

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

Только российские облака соответствуют локальному законодательству о хранении персональных данных. Кроме того, размещение IT-инфраструктуры в санкционных сервисах (например, Microsoft Azure или Amazon), которые официально недоступны в России, предполагает проблемы с их оплатой. В целом пользоваться подобными иностранными сервисами сегодня нецелесообразно. Кроме того, если международные компании хотят локализоваться в России, то им логичнее пользоваться отечественной IT-инфраструктурой, включая облачные сервисы.

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

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

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

Облачная миграция может быть:

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

Как врач начинает лечение пациента с обследования и выставления диагноза, так и IT-специалисты перед началом облачной миграции всегда анализируют текущую IT-инфраструктуру. Интересно, что чаще всего актуальной и полной информации о такой инфраструктуре у заказчика нет, причем чем крупнее клиент, тем больше у него хаоса. Часто причина в том, что крупные компании состоят из более мелких, которые когда-то объединились в одну вместе со своей инфраструктурой – отсюда и дублирующие сервисы, и прочая неразбериха. Анализ позволяет оценить готовность к миграции и ее оптимальный путь: полный или частичный перенос в облако всех данных.

На этом этапе нужно понять, какое оборудование понадобится для миграции: процессоры, диски, ОЗУ и прочее «железо». Если неправильно провести сайзинг, то не хватит производительности, а бюджет будет некорректным. Например, компания планировала тратить на облако 300 тысяч рублей в месяц, а после добавления ресурсов выходит 600 тысяч. При этом с технической точки зрения проект можно считать успешным, но бизнес недоволен, поскольку предполагал совершенно другие затраты. Поэтому для сайзинга нужна экспертиза, а если подойти к процессу спустя рукава, то грамотно оценить масштаб миграции не получится.

После планирования ресурсов нужно выбрать подходящего облачного провайдера, которых на рынке сегодня предостаточно: Cloud.ru (в прошлом SberCloud, Cloud), VK Cloud, Yandex Cloud, Good Cloud и другие. Некоторые облака в большей степени «заточены» под Linux-серверы, другие хорошо «переваривают» Windows-инфраструктуру. Некоторые провайдеры позиционируют себя как публичные облака для маленьких компаний, другие – как решение для крупных корпоративных клиентов. У каждого провайдера, безусловно, свои особенности, поэтому выбор зависит от специфики бизнеса.

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

Поэтапный перенос производится руками опытных админов под присмотром архитектора и руководителя проекта. Это долгий и сложный этап, во время которого в облако переносятся домен, почта, 1С, сервер сертификатов и т.д. Перенос данных может занять несколько дней, особенно если происходит миграция из облака в облако. Интересно, что сегодня даже крупные компании часто переносят почту не на собственный почтовый сервер, а в публичные сервисы, такие как «Яндекс 360» и «Почта VK».

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

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

Среди IT-руководителей и топ-менеджеров по этому поводу нет единого мнения. Часто считается, что некоторые данные и приложения лучше оставить в локальной инфраструктуре:

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

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

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

✔ В статье «Облачная миграция: ошибки и подводные камни при переезде в облако» вы также можете узнать о распространенных ошибках облачной миграции и постмиграционных мероприятиях.‍