Облачная миграция: когда и как правильно переходить в облака
Причины и задачи миграции в облако
Чаще всего компании переходят в облако по следующим причинам, которые непосредственно связаны с задачами этого процесса.
Замена устаревшего оборудования
Например, компания когда-то купила серверное оборудование и построила на нем IT-ландшафт, но со временем техника устарела и стала нуждаться в замене. Процесс обновления оборудования – долгий и дорогой, поскольку выросла цена, увеличились сроки поставок и появились вопросы с гарантией, ведь часть решений привозят в страну по схеме параллельного импорта. Гарантии от западного вендора нет никакой, а условия дистрибьютора зачастую не совсем привлекательные. Поэтому многие компании обходят такие проблемы переносом собственной IT-инфраструктуры в облако.
Снижение затрат на содержание IT-инфраструктуры
Миграция в облако позволяет сократить капитальные затраты и не переплачивать за оборудование. Например, при увеличении объемов данных или масштабировании компании не нужно закупать дополнительное IT-оборудование, ведь можно мгновенно арендовать дополнительные виртуальные мощности. Таким образом, затраты становятся более гибкими и управляемыми.
Повышение гибкости и масштабируемости
Облачные ресурсы подстраиваются под текущие потребности бизнеса. Например, интернет-магазин проводит «Черную пятницу», из-за чего количество посетителей увеличивается в несколько раз. Облачный провайдер может обеспечить дополнительную мощность и ресурсы мгновенно, чтобы поддержать доступность и отклик сайта. Когда трафик снижается, ресурсы также можно легко уменьшить, чтобы сократить затраты.
Соответствие требованиям хранения данных в России
Только российские облака соответствуют локальному законодательству о хранении персональных данных. Кроме того, размещение IT-инфраструктуры в санкционных сервисах (например, Microsoft Azure или Amazon), которые официально недоступны в России, предполагает проблемы с их оплатой. В целом пользоваться подобными иностранными сервисами сегодня нецелесообразно. Кроме того, если международные компании хотят локализоваться в России, то им логичнее пользоваться отечественной IT-инфраструктурой, включая облачные сервисы.
Обеспечение высокой доступности и отказоустойчивости
В облаке все данные многократно дублируются: от питания и провайдеров до серверов и сетевых устройств, что гарантирует доступность инфраструктуры, сервисов и сохранность информации. При этом некоторые провайдеры предлагают резервирование на уровне ЦОДов, то есть полную катастрофоустойчивость. Если один из нескольких дата-центров по какой-то причине выйдет из строя, то системы автоматически переключатся на резервные ЦОДы, что гарантирует непрерывную работу IT-инфраструктуры даже при возникновении локальных проблем.
Оптимизация управления IT-инфраструктурой
Облако снижает нагрузку на внутренние IT-ресурсы и повышает их эффективность. Например, после миграции даже небольшая компания может позволить себе использование тех же уровней защиты данных, что и у крупных организаций, без необходимости нанимать команду специалистов по безопасности. Также переход в облако позволяет значительно сократить количество физических серверов, в результате чего IT-отдел может сосредоточиться на более важных задачах.
Сокращение сроков запуска новых проектов
Облачные решения упрощают запуск новых сервисов и приложений. Например, если компания хочет запустить внутренний стартап, то ей не нужно тратить ресурсы на дополнительное оборудование, поскольку можно арендовать облачные мощности и протестировать новый проект. Если стартап потерпел неудачу, то его можно быстро «схлопнуть», избежав капитальных затрат.
Типы IT-инфраструктуры при миграции в облако
Облачная миграция может быть:
- Полной — перенос всей IT-инфраструктуры и данных в облако.
- Частичной — перенос отдельных приложений или сервисов.
- Гибридной — распределение ресурсов между облаком и локальной инфраструктурой, позволяющее размещать и поддерживать критически важные процессы локально.
Наиболее распространенным вариантом является гибридная миграция, которая позволяет компаниям находить баланс между локальной инфраструктурой и облачными возможностями. Гибридные решения помогают адаптировать ресурсы в зависимости от текущих потребностей.
План миграции в облако
1. Анализ текущей IT-инфраструктуры
Как врач начинает лечение пациента с обследования и выставления диагноза, так и IT-специалисты перед началом облачной миграции всегда анализируют текущую IT-инфраструктуру. Интересно, что чаще всего актуальной и полной информации о такой инфраструктуре у заказчика нет, причем чем крупнее клиент, тем больше у него хаоса. Часто причина в том, что крупные компании состоят из более мелких, которые когда-то объединились в одну вместе со своей инфраструктурой – отсюда и дублирующие сервисы, и прочая неразбериха. Анализ позволяет оценить готовность к миграции и ее оптимальный путь: полный или частичный перенос в облако всех данных.
2. Сайзинг и планирование ресурсов
На этом этапе нужно понять, какое оборудование понадобится для миграции: процессоры, диски, ОЗУ и прочее «железо». Если неправильно провести сайзинг, то не хватит производительности, а бюджет будет некорректным. Например, компания планировала тратить на облако 300 тысяч рублей в месяц, а после добавления ресурсов выходит 600 тысяч. При этом с технической точки зрения проект можно считать успешным, но бизнес недоволен, поскольку предполагал совершенно другие затраты. Поэтому для сайзинга нужна экспертиза, а если подойти к процессу спустя рукава, то грамотно оценить масштаб миграции не получится.
3. Выбор облачного провайдера
После планирования ресурсов нужно выбрать подходящего облачного провайдера, которых на рынке сегодня предостаточно: Cloud.ru (в прошлом SberCloud, Cloud), VK Cloud, Yandex Cloud, Good Cloud и другие. Некоторые облака в большей степени «заточены» под Linux-серверы, другие хорошо «переваривают» Windows-инфраструктуру. Некоторые провайдеры позиционируют себя как публичные облака для маленьких компаний, другие – как решение для крупных корпоративных клиентов. У каждого провайдера, безусловно, свои особенности, поэтому выбор зависит от специфики бизнеса.
4. Проектирование архитектуры системы
Наиболее технологически сложный этап. Разработка архитектуры облачных решений учитывает требования бизнеса к отказоустойчивости, надежности, времени восстановления после сбоя и т.д. Если ошибки в сайзинге можно достаточно быстро исправить (докинуть процессоров или памяти, например), то архитектуру поменять сложно, поэтому она изначально должна закладываться корректно в соответствии с задачами бизнеса. Если есть время и ресурсы, то можно создать тестовую архитектуру и предоставить ее заказчику для временного пользования и обнаружения возможных проблем. Это особенно актуально для крупных компаний с большим количеством сервисов. Если времени на это нет, сразу создается полноценная инфраструктура.
5. Перенос данных и приложений
Поэтапный перенос производится руками опытных админов под присмотром архитектора и руководителя проекта. Это долгий и сложный этап, во время которого в облако переносятся домен, почта, 1С, сервер сертификатов и т.д. Перенос данных может занять несколько дней, особенно если происходит миграция из облака в облако. Интересно, что сегодня даже крупные компании часто переносят почту не на собственный почтовый сервер, а в публичные сервисы, такие как «Яндекс 360» и «Почта VK».
6. Тестирование и запуск
На этом этапе основное внимание уделяется проверке готовности системы к полноценной эксплуатации после переноса. Специалисты проводят различные виды тестирования (включая функциональное и нагрузочное), проверяя работу всех приложений и сервисов. Важно выявить и устранить любые потенциальные проблемы до запуска всей инфраструктуры, чтобы избежать сбоев в работе системы и минимизировать риски для бизнеса. Кроме того, на данном этапе осуществляется подготовка команды пользователей и администраторов к новым условиям работы.
7. Поддержка и оптимизация
Системные администраторы и инженеры data-центра следят за производительностью приложений, использованием ресурсов и потенциальными проблемами, которые могут возникнуть после миграции. Важно поддерживать высокую доступность и отказоустойчивость сервисов, поэтому проводятся регулярные тестирования и обновления системы безопасности, а также резервное копирование данных. Оптимизация подразумевает анализ текущих ресурсов и затрат для выявления возможностей улучшить производительность и уменьшить расходы.
Что не нужно переносить в публичное облако
Среди IT-руководителей и топ-менеджеров по этому поводу нет единого мнения. Часто считается, что некоторые данные и приложения лучше оставить в локальной инфраструктуре:
- Конфиденциальные данные: например, финансовую информацию и базы данных клиентов;
- Критические системы управления: приложения, которые необходимо держать под строгим контролем;
- Приложения, тесно интегрированные с локальным оборудованием: если приложение требует специфического оборудования для работы, его перенос в облако может вызвать проблемы.
Некоторым компаниям важно, чтобы тот или иной сервис был всегда доступен вне зависимости от работоспособности интернета. Например, если у торговой компании перестанет работать складской учет, то это может привести к огромным убыткам. Поэтому размещать складские программы и прочие сервисы можно либо полностью на локальном сервере, либо по гибридной модели (сама инсталляция находится локально, а реплика – в облаке).
Что касается размещения конфиденциальных данных, то сегодня у многих компаний в облаке хранится финансовая и кадровая информация, и никаких проблем не возникает. Здесь важно, чтобы облако в принципе соответствовало требованиям, предъявляемым к хранению персональных данных, но это снимает только часть проблем. Важно, чтобы облачная инфраструктура была правильно защищена средствами безопасности.
Впрочем, как показывает практика и громкие случаи взлома IT-инфраструктур, при желании злоумышленники могут получить доступ и к локальным серверам с важной информацией, поэтому опасность облачного хранения данных, по-моему, немного преувеличена.
В следующем материале расскажу об ошибках и подводных камнях облачной миграции – не пропустите!
Эх, думала, тут про отпуск, а это опять работа)
У нас в офисе какую-то штуку года 2 назад замутили после того как полетели разом неск компов - все доки хранятся типа на сервере. Но косяк - нельзя отправить на обычную почту мэйл. Это про то?
Пока надо поработать) Да, частный случай облака, скорее всего
а вы в текущую структуру встраиваете или создаете какую-то собственную конфигурацию?
И так и так делаем. Чаще всего гибрид - что-то в офисе (серверной), что-то в облако переводим. Зависит от задачи, в общем.
Удивительна конечно разница между малым и крупным бизнесов. Малый бизнес уже лет 10 как весь в облаках. Крупняк только задумался.
Вы наверное с госкорпорациями работаете, да, Дима?
В основном с коммерческими, Таня. Много небольших и средних. Но многие небольшие имеют собственные инфраструктуры. Не все такие прогрессивные как вы) Но, учитывая сложности с обновлением железа, все всё более позитивно смотрят на облако)
Сайзинг, my ass!
прочёл раздел но так и не понял, чего это такое. оценка требуемых мощностей или же "осмечивание" (тоже ну и словечко) — ну то есть планирование бюджетов. или и то и другое?