В прошлой статье «Непрерывность малого бизнеса и выбор провайдера услуг сопровождения» мы говорили о том, насколько полезно подчинить формирование Соглашения об уровне услуг SLA (Service Level Agreement) актуальным бизнес-задачам. Не следует считать содержание услуги SLA внутренним делом. Согласно «Википедии», Соглашение об уровне обслуживания – термин методологии ITIL, обозначающий формальный договор между заказчиком услуги и её поставщиком, содержащий описание услуги, права и обязанности сторон, а также согласованный уровень качества предоставления данной услуги. Фактически Соглашение об уровне обслуживания — это оформляемое приложением к сервисному контракту соглашение о способе контроля производительности поставщика услуг.
Сервисный контракт — это документ более высокого порядка в отношениях между сторонами. Соглашение об уровне (SLA) является подчиненным. Это важное различие, потому что аббревиатура SLA часто неправильно используется для ссылки на договорные отношения в целом. Контракт, как правило, содержит политики для приемлемого использования, обязательства конфиденциальности, средства правовой защиты от неисполнения.
Сервисный контракт об обслуживании: юридический документ, определяющий правила юридического договора между пользователем облака и поставщиком облака.
Соглашения об уровне услуг SLA: документ, в котором указаны технические гарантии производительности, которые дает облачный провайдер, как обнаруживаются и обрабатываются споры, а также любые способы устранения сбоев производительности.
Облачные SLA
Сервисный контракт и SLA Соглашение об уровне оказываемых услуг неразрывно связаны с сервисами. Потребитель может иметь соглашение с одним поставщиком, но услуга при этом предоставляется через множество субподрядчиков. Таким образом, потребитель не имеет прямых договорных отношений с этими предприятиями и может даже не знать об их существовании. Более динамичная номенклатура сервисов требует адекватной динамики формирования услуги SLA. В телекоммуникационной отрасли уже применяются автоматизированные средства формирования SLA, адекватные набору оказываемых сервисов. Облачные услуги занимают промежуточное место между традиционными ИТ и телекоммуникационными услугами. В сравнении с традиционными ИТ, в бизнесе число участников процесса оказания облачного сервиса выше, а участие некоторых из них абсолютно незаметно для потребителей. Например, облачные услуги могут оказываться подрядчиком в ЦОД, арендованном у другого подрядчика.
Поскольку SLA – инструмент контроля производительности подрядчика, предоставляющего аутсорсинг IT-услуг, его показатели должны быть измеряемы. Метрики в SLA обычно разделены на две основные категории: бизнес-метрики и технические метрики (метрики мониторинга), которые позволяют выполнять бизнес-требования. Метрики, включаемые в мониторинг, как правило, являются основным компонентом SLA Соглашения об уровне оказываемых услуг. Вот некоторые примеры показателей: количество пользователей, минуты экземпляра, объем используемых ресурсов хранилища, байты, минуты процессора и объем оперативной памяти в мегабайтах. Метрики затрат устанавливаются в денежной форме (например, «рублей/минута экземпляра»).
Метрики SLA требуют соответствующей категоризации, уточнения для соответствия целям SLA и определения последствий, когда SLA не выполняются. Например, «время отклика» может быть указано в SLA, в то время как другие технические меры, такие как «скачки» и «полоса пропускания», могут использоваться для динамического распределения ресурсов, позволяя выполнять SLA «время отклика».
Таблица ниже представляет упрощенный пример того, как метрика «времени отклика» может быть определена и оценена в контексте SLA.
Контекст
Показатель
Ограничения
В рабочее время с 00:00 до 12:00 по Московскому времени (без гарантии в нерабочее время)
Измерение 1
Дата / время запроса к облачному провайдеру на получение дополнительной памяти
Измерение 2
Дата / время успешного ответа от облачного провайдера
Расчет метрики
Значение 2 – Значение 1
Метод сбора
Автоматизировано
Единицы
Миллисекунды
Гарантии поставщика
Гарантия поставщика облачных вычислений - максимум 3000 миллисекунд времени отклика на запросы хранилища IaaS с 00:00 до 12:00.
Ответственность
На каждые 10 запросов хранилища IaaS, превышающих 3000 миллисекунд, будет применено сокращение на 10% к общей стоимости хранения IaaS за месяц.
Метрики облачных вычислений предоставляют важную информацию для оптимизации работы в облаке, проведения сравнительного анализа и принятия обоснованных решений. Они являются краеугольным камнем прозрачного управления Соглашения об уровне услуг SLA и надлежащего управления. Соображения по метрикам зависят от поддерживаемых моделей (IaaS, PaaS и SaaS) и типа услуг, предоставляемых в них (сети, хранилища и вычислительных услуг для IaaS). Например, «Восстановление» может использовать «Среднее время восстановления» в качестве показателя облачного SLA. В таком контексте часто указываются ожидания, связанные с минимумами, максимумами, значениями по умолчанию и последствиями отклонений от заявленных целей. Появился новый термин Соглашение об уровне облачных услуг (Cloud Service Level Agreement, CSLA).
Таким образом, при рассмотрении метрик в CSLA рекомендуется, чтобы потребители и поставщики одинаково поняли:
бизнес-цели для облачной возможности;
контекст и место, в котором заинтересованные стороны вписываются в облачную экосистему;
потенциальные каскадные соглашения об уровне обслуживания и связанные с ними метрики;
значение «технических метрик» по сравнению с более видимыми «бизнес-метриками»;
набор метрик, которые соответствуют приоритетным целям;
применяемые модели стоимости использования;
как будут использоваться метрики и какие решения будут приниматься;
определение показателей на правильном уровне детализации и способы их контроля на постоянной основе;
какие доступные стандарты помогают обеспечить последовательный метод измерения (некоторые будут развиваться по мере развития облачных вычислений);
ценность и ограничения собранных метрик.
Облачные контракты
Сервисные контракты и облачные соглашения об уровне обслуживания являются ключевыми компонентами сервисов облачных вычислений, но они, возможно, являются наименее понятными, поскольку для них нет общепринятых стандартных структур или языка. Первоначальные контракты на облачные сервисы будут в основном включать роли потребителя и поставщика услуг. Однако в обществах с развитым институтом оказания услуг в области ИКТ возникли роли не только поставщика и потребителя облачных услуг, но и брокера, аудитора, транспортера (carrier), интегратора и аудитора. Эти функции и многосторонние контракты в этой работе не рассматривались, однако следует иметь в виду объективный вектор развития облачных услуг.
Контракт по умолчанию, предлагаемый провайдерами облачных услуг, часто составляется для защиты интересов провайдера и может серьезно ограничивать осведомленность потребителя в механизмах доставки услуги, включая зависимости от других провайдеров и их пригодность, надежность обработки данных потребителя. Кроме того, контракт обычно ограничивает возможности потребителя в случае невыполнения обязательств поставщиком или субподрядчиком. Таким образом, потребитель облачных услуг обязан исследовать потенциальных провайдеров вместе с их зависимостью от партнеров в предоставлении услуги и стремиться к заключению контрактов, которые распределяют ответственность между потребителем и провайдером.
Основные принципы заключения справедливых контрактов на облачные вычисления и CSLA остаются неизменными: распределение ответственности и сопутствующие риски между вовлеченными сторонами наряду с четко определенными спецификациями и методами оценки производительности.
Хотя специфика доступности в качестве целевого показателя производительности может содержаться в SLA, контракты с поставщиками могут включать в себя более широкую формулировку заявления об услуге, предоставляемой на условиях «как есть» и «как доступно». Такие заявления заслуживают тщательной проверки, чтобы все стороны одинаково понимали, что означает доступность услуг по сравнению с простоями, как запланированными, так и незапланированными. Также считается, что в какой-то момент предоставление скидки не может быть удовлетворительным средством для значительных или повторяющихся сбоев доступности услуг со стороны поставщика, независимо от причины.
Для облачных вычислений сервисный контракт будет иметь ряд отличий.
Административный
права интеллектуальной собственности на сервис/контент;
обязательства конфиденциальности;
условия раскрытия данных, при которых поставщики будут раскрывать информацию о клиентах (включая данные клиентов, хранящиеся в облаке поставщика);
доступность данных после завершения отношений по договору;
юрисдикция расположения данных;
условия изъятия данных как имущества;
взаимное раскрытие информации о сбое в работе;
обязательства взаимной отчетности об инцидентах;
порядок внесения изменений SLA;
форс-мажорные обстоятельства.
Финансовый
гарантии исправления дефектного продукта;
порядок определения скидки для будущих счетов при нарушении SLA;
ответственность за ущерб прямая;
ответственность за ущерб косвенная;
ограничения ответственности.
Технический
сертификация технических и нетехнических средств;
границы организации, координации и управления (оркестровка услуг) облачной инфраструктурой;
границы интероперабельности;
функциональная совместимость и обмен информацией между различными функциональными блоками;
плановые отключения облачных услуг.
Безопасность
безопасность облачных услуг;
непрерывный мониторинг безопасности;
расследования, пригодные в качестве доказательства в суде;
управление идентификацией и контролем доступа к ресурсам;
внеплановое отключение;
действия при аварийном восстановлении;
порядок реагирования на инцидент.
По мере развития сервисов облачных вычислений, транспортные средства, которые формируют основу отношений между ролями (то есть контракты и Соглашения об уровне услуг SLA), будут развиваться. Термины и их определения, содержащиеся в этом документе, могут нуждаться в изменении или добавлении других определений, чтобы лучше отражать контекст и использование в соглашениях. Тем не менее, они служат основой для содействия содержательному обсуждению между поставщиками и потребителями облачных услуг в создании высококачественного и полезного CSLA.