Миграция в облако: как обеспечить безопасность данных и стабильную работу системы

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

Вместе с тем, организация миграции информационной системы с локальной платформы в облако содержит немало нюансов, о которых нам рассказал руководитель департамента DevOps компании DBI Геннадий Шуров.

Сколько времени занимает переход в облако IT-инфраструктуры предприятия? От чего зависят сроки?

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

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

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

А пропускать какие-то этапы мы обычно не советуем, так это чревато ошибками, сбоями. Да, есть компании, для которых ограниченные возможности информационной инфраструктуры на период миграции в облако не являются критичными. Но для других корпораций, где цифровые сервисы работают в формате 24/7, такой вариант неприемлем.

Что, как правило, переносят в облако?

— Классический вариант – полная миграция информационной системы. Но, самое простое, с чего чаще всего начинают, это перенос в облако резервных копий, своего рода «слепок» системы для восстановления, если что-то происходит с основной системой.

Следующий уровень — «холодное» хранение данных, то есть перенос самых объемных данных, которые дорого и сложно хранить локально.

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

С какими сложностями сталкиваются специалисты DBI, осуществляя проекты миграции в облако?

— Нюансов довольно много.

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

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

— Да, нюанс миграции связан с общим стремлением клиента к модернизации информационной системы.

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

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

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

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

 Может ли компания, опираясь на силы своего IT-отдела, перейти в облако?

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

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

Переход в облако осуществлен что дальше? Клиенту еще необходима наша техподдержка?

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

Иногда клиент работает в облаке в формате IaaS (Infrastructure as a Service), где инфраструктура выступает как услуга.

Другой вариант —  как услуга используется платформа PaaS (Platform as a Service). Примером таких систем является база данных, как сервис или kubernetes кластер, управляемый облачным провайдером.

Наконец, есть SaaS (Software as a Service) — модель предоставления программного обеспечения, при которой пользователи получают доступ к готовым приложениям онлайн, не имея доступа к инфраструктуре под приложениями.

В любом случае, после миграции определенные компетенции по работе в облаке у IT-отдела компании должны появиться. Ну, а если требуется более серьезная помощь, DBI всегда на связи — contact@DBI.ru.