Экспертный материал
Сергей Бондаренко | Руководитель технического отдела
Миграция в облако — один из основных тенденций в ИТ-индустрии за последнее десятилетие. Она остаётся актуальной как для крупных компаний, так и для представителей малого и среднего бизнеса. Как перенести ИТ-инфраструктуру правильно, чтобы не пришлось возвращаться к началу, и какие самые частые ошибки подобных проектов — в нашей статье.
Что такое миграция в облако и почему это важно
Миграция в облако — это процесс перемещения данных и приложений:
-
из частных локальных серверов на серверы поставщиков облачных услуг,
-
между разными облаками.
С каждым годом все больше компаний решаются перенести свои бизнес-процессы в облако, и причины, которые к этому подталкивают, стали за последние пару лет разнообразными. Среди них:
-
растущие угрозы и, как следствие, ужесточение требований к конфиденциальности и информационной безопасности;
-
необходимость обеспечивать ускоренное и непрерывное развитие ИТ-сервисов в условиях цифровой трансформации;
-
конкурентная гонка за качество обслуживания клиентов, необходимость быстро адаптироваться к изменениям на рынке;
-
участившиеся запросы на расширение возможностей для обработки и использования большого массива данных;
-
противоречия в бюджете: необходимость непрерывно развивать ИТ-сервисы и при этом — сокращать расходы на эксплуатацию, штат и пр;
-
сбои в поставках оборудования из-за логистических и геополитических проблем.
Поэтому и крупные, и небольшие компании всё охотнее принимают решение о миграции — им важно быстро реагировать на изменения и легко масштабироваться, оптимизировать расходы на ИТ и при этом обеспечивать высокий уровень безопасности данных. Также «переезд» в облако стал особенно популярен среди бизнесов с распределенной командой, работающей в разных часовых поясах. В результате это помогает компаниям сфокусироваться на стратегических задачах, повышать эффективность управления ИТ-инфраструктурой, быстрее внедрять новые функции и выстраивать взаимодействие отталкиваясь от потребностей, а не ограничений.
Варианты миграции в облако
В зависимости от потребностей компания может перенести в облако все ИТ-решения, например, полностью отказавшись от on-premises инфраструктуры, или лишь избранные приложения. В чем особенности и отличия этих двух сценариев
Полная миграция
При таком сценарии перехода в облако компания последовательно переносит всю ИТ-инфраструктуру к cloud-провайдеру. Полную миграцию чаще всего выбирают небольшие компании, которые не специализируются на ИТ, а ИТ-архитектура приложений относительно простая. Как правило, этот процесс занимает нескольких недель в зависимости от сложности инфраструктуры и количества переносимых систем
Частичная (или постепенная) миграция
Наиболее популярное решение среди крупных компаний со сложным, разветвлённым ИТ-ландшафтом. В этом случае сначала переносят наименее важные приложения (например, пользовательские виртуальные машины, тестовые среды), а потом — всё остальное.
Компании выбирают чаще всего этот вариант миграции, по старинке предпочитая хранить уникальные решения или сервисы, которые обеспечивают конкурентное преимущество, на собственной ИТ-инфраструктуре. Несмотря на то, что облачные провайдеры уже давно способны обеспечить необходимый уровень безопасности, не все из коммерческого сектора готовы довериться. Однако именно локальная ИТ-инфраструктура чаще всего подвергается хакерским атакам и сталкивается с утечками, а не ИТ-компании, у которых есть большой штат квалифицированных специалистов, занимающихся вопросами кибербезопасности.
Этапы миграции в облако
Переход в облако — сложный процесс, но его можно представить в виде последовательности простых шагов. Мы выделяем шесть этапов.
Стратегия миграции и управление процессом
Определите цели и задачи переезда в облако. Подробно опишите ожидания от миграции, ситуацию после окончания проекта — от этого зависит ход реализации. После этого выберете того, кто будет управлять процессом, контролировать и нести ответственность. Проектом должны заниматься как минимум проджект-менеджер и исполнитель. Если первой из этих ролей нет в вашей команде, доверьте эту функцию сисадмину.
Задачи проджект-менеджера или сисадмина:
- контроль работы исполнителя;
- помощь ему: советы, подсказки, рекомендации;
- составление календарного плана, контроль за сроками реализации; главное здесь — спокойный темп, который позволит избежать ошибок, а значит, и откатов к началу;
- определение критериев оценки результата на каждом этапе.
Анализ ИТ-инфраструктуры
Проанализируйте имеющиеся в компании ИТ-ресурсы с двух сторон — технической и коммерческой. Эта оценка поможет определить объём данных для переноса, риски и сроки миграции, затраты проекта и преимущества. Также это позволит определить, какие системы адаптированы к «переезду», нужен ли каким-то из её компонентов реинжиниринг и т.д.
Итак, нужно точно определить данные о:
- всех приложениях и их архитектуре;
- модулях этих сервисов, языках и средствах разработки, внешних и внутренних зависимости, схемах развертывания;
- соглашении об уровне обслуживания (SLA);
- вычислительных ресурсах, на которых стоят сервисы: конфигурация, ОС, технические характеристики, сетевые параметры и пр;
- базах данных: типы, версии, объёмы информации, производительность и пр;
- промежуточном ПО, например, для кеширования, передачи сообщений или интеграционная шина;
- особенностях эксплуатации, требованиях по безопасности, соответствии стандартам отрасли.
Вся эта информация об ИТ-инфраструктуре поможет вам определиться с вариантом миграции: частичная или полная.
И наконец, соотнесите собранные данные с целями, которые вы определили ранее, чтобы ещё раз убедиться, что сможете их достичь.
План миграции
Качественное планирование значительно упрощает процесс миграции. На этом этапе компания:
- выбирает провайдера, исполнителя (собственная команда или внешние специалисты), требования к новой облачной площадке (частная, публичная или гибридная), ИТ-инструментов и наиболее удобного времени для реализации проекта;
- приоритезирует приложения,
- рассчитывает оптимальный объём облачных ресурсов и соответствующих затрат,
- тестирует виртуальную платформу.
Делить миграцию на этапы обязательно и важно, вне зависимости от объёма работ. Такой подход позволяет лучше распределять нагрузку, следить за сроками и избегать необходимости откатываться к началу проекта, чтобы исправить ошибки. Здесь переходим к следующего этапу — разработке дорожной карты миграции.
Дорожная карта миграции
Дорожная карта включает в разработку целевой архитектуры, которая будет учитывать объём сервисов, планирование взаимосвязей компонентов (например, лучше всего «держать» приложения «1С» и базу данных SQL на одной площадке), обеспечение связности сети и её отказоустойчивости, а также проверка наличия резервных копий. И обязательный вопрос — составление плана аварийного восстановления в критической ситуации. Этот план «Б» — набор и порядок действий, которые помогут в кратчайшие сроки вернуть работоспособность сервисов, если что-то пошло не так.
Чем подробнее дорожная карта, тем проще оптимизировать и контролировать ресурсы: время, бюджет, рабочие часы, — а также меньше рисков нанести вред пользователям и самой компании.
Миграция
Чтобы миграция прошла успешно, рекомендуем провести функциональное и нагрузочное тестирование, а также просканировать инфраструктуру на наличие уязвимостей. Это придаст уверенности в ходе проекта и позволит перестраховаться. И только после этого можно последовательно переносить сервисы на облачные ресурсы.
Для критичных приложений лучше всего использовать бесшовную миграцию. Это позволит избежать любых сбоев или остановок работы, которые пользователи могли бы заметить из-за смены площадок.
Оптимизация
На одной лишь миграции проект не заканчивается — нужно позаботиться о возможности управлять безопасностью и контролировать использование ресурсов (затрат, рабочих нагрузок). Их внедрение позволит быстро масштабироваться по мере роста бизнес-потребностей.
Несколько рекомендаций, как избежать ошибок при миграции
Не перебарщивайте с дедлайнами
Если «переезжаете» от одного провайдера к другому, планируйте миграцию аккуратно, чтобы был запас до момента отключения хостинга – хотя бы пара недель. Это позволит вам остаться на старой площадке, если на проекте произойдут сбои, перенос не случится и прочее — сможете просто продлить оплату периода.
Составьте расписание бэкапов
В первую очередь сделайте бэкапы приложений до старта миграции. После — резервные копии настроек после каждого успешно выполненного этапа. А если у вас возникли проблемами с бэкапами (например, закончилось место на сервере), отложите перенос систем в облако. В противном случае последствия в случае ошибок могут быть более неприятными.
Выбирайте проверенный стек технологий
Проект миграции не время для экспериментов. Чтобы избежать факапов на проекте, тщательно проверьте инструменты перед использованием. Например, можете создать копию ИТ-инфраструктуры и попробовать перенести ее с помощью выбранного софта. Важно при этом обеспечить условия, которые будут максимально приближены по свойствам (например, величина задержек сети) к реальной среде.
Другой вариант — пойти «протоптанной дорогой» и использовать в процессе миграции те инструменты, с которыми уже регулярно работаете. Например, предпочитаете Ansible для развертывания копии приложения? Не изобретайте инструмент и выберете его.
Определите слабые места вашей архитектуры
Задача проджект-менеджера/сисадмина — проанализировать перевозимые приложения, найти слабые места и составить дорожную карту миграции с их учётом. Большинство проблем таится, как правило, в администрировании баз данных, настройках сети, каналах связи и даже коде. Любая из них может дать о себе знать в самый неподходящий момент.
Сделайте чекап сертификатов
Среди автолюбителей есть хорошее правило — сделать полное техобслуживание машины перед долгой поездкой. Это нужно для того, чтобы убедиться, что все работает исправно, и снизить риск неполадок. Это правило актуально и для проекта миграции.
Обязательно проверьте актуальность сертификатов — обновите их, если срок их действия вот-вот истечёт. Проверьте график регламентных работ: давно ли были автоматический сброс кэша и бэкап? есть ли риск, что они произойдут во время переноса приложений? Такие ошибки чреваты снижением производительности, которая так нужна при миграции. Если планируете перезагрузку системы при миграции, то убедитесь, что её перезапуск происходит успешно и все необходимые сервисы стартуют автоматически (или в крайнем случае есть план запуска этих сервисов).
Кому доверить миграцию
Перенести приложения в облако можно своими силами, но в особенных случаях лучше обратиться к профильным специалистам. Что это за исключительные случаи?
- Высокая цена ошибки: простои обойдутся дороже проекта, а любой сбой серьезно навредит репутации компании.
- Маленькая внутренняя команда. Если вы поручаете миграцию одному-двум специалистам, скорее всего, они будут сильно перерабатывать, уставать и допускать ошибки.
- У сотрудников нет достаточного опыта и нужного уровня компетенций, чтобы самостоятельно перенести приложения.
- Нужен сторонний экспертный взгляд на ИТ-инфраструктуру. Внешние команды, специализирующиеся на подобных проектах, способны разглядеть неочевидные риски или проблемы, которые могли бы вылезти при переезде.
- Сотрудникам не хватает компетенций или опыта для самостоятельного переноса инфраструктуры.
Мы предоставляем комплекс консультационных и инженерных услуг по миграции приложений из систем виртуализации или сервисов в облако CorpSoft24. Чтобы обратиться к нам, достаточно оставить заявку, и мы свяжемся с вами.
