• Текст документа
  • Статус
Документ в силу не вступил

ПНСТ 367-2019


ПРЕДВАРИТЕЛЬНЫЙ НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ

Информационный менеджмент

ОБЛАЧНЫЕ ВЫЧИСЛЕНИЯ

Структура соглашения об уровне сервиса. Метрическая модель

Information management. Cloud computing. Service level agreement (SLA) framework. Metric model


ОКС 35.020

Срок действия с 2021-01-01
по 2021-12-31


Предисловие

1 РАЗРАБОТАН Акционерным обществом "Всероссийский научно-исследовательский институт сертификации" (АО "ВНИИС") и Обществом с ограниченной ответственностью "Информационно-аналитический вычислительный центр" (ООО ИАВЦ)

2 ВНЕСЕН Техническим комитетом по стандартизации ТК 022 "Информационные технологии"

3 УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 18 октября 2019 г. N 44-пнст

Правила применения настоящего стандарта и проведения его мониторинга установлены в ГОСТ Р 1.16-2011 (разделы 5 и 6).

Федеральное агентство по техническому регулированию и метрологии собирает сведения о практическом применении настоящего стандарта. Данные сведения, а также замечания и предложения по содержанию стандарта можно направить не позднее чем за 4 мес до истечения срока его действия разработчику настоящего стандарта по адресу: 123557 Москва, Электрический пер., д.3/10, стр.1 и/или в Федеральное агентство по техническому регулированию и метрологии по адресу: 109074 Москва, Китайгородский проезд, д.7, стр.1.

В случае отмены настоящего стандарта соответствующая информация будет опубликована в ежемесячном информационном указателе "Национальные стандарты" и также будет размещена на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (www.gost.ru)

Введение


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

- ясность: определение того или иного показателя может быть неполным, неоднозначным, нелогичным или противоречивым, либо такое определение может полностью отсутствовать. Например, определение такого показателя, как "доступность", может не иметь ничего общего с общепринятым понятием термина "доступность". В случае такой неоднозначности сервис может быть практически постоянно недоступен в общепринятом смысле, а в соответствии с выбранным определением показателя показывать стопроцентную доступность. Такое может произойти в случае, если для определения значения показателя требуется постоянный мониторинг, который невозможно обеспечить, или если значение показателя определяется на основании экспертной оценки провайдером сервиса, оценка которого может оказаться субъективной;

- сопоставимость: сравнение различных сервисов с точки зрения требуемого качества сервиса может оказаться нецелесообразным или невозможным вследствие несовместимости определений соответствующих показателей, а также их количественных и качественных характеристик;

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

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

- ясность: формулировка определения показателя устраняет неоднозначность, присущую описанию, сделанному с помощью "естественного языка";

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

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

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

1 Область применения


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

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

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

Любая спецификация показателей признается как соответствующая настоящему стандарту в том случае, если эта спецификация использует типы данных и отношения, описанные в разделе 7 настоящего стандарта. Если XML-документ, описывающий метрику, использует пространство имен urn: RosStandard:IT:CloudComputing:SLA:Metrics:v1.0.0, этот документ должен соответствовать схеме, приведенной в приложении А.

2 Термины и определения


В настоящем стандарте применены следующие термины с соответствующими определениями.

2.1 характеристика облачного сервиса: Свойство облачного сервиса.

Примечание - Свойство/характеристика может быть качественным или количественным.

2.2 показатель облачного сервиса: Показатель, предназначенный для определения характеристики облачного сервиса.

2.3 целевой параметр облачного сервиса: Обязательство провайдера облачного сервиса обеспечить заданную характеристику облачного сервиса.

Примечание - Набор целевых параметров облачного сервиса представляет собой объединение набора целевых количественных и качественных параметров облачного сервиса.

2.4 измерение: Набор операций, направленных на получение результатов измерений.

Примечание - Представленное определение основано на определении "измерения" в соответствии с [1]*. Кроме указанного, в настоящем стандарте оно используется в значении отдельного акта выполнения указанных операций, направленных на получение отдельного экземпляра результатов измерений.
________________
* Поз.[1]-[4] см. раздел Библиография. - Примечание изготовителя базы данных.

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

2.6 показатель: Стандарт измерений, определяющий условия и правила выполнения измерений и интерпретации результатов измерений.

Примечания

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

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

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

2.7

единица измерения: Вещественная скалярная величина, принятая к использованию как эталон для определения количественного значения измеряемой характеристики.

[ИСО/МЭК 80000-1:2009, пункт 3.9]


3 Сокращения


В настоящем стандарте использованы следующие сокращения:

СУС - соглашение об уровне сервиса;

Облачный СУС - соглашение об уровне облачного сервиса;

ПОС - показатели облачных сервисов;

ПДн - персональные данные;

ЦЗОС - целевое значение облачного сервиса;

ЦКОС - целевое качество облачного сервиса.

4 Обзор показателей

4.1 Общие положения


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

4.2 Контекст разработки


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

К основным категориям характеристик облачных сервисов, в которых может быть заинтересован потребитель, относятся: производительность, доступность, информационная безопасность, удобство, поддержка, возможность прекращения использования, управление, изменение сервиса, надежность сервиса, наличие необходимой аттестации/сертификации, управление данными и защита персональных данных. Описание каждой категории, а также соответствующих качественных и количественных характеристик дано в [2].

Процесс приобретения облачных сервисов может быть разбит на три основных этапа:

а) подбор облачных сервисов, которые удовлетворяют требованиям потребителя;

б) достижение соглашения относительно свойств и состава облачного сервиса между провайдером и потребителем (договор, который включает в себя облачные СУС);

в) оперативное управление, в рамках которого выполняется мониторинг облачного сервиса на предмет соответствия ограничениям, заданным в договоре.

4.2.1 Выбор облачного сервиса

В настоящее время провайдеры определяют состав характеристик облачного сервиса и способы их количественной оценки каждый по-своему. Это делает сравнение характеристик облачных сервисов разных провайдеров (а иногда и одного провайдера) сложным или даже невозможным. Характеристики облачного сервиса часто определяются с помощью размытых текстовых описаний и их трудно не только сравнить, но и просто понять. Это затрудняет перенос набора требований в соглашение между потребителем и провайдером, в результате формируются соглашения (СУС), которые могут не отвечать потребностям сторон. Как описано в [2], обязательство, записанное в облачный СУС, принимает количественную (ЦЗОС) или качественную (ЦКОС) форму. ЦЗОС - это обязательства провайдера по обеспечению характеристик предоставляемого облачного сервиса, имеющие количественную оценку, в то время как ЦКОС - это обязательства в отношении качественных характеристик.

Пример - Облачный сервис будет доступен 99,9% времени в заданный период времени. В случае невыполнения данного обязательства потребитель имеет право на получение компенсации, предусмотренной договором.

Недоступность означает:

а) облачный сервис не отвечает на запросы;

б) облачный сервис возвращает ответ на допустимый запрос пользователя в течение двух или более последовательных интервалов длительностью в 1 минуту;

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

Это важное понятие, поскольку оно имеет основополагающее значение для всех облачных сервисов. Хотя для доступности указано число (в процентах), неясно, как это число рассчитывается. Определение недоступности дано, но неясно, как рассчитывается процент доступности в случае недоступности. Другой поставщик может использовать понятие доступности и рассчитывать его по-другому, что делает невозможным сравнение целевого параметра или измеренных уровней сервиса. В таблице 1 приведено сравнение доступности двух сервисов.

Таблица 1 - Пример разных интерпретаций провайдерами одной характеристики

Сервис

Определение доступности

Обязательство

Целевой параметр

Сервис 1

Доля времени безотказной работы в общем количестве времени работы

99,99%

Время безотказной работы

Сервис 2

Доля успешных транзакций в общем количестве транзакций

99,99%

Время безотказной работы


Сравнение доступности двух сервисов, приведенных в таблице 1, невозможно. В то время как характеристика ("доступность") и обязательство по ее целевому значению (99,99%) кажутся идентичными, текст, определяющий время безотказной работы двух сервисов, принципиально отличается. Облачный сервис 1 использует определение доступности, основанное на времени, а облачный сервис 2 использует определение доступности, основанное на транзакциях. Поэтому потребитель неспособен оценить, в чем заключается различие между этими сервисами.

4.2.2 Преобразование требований потребителя в соглашение

После выбора сервиса провайдер и потребитель уточняют целевые требования к параметрам сервиса. Требования будут преобразованы в набор ЦЗОС (количественные характеристики) и ЦКОС (качественные характеристики), фиксируемые в облачном СУС. Как и описания возможностей облачных сервисов, используемых в процессе принятия решений, ЦЗОС/ЦКОС в настоящее время также описываются неформализованным образом с использованием естественного языка. Это добавляет двусмысленность процессу и увеличивает его время и сложность, поскольку каждый целевой параметр должен быть тщательно рассмотрен и оценен в каждом конкретном случае.

4.2.3 Обеспечение выполнения соглашения

После заключения соглашения и подготовки облачного сервиса к работе начинается его эксплуатация сотрудниками потребителя. В процессе эксплуатации и провайдер, и потребитель контролируют заданные параметры работы сервиса. Провайдер предоставляет потребителю инструменты для измерения характеристик облачного сервиса и/или данные для их измерения. Потребитель сравнивает результаты измерения уровня сервиса с целевыми значениями, указанными в соглашении. Из-за неоднозначного и противоречивого характера описания ЦЗОС/ЦКОС и показателей потребителю сейчас трудно быть уверенным в том, что результаты измерений вычисляются так же, как это определено в облачном СУС.

4.3 Показатели


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

ПНСТ 367-2019 Информационный менеджмент. Облачные вычисления. Структура соглашения об уровне сервиса. Метрическая модель

Рисунок 1 - Определение правил измерения показателем


Показатель описывает характеристику облачного сервиса и сведения, необходимые для ее использования (параметры, данные, правила, выражения, дополнительные сведения). Например, показатель "доступность" будет определять практические шаги процесса измерения, необходимые для расчета доступности, измерения времени простоя, правил исключения и т.д. Результатом измерения является значение, полученное в результате выполнения измерения заданного показателя. Оно служит оценкой наблюдаемой характеристики. Как показано на рисунке 1, показатель определяет правила измерения, поэтому измерение может быть выполнено повторяемым, сопоставимым способом. Измерение дает результат измерения, который в сочетании с информацией о показателе предоставляет сведения о характеристике. Характеристики облачных сервисов почти никогда точно не известны, поэтому вместо этого выполняется аппроксимация характеристики (на основе одного или нескольких измерений), при этом учитывается погрешность между аппроксимацией и фактическим значением характеристики. Эта погрешность напрямую связана с используемым процессом измерения. Другими словами, показатель - это стандартный набор правил, позволяющих генерировать повторяемые, сопоставимые оценки характеристики.

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

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

4.4 Показатели облачных сервисов


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

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

Хотя метрическая модель, описанная в разделе 6, предназначена для общего пользования, в настоящем стандарте основное внимание уделяется показателям, используемым в облачных СУС.

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

- показатели могут использоваться провайдерами для описания производительности облачного сервиса;

- помогают потребителям сравнивать предложения от разных провайдеров (в тех случаях, когда провайдеры используют одни и те же показатели);

- могут использоваться для описания ЦЗОС и ЦКОС облачного СУС;

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

4.4.1 Основные заинтересованные стороны

Настоящий раздел содержит список сторон, заинтересованных в показателях облачных СУС. Каждая группа заинтересованных сторон имеет различные интересы и проблемы. Каждая группа заинтересованных сторон использует показатели по-разному с учетом своих интересов. Общий состав и структура заинтересованных сторон представлена на рисунке 2.


ПНСТ 367-2019 Информационный менеджмент. Облачные вычисления. Структура соглашения об уровне сервиса. Метрическая модель

Рисунок 2 - Состав и структура сторон, использующих показатели


Представитель

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

Контролирующая сторона

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

Удостоверяющая сторона

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

Договорный отдел/закупочное подразделение потребителя

Участвует в переговорах между потребителем и провайдером. Использует показатели настоящего стандарта для анализа возможностей сервиса и сравнения одного сервиса с другими. Стоит отметить, что сотрудникам по закупкам потребителя не нужно полное понимание показателя. Все, что требуется, - это понимание основного описания и определения показателя.

Операционное подразделение провайдера

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

Команда продаж провайдера

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

Риск-менеджер сервиса (со стороны провайдера)

Гарантирует, что сервис соответствует требованиям сертификации и аудита (как внутреннего, так и внешнего), а также другим контрольным мероприятиям. Использует показатели настоящего стандарта для измерения и сравнения характеристик облачных сервисов.

Служба поддержки (со стороны провайдера)

Осуществляет оценку претензий к качеству сервиса, если определенный целевой параметр не был обеспечен.

Команда разработки

Внедряет системы измерения на основе показателей настоящего стандарта для мониторинга производительности обслуживаемых сервисов и определения степени соответствия параметрам СУС.

Интегратор сервисов

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

Служба стороннего мониторинга

Отслеживает обслуживаемые сервисы, используя показатели настоящего стандарта. Должна знать показатели, используемые для данного ЦЗОС или ЦКОС и отслеживать, чтобы мониторинг выполнялся с использованием тех же показателей. Может привлекаться как потребителем, так и провайдером, а также другими заинтересованными сторонами для выполнения измерений показателей настоящего стандарта.

4.4.2 Направления использования показателей облачных сервисов

Настоящий пункт описывает общие направления использования показателей.

4.4.2.1 Описание облачных сервисов

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

4.4.2.2 Сравнение облачных сервисов

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

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

4.4.2.3 Интерпретация соглашений об уровне облачного сервиса

Важные для потребителя характеристики сервисов включаются в облачный СУС в форме целевых параметров показателей.

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

4.4.2.4 Разработка инструментов мониторинга производительности

Настоящий стандарт определяет модель показателей целостным и непротиворечивым образом, что позволяет группам разработчиков понять, как создавать инструменты для получения и интерпретации результатов измерений отдельного показателя.

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

Потребители или сторонние лица, такие как аудиторы облачных СУС, могут использовать метрические описания для разработки механизмов мониторинга сервиса и обнаружения нарушений условий соглашения (в большинстве случаев потребители сами контролируют выбранные сервисы и требуют компенсаций в случаях, когда провайдеры не выполняют свои обязательства).

4.4.2.5 Мониторинг производительности сервиса

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

4.4.2.6 Верификация облачных СУС

Измерение формирует результат измерения, являющееся значением, оценивающим характеристику. Поскольку измерение основано на тех же показателях, которые используются для характеристики облачных СУС (через целевой параметр, входящий в СУС), можно сравнить результат измерения (т.е. уровень сервиса) с обязательствами относительно целевых параметров, как показано на рисунке 3.


ПНСТ 367-2019 Информационный менеджмент. Облачные вычисления. Структура соглашения об уровне сервиса. Метрическая модель

Рисунок 3 - Роль показателей в цикле мониторинга сервиса

4.4.2.7 Завершение функционального цикла

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

4.5 Показатели облачных СУС


Определение и использование показателей, а также порядок их измерения являются важными компонентами облачных СУС и ЦЗОС/ЦКОС, которые являются составными частями облачных СУС. В облачных СУС показатели используются для установления границ, в которых должен действовать поставщик сервиса. Стандартные показатели и шаблоны показателей облачных СУС упрощают и ускоряют разработку облачных СУС и включенных в них ЦЗОС/SQO легче и быстрее.

5 Обзор метрической модели

5.1 Общие положения


Целью настоящего стандарта является описание модели определения показателей облачных СУС. Модель формирует основу для определения показателей и использования их потенциальными заинтересованными сторонами.

Как указано в [2], "определения облачных ЦЗОС и ЦКОС нейтральны к технологиям или бизнес-моделям, поэтому не все ЦЗОС и ЦКОС применимы к тем или иным облачным сервисам, а те, которые применяются, могут быть реализованы и применены по-разному в каждом конкретном облачном сервисе".

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

Комплекс целевых параметров может быть описан с использованием более чем одного показателя.

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

Полезно отметить, что хотя метрическая модель предназначена для поддержки показателей облачных СУС, ее можно использовать для определения любых показателей.

5.2 Основные понятия


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

5.2.1 Целевые количественные (ЦЗОС) и качественные (ЦКОС) параметры сервиса

Облачный СУС включает в себя набор целевых количественных (ЦЗОС) и качественных (ЦКОС) параметров сервисов, в отношении которых берет обязательства провайдер сервисов.

Метрическая модель в этом стандарте может использоваться для описания показателей, используемых для описания как ЦЗОС, так и ЦКОС. Однако в случае ЦКОС отсутствуют формулы и параметры, поскольку ЦКОС определяется набором правил формирования показателей.

Пример ЦЗОС - доступность (см. приложение В.1 для этой метрики в форме, предусмотренной настоящим стандартом).

Обязательство

Облачный сервис будет доступен 99,9% времени в заданный период времени. В случае невыполнения этого обязательства потребитель имеет право на получение компенсации в соответствии с условиями договора.

Недоступность означает:

- облачный сервис не отвечает на запросы

- облачный сервис возвращает ответ на корректный запрос пользователя в течение двух или более последовательных интервалов длительностью по одной минуте.

В соответствии с замерами третьей стороны длительность загрузки эталонного документа превышает среднюю величину в 1 секунду.

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

Определения

Регламентные работы - мероприятия по обслуживанию, запланированные не позднее чем за 5 дней до начала, длительностью не более 1 часа в календарную неделю.

Пример ЦКОС - согласие на сбор и использование персональных данных (см. В.2 приложения В для соответствующего показателя в форме, предусмотренной настоящим стандартом).

Описание

Данный параметр (ЦКОС) относится к качественным параметрам, описывающим тип договоренности относительно сбора, использования и обмена персональными данными. Значение параметра соответствует следующей шкале.

Формулировка и выходные данные

Уровень 0 - Отсутствие согласия. В процессе или перед сбором персональных данных согласие пользователя получено не было.

Уровень 1 - Предполагаемое согласие. Согласие вытекает из действий субъекта данных, инструменты выражения согласия или отказа не предоставляются.

Уровень 2 - Отказ. Субъект данных может принять меры для недопущения сбора персональных данных, при этом инструменты выражения согласия не предоставляются.

Уровень 4 - Выраженное согласие. Субъект данных явным образом подтверждает согласие на сбор и/или использование персональных данных.

5.2.2 Форматы показателей

Модель, описанная в разделе 7, формирует концептуальную основу для спецификации показателей целостным и непротиворечивым для разных групп пользователей способом, обеспечивает сопоставимость показателей и потенциально облегчает автоматизацию процесса определения показателей. Подробная спецификация показателя может быть выполнена в формах XML- и JSON-документов или других сериализуемых форматах, как это показано в примерах, представленных в приложениях Б и В к настоящему стандарту. В настоящем стандарте представлены два подхода к заданию показателей:

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

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

6 Метрическая модель

6.1 Разработка метрической модели


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

- целостное и полное представление информации: информация о показателях должна быть представлена непротиворечивым и воспроизводимым образом, чтобы ее можно было эффективно организовывать, обмениваться ею и использовать ее;

- явное выделение связей: показатели должны быть представлены таким образом, чтобы отношения между ними, если таковые имеются, были явными. Это объясняет их воздействие и их важность;

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

- сопоставимость: показатели должны содержать достаточно информации, чтобы пользователь мог эффективно сравнивать их, находить и понимать сходства и различия;

- адаптивность: модель должна быть достаточно гибкой, чтобы ее можно было легко интегрировать с другими метрическими моделями, дополняющими данную модель (например, определять методы и процесс измерения);

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

6.1.1 Спецификация метрической модели

На рисунке 4 показана метрическая модель, поддерживающая ЦЗОС/ЦКОС [2].


ПНСТ 367-2019 Информационный менеджмент. Облачные вычисления. Структура соглашения об уровне сервиса. Метрическая модель

Рисунок 4 - UML-представление метрической модели


Эта модель использует обозначения диаграммы класса UML [3]. Классы (показаны в виде прямоугольников) представляют типы элементов, которые можно найти в экземпляре показателя. Классы содержат признаки, определяющие данные, присоединенные к элементу. Отношения между классами называются ассоциациями и отображаются в виде линий, связывающих прямоугольники.

Ассоциации с пустым ромбом - это группы, представляющие собой набор повторно используемых элементов. Стрелки в конце ассоциаций показывают направление ассоциации (например, от показателя к правилам). Метка рядом с ассоциацией представляет определенную роль для класса.

Настоящий стандарт не предписывает конкретный формат представления показателя, но используемый формат должен соответствовать схеме классов, описанной на рисунке 4. Если для описания показателя используется XML, он должен основываться на пространстве имен "urn:RosStandard:IT:CloudComputing:SLA:Metrics:v1.0.0" (XML-схема представлена в приложении Г), а также должен соответствовать схеме, приведенной в приложении А.

6.1.2 Описание метрической модели

Элемент Metric содержит основную информацию, связанную с показателем. Эта информация предоставляет контекст для показателя. Элемент Expression содержит формулу или текстовое описание (например, выраженное на естественном языке), необходимые для количественного или качественного расчета результата измерения показателя. Элемент Metric может состоять из вложенных элементов, которые записываются в том же виде, что и элемент Metric. Элементы Parameter содержат значения, используемые в элементе Expression. Параметры рассчитываются перед процессом измерения и остаются постоянными во время процесса измерения, но могут изменяться между двумя измерениями. Элементы Rule содержат ограничения, необходимые для понимания характеристики и обеспечения повторяемости измерений, выполненных с помощью показателя.

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

6.1.3 Расширение показателей

При необходимости для обеспечения соответствия дополнительным бизнес-требованиям данная модель может быть расширена. Расширяемость поддерживается для того, чтобы повысить гибкость метрической модели, расширить ее возможности, а также свести к минимуму необходимость изменений и обновлений в основном стандарте при появлении новых тенденций в СУС. Расширяемость реализуется посредством либо создания новых элементов метрической модели, либо расширения существующих элементов новыми полями (допускается сочетание и того, и того).

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

6.1.4 Детальное описание метрической модели

Каждый представленный в метрической модели класс подробно описан в приведенных далее таблицах. Указанные таблицы образуют нормативное описание модели и содержат больше сведений, чем представлено на рисунке 4. В таблице 2 приведено детальное описание показателя.

Таблица 2 - Показатель: детальное описание

Имя класса

Metric

Описание

Информация о показателе

Атрибут или класс

Тип

Множественность/
обязательность

Определение

Id

Строка

1

Уникальный идентификатор показателя в рамках данного контекста

description

Строка

0..*

Описание показателя

source

Строка

1

Разработчик показателя (лицо или организация)

scale

Список выбора

1

Классификатор типа данных, полученных в результате измерения; возможные значения: "номинальный", "порядковый", "интервальный" и "отношение"; количественные параметры (ЦЗОС) могут быть "интервальными" или "отношениями", качественные параметры (ЦКОС) могут быть "номинальными" и "порядковыми"

Note

Строка

0..*

Дополнительная информация о показателе или способе его применения

category

Строка

0..1

Указание на принадлежность к группе показателей со сходными формулами расчета, правилами или параметрами

expression

Expression

0..1

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

и правил; формулы могут также ссылаться на идентификаторы других выражений, показателей и параметров; в то же время идентификаторы, используемые в рамках одной формулы, должны быть уникальными

parameter

Parameter

Доступ к полной версии этого документа ограничен

Ознакомиться с документом вы можете, заказав бесплатную демонстрацию систем «Кодекс» и «Техэксперт».

Что вы получите:

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

При возникновении проблем свяжитесь с нами по адресу spp@kodeks.ru

ПНСТ 367-2019 Информационный менеджмент. Облачные вычисления. Структура соглашения об уровне сервиса. Метрическая модель

Название документа: ПНСТ 367-2019 Информационный менеджмент. Облачные вычисления. Структура соглашения об уровне сервиса. Метрическая модель

Номер документа: 367-2019

Вид документа: ПНСТ

Принявший орган: Росстандарт

Статус: Документ в силу не вступил

Опубликован: Официальное издание. М.: Стандартинформ, 2019 год
Дата принятия: 18 октября 2019

Дата начала действия: 01 января 2021
Дата окончания действия: 31 декабря 2021
Информация о данном документе содержится в профессиональных справочных системах «Кодекс» и «Техэксперт»
Узнать больше о системах