Миграция в облако тесно связана с перемещением данных, настроек, приложений, операционных систем в виртуальный дата-центр облачного провайдера. Кажется, что это сложно и ненадежно, однако все больше компаний доверяют сервисы технологии IaaS. Например, в течение трех последующих лет 50% индийских организаций планируют переместить инфраструктуру в облако.
Рынок «идет» вверх — по прогнозу аналитического агентства Gartner, в 2017 году IaaS-сегмент вырастет на 36,8% и достигнет планки в 34,6 млрд долларов. Поэтому в сегодняшнем материале мы поговорим о том, на что компаниям обратить внимание, чтобы мигрировать инфраструктуру в облачную среду и избежать потенциальных рисков.
/ Flickr / goldswordfish / CC
Из-за объемов IT-инфраструктуры и миллиардов долларов, затрачиваемых каждый день на оборудование, программное обеспечение и поддерживание сервисов, переход от модели развертывания on-premise к облачной невозможно совершить за одну ночь.
При переносе IT-отделам компаний приходится решать, как поддерживать доступ к источникам данных — большинство сценариев миграции включают перенос информации с использованием бэкап-инструментов и систем восстановления в случае катастрофы (disaster recovery).
Большинство ошибок, которые подстерегают руководство компаний на этом пути, присущи любому крупному IT-проекту. Отсутствие плана миграции и схемы зависимости приложений — одни из самых популярных. Сюда же относятся инициация миграции без предварительных тестов, мнение, что все провайдеры одинаковые и просчеты в политиках безопасности.
Подробнее об этих типах рисков и как их избежать, мы расскажем далее.
Переход в облако совершают крупные компании и небольшие стартапы — 52% сегмента малого бизнеса обратились к облачной инфраструктуре. По данным International Data Corporation (IDC), каждая небольшая компания, которая использует облачные технологии, экономит значительные суммы. Организации также получают возможность управлять инфраструктурой из одной консоли, что упрощает взаимодействие и ускоряет доставку сервисов потребителям.
Существуют кейсы, демонстрирующие успешную миграцию IT-инфраструктуры в облако IaaS-провайдера. При этом часть компаний используют облако как вторичный плацдарм, где хранят «вторичные» сервисы, а другие — целиком отдают инфраструктуру на аутсорсинг и размещают там бизнес-критические системы.
Пример постепенной миграции в облако — поэтапная трансформация инфраструктуры Netflix. Об этом мы писали тут. Компания переводила сервисы в облако на протяжении нескольких лет, пересмотрев концепцию предоставления услуг.
В Netflix перенесли в облако платежную инфраструктуру и сервисы предоставления счетов, платформу Big Data, службы видеотрансляции, систему управления данными клиентов и др.
Российские компании также переходят в облачную среду. Delivery Club — сервис по доставке еды c полностью виртуализированной системой. В случае Delivery Club, облако упростило управление, поддержку и обеспечило надежность.
Мигрировал в облако провайдера и автомобильный холдинг «Терра-авто». Компания разместила в виртуальной среде телекоммуникационный компонент, почтовые сервисы и инструменты фильтрации трафика.
Одной из причин, почему эти компании перешли в облако, стало упрощение масштабирования. Облачная инфраструктура позволяет при необходимости увеличивать (уменьшать) количество серверных ресурсов. Такой подход важен при создании проектов, в которых нагрузка изменяется сезонно или постоянно увеличивается.
Организации могут перемещать ВМ с одной физической машины на другую. Это также повышает надежность: даже если один из серверов выходит из строя, ВМ продолжает работу на другом. Все это исключает большинство ошибок при настройке инфраструктуры.
Для успешной миграции нужно: разработать план, сформировать облачную инфраструктуру, протестировать её, перенести данные и запустить сервис.
Однако хотелось бы отметить, что переезд в облако — это процесс индивидуальный для каждой организации, потому некоторые технические вопросы решаются исходя из нужд компании.
Шаг 1. Перед тем как начать миграцию, нужно провести инвентаризацию IT-окружения, чтобы построить текущую картину инфраструктуры. Это позволит понять, какие приложения подходят для перемещения в облако. Для этого нужно категоризировать приложения один за другим на основании атрибутов. При создании каталога применяют два подхода: «сверху-вниз», который позволяет понять, где приложения принесут пользу бизнесу, и «снизу-вверх», фокусирующийся на технических возможностях.
Подход «сверху-вниз» следует парадигме трансформации бизнеса с целью реализации максимального потенциала, поэтому основывается на оценке технических аспектов и аспектов безопасности каждого приложения:
После проведения анализа эти показатели формируют счет, которая отражает сложность переноса того или иного приложения в облако. Подход «сверху-вниз» также включат оценку финансовой выгоды: TCO, сезонные скачки активности пользователей, необходимые уровни масштабируемости, отказоустойчивость.
Одновременно может применяться подход «снизу-вверх». Как уже было отмечено, он фокусируется на технических требованиях, поэтому показатели для оценки находятся в базе данных управления конфигурацией (CMDB):
Закончив эту оценку, IT-команда составляет список приоритетов, то есть определяет, какие приложения более других выиграют от миграции в облако. Эксперты рекомендуют начинать переход в облачную среду с простых проектов, постепенно увеличивая сложность.
Кроме того, еще в самом начале нужно решить, какая облачная модель лучше подойдет для реализации проекта: публичное, частное или гибридное облако. Согласно статистике, за последние годы популярность в корпоративной среде набирают гибридные облака.
Шаг 2. Это этап выбора облачного провайдера с тестированием возможностей облачной площадки. Оцените надежность площадки провайдера и проверьте её на соответствие требованиям компании. Надежность облачной платформы зависит от используемого оборудования, поэтому стоит обратить внимание на актуальность «железа», его класс и проверить наличие резервирования (не должно быть единой точки отказа).
Также большинство коммерческих дата-центров заявляют, что их инфраструктура соответствует стандарту по категории надежности Tier III. Однако это не всегда так. Проверить сервис-провайдера просто: запросите сертификаты, подтвержденные Uptime Institute. UTI сертификаты для российских дата-центров находятся на сайте организации.
После того как вы определились с провайдером, в обязательном порядке проведите тестирование облачной площадки и тестовую миграцию. Например, мы в компании «IT-ГРАД» по запросу клиента предоставляем бесплатный доступ VMware vCloud на две недели. Это позволит вам убедиться, что все сервисы работают правильно.
Шаг 3. При переносе IT-инфраструктуры в облако следует выбрать миграционный путь: постепенный или полный переход.
Постепенная миграция подходит для крупных компаний с разветвлённой инфраструктурой. Такой переход выполняется на протяжении нескольких месяцев или даже лет (например, случай компании Netflix, о которой мы говорили выше). В этом случае составляется поэтапный план переноса с указанием критичных сервисов и приоритетов.
При полной миграции инфраструктура компании переносится за несколько дней. Здесь составлять дорожную карту нет необходимости, но расписать план работ все же стоит.
Таким образом, выбор способа миграции зависит от размера организации и сложности инфраструктуры. Малому и среднему бизнесу подойдет полная миграция. Крупным компаниям стоит обратить внимание на частичную миграцию. Важно помнить, что перенос сложного окружения в облако может потребовать переработки приложений, чтобы сохранить или повысить скорость работы и безопасность.
Помимо способа миграции, также стоит определиться со временем переноса. Для этого необходимо понять, когда критичные сервисы используются слабо и запланировать миграцию на этот момент.
Шаг 4. Далее, можно приступать к миграции, придерживаясь выбранной стратегии. После остается выполнить проверку и тестирование сервисов. Если ошибок нет — сервисы выводятся в продакшн.
/ Flickr / Peter Stevens / CC
Выбор способа миграции в облако зависит от конкретной ситуации, например, текущей инфраструктуры компании и возможностей. Это может быть перенос физической IT-инфраструктуры в виртуальную среду, перенос локальной виртуальной инфраструктуры в облако, переход от одного провайдера к другому и др. Ниже рассмотрим возможные варианты миграции подробнее. Часть из них выполняется с помощью инструментов компании VMware.
Импорт-экспорт ВМ
Если у компании уже есть виртуальная инфраструктура на базе VMware, то её виртуальное окружение позволяет «перекинуть» сразу несколько ВМ.
Все параметры виртуальных машин «упаковываются» в файлы формата OVF/OVA. Затем они используются экспорта на платформу виртуализации VMware vSphere и другие. Переносить приложения в облако также позволяет VMware vCloud Connector. Как работать с этим инструментом ми писали в нашем блоге.
Миграция на уровне сервисов
Провайдер создает у себя дублирующий сервис. Этот сервис синхронизируется с локальным сервисом клиента. Как пример можно привести миграцию Active Directory. Облачный провайдер разворачивает у себя необходимое количество ВМ, после чего база данных реплицируется в облако вместе с контроллерами.
«Горячее» и «холодное» клонирование
При «горячем» клонировании выполняется перенос работающего узла. Оригинальный сервер останавливается только в момент переключения. Утилита vCenter Converter автоматически определяет диски, разделы и сетевые интерфейсы, оперативную память и процессоры. На основе этих данных создается новая виртуальная машина на ESXi-хосте.
VMware vCenter Converter также может выполнять «холодное» клонирование. Этот вид клонирования рекомендован для миграции Active Directory и почтовых серверов. Машина останавливается, создается образ жесткого диска и выполняется конвертация в ВМ.
Установка с нуля
Провайдер создает ВМ, и на неё накатывается операционная система и необходимое программное обеспечение. Затем происходит переключение клиентов.
При миграции в облако компании порой не уделяют внимания некоторым деталям. Давайте рассмотрим самые популярные ошибки, которые совершают организации при переходе к облачной инфраструктуре.
«Все провайдеры одинаковые»
Это опасное предположение. Хотя каждый облачный провайдер предлагает для работы виртуальные машины и несколько типов хранилищ, они отличаются тонкостями, моделями оплаты и качеством сервиса. Сюда же относится готовность провайдера отработать в случае непредвиденных ситуаций, а также качество пользовательской поддержки.
Например, мы в «ИТ-ГРАД» предлагаем несколько площадок для размещения данных. Клиент может создавать несколько виртуальных дата-центров и настраивать параметры производительности и безопасности для каждого. Мы также предлагаем разные модели оплаты, включая Pay-As-You-Go.
Другая ошибка, которая является своеобразным следствием, — это отказ от нативных облачных сервисов и использование собственных инстансов виртуальных машин. Эту ошибку легко допустить, поскольку кажется, что это позволит избежать привязки к вендору. Однако она приводит к тому, что компании изобретают велосипед, игнорируя одно из главных достоинств облаков: высококачественные сервисы, которые можно создавать и использовать без дополнительных настроек.
Нет схемы зависимости приложений
При миграции в облако уделите внимание схеме зависимости приложений. Как они связаны друг с другом и инфраструктурой в целом. Представьте эту схему в виде карты зависимостей. Если оказывается, что несколько приложений обращаются к одной базе данных, нужно проработать механизм комбинированного перемещения в облако. Иначе работа приложений нарушится.
Например, как говорят в «Хантердон Медикал Сентер», они совершили эту ошибку во время первой миграции систем в облако. Сотрудники не провели глубокий анализ приложений. Специалисты переносили почтовую систему в G Suite, однако не учли, что именно пользователям было нужно от старой системы, и не проанализировали, как она себя поведет в новом окружении.
Нет плана миграции
До начала миграции ответьте для себя на вопросы: что вы будете переносить в облако, в каком порядке, когда и за сколько? Составьте план переноса.
Эксперты из технологической компании DoubleHorn также советуют для составления плана прибегнуть к помощи третьих лиц и консалтинговых фирм. Они помогут найти и применить лучшие практики и избежать дорогостоящих ошибок.
Забыли про политики безопасности
Перевод инфраструктуры в облако часто ведет к неполноте политик безопасности, которые не согласуются с новыми стандартами. Все организации имеют требования к безопасности для авторизации пользователей, настройки приложений и мониторинга систем. Эти политики зачастую не изменяются, однако при работе с облаком они должны быть усилены. Лорен Худзиак (Loren Hudziak) из Google отмечает, что организациям нужно обратить внимание на безопасность по всем фронтам, чтобы получить все преимущества облачной инфраструктуры.
Запуск без тестирования
Перед миграцией в облако нужно выбрать надежного и проверенного хостинг-провайдера. О тонкостях выбора и о том, на что обращать внимание, мы рассказывали в одном из наших материалов. Выбрав облачного-провайдера, запросите тестовый доступ к облачной площадке. Проведите тесты.
По данным облачных провайдеров, многие организации, мигрирующие в облако, не имеют установленного плана восстановления в случае катастрофы. А многие из тех, кто его имеет, никогда его не тестировали.
Когда округ Кинг в Вашингтоне, мигрировал в облако бэкап-систему, они провели тестирование того, как данные передаются в облако. Все работало хорошо. Однако они не протестировали их восстановление. По словам Тэмуджина Бейкера (Temujin Baker), руководителя по работе с архитектурой приложений, они не учли особенности работы с облаком, когда сервису требуется время на получение данных.
Поэтому внимание к деталям и оценка результатов — важные компоненты процесса миграции в облако. Если следовать установленным рекомендациям и действовать по плану, конечный результат будет ожидаемым.
P.S. Еще несколько материалов по теме из нашего блога:
Рынок «идет» вверх — по прогнозу аналитического агентства Gartner, в 2017 году IaaS-сегмент вырастет на 36,8% и достигнет планки в 34,6 млрд долларов. Поэтому в сегодняшнем материале мы поговорим о том, на что компаниям обратить внимание, чтобы мигрировать инфраструктуру в облачную среду и избежать потенциальных рисков.
/ Flickr / goldswordfish / CC
Что может пойти не так
Из-за объемов IT-инфраструктуры и миллиардов долларов, затрачиваемых каждый день на оборудование, программное обеспечение и поддерживание сервисов, переход от модели развертывания on-premise к облачной невозможно совершить за одну ночь.
При переносе IT-отделам компаний приходится решать, как поддерживать доступ к источникам данных — большинство сценариев миграции включают перенос информации с использованием бэкап-инструментов и систем восстановления в случае катастрофы (disaster recovery).
Большинство ошибок, которые подстерегают руководство компаний на этом пути, присущи любому крупному IT-проекту. Отсутствие плана миграции и схемы зависимости приложений — одни из самых популярных. Сюда же относятся инициация миграции без предварительных тестов, мнение, что все провайдеры одинаковые и просчеты в политиках безопасности.
Подробнее об этих типах рисков и как их избежать, мы расскажем далее.
Кто уже с этим справился
Переход в облако совершают крупные компании и небольшие стартапы — 52% сегмента малого бизнеса обратились к облачной инфраструктуре. По данным International Data Corporation (IDC), каждая небольшая компания, которая использует облачные технологии, экономит значительные суммы. Организации также получают возможность управлять инфраструктурой из одной консоли, что упрощает взаимодействие и ускоряет доставку сервисов потребителям.
Существуют кейсы, демонстрирующие успешную миграцию IT-инфраструктуры в облако IaaS-провайдера. При этом часть компаний используют облако как вторичный плацдарм, где хранят «вторичные» сервисы, а другие — целиком отдают инфраструктуру на аутсорсинг и размещают там бизнес-критические системы.
Пример постепенной миграции в облако — поэтапная трансформация инфраструктуры Netflix. Об этом мы писали тут. Компания переводила сервисы в облако на протяжении нескольких лет, пересмотрев концепцию предоставления услуг.
В Netflix перенесли в облако платежную инфраструктуру и сервисы предоставления счетов, платформу Big Data, службы видеотрансляции, систему управления данными клиентов и др.
Российские компании также переходят в облачную среду. Delivery Club — сервис по доставке еды c полностью виртуализированной системой. В случае Delivery Club, облако упростило управление, поддержку и обеспечило надежность.
Мигрировал в облако провайдера и автомобильный холдинг «Терра-авто». Компания разместила в виртуальной среде телекоммуникационный компонент, почтовые сервисы и инструменты фильтрации трафика.
Одной из причин, почему эти компании перешли в облако, стало упрощение масштабирования. Облачная инфраструктура позволяет при необходимости увеличивать (уменьшать) количество серверных ресурсов. Такой подход важен при создании проектов, в которых нагрузка изменяется сезонно или постоянно увеличивается.
Организации могут перемещать ВМ с одной физической машины на другую. Это также повышает надежность: даже если один из серверов выходит из строя, ВМ продолжает работу на другом. Все это исключает большинство ошибок при настройке инфраструктуры.
Еще несколько практических кейсов
- КУБИТ: организация комплексных IT-решений с использованием IaaS-облака
- Оператор каршеринга BelkaCar использует облако для обеспечения отказоустойчивости
- Сеть универсамов «АБК»: опыт использования облака IaaS
- Использование IaaS компанией S7 Airlines
- Использование IaaS облачным провайдером для предоставления SaaS-сервиса
Как мигрировать
Для успешной миграции нужно: разработать план, сформировать облачную инфраструктуру, протестировать её, перенести данные и запустить сервис.
Однако хотелось бы отметить, что переезд в облако — это процесс индивидуальный для каждой организации, потому некоторые технические вопросы решаются исходя из нужд компании.
Шаг 1. Перед тем как начать миграцию, нужно провести инвентаризацию IT-окружения, чтобы построить текущую картину инфраструктуры. Это позволит понять, какие приложения подходят для перемещения в облако. Для этого нужно категоризировать приложения один за другим на основании атрибутов. При создании каталога применяют два подхода: «сверху-вниз», который позволяет понять, где приложения принесут пользу бизнесу, и «снизу-вверх», фокусирующийся на технических возможностях.
Подход «сверху-вниз» следует парадигме трансформации бизнеса с целью реализации максимального потенциала, поэтому основывается на оценке технических аспектов и аспектов безопасности каждого приложения:
- Категоризация данных, требования к безопасности;
- Сложность интерфейса, аутентификация, структура данных, требования к латентности;
- Требования к работе (SLA), интеграция, мониторинг.
После проведения анализа эти показатели формируют счет, которая отражает сложность переноса того или иного приложения в облако. Подход «сверху-вниз» также включат оценку финансовой выгоды: TCO, сезонные скачки активности пользователей, необходимые уровни масштабируемости, отказоустойчивость.
Одновременно может применяться подход «снизу-вверх». Как уже было отмечено, он фокусируется на технических требованиях, поэтому показатели для оценки находятся в базе данных управления конфигурацией (CMDB):
- Память, число процессоров, занимаемое место на диске операционной системой;
- Платы сетевого интерфейса;
- IPv6;
- Поддержка доменов;
- Наличие сторонних компонентов и пакетов приложений.
Закончив эту оценку, IT-команда составляет список приоритетов, то есть определяет, какие приложения более других выиграют от миграции в облако. Эксперты рекомендуют начинать переход в облачную среду с простых проектов, постепенно увеличивая сложность.
Кроме того, еще в самом начале нужно решить, какая облачная модель лучше подойдет для реализации проекта: публичное, частное или гибридное облако. Согласно статистике, за последние годы популярность в корпоративной среде набирают гибридные облака.
Шаг 2. Это этап выбора облачного провайдера с тестированием возможностей облачной площадки. Оцените надежность площадки провайдера и проверьте её на соответствие требованиям компании. Надежность облачной платформы зависит от используемого оборудования, поэтому стоит обратить внимание на актуальность «железа», его класс и проверить наличие резервирования (не должно быть единой точки отказа).
Также большинство коммерческих дата-центров заявляют, что их инфраструктура соответствует стандарту по категории надежности Tier III. Однако это не всегда так. Проверить сервис-провайдера просто: запросите сертификаты, подтвержденные Uptime Institute. UTI сертификаты для российских дата-центров находятся на сайте организации.
После того как вы определились с провайдером, в обязательном порядке проведите тестирование облачной площадки и тестовую миграцию. Например, мы в компании «IT-ГРАД» по запросу клиента предоставляем бесплатный доступ VMware vCloud на две недели. Это позволит вам убедиться, что все сервисы работают правильно.
Шаг 3. При переносе IT-инфраструктуры в облако следует выбрать миграционный путь: постепенный или полный переход.
Постепенная миграция подходит для крупных компаний с разветвлённой инфраструктурой. Такой переход выполняется на протяжении нескольких месяцев или даже лет (например, случай компании Netflix, о которой мы говорили выше). В этом случае составляется поэтапный план переноса с указанием критичных сервисов и приоритетов.
При полной миграции инфраструктура компании переносится за несколько дней. Здесь составлять дорожную карту нет необходимости, но расписать план работ все же стоит.
Таким образом, выбор способа миграции зависит от размера организации и сложности инфраструктуры. Малому и среднему бизнесу подойдет полная миграция. Крупным компаниям стоит обратить внимание на частичную миграцию. Важно помнить, что перенос сложного окружения в облако может потребовать переработки приложений, чтобы сохранить или повысить скорость работы и безопасность.
Помимо способа миграции, также стоит определиться со временем переноса. Для этого необходимо понять, когда критичные сервисы используются слабо и запланировать миграцию на этот момент.
Шаг 4. Далее, можно приступать к миграции, придерживаясь выбранной стратегии. После остается выполнить проверку и тестирование сервисов. Если ошибок нет — сервисы выводятся в продакшн.
/ Flickr / Peter Stevens / CC
Инструменты и способы миграции
Выбор способа миграции в облако зависит от конкретной ситуации, например, текущей инфраструктуры компании и возможностей. Это может быть перенос физической IT-инфраструктуры в виртуальную среду, перенос локальной виртуальной инфраструктуры в облако, переход от одного провайдера к другому и др. Ниже рассмотрим возможные варианты миграции подробнее. Часть из них выполняется с помощью инструментов компании VMware.
Импорт-экспорт ВМ
Если у компании уже есть виртуальная инфраструктура на базе VMware, то её виртуальное окружение позволяет «перекинуть» сразу несколько ВМ.
Все параметры виртуальных машин «упаковываются» в файлы формата OVF/OVA. Затем они используются экспорта на платформу виртуализации VMware vSphere и другие. Переносить приложения в облако также позволяет VMware vCloud Connector. Как работать с этим инструментом ми писали в нашем блоге.
Миграция на уровне сервисов
Провайдер создает у себя дублирующий сервис. Этот сервис синхронизируется с локальным сервисом клиента. Как пример можно привести миграцию Active Directory. Облачный провайдер разворачивает у себя необходимое количество ВМ, после чего база данных реплицируется в облако вместе с контроллерами.
«Горячее» и «холодное» клонирование
При «горячем» клонировании выполняется перенос работающего узла. Оригинальный сервер останавливается только в момент переключения. Утилита vCenter Converter автоматически определяет диски, разделы и сетевые интерфейсы, оперативную память и процессоры. На основе этих данных создается новая виртуальная машина на ESXi-хосте.
VMware vCenter Converter также может выполнять «холодное» клонирование. Этот вид клонирования рекомендован для миграции Active Directory и почтовых серверов. Машина останавливается, создается образ жесткого диска и выполняется конвертация в ВМ.
Установка с нуля
Провайдер создает ВМ, и на неё накатывается операционная система и необходимое программное обеспечение. Затем происходит переключение клиентов.
Риски при миграции и как их избежать
При миграции в облако компании порой не уделяют внимания некоторым деталям. Давайте рассмотрим самые популярные ошибки, которые совершают организации при переходе к облачной инфраструктуре.
«Все провайдеры одинаковые»
Это опасное предположение. Хотя каждый облачный провайдер предлагает для работы виртуальные машины и несколько типов хранилищ, они отличаются тонкостями, моделями оплаты и качеством сервиса. Сюда же относится готовность провайдера отработать в случае непредвиденных ситуаций, а также качество пользовательской поддержки.
Например, мы в «ИТ-ГРАД» предлагаем несколько площадок для размещения данных. Клиент может создавать несколько виртуальных дата-центров и настраивать параметры производительности и безопасности для каждого. Мы также предлагаем разные модели оплаты, включая Pay-As-You-Go.
Другая ошибка, которая является своеобразным следствием, — это отказ от нативных облачных сервисов и использование собственных инстансов виртуальных машин. Эту ошибку легко допустить, поскольку кажется, что это позволит избежать привязки к вендору. Однако она приводит к тому, что компании изобретают велосипед, игнорируя одно из главных достоинств облаков: высококачественные сервисы, которые можно создавать и использовать без дополнительных настроек.
Нет схемы зависимости приложений
При миграции в облако уделите внимание схеме зависимости приложений. Как они связаны друг с другом и инфраструктурой в целом. Представьте эту схему в виде карты зависимостей. Если оказывается, что несколько приложений обращаются к одной базе данных, нужно проработать механизм комбинированного перемещения в облако. Иначе работа приложений нарушится.
Например, как говорят в «Хантердон Медикал Сентер», они совершили эту ошибку во время первой миграции систем в облако. Сотрудники не провели глубокий анализ приложений. Специалисты переносили почтовую систему в G Suite, однако не учли, что именно пользователям было нужно от старой системы, и не проанализировали, как она себя поведет в новом окружении.
Нет плана миграции
До начала миграции ответьте для себя на вопросы: что вы будете переносить в облако, в каком порядке, когда и за сколько? Составьте план переноса.
Эксперты из технологической компании DoubleHorn также советуют для составления плана прибегнуть к помощи третьих лиц и консалтинговых фирм. Они помогут найти и применить лучшие практики и избежать дорогостоящих ошибок.
Забыли про политики безопасности
Перевод инфраструктуры в облако часто ведет к неполноте политик безопасности, которые не согласуются с новыми стандартами. Все организации имеют требования к безопасности для авторизации пользователей, настройки приложений и мониторинга систем. Эти политики зачастую не изменяются, однако при работе с облаком они должны быть усилены. Лорен Худзиак (Loren Hudziak) из Google отмечает, что организациям нужно обратить внимание на безопасность по всем фронтам, чтобы получить все преимущества облачной инфраструктуры.
Запуск без тестирования
Перед миграцией в облако нужно выбрать надежного и проверенного хостинг-провайдера. О тонкостях выбора и о том, на что обращать внимание, мы рассказывали в одном из наших материалов. Выбрав облачного-провайдера, запросите тестовый доступ к облачной площадке. Проведите тесты.
«Если клиент, разворачивая инфраструктуру, решает установить приложения, не поддерживающие cloud-архитектуру и заточенные только на on-premise-инсталляцию, провал гарантирован, — говорит Екатерина Юдина, руководитель проекта, контент-инженер компании «IT-ГРАД». — Чтобы избежать подобной ситуации, поставщик услуг предлагает возможность бесплатного и заблаговременного тестирования».
По данным облачных провайдеров, многие организации, мигрирующие в облако, не имеют установленного плана восстановления в случае катастрофы. А многие из тех, кто его имеет, никогда его не тестировали.
Когда округ Кинг в Вашингтоне, мигрировал в облако бэкап-систему, они провели тестирование того, как данные передаются в облако. Все работало хорошо. Однако они не протестировали их восстановление. По словам Тэмуджина Бейкера (Temujin Baker), руководителя по работе с архитектурой приложений, они не учли особенности работы с облаком, когда сервису требуется время на получение данных.
Поэтому внимание к деталям и оценка результатов — важные компоненты процесса миграции в облако. Если следовать установленным рекомендациям и действовать по плану, конечный результат будет ожидаемым.
P.S. Еще несколько материалов по теме из нашего блога:
ArizuTechi
Очень полезная статья! А как вы считаете? Малый бизнес: стоит ли переносить ИТ-инфраструктуру в облако? Допустим на примере салона красоты? Чтобы приложениям, инфраструктуре, платформе и сервисам быть доступными удалённо с помощью интернет-соединения, с любого устройства.
it_man Автор
Добрый день! Спасибо, что читаете.
Все зависит от ваших задач. Мы всегда рады обсудить.
Можете написать нам сразу на общую почту info@it-grad.ru