От виртуализации к частному облаку в «Газпром нефть»

Перейти с зарубежной платформы виртуализации на российскую и одновременно перестроить предоставление вычислительных ресурсов: объединить мощности двух центров обработки данных в общий пул, выдавать инфраструктуру по запросу через портал и API, перевести в облако корпоративные системы, включая 1С. Платформа должна работать на российском оборудовании и операционной системе и допускать размещение важных информационных систем.

Частное облако на платформе VK Private Cloud в двух центрах обработки данных с отдельными контурами под продуктивные нагрузки, разработку, инфраструктуру приложений и резервного копирования и базовые сервисы цифровой B2B-экосистемы. Объектное хранилище VK Object Storage на 500 ТБ. Ресурсы выдаются через портал самообслуживания, API и Infrastructure as Code, потребление учитывается биллингом по проектам.

Стандартная виртуальная машина предоставляется за 20 минут вместо 9 дней, утилизация мощностей в центральных ЦОД выросла с 30% до 70%. В облаке более 8000 виртуальных машин, среди них корпоративная учётная система 1С и система управления событиями информационной безопасности. Миграция и обновления платформы стали регулярными операциями.

«Газпром нефть» входит в число крупнейших нефтяных компаний России и работает по всей цепочке: разведка и добыча, переработка, сбыт. Компания территориально распределена, и вычислительные ресурсы для сотен информационных систем и продуктовых команд размещает в собственных центрах обработки данных и на удалённых площадках.

Российские платформы виртуализации компания изучала с 2019 года, проводила пилоты и оценивала их готовность. В 2022 году риски эксплуатации зарубежной платформы стали очевидны, и компания приняла решение о полном переходе на российские решения: платформа виртуализации, операционная система, серверное оборудование. Проект с самого начала рассматривали шире замены одного продукта другим. Мощности были распределены по классической схеме: серверы закреплены за командами и системами. Средняя утилизация держалась около 30%, каждое расширение проходило через заявки и согласования, стандартная виртуальная машина выдавалась в среднем за девять дней. Основные потери времени приходились на ожидание и передачу заявки между специалистами. Эффективность инфраструктуры стала вопросом уровня руководства компании. Цель сформулировали через экономику: изменить стоимость и скорость получения вычислительных ресурсов. Частное облако стало инструментом для этой цели.

- Общий пул. Ресурс перестаёт быть «сервером команды», мощности объединены и загружаются плотнее. - Самообслуживание. Типовая инфраструктура выдаётся как сервис через портал, без ручного выделения. - API и Infrastructure as Code. Продуктовые команды получают ресурсы из своих конвейеров поставки. - SLA и биллинг. Видно, кто сколько потребляет и сколько это стоит. Отдельное требование: воспроизводимость. В прежней модели отдельные кластеры со временем начинали отличаться друг от друга настройками и локальными особенностями. Компании нужно было, чтобы один и тот же запрос давал одинаковый результат независимо от площадки и специалиста, через единый интерфейс управления и API. Распределённая структура компании задала архитектуру: на удалённых площадках остаётся минимально необходимый набор ресурсов, дополнительную мощность они получают из центра. Так компания не держит избыточное оборудование на периферии и сохраняет автономность площадок при проблемах с каналами связи.

Частное облако работает в двух центрах обработки данных. Помимо двух продуктивных контуров IaaS развёрнуты среда совместной разработки для продуктовых команд и партнёров, инфраструктурный контур для приложений и резервного копирования и платформа для базовых сервисов цифровой B2B-экосистемы. Под управлением платформы более 270 серверов, более 8000 виртуальных машин, более 100 внутренних заказчиков. Объектное хранилище VK Object Storage развёрнуто с полезной ёмкостью 500 ТБ и рассчитано на 1 млрд объектов; сейчас оно проходит апробацию под данные приложений и резервные копии. Портал самообслуживания оформлен в фирменном стиле компании и встроен в её процессы. Пользователь указывает параметры виртуальных машин, операционную систему и сетевой сегмент, дальше платформа резервирует ресурсы, выбирает кластер, создаёт связанные задачи в системе управления ИТ-процессами и проверяет ограничения, включая бюджетные. Проверки безопасности встроены в конвейер через предсогласованные шаблоны, под контролем специалистов остаются только изменения, которые могут затронуть критичные системы. Платформа интегрирована с корпоративными системами: SIEM, резервное копирование, служба каталогов, сканирование уязвимостей. Инфраструктура построена на российском серверном оборудовании и работает под управлением РЕД ОС.

Первые миграции выполняли вручную, и стало ясно, что такой подход не масштабируется: в компании работало несколько платформ виртуализации, и комбинации оборудования, версий, драйверов и операционных систем не повторялись. Массовую миграцию автоматизировали: скорость выросла с 30 виртуальных машин в месяц до более 30 в день, в отдельные периоды до 40. Инструмент применяется и для переноса нагрузок между российскими платформами и между центральными и удалёнными площадками, миграция стала регулярным управляемым процессом. В облако переведены корпоративная учётная система 1С, серверы приложений, терминальные сервисы и система управления событиями информационной безопасности. Высоконагруженные системы на 1С требовали отдельной работы: анализ архитектуры, поиск узких мест, нагрузочное тестирование в условиях, близких к промышленным, и только затем масштабирование. Горячая миграция затронула машины с базами данных объёмом более 30 ТБ. Время прерывания сервисов при переносе сократилось в 7 раз. Самый крупный сценарий: переход самого большого кластера, около 1300 виртуальных машин, на новую версию платформы. Компания выбрала параллельное построение: рядом с действующим кластером на новом оборудовании готовили новый, затем вводили период заморозки изменений в старом. Подготовка заняла около трёх месяцев, само переключение около часа.

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

Компания оценивает платформу по трём группам метрик, и по каждой есть результат. - Скорость. Стандартная виртуальная машина предоставляется за 20 минут вместо 9 дней, миграция ускорилась с 30 виртуальных машин в месяц до более 30 в день. - Качество сервиса. Корпоративные системы, включая 1С, работают в облаке; крупнейший кластер переведён на новую версию платформы с окном переключения около часа. - Эффективность. Утилизация мощностей в центральных ЦОД выросла с 30% до 70%, плотность использования инфраструктуры втрое. На удалённых площадках компания сознательно держит резерв под отказоустойчивость. - Компания перешла к модели внутреннего облачного провайдера, а обновления платформы и миграции стали регулярными операциями, которые инженеры проводят самостоятельно.

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