Облачная стратегия или аренда ресурсов по потребности

Точечная аренда: скрытые издержки

Когда компания арендует облачные ресурсы без четкой стратегии — под конкретный проект, для временного всплеска нагрузки или «потому что так быстрее» — она попадает в ловушку растущих операционных расходов. По данным исследования Accenture, миграция без стратегии может привести к снижению TCO лишь на 10-15%, тогда как продуманный подход дает экономию до 40%.

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

Стратегии облачной трансформации

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

Cloud Native\First для цифровых сервисов

Подход предполагает размещение всех новых разработок в публичном облаке с минимальными исключениями. Эта модель оптимальна для ритейла и цифровых сервисов, где критична масштабируемость и скорость вывода продуктов на рынок (time-to-market).

Компании полностью отказываются от управления виртуальными машинами: вместо установки PostgreSQL на виртуальную машину приобретают Managed PostgreSQL, а вместо настройки Kubernetes с нуля используют Managed K8s и т.п. Использование исключительно IaaS не решает основные задачи бизнеса. Вы переносите в облако большую часть рутинных задач по управлению инфраструктурой (администрирование ОС, установка патчей, бэкапы для СУБД, организацию отказоустойчивости и т.п.), но платите за это несколько больше.

Например, для М.Видео переход на облачную модель потребления и использование платформы данных позволил отказаться от CAPEX и четко связал затраты в рамках OPEX, перераспределив таким образом порядка 50% стоимости бизнес-проекта на горизонте трех лет в пользу актуальных для развития компании продуктов, а не инфраструктуры.

В российских реалиях 2025 года, когда сроки поставки high-end оборудования (вроде кластеров NVIDIA H100\Н200) могут достигать 6–9 месяцев, а их стоимость очень высокая, облачная стратегия становится практически безальтернативной для сценариев, связанных с ИИ. В контексте ИИ термин Cloud Native часто понимают неправильно. Многие думают, что это просто аренда виртуальной машины с GPU вместо покупки физического сервера. Cloud Native AI — это использование управляемых ML-платформ (MLaaS), где вы платите не работу\простой виртуальной машины, а за сам процесс обучения или инференса (работы) модели.

1.     Корпоративный RAG (Retrieval-Augmented Generation). Бот и RAG-логика развернуты в виде serverless-контейнеров. Данная архитектура обеспечивает автоматическое масштабирование до нуля в периоды простоя (например, в нерабочие часы), что позволяет полностью исключить соответствующие эксплуатационные расходы. Вместо хостинга своей Llama 3 или другого решения вы подключаетесь по API к дообученным моделям провайдера (YandexGPT, GigaChat и т.п.). Time-to-market сокращается с месяцев до недель. Вы оплачиваете только токены и запросы, а не за простаивающую GPU-мощности.

2.     «Взрывное» дообучение (Fine-Tuning). Допустим, банку необходимо раз в месяц переобучать скоринговую модель на новых данных. Процесс занимает 48 часов, но требует мощности суперкомпьютера. Архитектору достаточно загрузить код и данные — дальше платформа делает всё сама. Она динамически создаёт инфраструктуру под нужный масштаб, разворачивает готовое окружение с необходимыми библиотеками, проводит обучение и — что ключевое — автоматически останавливает и удаляет все ресурсы после завершения, исключая лишние расходы. Экономия CAPEX — 100%.

3.     MLOps как сервис. Ключевая сложность в машинном обучении сегодня — это не создание модели, а её эффективная доставка в промышленную эксплуатацию. Cloud Native-подход решает эту проблему за счёт использования готовых MLOps-пайплайнов облачного провайдера. Развернуть обученную модель в высоконагруженный кластер можно с помощью стандартных декларативных манифестов. При этом облако полностью отвечает за масштабирование инфраструктуры.

Гибридная модель для регулируемых отраслей

Данный подход актуален для банковского сектора, промышленности, госсектора, медицинских компаний.

Ядро системы (специализированное банковское ПО, ERP, АСУ ТП\SCADA) остается в собственном контуре или в частном облаке (Private Cloud) внутри периметра заказчика. В публичное облако выносятся только пиковые нагрузки, тестовые среды и фронтенд.

Системы остаются локально по нескольким причинам:

1.     Жёсткими требованиями к латентности (до 5 мс): промышленное IoT, SCADA, HFT-торговля. 

2.     Системы с уникальными, унаследованными (legacy) требованиями\кодом. Если у вас есть дата-центр, а нагрузка не меняется годами, то расчет Total Cost of Ownership (TCO) за 5-7 лет может показать экономическую нецелесообразность переноса таких систем в облако.

3.     Данные, подпадающие под сверхжесткие регуляторные ограничения.

ICL Services работает с крупными российскими организациями и российскими филиалами иностранных/локализованных компаний. На примере проектов видим, что гибридная модель для компаний уровня enterprise является основной – особенно для банков и тех клиентов, у которых есть собственные заводские мощности на территории РФ. Какие-то компании для локальной инфраструктуры выбирают стандартный подход – железные сервера и виртуализация, некоторые частные облака, позволяющие получить преимущества облачных технологий (автоматизация, оркестрация, масштабируемость) при полном соответствии требованиям регуляторов. Крупные облачные провайдеры предлагают свои решения для частного облака – VK Private Cloud и Evolution Stack (сертифицированная для КИИ). Важно учитывать, что развертывание частного облака сопряжено со значительными капитальными затратами (CAPEX).

Мультиоблачность для снижения рисков

Согласно исследованиям 65% крупных компаний уже применяют мультиоблачные стратегии. Ключевая цель — устранение зависимости от одного поставщика и повышение отказоустойчивости, кроме того, мультиоблачная архитектура позволяет распределять нагрузку между провайдерами в зависимости от специфики задач: один для AI/ML-вычислений, другой для хранения данных, третий для веб-сервисов.

При повышенных требованиях к RTO (менее 5 минут) и высокой чувствительности к финансовым потерям даже от кратковременного простоя такая тщательно продуманная и реализованная стратегия может использоваться как основная. Она позволяет достичь SLA 99,99 % и значительно снизить риски, однако за это может потребоваться заплатить заметным увеличением операционных расходов (OPEX).

В 2025 году мы наблюдаем растущий интерес клиентов к мультиоблачной стратегии. Ключевые цели, которые они преследуют, — это повышение отказоустойчивости инфраструктуры и оптимизация облачных расходов. Последняя достигается за счет гибкого выбора наиболее выгодного провайдера под разные задачи, особенно для ML-нагрузок — будь то аренда GPU-виртуальных машин или использование готовых AI-сервисов и платформ.

Практические шаги к стратегии

Целостная облачная стратегия превращает инфраструктуру в драйвер гибкости бизнеса.  Рассмотрим основные шаги для построения такой стратегии:

1.     Создайте межфункциональную рабочую группу, включив в нее представителей ключевых направлений: бизнес-подразделений, ИТ-департамента, финансовой службы и отдела безопасности.

2.     Проведите инвентаризации текущего ИТ-ландшафта и классификацию данных и определение уровня значимости информационных систем в рамках КИИ (критической информационной инфраструктуры). Разработайте матрицу принятия решений: для каждого типа нагрузки определите оптимальную модель размещения.

3.     Рассчитайте текущий TCO для ключевых систем и смоделируйте стоимость в облаке на 3-5 лет. Корректный расчет TCO должен включать затраты на электроэнергию, охлаждение, персонал, лицензии, резервирование и физическую безопасность для локальной инфраструктура, а в облаке помимо аренды мощностей (vCPU\CPU\данные) должны учитываться дополнительные расходы на трафик (модель тарификации трафики различается от провайдера к провайдеры: где-то оплачивается только исходящий трафик, где-то также входящий, но не забывайте, что выделенный канал всегда оплачивается отдельно), резервные копии, лицензии ПО, трудозатраты на управление как самими сервисами, так и разными консолями при мультиоблачном подходе, и др.

4.     Выберите провайдера(-ов) на основе не только цен, но и зрелости платформы (наличие PaaS, ИБ-сервисов и т.п.), экосистемы партнеров, географического присутствия и выполнения требований регуляторов. Проведите тестирование выбранных 2-3 провайдеров перед принятием решения: оцените производительность, надежность и качество технической поддержки. Не забывайте, что стратегия должна предусматривать возможность (пусть и сложную) смены провайдера или использования нескольких провайдеров совместно.

5.     Внедрите инструменты управления (FinOps, Security Posture Management) с первого дня использования облака.

6.     Пересматривайте облачную стратегию не реже раза в год: рынок российских облачных сервисов растет на 25-30% ежегодно, появляются новые сервисы и меняются ценовые модели. То, что было нерентабельно год назад, может стать оптимальным решением сегодня.

Стратегический сдвиг в управлении ИТ

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

Источник