Как успешно мигрировать в облако

Организации по всему миру переходят на облачные сервисы, чтобы поддержать процессы цифровой трансформации и обеспечить операционную эффективность за счет гибкости и масштабируемости, отмечают эксперты международного аналитического агентства IDC. Снижение расходов, по их оценкам, может составить более 50% за пять лет использования облака, а внедрение новых приложений ускорится на 75%. В свою очередь, исследователи Enterprise Strategy Group (ESG) оценили снижение стоимости хранения данных в облаке на 69%, а стоимости вычислений — на 63%.

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

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

В Х5 Tech согласны, что для крупного бизнеса облако — это прежде всего скорость, устойчивость и гибкость ИТ‑инфраструктуры. «Оно позволяет быстрее запускать цифровые продукты, масштабировать ресурсы и централизованно управлять большим количеством систем», — дополняет управляющий директор Х5 Tech Александр Костин.

Дополнительный фактор, появившийся на российском рынке в 2025 году, — спрос на облачные ресурсы на фоне дефицита и подорожания традиционной памяти для вычислительного оборудования.

По словам директора технологической практики «ТеДо» Юрия Швыдченко, переход в облако позволит сгладить дефицит мощностей из‑за повышения их стоимости, но эта мера будет ограниченной по времени. Облачные провайдеры закупают ресурсы с большим объемом и горизонтом планирования — в среднем до двух лет.

Какую модель облака выбирают и для чего

Преимущества облачных сервисов зависят от модели использования. Выбирая модель SaaS («ПО как услуга»), бизнес получает готовые технологические решения «из коробки» — без необходимости создавать и поддерживать собственные платформы и команды разработки.

«SaaS остается массовым выбором для прикладных задач — управления взаимоотношениями с клиентами (CRM), HR, документооборота, коммуникаций, бухгалтерии, сервис-деска», — рассказывает исполнительный директор Ассоциации облачных и технологических провайдеров Антон Салов.

В модели IaaS («Инфраструктура как услуга») компания получает готовую ИТ‑инфраструктуру для запуска собственных продуктов и сервисов. Для бизнеса это снижает капитальные затраты (CAPEX) на покупку и модернизацию оборудования — и переводит их частично в операционную модель (OPEX) с оплатой за фактически используемые ресурсы.

«IaaS сегодня активно растет за счет миграции инфраструктуры, дефицита собственных мощностей и спроса на графические процессоры (GPU)», — поясняет Антон Салов.

Сегмент PaaS («Платформа как услуга»), по оценкам аналитических агентств, в России пока менее зрелый, чем в мире. По мнению Антона Салова, его роль растет там, где компании переходят от простой аренды виртуальной машины к платформенной разработке, с использованием контейнеров, баз данных как сервиса, объектного хранилища, MLOps — набора практик, которые объединяют машинное обучение (ML), разработку (Dev) и операционную деятельность (Ops).

Руководитель проектов практики «Промышленность и технологии» Strategy Partners Александр Михайлов отмечает, что на российском рынке появился тренд на построение «сложных» вендорских систем, когда идет отказ от принципа «одного поставщика» и выбор в пользу разных поставщиков: под конкретную задачу выбирается тот, кто может решить ее оптимальным способом.

Какие сценарии миграции используют и где

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

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

Для крупных компаний также критичны задержки передачи данных: для части критических (mission-critical) систем они должны оставаться минимальными.

Решение о миграции может исходить также из фактора критичности нагрузки для бизнеса. Она может различаться в зависимости от отрасли. К примеру, в ретейле сбои напрямую влияют на клиентский опыт и операционные процессы, поэтому важны требования к отказоустойчивости, задержкам и доступности, рассказывает Александр Костин. Именно поэтому X5 использует архитектуру «центр + периферия»: критичные вычисления централизованы в Salt X5, а локальная инфраструктура в магазинах и распределительных центрах обеспечивает автономность даже при нестабильной связи. Такой подход позволяет одновременно обеспечивать высокую доступность систем, низкие задержки и устойчивость бизнеса.

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

При этом облачные технологии по‑прежнему играют для финтеха важную роль как площадка для экспериментов и развития нефинансовых направлений бизнеса. По данным Т‑Банка, в облаке удобно и экономично запускать пилоты по новым цифровым продуктам, аналитическим сервисам, ML/ИИ‑моделям и клиентским интерфейсам, где можно работать с обезличенными данными или внешними наборами данных без риска нарушения банковской тайны.

Как эффективно организовать процесс миграции

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

Базовый сценарий миграции — «переезд как есть» (lift-and-shift). Это самый простой и быстрый путь, когда виртуальные машины и серверы переносят без изменения архитектуры. «Именно поэтому доля IaaS в структуре российского рынка так велика — почти половина компаний берут у провайдера только вычислительные мощности», — отмечает директор по развитию облачных и инфраструктурных продуктов МегаФона ПроБизнес Станислав Попов. Это быстро и дешево на входе, но не дает экономии на эксплуатации. Просто арендуя чужие серверы, заказчик не извлекает никаких преимуществ из архитектуры облачной платформы.

Другой, и растущий сегодня по востребованности сценарий — когда организация переезжает на новую платформу или систему целиком. Такой подход сформировался после ухода зарубежных вендоров — у заказчиков появилась задача миграции на отечественные решения СУБД, а также ERP и CRM. В такой конструкции проще развернуть новую платформу сразу в облаке, чтобы учесть особенности ее архитектуры и при этом не тратиться на новое оборудование, дополняет Станислав Попов. Фактически это оказалось одним из эффектов общего тренда импортозамещения на российском рынке.

Альтернативный сценарий — когда перед миграцией нужно перепроектировать архитектуру приложения или переписать его код под облако. Это более затратный проект на старте, однако он позволит более гибко управлять ресурсами из облака и пользоваться более широким их спектром — включая управляемые сервисы (например, базы данных).

Часто миграция стартует с подхода lift-and-shift как первого этапа, а далее, на втором этапе, запускается необходимый рефакторинг (перепроектирование) приложений под облачный (cloud-native) формат.

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

Мигрировать лучше связанными кластерами, а не по одной системе, отмечают в МегаФоне ПроБизнес. Так не будет рушиться сетевая связность, и после миграции можно будет сразу проверить работоспособность систем в комплексе, а не поодиночке.

Ключевые этапы процесса миграции:

1. Планирование проекта, включая цели, — что ожидается в результате миграции.
2. Аудит существующей инфраструктуры (серверов, сетевых ресурсов, приложений и баз данных) — для понимания зависимостей между системами и оценки необходимых облачных ресурсов.
3. Расчет совокупной стоимости владения (TCO), ожидаемой окупаемости инвестиций и экономии.
4. Выбор провайдера (с учетом стоимости услуг, уровня SLA, поддержки необходимых технологий, наличия и параметров ЦОД и пр.).
5. Проектирование архитектуры (как правило, совместно с провайдером продумывается будущая инфраструктура в облаке, включая вычислительные мощности, организацию хранения данных, пропускную способность сети и пр.).
6. Подготовка инфраструктуры к миграции, с разработкой плана отката на случай сбоев.
7. Развертывание базовой инфраструктуры в облаке.
8. Перенос нагрузок в облако — как правило, реализуется в несколько «волн», начиная с пилотного проекта (перенос некритичного простого сервиса для отработки процесса).
9. Настройка мониторинга и политик безопасности.

Типовые ошибки при миграции в облако:

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

Как распределять зоны ответственности при использовании облака

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

В технической сфере, в зависимости от того, в какой модели заказчик потребляет облачные ресурсы (IaaS / PaaS / SaaS), пограничной зоной ответственности будет операционная система, среда исполнения или же конкретный слой приложения. «Ключевой момент — данные и доступы всегда, на любом слое, на заказчике, провайдер не имеет к ним доступа и права раскрывать информацию», — поясняет Станислав Попов.

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

В случае обеспечения требований № 187‑ФЗ аттестация облака снимает с заказчика часть нагрузки, но не делает его автоматически соответствующим требованиям. Ответственность субъекта КИИ в любом случае остается на организации. «Преимущество миграции в облако здесь — возможность использовать накопленный опыт и помощь сервис-провайдеров в итоговой аттестации информационной системы в уже описанном и понятном контуре инфраструктуры и средств защиты», — рассказывает Станислав Попов.

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

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

За последние годы в облако переехали администрирование СУБД, мониторинг событий информационной безопасности, сертифицированные СЗИ и аттестации — что еще лет 5-7 назад казалось невозможным. Сейчас в облаке активно используется инфраструктура для ИИ.

Как управлять стоимостью облачного проекта

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

Облачная модель привлекает бизнес гибкой тарификацией pay‑as‑you‑go. Она позволяет платить только за те ресурсы, которые фактически использует компания.

«Значительная часть избыточных расходов возникает из‑за отсутствия контроля над потреблением», — считает руководитель программ исследований российского рынка Apple Hills Digital Василий Пименов. При этом практика FinOps (Financial Operations — управление облачными расходами как отдельная функция), по его словам, пока не получила широкого распространения — большинство компаний ведут такой контроль в Excel или не ведут его системно вообще.

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

Как оценить успешность миграции

Главный показатель успешности облачного проекта — это выгода для бизнеса. Ее можно измерить как в сокращении издержек на инфраструктуру, так и в ускорении вывода новых продуктов на рынок (Time-to-Market).

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

Чего не стоит ожидать:

• Экономии расходов уже с первого дня — в силу значительных первоначальных вложений она будет понятна по итогам более продолжительного периода. Лучше ориентироваться на показатели ТСО на горизонте 3-5 лет. Если же четко не отслеживать затраты, можно упустить, например, скрытые расходы на инфраструктуру — и в итоге при миграции в облако они могут даже вырасти.
• Роста производительности — например, если были мигрированы приложения с неоптимизированным кодом или неправильно была спроектирована сеть.
• Автоматического повышения отказоустойчивости — провайдер действует в рамках SLA, прописанных в договоре, а полноценную отказоустойчивость должен заранее продумать и спроектировать заказчик.
• Отсутствия рисков безопасности — провайдер отвечает за защиту своей инфраструктуры, но организация и настройка доступа, шифрование, управление правами — на стороне заказчика.