Облачный атлас. Как избежать ошибок при миграции в cloud-среду

По данным IDC, российский рынок облачных решений (1 млрд долларов) составляет менее 1% от международного, но растёт очень быстро. Cloud-решения находятся на вершине технологического хайпа и могут решить множество актуальных бизнес-задач.

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

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

Несоответствие результата ожиданиям

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

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

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

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

Экономия случается не всегда

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

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

Так производитель минеральных вод «Холдинг Аква» решил перейти на облачный сервис Selectel на базе VMware. Хотя компания мигрировала из облака другого крупного провайдера и масштабировала ИТ-инфраструктуру в 4 раза, уровень ежемесячных затрат удалось сохранить на прежнем уровне. «Всё больше компаний полностью переносят свои ресурсы в облака. Так и в этом проекте: изначальным посылом было „ничего на земле“. Мы увеличили количество пользователей с 30 до 130 рабочих мест, сохранив общий уровень ежемесячных затрат на виртуальные ресурсы и поддержку», — рассказал Тимур Бадретдинов, руководитель отдела инфраструктурных решений компании Syssoft.

Инфраструктурные проблемы

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

Александр Гришин, владелец продукта VMmanager из ISPsystem, говорит, что избежать проблемы помогает детальное описание внутренней инфраструктуры. «Должно быть чёткое понимание, из каких компонентов она состоит, как приложения взаимодействуют друг с другом, какие из них могут быть перенесены только единовременно и так далее», — говорит он.

Пример. Крупная компания решила отправить в облако бэкапы ИТ-системы. Цена за объём хранимых данных была приемлемая, поэтому сделка казалась привлекательной. «При тестировании выяснилось: чтобы потом воспользоваться этими бэкапами для восстановления, нужно в 2—3 раза больше времени, чем это допустимо для заказчика», — рассказал Вячеслав Медведев, руководитель направления облачных решений «Инфосистемы Джет». По рекомендованному провайдером тарифу канал облака оказался недостаточно производительным. А если использовать более производительный канал, то стоимость услуги увеличивалась и не подходила компании по бюджету. В итоге проведение тестов остановило компанию от принятия невыгодного решения.

Снижение производительности

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

В компании «Инфосистемы Джет» подбирали облачного поставщика для компании с высокими требованиями по ИБ. И выяснили интересную вещь. У провайдера был сертифицированный в соответствии с ФЗ-152 контур для размещения персональных данных. После проведения нагрузочных тестов оказалось, что за счёт наложенных средств безопасности реальная производительность ниже. В предоставленной провайдером документации этой информации не было. Компании пришлось увеличить объём заказанных ресурсов (обратиться к другим поставщикам), иначе заказчик столкнулся бы со снижением скорости обработки данных.

Как избежать распространённых рисков — снижения производительности, утечки данных?

Дмитрий Романченко, директор ИБ-департамента Rubytech, рассказал, почему модель безопасности из облака (security as a service — SECaaS) на бумаге выглядит красиво, а на практике чревата сложностями. Дело в том, что злоумышленникам экономически выгодно атаковать облака провайдеров: концентрация объектов в облаке в случае успешной атаки обещает большую «прибыль». Доходы хакеров суммируются, удельные затраты на каждую атакованную систему падают. «Более того, появляется „отраслевая специализация“ хакерских группировок, что повышает вероятность „пробоя“ защиты, а также кратно увеличивает нагрузку на системы автоматического отражения атак и системы мониторинга, выводя их за границы адаптации», — говорит Дмитрий.

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

Выбор подрядчика

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

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