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

1. Ошибки в оценке стоимости

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

И здесь компания совершает популярную ошибку в расчёте стоимости хостинга — за основу она берёт ТЗ, в котором перечислены текущие ресурсы этих серверов. Такой подход неверный, хоть и быстрый. Мало того, что железо по производительности сильно отличается от того, что можно в итоге получить в облаке, оно может быть не нагружено до конца, а это чревато включением в стоимость лишних ресурсов.

Или другой распространённый пример: компания, у которой раньше было только своё железо, не проводит тесты и переносит продуктивную среду в облако. Рынок платформ огромен, и как показывает практика, бизнесу сложно выбрать подходящий продукт, который будет точно соответствовать потребностям и затратам. Посмотрите на калькулятор ЕС2 инстансов Amazon Web Service, S3 от них же, или на многообразие Storage у Microsoft Azure — это десятки вариантов. Некоторые компании в этом случае выбирают самые производительные сервисы, но это может быть неоправданно дорого. А если остановиться на самых дешёвых вариантах, бизнес рискует столкнуться с серьёзными проблемами с производительностью, которые вскроются лишь позже, на пиковых нагрузках.

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

И последний риск при оценке стоимости — неправильно проведённые тесты. Предположим, что они прошли, ИТ выключил виртуальные машины и забыл про них. Однако выключенные инстансы в облаке стоят денег, и компания заплатит за хранилище (storage) как за включённые. Дополнительно провайдер может взять с клиента сумму за полный месяц использования лицензий.

Что поможет решить проблему

Планирование и тесты — залог успеха в корректной оценке стоимости. Тестирование можно провести самостоятельно или отдать на аутсорсинг внешним экспертам. В первом случае нужно будет уделить особое внимание выбору корректного тарифа, изучению контракта на хостинг и лицензионного соглашения. Рекомендую присмотреться к тарифам PAYG (pay as you go), если тесты непродолжительные. Во втором случае специалисты помогут разобраться в многообразии облачных сервисов и выбрать наиболее подходящий, что в дальнейшем сильно сократит бюджет на эксплуатацию.
При переходе в облако критичность каналов передачи данных возрастёт, поэтому их важно включать в расчёт.
В случае, когда у бизнеса только продуктивная среда без резервирования, понадобятся дополнительные мощности на случай серьёзного сбоя. Это нужно учитывать сразу.
Не нужно пренебрегать перепроверкой лицензионных соглашений или договоров на хостинг перед миграцией – часть информации может просто забыться за давностью лет. Это позволит избежать незапланированных затрат на покупку новых лицензий.

2. Проблемы с безопасностью

Бытует заблуждение о том, что, если провайдер отвечает за безопасность облака, значит, самой компании не нужно об этом заботиться. Это ошибочно. Да, провайдер отвечает за физическую безопасность в своих ЦОДах и облачной платформы, но не более того. Всё, что находится «поверх» платформы, — забота пользователя. Именно поэтому чаще всего киберинциденты в этих сферах случаются из-за внутренних причин, а не по вине поставщика.

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

Ещё одно заблуждение: при переходе в облако все данные бэкапятся. Однако, если пользователь случайно удалил виртуальную машину или проект/подписку, то это означает лишь одно — данные потеряны безвозвратно. Это может стать неприятным сюрпризом.

И третий момент: соблюдение законов о персональных данных — будь то GDPR или ФЗ 152 — это тоже забота компании, а не провайдера.

Что поможет решить проблему

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

3. Низкая производительность приложения или его компонентов после миграции

Переезд в облако «как есть», т. е. перенос виртуальных машин из вашего офиса в облако, – это плохая затея. По сути, это просто смена одного «офиса» на другой. Представим классическое приложение из нескольких стандартных компонентов: база данных, веб-интерфейс, само приложение, служба или сервис. Для хостинга в своём периметре, скорее всего, понадобится несколько серверов. Если это приложение критично для бизнеса, оно должно быть отказоустойчивым, а значит нужны ДБ кластер или мирроринг, балансировщик нагрузки для веб-сервера и резерв мощностей. Перенося это всё в облако, мы получали огромный пул ресурсов, которым надо управлять и поддерживать, но такое массивное решение не будет гибким.

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

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

Что поможет решить проблему

Самое главное – тщательно спланируйте всё «на берегу», определитесь с архитектурой, привлеките внешних экспертов, если у команды нет достаточного опыта в этой области.
К примеру, если задача – стать cloud independent, чтобы все данные и компоненты можно было развернуть быстро и в любой среде, лучше всего выбрать Infrastructure-as-Code (Iac), внедрить мониторинг и алертинг сервиса по приоритетным метрикам. На этой основе можно дополнительно реализовать механизмы autohealing и autoscaling – так приложение будет автоматически реагировать на изменения загрузки, а его доступность сильно вырастет.

4. Низкая доступность приложения

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

Что поможет решить проблему

Нужно перейти на микросервисную архитектуру, если это возможно. Многообразие публичных облаков позволяет легко заменить IaaS-, PaaS- или SaaS-сервис и при этом сильно сэкономить на поддержке.
Автоматизация лишней не будет, тем более все серьёзные публичные облака предлагают функциональность IaC. Это поможет быстро разворачивать инфраструктуру приложения, легко менять её компоненты и параметры, применять механизмы самовосстановления (autohealing) и автомасштабирования (autoscaling) при грамотной настройке метрики мониторинга, а также быстрее переходить от одного облачного провайдера к другому или даже строить гибридные решения.
Не стоит забывать про резервные системы, разделение на production, pre-production и тестовые среды. Напишите и протестируйте процедуры аварийного восстановления. Не формально опишите, а проверяйте их регулярно, тестируйте и изменяйте, если были изменение в вашем приложении. Используйте несколько географисеских зон доступности, не держите все ваши инстансы в одном регионе. Изучайте особенности конкретного облака и тестируйте все нововведения, не бросайтесь в них с головой несмотря на показатели SLA, которые вам транслирует провайдер.

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

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

Колесов Александр

руководитель подразделения Cloud & Infra

С чем мы столкнулись при миграции сервиса в облако: 4 главных проблемы и варианты их решения