Что такое частное облако?

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

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

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

Что такое частное облако?

Частное облако – это облачная инфраструктура, предназначенная для исключительного использования одной организацией. Ее ресурсами могут пользоваться разные подразделения, команды или внутренние системы компании, но сама среда создается для потребностей этой организации. Управлять ею может сама компания, внешний провайдер или обе стороны в соответствии с согласованным распределением ответственности.

Такое определение соответствует классификации, представленной в NIST Special Publication 800-145. NIST указывает, что частное облако может принадлежать самой организации, третьей стороне или обеим сторонам, а его инфраструктура может находиться как на площадке организации, так и за ее пределами. Следовательно, физическое расположение оборудования не является единственным признаком private cloud.

Частное облако не следует отождествлять с одним выделенным сервером. Dedicated server может быть частью такой архитектуры, но cloud-модель предполагает работу с пулом вычислительных, дисковых и сетевых ресурсов, их централизованное управление, виртуализацию и возможность выделять мощности отдельным рабочим нагрузкам без жесткой привязки каждой системы к одному физическому серверу.

Также важно различать полностью выделенную private cloud и VPC – Virtual Private Cloud. В VPC клиент получает логически изолированную виртуальную сеть и контроль над ее адресацией, маршрутами, подсетями и правилами доступа, но физическая платформа может обслуживать нескольких заказчиков. Именно как логически изолированную виртуальную сеть VPC определяет, например, официальная документация AWS.

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

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

Hostpark предлагает отдельное коммерческое решение «Частное облако VMware». При выборе такой платформы важно оценивать не только маркетинговое название, но и фактическую конфигурацию среды: доступные ресурсы, уровень логической или физической изоляции, модель управления, характеристики storage, сетевые возможности, резервирование, backup, условия SLA и границы ответственности провайдера.

Как работает частное облако?

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

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

Типичная частная облачная среда может состоять из следующих уровней:

• Вычислительные ресурсы. Физические серверы предоставляют CPU и оперативную память для виртуальных машин, контейнеров и других рабочих нагрузок. Фактическая производительность зависит от моделей процессоров, архитектуры узлов, политик резервирования и допустимого overcommit.
• Системы хранения данных. Дисковые массивы или программно определяемые хранилища используются для системных дисков, баз данных, файлов и образов виртуальных машин. Для оценки важны не только доступные гигабайты, но и задержка, IOPS, пропускная способность, отказоустойчивость и доступные классы storage.
• Сетевая инфраструктура. Коммутаторы, маршрутизация, VLAN, виртуальные сети, VPN и правила фильтрации обеспечивают связь между компонентами и контроль трафика. Сетевую архитектуру необходимо проектировать с учетом внешних интеграций, административного доступа и необходимости резервирования каналов.
• Уровень виртуализации. Гипервизор создает и изолирует виртуальные среды и позволяет распределять между ними ресурсы физического кластера. Функциональность зависит от конкретной платформы, лицензий, версии программного обеспечения и активированных компонентов.
• Платформа управления. Через панель, API или средства автоматизации администраторы создают виртуальные машины, изменяют конфигурации, настраивают сети и контролируют использование ресурсов. Наличие API особенно важно для Infrastructure as Code, автоматического развертывания и интеграции с корпоративными процессами.
• Средства защиты и непрерывности. В архитектуру при необходимости добавляются firewall, шифрование, журналирование, резервное копирование, репликация, мониторинг и disaster recovery. Их наличие, параметры и ответственные стороны зависят от конкретной конфигурации и договора.

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

Отдельное значение имеет сетевой уровень. В корпоративной среде можно разделять административный, внутренний и внешний трафик, создавать отдельные сегменты для баз данных, приложений или тестовых систем и определять правила доступа между ними. Для дополнительной защиты периметра Hostpark отдельно предлагает Atman Firewall. Это самостоятельная сетевая услуга, поэтому ее не следует считать автоматически включенной в любое частное облако.

Хранилище также необходимо подбирать под характер нагрузки. Для транзакционных баз данных могут быть важны стабильная задержка, количество операций ввода-вывода и производительность во время пиков, тогда как архивы, резервные наборы или большие объемы статических файлов предъявляют другие требования. Hostpark отдельно предлагает Object Storage на инфраструктуре Atman с доступом через совместимые протоколы S3 и Swift. Это отдельный тип объектного хранилища, а не обязательный storage-уровень частного VMware-облака.

Реальная гибкость частной среды зависит от запаса ресурсов и архитектуры. Если в доступном пуле имеются свободные CPU, RAM и storage, увеличение конфигурации виртуальной машины или создание новой VM может выполняться без приобретения отдельного сервера. Если физические ресурсы исчерпаны, кластер необходимо расширять или изменять заказанную конфигурацию. Отдельные операции масштабирования также могут потребовать планового окна или переноса рабочих нагрузок.

Какие бывают виды частного облака?

Частное облако является отдельной моделью развертывания cloud infrastructure, но на практике его реализацию часто описывают по месту размещения оборудования и способу администрирования. Поэтому термины on-premises, hosted и managed характеризуют разные аспекты одного решения и могут частично сочетаться.

On-premises private cloud

On-premises private cloud развертывается на инфраструктуре самой организации. Серверы, storage и сетевое оборудование находятся на ее площадке или в собственном дата-центре, а компания контролирует физическую платформу и облачное программное обеспечение.

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

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

Hosted private cloud

Hosted private cloud размещается в дата-центре внешнего провайдера. Бизнесу не требуется самостоятельно создавать серверное помещение, системы охлаждения, резервное электропитание или внешнюю сетевую инфраструктуру. Общие принципы работы профессиональных ЦОД подробнее описаны в материале о том, как работает дата-центр.

При этом hosted private cloud не следует автоматически воспринимать как отдельный физический кластер. Конкретная реализация может предусматривать dedicated hardware, зарезервированный пул или другую схему изоляции. Уровень выделения серверов, сети и storage должен определяться технической спецификацией конкретной услуги.

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

Managed private cloud

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

Объем managed-услуг зависит от договора. Он может охватывать поддержку платформы виртуализации, мониторинг, сетевую инфраструктуру, обновление определенных компонентов, управление емкостью или другие операции. При этом администрирование гостевых операционных систем, баз данных и бизнес-приложений может оставаться ответственностью клиента.

В договоре необходимо отдельно зафиксировать, кто устанавливает обновления, реагирует на уведомления, управляет учетными записями, восстанавливает данные, тестирует backup и отвечает за устранение уязвимостей внутри VM. Без такого разграничения термин managed может создавать ошибочное ожидание, что провайдер полностью отвечает за все уровни системы.

Отдельно существуют гибридные архитектуры, в которых частная среда взаимодействует с публичным облаком или другими площадками. Для построения выделенного соединения с ресурсами AWS, Google Cloud или Microsoft Azure Hostpark предлагает Atman Cloud Connect. Это отдельный сервис передачи данных, который может использоваться как часть гибридной или multi-cloud архитектуры.

Преимущества и недостатки частного облака

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

Контроль над архитектурой

Частная среда позволяет точнее определять конфигурацию ресурсов, сетевую топологию, правила сегментации, модели доступа, требования к storage и другие параметры. Это важно для систем с нестандартными интеграциями, специфическим программным обеспечением или особыми корпоративными стандартами.

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

Изоляция ресурсов и безопасность

Одной из причин использования private cloud является необходимость в отдельной среде для систем одной организации. Однако уровень изоляции необходимо оценивать фактически. Логически изолированный VPC на общей аппаратной платформе и частное облако на dedicated hardware – это разные архитектурные модели.

Ни одна из них не обеспечивает безопасность сама по себе. Рисками остаются скомпрометированные учетные записи, неправильные права доступа, уязвимые приложения, отсутствие обновлений, ошибки конфигурации, недостаточная сегментация или непродуманная стратегия резервного копирования. Private cloud следует рассматривать как один из уровней архитектуры, а не как замену системному управлению информационной безопасностью.

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

Масштабирование

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

Однако частное облако имеет физические ограничения. Если резерв CPU, RAM или storage исчерпан, требуется расширение инфраструктуры. Оно может предполагать заказ оборудования, добавление узлов, приобретение лицензий или изменение тарифной конфигурации. Поэтому утверждения о неограниченном или мгновенном масштабировании без привязки к конкретной архитектуре являются некорректными.

Прогнозируемость ресурсов

Выделенный или зарезервированный пул позволяет планировать инфраструктуру под конкретную нагрузку и уменьшать зависимость от поведения других клиентов на тех уровнях, которые изолированы выбранной архитектурой. Это может быть важно для ERP, баз данных, VDI и других корпоративных систем.

Однако прогнозируемая производительность зависит не от слова private, а от параметров CPU, storage, сети, политик overcommit, резервирования и поведения платформы при отказе узлов. Эти характеристики необходимо оценивать в технической спецификации и проверять нагрузочными тестами до переноса критических систем.

Стоимость и сложность

Частное облако обычно предполагает резервирование или выделение определенного объема инфраструктуры для одного заказчика, поэтому его экономика отличается от массовой public cloud. Для on-premises в расходы входят оборудование, лицензии, электропитание, охлаждение, сеть, физическая безопасность, запасные компоненты и персонал. В hosted-модели значительная часть этих расходов переносится в оплату услуг провайдера.

Оценивать необходимо общую стоимость владения: вычислительные ресурсы, storage, лицензии, сетевые сервисы, backup, техническую поддержку, миграцию, администрирование, обучение команды и дальнейшее расширение. Сравнивать только цену CPU и RAM недостаточно, поскольку в разных предложениях часть компонентов может оплачиваться отдельно.

Необходимость компетентного администрирования

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

Отдельно планируется резервное копирование. Наличие облачной платформы не означает автоматического создания независимых копий данных. Hostpark предлагает отдельные сервисы резервного копирования, включая решения на основе Veeam и BaaS Atman. Для критических систем необходимо определить политику backup, периодичность создания копий, срок их хранения, защиту от удаления и процедуру регулярной проверки восстановления.

Чем частное облако отличается от публичного?

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

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

Пример публичной модели в актуальном предложении Hostpark – Atman Cloud. Платформа построена на OpenStack и работает как shared public cloud, где клиенты получают отдельные виртуальные среды на общей инфраструктуре.

Коммерческая терминология разных провайдеров может отличаться от академической классификации. В частности, VPC предоставляет логически частную среду, но не обязательно означает dedicated physical infrastructure. Поэтому при сравнении cloud-решений необходимо анализировать фактический уровень изоляции, модель распределения ресурсов и технические гарантии, а не только название продукта.

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

Кому и для чего необходимо частное облако?

Целесообразность private cloud определяется не только размером компании. Важнее то, какие системы она использует, насколько критичны данные, требуется ли специальная сетевая архитектура, какой уровень контроля необходим и насколько стабильной или прогнозируемой является нагрузка.

Один из характерных сценариев – критические корпоративные системы, для которых компания хочет контролировать размещение ресурсов, сетевые сегменты, административные доступы, storage и политики резервирования. Это могут быть ERP, CRM, базы данных, системы документооборота, внутренние порталы, VDI или специализированные бизнес-приложения.

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

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

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

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

Частная модель может быть актуальна и для организаций с требованиями к определенному месту обработки данных, специальным интеграциям или контролю аппаратной платформы. Однако соответствие регуляторным требованиям не возникает автоматически благодаря использованию private cloud. Необходимо оценивать место хранения, доступы, шифрование, журналы, субподрядчиков и другие меры.

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

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

Выбор необходимо начинать с инвентаризации систем. Компания должна понимать, какие приложения и данные требуется перенести, сколько CPU, RAM и storage они используют, как изменяется нагрузка, какие зависимости существуют между системами и какой простой является приемлемым.

При сравнении решений целесообразно последовательно проверить следующие параметры:

1. Тип среды и уровень изоляции. Необходимо определить, достаточно ли логически изолированного VPC или проект требует dedicated physical servers, storage либо сетевых компонентов. Эту характеристику нельзя определять только по названию продукта – она должна быть зафиксирована в спецификации.
2. Вычислительные ресурсы. Следует оценить CPU, RAM, storage, допустимые лимиты, политики overcommit и запас мощности. Для производительных систем важны характеристики дискового уровня, сети и поведение платформы во время пиковой нагрузки.
3. Сетевая архитектура и безопасность. Необходимо определить сегментацию, маршрутизацию, VPN, административный доступ, правила фильтрации, журналирование и ответственность за защиту операционных систем и приложений. Отдельно проверяются пропускная способность, задержка и резервирование каналов.
4. Масштабирование. Следует понимать, как увеличиваются CPU, RAM и storage, что происходит после исчерпания текущего пула и требует ли расширение простоя отдельных компонентов. Также необходимо уточнить сроки предоставления дополнительных ресурсов.
5. SLA и доступность. Важно проверить, на какой именно компонент распространяется SLA, как определяется недоступность, какие предусмотрены исключения и какая ответственность установлена договором. SLA дата-центра, сети, cloud platform и конкретной VM нельзя отождествлять.
6. Backup и disaster recovery. Необходимо определить, входит ли резервное копирование в конфигурацию, где находятся копии, как они защищены, каков срок их хранения, а также согласовать целевые RPO и RTO для критических систем. Backup и DR являются разными уровнями защиты.
7. Границы технической поддержки. Следует зафиксировать, за что отвечает провайдер: физическую платформу, виртуализацию, сеть, гостевые ОС, базы данных, backup или приложения. Формулировка «поддержка 24/7» сама по себе не определяет перечень работ и время выполнения каждой операции.
8. Полная стоимость. Необходимо учитывать ресурсы, лицензии, storage, резервное копирование, сетевые услуги, IP-адреса, миграцию, администрирование, поддержку и дальнейшее масштабирование. Отдельно следует проверить минимальные обязательства, сроки договора и условия выхода с платформы.

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

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

Для критических систем важно моделировать не только нормальную работу, но и отказы. Необходимо понимать, что произойдет при выходе из строя физического узла, storage или сетевого компонента, где находятся независимые копии данных и каким будет порядок восстановления. Отказоустойчивый кластер защищает от части инфраструктурных сбоев, но не заменяет резервные копии и DR-план.

RPO определяет допустимый объем потери данных во времени, а RTO – целевое время восстановления сервиса. Например, ежедневная копия может означать потенциальную потерю изменений за значительную часть суток, даже если само восстановление выполняется быстро. Эти показатели необходимо определять для каждой критической системы с учетом ее роли в бизнес-процессах.

Резервное копирование не заменяет disaster recovery. Backup необходим для возврата данных или системы к предыдущему состоянию, а DR описывает восстановление критических сервисов после серьезной аварии. Hostpark предлагает отдельную услугу DRaaS, которую следует оценивать как самостоятельный компонент стратегии непрерывности, а не как автоматическую функцию частного облака.

Подходы к планированию восстановления информационных систем, анализу влияния на бизнес и определению стратегий непрерывности изложены в NIST Special Publication 800-34 Rev. 1. Документ не заменяет индивидуальный DR-план, но помогает правильно разграничить резервное копирование, техническое восстановление и обеспечение непрерывности операций.

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

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

Заключение

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

Ключевой характеристикой является не само слово private, а фактическая архитектура. Логически изолированный VPC, dedicated physical infrastructure и полностью управляемая частная среда имеют разные уровни изоляции, контроля, стоимости и ответственности сторон. Поэтому эти понятия нельзя использовать как взаимозаменяемые.

Также частное облако само по себе не гарантирует backup, disaster recovery, firewall, безотказность или определенный SLA. Каждый из этих компонентов должен быть предусмотрен архитектурой и подтвержден спецификацией услуги или договором. Для критических систем необходимо отдельно определить RPO, RTO, процедуры тестового восстановления и ответственных лиц.

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