Все больше компаний в России строят распределенную ИТ-инфраструктуру, объединяя локальные ресурсы и несколько облачных платформ. Такой подход помогает избежать зависимости от одного поставщика, повысить устойчивость и точнее управлять расходами.
Мультиоблако: к распределенной инфраструктуре без потерь
Публичные облака остаются важной частью развития ИТ-инфраструктуры в России. В 2024 г. объем рынка облачных услуг достиг ₽165,6 млрд — на 36% больше по сравнению с предыдущим годом. По оценкам, в 2025 г. рост продолжится и может составить еще 20–30%. Вместе с расширением рынка усиливается специализация: заказчики выбирают облачные решения под конкретные задачи и бизнес-сценарии.
Все чаще компании уходят от модели «одного облака» в сторону распределенной архитектуры, совмещающей локальные ресурсы и разные облачные платформы. Это позволяет не только повысить отказоустойчивость и гибкость, но и избежать зависимости от одного поставщика.
Рейтинг платформ для управления облачной инфраструктурой. Структура баллов
Подробнее: Обзор российских платформ для управления облачной инфраструктурой 2025
По оценкам, 89% корпоративных заказчиков в мире используют два и более облака от разных провайдеров. В России мультиоблако пока внедряется не столь широко, но его доля стабильно растет — как ответ на задачи импортозамещения, оптимизации затрат и повышения управляемости ИТ-инфраструктуры.
Мультиклауд и гибрид: не одно и то же
Понятия «гибридное облако» и «мультиоблако» часто воспринимаются как взаимозаменяемые, но это разные модели. Гибрид чаще всего предполагает сочетание собственной инфраструктуры (частного облака или ЦОДа) с одним публичным облаком. Под мультиоблаком, как правило, понимается использование нескольких независимых облачных платформ, которые могут включать как публичные, так и частные сервисы, не связанные между собой. Мультиоблако может быть частью гибридной архитектуры. Например, когда «одно плечо» остается в локальном ЦОДе, а другие выносятся в разные публичных облака.
Такая схема позволяет распределять нагрузку, резервировать компоненты инфраструктуры и получить сервисы, которых может не оказаться у одного из поставщиков услуг. Т.е. мультиоблако также помогает уйти от зависимости от одного провайдера: если, например, он меняет тарифы, уходит с рынка или ограничивает функциональность, ресурсы, особенно с учетом быстро меняющейся технологической и регуляторной среды, можно перераспределять.
Что нужно для работы мультиоблака
Чтобы управлять мультиоблачной средой — инфраструктурой, распределенной в разных облаках — необходим набор инструментов, которые работают как единая система.
В основе — единый управляющий слой, который позволяет работать с разными облаками и платформами как с одной средой, вне зависимости от того, где размещены ресурсы и на чем они развернуты. Через такой интерфейс администратор может запускать виртуальные машины, распределять мощности между командами или проектами, а также отслеживать текущее потребление ресурсов.
Учет и биллинг – в мультиоблачной среде ресурсы поступают от разных провайдеров, каждый из которых использует собственную модель тарификации. Система управления должна сводить эти данные в единое представление, позволяя контролировать потребление, прогнозировать затраты и выявлять неиспользуемые ресурсы.
Поддержка шаблонов развертывания и сценариев автоматизации упрощает запуск инфраструктуры под задачи разных команд. Интерфейсы самообслуживания позволяют пользователям заказывать ресурсы без участия ИТ, по утвержденным политикам.
Кроме того, в мультиоблачной среде особенно важны:
- единый мониторинг состояния и инцидентов во всех облаках — с возможностью быстро локализовать и устранить проблему независимо от платформы;
- централизованное управление доступом — с разграничением прав по ролям и проектам, охватывающее ресурсы на разных провайдерах;
- консолидация информации о ресурсах — чтобы видеть в одном интерфейсе, какие виртуальные и физические мощности используются и где.
Где и как работает мультиоблако
Мультиоблачная архитектура может выглядеть по-разному — в зависимости от задач бизнеса, зрелости инфраструктуры и подхода к миграции. Самый распространенный сценарий — использование сразу нескольких публичных облаков. Каждое может, например, отвечать за свою часть: одно — за хранение, другое — за вычисления, третье — за резервное копирование или ИИ-задачи.
Другой вариант — комбинация с собственной инфраструктурой. Это по сути гибридная модель, в которой часть ресурсов остается в локальном ЦОДе, а в облаках размещаются сервисы, требующие масштабируемости или высокой доступности или обеспечивающие работу при критичных нагрузках при сбоях или пиках.
Мультиоблако удобно для работы с разнородными системами. Оно позволяет:
- разместить данные в одной платформе, а аналитику — в другой;
- выбрать провайдера с нужным набором технологий (например, поддержкой определенной СУБД, контейнеризации или GPU);
- использовать разные облака под разные зоны ответственности — продакшн, тестирование, разработки.
В ИТ-ландшафте, где сложно заранее предсказать, какая платформа или сервис окажется критически важным, мультиоблако помогает избежать лишних трат и технических ограничений.
Когда человек не справляется: автоматизация и AIOps
Мультиоблачная архитектура почти всегда подразумевает высокую динамику: ресурсы запускаются и выключаются в разных средах, пользователи работают в десятках проектов, а потребление постоянно меняется. Поэтому в таких системах все чаще применяются технологии автоматизированного управления.
Во-первых, это шаблоны развертывания и инфраструктура как код — сценарии, по которым можно запускать типовые среды без участия администратора. Во-вторых, поддержка DevOps-практик — когда приложения и инфраструктура разворачиваются как единое целое, по заранее заданным сценариям. Такой подход позволяет быстрее запускать новые сервисы и сокращать число ошибок при обновлениях.
Отдельное направление — AIOps, автоматизация управления ИТ-инфраструктурой на основе анализа данных. Такие системы прогнозируют нагрузку, находят отклонения, автоматически масштабируют ресурсы, помогают снизить затраты и уменьшают число ложных тревог в мониторинге.
Некоторые системы предлагают предиктивную аналитику — прогнозы нагрузки и затрат по облакам. Это помогает заранее увидеть, где могут возникнуть перегрузки или перерасход, особенно если изменения у одного провайдера влияют на работу всей инфраструктуры.
Безопасность между облаками
Чем больше облаков используется, тем сложнее управлять безопасностью. У каждого провайдера — свои правила, доступы и инструменты защиты. Но требования по безопасности и соответствию регуляторным нормам одни для всей инфраструктуры — и их нужно соблюсти сразу во всех облаках.
Ключевая задача — централизовать управление доступом. Это означает, что правила для пользователей, ролей и проектов должны действовать одинаково во всех облаках. Также важно вести аудит действий и контролировать, кто и какие ресурсы использует.
Отдельный риск — расхождения в настройках безопасности между облаками. Если, например, в одном облаке виртуальная машина запускается с другими параметрами защиты или сетевыми правилами, это может создать уязвимость в общей системе.
Дополнительные сложности возникают, когда в мультиоблачной инфраструктуре задействованы данные разного уровня чувствительности. Компании, работающие с персональными данными, КИИ или государственными информационными системами, должны учитывать требования законодательства — например, ФЗ-152, нормативы ФСТЭК и отраслевые регламенты. Облачная среда должна быть настроена так, чтобы эти требования соблюдались во всех сегментах инфраструктуры.
Облачные платформы предлагают разные механизмы защиты: изолированные контуры, шифрование, защищенные каналы передачи данных. Но в мультиоблачной архитектуре важно, чтобы все эти меры работали согласованно. Поэтому нужна понятная система контроля — с правилами, кто и где размещает данные, какими политиками пользуется и как отслеживаются инциденты в разных облаках.
Как перейти к мультиоблаку и что может помешать
Переход к мультиоблачной архитектуре требует не только технических изменений, но и пересмотра процессов управления ИТ. Нужно заранее определить, какие системы можно перенести без изменений, какие придется адаптировать, и как будет организовано взаимодействие между облаками. Также важно понять, кто отвечает за ресурсы в каждом из облаков, как распределяются бюджеты и как соблюдаются требования по безопасности.
Обычно используют два подхода:
- Смена платформы (replatforming) — минимальные изменения: например, вынос базы данных в облачный сервис или частичная миграция компонентов;
- Смена архитектуры (rearchitecting) — полная перестройка архитектуры с переходом на микросервисы, контейнеры и DevOps-подходы.
Мешать переходу к мультиоблаку может целый комплекс факторов. Многих компании сделали вложения в оборудование и локальные лицензии, которые может быть сложно списать на этом этапе. Часто не хватает специалистов с опытом работы в распределенных средах. Возникают сложности с интеграцией облаков между собой и с существующими системами. Не всегда заранее выстраивается понятная модель безопасности. А ожидания от перехода к мультиоблачной структуре могут оказаться завышенными — особенно если недооценены организационные изменения.
Даже при технической готовности проект может тормозиться из-за разного понимания целей со стороны ИТ, информационной безопасности и бизнеса. Без общего подхода мультиоблачная архитектура легко превращается в разрозненный набор решений.
Чаще всего переход проходит проще у тех компаний, которые уже работали в облаке или используют облачную платформу в качестве «второго плеча». В этом случае есть возможность сохраняя контроль над существующей инфраструктурой, постепенно включать другие облака в единый контур управления.
Поделиться
