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

Основные этапы миграции в облако

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

1. Проверка и выбор облачной модели

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

Модель. Выбор подходящей именно вам модели облака (публичное, частное или гибридное) — это важный момент. Малому и среднему бизнесу зачастую более выгодна гибридная модель.

2. Тестовая миграция и проверка облака

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

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

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

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

3. Дорожная карта миграции

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

Выбор правильного времени для миграции часто может гарантировать успех всей деятельности. Если вы счастливый обладатель большой и сложной инфраструктуры, миграция будет «всегда не вовремя». Поэтому важно выделить особо критические элементы, понять, в какой период времени они менее всего используются (или — в идеале — не используются) и запланировать миграцию именно на этот период. Если у вас есть свой собственный дата-центр (и соответственно частное облако), полный единовременный переход может быть слишком рискованным, учитывая вероятность полного отказа системы. Стоит двигаться поэтапно. Например, при переносе почтовой системы в облако имеет смысл оставить локальным хранилище данных, а также заранее уточнить у поставщика облачных услуг, какие конкретно меры и в какие сроки будут им предприняты для восстановления работоспособности системы в случае форс-мажора.

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

Безопасность в облаках

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

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

Всегда проверяйте поставщика облачного сервиса. Для этого задайте себе следующие вопросы:

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

Доверяйте действиям, а не словам.

Основные моменты для любой стратегии миграции в облако

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

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

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

Производительность приложений в облаке

Чтобы не растерять производительность, выбирайте поставщиков с надежными резервными каналами, трезво оценив, какого плана услуги они предоставляют, в какое время, и в каком объеме.

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

Заключите соглашение об уровне услуг. «Service Level Agreement» (SLA)— термин методологии ITIL, обозначающий формальный договор между заказчиком услуги и её поставщиком. Профессиональные поставщики облачных услуг предоставляют условия, включающие круглосуточную поддержку. Таким образом, например, аппаратный сбой на стороне подрядчика перестает быть проблемой заказчика. Но могут существовать расхождения между тем, что поставщик услуг готов сделать, чтобы решить вашу проблему, и тем, что поставщик может делать в рамках выбранного вами плана подписки. Конфликт интересов становится явным в тот момент, когда вы хотите получить «подписочный» платеж, а поставщик выставляет счет за ресурсы по факту их использования. Выбирая поставщика, стоит учесть данную особенность, и, повторюсь, тщательно изучить SLA. Разработайте план Б на случай, если потребуется расширить инфраструктуру.

Планируйте периоды пиковой нагрузки. Часы пик бывают не только у вас, но и у провайдеров, и «веселье» начинается, когда такие времена наступают у вас обоих. Важно иметь план Б и на этот случай.

Затраты при переходе на облачные технологии: что входит в уравнение?

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

Электричество. Для стран, где электричество стоит дорого (т. е. для большинства стран), это очень важная часть уравнения. В этом случае переход на облачные технологии является чрезвычайно эффективным, потому что за деньги, которые вы тратите на 10 реальных серверов, можно получить 20–30 виртуальных.

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

Интеграция. Если облако является публичным, продумайте для себя ответы на следующие вопросы:

  • Каким образом пользователи будут иметь доступ к системам, которые находятся не в локальной сети, а в Интернете?
  • Какие технологии и сетевое оборудование следует использовать?
  • И, наконец, как команда поддержки инфраструктуры сможет это реализовать?

Когда речь идет о гибридном облаке, тщательно спланируйте и продумайте интеграцию между публичным и локальным облаками. Вопросы для проработки:

  • Каким образом удастся совместить локальное и публичное облако?
  • Будут ли все приложения работать так, как задумано?
  • Какой будет реакция пользователей на фактически двойную инфраструктуру?

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

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

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

Автор статьи — ведущий системный инженер компании Itransition.