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

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

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

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

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

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

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

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

Многие IT-лидеры называют экономию важным фактором при переходе в облако для клиентов. Но надежды заказчиков не всегда оправдываются.

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

Так, крупный производитель минеральной воды решил перейти на облачный сервис Selectel. Хотя компания мигрировала из облака другого крупного провайдера и масштабировала IT-инфраструктуру в 4 раза, уровень ежемесячных затрат удалось сохранить на прежнем уровне.

Сложность состоит ещё и в том, что большинство компаний не знают на необходимом уровне свою IT-инфраструктуру. Решение данной проблемы — аудит. Его можно провести силами внутренних IT-служб либо с привлечением аутсорсинговой компании.

Пример. Крупный банк внедрил систему, которая относится к классу критических приложений. Систему разместили в облаке, а через некоторое время выяснилось, что она располагается только в одном дата-центре. Значит, если ЦОД «упадёт», банк не сможет обслуживать своих клиентов в отделениях по всей стране. Разместив систему в облаке, специалисты не до конца учли особенности её внутреннего устройства и возможности катастрофоустойчивости. Чтобы избежать этого, IT-специалисты разработали комплект архитектурных стандартов для всех задействованных инфраструктурных компонентов. Система была перепроектирована и развернута в соответствии с ними.

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

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

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

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

Михаил Лобоцкий,

заместитель генерального директора,

директор по продуктам компании SberCloud:

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

Для того чтобы у клиентов SberCloud миграция в облако проходила максимально корректно и эффективно, у нас есть целое направление — SberCloud Professional & Managed Services. Это комплекс экспертных услуг по внедрению и адаптации облачных сервисов SberCloud, включая консалтинг, проекты миграции под ключ, настройку ПО в нашем облаке, администрирование облака.

Чтобы предотвратить утечку данных, нужно выбрать правильное облако, аттестованное согласно ФЗ-152 по уровням защищённости 1, 2 или 3. При этом важно понимать, что облачный провайдер обеспечивает безопасность самой облачной инфраструктуры, а безопасность систем, расположенных в облаке, находится в зоне ответственности клиента. Антивирус, антиспам, анти-DDoS, WAF, NGFW — ключевые инструменты защиты корпоративных систем. В нашем портфолио есть все эти продукты, а наши облачные платформы аттестованы согласно ФЗ-152 по разным уровням защищённости, включая первый. Всё это обеспечивает нашим клиентам комплексную безопасность.

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

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

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

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

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