Миграция данных в облако: как избежать проблем и ошибок?

С какими проблемами можно столкнуться

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

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

Давайте попробуем разобраться, что может пойти не так, и как нам взять максимум от облака после миграции. Спросите себя «Зачем мне облако»? Популярные ответы «сэкономить», «сократить IT-штат», «повысить доступность» или самое прекрасное: «все так делают, чем мы хуже?» являются следствием стереотипов об облаках и облачном хостинге. Чтобы грамотно ответить на вопрос «зачем», стоит сначала посмотреть на преимущества, которые предоставляет облачный хостинг, и исходя из ваших бизнес-задач, выбрать те, которые действительно важны.

Зачем мигрировать

  1. Отсутствие капитальных затрат и собственной инфраструктуры. Одним из самых очевидных плюсов с точки зрения затрат – нет необходимости вкладываться в содержание собственной инфраструктуры. Помимо оборудования, которое надо постоянно обновлять, вы должны обеспечить физическую безопасность помещения, озаботиться о системах кондиционирования, видеонаблюдения и пожаротушения.
  2. Безопасность. Вам не нужно будет думать о физической безопасности вашей инфраструктуры, достаточно выбрать IT-интегратора, который обеспечивает безопасность по стандартам. Стандарты должны быть прописаны в договоре.
  3. Неограниченные ресурсы и гибкая система оплаты. Переходя в облако, вы получаете практический бесконечные ресурсы. Вы можете оплачивать их по схеме pay as you go, и потреблять столько мощностей, сколько вам необходимо в данный момент времени. Для компаний, занимающихся разработкой, это очень большой плюс. Например, можно увеличить ресурсы на тестовом контуре в десятки раз, провести необходимые тесты, и «схлопнуть» инфраструктуру, когда это потребуется. Делать это на своих мощностях, значит либо держать большой объем оборудования, которое не будет использоваться большую часть времени, либо ограничивать свои среды, тем самым потенциально снижая качество тестов, или скорость выхода приложения.
  4. Масштабируемость и «самолечение» – autoscaling & autohealing. Если ваша архитектура позволяет масштабироваться, то вы можете настроить правила автоматического масштабирования и восстановления, на основе триггеров систем мониторинга. После внедрения механизмов autohealing ваше приложение сможет самостоятельно восстанавливаться после сбоев, снижая время простоя до минимума.
  5. Наличие PaaS сервисов. Представим классическое приложение из нескольких стандартных компонентов: база данных, веб-интерфейс и само приложение, служба или сервис. Для хостинга такого приложения в своем периметре вам скорее всего понадобится несколько серверов. Если ваше приложение критично для бизнеса, оно обязано быть отказоустойчивым, – вы построите ДБ кластер или внедрите мирроринг, сделаете балансировщик нагрузки для веб-сервера и зарезервируете ресурсы для самого приложения. Помимо тестовых сред и для разработки, вам потребуется довольно много серверов и массивная инфраструктура. При переходе в облако вам будут доступны PaaS сервисы, и тогда те же задачи вы сможете реализовать, например, на DBaaS и контейнерах. Вы не будете разворачивать виртуальные машины, базы данных и другие компоненты – это больше не потребуется.
  6. Возможность построения гибрида. Если ваше приложение поддерживает микросервисную архитектуру, является cloud native, вы сможете легко балансировать между несколькими облаками. Популярная схема – бизнес-критичные данные хранить в своем периметре, веб-сервер и ДБ в публичных облаках, разделив данные таким образом, чтобы не нарушать закон о персональных данных. Вы не будете зависеть от одного облачного провайдера и получите возможность относительно легкой миграции из одного публичного облака в другое.

Все перечисленные преимущества, однако, могут быть перечеркнуты недостаточным планированием или непониманием принципов работы облачного хостинга.

Чек-лист: как избежать проблем

  1. Назначить архитектора миграции и других ответственных. Архитектор миграции – это специалист на уровне системного архитектора, ответственный за планирование и завершение всех аспектов миграции.
  2. Определить методику перехода. Нужно решить, будете вы переносить все приложение сразу или же по частям. Для этого определите связи между сервисами и поймите, какие из них зависят друг от друга. 
    У нас был кейс, в котором главной целью было снижение капитальных затрат на оборудование: переезд был инициирован финансовым, а не IT-отделом. Проект разрабатывал заказчик, покупая только IaaS. Был спланирован переезд пары десятков приложений с целью сократить количество физических серверов на собственной площадке на 70%. Они не учли, что при переходе в облако требования к качеству каналов передачи данных растут. Миграция приложений прошла нормально, все облачные сервисы работали штатно, без проблем и отказов – как и ожидалось. Однако, очень скоро стало очевидно, что скорость работы с приложениями сильно снизилась – ширины канала передачи данных не хватало, а частые аварии у операторов связи приводили к простоям. Изначальная цель миграции был достигнута – капитальные расходы значительно сократились, но при этом производительность приложений снизилась. Компании пришлось в срочном порядке менять сетевую инфраструктуру, увеличить пропускную способность интернет-каналов и улучшить их отказоустойчивость. Если бы они провели аудит до начала работ, этого бы удалось избежать.
  3. Выбрать одно облако или использовать несколько облаков. Если вы не хотите полностью зависеть от одного провайдера, можно задуматься о мультиклауд подходе – это когда ваша инфраструктура распределена между несколькими облаками для обеспечения высокой отказоустойчивости бизнес-критичных приложений.
  4. Установить KPI для облака. Возможно, вы уже определили некоторые ключевые показатели эффективности для своих приложений и служб, но применимы ли они для приложения или сервиса, когда они находятся в облаке? Правильные KPI должны демонстрировать, как проходит текущая миграция, выявляя видимые или невидимые проблемы, которые могут скрываться в вашем приложении.
  5. Определить базовые показатели эффективности. Чтобы отслеживать KPI, сначала вам нужно измерить ваши стандартные показатели производительности. Предыдущий пункт определяет, каких результатов вы хотите достичь. Здесь же вы определяете свою «норму».
  6. Расставить приоритеты для компонентов миграции. Нужно решить, будете вы переносить все приложение сразу или же по частям. Для этого определите связи между сервисами и поймите, какие из них зависят друг от друга.
  7. Создать план переноса данных. Перенос данных – одна из самых сложных частей миграции в облако. Расположение данных может существенно повлиять на производительность приложения.
  8. Переключить на продуктовую среду. Когда и как вы переключите производственную систему с устаревшего локального решения на новую облачную версию? Ответ зависит от сложности и архитектуры приложения, и особенно от архитектуры ваших данных и их хранилищ.
  9. Распределите мощности приложения. Облако оптимизировано для динамического распределения ресурсов, и когда вы распределяете ресурсы (например, серверы) статически, вы не пользуетесь преимуществами облака.

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

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

Послесловие

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

Читайте также:

Расскажите коллегам:
Комментарии
Генеральный директор, Москва

Александр, а что происходит с данными и возможностью продолжать работу, в случаях когда компания не может заплатить за услуги "облачного" провайдера/подрядчика . Деятельность компании-остановится, доступ к данным будет ограничен?  Каковы риски в части конфидициальности информации например, ("черная касса") и возможности продолжать работу без оплаты: свои мощности VS облако?

Руководитель, Москва

Почему-то говорят, что раз облако, то это стороннее.. Почему никто не говорит, что может быть и свое облако.

Генеральный директор, Москва
Максим Часовиков пишет:

Почему-то говорят, что раз облако, то это стороннее.. Почему никто не говорит, что может быть и свое облако.

Осталось в очередной раз уточнить, кто и что имеет в виду под облаком. Но 100% собственное облако тяжело обосновать. 

Руководитель, Москва
Евгений Равич пишет:
Осталось в очередной раз уточнить, кто и что имеет в виду под облаком. Но 100% собственное облако тяжело обосновать. 

Для меня важные совойства облачного сервиса: 
1. Прозрачность (то есть все равно как именно делается)
2. Децентрализованность (ресурсы распределены географически)
3. Нагрузка может налету диспетчеризироваться по ресурсам незаметно для пользователя
4. Легкое масштабирование
5. Навреное, это выводится из предыдущих - услуга продолжает оказываться (пусть и с бтлее низким качеством) если физически некоторое количество оборудования не доступно


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

Начальник участка, Москва

Прочитал статью. Взгрустнулось. Полез читать Маяковского "облако в штанах" прям побойчее намного. 

Аналитик, Москва

А всё-таки в классное время мы живём! Когда-то меня учили и я учил - создавайте резервные копии! Записал на диск, сохрани на дискету! А лучше на две! А самые сознательные - на три! При этом меня лично доставали работкник всяких отделов секретности - каждую дискету надо было учесть своеобразным способом. 

Нонче не то, что давеча.

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

Генеральный директор, Москва
Максим Часовиков пишет:
Евгений Равич пишет:
Осталось в очередной раз уточнить, кто и что имеет в виду под облаком. Но 100% собственное облако тяжело обосновать. 

Для меня важные совойства облачного сервиса: 
1. Прозрачность (то есть все равно как именно делается)
2. Децентрализованность (ресурсы распределены географически)
3. Нагрузка может налету диспетчеризироваться по ресурсам незаметно для пользователя
4. Легкое масштабирование
5. Навреное, это выводится из предыдущих - услуга продолжает оказываться (пусть и с бтлее низким качеством) если физически некоторое количество оборудования не доступно


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

Увы, это совсем не Private Cloud. Скорее, некая очень дорогая распределенная корпоративная инфраструктура.

Посмотрите дефиниции NIST.

Генеральный директор, Москва
Анатолий Курочкин пишет:

А всё-таки в классное время мы живём! Когда-то меня учили и я учил - создавайте резервные копии! Записал на диск, сохрани на дискету! А лучше на две! А самые сознательные - на три! При этом меня лично доставали работкник всяких отделов секретности - каждую дискету надо было учесть своеобразным способом. 

Нонче не то, что давеча.

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

С каждым днем всё актуальнее, но не сказал бы, что проще - много новых угроз. Можно пользоваться какими-то вариантами  правила 3-2-1. Можно придумать свои политики резервирования. Детали важны.

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

Аналитик, Москва
Евгений Равич пишет:
Анатолий Курочкин пишет:

А всё-таки в классное время мы живём! Когда-то меня учили и я учил - создавайте резервные копии! Записал на диск, сохрани на дискету! А лучше на две! А самые сознательные - на три! При этом меня лично доставали работкник всяких отделов секретности - каждую дискету надо было учесть своеобразным способом. 

Нонче не то, что давеча.

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

С каждым днем всё актуальнее, но не сказал бы, что проще - много новых угроз. Можно пользоваться какими-то вариантами  правила 3-2-1. Можно придумать свои политики резервирования. Детали важны.

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

Абсолютно согласен!

Генеральный директор, Москва
Анатолий Курочкин пишет:
Евгений Равич пишет:
Анатолий Курочкин пишет:

А всё-таки в классное время мы живём! Когда-то меня учили и я учил - создавайте резервные копии! Записал на диск, сохрани на дискету! А лучше на две! А самые сознательные - на три! При этом меня лично доставали работкник всяких отделов секретности - каждую дискету надо было учесть своеобразным способом. 

Нонче не то, что давеча.

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

С каждым днем всё актуальнее, но не сказал бы, что проще - много новых угроз. Можно пользоваться какими-то вариантами  правила 3-2-1. Можно придумать свои политики резервирования. Детали важны.

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

Абсолютно согласен!

Думали о таком сервисе хорошего качества для наших условий еще до короны. В отдельных географиях технически возможно, но финансовая модель достаточно (если не слишком) сложная.

Оставлять комментарии могут только зарегистрированные пользователи
Статью прочитали
Обсуждение статей
Все комментарии
Дискуссии
Все дискуссии
HR-новости
Две трети компаний переманивают чужих сотрудников

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

Эйджизм на рынке труда России снизился

Работодатели все чаще присматриваются к возрастным кандидатам.

60% подрабатывающих россиян не копят деньги системно

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

70% россиян обращают внимание на корпоративную культуру при выборе работодателя

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