Миграция в облако - 10 шагов, которые вы должны выполнить

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

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

Вот 10 шагов, которые необходимо предпринять при переходе к общедоступному облаку

1. Определение цели миграции в облако

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

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

2. Анализ текущей ситуации

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

• уровень виртуализации системы - при миграции в облако необходимо будет перестроить архитектуру системы; если система частично или полностью виртуализирована, будет проще мигрировать; однако, если он адаптирован только для локального решения, больше времени придется потратить на перестройку архитектуры;
• оценка необходимости переноса отдельных приложений - может случиться так, что некоторые приложения (например, старые или те, которые хранят / обрабатывают персональные данные) лучше оставить в текущем или слегка измененном виде на локальном решении;
• используется коммерческое ПО - некоторые лицензии на ПО не предусматривают использование облачных сервисов, их запуск возможен только на локальном решении;
• стоимость текущего решения - помимо явных затрат (например, вознаграждение сотрудников, оплата покупки или аренды машин), стоит учитывать неявные затраты (например, время, потраченное сотрудником на обслуживание инфраструктуры, а не на проведение работ по развитию);
• необходимость соблюдения правовых норм и стандартов, например Закона о банках или GDPR.

3. Выбор партнера

Миграция в облако (особенно на первом этапе) - непростая задача, и зачастую необходимо сотрудничать с квалифицированным, опытным партнером. Партнер - это компания, которая действует от имени поставщика облачных услуг, например, Google Cloud Premier Partner в случае Google Cloud Platform.

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

4. Подбор специалистов в команду и определение лидера миграции

Команда, которая будет руководить миграцией, должна состоять из людей, очень хорошо знающих систему, и в идеале она должна состоять из людей, участвовавших в ее создании. С другой стороны, вам нужны люди с высоким уровнем знаний о решении, на которое будет выполняться миграция (например, GCP, AWS, Azure) - желательно, чтобы это был Партнер.

Команду должен возглавлять лидер - архитектор или специалист в области системной инженерии. Лидер при поддержке Партнера (например, Cloud Architect ) будет принимать решения о ходе миграции данных, уровне рефакторинга или механизмах переключения производственной среды.

5. Выбор решения - одно публичное облако, мультиоблако, гибридное облако

После постановки цели и анализа текущей ситуации следует выбрать облачное решение. К наиболее популярным общедоступным облакам относятся Google Cloud Platform, Amazon Web Services и Microsoft Azure. При выборе поставщика стоит обратить внимание, среди прочего, на от производительности решения, гарантированного SLA, затрат (включая метод расчета, в секундах или минутах) или дополнительных необходимых услуг (например, аналитика BigData, машинное обучение, искусственный интеллект).

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

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

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

6. Стратегия миграции

Цель миграции также определяет способ ее выполнения. Есть три популярных стратегии перехода в общедоступное облако на выбор:

• Lift-and-Shift (также известный как rehosting) - стратегия перехода в облако без внесения каких-либо изменений в существующую систему; единственное, что меняется, - это поставщик услуг инфраструктуры;
• реплатформа - стратегия, учитывающая внесение изменений в систему, часто сочетается с оптимизацией существующей архитектуры и внесением улучшений;
• рефакторинг - стратегия миграции, в ходе которой вносятся существенные изменения или полная реконструкция архитектуры системы (например, переписывание приложения для контейнеризации).

7. Расстановка приоритетов и составление расписания

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

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

8. Выбор показателей

Правильно выбранные и хорошо контролируемые KPI (показатели эффективности) позволят вам отслеживать, идет ли миграция в соответствии с планом, а если нет - над какими областями необходимо поработать. Элементы, которые можно измерить во время миграции в облако:

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

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

• процент загрузки ЦП,
• свободное место на диске,
• производительность и скорость сети,
• стоимость содержания инфраструктуры,
• скорость разработки продукта.

9. Обновление внутренних процессов

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

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

10. Способ переключения производственной среды

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

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