Top.Mail.Ru
СБЕР Про | Медиа
Облачный атлас. Как избежать ошибок при миграции в cloud-среду
  • ТМТ

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

  • 8 мин
  • 2 873

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Какие ошибки чаще всего совершают компании, переходя в cloud-среду?

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

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

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

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

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

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

Избежать ошибок можно с помощью комплексного подхода к миграции в облако с проработкой всех вышеперечисленных факторов. В частности, для корректной оценки экономики можно использовать калькулятор TCO (Total cost of ownership) — у нас в SberCloud есть такой. Калькулятор структурирован так, что различные ошибки в финансовых расчётах легко заметить и, следовательно, их избежать.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Привязка к одному поставщику

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

Провайдеры отмечают, что избежать ошибок на облачном пути помогает облачный консалтинг — привлечение независимого консультанта, контролирующего выполнение задач клиента IT-подрядчиком. По мнению экспертов, облачный консалтинг будет крайне востребован в следующие 5 лет. К 2025 году более 75% крупных организаций будут обращаться к внешним консультантам для разработки облачной стратегии, тогда как в 2019 году это делало лишь 40% компаний. Причина повышения спроса на экспертное сопровождение в том, что масштабные облачные миграции действительно сложно выполнять самостоятельно, каким бы крупным ни был провайдер.

Эта статья была вам полезна?

Читайте ещё