Договор оказания облачных услуг

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

Существует четыре главные вида договоров облачного сервиса, которые могут соответствовать вашим потребностям в зависимости от размера бизнеса, решений, которые вы хотите разместить, и так далее:
 

1. Инфраструктура как услуга (IaaS). Модель облачных вычислений, которая позволяет предприятиям за ежемесячную абонентскую плату пользоваться ИТ-инфраструктурой, которая находится в ЦОДе провайдера: серверами, системами хранения и резервного копирования, сетью. Вам больше не нужно приобретать собственное компьютерное оборудование, устанавливать его и обслуживать. Компании, заключающие договор IaaS, выигрывают от повышения гибкости: они могут увеличить или уменьшить свое потребление в соответствии со своими потребностями. Конечный пользователь должен настроить и управлять платформой и средой, развертывать приложения на ней. Примеры IaaS: AWS (EC2), GCP (CE), Microsoft Azure (VM).
    

2. Платформа как услуга (PaaS). Позволяет компаниям иметь быструю вычислительную среду, полностью информируя их о приложениях, которые они устанавливают, настраивают и используют. PaaS хорошо подходит для хостинга приложений, которые не подходят для модели SaaS. Разработка и эксплуатация приложений возможна без какого-либо беспокойства, обновления платформы и базового программного обеспечения – все это полностью поддерживается поставщиком. Преимущества очевидны: доступ к платформе осуществляется напрямую через веб-браузер без установки плагина, выполнение приложения осуществляется на той же платформе, предоставляемой удаленно, и через веб-интерфейс вашего хоста. Примеры PaaS: Google App Engine, CloudFoundry, Heroku, AWS (Beanstalk).
    

3. Программное обеспечение как услуга (SaaS). Это самая простая и самая популярная облачная модель для использования одного или нескольких приложений. Заключив договор услуг SaaS, компании получают к ним доступ с любого подключенного компьютера с помощью простого веб-браузера, при этом лицензию покупать не нужно, программное обеспечение обновляется без вашего участия.  Лучший пример SaaS - GMAIL. Команда Google управляет всем, мы используем приложение через любой клиент или браузер. Другие примеры: 1С и Salesforce.
    

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

Некоторые эксперты различают разновидности этих моделей, а именно: 

• Контейнер как услуга (CaaS). Это облачная виртуальная инфраструктура на основе контейнеров, в которой механизмы контейнеров, оркестровка и базовые вычислительные ресурсы доставляются пользователям как услуга от облачного провайдера. Google Container Engine (GKE), AWS (ECS), Azure (ACS) и Pivotal (PKS) являются примерами CaaS.

• Функция как услуга (FaaS). Предоставляет платформу, позволяющую заказчикам разрабатывать, запускать и управлять функциональными возможностями приложений без сложностей построения и обслуживания инфраструктуры. AWS (Lamda), Google Cloud Function — примеры Faas.

Общие требования к договору

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

 

Стандарт эталонной архитектуры облачных вычислений ИСО / МЭК 177891 предусматривает роль Партнера облачного сервиса. Партнер облачных услуг является стороной, занимающейся поддержкой деятельности клиента или провайдера облачных услуг. Соглашения об облачных услугах (CSA) предназначены для установления четких ожиданий в отношении обслуживания между клиентом и провайдером облачных услуг, но также должны существовать между клиентом и другими облачными организациями, такими как облачный оператор, облачный брокер и даже облачный аудитор. Одной из партнерских ролей, которая особенно важна для CSA и SLA, является облачный аудитор. Маловероятно, что клиент имеет непосредственное представление о работе поставщика облачного сервиса, особенно в отношении таких аспектов, как безопасность и защита конфиденциальных данных.  Сосредоточимся на требованиях, которые являются общими для всех моделей взаимодействия:
 

• Гарантии CSA должны быть определенными, объективными и измеримыми с помощью масштабированной матрицы штрафов, которая описывает случаи нарушений провайдером. 

• Политика допустимого использования определяет, как клиент может использовать сервис, и какие действия может предпринять провайдер в случае нарушения клиентом.

• Список отказа от ответственности указывает, что представляет собой незаконное использование.

• Избыточное использование. Использование сверх пороговых значений по контракту повлечет за собой рост стоимости. Клиенты должны правильно определить свои требования и понять, что будет в том случае, когда ими будет превышен порог использования.

• Активация услуги. Время, когда услуга становится активной, должно быть точно определено, чтобы обеспечить «отправную точку» для измерения производительности. 

• Модель оплаты должна быть определена, обычно в виде ежемесячной абонентской платы или платы за использование.

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

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

• Перемещаемость. Клиенты должны учитывать потенциальную необходимость передачи соглашения в случае продажи их бизнеса.

• Служба поддержки. Клиенты должны сообщать о проблемах, указанных в CSA, в службу поддержки.

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

• Субподрядные услуги. Клиент должен убедиться, что CSA непосредственного поставщика однозначно заявляет, что его CSA относится к полному сервису, независимо от того, являются ли части сервиса сторонними.

• Лицензионное программное обеспечение. Облачные услуги могут включать стороннее лицензионное программное обеспечение, которое оплачивается ежемесячно на основании лицензионного соглашения с поставщиком услуг. Такое ПО регулярно обновляется его производителем.

• Отраслевые стандарты. Клиенты, которые работают в регулируемых отраслях, должны убедиться, что их юридическая команда полностью вовлечена в переговоры по CSA.

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

В зависимости от выбранной модели предоставления услуги могут быть разные требования к содержанию CSA: инфраструктура как услуга (IaaS), платформа как услуга (PaaS), программное обеспечение как услуга (SaaS) и рабочий стол как услуга (DaaS, Desktop-as-a-Service). Эластичность является фундаментальным преимуществом использования облака, Соглашения об облачных услугах отражают необычные аспекты его аутсорсинга.
 

Специфика модели

IaaS, Faas. Облачные IaaS CSA аналогичны SLA для сетевых служб, хостинга и аутсорсинга центров обработки данных. Основные проблемы связаны с отображением требований приложений высокого уровня на уровне сервисов инфраструктуры. Метрики хорошо понятны в абстракциях IaaS (вычисления, сеть и хранилище). Клиенты должны настаивать на включении следующих метрик в своем облачном SLA:
 

• показатели: доступность, продолжительность простоя, время перезагрузки сервера;

• метрики сети: доступность, потеря пакетов, пропускная способность, задержка, среднее / максимальное дрожание;

• метрики хранения: доступность, ввод / вывод в секунду, максимальное время восстановления, время обработки, задержка с внутренним вычислительным ресурсом.
   

Метрики вычислений обычно исключают уровни обслуживания для их производительности. Заказчикам просто гарантируется доступность вычислительных ресурсов, за которые они заплатили. Клиенты должны различать среды разработки IaaS и производственные среды IaaS при рассмотрении своих соглашений об облачном обслуживании. В производственных средах обычно требуются более строгие цели уровня обслуживания, чем в средах разработки. Сетевые метрики в облачном SLA обычно охватывают подключение центра обработки данных облачного провайдера к интернету в целом, а не к какому-либо конкретному провайдеру или клиенту. В договорах IaaS предпринимаются некоторые усилия по стандартизации, которые помогают описывать и управлять услугами, предлагаемыми на этом уровне. По возможности клиенты должны убедиться, что CSA включает положения, требующие от своих облачных провайдеров поддержки открытых стандартных интерфейсов, форматов и протоколов для повышения функциональной совместимости и портативность.
 

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

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

2. Решения на основе развертывания. Позволяет развертывать промежуточное программное обеспечение поверх ресурсов, приобретенных у облачного провайдера согласно договору IaaS, предлагая услуги по развертыванию для клиентов, которые автоматизируют процесс установки и настройки промежуточного ПО. Эти решения PaaS дают богатый набор возможностей управления, включая возможность автоматического изменения количества машин, назначенных приложению, и автоматическое масштабирование в соответствии с использованием приложения.
    

При рассмотрении своих договоров об облачном обслуживании PaaS, клиенты должны различать среды разработки PaaS и производственные среды PaaS. В производственных средах обычно требуются более строгие цели уровня обслуживания, чем в средах разработки. Как минимум все требования IaaS SLA должны включаться в PaaS SLA. Появляются стандарты, помогающие идентифицировать услуги PaaS, предлагаемые поставщиками облачных услуг, и стандартные интерфейсы для связи с поставщиками PaaS для предоставления или управления периферией. Такие стандарты, как OASIS Topology and Orchestration Specification для облачных приложений (TOSCA), уже разработаны для решения вопросов переносимости и совместимости между провайдерами. Кроме того, предложения PaaS с открытым исходным кодом, такие как Cloud Foundry и OpenShift, начинают набирать обороты на рынке. Заказчики должны убедиться, что их CSA включает в себя поддержку открытых стандартов по мере их появления, чтобы уменьшить зависимость от провайдера.
 

SaaS, DaaS, FaaS. Учитывая разнообразие услуг, предоставляемых на основании SaaS-договора, сложно предоставить исчерпывающий и репрезентативный список целей уровня обслуживания SaaS, на которые клиенты должны обратить внимание в своих CSA. Однако клиенты должны ожидать, что общие цели уровня обслуживания SaaS, такие как ежемесячное совокупное время простоя каждого приложения, время отклика приложения, постоянство информации о заказчике и автоматическая масштабируемость, обязательно должны быть включены в их CSA. Клиенты должны убедиться, что данные, хранящиеся в облачных ресурсах провайдера, хранятся в стандартных форматах, чтобы обеспечить их переносимость в случае необходимости перехода к другому провайдеру. Заказчики услуг должны настаивать на гибких договорах с отчетностью, которая содержит измеримые критерии по отношению к их целям, а не к потребностям поставщиков облачных услуг.
 

Интерес к облачным услугам отражает объективный мировой процесс: отказ от владения в пользу аренды во всем — от жилья до гаджетов. Люди все чаще хотят заменить право владения правом пользования. Облачные вычисления позволяют развить эту тенденцию и дополнительно снимают ограничения. Потребности современной компании изменились: больше не возникает вопрос, стоит ли использовать облако, вопрос лишь в том, какую модель облачных услуг выбрать.