Миграция в облака: семь шагов вашего бизнеса

Первый шаг - определение бизнес-задач вашей компании и определение возможных ограничений по миграции в облака

Оцените зону применения или очертите границы использования облачных ресурсов у себя в компании. Если вы новая компания или стартап, вам смело можно начинать пользоваться решениями под ключ, например, VDI (виртуальными рабочими местами) из облака. Можно также использовать услуги по предоставлению сервиса почты, офисного ПО, видеоконференцсвязи или корпоративного мессенджера. Пользуются популярностью услуги облачных CRM и ERP.

Руководитель отдела облачных сервисов компании «Онланта» (группа компаний ЛАНИТ) Олег Коновалов

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

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

Второй шаг – правильный сайзинг виртуальных ресурсов

Следует определить параметры производительности и объем нужной вам облачной инфраструктуры. Необходимые виртуальные ресурсы могут не соответствовать один к одному физической инфраструктуре. Почему?

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

Третий шаг – выбор облачного провайдера

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

У многих руководителей может возникнуть вопрос: выбирать ли международную компанию или российского провайдера. Надо иметь в виду следующие моменты.

1. У зарубежных компаний может не быть полноценной русскоговорящей техподдержки.
2. В случае необходимости изменения архитектуры облака под ваши требования российские провайдеры, как правило, готовы обеспечить участие своих ИТ-архитекторов для планирования инфраструктуры. Они же проводят сайзинг, составляют календарный план миграций.
3. Российские компании лучше понимают специфику нашего бизнеса в целом: требования законодательства, протоколы ГОСТа о передаче данных, требования о хранении персональных данных.
4. Уровень компетенции российских инженеров уже давно не уступает профессиональной подготовке специалистов в международных компаниях. Мы участвуем в международных конференциях и видим это. Наши вопросы к зарубежным вендорам нередко помогают иностранным партнерам развивать свои продукты. Например, один из ведущих производителей систем виртуализации неоднократно вносил обновления в свои решения после обработки наших запросов.
5. Наконец, российский провайдер часто обладает большей гибкостью и готовностью подстраиваться под заказчика в плане предоставления услуг.

Главный совет – если вы решили довериться российскому партнеру, то он должен иметь имя. Почти любая компания представит SLA с красивыми цифрами доступности. Но не каждая компания может обеспечить реальную надежность, так как часто гарантии доступности касаются только гипервизора, и не учитывают доступность сети и СХД. Серьезный облачный провайдер имеет большие репутационные риски. При современных методах миграции виртуальных мощностей осуществить перенос инфраструктуры от одного провайдера к другому – несложное дело. Именно для защиты от репутационных рисков компании готовы вкладывать средства в современные и надёжные аппаратные и программные средства защиты, мониторинга и анализа, которые позволят им оказывать качественный сервис. В первую очередь, стоит обратить внимание на компании, которые не стесняются и не боятся работать на площадках СМИ, рассказывать о своих решениях, выслушивать комментарии аудитории и давать адекватную и конструктивную обратную связь. Выбрав такого провайдера, вы всегда будете уверены, что не останетесь наедине с одним лишь менеджером проекта, который может быть и не вполне компетентным.

Четвертый шаг – уточнение деталей

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

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

Пятый шаг - юридические договоренности с партнером

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

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

Как только ТКП согласовано с вашей стороны и вы согласны работать с выбранным провайдером, можете переходить к подготовке договора. Не забудьте про соглашение об уровне сервиса (SLA), в котором должна быть зафиксирована ответственность исполнителя и все параметры предоставляемого сервиса, которые вам были обещаны.

После подписания всех необходимых документов начинается реализация календарного плана миграции.

Шестой шаг – выбор способа миграции и миграция

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

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

Способы миграции зависят от требований к доступности информационной системы и её особенностей. У нас были проекты по переносу информационной системы с десятками терабайт данных, при этом нельзя было допустить, чтобы система не работала более 2 часов. Приходилось готовить полную копию системы и 2 часа использовать только на переключение сервисов.

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

Седьмой шаг – не понравилось? Возвращайтесь!

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

Мигрировать всё обратно можно. Я не буду говорить, что это простой процесс. Обратная миграция – масштабный проект, о котором лучше заранее предупредить облачного провайдера, чтобы он смог сразу создать все необходимые для этого условия.

Автор: Олег Коновалов, руководитель отдела облачных сервисов компании «Онланта» (группа компаний ЛАНИТ)