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

(утв. и введен в действие Приказом Росстандарта от 18.10.2019 № 44-пнст)

Утвержден и введен в действие

ИНФОРМАЦИОННЫЙ МЕНЕДЖМЕНТ

по 31 декабря 2021 года

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Примечание — Представленное определение основано на определении «измерения» в соответствии с [1]. Кроме указанного, в настоящем стандарте оно используется в значении отдельного акта выполнения указанных операций, направленных на получение отдельного экземпляра результатов измерений.

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.

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

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

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

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

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

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

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

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

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

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

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

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

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].

Рисунок 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 приведено детальное описание показателя.

Показатель: детальное описание

Имя класса	Metric
Описание	Информация о показателе
Атрибут или класс	Тип	Множественность/обязательность	Определение
Id	Строка	1	Уникальный идентификатор показателя в рамках данного контекста
description	Строка	0..*	Описание показателя
source	Строка	1	Разработчик показателя (лицо или организация)
scale	Список выбора	1	Классификатор типа данных, полученных в результате измерения; возможные значения: «номинальный», «порядковый», «интервальный» и «отношение»; количественные параметры (ЦЗОС) могут быть «интервальными» или «отношениями», качественные параметры (ЦКОС) могут быть «номинальными» и «порядковыми»
Note	Строка	0..*	Дополнительная информация о показателе или способе его применения
category	Строка	0..1	Указание на принадлежность к группе показателей со сходными формулами расчета, правилами или параметрами
expression	Expression	0..1	Формула, описывающая порядок расчета показателя; количественные параметры должны иметь формулу расчета, в то время как качественные параметры могут иметь, а могут и не иметь формулы расчета, т.е. быть специфицированными с помощью естественного (неформализованного) языка; в формулах расчета используются идентификаторы исходных показателей, параметров и правил; формулы могут также ссылаться на идентификаторы других выражений, показателей и параметров; в то же время идентификаторы, используемые в рамках одной формулы, должны быть уникальными
parameter	Parameter	0..*	Параметры определяют фиксированные величины, используемые в формуле или показателе, и известные на момент выполнения расчетов; значение параметра вычисляется до того, как запускается измерение показателя; параметр может быть использован в более чем одном показателе, если в наборе использующих его показателей данный параметр имеет уникальный идентификатор
rule	Rule	0..*	Правило предназначено для определения границ показателя и указания допустимых методов измерения; правило может ссылаться на идентификаторы других формул; в то же время в рамках отдельного правила должны использоваться уникальные идентификаторы
underlyingMetric	Metric	0..*	Показатель, используемый внутри формулы в качестве переменной; связь с указанным показателем в формуле производится через идентификатор показателя
underlyingExpression	Expression	0..*	Дополнительное выражение, используемое в рамках основной формулы, параметра или правила

Детальное описание формулы приведено в таблице 3.

Таблица 3

Формула: детальное описание

Имя класса	Expression
Описание	Формула для расчета показателя и сопроводительная информация
Атрибут или класс	Тип	Множественность/обязательность	Определение
id	Строка	1	Уникальный идентификатор формулы (в контексте показателя)
description	Строка	0..*	Описание формулы
expressionStatement	Строка	1	Определение формулы, использующее, при необходимости, идентификаторы связанных показателей, параметров и правил; в то же время в рамках отдельной формулы должны использоваться уникальные идентификаторы
expressionLanguage	Строка	1	Язык, используемый для формул расчета показателя (в соответствии с ИСО 80000)
note	Строка	0..*	Дополнительная информация о формуле
unit	Строка	0..1 (требуется, если тип результата «интервал» или «отношение»)	Единица измерения

Детальное описание параметра приведено в таблице 4.

Таблица 4

Имя класса	Parameter
Описание	Параметр определяет фиксированные величины, используемые в показателях, формулах или правилах на момент их расчета; параметр может быть использован в более чем одном показателе, если в наборе использующих его показателей данный параметр имеет уникальный идентификатор
Атрибут или класс	Тип	Множественность/обязательность	Определение
id	Строка	1	Уникальный идентификатор параметра
description	Строка	0..*	Описание параметра
parameterStatement	Строка	1	Порядок расчета параметра или его величина
unit	Строка	1	Единица измерения
note	Строка	0..*	Дополнительная информация о параметре

Имя класса	Rule
Описание	Правило предназначено для определения границ показателя и указания допустимых методов измерения; например, показатель «AvailabilityDuringBusinessHour» может быть описан через задание ограничений показателя «Availability» посредством определения «BusinessHour» (час рабочего времени). Правило содержит ограничения для формулы расчета показателя; ограничения могут задаваться различным образом: неформализованным языком, ИСО 80000, SBVR и т.д.
Атрибут или класс	Тип	Множественность/обязательность	Определение
id	Строка	1	Уникальный идентификатор правила
description	Строка	0..*	Описание правила
ruleStatement	Строка	1	Ограничение метрики
ruleLanguage	Строка	1	Язык, используемый для формулировки правила в ruleStatement
note	Строка	0..*	Дополнительная информация о правиле

Приложение А (обязательное)

ВЗАИМОСВЯЗЬ ПОКАЗАТЕЛЕЙ, ЦЕЛЕВЫХ ПАРАМЕТРОВ И ИХ РАСЧЕТОВ

Рисунок А.1 — Целевой параметр и его оценка

Целевой параметр: детальное описание

Имя класса	SO
Описание	Целевой параметр, ассоциированный с конкретным показателем
Атрибут или класс	Тип	Множественность/обязательность	Определение
Id	Строка	1	Уникальный идентификатор параметра
name	Строка	0..*	Имя целевого параметра в соответствии с «ключевыми понятиями» [6]
soConditionStatement	Строка	1	Условное выражение, определяющее обязательство по отношению к целевому параметру
note	Строка	0..*	Дополнительная информация о целевом параметре
metric	Metric	1	Показатель, ассоциированный с целевым параметром

Имя класса	MeasurementResult
Описание	Результат измерения характеристик облачного сервиса, основанных на показателе
Атрибут или класс	Тип	Множественность/обязательность	Определение
Id	Строка	1	Уникальный идентификатор результата измерений
value	Строка	1	Величина, составляющая результат измерений
uncertainty	Строка	1	Формулировка, характеризующая погрешность результата измерений, вытекающая из особенностей процесса измерений
time	Строка	1	Дата и время проведенного измерения
note	Строка	0..*	Дополнительная информация о результате измерения
metric	Metric	1	Показатель, используемый для получения «value» и «uncertainty»; ссылается на тот же показатель, который ассоциирован с целевым параметром

Таблица А.3

Имя класса	SO Evaluation
Описание	Оценка целевого параметра на основе результата измерений для тех случаев, когда целевой параметр и результат измерений (количественный или качественный) основаны на одном и том же показателе
Атрибут или класс	Тип	Множественность/обязательность	Определение
id	Строка	1	Уникальный идентификатор выполненной оценки
comparisonResult	Логический	1	Результат сравнения результата измерений с заданной величиной целевого параметра (обязательством)
note	Строка	0..1	Дополнительная информация о проведенной оценке
so	SO	1	Целевой параметр, относительно которого выполняется оценка
measurementResult	MeasurementResult	1	Результат измерения, соотнесенный с оценкой целевого параметра

Приложение Б (рекомендуемое)

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

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

При использовании данного шаблона первой создается таблица Metric, связанная с ней таблица Expression, и далее, по необходимости, таблицы Rule и Parameter.

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

Таблица Б.3 «Параметры» содержит определения параметров, используемых в формулах.

Таблица Б.4 «Правила» содержит правила или ограничения, которым должно соответствовать измерение.

Metric (id)
description
source
scale
note
category
expressionStatement
parameter
rule
underlyingMetric
underlyingExpression

Expression (id)
description
expressionStatement
expressionLanguage
unit
note

Parameter (id)
description
parameterStatement
unit
note

Таблица Б.4

Правила

Rule (id)
description
ruleStatement
ruleLanguage
note

Таблица Б.5

Табличная форма целевого параметра

SO (id)
name
soConditionStatement
note
metric

Таблица Б.6

Таблица оценки целевого параметра

SO Evaluation (id)
comparisonResult (true/false)
note
so
measurementResult

MeasurementResult (id)
value
uncertainty
time
note
metric

Приложение В (справочное)

В.1 Пример количественной характеристики «Доступность облачного сервиса: табличная и XML-реализация»

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

В.1.1 Описание примера параметра «доступность»

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

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

В.1.2 Анализ целевого параметра

Целевой параметр указан в разделе «Обязательства» и составляет 99,95% времени. Время, в течение которого данная характеристика может измеряться, также указано в разделе «Обязательства» как «период тарификации», но значение или порядок определения величины «период тарификации» не представлены. В рамках примера принимается, что «период тарификации» составляет 30 дней. Описание недоступности дано в разделе «Недоступность». В соответствии с описанием имеется три типа недоступности:

• отсутствие ответа;

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

Этой информации достаточно для формирования показателя «доступность». В приведенном далее разделе дается описание данного показателя в табличной форме в соответствии с приложением В, а также в форме XML-документа, сформированного в соответствии со схемой, представленной в приложении А.

В таблице В.1 приведен пример целевого параметра «доступность» в табличной форме.

Целевой параметр «доступность»

SO (SO_001)
name	Доступность облачного сервиса (Cloud service availability)
metric	M_AVL_002
soConditionStatement	> 99.95%

В.1.3 Пример показателя в табличной форме

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

Metric (M_AVL_002)
description	Доступность облачного сервиса (CloudServiceAvailability)
source	Пример
scale	«Отношение»
note	Основано на общепринятой практике
expressionStatement	E_001
parameter	P_001
underlyingMetric	M_TQD_001

Expression (E_001)
expressionStatement	100 x (P_001 — M_TQD_001)/P_001
expressionLanguage	ИСО 80000
unit	Проценты

Parameter (P_001)
parameterStatement	2.592 x10^6
unit	Секунды
note	Параметр соответствует 30-дневному периоду тарификации, выраженному в секундах

Metric (M_TQD_001)
description	Общее время простоя (TotalQualifiedDownTime)
source	Пример
scale	«Отношение»
underlyingMetric	M_QDT_001
expression	E_001

Таблица В.6

Expression (E_001)
expressionStatement	\Sigma(M_QDT_001)
expressionLanguage	ИСО 80000
unit	Секунда

Таблица В.7

Metric (M_QDT_001)
description	Время простоя (QualifiedDownTime)
source	example
scale	RATIO
rule	R_001, R_002, R_003
expression	E_001

Таблица В.8

Expression (E_Q001)
expressionStatement	\Delta(t)
expressionLanguage	ИСО 80000
unit	Секунда

Rule (R_001)
ruleStatement	Временной интервал начинается с момента обнаружения, что сервис недоступен, и завершается в момент, когда фиксируется, что сервис перестал быть недоступен в соответствии с правилами R_002, R_003, R_004
ruleLanguage	Russian

Rule (R_002)
ruleStatement	Сервис не откликается
ruleLanguage	Russian

Таблица В.11

Rule (R_003)
ruleStatement	Сервис возвращает ошибку сервера в ответ на корректный пользовательский запрос в течение двух или более последовательных интервалов длительностью по одной минуте
ruleLanguage	Russian

Rule (R_004)
ruleStatement	Длительность загрузки эталонного документа превышает среднюю величину в 1 секунду. Недоступность, вызванная регламентными работами, исключена из расчета
ruleLanguage	Russian

В.1.4 Пример метрики в форме XML-документа

Ниже представлен пример XML-документа, описывающий изложенный выше пример метрики.

expressionLanguage=«ISO80000»unit=«percentage»/>

<Parameterid=«P_001»parameterStatement=«2.592 x10^6»unit=«second»

note=«Параметр соответствует 30-дневному периоду тарификации, выраженному в секундах „/>“»

<Metricdescription=«TotalQualifiedDowntime»source=«example»id=«M_TQD_001»scale=«RATIO»>

<Expressionid=«E_001»expressionStatement=«Σ(M_QDT_001)»

expressionLanguage=«ISO80000»unit=«second»/>

<UnderlyingMetricRefrefid=«M_QDT_001»/>

<Metricdescription=«QualifiedDownTime»source=«example»id=«M_QDT_001»scale=«RATIO»>

<Expressionid=«E_001»expressionStatement=«Δ(t)»expressionLanguage=«ISO80000»unit=«second»/>

<Ruleid=«R_001»ruleLanguage=«Russian»lang=«ru»

ruleStatement=«Временной интервал начинается с момента обнаружения, что сервис недоступен, и завершается в момент, когда фиксируется, что сервис перестал быть недоступен в соответствии с правилами R_002, R_003, R_004»/>

ruleStatement=«Сервис возвращает ошибку сервера в ответ на корректный пользовательский запрос в течение двух или более последовательных интервалов длительностью по одной минуте»/>

<Ruleid=«R_004»ruleLanguage=«Russian»lang=«ru»

ruleStatement=«Длительность загрузки эталонного документа превышает среднюю величину в 1 секунду. Недоступность, вызванная регламентными работами, исключена из расчета.»/>

В.1.5 Пример оценки целевого параметра доступности

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

• связанный показатель M_QDT_001 = [4000 с, 3200 с] (примем наличие двух периодов простоя);

M_AVL_002 = 100* \frac{P_001 - M_TQD_001}{P_001} ;

Один из способов использования показателя облачного СУС — оценка целевого параметра, включенного в облачный СУС. На рисунке 3 представлена связь между результатом измерения M_AVL_002 и значением целевого параметра. Поскольку обе величины основаны на одном и том же показателе, они подлежат сравнению с точки зрения оценки факта выполнения зафиксированных обязательств. На основе приведенного выше примера оценка целевого параметра выглядит следующим образом:

Таблица В.13

MeasurementResult (MR_001)
value	99.722
uncertainty	Не задана
time	23.05.2018 21:00
metric	M_AVL_002

Таблица В.14

SO Evaluation (SOE_001)
comparisonResult (true/false)	FALSE
so	SO_001
measurementResult	MR_001

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

В.2 Пример качественной характеристики «Согласие на сбор и использование персональных данных»

В.2.1 Описание примера качественного целевого параметра

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

• уровень 0 — Отсутствие согласия. В процессе или перед сбором персональных данных согласие пользователя получено не было;
• уровень 1 — Предполагаемое согласие. Согласие вытекает из действий субъекта данных, инструменты выражения согласия или отказа не предоставляются;

Предоставленной информации достаточно для формирования показателя «Согласие на сбор и использование персональных данных». В следующих разделах представлено описание указанного показателя в табличной форме (в соответствии с приложением Б) и в форме XML-документа по схеме, заданной в приложении Г.

Таблица В.15

SO (SO_002)
Name	Согласие на обработку персональных данных (PII Consent)
soConditionStatement	True if «3»
Metric	M_TPC_001

В.2.3 Пример показателя в табличной форме

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

Metric (M_TPC_001)
Description	Тип согласия на обработку персональных данных (TypePIIConsent)
Source	Пример
Scale	«Порядковый»
Note	Согласие на обработку персональных данных ранжировано по следующей шкале
Expression	E_TCL_001
underlyingMetric	M_TCL_001, M_TCL_002, M_TCL_003, M_TCL_004

Таблица В.17

Expression (E_TCL_001)
expressionStatement	M_TPC_001 равняется одной из величин M_TCL_001, M_TCL_002, M_TCL_003, or M_TCL_004, в зависимости от критериев, указанных в соответствующих правилах
expressionLanguage	Russian

Metric (M_TCL_001)
description	Тип согласия — Уровень 0 (TypePIIConsent_Level0)
source	Пример
scale	«Порядковый»
rule	R_001
expression	E_001

Таблица В.19

Expression (E_001)
expressionStatement	0
expressionLanguage	ИСО 80000

Таблица В.20

Rule (R_001)
ruleStatement	Отсутствие согласия. В процессе или перед сбором персональных данных согласие пользователя получено не было
ruleLanguage	Russian

Таблица В.21

Metric (M_TCL_002)
description	Тип согласия — Уровень 1 (TypePIIConsent_Level1)
source	Пример
scale	«Порядковый»
rule	R_002
expression	E_002

Таблица В.22

Expression (E_002)
expressionStatement	1
expressionLanguage	ИСО 80000

Таблица В.23

Rule (R_002)
ruleStatement	Предполагаемое согласие. Согласие вытекает из действий субъекта данных, инструменты выражения согласия или отказа не предоставляются
ruleLanguage	Russian

Таблица В.24

Metric (M_TCL_003)
description	Тип согласия — Уровень 2 (TypePIIConsent_Level2)
source	Пример
scale	«Порядковый»
rule	R_003
expression	E_003

Таблица В.25

Expression (E_003)
expressionStatement	2
expressionLanguage	ИСО 80000

Таблица В.26

Rule (R_003)
ruleStatement	Отказ. Субъект данных может принять меры для недопущения сбора персональных данных, при этом инструменты выражения согласия не предоставляются
ruleLanguage	Russian

Таблица В.27

Metric (M_TCL_004)
description	Тип согласия — Уровень 3 (TypePIIConsent_Level3)
source	Пример
scale	«Порядковый»
rule	R_004
expression	E_004

Таблица В.28

Expression (E_004)
expressionStatement	3
expressionLanguage	ИСО 80000

Таблица В.29

Rule (R_004)
ruleStatement	Выраженное согласие. Субъект данных явным образом подтверждает согласие на сбор и/или использование персональных данных.
ruleLanguage	Russian

<Metricsxmlns=«urn:RosStandard:IT:CloudComputing:SLA:Metrics:v1.0.0»>

<Metricid=«M_TPC_001»description=«TypeOfPIIConsent»source=«example»scale=«ORDINAL»

note=«Согласие на обработку персональной информации ранжировано по следующей шкале»>

<Expressionid=«E_TCL_001»

expressionStatement=» M_TPC_001 равняется одной из величин M_TCL_001, M_TCL_002, M_TCL_003, orM_TCL_004, в зависимости от критериев, указанных в соответствующих правилах»

expressionLanguage=«Russian»/>

<UnderlyingMetricRefrefid=«M_TCL_001»/>

<UnderlyingMetricRefrefid=«M_TCL_002»/>

<UnderlyingMetricRefrefid=«M_TCL_003»/>

<UnderlyingMetricRefrefid=«M_TCL_004»/>

<Metricid=«M_TCL_001»description=«TypeOfPIIConsent_Level0»source=«example»scale=«ORDINAL»>

<Expressionid=«E_001»expressionStatement=«0»expressionLanguage=«ISO80000»/>

<Ruleid=«R_001»ruleLanguage=«Russian»lang=«ru»

ruleStatement=«Отсутствие согласия. В процессе или перед сбором персональных данных согласие пользователя получено не было»

/>

<Expressionid=«E_002»expressionStatement=«1»expressionLanguage=«ISO80000»/>

<Ruleid=«R_002»ruleLanguage=«Russian»lang=«ru»

ruleStatement=«Предполагаемое согласие. Согласие вытекает из действий субъекта данных, инструменты выражения согласия или отказа не предоставляются»

<Metricid=«M_TCL_003»description=«TypeOfPIIConsent_Level2»source=«example»scale=«ORDIN»

AL«>»

<Expressionid=«E_003»expressionStatement=«2»expressionLanguage=«ISO80000»/>

<Metricid=«M_TCL_004»description=«TypeOfPIIConsent_Level3»source=«example»scale=«ORDIN»

AL«>»

<Expressionid=«E_004»expressionStatement=«3»expressionLanguage=«ISO80000»/>

<Ruleid=«R_004»ruleLanguage=«Russian»lang=«ru»

ruleStatement=«Выраженное согласие. Субъект данных явным образом подтверждает согласие на сбор и/или использование персональных данных.»/>

Фиксация результатов измерений

Таблица В.30

MeasurementResult (MR_002)
value	3
uncertainty	Данные стороннего аудита
time	25.05.2018 21:00
metric	M_TPC_001

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

Таблица В.31

SO Evaluation (SOE_002)
comparisonResult (true/false)	TRUE
so	SO_002
measurementResult	MR_002

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

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

В.3.2 Пример 1

Например, необходимо собирать информацию для последующего выполнения выборки данных. Это может быть реализовано посредством создания дополнительного элемента «Выборка» (Sample) (входящего во внутреннюю структуру показателя). Представленный ниже пример взят из действующего онлайн-хранилища бинарных данных, в СУС которого предусмотрены разные обязательства в зависимости от типа операций. В представленном примере элемент «Выборка» (Sample) создается только для одного типа операций, однако указанный порядок может быть экстраполирован на другие типы операций. Приведенный ниже фрагмент описания показателя содержит дополнительные сведения для связанного показателя «M_HER_001», посредством использования созданного пользователем элемента «Выборка» (Sample).

«expressionLanguage»:«ISO80000»,

«underlyingExpression»:[

{

«note»:«Number of samples within the boundary period»

},

{

«note»:«Number of error samples within the boundary period»

}

]

«name»:«STORAGEGETBLOCKLISTAPICALLresponsetime»,

«id»:«SAMPLE_001»,

«scale»:«interval»,

«operation»:«GetBlockList»,

«note»:«примервыборкидляизмерениявремениоткликасервиса»

}]

«id»:«MAS_001»,

«source»:«example»,

«scale»:«NOMINAL»,

},

«parameter»:[{

«id»:«P_002»,

}],

«underlyingMetric»:[{

«description»:«Долявременибезотказнойработывтечениемесяца»,

«expression»:{

«id»:«E_002»,

«expressionStatement»:«100 — M_AER_001»,

«underlyingMetric»:[{

«description»:«Средняядоляошибок»,

«id»:«M_AER_001»,

«expression»:{

«expressionStatement»:«M_AER_001 = AVG(M_HER_001) AND M_HER_001 belonging to»

P_001»,

«id»:«P_001»,

«description»:«платежныйпериод»,

«unit»:«month»,

«description»:«Доляошибок, вчас»,

«id»:«M_HER_001»,

«source»:«example»,

«id»:«E_001»,

«expressionStatement»:«E_003/E_002»,

«expressionLanguage»:«ISO80000»,

«expressionStatement»:«&#3A3;(SAMPLE_001 belonging to P_001)»,

«expressionLanguage»:«ISO80000»,

«note»:«Количествоэлементоввыборкиврамкахзаданногопериода »

«expressionStatement»:«&#3A3;(SAMPLE_001.value>P_002 belongingtoP_001)»,

«expressionLanguage»:«ISO80000»,

«note»:«Количествоэлементоввыборкисошибкамиврамкахзаданногопериода »

«parameter»:[

{

«parameterStatement»:«3600»,

},

{

«parameterStatement»:«60»,

{

«id»:«P_003»,

«description»:«платежный период»,

],

«samples»:[{

«name»:«STORAGEGETBLOCKLISTAPICALLresponsetime»,

«unit»:«second»,

«protocol»:«REST»,

«operation»:«GetBlockList»,

}]

}],

«note»:«Пример»

}

В.3.3 Пример 2

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

Поскольку элемент «Выборка» (Sample) в модели не определен, класс «Выборка» (Sample) может быть изменен и получена следующая форма:

«parameter»:[

{

«id»:«P_001»,

«unit»:«month»,

«parameterStatement»:«1»

},

{

«id»:«P_004»,

«parameterStatement»:«small, default, large»,

«scale»:«ordinal»

},

{

«id»:«P_005»,

«unit»:«perday»,

«parameterStatement»:«3»

}

],

«samples»:[{

«description»:«DaCapo Benchmark»,

«id»:«SAMPLE_001»,

«scale»:«interval»,

«value»:«Throughput»,

«unit»:«operations/sec»,

«operation»:«Avrora»,

«workload_type»:«P_004»,

«workload_value»:«default»,

«frequency»:«P_005»,

«note»:«примеропределениятестапроизводительности»

}]

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

Текст JSON-документа для представленного примера изложен ниже:

{

«description»:«Параметрывиртуальногоядрадлямалыхвиртуальныхмашин»,

«id»:«M_MAS_001»,

«source»:«example»,

«scale»:«NOMINAL»,

«expression»:{

«id»:«E_001»,

«expressionStatement»:«M_STD_001 < P_002 & M_AVG_001 <> P_003»,

«expressionLanguage»:«ISO80000»

},

«parameter»:[

{

«id»:«P_002»,

{

«id»:«P_003»,

«unit»:«operations per second»,

«underlyingMetric»:[{

«name»:«Среднеестандартноеотклонениеотэталонныхзначенийтестовпроизводительности, % отсреднегозначения»,

«id»:«M_STD_001»,

«source»:«example»,

«unit»:«%»,

«expressionLanguage»:«ISO80000»

},

«parameter»:[],

«unit»:«»,

«scale»:«interval»,

«expression»:{

«id»:«E_001»,

«expressionStatement»:«average(SAMPLE_001) belonging in P_001»,

«expressionLanguage»:«ISO80000»

},

«parameter»:[

{

«id»:«P_001»,

«unit»:«month»,

«parameterStatement»:«1»

},

{

«id»:«P_004»,

«parameterStatement»:«small, default, large»,

«scale»:«ordinal»

},

{

«id»:«P_005»,

«unit»:«perday»,

«parameterStatement»:«3»

}

],

«samples»:[{

«description»:«DaCapo Benchmark»,

«id»:«SAMPLE_001»,

«scale»:«interval»,

«value»:«Throughput»,

«unit»:«operations/sec»,

«operation»:«Avrora»,

«workload_type»:«P_004»,

«workload_value»:«default»,«frequency»:«P_005»,

«note»:» примеропределениятестапроизводительности «»

}]

}]

}],

«note»:«примерметрикивформате JSON»

}

Приложение Г (обязательное)

XML-СХЕМА МЕТРИЧЕСКОЙ МОДЕЛИ

Представление показателя в форме XML-документа должно соответствовать как UML-модели, представленной в приложении А, так и XML-схеме, представленной ниже. XML-схема соотнесена с пространством имен:

urn:RosStandard:IT:CloudComputing:SLA:Metrics:v1.0.0.

<xs:schemaxmlns:xs=«http://www.w3.org/2001/XMLSchema» elementFormDefault=«qualified»

targetNamespace=«urn:RosStandard:IT:CloudComputing:SLA:Metrics:v1.0.0» version=«1.0.0»

xmlns=«urn:RosStandard:IT:CloudComputing:SLA:Metrics:v1.0.0»>

<xs:complexType name=«MetricType»>

xs:sequence

<xs:element name=«Expression» type=«ExpressionType» minOccurs=«0»/>

<xs:element name=«ExpressionRef» type=«ReferenceType» minOccurs=«0»/>

<xs:element name=«Parameter» type=«ParameterType» minOccurs=«0»

maxOccurs=«unbounded»/>

<xs:element name=«ParameterRef» type=«ReferenceType» minOccurs=«0»

maxOccurs=«unbounded»/>

<xs:element name=«Rule» type=«RuleType» minOccurs=«0» maxOccurs=«unbounded»/>

<xs:element name=«RuleRef» type=«ReferenceType» minOccurs=«0» maxOccurs=«unbounded»/>

<xs:element name=«UnderlyingMetric» type=«MetricType» minOccurs=«0»

maxOccurs=«unbounded»/>

<xs:element name=«UnderlyingMetricRef» type=«ReferenceType» minOccurs=«0»

maxOccurs=«unbounded»/>

<xs:element name=«UnderlyingExpression» type=«ExpressionType» minOccurs=«0»

maxOccurs=«unbounded»/>

<xs:element name=«UnderlyingExpressionRef» type=«ReferenceType» minOccurs=«0»

maxOccurs=«unbounded»/>

</xs:sequence>

<xs:attribute name=«id» use=«required» type=«xs:NCName»/>

<xs:attribute name=«description» type=«xs:string»/>

<xs:attribute name=«source» use=«required» type=«xs:NCName»/>

<xs:attribute name=«scale» use=«required»>

xs:simpleType

<xs:restriction base=«xs:string»>

<xs:enumeration value=«ORDINAL»/>

<xs:enumeration value=«NOMINAL»/>

<xs:enumeration value=«INTERVAL»/>

<xs:enumeration value=«RATIO»/>

</xs:attribute>

<xs:attribute name=«category» type=«xs:string»/>

<xs:attribute name=«note» type=«xs:string»/>

<xs:complexType name=«ParameterType»>

<xs:attribute name=«id» use=«required» type=«xs:NCName»/>

<xs:attribute name=«description» type=«xs:string»/>

<xs:attribute name=«parameterStatement» use=«required» type=«xs:string»/>

<xs:attribute name=«note» type=«xs:string»/>

</xs:complexType>

<xs:complexType name=«ExpressionType»>

<xs:attribute name=«id» use=«required» type=«xs:NCName»/>

<xs:attribute name=«description» type=«xs:string»/>

<xs:attribute name=«expressionStatement» use=«required» type=«xs:string»/>

<xs:attribute name=«expressionLanguage» use=«required» type=«xs:NCName»/>

<xs:attribute name=«unit» type=«xs:NCName»/>

<xs:attribute name=«note» type=«xs:string»/>

</xs:complexType>

<xs:complexType name=«RuleType»>

<xs:attribute name=«id» use=«required» type=«xs:NCName»/>

<xs:attribute name=«ruleStatement» use=«required» type=«xs:string»/>

<xs:attribute name=«ruleLanguage» use=«required» type=«xs:NCName»/>

<xs:attribute name=«lang» use=«required» type=«xs:NCName»/>

<xs:attribute name=«note» type=«xs:string»/>

</xs:complexType>

<xs:complexType name=«ReferenceType»>

<xs:attribute name=«refid» use=«required» type=«xs:NCName»/>

</xs:complexType>

<xs:element name=«Metrics»>

xs:complexType

<xs:choice maxOccurs=«unbounded»>

<xs:element name=«Metric» type=«MetricType»/>

<xs:element name=«Expression» type=«ExpressionType»/>

<xs:element name=«Parameter» type=«ParameterType»/>

<xs:element name=«Rule» type=«RuleType»/>

</xs:choice>

</xs:complexType>

<!- — Uniqueness constraints — ->

<xs:unique name=«metricIDUnique»>

<xs:selector xpath=».//*/Metric«/>»

<xs:field xpath=«@id»/>

</xs:unique>

<xs:unique name=«expressionIDUnique»>

<xs:selector xpath=».//*/Expression«/>»

<xs:field xpath=«@id»/>

</xs:unique>

</xs:unique>

<xs:unique name=«ruleIDUnique»>

<xs:selector xpath=».//*/Rule«/>»

<xs:field xpath=«@id»/>

</xs:unique>

</xs:element>

</xs:schema>

Библиография

[1]	ИСО/МЭК 15939:2017 Системная и программная инженерия. Процесс измерения (Systems and software engineering — Measurement process)
[2]	ИСО/МЭК 19086-1:2016 Информационные технологии. Облачные вычисления. Структура соглашения о качестве предоставляемых услуг (SLA). Часть 1. Обзор и концепции (Information technology — Cloud computing — Service level agreement (SLA) framework — Part 1: Overview and concepts)
[3]	ИСО/МЭК 19501:2005 Информационные технологии. Открытая распределительная обработка. Унифицированный язык моделирования (UML). Версия 1.4.2 (Information technology — Open Distributed Processing — Unified Modeling Language (UML) Version 1.4.2)
[4]	National Institute of Standards and Technology (NIST) Special Publication (SP)800-53 (NIST 800-53)

УДК 004:006.354	ОКС 35.020
Ключевые слова: информационные технологии, облачные вычисления, договор об уровне сервиса, метрическая модель

---