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

Что и куда выносить

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

Хороший пример эластичной задачи – аналитика на больших объёмах. Кластер для разовых расчётов дешевле поднять в облаке на несколько часов, чем держать стойку круглый год; как это устроено на практике, мы разбирали в материале про Hadoop в корпоративной среде. Для вычислительных всплесков подойдут и свежие IaaS-предложения – например, недавно анонсированный Google Compute Engine, который даёт виртуальные машины с почасовой оплатой.

Где проходит граница по 152-ФЗ

Главное ограничение для российского заказчика – закон «О персональных данных». Перенос ПДн в публичное облако, особенно с серверами за рубежом, означает трансграничную передачу и аттестацию площадки по классу ИСПДн. Большинству проще не выносить такие данные вообще.

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

Как связать две площадки

Техническая основа гибрида – надёжный канал и единое управление. Мы поднимаем site-to-site VPN или арендуем выделенную линию между серверной заказчика и облачным провайдером, настраиваем общую адресацию и DNS, чтобы приложения не различали, где именно работает соседний сервис.

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

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

Вывод

Гибридное облако – не компромисс, а осознанное распределение: контроль и соответствие закону остаются на частной площадке, гибкость и масштаб приходят из публичной. Связка работает, когда граница данных проведена честно, канал зарезервирован, а управление сведено в одну точку. Дальше всё сводится к проектированию инфраструктуры под конкретные системы и требования регуляторов.